サイバー攻撃の監視および対応センターで2番目のSIEMを実装した方法

1つの頭は良いですが、2つは美しくありません...それで、サイバー攻撃を監視して対応するためのSIEMプラットフォームがセンターに1つしかない、素晴らしい時代に生きながら考えました。これがHPArcSightであったことは周知の事実であり、SOCの中心を構築するための要求、希望、野心的な計画の棘を経て、ロングマラソンの唯一の完走者であることが判明しました。



そして、何も良い前兆とは思えませんでしたが、ある時点で、代替プラットフォームで作業する必要性についての考えが現れ、ますます強く主張するようになりました。そして、ここでの主な機関車は、GosSOPKAセンターの積極的な開発でした。これらのセンターの1つになるためには、提供されているソフトウェアを使用する必要がありました「外国の個人および（または）法的実体の直接的または間接的な管理下にないロシアの組織による保証および技術的支援」（2019年5月6日付けのFSBの命令第196号、第3.4項）。これらすべてにどのように苦しみ、最終的に何が起こったのかを以下に示します。





アニメシリーズ「キャットドッグ」からのショット



ポリガミー、マルチベンダー を公​​言し（そして、私たちが覚えているように、このタイプの活動はバッグの荷降ろし操作とは非常に異なります）、市場で広く普及しているSIEMソリューションで作業する準備ができていると言うSOCがあると聞いています。このようなアプローチを定性的に実装することが不可能な理由は、以下の説明から理解できます。私たちはArcSightにとても愛着を持ち、その周りにソリューションとプロセスのエコシステム全体を構築することができたため、エイリアンのSIEMを組み込むことは非常に困難であり、多くの困難な質問を投げかけました。

1. どのソリューションを選択しますか？
2. 新しいSIEMシステムをTIER1操作に統合するにはどうすればよいですか？
3. ArcSightが現在新しいプラットフォームに転送する必要がある多くの内部統合をすべてどのように転送できますか？
4. SIEMコンテンツ開発のイデオロギーを同期させ、対称的な検出ルールのセットを提供するにはどうすればよいですか？

解決策の選択は簡単な作業ではありませんでした。どこでも渦に飛び込む必要があり、その深さを見積もることはできませんでした。その結果、別の方法で選択することにしました。ベンダーのSIEMを使用することで、要件に応じた改善の優先度が高く、その約束を信じていました。このようにして、Positive Technologiesとの技術的パートナーシップが生まれ、MaxPatrolSIEMがSIEMの目標到達プロセスに登場しました。

はい、新しいプラットフォームがあります。しかし、誰が彼女と一緒に働くのでしょうか？

正直なところ、最初は、新しいツールキットと並行して2番目のチームが作業しなければできないと感じました。この感覚は、2番目のSIEMのテストに参加した上級アナリストラインでさえ受け入れるのが難しいと感じたという事実によって強化されました。したがって、当初、コンセプトは次のように描かれました。それぞれが独自の機器でシャープ化された2本のTIER1ラインと、マルチプラットフォームのTIER2です。 T1からT2までのスペシャリストの成長要因としてのマルチプラットフォーム準備要因。



1番目のレーンをTIER1とTIER2に分割するのに十分な理由を蓄積したのはこの頃でした（これについては別のシリーズの記事で詳しく説明します）。また、当初のコンセプトではT2は両方のプラットフォームで動作するはずなので、すべてのMP SIEMインシデントを、新しいSIEMに没頭した最も経験豊富な第1戦闘機から形成された第2レーンに変えました。将来的には、2番目のラインのエンジニアは先輩の同僚であるアナリストよりもMP SIEMを前向きに認識していたと言えます。これにより、プラットフォームが完全に1番目のラインに着陸し、いくつかの特殊なものを囲うことができないという希望が生まれました。



単一のエコシステムへの統合の問題も、私たちが予想したほど苦痛ではありませんでした。おそらく、開発された統合メカニズムに柔軟性と構成の冗長性が最初に含まれていたという事実によって助けられました。私が自慢したい特に大きな勝利はありませんでした。新しいシステムをエコシステムと調査プロセスにすばやく組み込みました。現在、さまざまなSIEMからのインシデントの処理は、SIEM自体のインターフェイスのみが異なります。すべてのルーティングおよび優先順位付けメカニズム、すべての充実した意思決定情報、すべての通知テンプレートは同一であり、同じ使い慣れた場所にあります。

コンテンツはどうですか？

コンテンツ（情報セキュリティイベントの相関とインシデントの識別のルール）なしで「空の」SIEMを進めることはできず、多くの脅威を明らかにすることはありません（ボックス化されたコンテンツは使用しません）。そのため、既存のJSOCシナリオの新しいプラットフォームで相関ルールを迅速に開発するタスクが発生しました。最初は、少しの血でやり遂げて、実装ロジックをコピーしてArcSightからルールを転送することにしましたが、これは私たちが真剣に取り組んだ間違いであることが判明しました。まったく異なる製品アーキテクチャでは、開発に「独自の」アプローチが必要でした。私はこのアプローチを加速するペースで形成しなければなりませんでした。ベンダーとの緊密なやり取りは、新たな問題について助言した多くの人々が、機能に既存のチップを改良し、新しいチップを作成するという私たちの要求の実装に取り​​掛かるのに役立ちました。コインの裏側は、この最新の機能で正しく機能するように、コンテンツを定期的に書き直す必要があったことです。しかし、彼らが言うように、変化するか死ぬので、私たちは文句を言いませんでした（おそらくチーム内でお茶を飲みながら）。



初期の段階では、ArcSightでの作業中に犬を食べた経験豊富な4行目のアナリストだけが、新しいSIEMのコンテンツの開発に従事していました。不思議なことに、何人かの男はその時までにすでに専門的な変形を経験していて、その高いレベルの成熟度で特定のSIEMへの「依存」を形成していました。新しいプラットフォームへの切り替えは、心理的にも技術的にも困難でした。その後、開発チームは、以下を含む新しいメンバーで大幅に拡大されました。 3行目の人たち、そして彼らのためだけに、このトピックははるかに簡単に、そしてしばしばさらに生産的になりました。



両方のSIEMのシナリオの分野横断的なリストにもかかわらず、主に異なるプラットフォームのアーキテクチャと機能の制限により、それらの実装は大幅に異なる可能性があります。たとえば、ArcSightでは、相関ルールで、非厳密一致によってアクティブシートにレコードが存在するかどうかのチェックを指定することはできませんが、MPSIEMでは可能です。一方、MP SIEMは、テーブルリストにレコードを追加または削除するための内部イベントを生成しませんが、ArcSightはこれを実行でき、多くのシナリオでこの機能が使用されます。JSOCスクリプトのナレッジベースに「デュアルライン」を導入し、実装の微妙な違いや、各プラットフォーム用の独自の調査ツールを説明するために、私は分断された個性を持って生きなければなりませんでした。



同時に、インシデント調査のロジックは生成されたSIEMに依存しないこと、および新しいSIEMはすべて同じタスクを解決するための新しいツールであることを1行目に伝えることが非常に重要でした。独自の特性を検討する必要がありますが、根本的な変化はありません。

そして、1行目の作業が沸騰し始めました

TIER1のMPSIEMでの作業への没頭は、新入社員の試運転に合わせて調整されたプロセスを経て徐々に進行しました。インシデントの基準が決定されましたが、MP SIEMの経験がまだあまりない、1行目の分析に与えるのはそれほど怖いものではありません。

• 重大度の低いインシデントの詳細（未分類のホスト/ネットワークおよびアカウント）;
• 長いSLAタイミング。
• インシデントの労働強度が低い（TIER2でインシデントを処理している間に統計を蓄積しました）。
• それほど猛烈な相関ルールではありません（はい、最初の行はそこにあるはずです）。

これらの基準に従ったシナリオはいくつかの段階に分けられ、「クレジット」を通過してインシデントのプールのソリューションにアクセスした後、TIER1エンジニアに1つずつ引き渡されました。



その結果、ツールのポートフォリオに2つのSIEMがあり、本質的に完全に同一のシナリオと処理ロジックが起動されます。



Alexey Krivonogov、地域ネットワーク開発のためのソーラーJSOCの副所長