 |
質の高い情報セキュリティポリシー作りを提唱する
【特集】スローポリシーのススメ
第2回 現状の情報セキュリティポリシーの問題点
|
宇崎俊介 |
|
| フィットしない米国式ポリシー |
主たる外資系企業の多くでは、トップダウンの全社的なリスクマネジメントに関する考え方が発達している。ある企業ではCEO（Chief Executive Officer）から全社的にポリシーを作成してイントラを守る旨、命令が下る。よって従業員おのおのが「自分達がポリシーに関して何をすべきか」を考えることが必要であり、雇用条件として自主的にポリシーを作成してそれを守ることが、必要条件として盛り込まれることもある。
このような状況下では自己の責任範囲と所在、守るべきルールの存在が必然化するため、従業員自体が体制を疑う余地はほとんどない。すなわち「イントラ」や「情報資産の抱えるリスク」、「インシデント発生時の自身の責任」について、正確に提示され、結果明確な意志が植えつけられることとなる。また「完全能力主義」や「担当業務のリスクレベルと報酬の相関関係」が完成しており、自らの仕事に強烈なプロ意識をもって臨み、プロジェクトに失敗すれば会社を去ることも当たり前な企業風土からも、自己の責任ということについて必然性を持って働いている従業員が多い。
逆に日本の大企業に代表される事業者では、情報セキュリティや機密保持という観点から、そのリスクについて明確な意思をもって検討しているところはまだまだ少ない。大きな組織ほど舵取りに時間がかかるのは至極当然なのであるが、経営陣層に「目の前の利益以外に投資するほど余裕がない」という論理が先に立ち、物事が進まないケースが見受けられる。コンピュータセキュリティ／ネットワークセキュリティを自社の情報資産に対するリスク回避策として認知するに至っていないからだ。
ところが金融系機関などでは外部から監査や監督などの名目で、内部の透明性を確保する必要性があり、なおかつ基幹業務のほとんどを金融機関独特のオンラインシステムで運営しているので、情報セキュリティポリシーは必然的に存在している。ポリシーがなければその企業の存在そのものが法的に存続できない可能性があるからだ。いわば外圧によってポリシーの普及を実現している例といっていいだろう。
一方でユーザーに相当する従業員側では、「ネットワークで発生した問題は情報システム室の問題」「ウイルスに感染するのはウイルスを作った人間が悪い」といった論理がまかり通ることがある。これは「金を稼がないセクションに金を投資することは、企業の利益に反する」という一部の経営者が持つ論理を反映している。
そのような状況下では収益貢献そのものが唯一の企業貢献であり、そのほかの社内コンプライアンス（守秘義務契約など）が無視されたり、罰則規定があっても甘すぎたり、黙殺されたりすることにつながる危険性がある。
このような状況下では情報セキュリティの観点から、企業の情報資産の機密性を確保することは非常に困難であり、ネットワークを通じて事故が発生すれば情報システム部門が叱責され、それ以外のインシデントでは社会的対面を気にするあまり、すべてが闇に葬られかねない。社内で調査会が開かれるだろうが、それはいかに情報インシデントをウヤムヤにし、マスコミリスクを回避するかに費やされるのかもしれない。実際にそういう体質は現実に見られることであり、非常に残念なことだ。企業の経営層は直接収益にかかわるリスクについては認識しているが、間接的ないし費用対効果の見えない部分の運用に関してはほとんどリスクが存在するものと認識していないといえるかもしれない。
これまでの話を整理すると、個々の責任の明文化をもって、トップダウンでポリシーを展開する米国式ポリシーを、そのまま日本で展開することは企業風土の差異からいって好ましくないと思われる。これが日本で情報セキュリティポリシーがうまく運用されない1つの原因だろう。もう1つの原因は前述のように個々の責任範囲の明確化を避けたがる、身内に甘い馴れ合い組織としての性質が潜んでいる危険性である。
むしろ情報インシデントの発生によって届け出などの手段に出ることで、対症療法的な手段を取ることが多い。結果として、営業収益を上げる部門の業務のリスク管理はなされていても、無防備な側面を攻められて緊急的な対応を迫られるというのが多くの情報インシデントの実状である。
結論として、いま現在「情報セキュリティポリシーがほしい」であるとか、「経営陣承認のもと、組織的にセキュリティ対策を実践したい」という願望を実現するには、実用書などによる通り一遍の方法では、極めて難しいといわざるを得ない。よって導入するにはコーポレートガバナンスの概念に基づいたそれなりの説得力ある説明が必要となるし、従業員への理解を促すフォローを加えた組織的浸透も非常に大切なことである。それらは周到に準備され、部門責任者と打ち合わせのうえ、タイミングを図って実行する必要がある。その方法については第3回で述べたい。
| 即席ポリシーが流行中？ |
ここで、「情報セキュリティポリシーがほしい」、あるいは「現在のポリシーのレビューを含めて見直したい」という要望があったとする。それらを顧客の奥底にある本音を含めて分類するならば以下のようになるだろう。
- 認証基準にこだわらず、柔軟かつ企業風土を反映した情報セキュリティポリシーを整備し、運用体制の監査までを外部に委託
- どんな形であれ、ポリシーがありさえすればよい
- とにかく早急にポリシーがほしい。内容は二の次である
- ISMSガイドなどに沿ったポリシーがほしいが、認証取得は考えない
- ISMSガイドに沿ったポリシーを策定して、認証取得までを頼みたい
- ISMSガイドなどに完全に沿わなくとも、組織の実状を反映し、運用を重視したポリシーを構成したい
その原因として、第1回でも述べたように、雛型にはめ込んでポリシーを出力させる手法が普及している点が挙げられるだろう。もちろん、そのような形式でも、項目ごとに過不足やウエイトを微調整することは十分可能である。
しかし、このような方式だとコンサルタントや現場の人間が考える、つまりポリシーの背景にある企業の本質・実態について熟慮する時間をないがしろにしているため、策定までの時間が短縮できる一方で、項目ごと抜け落ちている場合にそのミスを見抜けないことが往々にしてある。そもそも業種によって「社内の書類」「個人情報」「業務データ」などの種類ごとに機密性区分や情報の取得フローはまったく異なっているのが普通だ。例えば最近企業合併が盛んであるが、業務の形態が異なる組織を統合する場合など、これはポリシー作りとして極めて危険であり、コンサルティングの本質をも見落とす可能性がある。
上記に示した6つのケースをポリシーの内容と、運用に関する事項などに分けて整理してみると、ここまで訴えてきた情報セキュリティポリシー作りの概念にかかわるポイントが見えてくるだろう。
|
|||||||||||||||||||||||||||||||||||||||||||||||||
| 表1 ポリシーのウエイトと運用までのポイント表（ポリシー・運用ともにそれぞれが0〜5点で表され、合計10点満点の表示になっている） |
こういったものに点数をつけることが必ずしも正確に物事を表すものではないことを前提にして、この表をご覧頂きたい。これを見ると、運用まで含めて満点といえそうなのは1と5である。ついで6 → 4 → 2 → 3の順となる。
これら6つの要求に対するソリューションを番号ごとに、SIerのコンサルタントの観点から見てみると以下のようになるかと思う。
|
|||||||||||||||||||||
| 表2 ソリューションタイプ別の解説 |
表2の解釈について明言させておきたいことは大きく分けて2点ある。
- “点数がよければよいソリューションである”とはいい切れない
- 情報セキュリティポリシーは手順書レベルで運用されて初めて価値を持つ
ところが企業の要望は表2のように多様化する。要望が2.ないし3.のような場合、理想論からいえば、そのような仕事は受けるべきではないと思われる。金さえ取れればよしとする、要件定義をしてポリシー作成ツールに流し込んで、プリントして「立派なポリシーができました」ということはまずないだろう。しかし、そういう仕事をする企業は本当の意味の情報セキュリティポリシーが作成するポテンシャルがないといわれても仕方がないのではないか。ポリシーは基本方針であろうがスタンダードであろうが最終的に顧客企業の人員を動かし、拘束するものであって
「型にはめたセキュリティ対策を顧客企業にポンと渡して後はよろしく」
などと行っているコンサルタントがいるとすれば、それは社会貢献としてのセキュリティエンジニアの理想像に逆行している。 また、
「どの企業でも似たようなポリシーになりますね」
などと平気でいってしまうコンサルタントは実態に合わせたモディファイができないか、ソリューション自体がそこで完結してしまっていることが疑われる。そんなことをしたら「情報セキュリティコンサルタント」でも「セキュリティエンジニア」でもなく、ただ規格化された商品を扱う物売りに過ぎない。上っ面でよければ、たとえBS7799に従ったポリシーなどでも1カ月程度集中して勉強すればたいていの人が書けてしまう。コンサルタントが付加価値をつける部分はそれ以上のレベルにあるといえ、それ以下なら対価の支払いに値しない。仮に似たようなポリシーができるとすれば、認証取得を大前提とした同規模・同業種などの場合などに限られる。
現実問題として、2. や 3.の類の要望は存在し、その根幹には「国外企業とのBtoB」や「海外資本との業務提携」、「外資の介入」などによって「情報セキュリティポリシーがないところとは一緒に仕事をやりません」という死活的直言を突然叩きつけられることなどがある。よってインスタントな情報セキュリティポリシーは作ってはならないと肝に銘ずべきであろうし、求めることも望ましくない。
| 実行できない手順書と、情報部門の嘆き |
セキュリティ対策の機密保護の度合いとアクセスの容易さは相反する関係にある。厳しい対策基準のもとに手順書が作られると、従業員が情報資源へのアクセスに時間や手間がかかってシステムの使い勝手が悪くなる。利便性追求を黙殺してでも、優先して守るべき情報資産を抱えているならそれでもよい。
ここに営業セクション向けのネットワーク利用手順書があったとする。電子メール利用手順書でもよい。これに第1回目に紹介したようなパスワードに関する話題が盛り込まれていたとする。さらにここで万全を期すべく、ポリシー策定の社内ワークグループは、
- 3カ月に1回のペースでパスワードを変えること
100％実施されなければ、つまり営業セクションの全員がパスワードの変更規定について実行していなければ、ポリシー（エグゼクティブ、スタンダード）に対してセキュリティ対策として実行漏れが生じたことを示すわけだ。加えてこのような手順書が配布されると、実行できない手順書だからということで、その文書のほとんどの項目が守られない、もしくは無視される可能性が高くなってくる。ポリシーそのものに不信感さえ見えてくる。そこでの営業セクションのメンバーの気持ちは 「こんなこと実際やってられませんよ。われわれの通常業務の苦労も考えてくださいよ」 となる。これでは高い金を払ってポリシーから手順書までを作ってもらっても意味がない。
ポリシー策定の社内ワークグループからしてみれば、 「なんだせっかく作ったのに！ いわれたことぐらい守ってくれ！」 さらに内心は、 「大金をかけたプロジェクトなのに……転んだら責任問題だ……」 という気持ちも当然あるわけで、語気も強くなろう。
こういった場合、結局手順書を含めて、すべて見直してみる必要があり、最悪のケースで場合は契約の内容によって2重の投資が必要になってくる場合もある。
ここで話は「情報システム部の嘆き」に変わるが、ポリシー策定のためには、「情報セキュリティ委員会」や「危機管理委員会」という名称の組織が、社内セキュリティ体制のハンドリングをすることが多い。さらにそれら上位組織の中にポリシー策定の社内ワークグループが存在するというケースが多い。その人員の中には情報システム部門がかかわることが非常に多くなる傾向がある。
情報セキュリティという言葉の範囲の中にネットワークセキュリティやシステムセキュリティが含まれるから当然のことである。その情報システム関連のセクション、特に商社や小売業に代表される多くの企業において、当該セクションが社内でのヘルプデスクとしての機能を要求される場合が多いことは周知の通りである。このため、情報システム部系セクションが、セキュリティ体制整備のために泣かされることは多い。
ヘルプデスクとしての機能を要求されるとはどういうことか。要は社内のシステム全般に関するトラブルシューティング屋さんとなるわけだ。「ネットワークシステムがない、OAシステムがない」状況から「OAシステムが導入され、ネットワークシステムが敷設された」状況に移行するに当たって、社内的に需要が発生し、例えば、
「コンピュータ担当員」が誕生→「コンピュータシステム室」誕生→「情報システム部」誕生などと呼称が変化すると同時に、なしくずし的に役割が増大している。現在でも「プリンタが動かない」「ネットワークが遅い」「CD-Rに記録できない」などということに、情報システム部が対応している企業はいくらでもある。またそういう企業では、社内における情報システム部のプライオリティは低く、要は「セキュリティ体制を整備しようと思って、ミーティングを開いても言うことを聞いてもらえません」ということになる。
分かりやすく例えていえば、情報システムセクションは、普段は「直しに来い！」といわれて「はい」と行く側である。「いわれたことだけをだまってやれ！」といわれる立場であり、「協力してほしい」などと頼める立場ではないのである。日々ヘルプデスク業務に忙殺され、それが当たり前のような認識ではセキュリティポリシーどころか、セキュリティ推進体制について話すことすら難しい。この状況では情報セキュリティ推進体制に関して、どんなに良い案を持っていても理解されない。
この状況ではセキュリティ体制は何も整備できない。まさに「情報セキュリティについて何とかしよう」と思う側と「余計な仕事は勘弁してくれ」という側の闘いになってしまう。まさに情報システム部の泣きどころである。
◇
では情報システム部はどのように動いて、危機管理委員会や情報セキュリティ委員会を動かせばいいのだろうか。また、多忙な実働部隊が実行できるポリシーをどうやって策定すればいいのだろうか。これらは多くのセキュリティ担当者が抱える頭痛の種だと思われる。これらに対する解を第3回で解説することにしよう。
 「第1回」へ |
「第3回」へ |
| Profile |
| 宇崎 俊介（うざき しゅんすけ）
株式会社ネットマークス ネットワークセキュリティ事業部 プロフェッショナルサービス室所属。情報セキュリティ全般を守備範囲とするコンサルタント。ISMS、BS7799、FISCのコンサルティングからセキュリティ診断・テキスト執筆・情報セキュリティポリシー策定まで幅広く担当。JNSA（日本ネットワークセキュリティ協会）ではISO/IECに関するWGや、関連法規の政策部会にて活動中。好きな言葉「食べ放題」。 |
| 関連記事 | |
| 実践！情報セキュリティポリシー運用 | |
| セキュリティポリシー策定に役立つ4冊！ | |
| 情報セキュリティマネジメントシステム基礎講座 | |
| 開発者が押さえておくべきセキュリティ標準規格動向 |
 |
「特集 スローポリシーのススメ」 |
- Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ （2017/7/24）
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。 - WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に （2017/7/11）
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。 - Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは （2017/7/10）
代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する - 侵入されることを前提に考える――内部対策はログ管理から （2017/7/5）
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃（APT：Advanced Persistent Threat）対策の観点から考える。
 |
|
|
|
|
