Wiresharkパケット解析講座(4) pcapからオブジェクトをエクスポートする 備忘録
以下の記事を読んだ際の個人的な備忘録です
pcapからさまざまな種類のオブジェクトを出力するためのヒント集
HTTPトラフィックからのオブジェクトのエクスポート
extracting-objects-from-pcap-example-01.pcap
-
以下でフィルタリングを行う
http.request
-
不審な.docと.exeのダウンロードフレームを確認したのち、[Filter] - [Export Objects] - [HTTP…] を選択してオブジェクトをダウンロードする
-
Content type が誤りの可能性も考慮して、ファイルに対して以下のコマンドを実行する
#ファイルの正式な種類を特定する file "filename" #ファイルのSHA256ハッシュを取得する shasum -a 256 "filename"
extracting-objects-from-pcap-example-02.pcap
フィッシングサイトからのネットワークトラフィックをレビューしたい場合、
[Filter] - [Export Objects] - [HTTP…] を選択して元のHTMLページの抽出も可能
SMBトラフィックからのオブジェクトのエクスポート
extracting-objects-from-pcap-example-03.pcap
SMBを使って感染済みクライアント(10.6.26.110)からドメイン コントローラ(10.6.26.6)に広がろうとしたTrickbot感染を取り上げる
[Filter] - [Export Objects] - [SMB…] を選択することで、SMBプロトコルによって通信されていたファイルの出力が可能
[Content Type]が100%になっていないと抽出できない
SMTPトラフィックからの電子メールのエクスポート
extracting-objects-from-pcap-example-04.pcap
-
以下のフィルター文で処理する
smtp.data.fragment
-
[Filter] - [Export Objects] - [IMF…] を選択して.emlファイルの抽出も可能
💡 IMF: Internet Message Format
FTPトラフィックからのファイルのエクスポート
extracting-objects-from-pcap-example-05.pcap
-
以下のフィルター文にて、FTPコマンドを確認する
ftp.request.command
-
以下のフィルター文にて、FTPデータチャネルのトラフィックを確認できる
ftp-data
-
FTPにてやりとりされたファイルのエクスポートはできないが、TCPストリームを辿ることは可能。Informationの末尾が「…( SIZE q.exe)」のフレームを右クリックして[Follow] - [TCP Stream]を選択する
-
これにより、FTPデータチャネルを経由するq.exeのTCPストリームが表示される。 [show data as] を [ASCII]から[Raw]に変更し、[save as..]より保存する
-
以下のコマンドを使用して保存したファイルがEXEであり、SHA256ハッシュの確認ができる(MacまたはLinux環境で実施する)
file q.exe q.exe:PE32 executable (GUI) Intel 80386, for MS Windows shasum -a 256 q.exe ca34b0926cdc3242bbfad1c4a0b42cc2750d90db9a272d92cfb6cb7034d2a3bd q.exe
-
感染したWindowsホストがFTPサーバーに返送したファイルを確認する。HTMLファイルが
STOR
されていることが確認できるftp.request.command
-
以下のフィルター文を使用して、FTPチャネル経由で送信された関連ファイルを確認する
ftp-data.command contains ".html"
-
HTMLファイルを出力することができる、Windowsホストの情報が送信されていることを確認できる
Wiresharkパケット解析講座(3) ホストとユーザーを特定する 備忘録
以下の記事を読んだ際の個人的な備忘録です。
DHCPトラフィックからのホスト情報
ネットワーク内でトラフィックを生成するホストの特定には3つの識別子が必要
内部ネットワークのIPアドレスを持つホスト上でpcapを取得することで関連づけられたMACアドレスとホスト名がわかる
フィルタリングすべきアクティビティ
- DHCP
- IPアドレスを自動割り当てに使用
- RFC2131 (https://tools.ietf.org/html/rfc2131)
- NBNS
- NetBIOS名とIPアドレスの関連付け
- RFC1002 (https://tools.ietf.org/html/rfc1002)
host-and-user-ID-pcap-01.pcap
dhcp
- [Dynamic Host Configuration Protocol (Request)] を展開し、以下の情報を確認する
NetBIOSネームサービス(NBNS)トラフィックからのホスト情報
DHCPリースの更新頻度によってはDHCPトラフィックがpcapに含まれない場合もある
NBNSトラフィックの確認によってIPアドレス・ホスト名・MACアドレスの識別が可能
host-and-user-ID-pcap-02.pcap
10.2.4[.]101の内部IPアドレスを使用しているWindowsホストからなるpcapファイル
NBNSトラフィック(TCP137)を表示する
nbns
HTTPトラフィックからのデバイスモデルとオペレーティングシステム
HTTPトラフィックのヘッダにある User-agent
文字列からOSが確認できる
host-and-user-ID-pcap-03.pcap
Internal IP: 192.168.1[.]97 を使用している Windowsホストからなるpcap
http.request and !(ssdp)
-
以下の列を選択し、詳細を確認する
-
[Hyper Text Transfer Protocol] で右クリックして [Follow] - [TCP Stream]の順に選択する
注:HTTP Bodyも確認したい場合は[HTTP Stream]を選択する
-
[User-Agent] 行を確認する
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.81 Safari/537.36
このとき Windows NTは以下の情報を参照する
Windows NT 5.1 Windows XP Windows NT 6.0 Windows Vista Windows NT 6.1 Windows 7 Windows NT 6.2 Windows 8 Windows NT 6.3 Windows 8.1 Windows NT 10.0 Windows 10
<aside> 💡 SSDP(Simple Service Discovery Protocol) UPnP(Universal Plug and Play)デバイスの検出と構成に使用されるマルチキャストプロトコル マルチキャストアドレス「239.255.255.250」に送信されるメッセージを使用して、ネットワーク上のUPnP対応デバイスを検出 Webブラウザーやその他のアプリケーションからのデバイスの検出によく使用される UPnP機能を備えたルーターやネットワークアダプタなどのデバイスでも使用される
</aside>
host-and-user-ID-pcap-04.pcap
Internal IP: 172.16.4[.]119 を使用している Androidホストからなるpcap
host-and-user-ID-pcap-05.pcap
iOSバージョンの特定が可能
HTTPSだとこれらの端末バージョンやブラウザ種類の特定が不可なことに注意
KerberosトラフィックからのWindowsユーザーアカウント
host-and-user-ID-pcap-05.pcap
以下フィルター文にてKerberos認証プロトコルで使用される「CNameString」フィールドを抽出する
「CNameString」はクライアントやサーバーの識別に使用される
kerberos.CNameString
-
1行目のフレームを指定し、詳細を確認する
-
[Kerberos] - [as-req] - [req-body] - [cname] - [CNameString: xxxxx]を右クリックし、[Apply as Column]する
-
ホスト名の「CNameString」は末尾が常に「$」になっているが、ユーザーアカウント名には「$」はつかない
-
以下のフィルター文を使用して、コンピューターアカウント(ホスト)名を除外できる
kerberos.CNameString and !(kerberos.CNameString contains "$")
Wiresharkパケット解析講座(2) 脅威インテリジェンス調査に役立つフィルタリング設定 備忘録
以下の記事を読んだ際の個人的な備忘録です。
基礎的なところがわかっていなくてRFC遡ってたりしたら2時間くらいかかりました。
URLやドメインは悪性なのでアクセスされないようご注意ください。
pcapでWebトラフィックをすばやく確認する
http.request or ssl.handshake.type == 1
不要なトラフィックの除外
使用ファイル:Using-Wireshark-diplay-filters-Emotet-with-IcedID.pcap
今回は1900/udp(Simple Service Discovery Protocol:SSDP)を除外する
(http.request or ssl.handshake.type == 1)and!(udp.port eq 1900) または (http.request or ssl.handshake.type == 1)and!(ssdp)
TCP接続を拒否するサーバーへの接続試行(TCP SYN セグメント)を含める
(http.request or ssl.handshake.type == 1 or tcp.flags eq 0x0002) and !(udp.port eq 1900)
DNS活動をフィルタする
使用ファイル:Using-Wireshark-diplay-filters-Nanocore-RAT.pcap
以下を追加することで、DNSの活動もフィルタすることができる
(http.request or ssl.handshake.type ==1 or tcp.flags eq 0x0002 or dns) and !(udp.port eq 1900)
上記のフィルター文は以下意味を持つ
- http.request or ssl.handshake.type==1 or tcp.flags eq 0x002 or dns
- !(udp.port eq 1900)
- UPnP(ユニバーサルプラグアンドプレイ)デバイスディスカバリプロトコルに対応するUDPポート1900のパケットを除外する
- ssl.handshake.type
-
-
- 0: HelloRequest
- 1: ClientHello
- 2: ServerHello
- 3: Certificate
- 4: ServerKeyExchange
- 5: CertificateRequest
- 6: ServerHelloDone
- 7: CertificateVerify
- 8: ClientKeyExchange
- 9: Finished
- 10: CertificateURL
- 11: CertificateStatus
- 12: SupplementalData
-
各メッセージの詳細については以下を参考にする
Wireshark · Display Filter Reference: Secure Sockets Layer
以下のフィールド文について
[TCP Retransmission] [TCP Port numbers reused] 49194 → 19055 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM
- [TCP Retransmission]
- このパケットが再送されたことを示す
- パケットが到着しなかった場合、送信元はパケットを再送することがある
- [TCP Port numbers reused]
- パケットに含まれる送信元ポート番号が、以前に使用されたポート番号と同じであることを示す
- [SYN]
- Seq=0
- データシーケンス番号が0であることを示す
- TCPでは、データがシーケンス番号に基づいて順序付けられる
- Win=8192
- 受信ウィンドウサイズが8192バイトであることを示す
- 送信元がバッファリングされたデータ量を指定する
- Len=0
- パケットに含まれるデータの長さが0であることを示す
- MSS=1460
- 最大セグメントサイズが1460バイトであることを示す
- 送信元と受信元の間で使用する最大ペイロードサイズを指定する
- WS=256
- ウィンドウスケール値が256であることを示す
- ウィンドウスケール値は、受信ウィンドウサイズを拡張するために使用される
- SACK_PERM
- Selective Acknowledgement Permittedが有効であることを示す
- 受信元が受信データを再送信する際に失われたデータだけを再送信することを可能にするフラグ
Standard query 0x9bf6 A www.mercedes-club-bg[.]com
- Standard query 0x9bf6
- A
- www.mercedes-club-bg[.]com
- DNSクエリの対象となるホスト名を示す
使用ファイル:Using-Wireshark-diplay-filters-FTP-malware.pcap
21: SSHサーバーが情報を待ち受ける
22: SSHサーバーが情報を送る
(1) 以下文でフィルターする
http.request or ssl.handshake.type==1 or tcp.flags eq 0x002 or dns or ftp
(2) 得られたフレームから抜粋して説明する
- FTP(File Transfer Protocol)のデータ転送しているフレームのInformationについて
Request: SIZE fc32.exe
Response: 213 670720
- FTPの
SIZE
コマンド- クライアントは、サーバーに対してfc32.exeファイルのサイズを問い合わせている
- サイズは
670720 byte
であることがわかる
- FTPの
- 続くFTPのフレームについて
Request: RETR fc32.exe
Response: 150-Accepted data connection
- クライアントは、fc32.exeファイルをダウンロードするために
RETR
コマンドを送信
- クライアントは、fc32.exeファイルをダウンロードするために
- サーバーは、データ接続を受け入れたことを示す
150
レスポンスを送信 - 続くFTPのフレームについて
Response: 226-File successfully transferred
- FTPのファイル転送の完了を示す
- サーバーはファイルが正常に転送されたことを示す226レスポンスを送信
FTPコマンドについて
以下の4.1.3. FTP SERVICE COMMANDS
を参照する
RFC 959: File Transfer Protocol
一部抜粋
- USER: FTPサーバーにログインするためのユーザー名を指定する
- PASS: ユーザーのパスワードを指定する
- RETR: ファイルをダウンロードするために使用するコマンド。ファイルの名前を指定する
- STOR: ファイルをアップロードするために使用するコマンド。ファイルの名前を指定する
- DELE: FTPサーバーからファイルを削除するためのコマンド。ファイルの名前を指定する
- SIZE: ファイルのサイズを取得するためのコマンド。ファイルの名前を指定する
- LIST: FTPサーバー上のディレクトリの内容をリストするためのコマンド。オプションでファイル名を指定することもできる
一部抜粋
4.2.1 Reply Codes by Function Groups
FTP パッシブモード/アクティブモード
- アクティブモード
- FTP(File Transfer Protocol)でサーバーがクライアントが指定したポートに接続してデータを送信
- パッシブモード
Wireshark における FTPフィルターについて
Wireshark · Display Filter Reference: Secure Sockets Layer
Using-Wireshark-diplay-filters-FTP-malware.pcapの分析
- ftp.totallyanonymous[.]com のAレコード確認、IPアドレスが
192.185.230[.]61
とわかる 192.185.230[.]61
にて以下のユーザー名、パスワードでサインインする- Request: USER schw@totallyanonymous1[.]com
- Request: PASS 520s984W
192.185.230[.]61
からFTPにて以下のファイルをダウンロードする- fc32.exe
- o32.exe
- ip.exe
- fc64.exe
- o64.exe
- myexternalip[.]comのAレコード確認、IPアドレスが
78.47.139[.]102
とわかる 192.185.230[.]61
にリダイレクトされ、今度は異なるユーザー名とパスワードでサインインする- Request: USER schw@totallyanonymous[.]com
- Request: PASS 520s984W
STOR
コマンドを使用して、ファイルをアップロードする- Request: STOR 6R7MELYD6
- ログアウト
使用ファイル:Using-Wireshark-diplay-filters-spambot.pcap
Wiresharkパケット解析講座(1) 表示列カスタマイズ 備忘録
以下の記事を読んだ際の個人的な備忘録です。
- 列を非表示または削除する:
- No.
- Protocol
- Length
- 列を追加する
- Time
- Source address
- Src port (unresolved) !New !Align left
- Destination address
- Dest Port (unredolved) !New !Align left
- Information
- 列の時刻設定をUTCに変更する
- [View] - [Time Display Format] - [Seconds Since Beginning of Capture] —> [UTC Date and Time of Day]
- [View] - [Time Display Format] - [Automatic] —> [Seconds]
- カスタム列の追加
- Display Filter にて「http.request」を指定する
- [Packet Details] ペインで [Hypertext Transfer Protocol] → [Host:] の行を右クリックし [Apply as Column]を選択
- Display Filter にて「ssl.handshake.type == 1」を指定する
- [Packet Details] ペインで [Secure Sockets Layer] → [TLSv1.2 Record Layer…] → [Handshake Protocol: Client Hello] → [Extension: server_name] → [Server Name Indication extension] → [Server Name: …] の行を右クリックし [Apply as Column]を選択
独学でCISSPを受験してきた(2022年11月)
こんにちは、またははじめまして。
先日CISSPを受けてきて、無事合格したためそこまでの学習記録を書いておこうと思います。
自分は非情報系学部からIT企業に新卒入社し、2年ほど営業ぽいことをしたのち、セキュリティ部門の技術職に異動して2年目になります。
技術職への異動に際して情報セキュリティマネジメントとかITパスポートをせっせと受験した程度で、あとは実務に必要なドキュメントをひたすら読み解き体当たりする日々です。
汎用的な情報系の知識がどれくらいないかというと、今年の4月にセキスペ受けて落ちてます。その時は先輩エンジニアに「セキスペすら落ちるようなエンジニアがセキュリティ関係のお仕事をしてるって許されないですよね....ハハ」という大変めんどくさい絡み方をするなどしています。
なので今回のCISSP受験はかなり自分の実力と距離感ある無謀な挑戦でした。ちなみに講座は受けておらず独学です。
私の受験記が、今後受験される方のお役にほんのすこしでも立てばとてもうれしいです☻
学習開始前のスペック
- IT企業(営業兼カスタマーサクセス+技術職)で体当たりの勤務経験4年間
- ITチョットワカル、特定の製品はマアマアワカル
持っている資格
- 情報セキュリティマネジメント
- ITパスポート
- マイクロソフト認定資格試験各種(最近だとSC-100とか取りました)
使用した教材と学習期間
以下の流れで勉強しました。4ヶ月とかなり長期間やってますが、実際に合計した勉強時間は250時間ほどかと思います。
学習期間 |
教材 |
勉強方法 |
8月 |
Eleventh Hour CISSP: Study Guide |
DeepLに翻訳かける翻訳かけたやつを3〜4周読む |
9月〜10月中旬 |
CISSP公式問題集 |
第1章〜第12章を3周強やる |
新版CISSP CBK 公式ガイド |
公式問題集でわからなかった単語調べる 章末問題を2周する |
|
10月下旬〜11月上旬 |
CISSP certification study guides, cheatsheet |
DeepLに翻訳かける 全然解釈が違う内容になるのでちまちま直す 3周くらい読む |
あとネットワーク系の知識が著しくないため、IPSecとかネットワーク脆弱性についてはYoutubeチャンネル「まさるの勉強部屋」さんに大変お世話になりました。
インフラエンジニアとかペンテスター経験ある方は2週間とかで足りるかもですが、諸々の知識がすっぱ抜けてる自分的にはインフラの冗長構成やネットワークの知識を一から勉強するにあたってこれくらいの時間は必要だったと感じています。(実際の試験に役立つかはさておき...)
各教材のURLは以下の通りです。
新版 CISSP CBK公式ガイドブック | アダム・ゴードン, 笠原 久嗣【監訳】, 井上 吉隆【監訳】, 桑名 栄二【監訳】 |本 | 通販 | Amazon
学習方法詳細
一部notionやPPT にまとめたりしていますが、自分は文字を「書く」行為に集中してしまい、内容が全く暗記できないため「書く」という行為はあまりしていません。
また、これは学習方法のひとつのためご参考までにご覧いただけますと幸いです。
【8月】
■Eleventh Hour CISSP: Study Guide
notion に翻訳をまとめてから、2周読みました。
最初は言っていることがさっぱりわからなくてぐぐったり、説明してくれているYoutubeの動画を見たり、途中で読む気を失ってマンガ読んだりしていたため1章読み終えるのに2~3日以上かけてやっていました。
そのため読み切るのに1か月かかってしまいましたが、普通にわかる人が読んだら1日前後で終わると思います。
【9月〜10月中旬】
■CISSP公式問題集
初見の問題は1章とくのに2~3時間ほどかけていました。
一気に解かずに1問解いて、解説読んでを繰り返していました。
間違えた問題はマークしており、間違えた回数に応じて色を変えていました。
1度間違えた:黄
2度間違えた:青
3度間違えた:赤
こんな感じです。PC版のKindleだと問題番号のリンクを押すとすぐ回答ページに飛ばされてしまって該当問題の回答だけチラ見することができなかったので、基本的にiPad で解いてました。
解説で用語がかなりわかりやすく説明されていることが多いので、解説にマーカー挽いて見返したりもしていました。
正答率の推移は
1回目:50~60% → 2回目: 80%前後 → 3回目: 90%前後 という感じでした。
特に第4章と第5章が弱かったので、そこだけ4回解きました。
■新版CISSP CBK 公式ガイド
章末問題だけ解きました。
公式問題集よりほんの少し難易度が高く、出題範囲にほぼ重複がないため知識の振り返りに役立ちました。
2回ほど解きました。
【10月下旬〜11月上旬】
■CISSP certification study guides, cheatsheet
リンクを開いていただければわかりますが、すべて英語のチートシートなので以下のように和訳してからpdf化してiPadに吐き出し、3~4周しました。
途中でわからないところや追加したいところはApple Pencil で書き込みを入れていったりしました。
章ごとに分量が違うので何とも言えないですが、1ページ15分以上はかけて関連用語を思い出したりしながら読んでいたと思います。
試験当日
身分証明書が2つ(内1つは写真有り)と食べ物が必要です。
お菓子を選ぶほどの精神的余裕がなかったのと、久しぶりの試験勉強と高い受験代のプレッシャーで油っぽいお菓子が苦手になっていたので炊き込みご飯のおにぎりを持っていきました。
8時から試験開始なので余裕を持って7時半前についたらその瞬間から試験が始まってしまい、めっちゃ焦りました。250問を6時間で解くのですが、私は4時間ほどで解き終えて会場を出ました。
170問ほど解いた後に10分ほど休憩をとり、残りの80問を解くという感じでした。1問1分以内を意識して解き進めていましたが時間配分を深く考えずに解いていっても制限時間をオーバーすることはないと思います。
本当は100問解いたら休憩というのを考えていたのですが、「もし、時間が足りなくなったらどうしよう...」「ここで悠々と休んだことが原因で落ちちゃったらどうしよう」とかの変な不安が先立ち、空腹の限界まで解いたときには170問目でした。
最後に
昨年技術職に異動してから実業務のキャッチアップに忙しすぎて、自分の勉強というものが全くできていなかったのですが、今回の試験勉強を通じて朝の始業前に1~2時間・終業後に2~4時間は確実に机に向かえる習慣が身についたので、習慣づけという観点ですごくいい経験になりました。
また時間があればあるほど業務に割いてしまい、平日は9時ー18時の業務時間を超えて、土日もダラダラと仕事してしまうみたいな悪い習慣がついており、試験勉強を成り立たせるにはそれらをすっぱりすっぱり断たねばならなかったので業務量の調整(オーバーワークしない)感覚が身についたように思います。
実務で役に立つかはまだわからないですが、引き続き研鑽していきます。
お読みいただきありがとうございました。
「事件・事故発生時の対策 有事に混乱しないための準備、技術、事例」を聞いてきました
以下のイベントを初めて聴講してきました。
登壇された5名の専門家の皆さまが持ち寄られた気になるトピックスについて45分間のパネルディスカッションが行われました。
ディスカッションされたトピックスは以下の5つになります。
- EC-CUBE 4.0 のXSSの脆弱性(徳丸さん)
- 事故原因報告のあり方(北河さん)
- ユーザー企業側で防ぎにくい攻撃(根岸さん)
- 知ってほしい事故対応事例(辻さん)
- オンラインでの本人確認(eKYC)(piyokangoさん)
以下に各トピックを持ち寄った専門家の方の補足説明と、議論についての議事を記載します。[議論]については、私の認識間違いがあるかもしれませんので、流し読みでお願いします。
EC-CUBE 4.0 のXSSの脆弱性(徳丸さん)
クロスサイトスクリプティング(XSS)は有名な脆弱性であるものの、悪用事例があまり知られておらず、対策が後回しになる傾向があるEC-CUBE 4.0のXSSはクレジットカード情報漏洩に至ったことが発表され、今後ウェブサイトへの攻撃のトレンドが変わる可能性を感じる*1
議論
- 管理画面の脆弱性で、本製品は中小零細企業で多く利用されているが、対策がおろそかになっている傾向がある(徳丸さん)
- 決済代行事業者からECサイトオーナーに注意喚起をしている状況(徳丸さん)
- 自分達が利用している製品の脆弱性を管理できているかが大切(根岸さん)
- XSSはアラートが出るだけという認識が広まっているのが良くなかった(徳丸さん)
- サイト運営者が、構築時のベンダーと連絡も取れず、運用保守まで手が回っていない(徳丸さん)
- EC-CUBE は注意して対応しているが、それでもなりやすいのか(北河さん)
- このような製品の場合、表示箇所のすべてが脆弱性となりうるし、管理画面のため脆弱性対応が薄かった(徳丸さん)
- XSSは脆弱性の高中低の中で、「中」と診断されがちだが、今後「高」と判断されることもあると思うか(辻さん)
- あるべき論としてはそうなりうるのではないか(徳丸さん)
事故原因報告のあり方(北河さん)
2020年10月 北米現地法人に設置していた旧型VPN装置から侵入。別型のVPN装置を導入済みだったが通信障害が発生した際の緊急避難用として1台のみ残存していた*2
具体的なメーカーや機種、脆弱性などについては、「詳しい情報を公開すると田曽式に影響を及ぼす恐れがある(同社広報)」などとして、コメントを避けた*3
議論
- 侵入原因の詳細が明らかでないため、具体的な対策が取りにくい。他社企業が対策しやすいように、より詳細な事由を公開をした方が良いのでは(北河さん)
- VPNの利用増加のあった4月から離れた10月に事件が起きたことから、なぜその脆弱性に気づけなかったのか知りたい。(北河さん)
- 事故対応アワードという取り組みの中で、事故情報の公開をいかにすべきかを議論している。被害を受けた企業自らどこまで公開するのが適切かを判断するのが難しかったのではないか。出さない方が社内的な判断として楽。(根岸さん)
- 〇HKの事例踏まえ、企業広報としてよく見せたいという心理もあるのではないか(徳丸さん)
- 基準がはっきりしていないので、広報等の関係者が藪蛇となるのを避けたい。関係者が多いことによるふわっとした怖さがある。(辻さん)
- 当事者の人たちが公開すべき部分とそうでない部分を判断できない。マイナスになることはないと専門家サイドは考えている(根岸さん)
- セキュリティを専門としないITエンジニアにとっても、攻撃手法を公開することに抵抗感がある(徳丸さん)
- 「旧型」の概念が企業によって異なるので・・・(徳丸さん)
ユーザー企業側で防ぎにくい攻撃(根岸さん)
アプライアンスやクラウドサービスの脆弱性による情報漏洩、サプライチェーン攻撃によるマルウェア感染など、ユーザー企業側で防ぎにくい攻撃にどう対処すべきか*4*5
議論
- ベンダー側の管理が原因となる問題が最近目立っている印象。ユーザーはこれらにどう向き合えばいいのかという質問に、専門家として答えにくいように感じる(根岸さん)
- 事前対応を捨てて、インシデントレスポンスに注力する等(徳丸さん)
- メルカリがCodecov社の脆弱性によって攻撃を受けた事件では、ソースコードだけでなく顧客情報も窃取されたことを踏まえ、プライベートなGitHubリポジトリにアクセスキーを置くのは控えたほうがいいとされている
- 機微な情報を散在させないという予防はできるのではないか(徳丸さん)
- 各ユーザーでクラウドサービスに機微な情報を業務上置くこともあるが、ちゃんと判断する必要がある。(根岸さん)
- 複数の事例が出てくる中で、すべてのユーザーが管理するのは難しい。利用者からすると何が起きているかわからない。全体的な統制を取る仕組みが必要と感じる(piyokangoさん)
- 様々な企業が提供しているサービスに対して、ユーザーと提供企業ではない、第三者の立場から統制するような組織が必要(piyokangoさん)
- アメリカでは飛行機調査の様に、セキュリティの問題についても事故調査を実施する第三者委員会が必要という議論がある(根岸さん)
- 広く影響が及ぶようなケースは、ベンダー側に強力な働きかけができる組織が必要(piyokangoさん)
- 日本企業が海外製品で被害を受けた事例はあまり聞かない。日本の製品を利用しているときに、自分がその製品ユーザー内で何番目にあたるのか、脆弱性がっ見つかった際にどれくらい攻撃を受ける確率が高いのか等を意識して製品を利用することも必要なのでは(北河さん)
知ってほしい事故対応事例(辻さん)
ノルウェーのサプライヤVolue社のランサム事案対応
① 被害が発生した当日の公表
② 自組織以外のチャネル(SNS、動画配信)の活用
③ 頻繁で積極的な情報公開
④ 顧客に向けたガイダンスの公開
⑤ リーダーシップの可視化
議論
- ここまで出していいんだと判断する一つの事例とはなる。完全に真似するのは難しいとは思うが、いいところは取り入れてほしい(根岸さん)
- リーダーシップの可視化は大切(徳丸さん)
オンラインでの本人確認(eKYC)(piyokangoさん)
- オンラインで実行者が本人であることを確認する手段
- 決裁アプリをはじめ様々なサービスでeKYCの導入が進んでいる
- パスワードがたどった道をたどらないかの懸念
(数えられないほどのパスワード情報が流通しているが、本人確認で利用されている運転免許証やパスポートといった本人確認用画像データが今後どこかに流出したことをきっかけにインターネット上で巡り巡ることにならないかの懸念) - コントロールが効かない範囲に漏れた後の最適解はあるか
(上記画像データが流出した場合の、ユーザーの最適解は何なのか)
議論
- eKYCのサービス提供事業者によっては、ライブネス判定を入れている企業もある
- 対面でやっていた本人確認をインターネットで完結できるような流れが生まれており、金融機関以外の企業がそうした認証をするときにどう守るかが問題。(根岸さん)
- 郵送での確認フェーズを含むことが多く、画像データのみで口座が作られることは一般的にはない。オンラインで完結させる企業は厳しい対応をしているように思う。(北河さん)
*1:【重要】EC-CUBE 4.0系における緊急度「高」の脆弱性(JVN#97554111)発覚と対応のお願い(2021/5/24 17:00 更新)|ECサイト構築・リニューアルは「ECオープンプラットフォームEC-CUBE」
*2:不正アクセスに関する調査結果のご報告【第4報】 | 株式会社カプコン (capcom.co.jp)
*3:【セキュリティ ニュース】カプコンへの不正アクセス、侵入経路は予備に残した以前のVPN機器(2ページ目 / 全2ページ):Security NEXT (security-next.com)