「設計上安全でない」セキュリティの文化は、バグが多いオペレーショナルテクノロジーデバイスの発見に引用されています。
研究者は、56のオペレーショナルテクノロジー（OT）ベンダーのデバイスに影響を与える10の脆弱性を発見しました。そのほとんどは、機器に固有の設計上の欠陥と、何十年にもわたって業界を悩ませてきたセキュリティとリスク管理への緩いアプローチに起因しています。
評判の高いベンダーであるHoneywell、Emerson、Motorola、Siemens、JTEKT、Bentley Nevada、Phoenix Contact、Omron、Yogogawa、および名前のないメーカーによってデバイスに見られる脆弱性は、その特性と脅威アクターが実行できることによって異なります。 ForescoutのVedereLabsの調査によると。
ただし、全体として、「各脆弱性の影響は、各デバイスが提供する機能に大きく依存します」と述べています。 ブログ投稿 火曜日に公開された欠陥について。
研究者は、各製品で見つかった欠陥の種類をXNUMXつの基本的なカテゴリに分類しました。 弱い暗号化または壊れた認証スキーム。 安全でないファームウェアアップデート。 またはネイティブ機能を介したリモートコード実行。
影響を受けるデバイスの欠陥を悪用することで脅威アクターが関与できるアクティビティには、次のものがあります。リモートコード実行（RCE）。コードはさまざまな専用プロセッサおよびプロセッサ内のさまざまなコンテキストで実行されます。 デバイスを完全にオフラインにしたり、特定の機能へのアクセスをブロックしたりできるサービス拒否（DoS）。 攻撃者がデバイスの重要な側面を変更できるようにするファイル/ファームウェア/構成の操作。 デバイス機能へのアクセスを許可する資格情報の侵害。 または、攻撃者がターゲットデバイスで目的の機能を呼び出すことを可能にする認証バイパス。
全身の問題
エベレスト山と山岳デバイスメーカーに関連して研究者がまとめてOT：ICEFALLと呼んだ欠陥は、セキュリティの観点から登る必要がありますが、重要なインフラストラクチャ自体を制御するネットワークの主要なデバイスに存在することは十分に悪いことです。
ただし、さらに悪いことに、脆弱性の影響を受ける製品ファミリの74％が何らかのセキュリティ認証を取得しており、市場に出荷される前に検証されているため、欠陥を回避できた可能性があります。 さらに、それらのほとんどは「詳細な脆弱性の発見中に比較的迅速に」発見されるべきだったと彼らは述べています。
OTベンダーが脆弱な製品に提供しているこのフリーパスは、セキュリティとリスク管理に関して業界全体が根強い努力を怠っていることを示しています。
「これらの問題は、セキュリティ認定製品での設計による安全でない慣行から、それらから離れようとする標準以下の試みにまで及びます」と研究者は投稿に書いています。 「[私たちの研究の]目標は、これらのシステムの不透明で独自性の性質、それらを取り巻く次善の脆弱性管理、および認証によって提供されるしばしば誤った安心感が、OTリスク管理の取り組みを大幅に複雑にする方法を説明することです。」
セキュリティパラドックス
実際、セキュリティの専門家は、重要なインフラストラクチャを実行するシステムを作成する分野でのベンダーの緩いセキュリティ戦略のパラドックスにも注目しました。 攻撃 これは、製品が存在するネットワークだけでなく、世界全体にとって壊滅的なものになる可能性があります。
「最も重要で機密性の高いタスクのいくつかを実行する産業用制御および運用技術デバイスは、 重要インフラ 環境は世界で最も安全性の高いシステムのXNUMXつですが、現実は正反対であることがよくあります」と、CerberusSentinelのソリューションアーキテクチャ担当副社長であるChrisClementsはThreatpostへの電子メールで述べています。
実際、調査で証明されているように、「これらの役割のデバイスが多すぎると、攻撃者がデバイスを完全に制御するために倒したりバイパスしたりするのが恐ろしく簡単なセキュリティ制御を備えています」と彼は言いました。
研究者の調査結果は、OT業界が「長い間延期されたサイバーセキュリティの計算を経験している」ことを示すもうXNUMXつのシグナルであり、ベンダーは、先に進む前に、最も基本的な生産レベルでセキュリティを統合することによって、何よりもまず対処する必要があります。
「機密性の高いオペレーショナルテクノロジーデバイスのメーカーは、設計プロセスの最初から始まり、最終製品での実装の検証に至るまで、サイバーセキュリティの文化を採用する必要があります」と彼は言いました。
リスク管理への挑戦
研究者は、OTデバイスのセキュリティ設計とリスク管理に固有の問題のいくつかの理由を概説し、メーカーが迅速に対処することを提案しました。
1つは、デバイス間の機能の均一性の欠如です。これは、デバイス固有のセキュリティの欠如も大きく異なり、トラブルシューティングを複雑にすることを意味します。 たとえば、ネイティブ機能を介してレベルXNUMXデバイスでRCEを取得するためのXNUMXつの主要な経路（ロジックのダウンロード、ファームウェアの更新、メモリの読み取り/書き込み操作）を調査したところ、研究者は、個々のテクノロジがこれらの経路を異なる方法で処理することを発見しました。
分析されたシステムはいずれもロジック署名をサポートしておらず、50％以上がロジックをネイティブマシンコードにコンパイルしていることがわかりました。 さらに、システムの62％がイーサネット経由でファームウェアのダウンロードを受け入れますが、この機能の認証を持っているのは51％だけです。
一方、デバイスの固有のセキュリティが直接メーカーのせいではなく、サプライチェーンの「設計上安全でない」コンポーネントのせいである場合があり、メーカーがリスクを管理する方法がさらに複雑になることが研究者によって発見されました。
「OTサプライチェーンコンポーネントの脆弱性は、影響を受けるすべてのメーカーから報告されるとは限らない傾向があり、リスク管理の難しさの一因となっています」と彼らは述べています。
長い道のり
実際、OTおよびITデバイスとシステムでリスク管理を管理するには、「共通のリスク言語」が必要です。これは、ベンダー間の多くの不整合と、業界におけるセキュリティおよび生産戦略では達成が難しいことです。 リスクレンズ.
これを改善するために、彼はベンダーがリスクを金銭的観点から定量化することを提案しました。これにより、リスク管理者とプラントオペレーターは、「脆弱性への対応–パッチ適用、制御の追加、保険の増加」に関する意思決定に優先順位を付けることができます。 IT資産と運用資産の両方。」
ただし、ベンダーがOT：ICEFALLシナリオを作成した基本的な課題に取り組み始めたとしても、セキュリティ問題を包括的に軽減するための非常に長い道のりに直面しているとForescoutの研究者は述べています。
「OT：ICEFALLに対する完全な保護には、ベンダーがデバイスファームウェアとサポートされているプロトコルの変更に関するこれらの基本的な問題に対処し、資産所有者が独自のネットワークに変更（パッチ）を適用する必要があります」と彼らは書いています。 「現実的には、そのプロセスには非常に長い時間がかかります。」
