アラートのトリアージ
検知されたアラートが組織に対して影響を及ぼすかを判断する作業
- 検出されたアラートが全て影響を及ぼすわけではない
- 攻撃ではない事象が攻撃として検知されてしまうケース（いわゆる誤検知、false positive）
- 攻撃ではあったがシステムに影響はなかったケース
- 影響の有無が即座に判断しづらく、トリアージの比重が重いのがセキュリティ監視の特徴
- プロダクトやプラットフォームの監視と大きく異なるのがこのポイント
- プロダクトやプラットフォームはサービスのAvailabilityを監視しており、そこに異常があること自体はすぐに判断できる
- そのためプロダクトやプラットフォームの監視関連技術をそのまま転用するのが難しい
どのように影響を判断するか？
- アラートの内容を確認する
- 発生した場所（ネットワークやホスト）、発生させた主体、発生した事象を正しく把握する
- そのうえで誤検知であると判断できる要素があれば無視する
- 脆弱性などの場合はその内容を精査し理解する
- 関連するログを確認する
- アラートの各要素をキーにして関連するログを探す
- 時刻
- 場所（ネットワークやホスト）
- Indicator（通信相手のIPアドレス・ホスト名や関連するファイル・プロセス）
- ログの中に侵害を示す兆候が無いか確認する
- 外部で公開されている IoC (Indicator of Compromise) との比較
- 関連するシステムの状況を確認する
- イベントが発生したとされるネットワークやホストにおいて異常がないか確認する
- ただし隠蔽されている可能性も高く、容易に判断できない場合も多い
- 脆弱性検知の場合はそのプラットフォームやプロダクトに影響がないかを調査する
- 人に聞く
- 組織内のメンバーが意図的にやったアクションであれば問題ない、というアラートも多い
- 組織のコミュニケーション文化がフラットかつオープンだと効率的
- ソフトウェア開発における誤検知でよくあるケース
<aside>
❓ Q. 影響のない攻撃を検知する意味はある？
組織での運用方針などによるが、原則はあまり意味はない。外部からの攻撃の傾向を知るなどのユースケースはあるが、具体的なアクションに繋がらないのであればなるべくアラート自体を削減して認知負荷を下げる方がおすすめ。
</aside>
対応ランブック
- トリアージ〜インシデント対応の過程について、部分的にでも対応方法を言語化したものを用意しておくと便利
- 対応開始から完了までの完全なシナリオのものを作るのは困難
- そのため部分的なチェック項目や対処プロセスを分解して用意しておくと良い
- 例：アラートの対象となるユーザの行動調査方法
- 例：出現したIPアドレスに関連したログの抽出方法
- 例：アラートの対象となったホストから不審な通信が発生していないかのチェック方法
監視体制
24/365体制
- 24時間365日、つまり昼夜問わず対応できる体制のこと
- アラート発生時に、夜中や休日であってもトリアージしたり、インシデント対応できるようにする
- オンコール勤務：何かあったとき（アラート発生時など）のみ対応する
- 担当時間、常に作業をしていなくても良いが、アラート発生時に出動する
- 一般的にはメインとサブの二人以上の構成で体制を組む
- 労働基準法への対応
- 労働時間に該当するのかの判断
- 待機手当の支給の検討
- どちらにしても担当者の精神的・肉体的に負担が大きくなる
- 待機中も気が休まらない
- 昼と夜の担当を入れ替えると生活バランスも崩れる
- 体制として人数は8人以上必要と考えるべき（ SRE本 11.3「バランスの取れたオンコール」 より）
- オンコールが最低8人としたとき、それだけのタレントを持ったメンバーを集められるか？
- サイバー攻撃に関する知識
- 断片的な事象から適切な仮説をたて、それを検証するためのデータを収集する調査能力
- 組織内のシステムの理解