では、ASMを導入していれば全て防げるのか。ここでは幾つかの事例を基に、ASMの限界を示したい。
例えば、高野総合会計事務所の事例では、委託先業者がネットワーク機器の設定変更作業を行った際、設定ミスによりアクセス制御に不備が生じ、そのわずか数日後にランサムウェア被害が発生している。アクセス制御の不備というのは、おそらく不要なポートの外部公開やアクセス元制限の緩和などだと考えられる。
また、別の事例では、ファイアウォールの更新作業の際にミスがあり、その翌日に侵害を受けている。ミスから侵害まではわずか30時間程度だ。
上の事例を見るに、ASMサイクルを1日1回の頻度で回していたとしても、攻撃者がこれを上回る速度で隙を見つけ、攻撃を成功させる可能性は否定しきれない。問いたいのは、「ASMツールで守るべきだったのか」ということだ。
設定変更を行ったのであれば、正常に稼働し通信ができるかどうかという「正常系」のテストだけでなく、意図しないアクセス元、例えばメンテナンス用のIPアドレス以外からアクセスできないかどうかという「異常系」のテストを行うのが本来のシステム運用の姿ではないだろうか。あえて言えば、これはASM以前にやっておく必要のあることだ。
システム運用における基本的な確認不足やテスト不足を、ASMというツールでカバーしようとするのは間違いだ。その手前で防げるミスは運用プロセスで防がなければならない。
また、ASMのスコープから漏れやすい盲点として、「持ち出しPC」の存在がある。SIMを搭載したPCが社外で使用されているとき、それはインターネット上に存在するアタックサーフェスとなる。石光商事の事例では、外部で使用していたPCがRDP(Remote Desktop Protocol)経由で侵害され、そのPCが社内ネットワークに接続された際に、攻撃者の侵入経路となってしまった。
持ち出しPCがモバイル回線で接続されている間は、ASMの対象から外れてしまう可能性がある。こうしたデバイスが侵害を受けた後に内部ネットワークに接続することで、攻撃者を招き入れる拠点となってしまうリスクがあるのだ。これを防ぐには、外部からのスキャンだけでなく、エンドポイントの保護や内部ネットワークの監視を含めた包括的な対策が必要となる。
さらに、内部ネットワークにおける「マイクロセグメンテーション(領域分割)」の重要性を示す事例もある。大阪急性期・総合医療センターの事例では、給食事業者のシステムが侵害され、そこからVPNやリモートデスクトップを経由して病院の基幹システムへと侵入された。
なぜ被害が拡大したのか。それは、給食管理サーバと電子カルテなどの重要システムが、マイクロセグメンテーションなどなしにフラットなネットワークでつながっていたからだ。
調査報告書を読むと、給食提供事業者とネットワークで直接つながっていた医療機関は大阪急性期・総合医療センター以外にも存在していることが分かる。だが、他の組織では栄養給食管理サーバと電子カルテサーバのシステムが異なるネットワークセグメントに配置されていたため、被害を免れたと考えられる。報告書は、「攻撃者はネットワークセグメントを分割した組織に対しては侵入を諦め、大阪急性期・総合医療センターへの侵入に集中したものと思われる」と述べている。不要な通信を遮断し、万が一侵入されても被害が波及しないようネットワークを分割しておくべきだったのだ。
サプライチェーンがつながっている以上、接続経由で侵害されるリスクはゼロにはできない。だからこそ、もしものときに攻撃可能な領域を減らしておく必要がある。
しかし、ネットワークを分割すれば安心かというと、そうではない。さらに衝撃的な事例がある。S-RM社が報告した「EDR(Endpoint Detection and Response)」を回避したランサムウェア感染のケースだ。
攻撃者は侵入後、EDRが導入されたWindows PC上でランサムウェアを実行しようとしたが、EDRに阻止された。しかしそこで攻撃者は諦めず、同じネットワーク内にあったLinuxベースのIoT機器に目を付けた。このIoT機器にはEDRが対応していない。攻撃者はIoT機器に侵入し、そこからWindows PCのドライブをネットワークマウントさせ、IoT機器側からランサムウェアを実行して暗号化に成功したのだ。
PCと、セキュリティレベルの向上に限界のあるIoT機器が同じセグメントにあり、互いに通信できる状態にあったことが最大の問題だ。従って、「利用しているIoT機器に対応したEDRを導入するべし」という話ではない。セキュリティレベルの異なる製品を、同じネットワークに置くことで全体のセキュリティレベルを下げないようにしようという話だ。IoT機器はPCとは別のセグメントに隔離し、SMB通信などPCへの不要な接続を遮断しておけば防げたはずである。
これらの事例から分かることは、ASMは有用な手段ではあるが、決して万能ではないということだ。
ASMを用いた外部からの資産の可視化と脆弱性の検出は、もちろん必要なことではある。しかし、持ち出し端末や内部ネットワークに存在する脆弱性までは、外部からのスキャンだけではカバーしきれないし、カバーすべきではない。
また、異常系テストの未実施、フラットなネットワーク構成や同一ネットワークにおける異なるセキュリティレベルであるデバイスの混在といった、基本的かつ初歩的な問題はASMでカバーしきれないし、カバーすべきではない。
「寝ていない、食べていない、運動もしていない」のに、サプリメントを飲んで健康になれるわけがない。ASMという“サプリメント”を摂取する前に、まずはあるべきシステム運用、適切なネットワーク設計、そして資産管理という基本的なところに立ち返り、自組織とそのネットワークを見つめ直してほしい。
われわれのゴールはASMを導入することでも、それで全てを解決しようと夢見ることではない。ASMが検出できる範囲と、検出できない「盲点」を正しく理解し、足りない部分は運用ルールやネットワーク設計、別の製品・サービスで補う。そうした全体を俯瞰した「セキュリティマネジメント」の仕組みを構築することこそが、今求められている真の対策なのである。
ASMはあくまで「従」である。それをうまく使うためには「主」であるユーザー、つまり皆さんが、何を可視化してくれるのかを理解する必要がある。ツールに踊らされることなく、自分たちの組織を守るために何が必要か、本質を見極める目が必要とされている。ぜひ、皆さんの組織でも、これらの点を話し合ってみてほしい。それこそが、組織のセキュリティ体制を真に「マネジメント」するための唯一の道なのだ。
SBテクノロジー株式会社
セキュリティリサーチャー
コンピュータの専門学校に通いながら、サイバーセキュリティを手探りで学び、侵入テストの仕事に就きたくて上京。現在は、侵入テストだけでなく、事件・事故を調査するセキュリティリサーチの仕事にも携わっている。侵入テストで培った攻撃者視点や分析力と、リサーチで得た情報・知識を基に、執筆や講演などのエバンジェリストとしても幅広く活動する。
Copyright © ITmedia, Inc. All Rights Reserved.