セキュリティ製品の基礎知識と導入手引き
【連載】情報セキュリティ運用の基礎知識

第4回 経営層にセキュリティの重要性を納得させる

ロードマップ

第1回　情報セキュリティの基盤技術としての暗号 第2回　社内ネットワークにおけるクライアントの対策 第3回　Web構築・運営における脆弱性とその解決法 第4回　経営層にセキュリティの重要性を納得させる

小川博久
シーフォーテクノロジー
2003/1/10

---

　どんな業務を行うにしても予算や人員を確保することが、一番始めの仕事になる。当然、セキュリティに携わる者にとっても同じであるが、セキュリティ関係の仕事においては、少なからず違う側面があるのも事実だ。連載最後の回は、セキュリティ関係の仕事には必ずついて回ってくる問題「上司を納得させる材料」について現場の立場に立って考えたい。

　企業に所属している限り、必要な人・物・金を確保するには、当然、上司や経営層を納得させなければならない。特にセキュリティ関連業務においては、上司や経営層にセキュリティの重要性を理解させるということが、最も重要な問題となってくる。

　企業のセキュリティを強化するということは、その企業のセキュリティに対する認識をあらためることと直結し、新たな予算・人材を確保することに加えて、関連部門すべての従業員にセキュリティ対策を徹底させるということが重要となるからだ。いくら予算・人材を確保できたとしても、関連部門のだれか1人でもセキュリティに対する認識が低く、協力も得られない場合、その企業のセキュリティレベルは低くなってしまう。

　企業のセキュリティ担当者にしてみれば、上司や経営層にセキュリティの重要性を理解･納得させ、トップダウンでセキュリティ対策を進める体制をつくっていくことが最初の仕事となり、大きなハードルとなる。

セキュリティは保険というありがちな認識

　「セキュリティ関係の予算を、渋々承認してもらい、いざ動こうとした矢先に、関連部門の人材に講習する時間をもらうことができず、全く動きようがなくなった」という話を聞くことがある。このような状況は、予算申請者（セキュリティ担当者）と承認者の認識にズレがあったことを端的に表している。

　セキュリティに対して予算を付けたというだけでセキュリティ対策を実施している、という意味合いの話を聞くが、このズレも同様の問題を含んでいるように思える。

　承認者としては「予算を与えるから後はどうにかできるだろう」と考え、セキュリティ担当者は「予算さえ付けばセキュリティの重要性が認識されたもの」だと考える。このズレは「予算さえあればセキュリティが確保できる」という承認者（上司）の間違った認識に対する訂正をセキュリティ担当者が正しく行っていないために起こる問題だろう。

　しかし、もっと突き詰めれば、実際にはセキュリティ担当者も「予算さえ付けばどうにかできる」と考えてしまう傾向が少なからずあることが問題であるようにも思える。

　セキュリティ担当者は、上司が持っている「セキュリティは保険的な意味合いで予算を付けている」という、ある意味正しいが間違った認識を改めさせるべく、適切に説明しなければならない。では、上司に何を説明し、何を納得させるのかを具体的に考えてみよう。

セキュリティ対策を実行するには「協力を促す資料」も必要

　最初に説明したとおり、セキュリティ対策を行う場合は、予算だけでなく人員（関連部門の協力）も必要になる。先ほどの例を違う角度から見てみると、関連部門（ユーザー）からの理解が得られていないという考え方もできるだろう。セキュリティ担当者は、 IETF RFC 2196（サイトセキュリティハンドブック）にあるように、次のようなバランスを保ちながら業務を進めていくことを理解しておくべきである。

（1）サービスの提供 VS セキュリティ	ユーザーに提供しているサービスには、それぞれ固有のセキュリティ対策を行わなければならない。リスクが大きい場合は、ユーザーが利用しているサービスを停止することも考えなければならない。
（2）操作性 VS セキュリティ	パスワードの管理や更新、各種認証デバイスを利用する場合でも、ユーザーには負担になってしまう。セキュリティの重要性を理解していないユーザーにとっては、セキュリティは負担でしかない。
（3）セキュリティのコスト VS 損失のリスク	セキュリティのコストは、損失した場合のリスクに対する費用であるため、さまざまなリスクを想定し、それに見合ったセキュリティ対策を施さなければならない。

　（1）、（2）に関しては、ユーザーに対して理解や協力を求めることになるが、当のユーザーにしてみると、通常業務に加えて新たに行わなければならないことが増えることになり、敬遠したいと思うのが現実である。セキュリティポリシーでは、トップダウンで進めることが常識であるが、セキュリティの担当者からすればこのようなユーザーを相手にすることに変わりはなく、上記のような話を相手に納得させなければならない。

　セキュリティの重要性を訴える機会がどの程度用意され、下準備（ネゴ）ができているか？ ということは、通常、セキュリティの啓蒙などといわれる。このセキュリティの啓蒙（教育）体制、強いては関連部門の協力を促す下準備は、予算を獲得した後に、本当に遂行できるかを示す資料になるため、実際の担当者同士がどの程度の内容や意識を共有しているのかという資料を示すことも、上司を納得させる大きな材料になると考えられる。具体的には、下記の内容を含んでいるだろう。

選定	関連部門の選定、協力を得たい実担当者の選定。選択部門や、各部門に対する設定人数との妥当性。
機会	社内で行う勉強会や定例会などの回数と内容。中期的にみた場合の段階的内容の妥当性。
資料	上記の機会を得た場合に使用する資料類の準備。第三者が公開している中立／客観的な資料を効果的に用いているか？
共有	関連部門の上長や実担当者に許可を得ているか？ 資料を配布しているか？ 意見があったか？

損失リスクを考慮した事前の資料を用意する

　先に紹介したサイトセキュリティハンドブックに記載されている「2. セキュリティポリシー - 2.1 セキュリティポリシーは、なぜ必要か？ - （3）セキュリティのコスト VS 損失のリスク」は、上司を納得させるうえで、最も重要なことであろう。

　数値化した資料は最も説得力があるという一般論だけではなく、ユーザーが納得できないほどの負担を強いられた場合、損失リスクに対するセキュリティコストの高さが問題視されることも考えられる。そのため、このセキュリティコストの妥当性は、何度も繰り返し参照される資料となる。この見積もりがあいまいな場合、予算が付いていたとしても、後々セキュリティ対策自体をストップせざるを得なくなる可能性があり、十分な検討が必要である。

　とかくセキュリティは費用対効果が明確になりにくいといわれているが、費用対効果を補足する材料としてリスク分析は重要である。リスク分析は、業務の種類やコンサルタントの数だけ存在するといっても過言ではないほど、さまざまな手法がある。ここでは、代表的なリスク分析手法を紹介する。

JRAM（JIPDEC Risk Analysis Method）	日本情報処理開発協会（JIPDEC）が、1992年に考案した手法。情報システムのリスクを、JRAM質問表を用いて脆弱性を把握／評価し、JRAM分析シートを用いて実際の損失額を算出する。定量的分析と定性的分析を利用している。
CRAMM（CCTA Risk Analysis Management Methodology）	英国大蔵省（CCTA）と英国規格協会（BSI）が1988年に考案した手法。CRAMM質問表を用いて情報資産の分類と評価を行い、脅威と脆弱性を5段階に評価する。さらに、CRAMMが提供する対策事項から選択するので、リスクマネジメント全般を対象とした手法である。この手法も定量的分析と定性的分析を利用している。
ALE手法	米国NISTが1977年に推奨した、定量リスク分析手法。損失評価額レベルと発生頻度レベルから、年間予想損失額（ALE）の近似値を求める定量的分析手法。

※なお、JIPDECから平成12年に出された「わが国における情報セキュリティの実態」の概要では、「JRAM自体が、情報環境の変化からすればすでに“古く役立たない”と判断されたのであろうか」というコメントもある。また、同概要では「重要性を感じない」や「効果があると思えない」という見解があることも事実である。

　費用対効果を別の角度から算出する方法もある。「情報セキュリティインシデントに関わる調査 調査報告書Ver.1.0」（情報処理振興事業協会セキュリティセンター）では、セキュリティインシデント被害額算出法も紹介されている。この算出方法は、インシデントが発生した場合に見合うコストを投下しているか？ という検討を行うための判断材料としても利用できるであろう。

　上で紹介した手法でも、正確なリスク分析を行うためには業務に合わせて細分化する必要があるため、確立した手法は存在しないと考えられる。また、一般的には、セキュリティポリシー策定業務中にリスク分析を行うと考えられているが、セキュリティコストに対する効果を考えるうえでも、特定のメンバーで試験的に実施してみることは有効であろう。

　メンバー内の意見が把握できるというメリット以外にも、質問内容や数値化の基準など分析手法のノウハウを蓄積できることも考えられる。こういった材料を用意することで損失リスクとセキュリティコストの対比を明確にすることができると考えられる。

　専門的な知識が必要だと考え、コンサルタントに頼んでしまうという考え方もあるが、コンサルタントに依頼したところで、実際には業務の実態を把握するための質問を受けることになる。その調査・回答をまとめるのは企業の担当者であったりする。やみくもにコンサルタントに依頼してしまうことを考えるならば、試験的なリスク分析を行うことが重要であろう。

　数値化した資料は重要であるが、上司を納得させる資料として、もう1つ考えておいた方がよいことは、「セキュリティ対策を行おうとしている企業にとって、リスク分析を行うことにマイナス要因は全くない」ということである。

　過度の投資はリスクになるが、リスク分析を行うこと自体は、プラス要因だけであってマイナス要因はまったくない、そして、そのプラス要因に見合うと考えられる投資を見極める資料（数字）を作成する。ということが重要である。

　具体的には、下記のような進め方が考えられる。

軽度なリスク分析の結果を提示する	過度にならない範囲でリスク分析を行い、分析結果を提出するとともに、リスク分析の必要性や重要性を意識させながら定着化（コスト意識）を図る。
情報システム費用に対するセキュリティ費用の対比を明確にする	情報システムの入れ替え時には、リスク分析を大々的に行うこともできるだろうが、既存の情報システムが稼動している場合は、掛かる情報システム費用に対し、セキュリティ費用との対比を示すことが上司にも納得できやすいであろう。

　IPAで公開されている情報セキュリティの実態調査［情報セキュリティの実態調査2001調査報告書］にも、情報システム費用に対するセキュリティ費用という比較で検討されている企業が多いことが報告されている。しかし、この方法は、セキュリティ対策費が情報システム部門での予算に計上されてしまい、セキュリティ対策に掛かるコストが明確でない。このような悪い側面もある。リスク分析の定着化や進め方は、企業が属している形態や業種に依って異なるが、あくまでもリスク分析の入り方として考えてほしい。

運用時の簡便性と適正性

　先に説明したのは、予算獲得のための数値化であって、製品導入や運用時の数値化と異なる。簡単にいえば、予算獲得には幾分厳密な数値化が必要だが、運用時に正しく利用されているか？ 運用方法を見直す必要はないか？ という運用チェックの数値化では、厳密性を求め過ぎてはいけないということである。実際には、次のようなことを考慮しなければならない。

●簡便性

　計測するための工数を軽減させ、容易にすることで3つのメリットがある。

• 計測者は、当然計測作業が楽である。
• ユーザーは、通常の業務に支障がないため（正確には、配慮されていると感じられるため）心理的な圧迫感がない。
• 上司は、計測者にもユーザーにも多大なコストをかけずに一定の計測結果が得られる。

●適正性

　適正さを求めると、厳密さが要求される。当然、上記の簡便性のメリットがなくなり運用の管理や見直しができなくなることになりかねない。管理のチェックや見直し検討ができなければ、実際の効果を適正に判断できないことになる。本当に求めるべき適正さとは「作業者が、計測の結果や議論などの成果が適正に評価されていると感じられる」という点である。運用のチェック時には繰り返し計測することが重要で、厳密な計測よりは、適正な評価を考慮することが求められる。

　よく聞く話に、システム導入のプレゼンテーションや説明会に参加するだけで、セキュリティ向上に貢献しているつもりになっているということがある。また、セキュリティ対策については、講師の話を30分座って聞いているだけでセキュリティの啓蒙になると、そればかりを繰り返し行っている企業もあるようだ。しかし、システム導入の効果や管理チェックに関しては、実務レベルの質問を5個用意するだけで、容易に実態を把握でき、議論の対象になり得る。当然、セキュリティに対する意識を高めることを考えても同様だろう。こういった手法を検討したり、導入前に告知することで、運用時のチェック方針や評価体制を示すことも重要な参考資料になるだろう。

◇

　これまで4回にわたって、「情報セキュリティ運用の基礎知識」と題して、情報セキュリティ技術や製品の概略を紹介してきた。ここで改めて強調するが、情報セキュリティ運用で重要になることは、情報資産に対する重要度と、製品が利用される環境を考慮して運用することである。

　そして、これらの業務を浸透、継続させるためには、セキュリティ対策に対する参加や発言を促す社内評価の体制を検討していただきたい。その際に、今回の連載記事が何らかの形で活用していただければ幸いである（今回で連載は終了です。ご愛読ありがとうございました）。

Index

第1回 情報セキュリティの基盤技術としての暗号 　 Page 1 情報セキュリティ製品のガードの対象“情報資産” 基礎知識として、まずは暗号技術の理解から 情報化社会における情報セキュリティの意義と目的 情報セキュリティ製品の有する機能 　 Page 2 そもそも暗号とは何か？ ハッシュ関数の役目 第2回 社内ネットワークにおけるクライアントの対策 　 パスワード、認証製品によるローカル環境の情報セキュリティ 暗号化によるローカル環境の情報セキュリティ 電子メール通信環境における情報セキュリティ 第3回 Web構築・運営における脆弱性とその解決法 Page1 クライアントとサーバ間のユーザー通信に関するセキュリティ Page2 Webサーバサイド（Webサイトを公開する側）のセキュリティ クライアントサイド（Webサイトを閲覧する側）でのセキュリティ 第4回 経営層にセキュリティの重要性を納得させる セキュリティは保険というありがちな認識 セキュリティ対策を実行するには「協力を促す資料」も必要 損失リスクを考慮した事前の資料を用意する 運用時の簡便性と適正性

■参考Webサイト
　IETF
　IETF RFC 2196（サイトセキュリティハンドブック）
　JIPDEC わが国における情報セキュリティの実態
　IPAセキュリティセンター 情報セキュリティインシデントに関わる調査 調査報告書Ver.1.0
　IPAセキュリティセンター 情報セキュリティの実態調査2001調査報告書

連載：情報セキュリティ運用の基礎知識

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）