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

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

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

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

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

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

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

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

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

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

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