一貫したネットワークセキュリティ衛生を確保する5つのヒント

セキュリティの焦点は、常に複雑で高度な攻撃への防御に置かれてきました。高度な攻撃者と優れた防御側との戦いは、格好の物語になります。いわば善と悪の対決です。

ロシアとウクライナの戦争を受けて、ロシアからのサイバー攻撃に備えてきた方も多いでしょう。米国政府は攻撃を想定するよう呼びかけています。ロシアが西側諸国に対して大規模なサイバー攻撃を仕掛けるかどうかは分かりませんが、仮に実行するとすれば、どのような攻撃を用いるのでしょうか。答えは、目的を達成できる最も単純な攻撃だと考えます。相当なサイバー能力を持つ国家は、いずれも数十(あるいはそれ以上)のゼロデイ攻撃を温存しています。しかし、やむを得ない状況でない限り、わざわざ高度な攻撃手段を使い捨てにするでしょうか。

合理的な攻撃者は、環境内に足がかりを得るために最も抵抗の少ない経路を探します。つまり、最も弱い部分を突くということであり、それはたいてい設定ミスやその他の基本的なセキュリティ上の誤りといった単純なものです。こうした攻撃から身を守る最善の方法を尋ねられたとき、私は通常、単純なことをしっかりやることだと答えています。フットボールにたとえるなら、ブロッキングとタックリングの基本です。

私のパートナー(であり DisruptOps の共同創業者)である Rich Mogull は、かねてより「単純なものはスケールしない」と述べており、それは正しい指摘です。2台のデバイスでファイアウォールの変更を行うのは難しくありません。しかし、世界中の数百台のデバイスでファイアウォールポリシーを適用するのは、極めて困難です。そして、それを毎回正確に実行するとなれば、難易度はさらに高まります。

そこで、単純なことを確実かつ一貫して実行するための解決策について考えてみましょう。意外にも、それには人材、プロセス、テクノロジーの組み合わせが必要です。なかでもプロセスを重視するのは、一貫性を実現する最善の方法だからです。全員が自分のすべきことを理解し、その活動を追跡する手段があれば、結果は自ずと一貫したものになります。

以下の5つのヒントは、セキュリティ衛生と全体的なセキュリティ体制を改善するための道筋となるはずです。

ヒント1:ポリシーについて合意を形成する

どこへ向かうのか分からなければ、いつ到達するのかも、そもそも「そこ」がどこなのかも分かりません。そこで最初のヒントは、成功の姿を把握できるよう衛生ポリシーを定めることです。1週間以内にパッチを適用するという目標を設定する場合でも、特定の地域への外向き通信を遮断する場合でも、ポリシーを定義し文書化しておくことで、実際に遮断を始める前に全員の認識をそろえられます。

ヒント2:可視性を広げる

見えないものは管理できない、という格言を聞いたことがあるでしょう。これは事実です。ポリシーについて全員の認識がそろったら、次は環境内に何があるのかを把握する必要があります。念のため申し添えると、ある程度はすでに把握しているはずです。拠点や導入済みのインフラなどです。資産情報が(名目上は)登録された CMDB をお持ちかもしれません。それが出発点になります。

手元にある資産リストや体制の情報は、特にクラウドや SaaS が急速に広がるなかで、すでに古くなっている可能性が高いといえます。したがって、オンプレミスとクラウドの両方を含む技術資産全体を把握するための、明確なプロセスとツールが必要です。

ヒント3:変更を管理する

もう一つ実装すべき重要なプロセスが変更管理です。誰が、いつ、どの変更を行うのか。このプロセスは、Log4j(あるいは次に広範な影響を及ぼす脆弱性)について知る前に検討しておくべきです。一貫性のある運用を成功させる鍵は、全員が自分の役割を理解していることです。総動員が必要な事態において、最も避けたいのは役割と責任の不明確さです。

変更には承認が必要でしょうか。承認者に RTO(応答時間目標)は設定されていますか。承認なしで変更を行うほど緊急な状況はあるでしょうか。どの程度のダウンタイムなら許容されますか。変更管理プロセスは、こうした状況に対応できるものである必要があります。

また、プロセスの一環として、誰が変更を行ったかを必ず監査してください。不適切な変更が発生した際に、誰の失敗かを把握したくなるはずです(これは半分冗談です)。さらに、管理者用デバイスが侵害された場合にも、攻撃者による変更がすべて記録されていれば、迅速にロールバックできます。

ヒント4:継続的な監視

ここまででプロセスの話は十分でしょう。次は実際に手を動かす番です。ここが面白いところですね。衛生管理の鍵は監視です。虫歯の検査のために年2回歯科を受診するように、インフラを継続的に監視して、すべてがポリシーに準拠していることを確認する必要があります。

つまり、デバイスの設定変更を確認するということです。前述のとおり、設定ミスは攻撃者にとって最も抵抗の少ない経路になりがちです。設定が変更されたかどうか、また変更された時期を確実に把握しておく必要があります。

適用可能なパッチについても監視が必要です。実際の適用は次のパッチ適用期間まで待つとしても、どのデバイスを更新する必要があるのか、またそのパッチの相対的な緊急度を把握しておけば、作業を効果的に計画できます。

上で「継続的」と述べましたが、これは相対的な表現です。設定を1分ごとに確認すべきでしょうか。1時間ごと、あるいは1日ごとでしょうか。状況によりますが、一般的には監視は多いほうが少ないより優れています。実際に最も望ましいのは、ログストリーム内の変更を検知する方法です。たとえば、AWS のセキュリティグループや(Palo Alto のファイアウォールを使用している場合は)Panorama のファイアウォールルールが変更された際にアラートを設定できます。このトリガーによって変更を発生と同時に把握でき、その変更が悪意ある行為者によるものであれば、1分1秒が重要になるのは間違いありません。

ヒント5:(ほぼ)すべてを自動化する

私たちは自動化を高く評価しています。実際、自動化は当社のすべての製品の中核的な要素です。「単純なものはスケールしない」ことを踏まえると、環境が大規模かつ複雑になるほど、自動化の採用は不可欠になります。セキュリティ人材のスキルギャップや、人材の確保と定着の難しさを考えれば、機械に任せられる範囲は広いほど望ましいといえます。

デバイスへの修正適用も、不正な変更のロールバックも自動化できます。パッチに関する情報源の監視を機械に任せることもでき、同じ機械が変更に関する多数の情報を収集して、定期外の変更や不正な変更を特定することもできます。

AWS の関係者は、人がインフラを変更するたびに、それは自動化の失敗だと考えています。大多数の企業にとっては理想論ですが、優れたビジョンではあります。プロセスを定着させ、担当者が繰り返し行っている定型作業を見極めたら、それを自動化してください。自動化を進めすぎることへのためらいも(場合によっては理解できるものとして)存在します。自身が納得できる以上の速さで自動化を進める必要はありませんが、同時に、変化への不安が組織の足かせになってはなりません。

まとめると、攻撃者にとって最も抵抗の少ない経路になっては*いけません*。運用の観点からセキュリティ衛生を一貫して確保できれば、セキュリティ体制は大幅に強化されます。攻撃を完全に防げるとは申し上げませんが、攻撃者に相応の労力を強いることはできます。