─ 具体的には、どのような事故を前提として考えておくべきでしょうか?

西本●では、実際に発生した事故を見てみましょう。下のグラフは、LACが2008年に緊急対応にあたった企業で発生した事故の統計データです。

（クリックで拡大）

「原因と手口」は、全体の41%がSQLインジェクション、15%がボットでした。

「被害内容」に目を向けると、情報漏えいと情報窃取で約半分です。主に過失・紛失が原因で情報が漏れたのが「情報漏えい」で、SQLインジェクションやボット感染が原因で情報が盗まれたのが「情報窃取」です。

（クリックで拡大）

─ SQLインジェクション攻撃の増加で、どうしても外部からの攻撃者に目が行ってしまいますが、内部犯行も比較的多く発生しているのですね。

西本●ええ、そうですね。内部犯行は、昔からコンスタントに発生しています。

競合に出し抜かれることが増えて何かおかしい、と気付いた社長からの依頼調査の例では、競合会社に転職した社員が、共用アカウントを利用して外部から侵入し、メールやサーバーをすべて盗み見ていたという事件もあります。

上層部しか知り得ない業務上の機密が漏れていた例では、ある上司のパソコンのハードディスクを、自分のパソコンにマウントしていた部下がいて、そこから情報が漏えいしていたケースもあります。部下は魔が差しただけかもしれませんが、パソコンの設定を部下にお願いしていた上司の問題でもあります。これは上司が部下を犯罪者にしてしまった例です。

また、出入りの業者が勝手に別のネットワークを作っていて、そこから情報が漏えいしていた事件もあります。

─ 実際の事件・事故の話を聞くと、ITだけでは予防しきれないものもありますし、人間の感情が引き金になっているものもありそうです。

西本●ええ、そのとおりです。事故前提で想定しておくべき脅威には、以下のようなものがあります。

「内部犯行」、特に「故意の内部犯行」に対する重要なことは、犯罪をエスカレーションさせない仕組みを作ることです。内部犯行が発生する組織というのは、監視が行き届いていなくて、犯罪がエスカレーションしてしまう傾向があります。上司には監督責任がありますから、部下が犯罪を犯すようなことがあれば、それは上司の責任です。つまり部下を犯罪者にしない仕組みが重要です。何かやったら絶対にバレてしまうことをあらかじめ知らせておくことで抑止しておいて、それでも防げない事故があるならば、それは「自爆的な犯行」です。

さらに「トレーサビリティの確保」、つまりシステム管理者や上司のPCを管理する人の作業トレースをしっかり取ることは重要です。PCI DSSにもありますが、管理者の作業はすべてログを取るべきです。管理者はシステムに対してあらゆる操作を実行できる権限が与えられていますが、決して神様ではないのだから、重要データへのアクセスを含め、その足跡をトレースしておくのは必須でしょう。

あと忘れてはいけないことは「ルールは形骸化する」ものであるということ。ルールを作るときは、「時限的なものにする」もしくは「ひとつルールを作ったら、ひとつのルールを削除する」というのはいかがでしょう。ついPCにいろんな対策を施すことばかりに目が行ってしまいますが、ルールを守るのはあくまでも「人」なのですから、人にも予防接種（教育や演習）を施すのも重要なセキュリティ対策です。

事故前提であるということは、組織に潜むリスクを定常的に把握することにつながるのと同時に、事後対応のためのセキュリティ対策に集中することでセキュリティコストを削減することにもつながります。事故の発生を問題とせず、発生後の対応を問題とする。そんな風に事後に力点を置いた運用ができる組織は、この不況において圧倒的に強みを発揮できると思いませんか。

しかし、こうしてみると「事故前提の対応強化」は、セキュリティだけではなく、私たちの生き方、会社運営も含めたパラダイムシフトなのかもしれませんね。

（終）