【解説】
企業を危うくするセキュリティ［NG］集

Side Story
もう1つのNG集──セキュリティ・ポリシー編

Anton Chuvakin／Computerworld米国版

　セキュリティ・マネジメントに絶対に欠かせないもの、それはセキュリティ・ポリシーだ。これの目的は、顧客／従業員情報や企業データの保護、セキュリティに対する姿勢の定義、情報漏洩時の対外的影響の最小化などである。米国の場合、セキュリティ・ポリシーを策定し会社全体で周知を図ることが法律で義務づけられている。

　しかし、セキュリティ・ポリシーを正しく策定し実践するのは容易なことでない。実際、多くの企業がポリシーの見落としや誤解などのミスを経験している。

　以下、セキュリティ・ポリシーの策定や実践にあたり犯しやすいNG（失敗やミス）を5つ紹介する。この中には、あまりに初歩的に感じられるものも含まれているが、看過すると企業の収支に重大な影響を引き起こす可能性が生じると考え、あえて明記している。

NG1：ポリシーを適用しない

　5つのNGの中でも、これはかなり重要である。一口に「ポリシーを適用しない」と言っても、その状態は実にさまざまだ。例えば、そもそもポリシーを一切持たない状態、非公式にそれとなくほのめかされた状態、経営陣レベルで策定かつ認識はされてはいるものの明文化されていない状態などがある。

　こうした状態はほとんど例外なく、セキュリティ上の弱さを露呈することにつながる。これに該当する企業は、セキュリティ・インシジントの際に法的責任を問われるだけでなく、セキュリティ・ポリシーを義務づけている法律に抵触する可能性も出てくる。

　しかも、いざセキュリティ・ポリシーを策定してみると、企業側は自分たちのシステムの大部分がポリシーに違反していることに気づく。これは、ポリシーが現行のIT運用基準に基づいて策定されていないためで、珍しいことではない。

　なお、違反部分については、それをドキュメント化してセキュリティ・リスクを分析しなければならない。そして、新たなポリシーを順守するために必要な改善コストを見積もる必要もある。

NG2：ポリシーを更新しない

　上のNG1に当てはまらないからと言って、安心はできない。セキュリティ・ポリシーはよく出来ているが、セキュリティを強化するには十分でないという現実問題に直面するかもしれないからだ。

　企業ネットワークやビジネス・プロセスが変化すると、当然のことながらセキュリティ・リスクとコンプライアンスの条件も変わってくる。したがって、セキュリティ脅威と企業像の変化に合わせて、セキュリティ・ポリシーも更新しなければならない。

　セキュリティ・ポリシーの更新が必要な具体的なケースとしては、新技術の導入（もしくは旧型ソフトウェアまたはハードウェアの廃棄）、新法の制定または規制強化、企業の吸収合併もしくは組織再編、新事業の設置あるいは新しい実務の採用などが挙げられる。基本的には、これらすべての実施に合わせて、セキュリティ・ポリシーを適切に更新しなければならない。

　どんなに見栄えのいいポリシー文書を掲げている企業でも、セキュリティ・リスクに合わせてポリシーを定期的に見直し、更新しなければ、いずれ攻撃者の格好の標的となるだろう。

NG3：ポリシーの順守を追跡管理しない

　セキュリティ・ポリシーを策定し、かつ定期的に更新しているのなら、理想的なポリシーの運用に向けて重要なステップを2歩進んだことになる。しかし、落とし穴はまだある。

　セキュリティ・ポリシーがきちんと守られているか、ポリシーの存在が従業員に認識されているかの確認を怠ると、ポリシーはたちまち無意味になり、法的にも役に立たなくなる。

　ポリシーの内容がすべての従業員にくまなく周知され、ポリシー順守を習慣づける教育が施されていることはきわめて重要だ。ポリシーの有用性を維持するため、ポリシーに基づく活動の継続的な監査も不可欠となる。

　ポリシーが順守されているかどうかを追跡するうえで最も効果的な手法は、おそらくロギングである。ログ・データを収集し分析すれば、IT環境で今起きていることを把握できるからだ。例えば、仕事関連の文書を個人メール・アカウントに送信したり、アクセス権限外にあるデータへのアクセスを試みたりしている従業員がいたら、その痕跡がイベント・ログとして残っているはずである。これは、クラッカーが外部からサーバへの侵入を試みたときも同様だ。

　ログを介して従業員とシステムの活動を追跡管理し、そこから得たデータをセキュリティ・ポリシーと照らし合わせることこそ、ポリシーの順守を継続的かつ客観的に管理する最良の方法と言えよう。

NG4：技術関連のポリシーしか策定していない

　以上3つの落とし穴を見事にクリアしていても、セキュリティ・ポリシーの内容が技術的なことに終始していたら、攻撃者に間隙を突かれることもある。

　例えば、パスワードの複雑化、ファイアウォール・ルールの厳格化、IPS（不正侵入検知防御）の導入、ウイルス対策ソフトのアップデートといった技術的なセキュリティ対策ばかりに目を向け、エンドユーザーの行動にはほとんど触れていないセキュリティ・ポリシーの場合は、従業員による特権乱用やコンピューティング・リソースの個人目的での使用など、比較的軽度ではあるが侵害行為を許してしまう可能性がある。

　もちろん、技術的な対策が当座しのぎではなく、セキュリティ・ポリシーに基づいた正式なものであることを示すことは重要だ。しかし、セキュリティ・ポリシーが「人間」「プロセス」「テクノロジー」の3要素で構成されることを忘れてはならない。

　そして、この3つのバランスをうまくとることに役立つのが前出のログ・データであることを、あらためて強調したい。自動更新や再起動といったシステムの活動と、日常的なITタスクから物理的なセキュリティに至るユーザーの活動はすべてログに残される。これをポリシーに照らし合わせてチェックすれば、ポリシーに抵触あるいは順守している人間を特定することが可能になる。

NG5：内容が理解しやすい形になっていない

　セキュリティ・ポリシーは、それを順守すべき対象者にとって理解しやすい形で書かれるべきである。たとえ上記3要素をくまなく網羅しているポリシーであっても、その内容を理解するのが難しいようであれば、違反行為を防ぐことは難しくなる。

　同様に、業務の一環として行っている日常的な活動まで禁止するような厳しすぎるポリシーにも問題がある。こうしたポリシーは、結果的に大勢の社員のポリシー違反を引き起こす可能性が高くなる。