流行中の「アタックサーフェスマネジメント」は使いものになるか？　根岸氏、辻氏、piyokango氏鼎談に見る3つの論点：ITmedia Security Week 2025 冬

　同ガイダンスでは、ASMの定義を「組織の外部（インターネット）からアクセス可能なIT資産を発見し、それらに存在する弱性（ぜいじゃく）性などのリスクを継続的に検出評価する一連のプロセス」としている。この1文の「外部から」となっている部分に辻氏は着目する。

　一方、米国立標準技術研究所（NIST）が発行している「SP800-53：米国連邦情報システムのセキュリティおよびプライバシー管理の管理策」では、ASMを「システム、システムコンポーネント、または環境の境界上で攻撃者がそれらに対して、侵入したり、影響を与えたり、データを取り出したりしようとすることができるポイントの集合」と定義している。

　辻氏はNISTにおけるASMの定義について「侵入経路がどこかは明確に書いておらず、内部、外部は関係なく、『アタックサーフェス』としている」とし、先のASM導入ガイダンスとの違いを指摘する。経産省による定義はやや狭い領域のみを指しており、「ASMという言葉を聞いたときに『何が対象となるのか』を意識するのが大事なのではないか」と辻氏は述べる。

　これらを踏まえ、辻氏は本ディスカッションにおけるASMの定義をまとめる。アタックサーフェスを「攻撃可能なIT資産とその状態」とし、これらを検出、評価、選別、修正するプロセスおよびサイクルをASMとする。これは脆弱性診断とは異なるものだ。

　根岸氏も「ASMは『資産管理と脆弱性管理を合わせたもの』と理解されることが多い。おおむね間違っていないものの、認識が異なる部分がある」と、ASMについて誤解が生まれやすい状況に触れる。

　その上で、把握すべき対象として「IT資産」「アクセス制御」「脆弱性」があると辻氏はまとめる。少々変わっていると思われるドメイン名の管理や、オープンポートといったもの、脆弱性に関しても悪用の有無や緩和策の有無、優先度なども把握対象だ。

　「資産は変わっていくものなので、このサイクルをぐるぐると回していく。さっきなかったものが今あるかもしれない。ASMはそういうものも把握しながら、きちんと対処しようというものだ」（辻氏）

「セキュリティのアレ」の3人はまず「ASM」を定義してから話を進める

　辻氏は続いて、攻撃の経路をまとめる。下図の赤いデバイスがASMを行う端末、そこにクラウドサービスや業務ネットワーク、サプライヤーとつながる専用線などがある。「外部から」とした場合、赤い端末から伸びる矢印がASMの対象範囲となる。

攻撃経路に関する情報をまとめる

　上図を見ても分かるように、社内に入り込む攻撃経路はインターネットだけでなく、支社やサプライヤーが侵害を受けた場合、専用線という非インターネットの経路も攻撃の侵入口として悪用される可能性がある。「海外支社からの経路などはアクセス管理が弱い場合も多い。ここから来たらどうするのかという意味で、ASMとは内部、外部、閉域網、VPNを含めて『経路がある』と想定する必要がある」（辻氏）

　攻撃者は弱い部分を狙ってくる。大企業だとセキュリティ対策が施され、簡単には侵入できない。攻撃者は脆弱な海外支社などから入り込もうとする。アタックサーフェスを攻撃経路と考えれば、外部からだけでなく、全てを考えねばならない。

　ここで辻氏は事例を紹介する。2024年6月4日夜に高野総合会計事務所、高野総合コンサルティングおよび監査法人TSKのデータ管理サーバでアラートが発生した。調査したところ、6月6日にランサムウェア（身代金要求型マルウェア）被害が発生した。事案発生の1週間ほど前、5月26日に委託業者がインターネットに外接するデバイスを更新した際、設定を誤ったことでアクセス制御不備が発生していたことが明らかになっている。

高野総合会計事務所における事例

• ランサムウェア被害発生についてのお知らせ（第2報）｜高野総合会計事務所
• ランサムウェア被害発生に関する調査結果のご報告（第3報）｜高野総合会計事務所

　「こういった設定不備に起因する事案はここ2、3年で増えている。外部からの調査はもちろん必要だが、このように侵入されてしまった際のことを考慮して内部からも調査することが必要なのでは。外部からの調査だけでいいのかどうかという問題はここからも伺い知れる」というのが辻氏の指摘だ。

　加えて辻氏は、5月26日に誤った設定を施し、そのわずか8日後には侵害を受けているというスピード感に注目する。「こういった状況を調べている攻撃者の総数が増えている。「イニシャルアクセスブローカー」という、侵入できる入り口ばかりを探すビジネスがある。10日弱あればその隙に付け込まれ、ランサムウェア事案にまでつながることを教えてくれる事例だ」と述べる。設定不備は自分たちでは絶対に気が付けないだけに、この考え方は重要だ。

　「委託先のチェック機構として、保険としてASMを活用していれば防げたのかもしれない」と辻氏が指摘すると、根岸氏も「本来アクセスされてはいけないものがアクセスされていないかどうかという“異常系の検証手続き”がなければ、保守事業者も気が付けない。委託元もその観点でのチェックが必要ではないか」と警鐘を鳴らす。

ASMは万能なのか？　“盲点”はないのか？

　根岸氏はさらに深掘りすべく「ASMに盲点はないのか」という視点で考えていく。一般的なASMの考え方では漏れてしまう部分をまとめ、表として提示する。

ASMの「盲点」

　特に気になる部分として、根岸氏は「リモート接続」を挙げる。2024年にはSIMを搭載したPC端末に含まれるRDP（Remote Desktop Protocol）接続が攻撃を受け、社内に侵入されたという事案が複数発表されている。

　「SIM内蔵のデバイスは、組織の資産として外部から認識するのが難しい。これらのRDPをASMの観点で見つけられるかというと、ちょっと難しいかもしれない」と根岸氏。「自分たちが使っている資産の管理やアクセスコントロール機構から、端末の安全性を監視しなければ見つからない。その視点が漏れていないか？」と疑問を呈す。

　リモートから脆弱性を突く攻撃が注目されているが、ローカルからの攻撃を見逃していないだろうか。権限を持つユーザーが乗っ取られ、ローカルの脆弱性を悪用できる場合、後の攻撃に大きな影響が出てしまう。しかし、その検出や管理は難しい。

　根岸氏は「外部からの攻撃者目線のみでは守ることは難しくなっている。資産管理や脆弱性管理の枠組みで資産の状況を調べておく必要がある」とし、先のASMを保険として活用するという観点についても「例えばテスト環境がうっかり外部に公開されるといったミスを、保険として見つけることはASMでもできる。しかし、外部公開の手続き部分での対策が不十分なままの状態を、ASMで解決させるのは違うのではないか」と指摘する。

　「警察庁の発表でも、ランサムウェアの感染経路はVPNが多いと報告されている。しかし脆弱性を突く手法だけでなく、認証情報が盗まれていたり、パスワードが弱かったりなど、正規のログインと変わらない形で侵入されてもいる。それはASMの観点で見えるわけではない。『ASMで対策できる侵入経路』と思っていたら、『実は全然違う原因による侵入経路だった』ということもあり得るのではないだろうか」（根岸氏）

　先の高野総合会計事務所の事例を見ても分かるように、脆弱性や設定ミスが発見されてから攻撃までの期間がだんだん短くなっていることについても、根岸氏は懸念を表明する。ゼロデイ攻撃はASMでは対処できないことに加え、脆弱性が公表されてパッチが登場し、適用されるまでの間に攻撃が来る「Nデイ攻撃」もわずか数日のことだ。Nデイ攻撃はASMで発見できる可能性はあるが、ASMのチェックサイクルが、攻撃が来るよりも短くなくてはならない。毎月チェックするだけではもはや足りないのだ。

　「ASMがダメというわけではない。今自分たちが対応しなければならない攻撃経路や脆弱性の対応として、優先順位を上げて取り組むべきなのは本当にASM的なものなのかどうか。その前に他の対策をした方がいい場合もある。盲点が存在するのではないかという観点を持ち、先述の表のようなことを考えてみてはどうだろうか」（根岸氏）

ASMが必要なところはどこか“確認”する

　ここまで聞き手に回っていたpiyokango氏も、「これまでずっと悶々（もんもん）としていたことがある」と切り出す。「ASMという言葉は攻撃対象となる部分がどこかをしっかり管理しようという趣旨だと思うが、公表されたインシデント情報を見ていて、その実態はどうなのかという視点から言葉の意味を捉えたい」と述べ、持論を展開する。

　piyokango氏はまず、攻撃対象、攻撃経路、手口をまとめたものを提示する。2024年に公表された不正アクセスやサイバー攻撃事例において、同氏が独自に集計したものだ。

• 認証認可の不正利用：107例
• 脆弱性の悪用：44例
• ソーシャルエンジニアリング：40例
• DDoS（分散型サービス拒否）攻撃：20例
• 設定不備の悪用：11例
• 調査中、記載なしなど：140例

piyokango氏による「どのような攻撃を受けているか」の集計

　最も多いのは「調査中」だが、piyokango氏はこの集計結果から、「攻撃を受けた組織では、攻撃対象についてしっかりと明らかになっているのか」と疑問を呈する。つまり、認証認可の不正利用で攻撃を受けているが、その認証情報がいつ、どうやって盗まれたのかなど、原因のさらなる「原因」があるはずだ。

　これには辻氏、根岸氏も同意する。「単に公表したくないからという理由ならばいいが、そうとも思えない。公表していないということは、把握ができていないからだろう」と根岸氏。辻氏は「報告書に『パスワードを強固なものにした』など、うっすらと原因らしきものが伺い知れる公表も存在する」と指摘する。「やはり、公表されている情報だけ見ると攻撃経路を特定、断定できているかは疑問」（piyokango氏）

　これを踏まえ、piyokango氏はASMについて、「確認」という言葉を使う。今回の議論におけるASMは、「どういう観点で期待するか、確認するか」というポイントがあるのではないか。piyokango氏は次のようにまとめる。

そのASMを「確認」せよ

　経産省のガイドラインには、ASMのプロセスが掲載されている。それを参考にpiyokango氏は確認の要点をまとめている。

　「発見」のプロセスでは、最新の脅威動向に準じた攻撃手法前提で調査されているかどうか。「収集」では、攻撃手法に応じたデータの収集が適切に行われているかどうか。「評価」では、発見・収集を基に十分な評価ができているかどうか。「対応」では、攻撃時の検出手段や検出後の対応手順を検証しているかどうか。

　「これらの観点でASMを活用してほしい。脆弱性管理にしても、そもそもその脆弱性は今攻撃に使われているのかどうか。活発に使われているものならASMでチェックする必要があるが、使われていない脆弱性を必死に管理していることもある。ASMでしっかりチェックしていたとしても、攻撃を受けたときに『何が原因か分からない』のでは、やっている意味に疑問符が付く」（piyokango氏）

　これを踏まえ、辻氏はこれまでセキュリティ診断を行ってきた経験から「サービスを提供する側、製品を導入する側において、ASMでいう“発見”のプロセスだけ話が進んで、見つけた後の対処のルールがあるかどうかはあまり明確になっていない」と指摘する。

　ASMは、最終的に攻撃に“対処”するまでのプロセスの一つでしかなく、“発見”したら終わりではない。piyokango氏は「セキュリティ対策製品を入れていたとしても、攻撃によってどういうログが出てくるのかが分かっていなければ、攻撃を特定できない」と付け加える。

　根岸氏は「自分たちにとって必要なASMを自分たちなりに定義する。そして、これまで述べた盲点や、piyokango氏の話したような視点でASMを捉えねばならないことが分かる。自分たちでそれをやってみることで、ベンダーや業界によるASMの定義に惑わされず、まずは自分たちが必要な部分を把握し、自分たちでカバーできない部分を製品でカバーできるのなら使うという判断をする。そういう整理や確認が必要だ」とまとめた。

　言葉としてのASMが今、流行している。使い方次第で便利な道具にもなるが、その導入は冷静に考えるべきだ。「自分たちに見えないものは守れない」のは間違いない。だが、資産が増え過ぎて、探さなければ守るべきものが見えない中、見落としているものすらも攻撃者はアクティブに探してくる。それが現状だ。

　ASM自体は必要なプロセスの一つだが、万能ではない。辻氏は「今回の議論が『自分たちに合った使い方は何か』という当たり前のことを、もう一度考える機会になればうれしい」とディスカッションを締めくくった。