本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「Azure Sentinelを起動したら自分のSIEM感が再定義された件」を再編集したものです。
この記事はFIXER Advent Calendar 2019 (https://adventar.org/calendars/4579) 12日目の記事です。前日は佐藤匠さんの『App Service EnvironmentとAzure Firewallを構成する』です。
はじめまして、三浦 史也と申します。FIXER唯一のCyber Security Analystとして10月に入社しました。ブログ第一弾として、2019年9月に一般提供が始まったAzure Sentinelについて筆を執ります。Azure Sentinelを簡単に紹介した後、Azure Sentinelの起動からMicrosoft Cloud App Security等とのログ連携について書いてまいります。
そもそもAzure Sentinelって何?
Microsoft社の言葉を借りると、Azure Sentinelとは「スケーラブルでクラウドネイティブ型のセキュリティ情報イベント管理 (SIEM) およびセキュリティ オーケストレーション自動応答 (SOAR) ソリューション」です。
なかなか掴みづらい表現だと思いますので、一旦は「セキュリティインシデントが起こってないか半自動で確認・対処してくれる」サービスとイメージしていただければと思います。以下でSIEMとSOARについてそれぞれ説明してまいります。
SIEM : Security Information and Event Management って何?
SIEMという言葉を検索してみると、様々な説明がでてきます。賛否あるかと思いますが、私のブログではSIEMを「セキュリティ情報イベント管理」という直訳の定義に加え、以下機能を持ったサービスや仕組みとして話を進めます。
・ 以下などの機器からのログを受信、整形(パーシング)、保存する
セキュリティ機器(WAF, IPS, IDS, EDRなど)
ネットワーク機器(ファイアウォール プロキシー, ルーターなど)
サーバー(Webサーバー, アプリケーションサーバー, DHCPサーバーなど)
その他様々なサービス(Office 365, Active Directoryなど)
・ アラートを定義し、受信ログや機械学習から情報資産を脅かすイベントを検知/通知する
・ ログを受信している機器単体の、あるいは、相関的なイベント分析の手助けをする
(ログ検索、Dashboard画面、整形されたログの出力)
SIEMをフル活用することにより、単純なセキュリティアラート以外に以下を見つけることができます。
・ガバナンスの崩壊
(社内ルールで禁止されているアプリケーション利用やグレーなデータの持ち出しを示すプロキシーログ)
・機器のメンテナンスやアップデートのミス
(過剰に検知されているIPSログ、メンテナンス日にログの増加が無いこと)
・運用の不備
(一般的には許可すべきでない通信が許可さているファイアウォールログ)
・脆弱性への対応不備
(脆弱性の存在をしめす応答やヘッダを含むログ)
セキュリティ/ネットワーク機器単体でも上記を見ることができますが、SIEMのDashboard画面などの活用で相関的・効率的に上記を見ることができます。SIEMは私たちにサイバーの世界で起こっている事象を美しくリアルタイムに見せてくれます。
SOAR : Security Orchestration, Automation and Responseって何?
私のブログではSOARをその直訳でセキュリティの「情報整理・自動化・応答」機能を持つものと定義します。
セキュリティインシデントが発生した際、「事象の正確な把握」「優先順位の判断」「一次対応」などが必要になりますが、その流れを自動的に行ってくれる機能を持つものがSOARです。「特定のイベントを検知した場合にSlackで詳細をまとめて通知する」や「AとBのセキュリティイベントが同じ送信元IPアドレスから同時に起こった場合、送信元のIPアドレスからの通信をファイアウォールで遮断する」などがSOARの基本的な利用例として考えられます。何だか人間に楽をさせてくれそうなSOAR機能ですが、Sentinelではプレイブックと呼ばれる手順の集まりがその機能を持っています(次回の記事で詳しくご紹介予定です)。
Azure Sentinelの起動
SIEMとSOARの説明を終えたところで、いよいよ、Azure Sentinelの起動についてその流れをご紹介します。今回は以下前提でAzure Sentinelを起動しました。
[前提]
・グローバル管理者ロールのアカウントで操作する
・既にAzure Sentinelを動かす為のLog Analyticsが作られている
① まず、Azureポータル画面の検索画面にAzure Sentinelと入力し、サービス配下にでてくるAzure Sentinelをクリックします。
② Azure Sentinelを動かすLog Analyticsをクリックします。その後右上に”Adding Azure Sentinel”というポップアップが上がります。
③ ①②の手順のみでAzure Sentinelが起動します。
※利用イメージがわきやすいようログ取込み後の画面です。
Microsoft Cloud App Security, Office 365, Azure Active Directory等とのログ連携
④ Azure Sentinel画面の左側「データコネクタ」タブをクリックします。その後、接続したいコネクタ(サービス)をクリックし、右下の「コネクタページを開く」ボタンをクリックします。今回はMicrosoft Cloud App Securityを選択しています。
⑤ 「前提条件」に問題がないか確認し、各「接続」ボタンを押していきます。「接続」ボタンが「切断」ボタンに変わると接続完了です。
①〜⑤の手順にかかった時間は約20分です(Office 365やAzure Active Directoryの接続も④⑤とほぼ同様で、その接続時間も20分に含まれています)。とても爆速でAzure Sentinelの起動とログの連携が終わりました。
自分の中のSIEM観が再定義された
一般的にSIEMをオンプレミスなどで導入するケースを考えると、ネットワークの構築やログの整形(パーシング)などに多大なコストがかかります。こちらの情報処理推進機構の調査報告書を読むと、SIEM導入の大変さがわかるかと思います。また、ログ量や接続サービス数にもよりますが、調査報告書のP.75を参照するとSIEM導入の概算費用は700万円と記載があり、決して安くないことが分かります。
今回はネットワーク構築やログの整形(パーシング)などに頭を痛めることなく、Azure SentinelとMicrosoft Cloud App Security、Office 365などのログを、わずか数十分で連携できました。その間の操作は、数十文字の入力、数十回のクリックだけでした。Azure SentinelとMicrosoft社提供のサービスの連携という条件下ではありますが、仮にオンプレミスで同様の連携をしようとした場合、数百倍以上の時間がかかっていたと思います。また、今回連携したログの90日のデータ保持料金は無料、 また、Microsoft Cloud App Security、Office 365のデータ取り込み料金が無料だったこともあり、導入に際しその費用総額は数百円でした。
※ 費用はデータ量やその他のサービス利用状況により異なります
SIEMの導入には多大なコストがかかるとの認識でした。しかしながらAzure Sentinel起動/連携の経験をとおし、私の中のSIEM要素として新たに「手軽さ」が加わることで、私のSIEM観の再定義が行われました。こちらのMicrosoft社の記事ではAzure Sentinelを「クラウドにおいて再定義される最新の SIEM」と説明していますが、その表現に異論はありません。
今後
今回のAzure SentinelとMicrosoft Cloud App Security, Office 365, Azure Active Directoryの連携で、オフィス環境におけるアカウントの不正利用、ウイルス感染などを検知するための材料が十二分にそろったと考えます。次回はAzure Sentinelのログ検索、プレイブック、ハンティングなどの各機能の紹介をできればと思いつつ、一旦、筆を置きます。
