機械学習に基づく自動脆弱性修復分析法

機械学習に基づく自動脆弱性修復分析法

[[393588]]

まとめ
ファームウェア/ソフトウェアのセキュリティ脆弱性はグリッド セキュリティに重大な脅威をもたらすため、電力会社は脆弱性が発見されたらすぐにその修復方法を決定する必要があります。電力業界では、考慮すべき要素が多く、パッチ適用とサービスの信頼性のバランスが重要であり、対処すべき脆弱性の数が多いため、修復の決定を下すのは困難な作業です。残念ながら、現在、修復の決定は手動で行われており、長い時間がかかります。これにより、セキュリティ リスクが増大し、脆弱性管理コストも高くなります。本稿では、電力会社の修理決定分析を自動化するための機械学習ベースの自動化フレームワークを提案します。私たちはこれを電力会社に適用し、同社から入手した 2 つの実際の運用データセットに対して広範な実験を実施しました。結果は、このソリューションが非常に効果的であることを示しています。

第1章 はじめに
ソフトウェア/ファームウェアの脆弱性は、敵対者がそれを悪用して電力システムのコンピューターやデバイスを制御し、破壊的な攻撃を仕掛ける可能性があるため、グリッドのセキュリティにとって重大な脅威となります。したがって、脆弱性とパッチ管理(VPM)は、現在の電力網セキュリティの重要かつ不可欠な要素の1つです[1]。すべての公益事業会社 (電気を生成、送信、および/または配電する会社) は、セキュリティ オペレーション センターに VPM メカニズムを導入しています。資産の 1 つにセキュリティ上の脆弱性が発見された場合、公益事業会社はセキュリティ リスクを軽減するために脆弱性を迅速に修復する方法を決定する必要があります。

電力会社にとって、修理の決定を下すのは容易ではありません。まず、パッチを適用することで脆弱性を修正できますが、パッチを適用すると資産の再起動が必要になり、サービスが中断されることが多いため、脆弱な資産にパッチを適用することが常に可能であったり、望ましいとは限りません。したがって、緊急パッチはすぐにインストールされますが、公益事業会社は通常、四半期ごとに資産に他のパッチをインストールするなどのメンテナンス スケジュールに従います。すぐに対処する必要があるものの、パッチを適用すると重要なサービスに支障をきたす可能性がある脆弱性については、まず脆弱性を軽減してから、次のメンテナンス サイクルでパッチを適用することができます。第二に、脆弱性のセキュリティリスクはそれぞれ異なります。たとえば、ユーザーのブラウザアクティビティが持続する監視制御およびデータ収集 (SCADA) オペレータワークステーション上の Google Chrome の脆弱性は、インターネットにアクセスできないアプリケーションサーバー上のインターネットブラウザの脆弱性とはまったく異なるリスクになります。組織は前者に対しては直ちに対応する必要がありますが、後者については今のところ保留しても問題ありません。修復の決定では、限られたセキュリティ リソースの使用を最適化するために、リスクに基づいて脆弱性の優先順位を反映する必要があります。第三に、修復の決定では、脆弱性に悪用可能なコードがあるかどうか、脆弱な資産にインターネットからアクセスできるかどうか、脆弱性の影響、パッチによって送電サービスが中断されるかどうかなど、脆弱性と資産の多くの要素を考慮する必要があるため、複雑な推論プロセスになります。 4 番目に、適用可能なセキュリティ脆弱性の数は、組織がアプリケーション リスク分析を実行する能力を超えることがよくあります。過去2年間で、米国国立標準技術研究所(NIST)の国家脆弱性データベース(NVD)によると、発見され公表されたソフトウェアセキュリティの脆弱性の数は2倍以上に増加しています[2]。電力会社では、毎月数百以上の資産に数百、あるいは数千の脆弱性が存在することも珍しくありません。

残念ながら、現在、電力会社による修復の決定は主に手作業で行われています。その結果、脆弱性の修復アクションの決定に長い遅延(多くの場合、数週間)が発生します。この長い遅延により、是正措置の適用が遅れ、高い安全上のリスクが生じます。手動分析には多くの人的時間が消費されるため、VPM のコストが増加します。

この問題に対処するために、電力会社向けの修復決定分析を自動化する機械学習ベースのフレームワークを提案します。アイデアは、脆弱性の特性と資産の特性に予測機械学習モデルを適用して、各脆弱性の修復決定を予測することです。このモデルは、過去の手動修復決定データに基づいて構築され、人間のオペレーターが決定を下す方法をキャプチャして模倣しますが、手動分析よりも迅速に決定を下すことができます。その結果、修復の決定にかかる待ち時間が大幅に短縮され、セキュリティ リスクが軽減されるとともに、手作業の労力が減るため VPM のコストも削減されます。注目すべきは、当社の機械学習アプローチは是正の決定のみを推奨し、予測された決定を受け入れるか受け入れないかの最終権限は人間のオペレーターが持つということです。

機械学習ベースの自動化フレームワークは、電力業界に関連する 2 つの最近の開発成果を活用しています。まず、北米電力信頼性協会(NERC)の重要インフラ保護(CIP)バージョン5 [3] の規制要件では、ベースライン構成を維持することが求められており、これにより、電力会社全体で適切なソフトウェア資産情報が利用可能になります。第二に、NIST NVDおよびサードパーティのサービスプロバイダーを通じて、適切にフォーマットされ、機械可読な脆弱性情報の可用性がここ数年で大幅に向上しました[2]。

この論文の貢献は次のように要約されます。

私たちの知る限り、これは、現在電力会社や他の多くの組織で手動で行われている、VPM での修復決定分析の自動化の実現可能性を調査した最初の研究です。この自動化により、脆弱性をよりタイムリーに修正してセキュリティが向上するだけでなく、VPM に必要な人的時間が短縮されるためコストも削減されます。この研究は、セキュリティ運用に機械学習を適用することの価値も実証しています。

運用環境における脆弱性シグネチャと資産特性に基づいて修復アクション分析を自動化する機械学習ベースのフレームワークを提案します。学習モデルとして決定木を選択したのは、それが人間の推論に似ており、必要に応じてオペレーターが予測を検証するための推論コードを生成できるためです。また、検証を容易にするために推論コードを簡素化する方法を設計し、資産機能のメンテナンスを簡素化するためのグループベースの資産管理アプローチを提案します。このフレームワークは電力会社を念頭に置いて提示されていますが、他の多くの組織にも適用できます。

私たちは電力会社向けのフレームワークをインスタンス化し、電力会社から取得した 2 つの 1 年間のデータセットに対して広範な実験評価を実施します。評価結果は、この方法が非常に効果的であることを示しています。

この論文の残りの部分は次のように構成されています。セクション 2 では関連する作業を確認します。第 3 章では、現在の公益事業会社の VPM の実践について説明し、調査の結果を示します。セクション 4 では、機械学習ベースの自動化フレームワークについて説明します。第5章では、電力会社におけるフレームワークの例を紹介します。第6節では評価結果を示します。最後の 2 つのセクションでは議論が示され、論文の結論として機能します。

第2章 関連研究
GFI LanGuard [4]、ManageEngineのPatch Manager Plus [5]、SolarWindsのPatch Manager [6]など、企業で使用できるVPMソリューションは数多くあります。ただし、これらのソリューションは、脆弱性修復リソースを最適化するために必要な意思決定ではなく、脆弱性の検出とパッチの展開に重点を置いています。 Doble EngineeringのPatchAssure[7]、Flexera[8]、FoxGuard Solutions[9]など、ユーティリティVPM向けに設計されたソリューションのほとんどもこのカテゴリに分類されます。運用環境の脆弱性分析を実行したり、脆弱性を解決する方法を決定することができません。

脆弱性の解決に関しては、公開されている情報源がいくつかあります。 NIST NVD [10]は、脆弱性データとそれらが報告する関連情報の、構造化され信頼性の高いソースを提供しています。 Vulners[11]には脆弱性情報を検索し、利用可能なエクスプロイトを発見するための自由にアクセスできるAPIがあり、Exploit Database[12]ではユーザーが利用可能なエクスプロイトを検索することもできます。

学術界でもこの分野の研究が行われています。 [13]と[14]は大規模な脆弱性データセットを分析し、脆弱性の属性と開示日の傾向を報告した。 [15]、[16]、[17]は、パッチがリリースされてからパッチがインストールされるまでの時間枠や脆弱性が効果的に保護されるまでの時間枠など、パッチとパッチの動作を分析しました。 [18]、[19]、[20]、[21]では優先順位をつけたパッチ適用アプローチについて説明している。 [22]と[23]は攻撃グラフに基づいてネットワーク攻撃のリスクを分析した。しかし、これらの作業では、脆弱性の修復に関する決定を分析するために、脆弱性のメトリックを組織の固有の環境に統合していません。私たちの以前の研究[24]は、電力会社の脆弱性修復の実践を実証的に分析した最初の研究であったが、修復措置を予測するものではなかった。機械学習はソフトウェアやソースコードの脆弱性を発見するために適用されてきました[25][26][27][28][29]–[30]、攻撃を検出するために適用されてきました[31]、[32]、しかし私たちの研究では機械学習を使用して脆弱性を修正する方法を決定します。

機械学習に基づく自動脆弱性修復分析方法 図1. 脆弱性とパッチ管理プロセス

第3節 電力業界におけるVPMの現状
このセクションでは、電力業界団体の現在の実践について説明します。米国国土安全保障省(DHS)によるVPMの推奨プラクティス[33]によれば、図1に示すように、脆弱性が発見された場合、組織はまず脆弱性情報と資産情報の両方を考慮し、脆弱性がシステムに影響を与えるかどうかを分析し、パッチ適用や緩和策などの脆弱性に対する是正措置を決定する必要がある。

公的機関がVPMを実際に実施するのは容易ではありません。ほぼ毎日、新たな脆弱性が発見され、新たなパッチがリリースされています。公益事業会社は、脆弱性を分析し、改善策を決定するために、かなりの時間と人的資源を費やす必要があります。 NERC CIP 標準では、セキュリティの脆弱性とパッチを特定して評価するための厳格な月次義務が求められます。基準の遵守は NERC を通じて厳密に監視され、定期的に罰金が課せられます。同様に、電力業界にはこれらの規制を厳格に遵守するための懲罰的インセンティブがあります。

現在の慣行についてさらに詳しく知るために、電力業界で調査を実施しました。この調査は、国家重要インフラ保護機構を通じて公益事業会社に広く配布され、コンプライアンス規制に密接に関連する情報共有の制限のため匿名で実施されました。 16の電力会社から回答を得た。回答した組織の 100% が脆弱性とパッチの手動分析を実行しています。これらの企業の約 60% は、毎年 3,000 件を超えるセキュリティ脆弱性に対処する必要があり、調査対象企業の半数は毎月 400 時間以上を VPM に費やしています。それらはすべて脆弱性とパッチの履歴を保持しています。調査では、VPM が公益事業会社にとって確かに時間と労力を要する作業であることがわかりました。

セクション 4: 機械学習ベースの修復アクション分析フレームワーク
セキュリティ運用担当者は、脆弱性の修復アクションを決定する際に多くの要素を考慮します。これらの要素には、脆弱性が整合性、可用性、機密性に影響を与えるかどうか、脆弱性が悪用されたかどうか、共通脆弱性評価システム(CVSS)スコアが何であるかなどの脆弱性情報が含まれます[34]。さらに、これらの要素には、脆弱なデバイスがグリッド運用にとって重要なフィールド デバイスであるかどうか、脆弱なデバイスが機密性/整合性/可用性攻撃に対して敏感であるかどうか、ソフトウェアが何であるかなどの資産情報も含まれます。たとえば、脆弱性が重要でないデバイスに存在し、影響が小さく、悪用可能な脆弱性がまだ存在しない場合は、今すぐ対処する必要はなく、次の計画サイクル (Patch-Later と表現) でパッチを適用できます。脆弱性が悪用される可能性があり、ユーザー ワークステーション上にある場合は、直ちにパッチを適用することが決定されます (Patch-Now で示されます)。脆弱性が重要なサーバー上にある場合は、サーバーにパッチを適用するとグリッド サービスに影響する可能性があるため、まず脆弱性を軽減し、次の計画サイクルでパッチを適用することが決定されます (Mitigate-Now-Patch-Later で示されます)。

このプロセスは面倒で反復的なので、是正措置の分析を自動化することを提案します。直感的には、一連のルール(各ルールはすべての要因の要因値の組み合わせとこの組み合わせの決定で構成される)を手動で作成し、それを使用してエキスパートシステム[35]に似た自動是正措置分析を実装することを検討できます。しかし、ルールベースの分析には実際的な課題があります。それは、考えられるすべての状況をカバーするために、ルールの数が指数関数的に増加することです。たとえば、当社の公益事業パートナーの 1 社では、それぞれに何らかの価値がある約 16 の要素が考慮されていました。因子値の可能な組み合わせの総数は約2400億です。まず第一に、ルールを動的に維持および更新するどころか、これほど多くのルールを手動で生成することは現実的ではありません。

図2: 自動脆弱性修復分析のための機械学習ベースのフレームワーク

分析を自動化するために機械学習を使用するアプローチを採用しました。私たちは、脆弱性を自動的に分析し、脆弱性と資産の特性に基づいて、今すぐパッチを適用するか、パッチ適用を次の定期メンテナンス サイクルまで延期するかなど、修復の決定を予測する機械学習ベースの修復決定分析フレームワーク (図 2 を参照) を提案します。フレームワークの中核となるのは、改善措置だけでなく、オペレーターが予測をより正確にしたい場合に備えて簡単に検証できる理由コードも出力する機械学習モデルです。モデルは、脆弱性情報、資産情報、および一連の脆弱性に対する人間による修復決定を含む過去の運用データからトレーニングできます。第 3 章で説明する業界調査では、調査対象のすべての電力会社が過去の運用データを保持していることが示されています。これは、VPM の規制要件により電力業界では予想されています。私たちのフレームワークは、セクション 3 で説明した DHS ガイダンスと一致していますが、機械学習ベースの自動化を導入し、より詳細な情報を提供しています。

この研究の目標は、機械学習による予測を人間の意思決定者と同じくらい正確にすることです。これにより、脆弱性に対する修復の決定がより迅速になり、より迅速な対応が可能になるため、セキュリティ リスクを軽減できます (分析についてはセクション VI-H を参照)。手動による決定は最適または正確ではない可能性があることを認識しており、人間のオペレーターよりも優れた決定を下す方法の研究は今後の課題として残しています。

機械学習に基づく自動脆弱性修復分析法 表1: 脆弱性の特徴

A. 脆弱性の特徴づけと管理

NVD には十分に確立された脆弱性特性があります。 NVD では、各脆弱性には、さまざまな側面から脆弱性の特性を表す一連の CVSS インジケーターが付属しています。私たちのフレームワークでは、リスク評価と修復決定分析に関連しているため、CVSS インジケーターを脆弱性特性として使用します。これらの機能とその可能な値は表 I に示されています。 CVSS スコアは、メトリックによって決定される 0 から 10 までの数値であり、一般的に、脆弱性の全体的な重大度を表すために使用されます。攻撃ベクトルは、ネットワークやローカル アクセスなどを通じて脆弱性が悪用される方法を示します。悪用可能性は、脆弱性が悪用される可能性を示します。 「高」は最も高いレベルで、脆弱性コードがすでに広く存在していることを示し、「未確認」は最も低いレベルで、脆弱性コードが存在しないことを示します。その間に 2 つのレベルがあります。ユーザー インタラクション (権限、それぞれ) は、攻撃者が脆弱性を悪用するために必要なユーザー インタラクション (特権レベル、それぞれ) の量を示します。他の 4 つのメトリックは、機密性、整合性、可用性の観点から、攻撃の複雑さと攻撃の影響を説明します。これらの指標の詳細な説明は[34]に記載されています。

NVD はさまざまなソフトウェア製品の脆弱性を毎日公開しています。各脆弱性は、CVE-2016-8882 などの一意の Common Vulnerabilities and Exposures (CVE) ID によって識別されます。組織は、資産の共通プラットフォーム列挙(CPE)名[10]を識別し、CPEを使用してNVDにクエリを実行することで、資産の脆弱性(CVEや脆弱性シグネチャを含む)を取得できます(NVDはこのようなクエリ用のAPIを提供しています)。 CPEは、適用可能な脆弱性を自動的に検索できるように構造化されたソフトウェアを表す命名標準です[36]。組織は資産の CPE を一度手動で識別すれば、更新を必要とせずに何年も使用できるため、メンテナンス コストが低くなります。

学習フレームワークは汎用的であり、企業が使用する可能性のあるその他の脆弱性機能 (サードパーティのサービスによって提供されるその他の機能など) をサポートできることは注目に値します。さらに、企業が修復決定分析で CVSS インジケーターのサブセットのみを使用する場合、学習モデルはそれらのインジケーターに基づいて構築できます。

B. 資産の特性と管理

脆弱性シグネチャには、公開された脆弱性情報を維持するための確立された CVE 標準がありますが、脆弱性シグネチャだけでは、個々のネットワーク資産に対して意味のある修復分析を実行するのに十分な情報が提供されません。インターネット経由で直接サービスを提供する脆弱なシステム (Web サーバーなど) の扱いは、高度に制御されたローカル ネットワーク内の分離されたシステムに適用される同じ脆弱性の扱いとはまったく異なります。同様に、ブラウザの脆弱性は、Web プロパティごとに大きく異なる形で適用されます。明らかに、電子メールと Web 閲覧を主目的として使用されるオフィス コンピュータは、偶然同じブラウザーがインストールされている、ユーザーとのやり取りがほとんどないサーバーよりもはるかに脆弱です。 NVD CVSS システムでは、環境スコアを計算するために、機密性要件、整合性要件、可用性要件という 3 つの資産特性を使用することを推奨しています。ただし、これら 3 つの特性だけを使用するだけでは不十分であり、セキュリティ オペレーターは他の特性も考慮する必要があります。たとえば、ネットワークを通じて侵入が発生する可能性がある場合、資産が外部からアクセス可能かどうかが重要な要素となります。したがって、これら 3 つの特性を補完する 2 つの資産特性をさらに特定しました。環境 CVSS システムとのもう 1 つの違いは、当社のアプローチでは、単純な数式を使用して環境スコアを計算するのではなく、機械学習を使用してこれらの機能を意思決定モデルに組み込むことです。これら 5 つの特徴について以下に説明します。

ワークステーション ユーザーがログインします。 (はいまたはいいえ) – 脆弱性のユーザー インタラクション機能に関連しており、ネットワーク アセットが人間のオペレーターに対話型ワークステーションを提供しているかどうかを意味します。資産にインタラクティブな使用機能がない場合、Web ブラウザなどのアプリケーションに影響を及ぼす脆弱性の影響は大幅に軽減されます。

外部アクセス可能。 (高、認証のみ、または限定) - 脆弱性の攻撃ベクトル特性に関連し、ネットワーク資産がネットワーク システムの外部から外部アクセス可能な程度を示します。たとえば、「高」はパブリック コンテンツを提供する Web サーバーを指し、「認証のみ」は使用前にログインが必要なリモート アクセス アプリケーション サーバーのセットを指します。制限とは、外部ネットワークに直接接続できないことを意味します。

機密保持要件。 (高、中、低) – 脆弱性の機密性影響特性に関連付けられており、資産の機密性要件が高いかどうかを示します。

整合性要件: (整合性要件)。機密保持要件に似ていますが、整合性に重点が置かれています。

可用性の要件。機密性要件に似ていますが、可用性に重点を置いています。

企業は実際の状況に応じて、独自のニーズを満たすためにいくつかの資産機能を追加/削除できます。

コミュニティベースの資産署名管理 ソフトウェアの脆弱性署名セットには、一貫した機械可読署名 (NVD 経由など) を維持する世界規模のコミュニティがありますが、ネットワーク資産署名は組織によって維持される必要があります。当社の調査によると、組織には何千もの資産があり、資産は頻繁に変更される可能性があります (つまり、資産が削除または追加される可能性があります)。資産の数が多く、動的に変化するため、各資産の特性値を分析して維持することは非常に面倒です。メンテナンスコストを削減するために、資産を役割や機能に基づいて資産グループに分割します。たとえば、特定の製造元および機能を持つすべてのリモート ターミナル ユニット (RTU) は、同様の機能を持っているため、グループ化できます。同様に、すべてのファイアウォールをグループ化することもできます。同じグループ内の資産は、同じ資産特性値のセットを共有します。その後、人間のオペレーターが各グループの特徴値を決定し、維持することができます。電力会社を対象とした当社の実験では、資産数が大幅に増加しても分類グループはほぼ一貫していました。たとえば、コントロール センターにオペレータ ワークステーションが 5 台あっても 100 台あっても、その特性は同じです。資産は現れたり消えたりするものですが、まったく新しい資産グループが出現することは非常に稀です。グループの数はアセットの数よりもはるかに少ないため、グループ化によって特徴値を維持するために必要な作業量が大幅に削減されます。

C. 機械学習アルゴリズムの選択

現在、多くの機械学習アルゴリズムが利用可能であり、問​​題を解決するために最適なものを決定する必要があります。このフレームワークでは、次の理由により、修復アクションの分析を自動化するために意思決定ツリー モデルを採用しています。 (1)決定木に基づく意思決定は人間の推論に似ている。ツリーの各レベルで、モデルは最も重要な要素を選択し、要素の値に基づいて問題空間を複数のブランチに分割します。ニューラル ネットワークやロジスティック回帰など、透明性があまり高くない他の多くの機械学習モデルとは異なり、決定木モデルでは、モデルの各ステップを確認し、モデルがどのように決定を下すかを知ることができます。したがって、決定木の予測を解釈し、予測を説明する理由コードを導き出すことができます。人間のオペレーターは理由コードに基づいて予測結果を検証できます。 (2)このVPM自動化問題に関して、我々の実験では、決定木は他のいくつかの機械学習アルゴリズムと比較して非常に優れた性能を示すことが示された。

説明のために、図 3 は修復アクション分析のコンテキストでトレーニングされたサンプルの決定木モデルを示しています。このツリーに基づく脆弱性予測プロセスは次のとおりです。新しい脆弱性データ レコードが予測のためにモデルに入力されると、モデルは最初にルート ノードの悪用可能性機能を調べます。脆弱性が未証明でない場合は、資産機能「ワークステーション ログイン」がチェックされます。ワークステーションがユーザーのログインを許可している場合は、リスクが大きくなるため、すぐにパッチを適用する必要があります。他のブランチも、他のレコードを通じて同様に走査できます。

図3: 訓練された決定木モデルの例

D. 理由コード生成

予測機械学習ツールが 100% 正確であることは困難です。予測決定の透明性を高めるために、私たちのアプローチでは、予測の信頼性とモデル選択決定の理由(理由コードと呼ばれる)の読みやすい説明を人間のオペレーターに提供します。決定木を使用すると、正当化コードの生成が可能になります。トレーニングされた決定木モデルは、ツリー構造に編成された接続ノードとセグメンテーション ルールのコレクションです。次に、ツリー パスをトラバースし、パス内のノード分割ルールを組み合わせることで、foreach リーフ ノード (決定ノード) の理由コードを取得できます。ただし、一部の長いパス (たとえば、ユーティリティのデータに基づいて構築したツリーに 18 個のノードがあるパスがあった場合) では、分割ルールを単純に組み合わせると、正当化コードが非常に長くなり、冗長になり、読みにくくなる可能性があります。この問題に対処するために、決定パスから導出された元の理由コードを簡素化および短縮する 2 つのルールを使用します。

交差: 範囲の交差を見つけることで冗長性を減らすことができます。たとえば、CVSS スコアなどの連続データの場合、理由コードの 1 つの条件が「CVSS スコアが 5.0 より大きい」であり、もう 1 つの条件が「CVSS スコアが 7.0 より大きい」である場合、交差を見つけることができ、理由コードを「CVSS スコアが 7.0 より大きい」と簡略化できます。

完了: パスの複数の条件で表示される一部の機能については、これらの条件を完了条件に置き換えることができます。たとえば、整合性の影響の場合、可能な値セットは、完全、部分的、なしです。たとえば、理由コードが「整合性の影響はなしではなく、整合性の影響は部分的ではない」の場合、部分的となしの補完条件は完全であるため、理由コードは「整合性は完全である」と簡略化できます。

セクション 5. フレームワークの例。電力会社の事例研究
機械学習ベースのフレームワークが現実世界でどの程度機能するかを調査するために、電力会社の VPM 運用プラクティスとデータに基づいてフレームワークを適用し、インスタンス化しました。 VPM の運用情報は機密性が高いため、同社から社名を匿名にするよう依頼されたため、この記事では OrgA と呼ぶことにします。

このフレームワークインスタンスでは、使用される脆弱性機能は CVSS インジケーターの 9 つの属性です (表 1 を参照)。使用される資産特性は、ワークステーションのユーザー ログイン、外部アクセス可能性、機密性要件、整合性要件、および可用性要件です。これらの機能は、人間のオペレーターが復元の決定を行うときに使用するものです。オペレーターが使用できる修復アクションは、「今すぐ修正」、「今すぐ軽減」、「後で修正」、および「後で修正」です。

資産の特性を取得するには、まず会社のベースライン構成管理ツールから資産のリストを取得します。その後、資産は機能に基づいて 43 のグループに分割されました。各資産グループについて、各資産特性の値を決定します。企業にとって、これらの資産特性と特性値は非常に安定しており、数年にわたって変更する必要はありません。脆弱性と脆弱性の特性を取得するために、ベースライン構成管理ツールでも利用できるソフトウェア/ファームウェアの名前とバージョンに基づいて、各ソフトウェア/ファームウェアの CPE が生成されます。次に、CPE をパラメータとして使用し、NVD の API を介して NVD に自動的にクエリを実行し、CVE および CVSS ベクトルを含む該当する脆弱性を NVD から取得する Python プログラムを開発しました。脆弱性検索は頻繁に実行する必要がありますが、Python プログラムによって自動化されます。ユーティリティの脆弱性を集約するサードパーティのサービスも、当社のフレームワークで使用できるものと同じ CVE および CVSS 情報を提供していることに注意することが重要です。

決定木は、ライブラリ Scikit-learn に基づいて Python で実装されています。公益事業会社は、過去の侵害、関連する資産、およびオペレーターが行った手動修復の決定など、VPM に関する運用データを保持します。これにより、ユーティリティの履歴データを使用して意思決定ツリー モデルをトレーニングできるようになります。 CVSS スコアを除き、すべての機能はカテゴリ別です。これらのカテゴリ値をワンホットエンコーディングを使用してバイナリデータに変換します。 CVSS スコアは 0 から 1 の間でスケーリングして正規化され、ツリーの分割度を測る尺度として Gini が使用されます。最良のパフォーマンスを達成するには、データセットに応じていくつかの決定木パラメータを調整する必要があることに注意してください (詳細についてはセクション VI-B を参照)。モデルのトレーニングが完了した後、新しい脆弱性が取得されると、その脆弱性と資産の特性がモデルに入力され、分析されます。

モデルは、予測決定、信頼度、理由コードという 3 つの情報を出力します。信頼値は 0 から 1 の間で、モデルの予測の信頼性を示します。たとえば、信頼性の低い予測を検証するなど、手動検証のための予測を選択する際にオペレーターをガイドできます。根拠コードは、人間のオペレーターが予測を理解し、検証するのに役立ちます。表 II は、3 つの異なる脆弱性の予測例を示しています。最初の例では、予測されたアクションが「後でパッチを適用する」であり、信頼度が 100% であることが示されています。この選択の根拠は、脆弱性が悪用不可能であり、CVSS スコアが 4.2 未満で資産への影響が低く、機密性への影響が中程度であることです。他の 2 つの予測も同様に解釈できます。

機械学習による自動脆弱性修復分析手法 表2: 3つの脆弱性の予測結果例

第6節 評価
このセクションでは、セクション 5 で説明したフレームワークのインスタンス化に関する実験結果を示します。

A. データセット

OrgA から 2 つのデータセットを収集しました。各データセットには 1 年間のデータが含まれています。データセットの 1 つは 2016 年 6 月から 2017 年 5 月の間に収集され、3,476 件の脆弱性データ レコードが含まれています。もう 1 つのデータセットは 2018 年 1 月から 12 月に収集され、3,660 件のレコードが含まれています。便宜上、これら 2 つのデータセットをそれぞれ 2017A と 2018A と呼びます。各脆弱性データ レコードには、関連するソフトウェア、脆弱性の特性、関連する資産、資産の特性などの情報が含まれます。さらに、各レコードには、脆弱性に対して人間のオペレーターが行った修復の決定が含まれます。

B. 決定木のパラメータ調整

ツリーが深すぎるのを防ぎ、過剰適合を避けるために、葉のノード内のサンプルの最小サンプル数(ノード内のサンプルの数が最小数を超えない場合、ノードは分割を停止します)とツリーの最大深度を適切に設定する必要があります。これらの2つのパラメーターは、展開環境に従って調整できます。実装では、ユーティリティ2017aデータセットを使用して、これら2つのパラメーターをチューニングします。具体的には、データセットの70%がトレーニングデータとしてランダムに選択され、他の30%がテストデータとして使用され、これら2つのパラメーターはテストパフォーマンスに従って調整されます。

葉のノード内のさまざまな最小サンプル数を実験し、結果を図4に示します。 「min_samples_leaf」は、葉のノードに必要なサンプルの最小数です。 「min_samples_leaf」が小さくなればなるほど、ツリーが分割され、ツリーが深くなります。図4に示すように、「min_samples_leaf」が8の場合、予測精度は最高で、97.22%です。ここで、予測の精度とは、人間のオペレーターが下した手動での決定と同一の予測された決定の部分を指します。 min_samples_leafが減少すると、ツリーが特殊すぎて新しいサンプルに一般化できないため、予測の精度が低下します。 「min_samples_leaf」が大きすぎる場合、ツリーがトレーニングデータに十分な詳細情報をキャプチャしないため、ツリーが短い場所で予測精度も低下します。したがって、残りの実験では、葉のノードの最小サンプル数を8に設定します。

機械学習に基づく自動脆弱性修復分析図4:min_leaf_samplesの予測。

図5:ツリーの深さの予測

異なる最大ツリー深度の下での予測精度を図5に示します。ツリーの深さが25を超えると、予測の精度は変わりなくなります。通常、最大の深さが大きい場合、ツリーをより深くすることで、過剰適合の問題が発生します。ただし、この場合、葉の最小数は8に設定されるため、葉のサンプルの数が8以下の場合、ツリーが分割され、したがって深く成長することはできません。残りの実験では、最大ツリーの深さを50に設定します。

C.予測精度

この実験では、組織ORGAの2つのデータセットでモデルをテストします。各データセットは、トレーニングで70%、テストで30%、2つの部分にランダムに分割されます。予測精度と偽陰性率を使用してパフォーマンスについて説明します。偽陽性率は、手動の決定がパッチノウまたは緩和されたパッチレーターである予測の一部として定義されますが、予測結果は後でパッチです。誤検知は、より迅速に対処する必要がある脆弱性の修正を遅らせるため、最小限に抑える必要があります。結果は図6に示されています。 2017Aデータセットの場合、予測精度は97.02%で、偽陰性率は1.24%です。 2018Aデータセットの場合、予測精度は98.82%で、偽陰性率は1.09%です。精度は非常に高いため、機械学習を使用して修復アクションを予測することが可能です。

誤った予測の調査機械学習予測の精度はすでに非常に高いですが、誤った予測の原因を理解したいと考えています。 2017Aデータセットの場合、誤った予測の2.98%を調査した後、これらの誤った予測は、同じ特性を持ついくつかの脆弱性が、決定ツリー(そして実際に他の学習algorithm)を混乱させるために、履歴データセットに一貫性のない手動修復決定によって引き起こされることがわかりました。同じ問題は、2018Aデータセットの予測エラーにもつながります。

これが起こる理由はいくつかあります。公益事業会社には、複数のセキュリティオペレーターが脆弱性を分析し、修復決定を行うことができます。異なるオペレーターは、同じ特性を持つ脆弱性、あるいは同じ脆弱性についてさえ異なる決定を下すことができます。オペレーターが1つしかない場合でも、同じ特性を持つ2つのセキュリティの脆弱性を処理する際に、異なる時間(たとえば、先月と今月)を処理する場合、異なる決定を下すことができます。これは、明らかなリスクの高い端(通常はパッチノウと緩和型のパッチレーターに入る)または明らかな低リスクの端(通常はパッチを入力する)ではなく、中央にある脆弱性について、特に特に起こりそうです。これは、オペレーターが完全に回避することはできないヒューマンエラーです。

同じ機能を持つ脆弱性記録の各グループについては、この記録グループの決定の大部分が正しい決定であり、少数の決定がエラーと見なされ、データセットの約3%が削除されたと仮定した場合、2017a Datased exted exed exed exted exted exed exed exed exed efced exted efced efced exted efced efced exted efced efced exced excedの同様の改善。この結果は、トレーニングデータセットに一貫性のない人間の決定のケースが少ない場合、予測のパフォーマンスが大幅に改善できることを示唆しています。

また、同じ機能を持つレコードでは異なる人間の決定の場合、予測の信頼が比較的低くなることもわかりました。たとえば、意思決定ツリーのリーフノードには、まったく同じ機能を持つ4つのレコードが含まれており、そのうち3つがパッチノウによって改善され、1つはMitigate-now-Patch-laterによって改善されています。その後、決定ツリーは、0.75の信頼性を持って予測された決定としてパッチノウを出力します。オペレーターが比較的低い信頼レベルで予測を検証/修正できる場合(つまり、0.9未満)、2017Aデータセットの99.42%の精度と0.38%の偽陰性、および2018Aデータセットの99.45%の精度と0.09%の偽陰性にパフォーマンスを改善できます。予測の約10%のみが0.9未満の信頼レベルを持っているため、手動での検証はすべての是正決定を手動で行うよりもはるかに短い時間がかかります。

D.理由コード検証

各予測には、ユーザーが必要に応じて予測を検証できるようにする理由コードが伴います。ここでは、最初に理由コードの長さを研究します。コードがその長さを表す必要がある理由の条件の数を使用します。たとえば、正当化コード「未確認の悪用可能性、CVSSスコアは4.2未満、機密性の影響は中程度であり、3つの条件が含まれているため、3は3の長さです。セクションVI-Cで説明した予測では、理由コードの平均長は6.9条件です。セクションIV-Dで提案されている長さ削減ルールを適用した後、平均長は3.6条件に減少します。たとえば、「未確認の悪用可能性、CVSSスコア9.15、外部アクセシビリティが限られている、CVSSスコアが6.30未満、認証されていない外部アクセシビリティ、中程度の可用性インパクトが「6.3未満」、外部アクセシビリティが限られている」と緩和された程度の利用可能性、緩和された利用可能性、長さの削減ルールは、理由コードの長さを大幅に短くすることができ、理解して検証しやすくなります。

次に、正当化コードが正当化コードを検証するのに必要な時間を調べ、対応する脆弱性の元の特徴に基づいて予測を検証するために必要な時間と比較することにより、予測決定を検証するのに十分かどうかをテストします。これを行うために、テストデータから100の予測をランダムに選択し、Orgaの安全オペレーターに、理由コードと元の機能に基づいてこれらの予測を検証するように依頼しました。

結果は、100の理由コードのうち98が予測決定を検証するのに十分であることを示しています。コード検証の理由により、間違った予測があることがわかりました。別の理由コードは、予測を検証するのに十分ではありません。

元の機能に基づいた理由コードの検証と検証に費やされた時間を図7に示します。ほとんどの理由コードは、非常に短時間で検証できます。理由コードの35%は5秒で検証でき、理由コードの90%は45秒で検証できます。平均検証時間は28.8秒です。図からわかるように、元の機能に基づく検証は、理由コードに基づいて検証よりも時間がかかります。予測の35%のみが60秒以内に検証でき、予測の約40%が4分以上の検証時間を必要とします。元の機能に基づく検証の平均時間は7分です。結果は、理由コードの効率を示しています。これは、決定プロセスにおける判断条件の重要性に基づいてある程度それを優先し、考慮せずに重要でない要因を隠すことに基づいて、それをある程度優先する決定ツリーからコードが導き出される(および最適化された)理由であるため、これは合理的です。

図7:理由コードと機能ベースの検証時間

図8:毎月の予測精度

E.動的トレーニングによる予測

上記の実験では、12か月のデータがトレーニングデータとテストデータにランダムに分割されました。実際には、セクション4-Eで説明したように、決定ツリーモデルは動的に更新し、最近の履歴データを使用してトレーニングする必要があります。この実験では、動的トレーニングを通じてモデルの予測精度をテストします。特に、オペレーターは、検査と検証のために月あたりの予測の10%をランダムに選択すると想定しています。毎月、過去6か月間にオペレーターが手動でチェックした脆弱性と意思決定をトレーニングデータとして使用し、新しい決定ツリーモデルを訓練し、来月の状況を予測するために使用します。 2018Aデータセットの予測結果を図8に示します。 X軸は、どの月が予測されるかを示し、y軸は予測精度を示します。たとえば、X軸が7の場合、最初の6か月でデータの10%を使用してモデルをトレーニングし、7か月間の決定を予測し、2ヶ月目から7か月目にデータの10%を使用してモデルを訓練し、8か月目の脆弱性を予測します。異なる月の予測精度は異なることがわかりますが、全体的には非常に高いです。ダイナミックトレーニング中の2017Aデータセットの予測パフォーマンスには同様の傾向があります。したがって、動的トレーニングは実行可能です。

F.さまざまな機能セットの予測

上記の実験では、ソフトウェア名、脆弱性の特性、資産名、資産特性など、16の機能が使用されました。ここでは、予測のためのさまざまな機能の有用性を評価し、図9の2017Aデータセットで結果を示します。ソフトウェア名と資産名が特性として存在しない場合、予測の精度はわずかに低下します。ただし、ソフトウェア名、資産名、および資産特性(つまり、脆弱性の特性のみ)がない場合、予測の精度は83.78%に低下します。結果は、脆弱性の特性と資産特性の両方が重要であることを示しています。

機械学習に基づく自動脆弱性修復分析図9:さまざまな機能セットの予測

G.他のモードとの比較

意思決定ツリーモデルを、ロジスティック回帰、サポートベクターマシン(SVM)、NEVベイズ、K-ニアストネイバー(KNN)、およびニューラルネットワーク:他の人気のある機械学習モデルと比較します。 2017Aデータセットを使用して、それらの70%がトレーニングデータとしてランダムに選択され、残りの30%がテストデータとして使用されました。図10に示すように、決定ツリーモデルは他のモデルよりも優れています。ロジスティック回帰とニューラルネットワークのパフォーマンスは、決定ツリーに似ています。ただし、決定ツリーほど説明するのは簡単ではありません。

ニューラルネットワークの合理化に関する最近の作業を考慮して、決定ツリーとの包括的な比較のために、理由ジェネレーター[37]を使用してニューラルネットワークモデルを適応および実装しました。スペースの制限により、この記事では適応と実装の詳細が省略されており、この記事の拡張バージョンで提供されます。図10に示すように、決定ツリーは、予測の観点から理性ジェネレーターを備えたニューラルネットワークよりも優れています。理由コードに関しては、決定ツリーによって生成された理由コードの平均長は約4で、ニューラルネットワークの理由コードの平均長は約8.5です。理由コードが予測をサポートするのに十分である場合(セクションVI-Dを参照)、決定ツリーの短い理由コードは解釈/検証しやすくなります。

機械学習に基づく自動脆弱性修復分析図10:他の機械学習モデルとの比較

H.是正分析の遅延とコスト

意思決定分析の是正遅延ここでは、自動決定分析によってORGAの時間を節約する時間を分析します。まず、機械学習ベースのフレームワークに必要な時間を計算します。脆弱性分析と決定予測の時間はミリ秒であり、無視することができます。機械学習モデルが動的にトレーニングされている場合、セクション6-Eで説明したように、オペレーターは脆弱性予測の10%を検証する必要があります。セクション6-Dに示すように、予測検証の平均時間は28.8秒です。 2017Aデータセットでカバーされている3476の脆弱性の場合、Orgaの平均検証時間は2.3人の時間/月です(これは典型的な決定サイクルです)。オペレーターが1つしかないと仮定します。決定遅延は2.3時間になるため、2.3時間以内に完了できます。

セクション6-Dのテストによると、各脆弱性の手動分析の平均時間は7分でした。 ORGAの手動分析の合計時間は、1か月あたり33.8人の時間です。繰り返しますが、オペレーターが1つしかないと仮定します。理論的には、このタスクは33.8時間以内に完了することができ、意思決定が33.8時間遅れます。しかし、実際の作業では、タスクに長い時間がかかる場合、タスクを完了する合計時間は、人間の時間よりも単純になります。人間のオペレーターは、マシンのように1日24時間働くことができず、会議、報告、トレーニングなど、他の多くのタスクを実行する必要があります。これらの要因は、是正意思決定に追加の遅延を作成します。これは、数日または数週間の分析プロセスに及ぶことがあります。これは、セクション3で説明した調査でも検証されており、参加者の50%が各サイクルの是正措置分析を完了するために16日以上が必要だと述べています。

このスケッチ分析によると、機械学習による修復決定分析の完了の遅れは数時間になる可能性がありますが、手動の決定の遅延は数日または数週間になる可能性があります。脆弱性の修理の決定を早期に行うことができる場合、これらの高リスクの脆弱性(パッチを適用または軽減する必要がある脆弱性)を先に発見することができ、それによってそれらをより早く修復し、電力会社のセキュリティリスクを大幅に減らすことができます。したがって、機械学習フレームワークを使用してユーティリティが直面するリスクは大幅に削減されます。

是正コスト決定分析安全な操作のVPM問題は人事配分の問題であるため、機械学習によってもたらされる人事コストの節約を分析します。上記の遅延分析から、機械学習を通じて、Orgaは1か月あたり31.5人の時間を節約できることがわかります。この計算により、年間378人の時間を節約できます。大規模でより多くの資産を持つユーティリティの場合、節約はさらに大きくなります。たとえば、私たちの調査では、参加会社は年間12,000の脆弱性があると述べました。これにより、合計1,305人の時間が節約されます。

パート7:ディスカッション
提案されたフレームワークは電力会社でのみテストされていますが、国土安全保障省のガイドラインと一致しており、普遍的であり、同様のリスク予防管理の課題と制約に直面するため、他の多くの組織、特に重要なインフラストラクチャに適用できます。このフレームワークが他の組織に適用される方法は、電力会社の組織と似ていますが、決定された資産特性と是正決定は異なる場合があります。

場合によっては、操作環境が是正措置に影響を与える可能性があります。たとえば、脆弱性が勃発し、見出し(メルトダウンの脆弱性など)を作成すると、会社の管理者は、一般の評判からの圧力のためにできるだけ早く修正したい場合があります。その後、オペレーターは、脆弱性/資産の特性に基づく決定ツリーの予測が「後のパッチ」であっても、「パッチが後で」ではなく、「パッチが後で」ではなく、「パッチが今すぐ」 - 「パッチが後で」を選択することがあります。この場合、オペレーターは意思決定を使用して、決定ツリーの予測を上書きすることができます。

セクション8。結論
このペーパーでは、VPMの課題を解決するためのより効果的な意思決定支援の必要性に対処し、脆弱性の修復決定を自動的に分析するための決定ツリーベースのフレームワークを提案します。電力会社向けにカスタマイズされたフレームワークインスタンスをテストし、会社から取得した2つのデータセットをテストしました。結果は、高い予測の精度と時間の節約を示しています。これらの結果は、VPMプロセスを自動化するために機械学習を適用することの価値を示しています。

この記事は、翻訳された記事、記事の元の著者、記事のソース:ieeexplore.ieee.orgです
元のアドレス:https://ieeexplore.ieee.org/document/9162309

<<:  中国、米国、欧州における人工知能開発の現状の比較分析

>>:  AIはセルオートマトンを通じてMinecraftで家を建てることを学ぶ

ブログ    
ブログ    
ブログ    

推薦する

...

OpenAI: 大規模ニューラルネットワークをトレーニングするための 4 つの基本手法

この記事はLeiphone.comから転載したものです。転載する場合は、Leiphone.com公式...

プログラマーはアルゴリズム思考をどのように向上させることができるでしょうか?

[[255991]]継続的な学習と継続的な開発は、主流の IT 業界のプログラマーにとって日常的な...

アマゾンのドローン配送部門の主要メンバーが目標未達成で辞任

アマゾンのドローン配送部門プライムエアで安全、飛行運用、規制業務を担当していたショーン・キャシディ氏...

C# のデータ構造とアルゴリズムにおけるキューの簡単な分析

C# のデータ構造とアルゴリズムのキューは、リストの先頭での削除操作とリストの末尾での挿入操作のみを...

必要なのはこれら3つの機械学習ツールだけです

多くの機械学習技術は、急速に概念実証から人々が日常的に頼りにする重要なテクノロジーの基盤へと移行して...

この戦略は不安定なGANを安定させるのに役立ちます

敵対的生成ネットワーク (GAN) は、非常に幅広い応用が期待できる非常に強力なタイプのニューラル ...

PyTorch ライブラリの 95% がこのバグの影響を受けます。テスラのAIディレクターも例外ではなかった

[[393110]]この記事はAI新メディアQuantum Bit(公開アカウントID:QbitAI...

毎日のアルゴリズム: 回文部分文字列

[[434467]]文字列が与えられた場合、その文字列に含まれる回文の部分文字列の数を数えることがタ...

...

...

「顔スキャン」のリスクについてどれくらい知っていますか?

情報化の急速な発展に伴い、顔認証や指紋認証などの技術が徐々に普及しつつあります。技術の進歩によっても...

この世界規模の問題に対して、ドローンはどれほどの助けとなるのでしょうか?

火事を起こすのは簡単ですが、消すのは難しいです。これは世界的な問題ですが、これを効果的に予防し、迅速...

旅行リスクの特定: AI ソリューションが世界の COVID-19 安全マップを作成

州や自治体が新型コロナウイルスから国民を守るために制限措置を講じてきたため、ほぼ2年間、あらゆる種類...