Last Updated 2003/1/3

●Security INDEXへ

★TOP INDEXへ

セキュリティポリシーの使い方

どの文献を読んでも言われていることだが、セキュリティポリシーは作ったら終わりではない。むしろ、作った後、ポリシーやスタンダード（ガイドライン）、プロシージャ（手順書）をちゃんと運用することの方が重要だ。重要であると同時に大変でもある。
ちゃんと運用するということは、要するに関連する全スタッフが手順どおりに業務を進めていて、かつ手順が守られていることが確認できる、ということである。標準による認証を取得する場合何でもそうだが、セキュリティ関連の標準に基づいて認証されようと思ったら、手順の遵守状況がはっきり把握できていなければならない。それも原則証拠付きで。
認証取得を目指さないとしても、ポリシーの導入によってセキュリティのレベルを向上させたいと思うのであれば、関連する全スタッフが一人残らず手順どおりに進めていなければ意味が無い。一人でも違反したりサボッたりしたら、セキュリティのレベルはその人のレベルに落ち込んでしまう。セキュリティは一番弱いところから破られるのが常だ。
折角多大なパワーを割いて作ったルール体系を、どうやったら効果的に運用できるか考えてみよう。

ポリシーを最も効果的に浸透させる方法は、罰則を設けることだろう。それも実効性を伴って、違反者の痛みになるような罰則でなければならない。
罰則は人事系罰則や経済的罰則というのが考えられる。
人事系罰則というのは、みなさん良くご存知のところだと思うが、「懲戒免職」や「降格」、「減給」とか「自宅謹慎」などを含む、昔ながらのトラッドな罰則のことである。組織ではこの仕打ちは大きな打撃である。したがって効果は抜群だろう。
人事系罰則の難点は、まず、ルールを決める手続きが煩雑になりがちである、というところだ。
人事系罰則を決めるには、労働組合と交渉しなければならない。そして、モロに旧来の人事組織とも折衝しなければならない。もちろん規則を変えるプロセスが煩雑でない組織もあるが、もともと古から存在する組織、部署と古から存在するルールの改造について、新参のセキュリティ関係者が折衝するのである。なかなか事が進まないという傾向は仕方が無いかも知れない。 また、もう一つ重大な難点は、罰の軽重とポリシー違反行為とをどうやって結びつけるのか、おそらく誰も経験したことが無い領域であろうからわからない、ということだ。具体的に言えば、「ネットワークに重大な影響を及ぼす設定ミスをやらかしてしまい、結果として2日間も一部業務を停止させてしまった」という事例は、減給3日に当たるものなのか、一ヶ月分なのか、それとも降格に値するものなのか、ということである。あるいは、「パスワードを盗まれてしまい、結果として顧客情報を21万件漏洩させてしまった」という事例は、懲戒免職になるのか、それとも懲戒・訓告で済ませることができるのか、ということである。このあたりは実例も少ないだけに、どういう結びつけ方にすれば良いのかは白紙から考えるくらいのことをする覚悟が必要だろう。
さらに厄介なのは、ネットワークに重大な影響を及ぼす設定ミス、というのが故意なのか、それとも単にうっかりしていただけなのか、ということが、実は良く分からない、という点だ。もちろん自分の意志で顧客情報を名簿屋に売り飛ばしていたら、それは懲戒免職されても仕方が無いだろうが、いつもは32文字で英数字記号でランダムなパスワードにしているのに、たまたまその日だけメンテナンス上やむをえない理由があって簡単なパスワードにしてしまい、結果顧客情報がダウンロードされて売り飛ばされた、というのは同じく懲戒免職に当たるのだろうか？それとも、やむをえない理由があった、ということで訓告になるのだろうか？結果として盗まれたモノが同じでそれによる影響が同じで、被害も一緒だったとしても、処罰に差をつけるのだろうか？
ただ、組織に与える被害と、その被害に対し故意かどうか、という部分は、既存の罰則でもすでに検討してあるはずだ。したがって、やはり最大の難点は罰則の軽重とセキュリティ違反の対応付け、ということになる。
しかし、難点を補って余りある効果は期待できる（笑）。（もちろん筆者も一企業の社員であり、あまり効果抜群な人事系罰則が出てくるとイヤな感じがするものだ）
結び付け方についてもう少し考えてみよう。
セキュリティポリシーを作るときにはリスク分析を行なうが、そこで必ず実施する作業に「情報資産の洗い出しと価値付け」というものがある（リスク分析コラム参照）。組織が抱える情報資産を列挙し、その資産が無くなったら、漏洩したら、破壊されたら、改ざんされたら、などの視点で、業務や組織全体に与える影響度を想定する、という内容の作業である。その作業によって何が分かるか、と言えば、顧客情報は業務計画情報よりも価値がある、人事情報は経営計画情報よりも価値が無い、というようなことだ。資産にプライオリティを付けることができるのだ。
そのプライオリティを「極秘」「社外秘」「公開」という3段階につけたとする。そしてその3ランクに「故意による」「故意ではない」というレベルをつける。

「極秘」「故意による」
「極秘」「故意ではない」
「社外秘」「故意による」
「社外秘」「故意ではない」
「一般公開」「故意による」
「一般公開」「故意ではない」

事前に念入りに分析検討して書き上げたポリシーであっても、運用し始めたら「厳しすぎる」とか「現状に合わない」とか「手順が増えて効率が悪くなった」などの不満が出てくるはずだ。業務の運用手順などは、例えばISO9000で規定されているものをそのまま導入したら手順が多すぎる、ということは現場レベルでは良く聞かれるグチだろう。
そのギャップをそのまま放置しておくとルールは無視されるようになる。
そうならないために、特に運用開始当初はギャップを吸い上げてポリシーを適切に修正することが重要になる。
ポリシーを修正等含めて柔軟に運用していくには、まず体制を考える必要がある。
世の中のさまざまなセキュリティ文献や標準を見ると、必ずと言っていいほど「セキュリティ委員会」や「ISMS委員会」などの設置に触れられている。どれも同じことを言っていて、要するに「独立性があり、ことセキュリティに関してはすべての権限を持つ組織」を作るべし、ということなのだ。
セキュリティ対策というのは、どうしても現場に対してもう一手間強いることが多い。例えば、今までであれば手順数は３つだったところを、セキュリティを考慮したガイドラインによれば４つになってしまう、ということだ。もちろん手間を増やさずに対策することを極力目指すべきであるし、リスクヘッジの方法によっては手間は減らせる面もあるが、今までリスク管理をしていなかったところに管理策を導入すれば、どうしてもそうならざるを得ないのだ。
となると現場では抵抗が出る。それでなくても予算は削られ人も削られ、作業はまだまだ効率化しなければならないのが今の現場である。セキュリティ対策やセキュリティポリシーの導入とは、その現場のいわゆる「手間削減欲求」とのせめぎあいという側面がある。
ということはつまり、生半可な権限しか持たない組織では、導入への強制力を持てないのだ。
だから、セキュリティ委員会には独立性が必要だし、出来うる限りその組織の最高責任者直属であるべきなのだ。
また、同時にその委員会はセキュリティポリシーに対して教条主義に陥ってはならない。教条主義というのは、ポリシーの条文第一で、条文絶対で、苦労に苦労を重ね、現場からも意見を吸い上げ（実は意見はあまり出てこなかったので、無いものと考えた、とか（苦笑））、そして作り上げた手順書やスタンダードを曲げる気はさらさらない、という態度である。よくあることだがそれは本来の目的を見誤っている。
セキュリティポリシーを作って運用する本来の目的は、その組織のセキュリティを守るためなのである。
ルール教条主義に陥って結局現場での運用にルールとのギャップを作ってしまったら、目的を大きく外れてしまうことになる。
したがって、ポリシーや関連ルール体系は出来る限り柔軟に現場の意見を取り入れて変更できるようにしたい。もちろん取り入れすぎてリスクを増大させるのも目的に反しているので、生の意見を吸い上げる態勢（定期的にインタビューする、匿名OKで意見を聞く、など）を整えて、出てきた意見を現場とセキュリティ管理者との間でディスカッションする。ディスカッションすれば、仮に結論が「ルール変更なし」ということになったとしても、現場は納得するだろうし（心の底からではないにしても）、変更する場合でも有益な意見をさらに汲み取るチャンスができる。ルール変更の効果をフィードバックしてもらえるパイプもできる。さらには啓蒙の手段ともなるのだ。
また、出てきた意見に対しては、それがどんなにくだらなく見えてもきちんと応じるべきである。セキュリティ的視点から見るとあまりに常識的なことであっても、その意見が出てきた背景は尊重すべきだ。
ポリシーの作成時も同じだが、そもそもセキュリティポリシーとそのルール体系はふつう現場にとっては抵抗感を抱くシロモノ以外の何物でもない。作成時にも同じように現場の意見をくみ上げる仕組みを取ることが重要だ。
しかし、あまりにフレンドリーに意見を取り入れる仕組みにしてしまうと、野放 図にさまざまな意見が殺到する懸念もある。最初はそれをさばくのは大変な作業量となるだろうが、むしろその懸念が現実化するほど意見が出てくるほうが実効性があるポリシーになるはずだ。また、単なる意見にとどまらない別な圧力がかかることもある（苦笑）。大学や研究所などの組織モデルでは往々にして現場責任者が最高責任者より偉かったり（！）するからだ。そういうケースでは最高責任者のお墨付きでも苦しいかも知れないが、「正論」と「意見交換の公開性」を利用して「そりゃどう考えてもおかしいでしょ？」というコンセンサスを取り付ける、などで抵抗するやり方もある。意見交換の公開性、というのは、さいわいにしてセキュリティ委員会ということで独立性のある組織になっているとしたら、そこでの情報交換に関しての管理権限はその組織にあるわけで、そこで交わされた意見はすべて公開してしまうのだ。公開されるとなると、あまり無茶なことは言わない、という抑止効果を期待するわけである（それでも弱いかも知れないし、そりゃどう考えてもおかしいでしょ、とならないかも知れないが（苦笑））。
公開性という話が出たついでだが、セキュリティ委員会で検討されている内容やそこで出ている意見はもちろんばりばり公開しまくりたいところである。あまり細かいレベル、例えば公開Webサーバーのバックアップ手順見直しについて、などは、ありていに言えば関係しない部署にとっては関心が無いことだ。そういう情報がばりばり出てきたとしてもあまり読まないだろう。
しかし、手順そのものでなく、ガイドラインのレベルで「一般的な顧客契約に関するガイドライン」の見直しというのは、すべてのスタッフが知っておくべきことだろう。そういう情報は出来る限り公開したい。
ここまで「公開」と書いたが、もちろん情報公開には違いが無いわけだが、意識としては「公開」という意識ではなく「宣伝広告」と捉えた方がいいだろう。自分が今直面している業務に対しては、相手も最大限、とまでは行かなくてもそれなりの関心を持つのが普通だ、と思ってはいけない。たとえ自分がやっている仕事が組織全体に関わる重要な仕事であっても、いや、だからこそその内容について上手に宣伝することが必要なはずだ。セミナー形式で発表したり、イントラネットを使ったり、メールで告知したり、パンフレットを用意したり、手を変え品を変えて広告宣伝すべきである（もちろん予算が許せば、だが）。
というわけで、セキュリティ委員会には広報の担当者、できれば経験者が必要となるはずである。委員会を組織するときに考慮しておきたい。

現場での軋みを意見として取り入れ、ポリシーを改良して運用が軌道に乗ってきたら、今度は監査を考える。
新しいルールを導入したら監査を実施して遵守状況を確認する必要がある。監査がやって来ないと思うとやはりルールは無視される傾向にあるため、不定期に抜き打ちで監査したい。監査が定期に、予測できる周期、期日で実施される場合、ユーザーはそれに備えてしまうため、あくまで不定期が原則だ。 とはいえ、不定期で厳格な監査をいきなりがんがん行なったら、反発心を抱かれてしまう危険性がある。それでなくても現場は本来の業務で大変なので、監査への協力のためにリソースを割いてもらうだけでも有り難いと思うべきである。だからぎりぎり締め付けるだけでなく、違反が発見されたとしても次回の監査まで対策の導入を留保するというような逃げ道を用意しておく。ただし、2度目に同じ違反をした場合、しかもその状況に改善が見られない場合は厳格に罰則を適用しなければならない。
監査結果もモチベーションに利用したい。
監査結果を点数のような尺度で見せるというのは、モチベーション向上に役立つだけでなく、セキュリティポリシーの導入プロセスの分析材料にもなる。以前に筆者の所属する組織でセキュリティ意識に関して簡単なアンケートを実施したことがある。そのときに出てきたのは、きっちり意識しているのは総務や人事などの部門で、若い女性社員の方が意識が高く、逆に最も低いのは男性で中堅以上の年齢層で営業部局、という結果だった。開発や技術などのセクションは意識が高めだが、実際にさまざまな対策を実施するのは面倒がる、という傾向も見られた。セキュリティへの意識ではなく、セキュリティポリシーとルール体系を導入運用する場合も、ほぼ同じような傾向になるのではないだろうか。
運用を立ち上げるというときには、最も面倒くさがる、最も意識が低い部署を意識すべきである。
モチベーションをかきたてるには、同じ数字を使う場合でも工夫が必要だろう。例えばきちっと実施されている率、というだけでなく、前回監査時からの伸び率、とか、全組織の平均値とその伸び率、可能であれば他社や他団体、業界平均の数字などを援用すると良いだろう。
さて、監査そのものの作業だが、自分たちで実施するというやり方以外に、外部のセキュリティベンダーに頼んで白紙から監査してもらう、という手もある。もちろん監査業者でも良い。
あるいはいっそのこと、例えばBS7799の監査および認証をサービスしているところとか、ISMS評価制度のもとでサービスしているところなどに頼むというのもある。いずれもそれなりにコストがかかるが、自ら監査作業をやる手間、監査できるまでになる手間などを考えると、依頼した方が良いかも知れない。ただし、気をつけたいのは、監査作業は担当者によって成績などにばらつきが出やすい、ということだ。これまで述べてきたような留保を全く認めないルール教条主義監査をする人も居れば、柔軟に留保する人も居る。何度か監査を実施してもらわないとそのあたりのニュアンスが分からない面もあるが、少なくともそのニュアンスが分かるまでは、実施した結果をそのままストレートに公開せず、セキュリティ委員会で受けて内容を吟味してから公表を考えるべきであろう。
こうして並べてみると、セキュリティ委員会の果たすべき役割は多い。ということは、やはり予算を取って継続的な組織にすることがのぞましい、ということである。
セキュリティの場合はとにかく一次導入費用的な部分だけが注目されるが、運用を考えると、むしろ導入後の維持管理にきっちり予算を考えておく方が重要だと言えるだろう。でなければ一時的にセキュリティのレベルが上がっても、すぐに落ち込んでしまうことになる。
それでは一次費用も無駄になる。

Copyright © 2002-2003 Sonoda Michio

★TOP INDEXへ