読者です 読者をやめる 読者になる 読者になる

内角540°

セキュリティ。SIEMとかIPSとか統計とかクラウドとか。数学以外で。

SIEM相関ルール成熟までのプロセス

Gartnerさんに掲載された記事。
問題は何か、明確にすることが大前提であり、
SIEMやSIEMによる相関ルールが目的にはならないことを強く推している。

SIEM Use Case Implementation and Tuning Process
blogs.gartner.com

1.問題の明確化

Define a particular problem to be solved by a SIEM tool in clear, unambiguous terms.

SIEMによって解決されるべき問題を明確に定義する。

2.SIEMの機能確認

Review the SIEM functionality (rules, algorithms, reports and dashboards) that is needed to solve the problem.

定義した問題を解決するために必要なSIEM機能を確認する。
(検知ルール、アルゴリズム、レポート、およびダッシュボード)

3.SIEMに与えられる情報は何か

Look at the available and potentially available log data that is useful for solving the problem.

問題を解決するために役立つログを確認する。

4.情報がSIEM上でどのように現れるか

If a correlation rule is the chosen piece of content to be created, analyze what sequence of logged events needs to be tracked and how these events are represented in a SIEM tool; using normalized events and taxonomy categories is highly recommended because they make the rule easier to modify, maintain and apply to additional log sources.

相関ルールが、一部のログを抜粋して作られる場合(?)、
イベントを"どのような序列で追跡できるか"、"SIEM上でどのように現れるか"を分析する。
正規化と分類を活用することで、ルールの修正・維持・ログの追加が容易になる。

5.検出ロジックの裏付け

If using a statistical detection method, review its logic to confirm that it will deliver the result needed.

統計的な検出をする場合、期待された結果が求められるかロジックの裏付けを確認する。

6.ロジックの確認

Draft correlation rules on paper, and review the logic flow.

紙に相関ルールを書き、ロジックを確認します。

7.相関ルールの実装

Implement the correlation rule using the SIEM rule interface; some products allow one to click on events and define a rule straight from the observed sequence of events.

SIEM上で相関ルールを実装する。
一部の製品では、観測されたイベントをクリックすることで、ルールを直接記述できる。

8.相関ルール発火の頻度を確認

If a product has functionality to test the rule or algorithm on historical data, execute this functionality to determine how often this rule would have fired in the past if it had been enabled.

SIEMにヒストリカル分析ができる機能があれば活用し、
アラートの発生頻度を確認する。

9.アラートの設定

Review any alerting process that this rule will trigger, and set up alerts to go to the people who know how to triage them.

相関ルールのアラートを設定し、対処できる人へ通知する。

10.運用環境へのデプロイ

Enable the rule to run on real-time data flow in the production environment.

運用環境でルールを適用する。

11.修正・改善

Review alerts generated by this rule, review the cases where the rule matches partially (if the SIEM product has such functionality) and refine when the rule is needed.

生成されたアラートを確認し、必要に応じて修正する。
どの部分がマッチしたか確認できる場合、活用する。

SIEMの活用と成熟過程(SIEM Use Cases and Process Maturity)

McAfeeに掲載されたGrant Babbさんの"SIEMの活用"に関する記事。
とても良い記事でした(・o・)


SIEM Use Cases and Process Maturity
https://community.mcafee.com/community/business/siem/blog/2012/12/24/siem-use-cases-and-process-maturity--the-plays-to-run

SIEM、4つのユースケース

I like to think of all the use cases that a SIEM performs as standing in four groups:

1.Log Management - get the events generated on your network flowing through SIEM and keep that pipeline operating smoothly
2.Threat and Risk Correlation - add intelligence to the event flow by attaching context or combining simple events into more complex ones
3.Incident Response - now that you know something is happening, you have to do something about it
4.Compliance - providing the necessary detail on security attributes to measure and report it to regulatory bodies

https://community.mcafee.com/servlet/JiveServlet/downloadImage/38-4541-37622/620-102/SIEM_use_cases.png

SIEMが行う4つのユースケースは以下の通り。

1. ログ管理
ネットワーク上のイベントをSIEMから"扱いやすい形"で取得できる。
2. 脅威やリスクの相関
属性追加や、イベント同士の相関により、インテリジェンスを付与する。
3. インシデント対応
発生した事象を把握し、対応する。
4. コンプライアンス
詳細を調査し、組織に報告する。

このプロセスは守らないと不十分/非効率な対応となる。
例えば、[2. 脅威やリスクの相関]を行わず、[3. インシデント対応]を行うことはNGである。
ログ管理は、データがあることを保証するだけ。

適切でないSIEMの運用

How do you know you ran this play? You might answer "yes" to one of these statements:
"my company only uses the correlation rules that shipped with the product"
"we don't use correlation rules to manage events, only alarms"
"we had to disable those devices because they were sending too many events"

「最初から入っていた相関ルールのみ使用している」
「相関ルールをイベント管理のためでなく、アラートのためだけに使用している」
「イベントが多すぎるので、いくつかの機器のイベント収集を無効にしている」

こんなユーザは要注意。
脅威やリスクの観点が全く考えられていないからである。

相関分析の本質はイベントの価値向上

Besides "catching the bad guy" (one I don't agree with, BTW), threat and risk correlation serves the purpose of helping you shape events to only tell you what you really care about. It's more than just a filter, it's a way to focus information, add context, and increase the ROI of your security data

相関分析の用途は、悪意のあるイベントの捕捉ではない。
本質は、注意したい事象に焦点を当てることである。
それはただのフィルターではなく、属性追加による情報の価値を高めるものである。

目的は、適切な過程を潤滑に踏めるようにすること

My Pick for Play to Run

I think the best thing to do for a company building a SIEM process is to follow the four use cases in the expected order: Log Management, Threat and Risk Correlation, Incident Response, Compliance. I do NOT think it should be done in a waterfall fashion: get ALL the logs in the SIEM, then do ALL your correlation rules, etc. You should start with a few critical data sources and take them ALL the way through the process. This gets you the true benefit of the SIEM without getting stuck at an earlier stage.

SIEM運用のベストプラクティスは、[1]-[2]-[3]-[4]を順にすすめることができること。
フローの潤滑に実施するためのログが必要であり、全てのログを取ることが目的ではない。

SIEMの成熟

Focus on the Flow, not the End State. To run this play, you have to change the way you look at the game. We don't live in a flowchart world, processes don't have neat boxes around them and all the input doesn't magically show up at the step where it needs to be. To me, all the logs in the SIEM, or all the correlation rules that are enabled, are just state. The point of getting them into that state is really just to get them somewhere else now. When you are adding data sources, think about what correlation rules this could generate; when you create a correlation rule, think about how efficient you can make the incident response on this. All of the SIEM use cases fit into a process flow, whose purpose is to tell your company what you want to know about the security data you are generating. If you focus on the flow, not these end states, you aren't walking or crawling, you're runnning.

注視すべきは、結論ではなく経過。

フローチャートのような世界ではないので、情報は必ずしも決まりきった流れで現れない。
あらゆるイベントログや、SIEMによる相関イベントログは、一つの状態を明らかにするけであり、
求められる情報は、その外である。

ログソースを追加する際は、
どのような相関ルールが作れるか、それによりインシデント対応をどのように効率的に行えるかを考えること。

SIEMは、"会社が求めている情報を提供すること"が目的です。
結果ではなく過程に注視すれば、その目的達成に近づける。その結果SIEMが成熟したといえる。

SIEMの使用例(Popular SIEM Starter Use Cases)

SIEMユースケースに関する記事。貴重。

参考:
blogs.gartner.com

1.認証を追跡し、アカウント侵害を検出

1.Authentication tracking and account compromise detection; admin and user tracking [this is the very use case that I detail in that post]

ActiveDirectoryやProxy、アプリケーションログから、
ユーザに不審な振る舞いがないか追跡する。

「同一ユーザ名で、複数のIPから認証」などですかね。
被害の前後でいずれも役に立つSIEMの活用方法ですね。

2.感染端末の追跡

2.Compromised- and infected-system tracking; malware detection by using outbound firewall logs, NIPS alerts and Web proxy logs, as well as internal connectivity logs, network flows, etc

FW、IPS、Proxy、内部通信ログからなどから、マルウェア感染のシステムを発見する。

あくまでも、"不審"ということしかわからない。
確実性を高めるには、セキュリティデバイス側で"マルウェア"と判別してほしい。←

3.IDS/IPSアラートの脅威評価

3.Validating intrusion detection system/intrusion prevention system (IDS/IPS) alerts by using vulnerability data and other context data about the assets collected in the SIEM [while some say “this is so 2002”, this use case is still here in its modern form of using SIEM for “context-enabling” various alerts]

IDS/IPSアラートを、資産の脆弱性情報と突合させて検証する。

SIEM設定よりも、資産情報管理のほうが大変。
自動収集して、自動でSIEMに読み込まれ、自動でエンリッチしてくれる機構がほしい。

4.不審な外部との通信

4.Monitoring for suspicious outbound connectivity and data transfers by using firewall logs, Web proxy logs and network flows; detecting exfiltration and other suspicious external connectivity

FW、IPS、Proxy、内部通信ログからなどから、不審な外部との通信を監視する。
情報流出や、不審な相手との接続を検知する。

C&Cサーバへの接続や、大きなサイズのアップロードを監視。
いずれも、感染後のアクティビティですね。

5.ポリシ違反の検出

5.Tracking system changes and other administrative actions across internal systems and matching them to allowed policy; detecting violations of various internal policies, etc [and, yes, even the classic “root access from an unknown IP in a foreign country at 3AM, leading to system changes” sits here as well]

様々な社内ポリシ違反の検出する。
・申請のない管理者権限の使用
・海外から午前3時に、root権限でアクセス

外からの脅威だけでなく、
内部の脅威を検知することは、SIEMの大きな役割ですね。
ProxyログをExcelで確認する時代は終わりました。

6.Webアプリケーションへの脅威検出

6.Tracking of Web application attacks and their consequences by using Web server, WAF and application server logs; detecting attempts to compromise and abuse web applications by combining logs from different components.

Webサーバや、WAF、アプリケーションのログから、Webアプリケーションの脅威を検出する。

ここに来てやっと、相関分析ならではな観点が。
WAFポリシを作り込むほうが強度は高そうですが、
WAF管理者と、SIEM管理者が同じとは限らないので…(そもそもWAFがないかも?)

さいごに

SIEMで期待される相関分析。
本当の意味で"相関"させるルールを導入し、活用するのは
海外のユースケースを見ても難しそう。

まだまだ単発イベントでアラートか、
人間がログ確認する補助ツールとしての活躍が主だと思う。