SOC ABCOT。従来のSOCがプロセス制御システムを保護しない理由

ロシア(そして原則として世界)でのSOCの主な経験と専門知識が、主に企業ネットワークの制御とセキュリティの問題に焦点を合わせていることは周知の事実です。これは、リリース、会議でのレポート、円卓会議などから見ることができます。しかし、脅威が発生するにつれて(Stuxnetの設定された痛みを思い出すことはありませんが、それでも、Black / Grey Energy、Industroyer、Tritonを通過しません)、「ロシア連邦の重要な情報インフラストラクチャのセキュリティについて」という法律の規制要件、カバーする必要性の問題SOCの注目とすべての産業会社の聖なるものはICSセグメントです。私たちは、約1年、このシェルへの最初の慎重なアプローチをした半前(12)。それ以来、もう少し経験と研究があり、SOCOT問題に特化した資料のフルサイクルを立ち上げる力を感じました。私たちが長い間慣れ親しんできた企業SOCの技術とプロセスが産業SOCとどのように異なるかから始めましょう(物事は人事問題に自然に起こります)。あなたがトピックに無関心でないならば、猫の下でお願いします。







分析を実質的にするために、まず、SOCOTをソーラーJSOCに実装されている監視センターの構造と比較していることを修正します。







とりわけ、産業部門も担当するGosSOPKAセンターのタスクのコンテキストで、これらの違いについて説明することができます。



モデルの各レベルの詳細は上の以前の論文に見出すことができるインフラストラクチャインベントリ監視、脅威インテリジェンス(12)、セキュリティ管理人員およびプロセス。..。現在の記事では、セキュリティ監視の中心的なブロックに焦点を当てます(自動化されたプロセス制御システムの応答および調査プロセスの機能については、今後の記事で説明します)。



劇場はハンガーから始まり、SOCは監視から始まります



イベントの監視、相関、インシデントの検出の分野では、すべてがすでに定義されており、既知であるようです。そして、セキュリティイベントを収集するためにエアギャップを埋めることさえ、かなり試行錯誤されたトピックです。しかし、それでもなお、注意を払う価値のあるニュアンスがいくつかあります。



一般的なSOCアーキテクチャ..。エアギャップのある一見単純な解決策にもかかわらず、分散型施設を備えた大規模な連邦企業の状況(これは特に電力業界に当てはまります)はかなり複雑です。オブジェクトの数は数千単位で測定され、多くの場合、イベント収集サーバーをオブジェクトに配置することさえできません。各オブジェクトは非常にコンパクトですが、重要な情報セキュリティイベントを生成する可能性があります。説明した状況に加えて、通信チャネルの問題が重なることがよくあるため、「センター」へのイベントの送信に少なくともある程度の大きな負荷がかかり、メインアプリケーションの動作が妨げられ始めます。



したがって、SIEMコンポーネントをサイトごとに正しく分解する方法は非常に深刻な問題です。以来、私たちはさらなる資料の1つでそれに戻りますこの日記のフィールドは小さすぎて、1つの情報記事を含めるには多すぎます。



ユースケースの専門化とプロファイリング。 ICSセグメントにのみ関連する完全に特殊化されたシナリオのトピックに触れなくても、ICSの標準的なインシデントでさえ完全に異なる意味と重要性を持っていることは注目に値します。私たちは皆、企業ネットワークでリモート管理ツールを長い間使用することに慣れています。しかし、そのような事件の重要性、そして原則として、閉じた技術ネットワークでのインターネットとの通信の成功の重要性が非常に大きいことは明らかです。同じことが、技術的なAWPでの新しいシステムサービスのインストール、必須の調査を必要とするマルウェアの検出の事実などにも当てはまります。



ユースケース操作の重要な制限は、情報セキュリティシステムの実装の制限(通常、技術セグメントはそれほど豊富ではありません)、および古いバージョンのオペレーティングシステムの使用(および技術者は不信感を持ってSysmonのインストールを検討します)によっても導入されます。



それでも、企業環境の非常に大量のユースケースをICSセグメントに正常に適用し、十分に高いレベルの全体的なインフラストラクチャ制御を提供できます。



さて、聖なる聖なるものを通り過ぎるのは難しいです-SCADAシステム..。情報セキュリティシステム、オペレーティングシステム、およびネットワークフローのレベルで、すべてのセグメントが少なくとも少しですが類似している場合、さらに深く進むと、重要な違いが生じます。企業のネットワークとセグメントに関しては、誰もがビジネスの監視とビジネスアプリケーションの接続を夢見ています。そして、このプロセスは複雑ですが(ログは変化し、CEFのふりをしたくありませんが、通常の情報はデータベースからのみ取得できますが、管理者は速度低下について誓い、不平を言います)、一般的に実装されます。技術セグメントでは、上位システムと中間レベルのシステムを接続する場合、これらの問題は、技術的なダウンタイムのスペースの重要性に関連して絶対的に高くなります。ソースを接続するための最初のステップを実行するには、次のものが必要です。



  1. スタンドを組み立てて、イベントの受信の成功を確認します
  2. すべての技術的な詳細を含む一般的なアーキテクチャソリューションを描画します
  3. 数か月以内にベンダーと合意する
  4. 戦闘負荷エミュレーションを使用して、顧客のスタンドで再度確認してください
  5. ソリューションを本番環境に実装するために非常に慎重に(ヘッジホッグに関する冗談のように)


悲しみ、憧れ、ビジネスプロセス。そしてこれは、原則として、APCSの機器は、十分な容量、完全、理解可能、高品質のロギングを特徴としているという事実にもかかわらずです。



しかし、幸いなことに(または偶然に)、通常、ICSセグメントに異なるアプローチを実装できます。それらのプロトコルのほとんどは、送信された情報の暗号化またはマスキングを意味しません。したがって、制御コマンドを監視および解析するための最も一般的なアプローチの1つは、産業用侵入検知システムまたは産業用ファイアウォールの実装です。これにより、コピーまたは実際のネットワークトラフィックを操作し、プロトコルと制御コマンドを解析して、後続のログを記録できます。それらのいくつかは、とりわけ、内部に組み込みの基本的な相関エンジンを備えています(イベントの正規化、分類、およびプロファイリングの恐怖から私たちを救います)が、同時に、それらはSIEMシステムの完全な代替ではありません。



, ,



先に進みます。 ICSネットワークの在庫の問題は最も苦痛が少ないはずです。ネットワークは非常に静的であり、機器は共通のセグメントから分離されているため、アーキテクチャに変更を加えるには、プロジェクト全体が必要です。企業ネットワークに関するおとぎ話-「モデルを修正してCMDBに入力するだけです。」しかし、いつものように、ニュアンスがあります。ICSセグメントの場合、新しい機器の出現は、インシデントまたは攻撃の非常に重要な兆候の1つであり、必ず特定する必要があります。そして、これらすべてを備えた従来のインベントリ方法(脆弱性スキャナーの動作モードを節約する)は、技術者の間で、さらには自動プロセス制御システムのセキュリティ担当者の間でさえ、最も深刻なアレルギーを引き起こします。不幸な時期に失敗したモードでの在庫スキャンでさえ、特定のアプリケーションを「置く」可能性がある場合、企業ネットワークでは珍しいことではありません。当然のことながら、自動化されたプロセス制御システムでそのようなリスクを負う準備ができている人は誰もいません。



したがって、APCSの主なインベントリツール(手動制御に加えて)は、前述のネットワークトラフィック分析システムと産業用侵入検知システムです。ネットワークに表示される新しいノードはそれぞれ、隣接ノードとの通信を開始します。通信の方法とプロトコルの両方、パケットとサービスフィールドの特異性により、新しい「ネイバー」をすばやく確認できるだけでなく、明確に識別できます。



対照的に、脆弱性を特定して管理するプロセスはより保守的です。原則として、インフラストラクチャは頻繁に、非常に制御された方法で更新およびパッチが適用されます。アプリケーションソフトウェアと技術機器のリストは固定されています。したがって、ICSセグメントの現在の脆弱性のリストとステータスを判別するには、通常、主要なソフトウェアのバージョンを判別し、メーカーの速報を確認するだけで十分です。その結果、私たちは積極的なスキャンとソフトウェア検証モードから、業界の専門家による技術的および手動のバージョン管理監査と分析の方法に移行しています。



脅威を分析または特定するプロセスも同様の方法で構築されます。原則として、1回限りの固定モデルは、インフラストラクチャの重要な再構築(新しいノードの追加、重要な機器のファームウェアバージョンの更新など)の事実、またはインフラストラクチャや新しい攻撃ベクトルに関連する新しい脆弱性を明らかにしたときに近代化されます。しかし、それらについても、すべてがそれほど単純ではありません。



OT脅威インテリジェンスまたは孤立したネットワークは妥協の指標を夢見ていますか



新しい脅威と攻撃ベクトルに関する情報は役に立たないでしょうか?すぐに「いいえ」と答えたいと思いますが、一緒に成熟したOTセグメントにおける古典的なTIデータの適用可能性を理解してみましょう。



TIは通常、フィード(データストリーム)またはIoC(特定のマルウェアまたはハッキングツールを識別するための侵害の指標)です。これらには、次の特性が含まれています。



  • (IP-, URL, ), upload «» , . , , . , , «» .
  • (MD5- , , / ..), / / . , . , , , , whitelisting, , . – «» . TI .


その結果、ICSを狙った攻撃の場合、TI市場では非常にまれなTTP、攻撃者の戦術とアプローチ、および攻撃に対する攻撃者の戦術とアプローチに関する情報が、セグメント内の脅威の監視と識別に防御メカニズムとアプローチを適応させることを可能にし、はるかに重要になります。



これらおよび他の多くのニュアンスにより、そのようなSOCを構築するプロセスまたは請負業者の選択に非常に真剣かつ思慮深いアプローチを取り、OTSOCを形成するための戦略について真剣に考える必要があります。それがSOCITと交差するか、それとは別に機能する場合、プロセス、チーム、およびタスクにおけるある種の相互の強化と相乗効果を解決することは可能ですか。次の記事では、この問題に対する国際チームのさまざまなアプローチに焦点を当てます。インフラストラクチャと生活のあらゆる面で安全を確保してください。



All Articles