はじめに

昨今のサイバー攻撃や内部不正の検出・対応のために、SIEMの導入に積極的な組織が国内でも増えてきています。金融庁ガイドラインをはじめとして、様々な業界におけるガイドラインでも、ログの収集・分析を一元的に行うための基盤整理が求められており、SplunkやSentinel、Exabeam、NG-SIEMといったSIEM製品が注目されています。

しかし、SIEM導入のために高い費用を払ったのに運用ができず、効果は期待外れになってしまった、という話も枚挙に暇がありません。実は、SIEMは導入後の運用が大事なのです。

そこで本記事では、SIEM運用がイマイチになってしまう理由と対策について解説します。運用にお困りの組織および導入をお考えの組織の参考になればと思います。

INDEX

はじめに

残念なSIEM運用事典
┗　[1]アラート疲れがひどい
┗　[2]誤検知が多すぎる
┗　[3]効果は見えないが、費用だけは目立つ

貴社のSIEM運用がイマイチな理由6つ
┗　理由[1]：「ログの一元管理」への理解が浅い
┗　理由[2]：組織のセキュリティカバレッジを理解していない
┗　理由[3]：日々のチューニングができていない
┗　理由[4]：SIEM製品の機能を使いこなせていない
┗　理由[5]：製品やAIへの過度の期待と依存
┗　理由[6]：そもそもIT資産管理ができていない

SIEM運用を改善する5つの指針
┗　1.ログ管理の目的を明確にする
┗　2.目的に沿って環境をチューニングする
┗　3.SOARや自動化機能を活用する
┗　4.不要な機能は勇気をもって停止する
┗　5.IT資産の洗い出しを優先する

まとめ

Q&A

残念なSIEM運用事典

弊社ではSIEMを含むSOCのマネージメントサービスを提供しています。弊社にSIEM運用をご相談されるお客様の課題として、以下がよく見られます。

[1]アラート疲れがひどい

各種のセキュリティ製品のアラートや関連ログを一元管理するようになると、連日大量のアラートが発生しますが、これがアラート疲れの原因です。
筆者は十数社のSOC運用に携わりましたが、実感としてSWGやCASB、ID管理、WAF、FW、IPSで非常に多くのアラートが発生する傾向があると感じています。

以下は弊社で監視しているMicrosoft製品の6カ月で見たアラート発生数です。
EmailやSharePointを監視するMDO（Microsoft Defender for Office）、クラウドアプリを監視するMDCA（Microsoft Defender for CloudApps）からのアラートが突出して多いことがわかるかと思います。

このアラートを元に状況を確認し、インシデントであると判断し対応するのはセキュリティや情報システムの担当者になると思います。専門性を持った人材が少ない組織では、1人にかかる重圧も大きくなるため、いつしか対応に疲弊してしまって、休職・退職するようなケースも少なくないようです。

多すぎるアラートに疲れた担当者や組織が、分析や対応を放棄してしまった状態を何度か目にしていますが、アラートの数や製品の設定を見れば無理もないと感じることもあります。手がつけられるうちに、早めに対処するべきです。

[2]誤検知が多すぎる

現代的なゼロトラストセキュリティにおいては、「すでに侵害（攻撃）が発生していると想定する」というアプローチでユーザーや端末から不審な挙動を検出します。

しかし、現代は働き方や使用ツールが多様化しているため「不審」の定義をパターン化することが難しいという問題があります。SIEMやセキュリティ製品は「不審と見られる」挙動から多数のアラートを生成してくれますが、誤検知ばかりで困るケースも多いのが実情です。誤検知によるアラートの生成を「セキュリティ製品の（性能の）問題だと思って放置して（受け入れて）いた」という話もよく耳にします。

誤検知はアラート疲れの原因になるだけでなく、SIEMやセキュリティ製品への信頼を失わせてしまうため、積極的に「改善して」いくべきです。以下は混同行列と呼ばれる分類方法ですが、精度を高めるにはFalse Positive（偽陽性）を減らしていくことが重要です。

[3]効果は見えないが、費用だけは目立つ

SIEMの導入は安くて数百万円、高い場合は数千万円以上にもなり、加えて運用コストもかかります。決して安い買い物ではないことを現場も経営層も理解しているからこそ、その効果への関心が高くなるのは当然のことです。

しかし、SIEMの導入後にその効果を実感できないという組織も多く、高い費用だけが目立ってしまってお荷物扱いされてしまうケースもあります。

特にガイドラインへの対応や、親会社や顧客の要請といった外部的な要因でSIEMを導入し、導入後の運用が考慮されていない場合に起こりがちな問題という印象です。

貴社のSIEM運用がイマイチな理由6つ

残念なSIEM運用になってしまう理由を深堀りすると、おおよそ次の6つの理由に当てはまります。自社の状況は大丈夫か、ぜひ点検してみてください。

理由[1]：「ログの一元管理」への理解が浅い

SIEMを導入することで「ログを一元管理する」ことが可能になりますが、「ログの一元管理」を「ログを一か所に集めて分析をすること」だと認識していると失敗します。それであれば、SIEMの導入により目的は達成されています。

管理には目的や目標が必要です。甲子園を目指す学校なら、部員集めや環境づくり、練習や試合のスケジュール調整、日々の練習やコンディション作りなどを行いながら、目的・目標の達成に向けて取り組んでいくはずです。これが管理です。

ログを一カ所にまとめて何をしたいのか。

目的を考えるところから運用を見つめ直してみましょう。

理由[2]：組織のセキュリティカバレッジを理解していない

「カバレッジ」とはカバーしている範囲という意味で、セキュリティにおけるカバレッジとは、つまり保護している範囲を意味します。

現代のSIEMのほとんどが相関分析を提供しています。しかし、自社で保有しているセキュリティ製品と、SIEMで提供される相関分析ルールによって、どんな攻撃を検出して防ぐことができるのかを把握していてこそセキュリティホールの存在に気付くことができます。

セキュリティの世界では、組織内で最もセキュリティレベルの低い部分がその組織のセキュリティレベルを決定します。SIEMやセキュリティ製品を入れたことに満足せず、カバレッジを広げるために何をすべきか考えましょう。MITRE ATT&CKなどのフレームワークは自組織のカバレッジの把握に役立ちます。

（引用: MITRE ATT&CK）

理由[3]：日々のチューニングができていない

多くの誤検知が発生する理由の1つが、日々のチューニング不足です。SIEMやEPP、EDR、SWGなど各種のセキュリティ製品はチューニングが可能になっており、適切にチューニングを行ってこそ運用が快適になります。

筆者の経験上、運用しながら3～6か月ほどチューニング作業を行っていると、誤検知も少なくなり、アラートの数や種類が安定してくるため、本物のアノマリー（異常）を判別しやすくなります。

そこまで至るのは少し大変ですが、地道な運用の積み重ねは嘘をつきません。下図は、とある顧客環境におけるインシデントの発生数の推移です。およそ半年で40%程度のインシデントが抑制できています。

蛇足ですが、私見では良いセキュリティ製品ほどチューニングもしやすい印象です。セットできるルールが多い、IoCを多く保持できる、条件を細かく設定できるなどの特徴があります。逆にチューニングの融通が利かない場合は製品の見直しを考えても良いかもしれません。

理由[4]：SIEM製品の機能を使いこなせていない

SIEMの大きな役割・機能として「ログの一元管理」「ログの相関分析」「組織内の各種データの可視化」「ログのエンリッチメント」といったものがあります。また、SOARという自動化機能を持つSIEMも増えてきました。こうした機能を使いこなすことこそ、SIEM運用の醍醐味と言えるでしょう。

たとえばTI（Threat Intelligence：脅威インテリジェンス）を追加することでログの分析精度の向上や調査情報のエンリッチメントが可能になりますし、UEBAやMLといった機能を使えばアノマリーを抽出して未知の攻撃に対しても検出が可能です。

その他にもハンティング用クエリの作成や保存、報告用のグラフや、ダッシュボード画面など様々な機能がありますが、一部の機能しか使われていないケースも多く見られます。宝の持ち腐れにならないよう、使用している製品の機能を再確認してみると良いでしょう。

●SIEMの機能や特徴についてはこちらの記事でも紹介しています。

SIEM製品とは？ SplunkとSentinelをエンジニア目線で比較してみた！

理由[5]：製品やAIへの過度の期待と依存

昨今のAIの発達により、AI技術を使って未知の脅威を検出できるようになってきています。しかしながら、AI検出には次のような問題がある点は認識しておかねばなりません。

• AIの判断や思考過程がブラックボックス化しやすい
• 人間が持つ情報と同レベルの質・量の情報をAIに与えるのが難しい
• AIは分析や判断はするが、責任はとってくれない
• SIEM搭載のAIは、思考や判断基準のチューニングが難しい

セキュリティ分析・対応向けのSOC-AIと呼ばれる製品は、上記の問題点の一部を解決しています。しかし、日本語の自然さや調査の粒度のコントロール、コストという点ではまだ課題がある印象です。また、最終的に人間が責任を取る必要がある点は変わりませんので、担当者にはAIの調査内容をレビューする実力が必要不可欠です。

現状ではセキュリティ製品やAIに過度な期待・依存をせず、人間を中心にセキュリティ分析・対応を行うのがベストな運用であると個人的に考えています。

理由[6]：そもそもIT資産管理ができていない

SIEMで社内のログの一元管理をすることはガバナンス上重要です。しかし、そもそも自社で把握していない製品のログはSIEMであっても収集できませんし、対象を管理することもできません。IT資産管理が不十分な状態ではSIEMによる効果は得られず、脆弱なインフラやアプリが利用されている可能性があります。

資産管理ソフトやASMツールなどを利用して、組織が把握していないITインフラやシャドーITが存在していないかを洗い出し、継続的に管理できる体制を作っておくことが大切です。

●資産管理やASMについてはこちらの記事でも触れております。

ASMサービス比較ガイド｜ASMとは？ 導入前に知るべき7つの選び方ポイント

ASMの必要性が高まる理由とは？　いま攻撃対象領域管理が注目される背景

ASM（Attack Surface Management）とは？　最新ガイドと企業のセキュリティ対策

●弊社でもEASMサービスをリリースしました。ぜひご活用ください。
SIV-ASMサービス
https://www.secure-iv.co.jp/siv-asm

SIEM運用を改善する5つの指針

では、SIEMの運用を改善するためにはどのようにしていけばいいのでしょうか。国内ではSIEMの運用の仕方についての情報が少なく、現場の状況もさまざまですので、正しい運用を定義するのは難しいのが実情です。本記事では筆者の運用経験に基づいて、以下の5つの指針をご紹介します。

1.ログ管理の目的を明確にする

まず、改めてログ管理の目的を明確にしましょう。以下は一例です。

＜目的の例＞

• コンプライアンスの遵守
• ログの適切な保存
• セキュリティインシデントの検知強化
• インシデントレスポンスの効率化
• その他

目的によって、運用・管理のアクションが変わってきます。目的を1つに絞る必要はありませんが、絞り込んだほうが運用に注力しやすく、管理対象ログの種類も減らせるため、低コストです。目的を定め、SIEM運用を通して段階的に管理していくことをお勧めします。こうした運用管理の結果をもって、SIEMの費用対効果を計ることが大切です。

2. 目的に沿って環境をチューニングする

目的を決定したら、その目的達成に向けて環境をチューニングします。

＜コンプライアンス強化のためのチューニング例＞

• ポリシー違反の端末を抽出するクエリの作成
• 検出されたシャドーITの数、種類、ユーザーを抽出するクエリの作成
• 社外からアクセスしたユーザーを抽出するクエリの作成
• 時間外に社内リソースにアクセスしたユーザーを抽出するクエリの作成
• 上記を検出した場合のプレイブックの作成
• 上記クエリ結果を集計、可視化したダッシュボードの作成
• その他

＜セキュリティインシデント検知強化のためのチューニング例＞

• 過去のインシデントからIoCを追加し、複数製品で利用可能にする
• 自社特有の誤検知についてルールをチューニング
• TIの活用による検知精度の向上とインシデント情報のエンリッチメント
• MITRE ATT&CKとの照合により、不足している攻撃の検知ルールを作成
• 最新のセキュリティ情報から想定される攻撃を検知するルールを作成
• その他

＜インシデント対応効率化のためのチューニング例＞

• （特定条件下における）重大度の見直し
• 影響の少ないインシデント、受容できるインシデントの自動クローズ設定
• TIや許可/拒否リストを活用した検知精度の向上
• 自動対応のためのプレイブック作成
• 担当者間の対応数の偏りの把握、調整
• MTTR（Mean Time to Respond: 平均解決時間）の計測、可視化
• その他

目的によってアクションが違ってくることがわかると思います。自組織では何を目的に、何を実施すべきなのか再度考え、優先順位をつけて改善してみましょう。でなく、取引先や委託先を含めたサプライチェーン全体のセキュリティ強化に使われ始めています。

3. SOARや自動化機能を活用する

サイバーセキュリティの世界では、「攻撃側による攻撃開始から目的達成までの平均時間」より「防御側による検知・対応の平均時間」が短ければ防御側の勝ちとみなします。また、インシデント対応においては「1-10-60ルール」と呼ばれるものがあり、1つの目標となっています。それだけインシデント対応には速度が重要です。

現代のセキュリティ製品にはインシデント対応を助ける様々な機能が備わっていますが、それでも大量のアラートの処理が求められる中、これは簡単な目標ではありません。

	コンセプト	例: マルウェア発生を検知した場合
1	1分以内に攻撃を検知	・ウイルス対策ソフトやEDRで検知
10	10分以内に攻撃の内容や目的、影響範囲について調査	・攻撃内容の調査 ・影響を受けた端末の把握 ・発生源、侵入経路の把握
60	60分以内に侵害の修復、対応	・必要に応じ端末を隔離 ・IoCの獲得とIoCを利用したブロック措置の適用 ・公式のパッチが出たら適用

SOARはセキュリティ製品を連携し、処理を自動化するための機能です。EPPと連携してIoCを自動追加したり、CASBやSWGと連携してC2通信と見られるIPアドレスへの通信を自動ブロックしたり、チケットシステムと連携して自動登録・入力を行ったりできます。インシデント対応中に発生する煩雑な作業を自動化することで、迅速で正確な作業を可能にするとともに、担当者が状況の把握や判断に集中できます。インシデント対応に伴うストレスへの対策やアラート疲れにも有効です。

4. 不要な機能は勇気をもって停止する

『せっかくのSIEMには多くのログを入れたいし、多くのアラートを発報してほしい、だからこそ高い費用を払った甲斐がある』そう思うのは当然です。しかし、それこそがSIEMの運用を複雑にし、アラート疲れを引き起こし、運用を高コストにしている要因でもあります。

管理の目的に沿って、必要なログだけを保存して管理するのが運用としては正解です。また、セキュリティ製品やSIEM用に提供されている検知ルールの中には重複するものや、さほど重要でないものも多く含まれています。不要なログの転送・保存を止めたり、重要でないアラートを停止することを恐れないでください。

また、運用が始まった後にも社内システムの構成や周囲の環境は変化します。定期的に設定や検知ルールを棚卸ししましょう。

5. IT資産の洗い出しを優先する

どれだけセキュリティ製品やSIEMを導入していても、組織の中に保護されていないIT資産があればセキュリティホールとなり、その他のIT資産にも影響が及ぶ可能性があります。そのため、SIEM運用の整備よりも、組織の状況を正確に把握するための体制を整えたほうが良い場合も多いです。

情報システム部門ではなく、部署単位でIT資産の購入や管理を行っている場合には目の届いていないインフラやアプリケーションが生じがちで、組織のポリシーが適用されておらず、セキュリティホールが放置されるケースもありますので注意しましょう。特にインターネットを通じて外部から接続できる資産には気を付けてください。

まとめ

SIEMは導入して終わりではなく、導入した後の運用が重要です。上記を参考に、ぜひ自組織のSIEM運用について見直してみてください。

ここまで読まれて、SIEMの導入や運用について難しいと思われた方もいらっしゃるかもしれません。実際、SIEMを正しく運用するためには経験や技術が必要になることが多いため、社内リソースが不足している場合は外部に委託するのも1つの手です。

セキュアイノベーションではSplunk、SentinelといったSIEMの検知ルールの作成やダッシュボード構築、運用のご相談を承っております。弊社のプライベートSOCサービスは、お客様の環境内でセキュリティ運用を行うマネージドサービスですので、環境構築から初期のチューニング、一定期間の運用までを行い、その後の環境をお客様ご自身で運用していただくといった使い方も可能です。

SIEMの構築や運用についてお困りごとがございましたら、ぜひ弊社までご相談をいただければと存じます。

Q&A

Q. SIEMの誤検知（False Positive）が多いのはなぜですか？

A. 検知ルールが汎用的で、自社環境へのカスタマイズが不足しているからと考えられます。

Q. アラートのチューニングが進まない原因は？

A. 作業の優先順位が低いこと、高い技術・知識に加えて自社環境や製品への理解が求められるため属人化しやすい点があると思われます。

Q. 外部に委託してもなかなか改善されないのはなぜ？

A. アウトソース先に環境についての情報が提供されていない場合や、アウトソース先の技術不足、契約にチューニングが含まれていない、担当者間のコミュニケーション不足などが考えられます。

Q. 人材不足による運用負荷やアラート疲れの問題の解決にはどうしたらいい？

A. セキュリティ製品やSOARの自動化機能を活用することが大切です。また、重要でないアラートの監視を止めるなど運用を工夫するのも有効です。

Q. SIEM製品によって運用負荷に差はあるのか？

A. 断言はできませんが、多くの場合、運用負荷の大きさはSIEM製品の種類や機能ではなく、設定や運用計画に依存しています。運用の前提が変わらないと仮定した場合、正しい形で運用を続けることで時間と共に運用負荷は低減していくはずです。