実践セキュリティ監視基盤構築(3): セキュリティ監視基盤をいつから始めるか
この記事はアドベントカレンダー実践セキュリティ監視基盤構築の3日目です。
セキュリティ監視は情報セキュリティ対策の重要な要素ですが、導入のタイミングは組織や事業規模によって異なります。今回は、セキュリティ監視基盤をいつから始めるべきかについて考察します。
組織の脅威・リスク分析を行う
セキュリティ監視は数ある情報セキュリティ対策の一つに過ぎません。どのような情報セキュリティ対策を講じるかは、組織の情報資産や守るべきデータを把握し、脅威やリスクを理解した上で、どのように対処するか（あるいは対処しないか）を考えることから始まります。
本文書では脅威・リスク分析について詳しくは触れませんが、セキュリティ監視を導入するかどうかを判断するためには、脅威・リスク分析を行うことが重要です。以下に、脅威・リスク分析のための著名なフレームワークやガイドラインをいくつか紹介します。
- STRIDE: Microsoftが開発したフレームワークで、脅威を6つのカテゴリ（Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege）に分類します。
- MITRE ATT&CK: MITREが開発したフレームワークで、サイバー攻撃の戦術や技術を体系的に整理したものです。攻撃者の行動を理解し、防御策を強化するために利用されます。
- NIST SP 800-30: NISTが提供するリスク評価のためのガイドラインです。リスクの特定、評価、対処を行うための手法が記載されています。
これらのフレームワークやガイドラインを参考に、組織の情報資産やリスクを把握し、セキュリティ監視が適しているかどうかを判断することが重要です。
セキュリティ監視に関するコスト
脅威・リスクの分析を行った上で、セキュリティ監視を導入するかどうかを判断するための重要な要素として、セキュリティ監視にかかるコストがあります。セキュリティにおける防御的対策は、一度設定すればその後は稀に調整するだけで済むことが多いです。一方で、セキュリティ監視は導入コストだけでなく、継続的な運用コストがかかります。このコストに対応できるかどうかが、セキュリティ監視を導入するかどうかの判断材料として重要です。
セキュリティ監視にかかるコストは、大きく分けて導入と運用の2つに分かれます。また、既製プロダクト、既製サービスの利用と内製でもコストが異なります。
- 既製プロダクト: 専用のハードウェアで構成されたセキュリティ監視プロダクトや、ソフトウェア製品をベンダーから購入し、汎用サーバーやクラウド上のインスタンスなどに導入するものを指します。商用の製品やオープンソースの製品があります。
- 既製サービス: クラウドサービスとして提供されるセキュリティ監視サービスを利用するものを指します。
- 内製: クラウドプラットフォームなどを利用し、自社でセキュリティ監視基盤を構築するものを指します。
導入のコスト
導入に関するコストを、筆者の経験に基づいてざっくりと比較すると以下のようになります。
| 項目 | 既製プロダクト | 既製サービス | 内製 |
|---|---|---|---|
| 購入費用 | 数百〜数千万（商用） | ほぼ無し | ほぼ無し |
| 導入工数 | 1〜3人月 | 1〜10人日 | 1〜10人日 |
| 開発工数 | 1〜3人月 | 1〜10人日 | 5〜20人月 |
既製プロダクトは商用の場合、導入に多くの購入費用がかかります。ほとんどの場合、ハードウェアやソフトウェア利用のライセンスを最初に購入する必要があります。規模にもよりますが、数百万円から数千万円単位の購入費用がかかることが一般的です。また、導入工数も多くかかることが多いです。これは接続するためのネットワークの調整や設定の変更、プロダクトの検証、そしてその上での実際の導入作業が必要になるためです。さらに、既製プロダクトの場合、カスタマイズや拡張に工数がかかることが多く、開発工数もある程度見込んでおく必要があります。
一方、既製サービスは従量課金型が多く、購入費用がほぼかかりません。さらにクラウドサービスの場合、アカウントを作成し、設定を行うだけで利用できることが多く、導入工数も比較的少なく済みます。拡張性も一定考慮されており、独自サービス・アプリからログを取り込む場合の開発工数は、既製プロダクトに比べて少ないことが多いです。ただし、対応できない機能については工数をかけても対応できないことが多く、この点については注意が必要です。
内製の場合は、クラウドプラットフォームを利用することで購入費用、導入工数はほぼかかりませんが、多大な開発工数がかかります。クラウドプラットフォームの利用には、クラウドプラットフォームの機能やAPIの理解、セキュリティ監視の知識や経験、ソフトウェアエンジニアリングの能力が必要であり、人材の確保という観点から考える必要があります。その代わりに、自社のニーズに合わせたセキュリティ監視基盤を構築することができ、機能要件の柔軟性や運用側のコスト削減につなげやすくなっています。
運用のコスト
導入にかかるコストだけでなく、運用にかかるコストも重要です。運用にかかるコストは、導入のコストと同様に既製プロダクト、既製サービス、内製で異なります。以下は一月あたりのコストのざっくりとした比較です。各項目はログ・アラートの総量によって大きく変化するので、割合として捉えてもらえると良いかと思います。
| 項目 | 既製プロダクト | 既製サービス | 内製 |
|---|---|---|---|
| システム利用費用 | 数十万〜数百万 | 数十万〜数百万 | 数万〜数十万 |
| システム運用工数 | 0.1人月 | 0.1人月 | 0.2人月 |
| 監視業務工数 | 0.1人月 | 0.1人月 | 0.1人月 |
導入では著しくコストのかかる内製ですが、運用側では比較的コストが抑えられることが多いです。これは、クラウドプラットフォームを活用することで、システム利用費用をコントロールできることが大きな要因です。特に保存するログの保存方法や処理のロジックを組織の要求に合わせて調整することで、コストの低減につなげやすくなっています。これによってスケールしやすいセキュリティ監視基盤を構築することができます。
一方で、既製プロダクトや既製サービスはシステム利用費用が多くかかることが多いです。内製と同じく取り込むログ量に対する従量課金になっている場合がほとんどですが、感覚値としては内製と比べておよそ10倍以上のコストがかかることが多いです。これは監視の規模を拡大させることに対するブロッカーとなることが多く、ログを網羅的に取り込みにくくなります。
運用工数については大きな違いはなく、どちらも日々トラブルなどが起きた時に対応したりするシステム運用工数や発生したアラートに関する調査などで一定の工数を必要とします。これは構築方法によらず、セキュリティ監視基盤を運用する上で必須な工数と考えて良いでしょう。ただし、内製のほうが機能の追加やメンテナンスなどで作業が発生するため、比較すると既製プロダクトや既製サービスに比べて多くなることがあります。
段階的なセキュリティ監視機能の導入
このようにセキュリティ監視は導入だけでなく運用のコストも必要となります。そのため、あらゆる組織が気軽に導入できるわけではありません。しかし、セキュリティ監視の一部の機能だけでも導入することで、組織全体のセキュリティ対策の水準を上げることもできます。ここでは、成長し続ける企業を例として、段階的にセキュリティ監視機能を導入し、調査・検知の成熟度を上げていくステップの例を示したいと思います。
Lv1：ログをためておく
- 調査能力：△
- 検知能力：✗
企業でいうとシードやアーリースタートアップなど、まだまだ成長途中の企業は、まずはログをためておくことから始めることをおすすめします。まだ情報資産の価値がそれほど高くなく、ビジネスを成り立たせる方法を試行錯誤している段階だと、検知の成熟度を上げるよりも、なにか問題が発生した際にそれを遡れるようにしておくことが重要です。
ログの保存についても集約する必要はなく、各クラウドサービスやアプリケーションが提供する保存方法をそのまま利用・分散して保持し、必要に応じてアクセスするで十分でしょう。ただし、ログがちゃんと出力される設定になっているかを確認したり、保存期間を設定するなどの基本的な設定は行っておくと良いでしょう。特に保存期間は短すぎても遡れる期間が限られてしまうが、長すぎてもコストがかかるため、適切な期間を考慮し設定することが重要です。
Lv2：ログを検索可能にする
- 調査能力：◯
- 検知能力：△
グロースやレイタースタートアップといったフェーズの企業になってくると、対外的な取引なども増え、情報資産の価値が高まってきます。特に取引先からセキュリティの状況について確認される機会も増え、一定水準のセキュリティ監視機能が求められるようになります。
このような段階では貯めているログを検索可能な状態にすることで、調査能力の向上や部分的な検知を実現出来るようになります。ログはなるべく集約して検索できる状態にするのが望ましいですが、そこまでが困難であればログごとに保存・検索形式を分離しても良いでしょう。重要なのはどこにどのようなログが保存されており、どうやって検索するかを把握しておくことです。
このようなログの検索ができるようになると、何かあったときの調査が捗るだけでなく、定期的にログをチェックするなどの業務もできるようになります。これによって、効率的ではないものの、一定の検知能力を持つことができるようになります。
Lv3：アラートを検知する
✅️ このアドベントカレンダーではLv3以降を想定した内容となります。
- 調査能力：◎
- 検知能力：◯
エンタープライズといったフェーズまでくると、組織のドメインに合わせた検知能力を実装するのが望ましいでしょう。ここでは自動的にログを分析し、不審な挙動などをシステムをまたがってアラートとして検知できるような機能が必要になります。
この段階まで来るとログは集約化したほうが良いでしょう。ログの集約化によって、ログの検索性が向上し、アラートを検知するための基盤を構築しやすくなります。ログが分散していると、ログの突合が困難になったりアラート検知のための仕組みを複数持たなければならなくなります。またログの保全なども統一した仕組みで運用したほうがコストを抑えられるため、この段階で集約化を検討するのがおすすめです。
アラートの検知を自動化することで、セキュリティ監視の効率化が図れます。具体的には検知までの時間が短縮され、対応できるアラートの幅が広がり、検知のための工数が削減されることが期待できます。ただし一方で、アラートの検知には誤検知が発生する可能性があるため、検知したアラートに対して適切な対応を行うための体制を整えることも、この段階では重要になってきます。
Lv4：ログの分析能力を持つ
- 調査能力：◎
- 検知能力：◎
Lv3の段階でアラートを検知する機能を持ったあとは最終形として、人間がより高度な分析をしてアラートを見つけられるようにします。これはいわゆるSOC（Security Operation Center）の機能に近いもので、専門のチームを組織し体制を作ります。セキュリティアナリストがログを分析（Threat Hunting）し、新しい脅威を見つけたり検知を効率化する、という機能を持ちます。
この体制を維持するためには人員・システムともにかなりのコストを要するため、数千人〜数万人規模の企業が対象となるでしょう。ただし、このような体制を持つことで、セキュリティ監視の成熟度を高めることができ、より高度な脅威に対応することができるようになります。
まとめ
セキュリティ監視基盤をいつから始めるべきかについて、組織の脅威・リスク分析を行い、セキュリティ監視にかかるコストを考慮することが重要です。また、段階的にセキュリティ監視機能を導入することで、組織全体のセキュリティ対策の水準を上げることができます。セキュリティ監視基盤を導入する際には、組織のニーズやリスクに合わせて段階的に機能を導入し、運用コストを抑えながらセキュリティ監視の成熟度を高めていくことが重要です。
Discussion