フォレンジック データの収集と分析は、インシデント対応プロセスのコア コンポーネントです。このプロセスは、侵害の存在とその後の範囲、攻撃者が使用するツール、および攻撃者の能力を判断するための中心となります。ただし、デジタル フォレンジックおよびインシデント レスポンス (DFIR) データの取得は、特に運用技術 (OT) システムが関与している場合は、必ずしも簡単な作業ではありません。
多くの場合、OT ネットワークには、組み込みソフトウェアおよびファームウェア コンポーネントを定期的に活用する、一般的ではなく、時には目立たないさまざまな製品が含まれています。この好例は、物理的な生産環境の正確で継続的な運用のために低遅延通信をサポートするリアルタイム オペレーティング システム (RTOS) です。
組み込みシステムは通常、従来のフォレンジック手法の範囲外であるため、防御側はこれらのシステムからデータを収集するためのツールと手法を特定または定義する必要があります。したがって、フォレンジック データを収集し、収集フレームワークを構築し、セキュリティ ベースラインを設定し、構造化されたインシデント対応プロセスを確立するには、体系的なアプローチが必要です。
この投稿では、Mandiant の世界的に有名なインシデント対応方法論に基づいて構築された、Mandiant の「組み込みシステム向け DFIR フレームワーク」について説明します。当社のフレームワークでは、OT デバイスに組み込まれているネイティブ機能やその他の一般的に利用可能なツールを活用して、資産所有者がインシデント対応の取り組みを準備できるようにする方法について説明しています。フレームワークの最後のステップを適用する方法を例示するために、ラボ設定のリモート ターミナル ユニット (RTU) の例からデータを収集します。
もっと学びたいですか？ PLC トレーニング コースのデジタル フォレンジックとインシデント対応に登録してください。
組み込み OT デバイスに DFIR フレームワークが必要な理由
Mandiant の Redline 、 FTK Imager 、 Volatility Frameworkなどの多くのツールは、IT エンドポイントと OT 中間システムにわたる DFIR 情報の標準を確立しています。私たちの経験に基づくと、組み込みシステムからデータを収集する場合、これらのツールの価値は限られています。組み込みシステム用の DFIR フレームワークが必要な理由は次のとおりです。
- OT 資産からフォレンジック データを収集すると、異常なアクティビティを特定するためのベースラインを確立したり、インシデントを調査したり、脆弱性や資産管理プログラムを支援したりするのに役立ちます。
- 組込み OT システムは、多くの場合、VxWorks、QNX、Windows CE など、物理的なプロセスや環境でリアルタイム機能をサポートする従来とは異なるオペレーティング システムに依存しています。ユーザーによる RTOS の操作は必ずしも単純ではなく、多くの場合範囲が制限されていますが、フォレンジック情報を収集するのに役立ちます。
- OT デバイスは、スタンドアロン、セグメント化、またはエアギャップである可能性があり、多くの場合、可視性の欠如や集中型データ集約につながります。データの手動収集が必要になる場合がありますが、これは時間がかかり、インシデントに対応する際に問題になる可能性があります。
- 構造化されたフレームワークに従ってこの情報を収集および分析する組織は、重要な資産の可視性が向上する可能性があります。これにより、悪意のあるアクティビティを特定し、インシデントが発生した場合に迅速に対応する機会が提供されます。
- 組織は、気付かないうちに資産からフォレンジック データを追跡することがよくあります。これは、調達、保守、またはその他のエンジニアリング プロセスの形で発生します。
組み込みシステム向けの Mandiant DFIR フレームワーク
Mandiant の組み込みシステム向け DFIR フレームワークは、インシデント対応プロセスの初期段階での組み込みデバイスからの情報の準備と収集に重点を置いた 3 つのステップで構成されています。データ収集の例を提供していますが、このドキュメントは、読者がデジタル フォレンジックの専門家になることを意図したものではなく、フレームワークを理解し、操作するデバイスに適用するためのガイドとして提供しています。
準備の 3 つのステップ:
- 環境内の組み込みデバイスのインベントリを特定して文書化します。それらから情報を抽出するために使用できるツールを決定します。
- エンジニアリング チームおよび相手先商標製造会社 (OEM) と協力して、インシデント対応と復旧作業のサポートに役立つ可能性のある追加の方法、ツール、データ ソース、およびベンダーの連絡先を特定します。
- 予期しない状況やインシデントに対応するときに役立つデータを収集します。
これらの手順は、根本原因分析 (RCA) や障害モードおよび影響分析 (FMEA) など、OT 担当者になじみのあるフォレンジック エンジニアリング プロセスと多くの重複があります。 RCA と FMEA は、産業プロセスに影響を与えるイベントの証拠の収集と分析に重点を置いていますが、組み込みシステムの DFIR フレームワークは、デジタル手段を通じて不正な活動を実行している敵対者のコンテキストを追加します。その結果、このフレームワークの適用は、サイバー セキュリティ担当者とエンジニアリング担当者の両方によってサポートされた場合に成功する可能性が最も高くなります。
ステップ 1: デバイスとツールの識別
このステップでは、エンジニアリング チームとセキュリティ チームが協力して、データを収集するデバイスを特定し、物理的なウォークダウンを実行し、技術手順やベンダー マニュアルなどのドキュメントを確認します。フィールド観察と製品ドキュメントからの情報は、デバイスとの通信に使用できるさまざまな方法に関する重要な詳細をもたらします。最も一般的な方法は次のとおりです。
- 構成、診断、およびトラブルシューティングのためにデバイスに接続するために使用されるソフトウェア アプリケーション。
- ターミナル、セキュア シェル (SSH)、ファイル転送プロトコル (FTP)、Telnet、またはデバイスへのコマンドライン アクセスを確立するために展開されたその他の通信プロトコル。
- Web サーバーがグラフィカル ユーザー インターフェイス (GUI) にアクセスできるようになりました。
- ポータブル メディアや専用ケーブルなどの物理ポートとインターフェイス。
体系的なデータ収集を維持するには、さまざまな製品と通信するための構造化された記録が必要です。このような文書には、セキュリティ管理のために無効化またはブロックされている製品機能や、セグメント化されていてポータブル メディア経由でのみアクセスできる資産などの詳細を記載する必要があります。次の表は、さまざまな有名な OT 製品と、それらが依存する通信方法を示しています。これには、異なる OEM および異なる物理ポートからのソフトウェアが含まれます。場合によっては、リストされている通信は、通常の運用には必要ないか、使用されない場合がありますが、インシデントに対応するときにデバイスへの代替アクセス方法を提供できます。
防御者は、バックアップ構成の場所、デバイス固有の技術手順/ベンダー マニュアル、資格情報、メンテナンス、トラブルシューティング、および構成の実行を担当する個人などのサポート データ リソースも文書化する必要があります。このドキュメントは、回復時間 (TTR) を短縮し、インシデントに対応する際の不必要な遅延を防ぐのに役立ちます。
ステップ 2: OEM コラボレーション
組み込みデバイスの機能と機能に関する詳細な情報は、OEM のサポートによって最も簡単に入手できます。組み込みデバイスの設計と製造を担当するベンダーは、フォレンジック プロセスをサポートできる特権的な情報とツールにアクセスできます。多くの場合、オペレーターはベンダーにサポートを依頼するか、デバイスから情報を収集するための高価な専用ツールを開発するかを決定する必要があります。
ほとんどの産業環境では複数の OEM の機器が使用されるため、インシデント対応の準備とトレーニングは、デバイスと通信する方法に関する正式な文書によってサポートされる必要があります。このデータの収集は、製品を操作するためのより詳細な知識とツールにアクセスできることが多い OEM のサポートにより、より簡単になります。
- OEM は、利用可能なデータ (揮発性と不揮発性の両方) とその収集方法を事前に特定するのに役立ちます。
- OEM は多くの場合、価値のあるデータをすばやく収集したり、製造したデバイスの分析を実行したりするために使用できる独自のツールや機器を持っています。
- OEM は、サービスを停止した侵害された機器の代わりに交換用デバイスを提供する場合があります。
- インシデントに対応する際にデバイス固有のソフトウェア ライセンスが緊急に必要な場合は、OEM のサポートが必要になることがあります。
- OEM は、資産所有者が手順に組み込むためのインシデント対応ガイダンスを持っている場合があります。
ステップ 3: データの識別と収集
セキュリティ チームと運用チーム (エンジニアリング、運用、保守など) の利害関係者は、前の手順で得られた結果に基づいて組み込みデバイスからデータを収集するために協力します。双方からのコラボレーションにより、予期せぬ、または意図しない生産への悪影響を防ぐことができます。この 3 番目のステップで収集された情報は、資産インベントリの構築または強化に役立ち、場合によってはベースラインの確立に役立ちます。
組み込み OT デバイスからのデータの識別と収集は、IT フォレンジックと同じ標準的なベスト プラクティスに従う必要があります。ただし、この場合、デバイスのステータスをより詳しく知るのに役立つさまざまな物理的およびデジタル入力を探します。次のリストは、インシデント対応と侵入分析に役立つと思われるデータの非網羅的な参照を提供します。
組み込みデバイスからフォレンジック データを取得するための特定のソリューションは 1 つではありませんが、デバイスに慣れ、デバイスに関する情報を収集する方法を学習するプロセスは、デバイスごとに一貫しています。これを考慮して、組み込みデバイスの DFIR の研究を支援するために General Electric が Mandiant に提供した General Electric D20MX RTU を使用して、フレームワークの 3 番目のステップを説明することにしました。この研究は、基本的な VxWorks メモリの収集と分析を実行するツールであるics_mem_collectの作成につながりました。
D20MX から情報を収集するために、コマンド ライン シェルと GUI ベースの専用アプリケーションの 2 つの方法を検討しました。両方の方法を使用して、さまざまな種類の情報を取得しました。
D20M シェル
利用可能なコマンドを最初に調査したところ、この方法により、デバイス パフォーマンスのベースラインを構築するための情報を収集し、必要に応じてライブ応答を実行できることがわかりました。 D20M シェル経由でアクセスできる情報には、デバイスのユーザー/エラー ログ、パフォーマンス、シリアル、および構成データが含まれます。標準の D20M シェルを使用して D20MX へのコマンドライン アクセスをテストしましたが、D20MX には、データへのさらなるアクセスと可用性を提供する 2 つの追加シェルがあることを強調しています。これらのシェルは、メモリの読み取りと書き込み、パケット キャプチャの実行など、その他の高度な機能をサポートしています。
SGConfig と DS アジャイル スタジオ
D20M シェルに代わるものは、PLC、RTU、入出力デバイス、インテリジェント電子デバイス (IED) などの多くのタイプの General Electric デバイスを管理する独自の GUI ベースのアプリケーションである SGConfig です。
SGConfig は主に RTU に関連する情報を管理し、構成アクションを実行するために使用されますが、その機能の一部はインシデント レスポンダーのサポートに適しています。たとえば、SGconfig は、テキスト、バイナリ、圧縮、XML 形式のデータなど、さまざまな形式で構成データをエクスポートできます (図 4)。さまざまなファイル形式を提供することは、さまざまなツールや方法論による分析をサポートするのに役立ちます。
SGConfig には、バイナリ形式の構成ファイルを比較するためのツールも含まれています。図 5 は、ベースライン エクスポート (左) とエクスポートされた新しい構成ファイル (右) を比較した例を示しています。この例では、SGCONFIG ソフトウェアを介してユーザーを追加することにより、D20MX 構成を変更しました。 SGConfig の「Config Compare」機能を使用して、「BackupAdmin」という名前で作成したユーザーを特定できました。 「構成比較」機能は、変更されたデータを含む構成テーブルを識別します。この場合、デバイスのマニュアルによると、テーブル B014USER には「ユーザーのログイン名、パスワード、アプリケーション アクセス、およびその他のユーザー固有の情報に関する情報が含まれています」。
見通し
Mandiant の組み込みデバイス向け DFIR フレームワークは、組み込みデバイスからデータを収集して処理するための体系的なアプローチを提案しています。そのため、フレームワークの適用は、セキュリティ グループ、エンジニア、メンテナンス ワーカー、およびオペレーター間のコラボレーションに依存して、サイバー インシデントへの対応をサポートするデータを収集および分析する必要があります。フレームワークで提案されているアクションの多くは、災害復旧やエンジニアリング RCA および FMEA などの他のタスクもサポートできる既存のプロセスと手順を活用しています。
さまざまな組み込み製品からのデータ収集のさまざまな例を提供することは、このフレームワークの範囲外でしたが、ほとんどの場合、エンジニアリング担当者は、組織が提案する手順に従うのに役立つツールを既に知っている可能性があります。また、次の推奨事項も提供します。
- OT チームや OEM と協力します。
- インシデント対応の取り組みをサポートする OT チームと OEM の連絡先を特定します。これには、エンジニアリング、運用、保守の各チームが含まれる必要があります。
- プロセスとその組み込みデバイスに関する知識と専門知識を持つ個人を特定します。
- これらの個人と協力してコミュニケーションを取り、このフレームワークで強調されている概念とプロセスを順を追って説明します。
- このレポートで説明されているプロセスを既存の手順に組み込みます。
- 組み込み産業機器に影響を与えるサイバーインシデントのインシデント対応および/またはエンジニアリング手順に、特定の言葉遣いとセクションを含めます。
- 組み込みデバイスのインベントリ、特定されたツールと通信方法、およびデータ チェックリストを追加します。
- デバイス/環境の構成はサイトや業界によって異なるため、利用可能なデータ ソースを確認し、可能な場合はこれらのリストをカスタマイズします。
- 新たに取得した組み込み産業機器のドキュメントを更新およびレビューするプロセスを作成します。
- 組み込み産業機器をインシデント対応トレーニングと演習に組み込みます。
- 組み込み産業機器に影響を与えるサイバーインシデントをエミュレートするテーブルトップ演習を開発し、手順の実行を演習します。
- サイバー攻撃と組み込みデバイスをカバーする OT チーム向けの意識向上トレーニングを開発します。
- このフレームワークの最初のステップで説明されているツールを使用して、組み込み機器からデータを収集するプロセスを順を追って説明します。
もっと学びたいですか？ PLC トレーニング コースのデジタル フォレンジックとインシデント対応に登録してください。
参照: https://www.mandiant.com/resources/blog/mandiant-dfir-framework-ot
Comments