実践セキュリティ監視基盤構築(5): セキュリティ監視の要件定義（機能）

この記事はアドベントカレンダー実践セキュリティ監視基盤構築の5日目です。

今回は、セキュリティ監視基盤の設計・構築を行う前に、自組織にとってどのようなセキュリティ監視が必要かを明確にするための要件について考えます。セキュリティ監視の要件定義は、一般的な要件定義と同様に、機能要件と非機能要件に分けて考えることができます。今回は機能要件について整理します。

現状分析

まず最初に行うべきは、自組織の状況を把握することです。データやシステム、脅威に関する情報を整理し、どこをどのように守りたいかによって、監視すべき対象や方法が変わってきます。このような分析は、セキュリティ監視の設計の道筋を立てるだけでなく、関係者間での認識を揃えるためにも有用です。

情報資産の整理

まずは、自組織が保有する情報資産を整理します。「情報資産」は情報セキュリティマネジメントシステム（ISMS, Information Security Management System）などに取り組んでいると聞き馴染みのある言葉だと思います。情報資産とは、データベースやファイルサーバ、アプリケーションなど、組織が保有する情報のことです。組織が現在どのような情報を持っていて、どこに保存され、どのように運用されているかを整理します。整理するまでもなく把握している、と考えるかもしれませんが、実際にどんなデータをどのように取り扱っているかは、その部署やチームしか把握していないことが多々あります。

情報資産の整理方法については諸説あるので省きますが、具体的な情報資産の例としては以下のようなものが考えられます。今回はシステム上のセキュリティ監視の話なので、電子データのみを対象として考えるとよいでしょう。

• 顧客情報（toB）、ユーザ情報（toC）
• 取引情報、事業計画、契約情報
• 人事情報
• 組織内ドキュメント
• システムに関する構成情報など
• システムの認証情報（パスワードなど）
• 開発されたソースコード

セキュリティ監視の要件を考えるうえでは、以下のような観点で情報資産を整理するとよいでしょう。

• どこに保存されているか
• 誰がアクセスできるか
• 情報資産が漏洩、あるいは破壊された場合の影響度

影響度については予測が難しいですが、相対的に評価することで、セキュリティ監視の優先順位をつけるのに役立ちます。

組織内システムの把握

次に、情報資産がどのようなシステム上に保存されているかを確認します。近年では、組織内向けのシステムがSaaSとして提供されることが多く、導入や利用が非常に簡単になりました。しかし、その結果、部署ごとに異なるシステムを利用していることがよくあります。また、ある程度の統制が取れている場合でも、利用するシステムの数や形態が増えると、常に正確な状況を把握するのは難しくなります。（シャドウITのように、統制から外れて利用されているシステムが存在する場合もありますが、それは今回のアドベントカレンダーの趣旨とは異なるため、ここでは省略します）

また、自社でサービス開発を行っている企業の場合、提供するサービスやその管理システムについても把握する必要があります。特にこれらのシステムでは、顧客情報やユーザ情報などの重要なデータを扱うことが多いです。これらは社外のSaaS以上に変化が早く、把握が難しいですが、セキュリティ監視の対象としては非常に重要です。

システムを整理する際には以下の観点に着目すると良いでしょう。

• システムの連携先: 業務をするうえで他のシステムと何らかの形で連携して動作するシステムは多く、どのシステムとどのようにデータ連携しているかは大事な要素です。これによってシステムが危殆化した際に、どのシステムに影響が出るかを把握することができます。
• システムが出力できるログ: 監視に利用できるログを出力できるかはシステムによって異なります。特にSaaSのシステムでは契約プランによって監査ログの有無が異なる場合が多いです。また、ログが出力できる場合もどのような種類のログが出力できるか、どの程度の詳細度で出力できるかを概ね把握しておくことが重要です。

脅威モデリング

最後に、自組織にとってどのような脅威があるかをモデリングします。脅威モデリングは、組織内の情報資産とシステムを把握したうえで、発生しうる脅威を整理します。

具体的な方法については割愛しますが、脅威モデリングによってどこに脅威が発生しうるかを把握しつつ、その影響度を評価します。これによって対策を講じるべきシステムや情報資産の対象を絞り込むことができます。

ユースケースの整理

情報資産とシステム、そして脅威が整理できたら、次にどのような事象を検知したいか、どのような事象に対して調査を行いたいかを整理します。これをユースケースと呼びます。このユースケースがセキュリティ監視を構築する上での大きな要件となります。

検知したい事象の整理

検知したい事象は、脅威モデリングで整理した脅威に対して、どのような事象を検知すればよいかを考えます。具体的な検知については、MITRE ATT&CKのようなフレームワークを参考にするとよいでしょう。MITRE ATT&CKは、様々な攻撃手法への対策として Detection というセクションがあり、具体的に検知するべき事象について例示されています。脅威モデリングで整理した脅威が利用しうる攻撃手法とマッピングし、検知すべき事象を整理します。

ただし、MITRE ATT&CKのようなフレームワークで示されている検知対象はあくまで一例であり、すべてをそのまま検知対象として採用するのは難しいでしょう。例えばMITRE ATT&CKで示されているModify Cloud Compute Infrastructure: Create Cloud Instanceでは、クラウドインスタンスの作成を検知することが推奨されていますが、このような記載もあります。

The creation of a new instance or VM is a common part of operations within many cloud environments. Events should then not be viewed in isolation, but as part of a chain of behavior that could lead to other activities. For example, the creation of an instance by a new user account or the unexpected creation of one or more snapshots followed by the creation of an instance may indicate suspicious activity.

(拙訳) 新しいインスタンスやVMの作成は、多くのクラウド環境における運用の一般的な部分です。イベントは単独で見るのではなく、他の活動につながる可能性のある一連の行動の一部として捉えるべきです。例えば、新しいユーザーアカウントによるインスタンスの作成や、予期しないスナップショットの作成の後にインスタンスが作成されることは、疑わしい活動を示している可能性があります。

記載にもある通り、クラウドを活用している組織であれば「インスタンスの作成」という事象自体は一般的な操作であるため、そのまま検知対象としてしまうと多くの誤検知が発生するでしょう。確かに「一連の行動」としてみると攻撃の一部である可能性はあります。しかしこれは実際におきたインシデントから遡った場合にわかることであり、機械的に絞り込むのは比較的難しいでしょう。

例えばこれを検知対象として扱うためには、以下のいずれかの条件を満たす必要があります。

1. その組織ではインスタンスの作成が非常に稀である、あるいは原則使用されないポリシーになっている
2. その組織ではインスタンスの作成はある特定の条件下でしか実行されないポリシーになっている
3. 定期的に時間をかけて分析をできる人物がいる

1,2 のようなポリシーがある場合は、そのポリシーに基づいて検知対象を設定することができます。3 についてはこの一つの事象だけであればそこまで工数はかかりませんが、同じような事象が数十、数百と設定された場合にスケールするのかが課題になります。

このようなことを踏まえ、検知対象を整理する際には

• 検知したい事象が、組織のポリシー・環境に基づいて機械的に特定できるか
• 分析にかかる工数を用意できるか

という観点を折込みつつ、脅威に対する優先度も加味して整理するとよいでしょう。すべてを一律に検知対象としてしまうと、誤検知が多くなり、結果的に監視の信頼性が低下する可能性があります。

調査したい事象の整理

並行して調査したい事象についても整理します。調査については人間が手作業で実施することを想定するので、砕いた表現をするならば「どのログを検索可能にしておくか」という整理になります。調査する対象の捉え方としては、大きく2つの観点があります。

1. 検知されたアラートが実際に影響を及ぼす可能性があるかどうかを調査する（トリアージ）
2. アラートが影響のあるインシデントであった場合、そのインシデントの原因、影響範囲を調査する（インシデントレスポンス）

1については殆どの場合、そのアラートが検知されたシステムのログから調査を始め、それでも影響が不明な場合は周辺システムのログを調査するという流れになります。そのアラートの時系列的な前後のログであったり、アラートに出現したIndicator（IPアドレス、ドメイン名、ユーザ名、ファイルハッシュ値など）をキーとして検索をします。そのため調査対象としては、どのような検知をするかをベースにそのシステムと、できれば周辺のシステムのログを対象にします。

2については、アラートが発生したシステムのログだけでなく、そのアラートが影響を及ぼす可能性がある他のシステムのログも調査対象になります。具体的には実際に影響があったシステムだけでなく、そのシステムの攻撃に至るまでの経路や、そこから攻撃が派生する可能性があるシステムも含まれます。しかし、可能性を考え始めるとすべてのシステムが対象となりえ、もちろんすべてのシステムのログが取得できるとよいですが、実際には困難です。そこで調査対象を絞り込むために、以下のようなシステムを中心に考えるとよいでしょう。

• 重要度の高い情報資産を扱うシステム
• 攻撃の経路として考えられるシステム（外部・内部含む）
• 全体を制御するようなシステム（例：AD、クラウドプラットフォーム、認証認可管理システムなど）

これらの情報を整理し、最終的にどのログを検索可能にしたいかというところまで整理すると、セキュリティ監視の要件が見えてくるでしょう。

インターフェースの整理

セキュリティ監視基盤が担うログの収集やアラート検知は原則として自動化されていますが、それでも人間が介入する部分があります。それが調査や分析のためのログへのアクセスと、アラートの通知および管理になります。これらのインターフェースも整理しておくことで、セキュリティ監視基盤の要件を明らかにできます。特に、調査・分析のためのインターフェースは全体の設計への影響が大きいため、事前に検討しておくことが重要です。

調査・分析のためのユーザインターフェース

調査・分析のためのインターフェースは、端的に言い換えればログの検索や集計のためのインターフェースとなります。ログの検索や集計は、セキュリティ監視基盤の中で最も頻繁に利用される機能であり、その使い勝手がセキュリティ監視の効率に大きく影響します。

ログ検索のためのインターフェースの例としては以下のようなものが考えられます。

• grep: オブジェクトストレージに保存されたログを直接検索するためのインターフェースです。Google Cloudの場合、BigQueryを使ってCloud Storageを参照することで同様のインターフェースを提供できます。（AWSの場合はAmazon AthenaやS3 Select）。簡易に実装できる反面、検索速度が遅く機能的にも非常に限定的なので、成熟したセキュリティ監視基盤での利用には適しません。
• SQL: 今回のアドベントカレンダーではGoogle Cloudを対象とするためBigQueryとなりますが、AWSの場合でもAmazon Athenaを利用することで同等のインターフェースが提供できます。もともと検索、集計のための言語であるため、複雑な検索や集計を行う際には非常に有用です。ただし、SQLのクエリ記述の知識が必要であるため、万人にとって使いやすいわけではありません。
• BIツール: BIツールを利用することで、SQLを知らなくてもログの検索や集計ができるようになります。Google Cloudの場合、Data Studioを利用することでBigQueryのデータを可視化できます。BIツールはSQLよりも直感的に操作できるため、ログの検索や集計を行う際には使いやすいですが、複雑な検索や集計を行う際にはSQLよりも限定的になることがあります。
• 検索エンジン: Elasticsearchのような検索エンジンを利用することで、ログの検索や集計を行うことができます。検索エンジンはログの検索に特化しているため、検索速度が速く、複雑な検索や集計も行うことができます。ただし、ログの取り込みやシステム運用のコストが比較的高くなってしまうことに注意が必要です。

このようなインターフェースがあることを踏まえつつ、要件を整理しておくのが良いでしょう。要件の整理には以下のようなポイントがあります。

• ログの検索・集計範囲: どの程度の期間のログを検索できるか。例えば検索エンジンを使う場合、ログの保存容量がコストに大きく影響するため、保存期間を短くして運用することがあります。検索エンジンとSQLを併用するやり方もありますが、その場合も期間の整理は必要です。
• ログの検索・集計速度: ログの検索速度は頻繁に検索や集計をする場合、ユーザビリティに大きく影響します。検索エンジンの方がよりインタラクティブに検索できますが、大規模データの場合はSQLの方が速いことがあり、どのような操作をしたいかを整理しておくとよいでしょう。
• ログの検索・集計の自由度: 検索エンジンやSQLは複雑な検索や集計を行うことができますが、BIツールやgrepは限定的です。どのような検索や集計を行いたいかを整理しておくと、適切なインターフェースを選択できます。
• ログの検索・集計に必要な熟練度: SQLやBIツールは熟練度が必要ですが、検索エンジンは比較的簡単に操作できます。ログの検索や集計を行うユーザのスキルを考慮して、適切なインターフェースを選択できます。実際に操作をするメンバーにあわせて、インターフェースを選択することが重要です。

まとめ

セキュリティ監視基盤を設計する際には、自組織の情報資産、システム、脅威を整理し、検知したい事象、調査したい事象、インターフェースを整理することが重要です。これによって、セキュリティ監視基盤の要件を明確にし、設計の方向性を定めることができます。今回は機能要件について整理しましたが、次回は非機能要件について整理します。