（3） システム利用の監視
7月23日時点での警察の調査によれば、犯人は2013年4月ごろからデータを盗もうと思っていたが、セキュリティが厳しくて実行ができず、2013年7月頃にスマートフォンの接続ができたことを機にデータの不正持出しを始め、名簿の事業者（safety）に売却したということです。
今回の事件が発覚したのは、6月下旬頃からベネッセコーポレーションから流出したデータを利用した、ジャストシステムのダイレクトメール送付が原因でした。それを一部の顧客が気付き、ベネッセコーポレーションに報告することで事件が発覚しました。もしも顧客からの通報がなければずっと気づかなかったままだとすると、そこに大きな問題があると考えられます。
情報セキュリティにかぎらず、事故は発生してからそれに気づくまでの期間が長ければ長いほど事故の影響は大きくなる傾向があります。1年間も放置されていたとすると、今回の犯人だけではなく、他の技術者にも犯行に及ぶ機会があったのではないかと邪推してしまいます。
筆者が社内犯罪の調査を依頼された時には、その可能性も含めて調査しています。そして、被害の全体像を把握しておかないと、対策を行っても後から被害が大きくなり、収集がつかなくなってしまうからです。事故に気づいたら、その時点で被害がこれ以上大きくならないように「封じ込め」をし、被害の全貌を把握するのが事故対応（インシデントレスポンス）の初動ということになります。
今回の事件はすべてシステム上で起こっています。ですから、システム監視だけで防ぐことができたかもしれません。防ぐことができなかったとしても、すぐに気がつけたかもしれません。まずは（1）管理者権限でその制限を解除し、（2）データをダウンロードします。次に（3）外部メディアにコピーし、（4）外部に持ち出します。
この（1）～（4）のうちの（3）までに気がつけば事件にはなっていなかったと考えることもできます。（4）の時点で気がついてすぐに対応ができれば、名簿業者にデータはわたらなかったかもしれません。
このように事故（インシデント）につながる小さな事象（イベント）ごとに監視することが重要です。
これらの事象をログにとっておくだけでは十分ではありません。なぜなら、今回の（1）から（4）までは期間を置かずに実施できるからです。この一連のイベントが実行されるまでに気づかなければいけないからです。
業務監視の必要性
データをダウンロードしようとするとアラートが出る仕組みになっていたということですが、これは牽制でしかありません。違反であることを通知しているだけで、それが実行されたということを把握しているのは実施者だけになってしまいます。
もしもアラートが出る仕組みになっているのだとしたら、そのアラートが出たことをさらに上位の管理者に伝える必要があります。それもリアルタイムに報告し、それが故意であったのかどうかを確認しなければいけません。アラートが出ているにもかかわらず、それを見逃してしまうことが大きな問題となります。
どのような事象についてアラートを出して上位に報告するのか、どのような事象をログに残しておくのかなどをシステム構築の段階で検討しておく必要があります。これができていなければ、事故にいち早く気がつくことができないでしょう。
事故にいち早く気がつくことができるシステムにするためには、システムの統合が必須です。ただし、巨大なシステムにしてしまうと改善が難しくなってしまいますので、サービスごとに開発し、ID管理やログ管理、アラート管理などをベースにしてシステムを統合するという方針で、再設計することが望ましいといえるでしょう。
今回のベネッセコーポレーションの例では、グループ会社で利用できるコミュニティクラウドを構築し、IDの発行やそれぞれのアカウントの振る舞いなどをグループ会社もしくはそのサービスの主体が把握できるような体制にしていくことが望ましいのではないかと考えます。
