参考文献
インシデントへの準備
サイバーレジリエンスとは
NIST SP800-160にて「サイバーリソースを含むシステム上で発生する不利な条件、ストレス、攻撃、侵害を予測し、耐性を持ち、回復を行い、適用する能力」と定義している。
すべてのサイバー攻撃を防ぐことは不可能であり、最も安全対策がなされているネットワークでも何らかの方法で侵入し、環境内で存在を維持できるという前提に基づく。予防のみの態勢から、予防・検知・対応を含んだセキュリティ態勢を移行することが不可欠である。
侵入が発生した場合、ネットワーク環境を防御できるかは発見的統制に依存する。アクティビティの悪性を理解して、効果的な対応が必要。インシデント対応プロセスでは、攻撃者を封じ込め、攻撃者による環境の変化を減らし、攻撃者を排除し、通常運用へ回復することを目指す。
技術の準備
インシデントに先立ち適切なセンサーを配置して情報収集する。準備が不十分だとすでに敗北が確定していまう。
異常を特定するためには、正常とはどのようなものかを明確に理解しておく。不正確なネットワーク図、更新されていないIT資産表しかなく、ソフトウェアのアップデートに関する管理記録もない場合、正常と異常の識別・判断することはほぼ不可能となる。
正確で最新のIT資産情報を持ち、アップデートやパッチを含む変更管理、正確なネットワーク図を持つことが基本的なセキュリティ管理施策となる。効果的なインシデント対応プロセスの第一歩は組織化され、維持・管理され、文書化された環境である。
十分な可視化
ログ、アラート、その他センサーをとおして環境の可視化を行う。ログを一元的に集約し、保存することは、セキュリティの観点だけでなく、規制対応・コンプライアンスの観点からも非常に重要である。戦略的SIEMとするため、価値の高いセキュリティイベントログに焦点をあてる。最も価値のあるイベントの特定が重要。イベントを取り込みすぎるとパフォーマンスが低下、逆に十分に取り込めていないと可視化を十分に行うことができない。
参考：Spotting the Adversary with Windows Event Log Monitoring
「Spotting the Adversary with Windows Event Log Monitoring」は、NSA（アメリカ国家安全保障局）が発行したガイドです。SIEM（セキュリティ情報イベント管理）環境でアラートやレポートを作成するためのガイドとして利用できます。
[https://cryptome.org/2014/01/nsa-windows-event.pdf:title]
攻撃者の平均潜伏期間は数週間ではなく数ヶ月である。攻撃者の行動に気づくまで、侵入した環境に馴染むための十分な時間を持っているといえる。現在何が起きているかを調査するだけでなく、すでに発生しているが検知されなかった悪意のある活動についても調査できるようにログを十分長く保持しておくことが非常に重要といえる。
最初に収集すべきログはDNSログがある。DNSログは基地の悪質なドメインやホストを予防的に監視し、一致するものはアラートを生成する。影響を受けたホストを特定するため後から検索することもできる。
サーバやエンドポイントからのログも重要。認証の成功、失敗、特定サービスへのアクセス、ファイルへのアクセス、カーネルモジュールの読み込みなど。
Netflow、IPFIXは送信元IPアドレス、ポート、送信先IPアドレス、ポートが含まれる、ネットワーク内のどのシステムが当該IPアドレスとやりとりしたかを特定する。
FWのログ、IPS/IDS、アンチウイルス対策ソフト、DLPなど。
インシデント対応準備のまとめ
インシデント対応は有事の際だけでなく、サイバーレジリエンス実現のため、積極的なプロセスに組み込まれるべきである。インシデントは正前に十分な準備をしておかないと戦いが始まる前に敗北してしまう可能性がある。
悪意のある痕跡の検知
ほとんどの攻撃は攻撃者のネットワーク接続から始まる。（データ持ち出しやC2を目的とした外部システムへの接続の可能性も含む）
DNSサーバやプロキシサーバからのログはネットワーク内で活動している攻撃者を検知する貴重な情報を提供する。
不審なポートの調査：システムへのアクセス、永続性確保の手法として、これまで使用していないポートを開くことがある。
Windows：netstat -anob
Linux:netstat -anp
不審なサービス、レジストリ：ユーザーとの直截なやりとりを必要とせず、システムが起動すると自動的に実行する。侵入したホストで永続性を確保するためにサービスは望ましい方法である。レジストリにエントリを追加することで同様の攻撃を試みることもできる
不審なアカウント：Administratorsにアカウントを追加することで権限昇格を試みる。企業全体のログインイベントを確認し、異常な活動を示すアカウントを探すことで、影響を受けるほかのシステムを特定することができる。
不審なファイル：バックドアの作成、システムの改変のためにファイルシステムに手を加える。一時ディレクトリにある実行ファイル、特にすでに実行されたファイルは不振と疑う。
認証情報の保護
インシデント対応車は自らの行動が事態を悪化させてはいけないという原則を心にとどめておく必要がある。
対話型ログインではユーザ名とパスワードを入力しLSASSが受け取りDLLと連携してNTMLハッシュを生成する。LSASSは入力されたパスワードから計算されたハッシュがSAMに保存されたNTMLハッシュと一致するか検証する。一致した場合、認証は正常に行われる。LSASSメモリ内には現在ログオンしているユーザになりすますためのNTハッシュが存在し攻撃者に狙われる。ローカルシステムの管理者権限を持っていればミミカッツなどのツールを使い認証情報を取得する。NTハッシュにはソルトがないため、ほかシステムのNTハッシュと比較し一致した場合は横展開が可能となる。
リモートトリアージのまとめ
侵害の被疑がある場合、IOCを特定・活用し、ほかに侵入されたシステムを特定できる必要がある。特定のIPアドレスや異常なプロトコル・ポートの利用、レジストリエントリなど影響を受けたシステムを特定することに役立つ。
イベントログ分析
イベントログはSIEMに集約し分析することができる。適切なチューニングとログ保持期間により有用な情報となる。
インシデント対応の観点からはSecurityログが最も有用。SystemログはOSやデバイスドライバの挙動など。
SIEMに集約されたログの保持期間は検討が必要。最適な保持期間は環境により異なるが攻撃者が検知されるまでの平均的な潜伏期間は数ヶ月に上ることを考慮する必要がある。
イベントログに記録する内容はグループポリシーによって制御可能である。適切のログが取得できる状態にしておくことは重要。
攻撃者は監査ポリシーｗ変更し、残す証拠を減らそうとするかもしれない。幸い、監査ポリシーの変更はイベントID4719として記録される。また、Securityログのクリアしたときもイベントログは生成される（ただし、Mimikatzが使用されたときはログが残らないことに留意）
イベントログまとめ
イベントログはインシデント対応車に有益な情報をもたらすが、適切に設定され保存されていることが前提となる。適切な監査ポリシーが組織全体に適用されていること、ログが集約されていること、必要なときに利用できることが重要。
継続的な改善
インシデント対応は予防、検知、対応のサイクルにある不可欠な要素です。インシデント対応から得られる成果は、単に特定のインシデントを軽減するだけではなく、環境の防御に有益な情報を提供し予防的統制・発見的統制の改善につなげる必要がある。
文書化
インシデント対応として最も重要な仕事に対応車の行動を正確に記録することがある。行動した日時を含む正確なメモをとり、疑問が生じた場合に正しく対応できるようにしておく必要がある。
- 攻撃者がどのようにアクセスしたか
- 攻撃者が使用したツール、脆弱性
- 観察または脅威インテリジェンスにもとづく攻撃者の動機、または目的
- 組織、システムへの影響に関する定量的な説明
- 対応車が行った検知および対応処置のタイムライン
- 機能した/しなかった予防的統制・発見的統制
最終報告はチームメンバーがレビューし関連するすべての事実が記載されていることを確認する。そこには行動の時間、使用したコマンド、影響を受けたシステム、得られた証拠ファイルの保存場所を含めること。
緩和策の検証
攻撃者の活動を特定し、インシデントの範囲を理解し、影響を受けたシステム一覧の作成、被害を抑えるために必要な封じ込めを実施し、脅威インテリジェンスを収集するために攻撃者を監視することができたら復旧フェーズに移行する。攻撃者が行った変更を元に戻し、通常のオペレーションを回復する。そのために次号継続計画や災害復旧計画にもとづいたオペレーションチームとの調整が発生する。
復旧後に攻撃者が環境に戻ってきたという事例がある。これは復旧が不完全であったため攻撃者を環境から排除できていなかったというもの。インシデント対応は潜伏期間（攻撃者が環境内で活動していた時間）を把握する必要がある。潜伏期間の計算を誤ると攻撃者がすでにシステムに侵入した状態のバックアップから復元してしまうことになる。これを防ぐためにはOSからクリーンインストールし、データのみバックアップから復元すること。
攻撃者が環境に行った変更を1つでも見逃してしまうと、攻撃者は検知を避けるため異なる攻撃手法で攻撃を再起する可能性が高くなる。インシデント対応の復旧フェーズではインシデント対応チームの準備態勢を強化する必要がある。
成功の積み重ねと、失敗からの学び
反省会では改善点をプロフェッショナルの立場から指摘し、組織プロセスをどのように改善していくかという立場からアプローチすべき。
ネットワークアーキテクチャ、内部手順、その他の管理態勢を詳細に評価する。そしてユーザーの行動がどうであれう実行をブロックすることが可能となるようなコントロールを検討するべき。
反省会はインシデント対応プロセスを見直す機会としても適している。インシデント発生前に行った準備は発生したインシデントに対応するために適切だったかという観点で見直し・評価する必要がある。期待通りに機能し、スムーズな対応を可能にした部分に注目するとともに改善可能な領域にも注目し具体的な提案をおこなう。
インシデント対応チームのスキルを評価し、追加のトレーニング、ツールを特定するのにも適している。対応プロセスの各ステップを実行するのに必要な時間を評価することも有益である。
- 影響を受けた範囲を十分に可視化できていたか
- ログやアラートを追加すれば攻撃者の潜伏期間の短縮ができたか
- エンドポイントの可視性は攻撃者の活動を十分にトレースできたか
- ネットワーク監視はトラフィックに関する想定通りの情報を提供されたか
継続的な改善まとめ
インシデントが発生するたびに貴重な情報が得られ、環境全体のセキュリティ態勢をフィードバックすｒことでサイバーレジリエンスを実現することに寄与する。予防的統制・発見的統制を評価し、対応プロセスを改善し、組織に包括的なセキュリティ態勢の向上させるトレーニングを特定する機会を提供する。
環境内の未知の攻撃者を検知し、環境の可視化が行われていることを評価し、潜在的な課題を特定する目的でプロアクティブな活動を行う必要がある。
プロアクティブな活動
インシデント対応は環境のアクティブディフェンスの予防・検知・対応サイクルにおける重要な役割を果たす。インシデントに関与していない時間は環境内に存在している可能性のある攻撃者を探したり、行動を模倣し呼ぼう・検知に関するコントロールが適切に機能するかテストし、改善するなどプロアクティブな活動をとおして防御を強化する。
驚異ハンティング
環境内に存在しうる悪意のある行動の証拠を継続的に探し続けることを驚異ハンティングという。
ログ、メモリ、その他イベントなどの証拠を探し出す行為は、インシデント対応者に経験と実践を提供し、実際に攻撃を受けたときの能力を向上させる。
仮説の構築→探し出すエビデンスの決定→調査→（必要に応じて）対応→予防的統制・発見的統制のギャップ特定→予防・検知の自動化
可能性のある驚異ハンティング用の仮説を検討することが現在のセキュリティ態勢の課題を特定し改善する機会となる。
一般的なデータソース
- ネットワークセキュリティ機器のログ
- ホストのログ、設定
- ADオブジェクト
- メモリアーティファクト
- レジストリの変更
- 異常なネットワーク接続
- 異常なプロセスやサービス
- その他侵害を示すIOC
このプロセスを進めることで仮説を特定する観点から補強・反証するのに役立つ追加の証拠の必要性に気づく。ログの保存期間が不十分である、ログの記録内容、ネットワークセンサーがとくていのセグメントに対して十分な可視化を提供していないなど。
将来的に攻撃を阻止するために役立つ予防的統制・発見的統制を検討する。アラートを生成するために自動化できる方法があればそれも含めて検討し、将来的に類似した調査にかける人的リソースの消費を回避することができる。
インシデント対応は予防・検知・対応サイクルからなるアクティブディフェンスの重要な構成要素です。日々の運用に統合された重要な要素と考え、対応プロセスだけでなく、環境の全体的な防御態勢を改善するための能動的な対応を行う必要がある。根拠に基づいた仮説に基づき脅威ハンティングをおこなうことでこれまで知られていなかった攻撃者の発見、脅威への対処を行うことができる。
攻撃者の活動を模倣し、予防的統制・発見的統制をテストすることが環境防御力を向上させる効果的な方法である。