評価されたリスクへの管理策の選択情報セキュリティマネジメントシステム基礎講座(5)

» 2002年11月29日 00時00分 公開
[駒瀬彰彦アズジェント]

 前回(第4回 ISMS構築で重要なリスクアセスメントの手法:GMITS-Part3)でリスクマネジメントにおけるリスクアセスメントの手法を紹介した。今回は、評価されたリスクに対してどのようにセーフガード(管理策)を選択するのか、そもそも管理策の選択とはどのような意味なのかを説明し、同時に有用なガイドを紹介する。

リスクマネジメントにおけるセーフガード(管理策)の選択

 管理策の選択というと、問題点(リスク)に対するソリューション(適切解決策)を決定することのように思われがちで、一連のセキュリティ対策における最終地点ととらえる方々が多いがそうではない。

図1 詳細リスク分析を含むリスクマネジメント(GMIT-Part3より抜粋) 図1 詳細リスク分析を含むリスクマネジメント(GMIT-Part3より抜粋)

 前回でも示したとおりセーフガードの選択はリスクマネジメントにおける1プロセスでしかない(図1)。また、適切な管理策を実装するというプロセス、すなわち、対策実装に関する計画を立案し、テストを行い、実装し、それらが正確に動作しているかをチェックし、改善するというPDCAサイクルのP(Plan:計画)に当たる部分にすぎない。

 また、管理策の選択とは、評価されたリスクに対しての処理方法(Risk Treatment)全般を考慮し、その中から適切な管理策を選択することを意味し、単にウイルス対策のためにワクチンソフトウェアを導入する、不正アクセスを防止するためにファイアウォールを設定するというような技術的対策を選択するという意味だけではない。

リスク処理方法

 リスクアセスメント後、識別されたリスクに対する処理には、大きく分けてリスクコントロールとリスクファイナンスという考え方がある。

●リスクコントロール

 リスクコントロールとは、リスクが現実化しないように、または、現実化してもその損害を最小限にするために事前に備えるセキュリティ対策のことで、予防するためのコントロールとリスク発生後の損害を低く抑えるコントロールがある。

 予防するためのコントロールには、リスクの要因となる“脅威”や“脆弱性”を少なくするための管理策などが該当する。

●リスクファイナンス

 リスクファイナンスとは、リスクが現実化してしまったときに備える資金的対策のことで、リスク保有とリスク移転という考え方がある。

 リスク保有は、自らの財政力をもって、財務上自己負担する資金的対策で、リスク移転とは、保険会社などの第三者に資金的なリスクを移転させることを指す。火災保険に加入するであるとか、システム障害に備えてIT保険に加入するといったコントロールがこれに当たる。

 一般にリスクマネジメントにおけるこれらの対策を総合的に考慮して実装していく必要があり、セーフガードの選択とは、かなりの広範囲のことを含んでいるのである。もちろん、リスクが極めて小さいので何も対策を施さないということも、りっぱなリスク処理方法の1つである。 

 これらのリスク処理方法の中で、最も注目されていて連日雑誌などで紹介されているのが、いわゆるリスクコントロールである。その中でもリスクを低減するためのコントロールとしては、安全なWebサーバの構築であるとか、ファイアウォールの設定方法などがこれに当たる。また、ISO/IEC 17799やJIS X 5080の詳細管理策、GMITS -Part4、5、PD3005(参考:第2回 認証取得のためのISMSガイド)などに記載されている詳細管理策もこれに当たる。 

 余談であるが、ISO/IEC 17799とBS7799-Part2または、JIS X 5080とISMS認証基準の差がよく理解できないという声も聞く。人によっては、両者には大差がなく、むしろISO/IEC 17799やJIS X 5080の方がより詳細にコントロールや例が記述されていることから、他方より優れているととらえている場合さえある。もちろん、ある場面においてはそれを否定できない部分もあるだろうが、これらの位置付けには大きな違いがある。このことは、ここまでに触れたリスク処理ということからも理解していただけるのではないだろうか? 

 すなわち、BS7799-Part2やISMS認証基準はISMS構築の仕様であり、リスクマネジメントが十分に行われるための体制およびリスクアセスメントの結果を踏まえ、前述した対策を総合的に考慮して適用することが可能な状態を要求しているのである。一方、ISO/IEC 17799やJIS X 5080は、その過程の中におけるリスク低減に適切であろうと考えられるベストプラクティスを実施基準として紹介しているにすぎない。従って、ISMSの構築とは、決して、ISO/IEC 17799やJIS X 5080の詳細管理策を単に実装することではないことを再認識していただきたい。

 さて、話を元に戻すが、リスクを低減するためのコントロールには、運用面での対策(非技術的な対策)と技術的な対策がある。GMITS-Part3では、非技術的な対策には物理的、人的、および管理的な対策があるとしている。

非技術的な対策
物理的 建造物内の壁面強化、消火システム、
ドアのセキュリティ強化など
人的 採用条件の見直し、人員の監視、教育など
管理的 安全運用手順書の完備、事業継続計画、
復旧計画の立案など
リスクを低減するためのコントロール

 一方、技術的な対策としては、ハードウェア、ソフトウェア、通信全般に関する対策が含まれる。これらの例は、身近にある雑誌などのネットワークのセキュリティ対策などを参照していただければよいであろう。重要なのは、これらの技術的な対応策は、セキュリティの機能と保証を提供するためにリスクに応じて選択されることである。セキュリティ機能とは、例えば、識別と認証、アクセス制御の要件、監査証跡/監査ログの要求、暗号化、メッセージ認証などを対象とする。保証要件とは、セキュリティ機能に必要な信頼のレベルを示し、従ってチェックの量と種類、テストなど、そのレベルを確認するのに必要な事項のことである。ここで、ピンとくる読者が多いのではと思うが、セキュリティ機能要件と保証要件に関する優れたガイドがISO/IEC 15408やJIS X 5070である。

 商品のセキュリティ評価を行う規格として、よく紹介される規格であるが、もともとCommon Criteria(コモンクライテリア)として知られた規格で情報技術セキュリティの評価基準のことであり、技術的な対応策を選択する際に考慮すべき事項が網羅されており有用なガイドである。ISO/IEC 17799は管理面の対策であるのに対し、ISO/IEC 15408は技術面の対策であるといわれるゆえんはこのあたりにある。

管理策の選択プロセス

 リスクアセスメントから管理策を選択し、実装するというプロセスを別の観点からまとめたものを図2に示す。この図はPD3005に記載されている。この図は、保護対象となる情報資産に要求されるセキュリティ要求事項に対して、BS 7799から管理目的を識別し、その管理策を実施することによってセキュリティの懸念を満たす一連の作業を示している。時間の経過や環境変化などによって、新たに識別されたセキュリティ要求事項を満たすために、この一連のプロセスは繰り返し実施される。

図2 管理策の選択プロセス 図2 管理策の選択プロセス

 この図中にある文章は、矢印の始点を主語に終点を目的語として成立する。すなわち、「セキュリティ要求事項は、管理目的として定義される」「管理目的は管理策によって満たされる」「管理策はセキュリティの懸念事項に対して保護する」「セキュリティの懸念事項はセキュリティの要求事項を識別する」と解釈していただきたい。ここで重要な点は、管理策は、ある目的を満たすために選択されるということである。いい換えると、選択された管理策は説明されなければならない。

 PD3005では、ISMSを構築するということは、管理策の選択という観点からすると、「組織は、管理策の選択プロセスの結果として、適用した管理目的および管理策を提示し、なぜそれらが必要であるかの理由を説明しなければならない。また、組織は必要でない管理策を提示し、なぜそれらが必要でないかの理由を説明する必要もある。」とあり、このことが、審査時に要求されることなのである。逆にいえば、ISMSの審査は、単に詳細管理策を施しているか否かの監査ではないことに留意していただきたい。


 次回は、セキュリティ監査の考え方と有用なガイドを紹介する。

著者紹介

株式会社アズジェント セキュリティポリシー事業部 

駒瀬 彰彦(こませ あきひこ)

取締役事業部長、ISMS適合性評価制度技術専門部会委員副主査、英国BSi (British Standards Institution)認証BS7799スペシャリスト。財団法人インターネット協会セキュリティ研究部会 副部会長。

株式会社アズジェント

トータルセキュリティソリューションプロバイダ。ファイアウォールなどセキュリティ商品提供を始め、コンサルティングや各種トレーニングを開催している。



Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。