遡ること11年前2008年９月30日、事件は起きました。もう11年も経ったのかというのが、今の率直な感想です。今振り返っても私のIT業界のキャリアの中で心身ともに壊滅的なダメージを受けた経験でもあり、後のCTOとしてのキャリアの第1歩でもあったセキュリティ事故でした。2008年の6月にITの責任者に就任し3か月後の出来事でした。
当時のセキュリティ事故のほとんどはSQLインジェクションやクロスサイトスクリプティング、CSRFを中心とした改ざん、情報漏洩でした。弊社のセキュリティ事故では、SQLインジェクションによる会員情報を保持していたデータベースの一部を改ざんされ、弊社が配信していたメールマガジンの一部に悪意のあるサイトへのリンクが埋め込まれるといった内容でした。実際の事故は9月30日に発見されたのですが、実は予兆があり、事故の数か月前にも不正アクセスと思われるトランザクションを検知していました。そこで付け焼刃のIDSの導入に踏み切り、まさに運用を開始したその時でした。幸いにして分かりやすい改ざんであったことやIDSでの検知がされたため、障害検知はかなり早いタイミングでできました。問題は障害を検知してからでした。
セキュリティ事故が発生したときに真っ先に行うのが、事象の把握と影響調査です。「どこに」「何が」「どのくらい」といった基本的な影響調査を行うわけですが、当時の弊社はアプリケーションの作りは開発者に依存し開発者でも分からないソースコードも存在していましたし、ドキュメントはなく、まさに影響調査を行うことなど至難の業でした。
これが今回のテーマのメインでもありますが、セキュリティ対策の肝は、当然、侵入されない（されにくくする）事は重要ですが、ことセキュリティ対策においては性悪説に立った対策が必要です。つまり、入り口の壁を高く頑丈にしても、悪意のある者が本気を出せば入口の壁などないに等しいと思うことです。泥棒もそうかもしれませんが、不正アクセスにも順番があります。入り口に穴がないかの調査をまずは行います。侵入したら気付かれるのか。侵入に対する難易度を測るわけです。入口に穴があり侵入可能となると次は家の中に何があるのか探ります。金目の物や目的の物がなければ単なる侵入に過ぎず、侵入者もリスクしかありません。
金目のモノや目当てのモノが見つかると、次に逃走経路を探ります。逃走経路にわざわざ痕跡を残したり逆探知されるようなマネはしません。そうやって侵入から情報漏洩につながるわけです。
