実践セキュリティ監視基盤構築(2): セキュリティ監視およびセキュリティ監視基盤とは
この記事はアドベントカレンダー実践セキュリティ監視基盤構築の2日目です。
基盤の構築の話をする前に、まずそもそも「セキュリティ監視」とは何か、そして「セキュリティ監視基盤」とは何かについて整理をしたいと思います。
セキュリティ監視とは
本稿では、セキュリティ監視を 「組織内で発生するセキュリティ上の問題を、継続的に検知・調査すること」 と定義します。
セキュリティ上の問題
セキュリティ上の問題とは、脆弱性や攻撃活動の兆候、インシデントなどを指します。
脆弱性は、システムやアプリケーションに存在するセキュリティ上の不備や欠陥であり、悪用されるとインシデントが発生する可能性があります。これは、利用しているソフトウェア、システム、サービスだけでなく、開発・運用しているものにも該当します。自分たちが開発・運用しているサービスの場合、コードに問題があるだけでなく、利用しているライブラリやフレームワーク、ビルド環境やデプロイのプロセスにも問題がある可能性があります。
攻撃活動の兆候は、悪意ある第三者による攻撃活動が行われている可能性を示す情報です。不審なアクセスログや通信ログ、異常なトラフィックなどが該当します。明らかな攻撃の痕跡だけでなく、調査活動や情報収集活動、侵入のための準備活動も含まれます。さらに、適切な権限を奪取し、正規のユーザーとして振る舞うような活動もあります。
インシデントは、セキュリティ上の問題が発生したことを指し、悪意ある第三者による不正アクセスや情報漏洩、システムのダウンなどが該当します。これは、先述の脆弱性や攻撃活動の兆候が悪用され、何らかの影響が出ている状態を指します。
これらのセキュリティに影響を及ぼす可能性のある問題を検知し、対応できるようにすることがセキュリティ監視の目的です。
継続的な検知・調査
「継続的に」とは、監視を一定期間ごとに行うのではなく、日常的に実施し、問題が発生した際には即座に対応できるようにするという意味です。セキュリティ上の問題を発見するためのアプローチとしては「監査」もあります。監査は、ある時点でのシステムやアプリケーションの状態を確認し、問題がないかどうかを検証するものです。多くの場合、監査は人手と時間をかけて実施するものであり、頻繁には実施できません。一方でセキュリティ監視は、機械的に情報を収集し、分析できる仕組みを用意することで、継続的に問題を検出し、即時の対応をすることを目的としています。
「即時」とはどの程度の速さを示すのでしょうか。例えば、Crowd Strike社が提唱している1-10-60の法則では、攻撃を検知してから1分以内にアラートを出し、10分以内に調査を開始し、60分以内に対応を完了することが求められています。この数値は環境や組織によって異なりますが、迅速なインシデント対応の目安として参考になります。
また、監視は大きく分けると、検知と調査という2つの役割があります。
- 検知：収集した情報を分析し、問題が発生しているかどうかを判断する機能。破壊的な行動を発見するだけでなく、潜在的な問題やリスクを発見することも含まれます。これは機械的に実施されるだけでなく、人間が専門知識と経験、文脈を活用して実施することもあります。
- 調査：検知された問題に対して、その原因や影響を調査する機能。問題の深刻さや影響範囲を把握し、対応策を検討するための情報を提供します。特にセキュリティの場合、攻撃を検知したとしても、それがどのような影響を及ぼすかという情報がないと、インシデントであるかの判断が困難であり、調査はそのための重要なステップです。
この2つの機能は表裏一体ですが、これらの役割を満たせるようなセキュリティ監視基盤を構築することが求められます。
なぜセキュリティ監視が必要か
では、なぜセキュリティ監視が必要なのでしょうか。セキュリティ監視によって検知する以前に攻撃を防いでいれば、セキュリティ監視は不要ではないかと思われるかもしれません。
実際、この考えは正しいです。セキュリティ監視は、すべての防御的対策より優先されるべきものではありません。低コストかつ少ない影響で実施できる防御的対策は多くあり、まずはそれらを優先するべきです。監視は時としてインシデントを見つける、つまり被害が発生している状況を発見するための手段であり、防御的対策の補完として位置づけられるべきです。
しかし、防御的対策にはいくつかの限界があります。
- 対策の抜け漏れ：防御的対策は基本的に脆弱性を解消するためのものですが、すべての脆弱性を把握できているかどうかはわかりません。すべて対応したつもりでも、それは「見えている範囲」の脆弱性であり、すべてを把握できているかどうかは、まさに悪魔の証明です。また、脆弱性の状況は日々変化しており、新たな脆弱性が発生することもあります。
- サプライチェーン攻撃：自組織のシステムやアプリケーションだけでなく、サプライヤーやパートナーのシステムやアプリケーションにも脆弱性が存在する可能性があります。これらの脆弱性は自組織からはコントロールできず、観測することも難しい場合があります。脆弱性の悪用を防ぐのが難しい場合、別の手段で対応する必要があります。
- ゼロデイ攻撃：脆弱性が公開されてから対策が公開されるまでの期間や、脆弱性が公開される前にその脆弱性を悪用する、いわゆるゼロデイ攻撃が存在します。これらの攻撃は、対策が公開されるまでの間、防御的対策を講じることが難しかったり、過去に遡って脆弱性の影響を受けなかったかの調査を求められることがあります。防御的対策によって影響を緩和させることはできますが、何らか別の手段での対応が効果的です。
- ユーザビリティの問題：防御的対策は攻撃者の活動を制限するだけでなく、自組織内のユーザーにも影響を与えることがあります。特にソフトウェアやシステムの使いやすさを犠牲にすることが多いです。ユーザビリティの悪いシステムは生産性を低下させるだけでなく、ユーザーがセキュリティ対策を回避しようとする可能性が高まります。これにより既存のセキュリティ対策が無効化されたり、新たな脆弱性が生じる可能性があります。
これらの背景から、防御的対策だけでは安全性を担保し続けるのが困難であり、セキュリティ監視を併用した運用が現実的に求められます。
セキュリティ監視基盤とは
セキュリティ監視基盤とは、セキュリティ監視を支えるためにログ収集、保全、分析、アラート検知、対応をするための情報システムです。セキュリティ監視基盤は、セキュリティ監視に特化したデータウェアハウス（DWH）と、アラート検知や対応のためのワークフロー管理のシステムといえます。
ログ収集
ログ収集は、システムやアプリケーションが出力するログを収集する機能です。ログは、システムやアプリケーションの状態や動作、ユーザーのアクセス履歴などを記録したものであり、セキュリティ監視において重要な情報源となります。
セキュリティ監視で取り扱うログは幅広く、自組織でログの内容やスキーマ、取得方法をコントロールできないログがほとんどであるという特徴があります。これは、自組織以外のクラウドサービスや既製ソフトウェアからのログを取り扱うためです。また、ログの形式や出力方法も多様であり、それらを統一的に収集するための仕組みが必要です。
ログ保全
ログ保全は、収集したログを保存する機能です。ログは、インシデントの調査や分析、法的な要求に対応するために長期間保存する必要があります。一方でログは大量に生成されるため、保存するためのストレージやデータベースの容量が必要となります。保存するための容量はコストに直結するため、ログの保全はコストを考慮しつつ、各種要件を満たすように設計しなければなりません。セキュリティ監視で利用するログは種類によって生成される量や求められる保存期間が異なるため、それらをうまく取り回すこともログ保全において重要な設計となります。
ログ分析・調査
ログ分析・調査は、監視を運用する人物が収集したログを検索したり、複数のログを突合したり、集計することで情報を得るための機能として定義しています。ログ分析はインシデントの可能性がある事象（アラート）を検知するための手段であり、いわゆるThreat Huntingと呼ばれる活動です。ログ調査はアラートの内容を確認したり、インシデントの原因や影響範囲を調べたりするための手段です。
ログ分析・調査は基本的には同じような機能が求められますが、ログ分析は定常的な監視のために実施され、ログ調査は何かしらのイベントが発生した時に実施されることが多いです。このような違いから、ログ分析とログ調査のユーザーインターフェースを分けて設計することもあり、ログ分析のほうがよりインタラクティブな操作が求められることが多いです。ただし、定常的にログ分析をするには専任の分析者が必要となるため、運用コストが比較的高くなり、実施するべきかどうかの検討が必要です。
アラート検知
アラート検知は、人間が行うログ分析とは異なり、自動的にインシデントの可能性であるアラートを発見するための機能として定義しています。アラート検知は、ログ分析・調査の結果を基に、あらかじめ設定されたルールやしきい値に基づいてアラートを見つけます。
アラート検知は人間を介さず自動的に実施されるため、アラートの精度や検知率が重要です。アラートが多すぎると見逃してしまう可能性があり、アラートが少なすぎると重要なインシデントを見逃す可能性があります。アラートの精度を高めるためには、アラートのルールやしきい値を繰り返し見直し、チューニングが必要です。ルールのチューニングをする際は、変更により適切にアラートを検知するようになるか、既存のアラートが検知されなくなることがないかなどの検証が必要であり、テストをどのように実行できるかが重要となります。
アラート対応
アラート対応は、検知された異常に対応するための機能です。アラートは、異常を検知した際に通知する手段であり、アラートを受け取った担当者がその内容を確認し、必要な対応を行います。アラート対応は、アラートを受け取った担当者が適切な対応を行うための情報を提供することが求められます。
まとめ
セキュリティ監視は、組織内で発生するセキュリティ上の問題を継続的に検知・調査することであり、防御的対策だけでは対応できない脆弱性や攻撃活動、インシデントを検知するために必要です。セキュリティ監視基盤は、そのセキュリティ監視を支えるための情報システムであり、ログ収集、保全、分析、アラート検知、対応をするための機能を提供するプラットフォームとなります。
次回は、このようなセキュリティ監視基盤をいつ頃から取り組むべきかについてお話ししたいと思います。
Discussion