---
title: "ASMの優先順位はどう決める？ Asset Inventoryと資産重要度分析"
slug: "asm-risk-prioritization-asset-criticality"
description: "ASMで見つかった大量のAssetやVulnerabilityを、Business Context、資産重要度、Exposure、Exploitabilityから優先順位へつなげる考え方を整理します。"
publishedAt: "2026-08-14"
updatedAt: "2026-08-15"
status: "published"
category: "security"
tags:
  - "asm"
  - "attack-surface-management"
  - "asset-management"
  - "risk-prioritization"
  - "cvss"
articleType: "technical-note"
source: "manual"
publicRisk: "low"
reviewNotes: "NIST CSF 2.0、NISTIR 8179、FIRST CVSS v4.0の一次資料を基に、ASMでの資産重要度分析と優先順位付けを整理。"
series: null
episode: null
audience: "security-engineers"
lang: "ja"
aiAssisted: true
humanReviewed: true
canonicalUrl: null
coverImage: null
external:
  qiita: null
  zenn: null
  note: null
  x: null
  youtube: null
  podcast: null
---

## 優先順位付けに必要な三つの判断

Attack Surface Management（ASM）でAssetやVulnerabilityを大量に発見しても、それだけでは何を優先して守るべきかは決まりません。

例えば、「CriticalなVulnerabilityが20件あるServer」と「悪用可能なVulnerabilityが1件ある決済API」があったとします。件数だけなら前者が目立ちます。しかし、前者は内部にあり廃止予定、後者はInternet Facingで購入Workflowに不可欠かもしれません。この場合、決済APIの1件を先に扱う方が大きなRisk Reductionにつながる可能性があります。

優先順位を考えるには、同じAssetを二つの方向から見る必要があります。

![Business ViewのAsset CriticalityとAttack Surface ViewのExposure・Threatを同じAsset上で接続し、Risk Prioritizationを決める図](/images/articles/asm-risk-prioritization-asset-criticality/two-views.webp)

- Business側から、失うと何が困るのかを見る
- Attack Surface側から、今どれだけ攻撃され得るのかを見る

この二つを同じAsset上で接続して、今どこへSecurity Resourceを投入するかを決めます。

ここで区別したいのは、次の三つです。

| 判断 | 問い | 主な入力 |
| --- | --- | --- |
| 資産重要度（Asset Criticality） | このAssetを失うと、どれほど困るか | Business Impact、Dependency、代替手段、Data |
| 現在のRisk状況（Current Risk） | 今、このAssetはどれほど危険か | Exposure、Vulnerability、Exploitability、Threat、既存Control |
| 対応優先度（Response Priority） | 何を、いつ、どの方法で扱うか | 現在のRisk、Risk Tolerance、実現可能性、Resource |

重要なAssetが常に最初の作業対象になるわけではありません。また、Riskが最も高い項目を、その日のうちにPatchできるとも限りません。重要度、Risk、作業順を分けると、優先順位の理由を説明しやすくなります。

この記事では、現時点のExposure、Threat、既存Controlを踏まえた運用上の評価を、便宜上`Current Risk`と呼びます。正式なRisk管理では、Controlを適用する前の[`inherent risk`](https://csrc.nist.gov/glossary/term/inherent_risk)と、適用後に残る[`residual risk`](https://csrc.nist.gov/glossary/term/residual_risk)を分けて記録します。対応順を決めるときは、既存Controlで何が軽減され、どのRiskが残っているかまで確認する必要があります。

前の記事では、[Attack Surfaceの定義とASM・EASMの対象範囲](/blog/asm-attack-surface-definition)を整理しました。この記事では、その次の段階として、発見したAttack SurfaceをBusiness上の優先順位へどう接続するかを扱います。

## 優先順位付けの土台としてのAsset Inventory

優先順位付けの土台になるのがAsset Inventoryです。

[NIST CSF 2.0のAsset Management（ID.AM）](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf#page=23)では、Business Purposeを実現するData、Hardware、Software、System、Facility、Service、Peopleなどを把握し、Business Objectiveに対する相対的重要性と組織のRisk Strategyに沿って管理する考え方が示されています。

EC事業を例にすると、対象はServerやApplicationだけではありません。

| 種類 | 例 |
| --- | --- |
| Data | 顧客情報、注文情報、決済情報 |
| System / Service | ECサイト、Payment API、Order Management、Identity Provider |
| Infrastructure | Cloud、Network、Endpoint |
| External Dependency | Payment Provider、SaaS、Logistics Provider |
| People / Facility | 運用担当者、Office、Data Center |

ただし、Asset Inventoryを100%完成させてからASMを始める、という意味ではありません。実際の環境には、管理部門が把握していないShadow IT、廃止されずに残ったLegacy System、新しく作られたCloud Resourceなどがあります。

![既知のAssetから継続的なDiscoveryを行い、未知・未管理のAssetの所有者と用途を確認してInventoryを更新する循環](/images/articles/asm-risk-prioritization-asset-criticality/inventory-loop.webp)

既知のInventoryはDiscoveryの起点になります。一方、Discoveryの結果はInventoryを更新します。Asset Inventoryは完成済みの正解表ではなく、ASMによって継続的に確かめる管理対象です。

発見結果をそのまま確定Assetとして登録するのも危険です。関連するDomainやIPが見つかっても、自組織が所有しているとは限りません。少なくとも、次の状態を分けて持つと扱いやすくなります。

| 状態 | 意味 | 次のAction |
| --- | --- | --- |
| Candidate | 自組織との関連が推定される | 帰属の根拠を確認する |
| Confirmed | 所有・管理関係を確認できた | OwnerとBusiness Contextを付与する |
| Rejected | 自組織のAssetではない | 根拠を残して探索対象から外す |
| Historical | 過去には関係したが現在は利用していない | 廃止状態や残存Exposureを確認する |

Discoveryの件数よりも、候補を確定・却下できるか、Owner不明のAssetがどれだけ滞留しているかが運用品質に影響します。

## AssetをBusinessへつなぐContext

Inventoryに次の名前だけが並んでいても、重要度は分かりません。

```text
payment-api.example.com
customer-db-prod
legacy-reporting-server
```

必要なのは、AssetをBusiness上の意味へ変換するContextです。例えばPayment APIなら、次のような情報を結び付けます。

| 項目 | 例 | なぜ必要か |
| --- | --- | --- |
| Owner | Payment Team | 誰が判断・対応するかを決める |
| Business Service | EC決済 | どの価値を支えるかを示す |
| Environment | Production | 利用状態を区別する |
| Supported Workflow | 注文 → 決済 | Business Impactを辿る |
| Data | 顧客・決済情報 | Confidentialityや規制影響を見る |
| Dependencies | Customer DB / Payment Provider | 障害・侵害の波及先を知る |
| Alternative | なし | 代替可能性を評価する |
| Lifecycle | Active | 廃止・移行予定を反映する |

これだけ分かれば、「Web APIが一つある」ではなく、「顧客の購入Workflowを担い、代替手段がないProduction Service」として理解できます。

重要なのは、すべての項目を最初から完璧に埋めることではありません。優先順位に効くContextから段階的に増やします。Owner、Business Service、Environment、Lifecycleの四つだけでも、何もないAsset一覧より大きく前進します。

## Workflow起点の資産重要度分析

資産重要度分析で陥りやすいのは、Systemの種類から重要度を決めることです。

```text
Payment API → ProductionだからHigh
Customer DB → DatabaseだからHigh
認証基盤 → 認証だからHigh
```

この付け方では、多くのAssetがHighになります。Highが相対的な優先順位として機能しなくなり、最終的にはVulnerability件数や製品スコアへ戻ってしまいます。

[NISTIR 8179のCriticality Analysis Process Model](https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8179.pdf#page=16)は、Program、System、Componentなどを、組織目標に対する重要性と、機能不全や喪失がもたらすImpactからPrioritizeする方法を示しています。

![BusinessからSystemとComponentへ重要な対象を絞るTop-down分析と、Componentから障害・侵害の影響を遡るBottom-up分析](/images/articles/asm-risk-prioritization-asset-criticality/top-down-bottom-up.webp)

EC事業なら、次のようにBusinessまで遡ります。

```text
Business Objective
顧客がオンラインで商品を購入できる
        ↓
Critical Workflow
注文 → 決済 → 在庫引当 → 出荷
        ↓
System / Service
Payment API / Order Management / Inventory System
        ↓
Component / Dependency
Customer DB / Payment Provider / Cloud Infrastructure
```

この関係なら、Payment APIが重要な理由を「Payment APIだから」ではなく、「売上を生み出す購入Workflowを成立させるうえで不可欠だから」と説明できます。

### Dependencyを補完するBottom-up分析

[NISTIR 8179のModel Overview](https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8179.pdf#page=16)では、BusinessからComponentへ下るTop-down分析と、Componentの機能不全や侵害がSystemやProgramへ与えるImpactを遡るBottom-up分析を組み合わせています。Baseline Criticalityを定めた後の[Process E](https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8179.pdf#page=56)では、Process間のInteractionやDependency、既存のRisk情報を横断的に確認し、主にSystem / SubsystemとComponent / SubcomponentのCriticalityを検証・調整します。Program LevelのBaseline Criticalityは、通常はProcess Eで確定し直す対象ではなく、横断確認の入力として扱われます。

Business Ownerが「決済Serviceが重要」と把握していても、実際には共通のIdentity Providerや、小さな変換Job、外部Providerが停止点になっているかもしれません。EngineeringとOperationsから依存関係を遡ることで、表面上は目立たないComponentの重要度を補正できます。

WorkflowとIT Assetは、同じ種類のものとして一つの一覧に並べるより、Business LayerとTechnology Layerに分けて関係を持たせる方が理解しやすくなります。

```text
Business Layer
├─ Business Objective: 商品を販売する
└─ Essential Workflow: 注文 → 決済 → 出荷
             │
             │ depends on
             ↓
Technology Layer
├─ EC Application
├─ Payment API
├─ Order DB
├─ Inventory System
└─ Payment Provider
```

Payment APIはIT Assetです。IP、URL、Software Version、Vulnerabilityなどを管理できます。一方、「決済する」というWorkflowは業務の流れであり、IPやOS、CVEを持ちません。ここで言いたいのは、Workflowを広い意味での資産と呼んではいけないということではなく、IT Assetとまったく同じ種類の管理対象として扱う必要はないということです。

両者の関係は、どちら側から見るかによって表現が変わります。

```text
Payment API ── supports ──> 決済Workflow
決済Workflow ── depends on ──> Payment API
```

`supports`は「Payment APIが決済業務を支える」、`depends on`は「決済業務がPayment APIに依存する」という意味です。同じ関係を逆方向から読んでいます。

この関係があると、ASMで`payment-api.example.com`のVulnerabilityを発見したときに、「このAPIが停止・侵害されると決済が止まり、商品の購入や売上へ影響する」とBusiness Impactまで辿れます。逆に、Business側で決済が重要なWorkflowだと分かれば、Payment API、Database、Authentication Service、外部Payment Providerなど、重点的に守るべきIT Assetを洗い出せます。

ASMが主にTechnology LayerのAsset、Exposure、Vulnerabilityを継続的に発見し、Criticality AnalysisがBusiness Layerから重要性を与えます。この上下を結ぶことが、Business CriticalityをASMの優先順位付けへ取り込む具体的な方法です。

## Failure ScenarioによるImpact評価

Ownerへ「このSystemは重要ですか」と聞くだけでは、多くの回答がHighになります。Systemを担当している以上、重要だと感じるのは自然です。

質問を具体的なFailure Scenarioへ変えます。

- 30分、4時間、1日停止すると何が起きるか
- 誤ったDataを返した場合、どの判断や処理が壊れるか
- 情報が漏えいした場合、顧客・契約・規制へどう影響するか
- 手作業や別Serviceによる代替手段があるか
- 他の重要なSystemがいくつ依存しているか
- 復旧に必要なData、手順、担当者が揃っているか

確認軸は、Confidentiality、Integrity、Availabilityだけに限りません。時間によるImpactの増加、代替手段、Dependency、Lifecycleも重要です。

| 観点 | 確認する内容 |
| --- | --- |
| Business Impact | どの業務・Missionが成立しなくなるか |
| Time | 停止時間とともにImpactがどう増えるか |
| Financial Impact | 売上減少や追加Costが発生するか |
| Customer Impact | 顧客が何をできなくなるか |
| Data | 漏えい・改ざん・喪失で何が起きるか |
| Dependency | 他の重要Systemが依存しているか |
| Alternative | 現実的な代替手段があるか |
| Recovery | 復旧にどれほど時間と手順が必要か |
| Legal / Contract | 法令、契約、SLAへ影響するか |
| Lifecycle | 現役、移行中、廃止予定のどれか |

CriticalityはSecurity Teamだけで決めるTechnical Scoreではありません。Business Ownerは売上や顧客影響、EngineeringはDependency、Operationsは代替手段と復旧、Legal / Complianceは法的要件、SecurityはExposureやThreatを把握しています。

誰が最終決定するかは組織によって異なりますが、根拠と情報提供者を記録しておくと、後から重要度を更新できます。

## Criticalityの判定基準と見直し

High / Medium / Lowの三段階でも、より細かな段階でも構いません。唯一の正しいScoreはありません。

以下は単純な実装例です。

| Level | 判定例 |
| --- | --- |
| High | 主要Businessを継続できない、大きな顧客・法的影響がある、代替手段がない |
| Medium | 一部の重要業務へ大きく影響するが、限定的な代替や復旧手段がある |
| Low | 主要Businessへの影響が限定的で、代替が容易、または廃止予定である |

大切なのはLevel名ではなく、何をもってHighとするかを組織内で揃えることです。

Criticalityを一つの数値へ潰しすぎると、同じHighでも理由が分からなくなります。例えば、Availabilityが重要なServiceと、Confidentialityが重要なData Storeでは、必要なControlが異なります。総合Levelに加えて、判定根拠やCIAごとのRequirementを残す方がProtectionへつなげやすくなります。

また、Criticalityには評価日と見直し条件が必要です。System移行、Business撤退、契約変更、Dependency追加によって重要度は変わります。`High`という値だけでなく、`なぜHighか`と`いつ見直すか`を管理します。

## Asset Criticalityと現在のRisk状況の接続

Asset Criticalityで分かるのは、Businessにとって何が重要かです。今日最初に何へSecurity対応するかは、まだ決まりません。

NIST CSF 2.0では、Asset Managementの[`ID.AM-05`](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf#page=23)でAssetをClassification、Criticality、Resource、MissionへのImpactに基づいてPrioritizeします。一方、Risk Assessmentの[`ID.RA-05`](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf#page=24)では、Threat、Vulnerability、Likelihood、Impactを用いて`inherent risk`を理解し、Risk ResponseのPrioritizationへつなげます。その次の[`ID.RA-06`](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf#page=24)が、Risk Responseの選択、優先順位付け、計画、追跡、共有を扱います。

ASMは、Assetに現在のAttack Contextを加えます。

- 外部または内部のどこから到達できるか
- VulnerabilityやMisconfigurationが実在するか
- 認証やNetwork制限などのControlがあるか
- ExploitやPoCが存在し、攻撃で使われているか
- 強い権限や重要なDependencyへ進む経路があるか
- AssetとExposureの状態が現在も有効か

![CriticalなFindingが20件ある廃止予定の内部Legacy Serverと、悪用可能なFindingが1件あるInternet FacingのPayment APIをRisk Reductionで比較する図](/images/articles/asm-risk-prioritization-asset-criticality/findings-vs-risk.webp)

図の判断は、Payment APIを常に先に直すという規則ではありません。仮定した条件の下では、その判断があり得るという比較です。Legacy Serverが実際には重要なCredentialを持ち、横展開の起点になるなら、優先順位は変わります。

このように、Business ContextとAttack Contextの両方を同じAssetへ結び付けます。

```mermaid
flowchart TB
  Asset["対象のAsset"]
  Asset --> Business["事業上のContext<br/>重要度・Business Impact・Dependency"]
  Asset --> Attack["現在の攻撃条件<br/>Exposure・Vulnerability・Threat"]
  Business --> Risk["現在のRisk状況<br/>失ったときのImpact × 攻撃可能性"]
  Attack --> Risk
```

図のポイントは、Business ContextとAttack Contextを単純に足すことではありません。まず同じAssetに両方のContextを結び付け、そのAssetを失ったときのImpactと、現在の攻撃可能性を合わせて評価します。既存Controlを考慮した場合は、軽減後に残るRiskも分けて記録します。

これは特定の計算式ではありません。掛け算や足し算で自動的に正解が出るという意味ではなく、Prioritizationに必要な情報の関係を表しています。

Vulnerabilityを多く消すことと、組織のRiskを大きく減らすことは同じではありません。件数をKPIにすると、直しやすいLow Criticality Assetへ作業が偏ることがあります。対応件数に加えて、重要Workflow上のRiskをどれだけ減らしたかを見る必要があります。

## CVSS v4.0 BTEが扱う範囲

ここまでのPriority判断には、CVSS v4.0のBTEも利用できます。ただし、BTEだけでBusiness Risk全体を表せるわけではありません。

[FIRSTのCVSS v4.0 Specification「Metrics」](https://www.first.org/cvss/v4.0/specification-document#Metrics)では、CVSSを四つのMetric Groupに分けています。

| Group | 表すもの | Scoreへの反映 |
| --- | --- | --- |
| Base | Vulnerability固有のTechnical Severity | 反映する |
| Threat | 時間とともに変化するExploit Maturity | 反映する |
| Environmental | 利用環境、Control、AssetのCIA Requirement | 反映する |
| Supplemental | Safety、Automatableなどの補足Context | 数値Scoreには反映しない |

[`CVSS-BTE`](https://www.first.org/cvss/v4.0/specification-document#Nomenclature)は、Base、Threat、Environmentalを反映したScoreの呼称です。独立した一つのMetricではありません。

![CVSSのBase・Threat・EnvironmentalをCVSS-BTEへ反映し、売上・顧客影響・規制・Reputation・対応ResourceはCVSSの外側からRisk Prioritizationへ加える図](/images/articles/asm-risk-prioritization-asset-criticality/cvss-bte-scope.webp)

[Environmental MetricsのSecurity Requirements](https://www.first.org/cvss/v4.0/specification-document#Confidentiality-Integrity-and-Availability-Requirements-CR-IR-AR)には、Confidentiality Requirement（CR）、Integrity Requirement（IR）、Availability Requirement（AR）があります。資産重要度分析で決済Serviceの停止許容時間が短いと分かった場合、その情報をARの判断材料にできます。ただし、[FIRSTのUser GuideにあるAvailability Requirementの指針](https://www.first.org/cvss/v4.0/user-guide#Availability-Requirement-AR)は、Uptime Requirementだけでなく冗長性も考慮します。重要度がHighだからARも自動的にHighになるのではなく、対象Systemに必要なAvailabilityと、実際の冗長構成を確認して設定します。

また、Modified Metricsを使うと、実際の配置やControlによってBaseの前提を調整できます。[FIRSTのConsumer Implementation Guide「Asset Management Systems and Environmental Metrics」](https://www.first.org/cvss/v4.0/implementation-guide#asset-management-systems-and-environmental-metrics)も、Asset Management SystemにあるNetwork配置、Proxy、IPS、Privilege、Encryption、Load Balancing、CIA RequirementなどをEnvironmental Metricsへ利用する例を示しています。

### CVSSの外側にあるBusiness Context

[CVSSのBase ScoreはRiskではなくSeverityです](https://www.first.org/cvss/v4.0/user-guide#CVSS-Base-Score-CVSS-B-Measures-Severity-not-Risk)。ThreatとEnvironmentalを加えたBTEは、組織の環境へ近づけた、より有用なRisk Assessmentの入力になります。しかし、[FIRSTのSpecification「Introduction」](https://www.first.org/cvss/v4.0/specification-document#Introduction)は次のようなFactorをCVSSの範囲外としています。

- Regulatory Requirement
- 影響を受けるCustomer数
- Monetary Loss
- Life / Propertyへの影響
- Reputational Impact

さらに、対応できるEngineer、Maintenance Window、Budget、VendorのFix提供時期などもCVSSには入りません。

したがって、CVSS-BTEはVulnerability Priorityを現実へ近づける有用なInputですが、Asset Criticality AnalysisやBusiness Risk Managementの代替ではありません。

## 現在のRisk状況から対応優先度へ

Riskが高いと分かっても、即座にPatchできるとは限りません。

NIST CSF 2.0の[`ID.RA-06`](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf#page=24)も、Riskを評価するだけでなく、Responseの選択、優先順位付け、計画、追跡、共有までを一つのOutcomeとして扱っています。

| 制約 | 例 | 取り得るResponse |
| --- | --- | --- |
| Maintenance Window | 常時稼働Serviceを停止できない | 一時Controlを置き、次のWindowでPatchする |
| Vendor Dependency | Fixがまだ提供されていない | 機能停止、Network制限、監視強化を行う |
| Resource | 対応できるEngineerが限られる | Risk Reductionの大きい項目へ集中する |
| Change Risk | 修正自体がBusiness停止を招く | Staging検証、段階Rollout、Rollbackを準備する |
| Architecture | 単純なPatchではAttack Pathが残る | Segmentationや認可設計を見直す |

実際の作業順は、概念的には次の情報で決まります。

```mermaid
flowchart TB
  Risk["現在のRisk状況<br/>攻撃可能性とBusiness Impact"] --> Strategy["対応方針<br/>どのRiskをどこまで減らすか"]
  Tolerance["Risk Tolerance<br/>許容できる残余Risk"] --> Strategy

  Resources["利用可能なResource<br/>担当者・時間・Budget"] --> Execution["実行条件<br/>今取れる対応は何か"]
  Feasibility["技術的な実現可能性<br/>Patch・一時Control・設計変更"] --> Execution
  Constraints["Business上の制約<br/>Maintenance Window・Change Risk"] --> Execution

  Strategy --> Priority["対応優先度<br/>誰が・何を・いつ・どう扱うか"]
  Execution --> Priority
```

現在のRisk状況が高い順に作業を並べるのではなく、許容できる残余Riskと、実際に取れる対応を分けて考えます。その上で、対応方法、Owner、期限を含む作業順序へ落とし込みます。

対応できないことと、Riskを受容したことは同じではありません。すぐに根治できない場合も、到達経路の制限、Featureの一時停止、Credential Rotation、追加監視などのMitigationを選べます。誰が、どの期限まで、どの残余Riskを承認したかを記録します。

## Baseline SecurityとDefense in Depth

Low Criticality Assetを守らなくてよいわけではありません。すべてのAssetにBaseline Securityを適用し、そのうえでHigh CriticalityまたはHigh Riskの対象へ追加のProtection、Monitoring、Resilienceを配分します。

Defense in Depthも、Security製品を増やすこと自体が目的ではありません。一つのLayerが破られても、別の独立したLayerがAttackをPrevent、Detect、Containできるようにします。

Payment APIなら、例えば次のようにAttack PathへControlを置きます。

| Layer | Control例 | 役割 |
| --- | --- | --- |
| Edge | WAF、Rate Limit、DDoS Protection | 不要なTrafficを減らす |
| Identity | MFA、Credential管理 | なりすましを防ぐ |
| Authorization | 最小権限、Object-level認可 | 権限外操作を止める |
| Application | Input Validation、安全なDefault | 悪用条件を減らす |
| Network | Segmentation、Egress制限 | 侵害後の移動を抑える |
| Data | Encryption、Backup、Integrity Check | DataへのImpactを抑える |
| Detection | Log、Alert、Response手順 | 侵害を見つけ封じ込める |

### Asset CriticalityをResilienceへつなぐ

重要なAssetは、攻撃されないように守るだけでなく、壊れたり止まったりしてもBusinessを継続・復旧できるようにする必要があります。Cyberattackだけでなく、Software障害、Cloud障害、Operator Mistake、Database障害などで停止する可能性もゼロにはできないからです。

NIST CSF 2.0でも、[`PR.IR-03`](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf#page=26)で通常時と不利な状況の両方でResilience Requirementを満たす仕組みを求め、[`RC.RP-02`](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf#page=28)でRecovery Actionの選択、範囲設定、優先順位付け、実行を扱っています。

```mermaid
flowchart TB
  Criticality["決済System<br/>重要度: High"] --> Impact["停止すると購入できず<br/>EC売上に影響する"]

  Impact --> Protection["防御<br/>攻撃されにくくする"]
  Protection --> Controls["WAF / MFA / Segmentation<br/>攻撃の予防・検知・封じ込め"]

  Impact --> Resilience["Resilience<br/>止めない・止まっても戻す"]
  Resilience --> Recovery["冗長化 / Failover<br/>Backup / Recovery / Incident Response"]
```

例えば、Corporate Websiteは8時間停止してもBusiness Impactが限定的である一方、Payment Systemは30分の停止でも売上に影響すると仮定します。両方にBaseline Securityは必要ですが、Payment SystemにはRedundancy、Failover、短時間で復旧する手順へより厚く投資する合理性があります。

Criticality AnalysisでBusiness Impactの大きいAssetが分かれば、「どのSystemを優先して復旧できるようにするか」「どの程度短い時間で復旧できるよう設計するか」といった投資判断に利用できます。複数のSystemが同時に停止した場合も、Payment System、Order System、Customer Supportのように、停止Impactと復旧要員をもとに順番を決められます。

ただし、Criticalityが高いAssetへすべてのResilience Controlを載せるという意味ではありません。StatelessなAPIならBackupよりもRedundancyや再Deploy能力、DatabaseならBackup、Replication、Restore前のIntegrity確認が重要です。CriticalityとFailure Scenarioに合わせて、継続・復旧に効く仕組みを選びます。

## Asset Contextの最小構成

最初から巨大なCriticality Management Systemを作る必要はありません。まず、同じAssetへBusiness ContextとAttack Contextを結び付けます。

| 項目 | 例 | Context |
| --- | --- | --- |
| Asset | `payment-api.example.com` | Identifier |
| Owner | Payment Team | Ownership |
| Business Service | EC決済 | Business |
| Supported Workflow | 注文 → 決済 | Business |
| Customer Impact | 停止すると購入不可 | Business |
| Data | 顧客・決済情報 | Business / CIA |
| Dependencies | Customer DB / Payment Provider | Architecture |
| Alternative | なし | Resilience |
| Lifecycle | Active | Lifecycle |
| Criticality | High | Business |
| Internet Exposure | Public | Attack Surface |
| Finding | Exploitable Vulnerability | Attack Surface |
| Threat Context | Exploitを観測 | Threat |
| Review Date | 四半期ごと、または変更時 | Governance |

運用では、すべてのContextが同じ速度で変わるわけではありません。

- Business ObjectiveやCriticalityは、Business変更やSystem移行時に見直す
- Owner、Lifecycle、Dependencyは、組織・構成変更に合わせて更新する
- Exposure、Vulnerability、Exploitabilityは、より短いCycleで再評価する

一つの総合Scoreだけを保存すると、どの変化で優先順位が上がったのか分かりません。元のContextと更新日時を残し、Priorityは再計算できる状態にします。

## 優先順位付けの実務Process

記事の内容を実務へ落とすと、Assetの発見からResponseで終わる一方向の作業ではなく、変化を検知して再評価する循環になります。

```mermaid
flowchart TB
  Discover["1. Assetの発見・帰属確認"]
  Business["2. Business Contextの付与"]
  Criticality["3. 資産重要度の評価"]
  Attack["4. 現在の攻撃条件を確認"]
  Response["5. 対応方法と優先度を決定"]
  Monitor["6. 変化を監視し再評価"]

  Discover --> Business --> Criticality --> Attack --> Response --> Monitor
  Monitor -. "変化を検知" .-> Discover
```

ここで`Candidate`と`Confirmed`はAsset Inventoryの状態、`Critical Workflow`はBusiness Impactが大きい業務経路、`Attack Context`はExposure、Vulnerability、Exploitability、Threat Contextのまとまりです。前節までで分けて整理した情報を、このProcessで同じAssetへ順に結び付けます。

実務のチェックリストにすると、次の順で進められます。

1. 既知のAsset InventoryとASMのDiscovery結果を照合し、Candidateの帰属を確認してOwnerとLifecycleを付ける
2. Confirmed AssetをBusiness ServiceとCritical WorkflowへMappingする
3. Failure ScenarioからImpact、Dependency、Alternativeを確認し、組織内の基準でCriticalityを判定する
4. Exposure、Vulnerability、Exploitability、Threat Contextを加え、現在のRisk状況を評価する
5. Risk Tolerance、Technical Feasibility、Resourceを考慮し、実行可能なResponseを選ぶ
6. Business、Asset、Exposure、Threatの変化を検知し、Criticalityと現在のRisk状況を再評価する

このProcessで最も難しいのは、数式を作ることではなく、AssetをBusiness Contextへ結び付け続けることです。Owner不明、Workflow不明、Dependency不明のAssetが増えるほど、優先順位はTechnical Severityへ引っ張られます。

逆に、最小限でもContextがつながっていれば、「なぜこのRiskへ今Resourceを投入するのか」をBusiness、Engineering、Operations、Securityの間で共有できます。

## Business Risk Reductionを基準にしたASM運用

ASMの価値は、Attack SurfaceやVulnerabilityを大量に列挙することだけではありません。

```mermaid
flowchart TB
  Scope["1. Assetを把握する"]
  Importance["2. 失ったときのImpactを評価する"]
  Exposure["3. 現在の攻撃条件を観測する"]
  Risk["4. 現在のRisk状況を評価する"]
  Action["5. 対応順と方法を決める"]

  Scope --> Importance --> Exposure --> Risk --> Action
```

各段階は別々の管理活動ですが、同じAsset Identifierで情報をつなぐことで、Discovery結果を作業順序まで説明できるようになります。

Business Criticalityだけでも、Vulnerability Severityだけでも優先順位は決まりません。Business側から見た重要度と、攻撃者側から見た現在の危険性を、同じAsset上で接続します。

CVSS-BTEは、Threat Intelligenceや自組織におけるCIA Requirement、実環境のControlを反映する有用な入力です。ただし、売上、顧客影響、規制、Reputation、対応Resourceまで一つのScoreで表すものではありません。

最終的に目指したいのは、「Criticalを何件消したか」だけで測るSecurityから、「限られたResourceでBusiness Riskをどれだけ減らせたか」を説明できるSecurityへの移行です。

## 参考資料

- [NIST: The NIST Cybersecurity Framework（CSF）2.0](https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20)
- [NIST: Criticality Analysis Process Model（NISTIR 8179）](https://www.nist.gov/publications/criticality-analysis-process-model)
- [FIRST: CVSS v4.0 Specification Document](https://www.first.org/cvss/v4.0/specification-document)
- [FIRST: CVSS v4.0 User Guide](https://www.first.org/cvss/v4.0/user-guide)
- [FIRST: CVSS v4.0 Consumer Implementation Guide](https://www.first.org/cvss/v4.0/implementation-guide)