第2回：セキュリティ推進担当側が陥り易いワナ (1/3)

セキュリティ推進担当が「やってはいけないセキュリティポリシー」

セキュリティポリシーを策定したはよいが、さまざまな部署から不満が出てしまったことはないだろうか。ガイドラインにそって策定したのにもかかわらず、なぜうまくいかないのか。それは「やってはいけないセキュリティポリシー」を実践してしまったからである。

「やってはいけないセキュリティポリシー」とは「現場の実情を反映していないポリシー」のことだ。「実行性を十分に考慮しきれないまま運用をはじめてしまったポリシー」といってもよい。このポリシーを作ってしまうと、現場で徹底されず、有名無実となっている例は非常に多い。

ではなぜ「実行できないポリシー」を作ってしまうのだろうか。

セキュリティに対する理想を描くことはわかる。できるだけ理想に近づけるよう努力することは大切である。問題なのは、実現性の検討が抜け落ちてしまうことだ。つまり、理想的なポリシーを作ったことで満足してしまうのである。

図1：情報セキュリティマネジメントの実践のための規範「JIS Q27002：2006」

ポリシーの策定で重要なのは網羅性

推進担当者はセキュリティの重要性を強く意識し、安心できるポリシーを作成したい。そのため、通常はJIS Q 27002などの規格を参照する（図1）。

ISMSの認証制度は規格に照らして不適合がないかを審査員が点検し、お墨付きを与えるものである。ISMS構築にあたり、まず規格を参照することは、何か答えを先に見ているような感覚になるかもしれないが、ガイドがない状態で取り組むのに比べ、ずっと効率的である。

何より網羅性が確保できる。この網羅性が重要だ。なぜならセキュリティポリシーを作成して、漏れがないことを証明することは、非常に難しいからである。JIS Q 27002などの規格はベストプラクティスを集めたものである。そのため本来はそれらすべてではなく、ポリシー適用組織の固有のリスクに応じて、追加しなければならない管理策があるかもしれない。しかしながら、最低限、規格で想定する範囲での管理策の抜け漏れを防ぐことはできる。しかし、ここにワナがある。 次のページ