最初に
SC-200の勉強です。
SentinelについてはMSの人が書いたガイドみたいな本もないし、公式ドキュメントにしか頼れない。その割に、Sentinelはリソースを建ててからの設定が面倒くさい気がします。（もう少しリソース作成時にどのログを取り込みますか？みたいなウィザードでポンポンできたらいいのにという感想を持った。）
基本的には以下のMicrosoft LearnとGithubのHandsOnが元ネタです。
あとまだ見ていないけど、MicrosoftのSC-200の動画Playlistがあったので置いておく。
Microsoft Defender, Defender for Cloudについてはこちらを見てください。
実際に自分で環境を構築したい場合はMicrosoft Defenderのページから環境構築できます。
SentinelはSIEM（security information and event management）製品で以下のような機能を提供する。
- Log management
- Alerting
- Visualization
- Incident management
- Querying data
Sentinelに対してConnector経由でサービスと接続し、ログはLog Analyticsに保管される。
ただし、Sentinelの他に併用すべきソリューションもあり。
①パフォーマンスモニタリングのためには、別途インフラログやアプリログはLog Analyticsに別に保管しておくべき。
②クラウドのセキュリティ態勢管理（CSPM）のためにはDefender for Cloudを利用するべき。
基本的には1 Azure Tenantに対して、1 Log Analytics Workspaceで1 Sentinel のインスタンス。ただし、Regionの制限などがある場合は複数立てることもあり得る。その場合はRegionまたぎのデータ送信になるのでデータ通信量分のコストが発生する。
環境構築
Create new workspace
Log Analyticsを作る。
LogAnalyticsとSentinelを関連付ける。
とかやってこんな風に2つリソースができた。
一旦Sentinel管理者用にSentinel Contributorの権限を自分に付与する。
ログ保持期間の設定
Log Analyticsは監査などの方針に則って、ログ保持期間を長めに持つこともできる。（基本はデフォルト30日。Application Insightsは90日。）
Log AnalyticsのTablesからTableごとに設定することも可能。
Sentinelはどこから使うか
ちなみにSentinelはMicrosoft DefenderとAzure Portalからアクセスできるが、利用できる機能は違いがあるらしい。うーん面倒くさい。
Perplexityに質問してみると、設定はAzure Portal、利用はDefenderという感じになりそう。
Sentinelの設定はどこから、、、
ちなみにSentinelの設定はResource GroupのSecurity Insightsではない。
ちゃんとトップページ > Sentinelから行く必要がある。
と思ったら、今後はDefender Portalで統一されていくらしい。
Content Hubから様々なデータを取り込む
Sentinelは様々なサービスからのログを取り込むことができる。Microsoft Defender XDRを介するもの、Defender for Cloudを介するもの、直接など。
Sentinelのコンテンツには以下のように様々なものがあり、Content Hubから設定することで使えるようになるものが多い。
- データ コネクタは、 さまざまなソースから Microsoft Sentinel へのログ インジェストを提供します
- パーサーは 、ログの書式設定/ASIM 形式への変換を提供し、さまざまな Microsoft Sentinel コンテンツ タイプとシナリオでの使用をサポートします
- ワークブックは、Microsoft Sentinelのデータに対する監視、視覚化、対話機能を提供し、ユーザーにとって意味のある洞察を強調します。
- 分析ルールは 、インシデントを介して関連する SOC アクションを指すアラートを提供します
- ハンティング クエリ は、Microsoft Sentinel で脅威を事前に検出するために SOC チームによって使用されます
- ノートブックは、 SOC チームが Jupyter と Azure Notebooks で高度なハンティング機能を使用するのに役立ちます
- ウォッチリストは、 強化された脅威検出とアラートの疲労軽減のために、特定のデータの取り込みをサポートします
- プレイブック と Azure Logic Apps カスタム コネクタは、Microsoft Sentinel の自動調査、修復、応答シナリオの機能を提供します
Threat Indicatorの取り込み
**Threat Intelligence Indicator（脅威インテリジェンス・インジケーター、略称：IOC）**は、Microsoft Sentinelがマルウェアや悪意のある通信などを検出する際に参照する"脅威のリスト"や"攻撃の兆候"の集まりです。
たとえば「悪意のあるIPアドレス」「既知マルウェアのファイルハッシュ」「フィッシングに使われたURL」などが含まれます。
Sentinelでは、このインジケーター情報（ThreatIntelligenceIndicatorテーブルなど）を使って、ログやイベントと照合し（たとえばネットワーク通信やメールの宛先、ファイル書き込み等）一致した場合に分析ルールで自動的にアラートを生成し、脅威を検出します。
これらはMicrosoftから提供されているものもあるし、独自にも定義できる。これをしなくても全く検知・アラート機能が動かなくなるわけではないが、高度な機能を利用するためにはやっておくべきということらしい。
Content HubからMicrosoft Defender Threat Intelligenceをインストールしてみる。
中身にはPlaybookなども含まれる。インストール自体は無料。
と思ったら、Data Connectorが含まれていないとThreat intelligence indicatorテーブルにデータが追加されないらしい。Preview版だがこちらも追加する。
Data ConnectorにThreat Intelligenceが表示された。
Connectしてやる。
LogAnalyticsのThreatIntelligenceIndicatorにデータが表示されるようになった。
ちなみにTAXIIという言葉も見かけるが、これはTrusted Automated eXchange of Indicator Informationの略で、攻撃の兆候を標準化するためのプロトコルらしい。Sentinelはこれのver 2.1まで対応している。
IPAのページでは「サイバー攻撃活動の情報を交換するための仕様」とある。これ専用の仕様があるなんてニッチすぎる。。。
Defender XDR
Microsoft DefenderのページからトップページのConnect a workspaceからでOK。
SentinelのConnectorのページにXDRがConnectedになっていることを確認。
Microsoft Defender XDR suite includes:
Microsoft Defender for Endpoint
Microsoft Defender for Identity
Microsoft Defender for Office 365
Microsoft Defender for Cloud Apps
Microsoft Defender Alerts
Microsoft Defender Vulnerability Management
Microsoft Purview Data Loss Prevention
Microsoft Entra ID Protection
Open Connector Pageからどのデータを取得するか選択。
とりあえずO365以外は全部ONにしてみる。
その他にもContent Hubから様々なデータソースを取り込める。
- マイクロソフト エントラ ID
- Azure アクティビティ
- Microsoft Entra ID Protection（マイクロソフト エントラ ID 保護）
- Azure DDoS対策
- アジュール情報保護
- Azure Firewall
- Microsoft Defender for Cloud
- Azure Web Application Firewall (WAF) (以前の Microsoft WAF)
- ドメイン ネーム サーバー
- オフィス365
- Windows ファイアウォール
- セキュリティ イベント
等
Microsoft Defender for Cloud
毎回思うのだが、Data Connectorがインストールされるだけでは足りなくて、個々のConnector Pageで有効化などをしなくてはいけないのは、不親切だと思う。
Azure Activity
ちなみに、インストール後はOpen Connector ページからポリシーで「必ずLog AnalyticsワークスペースにAzure Activityログを送る」というルール（ストリーミングポリシー）がを作る必要がある。これにより、原則全てのリソースはLog Analyticsにログを送信するのが必須になる。（例外設定は可能）
Azure Policyに追加されている。
Entra ID
SigninログとかSentinelで分析したい場合。
とりあえず全部取り込んじゃえ。
EntraのDiagnostics SettingsでもLog Analyticsにデータ送信するようになっていることを確認。
VM
Windows Deviceのログ
Windows Security Eventsを選択。これを使えば、Azure Monitor AgentがインストールされているVMからログが取得できる。
Open Connector Pageから、Data Collection Ruleを作る。
ちなみに、Defender for Cloudを設定する際に、Defender for Servers Plan 2をOnにしていれば、原則自動的にAzure Monitor AgentはVMにインストールされる。
Agentless scanなどもあるけど、Sentinelとの連携のためにはAgentが必要ということらしい。
Linux Host
Common Event Format Connectorというものを使う。
Perplexityの説明。なるほど。
Common Event Format（CEF）とは、セキュリティイベント等のログを共通の構造・書式で記録するための標準システム。世界で広くSIEM製品のログ標準化・相互連携に活用されている形式です。
Linux VMはちょっとスキップしてしまうが、基本的にはLinuxもAzure Monitor Agentを入れたVMに対して、Data Collection Ruleを設定する感じらしい。
取得したいものによって違う。ちゃんとやるならどちらも取得しなくちゃなのかな。。。
Azure Policyの利用
ちなみに、標準ではVMが増えても自動的にログ取得対象にしてくれないため、Policyで自動化することが望ましい。Perplexityによる。
しくみ・必要な設定
標準状態（手動連携だけ）
AMAインストールやDCRの関連付けを手動で行った場合、新規VMには自動でこの設定が継承されません。⇒ 新しく増えたVMには自分でAMA＋DCR紐付けを追加する必要あり。
Azure Policyによる統制を導入した場合
「Azure Monitor エージェントをインストールし、データ収集ルールに関連付ける」というAzure Policy（OS別イニシアティブ）をサブスクリプションやリソースグループに割り当てておくことで、以後そこで作成されたVMには自動的にAMAがインストールされ、指定したDCRも自動で適用されます。⇒ VMが増えても自動追従し、設定漏れ・運用負担を大きく減らせます。
まとめ
AMAコネクタやDCRだけでは“新規VMの自動連携”はされません。Azure Policyを導入すれば「新たに作成されたVMも自動的にAMA＋DCRによるログ取得対象」となります。大規模・長期運用ではAzure Policyによる統制を強く推奨します。
サードパーティ製品のログ
サードパーティのものを取り込む場合はAzure Linux VM内のAgentをフォワーダーとして経由して取り込む必要がある。Syslog と Common Event Formatが使える。
Content Hub > CEFで検索。
、、、が、Open Connectorから詳細を設定しようとしたところエラーになった。。
一応ドキュメントを見る感じ、Forwarderを構築するための手順が書かれて要るっぽい。
Watchlist
Watchlistを使えば外部データをcsvとして取り込むことができる。
使い方としては色々で、以下のようなケースを想定する。(正直ただカスタムデータ取り込めて何がうれしいの？と思ってました。。。)
- 脅威調査やインシデント対応の効率化：資産リストや許可されたユーザーのホワイトリスト、退職者リストなどをウォッチリストとして管理し、検出ルールや脅威ハンティングクエリで参照することで、誤検知を減らしたり迅速な対応が行えます。
- アラートの疲労軽減：許可済みのIPやユーザーをホワイトリストとしてあらかじめ登録し、それらからのアラートを抑制することで、不要なアラートを減らし、本当に対処が必要な脅威に集中できます。
- 自動化連携：Logic Appsなどと組み合わせて、ウォッチリストへのデータの定期的な自動更新も可能です。
自動対応（SOAR）
オートメーションルールとプレイブックの2種類がある。
基本的な使い分けとして、インシデントやアラート発生時に「まずオートメーションルールがトリガーされ、必要に応じてプレイブックが実行される」スタイルが推奨されています。オートメーションルール自体のアクションから直接プレイブックの呼び出しが指定できます。
「トリガーと制御」＝オートメーションルール、「具体的な自動対応内容」＝プレイブック、という役割分担が基本です。
オートメーションルール
例として以下のようなことができる。
- インシデントを適切な担当者に自動的に割り当てたり
- 分類のためにインシデントにタグを付けたり
- インシデントの状態を変更して閉じたり
- Playbookを実行したり
一から作ってみる
Configuration > Analyticsでカスタムクエリでアラートを挙げることができる。
トリガー
アクション（そんなにできること多くない）
Templateから作る
オートメーションルールは上記のように一からも作れるし、templateからも作れる。今度はTemplateから作ってみる。
例えばCloudshellの利用者が増えたのを検知。
どんなクエリを
どれくらいの間隔で検知するか。
同じアラートがずっと上がらないように1時間に1回とかも制限できる。
検知したらインシデントを作成する。
インシデントが作成されたらどんなAutomated Responseが実行されるか。
試しにCloudshellを有効化してみる。
Incidentとして検知された。
Defender for Identityをオンプレドメコンに導入
センサーというものをドメコンにインストールする必要がある。これによりオンプレのアクティブディレクトリの監視もできるようになる。
Playbook
アラートが発生したときの自動対応でPlaybookを利用できる。
Content HubからSoar Essentialsをインストールする。
Phishing用のPlaybookを設定する。
Logic Appsが開くのでEditすると中身が見れる。
Automation RuleとPlaybookの連携
Automation RuleからIncidentが作られたときにPlaybookを実行する。
サンプル
その他Playbookのサンプルは以下Github リポジトリにある。
長くなったので、その２は下に続きます。