前回のブログでは、Zeekフォーマットのメタデータがもたらす利点について書きました。今回のブログではその続きとして、お客様がZeekの導入をサポートするエンタープライズソリューションとして弊社を選ばれる理由について説明します。
その理由は、当初はZeek/Broの配備と保守を自社で行うことを選択した、ある政府系顧客の経験を通じて語るのが最も適切である。当時、その理由は合理的でした：1回限りの小規模な展開には社内のリソースを使用し、残りのインフラと一緒に段階的に保守しながら、セキュリティチームに大きな価値を提供する。
しかし、時が経つにつれて、それは次第に通用しなくなっていった：
- チューニングを維持するのは難しかった。パッチや新しいバージョンがリリースされるたびに、管理者はバイナリを再コンパイルし、再デプロイする必要があった。
- スケールが難しくなった。部分的にはアーキテクチャ上の決定ではあるが、センサーがデフォルトでスケールすることはほとんどない。センサーあたり3Gbpsで動作するようなデプロイメントはあまり見かけません。時間の経過とともに、センサーはパケットをドロップし始めました。顧客は突然、必要な処理をサポートするためにクラスターを構築しなければならなくなった。
- 複数の地理的なロケーションに分散したセンサーの軍団を管理するのは骨が折れるほど困難で、特にセンサーの構成が異質な場合はなおさらでした。システムに精通していた管理者が退職すると、セキュリティ・インフラの重要な部分が管理されないまま放置されることになった。
このようなトレードオフの関係から、多くのお客様から、セキュリティチームが時間をより有効に使うにはどうしたらよいかというご質問をいただきます。自己管理方式でツールを手作業で管理する(つまり、かろうじて存続させる）のか、それともセキュリティの専門家や脅威ハンターになるのか。自己管理シナリオとVectra の展開を比較してみましょう。
この顧客に共通する導入の課題に加え、システム監視、システム・ロギング、さらにはフロントエンド認証といった日々の運用要件が大きな負担となっている。多くの場合、このような導入の複雑さを簡素化できるパートナーを見つけることを選択します：導入までの時間を短縮し、定期的なパッチ適用や保守の必要性をなくす自動アップデートを可能にし、継続的なシステム監視を実行します。
これらは、セキュリティチームの本来の任務に専念できるようにするための既定の機能である。データの取得と分析のアーキテクチャと展開について考えてみましょう。このような問題については、 Vectra の担当者にご相談いただくか、ガートナー社の本リサーチの著者にお問い合わせください。