コネクテッドデバイスの数が増え,CVEが毎年リリースされる中,組織はサイバーリスクの評価と軽減を優先しなければならない.そこで必要になるのが脆弱性管理である.
脆弱性管理プロセスの一環として,脆弱性アセスメント(VA)は,組織内のデバイス,ネットワーク,ソフトウェアの脆弱性を特定し,優先順位をつけることを含む.これらの資産をスキャンし分析することで,リスク管理者は毎年リリースされる新しいCVE(共通脆弱性・暴露)を迅速に特定することができる.
脆弱性が特定され,優先順位が付けられると,組織は,パッチを適用したり,暗号化やアクセス制御などのセキュリティ制御によって脆弱性を緩和したりするなど,脆弱性に対処するための措置を講じることができる.さらに,脆弱性管理には,新たな脅威や既存の脆弱性の変化を検出するためのネットワークの定期的なスキャンも含まれ,適切なセキュリティ態勢が長期にわたって維持されるようにする.
このブログでは,ICSの脆弱性評価プロセスを説明し,CVEを特定する方法を説明し,組織がデジタル資産をよりよく保護し,悪意のある活動が発生する可能性を減らすのを支援します.
ICS脆弱性評価プロセス
VAの手続きには大きく分けて3つのステップがある：
- 資産を特定し,共通プラットフォーム列挙(CPE)を割り当てる.
- 公表されている共通脆弱性・暴露(CVE)の特定
- CVEを正しいCPEにバインドする
これらのステップを促進するためには,当局が発見したCVEを公開し,厳格な標準構造に従い,信頼できるレビュープロセスを経ることができるユニークで正確なデータベースが必要である.理想的な世界であれば,先の記述は真実であっただろう.残念ながら,現実にはほど遠い.
米国国立標準技術研究所(NIST)が管理する国家脆弱性データベース(NVD)が,現在利用可能な最も近い代替手段である.NVD ウェブサイト上の CVE の例を図 1 に示す.
その存在にもかかわらず,NVDには信頼性を制限する固有の特性がある.大きな問題のひとつは,NVDが主要な情報源ではないため,コンテンツのリリースが遅れることである.
以下のセクションでは,ICS脆弱性評価プロセスのステップ,私たちが遭遇する問題,および潜在的な解決策について説明します.
ステップ1：資産の特定とCPEの割り当て
ここでの目的は,各製品や製品ファミリーの標準的な命名規則を通じて,製品クラスを命名するための標準化されたアプローチを定義することである.MITREはCPEと呼ばれるものを作成し,製品とその脆弱性に関する情報を共有するための標準を提供している.適切な命名規則がなければ,脆弱性に関する情報を共有することは非常に困難である.
資産を特定するには通常3つの方法がある：
- 手作業による特定：データシートを読んだり,デバイス設定に使用するソフトウェア内の関連プロジェクトファイルにアクセスしたりして,各デバイスを徹底的に調査すること.
- パッシブ・ネットワーク・ベースの識別：デバイスのトラフィックをリスニングしてフィンガープリントを作成する.
- アクティブ・ネットワーク・ベースの識別：フィンガープリントに必要なすべての値を読み取るためにデバイスに問い合わせること.
手作業による識別は拡張性に欠け,信頼性に欠ける可能性があるため,手作業のみによる識別はお勧めできない.大量のデータを効率的に処理するには限界があり,エラーの可能性も高くなる.
パッシブ・アセット識別ストラテジー(AIS)は,より効率的でスケーラブルであり,ネットワーク・パ フォーマンスに大きな影響を与えない.これは,Nozomi Networks で使用されている主なアプローチである.有益ではあるが,すべてのデバイスが正確な CPE をパッシブに生成するために必要なすべての情報を通信するわけではないという限界がある.たとえば,脆弱性は PLC が使用する特定の CPU 構成に直接影響する可能性がありますが,PLC は使用する CPU のモデルを送信しない可能性があります.パッシブAISの際,組織は,この種の脆弱性に関連するサイバーリスクを評価する際に,製品モデルとCPU構成の両方を考慮に入れる必要がある.もう一つの問題は,デバイスによっては,生成するトラフィックを暗号化し,直接特定することを難しくしている場合があることだ.このような場合,VAはサイドチャネル検知に頼ることをお勧めする.
アクティブAISは,確かに最も強力な戦略である.なぜなら,認証されていない,または認証されたデバイスのクエリーを実施し,必要な情報をすべて抽出できるからである.しかし,これには代償が伴います.ネットワークやクエリーされたデバイス自体に,より多くの負荷がかかる可能性があるからです.さらに,認証されたクエリーを実行することで,セキュリティ・リスクが発生したり,適切に実装されていない場合,デバイスが壊れたりする可能性があります.
現在,広く使われているCPEの規格は,バージョン2.2と2.3の2種類である.
- バージョン2.2はシンプルに見えるかもしれないが,属性が少なく,汎用性が低い.
- バージョン2.3はバージョン2.2に取って代わり,WFN(Well-Formed CPE Name)を導入し,CPEユーザーコミュニティから提案された新機能を追加する.さらに,URIバインディングを使用したバージョン2.2との下位互換性がある.
NISTによると,「CPEバージョン2.3は,CPE標準をスタックに編成された一連の個別仕様に分割することで,過去のCPEの慣行から大きく逸脱している：ネーミング,ネームマッチング,辞書,言語である.ネーミングはスタックの基礎であり,各仕様はそれ以前の仕様の上に構築される."
URIバインディングは,WFNを機械可読エンコーディングに変換するプロセスであり,可逆的であり,2.3 CPE仕様で定義されている.
WFNの例,CPE 2.3：
URIバインディングWFN：
上に示したように,URIバインディングを使用する場合,バージョン2.2との互換性を持たせるために属性の数は限られている.実際,旧バージョンは次のような構造になっている：
つまり,上の例のように,1つの属性により多くのデータを詰め込む必要があります.したがって,CPE 2.3フォーマットは以前のものよりも汎用性が高くなっています.
このステップに関連するすべての問題を簡単に解決するには,適切なCPEを使用するだけでは不十分である.製品はしばしば別のベンダーから購入されるため,CPEのベンダーが変わったり,製品名が変更されたり,バージョンに一貫性がなくなったりする可能性がある.さらに,過去と現在の製品間のCPEの粒度は,さまざまな標準に従う可能性がある.
このような課題に対処するため,私たちは個々の製品にカスタマイズしたソリューションを導入し,手作業と自動化された技術を組み合わせてNVDからのデータを改善し,標準化するために多大な努力を払っています.
この種の問題の一例は,Hikvisionのサブベンダーのネーミングである.Hikvisionは多くのベンダーのカメラ,DVR,その他のデバイスを製造しており,それらのデバイスに自社のブランドを表示しています.これらのデバイスはSADPプロトコルを使用してネットワーク経由で情報を送信します.このアプローチの問題点は,SADP プロトコルからベンダー名を抽出して適切な CPE を作成することができないことです.これを解決し,適切な CPE を作成するために,他の方法でベンダー名を抽出できる自動化ツールを構築することに成功しました.
ステップ2：公表されたCVEの特定
このステップはタイミングがすべてである.CVEがベンダーアドバイザリなどの一次情報源からリリースされた場合,NVDがそのCVEに関する情報をレビューして配布するまでに数週間から数カ月かかることがあります.
このため,理論的には現存するすべての一次情報源を速やかに解析できるはずだ.このアプローチを拡張するのは難しい.というのも,それらはさまざまなフォーマットで配布されており(その数は多い),手作業で多くの労力を必要とするからだ.
この問題を克服するために,いくつかの大規模なベンダーは,標準的なフィールドを持つJSONファイルであるCommon Security Advisory Framework(CSAF)形式でアドバイザリを配布し始めており,誰にとっても簡単になっている.以下の図2を参照：
この規格はデータの一貫性を提供するものではあるが,大手のベンダーが微妙に異なる方法で使用しているのに対し,中小のベンダーは使用すらしていない.つまり,高品質の製品を顧客に提供するためには,データの正規化とエンリッチメントが必要なのだ.
ステップ3：CVEとCPEのバインド
最後に,どのCVEが組織に影響を及ぼすかを判断するために,CVEを正しいCPEに関連付けることが極めて重要である.このステップの重要な成功要因は,正確性を維持し,情報が最新であることを保証することである.
CVEに特定の製品の脆弱性をマークする場合,好きなだけ具体的にすることができます.いくつかの例を見てみよう：
- 製品アドバイザリーの例1："脆弱な拡張機能が有効になっているソフトウェアのバージョンは13.3以下"
- 脆弱な拡張機能がインストールされているかどうか,ましてや有効になっているかどうかを常に特定できるわけではないので,トレードオフをしなければならない.
- 製品アドバイザリ例 2: "PLC XYZ がポート 3 で Modbus プロトコルを使用するように設定されている場合".
- CPEの命名仕様によると,インストールされた製品のユーザー定義コンフィギュレーションを表すバージョン2.3は対象外である.
上記の例を踏まえると,CPE以外にもデータ収集を拡大することで,結果の精度を向上させ,プロセスをより効果的なものにすることができる.それが不可能な場合は,偽陽性と偽陰性の最適なバランスを見つける必要がある.特異度(真陰性率)よりも感度(想起率)を優先することが望ましい.しかし,感度を上げると過剰な偽陽性が発生し,プロセス全体が非効率になる可能性があるため,感度を上げることによる増分コストを理解することが重要である.
最適なデータ品質を得るためには,CVE が公開された後,パッチがリリースされ,さらなる調査が行われるにつれて,影響を受ける製品が変更される可能性があることに留意することが重要です.通常,CSAF アドバイザリおよび NVD は,CVE の更新に関する通知を効率的に提供します.
概要
ICSの脆弱性評価は多くの組織にとって重要なプロセスであるが,これらのステップは見かけほど単純明快ではないことが多い.識別と報告のエコシステムには非効率性があるものの,CVEがリリースされたときに迅速に対応することが重要である.これを達成するためには,自動化と手作業の両方を駆使してNVDとベンダーアドバイザリの両方に頼ることで,高い精度で障害を克服することが可能だ.
