インシデントレスポンスのためのセキュリティ監視

Using modern technologies

　企業や組織を狙うサイバー攻撃はますます巧妙化してきており、被害が後を絶ちません。
『サイバー攻撃を検知するきっかけとして、各種機器のログを取得しているものの、何をどのように確認すべきかわからない』といった状況に陥っている企業も多いのではないでしょうか。

本記事では、インシデントレスポンス能力向上のために、効果的なセキュリティ監視を導入するうえで参考となるモデルをご紹介します。

SIEM／SOCとは

　各種機器のログを効果的に分析・監視し、セキュリティ侵害を検知するための仕組みとしてSIEM／SOCがあります。

　SIEM（Security Information and Event Management）とは、様々な機器のログを集約し、ログ同士を相関的に分析することで、機器単体では発見できないような不正アクセスやその兆候を検知し、分析・可視化することが出来るシステムのことです。

SIEMで取扱うログソースとしては、主にネットワーク、サーバ、エンドポイント、及びIDS/IPS、WAFに代表されるセキュリティ機器があります。

　また、SIEMを監視する組織として、SOC（Security Operation Center）があります。SIEMの監視でアラートが上がると、オペレータ、アナリスト、アーキテクトの順に連携されていきます。SOCの体制・主な役割は、一般的に図1のようになります。

図1. SOC体制、役割の例（NRIセキュアが作成）

　SOCの代表的な形態としては、『プライベートSOC』と『商用SOC』の2つに分類でき、それぞれ表1のような特徴、メリット、デメリットがあります。

表1. SOCの代表的な形態

SOC形態	特徴	メリット	デメリット
プライベートSOC	自組織のみを監視する	自組織の業務やシステム構成等の実態に合わせた細かな監視のチューニングが可能。	運用コストが高く、専門人員の確保が難しい。
商用SOC	複数の組織、業界を横断的に幅広く監視する	他組織や同業界で発生した攻撃情報を複数の組織間で連携し、横断的な監視が可能。	特定組織の業務やシステム構成等の実態を考慮した細かな監視が難しい。

　SIEM／SOCの導入にあたり、自社で実装する機能、ベンダにアウトソースする機能を検討することは、効果的なインシデントレスポンスを行う上で非常に重要になってきます。

インシデントレスポンスのモデルパターン

　SIEM／SOCからセキュリティインシデントに関する通知を受け取り、適切な対応を実施する組織（チーム）として、CSIRT（Computer Security Incident Response Team）があります。SIEM／SOCとCSIRTの組み合わせによる、インシデントレスポンスの代表的なモデルパターンとして以下の3つがあげられます。

パターン①：SIEM／SOC、CSIRT一元管理型

　自組織のみでSIEM／SOC、CSIRTを構築するモデルです。

図2. インシデントレスポンスのモデル①：SIEM／SOC、CSIRT一元管理型（NRIセキュアが作成）

パターン②：SIEM／SOC分離型

　自組織でCSIRTのみを構築して、SIEM／SOCは外部ベンダにアウトソースするモデルです。

図3. インシデントレスポンスのモデル②：SIEM／SOC分離型（NRIセキュアが作成）

パターン③：SOC分離型

　自組織でCSIRT及びSIEMを構築して、SOCのみを外部ベンダへアウトソースするモデルです。

図4. インシデントレスポンスのモデル③：SOC分離型（NRIセキュアが作成）

これらのモデルパターンとそれぞれの特徴、メリット、デメリットを表2に記載します。

表2. インシデントレスポンスの代表的なモデルパターン

SOC形態	特徴	メリット	デメリット
① SIEM／SOC、CSIRT 一元管理型	自組織のみでSIEM／SOC、CSIRTを構築するモデル。	・自組織の環境に合わせた細かな監視項目の作成が可能。・SOC-CSIRT間の情報連携が迅速。	・SIEMの導入・運用コストが高い。・セキュリティ監視の専門性を備えた人員を自組織に確保する必要がある。
② SIEM／SOC 分離型	自組織でCSIRTのみを構築して、SIEM／SOCは外部ベンダにアウトソースするモデル。	・SIEMの導入コストが不要。・セキュリティ監視の専門領域をアウトソース可能。	SOCベンダ側は商用SOCであることが多いため、自組織の環境に合わせた細かな監視項目の作成ができないことがある。
③ SOC分離型	自組織でCSIRT及びSIEMを構築して、SOCのみを外部ベンダへアウトソースするモデル。	・セキュリティ監視の専門領域をアウトソース可能。・自組織の環境に合わせた細かな監視項目の作成が可能。	・SIEMの導入・運用コストが高い。・本モデルに対応できるSOCベンダが少ない。

　自組織のセキュリティに対する考え方やコストを考慮して、最適なインシデントレスポンスのモデルパターンを選定する必要があります。

　上記の内、モデルパターン①または②は、一般的に採用する企業が多く、導入・運用の事例やノウハウも豊富です。一方で、モデルパターン③は、事例やノウハウが少なく、非常に実装の難易度が高いモデルパターンとなります。

　筆者がコンサルティングご支援をしている現場において、最近、『セキュリティ監視を外部ベンダにアウトソースして運用負荷を下げつつも、外部ベンダのデフォルト監視項目だけでなく、より自組織の環境を考慮した監視設計を実現したい。』ということで、モデルパターン③を採用するケースがありました。

　以降では、その際の知見を元に、モデルパターン③を導入する際のポイントについて、解説していきます。

インシデントレスポンスモデル③「SOC分離型」導入のポイント

前提事項

　モデルパターン③を採用するうえで、自組織固有の監視要件やSIEM構成、SOCの運用設計について、SOCベンダとどのように協調できるかが大きな課題となります。自組織だけでこれら全てを実装した後では、どのベンダにもSOC運用を受け入れてもらえない可能性が高いです。

　モデルパターン③の導入を成功させるためには、要件定義の段階から、自組織だけでなく、実際に監視運用をする立場のSOCベンダも検討に参画し、双方合意しながら密に連携してセキュリティ監視の導入を進めていくことが大変重要となります。後述する各工程（監視要件定義、SIEMの導入、SOCの運用設計）について、初期段階からSOCベンダと共に検討を進めていくようにしましょう。

監視要件定義

　セキュリティの監視要件を検討していくうえで、まずは、自組織にとってどのようなセキュリティリスクが存在するかを把握する必要があります。セキュリティリスクの例としては、以下のようなものがあります。

公開サービスへの不正アクセスによる個人・機密情報の漏洩、改ざん、サービス停止、踏み台化等
OA端末のマルウェア感染による個人・機密情報の漏洩等
内部不正による個人・機密情報の漏洩、改ざん等

　これらのセキュリティリスクに対して、何で（監視機器）どのように（監視項目）監視するのかを定義します。
　監視機器の種別について、表3に例示します。

表3. 監視機器の例

環境		監視対象機器
Webネット環境		DDoS対策サービス、FW、 IDS/IPS、 WAF、改ざん検知
OA環境	Web	FW、プロキシ(URLフィルタ、アンチウイルス)、次世代FW、振舞い検知、DNS
	メール	FW、スパム、アンチウイルス、メールフィルタ、次世代FW、振舞い検知
	エンドポイント	アンチウイルス、EDR、端末操作監視ソフト
	クラウド	SaaS API、CASB
	その他	AD（Active Directory）、リモートアクセス機器

　また、リスク・監視機器・監視項目の整理方法について、表4に例示します。

　本表を参考に、自社環境に合わせて記載頂ければと思います。

表4. リスク・監視機器・監視項目の整理例

Secure SketCH_リスク・監視機器・監視項目の整理例

　一つ一つの監視項目について、「どういった状況になったらアラートを出力するか？」という検知ロジックを検討する際は、フローチャートを作成・可視化し、共有しておくと効果的です。

例① ブラックリストへのアクセスがあった場合

　振る舞い検知ログから特定される怪しい挙動のURL・IPや、外部情報などからアクセスを拒否すべきURL・IPについて、ブラックリストとして記録する。
　URLフィルタやFWのログから、当該ブラックリストへのアクセスがあった際に、アラートを出力する。

Secure SketCH_検知ロジック_ブラックリストへのアクセス監視

図5. 検知ロジックフローチャート例①アクセスログとブラックリストの相関監視（NRIセキュアが作成）

例② 大量の認証失敗後に認証成功した場合

　ADのログから、大量にログインを試みて認証に失敗したユーザのIDをブラックリストとして記録する。
　ブラックリストにあるユーザIDが認証を成功させた際に、アラートを出力する。

図6. 検知ロジックフローチャート例②ユーザが大量の認証失敗後に、認証成功した場合を検知

（NRIセキュアが作成）

SIEMの導入

　セキュリティ監視要件が定まった後は、当該要件に沿って監視をするために、SIEM機器の選定、構築を行います。その際に、表5のような項目を検討します。

表5. SIEM導入時の主な検討項目

検討項目		ポイント
監視項目		デフォルトの監視項目、チューニング可否
処理性能		・単位時間あたりの受信可能ログ量・アクセス先IP、URL等のログの分析・検索速度・定型レポートの作成速度
ディスク容量		・オンライン／オフラインのログ保存容量・ログ保存領域の拡張性
耐障害性		・冗長構成・SIEM関連の設定ファイル、ログのバックアップ運用・メーカ保守体制
非機能要件		・SIEM自身のセキュリティ堅牢性・監視用コンソールの設計

SOCの運用設計

　SIEMの構築やテストと並行して、SOCの運用設計も検討する必要があります。『セキュリティ監視運用の全体像』を図7に表します。

Secure SketCH_セキュリティ監視運用の全体像

図7. セキュリティ監視運用の全体像（NRIセキュアが作成）

　図7に記載の『SOC運用における主な業務区分・概要』について、表6に記載します。

表6. SOC運用における主な業務

業務区分		概要
アラート監視		アラートの検知及び SOC-CSIRT間での情報共有
分析		・検知したアラートの傾向を時系列で分析。・攻撃内容・自組織への影響の特定。
調査		外部機関から提供される脅威情報による過去ログ調査、影響の特定。
定期報告		直近で発生したインシデントの日時・事象・影響・対応方針・現在のステータス、検知傾向、監視改善提案等に関する定期的なCSIRTへのレポート報告。
インシデント管理		SOAR（Security Orchestration and Automation Response）等を活用したインシデントのステータス管理。
監視体制維持		・SOC監視メンバの時間帯によるローテーション管理。・オペレータ、アナリスト等のメンバへの定期的な教育・訓練。
SIEMの機能維持管理		サイバー攻撃に関する情報、脆弱性情報等の外部からの脅威情報を元に、検知ロジックやその閾値、ブラックリスト等をチューニング。

おわりに

　本記事では、セキュリティ監視を導入するうえで参考となるモデルについてご紹介しました。今後、セキュリティ監視を導入検討する企業は、是非参考にして頂ければ幸いです。

　セキュリティ監視は、一度導入して終わりではありません。セキュリティリスクやサイバー攻撃手法は日々変化しており、それに応じた新たな監視機器・機能の追加、SIEMのセキュリティ監視要件の見直し、人員強化等を継続的に行うことで、導入効果をより高めていくことが重要です。