imdays

勉強の記録

Wiresharkパケット解析講座(4) pcapからオブジェクトをエクスポートする 備忘録

以下の記事を読んだ際の個人的な備忘録です

unit42.paloaltonetworks.jp

 

pcapからさまざまな種類のオブジェクトを出力するためのヒント集

HTTPトラフィックからのオブジェクトのエクスポート

extracting-objects-from-pcap-example-01.pcap

  1. 以下でフィルタリングを行う

    http.request

  2. 不審な.docと.exeのダウンロードフレームを確認したのち、[Filter] - [Export Objects] - [HTTP…] を選択してオブジェクトをダウンロードする

  3. 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トラフィックからの電子メールのエクスポート

  • 感染したWindowsホストをスパムボットに変更するマルウェアがある
  • スパムボット
    • 毎分数百件ものスパムメッセージや電子メールを送信する
    • SMTPを使ってメッセージ送信することもある

extracting-objects-from-pcap-example-04.pcap

  1. 以下のフィルター文で処理する

    smtp.data.fragment

  2. [Filter] - [Export Objects] - [IMF…] を選択して.emlファイルの抽出も可能

    💡 IMF: Internet Message Format

FTPトラフィックからのファイルのエクスポート

extracting-objects-from-pcap-example-05.pcap

  • 以下を確認することができる
    • FTPサーバーから取得されたマルウェア実行可能ファイル
    • 感染したWindowsホストがFTPサーバーに返送したファイル

  1. 以下のフィルター文にて、FTPコマンドを確認する

    ftp.request.command

  2. 以下のフィルター文にて、FTPデータチャネルのトラフィックを確認できる

    ftp-data

  3. FTPにてやりとりされたファイルのエクスポートはできないが、TCPストリームを辿ることは可能。Informationの末尾が「…( SIZE q.exe)」のフレームを右クリックして[Follow] - [TCP Stream]を選択する

  4. これにより、FTPデータチャネルを経由するq.exeのTCPストリームが表示される。 [show data as] を [ASCII]から[Raw]に変更し、[save as..]より保存する

  5. 以下のコマンドを使用して保存したファイルが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

  6. 感染したWindowsホストがFTPサーバーに返送したファイルを確認する。HTMLファイルが STOR されていることが確認できる

    ftp.request.command

  7. 以下のフィルター文を使用して、FTPチャネル経由で送信された関連ファイルを確認する

    ftp-data.command contains ".html"

  8. HTMLファイルを出力することができる、Windowsホストの情報が送信されていることを確認できる

Wiresharkパケット解析講座(3) ホストとユーザーを特定する 備忘録

以下の記事を読んだ際の個人的な備忘録です。

unit42.paloaltonetworks.jp

 

DHCPトラフィックからのホスト情報

ネットワーク内でトラフィックを生成するホストの特定には3つの識別子が必要

内部ネットワークのIPアドレスを持つホスト上でpcapを取得することで関連づけられたMACアドレスとホスト名がわかる

フィルタリングすべきアクティビティ

host-and-user-ID-pcap-01.pcap

DHCPトラフィックを表示する

dhcp
  1. [Dynamic Host Configuration Protocol (Request)] を展開し、以下の情報を確認する
    • [Option: (61) Client identifier] - [Client MAC address: Apple_d2:e3:4f (7c:6d:62:d2:e3:4f)]
    • [Option: (12) Host Name] - [Host Name: Rogers-iPad]

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)

  1. 以下の列を選択し、詳細を確認する

  2. [Hyper Text Transfer Protocol] で右クリックして [Follow] - [TCP Stream]の順に選択する

    注：HTTP Bodyも確認したい場合は[HTTP Stream]を選択する

  3. [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. 1行目のフレームを指定し、詳細を確認する

  2. [Kerberos] - [as-req] - [req-body] - [cname] - [CNameString: xxxxx]を右クリックし、[Apply as Column]する

  3. ホスト名の「CNameString」は末尾が常に「$」になっているが、ユーザーアカウント名には「$」はつかない

  4. 以下のフィルター文を使用して、コンピューターアカウント(ホスト)名を除外できる

    kerberos.CNameString and !(kerberos.CNameString contains "$")

Wiresharkパケット解析講座(2) 脅威インテリジェンス調査に役立つフィルタリング設定 備忘録

以下の記事を読んだ際の個人的な備忘録です。

基礎的なところがわかっていなくてRFC遡ってたりしたら2時間くらいかかりました。

URLやドメインは悪性なのでアクセスされないようご注意ください。

unit42.paloaltonetworks.jp

 

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)

上記のフィルター文は以下意味を持つ

      • 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

各メッセージの詳細については以下を参考にする

RFC 5077: Transport Layer Security (TLS) Session Resumption without Server-Side State (rfc-editor.org)

TLS

Wireshark · Display Filter Reference: Secure Sockets Layer

 

  • tcp.flags
    • TCPヘッダーのフラグビットを表す
    • TCPヘッダーは、TCPプロトコルで送信されるパケットに含まれる
    • tcp.flagsには、以下のような値がある
      • 0x000: None (フラグなし)
      • 0x001: FIN (接続終了を示すフラグ)
      • 0x002: SYN (接続開始を示すフラグ)
      • 0x004: RST (接続リセットを示すフラグ)
      • 0x008: PSH (データ送信を要求するフラグ)
      • 0x010: ACK (確認応答を示すフラグ)
      • 0x020: URG (緊急データを含むことを示すフラグ)
      • 0x040: ECE (ECNによる輻輳制御を示すフラグ)
      • 0x080: CWR (ECNによる輻輳制御を示すフラグ)
    • 上記のフラグビットは、値をOR演算子で組み合わせることができる
      • たとえば、tcp.flagsが0x018である場合、ACKフラグとPSHフラグがセットされていることを示す
    • TCPのフラグビットの詳細については、RFC 793（Transmission Control Protocol）を参照する

 

以下のフィールド文について

[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]
    • SYNフラグが設定されていることを示す
    • SYNはTCP接続確立の最初のステップであり、通信相手に接続をリクエストするフラグ
  • Seq=0
    • データシーケンス番号が0であることを示す
    • TCPでは、データがシーケンス番号に基づいて順序付けられる
  • Win=8192
    • 受信ウィンドウサイズが8192バイトであることを示す
    • 送信元がバッファリングされたデータ量を指定する
  • Len=0
    • パケットに含まれるデータの長さが0であることを示す
  • MSS=1460
    • 最大セグメントサイズが1460バイトであることを示す
    • 送信元と受信元の間で使用する最大ペイロードサイズを指定する
  • WS=256
    • ウィンドウスケール値が256であることを示す
    • ウィンドウスケール値は、受信ウィンドウサイズを拡張するために使用される
  • SACK_PERM
    • Selective Acknowledgement Permittedが有効であることを示す
    • 受信元が受信データを再送信する際に失われたデータだけを再送信することを可能にするフラグ

 

以下DNSトラフィックのInformationの説明

Standard query 0x9bf6 A www.mercedes-club-bg[.]com
  • Standard query 0x9bf6
  • A
    • このDNSクエリのタイプを示し、この場合はIPv4アドレスを意味する
  • 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のフレームについて
    • Request: RETR fc32.exe
    • Response: 150-Accepted data connection
      • クライアントは、fc32.exeファイルをダウンロードするために RETRコマンドを送信
  • サーバーは、データ接続を受け入れたことを示す 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）でサーバーがクライアントが指定したポートに接続してデータを送信
  • パッシブモード
    • クライアントがファイアウォールやNAT背後にある等の制限でFTPクライアントがサーバーに対してアクセスできない場合
    • FTPサーバーがデータを送信するためにランダムに選択したポートを開き、クライアントはこのポートに接続してデータを受信

      1. FTPサーバーはPASVコマンドを使用して、クライアントに対して使用するポートを通知

      2. クライアントは、このポートに接続してデータを受信するための新しい接続を開始

        💡 注意 FTPパッシブモードはセキュリティ上の問題がある FTP暗号化や、代替プロトコル(例:SFTP)の使用が推奨

 

Wireshark における FTPフィルターについて

Wireshark · Display Filter Reference: Secure Sockets Layer

 

Using-Wireshark-diplay-filters-FTP-malware.pcapの分析

  1. ftp.totallyanonymous[.]com のAレコード確認、IPアドレスが 192.185.230[.]61 とわかる
  2. 192.185.230[.]61にて以下のユーザー名、パスワードでサインインする
    • Request: USER schw@totallyanonymous1[.]com
    • Request: PASS 520s984W
  3. 192.185.230[.]61からFTPにて以下のファイルをダウンロードする
    • fc32.exe
    • o32.exe
    • ip.exe
    • fc64.exe
    • o64.exe
  4. myexternalip[.]comのAレコード確認、IPアドレスが 78.47.139[.]102 とわかる
  5. 192.185.230[.]61にリダイレクトされ、今度は異なるユーザー名とパスワードでサインインする
    • Request: USER schw@totallyanonymous[.]com
    • Request: PASS 520s984W
  6. STOR コマンドを使用して、ファイルをアップロードする
    • Request: STOR 6R7MELYD6
  7. ログアウト

 

使用ファイル：Using-Wireshark-diplay-filters-spambot.pcap

  1. クライアント(10.6.5[.]102)からDCおよびDNSサーバー(10.6.5[.]1)に向けてさまざまなメールサーバーへのDNSクエリがみられる

  2. SMTPトラフィックに関連した465/tcp, 587/tcpへのTCP SYNパケットも見られる

  3. 以下の情報が得られるので、各IPに対してTCP SYNパケットを送っている

  4. TCPストリームを追跡して内容確認する
  5. 特定のフレームを指定し、右クリックして [Follow] - [TCP Stream]の順に選択する
    •  そのフレームに関連するSMTP通信の内容が表示される
    • 例えばスパムbotから送信された電子メールの一つが見つかる

Wiresharkパケット解析講座(1) 表示列カスタマイズ 備忘録

以下の記事を読んだ際の個人的な備忘録です。

unit42.paloaltonetworks.jp

  •  列を非表示または削除する：
    • 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]
  • カスタム列の追加
    1. Display Filter にて「http.request」を指定する
    2. [Packet Details] ペインで [Hypertext Transfer Protocol] → [Host:] の行を右クリックし [Apply as Column]を選択
    3. Display Filter にて「ssl.handshake.type == 1」を指定する
    4. [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チョットワカル、特定の製品はマアマアワカル

 

持っている資格

 

使用した教材と学習期間

以下の流れで勉強しました。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チャンネル「まさるの勉強部屋」さんに大変お世話になりました。

まさるの勉強部屋 - YouTube

インフラエンジニアとかペンテスター経験ある方は2週間とかで足りるかもですが、諸々の知識がすっぱ抜けてる自分的にはインフラの冗長構成やネットワークの知識を一から勉強するにあたってこれくらいの時間は必要だったと感じています。（実際の試験に役立つかはさておき...）

 

各教材のURLは以下の通りです。

amzn.asia

amzn.asia

新版 CISSP CBK公式ガイドブック | アダム・ゴードン, 笠原 久嗣【監訳】, 井上 吉隆【監訳】, 桑名 栄二【監訳】 |本 | 通販 | Amazon

www.comparitech.com

 

学習方法詳細

一部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に吐き出し、３～４周しました。

途中でわからないところや追加したいところはApple Pencil で書き込みを入れていったりしました。

章ごとに分量が違うので何とも言えないですが、1ページ15分以上はかけて関連用語を思い出したりしながら読んでいたと思います。

 

試験当日

身分証明書が2つ（内1つは写真有り）と食べ物が必要です。

お菓子を選ぶほどの精神的余裕がなかったのと、久しぶりの試験勉強と高い受験代のプレッシャーで油っぽいお菓子が苦手になっていたので炊き込みご飯のおにぎりを持っていきました。

 

8時から試験開始なので余裕を持って7時半前についたらその瞬間から試験が始まってしまい、めっちゃ焦りました。250問を6時間で解くのですが、私は4時間ほどで解き終えて会場を出ました。

170問ほど解いた後に10分ほど休憩をとり、残りの80問を解くという感じでした。1問1分以内を意識して解き進めていましたが時間配分を深く考えずに解いていっても制限時間をオーバーすることはないと思います。

本当は100問解いたら休憩というのを考えていたのですが、「もし、時間が足りなくなったらどうしよう...」「ここで悠々と休んだことが原因で落ちちゃったらどうしよう」とかの変な不安が先立ち、空腹の限界まで解いたときには170問目でした。

 

最後に

昨年技術職に異動してから実業務のキャッチアップに忙しすぎて、自分の勉強というものが全くできていなかったのですが、今回の試験勉強を通じて朝の始業前に1~2時間・終業後に2~4時間は確実に机に向かえる習慣が身についたので、習慣づけという観点ですごくいい経験になりました。

 

また時間があればあるほど業務に割いてしまい、平日は9時ー18時の業務時間を超えて、土日もダラダラと仕事してしまうみたいな悪い習慣がついており、試験勉強を成り立たせるにはそれらをすっぱりすっぱり断たねばならなかったので業務量の調整（オーバーワークしない）感覚が身についたように思います。

 

実務で役に立つかはまだわからないですが、引き続き研鑽していきます。

お読みいただきありがとうございました。

「事件・事故発生時の対策 有事に混乱しないための準備、技術、事例」を聞いてきました

以下のイベントを初めて聴講してきました。

news.mynavi.jp

 

登壇された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)

*4:プロジェクト情報共有ツールへの不正アクセスについて : 富士通 (fujitsu.com)

*5:【FileZen】脆弱性対応の経緯 | サポート情報 | ソリトンシステムズ (soliton.co.jp)