第5回「インシデント対応は“SOAP方式”で」---現場で戦った筆者の平原氏に聞く：ITpro

ひげの人です（ぇ

平原さんでもうまくいかないケースはもちろんあって、難しい判断を下さないといけない事も多く、失敗もあるとの事。

まぁ当然といえば当然ですし、お願いする企業側も一部の部門だけ突っ走っていてもだめで、周りの協力は必須ですね。

逆に平原さんが対応した中で，緊急対応が上手くいかなかったケースはあるのでしょうか。

残念ながら上手くいかず，インシデントが長期化してしまったこともありました。インシデント対応の中で出くわす決断の分岐点で誤った方向を選択することや，組織的な問題で重要な決断ができないまま状況だけが悪化していく苦いケースも経験してきました。
セキュリティ・インシデント発生時に，知恵と体力を最も使うのはシステム管理部門です。しかし，システム管理部門だけでは上手くいかないことがあります。上長や経営層に対して，今起こっている事態がどの程度の損失を招くものなのか，またどの程度の投資によって最小化できるのかを説くことで全社的な協力体制をリードすることも必要です。

こういう計算は本当に必要、経営層や上層部を動かす原動力になりますので。

先行してこういう計算をしておけば、事前に対策も予算化できるんですけど、、、あんまりやられてないですよね。

乱暴な計算ではあっても，インシデントによる被害額を想定することで「見える化」が可能になります。例えば，年間売り上げ300億円，240営業日の企業において，全クライアント数1000台のうちの20％が不正プログラムに感染し，そのコンピュータ上での業務がストップしたと仮定します。その場合の暫定被害額は，6時間のダウン時間で1874万円に達してしまいます。もしインシデントが72時間に及ぶと，被害額は計2億2492万円にも達する計算になります

SOAP方式やトリアージなど色々ありますが、

SOAP方式は看護学において「問題志向システムに基づく診療記録の叙述的経過記録の記載方式で使用される」とあります。叙述的経過記録とは，患者の解決すべき問題がどのような経過をたどりながら解決されていったかを記録するものであり，問題解決を行う方法を見出すためのプロセスと言えます。4つのステップから成り立っており，日本看護協会出版会による看護学辞典から引用すると次のように説明されています。
1. 問題に関しての患者および家族が直接提供する訴えなどの主観的情報（Subjective data; S）
2. 観察や検査などにより医師や看護者などの専門職が取り出す客観的情報（Objective data; O）
3. （1）と（2）を分析して，その問題が解決に近づいているか否かを判断する（Assessment; A）
4. （3）に基づいて行った計画の実施，計画の続行，修正の有無（Plan; P）

具体例ですが、現場の正しい情報を集めることも本当に必要。

それも、同じ条件で色々調べてもらうことが必要ですね。

（1）の「主観的情報の収集」は，管理者や社内ユーザーの状況を傾聴することに当てはめることができます。今回の事例においては，M氏が最初の電話で伝えた「いくつかの業務アプリケーションにおいて起動不可になるアプリケーションや，起動はするが途中でエラー・メッセージが表示されて終了してしまうアプリケーションがある」との説明や（第1回を参照），私がA社に到着直後，M氏がホワイトボードを使って説明したシーン（第2回を参照）などが該当します。
（2）の「客観的情報の収集」は，SIC（シック）ツールやネットワーク・プロトコル・アナライザといった情報採取ツールを使用して私が実行した情報収集活動です（第2回を参照）。
（3）の「情報の分析」とは，（1）と（2）で収集した双方の情報を分析することです。（2）で収集した情報の分析に関しては，セキュリティ・ベンダーに任せるのが一般的でしょう。ただし，不正なプログラムさえ特定できれば，不正プログラムの解析手法の一つである動的解析手法を使って，アクセスする URLや通信に使うポート番号などをユーザー自身が確認することもできます。
動的解析手法とは，実際に検体を動作させてプログラムの動作を確認する手法であり，ブラックボックス・テストとも呼ばれているものです。この手法は，アプリケーションのデバッグ経験やトラブル・シューティング経験があれば，比較的短期間に習得できる技術であり，セキュリティ・インシデントの感染被害の最小化や局所化を行うのに有効だと思います。
（4）の「問題解決のための計画立案と実行」は，（3）で得た情報を基にして，感染被害の最小化・局所化，修復作業を展開することです。そして，事後の対応も含まれます。喉元過ぎれば熱さを忘れるではないですが，とかくセキュリティ・インシデントは事後の見直しがなされていないことが多いのが実情ではないでしょうか。

Web脅威を発見した場合は、すぐにパターン配布より前に、情報からプロキシで止めるのが一番良いでしょうね。

URLフィルタを入れる前から、Squidでこの方式良くやっていました。（情報漏洩型のやつね）

新たな「Webからの脅威」に遭遇してしまったのですが，すぐに収束させることができました。

参考までにその経緯を紹介します。
まず感染発見後，すぐにプロキシ・サーバー上での不正ドメインのブロックを行い，マザーウイルスからの連続的なダウンロードを防ぎ，感染被害の最小化を試みました。すると，この企業の別拠点においても，別の改ざんされた正規サイトから新たなマザーウイルスがダウンロードされ，もう一度，感染拡大の危険が高まりました。そこで，不正ドメインのブロックに加え，業務に必要不可欠でかつ安全なサイトと事前に確認されたサイトにのみアクセスを制限するという対策を施しました。この対策が好を奏し，セキュリティ・インシデントに応対しつつもビジネスを継続することができたそうです。