【ITニュース解説】Building a Repeatable Public-Sector Exposure Baseline

システムエンジニアを目指す皆さんにとって、サイバーセキュリティは非常に重要なテーマの一つだろう。インターネットと接続されたシステムを開発・運用する上で、避けて通れない課題が「外部からの露出状況」の把握だ。世の中では日々、企業や政府機関を狙ったサイバー攻撃が報告されている。例えば、ウェブサイトへの大量アクセスでサービスを停止させるDDoS攻撃や、システムの脆弱性を突いた情報漏洩などが挙げられる。これらの攻撃の多くは、外部からアクセス可能なシステムが狙われることで発生する。

このような脅威に対抗するためには、自社の、あるいは担当するシステムの外部からの見え方を常に把握しておく必要がある。しかし、一度だけ調査して「これで終わり」にしてしまうと、その情報はすぐに古くなってしまう。システムは日々更新され、新しいサービスが追加されたり、古いものが停止されたりするからだ。そこで重要になるのが「ベースライン」という考え方だ。ベースラインとは、外部からどのように見えているかを定期的に測定し、その結果を記録していく基準値のことである。一度の測定は、ある時点でのスナップショットに過ぎないが、ベースラインを継続的に取ることで、システムの変化を時系列で追うことができ、前回との比較によって「何が変わったのか」「どこに問題があるのか」を発見できるようになる。この比較こそが、セキュリティ対策における真の価値を生み出すのだ。エストニアで発生したDDoS攻撃やデータ漏洩といった大規模なサイバーインシデントは、まさに外部からアクセス可能なシステムが狙われた事例であり、このような事態を未然に防ぎ、あるいは迅速に対応するためにも、継続的な監視と変化の把握が不可欠となる。

では、実際にベースラインを構築するには何が必要なのだろうか。繰り返し利用可能で、他のチームにも共有できるベースラインは、主に五つの要素で構成される。一つ目は「スコープ」、つまり測定対象の範囲を明確にすることだ。これは、特定の国、業界、組織、ドメインの集合、あるいはネットワークの範囲など、具体的な測定対象を指し示す。二つ目は「クエリ」で、これは測定を行う際に使用する正確な検索条件そのものを記録することである。例えば、「国がエストニアで、業界が政府機関のシステム」といった具体的な検索文字列をそのまま保存する。三つ目は「ユニット」、すなわちカウントする単位である。これは、ドメイン資産の数なのか、ホストの数なのか、それとも特定のサービスの数なのか、あるいは証明書の一致数なのかを明確にする。四つ目は「日時とタイムゾーン」は、測定が行われた正確な日付と時刻、そしてタイムゾーンを記録することで、異なる時点での測定結果を正確に比較可能にする。最後に五つ目は「解釈の限界」で、この数値が何を断定するものではないか、その限界を一言で注記しておくことで、誤った解釈を防ぐ。例えば、「この数値は、脆弱性や侵害を直接示すものではない」といった注意書きがこれに当たる。これらの要素をきちんと記録しておくことで、誰でも同じ条件で測定を再現でき、結果を比較できるようになる。

外部からの露出状況には複数の側面があり、実用的なベースラインはそれらを網羅的に捉える必要がある。具体的には、主に四つの層をカバーすることが推奨される。まず、「セクター固有のスコープ」は、政府機関のような特定の狭い範囲に絞った資産の数である。次に、「Webプレゼンス」は、インターネット上で公開されているHTTPSを使ったWebサイトやWebサービスに関連するドメイン資産の数を示す。さらに、「アクセス可能なサービス」は、ポート443のような主要なサービスポートで応答する全てのホスト資産の数だ。これは、Webサービスだけでなく、他の様々なサービスを含み得る。そして、「管理インターフェース」は、SSH（Secure Shell）のようなWeb以外のプロトコルを介して外部に公開されている管理用のインターフェースの数を示す。Webサービスだけを監視していては、SSHのようにシステム管理に使われる重要なインターフェースの露出を見落としてしまう可能性がある。これら四つの層はそれぞれ異なる情報を提供し、異なるリスクを示すため、全てを網羅的に把握することが、セキュリティ上の盲点をなくす上で非常に重要となる。

一度ベースラインを構築しても、それを継続的に運用しなければ価値は生まれない。役立つベースラインは、担当者がいなくとも自律的に機能する仕組みが求められる。そのための運用ポイントがいくつかある。まず、「測定頻度を決める」ことだ。例えば、狭いスコープの重要な資産は毎月、広範な層の資産は四半期ごとに測定するなど、対象に応じて適切な周期を設定する。次に、「スコープ定義をバージョン管理する」ことで、測定の対象範囲や条件に変更があった場合に、その変更内容と理由を記録に残し、誰でも確認できるようにする。安易にクエリを変更してしまうと、過去のデータとの比較が不可能になってしまうため、これは非常に重要な原則だ。さらに、「優先順位付けの前に所有者を特定する」必要がある。ただ「これだけの資産がある」と数値を出すだけでは不十分で、それぞれの資産がどの部署や担当者に属しているかを明らかにして、具体的な改善作業につながるようにする。また、「追加だけでなく、削除も追跡する」ことも重要だ。システムを停止したはずなのに、外部からまだアクセス可能な状態になっている場合、それは運用上のミスであり、セキュリティリスクとなり得るため、このような「残存資産」を見つけ出す必要がある。最後に、「修正後に再測定する」ことで、発見された問題が本当に解決されたのかを確認する。確認作業まで含めて、問題解決の一環と捉えるべきだ。

ベースラインの運用においては、いくつか陥りがちな間違いがあるため、これらを避けることが重要だ。最も一般的な間違いは、「測定のたびにクエリを変更してしまう」ことだ。検索条件が変わってしまうと、以前の測定結果と現在の結果を単純に比較することができなくなり、ベースラインとしての価値が失われてしまう。次に、「重複するカウントを合計する」ことだ。例えば、同じシステムがドメイン資産としても、特定のポートで応答するホスト資産としてもカウントされる場合がある。これらを単純に足し合わせると、実態とは異なる意味のない数値になってしまうため、注意が必要だ。また、「可視性を脆弱性と混同する」ことも避けるべきだ。インターネット上に公開されている資産が見つかったとしても、それはすぐに「脆弱性がある」とか「すでに侵害されている」ということを意味するわけではない。公開されていること自体はリスクの一因となるが、それが直ちにセキュリティ上の問題となるわけではないことを理解しておく必要がある。エストニアの事例でも、DDoS攻撃を受けたサイトがホストレベルで侵害されたとは断定されていない。そして、「非Web層を無視する」ことも危険だ。Webサービス以外の管理用インターフェースなどは、インシデント報告書に現れることが少ないため見過ごされがちだが、これらが不正アクセスの経路となるケースは少なくない。

エストニアの事例が示すのは、サイバーインシデントが特定のセクターや原因に限定されず、繰り返し発生するということ、そして外部からアクセス可能なシステムの状態は事前に把握可能であるということだ。適切に文書化されたベースラインは、この事前知識を次のインシデント発生時に活用するための重要な仕組みとなる。システムエンジニアにとって、システムが外部にどう見えているかを理解し、その変化を定期的に監視することは、セキュリティ設計や運用において不可欠なスキルとなるだろう。このような外部からの露出状況の把握には、ZoomEyeのような外部のサイバー脅威インテリジェンスツールが非常に有効だ。ZoomEyeは、国、業界、サービス、ポート、証明書などの条件で再現可能な検索クエリを提供し、内部システムにアクセスすることなく、外部から見た自社の公開資産の数を把握し、記録・比較することを可能にする。これにより、日々のインシデント対応だけでなく、長期的なセキュリティ対策において、常に外部からの露出状況を最新の状態に保ち、潜在的なリスクに備えることができる。継続的なベースラインの構築と運用は、堅牢なシステムを維持するための重要な基盤となるのだ。