セキュリティアラートの自動対応の種類についてまとめた

最近、セキュリティアラートの自動対応に対する機運が高まっているので、どういった種類のものがあるかについて整理のため自分なりにまとめてみました。なおここでの「アラート」は「セキュリティシステムや人間がある程度の確度をもってセキュリティ侵害が発生した、あるいは発生し続けていると判断したもの」を指しています。

disclaimer

基本的に筆者の知識・経験に基づいて書いてます。もっとこういうのあるよ、というのがあれば教えて下さい
アラートの検知などの話はしません
各対応の細かい実装方法についても話しません（環境・製品・サービスなどに大きく依存するため）
アラートの対象となるホスト（被害を受ける側）については、特に断りがない限りサーバ環境とクライアントPC環境の両方を想定して書いています

お題は以下の通りです。

Notification (通知)
Investigation (調査)
Preservation (保全)
Block (遮断)
Remediation (修復)
Quarantine (隔離)

これらから1つだけ選ぶ、というよりは状況などに応じて複数を併用することを想定しています。

Notification (通知)

概要: アラートが検知されたことを関係者に通知する。EメールやSlackなどチャットに流すこともあるし、PagerDutyのように通知先や対応状況の共有などをサポートするツールを利用することもできる
利点
- 対象ホストに対して（基本的に）全く干渉しないため誤検知だとしてもホスト・サービスなどに対して影響しない
課題
- （当然だが）人間が対応を開始するまではホストはアラートで示された状況から何も変化しないので、もし本当に危険に晒されている状況で人間が対応を開始できなければ危険度は高くなっていく
検討事項
- 基本的には人間が対応をすることが前提であるため、誰がいつどのように対応するか？ということまで含めてちゃんと設計する。例えば「通常業務時間内で対応する」というのであれば原則として深夜や土日に検知されたアラートについては通知がきても翌営業日ないし週明けにしか対応できない、というようなことを組織内で握っておく必要がある
- ホストに影響がないからといってどんなアラートでも通知しようとすると流量が増えていき人間が疲弊する。また、意図的に増やそうとしなくてもセキュリティシステムなどの更新により新しいアラートが検知されて流量が増える可能性もある。そのためアラート数を少なくするような仕組みとセットで考えるとよい

Investigation (調査)

概要: アラートに出現した識別情報（IPアドレス、ドメイン名、ユーザ名、ファイルのハッシュ値などなど）に対して関連情報を収集する。例えば不審な通信のアラートが検知された場合、外部の脅威情報DB（VirusTotalやabuse.chなど）を参照することで、その通信先がC&C（Command & Control）サーバとして利用されていたのかどうかを知ることができる。他にもあるユーザが不審な行動をしたというアラートが検知された場合、組織内で利用しているサービスやシステムのログを参照することで、当該ユーザがアラートの前後に何を、どこから実施していたのかがわかる。これによって、アラートのリスク評価などの時間を短縮できる。なお、調査のみを単独で実施するというよりは通知などと組み合わせることでより効果を発揮する
利点
- 調査をする過程において判断が必要となる手順はあまりないため、誰がやっても同じ結果になる。そのため自動化の恩恵（時間の短縮、ミスの防止）を十全に受けることができる。
課題
- 特になし
検討事項
- 外部の情報を参照する場合はAPIなどを使って検索をすることになるが、そのような脅威情報を提供してくれるサービスは無料版だとかなり厳しくAPIの利用制限が定められている場合が多い。したがって、アラートが大量に発生している状況ですべてのアラートについて調査しようとするとあっという間に利用制限に引っかかる。特に自動化していると気づかずにDoSのようになってしまって、あげくBANされる可能性もあるため流量の制限などは事前によく検討しておく必要がある。なお有料版にすることで制限緩和してくれるサービスもあるが、だいたいはそこそこいいお値段である
- 上述のポイントにも絡むが、1つのアラートに対してどこまで深堀りするかも考える必要がある。例えば、あるIPアドレスが過去にマルウェアを配布していたという情報を得た際、どのような種類のマルウェアなのかを知ることでよりリスク評価が容易になる。ただ、そのような紐付けされた情報をたぐり始めると際限がなくなってしまい、APIの制限にひっかかったりシステムの負荷が上がってしまうという問題がある。そのため、無闇に関連する情報を探すのではなく、アラートに含まれる識別情報の意味と文脈を考えて、ちゃんと調査する対象を選んだりどこまで調べるかを考えなければならない

Preservation (保全)

概要: アラートの対象となっているシステムから調査に必要そうな情報を探して別の場所に保全する。集める情報としてはシステムログ、ミドルウェアやシステムの設定情報、動いているプロセスやネットワークの状況といったものが挙げられる。フォレンジックアーティファクト収集ツールを自動で実行しデータを別の場所へ転送するイメージ
利点
- 通知、調査に次いでホストに影響を及びさない（ただし情報取得時に負荷のかかる手段を使うと、可用性の面で影響があるかもしれない）
- 収集したい情報が大量であったとしてもアラートが検知された近辺でのみ収集することで、データ転送やストレージなどのコストを下げられる
課題
- 通知などと同様にホストに干渉しないため進行中の脅威があった場合に阻止してくれるものではない
- 侵害を受けたホストの場合、保全の対応をする前にrootkitなどを仕込まれている可能性があるため、ファイル情報やプロセス情報などが改ざんされたものになっている恐れがある
検討事項
- セキュリティ侵害を受けた対象ホストから保全した情報の削除・変更ができるとまずいので、権限の設定やアーキテクチャをちゃんと考える必要がある
- 課題の部分でも述べたとおりアラート発生後だと正しい情報を取得できない可能性がある。自動化によって対応開始の時間を短縮でき人間が手動で対応するよりは良いが、アラートもセキュリティ侵害発生直後に発見されているとは限らず、後手に回っているのは間違いない。そのため多少データ転送やストレージのコストがかかったとしても、常時必要な情報を収集する仕組みを検討する価値はある
- 厳密な証拠保全の観点から言うと、自動保全の工程で微細な証拠を消してしまう（例えば証拠が残っているディスクの一部の領域を上書きしてしまうなど）可能性もあるので、そういった工程のなかで影響がないように留意する

Block (遮断)

概要: 現在進行系で攻撃を受けている際に、攻撃元になっている相手を遮断して攻撃による影響を排除すること。つまりBAN。主に外部にサービスを提供するサーバ環境で必要な場合が多い。狙ってやってくるDoS攻撃だけでなく、悪意のあるなしに関わらずシステムに想定外の負荷をかけるような通信や、不正な行動（リスト型攻撃など）を弾くといった場面でも有効な場合がある
利点
- 可用性の点でいうと、サービス側の性能向上や負荷がかかる部分の修正といった作業無しですぐ効果がでる
課題
- サービスの場合、すべての通信を遮断するとただのサービスダウンになってしまうので攻撃者の識別子（IPアドレスやユーザ名）を指定した上で遮断することになる。しかし、どちらも攻撃者からすると比較的簡単に用意できるため、ボットネットなどを使って数の暴力で押されると弱いという問題がある
- 概要にも書いたとおり、あくまで可用性への影響低減や不正な行動の抑制に対して効果があるものであり、任意コード実行などの攻撃が成功したあとに遮断しても無意味である（遮断しても別の場所から打ち込まれて死亡するだけなので）
検討事項
- BANした対象をどの程度の期間BANし続けるかも考えておく必要がある。IPアドレスのような識別子はNATによって複数人が同時に使っていたり、アドレスのつけ変わりによって別の人が利用したりすることはよくある。永久にBANし続けると無関係の人まで巻き込んでしまうため、攻撃による影響低減とのバランスをとって検討しなければならない
- サービス内でBANする場合は比較的柔軟に遮断ルールを持てる（はずだ）が、マネージドサービスやセキュリティ製品をつかってネットワークのレイヤでBANする場合は保持できるルール数に上限があったりするので注意が必要である
- あくまで筆者の経験則や聞いた話だが、いきなりボットネットで大規模攻勢に晒されるということはあまり多くはない気がするため、短期的には遮断しつつ、その間に別の対応を進めるというような併用が効果的かもしれない

Remediation (修復)

概要: 攻撃、あるいは悪意のないミスなどによって変更されてしまったファイルや設定などを含むシステムをあるべき状態に戻すこと。サーバ上のコンテンツ復旧や、マルウェアに汚染されたホストからマルウェアを取り除いて正常な状態に戻すといったようなことも含める。また、ホストだけではなくクラウドを含むマネージドサービスについても、管理者が禁止している設定内容になっていた場合に自動的に修復させる、といった用法もある。概念としてまとめてしまったが、具体的な方法については修復対象によって大きく異る。
利点
- 攻撃によるコンテンツや設定などの改変に対しては、（場当たり的にではあるが）可用性を高めることができる。機密性や完全性が損なわれている状態だとしても、とにかく可用性を維持したいというようなものに有効
- （主に悪意のない）意図しない設定変更などに対しては、認可の粒度の粗さを補うことができる。つまり「Aという項目に対して変更する権限をあたえる」までしか認可の設定ができないシステムにおいて「Aという項目はXかYという内容になっていなければならない」というルールを強制したい場合に、「Aという項目がZになっていた場合に自動的にXに戻す」というような対応をすることで、擬似的にルールを実現できる。
課題
- 攻撃による改変に対しては、根本原因を取り除くわけではない。改変が発生しているということはホスト上の様々な箇所が改変されている可能性があり、それらを全て適切に修復するのはかなり困難である。例えばサーバの場合だとコンテンツや設定だけでなく、同時にバックドアが仕込まれている可能性が高い。またPC環境でマルウェアに感染していた場合、昨今のマルウェアは感染とほぼ同時に複数の悪意あるコードをホスト上のあちこちに仕込み、1つや2つ駆除されたとしても別のマルウェアが再度汚染を再開させてもとの状態に戻ってしまう。したがって攻撃に対しては場当たり的であると言わざるを得ない。
- 主に悪意のない、意図しない変更に対する修復についても便利ではあるものの、一度は意図しない状態になってしまう（完全に変更を防げるわけではない）という点に留意する必要がある。そのため、根本的には認可の粒度をより細かくできるようにする、というアプローチの方が重要である。
- クラウドのような環境であれば問題が起こったホストをまるごと潰して、全く同じものを再度作り直すという自動化をすることで、ホスト上にどのような改変がされていたとしても完全にその影響は除去できる。ただし、同じものが再度作られるということは当然攻撃を成功させた脆弱性もそのまま再現されるので、やはり根本解決には至らない
検討事項
- 課題で述べたとおりあくまで場当たり的な対応であり、修復単体で対策しても可用性を少し高める程度である。並行して根本的な（おそらくは人間による）対応を実施するということを念頭に置いて自動化を設計する必要がある。
- フォレンジックの観点で考えるといろいろな痕跡を破壊する可能性があるため、それを踏まえた上で実施するかどうかを検討する必要もある。

Quarantine (隔離)

概要: 攻撃を受けたとされるホストをネットワークから切り離し、攻撃による内外への影響を閉じ込める。攻撃を受けただけという状況よりは、攻撃が成功してすでに侵入されている、といった状況で被害の拡大を防ぐのに有効な一手になる。
利点
- ほとんどの攻撃がネットワーク越しに発生する＆社内向けシステムもほとんどがネットワークによってアクセスされることを考えると、攻撃元からの指示を止めつつ内部システムや外部サイトへの影響を完封できる。攻撃の進行を食い止めるための強力な方法である
課題
- ネットワークから切り離されるため、可用性に対しての影響が大きい。サーバの場合はサービスの提供が全くできなくなるし、PC環境の場合は操作している人の作業が強制的に中断される可能性がある。サーバの場合はサービスが冗長化してあって対象のホストを急に隔離しても大丈夫＆すぐに代替のサーバが用意できる、というようなアーキテクチャになっている必要がある。PC環境の場合は事前にそのような対応をすることについての合意形成が必要になる
- 課題と言うほどではないかもしれないが、ほとんどの場合があくまでホスト単位での隔離なので、すでに攻撃が横展開されていた場合は影響を完封できないことには留意したい
検討事項
- 課題で述べたとおり、他の対策に比べて非常に影響が大きく安易に実施できない。そのため自動的に実施する場合は、対象ホストの重要度（機密性の高い情報がある、強い権限を持っている、など）を考慮したり、攻撃が進行中であることを示す複数の証拠をもとに発動させるなど、慎重に条件を検討する必要がある
- ネットワーク通信を遮断するため、C&Cサーバとの通信も遮断される。これは影響を極小化するという意味ではいいが、フォレンジックの観点からは追跡が難しくなるとも言える。これについてはどちらが良いかという諸説がありつつ、ビジネス的な判断要素も多分に絡まってくる。そういった高度な判断が必要と考えると、やはりあまり自動化に向かないかもしれない