2.2 ASMのプロセス #

本ドキュメントで参照する定義「組織の外部（インターネット）からアクセス可能な IT 資産を発⾒し、それらに存在する脆弱性などのリスクを継続的に検出・評価する⼀連のプロセス」は抽象度が高い状態です。改めてプロセスを紐解くと以下のように解釈可能です。

アタックサーフェスの検出（発見）
組織の外部からアクセス可能なIT資産を検出（発見）します。 “外部からアクセス可能な資産を検出する"という表現が重要なポイントで、必ずしも外部（インターネット上）から検出するのではなく外部からアクセス可能な資産を検出さえすれば方法は問われていません。これが検出方法の異なる製品やサービスがおしなべてASMと呼称される理由であると考えています。（製品やサービスの種別については後述します。）
付加情報の収集とリスク評価
発見したIT資産の情報と脆弱性を継続的に検出・評価します。発見したIT資産の構成情報（ポート、利用製品など）の取得や何らかの評価を行い、設定ミスや影響を受ける脆弱性があるかの確認をすることでリスクの度合いを評価します。脆弱性の有無を評価するための脆弱性スキャンは必須ではなく、エージェントなどにより、設定情報や利用製品情報を取得して脆弱性情報のカタログとの照らし合わせにより、対象IT資産のリスク評価を行うものもあります。継続的な評価をコンティニュアスモニタリング（常時監視）と関連付けている製品やサービスもあります。
リスクへの対応（IT資産および対策状況の管理）
アタックサーフェスの発見、リスク評価の後、IT資産管理とリスクへの対応に取り組みます。 IT資産管理は、元から自分たちで取り組んでいたIT資産管理と組み合わせて一元的に管理できるように整理する等の取り組みが考えられます。ここで整理したIT資産の一覧が、次サイクルのアタックサーフェス検出の調査起点（探索のための種）となります。発見される未知のアタックサーフェスの量がある程度収束するまでは、高い頻度でサイクルを回すことが望ましいです。リスクへの対応は、既知のIT資産であれば担当部門に対応依頼をし、継続的なリスク評価の中で対応状況を確認すればよいですが、未知のIT資産の場合は担当部門を探すところから取り組む必要があるため、組織内で横断的な協力やトップダウンでの対策指示が必要となることもあります。

flowchart TD
    A[従来の資産管理（資産一覧）] 
    B[1.アタックサーフェスの検出（発見）] 
    C[2.情報取得とリスクの評価]
    D[3.リスクへの対応]
    A --> |インプット| B --> C --> D --> B
    D --> |IT資産情報の棚卸| A

従来の管理方法との組み合わせによるASMならではの価値 #

従来の管理方法（ルールベースでの管理）でIT資産を網羅的に把握し、把握した全てのIT資産、少なくとも全てのアタックサーフェスに対して脆弱性診断によるリスク評価を行うことができれば、理想的な管理状態に近いと考えられます。
しかし、従来の管理方法での網羅的な把握も、全てのアタックサーフェスへの脆弱性診断も、コスト的な面から見て現実的ではありません。

ASMでのIT資産の検出＋リスク評価のプロセスが有効に働けば、従来の管理方法では拾いきれなかったIT資産が発見され、高リスクなIT資産を優先して対策可能になるため、ASMだけでよいと考える方もいると思います。しかし、ASMでは資産検出は検索やクローリングなどにより稼働しているシステムを探すアプローチが多いことから、全てのIT資産を把握しきることは難しく、内部情報との連携も難しいと考えられます。また、リスク評価においても脆弱性診断と同程度ではなく、簡易的なものであることが多いです。

そのため、従来の管理方法（内部で管理している情報）とASM（外部から取得した情報）を組み合わせて、従来の管理方法では漏れてしまっていたIT資産を把握するようにIT資産管理プロセスを組み立てることをお勧めします。また、脆弱性診断によるリスク評価についても、資産全体に簡易的な評価（ASMでの評価）を実施しつつ、より重要な資産や深い確認が必要であると確認された資産には脆弱性診断も実施するといったように、従来の管理方法とASMを組み合わせることで、よりASMの価値を実感できるようになります。

補足
ASMツールと脆弱性診断の特徴を解説した関連コラム「ASMツールは脆弱性診断の代わりになる？」もあわせてご参照ください。
「従来の管理方法でアタックサーフェスを十分に管理できている組織であればASMに取り組む必要性が低い。」というよりも、既に十分にASMに取り組めていると考えられます。自組織にASMが必要であるのかについては3章に記載します。