前へ 1 2 次へ

第14回 “あのセキュリティ事故”はどうやったら防げた? 検証委員会

ダークウェブで攻撃者がやり取りする情報も把握、ASMから進化した“CTEM”=「FortiRecon」

化学メーカーの研究データが漏洩! 脆弱性診断が見落としたVPN装置… どうやったら防げた?

文●大塚昭彦/TECH.ASCII.jp

提供: フォーティネット

  • この記事をはてなブックマークに追加
  • 本文印刷

■今回のセキュリティ事故:

 中堅化学メーカーQ社は、半導体製造で使われる高機能な樹脂素材を専門に手がける企業だ。創業から50年以上が経つが、その研究開発力は現在も世界トップクラスと言われる。グローバル市場におけるシェアは高く、国内と海外に数十の拠点、グループ子会社を持つ。

 世界中のメーカーがしのぎを削る分野だけに、製造技術に関する情報や最新の研究データは“トップシークレット”である。そのため、Q社の情報システム部門では情報保護とセキュリティ対策に神経をとがらせていた。セキュリティ対策の一環として、3カ月に一度、セキュリティベンダーに依頼して脆弱性診断を実施している。

 この脆弱性診断は、あらかじめQ社側でリストアップしたIT資産(サーバーなど)に対して、脆弱性スキャンや疑似攻撃を実施するものだ。診断の実施後、ベンダーのセキュリティ専門家から結果報告と改善提案が行われ、脆弱性が発見された場合は速やかに、パッチ適用(セキュリティアップデート)や設定修正などの改修作業を行う。情報システム部の誰もが「当社は優等生的なセキュリティ対策ができている」と自負していた。

 しかし、そんな中で事故が起きた。海外の研究開発拠点でランサムウェア感染が発生し、ファイルサーバーに保存されていた研究データの大部分が暗号化されてしまったのだ。さらに、外部との通信ログを詳しく調べたところ、研究データの一部が盗み出された可能性があることも分かった。それが数年前の古い研究データだったことは不幸中の幸いだが、重大インシデントであることには変わりない。

 攻撃者の侵入経路を調査したところ、拠点のネットワークに接続された古いVPN装置が“攻撃の侵入口”になっていたことが分かった。パッチが適用されないまま放置されたこのVPN装置には、既知の脆弱性があり、攻撃者はそれを突いて侵入したのだった。

 問題は、このVPN装置の存在を誰も認識していなかったことだ。装置の年式から、拠点の開設準備時に仮設のリモートアクセス手段として利用されたものと推測されたが、当時の記録には残っておらず、拠点の情報システム担当者も引き継ぎを受けていなかった。そして、日本の本社側のIT資産リストにも載っていなかったため、定期的な脆弱性診断では発見しようがなかったのである。

 こうした報告に、Q社の情報システム部は頭を抱えてしまった。数十ある拠点や子会社には、誰も存在を把握していないIT資産がほかにも存在するのではないか。各拠点や子会社には緊急調査を依頼する予定だが、小さな拠点にはIT専任担当者がおらず、調査が不十分なまま終わってしまう可能性もある。……このセキュリティ事故は、どうやったら防げたのだろうか?

※このストーリーはフィクションです。実在する組織や人物とは関係ありません。


「把握できていないIT資産は守れない」という現実

 セキュリティ対策の一環として、Webサイトや業務システムの「脆弱性診断サービス」を利用している企業/組織は多い。一般的には、顧客企業側がリストアップしたIT資産に対して、企業ネットワークの内外から脆弱性スキャンや疑似攻撃(ペネトレーションテスト)を実行し、潜在する脆弱性や設定の問題をあぶり出す。そのレポートに基づき、顧客企業側はセキュリティアップデートなどの対応を行う。最低でも年1回以上、数カ月おきに実施するケースが多いようだ。

 ただし今回のQ社のように、誰も存在を把握していない“未知のIT資産”が社内に存在すると、それは脆弱性診断の対象外になってしまう。まずは、これが大きな問題だ。

 クラウド利用の普及やITインフラの複雑化が急速に進む中で、こうした“未知のIT資産”は発生しやすくなっている。たとえば、一時的に使われたVPN装置やIoTデバイス、システムの開発環境/テスト環境などが、アップデートされないまま放置され、サイバー攻撃のターゲットになるケースはよくある。さらに、従業員が無許可で利用する“シャドーIT”も、攻撃リスクのある未知のIT資産に含めてよいだろう。

 もうひとつ、脆弱性診断が「定期的にしか」実施できない点も問題である。診断を実施した時点では問題がなくても、次の診断を行うまでの間に新たな脆弱性が見つかり、攻撃に利用され始めるなど、状況は常に変化しうるからだ。

 特に現在では、「クラウドサービスの設定ミス」ひとつで簡単に、IT資産が脆弱な状態へと変化してしまうことにも留意しなければならない。たとえば、エンドユーザーがクラウドストレージの設定変更を誤り、個人情報や機密情報が誰でもアクセスできる状態になっていたという事故は、枚挙にいとまがないほどだ。こうした事故も、定期的な脆弱性診断を待って発見するのでは遅すぎる。

 以上のような現状を考えると、企業のIT担当者が「社内のIT資産はすべて把握できている」「定期的に脆弱性診断を受けているのでセキュアだ」と過信するのは危険だ。セキュリティリスクをさらに減らせる方法を検討しなければならない。

「ASM(アタックサーフェスマネジメント)」の利点と課題

 こうした現在のニーズに対応するために登場したのが、「ASM(アタックサーフェスマネジメント)」と呼ばれるセキュリティの考え方(およびツール)である。経済産業省が2023年に「ASM導入ガイダンス」を発行したことで、国内でも注目されるようになった。

 ASMでは、攻撃対象になりうる企業のIT資産(アタックサーフェス)を自動的に発見/可視化し、その攻撃リスクを評価する。たとえば、企業がインターネットに公開しているサーバーにアクセスし、詳細な情報(OSやソフトウェアのバージョン、公開しているポート番号など)を収集して、攻撃対象になりうるかどうか、攻撃リスクはどれほどかを判断する――といった流れだ。

一般的なASMの特徴とイメージ(出典:経済産業省)

 先に紹介した脆弱性診断との主な違いは、IT担当者が把握していないIT資産(未知のIT資産)も発見できること、脆弱性診断よりも頻繁に実行できるため設定ミスなどの状態変化(新たな脆弱性の発生)を発見しやすいことだ。

 なおASMは、インターネットからアクセスできる外部公開のIT資産を調査対象とする「EASM(External ASM/外部ASM)」と、企業内ネットワークからしかアクセスできないIT資産を調査する「IASM(Internal ASM/内部ASM)」に分類されることもある。

経済産業省は「ASM導入ガイダンス」を発行し、セキュリティ対策の強化を訴えている(出典:経済産業省)

 こうした利点を持つASMだが、広く普及するにつれて「運用の難しさ」も指摘されるようになった。特に、セキュリティの専門家ではない担当者にとっては、使いこなしが難しい部分が多々あるようだ。

 たとえば、ASMを実行して多数のIT資産でリスクが指摘されても、どれから対策を進めるべきかの優先順位付けは難しい。攻撃発生のリスクが低いと評価されたものでも、攻撃成功時に想定されるビジネスへの影響が重大なものであれば、対策の優先度を挙げなければならない。そのほかにも、攻撃リスクを引き下げるための具体的な対策が分からない、運用人員が少なく改善のアクションがなかなか進まない、といった課題が生じているという。

前へ 1 2 次へ