脆弱性診断やペネトレーションテストは昔からよく聞きましたが、最近はBASやASMなど聞きなれないキーワードも出てきています。
いろいろなキーワードがあってどれがどんな特徴かわからなくなるので、整理してみました。

なお、最近はCTEM（Continuous Threat Exposure Management＝継続的に外部にさらしてしまってている脅威を管理する）というキーワードもよく聞きます。まとめにあたって参考までに評価として、属人性をなくし継続的にできるか、テストを網羅的にできるか、実際攻撃を想定した深度でテストできるか、なども記載してみました。
表記はできるだけ難しい言葉は使わないようにしたつもりです。

まず「脆弱性管理」

テストというよりは、脆弱性の有無自体を管理しようというものです。脆弱性の管理DBと実システム環境を照らし合わせて、使用しているOS・ミドルウェアなどの脆弱性の一覧を出すことが多いかと思います。最近では自動化のツールも有償・無料含めて多くあります。

一見これでいいように見えますが、日々大量の脆弱性が発見される中で検知された脆弱性をすべて対応するのは現実的ではないです。最近のプロダクトは多くのオープンソースを使っているために管理できていないところに脆弱なプロダクトが混じることもあります。また、自作アプリケーションの脆弱性をここで管理することはできないです。
となると、脆弱性を管理するという方向から脆弱性をテストするアプローチにかわります。

なお、個人的には脆弱性管理を否定はしません。むしろ重大な脆弱性が発見された際に、その情報だけを頼りに迅速に対応を計画し実行するには非常に重要です。
資産管理の一環としてとらえて、やれる範囲で実施ほうが良いかと思います。

最低ラインの「脆弱性診断」

アプリレイヤを中心にした「Webアプリケーション診断」ともっと下のレイヤを中心にした「プラットフォーム診断」に分けられます。

Webアプリケーション診断でよくおこなわれるのは、OWASP TOP 10 にあげられる項目などを中心にWebアプリの脆弱性有無をテストするものです。
クロスサイトスクリプティング（XSS）やSQLインジェクションなど、よく耳にするものが多いかと思います。
プラットフォーム診断は、OSやミドルウェアの設定不備などの脆弱性を検知します。初歩的な設定ミスや既知の脆弱性確認には有効です。 どちらも最近はかなりの範囲を自動でテストできますが、人手でより深く診断することも重要視されます。

脆弱性診断の欠点は、脆弱性として検知されたものが必ず脅威になるとは限らず、検知された脅威レベルが実際の深刻度と合致するのとは限らないことです。特に自動で行う場合は、脆弱性として検知されたものの無害なものが多いのは事実です。
また脆弱性として検知されたものを無害と判断する場合、その判断が妥当かの担保はとれません。無害と判断したものがその後の変更で危険なものに変化することもあります。
こうしたことを人手でカバーするとなると、コスト増に直結します。

オープンソースで手軽に実施する、または安価な外部サービスを利用して実施するには良いですが、脆弱性診断だけでは不十分であることは認知したほうがいいかと思います。

継続実施：〇 自動製品であれば継続的に可能。手動テストの組み入れ方が課題
非属人化：〇 自動製品であれば問題なし
網羅性：〇 むしろ誤検知が課題
攻撃者視点：× 脆弱性があることに留まり、本当に危険かは人が判断

攻撃をシミュレーションする 「Breach and Attack Simulation（BAS）」

実際のサイバー攻撃や侵害シナリオを攻撃者の視点でシミュレーションして、脆弱性を特定したり、既存のセキュリティ対策の効果を評価したり、自組織のインシデント対応能力を検証します。シミュレーションのシナリオ次第では、他のカテゴリの製品ではできないような複雑なテストもできます。
脆弱性診断が単なる診断に留まるのに対し、実際に攻撃のシナリオに基づいて脆弱性への耐性をテストできること、およびインシデント発生時対応の訓練になるのが特徴かと思います。

万能に見える反面、シミュレーションを作るにはどうしてもパラメータが多くてそれなりにナレッジを必要とするため、その人材確保が課題になるかと思います。
またシナリオの範囲でのテストになるため、網羅性が低くなる可能性がありますし、網羅性を高めようとするとコストに結びつきます。
また、エージェントが必須になることが多く、それを嫌う人も当然います。

継続的にBASを実施することで、セキュリティ状況の変化を把握し、対策の改善を進めることができます。

継続実施：〇 シナリオの範囲で継続的に実施可能
非属人化：× シナリオ作成が課題
網羅性：× シナリオの範囲のみ
攻撃者視点：〇 シナリオ次第では複雑な攻撃もシミュレーション可能

対象を探すところから始める「Attack Surface Management（ASM/EASM）」

攻撃者の視点から攻撃可能な対象を探し出し、脆弱性などのリスクを継続的に検出・評価するものです（テストツールだけでなくそのプロセスも含む）。脆弱性診断が診断対象を特定して実施するのに対し、ASMでは、攻撃可能な対象を探すところから始めるのが大きな違いです。
ASMのうち、特に外部に公開されているものを対象するものはEASM（External Attack Surface Management）と紹介されることもあります。
DNSのゴミ設定とか野良・放置のブツを炙り出し評価してくれることもあります。

ただし、脆弱性スキャンに留まるため、検知された脆弱性の深刻度の判断は浅いものになります。 したがって、攻撃者視点での完全な攻撃シミュレーションではなく、脆弱性スキャンのレベルに留まることがあります。

継続的な実施や自動化・攻撃者の視点からの攻撃可能な対象の検出とリスク評価の面では非常に役立ちます。

継続実施：〇 継続的に実施することを前提としたもの
属人性排除：〇 基本は自動
網羅性：〇 攻撃可能な対象のスキャンから開始
攻撃者視点：△ 脆弱性スキャンに留まる

やはり強力な「ペネトレーションテスト」

実際に攻撃者の視線で攻撃を仕掛け、脆弱性をついて評価するものです。外部事業者に依頼して実施するほか、最近では大手企業でレッドチームと呼ばれる組織を組成し、自社に対してテストをおこうところも出てきました。
脆弱性が本当に深刻かどうかを見極めるには非常に有用です。

ただし、ペネトレーションテストを実施するには高度な知識が必要で属人性は極めて高くなります。テスト実施期間だけでなく実施までの調整期間が長くなったりコストも高くなる傾向にあります。
また、同じシステムに対して繰り返しペネトレーションテストするとテストする側が飽きてしまい(^^)、継続的に実施するには人材確保に落とし穴があります。

ペネトレーションテストは他のカテゴリに比べても攻撃者の視点からの深い評価を提供する点で非常に価値があります。

継続実施：× 人材確保が困難
属人性排除：× 高度な人材が必要
網羅性：△ 実施する人の能力とテスト期間次第
深度：〇 攻撃者の視線

次世代の「Automated Security Validation（自動ペネトレーションテスト）」

最近では自動ペネトレーションテストをおこなうプロダクトも出てきました。現在はPenteraという製品だけですが、ASVという新しカテゴリになりそうです。
最小限のパラメータ指定で攻撃者視点の「攻撃」を攻撃対象の検出から自動で実行することができます。攻撃は稼働影響が出ないように無害化を十分に考慮し検証されています。テスト実施後には実際の攻撃結果に基づく深刻度評価した結果レポート出力ができ、問題点への対処を記したWikiもついている優れものです。

攻撃・評価というサイクルを自動でスケジューラで実行でき、かつ対処方法のアドバイスまで自動で入手できるというのは、他のカテゴリと比較してかなり魅力的です。発展途上の分野・プロダクトではありますが目が離せません。

ただし、あくまで自動でしかなく、手動ペネトレーションテストをはじめとする施策を否定するものはないです。やはり人でしかできない脆弱性のテストがあることは忘れてはいけません。

攻撃者視点で網羅的に繰り返しペネトレーションテスト手法で脆弱性の検証ができるという点で非常に価値があります。

継続実施：〇 自動で実施
属人性排除：〇 最小限のパラメータで実行
網羅性：〇 網羅的なテスト
深度：〇 攻撃者の視線

最後に

おおまかなカテゴリ分けをしてみましたが、実際は複数のカテゴリにまたがる機能を持つものもあるため、実際の製品仕様をきちんとおさえることが重要です。

また、全体として自動化ツールと人的な手動実施にバランスが最終的にはとても重要です。自動化で迅速に網羅的に行いつつ、人による深い分析（特に脆弱性の深刻度）と正確な評価・対応の優先順位判断をおこなう必要があります。

販売代理店の言いなりにならずに、自分たちで何をやろうとしているかを理解する手助けに本資料がなれば幸いです。