セキュリティ運用 2021.07.20

Step Up！「雰囲気インシデントレスポンス」からの脱却

セキュリティ担当者に対する期待は日を追うごとに高まり、責任も大きくなっています。それにも関わらず、必要なスキルセットや業務設計が曖昧なまま運用を続けることに不安を感じている企業様も多いのではないでしょうか。本記事では、様々なインシデントに柔軟に対応するためのキーとなる「分析」業務にフォーカスし、アナリストの知見や暗黙知となっている分析業務の一例など、今よりプラス一歩踏み出すためのヒントをご提供します。インシデントレスポンスに求められる考え方をはじめ、セキュリティツールを活用した運用事例や実際に役立つテクニックなどについて解説します。

インシデントレスポンスにおいて「分析」が重要なワケ

少し前に、セキュリティ運用を自動化するソリューションであるSOARの導入に向け、お客様とインシデントレスポンスについてのディスカッションをする機会がありました。その際、お客様とインシデントレスポンスに関する考え方の違いが非常に大きいと感じ、その理由について考えました。
お客様は「検知したらとにかくそれを対処したい、そしてその作業を自動化したい」とご希望をいただいたのですが、「検知」と「対処」の間には「分析」という基本的かつ重要な業務があるはずで、弊社としては、それを自動化してはどうかという提案を行いました。しかし、お客様は「分析の重要性がよくわからないし、自分たちにはハードルが高い」とおっしゃっていたのです。

図1.jpg
では、なぜ分析が必要なのでしょうか。１つは脅威の進化です。VPNや公開サーバに対する攻撃の激化をはじめ、Lateral Movement（水平展開）の完全定着化、そして侵入後、数時間で横展開しまうなど攻撃スピードの高まりなど、脅威に対していかに迅速かつ的確に対応できるかということが求められます。２つめは、守るべき資産の多様化です。現在の企業では、クラウド利用が推進されていることはもちろん、子会社や海外拠点における資産も増え、またリモートワークの進展も資産の多様化に大きく関係しています。こういった状況に対応するために、EDRやSIEM、UEBAといった「導入して終わりではなく、使いこなすことで真価を発揮する」ソリューションが増えていることも、分析が求められる背景にあります。

図2.jpg

インシデントレスポンスにおける昔と今の違い

分析の必要性を理解するためには、これまでのインシデントレスポンスと今必要なインシデントレスポンスの違いを知ることが重要です。これまでのインシデントレスポンスは、守るべき資産に対してセキュリティソリューションを導入し、運用が開始された後はアラートの検知および確認、対処していくというシンプルなプロセスでした。
導入段階では検知精度をとにかく追及し、性能低下に注意しながら漏れなく導入していくことが意識され、検知プロセスでは、アラートを見逃さない体制づくりや深夜対応、過検知対応など運用面で考慮すべきポイントに留意してきたはずです。そして確認プロセスでは、隙なく抜けなく確認できるか、そして余計なことはしないことが求められ、最終的には対処のプロセスでスピード感をもって定められた方法に沿って確実に行うことで、ようやく安心できるというのが一般的なインシデントレスポンスのプロセスでした。しかし、実際には想定外の事態が数多く発生し、被害は連鎖、継続してしまっているのが今の実態です。
図3.jpg

では、今求められているインシデントレスポンスとはどんな考え方が必要なのでしょうか。実はこれまでイメージしていたプロセスよりも複雑です。あくまでアラートはきっかけに過ぎず、挙がってきたアラートに対して分析を繰り返し、追加の情報収集や監視も合わせて実施していくことで、脅威の全貌を把握、特定することが可能となります。つまり、分析を行うことではじめて、対処策が決まってくるわけです。
図4.jpg

もし従来の考え方のままインシデントレスポンスを続けていた場合、どんな問題が起きるのでしょうか。例えば端末からアラートが挙がってその個所を特定することで、ネットワークからの隔離や初期化といった一時的な対処はすぐにできるかもしれません。しかし、侵入経路がわからない、そもそもの原因がわからないなど、全貌が見えていないと恒久対策をとることが難しいと言わざるを得ません。当然、影響範囲が特定できず、緊急度や優先度の判断も困難な状況になってくるはずで、大小さまざまな脅威が同時に起きているなかで、重要な脅威を見逃すリスクも非常に高まってしまうことになります。さらに、ビジネスへの影響など被害内容が断定できないことで、インシデントレスポンスをクローズしていいかどうかの判断も難しくなってきます。だからこそ、分析というプロセスが非常に重要になります。
図5.jpg

分析における基本的な考え方は、今見えているものは全体の一部であり、全貌把握を強く意識することです。例えば、影響範囲が誤っている可能性やインシデントが継続しているかもしれないという可能性を考慮することが重要です。また、得られた情報を用いて多段的な分析を行うことが重要で、アラートやログからの気づき、そして外部からの情報収集の結果を用いて分析を繰り返すことも必要です。OODA Loopというフレームワークがセキュリティの戦略や運用検討でも用いられますが、シンプルな線形のループだと誤解されているケースもあります。実際は、非常に複雑なフィードバックが随所に入ってくることを忘れてはなりません。

2つのインシデントレスポンス運用事例

ここで、インシデントレスポンスに対する取り組みに関する2つの事例を紹介します。1つ目が、S&J株式会社が手掛けるSOCサービスをもとにした事例です。具体的には、ユーザ企業であるマクニカからSandboxやEDRからの各種ログを受け取ることでアラート監視を実施するなど日々分析を行っていますが、そのなかで脅威を見つけた場合は簡単な一次分析を行ったうえでエスカレーションレベルを決定、その内容に応じて通知とエスカレーションを実施しています。一次分析については、検知内容をさまざまなソースと照合することで悪性かどうかの判断だけでなく、アラートの正当性や意図性の確認、そして初動措置や追加調査の案出しなどが含まれています。これら一次分析の内容に応じて、マクニカ側では、EDRやSIEMのサーチ機能によるHashサーチといった影響範囲の調査をはじめ、利用者への聞き込みを含めた原因や侵入経路の特定、そして対応策の検討、実施などの二次分析などを実施しています。インシデント対応においてスピード感は非常に重要ですが、自組織ではできない部分は外部委託することも必要です。特に専門性、権限などのバランスもあるため、それぞれに応じた役割分担と連携を行っている事例となります。
図6.jpg

2つ目の事例として、CrowdStrikeを導入しているユーザ企業において発生したサイバー攻撃への対応事例を紹介します。この顧客の実例では、出張先の従業員がホテルでリモートワークをした際に、VPNを経由せずに社内のプロキシを経由せずにインターネットに直接アクセスした際に脅威に触れたというインシデントが発生したケースです。アラートが挙がった後の調査の初期段階で、アラートに含まれる情報を分析し、特徴的な中間ファイルのパスからハッキングツールであるBottle Exploit Kitを使用した攻撃であると推測しました。次に、Spotlight（脆弱性管理モジュール）を使用することで、Bottle EKが悪用する脆弱性がPCに残っていることが確認でき、Bottle EKを使用した攻撃を受けたという判断をしました。インシデントの調査をする過程で、客先に数日間滞在する必要があるという業務状況から、調査に必要なファイルをリモートで回収し、Hashサーチ機能を使って他端末への影響を調査することに。同時に、Spotlightを使って脆弱性のあるホストの洗い出しを実施した結果、被害を受ける可能性のある端末が多いことが明らかになり、全社あてに注意喚起を実施しました。このインシデントに関する調査では、アラートから端末と利用者を特定することで利用者や所在を洗い出し、攻撃の種類やその原因、影響範囲、そして潜在リスクまで含めてセキュリティツールをフル活用しています。これらツールが持つ分析機能によってうまく対処することができた事例です。

図7.jpg

インシデントレスポンスをステップアップさせるために必要なこと

ここからは、事例のようにインシデントレスポンスへの迅速な対応を実現するためには、どのようにステップアップしてくべきかをお伝えします。理想的には、既存の運用を全て見直し、一から再構築していくことが望ましいでしょう。しかし、そのような全体見直しはどうしても手間と時間がかかってしまうため、なかなかステップアップできない要因の1つにもなっています。そのため、第一歩を踏み出すためには、形式にこだわらずやれることからやっていくことが大切です。完璧を目指さなくとも一歩を踏み出すことが大事なことです。

ステップアップのヒントとして、インシデント発生時においても「5W1H」の考え方を活用できます。物事を整理する際にも便利ですが、セキュリティの運用として重要なインシデントレスポンスにおいても非常に整理しやすい考え方です。特にWhat（被害内容）やWhen（開始／終了）、Where（影響範囲）という3つについては、現在発生しているインシデントをクロージングするために必要な情報で、これが基本になります。そして、Who（攻撃者）やWhy（動機）、How（攻撃手法）についてはややアドバンスドな情報であり、ある程度慣れてきたら追求していくという考え方でもよいかもしれません。
図8.jpg

インシデントレスポンスにおける分析テクニックの紹介

次に、具体的にどういったテクニックを使って分析していけばよいか、3つのナレッジを紹介します。

アラートから得られる情報の活用

1つめのテクニックは、アラートから得られる情報を最大限活用することです。アラートはインシデントの一部を通知するもので、そこにはファイル名やプロセス名、フルパス、ハッシュ値など活用できるさまざまな情報が含まれています。得られた情報をもとに全貌の調査を行っていくことになります。その情報をもとに、VirusTotalといったレピュテーションサイトなどはもちろん、SNSや検索エンジンを駆使して公開情報（OSINT）をうまく活用してください。もしそれらから情報が得られない場合は新型の攻撃である可能性を念頭に、さらに分析を進めていくと良いでしょう。ただし注意すべきは、検体そのものをアップロードしないことです。社内の機密情報などをアップロードすると、リサーチャーの間でシェアされてしまうこともあります。
またセキュリティ製品を導入していれば、EDRのサーチ機能を使って、他の端末でも攻撃が発生していないか、同じ攻撃が早い時刻で発生しているホストを探すなど侵入経路の調査にも活用できます。ほかにも、実際に被害が発生したかどうかはエンドポイントだけでは分からないケースもあるため、SIEMなどを使って上位のネットワーク機器がブロックしていないかどうかなどを確認することも有効です。

図9.jpg

コマンドラインの確認

2つ目のテクニックとして挙げたのが、コマンドラインの確認です。コマンドラインが重要なのは、悪性かどうかを適切に判断するためです。OS標準ツールを悪用される攻撃手法が定着してきています。そのため、アラートで見つけたファイルやツールが悪性かどうかではなく、使われ方で判断していくことが必要です。ファイルレス攻撃などはOSの標準機能が悪用されるため、cmd.exeやpowershell.exeなどはOSの起動プロセスでも利用されることを考えると、単体で悪性かどうかは判断できません。それらのプロセスにどのような引数（コマンドオプション）が与えられたかが重要になってくるわけです。ほかにも、通信先やスクリプトのフルパス、持ち出される中間ファイル、レジストリへの書き込みなどの動きもコマンドラインから見えるようになります。補足として、ファイルレスの攻撃では、コマンドオプションをエンコードして難読化する手法が一般化しつつあります。それをデコードするサイトやツールを使うことで攻撃内容が確認できるようになります。

図10.jpg

プロセス前後の関係性

3つ目がプロセス前後の関係性を見ることです。アラートが上がった前後で何が行われているかによって、意図性を確認することが目的になります。先に挙げたテクニックでプロセスやその使われ方が悪性だと判断できたとしても、どのような意図なのかが判断することは難しいです。そんなときに、EDRのプロセスツリーを可視化する機能を使うことで、親プロセスを確認したり、どのようなユーザ操作によって発生したかを特定したりすることができます。通常Windows上でファイル操作をしているとOS標準であるexplorer.exeからいろいろなプロセスが起動するように見えることが多いですが、explorer.exeでないところからプロセスが起動していると、プロセスがインジェクションされた可能性も出てくるため、脆弱性を突かれた攻撃の可能性が類推できるようになります。また子プロセスを見て何が実行されたのかを確認し、もし攻撃がブロックされている場合には、アラートになっていないものの重要な情報が残されている可能性もあります。攻撃者が消去する予定だったファイルが生成されたままのケースもあるので、ブロックできた場合はそんなファイルを収集して解析していくということも有用なテクニックの1つです。

図11.jpg 　

分析業務と相性のいいソリューション

昨今のセキュリティソリューションは、分析を行うための機能が非常に充実しています。例えばEDRではアラートの分析やサーチ機能によって、エンドポイントの調査を簡単に行うことができます。また、SIEMではサーチ機能やドリルダウン調査、そして普段とは違う傾向となる特異点に対する気づきが得られるカスタムダッシュボードを作成することも分析業務では有用です。ほかにも、人や資産の観点で異常を検知するUEBAや、対処ツールではないものの運用の自動化や属人性の排除に役立つSOARなどについても役立ちます。

図12.jpg

まとめ

いまのインシデントレスポンスでは「分析」が重要で、何が起きるか、起きているかわからないからこそ、分析は不測の事態に対応するという考え方を持つ必要があります。そして、ステップアップには最初の一歩が肝心であり、完璧を目指さなくとも、やれることから始めてみてはいかがでしょうか。