SDPによるエンタープライズセキュリティの青写真

エグゼクティブサマリー

今日のビジネスは、自由に流れる情報によって動かされています。企業データは、クラウドやモバイル・デバイスを介して移動し、ソーシャル・ネットワーク上のアイデアや投稿を介して発信されます。BYOD、モビリティ、クラウドコンピューティングは、静的なIT環境に革命をもたらし、動的なネットワークとインフラストラクチャの必要性を導入しました。

しかし、私たちのIT環境が急速に変化したとすれば、脅威の状況はさらに急速に変化しています。この進化の巧妙さと速度は、新しい攻撃タイプを頻繁に解き放ち、既知と未知の脅威を組み合わせ、「ゼロデイ」の脆弱性を利用し、文書、ウェブサイト、ホスト、ネットワーク内に隠されたマルウェアを利用することで、指数関数的に増大しています。

ITインフラストラクチャやネットワークの需要が高く、境界線が十分に定義されておらず、脅威が日に日にインテリジェント化している世界では、変化し続ける脅威の状況の中で企業を保護するための適切な方法を定義する必要があります。

ポイント・セキュリティ製品は広く普及していますが、これらの製品は、アーキテクチャ指向ではなく、本質的に反応的で戦術的な傾向があります。今日の企業は、高性能なネットワーク・セキュリティ・デバイスとリアルタイムのプロアクティブな保護を組み合わせた単一のアーキテクチャを必要としています。

組織を積極的に守るためには、新しいパラダイムが必要です。

SDP(Software-Defined Protection)は、新しい実用的なセキュリティアーキテクチャと方法論です。SDPは、モジュール式でアジャイルなインフラストラクチャを提供し、最も重要なのはセキュリティです。

このようなアーキテクチャは、本社、支店、スマートフォンやモバイルデバイスを介したローミング、クラウド環境を利用する場合など、場所を問わず、あらゆる規模の組織を保護する必要があります。

セキュリティ管理者が何千ものアドバイスや推奨事項を手動でフォローアップしなくても、防御は脅威の状況に自動的に適応しなければなりません。これらの防御は、より大きなIT環境にシームレスに統合され、アーキテクチャは、内部および外部のインテリジェントなソースの両方を協調的に活用する防御姿勢を提供しなければなりません。

SDP アーキテクチャは、セキュリティインフラストラクチャを、相互に接続された 3 つの層に分割します。

  • 物理的および仮想的なセキュリティ実施ポイントに基づき、ネットワークをセグメント化し、需要の高い環境で保護ロジックを実行する実施層。
  • 脅威情報のさまざまなソースを分析し、保護とポリシーを生成して実施層が実行する制御層。
  • インフラストラクチャをオーケストレーションし、アーキテクチャ全体に最高レベルの俊敏性をもたらす管理層。

高性能な実施層と、急速に進化するダイナミックなソフトウェアベースの制御層を組み合わせることで、SDPアーキテクチャは運用上の回復力を提供するだけでなく、絶えず変化する脅威の状況に対応したプロアクティブなインシデント予防を実現します。

将来を見据えて設計されたSDPアーキテクチャは、従来のネットワークセキュリティとアクセス制御ポリシーの要件に加えて、モバイルコンピューティングやSDN (Software-Defined Networks) などの新しいテクノロジーを採用する現代の企業が必要とする脅威の防止をサポートします。

01 実施層

企業のセキュリティを確保するための最初のステップは、ユーザーとシステム間の相互作用を仲介するために、ネットワークとホストの両方に実施ポイントを実装する場所を特定することです。

このようなセグメンテーションは、攻撃を受けた組織の存続に不可欠であり、したがって、実施層の主な原則となっています。SDP アーキテクチャのセグメント化は、ネットワーク内での脅威の拡散を防ぐことで、単一のネットワークコンポーネントを標的とした攻撃が企業のセキュリティインフラストラクチャ全体を弱体化させないようにします。

セグメンテーションはセキュリティ実施の基礎となるものです。以下のことを実現することを目的としています。

  • ネットワークの様々なセグメントに対して、よりシンプルでモジュール化されたセキュリティポリシーをサポートする
  • 異なるセグメントのセキュリティ・アーキテクチャ・テンプレートの作成を可能にする
  • セグメント内の侵害されたホストに封じ込めポリシーを適用する
  • セキュリティ・コントロールによる仲介を必要としないセグメント内相互作用の定義

セグメンテーションの動機づけ

第一世代のネットワーク・セキュリティは、1990年にBill Cheswick氏が基本的なコンセプトを説明したように、「柔らかくて噛みごたえのある中心部の周りに、ある種のカリカリの殻が付いている」境界線保護に焦点を当てていました。これは、内部ネットワークが「信頼されている」のに対し、外部のインターネットは「信頼されていない」というものでした。ファイアウォールの役割は、アウトバウンド接続(信頼されたものから信頼されていないものへ)を許可し、インバウンド接続を防ぐことでした。その後、次世代ファイアウォールは、侵入防止システム(IPS)とユーザーおよびアプリケーション認識機能を追加してこのフレームワークを拡張し、アウトバウンドとインバウンドのネットワークトラフィックをよりきめ細かく制御するようになりました。

現在、企業を効率的に保護するためには、もはや境界線の保護だけでは十分ではありません。今日の企業情報システムは、複数の物理的なサイトやネットワーク環境に配置されており、社内のユーザーだけでなく、ビジネスパートナー、顧客、一般の人々にもサービスを提供しています。企業資産は、メインフレームコンピュータから従業員のモバイルデバイスまで、さまざまなタイプのコンピューティングリソースに依存しています。

境界線が曖昧になり、拡大し続ける中、多くの組織は、信頼できる内部ネットワークを前提とすることがもはや安全な手段ではないことに気付いています。やる気のある攻撃者は、物理的なアクセス、ソーシャル・エンジニアリング、ハードウェアやソフトウェアのサプライ・チェーン内での妥協、ゼロデイ・エクスプロイトを利用して、最終的には企業の防御メカニズムを突破することができます。企業ネットワーク内の相互作用を可視化し、保護するためには、内部セキュリティ対策が必要です。

区画化は、攻撃を受けた組織の生存に不可欠です。空母が攻撃を受けたときに損害を封じ込め、浮揚を維持するために、密閉された防水コンパートメントを使用するという空母の概念と同様に、大規模な組織は、異なるセキュリティ特性を持つネットワークの様々なセグメントを識別し、脅威の封じ込めと回復のために必要なセキュリティ管理を確立しなければなりません。

ユーザーと重要な企業資産の間に実施ポイントを導入することで、ユーザーのワークステーションが外部の攻撃者によって侵害された場合の可視性を高めることができるだけでなく、内部ユーザーによる不正アクセスを検出して防止し、企業のセキュリティポリシーを実施することができます。

セグメンテーションの方法

セグメンテーションの実装は、ネットワーク内の「アトミック」セグメントを定義することから始まります。セグメントは、実施ポイントによって保護されたコンピューティングおよびネットワーキング要素の論理的なセットとして定義されます。セグメントは、ホスト上で実行される単一の実行ファイルのように小さいものから、組織全体のように大きいものまであります。アトミックセグメントには、同じポリシーと同じ保護特性を共有する要素が含まれます。定義された保護ロジックを強制するために、各セグメントの境界に強制ポイントが導入されます。セグメントをグループ化して、モジュール式の保護を可能にすることができます。セグメンテーションモデルが作成されたら、それをネットワーク設計に統合します。最後に、信頼されたチャネルを確立して、さまざまなネットワークセグメント間の相互作用とデータフローを保護します。

以下、セグメンテーションの方法について説明します。

  1. ステップ1  アトミックセグメント
    1. 同じポリシーと保護特性を共有する要素を特定する
    2. セグメント境界にセキュリティ実施ポイントを定義し、セグメントに出入りするすべての情報の流れを仲介し、制御されたアクセスのみを許可する
  2. ステップ2  セグメント別グルーピング
    1. モジュール式保護を可能にするためのアトミックセグメントのグループ化
    2. すべての企業資産が管理されたセグメントの境界内で定義されるまで、セグメントのグループ化を繰り返す
  3. ステップ3  実施強化
    1. ネットワークセキュリティ・ゲートウェイやホストベースのソフトウェアなど、物理的および仮想的なコンポーネントを統合する
    2. 統合と仮想化を使用して最適なソリューションを実現する
  4. ステップ4  信頼できるチャンネル
    1. セグメント間の相互作用とデータフローの保護

ステップ1  アトミックセグメント

アトミックセグメントは、以下のような一連のコンピューティングおよびネットワーキング要素で構成されています。(1) 共通のセキュリティプロファイルを共有していること、(2) さらに小さなセグメントに細分化できないこと、(3) セグメントと外部エンティティとの間のすべての相互作用を仲介するセキュリティ制御を使用して保護できること。アトミックセグメントの例としては、セキュリティソフトウェアがインストールされた単一のデバイスや、セキュリティゲートウェイによって保護された共有ネットワーク上の多数のホストが挙げられます。

アトミックセグメントを定義し、共通のセキュリティプロファイルを共有するエンティティを特定することは、SDP アーキテクチャを実装するための最初のステップです。セキュリティプロファイルは、セグメント内の企業資産の価値と、セグメントのユーザーとセキュリティ管理に付与される信頼レベルに基づいて、各セグメントに割り当てられます。

脅威は、異なるセキュリティプロファイルを持つ2つのセグメントが相互に作用する場合に発生する可能性があります。さらに、脅威が発生する可能性は、2 つのセグメントのセキュリティ プロファイルの違いと並行して増大します。このようなリスクを回避するために、多くの組織では、このセグメンテーション方法論をサポートできるデータ、ホスト、アプリケーション、およびネットワークのために、企業全体の分類スキームを使用しています。

ビジネスの目的に応じて、以下のセキュリティ要求事項のうち、1つを分類の主要な原則として選択します。機密性、完全性、可用性(CIA)。一例としては、以下のようなものが考えられます。

  • パブリック – 一般の人がアクセスできるようにクリアされたシステムやデータ
  • 顧客 – 顧客の機密情報を含むシステムおよびデータ。通常、認証された顧客と少数の内部ユーザーがアクセスできるようにクリアされている
  • 内部 – 従業員はどこからでもアクセス可能
  • 機密性 – 強化された保護が必要な内部システムとデータ
  • 部門別 – 部門の役割によって選ばれた個人に限定されている

このタイプの分類は、セグメントとそのセキュリティプロファイルの定義に役立ちます。各企業に必要なセグメンテーションのレベルと程度は、その企業のビジネスニーズとセキュリティ要件によって異なります。組織によっては、厳格な「最小特権」と「特権分離」のポリシーを適用しているところもあれば、すべてのユーザとシステムを、アクセスレベルとミッションクリティカル性の点で同等と考えているところもあります。

ヒント
セグメントの境界を決定する際には、エンティティが同じ権限を持ち、同じビジネスプロセスをサポートし、同じような資産を扱い、同じレベルのセキュリティ保護を受けているかどうかを必ず確認します。これらの質問にすべて「はい」と答えた場合、これらのエンティティを 1 つのアトミック・セグメントに含めることができます。少なくとも1つの質問に対して「いいえ」と答えた場合は、エンティティを個別にセグメント化する必要があります。

以下に、エンティティを異なるセグメントに分離する例をいくつか示します。

  • 同じ LAN 上の 2 台のエンドユーザー・ワークステーションが、同じ分類の企業資産にアクセスしている。
    • 一方のワークステーションのユーザがもう一方のワークステーションを攻撃する動機はほとんどないので、2つのホストは1つのアトミックセグメント内にあると考えられます。
    • 一方、ユーザーは、権限のない企業資産にアクセスしたいと思うかもしれません。このようなユーザーと資産は、別々のセグメントでモデル化されるべきです。
  • データセンター内のサーバーには適用されない脅威(物理的な盗難など)にさらされるモバイルデバイス。
    • これらのエンティティには異なるセキュリティ要件があり、1 つのアトミックセグメントにまとめるべきではありません。
  • 事業部と拠点を分離する。
    • 異なるエンティティは、常に別々のセグメントでモデル化する必要があります。
  • 組織外のユーザーがアクセスできるサーバー。
    • これらのエンティティは、外部に公開されていない内部サーバーとは異なるセキュリティプロファイルを持っています。

ステップ2  セグメント別グルーピング

アトミックセグメントが特定されると、それらを階層的なセグメントにグループ化することができます(例えば、アプリケーションをホスト境界内でグループ化し、ネットワークセグメント内で複数のホストをグループ化し、複数のネットワークを階層的にグループ化することができます)。

各サブセグメントはそれぞれ独自の保護を処理しますが、グループ化することで以下のような機能をサポートしています。

  • 抽象化と情報隠蔽によるモジュール性の向上
  • サブセグメントよりも上位セグメントの境界での信頼性の向上または包括的な保護の強化
  • セキュリティインフラサービスの集中管理と提供
  • 感染封じ込めと回復

図 1-A のサンプルサイトを考えてみましょう。この企業は、MPLS プロバイダのネットワークで接続された複数のサイトで構成されています。網掛けのボックスで表された各サイトは、内部ユーザー(LAN)とサーバー・セグメントをホストするアクセス・ネットワークで構成されています。内部サーバーと機密サーバーは、ゲートウェイまたは実施ポイントによってユーザーから隔離された別々のセグメントでホストされています。複数の部門別セグメントは、部門のエンドユーザーに自己完結型の機能を提供します。最後に、非武装地帯(DMZ)は、それ自身のセグメントで、パブリック・フェイシング・サービスを提供します。

この例では、複数のサーバセグメントと独立したユーザセグメントにより、セグメント間のすべての相互作用をきめ細かく制御することができます。この制御により、分類ベースのセキュリティポリシーが適用され、危殆化したホストの封じ込めが可能になります。すべての内部セグメントは、サーバーセグメント内の集中システムとネットワーク管理インフラストラクチャからセキュリティサービスを受けます。インターネットおよび WAN アクセスは、専用の実施ポイントによって制御されます。また、インターネットの実施ポイントは、DMZへの出入りを制御します。


セグメントのグルーピング
図1-A


階層的なグループ内では、インタラクションが複数の実施ポイントを通過する場合があります。 たとえば、インターネット上のリソース(コンテンツ更新サービスなど)に接続する「内部サーバー」セグメントのサーバーは、次の順次実施ポイントによって仲介される場合があります。

  1. 「内部サーバー」セグメントのホストにインストールされているセキュリティソフト
  2. 「内部サーバー」セグメント境界実施ポイント
  3. データセンターの境界に設置された実施ポイント
  4. インターネットに面した境界施行ポイント

DMZセグメント上に配置されたプロキシを介した相互作用は、DMZセグメントに出入りするDMZセグメント実施ポイントを含む追加の制御パスを通過することになります。

企業は、ネットワークの連続した大きな部分でセグメントをグループ化するプロセスを繰り返すことで、すべての資産が保護されたセグメントに含まれていることを確認することができます。セグメントのグループ化に応じて確立された階層的な防御ラインは、内部ネットワークを区画化し、優れた保護を提供します。

ステップ3  実施強化

モデルから実装まで

セグメンテーションモデルが作成されると、定義された実施ポイントはネットワークセキュリティゲートウェイとして、またはホストベースのソフトウェアとして実装する必要があります。マルチホームゲートウェイ、ゲートウェイ仮想化、仮想ローカルエリアネットワーク(VLAN)、SDN、ネットワーク仮想化などの統合と仮想化技術を使用して、最適なパフォーマンス、管理性、所有コストを実現することができます。

セグメンテーション・モデリング・プロセス(図 1-B)は、DMZ セグメント上のユーザ・ワークステーション、サーバ(CRM、R&D、および財務)、セキュリティ・オペレーション・センター(SOC)、および外部に面したサーバで構成されるサンプル・ネットワークのセグメンテーションを示しています。セキュリティプロファイルは、アトミックセグメントに関連付けられています(図1-Aの「セグメント分類」の凡例を参照)。各セグメントの境界には、実施ポイントが配置されます。セグメントは、セキュリティプロファイルに従ってグループ化されます。


企業のセグメンテーションプロセス
図1-B


このボトムアップのモデリングプロセスは、単一のビジネスアプリケーションから組織全体に至るまで、必要な実施ポイントを決定するために必要な柔軟性とモジュール性を提供します。セキュリティ・エンジニアは、どこから始めて(プロセス、ホスト、ネットワークなど)、どこで停止するかを決定します。そして、実施ポイントは、対応するセグメント境界内でホストされているデータとシステムの保護を提供する階層的な防御ラインを確立します。

ゲートウェイ統合

図 1-A のモデルでは、8 つの異なるネットワークセグメント境界の実施ポイント(LAN セグメントのホストベースのセキュリティソフトウェア実施ポイントを含まない)が描かれていますが、実装では通常、8 つのセキュリティゲートウェイアプライアンスは反映されません。セキュリティ、財政的、およびパフォーマンスの制約に応じて、複数の実施ポイントを、各サイト内の単一のマルチホーム・セキュリティ・ゲートウェイ・アプライアンスに統合することができます。図 1-C は、すべてのセグメント間の相互作用を制御するために使用される統合セキュリティ・ゲートウェイの簡単な構成を示しています。

セキュリティの仮想化

ゲートウェイの統合はコスト面で大きなメリットを得ることができますが、実施ポイントの統合にはいくつかのデメリットがあります。特に、より複雑なセキュリティ・ポリシーは、構成エラーのリスクの増加につながる可能性があります。例えば、2つの内部セグメント間のアクセスを許可する誤った設定のルールが、誤ってインバウンド・インターネット・アクセスを許可してしまう可能性があります。

図 1-C に示すモノリシック構成の代替として、仮想セキュリティゲートウェイを検討することができます(図 1-D)。このシナリオでは、単一のアプライアンスが複数の仮想システムをホストします。各システムは論理的にセキュリティ・ゲートウェイと同等であり、独立して管理することができます。

セキュリティ仮想化により、管理が簡素化されます。各仮想システムはセキュリティセグメントの実施ポイントに対応しており、そのセキュリティ制御は独立して展開して管理することができます。同時に、統一されたハードウェアプラットフォームを使用することで、所有コストを削減することができます。

サーバー仮想化(クラウド)

サーバ仮想化環境(付録-設計パターン:クラウドを参照)では、図A~Dに描かれているように、仮想セキュリティゲートウェイは仮想マシン(VM)を使用して実装することができます。クラウドインフラストラクチャは、基礎となる仮想化技術を提供し、VLANを作成してVMレベルの実施ポイントを介して接続することで、セグメント間のトラフィックがVMレベルの実施ポイントを介して流れることを保証します。同じ物理ホスト上の異なるVM間のトラフィックの調停は、ホスト上のVMで実行されている実施ポイントによって効率的に処理することができます。

実施はハイパーバイザー自体に統合することもでき、すべての情報フローが仲介され、実施ポイントの後ろに仮想マシンを配置するために仮想ネットワークを再設計する必要はありません。ハイパーバイザー レベルの実施ポイントは、仮想化プラットフォームが提供する API フックを使用して、ホストされた VM との間のすべてのネットワーク トラフィックを受信します。

さらに、サーバ仮想化環境は、仮想化サーバから高性能なカスタムセキュリティハードウェアにセキュリティ処理をオフロードするために、物理的な仮想化セキュリティゲートウェイ(図1-Dに示すように)を組み込むこともできます。

仮想LAN(VLAN)

VLANは、企業ネットワークをセグメント化するために使用される重要なネットワークメカニズムです。トランクインターフェースを使用してスイッチに接続されたセキュリティゲートウェイは、複数のVLANを介してネットワークトラフィックを分析し、転送することができます。この構成により、1つのセキュリティゲートウェイで数百のVLAN間のネットワークトラフィックを制御することができます。図1-Eでは、スイッチデバイスは、セキュリティゲートウェイを介してVLAN02からVLAN03に流れるすべてのネットワークフレームを転送するように構成され、ゲートウェイに実装された仮想化されたセグメント実施ポイントを介してセグメント間のトラフィックの調停を確実にします。

VLAN アーキテクチャをセグメント化するための主な欠点は、セグメント分離ポリシーを実施するためにネットワークスイッチに依存していることです。設定を誤ると、VLANホストが別のホストにクロスオーバーすることを可能にするVLANホッピング攻撃によって、スイッチがバイパスされる可能性があります。したがって、仮想分離とネットワーク分離の組み合わせを使用して、セグメント間分離の段階的なレベルを提供する必要があります。

ソフトウェア定義ネットワーキング (SDN)

従来のネットワークインフラストラクチャでは、ルータ、スイッチ、ファイアウォール、IPS などのネットワークおよびネットワークセキュリティ機能は、物理的なアプライアンスやデバイスとして実装されています。ネットワークの流れはネットワーク・トポロジーによって決定され、個々のネットワーク・デバイスは、パケットを目的地に移動させるための最良の方法をローカルで決定します。しかし、クラウドベースの仮想化されたサーバとネットワーク環境の出現により、複雑なネットワークの変更なしに新しいアプリケーションを素早くデプロイする能力は標準的な要件となりました。SDN はネットワーク制御がネットワークインフラストラクチャから切り離された新しいネットワークアーキテクチャです。

図 1-F のように SDP 実施層を SDN インフラストラクチャレイヤと統合することで、SDN スイッチは、適切なフローとサブフローを適切な SDP セグメント実施ポイントにオフロードするセキュリティの役割を持つ単純な実施ポイントとして登録されます。

下の図 1-G は SDP と SDN アーキテクチャ間の統合を示しています。SDP 管理層は SDN アプリケーション API (1) を使い、SDP と SDN 制御層 (2) の間でネットワークとセキュリティポリシーを調整することで、この統合をオーケストレーションします。ネットワークフローは SDP/SDN 制御層によってプログラムされ、中央の物理的または仮想的な SDP 実施ポイント(3)を通過するようになります。これにより、適切なフローとサブフローを適切なセグメントの実施ポイントにオフロードするというセキュリティの役割を持つ単純な施行ポイントとして SDN スイッチを参加させることで、すべてのセグメント間の相互作用が継続的に仲介されることが保証されます。

例えば、SDN スイッチは LAN セグメントと内部サーバ間のインタラクションを一つのセキュリティゲートウェイの実施ポイントを介して転送するように指示することができ、一方で DMZ とのインタラクションは拡張された保護を実装した別の実施ポイントを介して転送されるべきです。別の例として、分散型サービス拒否 (DDoS) トラフィックは一度識別されると合法的なトラフィックとは異なるルーティングが可能で、許可された相互作用が自由に流れることを可能にします。

セキュリティ処理をクラウドにオフロード

セキュリティ処理は、ネットワークおよびホストベースの実施ポイントから、プライベートおよびパブリッククラウド構成内の専用リソースにオフロードすることができます。ローカルで利用可能な情報に基づいてセキュリティの決定を行う代わりに、実施ポイントはクラウドに問い合わせを行うことができます。クラウドベースの実施ポイントは、SDP実施層の拡張機能になります。

クラウドへのオフロードには、次のようなメリットがあります。

  • セキュリティの決定が脅威指標などの複雑で変化の激しい情報に依存している場合、そのような情報を関連するすべての実施ポイントに配信することは、すぐに困難になります。オフロードにより、このようなデータを集約してクラウドで使用することができます。
  • セキュリティ・インシデント・イベント管理(SIEM)システムは、セキュリティ・イベント・ログを集中的に収集・分析することで、ビッグデータ・ストレージを提供し、遡及的なセキュリティ分析を行うことができます。危殆化の可能性のある兆候を強調し、承認された相互作用のためのグローバルなベースラインを生成することができます。ベースラインを使用して、行動の異常を示す実施ポイントを提供することができます。
  • 電子メールのようなストア・アンド・フォワードシステムでは、データコンテンツや添付ファイルをクラウドにアップロードして解析する際に発生する遅延は過度ではありません。実際、添付ファイルはサンドボックス環境で検査して、受信ホストに転送される前に悪意があるかどうかを判断することができます。
  • インターネットを介してクラウドベースのポータルに接続しているモバイル・ユーザは、地理的に近い場所にあるセキュリティ・サービスを受けることができるため、ネットワーク・トラフィックを中央の実施ポイントにルーティングする場合に比べて、より信頼性が高く、より迅速なセキュリティ処理が可能になります。

クラウドベースのセキュリティ管理は、セキュリティの課題を企業ネットワークからクラウドに移行させます。企業は、外部のクラウドプロバイダーから十分な保証と監視機能を得て、必要なセキュリティ管理が行われていることを確認する必要があります。さらに、クラウドとの間のすべての通信を認証し、保護するために、信頼できるチャネルを使用する必要があります。クラウドとネットワークの可用性プロファイルも、DDoS 攻撃の可能性を考慮して検討する必要があります。

クラウドベースのセキュリティ実施例は、付録A-設計パターン:モバイルに記載されています。

ステップ4  信頼できるチャンネル

セグメント実施ポイントは、許可されていないセグメント間の相互作用を防止します。ただし、許可された相互作用も保護する必要があります。2 つのネットワーク・セグメントが同居する要素を持つ場合、セキュリティ・ゲートウェイは、セグメント間の相互作用を仲介するために、両方のセグメントに物理的に接続することができます。両者が物理的に分離されている場合、そのような相互作用は、ネットワーク・インフラストラクチャを通過する間、安全に保護されなければなりません。

セグメント間の相互作用が、信頼されたネットワーク内の階層セグメントによって確立されている場合、階層セグメントは、転送中のデータの安全性を確保する責任があります。しかし、ネットワークが2つのセグメントのセキュリティプロファイルに対して「信頼されていない」場合、攻撃者は2つのセグメント間を流れるデータにアクセスしたり、変更したりする可能性があります。そのため、セグメント間で信頼できるチャネルを確立し、セグメント間のやり取りには暗号化を使用する必要があります。このようなチャネルは、そのチャネルを通過するデータへの不正アクセスを防ぐと同時に、情報変更の試みを検出してブロックすることができます。

次の例では、異なるサイトにある 2 つの部門が、信頼されたチャネルを介して相互作用する様子を示しています。この例では、内部ユーザーは内部サーバーに直接アクセスすることができます。


Stuxnetのケーススタディ

セグメンテーションによってコンピュータワームの拡散を防ぐ方法

2010年6月、イランの核計画で使用されているシーメンスの産業用監視制御・データ収集(SCADA)システムを標的とした新たなネットワークワームが発見されました。公的な情報源によると、このワームは核濃縮装置にダメージを与え、プログラムの目的に大きな影響を与えました。このケーススタディでは、このワームの特徴を分析し、ワームの成功と効果的でないセグメンテーションとの間に直接的な関係があることを示しています。一般的に「Stuxnet」と呼ばれるこのワームは、以下のような複合的な脅威でした。(1) USB フラッシュドライブを介して Windows ベースのワークステーションに感染し、(2) ネットワークおよびリムーバブルメディア攻撃のベクターに感染し、(3) 感染したホストがコマンド制御 (C&C) サーバーに接続して、さらなるコマンドを受信して情報を抽出し、(4) SCADA 制御ソフトウェアを実行しているホストを特定し、プログラマブルロジックコントローラ (PLC) を再プログラムして、ウラン濃縮に使用される遠心分離機にダメージを与えるという複合的な脅威でした。


Stuxnet

図1-I


Stuxnetは自身を隠し、撲滅活動を複雑にするために複数の欺瞞技術を使用していました。このワームは何年にもわたって隠蔽されたままで、既知の脆弱性と未知の脆弱性の両方を介して拡散しました。最初は信頼できる内部のワークステーションに注入されたこのワームは、横方向に拡散し、イラン国内だけでも6万台以上のホストに感染し、ナタンツ原子力施設の遠心分離機約1,000台に損害を与えたと報告されています。ワームの攻撃的な再感染行動のため、復旧には数ヶ月間の集中的な努力が必要でした。

以下のセグメント境界の保護により、攻撃を混乱させることができました。

アクセス制御

  1. アトミック・セグメント境界でマルウェアが USB インターフェイスを介してホストに侵入するのをブロックする必要がありました。エンドポイントのホストと LAN セグメントの境界を制御することで、感染したホスト間の P2P 接続の確立を防ぐことができました。検出された場合、感染したホストの送信ネットワーク接続を許可されたネットワークサービスのみに制限することで、感染を食い止めることができました。
  2. ミッションクリティカルなコンポーネントであるオペレータの PC には、ネットワーク経由でアクセスできないようにすべきではありませんでした。セグメント境界ファイアウォールにより、これらの PC へのアクセスを防ぐことができました。

脅威の防止

3. LAN セグメントと WAN の境界にある IPS が感染したホストを検出し、既知の脆弱性を介して他のセグメントにマルウェアが拡散するのを防ぐことができました。ワームが検出され、解析された後、IPSは動的に分散されたカスタムIPSシグネチャを適用し、これまで知られていなかった脆弱性の悪用を防ぐことで、ワームを完全に封じ込めることができました。

4. LANからインターネット上のC&Cサーバへのアウトバウンドアクセスをサイト境界および組織境界で検知し、ブロックすることができました。

Stuxnet ワームが多数の標的への感染に成功したことは、原子力制御用の PLC にアクセスするミッションクリティカルなオペレータ PC など、セキュリティの特性が異なるエンティティ間でのセキュリティ制御メカニズムが不十分であったことを示しています。

🔶実施層の概要

SDP アーキテクチャの実施層は、ソフトウェアで定義された保護を実行するためのプラットフォームとして機能する実施ポイントで構成されます。実施ポイントは、ネットワークセキュリティゲートウェイ、ホストベースのソフトウェア、モバイルデバイスアプリケーション、またはクラウド上の仮想マシンとして実装することができます。

実施層の背後にある主な原理はセグメンテーションです。セグメンテーションは、ネットワーク内での脅威の増殖を防ぐため、攻撃を受けている組織の生存に不可欠です。セグメンテーションの実装は、ネットワーク内の「アトミック」セグメントを定義することから始まります。各アトミック・セグメントの境界には、定義された保護ロジックを実施するための実施ポイントが導入されます。アトミック・セグメントをグループ化して、モジュール式の保護を可能にします。最後に、信頼されたチャネルを確立して、さまざまなネットワークセグメント間の相互作用とデータフローを保護します。

このセグメンテーション手法はゲートウェイの統合を促進し、従来の物理的な構成から、ネットワークとセキュリティの仮想化、仮想LAN、SDNインフラを使用した最新の動的な構成まで、多くのネットワークインフラ構成に適用することができます。

SDP Enforcement Layerは、最も複雑なAdvanced Persistent Threats (APT)からのネットワーク感染に対する効果的な防御として、このセグメンテーションアプローチに依存しています。

02 制御層

制御層は、SDP アーキテクチャの中核をなしています。制御層の役割は、ソフトウェアで定義された保護を生成し、それを適切な実施層の実施ポイントに展開して、高性能な専用ハードウェアを使用して実装するか、ネットワーク、モバイルデバイス、クラウド上のホストベースのソフトウェアとして実装するかにかかわらず、実行することです。

保護カテゴリには、脅威防止、アクセス制御、データ保護などがあります。これらの戦略は、セキュリティポリシーのルールが描かれる基礎となる知識領域で異なります。

  • 「脅威防止」は、脅威と脅威行動の理解に基づいています。「脅威防止」は、コミュニティから受信した協調的なリアルタイムの脅威インテリジェンスを基にしています。
  • アクセス制御は、管理層によって設定された、企業内のユーザーと資産の間で許可された相互作用のセキュリティポリシーモデルを強制します。
  • データ保護は、動作や相互作用よりもデータの分類に焦点を当てています。管理層は、組織内のデータフローポリシーを決定します。

ソフトウェアで定義された保護機能は、新しい脅威や動的な脅威、変化する企業のネットワーク構成に対応するために必要なレベルの柔軟性を提供します。実施層は、企業全体の実施ポイントで保護を実行できる堅牢なプラットフォームを提供します。保護はソフトウェアによって制御されるため、新しい脅威や攻撃方法が発見された場合や、新しい技術が組織に導入された場合でも、実施ポイントに配置された基盤となるハードウェアを交換する必要はありません。

プロテクションは、何千もの勧告や勧告のレビューを手動でフォローアップすることなく、脅威の状況に自動的に適応しなければなりません。これは、人間の意思決定を利用するために必要な場合にのみ管理層と対話する自動化された脅威防止コントロールを使用することで実現されます(例えば、脅威の指標が脅威や攻撃の特定についての信頼性が低い場合など)。

脅威の防止

脅威防止保護は攻撃者をブロックし、脆弱性の悪用や悪質なペイロードの配信を拒否します。脅威防止のポリシーはシンプルです。「すべての脅威は防ぐべきである 」ということです。このポリシーは、個々の企業がカスタマイズする必要はほとんどなく、むしろ汎用的なものであり、すべての組織に適用されるべきものです。

脅威防御は、感染前と感染後の 2 つのグループに分けることができます。感染前防御は、内部アプリケーションやプロトコルの脆弱性を悪用したり、許可されたアプリケーションへのサービスを拒否しようとする脅威のプロアクティブな検出と防御を提供します。感染後防御は、脅威が 1 つ以上のネットワーク・エンティティを妨害することに成功した後に、脅威を検出、封じ込め、解除する機敏な防御を提供します。これらの保護機能は、マルウェアの拡散を抑制し、C&Cサーバへのボット接続をブロックします。

場合によっては、単一のセキュリティ上の知見だけでは、脅威の存在に対する信頼性が低いことがあります。制御層の脅威防御コンポーネントは、シグネチャ、レピュテーション、ビヘイビア、マルウェアのエミュレーション、人間による検証など、複数のエンジンからの知見を相関させて、より高いレベルの信頼性を得ることができます。さらに、制御層は、外部のリソースを利用して、有意義なセキュリティ保護を生成することができます。

脅威防止対策を効果的に行うためには、広範で信頼性の高い脅威インテリジェンスが必要です。企業は、人手による介入を必要とせずに、着実に脅威インテリジェンスがセキュリティ環境に流入してくることを期待しなければなりません。

脅威インテリジェンス

脅威インテリジェンスは、外部および内部の脅威データの情報源を使用して取得します。理想的には、これらの情報源には、CERT(Computer Emergency Readiness Teams)やCSIRT(Computer Security Incident Response Teams)などのパブリックセキュリティインテリジェンス、各種セキュリティアナリスト、セキュリティ製品ベンダー、セキュリティコミュニティ内のその他の組織が含まれていることが望ましいです。このような外部ソースに加えて、マルウェアの調査、サンドボックス技術、実施ポイントから収集したセキュリティイベントのデータ分析などを通じて、脅威インテリジェンスが企業内で生成されます。

脅威インテリジェンスでは、脅威のエージェント、その意図するターゲット、攻撃キャンペーン、および既知の戦術、技術、および手順(TTP)が記述されています。脅威インテリジェンスを使用して、脅威防止対策は、セキュリティのビッグデータを指標と攻撃の説明の形で実行可能なインテリジェンスに変換します。これらの指標は、実施層が実施の決定を実行するためのロジックであり、組織は攻撃が展開される前に攻撃を予測し、ネットワーク内で検出された場合にその重要性を認識することができます。

脅威インテリジェンス分析プロセスでは、生のインテリジェンスを使用して、実用的なインテリジェンス、すなわち脅威の検出と防止に使用できる脅威指標を生成します。このような実用的なインテリジェンスは、以下の質問に答えます。

  • どのような悪意のある動作を探すべきか? 例としては、ネットワークアドレス、ドメイン名解決要求、URL、システムコール、ファイルハッシュなどがあります。
  • どこを探すべきか? ネットワーク上、電子メールや文書の内部、ディスク上、メモリ内などです。
  • このイベントまたは一連のイベントの重要性は? メタデータは、インジケータの信頼度、対応する攻撃の深刻度などの追加情報を提供します。
  • この攻撃からどのように身を守るか? 例:攻撃をネットワーク上でブロックすべきか、ホスト上でブロックすべきか。この脆弱性に対するパッチはありますか?

以下の例は、脅威インテリジェンス分析プロセスを示しています。

  • 生の情報を集める: 攻撃者が金融部門のターゲットに対してキャンペーンを展開しているとの通知を受けました。攻撃者の観測されたTTPは、様々なチャネル(電子メール、USBディスク、改ざんされたウェブサイトなど)を使用して、文書リーダーの脆弱性を悪用したマルウェアを含む文書を標的とするユーザーに配信することです。不審なユーザがマルウェアを起動すると、C&Cサーバに接続し、リモートアクセスツール(RAT)を使用して攻撃者に内部ネットワークへのアクセスを提供します。
  • 実用的なインテリジェンスを生成する:実施層のサンドボックスはドキュメントを実行し、ローカルファイルシステム上にファイル(RAT)をドロップしようとするマルウェアが含まれていることを識別します。サンドボックスは、ドキュメントとファイルの固有のハッシュを計算し、これらを実行可能な指標として制御層に提供します。これらの指標に基づいて、制御層は攻撃に対する防御策を生成し、企業の実施ポイントに自動的に配布します。指標はコミュニティ内の他の組織とも共有されます。
  • 感染後のダメージを含む:記録されたネットワークデータとホストのファイルシステムのその後のビッグデータ分析により、ドキュメントやファイルのハッシュとさらに一致する結果が得られる可能性があります。これにより、感染したホストをさらに特定し、ネットワーク上でのアクセス権を制限することで、これらのホストを封じ込めるための保護機能を自動的または手動で生成することができます。
  • セキュリティイベントを分析する:ログデータをさらに分析すると、疑わしいホストと特定のアウトバウンド接続の間に統計的な相関関係があることがわかるかもしれません。ターゲットとなるホストは、潜在的なC&Cサーバや攻撃者のドロップゾーンとして特定され、対応するIPアドレスやURLは、さらなるボット通信をブロックするための指標として使用できます。

脅威指標は、攻撃から攻撃への変異に比較的コストがかかる脅威行動の側面を特定する場合に特に効果的です。例えば、攻撃のソースアドレスが攻撃者によって偽装されており、接続から接続へとランダムに変化する可能性がある場合、攻撃のソースアドレスをブロックしても何のメリットもありません。しかし、ボットのC&Cサーバへの接続は、前のサーバがブロックされるたびに攻撃者が新しいC&Cサーバをセットアップする必要があるため、変異しにくくなります。

高度な攻撃では、より複雑な脅威指標のマッチングが必要になります。例えば、最新のマルウェアはC&CサーバのURLをランダムに生成し、多数の潜在的なサーバにアクセスできるようにしているかもしれません。このアルゴリズムを分析すると、攻撃で使用されるすべてのURLを識別できる対応する複雑な指標が得られます。

脅威指標の生成

異常なソースや悪意のあるソースを検出することで、企業内に脅威指標を生成することもできます。このような内部指標のソースには、以下のようなものがあります。

  • サンドボックス化された環境で実行される実施層のセキュリティ制御ロジック。マルウェアを含む可能性のあるドキュメントやアプリケーションは、検出された不正行為に対して脅威指標を生成します。
  • 実施層から受信したセキュリティイベントを分析し、異常や攻撃を特定するのに役立ちます。これらの脅威が認識されると、脅威指標が生成され、さらなる攻撃をブロックし、感染したエンティティを封じ込めることができます。
  • セキュリティアナリストによるネットワークとホストのフォレンジック分析では、脅威指標を生成し、それを制御層に送り、実施ポイントに配信することができます。
  • 内部ネットワークに侵入したと思わせるために攻撃者を罠にかけることができるハニーポットを使用し、防御者が TTP を分析して適切な脅威指標を生成して攻撃をブロックするための時間を稼ぐことができます。

ゼロデイプロテクション

脅威プレイヤーは、脆弱性(システムの潜在的なセキュリティ上の欠陥)を悪用して企業資産を標的とします。先に説明したように、脅威防止対策では、脅威の行動を検知して防止することで脅威に対抗します。しかし、システムの脆弱性は、セキュリティ上の欠陥がシステムの所有者に知られる前に、攻撃者によって発見されることがあります。これらは「ゼロデイ」脆弱性と呼ばれています。定義上、ゼロデイ攻撃は、事前の脅威インテリジェンスが利用できないため、直接対抗することができません。ゼロデイ攻撃を軽減するために、以下の防御戦略を使用することができます。

  • サンドボックス化 – 対象となるシステムをエミュレートした環境でドキュメントやアプリケーションを実行することができます。予期せぬ動作が検出された場合、実行が終了し、悪意のあるドキュメントやアプリケーションがネットワークに侵入したり、標的となるホストに到達したりするのをブロックします。
  • 攻撃面の最小化 – 最小特権の原則は、システムコンポーネントの欠陥を隠すことができるため、ゼロデイ攻撃に対して非常に効果的です。最小特権の制御は、これを防ぐことができます。
    • ネットワークポートやサービスへのアクセス、ネットワークプロトコルを制限することで、一般的ではない(そのためテストが甘いことが多い)機能がブロックされるようにします。
    • データオブジェクトや未知のプログラムからのコード実行により、アプリケーションがシステムの状態を変更することを制限します。
    • 通信を必要としないホスト間のネットワーク相互作用(例: P2P ネットワーキング)
  • 挙動制御と異常検出 – システムを「通常の」挙動に制限することで、マルウェアがシステムコンポーネントを正常に破壊してもブロックすることができます。例えば、異常なネットワークスキャンを実行するホストは、次のような封じ込め制御を使用して制限することができます。
  • Man in the loop – マルウェアや脅威は、機微な操作を人間が確認したり、承認したりすることで倒すことができます。これは、異常な行動のみが介入を必要とするように、行動のベースライン化と組み合わせることができます。
  • 回顧的分析 – 新たに検出された脅威や脆弱性について脅威インテリジェンスを受信した場合、過去のシステムイベントログをレビューして、悪意のある活動や危殆化の指標を特定することができます。

上記に加えて、脆弱性のあるアプリケーションへのタイムリーなパッチ適用と、脅威インテリジェンスに基づいた IPS 制御の使用は、既知の脆弱性にさらされる機会を減らし、脆弱性が発見された後、可能な限り早く悪用を阻止することができます。この方法はゼロデイの悪用を防ぐものではありませんが、高度な攻撃の大部分は、既知ではあるがパッチが適用されていない脆弱性を利用していることに注意する必要があります。

アクセス制御

アクセス制御は、伝統的に企業のセキュリティポリシー実施の中核をなしており、今日でもあらゆるセキュリティアーキテクチャの基礎となっています。

アクセス制御は、企業ネットワーク内のユーザーとデータ間の相互作用を定義することで、ビジネスプロセスを可能にします。ビジネスをサポートするために必要な最低限のレベルを適用し、”Least Privilege “というセキュリティ原則を適用します。明示的に許可されていない相互作用は、許可されていないとみなされ、ブロックされるべきです。

アクセス制御の保護は、企業固有のビジネスルール、資産、ユーザー、役割、およびアプリケーションを記述するリポジトリに依存しており、これらの同じ資産、ユーザー、およびアプリケーション間で許可された相互作用のセットのセキュリティポリシーを定義します。

例えば、アクセス制御では、ユーザーが機密性の高い企業サービスへのアクセスを許可されているかどうかを判断し、ユーザーの所在地、ホストの状態、時間帯などに基づいて認証を行うことができます。

これらの保護制御は、インバウンドとアウトバウンドの制御セットに分けることができます。インバウンドでは、各セグメントは外部からの攻撃から資産を保護する必要があります。最小特権の厳格な実施により、攻撃対象を最小限に抑えることができます。例えば、セグメント内のアプリケーションにセキュリティ上の欠陥があるかもしれませんが、アプリケーションへのアクセスはアクセス制御ポリシーによって拒否されているため、その脆弱性を悪用することはできません。また、最小特権の原則は、保護されたセグメント内のクライアントには、直接または間接的にビジネスをサポートする 外部サービスへのアクセスのみを許可すべきであることを規定しています。したがって、この原則を実施するためには、アウトバウンド制御が必要となります。

トラフィックの分析と制御は、コンテキストに基づいて適応的に行われます。例えば、インターネットトラフィックの場合、制御層はクラウドデータベースを参照して最新の認可されたアプリケーションやプロトコルを確認し、内部トラフィックの場合は組織で使用されている適切なアプリケーションやプロトコルの使用を承認することができます。

さらに、制御層は他の IT システムに実装されているネットワークの変更や定義を認識しています。例としては、ユーザーリポジトリの変更、新しい仮想マシンへのセキュリティの自動適用、ドメインネームサーバ (DNS) で定義された新しいホストへのアクセスの許可などがあります。SDN の場合、コントロール層は適切な施行ポイントを介してネットワークトラフィックの流れを指示し、それによってネットワークを企業のセグメンテーションモデルとセキュリティポリシーに適合するように整形します。

データ保護

情報を適切に保護するためには、保護は、データの安静時(保管時)と動作時に従わなければなりません。不正なユーザーへのアクセスを拒否するために、組織内外のデータを保護するために暗号化された制御が適用されます。企業情報を分類してデータを分類することで、データの流れを調べ、データの損失を特定して防止することができます。

データ保護は、データの分類と電子透かしのセキュリティポリシーに依存します。データは、その所有権、属性、コンテンツに基づいて分類されます。データ署名は、データの機密性に基づいて作成され、任意のホストや場所から不正なユーザーへのデータ漏洩を防ぐために使用されます。

さらに、データの暗号化やデジタル署名などの暗号化メカニズムをストレージ内のデータに適用して、不正アクセスや変更を防ぐ必要があります。これらのメカニズムは、データが管理されているシステムの外にコピーされた場合でも、永続的な保護を提供します。

暗号化は、モバイルデバイス、リムーバブルメディア上のストレージ、共有ストレージ環境、クラウドコンピューティングで特に価値があります。鍵と暗号化されたデータへのアクセスを効果的に管理するためには、ローカルまたはクラウドベースの鍵管理インフラストラクチャが必要です。また、暗号化は、鍵の失効を通じた安全なデータ廃棄を確保するためにも使用できます。

保護制御の選択のためのリスクに基づくアプローチ

異なる実施ポイントでは、異なる保護が必要となります。保護タイプの選択は、セグメントの資産、ユーザの権限、および脅威環境に依存します。また、システムの性能や運用上の制約も考慮する必要があります。

制御層の役割は、アクセス制御とデータ保護ポリシーを実施し、識別された脅威に対抗するために、各セグメント境界実施ポイントで実行される適切なセキュリティ制御ロジックを選択することです。

セキュリティ対策を選択する最初のステップは、各セグメントまたはセグメントのグループごとにリスク分析を行うことです。リスクとは、組織の業務や資産に対するセキュリティ事故の影響度と発生の可能性のレベルと定義されています。このようなセキュリティ事象には、セキュリティポリシー違反、脅威の顕在化、不適切なデータフローなどがあります。リスクを理解することで、セキュリティ対策の優先順位付けされたフレームワークが得られます。

セグメントの境界を横切る相互作用ごとに、異なるリスクカテゴリーが考慮されます。リスクのレベルは、発生、成功の可能性、および潜在的な損害に基づいてコード化することができます。例えば、アウトバウンドHTTPリクエストは、サンプルのリスク分類スキームに関連して分析することができます。

リスクリスクの説明アウトバウンド HTTP リクエストの分析
インサイダー認可されたユーザーが、セキュリティポリシーに違反するインタラクションを実行した場合セグメント内のユーザーは外部サービスへのアクセスを許可されているか?
外部からの攻撃外部から資産やサービスに不正にアクセスしようとする者外部サービスが攻撃者になりすまされる可能性はあるか?
データアクセス攻撃者がネットワークやストレージのインフラストラクチャにアクセスすることで、トランジット中のデータや休止中のデータを読み取ったり、変更したりする相互作用のためのネットワーク・パスは傍受されやすいか?
データ漏洩機密データが不正なユーザーに送信されたり、リムーバブルメディアに書き込まれたりする不正な場所に大量のデータがアップロードされる可能性はあるか?
悪用攻撃者がプロトコル違反を行い、システム障害を引き起こすプロトコル違反により、セグメント内でクライアントの悪用やマルウェアのダウンロードが行われる可能性は?
マルウェアネットワーク上またはリムーバブルI/Oデバイスを介して配信される悪意のあるコードは、ビジネス資産に悪影響を与えるリクエストがマルウェアの動作を示す可能性はあるか(例:C&Cサーバへの接続やドロップゾーン)?
サービスの拒否インタラクションが処理、ストレージ、またはネットワークの容量を過剰に消費し、許可されたインタラクションのサービスを拒否するリクエストの速度、持続時間、帯域幅が、許可された相互作用のサービスレベルに影響を与える可能性があるか?

リスクは、上述のように高レベルで考慮されることもあれば、潜在的な攻撃方法に関連して詳細に考慮されることもあります。一連のセキュリティ対策は、それぞれのリスクを軽減し、企業が許容できるレベルまでエクスポージャーを減らすために定義されています。

以下の図 2-C に、リスクと保護のマッピングを簡略化した図を示します。各行には、高レベルのリスクまたは詳細な攻撃方法(例:リンク先のメールとして配信されるマルウェア)が記述されており、各列には、緩和する保護パッケージ(例:感染前の脅威防止)または特定の保護(例:URL に対するレピュテーションベースのフィルタリング)が識別されています。

保護とリスクをマッピングすることは有効です。

  • すべてのリスクが十分に軽減されていることを確認する。
  • 複数の実施ポイントを通過する相互作用を考慮した場合に、どの実施ポイントがどのセキュリティ制御を適用すべきかを決定する
  • 残存リスクを特定し、所定の制御が効果的でない、高すぎる、または過剰なリソースを必要とすることが判明した場合に、セキュリティ制御を調整する

「ステップ2-セグメントグループ化」で説明したように、階層的グループ化は、一つの相互作用が複数の実施ポイントを横断する可能性があることを意味しています。つまり、対応するリスクを軽減するために、相互作用の経路に沿って複数のポイントで制御を適用する必要があります。例えば、既知のマルウェアのシグネチャと受信メールメッセージを一致させるマルウェア対策は、セキュリティゲートウェイの実施ポイントで、メールリレーをホストするDMZ、メールリレー自体、内部メールサーバ、またはクライアントホストに適用することができます。

セキュリティ対策とリスクのマッピング 図2-C

リスクアクセス制御脅威の防止データ保護
インバウンドアウトバウンド
インサイダー
外部からの攻撃
データアクセス
データ漏洩
悪用
マルウェア
サービスの拒否

制御層は、相互作用に関連するリスクを相互作用経路全体に沿って制御することができるように、制御を実施ポイントに提供します。以下に、必要なコントロールを適用する場所についての一般的な推奨事項を示します。

  • インバウンドアクセス制御と感染前の脅威防止のセキュリティ制御(ファイアウォール、IPS、ユーザー識別など)は、可能な限り資産に近いところで適用する必要があります。これにより、セキュリティバイパスのリスクを低減し、特定の資産に合わせたより詳細な制御をサポートします。
  • 攻撃者のモチベーション、攻撃の機会、リスクが高いため、組織の境界でサービス拒否対策を実施する必要があります。
  • 感染前のマルウェア対策は、通常、外部のエンティティによって生成されるため、組織の境界に実装する必要があります。さらに、マルウェア対策は通常、エンドポイントホストやマルウェアを含む可能性のあるドキュメントを処理するモバイルデバイスに実装されています。実施ポイントの選択は、パフォーマンスの問題とデータの暗号化を考慮に入れる必要があります(例:暗号化されたメールメッセージは、マルウェアのスキャンを行う前に復号化する必要があります)。
  • 外部アプリケーションへのアクセスを制限するための感染後の脅威防止対策は、通常、組織の境界で行われます。リスクの高いターゲットやアプリケーションを特定するために、協調的なインテリジェンスが使用されます。また、脅威の封じ込め機能を提供するために、エンドポイントホスト上でアウトバウンドネットワークアクセスを制御することもあります。
  • ネットワークレベルのデータ損失防止対策は、分類スキームに沿って実施されています。内部情報は組織外へのデータ流出時に管理し、部門別データは部門セグメントの境界で管理すべきです。さらに、データアクセスの脅威から保護するために、エンドポイントホスト、モバイルデバイス、クラウド環境に暗号化制御をインストールする必要があります。

実施ポイントと制御の実施ポイントへのマッピングのさらなる説明については、付録に記載されているネットワークセグメンテーション設計パターンを参照してください。

図 2-D は、前章で説明したサンプルサイトのサンプル実装を示しており、異なる実施ポイントで異なるセキュリティ制御が適用されています。セグメント境界制御は、2 つの物理アプライアンスに統合されています。1 つ目の物理アプライアンスは、インターネットと DMZ 間、および DMZ と内部ネットワーク間のアクセスを制御します。2 番目のセキュリティ・ゲートウェイは、MPLS ベースの WAN、LAN、および内部、センシティブ、および部門別サーバ・セグメントの制御を提供する 5 つの仮想システムを実装しています。

この例では、内部サーバーセグメントのホストには、ファイアウォール、マルウェア対策、フルディスク暗号化、集中ログなどのセキュリティソフトウェア制御が含まれています。モバイルデバイスには、ファイアウォール、暗号化、ロギング、VPN の制御が含まれています。モバイルデバイスをインターネット経由で企業に接続するために、VPNによる信頼されたチャネルが使用されます(付録 – 設計パターン:モバイルを参照してください)。

インターネットに面したセキュリティ・ゲートウェイは、一般にアクセス可能なインターネットと組織の境界セキュリティ・プロファイルの間の差が最も重要であるため、最も広範な制御セットを実装しています。この堅牢な設計には、(1)インバウンドアクセスコントロール:ファイアウォール、IPS、DDoS対策、(2)感染前の脅威防止:マルウェア対策、(3)感染後の脅威防止:ボット対策、(4)アウトバウンドアクセスコントロール:アプリケーション制御とURLフィルタリング、(5) データ保護:データ損失防止(DLP)とVPN、が含まれています。内部サーバの場合、セキュリティプロファイルの差分が少ないため、仮想システムにはインバウンドアクセス制御と脅威対策(ファイアウォールとIPS)のみを配置しています。

この例のすべての実施ポイントは、広帯域監視のためのイベントロギングも実装しています。

RSAのケーススタディ

高度な持続的脅威(APT)攻撃の解剖学

2011年3月17日、コンピュータ・セキュリティ・ベンダーのRSAは、同社のネットワークがAPTを通じてハッキングされ、ハッカーがRSAのSecurID認証トークンに関連する機密データを盗んだと発表しました。2011年6月までに、顧客からの攻撃が何度か成功した後、RSAは4,000万個のSecurIDトークンを現場で交換することを余儀なくされました。この攻撃により、RSAは数百万ドルの損害を被り、評判を大きく落としました。

攻撃の順序は以下の通りでした。(1) 2つの異なる標的型フィッシングメールが2つの小グループの従業員に送信された。(2) 1人の従業員が騙されてメールを開いてしまった。メッセージには、エクセルのスプレッドシートに添付されたAdobe Flashのゼロデイエクスプロイトが含まれており、Poison Ivyの亜種であるリモートアクセスツール(RAT)がインストールされていた。(3) 攻撃者はRSAネットワーク内を横方向に移動し、特権アクセスを得るまでユーザーの資格情報を盗み出した。(4) RSA SecurIDデータが盗まれ、攻撃者が後で取り出せるようにドロップゾーンに抽出されていた。

図2-Eと2-Fは、このケーススタディを使用して、セキュリティ制御の選択がマルチベクター攻撃にどのように対抗できるかを示しています。

RSAセキュリティチームは、脅威インテリジェンスと分析のコントロールを実装し、攻撃が進行中であっても検知することができましたが、ネットワーク内に侵入した攻撃者が目的を達成するのを阻止するための適切な予防的コントロールを欠いていました。この攻撃では、侵入のキルチェーンは一連の相互作用に対応していました。十分にセグメント化された企業では、これらの相互作用は、インターネットからDMZへ、DMZから内部サーバセグメントへ、内部サーバセグメントからアクセスネットワークへなど、複数のセグメントの境界や実施ポイントを横断します。これらの実施ポイントはそれぞれ、異なるセキュリティ制御ロジックタイプを組み合わせて攻撃を検出し、ブロックする機会を表しています。

RSA 攻撃は、侵入のキルチェーンに沿ったいくつかのポイントで破壊できたでしょう。

  • 感染前の脅威防止 – 電子メールの添付ファイルは隔離され、組織に脅威をもたらさないことを確認するためにテストできたでしょう。
  • 感染後の脅威対策 – Poison Ivy RATはよく知られた悪意のあるアプリケーションで、そのC&Cサーバへの接続をブロックするべきでした。
  • インバウンドアクセスコントロール – 感染したエンドポイントはRSAの「王冠の宝石」にアクセスできないようにブロックされるべきでした。
  • アウトバウンドアクセスコントロール – 組織の境界でデータ損失防止のセキュリティコントロールを使用することで、データの流出がブロックできたでしょう。
  • データ保護 – 機密情報は暗号化された形式で保存されるべきでした。

🔶制御層の概要

SDP アーキテクチャ制御層の役割は、保護機能を生成して実施層に展開することです。これらの保護には、脅威防止、アクセス制御、およびデータ保護が含まれます。

これらの保護制御を各セグメントとその資産に関連するリスクに体系的にマッピングすることで、企業は APT を含むあらゆるタイプの攻撃に対して堅牢な多層防御を実装することができます。

適切な保護を開発するために、制御層は、組織とその情報システムに関する知識(アクセス制御)、脅威に関する知識(脅威防止)、データ資産とその分類に関する知識(データ保護)を含むデータのリポジトリに依存しています。

最後に、今日の企業にとっては、各セグメントのリスク分析を行い、評価されたリスクを関連するセキュリティ対策にマッピングし、相互作用パスを分析して、各実施ポイントでの保護範囲を最大化することも重要です。

03 管理層

管理層は、セキュリティと企業のビジネスプロセスを統合することで、アーキテクチャがその役割を果たすことを可能にします。

企業のネットワークは頻繁に変化します。これは特に仮想化されたデータセンターやサービス指向アーキテクチャ (SOA) に当てはまります。アプリケーションがホストからホストへ、仮想ホストが物理サーバから別のサーバへと移動し、SDN や他の API を介してネットワークが動的に再構成されます。モバイルユーザとクラウドサービスは企業ネットワークの範囲を広げます。これらの頻繁で速いペースでの変化は、従来はネットワークアドレスやサービスの機能としてネットワークアクセスコントロールを管理する必要があったセキュリティ管理者に多大な負担をかけています。

さらに、組織内外の敵対的な脅威環境が増加しているため、管理者は、ユーザー ID、役割の割り当て、ホストのコンプライアンス ステータス、データ ID、アプリケーション ID、リクエスト パラメータなどの追加属性を考慮に入れた、より詳細な最小特権ポリシーを管理する必要があります。

ネットワークの複雑さときめ細かなポリシーの要件により、セキュリティ管理者は、急速に進化するビジネスプロセスに追いつくことができなくなっています。SDP管理層は、以下のようなフレームワークを提供することで、この課題に対処します。

  • モジュール型 – セキュリティポリシーの管理は、セキュリティセグメントの境界と保護タイプに従い、各管理ユーザーにシンプルなポリシーサブセットを提供します。
  • オープン – 制御層を企業システムと同期させ、管理者の作業負荷を軽減し、ネットワーク内のセキュリティポリシーの一貫性を確保するための自動化をサポートするためにAPIを使用しています。
  • レジリエンス – 企業の可視化により、サイバー攻撃を検知、阻止、撃退し、追跡調査や復旧、コラボレーションをサポートすることで、サービスレベルを維持しながら攻撃を「撃退」することが可能になります。

モジュール化

大企業における企業のセキュリティポリシーは非常に複雑になっています。セキュリティポリシーのルールベースには、通常、何千ものルールが含まれています。さらに悪いことに、多くの組織では複数のセキュリティ管理ツールが使用されており、それぞれが企業構成のサブセットのみを狭く表示しています。複雑さとトンネルビジョンの組み合わせは、サイロ化された管理手法につながります。

統合コンソールにより、管理者は、ネットワーク、ホスト、アプリケーション、およびデータを統合した方法でセキュリティポリシーを定義することができます。ポリシーのモジュール化により、管理者は、セキュリティポリシールールを独立したモジュールに分離することで、モノリシックなルールベースをシンプルで再利用可能な管理可能なコンポーネントに分解し、各モジュールが全体のポリシーの単純な側面に関係するようにすることができます。管理層は、異なるポリシーモジュールを統合して、制御層にプロビジョニングされた完全なポリシーを作成します。

モジュラーポリシーの目標を達成するためには、セキュリティポリシーは、実施層で定義された論理的なセグメントの境界に従う必要があります。各セグメントとその必要な相互作用に焦点を当てることで、ポリシーの定義が大幅に簡素化されます。

モジュール化により、組織の課題に対処するために、異なるチームが同時に作業することで、セキュリ ティ管理タスクを分散させることが容易になります。各管理者は、自分の責任範囲に関連する全体的なセキュリティポリシーの単純なサブセットにさらされます。非常に大規模な組織に対応するためには、管理層は、複数の管理者が同時にセキュリティポリシー管理プロセスに参加し、セキュリティポリシーの同時変更を可能にし、必要に応じてマージ機能を提供することをサポートする必要があります。

ポリシーモジュールは、異なる保護タイプを考慮して、レイヤーとサブレイヤーで定義されます。別々のレイヤでは、ネットワークフロー、データフロー、適用される規制の遵守などを扱うことができます。グローバルポリシーは、より詳細な下位ポリシーによって上書きすることができます(ただし、違反することはできません)。管理層は、ポリシーの継承とポリシーモジュール間の競合解決に対処するためのフレームワークを定義します。

図3-Aの例では、内部サーバーセグメントはデータベースサーバーをホストし、データベースにアクセスするために使用されるWebサーバーはDMZセグメントでホストされています。データセンターのネットワーク管理者は、内部ネットワーク上で特定のプロトコルを許可するグローバル・ネットワーク・セキュリティ・ポリシー・レイヤー(1)を定義することができます。認可されたWebアプリケーションを定義するサブレイヤはDMZ管理者が管理することができます(2)。一方、内部サーバの管理者はセグメントからの流出を認可されたデータオブジェクトを定義する独立したレイヤを管理します(3)。

管理層は、管理者のアクションと管理層の自動化スクリプトの両方について、最小特権と職務分離の原則を実施する必要があります。これにより、ポリシーの複雑さ、設定ミスのリスク、インサイダーの脅威を軽減することができます。例えば、異なるチームがアクセス制御と脅威防止保護の管理を担当する場合があります。

堅牢な職務分離機能は、専任のセキュリティ担当者だけに依存した場合に自然に発生するボトルネックを防止する委任フレームワークをサポートすることができます。ビジネスユーザーは、責任範囲内のエンティティのアクセス権を管理する権限を与えられ、これらの管理タスクを実行するための適切なユーザインタフェースを提供することができます。委任範囲の最果てでは、疑わしいサイトにアクセスするかどうかなどの日常的なセキュリティ上の判断をエンドユーザーに任せることができます。例えば、ユーザーはファイルやネットワークサービスにアクセスするためのビジネス上の正当な理由を提供することができ、この要求は管理者によって一旦検討された後、許可または拒否される可能性があります。

異なる保護タイプは、異なる管理上のユースケースを定義します。企業固有の構成に基づいて各セグメントに合わせたアクセス制御ポリシーや、データの分類に焦点を当てたデータ保護とは対照的に、各セグメントに適用される脅威防止保護は、各保護の一般的な特性に基づいて選択されます。

  • 個々の保護の信頼度(偽陽性のリスクのレベル)
  • 対応する攻撃の業務に対する深刻度
  • 脅威防止分析の中には、他の分析よりも多くの処理リソースとストレージリソースを必要とするものがあるため、脅威防止のためのパフォーマンスのトレードオフが許容されます。管理者は、各管理スコープにこれらのリソースを割り当て、どの保護を適用でき、どの保護をリアルタイムで実行する必要があるかを選択します。

自動化

企業の構成は、ネットワーク、アプリケーション、ホスト、ユーザー、および役割が変化するビジネス環境に動的に適応するように、急速に進化しています。今日では、管理者が企業構成のすべての変更に手動で従うのは大変な作業です。これは、サーバーとネットワークのIDと場所の急速な変化に保護が従う必要があるため、サーバー仮想化とSDNを使用する仮想化環境で特に当てはまります。

SDP管理層は、組織がセキュリティポリシー管理を自動化し、他の企業システムとの連携を可能にするオープンな自動化インタフェースを提供しなければなりません。

企業システムとの同期

SDP管理層は、SDP管理層API、CLI、およびその他のインターフェイスを介してオブジェクトやオブジェクト属性を自動的に更新することで、制御層のセキュリティポリシーを、クラウドオーケストレーションディレクター、構成データベース、資産インベントリシステム、およびID管理インフラストラクチャなどの企業のダイナミック環境と同期させます。

自動化は通常、属性ベースのアクセス制御(ABAC)モデルに依存しています。ABAC は、IP アドレスやネットワークポートなどの静的な技術的識別子を使用するのではなく、役割、アプリケーション、データの分類、クライアントやサーバーの種類などの論理的および文脈的な属性の関数としてセキュリティポリシーを伝えます。

前述の例(図3-Aを参照)では、セキュリティポリシーモジュールは、Webアプリケーションサーバからアプリケーション固有のデータベースアクセスプロトコルのセットを介してデータベースサーバへのアクセスを許可し、データベースへの他のすべてのアクセスを禁止することができます。企業システムによって新しいホストがデータベースサーバとして識別されると、ポリシーモジュールは、保護範囲に新しいホストを含む新しいポリシーのインストールを必要とせずに、このホストに暗黙的に適用されます。

その他の同期化の例としては、以下のようなものがあります。

  • アイデンティティの認識とアプリケーションの認識は、役割ベースのアクセス制御ポリシーの定義をサポートすることができます。
  • データ認識はDLPポリシーをサポートできます。
  • クラウドオーケストレーションは、物理ホスト間で仮想マシンが作成され移動する際に、仮想マシンを自動的に保護することができます。
  • CRMシステムで開かれたチケットは、管理層が扱うセキュリティプロビジョニングワークフローと自動的に同期させることができます。
  • ネットワーク管理システムは、セキュリティポリシーを定義するために使用できるネットワークトポロジーと資産インベントリ情報を提供することができます。
  • SDN API は保護されたセグメント間のネットワークフローが適切な実施ポイントを通過することを保証するために使われます。

ルールの衛生

セキュリティ設定ルールは、時間の経過とともに量が増えていく傾向があります。システム管理者は、新しいユーザ、ホスト、アプリケーション、およびインタラクションをサポートするために頻繁に変更を行いますが、廃止されたシステムのセキュリティ管理者に通知することはほとんどありません。制御パフォーマンスに影響を与えるだけでなく、大規模な構成セットは、必要な保護を無効にしてしまうエラーのリスクを高めます。

ポリシーの自動化は、よくあるエラーを管理者に警告し、ポリシーの自動調整や微調整を行うことで、正確なセキュリティポリシーを確保することができます。

  • 管理者が対応するルールが既に存在するかどうかを確認せずに変更を行った場合、冗長なルールが作成されることがあります。
  • 孤立したルールとは、もはや存在しないエンティティを指します。孤立したルールは、構成ルールセットのスペースを占有し、パフォーマンスに影響を与えるだけでなく、アドレスやアイデンティティが他の目的で再利用された場合にもリスクをもたらします。孤立した IPS シグネチャは、保護されたセグメント内にインストールされていないアプリケーションやアプリケーションのバージョンの脆弱性から保護される可能性があります。例えば、産業制御に特化した IPS 保護は、特定の組織にのみ関連している可能性が高く、他の場所では省略することができます。
  • シャドーイングされたルールは、他のより優先度の高いルールによって上書きされるため、非アクティブになります。例えば、CFOが財務システムへのアクセスを許可するルールが、経営グループ全体の権限と並行して存在している場合、そのルールは冗長になる可能性があります。例外とされていたルールが、より一般的なルールによって上書きされてしまうこともありますが、その場合は優先度を適宜調整する必要があります。
  • インタラクションに力を与える一時的なルールは、有効期限と関連付けるべきであり、その期限が過ぎれば自動的に削除されるべきです。
  • コンプライアンス違反は、セキュリティポリシーの構成が業界の規制(PCI DSS、HIPAA、NERC CIP など)に違反している場合に自動的に特定できます。例えば、暗号化を必要とするインタラクションが、構成エラーにより平文で許可される可能性があります。

可視性

可視性が必要な理由は2つあります。状況認識 – ネットワークで何が起こっているかを理解すること、そしてインシデント対応 – 何かを行うことです。

SDP管理層は、制御層の保護機能と人間の対応者との相互作用として、インシデント対応をサポートします。自動化されたコントロールは、膨大な量のビッグデータを選別し、異常な行動を検出することに優れていますが、不正な行動のパターンを特定し、誤検出を取り除き、動機と意図によるイベントの分類を行い、効果的で安全な行動方針(COA)を特定するという点では、人間のインテリジェンスの方が優れています。自動化された反応メカニズムは、信頼性の高い指標と一致する悪意のある行動をブロックするために使用されることがあります。

状況認識

管理層は、ネットワーク内に配置された実施ポイントからのイベントを収集、統合、および関連付けします。インシデント対応者は、イベントの連鎖をリアルタイムで可視化することができます。これにより、最初の攻撃のベクトル、その後に行われた破壊されたホストや侵害されたデータを特定することができます。イベントの調査では、特定された各攻撃に関連するマルウェア、脅威行動、およびネットワークアドレスに関する新たな脅威指標を生成することができます。これらの指標は、制御層に自動的に送られ、そこから実施層に配信され、組織を保護します。

セキュリティ関連のイベントレポートは、以下のようなさまざまなソースから受け取ることができます。

  • 検出された相互作用と脅威の指標との間の一致を報告する実施ポイント。
  • 実施ポイントは、不正な相互作用を報告します。
  • 管理層の分析では、承認されたと思われる相互作用記録の異常が発見され、さらなる調査が必要となります。
  • 組織の内部または外部の情報源から不審な行動の報告を受けた場合。例えば、ユーザーがサービスが利用できないと報告したり、別の企業が組織内からの攻撃を訴えたりします。

潜在的なインシデントが検出された場合、検出された症状をトリアージし、対応が必要かどうかを決定するために、対応手順を起動する必要があります。フォレンジックデータを収集し、分析します。攻撃を停止させ、被害の可能性を調査し、攻撃の再発を止めることに注意を払う必要があります。

インシデントは、非標的型ウイルスやハッキング未遂のように、独立したイベントである可能性があります。攻撃が阻止されたり、回復されたりすれば、それは終わりです。逆に、インシデントは、より広範な攻撃キャンペーンの症状である可能性があります。後者の場合、検出された事象や一致した指標が氷山の一角である可能性があるため、インシデント対応者が各インシデントをどちらかに分類することが重要です。調査員は、過去(すなわち、開始イベントの前の出来事)と未来(すなわち、最初に特定されたイベントの後に攻撃がどのように進行したか)を調査するべきです。

調査プロセスの一環として、追加の指標や疑わしいホストが特定されることがあります。これらの指標は、適用可能な保護を生成し、調査範囲を拡大するために制御層に伝えられます。このプロセスでは、過去のイベント記録や、内部および外部の情報源(インターネットなど)を利用したデータの充実に依存します。

  • 侵入キルチェーンの感染前の部分は何だったのでしょうか? 言い換えれば、このホストはいつ、どのようにして感染したのでしょうか? ホストからホストへのアクティビティをキャプチャしたログを確認することで、侵害の期間とそれに先立つアクションを特定することができます。ホストがどのようにして感染したかがわかれば、同じ配信メカニズムを使った将来の攻撃をブロックすることができます。
  • ログには同じ攻撃を受けた可能性のある他のホストの証拠が含まれていますか? これらのホストを含むように調査プロセスを拡大すべきです。
  • 感染後 – 疑われるホストからのすべてのアウトバウンド活動を見直す必要があります。これにより、感染した可能性のある追加のホストの兆候が得られるかもしれません。感染したホストからのアウトバウンド接続は、以前に知られていなかったC&Cサーバやドロップゾーンへの接続である可能性があります。未知の接続先が悪意のあるものかどうかを判断し、対応する脅威指標を生成するために、未知の接続先を調査する必要があります。

管理層は、データの可視化と分析ツールを使用して、イベントの属性と一致する可能性のあるベースラインのユーザー行動や脅威指標に関する情報をインシデントレスポンダーに提供することで、これらの調査をサポートします。異なるイベントを相関させ、イベントを「正常」「異常」な行動の既知のパターンに一致させることで、インシデント対応者がレビューする必要のあるイベントレポートの量を減らすことができます。ワークフローと意思決定支援ツールは、初期対応の調整を支援します。ハニーポットやハニーネットは、攻撃者を引き出して行動を調査するために、ターゲット環境をシミュレートするために使用されることがあります。

インシデント対応

攻撃に対応するための選択肢は、その攻撃の想定されるキルチェーンフェーズ(すなわち、感染前(偵察、配送、または搾取)か 感染後(設置、C&C、または目的地での行動)かによって異なります。一般的に、攻撃の混乱には以下のいずれかの行動が含まれます。

  • 脅威エージェントがターゲットと相互作用することを防止またはブロックする
  • 期待される承認された相互作用プロトコルとデータコンテンツの実施
  • システムの状態変化とデータフローの制約(例:リソース割り当ての実施や、定義された境界線外への機密データの漏洩防止)

アクティブなインシデントの前駆体は、検出された攻撃者の偵察、ヒューマン・エンジニアリング・インシデント未遂の報告、または差し迫った攻撃に関する脅威インテリジェンスの形で識別される場合があります。例えば、推定される攻撃者によって悪用された脆弱性を除去またはマスクする適切な保護機能を配布したり、マルウェアが配布されているウェブサイトへのアクセスをブロックする脅威指標をインポートしたりするなどです。

感染後に攻撃が成功したと合理的な疑いがある場合は、感染後の封じ込め制御を使用して、感染の兆候を調査しながら、相互作用を最小限に抑えることができます。最小限の機能しか使用できない構成をセグメントごとに事前に定義しておき、セグメントが危険にさらされている、または進行中の攻撃に対して脆弱であると判断された場合に自動制御を実行することができます。封じ込めは、複数の攻撃ベクトルをブロックしながら、ビジネスに不可欠な相互作用を可能にします。

攻撃者は、単一の組織だけを攻撃したり、ターゲットごとに完全な TTP をゼロから再構築したりすることはほとんどありません。セキュリティイベントを共有することで、協調的なインテリジェンスが可能になり、大規模なグループの統合イベントデータを使用することで、企業の防御を支援することができます。脅威エージェント、TTP、脅威指標を1つの企業ネットワーク上で特定し、共有することで、自分自身が標的にされる前に、知識が他の人に利益をもたらすことができます。

管理層の概要

管理層は、Software-Defined Protection アーキテクチャを実現します。アーキテクチャの各コンポーネントを有効にすることで、この層は、セキュリティ管理者と他の 2 つの SDP 層間のインターフェイスとして機能します。

SDP 管理インターフェイスでは、アクセスポリシーとデータ制御ポリシーの定義と脅威防止の有効化を別々に行うことができます。脅威防止ポリシーは、アクセスポリシーとデータコントロールポリシーによって許可されたトラフィックに自動的に適用されますが、別の担当者が管理したり、外部に委託したりすることもできます。

アクセス制御の領域内では、SDP管理は、さまざまなネットワークセグメントに関連付けられたポリシーレイヤーとサブレイヤーをサポートし、同時にそれらのすべてを同時に処理できる特定の管理者に管理を委任する機能を提供する必要があります。

エンタープライズオーケストレーションは、管理層に、組織に合わせたセキュリティ管理に必要なインテリジェンスを提供します。

さらに、管理層は、ネットワークで何が起こっているかを可視化し、プロアクティブなインシデント対応をサポートします。

S 概要

今日のセキュリティの課題には、保護アーキテクチャの新しい視点が必要とされています。明日の脅威は昨日のものとは異なり、高度な企業情報システムの刻々と変化する要件に迅速に対応し、歩調を合わせて対応するアーキテクチャが求められます。

SDP アーキテクチャは新しいパラダイムであり、モジュール式でダイナミックなセキュリティインフラストラクチャを実装するための実用的なアプローチです。ソフトウェアで定義された保護は、必要な柔軟性を提供し、新たな脅威や、新しいエンタープライズコンピューティングやネットワーキングプラットフォームから生まれた課題に対処するために適応することができます。

企業内で現在活動している脅威を特定するために、組織は、脅威指標の形で実行可能なインテリジェンスを生成して配布するためのメカニズムとプロセスを実装する必要があります。脅威の予防に使用される脅威インテリジェンスは、外部および内部の脅威データのソースを使用して取得されます。指標は、実施ポイントがリアルタイムで脅威を検出し、ブロックするために使用されます。

最後に、モジュール化されたオープンで弾力性のあるセキュリティ管理により、企業は、階層化されたセキュリティ管理フレームワークを使用して、業務の委任と分離をサポートすることで、セキュリティをビジネスプロセスと統合することができます。自動化は、他の企業システムとのセキュリティアーキテクチャのオーケストレーションに使用されます。

この近代的なアーキテクチャにより、攻撃は撃退され、内部リソースを破壊する可能性のある外部からの脅威は検出され、封じ込められ、除去されます。

ソフトウェア定義保護

SDP(Software-Defined Protection)は、Check Pointが顧客やコミュニティに提供する実用的なセキュリティ・アーキテクチャです。Check Pointの SDP は、モジュール式で俊敏なセキュリティ・インフラストラクチャを提供します。

本稿では、Check Pointの製品やセキュリティ・サービスを利用して、ネットワーク環境、ホスト環境、モバイル環境、クラウド環境にまたがる SDP アーキテクチャを構築する方法について説明します。

Check Pointのソフトウェアで定義された保護機能は、新たな脅威に対応し、新しい技術を取り入れるために必要な柔軟性を備えています。Check Pointのソリューションは、既知および未知の脅威に対する新しい保護機能や最新の保護機能を生成し、その知識をクラウドを通じて積極的に配信します。健全なアーキテクチャ・セキュリティ設計に基づいたCheck Pointのセキュリティ・ソリューションを導入することで、企業は最先端の情報システム・ソリューションを自信を持って導入することができます。

Software-Defined Protection は、相互に接続された 3 つのアーキテクチャ層が連携して、適応性の高い集中管理された高性能なセキュリティを提供するという観点から、企業のセキュリティアーキテクチャを説明しています。

 

コメント

タイトルとURLをコピーしました