- 脅威防止
- 脅威検出
- 脅威への対応。
どのようなソリューションを検討しても、これらは企業ネットワークのどこにでも実装する必要があるこれらの3つのタスクに適合します。 脅威と戦うこのライフサイクル（BEFORE-TIME-AFTER）は、シスコのCisco Information Security Serviceの活動の基盤です。 さらに、シスコには境界線の概念がないため、データセンター、クラウド、Wi-Fiセグメント、従業員のモバイルデバイス、インターネットアクセスポイント、そしてもちろん、上記の3つのタスクをどこでも実装しようとしていることに注意してください、社内ネットワークで、今日は監視について説明します。
内部ネットワークを監視する必要があるのはなぜですか？
結局のところ、私たちはITU、IDS、コンテンツフィルタリング、および他の多くのネットワークセキュリティツールを配置する境界については、このような質問はありません（境界がないのはなぜかを改めて説明します）。 内部ネットワークを例外にする必要があるのはなぜですか？ 境界線を迂回して外部から侵入することは不可能ですか？ はい、たくさんの方法。 保護されていないWi-Fiを介して、またはホットコーヒーを飲んだり、カフェで食事をしたりする従業員のモバイルデバイスが自動的に接続する隣のチョコレートハウスのアクセスポイントを介して。 ハッキングされた自宅のラップトップまたはタブレット/スマートフォンを通じて、「IT担当者を整理」するために彼をオフィスに引きずり込んだマニュアル。 オフィスに投げ込まれたフラッシュドライブを介して、検出できない悪意のあるコードが注がれます。 セキュリティの問題を考慮せずに開発された、クライアント/サーバーアプリケーションの暗号化されたチャネルを通じて。 はい、最終的に境界線の脆弱性を介して（私たちのITUが絶対に無防備であると仮定しません）。 つまり、内部ネットワークには境界と同じ保護が必要であり、多くの組織は不当に防御努力に集中することが多く、最も弱いリンクに関する真実を完全に忘れています。
IDSでは十分ではありませんか？
内部のシスコネットワークで脅威がどのように防止されるかについては既に説明しました-これには、各スイッチまたはルーターを有効にする分散ITUとして機能するCisco Identity Service Engine（ISE）を使用し、最後の4万個以上をアクセス制御の内部手段の一部にしています動的ポリシーに取り組んでいます。 しかし、私たちにとっては、境界設定と予防だけでは十分ではありません。 また、内部で許可された接続のフレームワーク内でアクティビティを監視し、内部アクセスの確立されたルールの違反も監視する必要があります（私たちはすべて人間であり、私たちは皆間違いを犯しがちです）。 境界に侵入検知システム（IDS）をインストールし、この問題を解決します。 内部ネットワークにIDSを配置するのは簡単ではありませんが、シスコはできるだけ多くのセンサーをCisco NGIPSに販売することを喜んでいます。 しかし、これは多くの場合不可能です（データセンターや個々のセグメントなど、ネットワーク内の一部の場所を除く）。 また、アーキテクチャの観点からも不可能です-すべてのスイッチポートがIDSセンサーを持つことができるわけではなく、IDSが頻繁に接続されるすべてのトランクまたはスパンポートがすべてのスイッチポートからトラフィックをプルするわけではなく、スパンポートは常に空いているわけではありません。 経済的な観点からも不可能です-各スイッチまたはルーターに高性能センサーを購入するのは非常に高価です。 シスコでも、NGIPSを作成しているという事実にもかかわらず、内部ネットワークのIDSを使用した監視に多額の費用をかけることはできません。これは非常に高価です。 スプリッター（タップ）を使用しようとしても、アーキテクチャーの観点からも、金融の観点からも、すべての問題を解決するわけではありません。 さらに、境界にいる間、セキュリティガードはITスタッフ（ネットワーク担当者）と一緒に暮らすことを何とかして学んだが、内部ネットワークでは競合がくすぶり続けています。 同じ問題を解決するために、従来のネットワークIDSに代わるものはありますか？
IDSなしで内部ネットワークを監視する方法は？
答えはイエスで、Netflowと呼ばれます。 これは、ネットワークの問題（troobleaching）を検出する目的でシスコによって最初に開発されたプロトコルであり、その後、機器でNetflowをサポートするか、クローン（Cflow、sFlow、Jflow）を作成した多くのネットワークメーカーの事実上の標準になりました。 NetStream、Rflowなど しかし、今日はシスコの内部ネットワークを監視する方法について話し、独自のネットワーク機器を使用するため、Netflowプロトコルのみに集中します。Netflowプロトコルは、企業レベルのほぼすべての通常のネットワークハードウェア（自宅から）デバイスがNetflowをサポートするのを待つ価値はありません。自宅では単純に必要ではなく、決定をより重く、より高価にするだけです。
したがって、制御を必要とするすべてのトラフィックが通過するネットワーク機器にはNetflowがあります。 これは、ネットワーク上の問題を検出するだけでなく、情報セキュリティの目的にも使用できることを意味します。 さらに、ネットワーク機器でのNetflowのサポートにより、監視のために別個の重畳ネットワークを構築することはできませんが、ISタスクにすでに使用されているネットワーク機器を使用することができます。 一方で、これはすでに行われた投資を保護し、監視ソリューションのコストを削減し、他方で、アーキテクチャと実装の両方の点でそれをより簡単にします-数十または数百のIDSセンサーに必要なフローを正しく指示する必要はありません。彼らのネットワークに置くことを余儀なくされたでしょう。 Netflowを使用すると、すぐに目に見えない別の利点が得られます。 従来のIDSをインストールする場合、保護システムのセンサーにトラフィックまたはそのコピーを送信する問題を解決する必要があります。 何らかの理由でこれが発生しない場合（たとえば、トポロジの変更やセンサーの帯域幅の不足などにより）、絶対に何も表示されず、関心のあるトラフィックに攻撃はないと考えられます。 センサー自体は動作します-必要なトラフィックを受信せず、分析しません。 これはNetflowでは機能しません-ネットワークデバイスを流れるすべてのものが表示されます。ネットワークデバイスは、ルーターまたはスイッチ（仮想のものを含む）だけでなく、たとえばファイアウォール（たとえば、Cisco ASAはNSEL機能をサポートします） Netflow Security Event Logging。これにより、適切な監視ツールによる分析のために、ネットワークストリームをNetflowの形式でブロードキャストできます。
シスコネットワークのセキュリティにNetflowを使用することから来たNetflowについて、いくつかコメントをする時が来ました。 最初に、Netflowを非サンプリングおよびサンプリングできることを知っておく必要があります。 それらの違いは、本全体を「表紙から表紙に」読んだり、10ページごとに止まったりする場合と同じです。 多くのネットワークデバイスはNetflowをサポートしていますが、サンプリングのみであり、監視に必要なすべてのトラフィックのほんの一部しか表示されないため、セキュリティの目的には適していません。 したがって、使用しているNetflowに注意してください。 情報セキュリティのためのサンプリングは適切ではありません。 第二に、Netflowの処理、特に非サンプリングは、ネットワークデバイスのプロセッサに負荷をかけることを知っておく必要があります。これは、ネットワークを計画し、Netflowに基づいてセキュリティ監視システムを構築する際に考慮する必要があります。 スイッチまたはルーターがすでに全容量で動作しており、通常の動作でCPU使用率が80〜90％に達した場合、デバイスでNetflowを有効にするかどうかを検討するのは10回の価値があります。 この状況には2つの解決策があります-ネットワークインフラストラクチャの更新（すべて同じ、遅かれ早かれ行われる必要があります）およびNetflow生成デバイスの使用。 シスコでは、両方のオプションを使用しました。 Netflowの監視が重要なタスクであり、アップグレードの時期になった場合、CPUをロードせずにNetflowを処理するハードウェアを備えた新しいスイッチとルーターをインストールしました。 それ以外の場合、FlowSensorと呼ばれるソリューションを使用しました。これは、トラフィックをNetflowにブロードキャストし（スプリッター、タップのアナログ）、セキュリティサービスによるさらなる分析のために渡されます。
Netflowは何を教えてくれますか？
Netflowプロトコルにはいくつかのバージョンがあり、最も一般的なものは現在5日と9日です。 後者に基づいて、オープンIPFIX仕様が開発されました。 プロトコルの5番目のバージョンでは、ネットワークトラフィックに関する次の情報を収集できます。
- 送信元アドレス
- 宛先住所
- UDPおよびTCPの送信元ポート
- UDPおよびTCPの宛先ポート
- ICMPのメッセージタイプとコード
- IPプロトコル番号
- ネットワークインターフェイス（ifindex SNMPパラメーター）
- サービスの種類の値
- 時間パラメータ
- 送信されたバイトとパケットの量
- TCPフラグ値
- ルート情報
- 自律システムに関する情報。
9番目のバージョンは、IPv6、MPLS、BGPに関連する追加フィールドをサポートしています。 また、カスタムフィールドをサポートするNetFlowの拡張バージョン、同じIPFIX、Flexible Netflowもあります。
この情報は一見表面的なものであり、ネットワークセッションのヘッダーにあるものだけを反映していますが、実際には、暗号化トラフィック分析テクノロジー（ETA）の話で既に見たように、これは多くの場合トラフィックを分類して認識するのに十分です。 たとえば、過剰な数のパケットまたはバイトはDoSを特徴づけることができ、限られた時間間隔での多数の宛先アドレスはネットワークスキャンなどを意味します。 Netflowを使用すると、ノードのプロファイルを作成し、標準動作からの逸脱を追跡できます。
以前はどのようにネットワークを監視していましたか？
当初、シスコは無料のモニタリングソリューションnfdump（ https://github.com/phaag/nfdump ）およびOSU FlowTools（OSUはOhio State Universityの略語）を使用していました。これにより、Netflowでの作業、フィルタリング、選択、その他の操作を実行できます。ネットワークストリーム。 どちらのソリューションも十分に高速で（1日に数十ギガバイトのストリームを処理できます）、tcpdumpなどの従来のユーティリティの経験があるユーザーにとって使いやすく、フィルタリングに柔軟性があります。 しかし、これらのツールには3つの部分に分けられる問題もあります。 まず、これらはユーティリティ自体の欠点であり、たとえば、通常のフローの集約を許可しなかったため、多くの場合、重複が発生します（同じストリームが5つのネットワークデバイスを通過することを想像してください-ユーティリティもそれらを5回表示および書き込みします）。 さらに、nfdumpおよびFlow Toolsでは、フローの損失を追跡することができなかったため、誤ったセキュリティの感覚につながりました（映画「DMB」の古典的なフレーズを言い換えると、「ストリームを見ていると思うが、実際にはそうではない」）。 小規模ネットワークでは、これはそれほど重要ではありませんが、シスコのような分散ネットワークでは、新しいサイトでの監視システムの実装が拡大するにつれて、大きな困難が生じ始めました。 第二に、オープンソースプロジェクトには、サポート、新機能の追加、Netflowのサポートされるバージョンの数の拡大などに関連する困難があります。 そして最後に、nfdumpとOSU Flow Toolsを使用するには、高度な資格を持つ人員だけでなく、インシデントの調査と対応に関連する一般的な日常業務を自動化するための相当な努力も必要でした。
たとえば、コマンドサーバーと通信する感染した内部マシンを検出するには、Cisco ACL形式で対応するリストを作成して最新の状態に保ち、それをフローフィルターユーティリティの入力に送信して、収集されたNetflowストリームに適用する必要があります。
[mynfchost]$ head bot.acl ip access-list standard bot permit host 69.50.180.3 ip access-list standard bot permit host 66.182.153.176 [mynfchost]$ flow-cat /var/local/flows/data/2007-02-12/ft* | flow-filter -S bot.acl Start End Sif SrcIPaddress SrcP DIf DstIPaddress DstP 0213.08:39:49.911 0213.08:40:34.519 58 10.10.71.100 8343 98 69.50.180.3 31337 0213.08:40:33.590 0213.08:40:42.294 98 69.50.180.3 31337 58 10.10.71.100 83
効果的な作業のためには、攻撃、C＆Cサーバー、内部ノード、さまざまな基準でセグメント化されたなど、多くの事前作成リストを最新に保つ必要があることは明らかです。 同時に、最後のリスト自体は、シスコの動的インフラストラクチャの変動により常に変化します。
nfdumpとOSU Flow Toolsの使用に関するもう1つの問題は、フローが単方向であるため、特定の接続を開始した人を認識できないことです（これは調査で重要です）。 クライアント/サーバー接続の最初のユーザーを把握するには、追加の作業を実行する必要があります。 最後に、これらのユーティリティの作業に関連する別の微妙な点に出会いました。 完了したストリームのみを記録するため、リアルタイムで発生する攻撃を迅速に追跡できなくなる可能性があります。 たとえば、攻撃者はすでにネットワークをスキャンし、ホストを侵害して侵入しましたが、nfdumpもFlow Toolsもネットワークフローを記録していないため、これを認識していません。
現在何を使用していますか？
nfdumpとOSU Flow Toolsの経験を積んだ後、IPv6とNetflowバージョン9に切り替えたとき、私たちが遭遇した欠点のないツールを探し始めました。 それはLancopeのStealthwatchソリューションであり、後に買収してシスコの一部となりました。 Stealthwatchは、任意のアナライザー「センサー-コレクター-アナライザー」のクラシックアーキテクチャに基づいて構築されています。
センサーとして、ネットワークインフラストラクチャを使用します。これは、内部ネットワークトラフィックをすべて通過させ、それをNetflowに変換し、分析のためにコレクターに渡します。 上記で書いたように、ネットワーク機器は常にNetflowをサポートしていないか、Netflowを効率的に処理できるわけではありません。 このタスクでは、個別のハードウェアまたは仮想FlowSensorを使用します（合計13台あります）。 シスコの地理的に分散したインフラストラクチャを考えると、1つまたは2つのコレクターへのすべてのフローを削減するのではなく、企業のバックボーンおよびデータセンターで悪意のあるアクティビティを検索するために毎日約200億のNetflowフローを処理する21 FlowCollectorの分散クラスター全体を削減します。 また、コンソールは2つしかありません。CiscoIncident Response Servicesは、役割に応じてコンソールにアクセスできます。
ユースケース
おそらく、私たちのネットワーク（そして一般的に）でのオープンソースNetflowモニタリングツールの効果的な使用に対する主な障害は、通常の分析の欠如でした。 フィルタリングとサンプリングの柔軟な手段がありますが、人がいなければネットワークフローの問題の有無を判断できません。 Stealthwatchはこの欠点を奪われました-その主な利点は、Netflowを評価し、ネットワークスキャン、DoS、悪意のあるコード配布、情報漏洩など、Netflowを評価し、さまざまなセキュリティ違反を認識できるアルゴリズムの組み込みデータベースの存在でした
Stealthwatchを使用する主なシナリオ（実際にはもっとあります）：
- 調査
- C＆Cとの相互作用の検出
- DoS攻撃の検出
- データ漏洩検出
- ファイアウォールを区切るためのルールの設定を確認します。
Netflowは、インシデント調査の理想的な情報源であり、誰が、何を、いつ、どのアクションを実行したかについて必要な情報がすべて含まれています。 同時に、この情報はすべてデータベースに保存され、応答サービスの従業員は必要な要求を行い、必要なフィールドでフィルタリングおよび選択し、質問に対する回答をすばやく見つけることができます。 Cisco ISEとの統合により、インシデントに関係するノードのIPアドレスへのバインドだけでなく、Active Directoryの会社のユーザーアカウントへのバインドも提供されます。 後者のオプションは便利なだけでなく、特定の瞬間にユーザー名を動的IPアドレスにマップするのにかかる時間を大幅に短縮します。 時間を短縮することは、インシデントの調査における重要な成功要因です。
Stealthwatchの威力を示す2番目のケースは、ボットネットとマルウェアのコマンドサーバーとの相互作用の検出です。 これは境界で行うことができるように思われますが、このメモが何から始まったかを思い出しましょう。 今日、ユーザーはさまざまな方法で攻撃できますが、必ずしも境界線を介して攻撃することはできません。 ランサムウェアが保護されていないWi-Fiを介してネットワーク内に侵入し、それを通じて情報が漏洩したり、悪意のあるコードの更新を受信した場合はどうなりますか これは、内部ネットワークトラフィックを監視することによってのみ修正でき、ステルスウォッチはここで不可欠です。 以前は、nfdumpを使用してこのタスクを実行しましたが、1つの制限がありました。コマンドサーバーのIPアドレスのリストを手動で更新し、さまざまなソースから収集する必要がありました。 Stealthwatchの場合、このタスクは自動的に解決されます。管理サーバーに関する情報を含む、侵害の最新のインジケーターを定期的にアップロードします。 この関数の有用性は、リストからアドレスの陳腐化を監視し、必要に応じてそれらを削除するという事実にもあります。 nfdumpの場合、これを手動で行う必要があり、貴重な時間がかかりました。
サービス拒否攻撃の検出は、ネットワークで使用するもう1つの一般的な使用例です。 これは、こうした事件が定期的に発生するということではありませんが、実際に発生します。 さまざまなネットワークおよびアプリケーションプロトコルを使用したリクエストの「フラッド」、「ストーム」、および「アバランシェ」は、Stealthwatchを使用して簡単に検出されます。
Stealthwatchを含むNetwork Traffic AnalysisクラスのソリューションにはDLP機能がなく、さまざまなプロトコルを使用して通信内容を監視することはできません。 ただし、これらは情報漏えいに対処する方法でもあり、わずかに異なる原則が使用されます。 Netflowのフレームワーク内で、送信された情報の量を追跡できることを考えると、ユーザーがインターネットからダウンロードまたはインターネットにアップロードできるさまざまなプロトコルを使用して、各ノードまたはユーザーに情報量の平均値を設定できます。 HTTPの場合、この数値は1日あたり100 MBです。
したがって、この値を超えると異常と見なされ、ISポリシーの明らかな違反として、たとえば5回以上などの大幅な超過が発生します。 クラウドストレージに大量のデータをアップロードすると、ユーザーが機密情報を盗もうとしている可能性があります。 もちろん、「may」という言葉を使用しても無駄ではありません。これは、完全に合法的な活動の兆候でもあるためです。たとえば、ユーザーが新しいソフトウェア配布またはドキュメントセットまたはビデオトレーニングをクラウド経由で送信します。 いずれにせよ、データのしきい値を超えるトリガーをトリガーすることが調査の理由になります。
Stealthwatchに関連してネットワークで積極的に使用しているもう1つのシナリオは、アクセス制御ルールの設定をチェックして、セグメント間の不正トラフィックを追跡することです。 セグメンテーションは、情報セキュリティサービスの分野で最も有用なツールの1つであり、攻撃エリアの大幅な削減、問題のローカライズ、調査の迅速な実施などが可能です。 ネットワークでは、ネットワーク機器に基づいてセグメンテーションが積極的に使用され、Cisco ISEがそれを管理します。 Stealthwatchを使用して、セグメンテーション設定の正確性を確認し、特定のセグメントに表示されるべきではないトラフィックを確認します。
同じ機能を使用すると、境界にあるファイアウォール設定の正確性を確認し、場合によっては許可されていないトラフィックを許可できます。 実際、このユースケースのStealthwatchは、管理者のアクションを監視するための追加ツールに変わります。
Stealthwatchを使用するのは誰ですか？
Stealthwatchは、ネットワーク担当者やIT専門家が使用できるソリューションですが、セキュリティの専門家を対象としています。 シスコでは、Cisco CSIRTインシデントレスポンスサービスを担当しています。 データセンター、大企業のハブ、およびDMZに設置された180の主要なネットワークデバイスからデータを収集し、1秒あたり約18万のストリームを受信します。
前のメモの 1つで、私たちの製品でのAPIの可用性について既に書いています。 StealthwatchにはそのようなAPIがあり、インシデント対応サービスで非常に積極的に使用されています。 特に、特定のグループに含まれるノードに関する情報を更新するのはAPIを通じてです。
APIを介して新しい悪意のあるノードに関する情報を更新し、その相互作用はStealthwatchを使用して監視されます。 APIを使用して、StealthwatchをオープンソースのThreat Intelligence CRiTSプラットフォームと統合します。 これにより、侵害の新しい指標に関するデータを受信した場合、APIを介してCRiTSに統合されたすべてのセキュリティ対策にこの情報を配信できます。
APIを使用すると、より詳細な調査を行うことを含め、シスコの主要な監視ツールであるSplunkに転送するためにStealthwatchから必要なイベントとフローを収集できます。
私が他のどこにも見たことのない興味深い体験は、モバイルSOC（セキュリティオペレーションセンター）の概念です。これは、企業、新しい工場、パートナーを購入するリモートサイトで、または接続されていないサイトで調査を実施するときに、情報セキュリティを監視するために使用します中央監視システム。 モバイルSOCは、IB機器を備えた持ち運び可能なラックであり、ステルスウォッチだけでなく、Netflow Generation Appliance、Splunk、Firepower、Web Security Applianceなども含まれます。
開発計画
すでに達成されていることに満足しておらず、当社のインフラストラクチャでステルスウォッチの使用を積極的に開発する予定です。 優先プランの中には：
- ISEとの継続的な統合により、インシデントに関係するノードとユーザーに関するコンテキスト情報を取得するだけでなく、ブロッキング機能を実装します。 将来、ISEを通じて、ネットワークレベルのStealthwatchとPCレベルのAMP4Eの組み合わせを実装する必要があります。これにより、情報セキュリティの問題をより迅速に特定できます。
- Stealthwatchの新しいバージョンに切り替えると、暗号化トラフィック分析機能が自動的に表示され、暗号化トラフィックの悪意のあるコードを検出できます。
- シスコで広く使用されているIaaSおよびPaaSクラウドプラットフォームを監視するためのStealthwatch Cloudの紹介。
- AnyConnectとの統合。これは、すべてのシスコ従業員がラップトップ、スマートフォン、またはラップトップで実装し、ユーザーおよびアプリケーションアクティビティに関するデータをNetflow形式で受信し、この情報をネットワークレベルでNetflowと関連付けるために実装されます。
一般に、Stealthwatchを使用したNetflowの分析は、情報セキュリティサービスが企業ネットワークの境界で使用される通常のセキュリティツールセットよりも多くのインシデントを検出するのに役立つことを認める必要があります。 わが国で発生したインシデントに関するデータのソースの変化のダイナミクスを追跡できます。 以前は、これは主にIDSからの攻撃シグネチャでしたが、現在、このソースはすべてのインシデントの5分の1しか占めていません。 別の5番目は行動分析、40％は妥協の指標です。 インシデントの残り20％の検出は、特にNetflowに基づいています。
追加情報：
-Cisco Success Storyのステルスウォッチ
-CSIRTの責任者によるシスコでのStealthwatchの使用に関するストーリー （ビデオ）
-Ciscoのステルスウォッチページ