SOCを例としたインシデント対応のポイント：ネットワーク運用におけるセキュリティ（1/3 ページ）

今回は、SOCを運用してきた立場から、インシデント対応についての考え方やポイント、心構えを紹介しよう。

[徳田敏文、高橋正和，ITmedia]

　インシデントというものは、こちらの都合には合わせてくれない。システムが稼動している限り、24時間、365日の体制を必要とする。だが、ITやセキュリティを本業としない通常の企業がこのような体制を取った場合、人件費だけでも莫大なコストになってしまう。このため、ネットワークやセキュリティオペレーションのアウトソースビジネスを利用するケースが増えている。

　ここでは、前回のセキュリティに対する考え方を踏まえたうえで、インシデントの監視／対応のプロであるSOC（Security Operation Center）を運用してきた立場から、インシデント対応についての考え方を紹介する。

SOC運用におけるインシデント対応

　SOCの運用においてインシデント対応を行う場合に最も重要なことは、「何がインシデントか」を明確に定義し、周知することだ。たとえエスカレーションフローを整備しても「連絡が遅れる」「機能していない」と評価される場合、現場のエンジニアやオペレータが「今起きていること」をインシデントとして認識していないことに起因することが多い。

　システムが事象をインシデントとして自動的に通知してくれるIDS／IPSやNMS（ネットワーク管理システム）などは、インシデント対応のトリガとしてわかりやすい。しかし運用におけるインシデントとはそれだけではないはずであり、さまざまな要因をあらかじめ想定しておくことが重要だ。たとえば、SLA（Service Level Agreement）に基づいてサービスを提供しているならば、SLA違反に発展する可能性がある場合、そうでなくてもサービスレベルの低下が予測される場合はすべて「インシデント」として対応を始めるべきである。

　インシデント取り扱いの判断の基準として、あらかじめ図1のようにインシデントのレベルや種類を整理しておくと、担当者による判断のばらつきを少なくすることができる。

インフラ 障害レベル高 （顧客へ提供するサービスが停止する障害） 統合監視・管理システムの障害 SOC⇔データセンター⇔インターネットの通信障害 プライマリ側インフラ機器／サーバの障害 SOCルームの停電 施設内への不審者の侵入 災害によるサービス停止 障害レベル中 （提供サービスの品質低下を伴う障害） 死活監視システムの障害 ユーザーポータルの障害 セカンダリ側インフラ機器／サーバの障害 運用データベースの障害 メール／FAXサーバの障害 電話回線の障害 障害レベル低 （提供サービスに影響がない障害） 機器設定情報ファイルサーバの障害 インフラ機器の再起動 監視コンソールPCの障害 SOCプロジェクターの障害

デバイス 障害レベル高 （顧客へ提供するサービスが停止する障害） FW-OS・IDS-OS再起動発生 RSKill/Dropレスポンスによる顧客通信障害の可能性がある場合 顧客デバイスの障害（顧客通信に障害が発生した場合） 複数センサーの停止（アップデートファイル適用不具合） IDS/IPSの危険度判定で高危険度と判断された場合（侵入など） 社内からのワーム拡散 障害レベル中 （提供サービスの品質低下を伴う障害） 顧客デバイスの障害（顧客通信に障害がない場合） 顧客デバイスのデーモンリスタート 顧客サイトからのワーム拡散 障害レベル低 （提供サービスに影響がない障害） 顧客デバイスのリソース高負荷（提供サービスに影響がない場合）

サービス 障害レベル高 （顧客へ提供するサービスが停止する障害） SLA違反 顧客からのクレーム FWルール適用間違い 誤って他顧客のOSを再起動した場合 メール送信ミス等顧客情報の漏洩、取り違えによるセキュリティ事故 5分以上監視サービスが停止する状況が発生した場合 障害レベル中 （提供サービスの品質低下を伴う障害） ポータルサイトへフェッチができない場合 事故、病気などによる欠員の調整 IDSルール適用間違い 障害レベル低 （提供サービスに影響がない障害） 問い合わせ対応の長期化（3回以上）

図1●判断基準の一例（出典：インターネット セキュリティ システムズ）

　また、この基準に照らし合わせてエスカレーションフローも明確にしておく。エスカレーションフローを作成する場合は、連絡方法と「連絡までの時間」を明記しておくことが何より重要だ。