セキュリティインシデントの調査を体験して得た気づき

今回は「セキュリティインシデントの調査を体験して得た気づき」についてご紹介します。

関連ワード （オフトピック等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、ZDNet Japan様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

　セキュリティインシデントは、時にシステム障害や情報漏えいなどの深刻な事態をもたらし、当事者企業が事業の中断や停止に追い込まれることもある。被害を最小限に抑えるには、素早い調査と対応が鍵を握るが、複雑な環境の調査は困難なことが少なくない。インシデント調査を体験する機会を得たので、そこで得られた記者なりの気づきをレポートしてみたい。

　インシデントの調査は、どのような原因でどのように推移し、どのような影響が起きているかを把握することで、被害を食い止める適切な対応を実行するために必要だ。しかし、インシデントを検知したタイミングや状況によって調査範囲や方法などが変わり、攻撃者の痕跡といった手がかりの有無や程度なども大きく関係する。調査ができる人材や技術、手段の確保も課題になる。

　今回はRSA Securityから取材提案があり、同社のインシデント調査・対応プラットフォーム製品「NetWitness Platform XDR」を使ったインシデント調査のワークショップに参加した。記者は、普段の取材でこうした製品の概要に触れる機会が多いものの、インシデントの当事者として調査に携わった経験がない。インシデントが発生した組織への取材内容は調査の結果が中心になり、調査自体について相手からうかがう範囲でしか知り得なかった。そこで同社の取材提案を受けて、実際のインシデントを参考にしているといい、インシデント調査を体験した。

　ワークショップで用いるNetWitness Platform XDRは、セキュリティ情報・イベント管理（SIEM）やエンドポイントおよびネットワークにおける脅威の検知および対応（EDR、NDR、XDR）などの機能を備える。同社によれば、元々は1990年代にネットワークトラフィックを可視化する米国政府の研究プロジェクトを受託したCTXが開発した技術という。CTXはその後に、さまざまな買収やスピンオフを経て、現在ではRSA Securityの一部となっている。

　ワークショップの環境は、同社がAmazon Web Services（AWS）上にNetWitness Platform XDRの環境を構築し、そこにウェブブラウザーでリモートからアクセスする。コミュニケーションツールは「Zoom」と「Slack」を用いた。取材した実施回には、記者以外に金融機関など複数の企業から8人が参加。まず製品紹介や操作方法の説明があり、練習問題を解く。その後に同社が用意した課題をクリアして得点を稼いでいく。ゲーム感覚でインシデントの調査を体験していく内容だ。

　取材経験を振り返ると、インシデント調査が企業や組織で本格的に必要とされ始めたのは、「標的型攻撃」の言葉が知られ出した2010年頃だろう。当初は、IT機器の膨大なログをSIEMで分析して状況を把握することが中心だった。その後、（月並みな表現だが）セキュリティの脅威の高度化・巧妙化が進み、同社の説明ではEDRやNDR、XDRをセンサーのように使ってIT環境全体を常に監視し、脅威を検知すれば、即時対応しつつ調査も行う。

　NetWitness Platform XDRは、この「対応」と「調査」、ダッシュボートとレポートの機能を搭載しているとのこと。実際のインシデント時は、調査や初動対応などの役割に応じて機能を使い分ける。今回のワークショップでは、ユーザー画面のタブで「調査」とその階下の「ナビゲーション」「レガシーイベント」「イベント」などの機能を利用し、必要に応じて「対応」の機能も使用した。