足りなかったのは脆弱化への対応

足りなかったのは脆弱化への対応

業務効率を考えれば、逸脱を認めないわけにはいかない。しかし逸脱を認めれば、明らかにセキュリティ面で脆弱になる。今回のケースでは、セキュリティポリシーに不備があったとか、ベースとなるセキュリティ対策が甘かったということではない。

ポイントは脆弱化への対策ができていなかったということだ。新たな脆弱性に対するリスク分析が行われず、追加すべきセキュリティ対策が取られなかったことが原因なのである。

図2：DMZ（De Militarized Zone）

注目すべきは「情報を社外へ流出させないこと」

今回の場合はセキュリティポリシーで端末PCの持ち込みを完全禁止するといった外形的なものではなく、「情報を社外へ流出させない点に着目した本質的な対策」が取れるか否かである。

持ち込み端末PCという新たな情報流出経路が生じたため、例えば「持ち込み端末PCへの小型可搬媒体による情報の受渡しを禁止する」や「社外向け通信のログを取得する」などが考えられる。

入ってくる情報はかまわない（ウイルス・ワームなどの防止は当然だが）。要は「出て行く情報を確実にコントロールすること」である。例えば、DMZ（De Militarized Zone）を備えたファイアウォールのような構造を思い浮かべてもらえばよい。

非常に少ない人数で開発をしているなら、持ち込み端末PCの使い方についても目がいき届くであろう。しかし何十人、何百人といった開発プロジェクトでは個々の使い方まで目が行き届くわけがない。

その中で、1人でも不適切な使い方をしていて、それを知らずに他の人が重要情報を開発環境に持ち込んだらどうなるだろう。結果は明白である。通 常、商用環境と開発環境は分離するが、商用データを使った並行運転試験などを想定した場合、三層構造のような環境の分離も考慮する必要がある。

読者の皆さんもご存知のように、多人数で開発を行うプロジェクトでシステム上の制約事項などがしっかり共有できていないと思わぬバグを作り込ん でしまう。これは品質上の欠陥を作り込んでしまった例だが、同様にセキュリティ上の欠陥もいとも簡単に作り込んでしまうものである。そしてこれらを防止す る仕組みが「品質管理システム」や「情報セキュリティマネジメントシステム」なのである。