ポリシーリスクを可視化。自然な言葉でポリシーに関する疑問を解決します。 デモを申し込む →
Published:
セキュリティは困難であり、代償は大きい
by FireMon
意思決定支援ツールが、セキュリティ運用チームの速度と正確性の両方をどのように向上させるか。
サイバーセキュリティは攻撃者が優位に立つ非対称なゲームだと言われてきました。攻撃者は一度成功すればよいのに対し、防御側は常に成功し続けなければなりません。たった一つのミスが、データ侵害、業務の中断、サービス停止、ランサムウェア感染といった壊滅的な結果を招くおそれがあります。
しかし、セキュリティを「正しく」行うことは困難です。家庭内ネットワークのように単一のシステムやネットワークしかない非常に小規模な環境であれば、正しく行うことは簡単に思えるかもしれません。すべての受信アクセスをブロックし、いくつかのシステムにパッチを適用する。それで完了です。
残念ながら、セキュリティ上の課題は、ネットワークの複雑さが拡大するにつれて指数関数的に増大します。他のリソースへの接続を必要とする新しいデバイス、ユーザー、サービスが追加されるたびに、環境の複雑さは n の 2 乗に比例して増大します。
100,000 以上のリソースを管理する大規模企業であれば、その複雑さは明らかでしょう。しかし、実際には 100 億通りの接続の可能性を管理する責任を負っていることをご認識でしょうか。さらに、各システムが複数のサービスを公開していることを踏まえると、複雑さはそれ以上になります(詳しくお読みになりたい場合はメトカーフの法則をご覧ください)。私の友人である Rich Mogull の言葉を借りれば、「シンプルなものはスケールしない」のです。
この複雑さという考え方を、ネットワークセキュリティポリシー管理の文脈に当てはめてみましょう。300 台のファイアウォールを管理し、各ファイアウォールに 300 のルールがある企業を考えてみます。ここでは、各ルールが送信元と宛先にそれぞれ数個のクラス C ネットワークを持ち、その間にいくつかのサービス(HTTPS、SQL、SSH など)が存在すると仮定します。
この環境において、セキュリティチームが管理する対象は次のとおりです。
- 300 台のファイアウォール
- 90,000 のファイアウォールルール
- 810,000 の論理ファイアウォールルール(送信元オブジェクト、宛先オブジェクト、サービス)
- 1,433,272,320,000(14 億)の接続(IP アドレス、IP アドレス、サービス)
300 台のファイアウォールと各ファイアウォールに 300 のルールという、この「シンプル」な環境では、セキュリティ運用チームは 14 億を超える接続を管理する必要があります。何らかの形の自動分析なしに、これを正しく行うことは不可能です。
課題は複雑さだけではありません。セキュリティはビジネスを支えることが求められ、そのビジネスは急速に変化します。新しいアプリケーションが稼働し、新しいパートナーが接続され、古いサービスが廃止され、そのすべてを今すぐ支える必要があります。許容される対応時間は企業ごとに異なり、数分から数か月まで幅がありますが、十分に速いと言えることはめったにありません。正しく行うことと迅速に行うことはしばしば相反しますが、それこそがセキュリティ専門家に課された使命です。
さらに悪いことに、人員を増やすだけでこの問題に対処することはできません。新規採用の抑制を求める圧力は常に存在します。仮に増員の承認が得られたとしても、今日の人材市場では、多額の報酬を支払わずに有資格の人材を見つけることは極めて困難でしょう。
では、指数関数的に増大するこれらの課題に、よくても線形にしか増えないリソースでどのように対応すればよいのでしょうか。
その答えは、意思決定支援ツールによってチームの能力を高めることです。先ほどのファイアウォールの例を用いて、具体的な課題と、優れたツールがリスクの低減、継続的なコンプライアンス、ポリシー変更を正確に展開するまでの時間短縮といったセキュリティ成果をどのように改善するかを見ていきましょう。
リスクを低減する
トラフィックの通過を許可するファイアウォールポリシー上のすべてのルールは、組織にリスクをもたらします。その多くは、ビジネスを機能させるために許容され、必要とされるリスクです。たとえば、SMTP トラフィックの送受信が許可されていないメールサーバーはほとんど役に立ちません。しかし、本番環境のファイアウォールには不要なルールが驚くほど多く存在し、その多くが不必要なアクセスや不必要に高リスクなアクセスを許可しています。
管理対象が 14 億の接続という例において、有用で必要なものと、無用で不要なものをどのように見分ければよいのでしょうか。ネットワークセキュリティポリシー管理ソリューションは、14 億すべての接続を評価し、削除すべきものを特定するために必要な意思決定支援を提供できます。
- 冗長なルールを見つける:冗長なルールはポリシーに不要な複雑さを加えます。既存のルールと重複しているため何の目的も果たしませんが、ミスを招きやすい複雑さをもたらします。これらはリスクなく削除できる、取り組みやすい対象です。
- シャドウ化されたルールを見つける:完全に冗長なルールよりも分かりにくいのが、別のルールによって「シャドウ化」されているルールです。このルールは価値を生まず、単にポリシーを複雑にするだけです。これらのルールは削除してください。
- 未使用のルールを見つける:ログトラフィックを適切に監視すれば、ポリシー内に存在しながら使用されていないルール(ルールに一致するトラフィックがないもの)を検出できます。これらのルールはポリシーを複雑にするだけでなく、リスクも増大させます。ただし、災害復旧システムなどの重要なプロセスが依存していながら、テスト時以外はトラフィックを発生させない場合もあるため、削除を決定する前にまず確認が必要です。
- ルール内の未使用オブジェクトを見つける:3 つの送信元ネットワーク、3 つの宛先ネットワーク、3 つのサービスからなる例のルールでは、その一部が不要であることは非常によくあります。未使用ルールの特定と同様の手法を用いれば、ルール内の未使用オブジェクトを特定できます。未使用オブジェクトはそれぞれ不要なリスクを表しており、削除すべきです。
- リスクの高いサービスを見つける:許可すべきでないアクセスもあります。たとえば、暗号化されていないプロトコルによるシステム管理は、機密データや認証情報を露出させるおそれがあります。このため、telnet のようなサービスはほとんどの場合許可すべきではありません。高リスクなサービスの使用を許可しているすべてのルールを見つけ、そのアクセスを削除してください。必要に応じて、システム停止を避けるため、ポリシーを変更する前にシステム担当チームと連携してこれらのシステムへのアクセス方法を変更してください。
- ゾーンポリシーに違反するルールを見つける:ファイアウォールはいずれの場合もネットワークセグメントを分離するように構成されています。多くの場合、異なるゾーン間で許容されるトラフィックを記述するセキュリティポリシーを定義できます。例としては、人事部門と財務部門の間で許可されるアクセスや、PII データをホストする環境とユーザーネットワークの間のアクセスなどが挙げられます。これらのゾーンポリシーに照らしてファイアウォールルールを評価することで、レビューと是正が必要な違反ルールを特定できます。
コンプライアンスを徹底する
ほとんどの組織は、1 つ以上の社内または社外のコンプライアンスフレームワークを順守することが求められます。たとえ要件がない場合でも、これらのフレームワークに照らして組織のセキュリティポリシーとプロセスの有効性を検証することは有用です。こうした環境の複雑さは評価を困難にし、場合によっては手作業のレビュープロセスでは実施すら不可能にします。自動化はそれを可能にするだけでなく、ほぼリアルタイムで不備を特定することにより、継続的なコンプライアンスの徹底を実現します。また、包括的なファイアウォールポリシー変更管理プロセスに統合することで、ミスの発生も防止します。
変更を管理する
例に挙げたネットワークで 14 億のすべての接続がビジネスの要求どおりに正確に機能し、すべてが完璧であったとしても、たった 1 つの変更が壊滅的な結果につながるリスクをもたらすおそれがあります。変更は避けられず、セキュリティチームは迅速かつ正確に対応できなければなりません。それがビジネス要件による変更であれ、緩和すべき外部脅威によるものであれ、新たなリスクやサービス停止を容易に招く可能性があります。不要なリスクを生じさせずに変更を最適に実装する方法を把握することは困難な作業であり、自動化された意思決定支援ツールが最も適しています。ユースケースの例は次のとおりです。
- 変更要求のリスクとコンプライアンスを評価する:実装すべきでない変更要求もあります。こうした変更の潜在的な影響をどのように評価するのでしょうか。脆弱性が判明しているシステムへのアクセスを露出させることになるでしょうか。ゾーンアクセスポリシーに違反するでしょうか。これらの要求を手作業でレビューするプロセスには数週間、場合によっては数か月かかることもあります。時間が経過するにつれてビジネス側の不満は高まり、高リスクな変更を防ぐために設計されたプロセスやセキュリティ管理を迂回する「緊急要求」につながります。自動化された事前変更評価ツールは、高リスクなルールをリアルタイムで特定し、要求者に差し戻すか、例外処理プロセスに回すという選択肢を提供します。
- 変更の実装方法を評価する:ファイアウォールベンダーは、既存ルールへの変更を非常に簡単に実装できるようにする点で優れた成果を上げています。しかし、エンタープライズ環境では、どのような変更を行うべきか、どのファイアウォールを変更すべきかを判断することは極めて困難です。既存の 14 億の接続の中に、新しいルール要求に必要なアクセスがすでにすべて存在しているかもしれませんが、それを把握できていない可能性があります。また、冗長になりかねない新しいルールを作成する代わりに、簡単な修正を加えるだけで済む既存のルールが存在する場合もあります。どのポリシーとデバイスを変更する必要があるか、またポリシーのどこで変更を行うかを特定するには、数時間を要することがあります。適切な意思決定支援ツールがあれば、このプロセス全体を自動化し、セキュリティ運用チームがより迅速に適切な変更を行えるようになります。
セキュリティは困難であり、その代償は大きなものです。チームが職務を遂行するために必要なツールを提供してください。
FireMon がチームに必要な意思決定支援をどのように提供できるかについて詳しくは、セキュリティポリシーソリューションのページをご覧ください。