White Paper SOC（セキュリティオペレーションセンター）運用は どんな業務で成り立っているのか ? 監視以外にもある重要なミッション White Paper 目次 まえがき . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 はじめに ∼監視をだれが行うか∼ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 SOC 担当者のミッション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 分析手法の開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 リスク分析結果の考え方 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 発見的統制の実現 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 分析手法の開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 ログの分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 定点観測の重要性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 異常を捉えるポイント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 ログ分析に必要なスキルとは？ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 SOC に関連する組織 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 報告 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 SOC は組織の重要なセンサー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 定例報告の頻度 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 報告の場は改善の場 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 まとめ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 分析手法の具体的な開発例（1） 画面のカスタマイズ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 分析手法の具体的な開発例（2） 検知ルールのチューニング 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 分析手法の具体的な開発例（3） 検知ルールのチューニング 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 分析手法の具体的な開発例（4） パーサーの改良 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 SOC（セキュリティオペレーションセンター）運用はどんな業務で成り立っているのか ? 2 White Paper まえがき 「SOC（Security Operation Center）」という言葉が、セキュリティの業務に携わる以外の方々からも聞かれるように なってきました。言葉は広がってきて認知度はあがっていきていることは実感するのですが、では SOC で何をしている のか？という点についてはあまり知られていないように感じます。SOC 従事者が多く受ける質問の一つに、平常時につい て「インシデント発生中以外は何をしているのですか？」という質問があります。多分「モニターを眺めているのだろう」と か、 「電話を待っているのだろう」というイメージでしょうか。テレビのニュースとかで見たことのある、警察や消防の指令 室みたいなものや、ちょっと見かけたことがあるビルの監視（管理人）室を想像しているかもしれません。 組織により多少の違いはあると思いますが、現場経験者は「SOC はインシデントの発生や、その予兆を見つけると言う使 命の元、ログの分析や分析手法の開発、分析結果の報告を行う他、インシデント発生時には CSIRT（Computer Security Incident Response Team）の支援を行う。」と表現する人もいます。 このドキュメントでは、SOC の第一線で活躍しているマカフィーのエキスパートの経験に基づき、SOC 担当者のミッ ション、分析手法の開発、ログの分析、報告といった活動の一部を紹介します。SOC に関わる人たちの日々の活動につ いて少しでも具体的なイメージを持っていただければと思います。 はじめに ∼監視をだれが行うか∼ まず、SOC の細かい話をする前に、SOC の組織形態＝監視をだれが行うのか、から考えていきましょう。SOC の相談で 多いのが監視要員を社内の人員で賄うべきか、外部サービス（MSS（Managed Security Service））を利用すべきか という事です。これまで MSS、組織内の人員による SOC 運用の双方に携わり利用してきた経験から、重要なポイントに 的をしぼって考えてみました。 スキル・リソース カバレージ可能な範囲 対応スピード 精度 MSS 企業内SOC 備考 ★★ ★ 社内でSOCを構築する場合、人材の確保とスキルの向上は重要な要素。 人材の確保ができずSOCをローンチできない事例も。 MSSであれば初めから高度なスキルをもった人材によるサービスが望める。 ★ ★★ MSSである場合、監視が可能な機器や監視対象装置が限定されるケースも。 内部のSOCであれば柔軟に対応が可能（ただし対応可能とするスキルの開発 は必須）。 ★★ ★★ インシデントやその予兆を見つけて通報のスピードに差異はない（と考えます）。 ★ ★★ 保護対象組織の資産の詳細の把握は精度の向上に重要。 内部SOCが圧倒的に有利。 比較をすると、企業内 SOC の方が優位な点が多い事がわかります。しかし、それらメリットに該当する点について、生か すも殺すもスキル・リソースに依存することも一つの事実であり、最も重要な要素であると考えます。SOC のローンチを 考えられる場合、当たり前かもしれませんが、優位な点を考えるだけでなく、それを生かすスキル・リソースという面につ いて考慮した上で MSS を利用するか、企業内 SOC とするのか、決定をしてください。 また、コスト面も重要なポイントです。MSS のサービス内容、自社リソース費用など条件により異なりますが、どのよう な体制を採用するか判断する前に自社リソース費用や対応可能レベルを想定した上で、いくつかの MSS の説明を聞いて みることをお勧めします。 本稿では SOC の組織形態に関わらず、SOC の現場の運用に関わる技術等の一部についてご紹介をします。SOC とは 何か？をイメージされていない方、これから SOC のローンチを考えられている方を特に対象として、イメージを持ってい ただけたらと思います。 SOC（セキュリティオペレーションセンター）運用はどんな業務で成り立っているのか ? 3 White Paper SOC 担当者のミッション 状況把握のためにモニターを眺めている印象が強いかもしれませんが、実際にはモニターを眺めている以上に時間を費 やしている業務が多々あります。モニターを眺めている印象が強いのはテレビや写真で「臨場感 れる」イメージの需要 が多いためでしょうか？ さすがにコーヒーを飲んでいるところとか、外の景色を見ながら考え事をしている映像では（たとえ重要な場面であって も）不採用となるのでしょう。はたまた Web ブラウジングをしている様子も（情報収集のためには重要な業務なのですが） ネットサーフィンをしているだけと、誤解を生む事になるので、こちらも画的に不採用かと思います。SOC の通常業務と して実際に取り組んでいる活動は以下のようなものです。 1. 業務の効率化 更に分析能力（深度、精度、スピード）を高めるための活動 – 分析手法の開発 ■ 新たな攻撃や脆弱性に対する情報の分析、検出手法の開発 ■ 分析手法の定型化 – 評価方針の決定 2. 調査（ログの分析） – リアルタイム分析 – 定点観測 3. 報告（臨時、定例） – 報告と CSIRT 支援 SOC の業務における PDCA イメージ これらの活動を PDCA（Plan Do Check Action）のスパイラルでイメージしたものが上図になります。次章以降は SOC の活動をこの「SOC における PDCA」の詳細を個々の活動を順を追って紹介する事によって、SOC が何をしてい るのか、説明していきたいと思います。 SOC（セキュリティオペレーションセンター）運用はどんな業務で成り立っているのか ? 4 White Paper 分析手法の開発 まず、はじめにリスク分析の結果について考えてみます。リスク分析では想定される脅威に対して、どのような対策がな されていて、どの程度リスクを低減できているのか、または脅威に対して対策がなされていない、または十分ではない ことを明らかにします。これは SOC において重要なインプットとなります。リスク分析は通常、残留リスクに対して「回避」 「転嫁」 「軽減」 「受容」を考慮しますが、可能な限り「軽減」を図るシナリオとなるケースが多いと考えます。 リスク分析結果の考え方 リスク分析を改めて考えてみましょう。前提となる目的を以下のように定義しています。 ■ ■ 定義された脅威に対して、どの対策でリスクの低減化が図れるのか、明らかにする。 定義された脅威と脅威に対する対策によりリスクの低減化が図られても、なおも残るリスク（残留リスク） を明らかにする。 さらにリスク分析とリスクコントロールの概念については下図にイメージをまとめてみました リスクコントロールの概念図 予防的統制はセキュリティ対策製品等の検知・動作ログを監視することである程度の対応は可能です。しかし、予防的 統制を潜り抜けた攻撃については予防的統制における対策以上に発見が難しくなります。これらが一般的には残留リス クになります。SOC では予防的統制と発見的統制、双方に対応することが求められている、そのように理解する必要が あるのではないかと考えます。従って、分析手法開発に当たっての課題は以下となります。 「残留リスクへの対策＝発見的統制に対してどのように対応するのか？」 発見的統制の実現 発見的統制の実現に向けて一つ、以下のようなログはブラック（＝問題あり）、グレー（＝問題がある可能性）、ホワイト（＝ 問題なし）のいずれに分類されるべきか考えてみていただきたいと思います。 技術に詳しい方であれば①、②、⑥をブラックと判断されるかもしれません。④はグレーと判断されるかもしれません。③、 ⑤はホワイトとするかもしれません。 正解は全てブラックです。ブラックと判断するのは極端かもしれません。しかし、ログが出ているという事は確実に何ら かの動きがあることを示しています。従って、基本的にすべて「ブラック」とみなして分析する（分析対象とする）必要が あります。SOC の分析に限らずですが、発見的統制の第一歩はこの意識付けから始まります。 SOC（セキュリティオペレーションセンター）運用はどんな業務で成り立っているのか ? 5 White Paper 分析手法の開発 先に述べたように、発見的統制の実現には、膨大なログの中から、これまでホワイトとして扱い（扱っていたかもしれない）、 分析の対象にしなかったログや、ネットワークトラフィックのようなログに該当しないような情報を解析することが不可欠 です。これはすなわち、膨大な量のデータを対象とすることを意味します。 従来のログ分析のスタイルは経験豊富な 職人 による「目 grep1 ＝勘」にある程度依存し、極めて属人的だったと思いま す。しかし、最近の流れは SOC のツールとして SIM（Security Information Management）/SIEM（Security Information and Event Management）を導入して組織的かつ効率的に分析に取り組むことが主流になってきてい ると思います。SIM/SIEM はこれまでより、多種大量のログを一元的に扱うことを可能とします。また、検知ルール（相 関ルールとも呼びます）の作成機能により、 ログ分析職人 に内在していた分析のノウハウ＝暗黙知の表出化、連結化を 実現し、組織の知として再利用を可能としました。 このような状況の変化もあり、SOC メンバーの大切な業務として、検知能力を最大化しつつ負担軽減を実現するために、 様々な情報ソースをもとに、発見的統制の実現に向けた検知ルールの作成とチューニングを行うことが求められます。 検知ルールの開発の例には以下のようなものがあります。 ■ SIM/SIEM の相関分析ルールの開発 ■ IPS/IDS の独自シグネチャの開発 ■ 独自ブラックリストの開発 大量のログを捌く仕組み作りに必要なスキルとして正規表現の理解が挙げられます。上記の開発をするためにログの文 字列を効率よく検索したり、法則性を確認したりする必要があるので、正規表現を理解している事は重要だと思います。 ただし、SIM/SIEM の相関分析ルールの開発については（正規表現に関する知識を無視するわけにいきませんが）SIEM グラフィカルなルール作成ツールが用意されていたり、分析済の統計的な傾向データを条件に使用できるなどルール開 発の敷居は低くなりつつあると思います。 （例）SIEM 相関分析ルール開発画面 1. Grep：Unix 系 OS で使用する文字列検索コマンド 本ドキュメントの最後に参考資料として分析手法の具体的な開発例を含めていますので、興味があればぜひ参考にしてく ださい。 ■ 画面のカスタマイズ ■ 検知ルールのチューニング 1、及び 2 ■ パーサーの改良 SOC（セキュリティオペレーションセンター）運用はどんな業務で成り立っているのか ? 6 White Paper ログの分析 ログの分析は SOC に求められる主要なミッションです。分析結果から得られた情報や考察を、事前に定められたセキュリ ティポリシーや対応フローを基として対応を行います。 NOC: Network Operation Center ログの分析は大きく二つの観点で行います。一つ目はリアルタイム分析、二つ目は定点観測になります。リアルタイム分 析はルールやシグネチャの条件に合致した結果、発報されたアラートを発報時点で即座に分析する手法です。一般的には こちらの分析をイメージされる方が多いのではないでしょうか？。もう一つが定点観測による分析手法です。 定点観測の重要性 検知ルールや機器のアラートをトリガーとして詳細の分析以外に、ログの量や推移をもととした分析、定点観測もインシ デントの予兆を知る上で重要な分析手法です。リアルタイムで見つけられない＝定義されていない振舞いを見つけるため にも、定点観測を意識した分析を常に心がけます。 異常を捉えるポイント 異常やスパイクを捉えるために非常に重要なことがあります。それは正常や通常の状態を知っていなければ異常やスパイ クという状況を把握できないということです。このことからも定期的に定点観測を行うことが重要です。異常に目を向け つつも、正常な状態を把握するという気持ちで正常時の特徴を捉えておくことが重要です。正常の特徴が把握できれば、 異常を検出するルールも記述できるようになる可能性が高くなります。 先ほど画面のカスタマイズの例がありましたが、異常かも？と思った時は、しばらく限定的なログの推移を一定期間（いつ もより短い周期で）確認するための画面を作成することもできます。一定期間特定目的の画面を作り、定期的にレポート を出力して見比べることで異常の特徴に気づきやすくなります。SIEM にはログの出力の推移を分析、そのログのベース ラインとの比較を簡単に行う事ができる機能があります（上図）。このような機能を活用することで、システムの異常の検 知を迅速にかつビジュアルで確認することが実現可能になります。 また、システムの活動が極めて安定しているような時間帯に目を向けるのも一つの方法です。セキュリティ対応の例でも 就業時間外のログに目を向けると異常を見つけやすくなることが書かれている例もあります。日本では（おそらく海外よ り）日常的に残業をするため業務規則に書かれている就業時間より、実際にほとんどの従業員が退社する以降の時間帯の ログに注目すると、不審なアクティビティが見つかるかもしれません。 ログ分析に必要なスキルとは？ ここまで、ログの分析手法について書きましたが、個々のアラートに対して求められる分析スキルについては言及しません でした。SOC をローンチするにあたり、要員のスキルについて考え方をどう持ったらよいのか、よく質問されます。この 質問に対する正解はない、と考えています。個々のアラートに対して、様々なアプローチがあり、すべてを網羅すること は難しいとも考えています。 SOC（セキュリティオペレーションセンター）運用はどんな業務で成り立っているのか ? 7 White Paper その上で、やや抽象的になってしまいますが、二つ、分析に求められるスキルがあると思います。一つは正しい状態を知 る事、二つはログが出力された原因を探求する事です。特に二つ目にあげた、ログが出力された原因を探求することは、 分析における姿勢として求められる重要な事だと考えています。私はこれを「風が吹けば桶屋が かる」 （Butterfly Effect）をたとえに説明をします。一見因果関係がないように思えるイベントであっても影響を及ぼしあっているかもし れない、そのように考えて、ログの詳細を調べる姿勢が、必要なスキルと言えるのではないか、と考えています。 SOC に関連する組織 先にログの分析において、SOC 以外の組織として CSIRT や NOC について図の中で示しました。SOC に関係する組織 としては、CSIRT と NOC の存在は欠くことができないと考えます。SOC、NOC、CSIRT がお互い、どのような関係で あるべきか、SOC を導入するに当たり、大きな課題になります。以下はこれらの組織の関連図の例です。 SOC、NOC、CSIRT の関係性については、SOC の設計において必ず言及されるポイントと考えます。SOC について は一つ意識していただきたい点があります。それは SOC は運用のチームの一つであることです。SOC は組織のセキュ リティに関するセンサーの役割を果たし、NOC と協同で組織のシステム運用を行っていくという意識は持っていただきた い、そして、決して NOC と SOC は対立する組織ではない、ということを理解していただきたいと思います。 SOC（セキュリティオペレーションセンター）運用はどんな業務で成り立っているのか ? 8 White Paper 報告 「報告」は SOC にお SOC の業務における PDCA イメージ、最後のステップとなる報告について説明したいと思います。 ける重要な業務です。組織内にどのような問題となるイベントが発生していて、問題のステータスはどうなっているのか を関係者に明らかにして、問題を共有する事が「報告」のミッションになります。 SOC は組織の重要なセンサー 報告と言えば形式的なものが多いと感じる人も多いと思いますが、 「SOC は組織のセキュリティに関するセンサー」であ る事を踏まえ、その重要性を認識してもらうためにも、正常時、問題発生時に関わらず解りやすく情報共有する必要があ ります。 報告は大きく分けて「臨時」と「定例」があります。臨時と定例の目的と内容は大きく異なります。定例報告と臨時報告の 考え方について、下図をご参考にしてください。 ■ 定例報告（日時報告、週次報告、月次報告） 基本的に固定メンバーでセキュリティ運用に関係する部門と管理者が対象 ■ 臨時報告 上記に加え報告内容に関連する部門が加わる 定例報告の頻度 定例報告の頻度については全ての組織にも当てはまる最適な頻度は無いと考えています。ここでは、報告のタイミング の例、特に考え方について紹介します。 定例報告のタイミングとして、大手ソフトウェアメーカーがパッチをリリースする第 2 または第 3 水曜日から 1 週間後程度 を目安としているケースが多くあります。 これは①パッチリリース直後に攻撃が発生する可能性が高い、②パッチ適用までのタイムラグ（攻撃が成立して検知する 可能性が高い）、③チューニング作業の進行状況、といった事を報告（最終的には安全宣言）する必要性から、このタイミン グがベターとして採用するケースが多いです。 SOC（セキュリティオペレーションセンター）運用はどんな業務で成り立っているのか ? 9 White Paper 報告の場は改善の場 報告の場は単にイベントの報告の場で終わるのは望ましくありません。組織防衛の現状を関係者全員で把握すると共に、 より正確に、最新の脅威や残存するリスクに対する脅威を認識し、脅威検知する為の施策の議論の場＝セキュリティ向上 の場とするのが望ましい活用方法です。 まとめ このドキュメントでは、 「インシデント対応中以外は何をしているのか？」というテーマで SOC メンバーとしての主な活動を 紹介しました。単にモニターを眺めているだけでは無く、日々の主要業務である分析手法の開発、ログの分析、報告をテー マに実際の現場の作業の一部を紹介しました。 SOC の一つのテーマとして限られたリソース（人材、時間、資金）で、可能な限り効率的な作業をしていく事が常に求めら れますので、定常や一次対応をどのようにしたら自動化できるのか？、新しい脅威に対抗するために日々の状況把握と詳細 な調査、組織のセンサーとしての状況共有と改善などに日々勤しんでます。 プロセス、テクノロジーが交差する常に刺激的な環境です。 （一見モニターを眺めているように見えて）SOC 運用業務は人、 マカフィープロフェッショナルサービスについて お客様が抱えるセキュリティ課題に対して専門的なアプローチを展開し、戦略から製品導入、運用支援まで、幅広くかつ 一貫したサービスを提供します。担当するセキュリティコンサルタントは、主にコンサルティングファーム、セキュリティ ベンダー、SI ベン ダーなど、多様なバックグラウンドの出身者で構成され、中央省庁や大手通信キャリアのような、日本 社会におけるセキュリティの中核・最先端と言える極めてシビアな現場で活躍しています。 SOC（セキュリティオペレーションセンター）運用はどんな業務で成り立っているのか ? 10 White Paper 参考資料 分析手法の具体的な開発例（1） 画面のカスタマイズ 分析に使用する画面のカスタマイズです。デフォルトで用意されている画面をログ分析者の分析手順を基にカスタマイズ した例を以下で紹介します。 ログの分析手順に応じた遷移（画面）をあらかじめ用意する事で、分析の効率は著しく向上します。最適な画面構成は実 際のケースを想定して手順を書きだしたものを基に分析画面を構成したり、実際に分析を行った際に使用した画面を保存 する事で構成を行います。分析手順を基とした画面のカスタマイズは分析作業の効率化に著しく貢献します。 最近の SIEM は画面のカスタマイズが簡単にでき、作業のしやすい画面を用意するのに特別なプログラミング等の知識 なしにドラック &ドロップ等で簡単に作成できます。例えばマカフィーの SIEM は表示形式（グラフ、リスト、メーターなど） の選択、対象データソース（もしくはグループの）選択、必要であればその他の条件設定というシンプルなステップでコン ポーネントを追加することができます。更に、作成した画面からのドリスダウンや表示方法の変更など運用で必要になる 操作も自動的に付加されます。 ④ホストスキャン及びポートスキャンとして認識 ⇒詳細調査に進む（２次調査のトリガー） ③攻撃元IPを軸として動向を調査 （複数のサーバがターゲットと認識） 2次調査 IPS/IDSの検知ログとの突合を実施 攻撃成功の可否を調査 ①攻撃元地理情報から イベント分布 ②イベント件数が多い時間帯の 攻撃元IPを特定 SOC（セキュリティオペレーションセンター）運用はどんな業務で成り立っているのか ? 11 White Paper 分析手法の具体的な開発例（2） 検知ルールのチューニング 1 SIEM、IPS（≒シグネチャを持つ製品）の検知ルールの最適化を図り、FalsePositive（偽陽性：過検知、誤検知）/ FalseNegative（偽陰性）の発生の軽減化を図る事も、SOC の業務として重要です。チューニングには、検知ルールの 最適化や、検知精度向上を目的とした条件の追加・調整などがあります。 ここでは単位時間当たりの対象ログの発生量の調整や、条件に一致する範囲を限定、もしくは広げたりするための条件の 追加例を紹介します。 例えば下の図のような BruteForce の結果、攻撃が成功したと考えられるパターンを考えてみましょう。 ①複数回ログインに失敗 ↓ ②ログインに成功 || BruteForce成功？ このパターンの場合、短時間に多数検知しているものの、分析の結果、FalsePositive であると判断された場合、 FalsePositive の条件に合致するものを除外することが検討可能です。例えば送信元が信頼できる場合はその送信元を 除外することができます。また、しきい値が低いため過検知となっているのかもしれません（BruteForce の場合、そう 言った条件となるケースは少ないかもしれませんが）。 この抽出条件を分析者の勘に頼る事は難しい場合があります。理由は組織や環境により傾向の違いがあるからです。そん な時は、異なるしきい値で数回試してみて、最も効果的な値を探すようにします。マカフィーの SIEM の場合、ルールを 編集するためのグラフィカルなインタフェースが用意されているので、条件の追加も下記のような画面上の操作で実行す る事ができます。 SOC（セキュリティオペレーションセンター）運用はどんな業務で成り立っているのか ? 12 White Paper 分析手法の具体的な開発例（3） 検知ルールのチューニング 2 ログのパーサー（構文解析エンジン）の最適化について紹介します。特にインシデント発生時には範囲及び状況の的確か つ最短時間での把握が最重要課題となるため、ログの高速検索＝高効率化を目的とした最適化を進める事は必要不可欠 です。以下にメールのログを例とした改善の一例をあげてみましょう。 パーサー改善前は以下のような構文解析（下線部を色別に解析）としています。 メールセキュリティシステム側のログは info@malicious.com からのメールの添付ファイルをマルウェアの検知 （Category=Malware.arch）と検知されている事を示しています。SOC の分析ではまずはこのログを基に同様の送 信元からマルウェアを添付したメールがメールセキュリティシステムをすり抜けて（FalseNegative が発生）いないか、 分析を試みます。その際、検索の軸として、①同じの送信元アドレス、または②同じドメインから送られてきているのでは ないか、と仮説を建てたうえで分析を試みます。①であれば送信元の完全一致で検索は可能です。しかし②を検索する 場合、部分一致となるため、非効率＝ SIEM に負荷を与える事となり検索スピードに影響（遅くなる）が出る事となります。 また、検知ルールを作成する際も条件が限定的になることが考えられます。 パーサー改善後（下線部を色別に解析）の構文解析の結果は以下となります。 この改善により、ドメイン名での絞り込みが可能となり info@malicious.com からのメールを不審として詳細分析の 対象とするだけでなく、shibuya@malicious.com も分析対象とする事でより早く判断する事が可能となります。ここ では数行のログのみ例としましたが、ログが膨大となった場合、確実に大きなスピードと精度の差となって表れてきます。 SOC（セキュリティオペレーションセンター）運用はどんな業務で成り立っているのか ? 13 White Paper 分析手法の具体的な開発例（4） パーサーの改良 あるログで取得したデータを、他のログの分析に使用するチューニングです。例えば下図のように、カテゴリーを定義し ている場合、レピュテーション技術を実装した製品のログを分析して、システムが悪意があると判断したログから他ログの 評価に使える内容を抽出、ブラックリストを構成した上で他のログの評価に 2 次利用します。 これを利用することで、例えばレピュテーション技術を持たないクライアント PC のパーソナルファイアウォールのアウト バンドの通信ログをブラックリストと突合わせる事により、インターネットと通信をするために必要なプロキシに到達でき ていないマルウェアの C&C サーバとの通信の試みを発見（マルウェアに感染しているクライアント PC の発見）すること も可能になります。ここではやや凝ったブラックリストの作成についてご紹介しましたが、一般的に SOC では独自にブラッ クリストを作成してログの評価に使います。多く SIEM では一定の条件に合致することで自動的にブラックリストを作成・ 更新をさせる事が可能な機能を持っています。SIEM の機能を生かし効率的なログの評価を実現してみてください。 SOC（セキュリティオペレーションセンター）運用はどんな業務で成り立っているのか ? 14 White Paper SOC（セキュリティオペレーションセンター）運用はどんな業務で成り立っているのか ? 15 White Paper マカフィー株式会社 www.mcafee.com/jp 東京本社 〒150-0043 東京都渋谷区道玄坂1-12-1 渋谷マークシティウエスト20F 西日本支店 〒530-0003 大阪府大阪市北区堂島2-2-2 近鉄堂島ビル18F 名古屋営業所 〒450-0002 愛知県名古屋市中村区名駅4-6-17 名古屋ビルディング13F 福岡営業所 〒810-0801 福岡県福岡市博多区中洲5-3-8 アクア博多5F TEL：03-5428-1100（代） FAX：03-5428-1480 TEL：06-6344-1511（代） FAX：06-6344-1517 TEL：052-551-6233（代） FAX：052-551-6236 TEL：092-287-9674（代） Intel および Intel のロゴは、米国およびその他の国における Intel Corporation の商標です。● McAfee、マカフィー、及び McAfee のロゴは、米国法人 McAfee, Inc. またはその関係会社の米国またはその他の国における登録商標または商標です。● 本書中のその他の登録商標及び商標はそれぞれその所有者に帰属します。©2015 McAfee, Inc. All Rights Reserved. ● 製品、サービス、サポート内容の詳細は、最寄りの代理店または弊社事業部までお問合せください。● 製品の仕様、機能は予告なく変更する場合が ありますので、ご了承ください。 MCAWP-SIEM-1504-GRP
© Copyright 2024 Paperzz
