フロンティアAIの登場により、検出される脆弱性の量は一気に増え上がった。すべてをひとまとめに捉えれば、物量に圧倒されて手が止まる。限られた人材で対応を進めるために、企業はどの観点で対策を切り分ければよいのか。
脆弱性対策を3つに分類
効率的に対応していくためにも、自社で落とし込むべき観点を冷静に整理することが重要だ。ひとまず、大きく以下の3つに分類して考えるとよいだろう。
- 大手ベンダーの製品に関する対策
- 自社開発システム、小規模ベンダーの製品に関する対策
- 未知の脆弱性、ゼロデイ攻撃への対応
1. 大手ベンダーの製品に関する対策
脆弱性の問題は、基本的に各製品ベンダーにとっても死活問題だ。そのため、グローバルの大手ベンダーから提供される製品については、各社が最先端のAIを駆使して網羅的に脆弱性を洗い出した上で、修正パッチを用意してくれるという前提に立ってよい。実際、すでにその流れになってきている。
そのため、ユーザー企業における課題は、市場における既知の脆弱性に関し、いかに迅速に確実に製品ベンダーからのアナウンスを収集できるか。そして、自社において該当するシステムがどこにどれくらいあるのかを整理した上で、いかに早く漏れなく修正パッチを適用するかが鍵となってくる。
なおそのような情報収集や資産の整理が難しければ、脆弱性スキャナーのようなツールを積極的に広く活用していくべきだ。とにかく重要なことは、脆弱性は次から次へと見つかるので、単発のテストや定期的なスキャンでやった気になるのではなく、継続的に「みっちり」と実施し、素早く修正対応することだ。そのためには、継続かつ高速なプロセスの確立と人材リソースの手当てが必要となる。
2. 自社開発システム、小規模ベンダーの製品に関する対策
自社で開発するアプリケーションやサービスは自分たちで脆弱性を検出しなければならない。特にそれを第三者に提供するようなSaaS企業や製品ベンダーにとっては、いかに攻撃者より早く自分たちで未知の脆弱性に気付くかという点が、大きな課題となってくる。
大きな負担となるが、自社で最先端のAIを駆使して対応すると同時に、専門的な第三者の支援も受けた方がよい。幸い、AnthropicのProject Glasswingの動向にかかわらず、Mythosと近い性能のAIはすでに他にも出てきている。また、OpenMythosのようなオープンソースツールも今後次々と出てくるので、手段はそれなりにあるだろう。
これには、有効なツールや支援の選定と導入、きめ細かいDevSecOpsサイクルの確立、そして高度なセキュリティ人材が欠かせない。なお、自社開発でなくとも、小規模なベンダー製品を利用している場合は、大手のように最先端の手法で脆弱性検査がされていない可能性もあるので、自社での対策を検討すべきだ。
あまり意識されていないことだが、「狙われるシステムは、その普及率に比例する」というのが、われわれの経験則だった。これは、本来脆弱性というものが攻撃者から見たその悪用の容易性を基礎とするものだからだ。しかし、脆弱性を見つけるのも悪用するのも、今後は攻撃者側のAIが面倒な部分を引き受けるため、これまで狙われなかった普及率が低いシステムこそ高い注意が必要となる。
なお、併せて意識しておくべき点として、Mythosも含め現状AIツールの多くは、人間が気付かない脆弱性を洗い出してくれると同時に、ノイズとして質の低い脆弱性情報も多量に出力する状況にある。そのため、脆弱性検査にAIツールを活用する現場では、本当に対策が必要な脆弱性なのかどうかを判断するトリアージや対応の優先度付けに莫大な人的負担が生じている。いずれはこの辺りもAIが賢くなれば解決してくれるようになるだろうが、まだ時間がかかりそうだ。セキュリティ人材はますます必要となっている。
3. 未知の脆弱性、ゼロデイ攻撃への対応
脆弱性に気付き、攻撃者よりも早く修正対応ができることが理想だ。しかし、今後は攻撃者側のAIが未知の脆弱性を検出し、パッチが提供される前にエクスプロイト（脆弱性を悪用）され、被害を受けてしまう可能性も高まってくる。あるいは、修正パッチが提供されているものの、可用性やサービスのスケジュール上の都合など、何らかの問題ですぐに適用できないことも現実的に十分あり得る。そのような場合どうすればいいのか。諦める、あるいは考えるのをやめるという選択肢はあり得ない。
通常の脆弱性検査やペネトレーションテストでは、検出された脆弱性がエクスプロイト可能であることが確認されたら、そこでいったん報告が必要になる。許可がない限り実際にそれをエクスプロイトしてシステムに被害をもたらすことはしない。
しかし、フロンティアAI時代のAIツールはそんなことはお構いなしだ。あっという間に脆弱性をエクスプロイトし、次なるシステムの破壊やマルウェアの埋め込みなど、容赦なく連続した攻撃を続け、あらゆる悪行の限りを尽くす能力がある。
だが、よほど整備された検証環境がない限り、自社で動いているシステムに対してその規模の攻撃テストをすることはできない。従って、テストで使うAIと本当の攻撃に使われるAIとでは今後もその使われ方の深さが違ってくる。そのため、防衛側は、未知の脆弱性がエクスプロイトされた後の最悪の事態を想定し、具体的な対応策を持っておくことが重要だ。
これはパッチ適用の話から離れた難しい内容となるものの、予防的コントロールをもって無視できない残存リスクが存在する場合は発見的コントロールで補強するのが定石だ。さまざまな角度での異常の検出やリアルタイム検知など監視の強化も検討すべきだ。
例えば、AIが人間とは比較できない速度と物量で攻撃してくるものでも、サーバへの接続セッション数の制限やネットワーク帯域の制限を受けることには変わりはない。必要があれば枠を絞っておくなどの調整や、内部通信の量的な異常を積極的に検知する監視面の対応も有効だ。本連載第2回でIT運用とセキュリティ運用の統合について触れたように、これまでITインフラ運用の管掌だった部分にセキュリティの観点を積極的に組み込んでいくことが今後はとても重要になってくる。
また、検知後のアクションとして、被害を最小限にする、あるいはレジリエンスの観点で持続や速やかな復旧ができるよう、具体的な仕組みを持っておきたい。例えば、「どのような攻撃や侵入が検知された（あるいは疑われる）場合に、システムを緊急停止するのか」といった規律について、組織として事業部門長を含めた合意形成が事前にできていなければ、有事にすぐ動くことはできない。また、より技術的な対応として、例えば異常検知と連動した動的なマイクロセグメンテーションなどによる隔離なども有効であるし、縮退やシステム間の連携を切った形でのサービス継続なども可能だろう。これらを事前に検討し、テストしておきたい。
脆弱性への対策という文字だけでもこのように考えるべき点が多々あるが、ことさら悲観的になる必要はないと考えている。セキュリティの世界はいつまでたっても「いたちごっこ」ではあるが、だからといって攻撃者が防衛側を圧倒し続けるということでもない。
攻撃者側もAIを使えるようになる一方で、検査する側でもAIを活用するのが当たり前になってくる。そして脆弱性は今後網羅的に洗い出されて、システムはより洗練されていく。当面システムのパッチ対応の負荷は高まるだろうが、いずれそれも落ち着いてくるだろうと予測している。
莫大な脆弱性対応の後に来るもの
むしろ今後セキュリティにおける主戦場、私たちにとってより難しい課題となってくるのは、AIによる高度な「なりすまし」への対策、特にアクセス管理にあると考えている。
せっかくなので、考えるきっかけとして、最後に少しだけアクセス管理についても触れておきたい。アクセス管理は利用者とシステムのはざまにある問題だ。これから増えるであろうAIエージェントが持つ権限にしても人間がその正しさや必要性、リスクを判断し、付与するものだ。だから、基本的にシステムとAIだけで自動化され完結するものではない。
一方で、アクセス権の付与も侵害調査も含め、そもそもセキュリティの運用全般において、明確なルールや事例に基づくものであればAIに任せれば済むのは言うまでもない。では、AIに任せられない状況というのは、どういう類のものだろうか。
それは、倫理的な判断が伴うようなケースだ。従って、今後セキュリティにおける人間の役割は、明確なルールがないような状況で判断を下すことに集中してくる。誰（またはAI）に、何を根拠に、何を許すか、という決定について善意や立場や利害関係、組織・個人の損得、それらの優先度などを含めた判断だ。
とはいえ、それらの判断は、乗っ取りやAIによる巧妙ななりすまし、産業スパイなどの懸念もある中で下さなければならない。その辺りの判断責任までも含めて、あらゆる責任をAIに委ねるようになれば究極的にすべてのセキュリティ運用を自動化できるようになるかもしれない。しかし、その時には何が正しいのか正しくないのか、その後のリスクも含めて、人間はAIが持つ倫理観に従うことになる。
いずれわれわれを悩ますことになるだろう、このようなアクセス管理が持つ難しさを鑑み下げてみると、しょせんと言っては語弊だが、脆弱性というのは単なるシステム的な不備でしかない。AIに見つけさせてふさげばよいだけの単純な話だ。今世間は大騒ぎしているが、AIの進化と共にいずれ人間が真剣に悩むべき問題ではなくなるだろう。
