企業ブログの一部として、情報セキュリティの分野における若い（しかし、それでも非常に明るい）イニシアチブに関する一連の記事を立ち上げたいと思います-JSOC（Jet Security Operation Center）-インシデントを監視して対応するための商業センターです。 記事では、自己宣伝を少なくして、練習にもっと注意を払うように努めます。それは、私たちの経験とサービス構築の原則です。 それにもかかわらず、これは私の最初の「ハブロ体験」であり、したがって厳密に判断しないでください。
SOC-前提条件
ロシアの大企業がSOCを必要とする理由をまったく伝えたくありません（この主題について書かれたさまざまな記事や研究が多すぎます）。 しかし、統計はまったく別の問題であり、それを覚えていないのは罪です。 たとえば、次のとおりです。
- 年間に1〜5000人の会社では、次のことが記録されます。
- 9000万のISイベント。
- 16,865件のインシデントの疑いのあるイベント。
- 109の実際の情報セキュリティインシデント。
- 2013年のISインシデントからの総損失は250億ドルに達しました。
- 大企業は少なくとも15種類の異種療法を使用しており、そのうち7を超えるログを積極的に分析してインシデントを特定していません。
これに関連するトピックに関する別の3〜4のニュースヘッドラインを追加すると、セキュリティを監視し、ISインシデントを特定および分析する必要があるという考えは、絶対に論理的で理解しやすくなります。
これに関してセキュリティの専門家は何をアドバイスしますか？ もちろん、SIEMソリューションを既存または建設中のSOCの中核にします。 これにより、いくつかの問題を一度に解決できます。
- インシデント管理の単一のコアのフレームワーク内で、他のシステムによって記録されたインシデントを独立してクローズする。
- 必要なイベントの検索、インシデントの調査、収集したデータの保存に便利なツールを入手してください。
- 特定の保護手段からの大きな間隔と大量の情報を分析することにより、統計的逸脱とゆっくりと発生するインシデントを特定します。
- 異なるシステムからのデータを比較および相関させ、その結果、インシデントを検出するためのシナリオの複雑なチェーンを構築し、一部のシステムのログの情報を他のシステムのデータで「強化」します。
少し一般的な方法論
SOCの成熟度にはいくつかのレベルがあります-SOMM（セキュリティ運用成熟度モデル）：
図 1-SOMMレベル残念ながら、ほとんどの企業は、独自のインシデント監視センターに向けて最初の一歩を踏み出し、そこで停止します。 HPの推定によると、世界のSOCの24％はレベル1に達しておらず、SOCの30％のみが基本（2）レベルに対応しています。 世界13か国（カナダ、アメリカ、中国、イギリス、ドイツ、南アフリカなど）で収集された企業の事業部門に応じたSOMMレベルの分布の統計は次のとおりです。
図 2-事業領域ごとのSOMMレベルの分布SOC社内：問題
同時に、ほとんどすべてのロシアの主要企業は、大規模なSIEMソリューションを導入する道を歩みました。 効果的なSOCを構築できましたか？ 残念ながら、ほとんどの場合はそうではありません。これまでのところ、ロシアでのSOCの発売は4回しか成功していません。
そして、原則として、独自のSOCを構築し始めると、誰もが同じ問題の3つの面に直面します。
第一に、さまざまな理由によるスタッフの定量的不足：スタッフの飢ationや専門大学の不足から、必要な能力の獲得の難しさまで。 事実、it-security部門の枠組みの中で、今日4-5人が働いており、会社のセキュリティを確保するための作業サイクル全体を実行しています（セキュリティ対策の管理から定期的なリスク分析、社内トピックの開発戦略の策定まで）。 当然、このような負荷では、SOCタスクに適切な時間を割くことはほとんど不可能です。
2番目のポイントは、内部SLAを使用して効果的な監視プロセスを構築することが不可能であることに関するものです。 SOCの立ち上げには通常、人員を割り当てる必要があることに加えて、ITセキュリティ部門にフルタイムのシフトシフトを作成し、延長された勤務日の一部として、または24時間体制で勤務する必要があります。 そして、これは2から5の新しい人員配置単位です。 同時に、人員の配置は、人事異動の絶え間ない監視（情報セキュリティの専門家が夜勤で働くことは非常にまれです）、構築プロセス、および実行される作業の内部品質管理の必要性に直接関連しています。
3番目のポイントは、発生するインシデントを処理するだけでなく、変化するインフラストラクチャや新たなセキュリティの脅威に合わせてシステムを絶えず「調整」および調整する必要性に言及する以外にありません。 また、選択したツールに関係なく、これはアナリストにとって非常に骨の折れる作業であり、常に最新の状態を保つ必要があります。 そして、純粋な分析とSOC開発に携わる人の存在は大きな贅沢です（大企業であっても）。
SOCの作成に対する現在の市場の需要を評価し、記述されたニュアンスと結び付けて、最初にアイデアを導き、次に独自の商用SOCを実際に構築しました。
プラットフォームの選択
当然のことながら、SOCを立ち上げたときに、まず「システムの中核を形成するSIEMソリューション」という質問に出くわしました。 それに応えて、作成したシステムの要件のリストを作成しました。 特に、次のことを行う必要があります。
- さまざまなリソースプール（この場合はさまざまな顧客）の蓄積データを物理的および論理的に分離し、アクセス権を分離できるようにします。
- イベント間の最も複雑なチェーンと関係を構築し、さまざまなディレクトリとイベントを使用して重要な情報でインシデントを補足できます。 同時に、すでに記述されているルールやスクリプトではなく、インシデントを検出するための独自のロジックを構築するためのフレームワークが必要でした。
- ソースシステムの方向で統合バスを記述および開発する機能を備えていること（および、ここでターゲットシステム/ディレクトリへのコネクタを書く際の最大の柔軟性が非常に重要です）および外部インシデント管理、レポート、および視覚化システムとリンクするためのAPI;
- SOCタスクを変更するための内部リソースをカスタマイズできます。 特に、ソースの監視、インシデント管理の維持とカスタマイズなどのための内部プロファイルの作成。 （ところで、これらの研究は別の記事の主題になります）。
SIEMクラスの主力製品であるHP ArcSightを選択しました（また、システムの寿命にはさまざまな困難がありましたが、後悔することはありませんでした）。 技術的には、JSOCは長い間HP ArcSightだけではありません。 SIEMコアは、トラフィックモニタリング、IPS \ ID、脆弱性評価など、さまざまな便利な機能に徐々に成長しています。 同時に、多数のスクリプト、アドオン、独自の開発を蓄積し、独自のセキュリティインテリジェンスソリューション（JiVS）と統合しました。
- 顧客の異常を高レベルで検索し、アクティビティとインシデントの一般的な傾向を追跡するためのツール。
- お客様の前でSLAの実装を監視および視覚化するシステム。
- ビジネスの顧客ガイダンスのための効果的な視覚的なダッシュボードとレポートシステム。
その結果、次のような顧客企業でのインシデントを検出するための保護プロファイル/エリアを作成しました。
- 会社の外部Webリソースに対する攻撃。
- システムおよびアプリケーションへの不正アクセス。
- ビジネスアプリケーションの包括的なセキュリティ。
- ゼロデイウイルスのヒューリスティック検出を含む、企業のネットワーク内のウイルスおよびマルウェアの活動。
- 企業ネットワークへのリモートアクセスを使用するためのポリシー違反。
- インターネットにアクセスして外部デバイスを操作するときの不正なユーザーアクション。
- アカウントの認証と使用の異常。
- および会社のインフラストラクチャ、内部情報セキュリティポリシー、および使用される保護手段に応じたその他のインシデントのカテゴリ。
インフラ
図 3-JSOCサービスインフラストラクチャ主要な技術プラットフォームを選択した後、インフラストラクチャを作成する問題を解決し、場所を特定する必要がありました。 西洋の同僚の経験から、建築物の目標アクセシビリティは少なくとも99.5％である必要があることが示されています（そして、最大の大変動耐性を持つ）。 同時に、地理の問題は根本的なままでした。コロケーションはロシア連邦の国境内でのみ可能であり、人気のある西洋のプロバイダーを使用する可能性を排除しました。 すべてのアクセスレベルで情報セキュリティインフラストラクチャを確保するという自然な疑問がこれに重なり、概して、私たちは選択の余地がありませんでした。私たちは給水センターのチームに頼りました。 JSOCの大規模なコロケーションの一環として、アーキテクチャを展開できるフラグメントを特に強調すると同時に、WDCのフレームワーク内にすでに存在するセキュリティプロファイルを強化しました。 ITインフラストラクチャは、当社のティア3データセンターに展開されており、その可用性率は99.8％です。 その結果、サービスの可用性の目標指標に到達することができ、作業の大幅な自由度とシステムの私たち自身への適応を受け取りました。
チーム
サービス開始の初期段階では、JSOCチームは3人で構成されていました。2人の監視エンジニアが8から22時間の時間間隔を閉じ、1人のアナリスト/管理者がルールの開発に関与しました。 顧客が指定したサービスのSLAも非常に穏やかでした。検出されたインシデントへの反応時間は最大30分、分析、分析レポートの準備、およびクライアントへの通知の時間は最大2時間でした。 しかし、最初の数か月の作業の後、私たちはいくつかの非常に重要な結論を下しました。
- 監視の変更は、必ず24 * 7モードで機能する必要があります。 夜間および夜間のインシデントの量は非常に少ないにもかかわらず、最も重要かつ重大なイベント（DDoS攻撃の開始、外部境界を通過する低速攻撃の最終段階、取引先の悪意のあるアクションなど）は、夜間および朝のシフトが始まる頃には、彼らはすでに関連性を失っています。
- 重大なインシデントの解析時間は30分を超えないようにしてください。 そうでなければ、それを防ぐか、損傷を大幅に最小化する可能性は壊滅的に低下します。
- 各インシデントに必要な解析時間を確保するには、解析のための本格的なツールキットを準備する必要があります：解析用のフィルタリングされたターゲットイベント、疑わしいアクティビティの統計的変化を示すトレンド、アクティビティをすばやく分析して運用上の意思決定を行うことができるターゲット分析レポートを備えたアクティブチャネル。
- クライアントのセキュリティ管理チームは、インシデントの監視および検出チームとは別にする必要があります。 そうしないと、チェーン内のヒューマンファクターの「構成の変更-インシデントの記録-誤検知の記録」のリスクがサービスの品質に大きく影響する可能性があります。
実際には、これらすべての結論により、Jet Infosystems社のInformation Security Centerのフレームワーク内に個別の構造単位が作成され、各タスクを提供するための3レベルモデルに焦点を当てました：インシデントの監視と分析、およびセキュリティツールの管理。 現在、この部門には30人以上がおり、成熟した構造になっています（図4を参照）。
- 24 * 7で機能する2つの勤務シフト：1つはインシデントの監視と分析に従事し、もう1つはシステム管理;
- クライアント内の運用アクティビティから抽出された専用の開発チーム。サービスと脅威監視プロファイルの関連性を維持できます。
図 4-JSOCの組織構造この組織構造により、次のSLA目標を達成できました。
| Jet Security Operation Centerのオプション | ベーシック | 高度な | プレミアム |
|---|
| サービス時間 | 8 * 5 | 24 * 7 | 24 * 7 |
|---|
| インシデント検出時間（分） | 重大な事件 | 15〜30 | 10-20 | 5-10 |
|---|
| その他の事件 | 60まで | 60まで | 45まで |
|---|
| 基本的な診断と顧客情報の時間（分） | 重大な事件 | 45 | 30 | 20 |
|---|
| その他の事件 | 120まで | 120まで | 90まで |
|---|
| 対策に関する推奨事項を発行する時間 | 重大な事件 | 最大2時間 | 最大1.5時間 | 最大45分 |
|---|
| その他の事件 | 最大8時間 | 最大6時間 | 最大4時間 |
|---|
現時点では、12の顧客にサービスを提供し、情報セキュリティを確保する上で直面する課題を解決しています。 これらはJSOCの最初の1年半の結果です。
この資料があなたにとってあまりにもマーケティング的ではないように願っています。 今後の記事では、次のようなトピックを取り上げる予定です。
- SOCの可用性：何であるか、何で構成されているか、およびそれを測定する方法。
- SIEMの相関ルールから実際のインシデント検出シナリオまでのパスはどれくらいですか。
- 組織の問題：SOCスペシャリストに教えるべきものと教えないもの。
- インシデントの解析に関する少しの練習。
継続するには...;）
dryukov