ASMを掘り下げる
アタックサーフェスとは何なのか？
インターネットなど、信頼性の低い領域に接している資産
組織のポリシーによっては、インターネットだけではなく、委託先との接続点などもアタックサーフェスと定義し得る
ASMで把握したい情報は何か？ -> アタックサーフェスのデータモデル
エンドポイント（IPアドレス、FQDN）
プラットフォーム（AWSとか）
情報ソース
システム※システムデータベース的なものとリレーション
管理者
脆弱性
攻撃者から見えているか？いないか？
種別
ソフトウェアライブラリの既知の脆弱性（CVE的なもの）
自前のロジックに起因する脆弱性（CWE的なもの）
クラウド設定不備
修正対応者
ASMの目的の分類
1. ASM-k(nown). 既知のアタックサーフェスの管理
管理
資産管理の側面：アタックサーフェスそのものの列挙
脆弱性管理の側面：アタックサーフェスにある脆弱性を可視化、リスク分析、優先順位づけ、対応（リスク低減 or 回避）
脆弱性の管理は、脆弱性の出自ごとに違ったツールでやっていることがある（ソフトウェアライブラリの脆弱性、ロジックの脆弱性、クラウドの設定不備）、それらをアタックサーフェスという切り口で並べて分析する
脆弱性間のチェーン
対応優先度の決定
2. ASM-u(nknown). 未知のアタックサーフェスの発見（発見 = 既知のアタックサーフェスにする）
ASM-u.1. 手近な方法で発見できる
クラウドプラットフォームのAPIとかから引っ張ってこれる
ASM-u.2. 攻撃者と同じ方法でしか発見できない
なぜ未知のアタックサーフェスが生まれるのか？
見えないはずのものがミスオペなどで意図せず見えてしまっている
例：メンテのタイミングでアクセス制限が外れてしまった
IT資産管理のサイクルから漏れてしまっている
この側面でASMが大活躍してしまうなら、IT資産管理の改善が必要
ASMの取り組み
未知のアタックサーフェスを把握して、既存の取り組みの対象にする
既存の取り組みの対象になっている脆弱性のうち、アタックサーフェスに存在するものを一元化する
他分野との連携・重複は避けたい（けっこう被っていることが多い）
この中での結論
既存の活動も、その領域内で「未知のxxx」を把握する（「既知のxxx」にする）活動を含む
既存の活動の中でexposureの要素を加味することで、ASMの目的の分類のうち1を満たせると言えそう
shinobe179.icon当たり前のことかもしれないけど、個人的にはけっこうよい気づき
管理単位がバラけてしまっているので、これを集約することには意味があるかも
CSPM
1の瑕疵のうち、クラウドの設定に起因するもの発見し、なくす活動
純粋な意味合いだけで言えば、「アタックサーフェス」かどうかの区別は含まない
例：パブリックサブネットだろうが、プライベートサブネットだろうが、セキュリティグループが0/0で開いてたら同じseverityで扱う、的な
脆弱性管理
1の瑕疵のうち、ソフトウェアライブラリの既知の脆弱性に起因するもの発見し、なくす活動
こちらも、純粋にはアタックサーフェスかどうかの区別は含まない
SSVCの場合exposure（システムのインターネットへの露出度合い）が含まれるため、「既知の脆弱性に限ったASM」をしている、と言えそう 留意：exposureはあくまでシステムやサーバー単位での露出度合いなので、脆弱性そのもののexposureはまた別
脆弱性のexposureは、以下の2軸だと思う
外部から存在が分かるかどうか
外部から悪用可能かどうか
結局何をするべきなのか？
ASM-k
資産管理 with exposure
資産を、資産の公開状態を含めて列挙する
公開していないはずの資産が公開されていることを検知する
脆弱性管理 with exposure（= CTEM かもしれない） 脆弱性を列挙する
資産の公開状態を加味してリスク判断する
管理対象とすべき資産が対象になっていないことを検知する
アタックサーフェス軸での情報整理
これらの営みから漏れてしまったものをASM-uで洗い出す