侵入前提の前提の話～アタックサーフェスマネジメントが今なぜ求められるのか～（後編）

SBテクノロジー プリンシパルセキュリティリサーチャーの辻です。
このブログの前編では、ランサム攻撃の仕組みや現状、その措置として有効なアタックサーフェスマネジメント（以下、ASM）、つまり「資産管理」と「脆弱性管理」がなぜ今改めて ASM として定義付けられたのか、ということをご紹介しました。
それでは、後編では ASM の押さえるべき大事なポイントやインシデントの事例などに触れていきましょう。

「資産管理」と「脆弱性管理」を改めて考える

ASM で管理すべき対象は、「資産」「アクセス制御」「脆弱性」の3つがあると考えています。
「資産管理」の資産とは、BOD の「23-01」では馴染みのない「IP 資産」と書かれていますが、IP アドレスを持つ資産ということになります。まずは、その「IP 資産」と言われるものの管理、例えば IP アドレスはいくつあり、それに紐付くドメインはどういうもので、それらではどのような OS、そしてアプリケーションが動作しているのか、といったことを把握し、リスト化します。脆弱性のスキャンをするために、「何があるのかを知る」という自分たちがこれから歩く道のりを知るための地図を作るということです。

IT 資産の把握ができたら、その次にやるべきことは「アクセス制御」。外部との通信口となるポートの開閉を調べ、開いていれば、本当に運用上開けておくことが必要なのか、必要であったとしてもアクセス元を最小限にする余地はないかといった検討。さらに認証も、その強度を上げる余地はないのか、例えば二要素認証にしているのかなどを考慮する必要があります。

そして最後は、二つ目の段階で熟慮の結果、それでもポートを不特定多数に開放する必要がある場合に、その IT 資産に「脆弱性」があるかどうかの調査を行うことです。

その一連の流れを、ショットではなく日々のサイクルとして回していくことがとても重要なポイントです。では、どこを重点的に ASM するか。あえて優先順位を付けるのであれば、やはりインターネットに面している部分です。ただしこれは、内部の ASM を後回しや疎かにして良いということではもちろんなく、順を追って対応が必要なのです。

脆弱性対応で重要なのは優先度

ここまでは、ASM やそれを取り巻く環境などについてお話ししました。
ASM でまずやるべきことは、ポートスキャンと脆弱性スキャンと前述しましたが、脆弱性が見つかった場合に、組織のネックになるのが対応をするための人的リソースや金銭的リソースです。IT 資産が増え、あてるパッチが多くなるほど人的リソースが割けなくなるなど、パッチマネジメントに悩む組織も多いのが現状です。

米国の非営利団体 MITRE 社が管理している脆弱性情報データベース「Common Vulnerabilities and Exposures（CVE）」によると、脆弱性は年々増加していて、2023年に発行された件数は3万件を超えました。
その脆弱性を全て対応するのか、古いものから対応していくのかとなると、それでは対応が追いつきません。人的リソースも金銭的リソースも潤沢にあり、パッチを即時に全てあてることができる組織であればいいですが、なかなかそういう組織は多くはないのではないでしょうか。さらに、パッチをあてる対象の再起動やその後の正常性チェックもあるので、運用の現場からはできる限り適用は最小限にしたいという声をよく聞きます。

そこで、多くの脆弱性の中で、本当に対応をすべき、人的リソースと金銭的リソースをかけるべき脆弱性を見極め、対応の優先順位を付けることが重要になってきます。

では、どのように対応優先順位を付けるのか。一つの判断材料として有効なのが、脆弱性が実際に悪用されたかが確認できる米国の CISA から出されている KEV（Known Exploited Vulnerabilities catalog）です。この情報は、米国政府が悪用を確認できているものとなりますので、日本独自で使われているアプリケーションなどの情報はありませんが、脆弱性の深刻度である CVSS（Common Vulnerability Scoring System）に加えて、KEV に掲載された情報と照らし合わせることで、悪用されている脆弱性の優先度を上げるという判断ができます。

アタックサーフェスマネジメントができていないことで起こるインシデントは多くある

日本で ASM が課題として捉えられていないということを前述しました。
例えば、アクセス制御不備が原因と考えられるランサムウェア感染の事例が日本でもいくつか公開されています。ある国立大学法人では、統合認証システムのサーバーがランサムウェアに感染、一部のデータが暗号化されました。原因はファイアウォールの設定変更作業時に外部からのアクセスがデフォルト値で許可となっていたにもかかわらず、作業を請け負った組織の作業者がデフォルト値を拒否と誤認していたことからでした。その結果、作業完了後から発覚までの2か月の間、本来アクセスできないはずのポートへ外部からアクセス可能な状態となっており、被害に遭ったというものです。

こういったケースはまれかと思うかもしれませんが、実態として意識せず外部に公開してしまっている環境は想像以上に多いのです。
本来であれば ASM が必要ですが、前述したように人的リソースや金銭的リソースでハードルが高く感じるなら、必要最低限の対応としてポートの開閉を確認するポートスキャンくらいは実施してほしいです。自組織が保有する IP アドレス、インターネットに面しているであろうグローバル IP アドレス、もしくはクラウドで使っている IP アドレスを把握し、ポートスキャンの実施をお薦めします。

アタックサーフェスマネジメントの第一歩は自組織の現状を知ること

今回のブログでは、ASM の重要性をご紹介しました。繰り返しになりますが、ASM の第一歩は、まず自組織の現状を知ることです。そして、もし運用上不要であるポートが開いている場合は、即座に閉じることです。

ここ数年、Endpoint Detection and Response（EDR）の認知度向上や浸透もあり「侵入されることが前提で」という言葉をよく聞くようになりました。その考えも必要ですが、一方で、侵入されてしまえば、対応のために莫大な人的リソースも金銭的リソースもかかってしまう。私たちが風邪をひくことを前提に薬を買っておくという前に、ワクチンを打つ、マスクと手洗いをして予防する。このように、セキュリティも「侵入前提」の前提として ASM に取り組んでいただきたいと思います。

さいごに ～編集後記～

本記事の編集を担当しました SBT ブログチームの神田です。「侵入前提の前提の話～アタックサーフェスマネジメントが今なぜ求められるのか～」前編・後編いかがだったでしょうか。読んでみて、分かってはいるものの、それでも ASM を日々実施するための労力をかけられない、という組織は多いと思います。そんなときお薦めなのが、当社のサービス『MSS for 脆弱性管理（VRM）』です。『MSS for 脆弱性管理（VRM）』は、資産の把握から脆弱性情報の収集・評価、検出された脆弱性に対する対応判断・計画策定・対応実施までの脆弱性管理ライフサイクルに沿ったプロセスを一元的に管理するサブスクリプションサービスです。初期費用不要で、最短15日で脆弱性管理に必要なプラットフォームを定額サービスとしてご利用可能なため、外注への金銭的リソースを課題に感じていた方にも導入いただきやすくなっています。また、クラウドサービスの監視・通知を行うサービス『クラウドパトロール』なら、ユーザー管理のミスや不要なポートの開放、ストレージの設定ミスなど、即時に対応すべきリスクを発見してユーザーに通知し、不正アクセスや情報漏えいの危険性を低減させます。
これを機に、自組織の ASM に改めて取り組むことを検討するきっかけになれば幸いです。