教学相長：ＩＳＭＳ／情報セキュリティ

　ここまで、リスクアセスメントを効果的、効率的に実施するために、情報資産の重要性（機密性、完全性、可用性が侵害された場合の影響のレベル）を評価し、情報資産の特性に応じてグループ化し、それぞれの脅威、脆弱性を特定・評価することを述べてきました。
　次は、規格要求事項 4.2.1e) の　3)リスクのレベルを算定し、4)リスクが受容できるか、又は対応が必要であるかを判断する。作業となります。
　まずは、「リスクレベルの算定方法」を定めておく必要があります。

　リスクの定義を紹介していませんでした。規格要求事項には、「リスク」の定義はありませんが、引用規格とされているJIS Q 27002(ISO/IEC27002:2005)で、「リスク：事象の発生確率と事象の結果の組合せ」（ここでの”事象”は、望ましくない事象に限定して良いでしょう。）としています。

　”事象の発生確率”は、脅威の発生頻度と脅威に対する脆弱性の程度で考えられます。”事象の結果”は、機密性、完全性、可用性が侵害された場合の影響（損害）の大きさとなります。
　これまで説明してきた、「情報資産の重要レベル（機密性、完全性、可用性が侵害された場合の影響のレベル）」と「脅威、脆弱性の評価レベル」をリスクの算定に用いるのです。

　前回は、リスクアセスメントを効果的、効率的に実施するために、情報資産のグループ化について説明しました。
　今回は、グループ化した情報資産の脅威・脆弱性の特定です。規格要求事項 4.2.1 d) 2 及び、c) 2 にあたる部分です。

　ちなみに、規格要求事項には、脅威、脆弱性の定義はありません。そこで、JIS Q l3335-1:2006（情報通信技術セキュリティマネジメント−第１部：情報通信技術セキュリティマネジメントの概念及びモデル）より引用して紹介しておきます。
・脅威：システムまたは組織に危害を与える、好ましくない偶発事故の潜在的な原因
・脆弱性：脅威によって影響を受け得る資産または資産グループの弱さ

　日常生活の中で例をとれば、「建物」という全体でいえば「泥棒にあう」という脅威にあたります。その脅威に受ける要因として、「泥棒の対象となりやすい立地環境にある」「ピッキングしやすい鍵である」「風呂場の窓が締められていない」などといったいろいろな脆弱性が見い出されます。その上で、「ピッキングしやすい鍵」という脆弱性に対して、「ピッキングしにくい鍵に交換する」「もう一つ鍵を付ける」「ピッキングセンサー・アラームを取り付ける」などの対策を考え、費用対効果などを考慮して対策を講じることになります。

　先週末、Ａ社の第四回目ＩＳＭＳ認証取得プロジェクト会議を開催しました。今のところ、ほぼ順調に進んでいます。
　こちらの説明は、第三回目プロジェクト会議での作業についての説明で、前回の情報資産の機密性(C)、完全性(I)、可用性(A)に続いて、”グループ化”の話です。

　次回の話となりますが、それぞれの情報資産にどのような脅威があるか？その脅威につけ込まれる脆弱性があるかを検討し、機密性・完全性・可用性を考慮のうえ、放置できない脆弱性には、何らかの補強策（セキュリティ対策）を講じることが必要です。
　この一連の作業がリスクアセスメントですが、洗い出された情報資産の一つ一つに検討していくと大変な作業となります。
　そこで、情報資産をグループ化して、グループ単位でリスクアセスメントを行うわけです。

　前回、説明すればよかったのですが、規格には、具体的なリスクアセスメントの手法は示されていません。また、リスクアセスメントの手法は幾つかの方法があります。
　ここで、紹介する手法は、GMITS（The Guidelines for the management of IT Security：ITセキュリティマネジメントのためのガイド）のISO/IEC TR 13335-3:1998で紹介されている例を参考にしたものです。

　まず、リスクアセスメントの最初の作業として、情報資産の機密性(C)、完全性(I)、可用性(A)を評価します。
　規格要求事項に示されているリスクアスメントの流れは次のようになっていますが、順番としては逆ですが、４）にあたる作業です。
　１）資産及び資産の管理責任者を特定する。
　２）それらの資産に対する脅威を特定する。。
　３）特定した脅威がつけ込む可能性のある脆弱性を特定する。
　４）機密性(C)、完全性(I)、可用性(A)の喪失が及ぼす影響を特定する。

　事故等の結果としてCAIの喪失による発生コストを予測する作業とといえます

　第三回目からは、いよいよ、ＩＳＭＳ構築の具体的な作業です。
　プロジェクト会議のレジュメ次第は次の通りですが、この部分は重要であり、第三回、第四回と継続して取り組みます。
　　１、リスクアセスメントの手法について
　　　　　・リスクアセスメントに関する要求事項
　　　　　・リスクアセスメント実施手順の提案
　　２、情報資産目録の作成について
　　　　　・情報資産のＣＩＡ評価
　　　　　・グループ化
　　　　　・資産目録の作成
　　３、リスクアセスメントの実施
　　　　　・脅威・脆弱性の特定
　　　　　・対策と詳細管理策の選択
　　　　　・残留リスク
　　４、リスク対応計画の作成について

　前回の規格要求事項の説明に続いて、再度、リスクアセスメントに関する規格要求事項を説明しました。この部分は、審査でも重点的に説明が求められますので、しっかりと理解していただきます。
　続いて、リスクアスメントの手法を決定します。

　今回は、第二回目プロジェクト会議の内容をご紹介します。
　レジュメ次第は、次のような簡単なものです。
　　１、JISQ27001規格要求事項について
　　２、情報資産の洗い出し状況について

　ＩＳＭＳ構築にあたっては、JISの規格要求事項を充分に理解しておく必要があります。また、ＩＳＭＳの審査を無難に対応する上でも重要です。
　およそ、３時間かけて、箇条ごとに、要点を説明させていただきました。とは言っても、その場で全てをご理解していただくのは難しいと思いますので、今後の作業の中で、なぜ、この作業を行う必要があるかについての説明を加え、審査までには、重要部分についてはしっかり理解していただきます。

　ＩＳＭＳの本質は、規格要求事項の「1 適用範囲 1.1 一般」に記載中の次の事項だろうと思っています。
　○その組織が存立するための核の事業リスクを考慮する
　○利害関係者に信頼を与えるセキュリティを確実にする

　この説明や個々の規格要求事項に関する説明は到底ここに書ききれませんので、今後の作業を紹介する中で触れて行きたいと思います。

　あとは、宿題としていた情報資産の洗い出しの状況を確認して終わりました。
　まだ、整理できていないものの、４０人弱の会社でも、６００件以上がリストアップされていました。
　第二回目プロジェクト会議の内容は、こんなところで終わっておきます。

　遅ればせながら、第一回目プロジェクト会議のレジュメ構成を紹介しておきます。
　　１、ブリーフィングツアー
　　２、ＩＳＭＳの概要
　　３、ＩＳＭＳ認証取得までの流れ
　　４、ＩＳＭＳへの取り組み
　　　　・適用範囲の決定
　　　　・ＩＳＭＳ組織の決定
　　　　・情報資産の洗い出し
　　　　・審査登録機関の選定

　これまで、ブリーフィングツアーとして社内を拝見し、ISMSの必要性や制度の説明、今後のスケジュールを確認したお話し、「適用範囲の決定」、「情報資産の洗い出し」について述べてきました。

　あと、「ＩＳＭＳ組織の決定」、「審査登録機関の選定」を簡単に述べて、第一回目プロジェクト会議のお話は終りにします。

　先週末、Ａ社の第３回目ＩＳＭＳ認証取得プロジェクト会議を開催しましたが、こちらでは、まだ、第一回目プロジェクト会議での作業の説明をしています。
　前回説明した「適用範囲の決定」に続いて、「情報資産の洗い出し」をお願いしました。

　JIS Q 27001では、リスクを特定するにあたって「ISMSの適用範囲の中にある資産及びそれらの資産の管理者を特定する。」とあります。
　また、管理策のA.7.1.1、A.7.1.2、A.7.1.3では、資産目録を作成すること。資産の管理者責任者を指定すること。資産の利用範囲を明確にすることが要求されており、情報資産の洗い出し（もしくは、情報資産の棚卸し）は、これらの作業のための基礎情報収集となります。

　そもそも「情報資産」とは何かを明確にしておかなければなりません。
　規格には、「情報資産」としての定義はありませんが、「資産」については「組織にとって価値をもともの」と定義されています。すなわち、「情報として、組織にとって価値のあるもの」ということになります。
　”組織にとって””価値あるもの”は、ISMSにおけるキーワードです。

＜前回からの続きです＞
　前回訪問時に、即決していただいたことから、早々に、ＩＳＭＳ認証取得に向けたプロジェクトを始動することとなり、第１回プロジェクト会議を開催しました。

　まずは、会社内を一通り巡回して、情報資産の存在やその扱いなどについて伺います。前回の訪問時に、一応は見学させていただき、およそは分かっていますが、ここでは、ロッカーや書棚の保管資料、パソコン内の情報、ネットワーク構成など詳細に確認させていただきます。また、屋外からも不正な侵入の可能性の確認、入退館の現状なども伺います。

　続いて、講義として、情報セキュリティの必要性など、情報漏洩等の実態やその原因、および、経営への影響などお話します。見学の中で見出した脆弱性などを例に、Ａ社でも、いつ発生してもおかしくないことを理解していただきます。また、ＩＳＭＳ適合性評価制度の仕組みを説明します。
　この部分は、セミナーなどでお話しする内容とほぼ同じです。

　今後、ほぼ、２週間に一回のプロジェクト会議を開催し、９月中の認証取得を目標とすることも確認しました。
（１回目は１月２５日に実施しましたので、約８ヶ月間の作業となります。）

　ここから、いよいよ、具体的な作業となります。
　最初の作業として、「ＩＳＭＳ適用範囲」を決定しなければなりません。

　ISO27001/ISMS構築支援日記でご紹介するお客様（これからは「Ａ社」とします。）の当初のご要望は、「プライバシーマーク付与認定を取得したい。」とのことでした。
　訪問してお話を聞くと「委託元より預った個人情報を加工する過程で、個人情報を適切に管理したい。」とのことでした。
　それならば、「プライバシーマーク」より「ＩＳＭＳ」が適切であること説明させていただき、ＩＳＭＳ認証取得を目指して取り組むことになりました。

　なぜ、Ａ社では、プライバシーマークよりＩＳＭＳが適切か？