ISMS

 以前は、テレビのニュースで、情報セキュリティインシデントを伝える場合、アナウンサーが最後に「ファイアウォールは設置されていなかったようです」と付け加えるのが、一般的でした。まるで、ファイアウォールさえ設置されていれば、防げたのに、そんなこともしていなかったの?とでも言いたげに聞こえました。2010年頃までは、こんなことを言っていたように思います。しかし、最近はこういうコメントは殆ど聞きません。

 ファイアウォールを設置していても防げないインシデントがたくさんあるということが一般に理解されてきているということでしょうか?例えば、SQLインジェクションとか、CSRF(クロスサイトリクエストフォージェリ)などのWeb通信に関する攻撃はファイアウオールではどうにもなりません。これらはWeb通信でやり取りされるアプリケーションレベルのデータの中身まで検査する必要があります。

 ファイアウォールやIDS、IPSなどにいくらお金をかけても、どうにもならないのが人の教育です。例えば、何千人もの社員がいる中で、一人でもセキュリティ意識の欠けた人がいて、自分のIDとパスワードを同じにしたり、passwordや12345678などの簡単な文字列をパスワードにしている人などがいると、それだけで企業ネットワーク全体のセキュリティレベルが下がってしまいます。

 組織の情報セキュリティを守るためには全員が一丸となって一つの方向を向いて努力していかなくてはなりません。これを可能にするのがマネジメントです。情報セキュリティをマネジメントするという考え方が最近特に重視されています。これがISMS(Information Security Management System)です。ISMSは日本語にすると情報セキュリティマネジメントシステムということになります。

 では、情報セキュリティをマネジメントするという考え方は最近の考え方なのか、というとそういうわけでもありません。1981年(昭和56年)には当時の通商産業省から「情報システム安全対策実施事業所認定制度」というものが告示されています。この制度は通称「安対制度」と呼ばれますが、「情報処理サービス業」を営む企業に対して、コンピュータシステムの安全対策がとられているかを認定する制度でした。

 この制度はあくまで業務として「情報処理サービス」を行う企業の、「コンピュータシステム」に関する制度でした。「情報処理サービス」を業務として行う企業以外は対象外でしたし、「情報処理サービス」を業務として行う企業でも、「コンピュータシステム」以外の、経営資源に関しては言及していませんでした。これは、まだコンピュータシステムが一般にそれほど普及していなかったということが原因だと思われます。

 しかし、最近では社会の隅々までコンピュータシステムが導入され、企業や組織ではそれがネットワーク化され、しかもインターネットに接続するというのが一般的となっています。ネットワークのどこかにウィルスが感染すると、瞬くうちに社内ネットワークに感染が拡大してしまうということも珍しいことではありません。コンピュータシステムだけでなく、人的資源などの組織全体に対してマネジメントする必要性が日々高まっているといわざるを得ません

■ ISMSの誕生
 そこで2001年に誕生したのがISMSです。これはイギリスの情報セキュリティ基準であった「BS7799-2」をベースにして作成されました。ISMSはスタート当初は「情報技術関連の業種」だけを対象としたものでしたが、2002年には「全業種」に対象が拡大されています。

 2005年には英国規格の「BS7799-2」が国際規格である「ISO/IEC 27001」になり、2006年にはこれがそのまま日本工業規格の「JIS Q 27001:2006」となっています。ISO/IEC 27001とJIS Q 27001は全く同じものです。これらで採用されているマネジメントシステムがISMSです。最新版は、ISO/IEC 27001:2013 (JIS Q 27001:2014)となっています。




1 ISMSとは

 ISMSとは組織の保有する情報資産を機密性・完全性・可用性(CIA)の観点から維持していくための規格です。

 組織の情報資産は概ねコンピュータの中に保管されていますが、コンピュータはネットワークでつながっています。従って、1台がウィルスに感染してしまうと、直ぐに感染がネットワーク全体に広がってしまいます。ネットワークにつながるパソコンには全部ウィルス対策ソフトを導入しなくてはなりません。1台でも導入していないパソコンがあるとそこが弱点になります。また、ウィルス対策ソフトを入れたら、定義ファイルを常に最新状態にしておかなくてはなりません。これを社員一人一人の自覚に任せて放っておくわけにはいきません。全社的にウィルス定義ファイルがインストールされているか、定義ファイルが常に最新状態になっているかを何らかの形で確認する作業が欠かせません。

 これは技術的な面でも同様です。ある一カ所はセキュリティが高まっていても、セキュリティレベルの低いところが野放しにされているという状態ではいけません。ネットワーク全体を見渡して、どこも同じレベルでセキュリティの高い状態が保たれていなくてはなりません。

 人的な面でも同じことが言えます。あるベテランのネットワーク管理の技術者が休暇を取っていたら、ネットワークがガタガタになってしまったというのでは困ります。また、これは一般社員のレベルでも言えます。多くの社員がセキュリティについての知識を持っていても、一部の社員が何もわからずめちゃめちゃなことをしていると、多くの社員の努力が台無しになってしまいます。

 情報セキュリティを確保するには組織的に取り組まなくてはなりません。それもトップダウン体制で進めていく必要があります。何度も言うようですが、取りこぼしは絶対にいけません。どこかに弱点があれば、組織全体のセキュリティレベルはその一番レベルの低いところと同レベルとみなす必要があります。

 組織の中で情報セキュリティを推進していく旗振り役を決めて、その人に情報セキュリティについては全権を委ねる必要があります。そして、その責任者をサポートする体制を構築しなくてはなりません。報告・連絡・指示系統をしっかりと構築します。

 社内にどのような情報資産があるか洗い出し、その情報資産がどのような脆弱性を持っているか、その脆弱性に対して、どのような危険があるかをなどを全部把握しておく必要があります。

 その後、情報資産を守るための計画を立案し(Plan)、それを実行します(Do)。計画通りに実施されているかを監査します(Check)。そして、計画が情報資産を守るための方法として適切かどうか見直し(Action)作業を行い、必要とあれば計画の修正を行います。これをPDCAサイクルといいます。ISO 27001ではISMSを確立し、導入し、運用、監視、見直し、維持改善をするPDCAサイクルの採用を求めています。




2 実施事項、組織体制、方針

2.1 実施事項

 ISMSを実施する場合に求められることは次の通りです。
① ISMSに関する方針を定め、要求事項を満たすことや継続的改善へコミットメントする
② リスクマネジメントなどISMSに関する計画を立案すること
③ 必要な資源や人員を確保すること
④ 策定した計画を運用すること
⑤ ISMSの実施に関するパフォーマンスと有効性を評価すること
⑥ 不適合が発生した場合には是正措置を行い、ISMSを継続的に改善すること

 以上のことをするためにはPDCAサイクルを回すことが重要というのがISO/IEC 27001の考え方でしたが、ISO/IEC 27001:2013では方法論の1つという位置づけになっています。

※ISO/IEC 27001ではPDCAサイクルの採用を強く求めていましたが、最新版のISO/IEC 27001:2013 (JIS Q 27001:2014)ではPDCAに関する記述はありません。最新版では、様々なモデルの採用の可能性を示唆しています。そして、付属書ではPDCAサイクルの概念を受け入れています。様々なモデルの採用があり得るが、PDCAサイクルはその中の有力な候補の1つだという位置づけのようです。

2.2 組織体制

 JIS Q 27001:2014は組織体制については「4 組織の状況」と「5 リーダシップ」で規定しています。分かりにくい文章ですので、少しかみ砕いて説明します。

2.2.1 「4.1組織及びその状況の理解」

 「4 組織の状況」の最初の「4.1 組織及びその状況の理解」で「組織は、組織の目的に関連し、かつ、そのISMSの意図した成果を達成する組織の能力に影響を与える外部及び内部の課題を決定しなくてなならない」と規定しています。

 少しわかりにくいので、中抜きして考えてみましょう。中を省略すると、「組織は、外部及び内部の課題を決定しなくてはならない」となります。

 「課題の決定」に関しては、注記ではJIS Q 31000: 2010の「5.3」に記載されている組織の外部状況及び内部状況の確定のことだと言っています。

 JIS Q 31000:2010の「5.3.2」では、「外部状況の確定」で、「外部状況とは、組織が自らの目的を達成しようとする状況を取り巻く外部環境」だとしています。そして、例として、社会及び文化、政治、規律、金融、技術、経済並びに競争の環境、あるいは組織の目的に影響を与える主要な原動力及び傾向、あるいは外部利害関係者との関係並びに外部利害関係者の認知及び価値観などが挙げられています。
 
 JIS Q 31000:2010の「5.3.3」では、「内部状況の確定」で、「内部状況とは、組織が自らの目的を達成しようとする状況を取り巻く内部環境」だとしています。

 リスクマネジメントプロセスは組織の文化、プロセス、体制及び戦略と整合していることが望ましいのですが、内部状況とは、組織がリスクを運用管理する方法に影響を及ぼすことがある組織内の全てを意味します。従って、セキュリティマネジメントのプロセスまたは活動に関する目的及び基準は、組織全体の目的に照らし合わせて考慮されなくてはならないし、リスクマネジメントも組織の目的に沿って行われなくてはなりません。

 「5.3.3」で内部状況に含まれることの例として次のような例が挙げられています。
-統治、組織体制、役割及びアカウンタビリティ
-方針、目的及びこれらを達成するために策定された戦略
-資源および知識として把握される能力(資本、時間、人間、プロセス、システム、技術)
-内部利害関係者との関係並びに内部利害関係者の認知及び価値観
-組織の文化
-情報システム、情報の流れ及び意思決定プロセス(公式、非公式)
-組織が採択した規格、指針及びモデル
-契約関係の形態及び範囲

 これで「外部及び内部の課題」が分かりました。これらの課題について、「4.1」は「組織の目的に関連し、かつ、そのISMSの意図した成果を達成する組織の能力に影響を与える」課題と言っています。

 「ISMSの意図した成果」とは何でしょうか?これについては、規格の概要(「0.1」)で書いているように、「リスクマネジメントプロセスを適用することで、情報の機密性、完全性、可用性を維持し、リスクを最適に管理しているという信頼を利害関係者に与えること」だと考えられます。

 従って、考えなくてはならない「課題」は、「組織の目的や、機密性・完全性・可用性を維持するために必要なこと」というように解釈することができます。

2.2.2 「4.2利害関係者のニーズ及び期待の理解」

 「4.2 利害関係者のニーズ及び期待の理解」では「利害関係者」と「その利害関係者の情報セキュリティに関連する要求事項」を定めなさいと言っています。

 利害関係者として考えられるのは、会社の株主、従業員、取引先、顧客などですが、これからISMSを構築していくにあたりどのあたりまで考慮するかということになります。

 その利害関係者が今回のISMSの構築に対して何を要求しているのか、何を望んでいるのか、何を期待しているのかを考えなさいということです。

2.2.3 「4.3 適用範囲の決定」

 「4.3 適用範囲の決定」ではISMSの適用範囲を自由に定めることができると規定しています。会社全体で適用するという場合もあるでしょうし、業務の範囲で区切って、例えばある特定事業本部に限定して適用するとか、ネットワーク管理部門だけ、あるいは場所、あるいは建物で限定して、ある特定の事業所の敷地の範囲で適用するとか、特定の建物限定で適用するなどの方法が考えられます。

 ただし、適用範囲は勝手に自由に決めていいというわけではありません。「4.1 に規定する外部及び内部の課題」、「4.2 に規定する要求事項」、「インターフェース及び依存関係」を考慮して決めなくてはなりません。そして、適用範囲を決めたら、文書化して、利用可能な状態にしておく必要があります。

2.2.4 「4.4 情報セキュリティマネジメントシステム」

 「4.4では、この規格に書かれている要求事項に基づいてISMSを確立し、実施し、維持し、改善する必要があると規定しています。これはISMSを運営していくためには、いわゆるPDCAサイクルを回していく必要があることを要求していると読めます。

2.2.5 「5.1 リーダシップとコミットメント」

 JIS Q 27001:2014の「5」はリーダシップについて規定しています。この中でトップマネジメントという言葉が盛んに使われていますが、これは何を指しているのでしょうか?用語の定義はJIS Q 27000で与えられていますので見てみましょう。それによるとトップマネジメント(top management、JIS Q 27000の2.84)は「最高位で組織を指揮し、管理する個人または人々の集まり」となっています。これを読むと単純に「社長」なのかなとも思えますが、この規定の注記1では「トップマネジメントは、組織内で、権限を委譲し、資源を提供する力を持っている。」とあります。注記2では「マネジメントシステムの適用範囲が、組織の一部だけの場合、トップマネジメントとは、組織内のその一部を指揮し、管理する人を言う」とあります。したがって、全社レベルでマネジメントシステムを適用する場合は社長で、事業部単位で行う場合は、その事業部の事業部長ということになります。部単位の場合は、部長ということになります。

 「5.1」ではトップマネジメントは、「a」~「h」までに列挙されたことに「リーダーシップとコミットメントを実証しなくてはならない」と言っています。コミットメントはこの場合は「約束する」とか、「本気で深く関与する」というような意味だと思います。a)~h)は次の通りです。

a) 情報セキュリティ方針及び情報セキュリティ目的を確立し、それらが組織の戦略的な方向性と両立することを確実にする。
b) 組織のプロセスへのISMS要求事項の統合を確実にする。
c) ISMSに必要な資源が利用可能であることを確実にする。
d) 有効な情報セキュリティマネジメント及びISMS要求事項への適合の重要性を伝達する。
e) ISMSがその意図した成果を達成することを確実にする。
f) ISMSの有効性に寄与するように人々を指揮し、支援する。
g) 継続的改善を促進する。
h) その他の関連する管理層がその責任の領域においてリーダーシップを実証するよう、管理層の役割を支援する。

2.2.6 「5.2方針」

 トップマネジメントは、情報セキュリティ方針を確立しなくてはなりません。そして、情報セキュリティ方針に盛り込まなくてはならない要件が「a」~「g」まで列挙してあります。

2.2.7 「5.3組織の役割、責任及び権限」

 トップマネジメントは、情報セキュリティに関する役割に関して、自分以外の人に責任と権限を割り当てることができます。具体的には実際の業務がISMS規格の要求事項を満たすようにすること、その結果をトップマネジメントに報告するという2点においては、責任と権限を他の誰かに割り当てなくてはなりません。この人がISMSの責任者になります。一般的にはCISO(Chief Information Security Officer、最高情報セキュリティ責任者)という名前が与えられることが多いと思います。



2.3 情報セキュリティポリシー

 JIS Q 27001:2014の[5.2方針」は「a」~「d」までに情報セキュリティ方針が満たすべき要件を上げています。

a) 組織の目的に対して適切である。
b) 情報セキュリティ目的を含むか、または情報セキュリティ目的の設定のための枠組みを示す。
c) 情報セキュリティに関連する適用される要求事項を満たすことへのコミットメントを含む。
d) ISMSの継続的改善へのコミットメントを含む。

 「e」~「g」には情報セキュリティ方針が満たさなくてはならない事項を上げています。
e) 文書化した情報として利用可能である。
f) 組織内に伝達する。
g) 必要に応じて利害関係者が入手可能である。

 情報セキュリティ方針は会社の情報セキュリティに関する原則や基本的な考え方を示す公式の文書です。この方針は社長が制定します。

 情報セキュリティ方針は会社の目的に対して適切でなくてはなりません。また、情報セキュリティの目的が示されていなくてはなりません。なぜ会社がISMSに取り組むのか、ISMSの狙いと必要性、重要性を明確にしなくてはなりません。会社のISMSをJIS Q 27001: 2014規格が要求するものに合わせるようにコミットメントしなくてはなりません。また、会社の事業上の要求事項、情報セキュリティに関する法令やガイドラインが求めているもの、契約上のセキュリティ義務などを遵守しなくてはなりません。また、ISMSを継続していく中で、内部監査の結果に対する改善点への対応や、改善策の実施結果の分析など、ISMSを継続的に改善していくことへの社長の誓約がなくてはなりません。

 情報セキュリティ方針の構成については特別な決まりがあるわけではありませんが、通常は3段階の階層構造をなしています。トップに位置するのが情報セキュリティ基本方針で、情報セキュリティの目標と、その目標を達成するために企業がとるべき行動を宣言します。また、なぜセキュリティが必要か、何をどこまで守るのか、誰が責任者かなどを明確にします。

 次の層に位置するのが情報セキュリティ対策基準です。ここでは、基本方針で示された目的を達成するためのは何をしなくてはならないかが記述されます。情報セキュリティ対策を行うためのルール集です。対策基準では、規定、適用範囲、対象者を明確にしなくてはなりません。

 第3層に位置するのが情報セキュリティ実施手順です。実施手順では、対策基準に定めた規定をどのように実施するかについて記載します。マニュアル、ガイドラインなどもここに入ります。

 基本方針と対策基準を併せて情報セキュリティポリシーといいます。あるいは、実施手順まで含めて情報セキュリティポリシーということがあります。





3 リスクマネジメント

 リスク(risk)とは脅威が、情報セキュリティ資産が持つ脆弱性につけ込み、組織に損害を与える危険性、あるいは可能性を言います。ここで言う脅威(threat)とはシステムまたは組織に対して損害を与える可能性のことです。脆弱性(vulnerability)とは脅威によってつけ込まれる可能性のある資産または管理策の弱点を指します。

 リスクをきちんと評価して、それに対する適切な対策を施すことをリスクマネジメントといいます。

※JIS Q 27001:2014ではリスクマネジメントに関しては、JIS Q 31000:2010(ISO 31000:2009)及びJIS Q 0073:2010(ISO Guide73:2009)と整合性がとられています。

3.1 リスクマネジメントの枠組み

 最初にリスクの運用管理のための枠組みを作らなくてはなりません。そのためには組織の内部、外部の状況を理解することが必要です。

 全社をあげてリスクマネジメントをするためにはリスクマネジメントプログラム全般を総合的に管理する統括的な管理組織が必要です。この組織をここでは「リスク管理委員会」とします。リスク管理委員会は経営トップに直結した組織とし、リスク管理委員会には情報収集の責任と権限を与えてください。

 リスクマネジメントに必要な資源をリスク管理委員会に割り当てます。この際は、人員、技能及び力量を考慮してください。それから、リスク管理の各プロセスで必要な資源を割り当てます。

 リスク管理委員会では、リスクマネジメントの方針を確定して、適切に社内に伝達して下さい。内部のコミュニケーション及び報告の仕組みを作って、社内の各部門から的確に情報を集めます。各部門はリスク管理委員会と連携しつつ、部門毎にリスクを分割管理します。

 組織を指揮統制するための仕組みができたら、リスクマネジメントを実践します。この実践は通常リスクマネジメントプロセスと呼ばれます。

 リスクマネジメントの枠組みは次のように進められます。

リスクマネジメント 枠組みの設計
プロセス
モニタリングとレビュー
枠組みの継続的な改善
 
 この4つの手順は順に進められます。また、この4つを順に行いつつリスクの運用管理をするための方針、目的、指令などの取り決めもこの枠組みの中に入ります。



3.2 リスクマネジメントプロセス

 リスクマネジメントプロセスは、リスクを的確に認識し対処していく過程です。リスクマネジメントプロセスでは、組織の状況に照らし合わせてどのようにマネジメントプロセスを進めていくかを決めていきます。どこの範囲にリスクマネジメントプロセスを適用するのか、どの程度であればリスクと判断するのか、どの程度は軽微なリスクといえるのかなどの基準を予め設定しておく必要があります。

 リスクマネジメントプロセスは組織の事業プロセスに合わせて作られており、組織の文化及び実務の中に組み込まれていることが必要です。組織の事業プロセスと全く関係のないところで行われるものならば、初めはいいですが、そのうちにないがしろにされてしまうでしょう。

 その後リスクアセスメントを行い、その結果に基づいて、リスク対応をします。

リスクマネジメントプロセス 組織内の状況の確定
リスクアセスメント
リスク対応


 リスクマネジメントプロセスの流れは次のようになります。リスクマネジメントプロセスでは、社内・社外の利害関係者と常に意思疎通を図りながら行わなくてはなりません。また、プロセスの各ステップでその都度モニタリングとレビューを行う必要があります。各ステップでモニタリングを繰り返すことで、リスクマネジメントプロセスが空洞化することを防がなくてはなりません。プロセスの実施組織は「できたと」といって、それでおしまいにして、各部門では多分分かってくれるだろうと思っていると、実は周りは全くついて来ていなかったということが良くあります。



3.3 リスクアセスメント

 リスクアセスメント(risk assessment)は、一般には、リスクの特定、リスクの分析、リスクの評価から成るとされていますが、リスクアセスメントに取り組む前に、リスクアセスメントの取り組み方法の定義しておかなくてはなりません。

リスクアセスメント リスク特定
リスク分析
リスク評価


 リスクアセスメントの取り組み方法の定義では、リスク基準を作成し、リスクアセスメントの一貫性、妥当性、比較可能性を保証するためのプロセスを定めて文書化します。

 リスク基準にはリスク受容基準と実施基準を含めなくてはなりません。リスク受容基準とは、組織としてリスクを保有することを許容するリスクの水準です。

3.4 リスクの特定

 リスク(risk)とは脅威が、情報セキュリティ資産が持つ脆弱性につけ込み、組織に損害を与える危険性、あるいは可能性を言うと説明しました。従って、リスクを特定するためには会社にどのような情報資産があるかを把握する必要があります。そのためには情報資産の洗い出しを行うと同時に、その資産の管理者が誰なのかも特定していきます。

 洗い出しを行った情報資産にはどのような脆弱性があるかを調査します。そして、その情報資産と脆弱性の組み合わせに対して、どのようなリスクがあるのかを判断していきます。

 情報資産は情報そのもの、とその情報を利用するために必要な様々なもの、プラス組織の評判(いわゆる”のれん”)、ノウハウなどが含まれます。

 情報を利用するために必要なものは、紙に書かれている情報の場合は、紙です。電子的な情報の場合は、その情報が格納されているコンピュータ、その情報が書かれたファイル、そのファイルを読み込むためのソフトウェア(WORD、Excelなど)、その情報がサーバ上にあり、ネットワークを経由で閲覧しなくてはならない場合は、ネットワーク機器(ルータ、スイッチ)、ネットワーク回線なども含まれてきます。また、プリンター、プロジェクタなどの出力装置、スキャナ、OCR(Optical Character Recognition)装置、外付けのフロッピーディスク装置、MO、メモリカードドライブなどの入力装置なども情報資産となります。



3.5 リスクの分析

 洗い出したリスクを分析します。分析手法としては、いくつかの方法があります。一般的に利用される手法には次のようなものがあります。

リスク分析方法  ベースラインアプローチ
非形式的アプローチ
詳細リスク分析
組み合わせアプローチ 


 分析手法について簡単に説明すると次のようになります。

リスク分析手法 内容 評価
ベースラインアプローチ 予め確保すべきセキュリティレベル(ベースライン)を設定し、そのための対策を選択し、対象となるシステムに一律に適用する 場合によっては不十分、あるいは過剰な分析となる
非形式的アプローチ 分析者の経験や判断に従ってリスクを評価する方式 分析者に能力があれば良いが、分析者が能力不足の場合は、適切な結果を得られないかも知れない
詳細リスク分析 詳細なリスクアセスメントを実施するアプローチで、情報資産に対して、資産価値、脅威、脆弱性やセキュリティ要件を識別し、評価する 情報資産ごとのリスク分析が可能だが、分析には多くの時間が必要
組み合わせアプローチ ベースラインアプローチと詳細リスク分析の手法を組み合わせる方法 システムによってはベースラインアプローチでは不十分であるが、詳細アプローチを適用すると過剰となってしまう場合もある。そこで、必要性に応じて、2つのアプローチを組み合あせることとした。一般的には最も推奨されるアプローチ





3.6 リスク評価

 全てのリスクを列挙し、列挙したものを片っ端から順番に処理していくと大変なことになります。全部終わるのに長期間かかる可能性があります。もしかしたら、何時まで経っても終わらない可能性もあります。そこで、発生した場合の影響の大きさと、発生頻度という観点からリスクを評価して(「影響力の大きさ」×「発生頻度」=「リスクの大きさ」)、リスクの大きなものから、対応するという必要があります。



3.7 リスク対応

 リスクを評価したらそのリスクに対してどのように対処すべきかということになります。全てのリスクに対して対応を考えるのが理想ですが、前に言いましたように、大きなリスクに対策が取れないうちにリスクが実現化してしまう可能性がありますので、大きなリスクから対応していかざるを得ません。対策は、コスト、マンパワーなどとのバランスで決めていきます。例えば、1万円する機器があったとします。これに対して、リスクがあると評価されました。もし、リスクが実現化すると、業務上10万円程度の損失が発生すると見込まれます。そして、この対策費として約100万円がかかると予測された場合に、さてどうするかという問題になります。

 対応方法としてはいくつかありますが、代表的な対応策は次のようなものです。

リスク対応 リスク回避
リスク低減
リスク移転
リスク保有

 1つずつ見ていきましょう。

リスク対応の方法 内容 評価
リスク回避 リスクが発生しないように対策する 発生確率が高く、しかも発生した場合の損害規模が大きい時に一般的に採用される方法

 コストの割りに利益がそれほど期待できない場合、適切な対策が見いだせない場合に採用します。例えば、個人情報を保有するのはリスクが高いので、個人情報は取得しないとか、リスクを回避するために特定の事業をやめてしまうなどです。

リスク対応の方法 内容 評価
リスク低減 リスクの発生頻度を下げるように対策する 発生確率は高いが、損害の程度はそれほど大きくない場合に採用される


 リスク低減は「リスクの最適化」などとも呼ばれます。リスクの元を除去したり、起こりやすさを低下させたりすることです。個人情報の漏洩対策の例としては、①技術的対策として、データベースの暗号化、DBサーバへのアクセス制御、ファイルへのアクセス制御、データベースの改ざん防止などが、②組織的・人的対策として、社員教育(パスワードの扱い方等)、③物理的な対策として、サーバ室への入退出管理などが考えられます。

 特に技術的な対策としては、認証、アクセス制御、情報の暗号化、通信の暗号化(SSL/TLS、SSH、VPN、IPsec等)、ファイアウォール、IDS/IPS、検疫システム、情報のバックアップ、ログの採取、OSやソフトウェアのセキュリティパッチの適用、システムの動作状況の確認(SNMP)、ウィルス対策ソフトウェアの導入などがあります。

 組織的・人的対策としては、情報セキュリティマネジメントシステムの採用などがあります。


リスク対応の方法 内容 評価
リスクの移転 リスクに関して損失を他者と共有する対策。例:アウトソーシング先にリスクの発生源を移動する 発生確率はそれほどでもないが、発生した場合の損失が大きくなる場合に採用される

 対策そのものを外部委託し、インシデント発生の責任を取ってもらう方法と、保険契約することでインシデント発生時の損失を分散する方法などが考えられます。

リスク対応の方法 内容 評価
リスクの保有 リスクを抱えておき、問題発生時に個別に対応する 発生確率が低く、損害の規模も小さい時に採用される


 リスク対応で選んだ選択肢に応じてリスクを修正しする対策が管理策(リスクコントロール)です。

 選定した情報セキュリティリスク対応の選択肢の実施に必要な全ての管理策を決定し、管理宣言書を作成します。管理宣言書には、必要な管理策と、それらの管理策を含めた理由、それらの管理策を実施しているか否かなどを記載します。

 更に情報セキュリティリスク対応計画を策定します。更に、情報セキュリティ対応計画書と受容リスクに関してリスク所有者の承認を得ます。

3.8 コミュニケーション及び協議

 外部及び内部の利害関係者とのコミュニケーション及び協議は、リスクマネジメントの全ての段階で実施してください。そのため、計画は早い段階で立てる必要があります。コミュニケーション及び協議では、リスクそれ自体、原因、(既知の場合は)リスクの結果、及びリスクに対応するために講じられるべき対策に関わる事項を扱ってください。

3.9 モニタリングとレビュー

 モニタリングとレビューはリスクマネジメントプロセスの一部として計画され、定期的または臨時に行われます。

 モニタリングとレビューに関しても責任を明確に規定してください。

 モニタリングとレビューのプロセスは、リスクマネジメントプロセスの全ての側面を網羅してください。次のようなことを心がけて下さい(JIS Q 31000:2010 「5.6」)。

-管理策が、設計及び運用の双方において、効果的かつ効率的であることを確実にする。
-リスクアセスメントを改善するための更なる情報を入手する。
-事象、変化、傾向、成功例及び失敗例を分析し、そこから教訓を学ぶ。
-リスク基準、並びにリスク対応及びリスクの優先順位の見直しを必要とすることがあるリスク自体の変化を含む、外部及び内部の状況の変化を検出する。
-新たに発生しているリスクを特定する。

 情報セキュリティ対応計画の進捗状況では、パフォーマンスの尺度を提出してください。
 
 モニタリング及びレビューの結果は記録に残し、適切に、外部及び内部に報告し、リスクマネジメントの枠組みのレビューに対するインプットして活用してください。

3.10 リスクマネジメントプロセスの記録作成

 リスクマネジメントのプロセスは記録を作成し、後で追跡ができるようにしておいてください。記録は、プロセス全体と共に、方法及び手段の改善の元となります。そのためには、記録の作成に関して次のことに留意してください(JIS Q 31000:2010 「5.7」)

-継続的学習に関する組織のニーズ
-経営の目的のために情報を再利用することの便益
-記録の作成及び維持管理に含まれる費用及び労力
-記録に関する法律上、規制上及び業務上のニーズ
-閲覧方法、検索の容易性及び保存媒体
-保有期間
-情報の機微性






更新履歴


2016/09/14          作成































































 ページの先頭