ASMの優先順位はどう決める？ Asset Inventoryと資産重要度分析

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

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

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

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

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

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

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

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

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

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

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

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

NIST CSF 2.0のAsset Management（ID.AM）では、Business Purposeを実現するData、Hardware、Software、System、Facility、Service、Peopleなどを把握し、Business Objectiveに対する相対的重要性と組織のRisk Strategyに沿って管理する考え方が示されています。

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

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

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

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

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

AssetをBusinessへつなぐContext

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

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

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

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

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

Workflow起点の資産重要度分析

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

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

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

NISTIR 8179のCriticality Analysis Process Modelは、Program、System、Componentなどを、組織目標に対する重要性と、機能不全や喪失がもたらすImpactからPrioritizeする方法を示しています。

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

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では、BusinessからComponentへ下るTop-down分析と、Componentの機能不全や侵害がSystemやProgramへ与えるImpactを遡るBottom-up分析を組み合わせています。Baseline Criticalityを定めた後のProcess Eでは、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に分けて関係を持たせる方が理解しやすくなります。

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とまったく同じ種類の管理対象として扱う必要はないということです。

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

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も重要です。

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

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

Criticalityの判定基準と見直し

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

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

大切なのは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でAssetをClassification、Criticality、Resource、MissionへのImpactに基づいてPrioritizeします。一方、Risk AssessmentのID.RA-05では、Threat、Vulnerability、Likelihood、Impactを用いてinherent riskを理解し、Risk ResponseのPrioritizationへつなげます。その次のID.RA-06が、Risk Responseの選択、優先順位付け、計画、追跡、共有を扱います。

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

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

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

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

図を読み込み中...

図のポイントは、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」では、CVSSを四つのMetric Groupに分けています。

CVSS-BTEは、Base、Threat、Environmentalを反映したScoreの呼称です。独立した一つのMetricではありません。

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

また、Modified Metricsを使うと、実際の配置やControlによってBaseの前提を調整できます。FIRSTのConsumer 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です。ThreatとEnvironmentalを加えたBTEは、組織の環境へ近づけた、より有用なRisk Assessmentの入力になります。しかし、FIRSTのSpecification「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も、Riskを評価するだけでなく、Responseの選択、優先順位付け、計画、追跡、共有までを一つのOutcomeとして扱っています。

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

図を読み込み中...

現在の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を置きます。

Asset CriticalityをResilienceへつなぐ

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

NIST CSF 2.0でも、PR.IR-03で通常時と不利な状況の両方でResilience Requirementを満たす仕組みを求め、RC.RP-02でRecovery Actionの選択、範囲設定、優先順位付け、実行を扱っています。

図を読み込み中...

例えば、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が同じ速度で変わるわけではありません。

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

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

優先順位付けの実務Process

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

図を読み込み中...

ここで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を大量に列挙することだけではありません。

図を読み込み中...

各段階は別々の管理活動ですが、同じ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
• NIST: Criticality Analysis Process Model（NISTIR 8179）
• FIRST: CVSS v4.0 Specification Document
• FIRST: CVSS v4.0 User Guide
• FIRST: CVSS v4.0 Consumer Implementation Guide