4回にわたり，トレンドマイクロでサポート・エンジニアを務めてきた平原氏が体験した事例の回想と合わせ，セキュリティ・インシデント発生時のノウハウを紹介してきた。最終回の今回は，筆者の平原氏に過去のインシデント対応を振り返ってもらうとともに，日々のシステム運用に携わる担当者にとって有益であろう長期的な視点でのセキュリティ・オペレーションの考え方と手法について聞いた。
A社のインシデント回想記は，非常にドラマチックなストーリーでした。このように波乱万丈なケースは，まれなのでしょうか。
 |
| 写真1●トレンドマイクロ サポートサービス本部 スレットモニタリングセンター マネージャーの平原伸昭氏 （写真：皆木優子） |
もちろん，今回の連載特集で紹介した事例は実話ですし，私自身のミスも含めて，読者の方に現場の空気を感じていただけるように包み隠さず書いたつもりです。
セキュリティ・インシデントの現場は，システム管理者にとってごく短い時間で重要な判断を次々と迫られる非常に過酷なものです。刻一刻と変化する状況に合わせ，それまでと180度の方向転換をせざるを得ないこともありますし，一定の犠牲を覚悟しなければいけない苦汁の決断を求められることもあります。そんな苦境を顧客企業と一緒に乗り越えて，A社のように無事解決に導けたときはサポート・エンジニアとして無上の喜びでもあります。
セキュリティのプロとして現場でサポートを続けてきた私には，これまで経験したインシデントの一つひとつがプロ野球の名シーンのように心に刻まれています。
逆に平原さんが対応した中で，緊急対応が上手くいかなかったケースはあるのでしょうか。
残念ながら上手くいかず，インシデントが長期化してしまったこともありました。インシデント対応の中で出くわす決断の分岐点で誤った方向を選択することや，組織的な問題で重要な決断ができないまま状況だけが悪化していく苦いケースも経験してきました。
セキュリティ・インシデント発生時に，知恵と体力を最も使うのはシステム管理部門です。しかし，システム管理部門だけでは上手くいかないことがあります。上長や経営層に対して，今起こっている事態がどの程度の損失を招くものなのか，またどの程度の投資によって最小化できるのかを説くことで全社的な協力体制をリードすることも必要です。
乱暴な計算ではあっても，インシデントによる被害額を想定することで「見える化」が可能になります。例えば，年間売り上げ300億円，240営業日の企業において，全クライアント数1000台のうちの20％が不正プログラムに感染し，そのコンピュータ上での業務がストップしたと仮定します。その場合の暫定被害額は，6時間のダウン時間で1874万円に達してしまいます。もしインシデントが72時間に及ぶと，被害額は計2億2492万円にも達する計算になります（図1）。
なお，実際のビジネスへの影響として，ここにインシデント対応に伴うエンジニアの人件費や，社会的信用度の失墜による株価下落，風評被害が加わります。
 |
| 図1●インシデントの暫定被害額の計算の仕方 |
今回の事例は24時間の集中的な対応でしたが，企業のシステム管理者は継続的にセキュリティを考える必要があると思います。セキュリティにかかわる総合的なオペレーションについて，システム管理者はどのような考え方をすればよいのでしょうか。
総合的なセキュリティ・オペレーションには，SOAP（ソープ）という考え方を勧めたいと思います。ここで言うSOAPとは，IT系の読者の皆さまに馴染みが深いXMLとHTTPなどをベースとした，他のコンピュータにあるデータやサービスを呼び出すためのSimple Object Access Protocol（SOAP）のことではありません。「Subject data」「Objective data」「Assessment」「Plan」の頭文字を取った，医療の世界でのSOAP方式のことです。「第3回 敵はファイル感染型！トリアージで修復端末の優先度を決めろ」で，災害医療などの際に負傷者を重症度，緊急度によって分類する「トリアージ」の考え方を紹介したように，医療の手法はITのインシデント対応の参考になる例が多いように感じます。
SOAP方式は看護学において「問題志向システムに基づく診療記録の叙述的経過記録の記載方式で使用される」とあります。叙述的経過記録とは，患者の解決すべき問題がどのような経過をたどりながら解決されていったかを記録するものであり，問題解決を行う方法を見出すためのプロセスと言えます。4つのステップから成り立っており，日本看護協会出版会による看護学辞典から引用すると次のように説明されています。
- 問題に関しての患者および家族が直接提供する訴えなどの主観的情報（Subjective data; S）
- 観察や検査などにより医師や看護者などの専門職が取り出す客観的情報（Objective data; O）
- （1）と（2）を分析して，その問題が解決に近づいているか否かを判断する（Assessment; A）
- （3）に基づいて行った計画の実施，計画の続行，修正の有無（Plan; P）
なるほど，ただ病気から回復するだけでなく，健康を継続する意味で看護の考え方が応用できるのですね。これをITの現場に当てはめると，具体的にはどうなるのでしょうか。
（1）の「主観的情報の収集」は，管理者や社内ユーザーの状況を傾聴することに当てはめることができます。今回の事例においては，M氏が最初の電話で伝えた「いくつかの業務アプリケーションにおいて起動不可になるアプリケーションや，起動はするが途中でエラー・メッセージが表示されて終了してしまうアプリケーションがある」との説明や（第1回を参照），私がA社に到着直後，M氏がホワイトボードを使って説明したシーン（第2回を参照）などが該当します。
（2）の「客観的情報の収集」は，SIC（シック）ツールやネットワーク・プロトコル・アナライザといった情報採取ツールを使用して私が実行した情報収集活動です（第2回を参照）。
（3）の「情報の分析」とは，（1）と（2）で収集した双方の情報を分析することです。（2）で収集した情報の分析に関しては，セキュリティ・ベンダーに任せるのが一般的でしょう。ただし，不正なプログラムさえ特定できれば，不正プログラムの解析手法の一つである動的解析手法を使って，アクセスするURLや通信に使うポート番号などをユーザー自身が確認することもできます。
動的解析手法とは，実際に検体を動作させてプログラムの動作を確認する手法であり，ブラックボックス・テストとも呼ばれているものです。この手法は，アプリケーションのデバッグ経験やトラブル・シューティング経験があれば，比較的短期間に習得できる技術であり，セキュリティ・インシデントの感染被害の最小化や局所化を行うのに有効だと思います。
（4）の「問題解決のための計画立案と実行」は，（3）で得た情報を基にして，感染被害の最小化・局所化，修復作業を展開することです。そして，事後の対応も含まれます。喉元過ぎれば熱さを忘れるではないですが，とかくセキュリティ・インシデントは事後の見直しがなされていないことが多いのが実情ではないでしょうか。
