脆弱性

2022.11.20

NIST NISTIR 8409 共通脆弱性評点システムの基礎評点の計算式の測定 (2022.11.15)

こんにちは、丸山満彦です。

意見募集をしていた、NISTIR 8409 共通脆弱性評点システムの基礎評点の計算式の測定が確定のようですね。。。

 

● NIST - ITL

・2022.11.15 NISTIR 8409 Measuring the Common Vulnerability Scoring System Base Score Equation

 

NISTIR 8409 Measuring the Common Vulnerability Scoring System Base Score Equation NISTIR 8409 共通脆弱性評点システムの基礎評点の計算式の測定
Abstract 概要
This work evaluates the validity of the Common Vulnerability Scoring System (CVSS) Version 3 "base score" equation in capturing the expert opinion of its maintainers. CVSS is a widely used industry standard for rating the severity of information technology vulnerabilities; it is based on human expert opinion across many sectors and industries. This study is important because the equation design has been questioned since it has features that are both unintuitive and unjustified by the CVSS specification. If one can show that the equation reflects CVSS expert opinion, then that study justifies the equation, and the security community can treat the equation as an opaque box that functions as described. この研究では、共通脆弱性評点システム (CVSS) Version 3の「基礎評点」式が、その保守者の専門的な意見を反映する上で有効であるかどうかを評価する。CVSSは、情報技術の脆弱性の深刻度を評価するための業界標準として広く利用されており、多くの分野や産業における人間の専門的な意見に基づいている。この研究は、CVSSの仕様では直感的でなく、正当化できない特徴を持つ方程式の設計が疑問視されているため、重要である。もし、数式がCVSS専門家の意見を反映していることを示すことができれば、その研究は数式を正当化し、セキュリティコミュニティは数式を説明通りに機能する不透明な箱として扱うことができる。
This work shows that the CVSS base score equation closely -- though not perfectly -- represents the CVSS maintainers' expert opinion. The CVSS specification itself provides a measurement of error called "acceptable deviation" (with a value of 0.5 points). This work measures the distance between the CVSS base scores and the closest consistent scoring systems (ones that completely conform to the recorded expert opinion). The authors calculate that the mean scoring distance is 0.13 points, and the maximum scoring distance is 0.40 points. The acceptable deviation was also measured to be 0.20 points (lower than claimed by the specification). These findings validate that the CVSS base score equation represents the CVSS maintainers' domain knowledge to the extent described by these measurements. この研究は、CVSSの基礎評点の式が、完全ではないものの、CVSSの保守者の専門家の意見を忠実に表していることを示している。CVSS仕様自体は、「許容偏差」(0.5ポイントの値を持つ)と呼ばれる誤差の測定法を提供している。この研究では、CVSSの基礎評点と、最も近い整合性のある評点システム(記録された専門家の意見に完全に適合するもの)との間の距離を測定している。著者らは、平均評点距離は0.13ポイント、最大評点距離は0.40ポイントと計算している。また、許容偏差は0.20ポイントと測定された(仕様で主張されている値より低い)。これらの結果から、CVSSの基礎評点式がCVSS保守者のドメイン知識をこれらの測定値で記述される程度に表していることが検証された。

 

・[PDF] NISTIR 8409

20221120-50144

 

目次...

Executive Summary エグゼクティブサマリー
1.  Introduction 1.  はじめに
2.  Common Vulnerability Scoring System 2.  共通脆弱性評点システ
2.1. CVSS Base Score Metrics 2.1. CVSS 基礎評点の評価基準
2.2. CVSS Base Score Equations 2.2. CVSS 基礎評点の計算式
3.  Rationale for the CVSS Base Score Equations 3.  CVSS基礎評点の算出根拠
3.1. Development of the CVSS Base Score Equation 3.1. CVSS基礎評点評価式の開発
3.2. Acceptable Deviation 3.2. 許容される偏差
4.  Metrology Tools, Metrics, and Algorithms 4.  測定ツール、測定基準、アルゴリズム
4.1. Knowledge Encoder Tool 4.1. ナレッジ・エンコーダ・ツール
4.2. Knowledge Constraint Graphs 4.2. 知識制約グラフ
4.2.1.  Equivalency Sets 4.2.1.  等価集合
4.2.2.  Magnitude Measurements 4.2.2.  マグニチュード測定
4.2.3.  Simplified Graphs 4.2.3.  簡略化されたグラフ
4.3. Inconsistency Metrics for Knowledge Constraint Graphs 4.3. 知識制約グラフの非整合性指標
4.4. Voting Unification Algorithm 4.4. 投票一元化アルゴリズム
4.4.1.  Analysis of Votes 4.4.1.  投票の解析
4.4.2.  Priority Ordering 4.4.2.  優先順位付け
4.4.3.  Unified Graph Construction 4.4.3.  ユニファイドグラフの構築
4.4.4.  Description of Constructed Graph 4.4.4.  構築されたグラフの記述
5.  Data Collection and Processing 5.  データの収集と処理
5.1. Data Set of Analyzied Vectors 5.1. 解析済みベクターのデータセット
5.2. Volunteer Participants 5.2. ボランティア参加者
5.3. Produced Knowledge Constraint Graphs 5.3. 作成された知識制約グラフ
5.4. Knowledge Constraint Graph Inconsistency Measurements 5.4. 知識制約グラフの非整合性測定
5.4.1.  Graph f00 5.4.1.  グラフf00
5.4.2.  Graph 977 5.4.2.  グラフ977
5.5. Unified Knowledge Constraint Graph 5.5. 統合知識制約グラフ
5.6. Optimal Number of Equivalency Sets 5.6. 最適な等価集合の数
6.  Measurement Approach 6.  測定アプローチ
6.1. Consistent Scoring Systems 6.1. 一貫した採点システム
6.1.1.  Scoring System Defnition 6.1.1.  採点システムの定義
6.1.2.  Consistent Scoring System Defnition 6.1.2.  一貫性のある採点システムの定義
6.2. Generation of a Closest Consistent Scoring System 6.2. 最接近型採点システムの生成
6.3. Measurement Methodology 6.3. 測定方法
7.  Measurement Results 7.  測定結果
7.1. Mean Scoring Distance 7.1. 平均得点距離
7.2. Maximum Scoring Distance 7.2. 最大評点距離
7.3. Acceptable Deviation 7.3. 許容偏差
7.4. Increasing Accuracy with More Data 7.4. より多くのデータによる精度の向上
8.  Interpretation of Results and Related Work 8.  結果の解釈と関連する研究
9.  Conclusion 9.  まとめ
References 参考文献
Appendix A. Acronyms 附属書A. 頭字語
Appendix B. Set of Evaluated CVSS vectors 附属書B. 評価済みCVSSベクタの集合
Appendix C. Encoded Knowledge Constraint Graphs 附属書C. 符号化された知識制約グラフ

 

エグゼクティブサマリー...

Executive Summary  エグゼクティブサマリー 
The Common Vulnerability Scoring System (CVSS) Version 3 maintained by the CVSS Special Interest Group (SIG) is a widely used industry standard for characterizing the properties of information technology vulnerabilities and measuring their severity. It is based on human expert opinion. Vulnerability properties are characterized through a multidimensional vector. The severity is primarily defned through a multi-part “base score” equation with 8 input metrics that is not readily amenable to human comprehension.  CVSS Special Interest Group (SIG) によって維持されている 共通脆弱性評点システム (CVSS) Version 3 は、情報技術の脆弱性の特性を特徴付け、その深刻度を測定するために広く使用されている業界標準である。CVSSは、人間の専門家の意見に基づいている。脆弱性の特性は、多次元ベクトルによって特徴づけられます。深刻度は、主に8つの入力指標を持つ多部構成の「基礎評点」式によって定義されるが、これは人間の理解には容易ではない。
To develop the equation, CVSS SIG members frst described a set of real vulnerabilities using CVSS vectors and assigned them one of fve severity levels. This created a partial lookup table mapping vectors to severity levels. They then defned a target score range for each severity level and created an equation to attempt to map each vector to a score within the specifed score range. Finally, they reviewed the equation’s scoring of vectors that were not included in the partial lookup table to evaluate the effectiveness of the equation on the full set of possible vectors. Since the equation could not perfectly map vectors to score ranges, the CVSS Version 3.1 specifcation provides a measurement of error (an ‘acceptable deviation’ of 0.5 points). However, suffcient information is not provided to reproduce the experiment.  この方程式を開発するために、CVSS SIGのメンバーはまず、CVSSベクトルを使用して一連の実際の脆弱性を記述し、5段階の深刻度レベルのうちの1つを割り当てた。これにより、ベクターと重要度レベルを対応させた部分的なルックアップテーブルが作成された。次に、各重要度レベルの目標評点範囲を定義し、各ベクトルを指定された評点範囲内の評点に対応付けることを試みる方程式を作成した。最後に、部分ルックアップテーブルに含まれていないベクトルに対する方程式の評点を確認し、可能性のあるすべてのベクトルに対する方程式の有効性を評価した。この方程式はベクターを評点範囲に完全に対応付けることができないため、CVSSバージョン3.1の仕様では、誤差の測定値(0.5ポイントの「許容偏差」)を提供している。しかし、実験を再現するのに十分な情報は提供されていない。
This work measures the degree to which the CVSS base score equation refects CVSS SIG expert domain knowledge while providing a reproducible justifcation for the measurements. It starts not from a set of real vulnerabilities, as the CVSS SIG did, but from a set of 66 vulnerability types (i.e., CVSS vectors) that represent 90 % of the vulnerabilities published by the U.S. National Vulnerability Database. CVSS SIG experts evaluate these vulnerability types and encode their knowledge as constraint graphs; sets of graphs are then unifed using a voting algorithm. These unifed graphs represent sets of consistent scoring systems (mappings of vectors to scores). The consistent scoring system closest to the CVSS Version 3.1 scores was found, and the distance between the scores and the closest consistent scoring system scores was measured. These measurements represent the degree to which the CVSS v3.1 base score equation represents the CVSS SIG expert domain knowledge.  この研究は、CVSS基礎評点の式がCVSS SIG専門家のドメイン知識をどの程度反映しているかを測定し、測定値の再現可能な正当性を提供するものである。CVSS SIGのように実際の脆弱性の集合からではなく、米国の国家脆弱性データベースによって公開された脆弱性の90%を占める66種類の脆弱性(すなわちCVSSベクトル)の集合から出発している。CVSS SIGの専門家はこれらの脆弱性の種類を評価し、その知識を制約グラフとして符号化する。次に、グラフの集合は投票アルゴリズムを用いて単一化される。これらの統一されたグラフは、一貫した採点システム(ベクトルと評点の対応付け)の集合を表している。CVSS Version 3.1の評点に最も近い一貫した採点システムを見つけ、その評点と最も近い一貫した採点システムの評点との間の距離を測定した。これらの測定値は、CVSS v3.1の基礎評点式がCVSS SIG専門家のドメイン知識をどの程度表しているかを表している。
Using this approach, the mean and maximum distance of the CVSS v3.1 scores compared to the closest consistent scoring system scores were measured, and the acceptable deviation was recalculated. Unlike acceptable deviation, the new distance metrics measure the score values themselves separate from the severity levels. Using all 12 CVSS SIG inputs, the mean scoring distance is 0.13 points, the maximum scoring distance is 0.40 points, and the acceptable deviation is 0.20 points. Sets of 11 out of 12 of the inputs were used to calculate precision measurements (i.e., standard deviation).  この方法を用いて、最も近い一貫性のある採点システムの評点と比較したCVSS v3.1評点の平均距離と最大距離が測定され、許容偏差が再計算された。許容偏差とは異なり、新しい距離メトリックは、深刻度レベルとは別に評点値そのものを測定する。12のCVSS SIGインプットすべてを使用した場合、平均評点距離は0.13ポイント、最大評点距離は0.40ポイント、許容偏差は0.20ポイントとなった。12個の入力のうち11個の入力は、精度の測定(すなわち標準偏差)を計算するために使用された。
These fndings validate that the CVSS base score equation functions as described (to the extent described by these measurements), and it represents the encoded CVSS SIG domain knowledge. The measurements support the equation as defned. The security community may use it as an opaque box without understanding the internal functionality.  これらの結果は、CVSS基礎評点の式が(これらの測定値によって記述された範囲内で)記述されたとおりに機能し、符号化されたCVSS SIGドメイン知識を表していることを検証している。測定結果は、定義された方程式をサポートしている。セキュリティコミュニティは、内部機能を理解することなく、不透明な箱としてそれを使用することができる。

 


 

まるちゃんの情報セキュリティ気まぐれ日記

・2022.11.17 CISA ステークホルダー別脆弱性分類 (SSVC) ガイド

・2022.06.11 NIST NISTIR 8409 (ドラフト) 共通脆弱性評点システムの基礎評点の計算式の測定

・2021.04.30 カーネギー大学 ソフトウェア工学研究所が「Stakeholder-Specific Vulnerability Categorization:SSVC 2.0」を発表していますね。。。

昔に遡り。。。

・2010.10.25 IPA 共通脆弱性評価システムCVSS概説

・2007.04.26 JVN は、名称をJP Vendor Status Notes (JVN) から、Japan Vulnerability Notes (JVN) と変更しました

 

 

| | Comments (0)

2022.11.17

CISA ステークホルダー別脆弱性分類 (SSVC) ガイド

こんにちは、丸山満彦です。

CISAがステークホルダー別脆弱性分類 (Stakeholder-Specific Vulnerability Categorization: SSVC) ガイドを公表していますね。。。

 

STAKEHOLDER-SPECIFIC VULNERABILITY CATEGORIZATION  ステークホルダー別脆弱性分類 
Carnegie Mellon University's Software Engineering Institute (SEI), in collaboration with CISA, created the Stakeholder-Specific Vulnerability Categorization (SSVC) system in 2019 to provide the cyber community a vulnerability analysis methodology that accounts for a vulnerability's exploitation status, impacts to safety, and prevalence of the affected product in a singular system. CISA worked with SEI in 2020 to develop its own customized SSVC decision tree to examine vulnerabilities relevant to the United States government (USG), as well as state, local, tribal, and territorial (SLTT) governments, and critical infrastructure entities. Implementing SSVC has allowed CISA to better prioritize its vulnerability response and vulnerability messaging to the public.  カーネギーメロン大学のソフトウェア工学研究所(SEI)は、CISAと共同で、脆弱性の悪用状況、安全性への影響、単一システムにおける影響製品の普及率を考慮した脆弱性分析手法をサイバーコミュニティに提供するために、2019年に「ステークホルダー固有の脆弱性分類(SSVC)」システムを作成した。CISAは2020年にSEIと協力して、米国政府(USG)、州・地方・部族・準州(SLTT)政府、重要インフラ事業体に関連する脆弱性を調査するために、独自にカスタマイズしたSSVC決定木を開発した。SSVCの導入により、CISAは、脆弱性対応と一般市民への脆弱性メッセージの優先順位をより適切に設定できるようになった。 
How CISA Uses SSVC  CISAはどのようにしてSSVCを使うのか? 
CISA uses its own SSVC decision tree model to prioritize relevant vulnerabilities into four possible decisions:  CISAは、独自のSSVC決定木モデルを使用して、関連する脆弱性を4つの可能な判断に優先順位付けしている。 
Track: The vulnerability does not require action at this time. The organization would continue to track the vulnerability and reassess it if new information becomes available. CISA recommends remediating Track vulnerabilities within standard update timelines.  追跡:この脆弱性は、現時点では対処する必要がない。組織は、脆弱性の追跡を継続し、新しい情報が入手できた場合に再評価を行いる。CISAでは、「追跡」の脆弱性を標準的な更新スケジュールで修正することを推奨している。 
Track*: The vulnerability contains specific characteristics that may require closer monitoring for changes. CISA recommends remediating Track* vulnerabilities within standard update timelines.  追跡*:この脆弱性には特定の特性があり、その変化についてより綿密な監視が必要な場合がある。CISAでは、「追跡*」の脆弱性を標準的な更新スケジュールで修正することを推奨している。 
Attend: The vulnerability requires attention from the organization's internal, supervisory-level individuals. Necessary actions include requesting assistance or information about the vulnerability, and may involve publishing a notification either internally and/or externally. CISA recommends remediating Attend vulnerabilities sooner than standard update timelines.  注意:この脆弱性は、組織内部の監督者レベルの個人による注意を必要とする。必要なアクションには、支援や脆弱性に関する情報の要求が含まれ、内部および/または外部への通知の公表を伴う場合がある。CISAでは、標準的な更新スケジュールよりも早く「注意」の脆弱性を修正することを推奨している。 
Act: The vulnerability requires attention from the organization's internal, supervisory-level and leadership-level individuals. Necessary actions include requesting assistance or information about the vulnerability, as well as publishing a notification either internally and/or externally. Typically, internal groups would meet to determine the overall response and then execute agreed upon actions. CISA recommends remediating Act vulnerabilities as soon as possible.  対処:この脆弱性は、組織内部の監督者レベル、および指導者レベルの個人による注意を必要とする。必要なアクションには、脆弱性に関する支援や情報の要求、社内外への通知の公表などがある。通常、社内のグループは、全体的な対応策を決定するために会議を開き、合意した対応策を実行することになります。CISAは、「対処」の脆弱性をできるだけ早く是正することを推奨している。 
The CISA SSVC tree determines the decisions of Track, Track*, Attend, and Act based on five values:   CISAのSSVC決定木は、5つの値に基づいて、追跡、追跡*、注意、対処を決定する。 
・Exploitation status   ・悪用状況  
・Technical impact   ・技術的影響  
・Automatable  ・自動化可能性
・Mission prevalence  ・任務の普及性
・Public well-being impact  ・公共福祉への影響 
To learn more, see the CISA SSVC Guide (pdf, 948 kb).  詳細については、CISA SSVC Guide (pdf, 948 kb)を参照のこと。 
CISA's SSVC Calculator  CISAのSSVC計算機 
The CISA SSVC Calculator allows users to input decision values and navigate through the CISA SSVC tree model to the final overall decision for a vulnerability affecting their organization. The SSVC Calculator allows users to export the data as .PDF or JSON. CISAのSSVC計算機を使用すると、ユーザーは意思決定値を入力し、CISAのSSVC決定木モデルを通じて、自分の組織に影響を与える脆弱性の最終的な総合意思決定に至るまでナビゲートすることができる。SSVC 計算機では、ユーザーはデータを.PDFまたはJSONとしてエクスポートすることができる。 
Additional SSVC Decision Tree Models   追加のSSVC決定木モデル  
Organizations whose mission spaces need to evaluate the effect of vulnerabilities in at least one external organization may find the CISA SSVC decision tree model helpful. The CISA SSVC decision tree model closely resembles the standard SSVC “Coordinator” tree. For organizations whose mission spaces do not align with CISA’s decision tree, the SEI whitepaper Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization (Version 2.0) details other decision tree models that may better align to their mission space.   ミッション・スペースが少なくとも1つの外部組織の脆弱性の影響を評価する必要がある組織は、CISAのSSVC決定木モデルが役に立つかもしれません。CISA SSVC決定木モデルは、標準的なSSVCの「コーディネータ」木に酷似している。ミッション空間がCISAの決定木と一致しない組織については、SEIホワイトペーパー「Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization (Version 2.0) は、組織のミッション空間に適した他の決定木モデルを詳細に説明している。 

 

・2022.11 [PDF] CISA Stakeholder-Specific Vulnerability Categorization Guide

20221117-01552

 

目次...

Overview 概要
The Vulnerability Scoring Decision 脆弱性スコアリングの決定
Relevant Decision Points 関連する判断ポイント
(State of) Exploitation 悪用状況
Technical Impact 技術的影響
Automatable 自動化可能性
Automating Reconnaissance and Vulnerability Chaining 偵察と脆弱性の連鎖の自動化
Mission Prevalence 任務の普及性
Public Well-Being Impact 公衆衛生への影響
Mitigation Status 緩和状況
Decision Tree 意思決定木

 

Exploitation status   悪用状況  
Evidence of Active Exploitation of a Vulnerability 脆弱性を積極的に悪用した証拠
・None ・なし
・Public PoC ・公開PoC
・Active ・アクティブ
Technical impact   技術的影響  
Technical Impact of Exploiting the Vulnerability 脆弱性を悪用した場合の技術的影響
・Partial ・部分的
・Total ・全体
Automatable  自動化可能性
・No ・No
・Yes ・Yes
Mission prevalence  任務の普及性
Impact on Mission Essential Functions of Relevant Entities 関連事業体のミッション・エッセンシャル機能への影響
・Minimal ・ミニマム
・Support ・サポート
・Essential ・必須
Public well-being impact  公共福祉への影響 
Impacts of Affected System Compromise on Humans 被災したシステムの危殆化による人体への影響
・Minimal ・ミニマム
・Material ・重要
・Irreverslble ・不可逆的

 

 

ブログ...

・2022.11.10 TRANSFORMING THE VULNERABILITY MANAGEMENT LANDSCAPE

TRANSFORMING THE VULNERABILITY MANAGEMENT LANDSCAPE 脆弱性管理状況を変革する
By Eric Goldstein, Executive Assistant Director for Cybersecurity エリック・ゴールドスタイン(サイバーセキュリティ担当エグゼクティブ・アシスタント・ディレクター)著
In the current risk environment, organizations of all sizes are challenged to manage the number and complexity of new vulnerabilities. Organizations with mature vulnerability management programs seek more efficient ways to triage and prioritize efforts. Smaller organizations struggle with understanding where to start and how to allocate limited resources. Fortunately, there is a path toward more efficient, automated, prioritized vulnerability management. Working with our partners across government and the private sector, we are excited to outline three critical steps to advance the vulnerability management ecosystem: 現在のリスク環境では、あらゆる規模の組織が、新たな脆弱性の数と複雑さを管理するという課題を抱えている。成熟した脆弱性管理プログラムを持つ組織は、取り組みの優先順位付けとトリアージに、より効率的な方法を求めている。一方、小規模な組織は、どこから手をつければよいのか、限られたリソースをどのように配分すればよいのかを理解するのに苦労している。幸いなことに、より効率的で自動化され、優先順位が付けられた脆弱性管理への道は開かれている。私たちは、政府機関や民間企業のパートナーとともに、脆弱性管理のエコシステムを前進させるための3つの重要なステップの概要を説明することができる。
・First, we must introduce greater automation into vulnerability management, including by expanding use of the Common Security Advisory Framework (CSAF) ・第一に、共通セキュリティ・アドバイザリー・フレームワーク  (CSAF) の利用を拡大するなどして、脆弱性管理にさらなる自動化を導入する必要がある。
・Second, we must make it easier for organizations to understand whether a given product is impacted by a vulnerability through widespread adoption of Vulnerability Exploitability eXchange (VEX) ・第二に、VEX(Vulnerability Exploitability eXchange)の普及により、ある製品が脆弱性の影響を受けているかどうかを、組織がより簡単に理解できるようにする必要がある。
・Third, we must help organizations more effectively prioritize vulnerability management resources through use of Stakeholder Specific Vulnerability Categorization (SSVC), including prioritizing vulnerabilities on CISA’s Known Exploited Vulnerabilities (KEV) catalog ・第三に、CISAのKEV(Known Exploited Vulnerabilities)カタログにおける脆弱性の優先順位付けなど、ステークホルダー別脆弱性分類 (SSVC) を使用して、組織が脆弱性管理リソースの優先順位をより効果的に決定できるようにする必要がある。
With these advances, described further below, we will make necessary progress in vulnerability management and reduce the window that our adversaries have to exploit American networks. 以下に説明するこれらの進歩により、私たちは脆弱性管理において必要な進歩を遂げ、敵対者が米国のネットワークを悪用するための窓を減らすことができるだろう。
1. Achieving Automation: Publish machine-readable security advisories based on the Common Security Advisory Framework (CSAF). 1. 自動化の実現:共通セキュリティ・アドバイザリー・フレームワーク (CSAF) に基づいて、機械可読のセキュリティ勧告を発行する。
When a new vulnerability is identified, software vendors jump into action: understanding impacts to products, identifying remediations, and communicating to end users. But as we know, the clock is ticking: adversaries are often turning vulnerabilities to exploits within hours of initial public reports. 新しい脆弱性が特定されると、ソフトウェア・ベンダーは、製品への影響の把握、対処法の特定、エンドユーザーへの情報提供などの活動に飛びつく。しかし、ご存知のように、時間は刻々と過ぎていく。敵は、脆弱性を最初に公表してから数時間以内にエクスプロイト(悪用)に変えてしまうことがよくある。
Software vendors work constantly to understand if their products are impacted by a new vulnerability. To meet this timeframe, our community needs a standardized approach for vendors to disclose security vulnerabilities to end users in an accelerated and automated way. ソフトウェアベンダーは、自社製品が新しい脆弱性の影響を受けているかどうかを把握するために常に努力している。この時間枠を満たすために、私たちのコミュニティは、ベンダーがエンドユーザーに対してセキュリティ脆弱性を迅速かつ自動的に開示するための標準的なアプローチを必要としている。
The CSAF, developed by the OASIS CSAF Technical Committee, is a standard for machine-readable security advisories. CSAF provides a standardized format for ingesting vulnerability advisory information and simplify triage and remediation processes for asset owners.  By publishing security advisories using CSAF, vendors will dramatically reduce the time required for enterprises to understand organizational impact and drive timely remediation. OASIS CSAF 技術委員会が開発した CSAF は、機械可読なセキュリティアドバイザリの標準である。CSAF は、脆弱性アドバイザリ情報を取り込むための標準化されたフォーマットを提供し、資産所有者のトリアージと修復プロセスを簡素化する。  CSAF を使用してセキュリティアドバイザリを公開することで、ベンダーは、企業が組織の影響を理解し、タイムリーに修正を行うために必要な時間を大幅に短縮することができる。
2. Clarifying Impact: Use Vulnerability Exploitability eXchange (VEX) to communicate whether a product is affected by a vulnerability and enable prioritized vulnerability response 2. 影響の明確化:VEXを使用して、製品が脆弱性の影響を受けるかどうかを伝え、優先的に脆弱性に対応できるようにする。
VEX allows a vendor to assert whether specific vulnerabilities affect a product; a VEX advisory can also indicate that a product is not affected by a vulnerability. Not all vulnerabilities are exploitable and put an organization at risk. To help reduce effort spent by users investigating vulnerabilities, vendors can issue a VEX advisory that states whether a product is or is not affected by a specific vulnerability in a machine readable, automated way. VEX is implemented as a profile in CSAF and is one of its more popular use cases, aligning with the existing work supporting machine-readable advisories. VEXにより、ベンダーは、特定の脆弱性が製品に影響を及ぼすかどうかを表明できる。VEXアドバイザリでは、製品が脆弱性の影響を受けないことを示すこともできる。すべての脆弱性が悪用され、組織を危険にさらすとは限らない。ユーザーが脆弱性を調査する労力を軽減するために、ベンダーは、製品が特定の脆弱性の影響を受けるかどうかを、機械的に読み取り可能な自動化された方法で表明するVEXアドバイザリを発行することができる。VEXは、CSAFのプロファイルとして実装されており、より一般的なユースケースの1つで、機械可読アドバイザリをサポートする既存の作業と連携している。
The ultimate goal of VEX is to support greater automation across the vulnerability ecosystem, including disclosure, vulnerability tracking, and remediation. VEX data can also support more effective use of software bill of materials (SBOM) data. An SBOM is a machine-readable, comprehensive inventory of software components and dependencies. Machine-readable VEX documents support linking to an SBOM and specific SBOM components. While SBOM gives an organization information on where they are potentially at risk, a VEX document helps an organization find out where they are actually affected by known vulnerabilities, and if actions need to be taken to remediate based on exploitation status. VEX の最終的な目標は、情報開示、脆弱性追跡、修正など、脆弱性エコシステム全体の自動化を促進することである。VEXデータは、ソフトウェア部品表(SBOM)データのより効果的な利用もサポートすることができる。SBOMは、ソフトウェアコンポーネントと依存関係の機械読み取り可能な包括的インベントリである。機械読み取り可能なVEX文書は、SBOMおよび特定のSBOMコンポーネントへのリンクをサポートする。SBOMは、組織が潜在的なリスクを抱えている場所に関する情報を提供するが、VEX文書は、組織が既知の脆弱性の影響を実際に受けている場所と、悪用状況に基づいて是正するために行動を起こす必要があるかどうかを確認するのに役立つ。
3. Prioritized Based on Organizational Attributes: Use vulnerability management frameworks, such as Stakeholder-Specific Vulnerability Categorization (SSVC), which utilize exploitation status and other vulnerability data to help prioritize remediation efforts. 3. 組織属性に基づく優先順位付け:ステークホルダー別脆弱性分類 (SSVC) などの脆弱性管理のフレームワークを使用し、悪用状況やその他の脆弱性データを活用して、是正措置の優先順位付けを支援する。
Last year, CISA issued Binding Operational Directive (BOD) 22-01, which directs federal civilian agencies to remediate KEVs and encourages all organizations to implement the KEV catalog into their vulnerability management framework. The first publication of KEV vulnerabilities derived from CISA's use of SSVC which occurred on November 3, 2021. 昨年、CISA は拘束的運用指令(BOD)22-01 を発行し、連邦政府文民機関に KEV の是正を指示するとともに、すべての組織に KEV カタログを脆弱性管理の枠組みに導入するよう奨励しました。2021年11月3日に発生したCISAのSSVCの利用に由来するKEV脆弱性の最初の公表は、このようなものであった。
CISA encourages every organization to use a vulnerability management framework that considers a vulnerability’s exploitation status, such as SSVC. CISAは、すべての組織がSSVCのような脆弱性の悪用状況を考慮した脆弱性管理のフレームワークを使用することを推奨している。
To assist organizations with using SSVC, today, CISA released: SSVCを利用する組織を支援するため、本日、CISAは以下を公開しました。
・An SSVC webpage introducing CISA's SSVC decision tree; ・CISAのSSVC決定木を紹介するSSVCウェブページ。
・The CISA SSVC Guide instructing how to use the scoring decision tree; and ・スコアリング決定木の使用方法を説明した「CISA SSVCガイド」、および
・The CISA SSVC Calculator for evaluating how to prioritize vulnerability responses in an organization’s respective environment. ・CISA SSVC計算機は、組織の環境における脆弱性対応の優先順位を評価するためのものである。
Organizations now have the option to use CISA’s customized SSVC decision tree guide to prioritize a known vulnerability based on an assessment of five decision points, which are (1) exploitation status, (2) technical impact, (3) automatability, (4) mission prevalence, and (5) public well-being impact. Based on reasonable assumptions for each decision point, a vulnerability will be categorized either as Track, Track*, Attend, or Act. A description of each decision and value can be found on CISA’s new SSVC webpage 組織は、CISAのカスタマイズされたSSVC決定木ガイドを使用して、5つの決定ポイント((1) 悪用状況 (2) 技術的影響 (3) 自動化可能性 (4) 任務の普及性 (5) 公共福祉への影響)の評価に基づいて、既知の脆弱性の優先度を決定できるようになった。各決定ポイントの合理的な仮定に基づき、脆弱性は「追跡」「追跡*」「注意」「対処」のいずれかに分類される。各判断と数値の説明は、CISAの新しいSSVCウェブページで見ることができる。 
As we collectively work to advance vulnerability management practices, we want to hear from you. Please send any feedback or questions to "Mail" 我々は、脆弱性管理の実践を推進するために、皆様からの意見を待っている。フィードバックや質問は、"Mail" まで。

 

 


 

関連...

まるちゃんの情報セキュリティ気まぐれ日記

・2022.06.11 NIST NISTIR 8409 (ドラフト) 共通脆弱性評点システムの基礎評点の計算式の測定

・2021.04.30 カーネギー大学 ソフトウェア工学研究所が「Stakeholder-Specific Vulnerability Categorization:SSVC 2.0」を発表していますね。。。

昔に遡り。。。

・2010.10.25 IPA 共通脆弱性評価システムCVSS概説

・2007.04.26 JVN は、名称をJP Vendor Status Notes (JVN) から、Japan Vulnerability Notes (JVN) と変更しました

| | Comments (0)

2022.10.06

米国 CISA 拘束的運用指令23-01 - 連邦ネットワークにおける資産の可視化と脆弱性検出の改善

こんにちは、丸山満彦です。

CISAが、連邦政府機関にサイバーセキュリティ資産の可視化と脆弱性検出の改善のために、「拘束的運用指令23-01 - 連邦ネットワークにおける資産の可視化と脆弱性検出の改善」を発出していますね。。。

SBOMの前提としての作業という位置づけですかね。。。

対象は例によって、連邦文民行政機関 (Federal Civilian Executive Branch: FCEB) のシステムで米軍のシステムや情報機関のシステムは基本は対象外ですね。。。

Cybeersecurity & Ingrastructure Security Agency: CISA 

・2022.10.03 CISA DIRECTS FEDERAL AGENCIES TO IMPROVE CYBERSECURITY ASSET VISIBILITY AND VULNERABILITY DETECTION

 

CISA DIRECTS FEDERAL AGENCIES TO IMPROVE CYBERSECURITY ASSET VISIBILITY AND VULNERABILITY DETECTION CISA、連邦政府機関にサイバーセキュリティ資産の可視化と脆弱性検出の改善を指示
New Binding Operational Directive Establishes Core Actions to Achieve Operational Visibility Throughout Federal Civilian Executive Branch   新しい拘束的運用指令は、連邦文民行政機関全体で運用の可視性を達成するための中核的な行動を確立する  
WASHINGTON – The Cybersecurity and Infrastructure Security Agency (CISA) issued today Binding Operational Directive (BOD) 23-01, Improving Asset Visibility and Vulnerability Detection on Federal Networks, that directs federal civilian agencies to better account for what resides on their networks. ワシントン - サイバーセキュリティおよびインフラセキュリティ局(CISA)は本日、拘束的運用指令(BOD)23-01「連邦ネットワークにおける資産の可視化と脆弱性検出の改善」を発行し、連邦民間機関に対して、ネットワーク上に存在するものをより適切に説明するように指示した。
Over the past several years, CISA has been working urgently to gain greater visibility into risks facing federal civilian networks, a gap made clear by the intrusion campaign targeting SolarWinds devices. The Biden-Harris Administration and Congress have supported significant progress by providing key authorities and resources. This Directive takes the next step by establishing baseline requirements for all Federal Civilian Executive Branch (FCEB) agencies to identify assets and vulnerabilities on their networks and provide data to CISA on defined intervals. 過去数年間、CISAは連邦政府民間ネットワークが直面するリスクの可視性を高めるために緊急に取り組んできたが、SolarWindsのデバイスを標的とした侵入キャンペーンによってそのギャップが明らかになった。バイデン=ハリス政権と議会は、重要な権限とリソースを提供することにより、大きな進展を支援してきた。この指令は、次のステップとして、すべての連邦文民行政機関(FCEB)に対して、そのネットワーク上の資産と脆弱性を特定し、定められた間隔でCISAにデータを提供する基本要件を確立するものである。
“Threat actors continue to target our nation’s critical infrastructure and government networks to exploit weaknesses within unknown, unprotected, or under-protected assets,” said CISA Director Jen Easterly. “Knowing what’s on your network is the first step for any organization to reduce risk. While this Directive applies to federal civilian agencies, we urge all organizations to adopt the guidance in this directive to gain a complete understanding of vulnerabilities that may exist on their networks. We all have a role to play in building a more cyber resilient nation.”   CISA長官のJen Easterlyは次のように述べている。「脅威者は、未知の、保護されていない、または保護されていない資産の弱点を突くために、我が国の重要なインフラと政府ネットワークをターゲットにし続けている。ネットワーク上に何があるのかを知ることは、どのような組織にとってもリスクを減らすための最初のステップである。この指令は連邦政府民間機関に適用されるが、すべての組織がこの指令のガイダンスを採用し、ネットワークに存在する可能性のある脆弱性を完全に理解することを強く勧める。私たちは皆、よりサイバーレジリエンスの高い国家を築くために果たすべき役割を担っている。」  
CISA is committed to using its cybersecurity authorities to gain greater visibility and drive timely risk reduction across federal civilian agencies. Implementation of this Directive will significantly increase visibility into assets and vulnerabilities across the federal government, in turn improving capabilities by both CISA and each agency to detect, prevent, and respond to cybersecurity incidents and better understand trends in cybersecurity risk.   CISAは、サイバーセキュリティの権限を用いて、連邦文民行政機関全体でより大きな可視性を獲得し、タイムリーなリスク削減を推進することを約束する。この指令の実施により、連邦政府全体の資産と脆弱性に対する可視性が大幅に向上し、その結果、CISAと各機関の両方によるサイバーセキュリティ事件の検出、防止、対応能力が向上し、サイバーセキュリティリスクの傾向がよりよく理解されるようになる。  
This Directive is a mandate for federal civilian agencies. However, CISA recommends that private businesses and state, local, tribal and territorial (SLTT) governments review it and prioritize implementation of rigorous asset and vulnerability management programs.  この指令は、連邦文民行政機関に義務付けられている。しかし、CISAは、民間企業や州・地方・部族・準州(SLTT)政府がこれを見直し、厳格な資産および脆弱性管理プログラムの実施を優先させることを推奨している。 
The new Directive can be found at Binding Operational Directive (BOD) 23-01.  新指令は、拘束的運用指令(BOD)23-01に掲載されている。 



拘束的運用規則...

・2022.10.03 BINDING OPERATIONAL DIRECTIVE 23-01 - IMPROVING ASSET VISIBILITY AND VULNERABILITY DETECTION ON FEDERAL NETWORKS

BINDING OPERATIONAL DIRECTIVE 23-01 - IMPROVING ASSET VISIBILITY AND VULNERABILITY DETECTION ON FEDERAL NETWORKS 拘束的運用指令23-01 - 連邦ネットワークにおける資産の可視化と脆弱性検出の改善
A binding operational directive is a compulsory direction to federal, executive branch, departments and agencies for purposes of safeguarding federal information and information systems. 44 U.S.C. § 3552(b)(1). Section 3553(b)(2) of title 44, U.S. Code, authorizes the Secretary of the Department of Homeland Security (DHS) to develop and oversee the implementation of binding operational directives. Federal agencies are required to comply with these directives. 44 U.S.C. § 3554(a)(1)(B)(ii). These directives do not apply to statutorily defined “national security systems” or to certain systems operated by the Department of Defense or the Intelligence Community. 44 U.S.C. § 3553(b), (d), (e)(2), (e)(3). This directive refers to the systems to which it applies as “Federal Civilian Executive Branch” systems, and to agencies operating those systems as “Federal Civilian Executive Branch” agencies. 拘束的運用指令とは、連邦政府の情報および情報システムを保護する目的で、連邦、行政府、機関に対する強制的な指示である。 44 U.S.C. § 3552(b)(1)。 合衆国法典第 44 編第 3553 条(b)(2)は、国土安全保障省(DHS)の長官に拘束的運用指令 を策定し、その実施を監督する権限を与えるものである。連邦機関は、これらの指令に従うことを要求される。 44 U.S.C. § 3554(a)(1)(B)(ii). これらの指令は、法令で定義された「国家安全保障システム」、または国防総省もしくは情報機関によって運用される特定のシステムには適用されない。 44 U.S.C. § 3553(b), (d), (e)(2), (e)(3)。 この指令は、適用されるシステムを「連邦文民行政機関システム」と呼び、それらのシステムを運用する機関を「連邦文民行政機関」と呼ぶ。
Background 背景
Continuous and comprehensive asset visibility is a basic pre-condition for any organization to effectively manage cybersecurity risk. Accurate and up-to-date accounting of assets residing on federal networks is also critical for CISA to effectively manage cybersecurity for the Federal Civilian Executive Branch (FCEB) enterprise. 継続的かつ包括的な資産の可視化は、あらゆる組織がサイバーセキュリティリスクを効果的に管理するための基本的な前提条件である。また、連邦ネットワーク上に存在する資産の正確かつ最新の会計処理は、CISAが連邦文民行政機関(FCEB)エンタープライズのサイバーセキュリティを効果的に管理するために不可欠である。
The purpose of this Binding Operational Directive is to make measurable progress toward enhancing visibility into agency assets and associated vulnerabilities. While the requirements in this Directive are not sufficient for comprehensive, modern cyber defense operations, they are an important step to address current visibility challenges at the component, agency, and FCEB enterprise level. The requirements of this Directive focus on two core activities essential to improving operational visibility for a successful cybersecurity program: asset discovery and vulnerability enumeration. この拘束的運用指令の目的は、機関の資産と関連する脆弱性に対する可視性の強化に向けて、測定可能な進歩を遂げることである。本指令の要件は、包括的で近代的なサイバー防衛作戦には不十分であるが、部局、機関、および FCEB エンタープライズレベルにおける可視性の現在の課題に対処するための重要なステップである。本指令の要件は、サイバーセキュリティプログラムを成功させるために運用の可視性を向上させるために不可欠な2つの中核的活動、すなわち資産の発見と脆弱性一覧に焦点を当てている。
・Asset discovery is a building block of operational visibility, and it is defined as an activity through which an organization identifies what network addressable IP-assets reside on their networks and identifies the associated IP addresses (hosts). Asset discovery is non-intrusive and usually does not require special logical access privileges. ・資産の発見とは、運用の可視性の構成要素であり、組織がネットワーク上に存在するネットワークアドレス可能なIP資産を識別し、関連するIPアドレス(ホスト)を識別する活動として定義される。資産発見は非侵入型であり、通常、特別な論理的アクセス権限を必要としない。
・Vulnerability enumeration identifies and reports suspected vulnerabilities on those assets. It detects host attributes (e.g., operating systems, applications, open ports, etc.), and attempts to identify outdated software versions, missing updates, and misconfigurations. It validates compliance with or deviations from security policies by identifying host attributes and matching them with information on known vulnerabilities. Understanding an asset’s vulnerability posture is dependent on having appropriate privileges, which can be achieved through credentialed network-based scans or a client installed on the host endpoint. ・脆弱性一覧は、これらの資産に存在する脆弱性の疑いを特定し、報告する。ホストの属性(OS、アプリケーション、オープンポートなど)を検出し、古いソフトウェアバージョン、アップデートの欠落、設定の誤りなどを特定しようとするものである。ホストの属性を特定し、既知の脆弱性に関する情報と照合することで、セキュリティポリシーへの準拠や逸脱を検証する。資産の脆弱性ポスチャを理解するには、適切な権限が必要である。この権限は、資格のあるネットワークベースのスキャンや、ホストのエンドポイントにインストールされたクライアントによって実現される場合がある。
Discovery of assets and vulnerabilities can be achieved through a variety of means, including active scanning, passive flow monitoring, querying logs, or in the case of software defined infrastructure, API query. Many agencies’ existing Continuous Diagnostics and Mitigation (CDM) implementations leverage such means to make progress toward intended levels of visibility. Asset visibility is not an end in itself, but is necessary for updates, configuration management, and other security and lifecycle management activities that significantly reduce cybersecurity risk, along with exigent activities like vulnerability remediation. The goal of this Directive is for agencies to comprehensively achieve the following outcomes without prescribing how to do so: 資産と脆弱性の発見は、アクティブスキャン、パッシブフローモニタリング、ログへのクエリ、またはソフトウェア定義インフラの場合はAPIクエリなど、さまざまな手段で行うことができる。多くの機関の既存の継続的診断・軽減(CDM)実装では、このような手段を活用して、意図したレベルの可視化に向けて前進している。資産の可視化はそれ自体が目的ではなく、脆弱性修正のような緊急の活動とともに、アップデート、構成管理、その他のセキュリティおよびライフサイクルマネジメントの活動によって、サイバーセキュリティのリスクを大幅に軽減するために必要なものである。本指令の目標は、各機関が以下の成果を包括的に達成することであり、その方法を規定するものではない。
・Maintain an up-to-date inventory of networked assets as defined in the scope of this directive; ・本指令の適用範囲に定義されるネットワーク資産の最新のインベントリを維持する。
・Identify software vulnerabilities, using privileged or client-based means where technically feasible; ・技術的に可能な場合、特権的またはクライアントベースの手段を用いて、ソフトウェアの脆弱性を特定する。
・Track how often the agency enumerates its assets, what coverage of its assets it achieves, and how current its vulnerability signatures are; and ・技術的に可能な場合は、特権的またはクライアントベースの手段を使用して、ソフトウェアの脆弱性を特定する。
・Provide asset and vulnerability information to CISA’s CDM Federal Dashboard. ・CISAのCDM Federal Dashboardに資産と脆弱性の情報を提供する。
Agencies may request CISA’s assistance in conducting an engineering survey to baseline current asset management capabilities. CISA will work with requesting agencies to provide technical and program assistance to resolve gaps, optimize scanning, and support achieving the required actions in this Directive. 各機関は、現在の資産管理能力を基準化するためのエンジニアリング・サーベイの実施においてCISAの支援を要請することができる。CISAは、要請した機関と協力して、ギャップを解決し、スキャニングを最適化し、本指令の要求事項の達成を支援するための技術的及びプログラム的支援を提供する。
This Directive’s requirements advance the priorities set forth in the Executive Order 14028 on Improving the Nation’s Cybersecurity, specifically Sec. 7 (Improving Detection of Cybersecurity Vulnerabilities and Incidents on Federal Government Networks), and provide operational clarity in achieving policy set forth in previous OMB Memoranda, including M-21-02, M-22-05, and M-22-09. Compliance with this Directive also supports BOD 22-01, Managing Unacceptable Risk Vulnerabilities in Federal Enterprise, as it will enable agencies to enhance the management of known exploited vulnerabilities that can be detected using automated tools. 本指令の要件は、国家のサイバーセキュリティの改善に関する大統領令14028、特に第7項(連邦政府ネットワークにおけるサイバーセキュリティの脆弱性とインシデントの検出の改善)で定められた優先事項を促進し、M-21-02、M-22-05、M-22-09などの以前のOMBメモランダムで定められた政策の達成に運用上の明確さを提供するものである。また、本指令を遵守することにより、BOD 22-01「連邦エンタープライズにおける許容できないリスクの脆弱性管理」をサポートし、自動化ツールを使用して検出可能な既知の悪用される脆弱性の管理を強化することが可能になるためである。
Scope 適用範囲
These required actions apply to any FCEB unclassified federal information system, including any federal information system used or operated by another entity on behalf of an agency, that collects, processes, stores, transmits, disseminates, or otherwise maintains agency information. これらの要求事項は、FCEBの非分類連邦情報システム(機関に代わって他の機関が使用または運用する連邦情報システムを含み、機関情報を収集、処理、保存、伝送、配布、または維持するもの)に適用される。
This Directive applies to all IP-addressable networked assets that can be reached over IPv4 and IPv6 protocols. For the purpose of this directive, an IP-addressable networked asset is defined as any reportable (i.e., non-ephemeral) information technology or operational technology asset that is assigned an IPv4 or IPv6 address and accessible over IPv4 or IPv6 networks, regardless of the environment it operates in. The scope includes, but is not limited to, servers and workstations, virtual machines, routers and switches, firewalls, network appliances, and network printers — whether in on-premises, roaming, and cloud operated deployment models. The scope excludes ephemeral assets, such as containers and third-party-managed software as a service (SaaS) solutions. この指令は、IPv4及びIPv6プロトコルを介して到達可能な、IPアドレス指定可能な全てのネットワーク資産に適用される。 この指令の目的上、IPアドレス指定可能なネットワーク資産とは、IPv4またはIPv6アドレスが割り当てられ、IPv4またはIPv6ネットワーク上でアクセスできる、報告可能(すなわち、非エフェメラル)な情報技術または運用技術資産と定義し、その運用環境を問わないものとする。この範囲には、オンプレミス、ローミング、クラウドのいずれの展開モデルであっても、サーバー、ワークステーション、仮想マシン、ルーター、スイッチ、ファイアウォール、ネットワーク機器、ネットワークプリンターが含まれるが、これらに限定されるものではない。コンテナやサードパーティが管理するSaaSソリューションなどの一時的な資産は対象外とする。
Required Actions 要求される対応
1. By April 3, 2023, all FCEB agencies are required to take the following actions on all federal information systems in scope of this directive: 1. 2023年4月3日までに、すべてのFCEB機関は、この指令の対象となるすべての連邦情報システムにおいて、以下の措置を講じることが求められる。
a. Perform automated asset discovery every 7 days. While many methods and technologies can be used to accomplish this task, at minimum this discovery must cover the entire IPv4 space used by the agency. a. 7日ごとに自動資産探索を実施する。このタスクを達成するために多くの方法と技術を使用することができるが、最低限、この発見は、機関が使用するIPv4空間全体をカバーする必要がある。
b. Initiate vulnerability enumeration across all discovered assets, including all discovered nomadic/roaming devices (e.g., laptops), every 14 days. b. 発見されたすべての資産(発見されたノマディック/ローミングデバイス(例:ラップトップ)を含む)に対して、14日ごとに脆弱性一覧を開始すること。
i. CISA understands that in some instances achieving full vulnerability discovery on the entire enterprise may not complete in 14 days. Enumeration processes should still be initiated at regular intervals to ensure all systems within the enterprise are scanned on a regular cadence within this window. i. CISAは、エンタープライズ全体の完全な脆弱性の発見が14日間で完了しない場合があることを理解している。エンタープライズ内の全システムがこの期間内に定期的にスキャンされるように、列挙プロセスを定期的に開始する必要がある。
ii. To the maximum extent possible and where available technologies support it, all vulnerability enumeration performed on managed endpoints (e.g., servers, workstations, desktops, laptops) and managed network devices (e.g., routers, switches, firewalls) must be conducted with privileged credentials (for the purpose of this directive, both network-based credentialed scans and client- or agent-based vulnerability detection methods are viewed as meeting this requirement). ii. 可能な限り最大限、利用可能な技術でサポートする場合、管理対象エンドポイント(例:サーバー、ワークステー ション、デスクトップ、ラップトップ)および管理対象ネットワークデバイス(例:ルーター、スイッチ、 ファイアウォール)に対して実施するすべての脆弱性一覧は、特権的資格情報を使用して実施しなければ ならない(この指令では、ネットワークベースの資格情報スキャンおよびクライアントまたはエージェント ベースの脆弱性検出方法の両方を、この要件を満たすものと見なす)。
iii. All vulnerability detection signatures used must be updated at an interval no greater than 24 hours from the last vendor-released signature update. iii. 使用するすべての脆弱性検出シグネチャは、ベンダーがリリースした最後のシグネチャ更新から24時間を超えない間隔で更新されなければならない。
iv. Where the capability is available, agencies must perform the same type of vulnerability enumeration on mobile devices (e.g., iOS and Android) and other devices that reside outside of agency on-premises networks. iv. 機能が利用可能な場合、機関は、モバイルデバイス(iOSおよびAndroidなど)および機関のオンプレミスネットワークの外に存在するその他のデバイスに対して、同じタイプの脆弱性一覧を実行しなければならない。
v. All alternative asset discovery and vulnerability enumeration methods (e.g., for systems with specialized equipment or those unable to utilize privileged credentials) must be approved by CISA. v. すべての代替的な資産発見及び脆弱性一覧方法(例えば、特殊な機器を有するシステムや特権的な認証情報を利用できないシステムなど)は、CISAによって承認されなければならない。
c. Initiate automated ingestion of vulnerability enumeration results (i.e., detected vulnerabilities) into the CDM Agency Dashboard within 72 hours of discovery completion (or initiation of a new discovery cycle if previous full discovery has not been completed). c. 発見完了後 72 時間以内に、脆弱性一覧結果(検出された脆弱性)の CDM Agency Dashboard への自動取り込みを開始する(または、以前の完全な発見が完了していない場合は、新しい発見サイクルを開始する)。
d. Develop and maintain the operational capability to initiate on-demand asset discovery and vulnerability enumeration to identify specific assets or subsets of vulnerabilities within 72 hours of receiving a request from CISA and provide the available results to CISA within 7 days of request. d. CISAからの要請を受けてから72時間以内に、特定の資産または脆弱性のサブセットを特定するためのオンデマンドの資産発見と脆弱性一覧を開始し、要請から7日以内に利用可能な結果をCISAに提供する運用能力を開発し維持する。
i. CISA understands that in some instances agencies may not be able to complete a full vulnerability discovery on the entire enterprise within this period. It is still necessary to initiate the enumeration process within this time period as any available results will provide CISA and agencies situational awareness in response to imminent threats. i. CISAは、場合によっては、機関がこの期間内にエンタープライズ全体の完全な脆弱性発見を完了できないことがあることを理解している。利用可能な結果があれば、差し迫った脅威に対応するためのCISA及び機関の状況認識が得られるため、この期間内に列挙プロセスを開始することが依然として必要である。
2. Within 6 months of CISA publishing requirements for vulnerability enumeration performance data, all FCEB agencies are required to initiate the collection and reporting of vulnerability enumeration performance data, as relevant to this directive, to the CDM Dashboard. This data will allow for CISA to automate oversight and monitoring of agency scanning performance including the measurement of scanning cadence, rigor, and completeness. 2. CISAが脆弱性一覧パフォーマンスデータの要件を公表してから6カ月以内に、すべてのFCEB機関は、この指令に関連する脆弱性一覧パフォーマンスデータの収集と報告をCDMダッシュボードに開始することが求められる。このデータにより、CISAはスキャニングの定時性、厳密性、完全性の測定を含む機関のスキャニング性能の監督と監視を自動化することができるようになる。
3. By April 3, 2023, agencies and CISA, through the CDM program, will deploy an updated CDM Dashboard configuration that enables access to object-level vulnerability enumeration data for CISA analysts, as authorized in the Executive Order on Improving the Nation’s Cybersecurity.   3. 2023年4月3日までに、各機関とCISAは、CDMプログラムを通じて、「国家のサイバーセキュリティの改善に関する行政命令」で認められた、CISAアナリストがオブジェクトレベルの脆弱性一覧データにアクセスできる最新のCDMダッシュボード構成を配備する予定である。  
Reporting Requirements and Metrics 報告要件と測定基準
1. Six, twelve, and eighteen months after the issuance, FCEB agencies will either: 1. 発行から6ヶ月後、12ヶ月後、18ヶ月後、FCEB機関は以下のいずれかを行う。
(1) Provide CISA (through a reporting interface in CyberScope) a progress report to include any obstacles, dependencies, or other issues that may prevent them from meeting the directive requirements and expected completion dates, OR (1) CISA(CyberScopeの報告インターフェースを通じて)に対し、指令の要件を満たすことを妨げる可能性のある障害、依存関係、その他の問題、および完了予定日を含む進捗報告書を提出する。
(2) Work with CISA through the CDM program review process outlined in OMB M-22-05, or superseding guidance, to identify and resolve gaps or issues that prevent full operationalization of asset management capabilities, including those requirements in this directive. (2) OMB M-22-05又はそれに代わるガイダンスに概説されているCDMプログラム・レビュープロセスを通じてCISAと協力し、本指令の要件を含む資産管理能力の完全運用を妨げるギャップ又は問題を特定し、解決する。
CISA Actions CISAの対応
1. Within 6 months of issuance, CISA will publish data requirements for agencies to provide machine-level vulnerability enumeration performance data in a common data schema. 1. CISAは、発行から6カ月以内に、各機関が機械レベルの脆弱性一覧パフォーマンスデータを共通のデータスキーマで提供するためのデータ要件を公開する予定である。
2. Within 18 months of issuance, CISA will review this directive to ensure the requirements remain relevant to the cybersecurity landscape. 2. CISAは、発行から18カ月以内に、本指令を見直し、要件がサイバーセキュリティの状況に引き続き適合していることを確認する。
3. Annually, by the end of each fiscal year, CISA will provide a status report to the Secretary of Homeland Security, the Director of OMB, and the National Cyber Director identifying cross-agency status, agency asset discovery and vulnerability management performance indicators, and outstanding issues in implementation of this Directive (scanning performance monitoring data, including the measurement of scanning cadence, rigor, and completeness). Additionally, CISA will report quarterly progress to OMB. 3. CISAは、毎年、各会計年度末までに、国土安全保障長官、OMB長官、及び国家サイバー長官に対して、機関間の状況、機関の資産発見及び脆弱性管理のパフォーマンス指標、並びに本指令の実施における未解決の問題(スキャンの定時性、厳格性、完全性の測定を含む、スキャンパフォーマンスモニタリングデータ)を特定する状況報告書を提出する。さらに、CISA は、四半期ごとに OMB に進捗状況を報告する。
4. CISA will monitor agency compliance with this Directive and will provide assistance upon request to support agency implementation. 4. CISAは、機関が本指令を遵守していることを監視し、機関の実施を支援するために要求に応じて支援を提供する。
Implementation Guidance 実施ガイダンス
The purpose of the Implementation Guidance document is to help federal agencies interpret and implement CISA’s Binding Operational Directive (BOD) 23-01. While the primary audience for this document is Federal Civilian Executive Branch (FCEB) agencies, other entities may find the content useful. At a minimum, CISA expects FCEB agencies to meet or exceed the guidance in this document. The guidance seeks to answer the most common questions asked by federal agencies. CISA will update this document with commonly asked questions and as new information becomes available. 実施ガイダンスの目的は、連邦政府機関がCISAの拘束的運用指令(BOD)23-01を解釈し実施するのを支援することである。この文書の主な対象者は連邦文民行政機関(FCEB)であるが、他の機関もこの内容を有用と考えるかもしれない。CISAは、少なくとも連邦文民行政機関が本書のガイダンスを満たすか、それを上回ることを期待している。このガイダンスは、連邦政府機関から寄せられる最も一般的な質問に答えようとするものである。CISAは、よくある質問や新しい情報が入手可能になったときに、この文書を更新する予定である。

 

 

実施ガイドライン... 用語定義とFAQですね...

 

・2022.10.03 IMPLEMENTATION GUIDANCE FOR CISA BINDING OPERATIONAL DIRECTIVE 23-01: IMPROVING ASSET VISIBILITY AND VULNERABILITY DETECTION ON FEDERAL NETWORKS

IMPLEMENTATION GUIDANCE FOR CISA BINDING OPERATIONAL DIRECTIVE 23-01: IMPROVING ASSET VISIBILITY AND VULNERABILITY DETECTION ON FEDERAL NETWORKS CISA拘束的運用指令23-01の実施ガイダンス:連邦政府のネットワークにおける資産の可視化と脆弱性の検出の改善
The purpose of this document is to help federal agencies interpret and implement CISA’s Binding Operational Directive (BOD) 23-01. While the primary audience for this document is Federal Civilian Executive Branch (FCEB) agencies, other entities may find the content useful. At a minimum, CISA expects FCEB agencies to meet or exceed the guidance in this document. The guidance seeks to answer the most common questions asked by federal agencies. CISA will update this document with commonly asked questions and as new information becomes available. この文書の目的は、連邦政府機関がCISAの拘束的運用指令(BOD)23-01を解釈し、実施するのを支援することである。この文書の主な対象者は連邦政府文民行政機関(FCEB)であるが、他の機関もこの内容を有用と考えるかもしれない。CISAは、少なくとも連邦政府文民行政機関が本書のガイダンスを満たすか、それを上回ることを期待している。このガイダンスは、連邦政府機関から寄せられる最も一般的な質問に答えようとするものである。CISAは、よくある質問や新しい情報が入手可能になったときに、この文書を更新する予定である。
Glossary 用語集
Vulnerability enumeration performance data – Otherwise referred to as scanning logs, vulnerability enumeration performance data describes datapoints or measurements that provide visibility on the level of performance relative to the requirements in this directive, using automation and machine-level data (e.g., logs/events indicating successful credentialed enumeration completion, date/timestamps surrounding enumeration activities, and signature/plug-in update date/timestamps). Data requirements to satisfy this objective will be published in a common data schema and made available to every Federal agency. 脆弱性一覧パフォーマンスデータ - スキャンログとも呼ばれる脆弱性一覧パフォーマンスデータは、自動化およびマシンレベルのデータ(例:認証された列挙の成功を示すログ/イベント、列挙活動に関する日付/タイムスタンプ、署名/プラグイン更新日付/タイムスタンプ)を使用して、この指令の要件に対するパフォーマンスのレベルを可視化するデータポイントまたは測定値について説明する。この目的を満たすためのデータ要件は、共通のデータ・スキーマで公開され、すべての連邦機関が利用できるようにする予定である。
Vulnerability enumeration – A technique to list host attributes (e.g., operating systems, applications, and open ports) and associated vulnerabilities. Vulnerability enumeration typically requires privileged access to gain full visibility at the application and configuration levels. 脆弱性一覧 - ホストの属性(オペレーティングシステム、アプリケーション、オープンポートなど) と関連する脆弱性をリストアップする技術。脆弱性一覧は、通常、アプリケーションおよび構成レベルで完全な可視性を得るために、特権的なアクセス を必要とする。
Privileged credentials – A local or network account or a process with sufficient access to enumerate system configurations and software components across an entire asset. Administrators must apply the principle of least privilege and/or separation of duties on the accounts used for vulnerability enumeration. Poisoning and machine-in-the-middle type attacks commonly target accounts with elevated privileges, including those used for vulnerability enumeration. 特権資格情報 - 資産全体のシステム構成とソフトウェアコンポーネントを列挙するために十分なアクセス権を持つローカルまたはネットワークアカウント、またはプロセス。管理者は、脆弱性一覧に使用するアカウントに最小特権の原則および/または職務分離の原則を適用する必要がある。ポイズニングおよびマシン・イン・ザ・ミドル型の攻撃は、脆弱性一覧に使用されるアカウントを含め、通常、昇格した特権を持つアカウントを標的としている。
Roaming devices – Devices that leave an agency’s on-premises networks, connect to other private networks, and directly access the public internet. ローミングデバイス - 機関のオンプレミスネットワークを離れ、他のプライベートネットワークに接続し、公衆インターネットに直接アクセスするデバイス。
Nomadic devices – Devices that permanently reside outside of agency networks. ノマディックデバイス – 機関内ネットワークの外に常時存在するデバイス。
Frequently Asked Questions よくある質問
Q: What is the scope of this directive? Which devices specifically need to be scanned? Q: この指令の対象は何であるか?具体的にどのデバイスをスキャンする必要があるか?
A: This directive applies to all IP-addressable networked assets that can be reached over IPv4 and IPv6 protocols. An IP-addressable networked asset is defined as any reportable (i.e., non-ephemeral) information technology or operational technology asset that is assigned an IPv4 or IPv6 address and accessible over IPv4 or IPv6 networks, regardless of the environment in which it operates. The scope includes, but is not limited to, servers and workstations, virtual machines, routers and switches, firewalls, network appliances, and network printers — whether in on-premises, roaming, or cloud-operated deployment models. The scope excludes ephemeral assets such as containers and third-party managed software as a service (SaaS) solutions. A: この指令は、IPv4およびIPv6プロトコルを介して到達可能な、すべてのIPアドレス指定可能なネットワーク資産に適用される。IPアドレス指定可能なネットワーク資産とは、IPv4またはIPv6アドレスが割り当てられ、IPv4またはIPv6ネットワーク上でアクセスできる、報告可能な(すなわち、非エフェメラルな)情報技術または運用技術資産であり、それが運用されている環境に関係なく、定義されている。この範囲には、オンプレミス、ローミング、クラウド運用のいずれの展開モデルであっても、サーバー、ワークステーション、仮想マシン、ルーター、スイッチ、ファイアウォール、ネットワーク機器、ネットワークプリンターが含まれるが、これらに限定されるものではない。ただし、コンテナやサードパーティ製のSaaSソリューションなど、一時的な資産は対象外とする。
Q: How does the pre-existing requirement to perform endpoint detection and response (EDR) differ from the requirements of this BOD? To what extent does EDR address asset visibility needs? Q: エンドポイントの検出と対応(EDR)を実行するという既存の要件は、このBODの要件とどのように違うのか?また、EDRは資産の可視化のニーズにどの程度対応しているか?
A: Asset visibility is a prerequisite for determining where to deploy EDR. While most EDR tools do not provide vulnerability information, the directive gives agencies the flexibility to use any tool that provides credential or client-level vulnerability information. If an agency deploys EDR tools that can provide vulnerability information, those tools can be used in place of a client-based scanner. A: 資産の可視化は、EDRを導入する場所を決定するための前提条件である。ほとんどのEDRツールは脆弱性情報を提供しませんが、この指令は、クレデンシャルまたはクライアントレベルの脆弱性情報を提供するいかなるツールも使用する柔軟性を機関に与えている。もし、機関が脆弱性情報を提供できるEDRツールを配備していれば、それらのツールをクライアントベースのスキャナーの代わりに使用することができる。
Q: This BOD uses the term “networked assets.” Does that imply cloud is out of scope? Q: このBODでは、"ネットワーク化された資産 "という用語が使われている。これは、クラウドが対象外であることを意味するのか。
A: Any non-ephemeral asset with an IP address is in scope, including applicable cloud assets. Many cloud use cases are unique. Many agencies have SaaS instances where agencies are unable to run their own scans. In the case of traditional data center collocations, infrastructure as a service (IaaS), and in some cases platform as a service (PaaS), all assets with an IP address are in scope. The scope excludes ephemeral assets such as containers and third-party managed SaaS solutions. A: IPアドレスを持つ非継続的な資産であれば、適用可能なクラウド資産も含めて対象範囲である。多くのクラウドのユースケースは独特である。多くの機関は、機関が独自のスキャンを実行できないSaaSインスタンスを持っている。従来のデータセンターのコロケーション、IaaS(Infrastructure as a Service)、場合によってはPaaS(Platform as a Service)の場合、IPアドレスを持つすべての資産がスコープに含まれる。コンテナやサードパーティ製のマネージドSaaSソリューションのような一時的な資産は対象外である。
Q: Why does the directive say “initiate scans” instead of “execute” or “complete scans”? Q: なぜ指令では、「実行」や「スキャン完了」ではなく、「スキャンを開始する」となっているのか?
A: Sometimes, especially in large enterprises, vulnerability scans may not be complete within the 14-day timeframe required in the BOD. To overcome this issue, BOD 23-01 requires agencies to initiate a new scan every 14 days regardless of whether the previous scan has completed. Agencies are also required to feed available results for the previous scan three days after the new scan is initiated, even when the previous scan is not fully complete. A: 特に大企業では、BODで要求されている14日間の期間内に脆弱性スキャンを完了できないことがある。この問題を克服するために、BOD 23-01は、前回のスキャンが完了したかどうかにかかわらず、14日ごとに新しいスキャンを開始するよう機関に要求している。また、前回のスキャンが完全に終了していない場合でも、新しいスキャンが開始されてから3日後に、前回のスキャンの結果を提供することが義務付けられている。
Q: What is the difference between “asset management” and “asset discovery”? Q: "資産管理 "と "資産発見 "の違いは何であるか?
A: Asset management and asset discovery are two distinct activities that frequently go hand in hand. Asset management is the active monitoring and administration of endpoints using a centralized solution, such as unified endpoint management (UEM), mobile device management (MDM), or enterprise mobility management (EMM). Inventories from asset management solutions may be used to feed the information about agency assets into the results of a comprehensive asset discovery effort. A: 資産管理と資産発見は、しばしば手を取り合って行われる2つの異なる活動である。資産管理は、統合エンドポイント管理(UEM)、モバイルデバイス管理(MDM)、エンタープライズモビリティ管理(EMM)などの集中型ソリューションを使用して、エンドポイントを積極的に監視および管理することである。資産管理ソリューションのインベントリは、機関の資産に関する情報を、包括的な資産探索の取り組みの結果に反映させるために使用することができる。
Asset discovery is the process of checking an IPv4 or IPv6 network for active and inactive hosts (e.g., networked assets) by using a variety of methods. The most common discovery methods include actively trying to communicate with all IP addresses in a range using a scan tool such as “nmap” (which is only feasible on smaller IPv4 based networks), or by passively monitoring traffic on the wire to detect activity from any new assets.   資産発見とは、さまざまな方法を用いて、IPv4またはIPv6ネットワークにアクティブなホストと非アクティブなホスト(ネットワーク上の資産など)があるかどうかを確認するプロセスである。最も一般的な発見方法は、「nmap」などのスキャンツールを使用して範囲内のすべてのIPアドレスとの通信を積極的に試みる方法(これは小規模なIPv4ベースのネットワークでのみ実行可能)、またはワイヤ上のトラフィックをパッシブに監視して新しい資産からのアクティビティを検出する方法などがある。 
Asset discovery helps organizations find unmanaged assets that are present on the network to ensure they are brought under appropriate management. It also helps organizations identify networked devices, such as Internet of Things (IoT), that cannot be centrally managed. It is possible for an asset to fall off the management tool due to inactivity or other reasons, requiring it to be rediscovered. 資産検出は、ネットワーク上に存在する管理されていない資産を発見し、適切な管理下に置くことを可能にする。また、IoT(Internet of Things)など、一元管理できないネットワーク上のデバイスを特定することもできる。不活性化などの理由で管理ツールから外れてしまい、再認識する必要がある場合もあり得る。
Q: Why does the directive reference the software bill of materials (SBOM) in the Background section but not in subsequent sections? Q: なぜ指令は背景のセクションでソフトウェア部品表(SBOM)に言及し、それ以降のセクションで言及しないのか?
A: SBOM is mentioned in the introduction to convey the Administration’s vision and describe our desired state in the long term. The directive focuses on very specific first steps that can be achieved within the next 6-12 months and are prerequisites for broader adoption of SBOM. Without comprehensive asset management, agencies will be unable to effectively use SBOMs to manage risk posed by asset components or libraries.   A: SBOMは、行政のビジョンを伝え、長期的に望ましい状態を説明するために、序章で言及されている。この指令は、今後6〜12ヶ月以内に達成可能で、SBOMをより広く採用するための前提条件となる、非常に具体的な最初のステップに焦点を合わせている。包括的な資産マネジメントがなければ、機関はSBOMを効果的に使用して、資産の構成要素やライブラリによってもたらされるリスクを管理することはできないだろう。 
Q: We offer public wireless access in conference rooms and lobbies. Are guest networks in scope? Q: 当社は、会議室やロビーで公衆無線アクセスを提供している。ゲストネットワークは対象であるか?
A:  Guest hosts are not in scope, provided the guest networks are physically segmented from agency networks. A: ゲストネットワークが機関のネットワークから物理的に分離されている場合、ゲストホストは適用範囲外である。
Q: Are bring-your-own-device (BYOD) assets in scope? Q:BYOD(Bring-Your-Own-Device)資産は範囲内か?
A: Most federal agencies do not allow BYOD on enterprise networks. If they do, then BYOD devices are in scope. This does not apply to personally owned equipment that connects to federal networks via web interface (e.g., website visitors or remote users connecting via SSL remote access solutions). A:ほとんどの連邦政府機関では、エンタープライズ・ネットワーク上でのBYODを許可していません。BYODが許可されている場合、そのデバイスは対象範囲に含まれる。ただし、Webインタフェース経由で連邦政府のネットワークに接続する個人所有の機器(Webサイトの訪問者やSSLリモートアクセスソリューションで接続するリモートユーザーなど)には適用されない。
Q: Are air-gapped networks in scope? It may not be possible to transfer a signature to air-gapped networks within 24 hours. Q:エアギャップ・ネットワークは範囲に含まれるか?24時間以内にエアギャップ・ネットワークに署名を転送することは不可能かもしれない。
A: Many logically isolated networks and systems are incorrectly considered air-gapped. Any device, system, or network that is directly connected to the operating environment, or is connected to another system that is connected to the operating environment, is not considered air-gapped and is in scope for BOD 23-01. Only systems that are truly physically air-gapped are out of scope. A: 論理的に分離されたネットワークやシステムの多くは、誤ってエアギャップされていると考えられている。動作環境に直接接続されている、または動作環境に接続されている他のシステムに接続されているデバイス、システム、またはネットワークは、エアギャップとはみなされず、BOD 23-01の適用範囲に含まれる。本当に物理的にエアギャップされているシステムのみが対象外である。
Q: Does the BOD include requirements for scanning software and configuration enumerations? Q: BODには、スキャンソフトウェアや構成列挙の要件が含まれているか?
A: No, the BOD requirements address only basic (IP) asset discovery and vulnerability enumeration. The current BOD does not address hardware management, software management, or configuration management and associated controls. Note that some vulnerabilities due to misconfigurations and basic configurations may be captured by standard vulnerability scanners. A: いいえ。BOD要件は、基本的な(IP)資産の発見と脆弱性一覧のみを扱っている。現在のBODは、ハードウェア管理、ソフトウェア管理、構成管理および関連するコントロールには対応していません。なお、設定ミスや基本的な設定による脆弱性は、標準的な脆弱性スキャナで捕捉できる場合がある。
Q: Which cloud assets are in scope? Q: どのクラウド資産が対象になるか?
A: Agencies are responsible for the discovery and enumeration of networked assets under agency control, such as assets in authority-to-operate (ATO) inventories. Each cloud instance is unique, but in general, third-party hosting solutions where agencies still control physical or virtual hosts, such as infrastructure as a service, are within the scope of this directive. A: 機関は、ATO(Authority-to-Operate)インベントリ内の資産など、機関の管理下にあるネットワーク資産の発見と列挙に責任を負う。クラウドのインスタンスはそれぞれ異なるが、一般的に、機関が物理的または仮想的なホストを引き続き管理するサードパーティのホスティングソリューション(サービスとしてのインフラストラクチャなど)は、この指令の対象範囲内である。
Q: Are communications devices, such as IP telephony, VOIP phones, cameras, and unified communications peripherals in scope? Q: IP電話、VOIP電話、カメラ、ユニファイドコミュニケーション周辺機器などの通信機器も対象となるか?
A: Yes, these devices are in scope. Adversaries have specifically targeted these devices as they are typically more difficult to harden. A: はい、これらのデバイスは対象である。一般的にハード化が困難なため、攻撃者はこれらのデバイスを特にターゲットにしている。

 

Cisa_20220913192501

 

 

| | Comments (0)

2022.09.22

ドイツ BSI (連邦情報セキュリティ局):自動車業界状況報告2021/2022

こんにちは、丸山満彦です。

ドイツの連邦情報セキュリティ局が自動車業界の情勢報告2021/2022を公表していますね。。。「サイバーセキュリティが鍵」というメッセージですね。これは、昨年に2021.09.07に発表された報告書に続く、第2版です。

Bundesamt für Sicherheit in der Informationstechnik: BSI 

・2022.09.19 Cyber-Sicherheit als Schlüssel: BSI stellt Automotive-Lagebild 2021/2022 vor

Cyber-Sicherheit als Schlüssel: BSI stellt Automotive-Lagebild 2021/2022 vor サイバーセキュリティが鍵:BSIが自動車業界状況報告2021/2022を発表
Die Digitalisierung moderner Autos schreitet weiter schnell voran. Mitunter sind über 100 einzelner digitaler Steuerungsgeräte in heutigen Autos verbaut, die miteinander verbunden sind oder zentral gesteuert werden können. Durch das autonome Fahren und den Einsatz Künstlicher Intelligenz wird die Komplexität der Software-Architektur in Fahrzeugen weiterhin rasant zunehmen. Und auch die Unternehmen selbst sind mehr denn je auf sichere IT-Systeme angewiesen. Dies stellt das Bundesamt für Sicherheit in der Informationstechnik (BSI) in der zweiten Ausgabe seines Branchenlagebilds Automotive fest. 現代のクルマのデジタル化は急速に進み続けている。現在の自動車には、100個以上の個別のデジタル制御装置が搭載され、それらが相互に接続されたり、集中的に制御されたりすることもある。自律走行や人工知能の活用により、自動車に搭載されるソフトウェア・アーキテクチャの複雑さは今後も急速に増していくだろう。そして、企業自体も、安全なITシステムへの依存度がこれまで以上に高まっている。これは、連邦情報セキュリティ局(BSI)が、自動車産業の状況報告書の第2版で述べている。
BSI-Präsident Arne Schönbohm: „Das BSI gestaltet Informationssicherheit in der Digitalisierung für Staat, Gesellschaft und auch Wirtschaft. Die Automobilindustrie nimmt dabei auf Grund ihrer volkswirtschaftlichen Bedeutung und ihrer umfangreichen Lieferketten eine besondere Stellung ein. Mit dem Lagebild Automotive 2021/22 wird einmal mehr deutlich, dass Cyber-Sicherheit in allen Gliedern der Lieferkette mitgedacht werden muss – von Anfang an bis zum fertigen Produkt. Cyber-Sicherheit ist der Schlüssel für eine funktionierende Automobilindustrie.“ BSIのアルネ・シェーンボーム会長:「BSIは、国家、社会、そして経済のために、デジタル化における情報セキュリティを形成している。自動車産業は、その経済的重要性と広範なサプライチェーンから、特別な位置を占めている。「自動車業界状況報告2021/2022」は、サイバーセキュリティはサプライチェーンのすべてのリンク(最初から最終製品まで)で考慮されなければならないことを改めて明確にしている。サイバーセキュリティは、自動車産業が機能するための鍵である。」
Das Branchenlagebild Automotive 2021/2022 ist die zweite Ausgabe eines branchenspezifischen Überblicks aus Sicht des BSI zur Lage der Cyber-Sicherheit im Bereich „Automotive“, sowohl hinsichtlich der Produktion, als auch der Fahrzeuge selbst. Es macht deutlich, dass künftige Automobile noch viel stärker als heute schon von IT-Funktionen abhängig sein werden. Die Steuerung des Fahrzeugs selbst, aber auch die Vernetzung mit der Infrastruktur (car-to-x) wird rasant digitalisiert. So wurde in Deutschland im vergangenen Jahr die weltweit erste Genehmigung für ein automatisiertes KFZ (Spurhaltesystem) erteilt. Daher ist es aus Sicht des BSI von besonderer Bedeutung, dass die dazu notwendigen, neuen Technologien nicht manipulierbar sein dürfen und mögliche Cyber-Angriffe keinen Einfluss auf die Fahrsicherheit haben dürfen. Das BSI begrüßt daher, dass die Hersteller Cyber-Sicherheit frühzeitig im Entwicklungszyklus neuer Fahrzeugmodelle berücksichtigen und die Umsetzung nach EU-Typgenehmigungsrecht auch nachweisen müssen. 「自動車業界状況報告2021/2022」は、「自動車」セクターのサイバーセキュリティ状況について、生産と車両自体の両面からBSIの視点でセクター別にまとめた第2版である。これからの自動車は、今以上にIT機能への依存度が高まることが明らかである。車両自体の制御はもちろん、インフラとのネットワーク化(car-to-x)も急速にデジタル化されている。例えば、昨年はドイツで世界初の自動運転車(車線維持システム)の認可が下りた。そのため、BSIの観点からは、このために必要な新技術が操作可能であること、起こりうるサイバー攻撃が運転の安全性に影響を与えないことが特に重要であるとしている。したがって、BSIは、メーカーが新車種の開発サイクルの早い段階でサイバーセキュリティを考慮し、さらにEU型式認証法に従って実装を証明しなければならないという事実を歓迎する。
Im Berichtszeitraum waren erneut mehrere Automobilzulieferer von Ransomware-Vorfällen betroffen. Dadurch kam es bei den Betroffenen zu massiven Unterbrechungen der Leistungserbringung. Die durch das BSI grundsätzlich festgestellte Tendenz, dass Dritte mittelbar ebenfalls von IT-Sicherheitsvorfällen in Mitleidenschaft gezogen werden, bestätigt sich auch hier. So war auch ein weltweit führender Automobilhersteller von Ransomware-Angriffen bei Zulieferern betroffen und musste seinerseits seine Produktion drosseln. Im Hinblick auf die operative Cyber-Sicherheit in den Betrieben stellen Ransomware-Angriffe aus Sicht des BSI aktuell die größte Bedrohung dar. Neben den bestehenden Auswirkungen der COVID‑19-Pandemie, insbesondere in den Bereichen von Zulieferteilen, -produkten oder –dienstleistungen, wird die Lage maßgeblich durch den Krieg in der Ukraine und den damit verbundenen wirtschaftlichen, aber zunehmend auch cyber-sicherheitsrelevanten Auswirkungen auf die deutsche Automobilindustrie geprägt. Dies sind u. a. Verfügbarkeitsangriffe auf Webseiten durch DDoS-Angriffe sowie intensive Hacktivisten-Aktivitäten. 報告書の期間中、いくつかの自動車部品メーカーが再びランサムウェアの被害を受けた。そのため、被災組織ではサービスの提供に大規模な支障をきたすことになった。BSIが確認した、ITセキュリティ事故の影響を第三者も間接的に受けるという一般的な傾向は、ここでも確認されている。例えば、世界的な大手自動車メーカーも、サプライヤーへのランサムウェア攻撃の影響を受け、生産縮小を余儀なくされました。企業における運用上のサイバーセキュリティについては、BSIの観点では、現在、ランサムウェア攻撃が最大の脅威となっている。COVID 19の大流行による既存の影響、特にサプライヤーの部品、製品、サービスの分野に加え、ウクライナ戦争とそれに伴う経済的な影響、さらにはドイツの自動車産業に対するサイバーセキュリティ関連の影響によって、状況は大きく変化している。DDoS攻撃によるWebサイトへの可用性攻撃や、ハクティビストによる集中的な活動などである。
Um die Cyber-Sicherheit für den Wirtschafts- und Automobilstandort Deutschland zu erhöhen, arbeitet das BSI in Fragen der Cyber-Sicherheit eng mit dem Kraftfahrtbundesamt (KBA), dem Verband der Automobilindustrie (VDA) sowie weiteren Behörden und aus der Wirtschaft betroffenen Unternehmen zusammen. ビジネスや自動車の拠点としてのドイツのサイバーセキュリティを高めるため、BSIは連邦自動車交通局(KBA)、ドイツ自動車工業会(VDA)、その他の当局やサイバーセキュリティ問題の影響を受ける企業と緊密に連携している。

 

・2022.09.19 Branchenlagebild Automotive 2021/2022

Branchenlagebild Automotive 2021/2022 自動車業界状況報告 2021/2022
Die zweite Auflage des Branchenlagebild Automotive 2021/2022 gibt einen branchenspezifischen Überblick zur Lage der Cyber-Sicherheit im Bereich „Automotive“. Sie zeigt vielfältige und komplexe Herausforderungen auf - sowohl hinsichtlich der Produktion als auch der Fahrzeuge selbst. Die Publikation verdeutlicht, wie wichtig diese Aufgabe bei Herstellern, Zulieferern, Entwicklern und anderen Dienstleistern der Automobilindustrie ist und stellt das Engagement des BSI in diesem Sektor dar. 「自動車業界状況報告2021/2022」の第2版では、自動車業界のサイバーセキュリティの状況を分野別にまとめている。生産面でも車両面でも、多様で複雑な課題が浮き彫りになっている。本書は、自動車産業のメーカー、サプライヤー、開発者、その他のサービスプロバイダーにとって、このタスクがいかに重要であるかを説明し、この分野に対するBSIのコミットメントを提示している。

 

・[PDF]

20220922-62925

・[DOCX] 仮訳

 

 

 

1 Einleitung 1 はじめに
2 Managementübersicht zur Gesamtlage 2 経営の全体像の把握
3 Cyber-Sicherheit in der Automobilbranche 3 自動車産業におけるサイバーセキュリティ
3.1 Branchenüberblick 3.1 業界の概要
3.2 Auswirkungen durch den Angriffskrieg auf die Ukraine 3.2 ウクライナへの侵略戦争による影響
3.3 Gefahren durch Cybercrime 3.3 サイバー犯罪による脅威
3.4 Bedeutung der Informationssicherheit in der Supply Chain 3.4 サプライチェーンにおける情報セキュリティの重要性
3.5 Qualifizierung von Schlüsselpersonal 3.5 主要な人材の資格
4 Cyber-Sicherheit im Fahrzeug sowie in digitalen Produkten 4 自動車およびデジタル製品におけるサイバーセキュリティ
4.1 Vernetztes Fahren 4.1 コネクテッド・ドライブ
4.2 Automatisierung und Künstliche Intelligenz 4.2 オートメーションと人工知能
5 Cyber-Sicherheit in Produktionsanlagen und -prozessen 5 生産工場・プロセスにおけるサイバーセキュリティ
5.1 Digitalisierung als Herausforderung in der Produktion 5.1 生産現場の課題としてのデジタル化
5.2 Schwachstellenmanagement 5.2 脆弱性管理
5.3 Dienstleister und Fernservices 5.3 サービスプロバイダーとリモートサービス
6 Maßnahmen und Aktivitäten 6 施策と活動
6.1 Informationssicherheit im Unternehmen 6.1 企業における情報セキュリティ
6.2 Regulierung und Standardisierung - Vorgaben zur Cyber-Sicherheit 6.2 規制と標準化 - サイバーセキュリティ要件
6.3 Neuregelungen für Unternehmen im besonderen öffentlichen Interesse (UBI) 6.3 特別公益法人(UBI)に対する新たな規制
6.4 Zusammenarbeit und Aktivitäten des BSI 6.4 BSIの協力と活動
7 Chancen und Risiken: Ein Blick in die nahe Zukunft 7 チャンスとリスク:近未来への展望
Literaturverzeichnis 書誌情報
Impressum インプリント

 

 

 


 

昨年度

まるちゃんの情報セキュリティ気まぐれ日記

・2021.09.08 独国 BSI 自動車業界におけるサイバーセキュリティ

Bundesamt für Sicherheit in der Informationstechnik: BSI

 ・2021.09.07 Crashtest für Cyber-Sicherheit – BSI stellt Automotive-Lagebild vor

 ・2021.09.07 Branchenlagebild Automotive

 ・[PDF] Branchenlagebild Automotive - Cyber-Sicherheit in der Automobilbranche

 20210908-61137

 

| | Comments (0)

2022.08.03

ドイツ BSI 静的アプリケーションセキュリティテストの文脈における機械学習

 こんにちは、丸山満彦です。

ドイツのBSIが静的アプリケーション セキュリティ テストにおける AI の使用に関する研究報告書を公表していますね。。。力作ですが、2023年初頭に最終化するようです。

 

Bundesamt für Sicherheit in der Informationstechnik: BSI

・2022.07.27 Machine Learning in the Context of Static Application Security Testing - ML-SAST

 

Machine Learning in the Context of Static Application Security Testing - ML-SAST 静的アプリケーションセキュリティテストの文脈における機械学習 - ML-SAST
Überblick über den aktuellen Stand in Forschung und Technik 研究・技術の現状を概観する
Im Projekt Machine Learning in the Context of Static Application Security Testing (ML-SAST) untersucht das BSI, wie Verfahren des maschinellen Lernens genutzt werden können, um Methoden der statischen Codeanalyse zu verbessern. 静的アプリケーションセキュリティテストの文脈における機械学習(ML-SAST)プロジェクトにおいて、BSIは機械学習手法を静的コード解析手法の改善にどのように利用できるかを調査している。
In der Softwareentwicklung stellt die statische Programmcodeanalyse neben der dynamischen Programmcodeanalyse eine wichtige Technik dar, um zum Beispiel redundanten Code, Verletzungen von Programmierrichtlinien oder Fehler in Treiberdateien aufzudecken. Sie ermöglicht ein automatisiertes Auffinden von potentiellen Schwachstellen im Programmcode durch statische Analyseverfahren. Ein aktuelles Anliegen ist es, bereits während der Programmierung Sicherheitslücken für verdeckte Angriffsmöglichkeiten, wie Pufferüberläufe, aufzudecken und somit einen Security-by-Design-Ansatz zu verwirklichen. ソフトウェア開発において、静的プログラムコード解析は、動的プログラムコード解析と並んで、冗長なコード、プログラミングガイドライン違反、ドライバファイルのエラーなどを検出するための重要な技術である。静的解析手続きにより、プログラムコードの潜在的な弱点を自動的に検出することができる。現在、バッファオーバーフローのような隠れた攻撃可能性を持つセキュリティ脆弱性を、プログラミングの段階ですでに検出し、セキュリティバイデザインのアプローチを実現することが課題となっている。
Im Rahmen des Projekts hat das BSI die neusta mobile solutions GmbH mit der Erstellung einer mehrteiligen Studie beauftragt. Im ersten Teil wird der aktuelle Stand der Forschung in den Bereichen des Machine Learning, der statischen Codeanalyse und deren Kombination untersucht. Flankierend wurden im zweiten Teil Experteninterviews geführt, um die Nachteile der aktuellen Ansätze zu erfassen, und geeignete Use-Cases zu definieren. Im letzten Teil werden vorhandene ML-SAST-Ansätze anhand der Use-Cases und einer neu entwickelten Metrik miteinander verglichen und ein Vorschlag für die Entwicklung eines neuartigen ML-SAST-Ansatzes vorgestellt. Dieser befindet sich aktuell in der Umsetzung. Die Veröffentlichung der finalen Studie und der Implementierung erfolgt Anfang des Jahres 2023. このプロジェクトの一環として、BSIはneusta mobile solutions GmbHに依頼し、いくつかのパートに分かれて調査書を作成した。第1部では、機械学習、静的コード解析、およびそれらの組み合わせの領域における研究の現状について検討する。第2部では、現在のアプローチのデメリットを明らかにし、適切なユースケースを定義するために、専門家へのインタビューを実施した。最後に、ユースケースと新たに開発した指標に基づいて、既存のML-SASTアプローチを相互に比較し、新しいML-SASTアプローチの開発に関する提案を行う。現在、実施中である。最終的な検討と実施は、2023年初頭に発表される予定である。

 

 

・[PDF] Machine Learning in the Context of Static Application Security Testing - ML-SAST

 

20220803-154552

目次...

1  Introduction 1 はじめに
1.1  Summary 1.1 概要
1.2  Summary in German 1.2 概要(ドイツ語)
1.3  Motivation 1.3 動機
1.4  Contribution 1.4 貢献度
1.5  Structure 1.5 構成
2  Artificial Intelligence and Machine Learning 2 人工知能と機械学習
2.1  Definition of Artificial Intelligence 2.1 人工知能の定義
2.2  Basic Principles of AI Systems 2.2 人工知能システムの基本原理
2.3  Machine Learning Primer 2.3 機械学習入門
2.3.1  Supervised Learning 2.3.1 教師あり学習
2.3.2  Unsupervised Learning 2.3.2 教師なし学習
2.3.3  Reinforcement Learning 2.3.3 強化学習
2.3.4  Neural Networks 2.3.4 ニューラルネットワーク
2.3.5  Recurrent Neural Networks 2.3.5 リカレントニューラルネットワーク
2.3.6  LSTM Networks 2.3.6 LSTMネットワーク
2.3.7  Bidirectional Sequence Models 2.3.7 双方向配列モデル
2.3.8  Graph Neural Networks 2.3.8 グラフニューラルネットワーク
2.4  Other Concepts and Further Reading 2.4 その他の概念と参考文献
3  Static Application Security Testing 3 静的アプリケーションセキュリティテスト
3.1  SAST Tools 3.1 SASTツール
3.2  Background on Static Program Analysis 3.2 静的プログラム解析の背景
3.2.1  Compiler Construction Techniques 3.2.1 コンパイラの構築技法
3.2.2  Typical Internal Data Structures for Static Program Analysis 3.2.2 静的プログラム解析のための典型的な内部データ構造
3.2.3  Static Analysis Problems 3.2.3 静的解析の問題点
4  ML in the Context of SAST 4 SASTの文脈における機械学習
4.1  Preliminaries 4.1 前提条件
4.2  Refinements 4.2 リファインメント
4.3  Current State of the Art 4.3 現在の技術水準
4.3.1  Datasets 4.3.1 データセット
4.3.2  Architectures 4.3.2 アーキテクチャ
4.3.3  Explainability 4.3.3 説明可能性
4.3.4  Outlook 4.3.4 展望
5  Expert Interviews 5 専門家インタビュー
5.1  Method 5.1 方法
5.2  Interview Partners 5.2 インタビューの相手
5.3  Results of the Expert Interviews 5.3 専門家インタビューの結果
5.3.1  Versions of C and C++ Used 5.3.1 使用したCおよびC++のバージョン
5.3.2  Opinions Towards SAST Tools in General 5.3.2 SASTツール全般に対する意見
5.3.3  Input Format for Rules for SAST tools 5.3.3 SASTツールのルールの入力形式
5.3.4  Expectations Towards ML-based SAST Tools and Ideas to this End 5.3.4 機械学習ベースのSASTツールへの期待とそのためのアイデア
5.3.5  Easily and Not Easily Detectable Errors 5.3.5 検出が容易なエラーとそうでないエラー
5.3.6  Sources for Error Use Cases 5.3.6 エラー・ユースケースのソース
6 Online Questionnaire 6 オンラインアンケート
6.1 Platform 6.1 プラットフォーム
6.2 Participants 6.2 参加者
6.3 Questionnaire 6.3 アンケート質問
6.4 Results 6.4 アンケート結果
6.4.1 C/C++ Versions 6.4.1 C/C++バージョン
6.4.2 SAST Tools 6.4.2 SASTツール
6.4.3 Input Format for Rules for SAST tools 6.4.3 SASTツール用ルールの入力形式
6.4.4 Error Use Cases 6.4.4 エラーの使用例
6.4.5 ML and SAST Tools 6.4.5 MLとSASTツール
7 Elicitation and Explanation of Error Use Cases with Descriptions 7 エラー・ユースケースの抽出と説明
7.1 void* Pointers 7.1 void*ポインタ
7.2 Difficulty in Tracking Tainted Data 7.2 汚染されたデータの追跡の困難さ
7.3 Integer Overflows Related to Tainted Data 7.3 汚染されたデータに関連する整数のオーバーフロー
7.4 Array Boundary Errors 7.4 アレイバウンダリエラー
7.5 Null Pointer Access 7.5 Nullポインタのアクセス
7.6 Format String Errors (With Tainted Data) 7.6 (汚染されたデータを含む)文字列のフォーマットエラー
7.7 String Termination Errors 7.7 文字列の終了エラー
7.8 Missing Security Checks for Critical Operations 7.8 重要な操作のためのセキュリティチェックの欠落
7.9 Unsafe Use of Random Number Generators 7.9 乱数生成器の安全でない使用
7.10 Information Flow Through Uncleared Main Memory Data Structures 7.10 安全でないメインメモリのデータ構造を介した情報の流れ
7.11 Insecure Origin of Cryptographic Keys and Initialization Vectors 7.11 安全ではない暗号鍵の出所と初期化ベクタ
7.12 Reuse of Initialization Vectors for Specific Operating Modes of Block Ciphers 7.12 ブロック暗号の特定の動作モードに対する初期化ベクタの再利用
7.13 Memory Leaks 7.13 メモリリーク
7.14 Dangling Pointers – Use-After-Free 7.14 ぶら下がりポインタ - ユーズ・アフター・フリー
7.15 Race Conditions 7.15 レースコンディション
7.16 Application-Specific Errors 7.16 アプリケーション固有のエラー
7.17 Pointer Casts to Types with Stricter Alignment 7.17 より厳格なアライメントを持つ型へのポインタキャスト
8 Evaluation Criteria for ML-SAST Approaches 8 ML-SASTアプローチの評価基準
8.1 Qualitative Criteria 8.1 定性的評価基準
8.1.1 Transparency 8.1.1 透過性
8.1.2 Other Requirements 8.1.2 その他の要求事項
8.2 Quantitative Criteria 8.2 定量的基準
8.3 Other Criteria 8.3 その他の基準
9 Data in ML-Experiments: Types, Formats and Schemata 9 ML-Experimentsにおけるデータ:データの種類,フォーマット,スキーマ
9.1 Benchmarks 9.1 ベンチマーク
9.2 Type, Format and Metrics 9.2 タイプ,フォーマット,評価基準
9.2.1 Name, Version and Description of Dataset 9.2.1 データセットの名称、バージョン、説明
9.2.2 Dataset Scheme 9.2.2 データセットのスキーム
9.2.3 Experiment Scheme 9.2.3 実験スキーム
9.2.4 Model Persistence and Tracking 9.2.4 モデルの永続性とトラッキング
9.3 Ontologies for Machine Learning 9.3 機械学習のためのオントロジー
10 Approaches to Conducting a Literature Mapping for ML-SAST 10 ML-SASTのための文献マッピングの実施方法
10.1 Research Questions 10.1 リサーチクエスチョン
10.2 Initial Search 10.2 初期検索
10.3 Iteration Steps 10.3 イテレーションステップ
10.4 Data Extraction 10.4 データ抽出
10.5 Summary of the Most Important Results 10.5 最も重要な結果のまとめ
11 Detailed Description of Most Appropriate Methods for ML-SAST 11 ML-SASTに最適な手法の詳細説明
11.1 Training Data 11.1 学習データ
11.2 Models 11.2 モデル
11.3 Explainability 11.3 説明可能性
12 Prioritization of Models for this Approach and Outlook on Further Work 12 本アプローチにおけるモデルの優先順位付けと今後の展望
12.1 Graph Neural Networks 12.1 グラフニューラルネットワーク
12.2 Conventional Neural Networks 12.2 伝統的ニューラルネットワーク
12.3 Clustering Approaches 12.3 クラスタリングアプローチ
12.4 Reinforcement Learning 12.4 強化学習
12.5 Ensembles of Approaches 12.5 アプローチのアンサンブル
12.6 Conclusion of the Prioritization 12.6 優先順位付けの結論
13 Conclusion 13 結論
13.1 Further Research 13.1 更なる研究
13.2 Outlook 13.2 展望
14 Appendix 14 附属書
14.1 Glossary 14.1 用語集
14.2 Results of the Literature Mapping 14.2 文献マッピングの結果
14.2.1 Base Set 14.2.1 基本セット
14.2.2 Round I 14.2.2 ラウンドI
14.2.3 Round II 14.2.3 ラウンドII
14.2.4 Round III 14.2.4 ラウンドIII
14.2.5  Round IV 14.2.5 ラウンドIV
14.3  Guideline for the interviews with the experts 14.3 専門家インタビューのためのガイドライン
Bibliography 書誌情報

 

 

| | Comments (0)

2022.07.02

デジタル庁 デジタル社会推進標準ガイドラインにセキュリティに関するドキュメントが追加されましたね。。。

こんにちは、丸山満彦です。

デジタル庁が、デジタル社会推進標準ガイドラインを公表していますが、そこにセキュリティに関するドキュメントが4つ、データ連携に関するドキュメントが1つ追加されましたね。。。

デジタル庁の「次世代セキュリティアーキテクチャ検討会」委員をしておりまして、こういうガイドラインが充実していけば良いと思っております。。。

● デジタル庁資料 - デジタル社会推進標準ガイドライン

 

セキュリティに関するドキュメント

ドキュメント名 本文
[PDF]
統合版[ZIP] 最終改定 ドキュメントの位置づけ 概要
DS-200 政府情報システムにおけるセキュリティ・バイ・デザインガイドライン 2,145KB 4,151KB 2022.06.30 Informative 情報システムに対して効率的にセキュリティを確保するためには、情報システムの企画から運用まで一貫したセキュリティ対策(セキュリティ・バイ・デザイン)を実施する必要がある。本文書はシステムライフサイクルにおけるセキュリティ対策を俯瞰的にとらえるため、各工程でのセキュリティ実施内容、要求事項を記載するとともに、関係者の役割を定義する。
DS-210 ゼロトラストアーキテクチャ適用方針 774KB 981KB 2022.06.30 Informative クラウドサービスの利活用拡大や、リモートワーク等の業務環境の変化に伴い、従来の境界型のセキュリティモデルだけでは、近年の高度化したサイバー攻撃を完全に予防・防御することは困難になってきており、ゼロトラストな考え方の適用が求められている。本文書は、ゼロトラスト・アーキテクチャを適用するための基本方針を説明するとともに、導入時の留意事項について述べる。
DS-211 常時リスク診断・対処(CRSA)アーキテクチャ 1,073KB 1,491KB 2022.06.30 Informative ゼロトラストアーキテクチャの環境下において、安定且つ安全なサービス提供を実現するためには、政府全体のサイバーセキュリティリスクを早期に検知し、低減する事が必要となる。本文書は、この活動を継続的に実施するための、情報収集・分析を目的としたプラットフォームのアーキテクチャについて説明する。
DS-221 政府情報システムにおける脆弱性診断導入ガイドライン 1,078KB 1,292KB 2022.06.30 Informative 政府情報システムにおいてサイバーレジリエンスを確保するためには、脆弱性診断を実施することが重要である。本文書は、最適な脆弱性診断を選定、調達できるようにするための、脆弱性導入に係る基準とその指針について説明する。


データ連携に関するドキュメント

ドキュメント名 本文
[PDF]
統合版
[ZIP]
最終改定 ドキュメントの位置づけ 概要
DS-400 政府相互運用性フレームワーク(GIF)   34,884KB 2022.06.30 Informative データの利活用、連携がスムースに行える社会を実現するための技術的体系として、「政府相互運用性フレームワーク(Government Interoperability Framework)」(GIF​)を提供する。当フレームワークを利用してデータを整備することで、拡張性が高く、連携が容易なデータを設計することが可能。

 

Digital




Continue reading "デジタル庁 デジタル社会推進標準ガイドラインにセキュリティに関するドキュメントが追加されましたね。。。"

| | Comments (0)

2022.06.25

SP 1800-34 (ドラフト) コンピューティングデバイスの完全性の検証

こんにちは、丸山満彦です。

NISTが、SP 1800-34 (ドラフト) コンピューティングデバイスの完全性の検証を公表し、意見募集をしていますね。。。

昨年3月から初期ドラフトを段階的に発表してきたものです。

これの日本政府版を考えることを想定すると、日米の国力の差は歴然ですね。。。日本製品がないですからね。。。

執筆には、NSA、MITREのメンバーに加えてベンダーからは、ArcherDell TechnologiesEclypsiumHewlett Packard EnterpriseHP Inc.IBMIntelSeagateが参加していますね。。。

 

NIST - ITL

2022.06.23 SP 1800-34 (Draft) Validating the Integrity of Computing Devices

SP 1800-34 (Draft) Validating the Integrity of Computing Devices SP 1800-34 (ドラフト) コンピューティングデバイスの完全性の検証
Announcement 発表
What Is This Guide About? このガイドは何について書かれているのか?
Technologies today rely on complex, globally distributed and interconnected supply chain ecosystems to provide reusable solutions. Organizations are increasingly at risk of cyber supply chain compromise, whether intentional or unintentional. Managing cyber supply chain risks requires, in part, ensuring the integrity, quality, and resilience of the supply chain and its products and services. This project demonstrates how organizations can verify that the internal components of their computing devices are genuine and have not been altered during the manufacturing or distribution processes. 今日のテクノロジーは、再利用可能なソリューションを提供するために、複雑でグローバルに分散し、相互接続されたサプライチェーンエコシステムに依存している。組織は、意図的であるか否かを問わず、サイバーサプライチェーンの侵害のリスクにさらされることが多くなっている。サイバーサプライチェーンのリスクを管理するには、サプライチェーンとその製品およびサービスの整合性、品質、および弾力性を確保することが一部で必要とされている。このプロジェクトでは、コンピュータデバイスの内部コンポーネントが本物であり、製造や流通の過程で変更されていないことを組織が確認する方法を紹介する。
Share Your Expertise 専門知識を共有する
Please download the document and share your expertise with us to strengthen the draft practice guide. The public comment period for this draft is now open and will close on July 25th, 2022. You can stay up to date on this project by sending an email to supplychain-nccoe@nist.gov to join our Community of Interest. Also, if you have any project ideas for our team, please let us know by sending an email to the email address above. We look forward to your feedback. 実践ガイドのドラフトを強化するために、ドキュメントをダウンロードし、あなたの専門知識を共有してください。このドラフトに対するパブリックコメント期間は現在開始されており、2022年7月25日に終了する予定である。このプロジェクトに関する最新情報は、supplychain-nccoe@nist.gov までメールをお送りいただき、Community of Interestにご参加ください。また、私たちのチームに対するプロジェクトのアイデアがあれば、上記のメールアドレスにメールを送ってお知らせください。皆様のご意見をお待ちしている。
Additional NIST Supply Chain Work NISTのサプライチェーンに関するその他の作業
NIST is also working on an important effort, the National Initiative for Improving Cybersecurity in Supply Chains (NIICS) with the private sector and others in government to improve cybersecurity in supply chains. This initiative will help organizations to build, evaluate, and assess the cybersecurity of products and services in their supply chains, an area of increasing concern. For more information on this effort, you can click here. NISTは、サプライチェーンにおけるサイバーセキュリティを向上させるために、民間企業や政府関係者とともに「サプライチェーンにおけるサイバーセキュリティ向上のための国家イニシアチブ(NIICS)」という重要な取り組みも行っている。このイニシアティブは、組織がサプライチェーンにおける製品やサービスのサイバーセキュリティを構築、評価、査定することを支援するもので、この分野はますます懸念されている。この取り組みの詳細については、こちらをご覧ください。
Abstract 概要
Organizations are increasingly at risk of cyber supply chain compromise, whether intentional or unintentional. Cyber supply chain risks include counterfeiting, unauthorized production, tampering, theft, and insertion of unexpected software and hardware. Managing these risks requires ensuring the integrity of the cyber supply chain and its products and services. This project will demonstrate how organizations can verify that the internal components of the computing devices they acquire, whether laptops or servers, are genuine and have not been tampered with. This solution relies on device vendors storing information within each device, and organizations using a combination of commercial off-the-shelf and open-source tools that work together to validate the stored information. This NIST Cybersecurity Practice Guide provides a draft describing the work performed so far to build and test the full solution. 組織は、意図的であるか否かにかかわらず、サイバーサプライチェーンの侵害のリスクにさらされることが多くなっている。サイバーサプライチェーンリスクには、偽造、不正生産、改ざん、盗難、予期せぬソフトウェアやハードウェアの挿入などがある。これらのリスクを管理するには、サイバー・サプライ・チェーンとその製品・サービスの完全性を確保する必要がある。このプロジェクトでは、組織が入手したコンピューティングデバイスの内部コンポーネントが、ノートパソコンであれサーバーであれ、本物であり、改ざんされていないことを確認する方法を実証する。このソリューションは、デバイスベンダーが各デバイス内に情報を保存し、組織が市販のツールとオープンソースのツールを組み合わせて使用し、保存された情報を検証することに依存している。このNISTサイバーセキュリティ実践ガイドは、完全なソリューションを構築しテストするためにこれまでに行われた作業を説明するドラフトを提供する。

 

NIST SP 1800-34 ipd

・2022.06.23 Validating the Integrity of Computing Devices NIST 1800-34 Practice Guide Draft

・[PDF] NIST SP 1800-34: Complete Guide

 

20220625-24825

 

目次...

1  Summary 1 概要
1.1  Challenge 1.1 課題
1.2  Solution 1.2 解決策
1.3  Benefits 1.3 利点
2  How to Use This Guide 2 このガイドの使い方
2.1 Typographic Conventions 2.1 タイポグラフィの規則
3 Approach 3 アプローチ
3.1  Audience 3.1 対象者
3.2  Scope 3.2 スコープ
3.2.1  Scenario 1: Creation of Verifiable Platform Artifacts 3.2.1 シナリオ1:検証可能なプラットフォームアーティファクトの作成
3.2.2  Scenario 2: Verification of Components During Acceptance Testing 3.2.2 シナリオ2:受入テストにおけるコンポーネントの検証
3.2.3  Scenario 3: Verification of Components During Use 3.2.3 シナリオ3:使用時のコンポーネントの検証
3.3  Assumptions 3.3 前提条件
3.4  Risk Assessment 3.4 リスクアセスメント
3.4.1  Threats 3.4.1 脅威
3.4.2  Vulnerabilities 3.4.2 脆弱性
3.4.3  Risk 3.4.3 リスク
3.5  Security Control Map 3.5 セキュリティコントロールマップ
3.6  Technologies 3.6 技術
3.6.1  Trusted Computing Group 3.6.1 トラステッドコンピューティンググループ
4  Architecture 4 アーキテクチャ
4.1  Architecture Description 4.1 アーキテクチャの説明
4.2  Existing Enterprise IT Management Systems 4.2 既存の企業IT管理システム
4.2.1  SIEM Tools 4.2.1 SIEMツール
4.2.2  Asset Discovery and Management System 4.2.2 資産発見・管理システム
4.2.3  Configuration Management System 4.2.3 コンフィギュレーション管理システム
4.2.4  Enterprise Dashboards 4.2.4 エンタープライズダッシュボード
4.3  Supporting Platform Integrity Validation Systems 4.3 サポートするプラットフォーム整合性検証システム
4.3.1  Host Integrity at Runtime and Start-up Attestation Certificate Authority (HIRS ACA)25  4.3.1 ランタイムおよびスタートアップ時のホスト完全性認証局(HIRS ACA)
4.3.2  Network Boot Services 4.3.2 ネットワークブートサービス
4.3.3  Platform Manifest Correlation System 4.3.3 プラットフォームマニフェスト相関システム
4.3.4  Eclypsium Analytic Platform 4.3.4 分析プラットフォーム
4.4  Computing Devices 4.4 コンピューティングデバイス
4.4.1  HP Inc 4.4.1 HP Inc.
4.4.2  Dell Technologies 4.4.2 デル・テクノロジー
4.4.3  Intel 4.4.3 インテル
4.4.4 Hewlett Packard Enterprise (HPE) 4.4.4 ヒューレット・パッカード・エンタープライズ(HPE)
4.4.5 Seagate 4.4.5 シーゲイト
5  Security Characteristic Analysis 5 セキュリティ特性分析
5.1  Assumptions and Limitations 5.1 前提条件と制限事項
5.2  Build Testing 5.2 ビルドテスト
5.2.1  Scenario 1 5.2.1 シナリオ1
5.2.2  Scenario 2 5.2.2 シナリオ2
5.2.3  Scenario 3 5.2.3 シナリオ3
5.3  Scenarios and Findings 5.3 シナリオと調査結果
5.3.1  Supply Chain Risk Management (ID.SC) 5.3.1 サプライチェーンリスクマネジメント(ID.SC)
5.3.2  Asset Management (ID.AM) 5.3.2 アセットマネジメント(ID.AM)
5.3.3  Identity Management, Authentication and Access Control (PR.AC) 5.3.3 アイデンティティ管理、認証、アクセス制御(PR.AC)
5.3.4  Data Security (PR.DS) 5.3.4 データセキュリティ(PR.DS)
5.3.5  Security Continuous Monitoring (DE.CM) 5.3.5 セキュリティ継続監視(DE.CM)
6  Future Build Considerations 6 今後の構築に関する考察
Appendix A List of Acronyms 附属書 A 頭字語(英語)リスト
Appendix B References 附属書 B 参考文献
Appendix C Project Scenario Sequence Diagrams 附属書 C プロジェクトシナリオシーケンスダイアグラム

 


まるちゃんの情報セキュリティティ気まぐれ日記

 

・2022.05.08 NIST SP 800-161 Rev. 1 システムと組織のためのサイバーセキュリティ・サプライチェーン・リスクマネジメントの実践

・2021.11.25 NIST SP 1800-34C (ドラフト) コンピューティングデバイスの完全性の検証(初期ドラフト)

・2021.10.30 NIST SP 800-161 Rev. 1 (Draft) システムと組織のためのサイバーセキュリティ・サプライチェーン・リスクマネジメントの実践(第2次ドラフト)

・2021.09.03 NIST SP 1800-34B (ドラフト) コンピューティングデバイスの完全性の検証(初期ドラフト)

・2021.03.18 NIST SP 1800-34 (Draft) Validating the Integrity of Computing Devices (コンピューティングデバイスの完全性の検証)(Preliminary Draft)

Continue reading "SP 1800-34 (ドラフト) コンピューティングデバイスの完全性の検証"

| | Comments (0)

2022.06.11

CISA Alert (AA22-158A) 中華人民共和国に支援されたサイバー犯罪者がネットワークプロバイダーやデバイスを悪用している (2022.06.07)

こんにちは、丸山満彦です。

米国家安全保障局(NSA)、サイバーセキュリティ・インフラセキュリティ局(CISA)、連邦捜査局(FBI)が共同で、中華人民共和国に支援された攻撃者が利用する脆弱性のリストを公開していますね。。。

● CISA

・2022.06.07 Alert (AA22-158A) People’s Republic of China State-Sponsored Cyber Actors Exploit Network Providers and Devices

 

Alert (AA22-158A) People’s Republic of China State-Sponsored Cyber Actors Exploit Network Providers and Devices アラート (AA22-158A) 中華人民共和国に支援されたサイバー犯罪者がネットワークプロバイダーやデバイスを悪用している
Summary 概要
This joint Cybersecurity Advisory describes the ways in which People’s Republic of China (PRC) state-sponsored cyber actors continue to exploit publicly known vulnerabilities in order to establish a broad network of compromised infrastructure. These actors use the network to exploit a wide variety of targets worldwide, including public and private sector organizations. The advisory details the targeting and compromise of major telecommunications companies and network service providers and the top vulnerabilities—primarily Common Vulnerabilities and Exposures (CVEs)—associated with network devices routinely exploited by the cyber actors since 2020. この共同サイバーセキュリティ勧告は、中華人民共和国(PRC)の国家に支援されたサイバー行為者が、侵害されたインフラの幅広いネットワークを確立するために、公に知られた脆弱性を悪用し続ける方法について説明しています。これらのサイバー攻撃者は、このネットワークを利用して、公共機関や民間企業を含む世界中のさまざまな標的を攻撃しています。本アドバイザリーでは、大手通信会社やネットワークサービスプロバイダーが標的とされ、侵害されたこと、また2020年以降、サイバー行為者によって日常的に悪用されているネットワーク機器に関連する脆弱性(主にCVE(共通脆弱性識別子))のトップについて詳述しています。
This joint Cybersecurity Advisory was coauthored by the National Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA), and the Federal Bureau of Investigation (FBI). It builds on previous NSA, CISA, and FBI reporting to inform federal and state, local, tribal, and territorial (SLTT) government; critical infrastructure (CI), including the Defense Industrial Base (DIB); and private sector organizations about notable trends and persistent tactics, techniques, and procedures (TTPs). この共同サイバーセキュリティアドバイザリーは、米国家安全保障局(NSA)、サイバーセキュリティ・インフラセキュリティ局(CISA)、連邦捜査局(FBI)が共同で作成したものです。この報告書は、これまでの NSA、CISA、FBI の報告を基に、連邦政府および州、地方、部族、領土(SLTT)、防衛産業基盤(DIB)を含む重要インフラ(CI)、民間企業に対し、注目すべき傾向と根強い戦術、技術、手順(TTPs)に関する情報を提供するものです。
Entities can mitigate the vulnerabilities listed in this advisory by applying the available patches to their systems, replacing end-of-life infrastructure, and implementing a centralized patch management program. この勧告に記載されている脆弱性を緩和するには、利用可能なパッチをシステムに適用し、耐用年数が経過したインフラを交換し、集中パッチ管理プログラムを導入する必要があります。
NSA, CISA, and the FBI urge U.S. and allied governments, CI, and private industry organizations to apply the recommendations listed in the Mitigations section and Appendix A: Vulnerabilities to increase their defensive posture and reduce the risk of PRC state-sponsored malicious cyber actors affecting their critical networks. NSA、CISA、FBI は、米国および同盟国の政府、情報収集機関、民間企業組織が、「緩和策」のセクションおよび「附属書 A:脆弱性」に記載された推奨事項を適用して防御体制を強化し、中華人民共和国の支援による悪質なサイバー行為者が重要ネットワークに影響を及ぼすリスクを低減することを強く推奨します。
For more information on PRC state-sponsored malicious cyber activity, see CISA’s China Cyber Threat Overview and Advisories webpage. 中国がスポンサーとなっている悪質なサイバー活動の詳細については、CISAの中国サイバー脅威の概要と勧告のウェブページを参照してください。

 

・[PDF]

20220611-153122  

 

 

ベストプラクティスは、、、

Best Practices ベストプラクティス
• Apply patches as soon as possible ・できるだけ早いパッチの適用
• Disable unnecessary ports and protocols ・不要なポートやプロトコルの無効化
• Replace end-of-life infrastructure ・耐用年数が経過したインフラの交換
• Implement a centralized patch management system ・パッチ集中管理システムの導入

 

Vendor CVE 脆弱性タイプ
Cisco CVE-2018-0171 リモートコード実行
  CVE-2019-15271 リモートコード実行
  CVE-2019-1652 リモートコード実行
Citrix CVE-2019-19781 リモートコード実行
DrayTek CVE-2020-8515 リモートコード実行
D-Link CVE-2019-16920 リモートコード実行
Fortinet CVE-2018-13382 認証バイパス
MikroTik CVE-2018-14847 認証バイパス
Netgear CVE-2017-6862 リモートコード実行
Pulse CVE-2019-11510 認証バイパス
  CVE-2021-22893 リモートコード実行
QNAP CVE-2019-7192 権限昇格
  CVE-2019-7193 リモートインジェクション
  CVE-2019-7194 XMLルーティング迂回攻撃
  CVE-2019-7195 XMLルーティング迂回攻撃
Zyxel CVE-2020-29583 認証バイパス

 

 

| | Comments (0)

NIST NISTIR 8409 (ドラフト) 共通脆弱性評点システムの基礎評点の計算式の測定

こんにちは、丸山満彦です。

NISTが、NISTIR 8409 (ドラフト) 共通脆弱性評点システムの基礎評点の計算式の測定を公表し、意見募集をしていますね。。。

なかなか興味深い報告書です。。。

 

● NIST - ITL

・2022.06.08 NISTIR 8409 (Draft) Measuring the Common Vulnerability Scoring System Base Score Equation

NISTIR 8409 (Draft) Measuring the Common Vulnerability Scoring System Base Score Equation NISTIR 8409 (ドラフト) 共通脆弱性評点システムの基礎評点の計算式の測定
Announcement 発表
Calculating the severity of information technology vulnerabilities is important for prioritizing vulnerability remediation and helping to understand the risk of a vulnerability. The Common Vulnerability Scoring System (CVSS) is a widely used approach to evaluating properties that lead to a successful attack and the effects of a successful exploitation. CVSS is managed under the auspices of the Forum of Incident Response and Security Teams (FIRST) and is maintained by the CVSS Special Interest Group (SIG). Unfortunately, ground truth upon which to base the CVSS measurements has not been available. Thus, CVSS SIG incident response experts maintain the equations by leveraging CVSS SIG human expert opinion. 情報技術の脆弱性の深刻度を計算することは、脆弱性修正の優先順位付けや、脆弱性のリスクの把握に役立つため、重要です。共通脆弱性評点システム(CVSS)は、攻撃の成功につながる特性や悪用が成功した場合の影響を評価するためのアプローチとして広く利用されています。CVSSは、FIRSTの後援を受け、CVSS Special Interest Group (SIG)によって維持管理されています。残念ながら、CVSS測定の基礎となるグランド・トゥルースは利用可能ではありません。そのため、CVSS SIGのインシデントレスポンスの専門家が、CVSS SIGの人間の専門家の意見を活用し、数式を維持しています。
This work evaluates the accuracy of the CVSS “base score” equations and shows that they represent the CVSS maintainers' expert opinion to the extent described by these measurements. NIST requests feedback on the approach, the significance of the results, and any CVSS measurements that should have been conducted but were not included within the initial scope of this work. Finally, NIST requests comments on sources of data that could provide ground truth for these types of measurements. この研究では、CVSSの「基礎評点」式の精度を評価し、この測定値がCVSSメンテナンス担当者の専門的な意見を表現していることを示しました。NISTは、このアプローチ、結果の重要性、およびこの作業の最初の範囲に含まれなかったが実施されるべきであったCVSS測定に関するフィードバックを求めます。最後に、NISTは、この種の測定にグランドトゥルースを提供できるデータソースについてのコメントを求めています。
Abstract 概要
This work evaluates the validity of the Common Vulnerability Scoring System (CVSS) Version 3 ``base score'' equation in capturing the expert opinion of its maintainers. CVSS is a widely used industry standard for rating the severity of information technology vulnerabilities; it is based on human expert opinion. This study is important because the equation design has been questioned since it has features that are both non-intuitive and unjustified by the CVSS specification. If one can show that the equation reflects CVSS expert opinion, then that study justifies the equation and the security community can treat the equation as an opaque box that functions as described. この研究は、共通脆弱性評点システム(CVSS) 第3版 の「基礎評点」式の有効性を、その保守者の専門的な意見を反映させることで評価するものです。CVSSは、情報技術の脆弱性の深刻度を評価するために広く利用されている業界標準であり、人間の専門家の意見に基づいています。この研究は、CVSSの仕様から直感的でなく、正当化できない特徴を持つ方程式の設計が疑問視されているため、重要です。もし、数式がCVSS専門家の意見を反映していることを示すことができれば、その研究は数式を正当化し、セキュリティコミュニティは数式を説明どおりに機能する不透明な箱として扱うことができます。
This work shows that the CVSS base score equation closely though not perfectly represents the CVSS maintainers' expert opinion. The CVSS specification itself provides a measurement of error called ``acceptable deviation'' (with a value of 0.5 points). In this work, the distance between the CVSS base scores and the closest consistent scoring systems (ones that completely conform to the recorded expert opinion) is measured. The authors calculate that the mean scoring distance is 0.13 points and the maximum scoring distance is 0.40 points. The acceptable deviation was also measured to be 0.20 points (lower than claimed by the specification). These findings validate that the CVSS base score equation represents the CVSS maintainers' domain knowledge to the extent described by these measurements. この研究は、CVSS基礎評点の式が、完全ではないものの、CVSS保守者の専門家の意見を忠実に反映していることを示しました。CVSS仕様自体は、「許容距離」(0.5点の値)と呼ばれる誤差の測定法を提供しています。この研究では、CVSSの基礎評点と、最も整合性の高い評点システム(記録された専門家の意見に完全に適合するもの)との間の距離を測定しています。著者らは、平均得点距離は0.13点、最大得点距離は0.40点であると計算しています。また、許容距離は0.20点と測定されました(仕様で主張されている値より低い)。これらの結果は、CVSSの基礎評点式がCVSS保守者のドメイン知識をこれらの測定で説明される程度に表していることを検証するものです。

 

・[PDF] NISTIR 8409 (Draft)

20220610-151106

 

目次...

Executive Summary エグゼクティブサマリー
1 Introduction 1 はじめに
2 Common Vulnerability Scoring System 2 共通脆弱性評点システム
2.1 CVSS Base Score Metrics 2.1 CVSS基礎評点の指標
2.2 CVSS Base Score Equations 2.2 CVSS 基礎評点の計算式
3 Rationale for the CVSS Base Score Equations 3 CVSS 基礎評点評点式の根拠
3.1 Development of the CVSS Base Score Equation 3.1 CVSS基礎評点評点式の開発
3.2 Acceptable Deviation 3.2 許容距離
4 Metrology Tools, Metrics, and Algorithms 4 計測ツール、計測指標、アルゴリズム
4.1 Knowledge Encoder Tool 4.1 知識エンコーダツール
4.2 Knowledge Constraint Graphs 4.2 知識制約グラフ
4.2.1 Equivalency Sets 4.2.1 等価性セット
4.2.2 Magnitude Measurements 4.2.2 マグニチュード測定
4.2.3 Simplifed Graphs 4.2.3 簡略化されたグラフ
4.3 Inconsistency Metrics for Knowledge Constraint Graphs 4.3 知識制約グラフの非整合性指標
4.4 Voting Unifcation Algorithm 4.4 投票統一アルゴリズム
4.4.1 Analysis of Votes 4.4.1 投票の分析
4.4.2 Priority Ordering 4.4.2 優先順位付け
4.4.3 Unifed Graph Construction 4.4.3 統一されたグラフの構築
4.4.4 Description of Constructed Graph 4.4.4 構築されたグラフの説明
5 Data Collection and Processing 5 データ収集と処理
5.1 Data Set of Analyzed Vectors 5.1 解析対象ベクターのデータセット
5.2 Volunteer Participants 5.2 ボランティア参加者
5.3 Produced Knowledge Constraint Graphs 5.3 作成された知識制約グラフ
5.4 Knowledge Constraint Graph Inconsistency Measurements 5.4 知識制約グラフの非整合性の測定
5.4.1 Graph f00 5.4.1 グラフf00
5.4.2 Graph 977 5.4.2 グラフ977
5.5 Unifed Knowledge Constraint Graph 5.5 統一された知識制約グラフ
5.6 Optimal Number of Equivalency Sets 5.6 最適な等価集合の数
6 Measurement Approach 6 測定方法
6.1 Consistent Scoring Systems 6.1 無矛盾な採点システム
6.1.1 Scoring System Defnition 6.1.1 評点リング・システムの定義
6.1.2 Consistent Scoring System Defnition 6.1.2 無矛盾な評点システムの定義
6.2 Generation of a Closest Consistent Scoring System 6.2 最も近い無矛盾性評点システムの生成
6.3 Measurement Methodology 6.3 測定方法
7 Measurement Results 7 測定結果
7.1 Mean Scoring Distance 7.1 平均得点距離
7.2 Maximum Scoring Distance 7.2 最大採点距離
7.3Acceptable Deviation 7.3 許容距離
7.4 Increasing Accuracy with More Data 7.4 より多くのデータによる精度の向上
8 Interpretation of Results and Related Work 8 結果の解釈と関連研究
9 Conclusion 9 まとめ
References 参考文献
List of Appendices 附属書一覧
Appendix A—Acronyms 附属書A - 頭字語
Appendix B- Set of Evaluated CVSS vectors 附属書B - 評価済みCVSSベクトル集合
Appendix C- Encoded Knowledge Constraint Graphs 附属書C - 符号化された知識制約グラフ

 

エグゼクティブサマリー

Executive Summary  エグゼクティブサマリー 
The Common Vulnerability Scoring System (CVSS) Version 3 maintained by the CVSS Special Interest Group (SIG) is a widely used industry standard for characterizing the properties of information technology vulnerabilities and measuring their severity. It is based on human expert opinion. Vulnerability properties are characterized through a multidimensional vector. The severity is defned primarily through a multi-part “base score” equation, with 8 input metrics, that is not readily amenable to human comprehension.  CVSS Special Interest Group (SIG) によって維持されている 共通脆弱性評点システム、 (CVSS) 第3版 は、情報技術の脆弱性の特性を特徴付け、その深刻度を測定するために広く使用されている業界標準です。CVSSは、人間の専門家の意見に基づいています。脆弱性の特性は、多次元ベクトルによって特徴づけられます。深刻度は、主に8つの入力指標を持つ多部構成の「基礎評点」式によって定義されますが、これは人間の理解には容易ではありません。
To develop the equation, CVSS SIG members frst described a set of real vulnerabilities using CVSS vectors and assigned them one of fve severity levels. This created a partial lookup table mapping vectors to severity levels. They then defned a target score range for each severity level and created an equation to attempt to map each vector to a score within the specifed score range. Finally, they reviewed the equation’s scoring of vectors not included in the partial lookup table to evaluate the effectiveness of the equation on the full set of possible vectors. Since the equation could not perfectly map vectors to score ranges, the CVSS Version 3.1 specifcation provides a measurement of error (an ‘acceptable deviation’ of 0.5 points). However, suffcient information is not provided to reproduce the experiment.  この方程式を開発するために、CVSS SIGのメンバーはまず、CVSSベクトルを使用して一連の実際の脆弱性を記述し、5つの深刻度レベルのうちの1つを割り当てました。これにより、ベクターと重要度レベルを対応させた部分的なルックアップテーブルが作成されました。次に、各重要度レベルの目標評点範囲を定義し、各ベクトルを指定された評点範囲内の評点に対応付けることを試みる方程式を作成しました。最後に,部分ルックアップテーブルに含まれていないベクトルに対する方程式の評点を確認し,可能性のあるすべてのベクトルに対する方程式の有効性を評価した.この方程式はベクターを評点範囲に完全に対応付けることができないため、CVSSバージョン3.1の仕様では、誤差の測定値(0.5点の「許容距離」)を提供しています。しかし、実験を再現するのに十分な情報は提供されていない。
This work measures the degree to which the CVSS base score equation refects the CVSS SIG expert domain knowledge while providing a reproducible justifcation for the measurements. It starts not from a set of real vulnerabilities, as the CVSS SIG did, but from a set of 66 vulnerability types (i.e., CVSS vectors) that represent 90 % of the vulnerabilities published by the U.S. National Vulnerability Database. CVSS SIG experts then evaluate these vulnerability types and encode their knowledge as constraint graphs; sets of graphs are then unifed using a voting algorithm. These unifed graphs represent sets of consistent scoring systems (mappings of vectors to scores).  この研究では、CVSS基礎評点の式がCVSS SIG専門家のドメイン知識をどの程度反映しているかを測定し、測定値に対して再現可能な正当性を提供します。CVSS SIGのように実際の脆弱性の集合からではなく、米国の国家脆弱性データベースによって公開された脆弱性の90%を占める66種類の脆弱性(すなわちCVSSベクトル)の集合から開始します。次に、CVSS SIGの専門家がこれらの脆弱性の種類を評価し、その知識を制約グラフとして表現します。そして、グラフの集合は投票アルゴリズムを用いて単一化されます。これらの統一されたグラフは、一貫した採点システム(ベクトルと評点のマッピング)の集合を表します。
The consistent scoring system closest to the CVSS Version 3.1 scores was found, and the distance between the scores and the closest consistent scoring system scores was measured. These measurements represent the degree to which the CVSS v3.1 base score equation represents the CVSS SIG expert domain knowledge.  CVSS 第3.1版の評点に最も近い一貫した採点システムを見つけ、その評点と最も近い一貫した採点システムの評点との間の距離を測定した。これらの測定値は、CVSS v3.1の基礎評点式がCVSS SIG専門家のドメイン知識をどの程度表しているかを表しています。
Using this approach, the mean and maximum distance of the CVSS v3.1 scores compared to the closest consistent scoring system scores was measured and the acceptable deviation was recalculated. Unlike acceptable deviation, the new distance metrics measure the score values themselves separate from the severity levels. Using all 12 CVSS SIG inputs, the mean scoring distance is 0.13 points, the maximum scoring distance is 0.40 points, and the acceptable deviation is 0.20 points. Sets of 11 out of 12 of the inputs were used to calculate precision measurements (i.e., standard deviation).  この方法を用いて、最も近い一貫性のある採点システムの評点と比較したCVSS 第3.1版の評点の平均距離と最大距離が測定され、許容距離が再計算されました。許容距離とは異なり、新しい距離メトリックは、深刻度レベルとは別に評点値そのものを測定します。12のCVSS SIGインプットすべてを使用した場合、平均評点リング距離は0.13点、最大評点リング距離は0.40点、許容距離は0.20点となりました。12個の入力のうち11個の入力は、精度の測定(すなわち標準距離)を計算するために使用されました。
These fndings validate that the CVSS base score equation functions as described (to the extent described by these measurements); it represents the encoded CVSS SIG domain knowledge. The measurements support the equation as defned. The security community may use it as an opaque box without understanding the internal functionality.  これらの結果は、CVSS基礎評点の式が(これらの測定値によって記述される範囲において)記述されたとおりに機能することを検証するもので、それは符号化されたCVSS SIGドメイン知識を表しています。測定結果は、定義された方程式をサポートしています。セキュリティコミュニティは、内部機能を理解することなく、不透明な箱としてそれを使用することができます。

 


 

まるちゃんの情報セキュリティ気まぐれ日記

CVSSが脆弱性についての数値をアウトプットとして出すのに対して、SSVCはとるべき対応をアウトプットして出すということで、具体的な対策に結びつける方法・・・

・2021.04.30 カーネギー大学 ソフトウェア工学研究所が「Stakeholder-Specific Vulnerability Categorization:SSVC 2.0」を発表していますね。。。

 

昔に遡り。。。

・2010.10.25 IPA 共通脆弱性評価システムCVSS概説

・2007.04.26 JVN は、名称をJP Vendor Status Notes (JVN) から、Japan Vulnerability Notes (JVN) と変更しました

 

 

| | Comments (0)

2022.05.21

CISA, FBI, NSA, ACSC, CCCS, NZ NCSC, NCSC-UK 初期アクセスを可能にする脆弱性

こんにちは、丸山満彦です。

米国のサイバーセキュリティ・インフラセキュリティ庁(CISA)、国家安全保障局(NSA)、連邦捜査局(FBI)、カナダ・サイバーセキュリティセンター(CCCS)、ニュージーランド国家サイバーセキュリティセンター(NCSC-NZ)およびコンピュータ緊急対応チーム(CERT NZ)、オランダ国家サイバーセキュリティセンター(NCSC-NL)、英国国家サイバーセキュリティセンター(NCSC-UK)が共同で、初期アクセスを可能にする脆弱性を公表していますね。。。 。。。

数あるセキュリティ対策を検討する際の優先順位付けに活用してくださいということですかね。。。

最近このメンバーでちょいちょい発表していますね。。。今回はオランダが入っていますね。。。

 

● NSA

・2022.05.17 NSA, Allies Issue Cybersecurity Advisory on Weaknesses that Allow Initial Access

NSA, Allies Issue Cybersecurity Advisory on Weaknesses that Allow Initial Access NSAと同盟国、初期アクセスを可能にする脆弱性に関するサイバーセキュリティアドバイザリーを発行
FORT MEADE, Md. — The Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA) and the FBI, along with allied nations, published a Cybersecurity Advisory today to raise awareness about the poor security configurations, weak controls and other poor network hygiene practices malicious cyber actors use to gain initial access to a victim’s system. メリーランド州フォートミード - サイバーセキュリティ・インフラセキュリティ庁(CISA)、国家安全保障局(NSA)、FBIは、同盟国とともに、悪意のあるサイバー行為者が被害者のシステムへの初期アクセスを得るために使用する、不十分なセキュリティ設定、弱い制御、その他のネットワーク衛生の不備に関する注意を喚起するサイバーセキュリティアドバイザリーを本日発表しました。
“Weak Security Controls and Practices Routinely Exploited for Initial Access” also includes best practices that can help organizations strengthen their defenses against this malicious activity. また、「初期アクセスのために日常的に悪用される脆弱なセキュリティ制御と慣行」には、このような悪意のある行為に対する組織の防御を強化するのに役立つベストプラクティスも含まれています。
“As long as these security holes exist, malicious cyber actors will continue to exploit them,” said NSA Cybersecurity Director Rob Joyce. “We encourage everyone to mitigate these weaknesses by implementing the recommended best practices.” NSAのサイバーセキュリティディレクターであるロブ・ジョイスは、以下のように述べています。「このようなセキュリティホールが存在する限り、悪意のあるサイバーアクターはそれを悪用し続けるでしょう。我々は、推奨されるベストプラクティスを実施することにより、これらの弱点を軽減するよう、すべての人に呼びかけます。」
Some of the most common weaknesses include not enforcing multifactor authentication, incorrectly applying privileges or permissions and errors within access control lists and not keeping software up to date. The advisory recommends mitigations that control access, harden credentials, establish centralized log management and more. 最も一般的な弱点としては、多要素認証の未実施、特権や許可の不正な適用、アクセス制御リスト内の誤り、ソフトウェアを最新に保っていないことなどが挙げられます。この勧告では、アクセスの制御、認証情報の強化、ログの集中管理などの緩和策を推奨しています。
CISA produced the advisory with help from NSA and other partners. That includes the FBI, the Canadian Centre for Cyber Security (CCCS), the New Zealand National Cyber Security Centre (NCSC-NZ) and Computer Emergency Response Team (CERT NZ), the Netherlands National Cyber Security Centre (NCSC-NL), and the United Kingdom National Cyber Security Centre (NCSC-UK) on the advisory. Many of the same cybersecurity authorities collaborated to release a complementary advisory on 27 April, which highlighted the top routinely exploited vulnerabilities from 2021. CISAは、NSAや他のパートナーの協力を得て、この勧告を作成しました。その中には、FBI、カナダ・サイバーセキュリティセンター(CCCS)、ニュージーランド国家サイバーセキュリティセンター(NCSC-NZ)およびコンピュータ緊急対応チーム(CERT NZ)、オランダ国家サイバーセキュリティセンター(NCSC-NL)、英国国家サイバーセキュリティセンター(NCSC-UK)が勧告に参加しています。同じサイバーセキュリティ当局の多くが協力して4月27日に補足勧告を発表し、2021年から日常的に悪用される脆弱性の上位を取り上げました。
Read the full report here. レポートの全文はこちらから確認ください。
Visit our full library for more cybersecurity information and technical guidance. その他のサイバーセキュリティ情報および技術ガイダンスについては、当庁のライブラリを確認ください。

 

・[PDF] Weak Security Controls and Practices Routinely Exploited for Initial Access

20220521-00743

Best Practices to Protect Your Systems システムを保護するためのベストプラクティス
· Control access. ・アクセス制御
· Harden credentials. ・クレデンシャルの強化
· Establish centralized log management. ・ログの一元管理
· Use antivirus. ・アンチウイルスの利用
· Employ detection tools. ・検知ツールの導入
· Operate services exposed on internet-accessible hosts with secure configurations. ・インターネットに接続可能なホストで公開されているサービスの安全な設定での運用
· Keep software updated. ・ソフトウェアの最新化

 


 

まるちゃんの情報セキュリティ気まぐれ日記

・2022.05.13 CISA、NSA、FBI、NCSC~UK、ACSC、CCCS、NCSC-NZ:マネージドサービスプロバイダー(MSP)と顧客を保護するためのサイバーセキュリティアドバイザリー

・2022.05.04 CISA, FBI, NSA, ACSC, CCCS, NZ NCSC, NCSC-UK 2021年に頻繁に悪用された脆弱性 (2022.04.27)

| | Comments (0)

より以前の記事一覧