Microsoft Sentinel 活用で注意したい点とメリット

Microsoft Sentinel（以下、Sentinel）は、Microsoft製品を中心に様々な製品のログを集約し、インシデント情報などを一元的に管理できる、クラウドネイティブのセキュリティ情報イベント管理（SIEM）^※1サービスです。

※1 SIEM：Security Information and Event Management

WindowsなどMicrosoft製品との相性が良く、簡単にログを収集・分析してアラートを受け取れます。一方で実際に試した結果、ログを収集したけれどログの活用ができない、円滑な運用を構築できない、といった相談を受けることが多くあります。

今回は、Sentinelを利用する際につまずきやすいポイントや、どこに注目すれば有効に活用できるのかについて解説します。

Sentinelとは

Sentinelは、クラウド型のログ統合管理サービスです。Microsoftの各種サービス、特にMicrosoft 365 E3/E5に含まれる高度なセキュリティサービスと連携機能が豊富にあります。また、Windows端末などのデバイス管理やセキュリティサービスのログを一括して取り扱えます。他社製品やサービスとの連携も豊富です。

例えば、Palo Alto Networks社のファイアウォール製品や、CrowdStrike社のFalconといったエンドポイント保護製品、Salesforce Service CloudといったSaaSと連携できます。さらに、ログを横断した高度な分析や、機械学習によるユーザーの行動分析（UEBA）^※2など、豊富なアラートを出すセキュリティ検知機能があります。検知したアラートに対して自動的に対応できる、自動化機能（SOAR）^※3も備えています。

※2 UEBA：User and Entity Behavior Analytics
※3 SOAR：Security Orchestration, Automation and Response

Sentinelの活用でつまずきやすい点

Sentinelでログを取り込むまでは簡単です。ログを分析するのも、あらかじめ用意されたルールを使えば容易にできます。つまずきやすい点を挙げるならば、アラートを検知してインシデントが起きた後の判断です。

インシデントの内容を調査するための支援はありますが、本当に対応する必要があるか、悪性のものかといった判断は運用する人が行います。対象となるシステムやサービスの知識に加えて、何が起きているか判断するセキュリティの知識が必要になるのです。

これは侵入検知システム（IDS/IPS）やWebの防御（WAF）のときにもあった問題ですが、SentinelではAzure ADの認証情報にWindowsのエンドポイント情報や、Azureなどのクラウドの情報、SaaSの利用情報、連携している他社製品・サービスの情報など、連携すればするほどに幅広いカテゴリーの知識が必要になります。そのため、インシデントの判断が難しく、結果として十分に活用しきれない状態が発生してしまいます。

アラートやインシデントは何が問題と判断したのかを教えてくれますが、必ずしも問題そのものを示すわけではありません。アラート自体にも誤検知があります。判断の指針になるインシデントの重大度も、利用環境によってはずれている場合があります。これらが調査を難しくする主な原因と言えるでしょう。

Sentinelの強み

活用しきることが難しい一面もありながらも、Sentinelには優れた点が多くあります。ここではその一部をご紹介します。

豊富な調査能力

Sentinelには豊富な調査機能があります。インシデントの調査では、ユーザーやIPアドレス、端末といったエンティティ識別子を元に、関連する情報を一覧できるようになっています。インシデント発生時にまず調べるべきことの一つに「どこで（誰で）問題が発生したか」があり、エンティティ識別子はこの調査を補助してくれます。

また、サイバー脅威インテリジェンス（CTI）^※4を利用して外部の脅威情報と連携できるので、他の組織で既に悪性と判断されていれば、インシデントの判断を簡略化できます。

※4 CTI：Cyber Threat Intelligence

より深い調査のために、ログの含まれるテーブルから直接KQLクエリで調査することも可能です。ハンティングクエリと呼ばれる深い調査に特化した調査機能や、プログラムで調査できるノートブック機能など、様々な手法で調査できます。自動化機能を併用すれば、あやしい挙動のユーザーを自動で隔離するなど調査対象自体を減らせます。

SIEMとして使い勝手がいい

Microsoftサービスの中で閉じるのであれば、Defenderのポータルなど優秀なポータルがありますので、必ずしもSentinelは必要ありません。しかし、他社製品・サービスと連携をさせたいのならば、豊富なコネクタを持つSentinelをおすすめします。例えば、組織内のファイアウォールのログを連携して、端末で検知したアラートと突き合わせて調査するといったことができます。

他社製品のログを収集できるだけではなく、取り込んだログに対してアラートを出すための分析ルールと、概要を確認するためのブック（ダッシュボード機能）が定義されているので、連携した段階である程度ログが活用できる状態になります。これは、ログを取り込むだけで、分析・活用は利用者に任せるタイプのSIEMにはない利点です。その上で十分な調査能力を持ち、運用負荷を減らすための自動化も行えます。これら全てが統合された形で利用できるのが、Sentinelの圧倒的な強みです。

最後に

Sentinelは豊富な機能を持ち、SIEMとして使いやすいサービスです。SIEMで陥りやすい「ログを集めたけれど、どう分析しよう」という問題に対してもある程度の解決策が用意されていて、SIEMの運用をはじめやすくなっています。インシデントの調査に対しても判断の難しさは残りますが、前述のように支援があります。また、Sentinelの機能に頼るのではなく、豊富な機能を素材として自組織なりに使いこなすことで、さらなる活用も可能なポテンシャルがあると考えます。

ラックでは、社内で実践したノウハウをもとにした、お客様への活用支援サービスを展開しています。Sentinelを使い始めたけれど使いこなし方に悩んでいる、ラックの使い方を知りたいという方は、ぜひお問い合わせください。