CSIRT/SOCは標的型サイバー攻撃の有力な“砦”
効果を最大化する構築・運用のポイントとは

現在、CSIRT/SOCを構築もしくは構築を検討している企業が増えています。その一方で構築を躊躇したり、構築しても運用できていない企業も多く存在します。構築・運用を阻む問題とは――。そしてその解決法とは――。CSIRT/SOCの構築・運用を数多く手がけているトレンドマイクロの佐山 享史が、現場で得た知見をもとにCSIRT/SOCを適切に構築・運用するためのポイントを解説します。

本稿は2014年11月21日に行われた情報セキュリティカンファレンス「Trend Micro DIRECTION」のセッションの採録です。

CSIRT/ SOCの構築・運用を阻む“壁”とは

「深刻化するセキュリティリスクを低減する仕組みとしてCSIRT/SOCの注目が高まっています。背景にあるのが、従来型のセキュリティ対策だけでは防ぎきれない標的型サイバー攻撃の増大です。内部犯による情報漏えいリスクも懸念されるため、『侵入を前提』とした対策としてCSIRT/SOCを導入する企業が増えているのです」。登壇したトレンドマイクロ スレットディフェンスSE本部 エンタープライズSE部 産業SE課 佐山 享史は、このようにCSIRT/ SOCのニーズが高まりつつある現状を示しました。

SOC(Security Operation Center)とはセキュリティデバイスやサーバのログを監視し、インシデントを発見する組織の総称。危険がないかを常時監視する「警備員」の役割を担います。一方のCSIRT(Computer Security Incident Response Team)はインシデントの対応を行う組織の総称。危険が発生した時に活動する「火消し役」です。

しかし、CSIRT/SOCのニーズが高まる一方、導入に二の足を踏む企業も少なくないといいます。「SOCの場合はコストの観点と組織・技術的な観点が大きなネックになっています。『コストをかけて専用のシステムを導入しても費用対効果が見えない』『ログを分析できる技術者がいない』『24時間365日のオペレーションが困難』などがその理由です」(佐山)。構築しても、効果の可視化や担当者への負荷といった運用面に課題を抱える声も少なくありません。

CSIRTに関しては、情報セキュリティ委員会との違いがわからないというように、早期の必要性を感じない声も聞かれます。運用面では、必要な情報が適切にエスカレーションされないことなどで頭を悩まされている企業も見られます。「情報がエスカレーションされなければ、適切な対処は困難です。逆に携帯電話の紛失など困ったことがあると何でもエスカレーションされ、煩雑な作業に振り回されるケースもあります」と佐山は指摘します。

目的を明確にし「効果の可視化」を図ることが重要

CSIRT/SOCがバズワードにならないためには、こうした構築・運用上の課題を解決することが重要です。
「まずSOCに関してはオペレーションセンターを作ることではなく、モニタリング機能を作ることを検討することが大切です。その際、自社の技術力や人的リソースを考え、範囲を限定して、効果が見えやすいものから始めるのも一つの手。例えば、ウイルス対策のモニタリングで感染傾向や攻撃の傾向を把握するのも、広い意味でSOCの機能の一部です」と佐山は説明します。

さらに「効果の可視化」に取り組み、費用対効果を目に見える形で示すことも重要なポイントです。「効果測定の指標として『インシデントの被害額を算定し、対応した実績を計算する』『インシデントによる業務稼働率の低下を算出し、対応した実績を計算する』などの方法が考えられます。具体的なリスクを想定し、対応によりどの程度の被害軽減が可能になるかを数値化すると効果がわかりやすくなります」(佐山)。

CSIRTについては、前提として目的を明確にすること。何のためにCSIRTが必要であるかをしっかり把握することが重要です。「CSIRTは緊急対応を行う組織。既に実施しているのであれば『できている』ことを明文化する必要があります。CSIRTと同等の対応ができていれば、CSIRTとして体制を作り直す必要はありません。できていない場合は、対象となるシステムや脅威、インシデントの範囲を定義し、スモールスタートで始めるのが効果的です。また対応基準をしっかり作り、エスカレーション方法など社内教育を継続的に行うことも欠かせません」と佐山は言います。

CSIRTの対象範囲の特定例

対象システム、脅威、インシデントなどのスコープを定義した上で、対象システムにおいて何を脅威とし、インシデントに対してどのように対処するかを明確化します。

CSIRTの対応基準の設定例

インシデントの種別により「低」「中」「高」などの対応基準を設定。具体的にどのようなアクションを行うかをあらかじめ定義します

CSIRT/SOCの効果を高める技術・製品の活用に目を向けることも大切です。その1つが、SOCにおけるログ分析。OSやアプリケーションの動作ログは、これまでインシデント発生時の調査に使われるケースが多くみられましたが、最近は常時監視することで、攻撃の兆候を見つけ、インシデントの早期発見に役立てようという考え方が広まりつつあります。

攻撃の兆候をみつけるためには、ログやアラートの分析、またこうした情報を相関分析する方法があります。ログ分析ではトリガーとなるアラートを見つけ出すことが重要になります。「ログを見るだけでなく、不正URLとの照合、過去にアラートのあった不審なアカウントとの照合などが有効な手立てとなります」と佐山は述べます。アラートの場合、その危険性と影響有無を判断することがポイントになります。相関分析では、アラートをトリガーに関連するログを調査します。これにより、より詳細な影響度が判断できます。

こうした相関分析については、製品を利用することも有効です。たとえばWebサーバを改ざんし、不正プログラムをダウンロードさせるような攻撃の場合、ネットワーク型監視センサー※1でexeファイルをアップロードする通信を検知し、さらにホスト型監視センサー※2ではファイル改ざんを検知する。2つのアラートを相関分析することで、危険と判断できるのです。

SIEM(Security Incident Event Manager)の活用も有効です。SIEMはログやアラートを収集し、分析・管理を自動化するツール。SOCのオペレーションを効率化し、手動でログ分析する場合に比べて調査工数の大幅な削減を期待できます。「ただし導入するだけで、分析方法が分からなければ、その効果も期待できません。SIEMの効果を高めるには『何を』『どう』分析するかポリシーを明確にし、運用に反映することが大切です」と佐山は訴えます。

ログ分析オペレーションのワークフロー

SOCにおける効果的なログ分析を行うには初動分析やインシデント調査など段階的なオペレーションが必要。この中で初動分析とインシデントの一次調査はSIEMによる自動化の効果が表れやすい部分です。SIEMに関しては「何ができるか」を考慮した上で導入することが大切です

「SOCに関してはインシデントを早期に発見することに主眼を置き、組織・体制の構築を目的とせず、インシデントを発見する機能の構築を最重視します。『効果の可視化』に向けた指標づくりや合意形成を目指すほか、効果的なログ分析や運用のためにはSIEMや外部サ―ビスの利用することも有効でしょう」(佐山)。

打開策として外部サービスの活用も視野に

このようにCSIRT/SOCが適切に構築・運用されれば、標的型サイバー攻撃に対処する上で非常に有効です。しかし、自社内の技術力や人的リソースだけでCSIRT/SOCの構築・運用定着を図るのは容易ではありません。その場合は外部サービスの活用も視野に入れるとよいでしょう。選択肢の1つとなるのが、トレンドマイクロの「CSIRT/SOC構築・運用支援サービス」です。構築から、構築後の監視運用、インシデント対応まで一気通貫した支援を提供できることが特長です。たとえば、インシデント特定後の対応に不安を抱えているお客様で、このサービスとウイルスバスター コーポレートエディションなどトレンドマイクロ製品をご利用されていれば、攻撃/インシデントを発見後、その脅威情報をトレンドマイクロにお送りいただくことで、パターンファイルへの迅速な反映、駆除までをご支援できます。

CSIRT/SOCがバズワードとなるか定着ワードとなるかは、適切な構築・運用スキームを実現できるかどうかにかかっています。「体制の構築がゴールではないが、CSIRTを設置することで、外部CSIRTと情報共有できるなどのメリットがあります。一方でSOCの目的はインシデントを発見する機能を作ることです。いずれも、『効果の可視化』に向けた指標づくりや経営陣との合意形成により適切な運用が可能になるでしょう」(佐山)。標的型サイバー攻撃のような脅威が猛威を振るう昨今、SOCで検知した脅威の兆候やインシデントを迅速にCSIRTに報告し、CSIRTでは原因の特定から対応を行う、対応後にはナレッジをSOCに共有する、これを繰り返すことで、組織としてのセキュリティが向上するでしょう。

トレンドマイクロではCSIRT/SOC構築・運用の支援のほか、トレンドマイクロ製品導入後、安心して運用を行っていただくためのご支援もしています。詳しくはこちら

※1 トレンドマイクロの対応製品 Deep Discovery Inspector
※2 トレンドマイクロの対応製品 Trend Micro Deep Security

記事公開日 : 2015.01.15
 この記事は、公開日時点での情報です