セキュリティ強化・投資計画に向けたNetFlow/sFlowの活用

NaaS/E (Network as a Sensor / Enforcer)

ここ最近NaaS/NaaEというキーワードが生まれている。

字面を見ると、SaaSから始まったPaaS/IaaS/DaaSの類か、と直感的に思う。

しかし、Ciscoではそれぞれ以下のように呼称している。

Network as a Sensor / Enforcer

www.cisco.com

IoTの普及なども受け、入口/出口対策などの局所的な方法では守れる範囲が限られてしまう。

具体的な例を挙げると、入口/出口のみでは、ウイルス感染した端末があった場合に、その端末が社内の同一LAN上にある端末/サーバ、基幹サーバにアクセスする通信は検知・防御することができない。

基幹サーバとの間にはFWが設置されているのが一般的だが、プロトコル/ポート番号が一致すれば通信は許可される可能性が高い。それぞれの通信区間での防御方法は以下のイメージになる。

通信元/通信先	攻撃者	中継サーバ	被害端末	社内基幹サーバ
攻撃者	-	-	入口	入口
中継サーバ	-	-	出口	出口
被害端末	出口	出口	×	×(社内FW)
社内基幹サーバ	出口	出口	×(社内FW)	×

この表の×となっている部分について、NaaS/Eの概念でNetFlow/sFlowを導入することにより、検知・防御を可能とする。

IPS/IDS,NG-FWなどのセキュリティ機器は一般的に高価で、かつ、継続運用も必要となるため、気軽に導入するにはハードルが高い。

それに比べ、NetFlow/sFlowでは、既存設備の有効活用で始めることができる。

企業内LAN機器はNetFlow/sFlowに対応しているものが多いため、簡単な設定追加のみで、トラフィックのフローデータを取り始められる。

トラフィックの可視化(見える化)ツール、異常検知時のブロック方法は検討が必要となるが、まずはデータを取らないことには始まらない。

概要レベルでの特徴的な差異は以下の通り。

諸々の差異はあるが、一番の致命的な差異は収集フロー対象である。

sFlowは数秒に1フローのサンプリングのため、必ず取りこぼしが発生する。

機器スペックが向上している現在においては、対応していればsFlowではなくNetFlowを積極採用すべきだと考える。

Flow Collector(コレクター)やManagement Console(管理・分析ツール)など、NetFlow/sFlowを受け取り分析するソフトウェアについては引き続き検討する。