侵害検出時間の短縮：ログデータの可用性

再びこんにちは！以前の記事で 、私たちは、仮想もしくは本格的なSOCを構築する際、多くのことが手に負えなくなる可能性があることを既に認識しました。特に、SIEMをあらゆるSOCの中心技術として運用する際にはそうです。また、自動化が進むべき道であると確立しました 現代の脅威とSIEMおよびSOC技術がもたらすオーバーヘッドに追いつきたいならば。 今日は、それぞれのSIEM展開と運用要素を分析し始めます。最初に浮かぶのはデータの可用性です。侵害検出時間に影響を与える要因は多く、2015年の時点でも平均で200日を超えていましたが、これはSIEMが侵害検出の選択技術であるからではありません。SIEMは受け取った入力に基づく出力を提供することしかできません。入力で何かを見逃してしまえば、出力が完全でないことを期待すべきではなく、時には出力がまったく得られないこともあります。 SIEMのせいでログ（とインシデント）が見逃されるのでしょうか？まあ、これもまた多くの要因に依存します。この混乱を解消し、SIEMを継続的に運用するために、管理/保守を担当する人物（あなたの会社にはいますよね？）は、あらゆる時点で、以下の2つの質問に答えるための十分な情報を持つ必要があります。「スコープ内のすべてのログデータが収集されていますか？」そして、答えがNOならば、「問題はSIEM側かそれ以外の部分か？」もし最初の質問への答えがNOならば、インシデント検出時間と精度に直接影響を与える重要なことを見逃していると確信できます。そして事実、これに標準回答するSIEMソリューションは存在せず、これに答えるためには常に手動の努力が必要です。 SIEMが「あなたのネットワークログデータの可用性は85%です」と言ったのを見たことがありますか？私は見たことがありません。しかし、我々にはまだ二つ目の質問がありますが、それすらも系統的に回答されることはありません。第一に答えられないから当然です。ですが、すべてが失われたわけではなく、十分な 調査 を行ったり、手動で求めて十分な時間と労力を費やしたりするならば、そこには答えが存在するのです。 いくつかの例を考えてみましょうログデータの収集方法に基づき、最も一般的なログ収集メカニズムである syslog から始めます。syslogを全く使用しないSIEM実装は考えにくいです。データを失う方法は多々あります：パイプ収集法のデーモンは収集コンポーネントが停止するとデータを失います。UDP（デフォルト）のsyslogプロトコルはパケット配信の保証がありませんし、syslogトラフィックの高容量（UDPとTCPの両方）はバッファサイズ制限や帯域幅制限、さらには特定のNICのパケット処理速度仕様に障害を受ける可能性があります。ログデータをファイルから読み取る場合ですら、ファイルの回転と整合性を考慮しなければなりません。これらの問題の診断は、SIEMコンポーネント自体の診断ログを読むことを伴う手動の定期作業が常です。診断データを持っているのであればの話ですが！最も醜い診断データでも何もないよりは良いですし、「我々のSIEMは魔法のようでエラーが全くない」と言い訳するよりは安価です。次には、ログフロー量と偏差をベースラインとする相関コンテンツを作成（もしくは再利用？）し、TCPdumpを実行してパケットドロップ率をチェックし、外部ソースを通じてコンポーネントの可用性を監視します…ちょっと待ってください、SIEM自身を監視するために追加する必要があるツールが少なくとも3つ出てきました。「私のネットワークログデータの可用性は何％ですか？」という簡単な質問に答えるためだけです。自動化への具体的な試みに話を戻すと、例えばSplunk on Splunk、これらは本当に効率的ですか？SIEM/ログ管理プラットフォームの自己診断を可能にするために追加するライセンスコストはどれくらいかかるのでしょうか？この最も人気のあるアプリケーションが生み出す性能への過剰な負荷はどれくらいでしょうか？では、数分だけsyslogとSplunkを脇に置き、次に最も人気のあるログソースである Microsoft Windowsイベントログのことを考えましょう。問題を簡潔に保つために言いますが：ログの回転、ネットワーク帯域幅、認証エラー/パスワードロックアウト、WMIとJCIFSの不安定性、高負荷のWindowsサーバー（ファイル監査、Active Directoryなど）などです。これを監視するためには、もう一セットのツールが必要で、そのツールはsyslog監視ツールと比較すると異なります！データベース、ファイアウォール/ngfw/ips/ngips/utm（OPSEC＆SDEEにご挨拶）を含む長いリストを続けることができ、その中でSIEMの影響を受けずに起こるが知っておくべきことをさらに多く発見するでしょう。そして、それは管理者に迅速かつ正確に情報を提供する必要があります。それでも、ここまで読んでいただいた方には良いニュースがあります。SIEM（またはほとんどのSIEM）自体には（ほぼ）読みやすい診断ログがあります。発見が難しい診断ファイルや、隠されたAPI呼び出し、多行のJavaスタックトレースには、上記の多くの問題に対する回答を提供することができる情報のビットやバイトが含まれています。それらを組み合わせて ここ 意味のあるプロファイリングメトリックを適用することによって、ミッション・クリティカルなセキュリティ検出プラットフォームが意図した通りに動作しているか、問題を無視するか、追加のリソースに問題を投げることによって半分修正しているかの違いを示す2つの簡単な質問に答えることができます。プロジェクトで計画された組織/顧客に求められたログデータの可用性を保証したいすべての人のために、自動化がここにありますし、彼らはSIEM投資の適切なリターンを得ることができます。この情報が考える種を提供することを望みます。お楽しみに！

p.s.　HPE ArcSightの専門家である場合、さらに良い知らせがあります！SIEMプラットフォームが価値を提供し、SIEMの専門家の世界中の時間を節約するためのグローバルな取り組みとして、SOC Primeはオンラインで即座に利用できる無料のSIEMヘルスチェックサービスを提供しており、エージェントログファイルを分析して、トップ5の重大な問題とその解決策を5分以内に提供します。エージェントログはありますか？ に投げてみてください！。 and see for yourself!