平成 12 年度経済産業省産業技術環境局委託
情報システムのセキュリティ技術の標準化に関する調査研究
情報システムのセキュリティ技術標準化
調査研究委員会
報
告
書
平成１３年３月
財団法人
日本規格協会
情報技術標準化研究センター
1
□この報告書は平成 12 年度に当協会が経済産業省産業技術環境局から委託を
受けて実施した「情報システムのセキュリティ技術標準化調査研究委員会」
の成果をとりまとめたものです。
□この報告書に添付している JIS 原案は、JIS 制定の審議の過程において
変更があり得ます。
また、ISO での今後の国際的審議の結果、変更されることがあります。
2
目次
1. はじめに ……………………………………………………………………
1
2. 調査研究体制 ………………………………………………………………
2
2.1 委員会構成とテーマ
…………………………………………………
2
………………………………………………………
3
……………………………………………………………
5
3. WG1 活動報告 ………………………………………………………………
7
3.1 目的 ………………………………………………………………………
7
3.2 担当分野の標準化動向 …………………………………………………
7
3.3 今年度の活動 ……………………………………………………………
8
3.4 今後の予定 ………………………………………………………………
8
4. WG2 活動報告 ………………………………………………………………
9
2.2 委員会開催一覧
2.3 委員会名簿
4.1 目的
………………………………………………………………………
9
4.2 担当分野の標準化動向 …………………………………………………
9
4.3 今年度の活動 ……………………………………………………………
9
4.4 WG2 の国際活動への貢献
……………………………………………
10
4.5 今後の予定 ………………………………………………………………
11
5. WG4 活動報告 ………………………………………………………………
12
5.1 目的
………………………………………………………………………
12
5.2 今年度の活動 ……………………………………………………………
12
5.3 今後の予定 ………………………………………………………………
12
5.4 WG4 が担当する標準化案件
…………………………………………
12
…………………………………………………………………
16
6. 今後の課題
附属資料
附属資料１
標準情報 （TR）原案
1-1 TR X 0036-1（IT セキュリティマネジメントのガイドライン−
第１部：IT セキュリティの概念及びモデル）原案
1-2 TR X 0036-2（第２部：IT セキュリティのマネジメント及び計画）原案
1-3 TR X 0036-3（第３部：IT セキュリティマネジメントのための手法）原案
1-4 TR X 0036-4（第４部：セーフガードの選択）原案
i
附属資料２
暗号関係
2-1 暗号概要
2-2 ISO/IEC SC27 提出済暗号一覧
2-3 国際標準活動への貢献（27N2723）
2-4 国際標準活動への貢献（27N2765）
附属資料 3 要約 JIS 原案
3-1 JIS X 5058-3（セキュリティ技術−かぎ管理−
第３部：非対称暗号技術を用いるかぎ確立機構）原案
3-2 JIS X 5061-1（セキュリティ技術−添付型デジタル署名−
第１部：総論）原案
3-3 JIS X 5061-2（セキュリティ技術−添付型デジタル署名−
第２部：識別情報に基づく機構）原案
3-4 JIS X 5061-3（セキュリティ技術−添付型デジタル署名−
第３部：証明書に基づく機構）原案
ii
1.はじめに
産業界および公的機関において情報技術の導入が本格化するのに従って、その安全性を確保
することの重要性が広く認識されるようになってきた。情報システムの安全性に関わる機能の
中でも、悪意の攻撃や大規模災害等の脅威に対する防備機能を中心とする情報セキュリティ機
能は特に重要でありかつ緊急性を増している。中央省庁の電子政府化構想を始め、地方自治体
において行政事務の電子化を進めるに際しても、そのセキュリティ保護が全体の成否を決定す
るものであることはいうまでもない。
情報システムのセキュリティを実現する技術には、暗号、認証、アクセス制御等、多様なも
のがあり、これらの技術を実装した種々の製品が開発されている。情報システムを導入する利
用者は、これらの製品の中からニーズに合致するものを選ぶ必要がある。しかし、そのニーズ
に応じて個別の製品を開発することは非効率的であり、また複数システムの相互運用の必要性
もあることから、基本機能の標準化を進めることによって製品のコスト削減と相互運用性の拡
大を図る必要がある。
情報システムのセキュリティに関する基本機能の国際標準化は、ISO/IEC JTC1/SC27 (Security
Techniques) と そ の 配 下 の WG1 (Requirements, security services and guidelines), WG2 (Security
techniques and mechanisms), WG3 (Security evaluation criteria)の三つの作業部会を中心として進め
られており、日本もこれに対して積極的な貢献をしている。この調査研究委員会は、SC27の作
成する国際規格を基盤として国内のニーズに対応するJIS作成について検討を行うことを主な
ねらいとし、平成11年度から活動を行なっている。平成11年度は、情報システムの調達におい
て適用すべきセキュリティ評価基準の国際規格 ISO/IEC 15408を翻訳しJIS原案として完成す
るなどの成果を得た。
平成 12 年度は、この調査研究委員会の下に WG1(概ね SC27/WG1 に対応)、WG2（暗号アル
ゴリズムを担当）、WG3(概ね SC27/WG3 に対応、ただし、本年度は休会)、WG4(暗号アルゴリ
ズムを除き、概ね SC27/WG2 に対応)の四つの WG を設置し、前年度に引き続いて活動を行な
った。この結果、IT セキュリティマネジメントのガイドライン（GMITS; ISO/IEC TR 13335）
の翻訳 JIS(TR)原案を作成したほか、かぎ管理‐第 3 部‐非対称暗号を用いるかぎ確立機構
(ISO/IEC 11770-3)等の要約 JIS 原案を作成した。また、SC27 における暗号アルゴリズム国際標
準化活動の開始に対応して、国内からの提案をとりまとめるため、電子政府利用のための暗号
技術評価プロジェクト（CRYPTREC）と連携して対策を検討した結果、国内提案の暗号アルゴ
リズムを基に JIS(TR)を作成することが適切であると判断しその原案作成を進めた。
1
2. 調査研究体制
2.1 委員会構成とテーマ
セキュリティ技術標準化調
総括（活動基本方針、JIS 原案審
査研究委員会
議
と承認、動向調査）
WG1：セキュリティマネジメント・
・ISO/IEC TR13335-1∼
4
運用等
の翻訳 JISTR 化
・ISO/IEC 17799 の JIS
WG2：標準暗号選定
・SC27/WG2 国内委員
会へ提出する標準暗号
選定の検討
WG3：セキュリティ評価基準（休会）
・セキュリティ評価基準
関連規格の JIS 原案作成
WG4：セキュリティ標準 JIS 原案作
・WG1,WG2,WG3 担当
成
範囲以外のセキュリティ
JIS 原案作成（要約）
2
2.2 委員会開催
親委員会
開催日
場所
実施内容
第１回
５月３１日 虎屋ビル第１会議室
活動計画
第２回
９月１４日 虎屋ビル３０１会議室
WG 活動報告、標準化動向
第３回
１１月３０日 虎屋ビル３０２会議室
第４回
２月２７日 虎屋ビル３０１会議室
TR 原案審議、報告書方針検討
TR 原案審議、報告書検討
WG1
開催日
場所
実施内容
第１回
７月 ６日 虎屋ビル第２会議室
活動方針
第２回
９月１４日 ｴｲﾄﾜﾝﾋﾞﾙ５０３会議室
TR13335 の用語，訳語検討
第３回
９月２５日 星陵会館会議室Ｂ
TR13335 の翻訳検討
第４回
１０月３１日 虎屋ビル３０３会議室
17799 状況報告，TR13335 翻訳
検討
第５回
１月３１日 虎屋ビル３０１会議室
情報部会懸案事項検討（Part１
∼３），Part４スケジュール
WG2
開催日
第１回
場所
実施内容
９月１３日 虎屋ビル３０２会議室
活動計画
第２回
１１月
２日
ｴｲﾄﾜﾝﾋﾞﾙ５０３会議室
暗号登録制度見直し検討
第３回
１２月１９日
虎屋ビル３０１会議室
暗号比較検討
第４回
２月１６日
機械振興会館 B3-9 会議室
暗号選定方法検討
第５回
３月
虎屋ビル３０１会議室
暗号選定方法検討
５日
3
WG4
開催日
第１回
場所
４月２５日
実施内容
日 本 規 格 協 会 第 ４応接 ISO/IEC11770JIS 原案最終確認
室
第２回
６月
７日
虎屋ビル第１会議室
ISO/IEC14888part1∼３用語検討
第３回
７月
４日
虎屋ビル第３会議室
ISO/IEC14888part1∼３用語検討
第４回
９月
７日
虎屋ビル３０１会議室
ISO/IEC14888part1∼３用語検討
第５回
１０月
５日
虎屋ビル３０２会議室
ISO/IEC14888part1∼３用語検討
第６回
１１月１４日
星陵会館会議室Ａ
ISO/IEC14888part1∼３用語検討
第７回
１２月１５日
桔梗ビル４０１会議室
ISO/IEC14888part1 ∼ ３ SCOPE
検討
第８回
１月３０日
虎屋ビル３０２会議室
用語委員会コメント検討
第９回
３月
桔梗ビル４０１会議室
ISO/IEC14888part1∼３解説検討
６日
4
2.3 委員会名簿
情報システムのセキュリティ技術の標準化調査研究委員会 名簿
氏名
所属
（委員長） 苗村 憲司 慶應義塾大学環境情報学部
（幹事）
中尾 康二 株式会社ＫＤＤ研究所
（幹事）
竜田 敏男 日本アイ・ビー・エム株式会社
（幹事）
櫻井 幸一 九州大学大学院システム情報科学研究科
（委員）
岩下 直行 日本銀行金融研究所
植村 泰佳 電子商取引安全技術研究組合
奥田 和男 社団法人日本情報システムユーザー協会
小倉 久宜 財団法人金融情報システムセンター
才所 敏明 株式会社東芝
紫合
菅
治
知之
日本電気株式会社
電子商取引推進協議会
宝木 和夫 株式会社日立製作所
竹田 栄作 三菱電機株式会社
田渕 治樹 富士通株式会社
徳永 英二 TOK
西川
満
情報処理振興事業協会
前川
徹
早稲田大学国際情報通信研究センター
森田
光
日本電信電話株式会社
吉田健一郎 財団法人日本品質保証機構
（ＯＢＳ） 東井 芳隆 経済産業省商務情報政策局情報セキュリティ政策室
八田
勲
経済産業省産業技術環境局標準課
（事務局） 山中 正幸 財団法人日本規格協会
情報システムのセキュリティ技術の標準化調査研究委員会 WG1
（主査）
名簿
中尾 康二 株式会社ＫＤＤ研究所
（副主査） 大越 丈弘 三菱電機株式会社
（委員）
榎木 千昭 情報システムコントロール協会
橘和 尚道 日本システム監査人協会
工藤 正康 日本アイ・ビー・エム株式会社
栗田 博司 情報処理振興事業協会
小林 秀樹 社団法人情報サービス産業協会
杉浦
昌
日本電気株式会社
関本
貢
財団法人日本情報処理開発協会
前川
徹
早稲田大学国際情報通信研究センター
5
山田 朝彦 株式会社東芝
山本
明
沖電気工業株式会社
吉田健一郎 財団法人日本品質保証機構
渡辺 展文 財団法人金融情報システムセンター
（OBS）
石井 伸治 経済産業省商務情報政策局情報セキュリティ政策室
平野 芳行 経済産業省産業技術環境局標準課
（事務局） 山中 正幸 財団法人日本規格協会
情報システムのセキュリティ技術の標準化調査研究委員会 WG2
（主査）
（委員）
名簿
櫻井 幸一 九州大学大学院システム情報科学研究科
岩下 直行 日本銀行金融研究所
大熊 建司
株式会社東芝
大森 基司 松下電器産業株式会社
高橋 昌
株式会社日立製作所
竹谷 清康 情報処理振興事業協会
竜田 敏男 日本アイ・ビー・エム株式会社
田中 俊昭
株式会社ＫＤＤ研究所
近澤
三菱電機株式会社
武
角尾 幸保 日本電気株式会社
鳥居 直哉 株式会社富士通研究所
中川
聰
沖電気工業株式会社
藤岡
淳
日本電信電話株式会社
宮地 充子 北陸先端科学技術大学院大学
（OBS）
山本 文土 経済産業省商務情報政策局情報セキュリティ政策室
平野 芳行 経済産業省産業技術環境局標準課
（事務局） 山中 正幸 財団法人日本規格協会
情報システムのセキュリティ技術の標準化調査研究委員会 WG4
（主査）
竜田 敏男 日本アイ・ビー・エム株式会社
（委員）
小林 邦生 日本電信電話株式会社
近澤
武
三菱電機株式会社
古川
潤
日本電気株式会社
宮崎 真悟 株式会社東芝
平野 芳行 経済産業省産業技術環境局標準課
（事務局） 山中 正幸 財団法人日本規格協会
6
名簿
3. WG 1 活動報告
3.1 目的
ＷＧ１は主にＳＣ２７/WG1（Requirements ,Security service and guidelines）で審議される国際
標準のうち、今年度はセキュリティマネジメントに関わるガイドラインの JIS 化を中心に活動
する。
3.2 担当分野の標準化動向
ISO/SC27/WG１では、セキュリティに関わる要求条件、TTP などのセキュリティサービス、
IDS やセキュリティマネジメントに関わるガイドラインの策定を主目的としている。現在、主
に以下の作業を中心に活動している。
（１） セキュリティマネジメント
TR13335（GMITS）が ISO／TR として、IS17799（情報セキュリティマネジメントのため
の実践規範）が国際標準（IS）として、それぞれ ISO における正式文書として登録されること
になる。このため、同様なセキュリティマネジメントに関わる内容が２つのカテゴリの文書と
して ISO で認められたこととなる。
TR13335（GMITS）に関しては、現在、第 1 部、および第 2 部の改版作業を進めており、
第 5 部（最終部）については、TR としてのドラフトが完成し（DTR）、投票中である。2001
年 4 月の SC27/WG1 オスロ会合における投票結果によって、正式な TR 化が決定する予定であ
る。
IS17799 については、2000 年 10 月の SC27 東京会合において、可決の投票結果が公表され、
提出されたコメントを反映し、IS 化を早急に実現させた。その間、カナダ、ドイツがその結果
を不服とし、ISO の調整機関である TMB に該規格の IS 化保留を促す嘆願書を提出した。しか
し、嘆願書について審議、挙手投票はしたものの、IS 化保留という強制行動は発動されず、現
状に至っている。
（２）TTP サービス
信頼される第 3 者機関によるサービス（TTP サービス）については、認証サービス、内容証
明サービス、タイムスタンプサービスなどいろいろなサービスが規定されており、それぞれの
サービス仕様、およびその利用におけるガイドラインについて最終投票で承認され，正式発行
待ちの状況である。具体的には、以下の２つの規格が完成した。
・TR15416：Guidelines on the use and management of TTP services
・IS15945：Specification of TTP services to support the application of digital signatures
上記の TR については、ITU-T SG7 とのリエゾンを強化していくことで合意されている。
（３）IDS フレームワーク
１）侵入検知システムフレームワーク
7
本フレームワークは、侵入検知システム（IDS）に関わる技術情報を集約しているもので
あり、標準資料（TR）として DTR のドラフト（PDTR）が完成した段階である。内容的
には、技術レベルは浅く、IDS の枠組みを広く概説している。
２）IDS に関わる新規課題の提案
新たな課題として、「IDS の実施、操作、管理のためのガイドライン」が WG1 の中で提
案され、投票を実施する予定となっている。本ガイドラインは、IDS を新たに導入しよう
としている技術者へのガイドライン（参考書）を与えることを目的としており、上記フレ
ームワークは IDS の概説、本ガイドラインは IDS 運用者への参考書といった位置付けであ
る。
3.3 今年度の活動
（１）ISO/IEC TR 13335 の JIS 化作業
本年度は、7 月から ISO/IEC TR 13335 ：IT セキュリティマネジメントのガイドライン
（GMITS）の JIS 化作業に注力した。TR13335 は５つのサブパートに分かれており、その中
で
第 1 部：IT セキュリティの概念及びモデル（TR X 0036-1：2001）
第 2 部：IT セキュリティのマネジメント及び計画（TR X 0036-2：2001）
第 3 部：IT セキュリティマネジメントのための手法（TR X 0036-3：2001）
の JIS 化を 12 月の段階で終了した。
なお、第 4 部：セーフガードの選択（TR X 0036-4：2001）については、現在、最終編集中で
あり、3 月の情報部会にて審議後、JIS 化の手続きを実施する予定である。
また、第 5 部：ネットワークセキュリティのマネジメントガイダンス（TR X 0036-5：予定）
は、現在 DTR（Draft
Technical
Report）として最終投票中であり、2001 年 4 月開催予定
の SC27 会合にて TR として固まった段階で着手することとしたい。
3.4 今後の予定
（１）IS 17799：情報セキュリティマネジメントのための実践規範の JIS 化
現在、2000 年 10 月 SC27 会合にて IS 化された IS 17799 の JIS 化作業を開始した段階で
ある。本標準は、完全翻訳 JIS 化を行う予定であり、2001 年 9 月をターゲットとして作業を進
めている。
（２）TR 13335 第 5 部：ネットワークセキュリティのマネジメントガイダンスの JIS 化（TR X
0036-5）
上述したように、2001 年の 4 月に第 5 部が TR 化された場合、TR X 0036-5 の JIS 化を実施
する予定である。スケジュールとしては、上記 IS 17799 の作業を優先させ、その完了後に着手
することになる。
8
4. WG2 活動報告
4.1 目的
ＷＧ２は主にＳＣ２７/WG2 で審議される国際標準のうち暗号アルゴリズムに関係する標準
類−NP18033（暗号アルゴリズム）及び ISO/IEC9979（暗号アルゴリズムの登録方法）−につ
いて活動する。
その活動とは次の２つである
・日本から暗号アルゴリズムを標準として国際提案すること及びその提案のために選定の評
価方法・基準を検討する事
・暗号アルゴリズムのＪＩＳ化の検討及び動向調査
4.2 担当分野の標準化動向
インターネット社会でのセキュリティ確保の基盤技術としての要求を受け、ISO/IEC JTC1
SC27 では現在 暗号アルゴリズムの標準化作業(NP18033)を審議している。現在の国際動向につ
いて記すと、2000 年秋に、NIST(米国)は，DES の後継として Rijndael を次世代暗号規格（AES）
に決定した。DES の非公開な標準化とは違い、AES では、全世界から公募形式をとり、安全性
や性能を公の場で審議した。さらに AES はロイヤリティー・フリーで利用可能であることを事
前に宣言している。また、昨年よりヨーロッパでは Nessie、日本では CRYPTREC といった暗
号アルゴリズム評価プロジェクトが開始された。AES では、米国国家標準 DES の後継としての
評価・選定を行なったが、Nessie や CRYPTREC ではアルゴリズムの評価が中心で、暗号アル
ゴリズムの国際規格をふまえ、強度性能評価が公的な機関で行われている。
最近日本から、国産の暗号アルゴリズム（特にブロック暗号）が多数発表されている。特に
１２８ビットブロック暗号は、ＡＥＳの刺激を受けて、ここ 1 年で新規発表があいついだ。こ
れらの中から、２つの評価プロジェクトに多く提案されている。
4.3 今年度の活動
本 WG2 では、日本暗号のＳＣ２７国際提案へ向けた評価・選定をはじめ、JISTR 化、登録制
など暗号アルゴリズムの規格化に関する諸問題を検討した。
昨年より SC27/WG2 で暗号アルゴリズム規格（18033）では、公開鍵暗号、ブロック暗号、ス
トリーム暗号の規格化が始まった。特にブロック暗号は複数の国内提案があり、国内での（事
前）選定が必要となった。本 WG2 発足の趣旨の一つは、これらの国内提案暗号の選定である。
選定のために必要な技術的評価は、本ＷＧ２単独では難しいため、以下の暗号技術評価委員会
（注１）の評価結果を参考することとし、９月からＷＧでの審議を開始した。
注１：経済産業省は、平成１２年度より、電子政府利用のための暗号技術評価プロジェク
ト
（CRYPTREC）
（事務局 IPA）
を開始した。
ISO 提案候補の暗号に関して、この CRYPTREC
へ積極的に投稿したものから選定を行うことにした。CRYPTREC の最終評価結果は、
9
2001 年 4 月に発表の予定である。
これまでに日本から ISO へ提案した暗号は 2000 年 9 月時点で共通かぎで Mars、MISTY、
CIPHERUNICORN-A、CAMELLIA、HIEROCRYPT-L1、-3、MULTI-S01、公開かぎで EPOC、
PSEC、HIME（-1、-2）の 11 種類である。H12 年 12 月に本 WG2 では、独自に提案者による討
論会も行った。ここでは、AES や他社提案方式と自社提案方式との比較を中心に日本提案の国
際レベルでの性能を議論し、国内での選定の検討を行った。この作業は現在も継続中である。
一方、新規に始まった国際標準化（18033）が長期にわたることが予想されるため、日本電子
政府用暗号技術評価プロジェクト CRYPTREC における結果を、電子政府用として利用できる
ように、国内独自の暗号アルゴリズムに関するリストの標準情報（TR）作成が検討された。こ
の目的は、電子政府用暗号技術評価プロジェクト CRYPTREC の成果を反映させた規格を作り、
従来の登録制(ISO 9979)暗号との識別をはかるためである。
また、従来の暗号アルゴリズム登録制(ISO 9979、JISX5060)も審議した。現在、国内では十
分な安全性評価がなされないまま暗号アルゴリズム登録が行われているため、このＩＳＯ登録
を実質以上に宣伝に利用するなどの問題点があることが指摘された。これも今後の課題の一つ
である。
今年度本 WG2 の活動を通じ、国内独自の暗号アルゴリズム標準情報（TR）作成という具体
的対応策が浮かんできたことは、本ＷＧ２今年度の最大の成果と考える。
ISO の暗号アルゴリズム標準(18033)は今後の SC27／WG2 国際会議、4 月のオスロ会議、そ
の次 10 月のソウル会議の審議を待たないとどのような形になるか不確定である。今後の国際標
準化の動向をふまえ、国内での暗号標準化を進め、18033 の標準作成へ対応していく予定であ
る。
また、登録制(JISX5060)の見直しを検討したが、国際での審議も必要であり、18033 のＩＳ化
に影響するため、現時点では、（すくなくとも国際レベルでは）従来の制度を維持する方向で
ある。
これまでの国際への貢献については次項にまとめた。
4.4 WG2 の国際標準活動への貢献
１９９９年１０月
ＳＣ２７コロンビア会議で暗号アルゴリズムの新規提案、
２０００年３月
新規提案の承認（３月締め切りで新暗号アルゴリズムの募集があった。）、日本から８件の
アルゴリズムを候補として提出（標準化ジャーナル５月号掲載）
２０００年４月
ＳＣ２７／ＷＧ２ロンドン会議
暗号アルゴリズムの提案（ＮＰ１８０３３）は審議の結果、以下の４つのパートに分けるこ
とを決定。
第１部：総論
10
第２部：非対称暗号
第３部：ブロック暗号
第４部：ストリーム暗号 エディタは櫻井（日本）に決定
２０００年９月
暗号アルゴリズムの寄書募集
日本は１１件のアルゴリズムの候補を提出。これらのアルゴリズムの概要を附属資料２-1
に掲載。
２０００年１０月
米国 ＡＥＳ ５つの最終候補から Rijndael を採用。
また、欧州
ＮＥＳＳＩＥプロジェクト本格活動開始 ２００２年 最終決定の見込み
２０００年１０月
ＳＣ２７東京会議提出したアルゴリズムについて各パートごとに議論し、２００１年２月末
までにドラフトを提出ことになった。ストリーム暗号については追加募集。各国から提案さ
れた暗号の一覧を別添資料 2-2 に示す。ブロック暗号の案にはデファクトであるトリプルＤ
ＥＳ及びＲｉｊｎｄｅａｌが入ることが有力となった。
２００１年３月
第１部のＷＤ２７Ｎ２７２３（附属資料 2-3）第２部のエディタ寄書 ２７Ｎ２７６５（附
属資料 2-4）が公開され、本ＷＧ２から提出した日本の暗号の一つが入った案が提示された。
第３部のドラフトは未公開。第４部のドラフトには日本のストリーム暗号が入る予定である。
これらのドラフトを元に４月のオスロ会議で審議される。
4.5 今後の予定
次年度は、ISO 提案暗号の国内評価・選定のＳＣ２７への提言とともに、電子政府用暗号技
術評価プロジェクト CRYPTREC の 2000 年度評価結果を反映させた暗号アルゴリズムのリスト
の標準情報（TR）原案作成が主な活動となる予定である。
特に暗号アルゴリズムのリストの標準情報（ TR）作成は国際的にも重要な課題であると考え
る。
ISO 15408 においても、暗号は各国の政策の違い等の理由で、規定されていない。しかし、こ
れは暗号（アルゴリズム）評価基準が不要というわけでなく、この部分は、各国独自に制定、
運営という意味を含んでいることに注意がいる。むしろ、これまでには暗号は各国の政策の違
い等の理由で国際レベルでの評価基準をあいまいにしてきた感がある。
AES, NESSIE, CRYPTREC などの評価プロジェクトが ISO 標準化と密接に関係してくること
を考えると、今後、暗号評価国際規準のようなものが登場してくる可能性もある。従来のＩＳ
Ｏガイドライン規格と違い、暗号アルゴリズムの設計に優れた技術をもつ日本が、先行して、
国内規準を国際の場にもっていく、ということも今ならば十分可能ではないかと考え、次年度
本ＷＧ２の中で、国内での検討を進める予定である。
11
5. WG4 活動報告
5.1 目的
JIS/WG4 は SC27/WG2 で制定される ISO/IEC JTC1 標準のうち、
暗号の標準化
（NP 18033）
及び暗号の登録制度（ISO/IEC 9979）を除く標準類の JIS 化を担当している。JIS/WG4 の担
当範囲と思われる ISO/IEC JTC1 標準（案）の JTC1 での標準化状況及び JIS/WG4 での JIS
標準化の状況・予定を以下に示す。
5.2 今年度の活動
WG4 は 2000 年度に、ISO/IEC 11770-3：1999 を JIS X 5058-3：2000 かぎ管理‐第 3 部
‐非対称暗号を用いるかぎ確立機構として平成 12 年 10 月に発行した。その後、ISO/IEC
14888-1：1999 （訂正版）、ISO/IEC 14888-2：1999 及び ISO/IEC 14888-3：1999（訂正版）
をそれぞれ JIS X 5061-1 添付型ディジタル署名‐第 1 部‐総論、JIS X 5061-2 添付型ディジ
タル署名‐第 2 部‐識別情報に基づく機構、及び JIS X 5061-3 添付型ディジタル署名‐第 3
部‐証明書に基づく機構として 2000 年度に作業を完了する予定であったが、原規格が難解で
あるため翻訳と解釈に手間取り、2001 年度にずれ込んでいる。
5.3 今後の予定
来年度は、（1）ISO/IEC 9798-1~5（エンティティ認証‐第 1∼5 部‐第 2 版）、（2）ISO/IEC
10118-1∼3（ハッシュ関数‐第 1∼2 部‐第 2 版と第 3 部‐追加第 1 版）、及び（3）ISO/IEC
9797-1∼2（メッセージ認証符号‐第 1∼2 部‐第 2 版）の優先順位で JIS 化していく予定であ
る。
5.4 WG4 が担当する標準化案件
01) 64 ビット暗号の利用モード（8372）
l
第1版
- ISO 8372:1987――→ JIS X 5052:199?
02) ｎビット暗号の利用モード（10116）
l
第1版
- ISO/IEC 10116：1996―→ JIS X 5053：1996
l
第2版
- WD 10116
03) エンティティ認証 （9798）
l
第1版
12
- ISO/IEC 9798-1：1991 一般モデル ―→ JIS X 5056-1：1996
- ISO/IEC 9798-2：1994 対称暗号 ―→ JIS X 5056-2：1996
- ISO/IEC 9798-3：1993 公開かぎ暗号 ―→ JIS X 5056-3：1996
- ISO/IEC 9798-4：1995 暗号検査関数 ―→ JIS X 5056-4：1996
l
第2版
- ISO/IEC 9798-1：1997 総論
JIS X 5056-1 [2001 年度優先順位１]
―→
- ISO/IEC 9798-2：1999 対称暗号
JIS X 5056-2 [2001 年度優先順位１]
―→
- ISO/IEC 9798-3：1998 非対称暗号
―→
JIS X 5056-3 [2001 年度優先順位１]
- ISO/IEC 9798-4：1999 暗号検査関数
―→
JIS X 5056-4 [2001 年度優先順位１]
- ISO/IEC 9798-5：1999 ゼロ知識技術
―→
JIS X 5056-5 [2001 年度優先順位１]
04) メッセージ認証符号（9797）
l
第 2 版： 暗号検査関数を用いるデータ完全性
- ISO/IEC 9797：1994
l
―→
JIS X 5055：1996
第 3 版： メッセージ認証符号 MAC
- ISO/IEC 9797-1：1999 ブロック暗号 ―→ JIS X 5055-1 [2001 年度優先順位３]
- FDIS 9797-2 ハッシュ関数 ―→
JIS X 5055-2 [2001 年度優先順位３]
06) 否認防止（13888）
l
第1版
- ISO/IEC 13888-1：1997 総論
JIS X 5059-1：1999
―→
- ISO/IEC 13888-2：1998 対称暗号
- ISO/IEC 13888-3：1997 非対称暗号
―→
―→
JIS X 5059-2：1999
JIS X 5059-3：1999
07) メッセージ復元型ディジタル署名（9796）
l
第1版
- ISO/IEC 9796：1991 メッセージ復元型 ―→ JIS X 5054：1996
l
第2版
- Part-1 冗長性利用 廃止 ―→ JIS X 5054：1996 ＜廃止＞
- ISO/IEC 9796-2：1997 ハッシュ関数 ―→
- ISO/IEC 9796-3：2000 離散対数
―→
未定
未定
08) 添付型ディジタル署名 (14888)
l
第1版
- I S O / I E C 1 4 8 8 8 - 1 ：1 9 9 9 総論 （訂正版） ―→ J I S X 5 0 6 1 - 1
[
2 0 0 0 年度完了予
定]
- I S O / I E C 1 4 8 8 8 - 2 ：1 9 9 9 識別情報
―→ J I S X 5 0 6 1 - 2
[
2 0 0 0 年度完了予定 ]
- I S O / I E C 1 4 8 8 8 - 3 ：1 9 9 9 証明書（訂正版）―→ J I S X 5 0 6 1 - 3
13
[
2 0 0 0 年度完了予
定]
- DCOR 14888-3 証明書型 （再訂正版） ―→
未定
09) ハッシュ関数（10118）
l
第1版
- ISO/IEC 10118-1：1994 総論
JIS X 5057-1：1996
―→
- ISO/IEC 10118-2：1994 ｎビットブロック暗号 ―→
JIS X 5057-2：1996
- ISO/IEC 10118-3：1998 専用ハッシュ関数 ―→ JIS X 5057-3 [2001 年度優先順位２]
- ISO/IEC 10118-4：1998 モジュラー演算 ―→ JIS 化不要（SC27 委員会の意見）
l
第2版
- ISO/IEC 10118-1：2000 総論 ―→
JIS X 5057-1 [2001 年度優先順位２]
- FDIS 10118-2 n ビットブロック暗号 ―→
JIS X 5057-2 [2001 年度優先順位２]
18) 鍵管理(11770)
l
第1版
- ISO/IEC 11770-1：1996 枠組み
- ISO/IEC 11770-2：1996 対称暗号
- I S O / I E C 1 1 7 7 0 - 3 ：1 9 9 9
JIS X 5058-1：1998
―→
―→
JIS X 5058-2：1998
非対称暗号 ―→ J I S X 5 0 5 8 - 3 ：2 0 0 0
行済 ]
23) チェック文字方式（7064）
l
第2版
- FCD 7064
26) 楕円曲線に基づく暗号技術（15946）
l
第1版
- FDIS 15946-1 総論
- FDIS 15946-2 ディジタル署名
- FDIS 15946-3 鍵設定
- CD
15946-4 メッセージ復元型ディジタル署名
27) タイムスタンプ（18014）
l
第1版
- CD 18014-1 枠組み
- WD 18014-2 独立トークン生成機構
- WD 18014-3 リンクされたトークン生成機構
31) 乱数生成（18031）
14
[2 0 0 0
年度に発
l
第1版
- WD 18031
32) 素数生成（18032）
l
第1版
- WD 18032
33) 暗号アルゴリズム（18033） これは WG4 の担当ではなく、WG2 の担当。
l
第1版
- WD 18033-1 一般
- WD 18033-2 非対称暗号
- WD 18033-3 ブロック暗号
- WD 18033-4 ストリーム暗号
15
5. 今後の課題
情報システムのセキュリティ技術に関する標準化活動に対して、内外の注目が増しているこ
とに対応して、本調査研究委員会としてもこれまで以上に効果的な活動を進める必要がある。
本年度に JIS(TR)原案作成を行なった IT システムマネジメントガイドラインは、情報システ
ムの導入を行なう公的機関および企業等において指針として広く役立つものと考えられるので、
その普及を図る必要がある。本調査研究委員会としては、これに関連の深い国際規格 ISO/IEC
17799 が 2000 年 12 月に発行されたので、その JIS 原案を急ぐことが期待されている。また、
SC27/WG1 が作成しているその他の国際規格等をどのように JIS 化すべきかについても検討を
行なうべき時期を迎えている。
SC27/WG3 関連では、セキュリティ評価基準の利用状況に注目するとともに、システムの用
途や環境に応じて適切なセキュリティ要件を選択するための protection profile の開発と登録に
関する JIS 原案の作成が必要となろう。
SC27/WG2 関連では、
暗号アルゴリズムに関する SC27 の標準化が本格化するのに対応して、
その評価方法と JIS のあり方を検討することが重要な課題となる。また、その他の多数の国際
規格を組織的に要約 JIS 化するための効率的な方法を検討することが必要と考えられる。
16
附属資料 1
1 -1
標準情報（ T R ）原案
T R X 0 0 3 6 - 1 （ＩＴセキュリティマネジメントのガイドライン−
第１部：ＩＴセキュリティの概念及びモデル）原案
1 -2
T R X 0 0 3 6 - 2 （ＩＴセキュリティマネジメントのガイドライン−
第２部：ＩＴセキュリティのマネジメント及び計画）原案
1 -3
T R X 0 0 3 6 - 3 （ＩＴセキュリティマネジメントのガイドライン−
第３部：ＩＴセキュリティマネジメントのための手法）原案
1 -4
T R X 0 0 3 6 - 4 （ＩＴセキュリティマネジメントのガイドライン−
第４部：セーフガードの選択）原案
17
ＴＲ
I T セキュリティマネジメントのガイドライン−
第 1 部：IT セキュリティの概念及びモデル
TR X 0036-1
(ISO/IEC TR 13335-1)
i
まえがき
この標準情報（TR）は，工業標準化法に基づいて，日本工業標準調査会の審議を経て，経済産業大
臣が公表した標準情報（TR）タイプⅢである。公表に当たっては，1996 年に発行された ISO/IEC TR
13335-1:1996[Information technology―Guidelines for the management of IT Security―Part
1:Concepts and models for IT Security]を基に作成した。
TR X 0036 の標準情報群は，次に示す 5 部で構成される。
TR X 0036-1 第 1 部 IT セキュリティの概念及びモデル
TR X 0036-2 第 2 部 IT セキュリティのマネジメント及び計画
TR X 0036-3 第 3 部 IT セキュリティマネジメントのための手法
TR X 0036-4 第 4 部 セーフガードの選択（制定予定）
TR X 0036-5 第 5 部 ネットワークセキュリティのマネジメントガイダンス（制定予定）
ii
目次
まえがき
序文 iv
1. 適用範囲 1
2. 参考資料 1
3. 定義 1
4. 構造 2
5. 目的 2
6. 背景 3
7. IT セキュリティマネジメントの概念 3
7.1 アプローチ 3
7.2 目的，戦略，及びポリシー 4
8. セキュリティ要素 5
8.1 資産 6
8.2 脅威 6
8.3 ぜい（脆）弱性 8
8.4 影響 8
8.5 リスク 8
8.6 セーフガード 9
8.7 残存リスク 9
8.8 制約事項 10
9. IT セキュリティマネジメントのプロセス 10
9.1 構成マネジメント 10
9.2 変更管理 11
9.3 リスクマネジメント 12
9.4 リスク分析 12
9.5 責任追跡性 12
9.6 セキュリティ意識向上 13
9.7 モニタリング 13
9.8 障害対策計画及び災害復旧計画 14
10. モデル 14
11. まとめ 18
解説
iii
序文
この標準情報（ＴＲ）群の目的は，IT セキュリティをマネジメントの観点から捉えてガイダンスすることであり，
解決策を提供することではない。組織のなかで IT セキュリティに対する責任がある人々は，この標準情報
群が取り上げている内容を，それぞれに固有のニーズにあわせて応用できる能力があることが望ましい。
この標準情報群が主な目標にしていることは，次のとおりである：
・ITセキュリティマネジメントに関連した概念を定義して説明すること，
・ITセキュリティマネジメントと，ITマネジメント全般との関係を明らかにすること，
・IT セキュリティについて説明するときに利用できる，いくつかのモデルを提示すること，及び
・IT セキュリティマネジメントに関して，一般的なガイダンスを行うこと。
この標準情報群は，複数の部によって構成されている。第１部では，IT セキュリティマネジメントの説明に
あたって用いる，基本概念及びモデルについて概説する。この内容は，IT セキュリティに対して責任があ
る経営管理者，及び組織のセキュリティプログラム全般に対して責任がある人々のために役に立つもので
ある。
第２部は，マネジメント及び計画の側面を取り上げている。この内容は，次のような，組織の IT システムと
関連する責任を負っている運営管理者に関係するものである：
・IT システムの設計・導入・試験・調達・運用に関して監督責任を負う IT 運営管理者，又は
・IT システムの利用を意味あるものとする諸活動について責任を負う管理者。
第３部では，プロジェクトの計画・設計・導入・試験・取得・運用といったライフサイクルの過程で，管理的な
業務に携わる人々に役立つセキュリティへの対処方法を説明する。
なお，この標準情報（TR）で点線の下線を施してある部分は，原標準情報（TR13335-1）にない事項であ
る。
参考
第４部では，セーフガードの選択についてガイダンスを行うが，ベースラインモデルと管理策とを利用する
ことがセーフガード選択にどう役立つかについても述べる。また，これらを利用することが第３部で説明し
たセキュリティへの対処方法をどう補足することなのか，また，セーフガードの選択のために，評価手法を
どう追加して使うかについても説明する。
第５部は，ITシステムを外部ネットワークに接続する組織に対するガイダンスである。このガイダンスでは，
外部との接続及びそれから得られる利便を保護するためのセーフガードの選択及びその使用について，
並びにシステムを外部と接続するときに追加すべきセーフガードについても取り上げている。
第５部の原標準情報（ISO/IEC TR 13335-5 Management guidance on network security）は，現在
審議中である。
iv
標準情報(TR)
IT セ キ ュ リ テ ィ マ ネ ジ メ ン ト の ガ イ ド ラ イ ン −
第 1 部：I T セ キ ュ リ テ ィ の 概 念 及 び モ デ ル
TR
X 0036-1: 2001
(ISO/IEC TR 13335- 1 :1996)
1.
適用範囲
この標準情報群では，IT セキュリティマネジメントに関するガイドラインを説明する。第 1 部
で，IT セキュリティマネジメントを最初に説明する上で欠くことのできない，基本的な管理の概
念及びモデルを説明する。これらの概念とモデルについては，第 2 部以降でより詳しく検討及び
展開し，より詳細なガイダンスを提供する。各部を総合すると，IT セキュリティのすべての側面
の認識と管理に役立てることができる。第 1 部は，この標準情報群の第 2 部以降を完全に理解す
るために必要である。
備考 この標準情報の対応国際標準情報を，次に示す。
なお，対応の程度を表す記号は，ISO/IEC Guide21 に基づき，IDT（一致している），
MOD（修正している）
，NEQ（同等でない）とする。
ISO/IEC TR 13335-1 :1996[Information technology―Guidelines for the
management of IT Security―Part 1:Concepts and models for IT Security]（IDT）
2. 参考資料
JIS X 5004 :1991 開放型システム間相互接続の基本参照モデル−安全保護体系
備考 ISO 7498 -2 : 1989, - Open Systems Interconnection - Basic Reference Model Part 2: Security Architecture が，この規格と一致している。
3.
定義
次の定義は，この標準情報群の３つの部で使用される。
3.1 責任追跡性（accountability）:あるエンティティの動作が，そのエンティティに対して一意
に追跡できることを保証する特性。(JIS X 5004:1991)。
3.2
資産（asset）: 組織に対して価値を持つもの。
3.3 真正性 （authenticity）: 対象またはリソースが要求されているものと同一であることを
主張する特性。真正性は，ユーザ，プロセス，システム，情報などのエンティティに対して適用
する。
3.4 可用性 （availability）: 許可されたエンティティによって要求されたときにアクセスと使
用が可能な特性(JIS X 5004 :1991)。
3.5 ベースラインコントロール（baseline controls）: システムまたは組織のために必要とされる
最低限のセーフガード。
3.6 機密性（confidentiality）: 許可されていない個人，エンティティ，またはプロセスに対して
情報を使用不可または非開示にする特性(JIS X 5004)。
3.7 データ完全性（data integrity）: 許可されていない方法でデータが改ざんまたは破壊されて
いない特性(JIS X 5004 :1991)。
3.8 影響（impact）: 好ましくない偶発事故の結果。
3.9 完全性（integrity）: データ完全性及びシステム完全性を参照。
3.10 IT セキュリティ（IT security）: 機密性，完全性，可用性，責任追跡性，真正性，及び信
頼性の定義，達成，維持に関するすべてのセキュリティ。
1
3.11 IT セキュリティポリシー（IT security policy）: 組織及びその IT システムの範囲内で，重
要情報を含む資産をどのように管理，保護，及び分配するかを統制する規則，指令，及び実践。
3.12 信頼性（reliability）: 矛盾のない計画とおりの動作及び結果を確保する特性
3.13 残存リスク（residual risk）: セーフガードが実施されたあとに残存するリスク。
3.14 リスク（risk）:
ある脅威が，資産または資産グループのぜい（脆）弱性を利用して，資産への損失，または損害
を与える可能性
3.15 リスク分析（risk analysis）: セキュリティリスクの識別，セキュリティリスクの程度の判
定，及びセーフガードが必要な領域の識別を実行するプロセス。
3.16 リスクマネジメント（risk management）: IT システムの資源に影響を及ぼす不確かな事象
を識別，制御，除去，または低減する総合的なプロセス。
3.17 セーフガード（safeguard）: リスクを低減する実践，手順，またはメカニズム。
3.18 システム完全性（system integrity）: システムが，意図的または偶発的な不正の操作から
妨害されることなく，本来果たすべき機能を滞りなく実行する特性。
3.19 脅威（threat）: システムまたは組織に危害を与える，好ましくない偶発事故の潜在的な原
因。
3.20 ぜい（脆）弱性（vulnerability）: 脅威によって影響を受け得る資産または資産グループの
弱さ。
4.
構造
この標準情報群の第 1 部は，次のように構成される。5.ではこの標準情報の目的を概説し，6.
では IT セキュリティマネジメントに対する背景要件を説明する。7.では IT セキュリティの概念
及びモデルの概要を説明し，8.では IT セキュリティの要素を吟味する。9.では IT セキュリティ
の管理に使用されるプロセスを検討し，10.ではこの標準情報に述べられた概念の理解に役立つ，
幾つかのモデルの概要を説明する。最後に，11.で第 1 部を要約する。
5.
目的
この標準情報群では，さまざまな読者を想定している。第 1 部の目的は，IT セキュリティマネ
ジメントに含まれるさまざまな項目を説明することと，IT セキュリティの基本概念及びモデルの
概要を説明することである。この資料は，基本的な管理の概要を説明するために短くまとめられ
ている。第 1 部は，組織においてセキュリティマネジメントに責任を持つ立場の上級管理者に適
しており，この標準情報の残りの部分（第 2 部，第 3 部等）にも興味をもつ人達へ IT セキュリテ
ィを紹介する役目を果たしている。第 2 部と第 3 部では，IT セキュリティの実施と監視の直接の
責任者に適合する，より理解しやすい情報と資料とを提供する。これは，第 1 部に述べられた概
念及びモデルに基づいている。
IT セキュリティに特定のマネジメントアプローチを提案することは，この標準情報群の意図す
るところではない。この標準情報群は有用な概念及びモデルの一般的な説明で始まり，IT セキュ
リティマネジメントに使用できる特定の技法及びツールの説明で終わる。この資料は一般的
（general）であり，さまざまなスタイルの管理及び組織環境に適用できる。この標準情報群は，
2
一つの組織，及びそこでの特定の管理スタイルの要求を満たすために，標準情報群の内容をそれ
に適応できるような構成をとっている。
6.
背景
政府及び商業組織は，事業活動を行う際に情報の使用に大きく依存している。情報及びサービ
スの機密性，完全性，可用性，責任追跡性，真正性，及び信頼性が欠けると，組織に悪影響を及
ぼすことになる。従って，組織内で，情報の保護と IT システムのセキュリティマネジメントが不
可欠である。この情報保護の要件は，今日の環境で特に重要である。なぜなら，IT システムのネ
ットワークによって多くの組織が内部的及び外部的に接続されているからである。
IT セキュリティマネジメントは，適切なレベルの機密性，完全性，可用性，責任追跡性，真正
性，及び信頼性を達成して維持するためのプロセスである。
IT セキュリティマネジメントの機能には，次が含まれる。
- 組織の IT セキュリティの目的，戦略，及び対策の決定
- 組織の IT セキュリティ要件の決定
- 組織内の IT 資産に対する，セキュリティ上の脅威の識別及び分析
- リスクの識別及び分析
- 適切なセーフガードの指定
- 組織内の情報とサービスを費用対効果に優れた方法で保護するため
に必要な，セーフガードの実施及び稼働の監視
- セキュリティ意識向上プログラムの開発及び実装
- 偶発事件の検出及び対応
IT システムに対するこれらの管理責任を果たすために，セキュリティは，組織の全体管理計画
における必須の部分でなければならない。その結果，この標準情報で触れられているセキュリテ
ィ項目のいくつかには，広範な一般的な管理との関連がある。この標準情報ではこのような広範
な管理の問題ではなく，セキュリティに関する話題に注力し，それらのセキュリティ項目が一般
的に管理とどのように関連しているかに焦点を置く。
7.
IT セキュリティマネジメントの概念
次の概念を採用するには，組織が運用されるときの文化及び環境を考慮する必要がある。なぜな
ら，それらは，セキュリティへの総合的なアプローチに重大な影響を及ぼすことがあるからであ
る。また，これらは，組織の特定部門の保護責任者にも影響を及ぼすことがある。場合によって
は，政府の責任と見なされ，法律の制定及び施行によってこの責任が解除される。あるいは，所
有者または管理者が責任を負うと見なされることもある。この問題は，採用されるアプローチに
相当な影響を及ぼすことがある。
7.1
アプローチ
組織内の IT セキュリティに関する要件を識別するには，計画的なアプローチが必要である。これ
はまた，IT セキュリティの実施及び継続的な管理についてもいえることである。このプロセスは
IT セキュリティマネジメントと呼ばれるプロセスであり，次の作業を含む。
・IT セキュリティのポリシーの開発
・組織内の役割及び責任の識別
・リスクマネジメント，次の識別及び評価を含む
−保護される資産
3
−脅威
−ぜい（脆）弱性
−影響
−リスク
−セーフガード
−残存リスク
−制約事項
・構成マネジメント
・変更管理
・障害対策プラン及び災害復旧のプラン
・セーフガードの選択及び実施
・セキュリティの意識向上
・次を含むフォローアップ
−保守
−セキュリティ監査
−モニタリング
−レビュー
−偶発事故の対応
7.2
目的，戦略，及びポリシー
企業におけるセキュリティの目的，戦略，及びポリシー(図 1 を参照)は，組織内の効果的な IT セ
キュリティの基礎として定式化することが必要である。これらによって組織の事業がサポートさ
れ，また，すべてのセーフガードの間での一貫性が保証される。目的によって達成すべき事柄を
識別し，戦略によって目的の達成方法を識別，そしてポリシーによって実行の必要な事柄を識別
する。
目的，戦略，及びポリシーは，組織の団体レベルから活動レベルまで階層的に発展することがで
きる。これらの 3 つの事柄は，
組織の要件を反映して制約事項を考慮したものであるべきである。
また，それぞれのレベル及びレベル全体を通じて矛盾がないことを保証すべきである。セキュリ
ティは，組織内でのあらゆる管理レベルの責任であり，システムのライフサイクルすべてのフェ
ーズで発生する。目的，戦略，及びポリシーは定期的なセキュリティレビュー(例: リスク分析，
セキュリティ監査)の結果に基づいて維持及び更新されるべきであり，ビジネスの目的によって変
化する。
企業セキュリティ ポリシーは，本来，組織全体のセキュリティに関する原則及び指示（directives）
から構成される。このポリシーは，個人の権利，法的な要件，及び標準について述べられたもの
を含む広範な企業ポリシーを反映していなければならない。
全社的な IT セキュリティポリシーは，企業セキュリティ・ポリシーに適用できる本質的なセキュ
リティ原則と指示，及び組織内の IT システムの一般的な利用法とを反映していなければならない。
IT システムセキュリティポリシーは，全社的な IT セキュリティポリシーに含まれるセキュリテ
ィ原則及び指示を反映していなければならない。また，これは特定なセキュリティ要件，実施さ
れるセーフガード，及び十分なセキュリティを確保するために，それらを正しく利用する方法の
詳細な情報が含まれていなければならない。いかなる場合でも，組織のビジネス・ニーズに合っ
たアプローチを取ることが重要である。
4
組織の
目的−戦略―ポリシー
全社的なセキュリティの
目的−戦略−ポリシー
全社的な財政の
目的−戦略−ポリシー
全社的なＩＴセキュリティの
目的−戦略−ポリシー
全社的な要員セキュリティの
目的−戦略−ポリシー
ＩＴシステムセキュリティ（１）
目的−戦略−ポリシー
図1
ＩＴシステムセキュリティ（ｎ）
目的−戦略−ポリシー
目的，戦略，及びポリシーの階層
IT システム・セキュリティの目的，戦略，及びポリシーは，セキュリティに関して IT システム
から何が求められるかを示す。これらは通常，自然言語を使用して表現されるが，数理言語を使
用してより形式的に表現する場合で必要である。これらは，IT セキュリティに関わる次の事柄を
取り扱うものである。
・機密性
・完全性
・可用性
・責任追跡姓
・真正性
・信頼性
目的，戦略，及びポリシーは，組織のためのセキュリティレベル，リスク許容の閾値，及び組織
の障害対策に関する要件を確立する。
8.
セキュリティ要素
この項の次の項では，セキュリティマネジメントのプロセスに含まれる主な要素（資産，脅威…）
を上位（概要）レベルで説明する。要素のそれぞれの概要を説明し，役に立つ主なものが識別で
きる。これらの要素及びその関係についての，より詳細な説明及び検討内容については，この標
準情報の第 2 部以降で説明する。
5
8.1
資産
資産の正しい管理は，組織の成功にとって必須であり，すべての管理レベルにおいて最も重要な
ことである。組織の資産とは，次を含んでいる。
・物理的な資産(例: コンピューター・ハードウェア，通信設備，建物)
・情報/データ(例: 文書，データベース)
・ソフトウェア
・製品の製造またはサービスの提供を行う能力
・人材
・無形資産(例: 営業権，企業イメージ)
これらの資産の大部分または全部は，ある程度の保護を保証するに十分な価値がある。また，容
認されているリスクの評価は，資産が保護されないときに必要である。
セキュリティの観点から見ると，組織の資産が十分に把握できないと，セキュリティプログラム
の実施及び保守を成功裡に実現することができない。多くの場合，資産を識別して価値を割り当
てる処理は上位（概要）レベルで実施でき，この時点では，費用がかかり，詳細でかつ時間のか
かる分析は不要である。この分析の詳細のレベルは，時間及び費用に対する資産価値で測定され
なければならない。どの場合でも，詳細のレベルはセキュリティの目的に基づいて決定すべきで
ある。多くの場合，グループ資産に有用である。
考慮すべき資産の属性には，それらの価値，感度及び固有のセーフガードが含まれる。資産の保
護要件は，特定の脅威が発生したときのぜい（脆）弱性によって影響を受ける。これらの事象が
資産所有者に明白な場合は，この段階で押さえるべきである。組織が運用される環境と文化は，
資産及びその属性に影響を及ぼすことがある。例えば，個人情報の保護を非常に重要と見なす文
化がある一方で，この問題にそれほどの重点を置かない文化もある。これらの環境及び文化の多
様性は，国際的な組織及び国境をまたがる IT システムの使用において重要と言える。
8.2
脅威
資産は，多くの種類の脅威にさらされる。ある脅威には，システムまたは組織及びその資産に危
害を加える好ましくない偶発事故を引き起こす可能性がある。この危害は，IT システムまたはサ
ービスによって処理されている情報への直接的あるいは間接的な攻撃(例: 不正なデータの破壊，
開示，修正，改悪，非可用性，または損失)から発生する。脅威は，資産に既存のぜい（脆）弱性
を悪用して，財産に危害を与える。これらの脅威には，自然に端を発するもの及び人に端を発す
るものとがあり，偶発的なもの及び意図的なものがある。偶発的及び意図的な脅威を理解し，脅
威のレベル及びその振る舞いを評価しなければならない。
6
脅威の例:
意図的
盗聴
情報の改ざん
システム・ハッキング
悪意のコード
盗難
人間
偶発的
誤り及び手落ち
ファイルの削除
不正ルーティング
物理的な事故
環境
地震
落雷
洪水
火災
環境的脅威の多くの場合については，統計データが入手可能である。組織は，脅威を評価するプ
ロセスにおいてこのデータを入手及び使用するべきである。脅威は，組織の特定の部分に影響を
及ぼすことがある。例えば，パーソナルコンピューターへの破壊行為などである。システムまた
は組織が存在する特定の場所によっては，幾つかの脅威がその周囲環境に共通して影響を及ぼす
ことがある。例えば，台風または落雷による建物の損害などがそれに当たる。脅威には，従業員
のサボタージュのように組織の内部から発生する場合と，悪意のハッキングまたは産業スパイな
どのように外部から発生する場合とがある。好ましくない偶発事故によって発生する危害につい
ては，一時的な危害の場合と，資産破壊のように永続的な危害の場合とがある。
脅威によって引き起こされる危害の規模は，事象によって大きく異なることがある。例えば，
・ソフトウェアウイルスは，ウイルスの動作によって危害の程度が異なる。
・ある特定の場所で発生する地震は，状況によって強度が異なる。
このような脅威には，しばしば強度の尺度が存在する。例えば，
・ウイルスは破壊型あるいは非破壊型として記述できる。
・地震の強度は，マグニチュードで記述できる。
幾つかの脅威は，複数の資産に影響を及ぼす。このような場合，どの資産に影響があるかによっ
て異なる波及効果を生む。例えば，単一のパーソナルコンピューター上のソフトウェアウイルス
は，限定的または局所的な影響しか及ぼさない。しかし，ネットワークに接続されるファイルサ
ーバ上に同じソフトウェアウイルスが存在すると，広範な影響を及ぼすことになる。それ以外の
脅威，又は異なる場所に存在する同じ脅威は，発生する危害の規模が一致することがある。脅威
によって発生する危害に一貫性があるときは，一般的なアプローチ（解決手段）をとることがで
きる。しかし，その危害が多様であるときは，脅威の発生ごとに，むしろ特定なアプローチをと
ることが適切である。
脅威には，その脅威自体の有益な情報を提供するといった特徴がある。これらの情報の例は次の
とおりである。
・ソース，すなわち部内者か部外者か
・モチベーション，例えば，財務利益，競争の利点
・発生頻度
・脅威の強度
組織の位置する環境及び文化は，その組織への脅威にどのように対処するかという事に，相当に
大きく関連し，影響を及ぼすことがある。
7
極端な場合，ある文化において脅威が有害とは見なされないこともある。脅威について言及する
場合は，環境及び文化の両方の面を考慮しなければならない。
8.3
ぜい（脆）弱性
資産に関するぜい（脆）弱性には，物理的なレイアウト，組織，手続き，要員，マネジメント，
管理，ハードウェア，ソフトウェア，または情報における弱点が含まれる。これらのぜい（脆）
弱性は，IT システムまたは事業の目的に危害を加える脅威によって増殖されてしまう。ぜい（脆）
弱性自体は害を与えない。ぜい（脆）弱性とは，資産に影響を与える脅威を許容する条件または
条件の集合でしかない。異なる発生源からのぜい（脆）弱性については，考慮が必要である。例
えば，資産に内在するぜい（脆）弱性など。ぜい（脆）弱性は，資産自体が変化してそのぜい（脆）
弱性がその資産には該当しなくならない限り，残存する。
ぜい（脆）弱性には，悪用されて好ましくない結果となってしまうシステム内の弱点が含まれて
いる。これらの弱点とは，危害を与える脅威を許容するものである。例えば，アクセス制御機構
の欠落は，侵入の脅威が発生して資産が失われるぜい（脆）弱性である。特定のシステムまたは
組織においては，脅威の影響を受けないぜい（脆）弱性もある。脅威及び関連するぜい（脆）弱
性は緊急課題と考えられる。ただし，環境は動的に変更できるので，古い脅威または新しい脅威
にさらされるぜい（脆）弱性を識別するためには，すべてのぜい（脆）弱性を監視すべきである。
ぜい（脆）弱性の分析とは，識別された脅威によって悪用される弱点を検査することである。こ
の分析では，そこでの環境及び既存のセーフガードを考慮しなければならない。脅威に対するシ
ステムまたは資産のぜい（脆）弱性とは，システムまたは資産の危害の被りやすさの表現である。
8.4
影響
影響とは，意図的または偶発的に発生した，資産に悪作用を与える好ましくない偶発事故の結果
である。この結果には，資産の破壊，IT システムへの損害，及び機密性，完全性，可用性，責任
追跡性，真正性，または信頼性の損失とがある。また，考えられる間接的な結果（影響）として
は，財務損失，市場シェアまたは企業イメージの損失が含まれる。影響を測定することにより，
好ましくない偶発事故の結果と偶発事故を防止するためのセーフガードの費用との間でバランス
をとることができる。好ましくない偶発事故については，発生頻度を考慮する必要もある。これ
は，それぞれの事故によって発生する危害は小規模でも，多くの偶発事故の総合的な影響で危害
が生じ得るときに特に重要である。リスクの評価及びセーフガードの選択において，影響の評価
は重要な要素である。
影響の定量的及び定性的な測定は，次のような多くの方法で実施できる。
・財務費用の確定
・経験に基づく強度の尺度(例: 1∼10)の割り当て
・予め定義したリストから選択した表現(例: 低，中，高)の使用
8.5
リスク
リスクとは潜在的なものである。すなわち，資産または資産グループへ（すなわち，直接的，間
接的に組織へ）の損失や損害を与えるぜい（脆）弱性に付け入る脅威である。1 つまたは複数の
脅威が，1 つまたは複数のぜい（脆）弱性に付け入る。
リスクのシナリオは，特定のまたはグループの脅威が資産に危害を与えながら，どのように特定
のまたはグループのぜい（脆）弱性を生み出していくかを説明するものである。リスクは，好ま
しくない偶発事故の発生確率及びその影響という 2 つの要因の組み合わせによって特徴付けられ
る。
8
資産，脅威，ぜい（脆）弱性，及びセーフガードに変更が発生すると，リスクに重大な影響が及
ぶことがある。環境またはシステムにおける変化を早期に検出あるいは認識することによって，
リスク低減のための適切な処置をとる機会が増加する。
8.6
セーフガード
セーフガードとは，脅威に対する保護，ぜい（脆）弱性の低減，好ましくない偶発事故の影響の
制限，好ましくない偶発事故の検出及び復旧の促進を行うことのできる，実践，手順，またはメ
カニズムである。効果的なセキュリティには通常，資産に対して階層的なセキュリティ機能を提
供するために，異なるセーフガードを組み合わせて使用することが必要である。例えば，コンピ
ュータに適用されるアクセス制御機構は，監査の管理，要員規約，トレーニング，及び物理的な
セキュリティによって実現されるべきである。セーフガードによっては，環境の一部，または資
産の固有のものとして既に存在したり，システムあるいは組織内で既に実施されていることがあ
る。
セーフガードは，次の１つ，または幾つかの機能を達成するためのものと考えられる。それらは，
検出，制止，保護，制限，訂正，回復，モニタリング，及び意識向上の機能である。セーフガー
ドを適切に選択することは，セキュリティプログラムをうまく実施する為に不可欠である。多く
のセーフガードは，複数の機能を提供する。複数の機能を満たすセーフガードを選択することは，
費用対効果にしばしば優れている。セーフガードが適用できる領域の例には，次が含まれる。
・物理的な環境
・技術的な環境(ハードウェア，ソフトウェア，及び通信)
・要員
・管理
セキュリティの意識向上はひとつのセーフガードであり，要員の問題に関連する。しかしながら，
この件は重要であるため 9.6 にて議論する。組織が活動している環境及び文化は，選択されたセ
ーフガード及び，組織のセキュリティへの意識向上に関係する。また，セーフガードの中には，
セキュリティに対する組織の態度（あり方）を強く明確なメッセージで表現するものもある。こ
れについては，組織が活動している文化や社会に有益なセーフガードを選択することが重要であ
る。
セーフガードの例は次のとおりである。
・ネットワークファイアウォール
・ネットワークのモニタリング及び分析
・機密保護のための暗号化
・デジタル署名
・ウイルス駆除ソフトウェア
・情報のバックアップコピー
・予備電源（の用意）
・アクセス制御機構
8.7
残存リスク
リスクは通常，セーフガードによって部分的に緩和されるだけである。部分的な緩和が，通常達
成できるすべてであるが，達成されるものが大きくする費用も増大する。これは通常，残存リス
クが残ってしまうことを意味する。セキュリティが組織のニーズにふさわしいかどうかの判断の
一部は，残存リスクの容認である。この処理は，リスクの容認として認知されている。
管理者は，影響とその事象が発生する可能性の点から見たすべての残存リスクを認識すべきであ
9
る。残存リスクの容認に対する判断は，好ましくない偶発事故の影響を認める地位に属する人物
と，残存リスクのレベルが容認されない場合に追加のセーフガードの実施を許可できる人物によ
って行われなければならない。
8.8
制約事項
制約事項は通常，組織の管理者によって設定または認識され，組織が運用される環境によって影
響を受ける。考慮すべき制約事項の対象の例として，次を挙げる。
・組織
・財務
・環境
・要員
・時間
・法律
・技術
・文化/社会
これらはすべて，セーフガードを選択及び実施するときに考慮されなければならない。既存にあ
る制約事項及び新規の制約事項については定期的に見直す必要があり，あらゆる変更を認識すべ
きである。また，制約事項は組織の文化と共に変化するだけでなく，時間，地理，社会の発展と
ともに変化することにも注意すべきである。組織が運用される環境及び文化は，いくつかのセキ
ュリティ要素，特に脅威，リスク，及びセーフガードに関連していることがある。
9.
IT セキュリティ マネジメントプ ロ セ ス
IT セキュリティマネジメントは，いくつかのプロセスからなる継続型のプロセスである。
構成マネジメントや変更管理のようなプロセスは，セキュリティよりむしろ秩序に属するもので
ある。また，リスクマネジメント及びそのサブプロセスであるリスク分析は，IT セキュリティマ
ネジメントにたいへん有用であることが経験から分かっている。リスクマネジメント，リスク分
析，変更管理，構成マネジメントを含む IT セキュリティマネジメントの概要を図２に示す。
9.1 構成マネジメント
構成マネジメントとは，システムの変更を追跡するためのプロセスであり，形式化して行うこ
ともできるし，非形式的に行うこともできる。構成マネジメントのセキュリティ上の主要な目的
は，システムの変更によって組織の総合的セキュリティ及びセーフガードの有効性を維持するこ
とである。
セキュリティ面から見た構成マネジメントの目的は，システムにどのような変更が加えられた
かを明確にすることであり，セキュリティを理由に IT システムの変更を妨げることではない。場
合によっては，セキュリティを弱めるような変更を行なわざるを得ないこともある。そのような
場合には，どの程度セキュリティが低減するのかを調べ，すべての関連した要素に基づいた管理
上の判断をすることが望ましい。言い換えれば，システムを変更するときは，セキュリティとの
関連に十分検討する必要がある。構成マネジメントのもう一つの目的は，システムの変更を，災
害復旧や障害対策計画などの文書に確実に反映させることである。システムの変更が重大な場合
には，システムのセーフガードの一部または全部を再度分析することが必要になる場合もある。
10
ITセ キ ュ リ テ ィ マ ネ ジ メ ン ト
変更管理
構成マネジメント
リスクマネジメント
モニタリング
セキュリティ意識向上
リスク分析
図２
IT セキュリティ マネジメント の 概 念 図
9.2 変更管理
変更管理とは，IT システムに変更が発生したとき，新しいセキュリティ要件の特定を支援する
プロセスである。
IT システム及びその動作環境は常に変化している。新しい IT 技術やサービスが利用可能にな
ったり，新しい脅威やぜい（脆）弱性が発見されることによって，こうした変化が生じる。IT シ
ステムの変更には次の事柄が含まれる。
・新しい手続き
・新しい機能
・ソフトウェアの更新
・ハードウェアの更新
・外部グループまたは匿名グループを含む新ユーザ
・ネットワークの追加及び相互接続
IT システムの変更が生じるとき，あるいは変更を計画するときには，その変更によってシステ
ムのセキュリティにどのような影響が及ぶのかを測定することが重要である。もし，そのシステ
ムに関する構成マネジメント委員会などの技術的なシステム変更を管理する組織があるなら，IT
セキュリティ担当役員をその委員会に割り当て，その変更がセキュリティに影響を与えるのかど
うか，またどの程度なのかを判断する責任を負わせるべきである。新しいハードウェア，ソフト
ウェア，サービスの購入を含む重大な変更については，新しいセキュリティ要件を決定するため
の分析が必要となる。一方，システムの変更の多くは実際には重大でないものであり，重大な変
更の際に必要とする広範な分析は必要としない。いずれにしても，費用対効果を考えたリスク評
価が必要である。重大でない変更の場合，リスク評価は会議で非公式に実施できるが，その結果
及び管理上の決定は文書化することが望ましい。
11
9.3 リスクマネジメント
リスクマネジメント活動は，システムのライフサイクルを通して行うと最も効果的である。リ
スクマネジメントプロセスは，それ自体が活動の重要なサイクルである。新しいシステムについ
てはシステムのサイクル全体を対象とし得るが，過去から稼働しているシステムについては，そ
のシステムの任意の時点から管理を始めることになる。戦略によって，システムのライフサイク
ルのある時点あるいは予め決めた日時から見直しを実施することにしてもよい。セーフガードの
実施状況をチェックする目的で，前回の見直しからの「フォローアップ」もありうる。最も費用
対効果が優れた時点でセキュリティを設計，実施するために，リスクマネジメントをシステムの
設計中や開発中からリスクマネジメントを実施する必要があるかもしれない。システムの重大な
変更を計画するときには，リスクマネジメントも開始することが望ましい。10.の図 4 はリスクマ
ネジメントに含まれる要素を示す。
どのようなリスクマネジメントの手法，技術を利用する場合であっても，すべてのシステムが
必ず適切に保護されるようにしつつ，バランスをとってセーフガードの決定及び実施に費やす時
間と資源を最小限にすることが重要である。
リスクマネジメントは，評価したリスクとセーフガードの効果及び（または）費用とを比較し
て，企業の事業目的及び IT セキュリティポリシーに矛盾しないシステムセキュリティポリシー及
び実施計画を策定することである。したがって，異なる種類のセーフガードについて検討し，費
用と効果を分析することが望ましい。どのセーフガードを選ぶかは，そのリスク及びそのリスク
が顕在化した場合の被害に応じて選択される。また，どの程度の残存リスクが許容できるかにつ
いても考えて置かねばならない。
セーフガード自体にぜい（脆）弱性が含まれており，セーフガードによって新しいリスクが発
生する場合があることにも注意することが望ましい。したがって，セーフガードの選択に当たっ
ては，そのセーフガードによるリスクの低減だけでなく，新たな潜在リスクの発生も考慮しなけ
ればならない。
次の項では，リスクマネジメントのプロセスについてさらに詳しく説明する。
9.4 リスク分析
リスクを抑制するのか許容するのかを識別する作業がリスク分析である。IT セキュリティにお
いては，IT システムのリスク分析は，資産価値，脅威，及びぜい（脆）弱性の分析が含まれる。
それぞれのリスクについて，機密性，完全性，可用性，責任追跡性，真正性または信頼性が侵害
されたときに，どの程度の被害をもたらすのかを評価する。リスク分析を行うことによって，試
算に発生しうるリスクが明らかになる。
リスク分析はリスクマネジメントの一部であり，最初にシステム全体の分析を短時間で行うこ
とによって，時間及び資源を浪費することなくリスク分析を実施できる。つまり，簡単なシステ
ム全体の分析によって，どのシステムを業務規則や必要最小限のベースライン管理策で適切に守
るのかを決定し，それらのシステムについて詳細なリスク分析を行う。業務規則は，必要最小限
の保護要件に合致した最善の手続き及び合意の共通基盤として用いることのできる必要最小限の
ベースライン管理策と一連の手引き書からなる。
9.5 責任追跡性
セキュリティ対策の効果的な実施のためには，セキュリティに関する責任者を明確にして承認
することと，責任追跡性とが必要とされる。責任と責任追跡性は，資産の所有者，提供者，及び
IT システムの利用者に割り当てる必要がある。したがって，資産の所有者及びそれに関連するセ
キュリティの責任は，セキュリティの監査とともに，セキュリティ対策の効果的な実施にとって
重要である。
12
9.6 セキュリティ意識向上
セキュリティ意識の向上は，効果的なセキュリティ対策の実施に必須の要素である。組織内の
個人がセキュリティ対策を怠ったり，個人のセキュリティに対する意識が欠けていたりしては，
セーフガードの効果を著しく低下させる可能性がある。一般的に，組織のセキュリティ水準は，
組織内の最もセキュリティ水準の低い個人の水準になると考えられている。セキュリティ組織内
のセキュリティ意識を確実に十分な水準にするためには，効果的なセキュリティ意識向上計画の
策定及び継続的実施が重要である。セキュリティ意識向上プログラムの目的は，次の項目を従業
員，提携先，供給者に理解させることである。
・セキュリティの目的，戦略，及びポリシー
・セキュリティの必要性と関連する役割及び責任
また，セキュリティ意識向上計画は，従業員，協力相手，及び供給者に動機を与え，それぞれ
のセキュリティに対する責任について了解させるように計画されていることが望ましい。
セキュリティ意識向上計画は，経営者から日々の活動の責任を負う担当者まで，組織内のすべ
ての階層で実施することが望ましい。同じ組織の異なる部門に属しそれぞれ異なる役割及び責任
を負う人々に対して，異なった意識向上用の資料を作成し配布することが必要になることも少な
くない。広範囲に及ぶセキュリティ意識向上計画は，段階的に開発し提供される。各段階は，こ
れまでに得られた教訓の上に構築され，セキュリティの概念から始まり，セキュリティ対策の実
施とモニタリングの責任に至る。
組織内のセキュリティ意識向上計画には，さまざまな活動が含まれる。その１つは，セキュリ
ティ意識向上のための資料（例： ポスター，掲示板，パンフレット，または概要説明）を作成し
配布することである。この資料の目的は，従業員及び契約者の一般的な意識を高めることである。
このほか，特定の従業員に対して適切なセキュリティ対策の実施を訓練する課程を提供すること
もセキュリティ意識向上計画に含まれる。極めて特定のセキュリティ分野については，専門家の
水準の教育を提供する課程が必要とされる。
また，セキュリティ以外の研修計画にセキュリティ関連の内容を組み込むことも効果的である。
ただし，この方法は，単独のセキュリティ意識向上計画に対する補足的または代替的な手段と見
なした方がよい。その組織の持つ文化的な要求条件や経営上の要求条件に調和したセキュリティ
意識向上計画をつくるためには，次の点を検討する必要がある。
・ニーズの分析
・プログラムの配布
・モニタリング
・意識向上プログラムの内容
9.7 モニタリング
セーフガードを実施するときには，それが適切に機能しているか，環境の変化によって無効に
なっていないか，責任追跡性がはっきりしているかをモニタリングすることが望ましい。システ
ムログの自動検査及び分析は，所定の効果を挙げているかどうかを確認する効果的な手段である。
ログの自動検査及び分析は，好ましくない事件の検出にも利用でき，抑止効果もあるかもしれな
い。
セーフガードの有効性は定期的に検証することが望ましい。これは，セーフガードが期待され
た形で機能し，使用されていることを検査し，モニタリングすることによって可能である。セー
フガード手段の多くは，ログやアラームレポートなど，セキュリティ上重大な事象を発見するた
めに検査すべき出力を提供する。一般的なシステム監査からもセキュリティの観点から有用な情
報が得られるので，システム監査をこの観点で利用することもできる。
13
9.8 障害対策計画と災害復旧計画
障害対策計画は，IT システムを含む業務を支援するプロセスが侵害されたり，利用不可能にな
った場合，どのように対処するのかを記述したものである。障害対策計画は，次のような数多く
の筋書きのありうる組み合わせを検討したものであることが望ましい。
・障害の時間の長さ
・さまざまな種類の設備の損失
・構内への物理的アクセス手段の全面的損失
・破壊が起きなかったと仮定した場合のあるべき状態への復帰の必要性
災害復旧計画は，まれな偶発事故によって被害をうけた IT システムの運転を復旧
させる方法を書いたものである。災害復旧計画は，次の内容を含む。
・災害を引き起こす基準
・災害復旧計画を実施する責任
・さまざまな復旧活動の責任
・復旧活動の詳細
10. モデル
IT セキュリティマネジメントについては多くのモデルが存在することが知られている。しかし，
この標準情報群の第 1 部に示すモデルは，IT セキュリティマネジメントの問題を理解する上で必
要な概念を提示するものである。このモデルによって次のことがわかる。
・セキュリティの各要素の関係
・リスクマネジメントの関係
・IT セキュリティ対策活動の管理
これまでに説明してきた概念と組織の事業目的が一体となって，組織の IT セキュリティのため
のポリシー，戦略，計画になる。最優先の目的は，リスクを組織が許容できる限界水準以下にし
つつ，事業遂行能力を維持することである。完全な効果をもつセキュリティはなく，まれな偶発
事故からの復旧計画の策定及び損害を拡大させないセキュリティの構成が重要である。
IT システムのセキュリティは，さまざまな観点からみることのできる多次元の問題である。し
たがって包括的で一貫した IT セキュリティのポリシー及び戦略を策定し，実施するには，関連す
るすべての局面を考慮することが望ましい。図３は，資産がどのように多くの脅威にさらされて
いるかを示している。これらの脅威は，常に変化しており，ほんの一部しか認識されていない。
このモデルが示すものは次のとおり，
・常に変化して一部しか認識されてない脅威を含む環境
・組織の資産
14
環 境
T
T
R
S
V
V
RR
S
V
資産
V
V
S
T
RR
T
図3
S
T
RR
V
凡例
R -リスク
RR- 残存リスク
S -セーフガード
T -脅威
V - ぜい(脆)弱性
セキュリティ要素の関係
・これらの資産のぜい（脆）弱性
・資産の保護及び，脅威による被害の低減のために選択されるセーフガード
・リスクを緩和するセーフガード
・組織にとって許容できる残存リスク
図３に示すように，多くの脅威やぜい（脆）弱性によって生まれるリスクを小さくするために，
いくつかのセーフガードは有効である。残存リスクを許容水準まで下げるために，いくつかのセ
ーフガードが必要になることもときどきある。リスクが許容できるとみなされる場合には，脅威
が存在してもそれに対するセーフガードを行わないことがある。また，ぜい（脆）弱性があって
も，それを悪用する脅威が知られていないこともある。ぜい（脆）弱性を悪用する脅威が顕在化
しないよう脅威が存在する環境をモニタリングするためにセーフガードを行うこともある。図３
には表示されていないが，さまざまな制約要因が，セーフガードの選択に影響を及ぼす。
図４は，リスクマネジメントと関係することの多い，セキュリティ要素間の関係を
示すものである。分かりやすくするために，主な関係だけを表示してある。
15
悪用
脅威
保護
セーフガード
合致する
ぜい(弱)性
増大
増大
減少
さらす
資産
リスク
必要性を示す
増大
持つ
価値
(潜在的な業務へ
の影響度による)
保護要求事項
図 4 ： リスクマネジメントにおける関係
（注）２つのボックスの間に記載された矢印上のラベルは，ボックス同士の関係を示す。
図５，図６，及び図７は，それぞれ保護要求事項と脅威，ぜい（脆）弱性，資産価値との関係
を示すものである。これらの図で示した観点の１つだけを重視した IT セキュリティマネジメント
のやり方もある。しかし，そのような方法では，重要な局面を見落とすことがある。したがって，
より広範囲にわたる問題解決手法を提供する図４を，この標準情報群の第２部及び第３部の基礎
として使用している。
16
脅威
資産
保護要求事項
図5
脅威からの視点
ぜい(弱)性
資産
保護要求事項
図６
ぜい（脆）弱性からの視点
資産
価値
(潜在的な業務への
影響度による)
保護要求事項
図７
被害からの視点
17
IT セキュリティマネジメントは，セキュリティのライフサイクルを考慮に入れた継続型のプロ
セスである。さまざまな局面については，この標準情報群の第２部でさらに吟味する。第３部で
は，セキュリティマネジメントの技法を検討する。図 8 に示すプロセスモデルは，IT セキュリテ
ィマネジメントに関するセキュリティ要素を集めた図である。図 8 については，第 2 部で詳細に
吟味する。
ITセキュリティ
ポリシー
組織的な考え方
リスクマネジメント
セーフガードの実施
フォローアップ
図8
IT セキュリティ プロセスの管理
11. まとめ
この標準情報群の第 1 部で説明する概念及びモデルは，組織の情報資産を保護するための戦略
の展開に用いることができる。この戦略及び関連セキュリティポリシーについては，技術及び情
報サービスの発展及び利用における急速な変化を考慮するために，組織の中で常に見直す必要が
ある。この標準情報群の第 2 部以降では，組織の中でこれらの概念及びモデルを効果的に使用す
る方法についてさらに説明する。
18
TR X 0036-1 ：2001
（ISO/IEC TR 13335-1 :1996）
IT セキュリティマネジメントのガイドライン−
第 1 部：I T セ キ ュ リ テ ィ の 概 念 及 び モ デ ル
解説
この解説は，本体及び附属書に記載した事柄，並びにこれらに関連した事柄を説明するもので，
標準情報の一部ではない。
1. 公表の経緯 情報化社会の発展に伴い，各種の事業活動が IT システムに大きく依存するよう
になってきた。このため，情報およびコンピュータ等の重要な資産を扱う IT システムを高い信頼
性のもとで運用・管理することが必要となり，IT システムのための体系的なセキュリティマネジ
メントの確立が急務となっている。
このような状況の中, ISO/IEC によって， ISO/IEC TR 13335‐ 1:1997（ Information
technology−Guidelines for the management of IT Security−Part1：Concepts and models for
IT Security）が公表された。
この標準化活動は， ISO/IEC JTC1/SC27/WG1 において審議されたが，日本も当初からこの
審議に参画し，多くのコメントを提出し，その作成に寄与してきた。
この標準化活動の完了を受けて，2000 年度から，財団法人日本規格協会では工業技術院の委託
により，情報システムのセキュリティ技術の標準化調査研究委員会を設置して標準情報（TR）の
原案作成を行った。
この標準情報は，TR X 0036-1 :2001 として公表するものである。
2. 概要 この標準情報群（TR X 0036）は，IT セキュリティマネジメントの枠組みについて記
述したものであり，第 1 部，第 2 部，第 3 部，第 4 部及び第 5 部から構成されている。
第 1 部 “IT セキュリティの概念及びモデル”では IT セキュリティの基本概念を，第 2 部 “IT
セキュリティのマネジメント及び計画”では IT セキュリティのマネジメント及び計画に関する行
動，並びに役割及び責任に関する内容を，第 3 部 “IT セキュリティマネジメントのための手法”
では IT セキュリティマネジメントを成功させるための推奨する手法を，第 4 部 “セーフガード
の選択”では適切なセーフガードを選択するためのガイドを，最後の第 5 部 “ネットワークセキ
ュリティにおけるマネジメントのガイダンス”では外部との接続及びそれから得られるサービス
を保護するためのセーフガードの選択及びその使用方法等をそれぞれ取り上げている。なお，第
5 部については，ISO/IEC JTC1/SC27/WG1 において現在審議中である。
この第 1 部“IT セキュリティの概念及びモデル”は，IT セキュリティマネジメントに含まれ
るさまざまな項目，及び IT セキュリティマネジメントを最初に説明する上で欠くことのできない，
基本的な管理の概念とモデルを説明している。特に組織においてセキュリティマネジメントに責
任を持つ立場の上級管理者に適している情報である。本標準情報では，IT セキュリティマネジメ
ントのためのアプローチ，目的，戦略，及びポリシーについて説明し，その中で考慮すべきセキ
ュリティ要素として，守るべき資産，脅威，ぜい（脆）弱性，リスク，防衛手段となるセーフガ
ード等について言及している。一方，セキュリティマネジメントは，構成マネジメント，変更管
理，リスクマネジメント，リスク分析，モニタリングなどの個々のプロセスによって構成され，
それぞれのプロセスについて目的，処理内容，効果が記述されている。最後に，IT セキュリティ
マネジメントのモデルとして，セキュリティ要素の相互関係モデル，リスクマネジメントの構成
要素間の関係，それぞれ保護要求事項と脅威，ぜい（脆）弱性，資産価値との関係を提示してい
る。
本概念とモデルは，組織の情報資産を保護するための戦略を展開するために有効となる。この
戦略と関連セキュリティポリシーについては，急速な進展を遂げている技術及び情報サービスの
変化を絶えず考慮し，組織の中で常に見直すことが必要となる。この標準情報群の第 2 部以降で
は，これらの概念とモデルに基づき，組織の中でこれらを効果的に使用する方法についてさらに
説明している。
1
3. その他解説事項
3.1 翻訳における考慮事項
−原標準情報群（ISO/IEC TR 13335）の翻訳にあたり，たとえ原語（英語）に対する日本工業標
準において用いる訳語（日本語）が定義されている場合であっても，一般の文脈でその原語を
カタカナで表記することの方が多いとき又はそれが読者の利便に資すると判断されたときは，
敢えてこの方法を用いた。
−原標準情報群でしばしば用いられている“management”の訳語としては，それが高次又は広
義の意味で用いられている場合には“マネジメント”を採用し，それ以外の場合には“管理”
を用いることを原則とした。例えば，セキュリティマネジメント・リスクマネジメントなどと
訳出したものは前者に属し，要員管理・変更管理などとしたものは後者に属する。しかしなが
ら明確に区別しにくい場合も多く，そのときは“マネジメント”をあてていることが多い。
−可能な限り分かりやすい翻訳を目指したが，原文を対照形式で添えて発行して，読者が原文を
容易に確認できるようにした。
3.2 ISO における継続審議状況
−2001 年 1 月現在，TR 13335-5 は審議中である。
−2001 年 1 月現在，TR 13335-1：1996 は改訂作業が行われている。
3.3 用語の定義と訳語
この標準情報群の第 1 部3.で定義している。
3.3.1 用語の定義 この標準情報群で用いる用語は，
3.3.2 訳語 この標準情報群では，この標準情報の3.で定義された用語以外に，次の訳語を使用
した。
原語
administration
assessment
assessment of risk
authentication
awareness
baseline approach
basic assessments
change management
code of practice
combined approach
commitment
configuration
configuration control
configuration management
contingency plans
corporate IT security officer
corporate IT security policy
cryptography
destructive attack
detailed risk analysis
disaster recovery
eavesdropping
electromagnetic radiation
employee
evaluation
fire, water
訳語
管理
評価、または分析（状況によって使い分ける）
リスクの評価
認証
意識、意識向上
ベースラインアプローチ
基本評価
変更管理
実践規範
組合わせアプローチ
コミットメント
構成
構成制御
構成マネジメント
障害対策計画
企業のITセキュリティ責任者
全社的ITセキュリティポリシー
暗号技術
破壊的攻撃
詳細リスク分析
災害復旧
盗聴
電磁放射
従業員
評価、または分析（状況によって使い分ける）
水害、災害
2
follow-up
high level risk analysis
identification
implementation of safeguards
implementation
incident handling
informal approach
information marking scheme
IT security architecture
IT security forum
IT security plan
IT security recommendations
loss
maintenance
malicious code
management
management commitment
masquerading of user identity
mechanism
media
misuse of resources
models
monitoring
natural disasters
needs analysis
network management
non-repudiation
operational issues
penetration test
people
personnel
policy relationships
practice
procedure
process/processes
property
protection requirements
requirement
resource
responsibility
risk acceptance
roles and responsibilities
security architecture
security awareness
security compliance
security elements
フォローアップ
上位レベルリスク分析（初期に実施する概要ﾚ
ﾍﾞﾙの分析）
識別、特定
セーフガードの実施
導入、実施
事件/事故の扱い
非公式アプローチ
情報重要度分類手法
ITセキュリティアーキテクチャ
ITセキュリティ委員会
ITセキュリティ計画
ITセキュリティの推奨事項
喪失
保守
悪意のあるコード
マネジメント、管理、経営管理
経営者のコミットメント（責任）
ユーザのなりすまし
しくみ
記録媒体 又は メディア、記録媒体(使分け
は文脈依存）
リソースの誤用
モデル
モニタリング
自然災害
必要性の分析
ネットワーク管理
否認防止
運用上の事項
ペネトレーションテスト
人
要員（人事管理の場合もある）
ポリシーの相互関係
慣例
手順、手続き
プロセス、過程
特性
保護要求事項
要求事項、要件（使分けは文脈依存）
資源
責任
リスクの容認
役割及び責任
セキュリティアーキテクチャ
セキュリティの意識向上
セキュリティ遵守
セキュリティ要素
3
security officer
security policy
security program
security training
software failures
staff
structure
sub-process
summary
theft
traffic overloading
transmission errors
user error
valuation
4.
セキュリティ責任者、セキュリティ部門責任者
(使分けは文脈依存)
セキュリティポリシー
セキュリティ計画（プラン）
セキュリティの訓練
ソフトウェアの欠陥
スタッフ
構成
サブプロセス
まとめ
盗難
トラヒックの過負荷
通信エラー
ユーザエラー
評価、または分析（状況によって使い分ける）
原案作成委員会の構成表 原案作成委員会の構成表を，次に示す。
平成 1 2 年度 情報システムのセキュリティ技術の標準化調査研究委員会 構成表
氏名
所属
（委員長）
苗村 憲司 慶應義塾大学環境情報学部
（幹事）
中尾 康二 株式会社ＫＤＤ研究所
（幹事）
竜田 敏男 日本アイ・ビー・エム株式会社
（幹事）
櫻井 幸一 九州大学大学院システム情報科学研究科
（委員）
岩下 直行 日本銀行金融研究所
植村 泰佳 電子商取引安全技術研究組合
奥田 和男 社団法人日本情報システムユーザー協会
小倉 久宜 財団法人金融情報システムセンター
才所 敏明 株式会社東芝
紫合
治 日本電気株式会社
菅
知之 電子商取引推進協議会
宝木 和夫 株式会社日立製作所
竹田 栄作 三菱電機株式会社
田渕 治樹 富士通株式会社
徳永 英二 ＴＯＫ
西川
満 情報処理振興事業協会
前川
徹 早稲田大学国際情報通信研究センター
森田
光 日本電信電話株式会社
吉田健一郎 財団法人日本品質保証機構
（オブザーバ）東井 芳隆 経済産業省商務情報政策局情報セキュリティ政策室
八田
勲 経済産業省産業技術環境局標準課
（事務局）
山中 正幸 財団法人日本規格協会
平成 1 2 年度 情報システムのセキュリティ技術の標準化調査研究委員会 WG1
（主査）
中尾 康二 株式会社ＫＤＤ研究所
（副主査）
大越 丈弘 三菱電機株式会社
（委員）
榎木 千昭 情報システムコントロール協会
橘和 尚道 日本システム監査人協会
工藤 正康 日本アイ・ビー・エム株式会社
栗田 博司 情報処理振興事業協会
小林 秀樹 社団法人情報サービス産業協会
4
構成表
杉浦
昌
関本
貢
前川
徹
山田 朝彦
山本
明
吉田健一郎
渡辺 展文
（オブザーバ）石井 伸治
平野 芳行
（事務局）
山中 正幸
日本電気株式会社
財団法人日本情報処理開発協会
早稲田大学国際情報通信研究センター
株式会社東芝
沖電気工業株式会社
財団法人日本品質保証機構
財団法人金融情報システムセンター
経済産業省商務情報政策局情報セキュリティ政策室
経済産業省産業技術環境局標準課
財団法人日本規格協会
5
ＴＲ
I T セキュリティマネジメントのガイドライン−
第 2 部：IT セキュリティのマネジメント及び計画
TR X 0036-2
(ISO/IEC TR 13335-2)
まえがき
この標準情報（TR）は，工業標準化法に基づいて，日本工業標準調査会の審議を経て，経済産業大
臣が公表した標準情報（TR）タイプⅢである。公表に当たっては，1997 年に発行された ISO/IEC TR
13335-2:1997[Information technology―Guidelines for the management of IT Security―Part
2:Managing and planning IT Security]を基に作成した。
TR X 0036 の標準情報群は，次に示す 5 部で構成される。
TR X 0036-1 第 1 部 IT セキュリティの概念及びモデル
TR X 0036-2 第 2 部 IT セキュリティのマネジメント及び計画
TR X 0036-3 第 3 部 IT セキュリティマネジメントのための手法
TR X 0036-4 第 4 部 セーフガードの選択（制定予定）
TR X 0036-5 第 5 部 ネットワークセキュリティのマネジメントガイダンス（制定予定）
ii
目次
1. 適用範囲
1
2. 参考資料
1
3. 定義
1
4. 構成
1
5. 目的
1
6. 背景
1
7. IT セキュリティマネジメント
2
7.1 計画及びマネジメントのプロセスの概要
2
7.2 リスクマネジメントの概要
3
7.3 実施の概要
3
7.4 フォローアップの概要
3
7.5 IT セキュリティの組込み
3
8. 全社的 IT セキュリティポリシー
3
8.1 目的
3
8.2 経営者の責任
4
8.3 ポリシーの相互関係
4
8.4 全社的 IT セキュリティポリシーの要素
4
9. IT セキュリティのための組織
5
9.1 役割及び責任
5
9.1.1 IT セキュリティ委員会
6
9.1.2 全社的 IT セキュリティ責任者
7
9.1.3 個別プロジェクト及び個別システムの IT セキュリティ担当者
9.2 コミットメント（関与）
7
9.3 一貫性のあるアプローチ
7
10. 企業のリスク分析戦略の選択肢
8
10.1 ベースラインアプローチ
8
10.2 非公式アプローチ
8
10.3 詳細リスク分析
9
10.4 組合せアプローチ
9
11. IT セキュリティの推奨事項
9
11.1 セーフガードの選択
9
11.2 リスクの容認
10
12. IT システムのセキュリティポリシー
10
13. IT セキュリティ計画
11
14. セーフガードの実施
11
15. セキュリティ意識
11
16. フォローアップ
12
16.1 保守
12
16.2 セキュリティ遵守
13
16.3 モニタリング
13
16.4 事件／事故の取扱い
13
17. まとめ
14
解説
iii
7
序文
この標準情報（ＴＲ）群の目的は，IT セキュリティをマネジメントの観点から捉えてガイダンスすることであり，解決策を提供
することではない。組織のなかで IT セキュリティに対する責任がある人々は，この標準情報群が取り上げている内容を，そ
れぞれに固有のニーズにあわせて応用できる能力があることが望ましい。この標準情報群が主な目標にしていることは，次
のとおりである：
・ITセキュリティマネジメントに関連した概念を定義して説明すること，
・ITセキュリティマネジメントと，ITマネジメント全般との関係を明らかにすること，
・IT セキュリティについて説明するときに利用できる，いくつかのモデルを提示すること，及び
・IT セキュリティマネジメントに関して，一般的なガイダンスを行うこと。
この標準情報群は，5 つの部によって構成されている。第１部では，IT セキュリティマネジメントの説明にあたって用いる，
基本概念及びモデルについて概説する。この内容は，IT セキュリティに対して責任がある経営管理者，及び組織のセキュ
リティプログラム全般に対して責任がある人々のために役に立つものである。
第２部は，マネジメント及び計画の側面を取り上げている。この内容は，次のような，組織の IT システムと関連する責任を負
っている運営管理者に関係するものである：
・IT システムの設計・導入・試験・調達・運用に関して監督責任を負う IT 運営管理者，
・IT システムの利用を意味あるものとする諸活動について責任を負う管理者，又は
・もちろんのことであるが，IT セキュリティについて責任を負う管理者。
第３部では，プロジェクトの計画・設計・導入・試験・取得・運用といったライフサイクルの過程で，管理的な業務に携わる
人々に役立つセキュリティへの対処方法を説明する。
第４部では，セーフガードの選択についてガイダンスを行うが，ベースラインモデルと管理策とを利用することがセーフガー
ド選択にどう役立つかについても述べる。また，これらを利用することが第３部で説明したセキュリティへの対処方法をどう補
足することなのか，また，セーフガードの選択のために，評価手法をどう追加して使うかについても説明する。
第５部は，IT システムを外部ネットワークに接続する組織に対するガイダンスである。このガイダンスでは，外部との接続及
びそれから得られる利便を保護するためのセーフガードの選択及びその使用について，並びにシステムを外部と接続する
ときに追加すべきセーフガードについても取り上げている。
なお，この標準情報（TR）で点線の下線を施してある部分は，原標準情報（TR13335-2）にない事項である。
参考
第５部の原標準情報（ISO/IEC TR 13335-5 Management guidance on network security）は，現在審議中である。
iv
1.
標 準 情 報 (T R )
TR
IT セ キ ュ リ テ ィ マ ネ ジ メ ン ト の ガ イ ド ラ イ ン −
第 2 部：I T セ キ ュ リ テ ィ の マ ネ ジ メ ン ト 及 び 計 画
X 0036-２: 2001
(ISO/IEC TR 13335-２:1997)
適用範囲
この標準情報群の第２部が提示するガイドラインは，IT セキュリティマネジメントに関する基本的な事項及びそれらの相互
関係を取り扱っている。このガイドラインは，IT セキュリティのすべての局面を認識した上で IT セキュリティを運営管理して
いくことに役立つ。第２部を十分に理解するためには，第１部で提示した概念及びモデルに習熟していることが必要であ
る。
備 考 この規格の対応国際標準情報を，次に示す。
なお，対応の程度を表す記号は，ISO/IEC Guide21 に基づき，IDT（一致している），MOD（修正
している），NEQ（同等でない）とする。
ISO/IEC TR 13335-2 :1997[Information technology ― Guidelines for the management of IT
Security―Part 2:Managing and planning IT Security]（IDT）
2. 参 考 資 料
T R Ｘ 0036-1 情報技術 − IT セキュリティマネジメントのガイドライン − 第１部:IT セキュリティの概念及びモデル
備考 ISO/IEC TR 13335-1 : 1996, Information technology - Guidelines for the management of IT Security Concepts and models for IT Security がこの標準情報と一致している。
3.
定義
この標準情報群の第２部にも，第１部で行った次の用語についての定義が適用される：責任追跡性，資産，真正性，可用
性，ベースライン管理策，機密性，データ完全性，影響，完全性，IT セキュリティ，IT セキュリティポリシー，信頼性，残存リ
スク，リスク，リスク分析，リスクマネジメント，セーフガード，システム完全性，脅威，ぜい(脆)弱性。
4.
構成
この第２部は 17 の項目で構成されている。５.及び６.では，この標準情報（第２部）の目的及び背景について説明する。７.
では，IT セキュリティマネジメントに含まれるさまざまな活動について概説する。８.から 16.で，これらの活動について詳述
する。17.はまとめである。
5.
目的
この第２部の目的は，IT セキュリティのマネジメント及び計画にかかわるさまざまな活動について説明するとともに，それに
付随した組織内の役割及び責任について説明することにある。この内容は，IT システムの調達・設計・導入・運用に責任を
もつ IT 運営管理者に特に関係が深いものである。またこの内容は， IT システムの利用を意味あるものとする諸活動につ
いて責任を負う管理者にも，IT セキュリティに対する責任の有無を問わず関係することである。広くいうならば，この第２部
は，組織の IT システムの運営管理に責任があるすべての者にとって有益である。
6.
背景
政府及び民間の組織の諸活動は，情報の利用に大きく依存している。情報及びそのサービスにおける機密性・完全性・可
用性・責任追跡性・真正性・信頼性の喪失は，組織に悪影響を及ぼすことになる。従って，情報を保護すること及び組織内
の情報技術(IT)システムのセキュリティを運営管理することが極めて重要になっている。この情報保護についての要求は，
今日の環境では特に重要である。なぜなら，多くの組織は IT システムのネットワークによって内部及び外部に接続されて
いるからである。
IT セキュリティマネジメントとは，機密性・完全性・可用性・責任追跡性・真正性・信頼性を確保しこれを適切なレベルで維
持するために用いるプロセスのことである。IT セキュリティマネジメントには，次の機能が含まれる：
・組織の，IT セキュリティの目的・戦略・ポリシーの決定，
・組織の，IT セキュリティの要求事項の決定，
・組織内の IT システム資産に対するセキュリティ上の脅威及びぜい(脆)弱性の特定及び分析，
・セキュリティリスクの特定及び分析，
・適切なセーフガードの確定，
・組織内の情報及びそのサービスを費用対効果に優れた方法で保護するために必要なセーフガードの，導入及び運用に
対するモニタリング，
1
・セキュリティ意識向上プログラムの開発及び実施，及び
・事件／事故の発見及び対応。
このような IT システムの運営管理責任を全うするためには，組織の総合的マネジメント計画においてセキュリティを必須の
ものとすること，及び組織のすべての機能プロセスにセキュリティを組み込むことが必要である。従って，この標準情報が扱
うセキュリティに関するいくつかの事項は，広い概念でのマネジメントにかかわることになる。ただこの標準情報は，マネジメ
ントの問題を広く取り上げようとするものではなく，各事項のセキュリティの側面及びそれらが一般的にどのようにマネジメン
トと関係するかに焦点をあてている。
7.
7.1
IT セキュリティマネジメント
計画及びマネジメントのプロセスの概要
IT セキュリティの計画及びマネジメントは，組織内に IT セキュリティのプログラムを確立し維持していく総合的なプロセスで
ある。図１は，このプロセスに含まれる主な活動を示す。マネジメントの態様並びに組織の規模及び構造はさまざまなので，
このプロセスは，使用される環境に合わせて修整することが望ましい。重要なことは，図１で示されるすべての活動及び機
能が，組織の態様，規模及び構造並びに事業のやり方の範囲内で行われる事である。図には示していないが，マネジメン
トレビューもこれらの活動及び機能の一部として行われる。
出発点は，組織の IT セキュリティの目的について明確な見解を確立することである。この目的は，より高次のレベルの目的
(例:ビジネスの目的)から導き出され，次にこれから，８.で詳述するように組織の IT セキュリティ戦略及び全社的 IT セキュリ
ティポリシーが導き出される。従って，全社的IT セキュリティポリシーの一部は，明確にされた目的の達成を確実にする，適
切な組織構造から生み出されるものである。
全社的ITセキュリティポリシー
(8. )
ITセキュリティのための組織
(9.)
リスクマネジメント(7.2 )
企業のリスク分析戦略の選択肢
(10.)
選択
ベースライン
アプローチ
非公式
アプローチ
詳細
リスク分析
ITセキュリティの推奨事項
(11.)
ITセキュリティポリシー
(12.)
ITセキュリティ計画
(13.)
実施 (7.3 )
セキュリティ意識向上
(15.)
セーフガード
(14.)
フォローアップ
(16.)
図1
セキュリティの計画及びマネジメントの概要
2
組合せ
アプローチ
7.2
リスクマネジメントの概要
リスクマネジメントには，４つの異なる活動が含まれる：
・全社的 IT セキュリティポリシーに沿った，組織に適切な総合的リスクマネジメント戦略の決定，
・リスク分析活動の結果又はベースライン管理策に基づいた，各 IT システムにおけるセーフガードの選択，
・セキュリティ推奨事項に基づく各IT システムのセキュリティポリシーの策定，及び，必要な場合には，全社的IT セキュリテ
ィポリシー (及び，該当するならば，部門の IT セキュリティポリシー)の更新，及び
・承認された IT システムのセキュリティポリシーに基づき各システムにセーフガードを実施するための，IT セキュリティ計画
の作成。
7.3 実 施 の 概 要
それぞれの IT システムに必要なセーフガードの実施は，それぞれの IT セキュリティ計画に従って行うことが望ましい。しば
しば軽視されるが，IT セキュリティ意識を広く向上させることは，セーフガードの有効性に大きくかかわることである。図１は，
セーフガードの実施とセキュリティ意識向上プログラムとの二つのタスクを並行的に行うのが望ましいことを示すものである。
なぜなら，ユーザの行動はにわかに変わることがなく，意識の向上には長期間にわたる継続した積み重ねが必要だからで
ある。
7.4
フォローアップの概要
16 .で取り上げるフォローアップの活動には，次の事項が含まれる：
・継続的かつ効果的な運用を確実にするための，セーフガードの保守，
・承認されたポリシー及び計画にセーフガードが沿っていることを確認するための，チェック，
・資産，脅威，ぜい(脆)弱性及びさまざまな問題に応じるセーフガードについての，リスクに影響をもたらす可能性のある変
更を検知するためのモニタリング，及び
・好ましくない事象に適切に反応することを確実にするための，事件／事故の取扱い。
フォローアップは継続的なタスクであり，これには既往の決定事項の再評価を含むことが望ましい。
7.5
IT セキュリティの組込み
IT セキュリティのすべての活動は，組織全体で統一的にかつ IT システムのライフサイクルの始点から開始された場合に最
も効果的である。IT セキュリティのプロセス自体が大規模な循環的活動であり，IT システムのライフサイクルのあらゆるフェ
ーズにこれを組み込むことが望ましい。セキュリティは新規のシステムに当初から組み込んだ場合に最も効果的であるが，
過去から引き継いできたシステム及び事業活動にセキュリティを組み込んだ場合でも，その時から効用を得ることができる。
IT システムのライフサイクルは，３つの基本フェーズに分けられる。これらのフェーズはそれぞれ次のように IT セキュリティと
関連する：
・計画:すべての計画及び意思決定の活動において，IT セキュリティのニーズを取り上げることが望ましい。
・取得:システムの設計・開発・購入・更新・構築のプロセスに IT セキュリティについての要求事項を組み込むことが望ましい。
将来ではなく適切なときにこれらの活動にセキュリティの要求事項を組み込むことは，費用対効果の点で優れたセ
キュリティの状況を確実にシステムにもたらす。
・運用: IT セキュリティを運用環境に組み込むことが望ましい。IT システムは，目的の業務に使用しているうちに，新しいハ
ードウェアコンポーネントの購入又はソフトウェアの変更若しくは追加を含む一連のアップグレードを経験するのが
通常である。加えて運用環境は頻繁に変化する。このような環境変化は，システム上に新たなぜい(脆)弱性を発生
させることがあり，それについては分析及び評価を行って，対策をとるか又は容認するかの決定を行うことになる。同
様に，システムを安全に廃棄又は譲渡することも重要である。
IT セキュリティは，IT システムのライフサイクルの各フェーズ及びフェーズ相互間での多くのフィードバックを伴った，継続
的なプロセスであることが望ましい。図１は全体的なフィードバックの経路を示したものである。多くの場合，フィードバックは
IT セキュリティのプロセスでの大きな活動のすべて及び活動相互間でも発生する。このフィードバックによって，IT システム
のライフサイクルの３フェーズを通して，IT システムのぜい(脆)弱性，脅威及びセーフガードに関する情報が途切れることな
く伝達される。
組織のなかの事業領域ごとに独自の IT セキュリティに対する要求事項が認識される可能性があることにも注意する必要が
ある。そのようなときは，事業領域の間でセキュリティにかかわる情報を共有し，お互いの事業領域及び組織全体の IT セキ
ュリティのプロセスを支援することが望ましく，このような情報は全体の経営意思決定プロセスを支援することにもなろう。
8 全社的 I T セキュリティポリシー
8.1 目的
目的(達成すべきこと)，戦略(目的達成の方法)及びポリシー(目的達成のためのルール)は，各レベルの組織及びそのなか
の事業単位又は部門ごとに定義することができる。効果的な IT セキュリティを達成するためには，組織レベル及び事業単
3
位における目的，戦略及びポリシーの足並みが揃っていることが必要である。多くの脅威(例えば，システムハッキング・ファ
イル滅失・火災)はビジネスに共通する問題であるから，異なる観点にたっていることの影響はあるだろうが，これらの事柄を
取り上げた文書類の間に一貫性のあることが重要である。
8.2
経営者の責任
最高経営者の IT セキュリティに対する責任は重要であり，この責任を発揮したものとして，正式に合意され及び文書化され
た全社的 IT セキュリティポリシーが策定されることが望ましい。全社的 IT セキュリティポリシーは，企業のセキュリティ基本
方針から誘導されることが望ましい。
8.3
ポリシーの相互関係
適切なときは，全社的 IT セキュリティポリシーを，企業の技術基本方針及び経営管理基本方針のなかに含めてもよく，この
二つの方針は企業の IT 戦略ステートメントの基礎となる。この戦略ステートメントでは，セキュリティの重要性について積極
的に言及することが望ましく，戦略に則っていくことにセキュリティが必要である場合はとりわけそうである。図２は，さまざま
なポリシーの相互関係を示したものである。実際の文書及び組織の構造は組織によって異なるだろうが，諸々のポリシーが，
さまざまな記述になっていても一定内容を扱っていること及び一貫性を維持していることが重要である。
ビジネスの目的及び
戦略から導き出された
企業のビジネス基本方針
マーケット基本方針
セキュリティ基本方針
情報技術基本方針
全社的ITセキュリテ
ィポリシー
部門のITセキュリテ
ィポリシー
・
・
・
システムBの
システムAの
ITセキュリティポリシー
図２
ポリシーの相互関係
特定のシステム及び特定のサービス又は特定の IT システム群及び特定のサービス群のためには，より詳細化した IT セキ
ュリティポリシーが必要になる。これらは通常，IT システムのセキュリティポリシーと呼ばれる。IT システムのセキュリティポリ
シーの適用範囲及び境界線が明確に定義されていること，並びにこれを設定することが事業及び技術上の理由に基づい
ていることは，運営管理上で重要なことである。
8.4
全社的 I T セキュリティポリシーの要素
全社的 IT セキュリティポリシーには，少なくとも次の事項を含むことが望ましい：
・機密性・完全性・可用性・真正性・責任追跡性・信頼性といった観点からの，IT セキュリティの要求事項。とりわけ資産の
所有者としての視点からの要求事項，
・組織的な基盤及び責任の割り当て，
4
・システムの開発段階及び調達段階でのセキュリティの組込み，
・指示書及び手順書，
・情報を分類するための分類定義，
・リスクマネジメント戦略，
・障害対策計画，
・要員問題(信頼が必要な，例えば保守要員及びシステムアドミニストレータのような地位につく要員には特別の注意を払う
ことが望ましい)，
・セキュリティ意識の向上及び訓練，
・法令上の義務，
・外注管理，及び
・事件／事故の取扱い。
9.
9.1
IT セキュリティのための組織
役割及び責任
IT セキュリティは多くの分野にまたがる問題であり，各 IT プロジェクト及びシステム並びに組織内の IT ユーザのすべてに
関連する問題でもある。責任を適切に割り当てること及び責任の境界を明確にすることで，すべての重要なタスクの確実か
つ効率的実行を確実にすることが望ましい。
この目標は組織の規模及び構造によって変わるさまざまな仕組みを通して達成できるが，どのような組織でも，次の役割を
カバーすることが必要である：
・例えば多くの分野にまたがる問題の解決並びに指示書及び標準規格の承認について担当する，IT セキュリティ委員会，
及び
・組織内の IT セキュリティのすべてについて，中心となって活動する全社的 IT セキュリティ責任者。
IT セキュリティ委員会及び全社的 IT セキュリティ責任者はともに，十分に定義されかつ曖昧ではない職務を担うことが望ま
しい。また全社的 IT セキュリティポリシーに関与できる上級の職員がこれに就くべきである。組織は，全社的IT セキュリティ
責任者のために，情報提供，責任及び権限に関する明確な方針を打ち出すことが望ましく，この責任者の職務はITセキュ
リティ委員会において承認されることが望ましい。これら職務の履行は，外部コンサルタントを利用することで補完することも
できる。
図３は，全社的 IT セキュリティ責任者，IT セキュリティ委員会，及び組織内の，例えば他のセキュリティ機能，ユーザ組織
及び IT とかかわる要員といった他の領域からの代表者の相互関係の典型を示したものである。このような関係は，ラインの
マネジメント又は機能上の場合もある。図３に示した IT セキュリティの組織の例では，３つの組織レベルが想定されている。
この例は，組織のニーズによってレベルを追加又は削除することで，どのような組織でも容易に採用できるものである。中小
規模の組織では，セキュリティに関するすべての役割をカバーする責任者として全社的 IT セキュリティ責任者を選任する
かもしれない。このように機能が統合される場合は，一人の手に過度の権力が集中して他からの影響又は管理が及ばなく
なることがないように，適切なチェックアンドバランス機構の維持を確実にすることが重要である。
5
経営陣
セキュリティ
担当役員
IT運営委員会
全社的ITセキュ
リティ責任者
全社的
ITセキュリティ
ポリシー及び
指示書
ITセキュリティ
委員会
全社レベル
*部門の
ITセキュリティ
責任者
IT関連代表者
ITユーザ
代表者
*部門レベル
*部門の
ITセキュリティ
ポリシー及び
指示書
個別システム又は
個別ﾌﾟﾛｼﾞｪｸトレベル
ITプロジェクト又は
システムの
セキュリティ担当者
凡例：
委員会への参画を示す
組織的なつながりを示す
* 部門がそれなりの規模であるときに限る
図3
9.1.1
ITプロジェクト
又はシステムの
セキュリティ
ポリシー
IT セキュリティのための組織の例
IT セキュリティ委員会
このような委員会は，セキュリティ要求事項の特定，セキュリティポリシーの策定，全社的セキュリティ計画の作成，実施結果
のレビュー及び全社的ITセキュリティ責任者への指示に必要なスキルを持つ者をメンバーとすることが望ましい。このような
目的に利用できる委員会組織が既に存在する場合もあろうし，それでも，独立の IT セキュリティ委員会を別に置く方がよい
場合もある。このような委員会の役割は，次のとおりである：
・IT 運営委員会に対する，戦略的セキュリティ計画についての助言，
・IT 戦略に裏打ちされた全社的 IT セキュリティポリシーの策定及び IT 運営委員会からの承認の取得，
・全社的 IT セキュリティポリシーの， IT セキュリティ計画への転換，
・全社的 IT セキュリティ計画の実施状況のモニタリング，
・全社的 IT セキュリティポリシーの有効性の見直し，
・IT セキュリティ問題についての意識向上の推進，及び
・計画プロセス及び IT セキュリティ計画の実施のために必要な経営資源(要員・資金・知識など)についての助言。
6
委員会が効果的であるために，IT システムのセキュリティ及び技術面にバックグラウンドを持つ者，並びに IT システムのプ
ロバイダ及びユーザの代表者をメンバーに含めることが望ましい。このような領域から得られる知識及びスキルは，実用的
な全社的 IT セキュリティポリシーの開発に必要である。
9.1.2 全社的 IT セキュリティ責任者
IT セキュリティの責任は皆に共有されるので，責任を感じる者が結局はだれもいないことになる危険性がある。このことを防
ぐために，責任を特定の個人に割り当てることが望ましい。全社的 IT セキュリティ責任者は，組織内の IT セキュリティ関連
すべての中心となることが望ましい。この責任を追加的に課してもよい者が既に存在するかもしれないが，専任のポストとし
て設置することが推奨される。全社的 IT セキュリティ責任者には，セキュリティ及び IT についてのバックグラウンドを持つ者
を選任することが望ましい。主な責任は次のとおりである：
・IT セキュリティ計画の実施に対する監視，
・IT セキュリティ委員会及びセキュリティ担当役員との連携及び報告，
・全社的 IT セキュリティポリシー及び指示書の維持，
・事件／事故調査の調整，
・企業全般にわたるセキュリティ意識向上プログラムの運営管理，及び
・IT プロジェクトのセキュリティ担当者及びシステムのセキュリティ担当者(及び，場合によっては，部門の IT セキュリティ責
任者)の担当事項の決定。
9.1.3 個別プロジェクト及び個別システムの IT セキュリティ担当者
個々のプロジェクト又はシステムにもセキュリティについて責任をもつ者を置くことが望ましく，これは IT セキュリティ担当者
と通常呼ばれる。これはフルタイムの職務ではないこともある。これら担当者の職務を指揮管理することは，全社的 IT セキ
ュリティ責任者(あるいは，それが置かれているときは，部門の IT セキュリティ責任者)の責任である。これら担当者は，ある
プロジェクト，あるシステム又はシステム群におけるセキュリティ関連すべての中心的役割を果たす。IT セキュリティ担当者
の主な責任は次のとおりである：
・全社的 IT セキュリティ責任者(あるいは，それが置かれているときは，部門の IT セキュリティ責任者)との連携及び報告，
・IT プロジェクト又はシステムのセキュリティポリシーの発行及び維持，
・セキュリティ計画の開発及び実行，
・IT セーフガードの実施及び使用状況の日々のモニタリング，
・事件／事故調査の開始及び支援。
9.2
コミットメント（関与）
効果的な IT セキュリティのためには，個々人の努力に対する管理者すべてのレベルからの支持が不可欠である。IT セキ
ュリティの目的達成に向けた企業規模の関与には，次の事項が含まれる：
・組織の全体的ニーズに対する理解，
・組織内の IT セキュリティのニーズに対する理解，
・IT セキュリティへの関与の意思表明，
・IT セキュリティのニーズに取り組む意志，
・経営資源を IT セキュリティに割り当てる意志，及び
・IT セキュリティの意味又は構造(適用範囲，限度)についての高次のレベルでの意識。
IT セキュリティの目標は，組織全体に公表されるべきである。従業員又は契約雇用者それぞれは，ITセキュリティに対する
自分の役割，責任及び貢献を認識して，この目標達成に対する任務が委ねられるべきである。
9.3
一貫性のあるアプローチ
IT セキュリティに向けた一貫性のあるアプローチを，開発・保守及び運用の活動すべてに適用することが望ましい。情報及
び IT システムのライフサイクルの，計画から廃棄に至るまでの全体を通じて，保護が確実にされることが望ましい。
図３に示したような組織構造では，組織全体が調和を保って IT セキュリティにアプローチすることができる。この状況では，
標準規格を利用することが役に立つ。標準規格としては，国際・国内・地域・産業セクター及び企業の標準又は規則を考え
ることができるが，組織のITセキュリティのニーズによって選択及び適用することになる。技術標準は，その実施，使用及び
運営管理に際して，規則及びガイドラインによって補足する必要がある。
標準規格を利用することの利点は，次のとおりである：
・統合されたセキュリティ，
・相互運用性，
・一貫性，
・可搬性，
・規模の利益，及び
・組織間の相互作用。
7
10 .
企業のリスク 分 析 戦 略 の 選 択 肢
セキュリティを高めることを望む組織は，自己の環境にふさわしくかつ効果的にリスクに取り組む手段を含んだリスクマネジメ
ント戦略をたてることが望ましい。必要なところにセキュリティのための努力を集中し，かつ費用及び時間の点で優れたアプ
ローチをとるための戦略が必要である。
すべてのシステムを詳細にレビューすることは，資源又は時間の点で効果的ではないし，重大なリスクを検討しないことも効
果的ではない。このような極端な例のバランスをとったアプローチとして，それぞれのニーズに合致した程度の分析によって
システムのITセキュリティニーズを決定する，上位（概要）レベルのレビューを行うことがある。組織のセキュリティニーズは，
組織の規模，ビジネスの種類，並びに環境及び文化に依存する。企業のリスク分析戦略の選択肢のどれを用いるかは，こ
のような事情をよく踏まえていることが望ましい。
組織は，状況によって，何もしないこと，又はセーフガードの実施を延期することを決断することがある。このような経営判断
は，上位レベルのレビューを完了したあとでのみ行われることが望ましい。ただし，このような決断を行う場合，経営管理者
は，自分の責任になるリスク及び悪影響並びに好ましくない事件／事故が発生する可能性を十分に認識することが望まし
い。このような認識がないと，組織は，法律又は規制に偶然に違反したりビジネス上の損失をこうむることがある。何もしない
こと又はセーフガードの実施を延期することの決断及び正当化は，これらのこと及び発生し得る悪影響を十分に検討したあ
とでのみ採られることが望ましい。
上位レベルのレビュー結果に基づき，次に説明する４つの選択肢のいずれかを用いることによって，リスクを緩和するセー
フガードが選択できる。次の項では，各選択肢のもたらす利点及び欠点を説明する。
10.1
ベースラインアプローチ
第一の選択肢は，或るセーフガードのまとまりを採用し，すべてのシステムに対してベースラインレベルでの保護を達成す
ることである。いくつかのベースライン文書及び慣例基準が，さまざまな標準的セーフガードを提案している。基本的ニーズ
を調査した後では，例えば，国際標準化団体及び国内標準化団体，業界セクタの標準又は推奨事項，適切な類似性(例
えば，ビジネスの目的・規模・IT システム・アプリケーション)を持つ会社など他の組織から，参考となるセーフガードをみつ
けることもできる。
このアプローチには，次のような多くの利点がある：
・詳細リスク分析を行う場合のような資源が不要であり，セーフガードの選択に費やす時間及び努力を低減できる。通常，
ベースラインセーフガードの特定には，多くの資源を必要としない，
・数多くのシステムに対し，大きな努力をすることなく同一又は類似のベースラインセーフガードを適用できる。一つの組織
に属する非常に多くのシステムが共通の環境で動作する場合で，ビジネスニーズが類似しているときは，ベースラインセ
ーフガードは，費用対効果に優れた解決策を提供できる。
この選択肢の欠点は，次のとおりである：
・ベースラインレベルの設定が高すぎると，システムによっては，過度に高価な又は過度に抑制的なセキュリティになること
がある。また，ベースラインレベルの設定が低すぎると，システムによっては不十分なセキュリティになることがある。
・セキュリティに関連する変更の管理が困難なことがある。例えば，システムをアップグレードするとき，元々のベースライン
セーフガードが引き続き維持されているかどうかを評価することが困難なことがある。
10.2
非公式アプローチ
２番目の選択肢は，すべてのシステムに対して非公式で実際的なリスク分析を実施することである。この非公式アプローチ
は構造化された方法に基づくものでなく，個人の知識及び経験を活用するものである。内部にセキュリティの専門家がいな
いときは，外部のコンサルタントによってこの分析を行うことができる。
この選択肢の利点は，次のとおりである：
・非公式分析を行うために改めて技術を習得する必要がないので，詳細リスク分析よりも迅速に実施される。従って，このア
プローチは費用対効果に優れていて，小規模の組織に適している。
次のいくつかの欠点が存在する：
・構造化されたアプローチでないため，何かのリスク及び関連領域を見落とす可能性が大きくなる。
・このアプローチは定式化されていないので，分析結果は，主観的な見方及びレビューアの偏った見方によって影響を受
けることがある。
・選択されたセーフガードの根拠が希薄なので，セーフガードの費用を正当化することも困難である。
・レビューを繰り返さないと，セキュリティに関連する変更を継続的に管理することが困難である。
8
10.3
詳細リスク分析
３番目の選択肢は，すべてのシステムに対して詳細リスク分析を行うことである。詳細リスク分析には，資産の特定及び評価，
並びに資産に対する脅威及び資産のぜい（脆）弱性の程度の評価が含まれる。この情報は，リスク評価のために使用され
る。このことによって，リスク分析は，特定の資産へのリスクに対する正当なセーフガードの特定，選択，及び採用，並びに
経営管理者が確定した容認レベルまでのリスク低減の根拠を提供する。詳細リスク分析は資源を非常に消費するので，こ
の方法を適用する範囲を慎重に設定すること及び絶えず管理者が注意を払っていくことが必要である。
この選択肢の利点は，次のとおりである：
・システムそれぞれのセキュリティの必要性に適合したセキュリティレベルが特定される。
・セキュリティに関連する変更の管理において必要な追加的情報が，詳細リスク分析から得られる。
この選択肢の主な欠点は，次のとおりである：
・明確な結果を得るのに，相当な時間・努力・熟練が必要である。
10.4
組合せアプローチ
４番目の選択肢は，上位レベルでのリスク分析アプローチを使用して，まず，ビジネス活動において危険又は重要なシステ
ムを特定することである。そして，その結果に基づき，適切な保護を達成するためには詳細リスク分析が必要なシステムと，
ベースライン保護で十分なシステムとに分類することである。
この選択肢は，10.1「ベースラインアプローチ」及び 10.3「詳細リスク分析」に記述した選択肢の長所を組み合せたものであ
る。従ってこの選択肢は，セーフガードの特定に費やされる時間及び努力の低減のバランスをとる一方で，すべてのシステ
ムを適切に保護することも保証する。
この選択肢の利点は，次のとおりである：
・重要な資源を投入する前に，上位レベルのアプローチを使用して必要な情報を収集するので，リスクマネジメントのプログ
ラムが受け入れ易くなる。
・組織のセキュリティプログラムの戦略的全体像を迅速に描くことが可能になる。この全体像は，適切な計画の立案を支援
するものとして使用できる。
・最も有益なところに資源及び費用を配分できる。また，危険度が高いと思われるシステムを早期に指摘できる。
この選択肢の欠点は，次のとおりである：
・上位レベルリスク分析の結果が不正確な場合は，詳細リスク分析が必要なシステムが指摘されないことがある。尤もこのよ
うなことは，上位レベルリスク分析の結果が適切にチェックされるなら発生する見込みは少ないし，指摘されなかったシス
テムも，少なくともベースラインセーフガードによってカバーされるだろう。
ほとんどの状況で，この選択肢は最も費用対効果に優れたアプローチを提供する。従って，ほとんどの組織に対して推奨
できるリスク分析の選択肢である。
11.
IT セキュリティの推奨事項
10 .で取り上げたアプローチのどれもが，セキュリティリスクを容認可能なレベルに低減するための，多くの推奨事項を提供
する。これらの推奨事項は，経営管理者によって承認されることが望ましく，また，次の事項を含むことが望ましい：
・検討する IT システムの，リスクの容認レベルを決定するための基準，
・容認レベルにリスクを低減するセーフガードの選択，
・これらセーフガードの実施上の利点及びこれらセーフガードによって達成されるリスク低減，及び
・これらセーフガードがすべて実施されたときでも残る，残存リスクの容認。
11.1
セーフガードの選択
セーフガードにはいくつかのタイプがある。例えば，好ましくない事件／事故の防止・低減・モニタ・検出，又は修正を行う
セーフガード，及びそのような事件／事故からの復旧を行うセーフガードである。防止策には，好ましくない行為の抑止及
びセキュリティ意識を高める活動を含めることができる。セーフガードを適用できる主な領域及び各領域におけるセーフガ
ードの例は，次のとおりである：
・ハードウェア(バックアップ・かぎ(鍵))，
・ソフトウェア(電子署名・ロギング・ウイルス対策ツール)，
・通信(ファイアウォール・データ暗号化)，
・物理的な環境(フェンス・バッジ)，
・人事管理(スタッフの意識・従業員の退職手順)，及び
9
・管理(権限付与・ハードウェアの廃棄・ライセンス管理)。
セーフガードはそれぞれが独立したものではなく，しばしば組み合わされて機能する。選択のプロセスでは，セーフガード
の相互依存性を考慮しなければならない。セーフガードを選択するときは，間隙が残らないようにチェックすることが望まし
い。このような間隙によって，導入したセーフガードに抜け道ができて，偶然の脅威によって障害が発生することがある。
新しいシステム，又は大きな変更が行われている既存システムでは，セーフガードの選択にセキュリティアーキテクチャを含
むことがある。セキュリティアーキテクチャは，IT システムに対してセキュリティ要求事項をどのように満たすかを記述し，か
つシステムアーキテクチャ全体の一部を成すものである。セキュリティアーキテクチャでは，技術的なセーフガードだけでな
く，技術以外の面も考慮に入れる。
すべてのセーフガードには，効果的な運用を保証するためのマネジメントが必要である。また，多くのセーフガードには，保
守を目的とする管理的な支援が必要である。セーフガードの選択プロセスでは，これらの要素に注意することが望ましい。
セーフガードは，効果的に，かつユーザ又は管理者に過度のオーバーヘッドを発生させることなく実施することが重要であ
る。セーフガードの導入が重大な変更を伴うものである場合は，セキュリティ意識向上プログラム，変更管理，及び構成マネ
ジメントと組み合わせて実施することが望ましい。
11.2 リスクの容認
選択したセーフガードの実施後にも，必ず残存リスクが存在する。なぜなら，絶対的に安全なシステムの構築は不可能であ
り，また，資産によっては，意図的に保護しないままでおくこともあるからである(例: 想定されるリスクが低いか，又は保護さ
れる資産の評価価値に対して推奨されたセーフガードの費用が高い場合)。
リスク容認プロセスの最初の段階は，選択したセーフガードをレビューし，すべての残存リスクを特定及び評価することであ
る。その次の段階は，残存リスクを，組織にとって ”容認可能”なものと ”容認不可”なものとに分類することである。
容認できないリスクが許容できないことは明らかであり，このようなリスクの影響又は結果を限定的にする追加のセーフガー
ドを検討するのが望ましい。このような場合には，ビジネス上の判断を行う必要がある。リスクを ”容認可能”と判断するか，
許容できるレベルにリスクを低減するための追加のセーフガードの費用が承認されなければならない。
12 .
IT システムのセキュリティポリシー
IT システムのセキュリティポリシーは，全社的及び部門のセキュリティポリシーに基づくことが望ましい。これらのシステムの
セキュリティポリシーは，システム及びサービスを保護するための規範及び規則の集合から構成される。このポリシーは，十
分なレベルの保護の達成を確実にする，システム及びサービスに適切なセーフガードを適用することで，実施されなけれ
ばならない。
IT システムのセキュリティポリシーは，その適用及び実施に要する財源及び人的資源が確実に約束された強制的な規範
及び規則の集合として，上級の経営管理者によって承認されなければならない。
各 IT システムのセキュリティポリシーを決定するときに考慮すべき重要事項は，次のとおりである：
・検討する IT システム及びその境界線の特定，
・そのシステムによって達成されるビジネスの目的の特定。これは，そのシステムのセキュリティポリシー並びにセーフガード
の選択及び実施に影響を及ぼすことがある，
・次による，ビジネスへの潜在的な悪影響：
― 情報を含めたサービス又は資産の可用性の喪失，否認，又は破壊，
― 情報又はソフトウェアの無認可の変更，及び
― 情報の無認可の開示，
これらには，直接又は間接の金銭的損失などの定量的な結果，及び営業権の喪失・死亡又は生命への危険・プライバ
シーの侵害などの定性的な結果が伴う，
・IT への投資レベル，
・IT システム及び取り扱う情報への重大な脅威，
・特定された脅威からの危険に IT システムをさらしておく弱点を含む，ぜい（脆）弱性，
・特定されたリスクに見合って必要なセキュリティセーフガード，
・IT 資産の保護費用などの，IT セキュリティの費用(IT セキュリティの費用は，IT システムを所有することに伴う費用の一部
として検討するのが望ましい)，及び
・外部委託者(例: 計算センター，PC サポート)との関係及び外部委託者の選択に関する規範。
IT セキュリティには計画的なアプローチが必要であり，他と分離して検討しないことが望ましい。IT セキュリティは，戦略計
画プロセスにおける主役であることが望ましく，そうあることによって，システムに対するセキュリティが最初から計画及び設
計される。ほとんどの場合，あとからセーフガードを追加することは，より費用がかかるか，実際的ではない。
10
13
IT セキュリティ計画
IT セキュリティ計画とは，IT システムのセキュリティポリシーを実施するための，調整された活動を定めた文書である。この
計画には，短期・中期・長期的に実施される主な活動，投資・運用・作業負荷などの観点から取りまとめた関連諸費用，及
び実施のタイムスケジュールを含むことが望ましい。この計画には，次の内容を含めることが望ましい：
・総合的なセキュリティアーキテクチャ及び設計，
・IT システムが，財務損失の最大見積もり，懸念事項，企業イメージなどの観点からみた組織のセキュリティ目的に合致し
ていることの，概要説明。
・経営管理者が認識しかつ確認した，評価されたリスクに対応したセーフガードの特定。
・効果の判定を含む，セーフガードの信頼性についての実際レベルでの評価，
・システム又はアプリケーションに関連させた残存リスクの評価の概要，
・セーフガード導入のための，相互の優先関係を明らかにした諸活動の特定及び定義，
・優先順位，予算，及びタイムスケジュールを含む，セーフガード導入に関する詳細作業計画，
・次の事項を含む，プロジェクト管理活動：
― 資源の確保及び責任の割り当て，及び
― 進捗報告の手順の特定，
・IT スタッフ及びエンドユーザに対する，セキュリティの意識向上及び訓練の要求事項，及び
・セキュリティの運用手順及び管理手順の開発に対する要求事項。
また，この計画には，計画自体の変更を含めて，上記の事項を承認するための条件及び行動を規定した手順を含めること
が望ましい。
14 .
セーフガードの実施
IT セキュリティ計画の策定に続いて，その実施が必要となる。通常，その実施は，IT システムのセキュリティ担当者が責任
を負う。セキュリティを実施するときは，次の目的に留意することが望ましい。即ち，次の事項が確実であることが望ましい：
・セーフガードの費用が，承認された範囲内にあること，
・IT セキュリティ計画の要求事項のとおりにセーフガードが正しく導入されること，及び
・IT セキュリティ計画の要求事項のとおりにセーフガードが運用及び管理されること。
技術的なセーフガードのほとんどは，運用手順及び管理手順によって補足される必要があり，技術的手段のみによって実
施することはできない。従って，手順は，ラインの管理者によって支持されかつ運用されることが望ましい。
セキュリティの意識向上及び訓練もセーフガードの一つと見なされる。意識向上については，その重要性に鑑み1 5.で別に
説明する。セキュリティの意識向上はすべての要員についてのものであるが，次の要員には特別のセキュリティ訓練が必要
である：
・IT システムの開発に対して責任を持つ要員
・IT システムの運用に対して責任を持つ要員，
・IT プロジェクト及びシステムセのキュリティ担当者，及び
・アクセス制御などのセキュリティ管理に対して責任を持つ要員。
IT セキュリティ計画の実施が完了した場合，正式なプロセスによって，IT システムのセキュリティ計画に掲げられたセーフ
ガードの実施を承認する措置をとることが望ましい。この承認が得られると，IT システム又はサービスの運用認可が与えら
れる。この承認プロセスはところによっては使用認定とも呼ばれる。
IT システム又はサービスに重大な変更があったときは，IT システム又はサービスの再チェック，再試験，及び再承認を行う
ことが望ましい。
15 .
セキュリティ意識
セキュリティの意識向上プログラムは，最高経営者からユーザまでの組織の全レベルを対象に実施することが望ましい。ユ
ーザレベルの要員の参加及び受け入れが無い場合，セキュリティの意識向上プログラムは成功しない。ユーザは，プログラ
ムの成功には自分達が重要であることを理解する必要がある。
意識向上プログラムでは，全社的 IT セキュリティポリシーの知識を伝達し，セキュリティガイドライン及び適切な行動を完全
に理解させることが望ましい。さらに，セキュリティの意識向上プログラムは，システムセキュリティ計画の目的も取り上げるこ
とが望ましい。このプログラムは，少なくとも次の項目を取り扱うことが望ましい：
・情報保護の基本的な必要性，
・セキュリティ上の事件／事故と組織との係わり合いのみならず，ユーザとの係わり合い，
・リスク及びセーフガードの理解に導く，背景目的，並びに全社的 IT セキュリティポリシー，及びリスクマネジメント戦略の説
明，
11
・セーフガードを実施及びチェックするための IT セキュリティ計画，
・情報の分類，
・データ所有者の責任，
・責任，職務内容記述書，及び手順，
・セキュリティ侵害又は侵害の企図に対する，報告及び調査の必要性，
・認可された方法で行動しないことによる結果(懲戒処分を含む)，
・セキュリティの遵守状況のチェック，及び
・変更管理及び構成マネジメント。
効果的なセキュリティの意識向上プログラムでは，小冊子・ハンドブック・ポスター・ビデオ・ニュースレター・実践演習・ワー
クショップ・セミナー・講義などのさまざまな媒体を使用する。意識向上プログラムの実施が社会，文化及び心理面を考慮し
ていること，並びにセキュリティの重要性を十分に意識する文化が開発されることが重要である。
セキュリティの意識向上には，組織内のすべての人々が関係することが望ましい。また，人々の行動様式に影響を及ぼして
責任感を強めることが望ましい。重要な要因は，管理者にセキュリティの必要性を認識させることである。部下のセキュリティ
意識向上を確実にすることは，管理者の仕事である。従って，管理者は，対応する予算を計画する必要がある。大規模な
組織の場合，IT セキュリティの意識向上の責任を，全社的 IT セキュリティ責任者に課することが望ましい。意識向上プログ
ラムの目的は，IT システムには重大なリスクが存在すること，そして情報の喪失又は無認可の変更若しくは開示によって組
織及び従業員に重大な結果が発生しうることを，関係者に意識させることである。
組織が置かれている状況について意識を高める集会を計画することは，好ましいことである。集会では，ニュースメディアに
よって報じられた例などよりも，容易に理解できて印象の強い，自社の場合などの身近な例を取り上げることが望ましい。こ
のような集会では講師と従業員が対話する多くの機会も提供される。セキュリティの意識向上集会の効果を測定し集会の
内容を評価するために，従業員のセーフガードへの遵守状況をモニタリングすることが望ましい。結果が満足のいくもので
ない場合，セキュリティの意識向上集会の内容を状況に合わせて変更することが望ましい。
セキュリティの意識向上集会は，既存スタッフの知識のリフレッシュ及び新しい要員への情報提供の両方を目的に，定期的
に実施されることが望ましい。さらに，新入社員，新規異動者，及び新規昇格者には，新しい責任について教育することが
望ましい。他の研修コースに IT セキュリティの側面を組み込むことも一考に価する。強調すべきは，セキュリティの意識向
上は持続させていくプロセスであり，終わったと見なすことができないことである。
16 .
フォローアップ
セーフガードが機能しており又機能し続けることを予想可能かつ適切な方法で確実にするために，すべてのセーフガード
を保守していくことが必要である。セキュリティのこの側面は極めて重要なことの一つであるが，またさして配慮されないこと
でも特徴的である。既存のシステム又はサービスに後から考えてセキュリティを追加した場合，時とともにそれを忘れてしま
うことも珍しくない。導入したセーフガードは無視される傾向があり，そこまでではなくても，セキュリティの維持又は改良にほ
とんど注意が払われないことがある。さらに，セーフガードの陳腐化も，偶然に見つけるというよりは計画的な行動によって
発見することが望ましい。また，セキュリティの遵守状況のチェック，動作環境のモニタリング，ログ記録のレビュー，及び事
件／事故の取扱いも，セキュリティの継続を確実にするために必要である。
16.1
保守
管理を含むセーフガードの保守は，組織のセキュリティプログラムに必須な部分である。次のことを確実にすることは，あら
ゆるレベルの管理者の責任である：
・組織の資源をセーフガードの保守に割り当てる，
・意図したとおりに継続されることを確実にするため，セーフガードを定期的に再評価する，
・新しい要求事項が発見された場合は，セーフガードを更新する，
・セーフガードの保守の責任を明確に定める，
・IT システムに対するハードウェア及びソフトウェアの変更及び更新によっても，既存のセーフガードの意図した作用が影
響されない，及び
・技術進歩によっても新しい脅威又はぜい（脆）弱性が持ち込まれない。
上記の保守活動が達成されるときは，既存のセーフガードは意図したとおりに実施され続け，費用への悪影響も回避でき
るだろう。
12
16.2
セキュリティ遵守
セキュリティの遵守状況のチェックは，セキュリティ監査又はセキュリティレビューとしても知られ，IT システムのセキュリティ
計画に対する適合及び遵守を確実にするための，非常に重要な活動である。
適切なレベルの IT セキュリティが有効であることを確実にするには，実施されているセーフガードが，IT プロジェクト又はシ
ステムセキュリティ計画に掲げられたセーフガードと継続的に適合していることが必要である。これは，すべての IT プロジェ
クト及びシステムで，次の間，成り立たなければならない：
・設計及び開発，
・運用されている間の期間，及び
・交換又は廃棄。
セキュリティの遵守状況のチェックは，外部又は内部の要員(例: 監査人)を利用して実施してよく，本質として，IT プロジェ
クト又は IT システムのセキュリティポリシーと関連させたチェックリストを用いることになる。
セキュリティの遵守状況のチェックは，計画され，かつ他の計画された活動と統合されることが望ましい。臨時に行うチェック
は，運用支援スタッフ及びユーザが，特定のセーフガード及び手順に従っているかどうかを調べるときに特に有用である。
チェックは，正しいセキュリティセーフガードが導入され，正しく実施，使用及び，適切な場合にはテストされることを確実に
するために実施することが望ましい。何かのセーフガードがセキュリティ上で適合していないことを検出したときは，是正処
置の計画を作成し，それを実践し，その結果をレビューすることが望ましい。
16.3
モニタリング
モニタリングは，IT セキュリティのサイクルで非常に重要な部分である。これが正しく実施されると，管理者は次について明
確に認識することができる：
・設定された目標及び期限に対して，どこまで達成されているか，及び
・達成すべき内容を満たしているかどうか，及び特別な対応がとられ，又はとられなかった個所。
資産・脅威・ぜい（脆）弱性・セーフガードのあらゆる変更は，リスクに重大な影響を及ぼすことがある。また，このような変更
を早期に検出することで，予防措置をとることができる。
多くのセーフガードは，セキュリティと関連する事象についてのログを作成する。これらのログは，少なくとも定期的に見直さ
れることが望ましい。また可能なら，統計的な技法を用いることで，変化の傾向を早期に検出し，悪影響を及ぼす事象の再
発を発見できるようにすべきである。過去の事象を分析するだけにログを使用することは，非常に強力なセーフガードの仕
組みを無視することになる。モニタリングには，関連する IT セキュリティ責任者及び管理者に定期的に報告を行うための手
順も含めることが望ましい。
16.4 事 件 ／ 事 故 の 取 扱 い
セキュリティに関する事件／事故の発生は回避できない。それぞれの事件／事故は，発生した損害に見合う程度の詳しさ
で調査することが望ましい。事件／事故の取扱いによって，通常の IT システム運用における偶然又は故意の破壊に対処
する能力を備えることができる。従って，組織の IT システム及びサービスの全体に適した，事件／事故の報告及び調査の
仕組みを開発することが望ましい。さらに， ITセキュリティ上の事件／事故及びそれに関連する脅威の発生，並びに IT 資
産及びビジネス活動への影響について幅広い見解を得るために，組織が連合した報告制度に参加することを検討すること
が望ましい。
IT セキュリティについての事件／事故調査の基本目的は，次のとおりである：
・分別ある効果的な方法での事件／事故への対処，及び
・類似した出来事が将来発生することを防止するための，事件／事故からの学習。
予め確定させた判断を含む対応計画を用意しておくと，組織は妥当な時間のうちに被害拡大を押さえる対策をとることがで
き，適切な場合には，予備手段によって規模を縮小してでもビジネスを継続することができる。事件／事故の取扱いに関す
る計画には，事象及び処理のすべてを網羅した時系列による記録作成の要求事項を含んでいることが望ましい。このこと
は，事件／事故の原因特定に繋がるはずである。これは，セーフガードの改良によって将来のリスクを低減するという，二
次目的に到達するための前提条件である。事件／事故がもつ効果の 1 つは，セーフガードに投資する意思が高められるこ
とである。
事件／事故を分析して記録を作成するときは，次の疑問をもって臨むことが重要である：
・何がいつ発生したか？
・スタッフは計画を遵守していたか？
・必要な情報をスタッフは適時に利用できたか？
13
・次に事件／事故が発生したときは，スタッフは何をしようとするか？
これらの疑問に答えることが，事件／事故を理解する上で役立つ。そしてこれを，関連する IT セキュリティポリシー及び計
画の改善(例: セーフガードの改善，ぜい（脆）弱性の低減，及びセキュリティの意識向上プログラムの修正)を通して，リスク
低減のために活用することが望ましい。
17 .
まとめ
第２部では， IT セキュリティの効果的なプログラムとかかわるマネジメントプロセス及び責任について検討した。この検討は，
IT セキュリティマネジメントに登場するいくつかの主要なプロセス及び機能を，管理者によく知ってもらうことを目的としてい
る。第２部が提供する情報は，すべての組織にそのままの形で適用できるものではないかもしれない。特に，小規模の組織
では，説明した機能を完全に実行するための資源をすべて持っている場合は少ない。このような状況では，基本的な概念
及び機能を組織に適した方法で取り扱うことが重要である。大規模な組織においても，第２部で取り扱った機能のいくつか
は，述べられたとおりに達成されないことがある。第３部では，第２部で説明した機能を満たすために使用できるいくつかの
技法を吟味する。第４部以降では，セーフガード及び外部接続のための特別なセーフガードの選択の問題を扱う予定であ
る。
14
TR X 0036-2 ：2001
（ISO/IEC TR 13335-2 :1997）
IT セキュリティマネジメントのガイドライン−
第 2 部：I T セ キ ュ リ テ ィ の マ ネ ジ メ ン ト 及 び 計 画
解説
この解説は，本体及び附属書に記載した事柄，並びにこれらに関連した事柄を説明するもので，
標準情報の一部ではない。
1. 公表の経緯 情報化社会の発展に伴い，各種の事業活動が IT システムに大きく依存するよう
になってきた。このため，情報およびコンピュータ等の重要な資産を扱う IT システムを高い信頼
性のもとで運用・管理することが必要となり，IT システムのための体系的なセキュリティマネジ
メントの確立が急務となっている。
こ の よ う な 状 況 の 中 , ISO/IEC によって，ISO/IEC TR 13335-2:1997（ Information
technology−Guidelines for the management of IT Security−Part2 : Managing and Planning
IT Security）が公表された。
この標準化活動は， ISO/IEC JTC1/SC27/WG1 において審議されたが，日本も当初からこの
審議に参画し，多くのコメントを提出し，その作成に寄与してきた。
この標準化活動の完了を受けて，2000 年度から，財団法人日本規格協会では工業技術院の委託
により，情報システムのセキュリティ技術の標準化調査研究委員会を設置して標準情報（TR）の
原案作成を行った。
この標準情報は，TR X 0036-2:2001 として公表するものである。
2. 概要 この標準情報群（TR X 0036）は，IT セキュリティマネジメントの枠組みについて記
述したものであり，第 1 部，第 2 部，第 3 部，第 4 部及び第 5 部から構成されている。
第 1 部 “IT セキュリティの概念及びモデル”では IT セキュリティの基本概念を，第 2 部 “IT
セキュリティのマネジメント及び計画”では IT セキュリティのマネジメント及び計画に関する行
動，並びに役割及び責任に関する内容を，第 3 部 “IT セキュリティマネジメントのための手法”
では IT セキュリティマネジメントを成功させるための推奨する手法を，第 4 部 “セーフガード
の選択”では適切なセーフガードを選択するためのガイドを，最後の第 5 部 “ネットワークセキ
ュリティにおけるマネジメントのガイダンス”では外部との接続及びそれから得られるサービス
を保護するためのセーフガードの選択及びその使用方法等をそれぞれ取り上げている。なお，第
5 部については，ISO/IEC JTC1/SC27/WG1 において現在審議中である。
この第 2 部“IT セキュリティのマネジメント及び計画”は，第 1 部での IT セキュリティマネ
ジメントのプロセス（構成マネジメント，リスクマネジメント，モニタリング等）及びそれらプ
ロセスの要素（資産，脅威，リスク等）についての概念説明，並びにそれらの相互関係の理解を
助けるモデルの提示を踏まえて，読者として IT システムのライフサイクル（計画，取得，運用）
に関係する人々及び IT システムの利用が意味あるものとなることに関係する人々を想定して，IT
セキュリティマネジメントのプロセスを組織の総合的なマネジメントのプロセス並びに組織機構
及びそれを構成する人々のなかにどのように取り入れていくかを，次のような視点からガイダン
スしている。
−IT セキュリティマネジメントのプロセスが，IT セキュリティポリシー設定からセーフガード等
の実施に至り，フォローアップをとおして再びポリシー設定に戻る，循環する連鎖の関係にあ
ること。
−IT セキュリティポリシーは，組織の基本目標及び戦略から導かれた組織の IT 基本方針・セキ
ュリティ基本方針等を踏まえて設定し，必要に応じて部門・IT システム・プロジェクトごとの
ポリシーに階層化すること。
−IT システムのライフサイクル全体に IT セキュリティマネジメントを及ぼすために，その責任
の中心になる者と責任範囲を明確にする必要があり， IT セキュリティに関係する人々で構成
1
された委員会を設置することが望ましいこと。またこのような組織体制は，必要に応じて部門・
IT システム・プロジェクトごとの体制として階層化すること。
なおこの第 2 部は，想定している読者が IT セキュリティマネジメントの全体を概観できるよ
うに，セーフガードの選択のために採用し得る道筋（ベースラインアプローチ，非公式アプロー
チ，組合せアプローチ）等についても触れているが，これらの点は，第 3 部が“マネジメントの
ための手法”として詳しく取り上げている。
3. その他解説事項
3.1 翻訳における考慮事項
−原標準情報群（ISO/IEC TR 13335）の翻訳にあたり，たとえ原語（英語）に対する日本工業標
準において用いる訳語（日本語）が定義されている場合であっても，一般の文脈でその原語を
カタカナで表記することの方が多いとき又はそれが読者の利便に資すると判断されたときは，
敢えてこの方法を用いた。
−原標準情報群でしばしば用いられている“management”の訳語としては，それが高次又は広
義の意味で用いられている場合には“マネジメント”を採用し，それ以外の場合には“管理”
を用いることを原則とした。例えば，セキュリティマネジメント・リスクマネジメントなどと
訳出したものは前者に属し，要員管理・変更管理などとしたものは後者に属する。しかしなが
ら明確に区別しにくい場合も多く，そのときは“マネジメント”をあてていることが多い。
−可能な限り分かりやすい翻訳を目指したが，原文を対照形式で添えて発行して，読者が原文を
容易に確認できるようにした。
3.2 ISO における継続審議状況
−2001 年 1 月現在，TR 13335-5 は審議中である。
−2001 年 1 月現在，TR 13335-1：1996 は改訂作業が行われている。
3.3 用語の定義と訳語
3.3.1 用語の定義 この標準情報群で用いる用語は，
この標準情報群の第 1 部3.で定義している。
参考のため，ここに転載する。形式は次のとおり。
原国際標準情報の箇条番号；日本語の用語；
（原国際標準情報の用語）
；日本語の定義
3.1 責任追跡性（accountability）:あるエンティティの動作が，そのエンティティに対して一
意に追跡できることを主張する特性。(JIS X 5004:1991)。
3.2
資産（asset）: 組織に対して価値を持つもの。
3.3 真正性 （authenticity）: 対象またはリソースが要求されているものと同一であること
を保証する特性。真正性は，ユーザ，プロセス，システム，情報などのエンティティに対して
適用する。
3.4 可用性 （availability）: 許可されたエンティティによって要求されたときにアクセスと
使用が可能な特性(JIS X 5004 :1991)。
3.5 ベースラインコントロール（baseline controls）: システムまたは組織のために必要とさ
れる最低限のセーフガード。
3.6 機密性（confidentiality）: 許可されていないの個人，エンティティ，またはプロセスに
対して情報を使用不可または非開示にする特性(JIS X 5004 :1991)。
3.7 データ完全性（data integrity）: 許可されていない方法でデータが改ざんまたは破壊され
ていない特性(JIS X 5004 :1991)。
3.8 影響（impact）: 好ましくない偶発事故の結果。
2
3.9 完全性（integrity）: データ完全性及びシステム完全性を参照。
3.10 IT セキュリティ（IT security）: 機密性，完全性，可用性，責任追跡性，真正性，及び
信頼性の定義，達成，維持に関するすべてのセキュリティ（aspects）
。
3.11 IT セキュリティポリシー（IT security policy）: 組織及びその IT システムの範囲内で，
重要情報を含む資産をどのように管理，保護，及び分配するかを統制する規則，指令，及び実
践。
3.12 信頼性（reliability）: 矛盾のない計画とおりの動作及び結果を確保する特性
3.13 残存リスク（residual risk）: セーフガードが実施されたあとに残存するリスク。
3.14 リスク（risk）:
ある脅威が，資産または資産グループのぜい（脆）弱性を利用して，資産への損失，または損
害を与える可能性
3.15 リスク分析（risk analysis）: セキュリティリスクの識別，セキュリティリスクの程度の
判定，及びセーフガードが必要な領域の識別を実行するプロセス。
3.16 リスクマネジメント（risk management）: IT システムの資源に影響を及ぼす不確かな
事象を識別，制御，除去，または低減する総合的なプロセス。
3.17 セーフガード（safeguard）: リスクを低減する実践，手順，またはメカニズム。
3.18 システム完全性（system integrity）: システムが，意図的または偶発的な不正の操作か
ら妨害されることなく，本来果たすべき機能を滞りなく実行する特性。
3.19 脅威（threat）: システムまたは組織に危害を与える，好ましくない偶発事故の潜在的な
原因。
3.20 ぜい（脆）弱性（vulnerability）: 脅威によって影響を受け得る資産または資産グループ
の弱さ。
3.3.2 訳語 この標準情報群では，この標準情報群の第 1 部 3.で定義された用語以外に，次の訳
語を使用した。
原語
administration
assessment
assessment of risk
authentication
awareness
baseline approach
basic assessments
change management
code of practice
combined approach
commitment
configuration
訳語
管理
評価、または分析（状況によって使い分ける）
リスクの評価
認証
意識、意識向上
ベースラインアプローチ
基本評価
変更管理
実践規範
組合わせアプローチ
コミットメント
構成
3
configuration control
configuration management
contingency plans
corporate IT security officer
corporate IT security policy
cryptography
destructive attack
detailed risk analysis
disaster recovery
eavesdropping
electromagnetic radiation
employee
evaluation
fire, water
follow-up
high level risk analysis
identification
implementation of safeguards
implementation
incident handling
informal approach
information marking scheme
IT security architecture
IT security forum
IT security plan
IT security recommendations
loss
maintenance
malicious code
management
management commitment
masquerading of user identity
mechanism
media
misuse of resources
models
monitoring
natural disasters
needs analysis
network management
non-repudiation
operational issues
penetration test
people
personnel
policy relationships
構成制御
構成マネジメント
障害対策計画
企業のITセキュリティ責任者
全社的ITセキュリティポリシー
暗号技術
破壊的攻撃
詳細リスク分析
災害復旧
盗聴
電磁放射
従業員
評価、または分析（状況によって使い分ける）
水害、災害
フォローアップ
上位レベルリスク分析（初期に実施する概要ﾚ
ﾍﾞﾙの分析）
識別、特定
セーフガードの実施
導入、実施
事件/事故の扱い
非公式アプローチ
情報重要度分類手法
ITセキュリティアーキテクチャ
ITセキュリティ委員会
ITセキュリティ計画
ITセキュリティの推奨事項
喪失
保守
悪意のあるコード
マネジメント、管理、経営管理
経営者のコミットメント（責任）
ユーザのなりすまし
しくみ
記録媒体 又は メディア、記録媒体(使分け
は文脈依存）
リソースの誤用
モデル
モニタリング
自然災害
必要性の分析
ネットワーク管理
否認防止
運用上の事項
ペネトレーションテスト
人
要員（人事管理の場合もある）
ポリシーの相互関係
4
practice
procedure
process/processes
property
protection requirements
requirement
resource
responsibility
risk acceptance
roles and responsibilities
security architecture
security awareness
security compliance
security elements
security officer
security policy
security program
security training
software failures
staff
structure
sub-process
summary
theft
traffic overloading
transmission errors
user error
valuation
4.
慣例
手順、手続き
プロセス、過程
特性
保護要求事項
要求事項、要件（使分けは文脈依存）
資源
責任
リスクの容認
役割及び責任
セキュリティアーキテクチャ
セキュリティの意識向上
セキュリティ遵守
セキュリティ要素
セキュリティ責任者、セキュリティ部門責任者
(使分けは文脈依存)
セキュリティポリシー
セキュリティ計画（プラン）
セキュリティの訓練
ソフトウェアの欠陥
スタッフ
構成
サブプロセス
まとめ
盗難
トラヒックの過負荷
通信エラー
ユーザエラー
評価、または分析（状況によって使い分ける）
原案作成委員会の構成表 原案作成委員会の構成表を，次に示す。
平成 1 2 年度 情報システムのセキュリティ技術の標準化調査研究委員会 構成表
氏名
所属
（委員長）
苗村 憲司 慶應義塾大学環境情報学部
（幹事）
中尾 康二 株式会社ＫＤＤ研究所
（幹事）
竜田 敏男 日本アイ・ビー・エム株式会社
（幹事）
櫻井 幸一 九州大学大学院システム情報科学研究科
（委員）
岩下 直行 日本銀行金融研究所
植村 泰佳 電子商取引安全技術研究組合
奥田 和男 社団法人日本情報システムユーザー協会
小倉 久宜 財団法人金融情報システムセンター
才所 敏明 株式会社東芝
紫合
治 日本電気株式会社
菅
知之 電子商取引推進協議会
宝木 和夫 株式会社日立製作所
竹田 栄作 三菱電機株式会社
田渕 治樹 富士通株式会社
徳永 英二 ＴＯＫ
西川
満 情報処理振興事業協会
5
前川
徹
森田
光
吉田健一郎
（オブザーバ）東井 芳隆
八田
勲
（事務局）
山中 正幸
早稲田大学国際情報通信研究センター
日本電信電話株式会社
財団法人日本品質保証機構
経済産業省商務情報政策局情報セキュリティ政策室
経済産業省産業技術環境局標準課
財団法人日本規格協会
平成 1 2 年度 情報システムのセキュリティ技術の標準化調査研究委員会 WG1 構成表
（主査）
中尾 康二 株式会社ＫＤＤ研究所
（副主査）
大越 丈弘 三菱電機株式会社
（委員）
榎木 千昭 情報システムコントロール協会
橘和 尚道 日本システム監査人協会
工藤 正康 日本アイ・ビーー・エム株式会社
栗田 博司 情報処理振興事業協会
小林 秀樹 社団法人情報サービス産業協会
杉浦
昌 日本電気株式会社
関本
貢 財団法人日本情報処理開発協会
前川
徹 早稲田大学国際情報通信研究センター
山田 朝彦 株式会社東芝
山本
明 沖電気工業株式会社
吉田健一郎 財団法人日本品質保証機構
渡辺 展文 財団法人金融情報システムセンター
（オブザーバ）石井 伸治 経済産業省商務情報政策局情報セキュリティ政策室
平野 芳行 経済産業省産業技術環境局標準課
（事務局）
山中 正幸 財団法人日本規格協会
6
ＴＲ
I T セキュリティマネジメントのガイドライン−
第 3 部：IT セキュリティマネジメントのための手法
TR X 0036-3
(ISO/IEC TR 13335-3)
i
まえがき
この標準情報（TR）は，工業標準化法に基づいて，日本工業標準調査会の審議を経て，経済産業大
臣が公表した標準情報（TR）タイプⅢである。公表に当たっては，1998 年に発行された ISO/IEC TR
13335-3:1998[Information technology―Guidelines for the management of IT Security―Part
3:Technique for the management of IT Security]を基に作成した。
TR X 0036-3 には，次に示す附属書がある。
附属書 A 全社的 IT セキュリティポリシーの目次の例
附属書 B 資産の評価
附属書 C 考えうる脅威のタイプのリスト
附属書 D 一般的なぜい（脆）弱性の事例
附属書 E リスク分析手法のタイプ
TR X 0036 の標準情報群は，次に示す 5 部で構成される。
TR X 0036-1 第 1 部 IT セキュリティの概念及びモデル
TR X 0036-2 第 2 部 IT セキュリティのマネジメント及び計画
TR X 0036-3 第 3 部 IT セキュリティマネジメントのための手法
TR X 0036-4 第 4 部 セーフガードの選択（制定予定）
TR X 0036-5 第 5 部 ネットワークセキュリティのマネジメントガイダンス（制定予定）
ii
目次
1. 適用範囲
2. 参考資料
3. 定義
4. 構造
5. 目的
6. IT セキュリティマネジメントのための手法
7. IT セキュリティの目標，戦略及びポリシー
7.1 IT セキュリティの目標及び戦略
7.2 全社的 IT セキュリティポリシー
8.企業のリスク分析戦略の選択肢
8.1 ベースラインアプローチ
8.2 非形式的アプローチ
8.3 詳細リスク分析
8.4 組合せアプローチ
9. 組合せアプローチ
9.1 上位レベルリスク分析（初期に実施する概要レベルの分析）
9.2 ベースラインアプローチ
9.3 詳細リスク分析
9.3.1 レビュー対象の確定
9.3.2 資産の特定
9.3.3 資産の評価，及び資産間依存関係の確定
9.3.4 脅威の評価
9.3.5 ぜい（脆）弱性の評価
9.3.6 既存及び計画中のセーフガードの特定
9.3.7 リスクの評価
9.4.セーフガードの選択
9.4.1.セーフガードの特定
9.4.2 IT セキュリティアーキテクチャ
9.4.3 制約事項の特定及びレビュー
9.5 リスクの容認
9.6 IT システムのセキュリティポリシー
9.7 IT セキュリティ計画
10. IT セキュリティ計画の実施
10.1 セーフガードの導入
10.2 セキュリティ意識の向上
10.2.1 必要性の分析
10.2.2 プログラムの周知
10.2.3 セキュリティ意識向上プログラムのモニタリング
10.3 セキュリティの訓練
10.4 IT システムの承認
11. フォローアップ
11.1 保守
11.2 セキュリティ遵守状況のチェック
解説
iii
11.3.変更管理
11.4.モニタリング
11.5.事件／事故への対応
12. まとめ
附属書 A 全社的 IT セキュリティポリシーの目次の例
附属書 B 資産の評価
附属書 C 考えうる脅威のタイプのリスト
附属書 D 一般的なぜい（脆）弱性の事例
附属書 E リスク分析手法のタイプ
iv
序文
この標準情報（TR）群の目的は，IT セキュリティをマネジメントの観点から捉えてガイダンス
することであり，解決策を提供することではない。組織のなかで IT セキュリティに対する責任が
ある人々は，この標準情報（TR）群が取り上げている内容を，それぞれに固有のニーズにあわせ
て応用できる能力があることが望ましい。この標準情報（TR）群特有の目標を，次に示す。
― ITセキュリティマネジメントに関連した概念を定義して説明すること。
― ITセキュリティマネジメントと，ITマネジメント全般との関係を明らかにすること。
― IT セキュリティについて説明するときに利用できる，いくつかのモデルを提示すること。
― IT セキュリティマネジメントに関して，一般的なガイダンスを行うこと。
この標準情報（TR）群は，5 つの部によって構成されている。第 1 部では，IT セキュリティマネ
ジメントの説明にあたって用いる，基本概念及びモデルについて概説する。この内容は，IT セキ
ュリティに対して責任がある経営管理者及びその組織のセキュリティプログラム全般に対して責
任がある人々のために役に立つものである。
第 2 部は，マネジメント及び計画の側面を取り上げている。この内容は，次のような，組織の IT
システムと関連する責任を負っている運営管理者に関係するものである。
― IT システムの設計・導入・試験・調達・運用に関して監督責任を負う IT 運営管理者
― IT システムの利用を意味あるものとする諸活動について責任を負う管理者
第 3 部では，プロジェクトの計画・設計・導入・試験・取得・運用といったライフサイクルの過
程で，管理的な業務に関連するセキュリティへの対処方法を説明する。
第４部では，セーフガードの選択についてガイダンスを行うが，ベースラインモデルと管理策と
を利用することがセーフガード選択にどう役立つかについても述べる。また，これらを利用する
ことが第３部で説明したセキュリティへの対処方法をどう補足することなのか，また，セーフガ
ードの選択のために，評価手法をどう追加して使うかについても説明する。
第５部は，IT システムを外部ネットワークに接続する組織に対するガイダンスである。このガイ
ダンスでは，外部との接続及びそれから得られるサービスを保護するためのセーフガードの選択
及びその使用について，並びに外部と接続するので IT システムに追加しなくてはならないセーフ
ガードについても取り上げている。
なお，この標準情報（TR）で点線の下線を施してある部分は，原標準情報（TR13335-3）にない事項で
ある。
参考 第５部の原標準情報（TR）ISO/IEC TR 13335―5，Guidelines for the management of IT
Security―Part5：Management guidance on network security は，現在審議中である。
v
標準情報 （ＴＲ）
IT セ キ ュ リ テ ィ マ ネ ジ メ ン ト の ガ イ ド ラ イ ン −
第 3 部：I T セ キ ュ リ テ ィ マ ネ ジ メ ン ト の た め の 手 法
ＴＲ
X 0036-3: 2001
（ISO/IEC TR 13335 - 3: 1998）
1.
適用範囲
この標準情報（TR）群の第 3 部は，IT セキュリティマネジメントのための手法を提供する。
これらの手法は，この標準情報群の第 1 部及び第 2 部に示されている一般的なガイドラインにも
とづくものである。これらのガイドラインは，IT セキュリティの実施を支援するよう設計されて
いる。第 1 部で紹介されている概念及びモデル，並びに第 2 部で述べた IT セキュリティマネジメ
ント及び計画に関する資料に精通することがこの標準情報群の第 3 部を完全に理解するために重
要である。
備考 この規格の対応国際標準情報を、次に示す。
なお、対応の程度を表す記号は、ISO/IEC Guide21 に基づき、IDT（一致している）、
MOD（修正している）
、NEQ（同等でない）とする。
ISO/IEC TR 13335-3 :1998[Information technology―Guidelines for the
management of IT Security ― Part 3:Techniques for the management of IT
Security]（IDT）
2. 参考資料
TR X 0036 −1 ，IT セキュリティマネジメントのガイドライン―第 1 部：IT セキュリティの概念
及びモデル
備 考 ISO /IEC TR 13335 −1 ：1996，Guidelines for the management of IT Security−
Part1:Concepts and models for IT Security が，この標準情報と一致している。
TR X 0036 −2 ，IT セキュリティマネジメントのガイドライン−第 2 部：IT セキュリティのマネ
ジメント及び計画
備考 ISO /IEC TR 13335 −2 ：1997，Guidelines for the management of IT Security−
Part2:Manageing and planning IT Security が，この標準情報と一致している。
3.
定義
この標準情報（TR）群の第３部の目的のために，第 1 部に記載した次の定義を適用する：責任
追跡性，資産，真正性，可用性，ベースライン管理，機密性，データの完全性，影響，完全性，
IT セキュリティ，IT セキュリティポリシー，信頼性，リスク，残存リスク，リスク分析，リスク
管理，セーフガード，システムの完全性，脅威及びぜい（脆）弱性。
4.
構成
この標準情報（TR）群の第 3 部は 12 の項目に分けられている。5.は，この標準情報（TR）群
の第 3 部の目的に関する情報を提供する。6.は，IT セキュリティマネジメントプロセスの概要を
示す。7.は，企業の IT セキュリティポリシーの重要性及びその望ましい内容について考察する。
8.は，
組織がセキュリティの必要性を確認するために使用できる 4 つの異なるアプローチを示す。
9.は，推奨するアプローチを詳細に示し，続いて 10.は，セーフガードの実施について示す。10.
には，セキュリティ意識向上計画及び承認プロセスの詳細な考察が含まれている。11.は，セーフ
ガードの効果的な実施に必要ないくつかのフォローアップ作業について述べる。最後に，12.は，
この標準情報（TR）群の第 3 部の簡単なまとめを示す。
5.
目的
この標準情報（TR）群の第 3 部の目的は，IT セキュリティマネジメントに成功するための手
法を示し，推奨することである。セキュリティの要求事項及びリスクを評価し，適切なセキュリ
ティセーフガード，すなわち正しい IT セキュリティレベルを確立及び維持することを助けるため
に，これらの手法を利用することができる。これらの手法によって得られる結果（適切なセキュ
リティセーフガード）は，現実の組織及び環境で要求される追加セーフガードによってさらに補
強されなければならない可能性がある。この標準情報（TR）群の第 3 部は，組織内の人々で，IT
1
セキュリティマネジメント及び／又は実施に責任を有する全ての人々に役立つ。
6.
IT セキュリティマネジメントのための手法
IT セキュリティマネジメントの過程は，第 1 部及び第 2 部に示された原則にもとづいている。特
定の部門と同様に組織全体にも適用できる。図 1 に，この過程における主要段階及びこの過程の
結果がどのようにしてそのさまざまな部分にフィードバックされるかを示す。必要ならば，1 つ
の段階内又は 1 個以上の段階が完了した後，フィードバックのループを確立してよい。次に示す
図１は，第 2 部の図１を改訂し，この標準情報で対象とする要旨を強調したものである。
ITセキュリティの目標，戦略及びポリシー
ITセキュリティの目標及び戦略
全社的ITセキュリティポリシー
企業のリスク分析戦略の選択肢
組合せ
ベースライン 非形式的
詳細
アプローチ アプローチ リスク分析 アプローチ
組合せアプローチ
上位レベルリスク分析
詳細
リスク分析
ベースライン
アプローチ
セーフガードの選択
リスクの容認
ITシステムのセキュリティポリシー
ITセキュリティ計画
ITセキュリティ計画の実施
セーフガード セキュリティ セキュリティ
の訓練
の意識向上
の実施
ITシステムの承認
フォローアップ
セキュリティ
遵守状況の
チェック
モニタリング
保守
事件／事故
の扱い
変更管理
図 1 IT セキュリティマネジメント
2
IT セキュリティマネジメントには，セキュリティのための要求事項，これらの要求事項を満たす
ための計画の確立，この計画の実施，実施されたセキュリティの保守及び管理が含まれる。この
過程は，組織の IT セキュリティの目標及び戦略の確立，並びに企業の IT セキュリティポリシー
を策定することにより開始される。
IT セキュリティマネジメント過程の重要部分は，リスクの評価であり，どのようにすればリスク
を受け入れられるレベルまで下げることができるかということである。組織及び環境も考慮した
事業の目標，および各 IT システムの特有の要求及びリスクなどを考慮に入れなくてはならない。
IT のシステム及びサービスのセキュリティ要求事項の評価をしてから，企業のリスク分析戦略を
選択することを推奨する。主な戦略の選択肢を 8.で詳細に示す。推奨する選択肢は，リスクの高
いシステムを確認するために全ての IT システムについて上位レベルのリスク分析を行う。次いで，
これらのシステムの詳細なリスク分析を行ない，一方，それ以外のシステムにベースライン手法
を適用する。高いリスクのシステムについては，資産，脅威及びぜい弱性を詳細に検討すること
により，評価されたリスクに見合った効果的なセーフガードの選択を容易にする詳細なリスク分
析となる。この選択肢を用いることによって，リスクマネジメント過程を，リスク又はニーズの
大きいところに集中させることができ，費用効果及び時間効果のより高い全体計画を，立てるこ
とができる。
リスク評価に続いて，各 IT システムに対するリスクを容認可能なレベルにまで低下させるために，
適用したセーフガードの確認を行なう。これらのセーフガードは，IT セキュリティ計画の概要と
おりに実施される。意識向上および訓練プログラムで実施を支援しなければならず，これはセー
フガードの効果を上げるために重要である。
さらに，IT セキュリティマネジメントには，様々なフォローアップ業務を取り扱う進行中の作
業が含まれ，これによって，初期の結果および決定に変更が加えられる。フォローアップ業務と
しては，保守，セキュリティ遵守チェック，変更管理，監視，および偶発事故への対応を含む。
7.
IT セキュリティの目標，戦略及びポリシー
組織の IT セキュリティの目標を確立した上で，企業の IT セキュリティポリシーを策定するため
の基盤を形成するために，IT セキュリティ戦略を策定しなければならない。企業の IT セキュリ
ティポリシーの策定は，リスク管理過程の結果が適切及び効果的であることを確実にするために，
非常に重要である。組織全体にわたる管理支援には，ポリシーの策定及び効果的な実施が必要で
ある。企業の IT セキュリティポリシーは，企業の目標及び組織の特定の状況を考慮したものでな
くてはならない。これは企業のセキュリティポリシー及び企業の事業方針と一致したものでなけ
ればならない。このような一致により，企業の IT セキュリティポリシーは，資源の最も効果的な
利用を達成するのに役立ち，様々なシステム環境にわたって，セキュリティへの一貫した手法を
確実にする。
各 IT システムまたは一部の IT システムについては，別途の特定のセキュリティポリシーを策
定することが必要な場合もある。このポリシーは，リスク分析または基本的な結果にもとづくべ
きであり，全社的 IT セキュリティポリシーと一致すべきである。それゆえ，関連するシステムに
ついてのセキュリティ推奨事項を考慮に入れるべきである。
3
7.1
IT セキュリティの目標及び戦略
IT セキュリティマネジメント過程における最初の第 1 歩として，組織にとって受け入れられる
リスクの一般レベルとはどのようなものかという問題を考慮するのが望ましい。受け入れられる
リスクの正しいレベル，すなわちセキュリティの適切なレベルは，セキュリティマネジメントの
成功の鍵である。必要なセキュリティの一般的なレベルは，組織に必要な IT セキュリティ対策方
針によって決定される。このようなセキュリティ対策方針を評価するためには，資産と，その資
産が組織にとってどれほどの価値のあるものかを考えるとよい。これは，主として，組織の事業
行為を支援するために IT が有する重要性によって決定される。IT 自体のコストは，その価値の
ほんの小さい部分を占めるに過ぎない。組織の事業のうちどの程度が IT に依存しているかを評価
するために，考えられる質問事項を次に示す。
― IT の支援なしでは実施できない事業の重要／きわめて重要な部分は何か。
― IT の援助があってはじめて可能な業務は何か。
― IT によって処理された情報の正確さ，完全性又は可用性に依存している重要な決定は何か。
また，この情報はどのくらい最新か。
― 保護しなくてはならない処理済みの機密情報は何か。
― 組織にとって望ましくないセキュリティ上の事件／事故と関係するものは何か。
これらの質問事項に答えることによって，組織のセキュリティ対策方針の評価の援助となる。た
とえば，事業の重要又はきわめて重要な部分が正確又は最新の情報に依存している場合，この組
織のセキュリティ対策方針のうち 1 つは，
情報が IT システムで処理されるときの情報の完全性及
び適時性の確保でもよい。また，重要な事業目標及びセキュリティに関連する事業目標を，セキ
ュリティ目標を評価するときに考えるとよい。
これらの目標を達成するための戦略は，セキュリティ対策方針に応じて合意されるのがよい。選
ばれた戦略は，保護するべき資産の価値に合ったものであるとよい。たとえば，上記の質問事項
のうち 1 個以上に対する回答が“はい”であれば，その組織のセキュリティの必要性が高いと思
われ，このような必要性を満たすための十分な努力を含む戦略を選択することが望ましい。
IT セキュリティの戦略では，
組織がその IT セキュリティ対策方針をどのように達成するかを，
一般的な用語で説明する。このような戦略が対象とする課題は，そのような目標の数，型及び重
要度によって決まることになり，通常は，組織が組織全体から参照される重要性を検討する課題
となる。このような課題は，現実にはその性格がきわめて特定されたものであるか，またはきわ
めて広義なものとなる可能性がある。
前者の例として，組織が，その事業の性格から，このシステムは全て上位レベルの可用性を維持
するべきであるという重要な IT セキュリティ対策方針を掲げることもあろう。この場合，組織全
体にウイルス駆除ソフトウェアをインストールすることによって，ウイルスの蔓延を最小限に抑
制（又は，選択したサイトに命じて全ソフトウェアが通らなくてはならないところをウイルスチ
ェック）することが，戦略的な課題となる。
後者の例としては，一般のレベルで，組織が IT サービスの販売を事業としているため，そのシス
テムのセキュリティを予定客先に証明する IT セキュリティ対策方針もあろう。この場合，システ
ムが全て，承認された第三者によってセキュリティがなされているという検証がなされるべきで
あるというのが戦略上の課題となることもあろう。
その他，特定の目標又はその組合せから，IT セキュリティの戦略について取り上げられる可能
性のある課題としては，次のようなものを含む。
― 組織全体として採用するリスク分析の戦略及び方法。
― 各システムについての IT システムセキュリティポリシーの必要性。
― 各システムについてのセキュリティ操作手順の必要性。
― 組織全体としての情報の秘密度別の分類制度。
4
― 他の組織との接続前の遵守，およびチェックするべき接続のセキュリティ条件の必要性。
― 普遍的に使用される偶発事故への対応制度。
セキュリティ戦略とその構成をなす課題は，いったん決定すれば，企業の IT セキュリティポリシ
ーに含めてよい。
7.2
全社的 IT セキュリティポリシー
全社的 IT セキュリティポリシーは，合意された全社的 IT セキュリティ対策方針及び戦略にも
とづいて策定すべきである。企業の IT セキュリティポリシーは，企業の事業，セキュリティ及び
IT についてのポリシー，並びにセキュリティ関連の法規制に矛盾しないよう確立し，維持しなく
てはならない。
7.1 に反映されているように，全社的 IT セキュリティポリシーに影響を及ぼす重要な事実は，
組織が自社で使用している IT にどのくらい依存しているかということである。IT の使用が重要
となり，組織の IT 依存度が高くなるほど，事業目標を満足するために，いっそうセキュリティが
必要とされる。全社的 IT セキュリティポリシーを立案する場合，文化，環境及び組織の諸特性を
念頭に置くべきである。何故なら，それらの特性がセキュリティへのアプローチ，たとえば一部
のセーフガードなどに影響を及ぼし，ある環境では容易に受け入れられるものでも，別の環境で
は全く受け入れられないような場合があるからである。
全社的 IT セキュリティポリシーに記述されるセキュリティ関連業務は，次のような事項にもと
づくことができる。すなわち，組織の目標及び戦略，以前のセキュリティのリスク分析及び管理
レビューの結果，実施されたセーフガード，その日その日の使用における IT セキュリティのモニ
ター及びレビュー，並びにセキュリティ関連の事故報告書などのセキュリティ遵守状況のチェッ
クなど，フォローアップ処置の結果とする。これらの業務中に検知された重大な脅威及びぜい弱
性は，それらのセキュリティ上の問題点を取り扱うための組織の総合的な手法を定めた全社的 IT
セキュリティポリシーに沿って，記述されなくてはならない。詳細な処置については，様々な IT
システムセキュリティポリシー又はその他の支援文書，たとえば，セキュリティ操作手順などで
示す。
全社的 IT セキュリティポリシーの策定にあたっては，次に示す職務の代表者が参加するとよい。
―
―
―
―
―
―
―
監査
財務
情報システム（技術者およびユーザ）
ユーティリティ／施設（すなわち，建物の構造及び設備，電力，空調に責任を有する人）
要員
セキュリティ
上級経営者
セキュリティ対策方針及びそれらの目標を達成するために組織が採用した戦略にしたがって，全
社的 IT セキュリティポリシーの詳細な適用レベルを選択する。全社的 IT セキュリティポリシー
には，最低限次の事項を記載するとよい。
― その範囲及び目的。
― 法規制上の義務に関するセキュリティ対策方針及び事業の目標。
― 機密性，完全性，可用性，責任追跡性，真正性及び情報の信頼性に関する IT セキュリティの
要求事項。
― 組織と個人の責任及び権限を網羅する情報セキュリティの管理。
― 組織が採用したリスクマネジメントアプローチ
5
― セーフガードの実施の優先度を決定するための手段。
― 管理で求められるセキュリティと残留リスクの一般的なレベル。
― アクセス制御のための一般的な規則（建物，部屋，システム及び情報への物理的アクセス制御
と同様な論理的なアクセス制御）
。
― 組織内部のセキュリティ意識向上及び訓練のアプローチ。
― セキュリティのチェックと保守のための明確な手順。
― 一般スタッフのセキュリティ事項。
― ポリシーを関連要員全員に伝達するための手段。
― ポリシーをレビューするべき状況。
― ポリシー変更の管理方法。
もっと詳細な全社的 IT セキュリティポリシーが必要な場合，次の事項も考慮するとよい。
―
―
―
―
組織全体に対するセキュリティモデル及び手順。
標準の使用。
セーフガードの実施のための手順。
フォローアップ業務へのアプローチ，たとえば，
― セキュリティ遵守状況のチェック
― セーフガードの監視
― 事件／事故に関連したセキュリティの対応
― IT システム使用のモニタリング
― 外部セキュリティコンサルタントとの契約状況。
企業の IT セキュリティポリシーの内容の例を附属書 A に示す。
この章で前述したように，以前のリスク分析及び管理レビュー，セキュリティ遵守状況のチェッ
クおよびセキュリティ事故の結果は，全社的 IT セキュリティポリシーに影響を及ぼすことがある。
また，このために，以前に定義した戦略又はポリシーのレビュー又は再定義が必要とされる場合
もある。
全てのセキュリティ関連措置のために適切な支援を確保するために，全社的 IT セキュリティポリ
シーは，上級経営者の承認を受けなければならない。
全社的 IT セキュリティポリシーにもとづいて，指示書を作成するとよい。これを管理及び従業員
全員に義務化する。これには，組織内でのセキュリティの責任を確認した文書にスタッフ各人の
署名が必要な場合もある。さらに，セキュリティ意識向上及び訓練のための計画を，周知させる
ために策定し，実施しなければならない。
全社的 IT セキュリティポリシーに責任を持ち，組織の要求事項及び実際の状況をポリシーに反映
することができる人物が選ばれなくてはならない。この責任者は，全社的 IT セキュリティ役員と
いうことになり，特にフォローアップ業務にも責任を負う。これには，セキュリティ遵守状況の
チェック，偶発事故及びセキュリティの弱点への処置，並びにこれらの処置の結果にしたがって
必要となる場合のある全社的 IT セキュリティポリシーへの変更も含まれる。
6
8.
企業のリスク分析戦略の選択肢
備考 この標準情報（TR）群の第 3 部が，完結し，第 2 部とは独立して読めるよう，8.は，第 2
部 の 10.と同じ課題を扱っている。
組織は，リスク分析業務を開始する前に，この分析に相応しい戦略を持つべきであり，その内
容（方法，手法等）を，全社的 IT セキュリティポリシーに文書化するとよい。リスク分析方法の
選択のための手段と基準は，組織として合意されたものでなければならない。リスク分析戦略は，
選択された手法が環境に適していること及びセキュリティの効果が，実際に必要とする部分に集
中することが望ましい。次に示す選択肢は，4 つの異なるリスク分析アプローチを述べたもので
ある。これら選択肢の基本的な違いは，リスク分析の深さである。全ての IT システムに詳細なリ
スク分析を行なうことは，一般にコストがかかりすぎ，重大なリスクに対して，外面的な注意だ
けでは効果的ではないので，これらの選択肢間のバランスが必要である。
何もしない可能性と，知られていない重大及び過酷な多数のリスクにさらされる事態を受け入
れる可能性は別として，企業のリスク分析戦略のためには，次の 4 つの基本的な選択肢がある。
― システムが直面するリスクを問わず，全ての IT システムに同じベースラインアプローチを用
い，セキュリティのレベルが常に適切だとは限らないということを容認する。
― リスク分析を行なうために非形式的アプローチを用い，高いリスクに曝されていると認識され
ている IT システムに注力する。
― 全ての IT システムに形式的アプローチを用いて詳細なリスク分析を行なう。
― 高いリスクに曝されている IT システムと，事業にとって危機的なシステムを確認するために，
はじめに“上位レベル”のリスク分析を行ない，続いて，これらのシステムについて詳細な
リスク分析を行ない，その他全てのシステムにベースラインセキュリティを適用する。
セキュリティのリスクを対象とするこれらさまざまな可能性を次に示し，次いで，好ましい手法
について推奨する。
組織がセキュリティについて何も行なわないと決定した場合，または，セーフガードの実施を
延期するよう決定した場合，経営陣はこの決定が持つ意味に気が付かなければならない。この決
定には，時間，費用，スタッフ又はその他の資源を必要としないが，この決定には多くの不利な
点がある。組織が自社の IT システムの危機的でないことに自信があるなら話は別だが，重大な結
果になるかもしれない。組織は法規制に従っていない可能性があり，セキュリティ違反があれば，
組織の評判が傷つく可能性もあり，何ら予防措置が講じられていなかったことが明らかとなって
しまう。組織が IT セキュリティにほとんど関心を持っていない場合又は事業上重要なシステムを
全く持っていない場合，適した戦略かもしれない。しかし，組織は，現実の状況が良いのか悪い
のかを知らないという立場に取り残され，ほとんどの組織にとって，これは良い解決策になりそ
うもない。
8.1 ベースラインアプローチ
第 1 の選択肢については，組織は標準セーフガードを選ぶことによって，全ての IT システムに対
してベースラインセキュリティを適用することができる。ベースライン文書及び行動規範には，
さまざまな標準セーフガードが示されている。この手法のさらに詳細な説明を9.2 に示す。
この手法には次のような多数の長所がある。
― 各セーフガード，リスクの分析及び管理には最低限の資源だけで実施できる。したがって，セ
キュリティセーフガードの選択に費やされる時間及び労力も少ない。
― 組織のシステムの多くが共通の環境で運用されており，セキュリティの必要性に共通点がある
とされる場合，大した労力を要せずに多くのシステムに同じ又は類似のベースラインセーフ
ガードを採用できるので，ベースラインセーフガードは，費用効率が良い解決策を提供する。
7
この選択肢の短所は次のとおり。
― ベースラインレベルが高すぎる場合，IT システムの一部には，過剰なセキュリティレベルに
なる。
― レベルが低すぎる場合，一部の IT システムではセキュリティが不足することになり，危険に
さらされるレベルが高くなる。
― セキュリティ関連の変更管理が難しくなる。たとえば，システムのグレードアップが行なわれ
る場合，もとのベースラインセーフガードで十分かどうかを評価するのが困難かもしれない。
組織の IT システム全部が，低レベルのセキュリティ要求事項しか持たない場合，最も費用効率の
高い手法となる可能性がある。この場合，大多数の IT システムが必要とする程度の保護を反映す
るようにベースラインを選択しなければならない。ほとんどの組織は，重要なデータを保護し，
法規制，例えばデータ保護法令を遵守するために，常に何らかの最低限度の標準にしたがうこと
が必要となる。しかし，組織のシステムの業務上の重要性，規模及び複雑さにおいて変動がある
場合，全てのシステムに共通の標準を適用するのは論理的でもなく，費用効率も良くない。
8.2
非形式的アプローチ
この選択肢は，非形式的で実用的なリスク分析を行なう。非形式的アプローチとは，構造化され
た方法ではなく，各個人の知識及び経験を利用することを基本とする。
この選択肢の長所は次のとおり。
― たいていは，多量の資源や時間を必要としない。この非形式的な分析を行なうのに，何ら追加
の技能を学ぶ必要はなく，詳細なリスク分析よりも迅速に行なわれる。
しかし，次のような多くの短所がある。
― 何らかの形式的なアプローチ又は包括的なチェックリストがない場合，いくつか重要な細目を
行わない可能性が増加する。
― このようにして評価されたリスクに対するセーフガードを実施することの正当化は難しい。
― リスク分析にほとんど経験のない人々には，この作業を支援する手本がほとんどない。
― 過去におけるアプローチの一部は，ぜい弱性をもとに実施されてきた。すなわち，このような
ぜい弱性を悪用する脅威があるか否かは考慮せずに，すなわち，セーフガードが現実に必要
か否かは考えずに， 確認されたぜい弱性にもとづいてセキュリティセーフガードが実施され
た。
― 主観性がある程度介入する。レビュー者の特定の偏見が結果に影響を及ぼすことがある。
― 非形式的リスク分析を行なった者が組織を退職した場合，さまざまな問題が生じる可能性があ
る。
このような短所があることから，このアプローチは，多くの組織にとってリスク分析への効果的
な手法ではない。
8.3
詳細リスク分析
第 3 の選択肢は，組織内の全ての IT システムについて詳細リスク分析を行なう。詳細リスク分析
には，資産の綿密な確認及び評価，それらの資産に対する脅威の評価，並びにぜい弱性の評価を
含む。これらの業務の結果を，次いでリスクの評価に用い，そこから正当なセキュリティセーフ
ガードを確認する。このアプローチについては9.3 で詳細に示す。
この手法を用いた場合の長所は，次のとおりである。
― 全てのシステムについて適切なセーフガードが特定される可能性がある。
― 詳細分析の結果をセキュリティの変更管理に利用することができる。
8
この選択肢の短所は次のとおりである。
結果を得るためには，かなりの時間及び労力，並びに専門知識を必要とする。
全ての IT システムが同じ詳細さで考察され，多くの時間をかけなければ分析が完了しないため，
セキュリティが必要な重要システムへの対応が手遅れになる可能性がある。
したがって，全ての IT システムについて詳細リスク分析を使用することは勧められない。このア
プローチを選択する場合，その実施には多くの方法がある。
― この TR に示された基準に合った標準アプローチを使用する。
（たとえば，9.3 に示されたアプ
ローチ。
）
― 組織に適したさまざまな方法で標準アプローチを使用する。
“リスクモデリング技法”
（9.3 に
示す。
）の使用も，有利となる組織がある。
8.4
組合せアプローチ
IT システムの事業上の価値及び IT が直面している危険なリスクに重点を置く場合，第 4 の選択
肢は，最初に，全ての IT システムについて初期の上位レベルのリスク分析を行なう。組織の事業
にとって重要及び／又は高リスクにさらされていると確認された IT システムについては，優先的
に詳細リスク分析を行ってよい。その他の全ての IT システムについては，ベースラインアプロー
チを選択してよい。この選択肢は，ある意味では，8.1 及び 8.3 示した選択肢の最も良い点を組み
合わせたものであり，セーフガードの確認に費やす時間及び労力を最低限におさえるようつりあ
いをとり，しかも高いリスクのあるシステムが適切に保護されることを確実にする。
この選択肢の追加の長所は次のとおり。
― 初期の迅速及び単純なアプローチを組み合せることで，リスク分析計画が受け入れられ易くな
る。
― 組織のセキュリティ計画の戦略図をすみやかに作成することができる。すなわち，良い計画立
案の補助としてこのアプローチを実施する。
― 資源と資金を，最も有利な部分に適用することができ，保護の必要性が最も大きいと思われる
システムが最初に対象となる。
― フォローアップ措置の成功の可能性も大きくなる。
唯一の潜在的な短所は次のとおり。
― 初期リスク分析は，上位レベルであり，あまり正確ではない可能性があるため，システムの中
には，詳細リスク分析が必要であると認められないこともある。しかし，これらのシステム
はベースラインセキュリティで網羅されている。また，これらのシステムは，ベースライン
アプローチ以上のものが必要か否かをチェックするために，必要に応じていつでも検討され
る。
ベースラインアプローチと組み合わせ及び該当する場合は詳細リスク分析と組み合わせて，上位
レベルのリスク分析アプローチを採用すると，大多数の組織に対して，最も効果的な方法を提供
する。このアプローチを推奨し，9.でさらに詳細に示す。
9
9. 組合せアプローチ
ここでは，これまでの項で推奨された組合せリスク分析戦略を実施するためのガイダンスを提供
する。
9.1 上位レベルリスク分析（初期に実施する概要レベルの分析）
まず，各 IT システムについて，どのアプローチ（ベースライン又は詳細リスク分析）が適切であ
るかを確定するために，上位レベルリスク分析を行うことが必要である。この上位レベルリスク
分析は，IT システム及び扱われる情報のビジネスの価値，並びに組織のビジネスという観点から
見たリスクを考慮する。どの IT システムにどのアプローチが適当であるかを決定するための入力
は，次の事項を考慮することによって得られる：
― IT システムを使って達成するべきビジネスの目的，
― 組織のビジネスが IT システムに依存している度合い，すなわち，組織が自らの生き残り，
又はビジネスの効果的な遂行のためにきわめて重要と考えている機能が，このシステム，又
はこのシステムで処理された情報の機密性，完全性，可用性，責任追跡性，真正性，及び信
頼性に依存しているか否かの程度，
― システムの開発，保守又は変更という点での，この IT システムへの投資レベル，及び
― 組織が直接価値を認めている IT システムの資産。
これらの項目を評価すれば，決定は一般的に容易である。システムの目的が組織のビジネス方針
に対して重要であるか，システムの変更の費用が高いか，又は資産の価値が高いリスクにさらさ
れている場合，そのシステムについては詳細なリスク分析が必要である。これらの条件のいずれ
か一つでも，詳細なリスク分析を行う十分な理由となる。
適用される一般的なルールは，次のようなものである。IT システムセキュリティの欠如の結果，
組織，そのビジネスプロセス，又はその資産に重大な損傷若しくは損害が生じる恐れがある場合
は，潜在的リスクを特定するために詳細リスク分析（9.3 ）が必要である。その他のすべての場合
は，ベースラインアプローチ（9.2 ）の適用によって適切な保護が提供される。
9.2
ベースラインアプローチ
ベースライン保護の目的は，組織におけるすべての又は幾つかの IT システムを保護するためのセ
ーフガードの最小セットの組合せを確定することである。このアプローチを使用することによっ
て，ベースライン保護を組織全体に適用することが可能となり，上記に示されたように，リスク
の高い IT システム又はビジネスにとって重要なシステムを保護するために，詳細リスク分析を追
加して使用することができる。ベースラインアプローチを使用することによって，組織がリスク
分析レビュー（8.1 ）の実行に要する投資額を抑制する。
最も一般的な脅威から IT システムを保護するためのセーフガードの組合せを提示するセーフガ
ードカタログを使用することによって，適切なベースライン保護を達成することができる。ベー
スラインセキュリティのレベルは，組織の要求に従って調節することができる。脅威，ぜい（脆）
弱性及びリスクに対する詳細な評価は必要ない。ベースライン保護を適用する場合に行なわなけ
ればならないことは，対象となった IT システムに関連のある部分をセーフガードカタログから選
択することである。既に実施されているセーフガードを特定した後，ベースラインカタログに掲
げられているセーフガードとの比較が行なわれる。まだ適切な箇所で実施されていないが，適用
可能なものは実施することが望ましい。
ベースラインカタログは，使用するべきセーフガードを詳細に指定することができ，又は，検討
中であるシステムに適したセーフガードを用いてセキュリティ要件の集合に対処するよう示唆す
ることもできる。いずれのアプローチにも利点がある。両方の種類のカタログは，標準情報(TR)
群の第 4 部の附属書で見ることができる。ベースラインアプローチの目的の一つは，組織全体に
わたってセキュリティセーフガードに一貫性を持たせることであり，これは両方のアプローチに
よって達成することができる。
10
一連のベースラインセーフガードを示した文書の幾つかは，既に刊行されている。また，同じ業
界内の企業間で，類似した環境が認められることがある。基本的な要求を検討した上で，多くの
異なった組織がベースラインセーフガードカタログを使用することも可能である。例えば，ベー
スラインセーフガードのカタログは，次のところから入手することができる：
― 国際及び国内の標準化機構，
― 工業規格又は勧告，又は
― できれば類似したビジネスの目的，規模を有する他社。
もちろん，組織もまた，特有の環境及びビジネスの目的に確立されたふさわしい，それ自身のベ
ースラインを生成してもよい。
9.3
詳細リスク分析
8.3 で示したように，IT システムの詳細リスク分析には，関連するリスクの特定，及びその大き
さの評価が含まれる。すべてのシステムについて上位レベルのレビューを行ない，8.4 で推奨され
たように，高いリスク又は重要なシステムについてだけ詳細リスク分析のレビューを行えば，詳
細リスク分析の要求を，時間と資金に不要な投資を行なわずに決定することができる。
リスク分析は，好ましくない事象によるビジネスへの潜在的な悪影響及びそれらの発生する可能
性を特定することによって行なわれる。好ましくない事象は，ビジネス，人又はその他の組織の
価値あるエンティティに悪影響を及ぼす可能性がある。好ましくない事象による悪影響は，リス
クにおける資産価値に対して起こりうる損害の複合物である。その発生する可能性は，潜在的な
攻撃者にとって，その資産がどれほど魅力的なものであるか，脅威が発生する可能性，及びぜい
（脆）弱性につけ込む場合の容易さなどに依存する。リスク分析の結果から，特定されたリスク
を許容できるレベルにまで低減させるのに使用できるセーフガードの特定と選択を行うことがで
きる。
詳細リスク分析には，図 2 に示したそれぞれのステップおける十分なレビューが含まれる。これ
によって，正当化されたセーフガードをリスクマネジメントのプロセスの一部として選択するこ
とができる。これらのセーフガードの要件は，IT システムのセキュリティポリシー及び関連 IT
セキュリティ計画の中で文書化される。システムのセキュリティ要件に影響を及ぼす可能性があ
る多くの事件／事故及び外部の影響のため，リスク分析の全部又は一部を再考することが必要で
ある。このような影響事象としては，最近行われたシステムへの重大な変更，変更の予定，又は
取扱う必要のある事件／事故の結果がある。
リスク分析の実施のためにはさまざまな方法があり，チェックリストに基づくアプローチから，
構造化分析に基づく手法まである。自動化（コンピュータ支援）又は手動による製品を使用する
ことができる。組織がどのような方法又は製品を利用するかとは関係なく，少なくとも，以降の
各項で特定される話題に取り組むことが望ましい。また，使用する方法は，組織の文化に適した
ものであることが大切である。
システムに対する最初の詳細なリスク分析のレビューが完了したら，レビューの結果 ― 資産と
その価値，脅威，ぜい（脆）弱性とリスクのレベル，及び特定したセーフガード ― を，例えば
データベースの中に格納するのが望ましい。言うまでもなく，ソフトウェア支援ツールを用いる
方法は，この作業をはるかに容易にする。この方法は，モデルと呼ばれることもあり，構成，処
理される情報の種類，脅威のシナリオなど，経時的な変化の発生時などに利用して大きな効果を
あげることができる。必要なセーフガードに及ぼす効果を確かめるために必要な入力は変更だけ
である。さらに，そのようなモデルは，例えば新しいシステムの開発中，同様に性質が類似した
他のシステムに対して使用する際に，さまざまなオプションを検討のために迅速に使用できる。
11
レビュー対象の確定( 9.3.1)
リスク分析
資産の評価，
及び資産間の依
存性の確定
資産の特定(9.3.2)
脅威の評価
ぜい（脆）弱性
の評価
既存及び計画
中のセーフガ
ードの特定
(9.3.3∼9.3.6)
リスクの評価
(9.3.7)
制約事項の特
定及びレビュー
( 9.4.3)
セーフガードの選択(9.4)
リスクの容認
(9.5)
No
Yes
ITシステムのセキュリティ
ポリシー(9.6)
ITセキュリティ計画(9.7)
図2
9.3.1
詳細リスク分析を含むリスクマネジメント
レビュー対象の確定
図 2 に示すように，資産の特定と評価のための入力物の収集に先立って，レビューの対象を定義
することが望ましい。この段階で慎重に対象を定義しておけば，不必要な作業を避けて，リスク
分析の質を向上させることができる。レビュー対象の説明は，検討中の IT システムについてのリ
スク分析のレビューを行う場合，次のいずれかを考慮しなければならないかを明確に定義するこ
とが望ましい。
―
―
―
―
IT 資産（例えば，ハードウェア，ソフトウェア，情報）
，
人員（例えば，スタッフ，下請業者，その他外部の要員など）
，
環境（例えば，建物，設備）
，及び
業務（作業）
12
9.3.2 資産の特定
資産とは，組織が直接価値を認めているものであって，組織がその保護を必要としているシステ
ム全体の構成要素又はその一部である。資産を特定するためには，IT システムがハードウェアと
ソフトウェア以外のものからも構成されているということを念頭に置くことが望ましい。例えば，
資産の種類は次のものがある：
― 情報／データ（例えば，支払いの詳細を含んだファイル，製品情報など）
，
― ハードウェア（例えば，コンピュータ，プリンタなど）
，
― アプリケーションを含むソフトウェア（ 例えば，テキスト処理プログラム，特別の目
的のために開発されたプログラムなど）
，
― 通信設備（例えば，電話，銅線，ファイバーなど）
，
― ファームウェア（例えば，フロッピーディスク，CD-ROM，PROM など）
，
― 文書（例えば，契約書など）
，
― 資金（例えば，ATM など）
，
― 製造物，
― サービス（例えば，情報サービス，計算資源など）
，
― サービスの信頼と信用（例えば，支払いサービス）
，
― 環境設備，
― 要員，
― 組織のイメージ。
確定したレビュー対象（9.3.1 参照）のすべての資産は，特定されなければならない。これとは逆
に，何らかの理由により，レビュー対象から除外するべき資産は，忘れたり見過ごしたりしない
ようにその他のレビューに割り当てる必要がある。
9.3.3 資産の評価，及び資産間依存関係の確定
レビュー中の IT システムにおけるすべての資産を列挙したリストを作成することによって資産
を特定するという目的を達成した後，これらの資産に価値を割り当てることが望ましい。これら
の価値は，組織のビジネスにとっての資産の重要度を表わしたものである。これは，情報並びに
他の IT システム資産の開示，修正，非可用性及び／又は破壊からビジネスへの潜在的な悪影響の
ようなセキュリティに関する利害関係を表現することができる。このように，組織のビジネス上
のニーズに基づく資産の特定と評価は，リスクの判定における重要な要因となる。
資産の評価のための入力物は，資産の所有者及びユーザが提供するのが望ましい。リスク分析を
行う人が資産のリストを作成する。これらの資産のそれぞれについて価値を特定するためには，
事業計画，財務，情報システム及びその他の関連業務部門からの支援を求めるのが望ましい。与
えられた価値を，その資産の入手並びに保守に要する費用，及び，機密性，完全性，可用性，責
任追跡性，真正性並びに信頼性の損失によるビジネスへの潜在的な悪影響に関連づけることが望
ましい。特定された資産はそれぞれ，組織にとって何らかの価値を有することが望ましい。しか
し，すべてについて財務上の価値を確定する直接的な又は容易な方法は無い。また，組織にとっ
ての非財務上の，すなわち質的な点から，重要性の価値又は程度を確定する必要がある。さもな
ければ，保護のレベルの特定が困難となり，組織の資源全体は資産の保護に専念するべきである。
このような評価の尺度の例は，低い，中程度，高いで区別することもでき，さらに詳しくは，次
のものによることもできる：
無視できる ― 低い ― 中程度 ― 高い ― きわめて高い
附属書 B は，可能性のある損害を考慮して，資産に対して価値を割り当てる場合に使用する尺度
として可能性のあるものを，より詳しく示している。どの尺度を用いるかに関係なく，この評価
で考慮するべき事項は，次に示す結果として生じる損害ということになる：
― 立法及び／又は規制に対する違反，
― ビジネスの遂行の悪化，
― 信用の損失／評判に対する否定的な影響，
― 個人情報に関連する機密保持義務の不履行，
― 個人の安全の危機，
13
― 法律の実施への悪影響，
― 取引上の機密保持の違反，
― 公共の秩序に対する違反，
― 財務上の損失，
― ビジネスの崩壊，
― 環境上の安全の危機。
組織は，そのビジネスにとって重要な別の基準の採用を考える必要があるかもしれない。その場
合，附属書 B で用いた基準にこれを追加しなければならない。また，組織は“低い”又は“高い”
というように，損害についての自身の限度を定義しなければならない。例えば，零細企業にとっ
ては致命的となりかねない財務上の損害も，大手企業にとっては“低い”又は“無視できる”と
なることもある。
分析する方法は，量的な評価ばかりでなく，量的な評価が不可能又は非論理的（例えば，生命を
失う可能性，ビジネス上の営業権を損失する可能性など）である場合には，質的な評価もできな
ければならないことを，この段階で強調しておくことが望ましい。使用する評価の尺度について
も説明を加えることが望ましい。
資産と他の資産との間の依存関係も特定することが望ましい。これは，これらの資産の価値に影
響を及ぼす可能性があるからである。例えば，データの機密性は，その処理全体を通じて守られ
ることが望ましい。すなわち，データ処理プログラムのセキュリティニーズを，処理されるデー
タの機密性を示す価値に直接関連づけることが望ましい。また，ビジネスプロセスが，プログラ
ムによって生成される特定のデータの完全性に依存している場合は，このプログラムの入力デー
タは適切な信頼性を有することが望ましい。さらに，情報の完全性は，その格納と処理に用いら
れるハードウェア及びソフトウェアに依存することになる。また，ハードウェアは電源の供給，
及び場合によっては空調に依存することとなる。このように，依存関係に関する情報は，関連す
る脅威，特にぜい（脆）弱性を特定する助けとなる。また，資産の真の価値が（依存関係を通じ
て）資産に与えられ，それによって適切なレベルの保護が確実に行なわれるようにするのにも役
立つ。
他の資産が依存している資産の価値は，次のようにして修正することができる：
― 従属資産（例えば，データなど）の価値が，対象資産（例えば，ソフトウェアなど）
の価値よりも低いか，又は等しければ，その価値はそのままとされる，及び
― 従属資産（例えば，データなど）の価値が大きい場合は，対象資産（例えば，ソフト
ウェアなど）の価値を，次に従って増加させることが望ましい：
― 依存度，及び
― 他の資産の価値。
組織は，ソフトウェアプログラムのコピーや，ほとんどの事務所で使用されている同じ種類の PC
など，2 箇所以上で使用される資産を持っている場合がある。資産の評価を行う場合には，この
事実を考慮することが大切である。一方では，これらのコピー等は見逃され易いので，それらす
べてを特定するよう注意しなければならないし，他方では，可用性の問題を低減するために利用
することも可能である。
このステップの最終的な出力は，開示（機密性の保持）
，修正（完全性の保持）
，非可用性並びに
破棄（可用性の保持）に関する資産及びそれらの価値，及び置き換え費用のリストである。
9.3.4
脅威の評価
脅威は，レビュー中の IT システムとその資産を損傷する可能性を持っている。脅威が発生した場
合は，好ましくない事件／事故の原因となる何らかの手段で IT システムに衝撃を与え，したがっ
て有害な影響を発生させる。脅威は自然に又は人間から発生する場合もあり，偶然である場合も
計画的である場合もあり得る。偶然又は計画的な脅威の原因を特定し，その発生の可能性が評価
14
されることが望ましい。IT システムセキュリティの不履行又は弱体化の可能性があるため，いか
なる関連する脅威も見逃してはならないことがきわめて大切である。
脅威の評価への入力は，組織の保護に対する責任者から入手するのと同様に，資産の所有者又は
ユーザ，人事部のスタッフ，設備計画及び IT の専門家から入手されることが望ましい。法律事務
所及び国内政府当局など，他の組織も，例えば，脅威の統計の提供などによって支援することが
できるかもしれない。一般に起こりうる脅威のリストは，脅威の評価の実施に役立つ。附属書 C
にその例を示す。ただし，どのようなリストでも完全ではあり得ないので，他の脅威カタログ（そ
の組織やビジネスに特有のもの）を参照することも有益な場合がある。脅威は，一般的に次のよ
うな場合に出現する。
― 誤りと省略，
― 詐欺及び窃盗，
― 従業員による妨害行為，
― 物理面の及び基盤面での支援の損失，
― 例えば，なりすましによって行われる悪意のハッキング，
― 悪意のあるコード，及び
― 産業スパイ。
脅威のカタログ又は初期の脅威評価の結果を用いる場合，脅威は刻々変化するものであり，特に
ビジネス環境や IT が変化する場合にはなおさらである。例えば，1990 年代のウイルスは，1980
年代のものよりもはるかに複雑である。ウイルスチェックソフトウェアなどのセーフガードの実
施は，常に，その時のセーフガードに抵抗力を持った新しいウイルスの開発につながることに注
意すべきことが興味深い。
脅威の原因（その脅威を誰がいつ生じさせたか）及び脅威の対象（すなわち，システムの要素の
うち，どれが脅威による影響を受けるか）を特定した上で，脅威が発生する可能性を評価する
（assess）ことが必要である。これには次を考慮に入れることが望ましい：
― 統計などが適用可能であれば，脅威の頻度（経験，統計などに従って，どれ位の頻度
で発生するか）
，
― 計画的な脅威の原因である，将来の攻撃者に対する，動機，認知及び必要とされる能
力，将来の攻撃者が利用できる資源，及び IT システム資産の魅力とぜい（脆）弱性の
認知，及び
― 偶然の脅威の原因については，化学工場や石油工場に近いなどの立地的な要因，極端
な気候条件の可能性，及び人間による誤りや設備の誤作動などに影響を及ぼす可能性
のある要因。
どの程度の正確さが要求されるかに依存するが，資産をその構成要素に分割し，脅威を構成要素
と関連づけることが必要な場合もある。例えば，物理的な資産は，当初“中央データサーバ”と
考えられる場合もあるが，これらのサーバの立地条件が異なることが確認された場合は，
“中央デ
ータサーバ１”と“中央データサーバ２”に別けることになる。これは，一部の脅威は異なった
ものであり，また別の脅威はレベルが異なっているかも知れないからである。同様に，あるソフ
トウェア資産が，最初は一つの“アプリケーションソフトウェア”とみなされているが，その後，
“アプリケーションソフトウェア”の 2 個又はそれ以上の実体に別けるような場合もある。デー
タ資産に関する一つの例として，最初は“犯罪履歴”と決定されたが，後に“犯罪履歴のテキス
ト”及び“犯罪履歴の画像”に別けられるということである。
脅威の評価の完了後は，確認された脅威，脅威が影響を及ぼすであろう資産若しくは資産のグル
ープ，及び（例えば高，中，低といった目盛りで表現される）脅威の発生しやすさの評価リスト
が残される。
9.3.5
ぜい（脆）弱性の評価
この評価には，物理的環境，組織，手順，要員，経営，管理，ハードウェア，ソフトウェア，又
15
は通信機器の弱点の特定が含まれる。これらは，資産及び資産が支援しているビジ
ネスを損なう脅威の原因によって利用されるかもしれない。ぜい（脆）弱性が存在するからとい
って，それ自体として損害を発生させるわけではない。それを利用しようとする脅威の存在が必
要だからである。対応する脅威が存在しないぜい（脆）弱性は，セーフガードの実施を必要とし
ないが，変更の認識と監視は行われるのが望ましい。不正確に実施され，又は作用しないセーフ
ガード，又は不正確に利用されたセーフガードは，それ自体がぜい（脆）弱性となり得ることに
注意することが望ましい。
ぜい（脆）弱性は，資産の購入時又は作成時に意図されたのとは異なった方法，又は目的で使用
できる資産の性質（properties）又は属性（attributes）と関連づけることができる。例えば，
EEPROM の性質の一つは，
格納された情報を消去したり書き換えたりできるということである。
これは，EEPROM の設計基準の一つである。しかし，この性質は同時に，EEPROM に格納され
た情報の無許可の破壊が可能であることも意味する。これがぜい（脆）弱性となるかもしれない。
この評価は，脅威によって利用される可能性のあるぜい（脆）弱性を特定し，その弱点の成功し
そうなレベル，すなわち利用の容易さを評価する。例えば，幾つかの資産は，容易に処分され，
容易に隠匿され，又は運搬される ― これらの性質はすべてぜい（脆）弱性と関連づけることが
できる。ぜい（脆）弱性評価についての入力は，資産の所有者又はユーザ，設備の専門家，及び
ハードウェアとソフトウェアに関する IT システムの専門家から入手されることが望ましい。ぜい
（脆）弱性の例として次のものが挙げられる：
― 保護されていない接続（例えば，インターネットへの接続）
，
― 訓練されていないユーザ，
― パスワードの誤った選択と誤用，
― 適切なアクセス管理ができていない（論理的及び／又は物理的）
，
― 情報又はソフトウェアのバックアップコピーがない，及び
― 洪水を受けやすい地域にある。
より多くのぜい（脆）弱性の例を附属書 D に示す。
ぜい（脆）弱性がどれくらい耐えがたいものであるか，言い換えれば，どれくらい容易に利用可
能であるかを評価することが大切である。ぜい（脆）弱性は，特定の状況において利用する可能
性のあるそれぞれの脅威に関して評価されることが望ましい。例えば，システムは，ユーザのな
りすまし及び資源の誤用の脅威に対するぜい（脆）弱性を有する場合がある。ユーザのなりすま
しに対するぜい（脆）弱性は，ユーザ認証が欠けていることから，高くなるおそれがある。一方
では，資源の誤用に対するぜい（脆）弱性は，低いかもしれない。それは，ユーザ認証がない場
合でも，資源の誤用を生じる恐れのある手段が限られているからである。
このステップの結果は，ぜい（脆）弱性及び，例えば，“高”，“中”，“低”といった尺度に
よる利用の容易さの評価によってリストにするのが望ましい。
9.3.6
既存及び計画中のセーフガードの特定
リスク分析のレビューに従って特定されたセーフガードを，既存の又は計画中のセーフガードに
追加するのがよい。例えば，セーフガードの重複など，不必要な作業又は費用を避けるために，
このような既存の又は計画中のセーフガードをこのプロセスの一部として特定することが重要で
ある。既存の又は計画中のセーフガードが正当化されないことが確認される場合もあり得る。こ
の場合，セーフガードを取り除き，他のより適切なものと交換するか，又はそのままにしておく
（例えば，費用上の理由から）べきかどうかをチェックすることが望ましい。
さらに，リスク分析のレビュー（9.4 参照）に従って選択されたセーフガードが，既存の又は計画
中のセーフガードと矛盾しないかどうか，すなわち，選択されているセーフガードと既存のセー
フガードとが相互に邪魔をし合わないかどうかを判定するために，チェックを行う必要がある。
16
既存のセーフガードを特定する間に，セーフガードが正確に働いていることを保証するためにチ
ェックを行うことが望ましい。作業の正確な実行に依存するが，ビジネスプロセスでは機能しな
いセーフガードは，ぜい（脆）弱性を生じさせる原因となる。
このステップの結果は，すべての既存の又は計画中のセーフガード，及びその実施と使用状態を
掲げたリストである。
9.3.7 リスクの評価
このステップの目的は，適切かつ正当化されたセキュリティセーフガードを特定し，選択するた
めに，IT システム及びその資産が暴露されるリスクを特定し，評価することである。リスクは，
リスクに対する資産の価値，ビジネスへの潜在的な悪影響を及ぼす脅威の発生の可能性，特定さ
れた脅威によるぜい（脆）弱性の利用の容易さ，及びリスクを低減させる可能性のある既存又は
計画中のセーフガードなどの関数である。
これらの要因を関連づけるには，さまざまな方法がある。例えば，資産に割り当てられた価値，
ぜい（脆）弱性及び脅威を組み合わせて，リスクの尺度となる値を得る。資産に対して評価され
た価値，ぜい（脆）弱性及び脅威に基づくさまざまな種類のリスク分析方法の詳細な考察を附属
書 E に示す。
リスクの程度を評価するためにどのような方法をとるにせよ，このステップの結果は，対象とす
る IT システムについての開示，修正，非可用性，及び破壊の影響のそれぞれについて測定された
リスクを列挙したリストにするのが望ましい。さらに，リスクの程度は，セーフガードを選択す
るに当って，どのリスクが最初に取り扱われるべきかを特定する場合に役立つ。使用する方法は
反復可能で，かつ追跡可能であるのが望ましい。
前にも述べたように，リスク分析のプロセスの全部又は一部の支援のために，さまざまな自動化
ソフトウェアツールを使用することができる。組織があるツールの使用を決定した場合は，使用
するアプローチがその組織の IT セキュリティ戦略及びポリシーに合うよう注意するのが望まし
い。また，ツールは入力の許容範囲でだけ正確に動作することができるので，正確な入力を入手
するよう努力することが望ましい。
9.4 セーフガードの選択
評価されたリスクを受け入れ可能なレベルにまで低減させるために，適切かつ正当化されたセー
フガードを特定し，選択することが望ましい。妥当な選択ができるように，既存の及び計画中の
セーフガード，IT セキュリティアーキテクチャ，及びさまざまな種類の制約事項を考慮に入れな
ければならない（9.3.6 ，9.4.2 及び 9.4.3 参照）
。セーフガードの選択に関する追加の助言は，ISO
／IEC TR 13335-4 にある。
9.4.1 セーフガードの特定
前のステップで決定されたリスクの大きさは，適切な保護のために必要なすべてのセーフガード
を特定するための基礎として使われることが望ましい。
評価されたリスクに対して効果的な保護を行うセーフガードを選択するためには，リスク分析の
結果を考慮することが望ましい。関連する脅威に対するぜい（脆）弱性は，どこに追加の保護を
行う必要性が生じる可能性があるか，及びどのような形をとるべきかを示す。
代替も可能であり，これは，検討したセーフガードの費用に従って決定される。セーフガードを
適用することができる分野には次のようなものがある：
― 物理的環境，
― 要員，
― 管理，
― ハードウェア／ソフトウェア，及び
― 通信。
17
既存の及び計画中のセーフガードが十分に効果的でない場合，それらを取り除く（又は実施しな
い）か，又は改善するために，保守も含めた費用の比較の観点から再検討することが望ましい。
この場合，不適切なセーフガードをそのまま放置して，別のセーフガードを追加するよりも，そ
れを撤去することの方が費用を要すことがある。また，あるセーフガードが，現在のレビュー対
象以外の資産を保護することもあり得る。
セーフガードの特定のために，保護するべきぜい（脆）弱性を考慮し，それらのぜい（脆）弱性
を利用する可能性がある関連した脅威を把握することが役立つ。一般に，リスクを低減するには，
さまざまな可能性がある。
―
―
―
―
―
―
リスクを回避する，
リスクを移転する（例えば，保険など）
，
脅威を少なくする，
ぜい（脆）弱性を少なくする，
生じる可能性のある影響を少なくする，及び
好ましくないイベントを検知し，対策を講じ，そのようなイベントから回復する。
これらの可能性（又はその組合せ）のうち，どれが最も適当であるかは，状況によって異なる。
セーフガードカタログが役立つこともある。しかし，カタログからセーフガードを選択する場合，
組織特有のニーズに合わせて調節することも大切である。
セーフガードの選択におけるもう一つの重要な側面は，費用の要因である。保護しようとする資
産の価値よりも，実施と保守の費用のかさむセーフガードを奨めるのは不適当である。組織がセ
キュリティのために割り当てた予算よりも高くつくセーフガードを推奨するのも不適当である。
しかし，実施しようとするセーフガードの数量や品質が予算によって低減するような場合は，慎
重な注意が必要である。これは，計画よりも大きなリスクを暗黙のうちに受け入れるのに等しい
からである。セーフガードについて確定された予算は，慎重に制限的な要因として使用するだけ
にとどめるのがよい。
IT システムの保護にベースラインアプローチが選ばれた場合は，セーフガードの選択は比較的簡
単である。セーフガードカタログは，最も一般的な脅威から IT システムを保護するための一連の
セーフガードを提案している。これらの推奨されたセーフガードを，既存の又は計画中のセーフ
ガードと比較し，まだ実施又は計画されていないものを，ベースライン保護を得るために実施す
るべきセーフガードとして，リストに作成する。
セーフガードの選択には，常に，事業レベルの（非技術的）セーフガードと技術的セーフガード
との間のバランスを含めるのが望ましい。事業レベルのセーフガードには，物理的，要員，及び
管理的なセキュリティを提供するものが含まれる。
物理的なセキュリティのセーフガードには，建造物内の壁面の強度，キーコードドアロック，消
火システム，及び守衛が含まれる。要員のセキュリティは，要員採用，
（特に“責任のある”人々），
スタッフの監視，及びセキュリティの意識向上プログラムを対象とする。
手順的なセキュリティには，安全運用手順書，アプリケーション開発及び受け入れ手順はもちろ
ん，事件／事故への対応の手順も含まれる。このカテゴリに関しては，適切なビジネスの継続性
が大切である。これには，各システムに対して臨時計画／災害復旧，戦略及び計画が開発される
ことが含まれている。計画には，災害又はサービスの中断が発生した場合の主要機能及び復旧優
先順位，処理ニーズ，及び従うべき組織の手順を含めることが望ましい。このような計画には，
組織がビジネスを行ないながら，処理される重要な情報を保護するために必要なステップを含め
なければならない。
技術的セキュリティには，ハードウェア及びソフトウェアのセキュリティはもちろん，通信のセ
ーフガードも含まれる。これらのセーフガードは，セキュリティの機能と保証を提供するために，
18
リスクに応じて選択される。機能は，例えば，識別と認証，論理的アクセス制御の要件，監査証
跡／セキュリティロギングの要求，ダイヤルバックセキュリティ，メッセージ認証，暗号化など
を対象とする。保証要件は，セキュリティ機能に必要な信頼のレベルを示し，したがって，チェ
ックの量と種類，セキュリティ試験など，そのレベルを確認するのに必要な事項を示している。
運用上及び技術的セーフガードの優先的な組合せに関する決定を行うに当っては，技術的なセキ
ュリティ要件を実装するためのさまざまなオプションが提示される。技術的なセキュリティアー
キテクチャは，必要に応じてセキュリティが提供できること，また，入手可能な技術で実施でき
ることを確認するのに役立つよう，各オプションについて定義していることが望ましい。
組織は，最終的なシステム解決策の一部として，評価された製品及びシステムを利用することを
選択する場合がある。評価された製品とは，第三者によって既に検討された製品である。ここで
第三者とは，組織内の別の部門でもよく，又は，製品並びにシステムの評価を専門とする独立し
た組織でもよい。評価は，構築中のシステムのために特に作成されたあらかじめ定められた一連
の基準に照らして行なってもよく，また，さまざまな状況下で利用できる一連の一般化された基
準によって行なってもよい。評価基準は，機能要件及び／又は保証要件を特定することができる。
幾つかの評価スキームが存在し，その多くは政府及び国際的な標準化機関によって策定されたも
のである。実施された一連の機能が必要とされたものであることの信頼性が必要である場合，及
びその機能の実施が正確かつ完全であるとの信用が必要な場合，組織は評価済みの製品及びシス
テムを利用することを決定することもできる。その代替として，焦点をあてた現実的なセキュリ
ティ試験も，提供されたセキュリティの信頼度を保証することができる。
実施のためにセーフガードを選択する場合，数多くの要因を考慮することが望ましいが，これに
は次のようなものが含まれる：
― セーフガードの使い易さ，
― ユーザに対する透明性，
― ユーザがその機能を果たすために提供される手助け，
― セーフガードの相対的強度，及び
― 実行される機能の種類 ― 予防，障害，検知，回復，修正，監視及び意識の向上。
一般に，セーフガードは，これらの機能のうちニつ以上を成し遂げる ― その数は多い程よい。
全体のセキュリティ，又は使用する一連のセーフガードを検討する場合，可能であれば，機能の
各種類の間でバランスを保つのがよい。これは，セキュリティ全体をいっそう有効的かつ効果的
なものにするのに役立つ。費用／利益の分析は，トレードオフの分析と同じくらい必要かもしれ
ない（特定の状況に関して，相対的重要性についての重みづけがなされた一連の基準を用いる競
合した代替案どうしを比較する方法）
。
9.4.2
IT セキュリティアーキテクチャ
IT セキュリティアーキテクチャは，システムのアーキテクチャ全体の一部として，IT システムに
対してどのようにセキュリティ要求を満足させるべきかを説明したものである。したがって，セ
ーフガードを選択するプロセスの中で IT セキュリティアーキテクチャを考慮することが大切で
ある。
新しいシステムの開発，及び既存のシステムに大きな変更が加えられる場合に，IT セキュリティ
アーキテクチャを使用することができる。リスク分析又はベースラインアプローチの結果に基づ
いて，セキュリティの要件を取り上げ，それをこれらの要件を満たすシステムに対する一連の技
術的なセキュリティサービスに仕上げる。場合によっては，特に既存のシステムに変更が加えら
れる場合，要件の一部は，使用される特定のセーフガードの形をとってもよい。
IT セキュリティアーキテクチャは，技術的なセキュリティサービス，及びそれがどのようにして
セキュリティ目標を達成するかに重点をおく。これを行う場合，関連する非技術的なセキュリテ
ィセーフガードを考慮に入れる。アーキテクチャは，さまざまな多くの見通し及びアプローチか
ら構築することができるが，基本原則を考慮に入れるのがよい。特有のセキュリティドメイン（同
19
じ又は類似のセキュリティ要件及びセーフガードの領域）におけるセキュリティ上の問題は，他
の特有なセキュリティドメインに対するセキュリティに悪影響を及ぼすことがあってはならない。
IT セキュリティアーキテクチャは，通常，一つ又はそれ以上のセキュリティドメインからなる。
セキュリティドメインは，組織が使用し，確立したビジネス上のドメインに，できる限り密接に
従うのがよい。これらのビジネス上のドメインは，特定のビジネス上の機能区分，例えば，給与
支払い，製造，又は客先サービスなどに従ったものでよく，又は，電子メールサービス又はオフ
ィスサービスなどのビジネス上のサービス区分に従ったものでもよい。
セキュリティドメインは，次の属性のうち一つ又はそれ以上に区分けされる：
― そのドメイン内でアクセス可能な情報のレベル，カテゴリ，又は種類，
― そのドメインに適用できる業務，
― そのドメインに関連する利害を共有するコミュニティ（COI）
，
― 他のドメイン及び環境との関係，及び
― ドメイン内で COI によって要求される機能又は情報アクセスの種類。
IT セキュリティアーキテクチャの構築にあたって，取り組むべき問題点として次のようなものが
ある：
― 特有なセキュリティドメイン間の相互関係及び相互依存関係，
― セキュリティサービスを弱める相互関係及び相互依存関係の影響又は係わり合い，及
び
― 弱点を修正，管理又は対処するのに必要な追加のサービス又は予防策。
IT セキュリティアーキテクチャは独立型のものではなく，むしろ他の文書とのインタフェースに
依存している。これらのうち最も重要なものは，ハードウェア，通信及びアプリケーションのよ
うなシステムアーキテクチャ及び他の関連したアーキテクチャである。IT セキュリティアーキテ
クチャは，システムの完全な説明を含んでおらず，技術的な側面と，セキュリティに関連する要
素だけを対象としたものとなる。IT セキュリティアーキテクチャは，環境に最適な保護を保ちな
がら，ユーザに及ぼす悪影響をできる限り少なくすることを目指すのがよい。
他の文書の幾つかは，IT セキュリティアーキテクチャに関連するか，又は依存している。これら
は，次のものを含んでいる：
― IT セキュリティの設計，
― IT セキュリティ運用の概念，
― IT セキュリティ計画，
― IT システムのセキュリティポリシー，及び
― 要求される場合，IT システム認証及び認定のドキュメンテーション。
9.4.3 制約事項の特定及びレビュー
セーフガードの選択に影響を及ぼす可能性がある多くの制約事項がある。勧告を行う時，及び実
施の間は，これらの制約事項を考慮しなければならない。
時間的な制約事項
多くの種類の時間的な制約事項が存在し得る。例えば，経営者が容認できる時間内にセーフガー
ドを実施するのが望ましい。ニつ目の種類の時間的な制約事項は，システムの寿命の続くうちに
セーフガードを実施できるか否かということである。三つ目の種類の時間的な制約事項は，経営
者が決定した期間が，システムを特定のリスクにさらされたままにしておくという点で，容認で
きる期間であるか否かという点である。
財務上の制約事項
セーフガードを実施する費用は，保護するべき資産の価値よりも高くしないことが望ましい。割
り当てられた予算を超過しないよう，できる限り努力することが望ましい。しかし，場合によっ
ては，それらの予算上の制約事項内で，望まれるセキュリティ及びリスクの容認のレベルを達成
できない場合もある。したがって，これは，このような状況の解決についての経営者の決定によ
る。
20
技術上の制約事項
プログラムやハードウェアの互換性のような技術上の問題は，セーフガードの選択時に考慮に入
れれば容易に回避することができる。また，既存のシステムへのセーフガードの遡及的な実施は，
技術上の制約事項によって妨げられることが多い。これらの困難さは，セーフガードのバランス
を，セキュリティの手順及び物理的な側面へと移動させるかもしれない。
社会的な制約事項
セーフガードの選択に対する社会的な制約事項は，国，産業部門，組織，又は組織内の部門ごと
に特有のものである場合がある。多くの技術上のセーフガードがスタッフの活発な支援に依存し
ているので，社会的な制約事項は決して無視できない。スタッフがセーフガードの必要性を理解
せず，又はそれが文化的に容認可能なものであると考えなければ，セーフガードは時間の経過と
ともに効果のないものとなる。
環境上の制約事項
環境の要因が，利用可能な空間，極端な気候条件，周囲の自然及び都市の立地などのように，セ
ーフガードの選択に影響を及ぼすことがある。
法律上の制約事項
個人データの保護や，情報処理に対する刑法上の規定などの法律上の要因が，セーフガードの選
択に影響を及ぼすことがある。消防法，労働関係法など，非 IT に特有の法規制が，セーフガード
の選択にも影響を与える可能性がある。
9.5 リスクの容認
セーフガードを選択し，選んだセーフガードが達成すると考えられるリスクの低減を確認した後，
常に残存リスクは存在し，絶対に安全というシステムは作ることができない。これらの残存リス
クを，組織にとって“容認可能”又は“容認不可能”のカテゴリに分けることが望ましい。この
カテゴリ分けは，これらのリスクと関連するビジネスへの潜在的な悪影響を検討することによっ
て行われる。一層の考察を進めなければ，これらの容認不可能なリスクを許容することができな
いのは明らかである。その他の制約事項（例えば，費用，又は単に予防不可能 ― 建物への航空
機の墜落や地震など。ただし，このような事象からの回復の計画をたてることは可能）があるの
で，容認するか否か，又は容認不可能なリスクを低減させるために，追加の，おそらく高価なセ
ーフガードを選ぶか否かは，経営者の決定するべき事項である。
9.6 IT システムのセキュリティポリシー
IT システムのセキュリティポリシーは，必要なセーフガードの詳細を含み，それらが何故必要な
のかを説明するのが望ましい。システムに対する IT セキュリティ計画は，それらをどのように実
施するかを取り扱うのが望ましい。
多くのシステムはそれぞれのセキュリティポリシーを必要としており，これは，リスク分析に基
づくことが望ましい。通常これは，大規模で複雑なシステム，又はその組織の他のシステムには
見られない特有であり，そして特殊な考察を導入したシステムの場合である。IT システムのセキ
ュリティポリシーは，企業の IT セキュリティポリシーと両立するのがよく，抵触は避けることが
望ましい。企業の IT セキュリティポリシーよりもレベルの低い問題点を対象とするのが望ましい。
IT システムのセキュリティポリシーは，リスク分析のレビューの結果及びこのシステムのための
セーフガードの特定に基づいたものであり，評価されたリスクに応じて選ばれた一連のセーフガ
ードによって支援されている。これらのセーフガードによって，システムにとって適切なレベル
の保護が達成される。
IT システムのセキュリティポリシーは，使用されている企業のリスク分析の戦略がどのようなも
のであるかには関係なく，次に述べる情報に基づくのが望ましく，また，対象とするシステムに
とって適切なセキュリティレベルを達成するのに必要なセーフガード（手順を含む）を内容とす
ることが望ましい。IT システムのセキュリティポリシー及び関連する全ての支援文書は次のもの
21
を取り扱うのが望ましい：
― IT システムの定義，その構成要素及び境界の説明（この説明はシステムを構成する
すべてのハードウェア，ソフトウェア，人，環境及び業務を対象とすることが望まし
い）
，
― IT システムに対するビジネスの目的の定義 ― これは，このシステムのための IT セ
キュリティポリシー，選択されたリスク分析のアプローチ，及びセーフガードの選択，
並びにその実施の優先順位に影響を及ぼすかもしれない，
― システムのためのセキュリティ対策方針の確定，
― 組織のビジネスが，IT システムの損失や危たい（殆）化によってどの程度危険にさ
らされる可能性があるか，この IT システムが遂行しようとしている仕事，及び処理さ
れる情報などの観点から，IT システムへの大まかな依存度，
― 設備，運用及び交換に用立てる費用と共に，IT システムの開発費，保守費，及び交
換費の観点から IT への投資レベル，
― IT システムに対して選択されたリスク分析アプローチ，
― 組織が保護したい IT システムの資産，
― これらの資産価値が危たい（殆）化した場合，組織に何が起きるかという観点での，
これらの資産の評価（この情報の開示，修正，非可用性及び破壊からのビジネスへの
潜在的な悪影響という観点で，保持している情報の価値を説明することが望ましい），
― IT システム及び取扱う情報への脅威。これには，資産と脅威との間の関係，並びに
それらの脅威が発生する可能性を含む，
― IT システムのぜい（脆）弱性。これには，脅威によって利用される可能性のある特
有の弱点の説明が含まれる，
― 次の事項の結果として，この IT システムに対するセキュリティリスク：
― 組織のビジネスに対する潜在的な悪影響，
― 脅威が発生する可能性，及び
― ぜい（脆）弱性の利用の容易性。
― この IT システムを保護するために特定されたセーフガードのリスト，
― IT セキュリティの費用見積り。
ベースライン保護を要求することだけを正当化したシステムの場合，詳細なリスク分析が行なわ
れたシステムよりも詳細度の低い場合もあるが，上記の見出しのもとで情報を提供することが可
能であることが望ましい。
9.7
IT セキュリティ計画
IT セキュリティ計画は，IT システムに対して要求されるセーフガードを実施するために行う処置
を定義した文書である。この計画には，上述したレビューの結果，適切なセキュリティのレベル
を達成し，維持するために短期，中期及び長期の時間枠内で行われる処置，費用，及び実施スケ
ジュールを内容とするのがよい。各システムについて次のものを含めることが望ましい。
― 機密性，完全性，可用性，責任追跡性，真正性及び信頼性の面から見たセキュリティ
対策方針，
― この IT システムに対して決定されたリスク分析のオプション（8.参照）
，
― 特定したセーフガードの実施後，
予想され，
容認された残存リスクの評価
（9.5 参照）
，
― 実施するべき選択されたセーフガードのリスト（9.4 参照）
，並びに既存の及び計画
中のセーフガードのリスト。これには，効果の判定及び必要なセーフガードのアップ
グレードを含む（9.3.6 及び 9.4 参照）
。このリストには，次のものを含める：
― 選択されたセーフガードの実施及び既存のセーフガードをアップグレードする
優先順位，及び
― これらのセーフガードが，実際にどのように働くべきか。
― これらのセーフガードの導入費及び運用費の見積り，
― これらのセーフガードの実施，及びフォローアップ作業のための人的資源の見積り，
及び
22
― 実施のための詳細な作業計画の内容は，次を含む：
― 優先順位，
― 優先順位に関連した実施スケジュール，
― 必要な予算，
― 責任，
― セーフガードの効果を高めるために必要な IT スタッフ並びにエンドユーザのた
めのセキュリティの意識向上及び訓練手順，
― 必要に応じて行われる承認プロセスのスケジュール，及び
― フォローアップ手順のスケジュール。
さらに，IT セキュリティ計画は，セーフガードの正しい実施のプロセスを管理するための能力を
説明したものであることが望ましい。例えば，
― 進捗報告手順の定義，
― 可能性のある困難さを特定する手順，
― 上記に挙げた各項目を証明する（validate）手順。これには，必要な場合，それぞれ
の部分又は計画自体の修正の可能性に関する手順を含む。
このステップの結果は，IT システムのセキュリティポリシーに基づく各システムについての詳細
な IT セキュリティ計画であり，これは 9.で述べたレビューの結果を考慮したものである。IT シ
ステムに対するリスクから導いた優先順位に従い，かつ，セーフガードをどのようにして実施す
るか，またどのようにして適切なセキュリティレベルに達するかの説明に沿って，セーフガード
が適時に実施されるようにするのが望ましい。また，このセキュリティレベルを維持するフォロ
ーアップ手順のためのスケジュールも含めるのが望ましい。これらのフォローアップ手順につい
ては 11.で述べる。
10. IT セキュリティ計画の実施
セキュリティセーフガードの正しい導入は，十分に構造化され，文書化された IT セキュリティ計
画に大きく依存している。同時に，各システムに関連するセキュリティ意識の向上及び訓練も実
施しなければならない。IT セキュリティ計画の策定が完了したら，システム又はサービスを実際
に使用する前に，全てのセーフガードの承認が必要である。
10.1 セーフガードの導入
セーフガードの導入のために，IT セキュリティ計画に記載された全ての必要なステップを行なう。
計画の責任者（通常は IT システムセキュリティ責任者）は，IT セキュリティ計画で概要を述べ
た優先順位及びスケジュールに従うようにしなければならない。
継続性及び一貫性を保つために，セーフガードの文書化は IT セキュリティ文書化の中でも重要な
部分を構成している。このプロセスは，多数の異なった方法で実行することができる。これは，
多くのセキュリティ文書，例えばセキュリティ計画，事業継続計画及びリスク分析文書並びにセ
キュリティポリシー及び手順の一部としなければならない。経営者，ユーザ，システム管理者及
び保守要員並びに構成／変更管理に参加している人々のニーズを満たすように設計する。セキュ
リティの中断及び見落としをなくすのに役立つよう，最新かつ十分な詳細に渡っており，セキュ
リティ作業が正しく，効率的に行なわれるよう情報を提供するものでなければならない。文書の
多く，特に脅威，脆弱性及びリスクに関する文書は重要性が極めて高いものとすることができ，
許可を得ない開示に対して保護されていなければならない。その結果，ほとんどの組織は，この
文書化を極めて慎重に扱う必要があり，
“信頼のある”周知手順を用いても良い。
このような手順を使用する場合，セーフガード情報のうち重要な部分をどのようにして格納し，
アクセスし，使用するかを説明するような方法で文書化しなければならない。さらに，これらの
手順では，セーフガード情報をどのように格納するかを決定する責任者，それにアクセスし，使
23
用できる者を確認しなければならない。周知手順の設計においては，セーフガード情報へのアク
セスの可能性について事業の継続性から使用するニーズなど，特別の要因を考慮に入れなければ
ならない。これには，時間が重要な項目であり，災害又はその他の予想外の事件発生時における
臨時の計画策定／災害復旧，戦略及び計画が含まれる。最後に，不本意又は知らずにセーフガー
ドの効果を減じてしまうような無許可の変更が行なわれないようにするためには，セーフガード
の文書化の厳密な構成管理も必要である。
一旦，IT セキュリティ計画が完成して，責任のある部署による承認されたら，セーフガードを導
入し，セキュリティ遵守状況をチェックし，試験を行なわなければならない。セキュリティ遵守
状況のチェックレビューは，セキュリティセーフガードが正しく導入されたこと，効果的に使用
されていること，適切に試験されていることを確かめるために行なわれる。セキュリティ試験は，
このレビューの一部として行なうことができる。試験は，正しく導入され，完了したことを確認
するための重要な手法である。セキュリティ試験は，セキュリティ試験計画によってガイドされ，
試験アプローチ，スケジュール及び環境が示される。もし，リスクの評価によって正当であると
認められるならば，ペネトレーションテストを実施することができる。詳細なセキュリティ試験
手順は，標準試験報告書を使用するよう文書化される。目標は，IT セキュリティ計画からの要求
を満足し，指定とおりにリスクが低減されるような方法で導入と試験を行なうことである。
10.2 セキュリティ意識の向上
セキュリティ意識向上プログラムの目標は，組織内の意識レベルを向上させて，セキュリティ意
識が定着し，プロセスが，全てのスタッフが容易に従うことのできる日常作業となる域に達する
ことである。プログラムは，IT スタッフ及びエンドユーザが IT システム（ハードウェア及びソ
フトウェア）の十分な知識を持つようにし，なぜセーフガードが必要なのか，また，どのように
して正しく使うかを理解させるようなものでなければならない。IT スタッフとエンドユーザが受
け入れたセーフガードのみが効果を発揮することができる。
セキュリティ意識向上プログラムへ記述内容は，組織内のあらゆるレベルからのものでなければ
ならない。これには全社的 IT セキュリティポリシーを含めるべきであり，組織における IT セキ
ュリティ計画の全ての目標を対象としなければならない。意識向上チームには，全ての部門から
の経営陣の支援が必要である。詳しく述べれば，セキュリティ意識の向上がプログラムに記述さ
れたコース，話し合い，その他の活動では，次のような話題を取り上げなければならない。
― 組織にとっても，個人にとっても，セキュリティが大切である旨の説明。
― 機密性，完全性，可用性，責任追跡性，真正性及び信頼性の観点から，IT システムのための
セキュリティのニーズと目標。
― 組織と個人におけるセキュリティ上の事故の意味。
― ハードウェア及びソフトウェアを含む IT システムの正しい使用。
― リスク及びセーフガードの理解を促進するための，目標背景及び，企業の IT セキュリティポ
リシー，セキュリティガイドライン及び指示並びにリスク管理戦略の説明。
― IT システムに必要な保護及びそのリスク。
― IT ドメインへのアクセス制限（許可された者，ドアロック，バッジ，入館ログなど）及び情
報へのアクセス制限（論理的アクセス管理，読み取り／更新の権利など）
，及びこのような制
限が必要な理由。
― セキュリティ違反又は悪意を持った企てを報告する必要性。
― 手順，責任及び業務の説明。
― セキュリティ確保のため，IT スタッフ及びエンドユーザがしてはならないこと。
― スタッフがセキュリティ違反をした場合の責任の重要さ。
― セーフガードの導入とチェックのための IT システムのセキュリティ計画。
― これらのセーフガードが必要とされる理由，及びそれらを正しく使用する方法。
― セキュリティ遵守状況チェックに関する手順。
24
― 変更及び構成管理。
セキュリティ意識向上プログラムの作成は，セキュリティ戦略，目標及びポリシーのレビューか
ら開始される。このプロセスは，組織の重要な機能を確認する立場にいて，上級経営者から全面
的な支援の得られる人々のチームによって行われなければならない。
レビューチームは，企業の IT セキュリティポリシーに従って，要件の内訳を決定しなければなら
ない。これに全体のセキュリティ（すなわち IT だけでなく）の案を組み合わせて，意識向上促進
ポスター，雑誌，企業パンフレット及び社内メールなど，様々な形で発表する。
レビューチームはセキュリティ上の懸念事項について，概況説明を明確にする。この概況説明の
ための必要な情報ベースを構築するために，要件の徹底したレビューを行なう。各要約は，スタ
ッフ全員が近代的情報技術に特有のリスクになじむように，定期的な間隔（例えば，6 ヶ月ごと）
で行われなければならない。
意識向上プログラムの目標及び内容を決定する責任は，上級経営者のレベルで，IT セキュリティ
委員会（標準情報(TR)群の第 2 部参照）に負わせなければならない。その作成及び実施の責任は，
企業の IT セキュリティ責任者及びセキュリティ意識向上プログラム開発チームに割り当てられ
る。これは，企業の他の訓練教育活動と連携して行なわなければならない。しかし，セキュリテ
ィポリシーと業務環境の手順を検討し，緊密に親しむのは各個人の責任である。それ故，セキュ
リティ意識向上プログラムは，組織のあらゆるレベルで実施しなければならない。
セキュリティ意識向上プログラムの作成を成功させるためには，次の構成要素を組入れなければ
ならない。
10.2.1
必要性の分析
対象グループ（幹部，経営者及びスタッフ）内にすでに存在する意識のレベル及び新しい情報を
彼らに送る最も妥当な方法を決定するには，セキュリティ知識の必要性分析を行なうことが必要
である。必要性分析は，現在の実際の業務状況との対比で，ポリシー，手順，態度，セキュリテ
ィの知識及び必要する実行態様を検討する。
10.2.2
プログラムの周知
総合セキュリティ意識向上プログラムには，対話手法と促進手法の両方を含めなければならない。
意識向上プログラムのこの部分の焦点は，必要性分析で確認されたセキュリティ意識が不足して
いる部分である。スタッフは，IT 資産には価値があり，それらの資産に対する脅威が現実に存在
するということを認識し，理解することが必要である。
このような組織のセキュリティ意識向上プログラムから導き出される利点は，スタッフに対して
セキュリティプログラムに参加するチャンスを与えるという点である。対話手法（スタッフ会議，
訓練コースなど）は相互の意思疎通を可能にし，これによって参加者とセキュリティ要員は，必
要性分析から得られた概念と要件を評価することができる。促進手法（ビデオ，e メール，ポス
ター，刊行物など）は一方的な通知方法で，これによって，経営陣が費用のかからない方法で概
念，情報及び態度を広く伝達することができる。
10.2.3 セキュリティ意識向上プログラムのモニタリング
セキュリティ意識向上プログラムの効果的なモニタリングには，2 つのはっきりと異なる構成要
素がある。
― 定期的な成績評価 セキュリティ関連挙動をモニタリングすることによって意識向上プログラ
ムの効果を判定し，プログラムの周知に影響を及ぼす変更が必要な場合を確認する。
25
― 意識変化管理 全体のセキュリティプログラムに対する変更（すなわち，ポリシー又は戦略の
変更若しくは新しい資産又は技術が導入され，脅威にも変動が生じた場合など）が生じた場合，
既存の知識やスキルのレベルを，これらの変化を反映したものに更新するために，セキュリテ
ィ意識向上プログラムを変更することが必要となる。
10.3
セキュリティの訓練
組織内の全ての人に適用される一般的なセキュリティ意識向上プログラムのほかに，IT セキュリ
ティに関連する業務及び責任を有するスタッフのために，特定のセキュリティ訓練が必要である。
セキュリティ訓練の深さは，IT セキュリティの組織にとっての全体の重要性に従って変動し，役
割に求められるのセキュリティの要件に従って変動する。必要があれば，大学の講義や授業への
参加など，もっと費用のかかる教育も提供するべきである。IT セキュリティ訓練プログラムは，
組織に関する全てのセキュリティのニーズを対象とするよう作成しなければならない。
特定のセキュリティ訓練が必要なスタッフを判定する場合は，次の事項を考慮に入れる。
― IT システムの設計と開発に主要な責任を有するスタッフ。
― IT システムの運営に主要な責任を有するスタッフ。
― 企業の IT プロジェクト及び IT システムセキュリティ担当役員。
― 例えば，アクセス管理又はディレクトリー管理など，セキュリティ管理責任を有するスタッフ。
さらに，現在及び計画中の業務，プロジェクト等に特別のセキュリティ訓練が必要な場合には，
チェックを行なわなければならない。特別のセキュリティ要件のある業務又はプロジェクトが開
始される場合，対応するセキュリティ訓練プログラムを，プロジェクトの発足前に開発し，活動
が適時に行なわれるようにする。
セキュリティ訓練コースの対象となる項目は，参加する者の役割及び機能に応じて決められるよ
うにする。一般的な項目は次のようなものとなる。
― セキュリティとは何か。
― 機密性，完全性及び可用性の違反防止。
― 組織あるいは個人に対する事業の影響度。
― 情報重要度区分基準。
― 全体のセキュリティプロセス。
― 全体のプロセスの説明。
― リスク分析の構成要素。
― セーフガード及びセーフガードに従うのに必要な訓練。
― 役割及び責任。
― IT システムセキュリティポリシー。
セーフガードの正しい導入及び使用は，セキュリティ訓練プログラムの対象とするべき最も重要
な問題の 1 つである。各組織は，その必要性，既存及び計画中のセーフガードに応じて，組織自
体のセキュリティ訓練プログラムを開発しなければならない。下記は，対象とするべきセーフガ
ード関連の項目の例であり，非技術的セーフガードと技術的セーフガードのバランスが重要であ
る。
― セキュリティインフラ
― 役割と責任。
― セキュリティポリシー。
― 定期的なセキュリティ遵守状況チェック。
― セキュリティ事故の取扱い。
― 物理的セキュリティ
― 建物
26
―
―
―
―
―
― オフィスエリア，マシン室。
― 装置（機器）
。
スタッフセキュリティ。
媒体セキュリティ。
ハードウェア／ソフトウェアセキュリティ
― 識別と認証。
― 論理的アクセス制御。
― 会計及びセキュリティ監査。
― 記憶情報の消去。
通信上のセキュリティ
― ネットワークインフラ
― ブリッジ，ルータ，ゲートウェイ，ファイアウォール。
― インターネット及びその他の外部接続。
事業の継続性。これには，障害対策計画／災害復旧，戦略及び計画が含まれる。
10.4
IT システムの承認
組織は，全ての又は選択された IT システムについて，それらが IT システムセキュリティポリシ
ー及び IT セキュリティ計画の要件に合うように承認が行われるようにしなければならない。この
承認プロセスは，セキュリティ遵守状況チェック，セキュリティ試験及び／又はシステム評価な
どの手法に基づくものでなければならない。手順は内部又は外部の規格によるものでよく，承認
プロセスを行なう部署は組織の内部又は外部のものでよい。
承認プロセスは，IT システムについて実施され，維持されたセキュリティセーフガードが，適切
なレベルの保護を提供することを確かめるものでなければならない。承認は，定義された運営環
境及び IT システムセキュリティポリシー又は計画に記載された一定の期間中有効でなければな
らない。導入されたセキュリティセーフガードへの大きな変更，又はセキュリティ関連運営手順
の変更には，再承認が必要な場合がある。再承認の基準は，IT システムセキュリティポリシー中
に含めなければならない。
承認プロセスは，主として文書のレビュー，物理的な検査及び技術的評価（すなわち，セキュリ
ティ遵守状況チェック）からなる。これを達成するには，次の主要事項を対象とすることが必要
である。
― 承認プロセスを策定して，特定の IT システムに合わせてアプローチの調整を行なう。この第
1 ステップは，スケジュール，必要な資源及び責任を定義するのにも役立つ。
― このプロセス中に用いられた文書を回収する。
― 文書の完全性と，組織内の他の文書との一貫性をチェックするために，文書レビューを行なう。
― IT セキュリティ計画中に記載された基準に照らしてレビュー及び試験を行なう。
― 承認プロセスの結果を要約し，システムのセキュリティ承認が全面的承認，一部承認，限定承
認又は無承認であるか，また権利放棄及び有効期間及び処理の制限を記載した報告書を作成し
なければならない。
― IT システム又はその環境に変化があれば，再承認が行われる。承認期間の終了ごとにも同様
である。
いったん承認プロセスが行われれば，フォローアップ手順が実施されることとなる。フォローア
ップは，システムのセキュリティ及びその環境の変化を検知し，調査するのに役立つ。検知に続
いてグレードアップの実施が必要となり，この場合，承認が行なわれる。
取引先の下記のような組織について，合意されたベースラインセキュリティ又は実務規約に合わ
せて IT システムの承認が必要とされる可能性もある。
27
― ベースラインセキュリティ又は実務規約の自社バージョンを確立し，その IT 設備への接続を
認める前に，遵守と承認を目的とし，納入業者／取引先に対して実務規約発行する組織。
― 多くの他の企業と取引を行ない，IT に接続することを希望しているが，そのためには，全体
としてのベースラインセキュリティ又は実務規約に照らして受け入れ可能なセキュリティプ
ロファイルを示すことが必要な組織。
― 他社と自社の IT 設備を接続することに関連するセキュリティリスクのレベル及び他社が満足
することを期待するセキュリティプロファイルを確立したいと考えている組織。これによって，
企業は，ベースラインセキュリティ又はセキュリティプロファイルと一貫性のある実務規約へ
の遵守を示すセキュリティ遵守状況のチェックレビューに基づき承認することができる。
11.
フォローアップ
フォローアップは，無視されることも多いが，IT セキュリティの最も重要な面の 1 つである。導
入されたセーフガードは，現実の事業生活の中でチェックされなければ，効果的に働かない。セ
ーフガードが正しく使用されることやセキュリティ関連事故及び変化があれば，それを検知し，
取り扱うことを保証しなければならない。フォローアップ活動の第 1 の意図は，セキュリティセ
ーフガードが導入時と同様に機能し続けるようにすることである。時間の経過に従って，サービ
ス又はメカニズムの働きが劣化する傾向がある。フォローアップは，この劣化を検知し，修正措
置を講ずることを意図したものである。IT システムを保護するのに必要なセキュリティのレベル
を維持する唯一の方策である。この章に述べる手順は，効果的なフォローアッププログラムの基
礎をなすものである。IT セキュリティの運用は IT セキュリティ計画が導入されてからも停止す
ることのないプロセスである。
11.1
保守
大多数のセーフガードは，その寿命の間の正確かつ適正な機能を保証するためには，保守と管理
の支援を必要とする。これらの活動（保守及び管理）を，正規のスケジュールに組まれた形で計
画し，実行しなければならない。このようにして，その間接費を抑制することができ，セーフガ
ードの価値を保持することができる。
誤作動を検知するには，定期的な検査が必要である。チェックされないセーフガードは，どの程
度の信頼度を置いてよいかわからないので，危険である。
保守業務には下記が含まれる。
― ログファイルのチェック。
― 変更及び追加を反映するためのパラメータの修正
― 乱数の初期値あるいは又はカウンターの再起動。
― 新しいバージョンへの更新。
保守と管理の費用は，異なるセーフガードを評価し，選択する場合，常に要因として考慮に入れ
なければならない。これは，セーフガードによって保守と管理の費用が大幅に異なることがあり
得るからである。このため，セーフガードの選択にあたって，重要な決定要因となることが多い。
一般的に言って，現在の保守及び管理の費用をできる限り低減させることが望ましい。これらの
費用が一時的な費用ではなく，反復発生する費用だからである。
11.2
セキュリティ遵守状況のチェック
セキュリティ遵守状況のチェックは，導入されたセーフガードのレビューと分析である。これは，
IT システム又はサービスが，IT システムセキュリティポリシー及び IT システムセキュリティ計
画中に文書化されたセキュリティの要件に従っているか否かをチェックするのに用いられる。セ
キュリティ遵守状況のチェックは，下記の遵守状況をチェックするのに用いることができる。
28
― 新しい IT システム及びサービスの導入後。
― 既存の IT システム又はサービスで，一定の時間経過（例えば，1 年）後。
― 既存の IT システム及びサービスで，IT システムセキュリティポリシーに変更が加えられた場
合に，要求されたセキュリティレベルを維持するためにどのような調整が必要かを見るために行
なう。
セキュリティ遵守状況チェックは，外部の要員もしくは内部の要員を使って行なってよく，本質
的には，IT システムセキュリティポリシーに関するチェックリストに基づく。
IT システムを保護するセーフガードは，次のようにしてチェックしてもよい。
― 定期的なチェック及び試験を行なう。
― 現実に発生する事故に照らして，運用状況をモニタする。
― 特定の重要度の高い分野もしくは関心のある部分について，セキュリティレベルと目標の状況
をチェックするスポットチェックを行なう。
セキュリティ遵守状況チェックを行なうに当って，IT システムに関する活動について，価値のあ
る情報が次から得られる。
― ソフトウェアパッケージのイベント記録の使用。
― イベントの完全な履歴をトレースするための監査証跡の使用。
承認とその後の正規チェックのために行なうセキュリティ遵守状況チェックは，前回のリスク分
析結果からの合意されたセーフガードリスト，IT システム・セキュリティポリシー及び IT 管理
者が署名，事故報告も含むセキュリティ運用手順にもとづいたものでなければならない。目標は
セーフガードが導入され，それも正しく導入され，正しく使用され，かつ該当する場合には試験
されたか否かを確かめることである。
セキュリティ遵守状況チェックの担当者／検査員は，通常の勤務日に建物内を歩き，セキュリテ
ィセーフガードがどのように使用されているかを見なければならない。面接ももちろん重要であ
るが，結果はできるだけ多くクロスチェックしなければならない。誰かが言うことは，そう信じ
られていることであって，現実ではない。一緒に働いている者とクロスチェックを行なう。
これは，総合チェックリスト及び合意された報告書を得るのに役立つ。これらを過小評価しては
ならない。これらのチェックリストには，一般的な確認情報，例えば，構成の詳細，セキュリテ
ィの責任，ポリシー文書，周囲の立地などである。物理的セキュリティは，マンホールの蓋を通
じての出入可能性を含む外部建物などの外面及び構造の健全性，ロック，火災検知及び防火（警
報を含む）
，同様に水／液体検知，停電などの内面を対象とする。
検知するものは多い。例えば，
― 物理的侵入又は迂回管理の可能なエリア。例えば，キーパッド及びカードシステムで操作しな
ければならないドア下のロックなど。
― 正しくないメカニズム又はメカニズムの正しくない設置。例えば，
間違ったタイプ，機能不足，
設置不足の検知設備。煙／熱検知装置はあるエリアについて十分に豊富か，正しい高さに設け
られているか。警報に対する反応は適切か。警報は管理点に適切にリンクされているか。新し
い危険発生源はあるか。誰かが突然可燃物の貯蔵に部屋を使用することないか。電力の適切な
バックアップや停電時の手順はあるか。正しいタイプのケーブルが使用されているか，鋭いト
レー縁部の近くに位置してはいないか。
セキュリティの他の面について，セキュリティのギャップを検知するために，次の質問が役立つ
であろう。
― 人事のセキュリティについては，雇用手順を見る。紹介状は実際に取っているか。雇用のギャ
ップをチェックしているか。スタッフは現実にセキュリティのことを知っており，知り得る状
態にあるか。重要な機能について，1 人に依存していないか。
29
― 管理セキュリティについては，文書は実際にどのように処分しているか。一般用の文書は実際
に更新されているか。リスク分析，状況チェック及び事故報告業務は定められたとおりに行わ
れているか。事業の継続性計画の対象範囲は正しいか，更新されているか。
― ハードウェア／ソフトウェアのセキュリティについては，必要なレベルの冗長性があるか。ユ
ーザ ID／パスワードの選択と手順はどうか。監査証跡は，エラーログ及び追跡の可能性を正
しい精度で選択することが可能となっているか。評価された製品は合意された要件を満足して
いるか。
― 通信上のセキュリティについては。要求された冗長度はあるか。ダイアルアップ設備がある場
合，必要な設備とソフトウェアは定められた場所にあり，適切に使用されているか。暗号及び
／又はメッセージの認知が必要な場合は，主要管理システム及び関連運営の効果はどの程度か。
要約すれば，セキュリティ遵守状況チェックは決して小さな仕事ではなく，成功裡に完了するた
めには，十分な経験と知識が必要なのである。これは，内部監査レビューとは別の業務である。
11.3
変更管理
IT システムと，それが動作する環境は，絶えず変化している。これらの変化は，新しい特徴とサ
ービスの出現，あるいは新しい脅威や無防備な箇所の発生の結果である。これらの変化は，新し
い脅威及び無防備な箇所をもたらす可能性もある。IT システムの変化には次のようなものがある。
―
―
―
―
―
―
新しい手順。
新しい特徴。
ソフトウェアの更新。
ハードウェアの変更。
外部グループや匿名グループを含めるための新しいユーザ。
追加のネットワーク構築及び相互接続。
IT システムの変更が発生し，もしくは計画されている場合，その変化がシステムのセキュリティ
に対してどのような影響を及ぼすかを判定することが大切である。システムが構成管理ボード
（Configuration Control Board）又はその他技術上のシステムの変化を管理する組織構造を有し
ている場合は，IT システムセキュリティ責任者又はその代表者を任命し，変化がセキュリティに
影響を及ぼすか否か，及ぼすなら，どのように及ぼすかの判定を行なう責任を負わせなければな
らない。新しいハードウェア，ソフトウェア又はサービスの購入を含むような大きな変更につい
ては，新しいセキュリティの要件を判定するために分析が必要となる。一方，システムに加えら
れた多くの変更が小さく，大きな変化に対するような高度な分析を必要としない場合でも，何ら
かの分析は必要である。いずれかのタイプの変化についても，非公式に会議で行なうこともでき
るが，その結果と経営陣の決定は文書として記録しておかなければならない。
11.4
モニタリング
モニタリングは，システム，そのユーザ，及び環境が，IT セキュリティ計画で定めたとおりのレ
ベルのセキュリティを保っているか否かをチェックする進行中の業務である。日常のモニタリン
グのための計画は，日常のセキュリティ作業を確実に行なわせるための追加の指導と手順を提供
するように作成される。セキュリティ上の問題点全てを全面的に対象とし，IT セキュリティ計画
を常に更新された状態としておくように，ユーザ，運用担当者及びシステム設計者は定期的に打
合わせを行なわなければならない。
モニタリングが IT セキュリティの保守の重要な一部である理由の 1 つは，
それがセキュリティ関
連の変化を検知する方法だからである。モニタリングしなければならない事項をいくつか挙げる
と，資産とその価値，資産に対する脅威及び無防備な箇所並びに資産を保護するセーフガードで
30
ある。
資産がモニタリングされるのは，その価値の変化を検知し，IT システムのセキュリティ目標の変
化を検知するためである。このような変動の理由として考えられるのは，下記の変化である。
― 組織の事業上の目標。
― IT システムで実行されるアプリケーション。
― IT システムで処理される情報。
― IT 設備。
厳しさの変化（例えば，環境の変化によって生じたもの，インフラ又は技術上の可能性の変化な
ど）を検知し，また，早い段階でのほかの脅威や無防備な箇所の出現を検知するために，脅威及
び無防備な箇所がモニタリングされる。脅威と無防備な箇所の変化は，資産の変化の影響を受け
ることもあり得る。
セーフガードの働きと経時的な効果をチェックするために，セーフガードのモニタリングが行わ
れる。セーフガードが適切に必要なレベルの保護に応じて IT システムを保護するようにしなけれ
ばならない。資産，脅威及び無防備な箇所の変化がセーフガードの効果と適切さに影響を及ぼす
可能性がある。
さらに，新しい IT システムが導入された場合又は既存のシステムに変更が加えられた場合は，こ
のような変化が既存のセーフガードの状況に影響を及ぼさないように，また，適切なセキュリテ
ィセーフガードが設けられた上で新しいシステムが導入されるようにすることが必要である。セ
キュリティの異常が発見された場合，セーフガードをレビュー，又は深刻な状況な場合は，IT シ
ステムセキュリティポリシーのレビューを調査してリスク分析業務が開始されるように，経営陣
に知見を報告することが必要となる。
IT システムセキュリティポリシーを遵守するため，次に示すものの適正なレベルの日常的モニタ
リングを維持するために，適切な資源を手当てしなければならない。
― 既存のセーフガード
― 新しいシステム又はサービスの導入。
― 既存のシステム又はサービスの変更計画。
多くのセーフガードは，イベント発生のログという形で出力を生成する。これらのログは，トレ
ンドの変化を早期に検知し，反復して発生する事故を検知できるようにするために，統計的手法
を用いて分析しなければならない。このようなログの分析の責任を割り当てなければならない。
分散環境では，ログは単一の環境に関する情報を記録するだけである。複雑なイベントの性格を
真に理解するためには，様々なログからの情報をまとめて，単一のイベントの記録にする。これ
らの一体化されたイベントの記録を，次に分析する。イベント記録の一体化は複雑な作業であり，
そのもっとも重要な面は，様々なログ記録を信用できる組合せとすることを可能にするパラメー
タの確認である。
日常のモニタを管理するための管理手法は，必要な活動についてセキュリティ運営手順文書を作
成することである。この文書は，全てのシステム及びサービスについてのセキュリティのレベル
が維持され，時間の経過に従って，システム及びサービスとして劣化しないようにするのに必要
な全ての措置を説明している。
セキュリティ構成を更新するための手順を文書化する。これには，調整されたセキュリティパラ
メータと，セキュリティ運用情報の更新が含まれる。これらの変更を，構成運用プロセスによっ
て記録し，承認しなければならない。日常の保守を行なうための手順を確定して，セキュリティ
が低下しないようにする。信用分散手順は，該当する各セキュリティ構成要素について説明され
なければならない。
31
セキュリティセーフガードをモニタするための手順を説明することが必要である。セキュリティ
ログのレビューのアプローチと頻度を述べなければならない。統計分析の方法とツールの使用を
説明しなければならない。様々な運営条件にもとづいて，監査しきい値をどのようにして調査す
るかの指導をしなければならない。
11.5
事件／事故への対応
リスクを確認し，その厳しさを測定するために，リスク分析が必要であることを強調してきた。
リスク分析を支援し，結果を促進するためには，セキュリティ上の事故に関する情報が必要であ
る。この情報を確実な方法で収集し，分析し，利点を提供するものとしてみなければならない。
このように，どの組織も適切な構造と組織を持った IT 事故分析基準（IAS）を運営し，受け取っ
て処理した情報からリスク分析，運用及びその他のセキュリティ関連業務を支援するようにする
ことが大切である。
現在及び今後のユーザのニーズを十分にみたすために，IAS はユーザの要求に基づく構造を持つ
べきである。さらに，実際の運営の前に，IAS の構造，得られる利点及び得られた結果を下記の
ために使用できるようにするにはどうするかを関係者全員が理解するように，セキュリティ意識
向上プログラム中の事件／事故への対応の部分を多くとることが必要である。
―
―
―
―
リスク分析と管理レビューの改善
事故の予防を助ける。
IT セキュリティ関連問題の意識レベルを高める。
コンピュータ緊急対応チームなどで使用するための“警報”情報を提供する。
これらに関して，IAS が対象にするべき主な面は次のとおりである。
― 外部又は内部の論理的及び物理的アタック，若しくは偶然，装置の誤動作又は人のエラーのい
ずれによって生じたかにかかわらず，望ましくない事故が生じた場合に，それを扱うためのあら
かじめ定めた計画の確立。
― 例えば，コンピュータ緊急対応チームを形成するために，事故調査の要員を指名して訓練する。
コンピュータ緊急対応チームは，IT 事故の原因を調査し，将来の潜在的な事故発生を研究し又は
履歴データの定期的な検討と分析を行なう人々と定義されたグループとして，多少とも形式化さ
れている。このチームの結論によって，治癒的な措置が行なわれる。コンピュータ緊急対応チー
ムは，組織の内部でも外部（契約による）でもよい。
計画と訓練された要員がそろい，望ましくない事故が発生しつつある場合は，拙速な決定は避け，
事故の原因を追求し，確認するのに使える証拠を提示し，価値のある資産の保護がすみやかに確
立され，事故のみならず，対応の費用も節減される。さらに，否定的な広報をできるだけ少なく
する。
組織は，効率的な IAS を用意して，事故にそなえる。その範囲は次のとおりである。
― 準備 文書化以前の予防措置，偶発事故に対する対応の指針及び手順（証拠の保全，イベント
ログの維持及び広報の取扱いを含む）
，必要な文書及び事業継続計画。
― 通知 事故報告手順，手段責任及び提出先。
― 評価 事故を調査し，その深刻さの程度を判定する手順及び責任。
32
― 管理 事故を取扱い，その損害を抑制し，それを根絶し，上級経営者に通知する手順及び責任。
― 回復 通常のサービスを再確立する手順と責任。
― レビュー 事故後の措置の手順と責任。これには，法律上の意味の調査及びトレンド分析が含
まれる。
IAS の使用は，個々の組織にとって利点があるが，組織によっては，一部の事故情報を他の組織
と共有して，
“警報”を入手し，すみやかに傾向を確認し，予防措置を可能にするためのもっと広
汎な基礎を提供すれば，さらに大きな利点が得られると考えられる。これを容易にするためには，
IAS データベース構造を利用するべきである。これは，十分な柔軟性があって，全面的（全ての
部門，脅威のタイプ及び影響）かつ各部門毎の／脅威／影響に関する特定のニーズについて，広
い範囲の要件を対象とすることができる。組織内部，組織間を問わず，各接続 IAS は同様の類似
事例，測定基準及び構造を用いて，事故に関する情報を記録することとなる。これによって，比
較と分析が可能となる。共通の構造を使用することが，いっそう総合的な結果に到達し，特に，
個別の IAS では確認できなかったようなケースでは，
“警報”の迅速な確認のための堅固なベー
スが得られる鍵となる。
上記からも分かるように，IAS とリスク分析との間のインタフェースを作り上げ，管理方法が達
成されれば，結果は大幅に改善され，それによって IAS から得られる利点は増加する。
脅威の発生に関する情報は，脅威の評価，従ってリスクの評価の質を大幅に改善する。さらに，1
個もしくはそれ以上の事故の調査中，無防備な箇所及びそれを利用する方法に関して，新しく追
加の情報が集められるようである。IAS を利用すれば，ユーザは無防備な箇所を確認し，評価す
ることができ，従って，リスク分析アプローチに価値のある入力を提供することができる。これ
は，一部には，脅威に関して導入された情報にもとづき，また一部には，例えばコンピュータ緊
急対応チームなどによる事故調査の結果に関する情報に基づくものである。一例として，論理的
な侵入の脅威（アタッカーの存在，及び処理された情報の魅力）は論理的な侵入への脆弱性（適
切な論理的アクセス管理メカニズムが不適切であったり存在しなかったりする）と組み合わせる
ことがあり，これによってリスクが発生する。従って，無防備な箇所の確認と評価のために IAS
を使用することは，脅威情報の使用を通じて行なうことができる。このような脅威の情報は，す
でに報告された事故からデータベースに入力され，他の発生源からの情報と組み合わされ，特に
コンピュータ緊急対応チームの調査及び研究と組み合わされる。これは以前には確認されなかっ
た無防備な箇所を対象とはしていないと考えられる。
発生した事故に関して報告されたデータに従って，IAS が機能することに注意されたい。従って，
IAS は，存在はするが，まだ IT 事故中では明らかになっていない無防備な箇所について，直接に
情報を提供することはできない。さらに，IAS データは，統計及びトレンド分析では慎重に使用
しなければならない。入力が不完全，あるいは誤って確認された可能性があるからである。それ
にも拘らず，コンピュータ緊急対応チームの調査の結果は，それまでに予想していなかったよう
な無防備な箇所について，何らかの見方を提供することがある。全体として，リスク分析及び管
理レビューへの正規の IAS 入力は，
脅威，
リスク及び脆弱性評価の質の改善に役立つ場合がある。
12.
まとめ
標準情報(TR)群のこのパートでは，IT セキュリティマネジメントにとって重要ないくつかの手法
を検討した。これらの手法は，標準情報(TR)群の第 1 部で提供された概念とモデルおよび標準情
報(TR)群の第 2 部で考察したマネジメントプロセスと責任に基づくものである。標準情報(TR)群
のこのパートにおける考察では，リスク分析を行うに当たってとりうる 4 つの戦略のメリットお
よびデメリットをそぞれぞれ示した。そして，その実施に役立つ組合せアプローチおよびいくつ
かの手法を詳細に記述した。一部の組織，特に小規模組識では，標準情報(TR)群のこのパートで
提供された全ての手法を，正確に記述とおりの方法で実施することはできないかもしれない。し
かし，これらの手法それぞれをその組織に適した方法で実行することが重要なのである。
33
附属書 A
全社的 IT セキュリティポリシーの目次の例
目次
1.
はじめに
1.1 概説
1.2 IT セキュリティポリシーの適用範囲と目的
2.
セキュリティの目的と原則
2.1 目的
2.2 原則
3.
セキュリティ組織／インフラ
3.1 責任
3.2 セキュリティポリシー
3.3 セキュリティの事件／事故の報告
4.
IT セキュリティ／リスク分析およびマネジメント戦略
4.1 はじめに
4.2 リスク分析とマネジメント
4.3 セキュリティの遵守状況のチェック
5.
情報の重要性とリスク
5.1 はじめに
5.2 情報の重要度分類手法
5.3 組織における情報の概要
5.4 組織における情報の価値／重要性レベル
5.5 脅威／ぜい（脆）弱性／リスク概要
6.
ハードウェアおよびソフトウェアのセキュリティ
6.1 識別と認証
6.2 アクセス管理
6.3 利用管理と監査証跡
6.4 完全な削除
6.5 悪意のあるソフトウェア
6.6 PC セキュリティ
6.7 ラップトップのセキュリティ
7.
通信セキュリティ
7.1 はじめに
7.2 ネットワークインフラ
7.3 インターネット
7.4 暗号化およびメッセージ認証
8.
物理的セキュリティ
8.1 はじめに
8.2 設備の場所
8.3 建物のセキュリティと保護
8.4 建物サービスの保護
34
8.5 支援サービスの保護
8.6 不正な占有
8.7 PC およびワークステーションへのアクセス可能性
8.8 磁気媒体へのアクセス
8.9 スタッフの保護
8.10 火災の延焼対策
8.11 水および液体対策
8.12 危険の検知と報告
8.13 落雷対策
8.14 機器の盗難対策
8.15 環境保護
8.16 サービスおよび保守の管理
9.
人事セキュリティ
9.1 はじめに
9.2 雇用条件
9.3 セキュリティ意識の向上と訓練
9.4 従業員
9.5 契約社員
9.6 第三者
10.
文書および記録媒体のセキュリティ
10.1 はじめに
10.2 文書セキュリティ
10.3 記録媒体の保管
10.4 記録媒体の廃棄
11.
障害対策計画／災害復旧戦略と計画を含む事業の継続性
11.1 はじめに
11.2 バックアップ
11.3 事業継続戦略
11.4 事業継続計画
12.
テレワーキング
13.
アウトソ−シングポリシー
13.1 はじめに
13.2 セキュリティ要件
14.
変更管理
14.1 フィードバック
14.2 セキュリティポリシーの変更
14.3 文書状況
附属書
A. セキュリティガイドのリスト
B. 法令と規則
C. 組識の IT セキュリティ責任者の責任範囲
D. IT セキュリティフォーラムまたは委員会の責任範囲
E. IT システムセキュリティポリシーの内容
35
附属書 B
資産の評価
組織の資産の評価は，リスク分析プロセス全体において不可欠なステップである。各資産に与え
られる価値は，その資産および関係する事業組識に関連した用語で表現される必要がある。資産
の評価を行なうためには，組織はまず，その資産全てを洗い出すことが必要である。すべての資
産が洗いだされたことを確認するために，資産を情報資産，ソフトウェア資産，物理的資産，お
よびサービスなどのタイプ別にグループ分けすることが有用である。これはまた，資産の価値を
決定する責任を負うこととなる資産の所有者を任命するのに役に立つ。
次のステップは，個々の資産に評価を与えるために使用する尺度と基準について合意することで
ある。ほとんどの組織内における資産は非常に多様である。したがって，既知の金銭的価値を有
する一部の資産は，現地通貨で評価し，一方，その他の多くの定性的な価値を有する資産には，
たとえば“非常に低い”から“非常に高い”といったような例の範囲で評価を与える。定量的な
評価方法，あるいは定性的な評価方法を使用するかの決定は，組織の選択の問題であるが，評価
される資産にも関連する。同一の資産について両方の評価方法を用いることもできる。
資産の定性的評価に用いられる典型的な用語としては次のようなものがある。無視できる，非常
に低い，低い，中くらい，高い，非常に高い，および重大。1 つの組織に適した用語の選択と範
囲は，組織のセキュリティのニーズ，組織の規模，およびその他の組織特有の要因に強く依存し
ている。
各資産に評価を与えるために用いられる基準は，まぎらわしくない用語である必要がある。この
ことは，資産の評価において最も難しい面のひとつである。なぜなら，一部の資産の価値は主観
的に判定されるしかなく，多くの異なった個人がそれぞれの判定を行ないがちであるからである。
元の費用，その資産を他のものと置き換えたり，再度作成する費用あるいはその有用性を含む資
産の価値を判定するために可能な基準は抽象的なものになってしまう。たとえば企業の名声また
は評判といったようなものである。
資産の評価のためのもう 1 つの要素は，事故の結果としての機密性，完全性および可用性の喪失
により発生するコストである。このような評価は，交換コストのほかに，資産の評価に３つの重
要な特性を与える。それらは，ある仮定された状況のもとにおけるセキュリティ事故の結果生じ
ると思われる潜在的損害または事業への悪影響の見積り額に基づくものである。このアプローチ
では，リスク評価の方程式の要素として損害およびその他の影響の費用を考慮することが必要と
される。
多くの資産は，評価の過程でいくつかの価値が割り当てられることがある。たとえば，事業計画
は，計画作成に費やされた労働にもとづき価値が与えられる。また，競合企業に対してどれ位の
価値があるかにもとづいて価値が割り当てられることもある。これらの価値それぞれは，大きく
異なる。割り当てられた価値は，全ての考えうる価値の最大であるか，また，考えうる価値のい
くつかの合計あるいはすべての合計かもしれない。最終的な分析では，資産に割り当てられる価
値を慎重に決定しなければならない。なぜなら割り当てられた最終的な価値は，資産の保護のた
めに用いられる資源の決定につながるからである。
最後に，資産評価は全て共通の基準にすることが必要である。これは，次に掲げるような基準を
用いて行なってもよい。資産の機密性，完全性および可用性の喪失の結果生じる可能性のある損
害を評価するのに使用することのできる基準には次のようなものがある。
―
―
―
―
法律および／または規制への違反
事業効率の悪化
営業権の損失／評判への否定的な影響
個人情報に関連する違反
36
―
―
―
―
―
―
―
個人の安全の危機
法律執行上の悪影響
取引上の機密保持契約違反
公共の秩序への違反
財務上の損失
事業活動の中断
環境の安全の危機
これらの基準は，資産評価のために考慮されるべき問題の例である。評価を行なうためには，組
織は，その事業のタイプとセキュリティの要件に関連する基準を選ぶ必要がある。これは，上述
した基準の一部が適用できないこと，およびリストに他の基準を追加する必要がある場合もある
ことを意味している。
考慮すべき基準を確立した上で，組織は，組織全体で使用すべき尺度について合意しなければな
らない。最初のステップは，使用するレベルの数について決定することである。最も適切なレベ
ルの数についてルールはない。レベルが多ければ，きめ細かくはできるが，差別化が細かすぎる
と，組織全体を通じて一貫した作業を行なうことが困難になる。通常は，全体のリスク評価プロ
セスに組織が使用しているアプローチと矛盾しない限りは，3 段階（たとえば，低，中，高）か
ら 10 段階のレベルが使用されている。
また，組織は，
“低い”
，
“中くらい”
，または“高い”のように，資産価値のための組織固有の範
囲を決めることができる。これらの範囲は，選択した基準にしたがって評価しなければならない。
たとえば，財務上の損失については，金銭的価値で範囲を決めなければならないが，個人の安全
の危機を考える場合は，金銭的価値は適当ではない。最後に，どのような損害を“低”とし，あ
るいは“高”とするかは各組織が決めるべき事柄である。小規模な組織にとっては致命的な損害
であっても，大規模な組織にとっては，無視できる程度であることもあるからである。
37
附属書 C
考えうる脅威のタイプのリスト
次のリストは，典型的な脅威の例を示すものである。このリストは，脅威の評価の過程で使用す
ることができる。脅威は，1 つまたはそれ以上の故意，偶発的または環境（自然）の事象によっ
て起こり得る。次のリストは，それぞれの脅威のタイプを示しており，また D（故意的）
，A（偶
発的）
，E（環境）のどの事象に関連しているかを表わしている。D は，IT 資産を目標とした故意
の行為に使用され，A は，IT 資産に偶発的に損傷を与え得る全ての人的行為に使用され，E は，
人の行為に基づくものではない全ての事故に使用されている。
地震 E
洪水 D，A，E
台風 E
落雷 E
争議行動 D，A
爆破行為 D，A
武器の使用 D，A
火事 D，A
故意の損害 D
停電 A
断水 A
空調故障 D，A
ハードウェアの故障 A
電力の不安定 A，E
極端な温度および湿気 D，A，E
ほこり E
電磁波放射 D，A，E
静電荷 E
盗難 D
記憶媒体の不正使用 D
記憶媒体の劣化 E
操作員のエラー D，A
保守のエラー D，A
ソフトウェアの故障 D，A
不正なユーザによるソフトウェアの使用 D，A
不正な方法でのソフトウェアの使用 D，A
ユーザ ID の偽り D
ソフトウェアの違法な使用 D，A
悪意のあるソフトウェア D，A
違法なソフトウェアの輸入／輸出 D
操作員のエラー D，A
保守のエラー D，A
不正なユーザ−によるネットワークへのアクセス D
不正な方法でのネットワーク設備の使用 D
ネットワーク構成要素の技術的障害 A
送信エラー A
回線の損傷 D，A
38
トラフィックのオーバーロード D，A
盗聴 D
通信への侵入 D
トラフィック分析 D
メッセージの経路選択の誤り A
メッセージの経路変更 D
否認 D
通信サービス（ネットワークサービス）の障害 D，A
スタッフ不足 A
ユーザのエラー D，A
資源の誤用 D，A
39
附属書 D
一般的なぜい（脆）弱性の事例
次のリストは，さまざまなセキュリティ領域における脆弱性の例を示す。リストには，これらの
ぜい（脆）弱性に付けこむ脅威の例を含んでいる。このリストは，ぜい（脆）弱性の評価の助け
となる。また，ある場合においては，他の脅威がこれらのぜい（脆）弱性につけ込む可能性があ
ることを考慮すべきである。
1. 環境および基礎構造
建物，ドアおよび窓の物理的保護の欠如
（たとえば，盗難という脅威に付け込まれうる）
建物，部屋への物理的アクセス管理の不適当または不注意な使用
（たとえば，故意の損傷という脅威に付け込まれうる）
不安定な電力配電網
（たとえば，電力不安定という脅威に付け込まれうる）
洪水の影響を受けやすい地域への配置
（たとえば，洪水という脅威に付け込まれうる）
2. ハードウェア
定期的な交換計画の欠如
（たとえば，記憶媒体の劣化という脅威に付け込まれうる）
電圧の変化に対する影響の受けやすさ
（たとえば，電力不安定という脅威に付け込まれうる）
温度変化に対する影響の受けやすさ
（たとえば，極端な温度という脅威に付け込まれうる）
湿気，ホコリ，汚れに対する影響の受けやすさ
（たとえば，ホコリという脅威に付け込まれうる）
電磁放射に対する影響の受けやすさ
（たとえば，電磁放射という脅威に付け込まれうる）
記憶媒体の不十分な保守／不適当な設置
（たとえば，保守エラーという脅威に付け込まれうる）
有効な構成変更管理の欠如
（たとえば，操作スタッフのエラーという脅威に付け込まれうる）
3.ソフトウェア
開発者のための不明確または不完全な仕様書
（たとえば，ソフトウェア障害という脅威に付け込まれうる）
ソフトウェアのテストをしない，または不十分なソフトウェアのテスト
（たとえば，不正なユーザによるソフトウェア使用という脅威に付け込まれうる）
複雑なユーザインタフェース
（たとえば，操作スタッフのエラーという脅威に付け込まれうる）
ユーザの識別および認証メカニズムの欠如
（たとえば，ユーザのなりすましという脅威に付け込まれうる）
監査証跡の欠如
（たとえば，不正な方法でのソフトウェア使用という脅威に付け込まれうる）
ソフトウェアの公知の欠陥
（たとえば，不正なユーザによるソフトウェア使用という脅威に付け込まれうる）
保護されていないパスワードファイル
（たとえば，ユーザのなりすましという脅威に付け込まれうる）
不充分なパスワード管理（簡単に推測できるパスワード，平文でのパスワードの保管，不十分な
頻度での変更）
40
（たとえば，ユーザのなりすましという脅威に付け込まれうる）
アクセス権の誤った割り当て
（たとえば，不正な方法でのソフトウェア使用という脅威に付け込まれうる）
管理されていないソフトウェアのダウンロードおよび使用
（たとえば，不当なソフトウェアという脅威に付け込まれうる）
ワークステーションから離れる際に“ログアウト”しない
（たとえば，不正なユーザによるソフトウェア使用という脅威に付け込まれうる）
効果的な変更管理の欠如
（たとえば，ソフトウェアの故障という脅威に付け込まれうる）
文書化の欠如
（たとえば，操作スタッフのエラーという脅威に付け込まれうる）
バックアップコピーの欠如
（たとえば，悪意のあるソフトウェアという脅威または火災という脅威に付け込まれうる）
適切に削除されていない記憶媒体の処理または再利用
（たとえば，不正なユーザによるソフトウェア使用という脅威に付け込まれうる）
4. 通信
保護されていない通信回線
（たとえば，盗聴という脅威に付け込まれうる）
ケーブル接続の欠陥
（たとえば，通信への侵入という脅威に付け込まれうる）
送信元および受信者の識別と認証の欠如
（たとえば，ユーザのなりすましという脅威に付け込まれうる）
平文でのパスワードの転送
（たとえば，不正なユーザによるネットワークアクセスという脅威に付け込まれうる）
メッセージ送受信の証明の欠如
（たとえば，否認という脅威に付け込まれうる）
ダイヤルアップ回線
（たとえば，不正なユーザによるネットワークアクセスという脅威に付け込まれうる）
保護されない重要度の高いトラフィック
（盗聴という脅威に付け込まれうる）
不適切なネットワーク管理（経路指定の回復）
（トラフィックの過負荷という脅威に付け込まれうる）
保護されない公衆回線への接続
（不正なユーザによるソフトウェア使用という脅威に付け込まれうる）
5. 文書
保護されない保管
（たとえば，窃盗という脅威に付け込まれうる）
廃棄時の注意欠如
（たとえば，窃盗という脅威に付け込まれうる）
管理されないコピー作成
（たとえば，窃盗という脅威に付け込まれうる）
6. 人事
要員の不在
（たとえば，要員不足という脅威に付け込まれうる）
外部または清掃スタッフによる作業時の監督不在
（たとえば，窃盗という脅威に付け込まれうる）
41
不十分なセキュリティ訓練
（たとえば，運用スタッフのエラーという脅威に付け込まれうる）
セキュリティ意識の欠如
（たとえば，ユーザエラーという脅威に付け込まれうる）
ソフトウェアおよびハードウェアの正しくない使用
（たとえば，運用スタッフのエラーという脅威に付け込まれうる）
モニターのしくみの欠如
（たとえば，不正な方法でのソフトウェアの使用という脅威に付け込まれうる）
遠隔通信媒体およびメッセージ伝達の正しい使用のためのポリシーの欠如
（たとえば，不正な方法によるネットワーク設備の使用という脅威に付け込まれうる）
不適切な採用手続
（たとえば，故意による損害という脅威に付け込まれうる）
7. 一般に適用されるぜい（脆）弱性
単一の障害点特性（Single point of failure）
（たとえば，通信サービスの故障という脅威に付け込まれうる）
不適切なサービス保守の対応
（たとえば，ハードウェア故障という脅威に付け込まれうる）
42
附属書 E
リスク分析手法のタイプ
リスク分析にはここで，あるいはこの標準情報（TR）群の他の部で検討してきた多くの段階があ
る。。それらの段階とは次のとおりである。
― 資産の特定と評価（事業に対する潜在的な悪影響の評価）
― 脅威の評価
― ぜい（脆）弱性の評価
― 既存の／計画中のセーフガードの評価
― リスクの評価
最終段階は全体としてのリスクを評価するものであり，この 附属書が焦点を当てている点である。
以前にも確認したように，価値を有し，かつある程度の脆弱性をもつ資産は，資産に対する脅威
が存在すれば，いつでもリスクにさらされていることになる。リスクの評価は，潜在的な望まし
くない事故による事業への悪影響と，評価された脅威およびぜい（脆）弱性のレベルの組み合わ
せである。リスクとは，実際にシステムおよび関連組織が損失を被るかもしれない可能性の程度
である。リスクは，下記の事項の関数である。
―
―
―
―
ド
資産価値
脅威と，それに関連した発生可能性で，資産に脅威を与えるもの
望ましくない影響を生じさせる脅威のぜい（脆）弱性への付け込みやすさ
ぜい（脆）弱性，脅威および影響度の重大さを低減する既存の，もしくは計画中のセーフガー
リスク分析の目的は，IT システムおよびその資産がさらされているリスクを特定し，評価して，
適切かつ正当化されたセキュリティのセーフガードを確認し，選択することである。リスクを評
価する場合，影響と発生可能性を含めて，いくつかの面を考慮する。
影響は，いくつかの方法で評価されるが，これには，量的，たとえば金銭的尺度を用いるもの，
質的な尺度を用いるもの（中位の，とか耐え難いといった形容詞の使用に基づくことができる），
またはこの両方の組み合わせなどである。脅威の発生の可能性を評価するために，資産が価値を
持ちつづけるか，または保護を必要とする時間枠を確定しなければならない。脅威の発生可能性
は，下記の影響を受ける。
1. 資産の魅力で，故意による人間の脅威を考える場合に適用される
2. 資産を報酬に換算する容易さで，故意による人間の脅威を考える場合に適用される
3. 脅威動因の技術的能力で，故意による人間の脅威に適用される
4. 脅威の発生見込み
5. ぜい（脆）弱性の影響の受けやすさで，技術的および非技術的双方のぜい（脆）弱性に適用
される
多くの方法は，表を利用し，主観的な尺度と経験による尺度を組み合わせている。現在のところ，
どの方法が正しくて，どの方法が間違っているということはない。組織が満足でき，信用でき，
かつ再現性のある結果が得られるということの方が大切である。表に基づく手法のいくつかの例
を下記に示す。
事例 1 あらかじめ定義された値を用いるマトリックス
この種のリスク分析では，現実又は導入予定の物理的資産に，交換又は再構築のコストにもとづ
いて評価される（すなわち，量的測定）
。これらのコストを，データ資産（次を参照）で用いられ
るのと同じ質的尺度に変換する。現行又は導入予定のソフトウェア資産は，購入又は再構築のコ
ストを確認することにより，物理的資産の場合と同じ方法で評価され，データ資産で用いられる
43
のと同じ質的尺度に変換される。さらに，機密性又は完全性に対して，アプリケーションソフト
ウェアに固有の要求事項があると分かる場合（たとえば，ソースコード自体が取引上重要度が高
い場合），データ資産の場合と同じ方法で評価される。
データ資産の価値は，実際に使用する時にデータの価値及び重要度を決定するためのデータ，若
しくは格納，処理又はアクセスされるデータについて権威を持って話すことのできる選ばれたビ
ジネス担当者（
“データ所有者”
）にインタビューすることによって入手する。インタビューは，
無許可開示，無許可の修正，拒絶，不定期な使用不可能及び破壊によるビジネス上のインパクト
から発生することが予想される最悪な事態のシナリオの観点から，データ資産の価値及び重要度
の評価を容易にする。
評価は，データ資産評価指針を用いて行なわれるが，これは次を含んでいる。
―
―
―
―
―
―
―
―
―
個人の安全。
個人情報。
法制度上の義務。
法律の実施。
取引上および経済上の関心。
財務上の損失／活動の分列。
公共の秩序。
事実上のポリシーおよび運用。
信用の喪失。
ガイドラインにしたがうことによって，後述の例のマトリックスに示されている 1∼4 のような数
的なスケールで価値を特定することが容易になる。すなわち，可能及び論理的である場合，量的
価値を認識することができ，
（たとえば生命の危機のように）量的評価が不可能な場合，質的価値
を認識することができる
次の重要な作業は，脅威のレベル（発生の可能性）及びぜい弱性のレベル（インパクトを及ぼす
脅威による利用の容易さ）の評価を可能にするために，脅威ごとに，すなわち，関連する脅威で
分けられた資産のグループごとに，質問状を完成させる。各質問への回答に点数がつけられる。
これらの点数は，知識にもとづいて累積され，範囲が比較される。これによって，たとえば“高”
から“低”の尺度で脅威のレベルを特定でき，同様にぜい弱性のレベルを特定することができる。
インパクトのタイプによって異なるが，この例を後述のマトリックスに示す。質問状に記入され
る情報は，該当する技術，要員及び業務担当者，並びに物理的なロケーション検査及び文書レビ
ューによって収集すべきである。
考慮するべき脅威のタイプを次のようにグループ分けする。人による計画的な無許可の行為，不
可抗力，人によるエラー及び設備／ソフトウェア／回線の故障。
資産の価値，並びに各インパクトのタイプごとに適した脅威及びぜい弱性のレベルを，次に示す
ように関連するリスクの度合いとスケール 1∼8 の尺度の組み合わせを特定するためのマトリッ
クスに適応させる。これらの値を構造化した方法でマトリックスにセットする。例を次に示す。
44
表1
低
脅威レベル
ぜい弱性のレベル
資産価値
０
１
２
３
４
中
高
低
中
高
低
中
高
低
中
高
０
１
２
３
４
１
２
３
４
５
２
３
４
５
６
１
２
３
４
５
２
３
４
５
６
３
４
５
６
７
２
３
４
５
６
３
４
５
６
７
４
５
６
７
８
各資産について，関連するぜい弱性及び対応する脅威を考慮する。対応する脅威のないぜい弱性
がある場合又は対応するぜい弱性のない脅威がある場合，現在のところリスクはない。
（しかし，
この状況が変る場合は注意すべき。
）マトリックス中の行は，資産価値によって特定し，列は，脅
威及びぜい弱性の厳しさによって特定する。たとえば，資産価値が 3，脅威は“高”及びぜい弱
性は“低”の場合，リスクの値は 5 である。たとえば，改修によって，資産価値が 2，脅威レベ
ルは“低”及びぜい弱性は“高”の場合，リスクは 4 である。脅威の厳しさの分類，ぜい弱性の
厳しさの分類及び資産評価の分類によるマトリックスのサイズは，組織の必要性に応じて調整す
ることができる。追加の列及び行を加える場合，リスクの度合いを追加することが必要である。
このアプローチの価値は，対象とするリスクの等級分けにある。
事例 2 リスクの度合いによる脅威の階級
マトリックス又は表を使用することにより，インパクト要因（資産価値）と脅威の発生の可能性
（ぜい弱性も考慮に入れる）を関連づけることができる。第 1 のステップは，脅威を受けている
資産（表では例 b）のそれぞれについて，あらかじめ定めた尺度，たとえば 1∼5 で，インパクト
（資産価値）を評価することである。第 2 のステップは，脅威（表中の例 c）のそれぞれについ
て，あらかじめ定めた尺度，たとえば 1∼5 で，脅威の発生の可能性を評価することである。第 3
のステップは，積算（b × c）によってリスクの度合いを計算することである。最後に，脅威を危
険にさらされている順でランク付けすることができる。この例では，1 が最低のインパクトであ
り，発生可能性が最も低い。
45
表2
脅威記述子(a)
脅威Ａ
脅威Ｂ
脅威Ｃ
脅威Ｄ
脅威Ｅ
脅威Ｆ
インパクト（資 脅威発生の可能性
リスクの度合い 脅威の階級(e)
産）値(b)
(c)
(d)
５
２
１０
２
２
４
８
３
３
５
１５
１
１
３
３
５
４
１
４
４
２
４
８
３
表２に示すように，これは，さまざまなインパクト及び様々な発生の可能性のある脅威を比較及
びここで示すような優先順位でランク付けを可能とする手順である。場合によっては，金銭的価
値を，ここで使用した経験値の尺度と関連づけることも必要となる。
事例 3 リスクの頻度及び考えられる損害の価値評価
この事例では，不要な事件のインパクト及びどのシステムに優先順位を与えるべきかの決定に
重点が置かれている。これは，それぞれの資産及びリスクについて 2 個の値を評価することによ
って行われ，これらの組合せによって各資産の点数を判定する。システムのための資産の点数を
全て加算すると，その IT システムに対するリスクの度合いが決定される。
まず，各資産に 1 つの値を割り当てる。この値は，資産に対する脅威が発生した場合，起こり得
る潜在的な損害に関するものである。資産に適用可能な脅威のための資産値を，資産に割り当て
る。
次に，頻度値を評価する。これは，脅威の発生の可能性及びぜい弱性の悪用のしやすさを組み合
わせて評価される。表 3 参照。
表3
脅威の
レベル
ぜい弱性の
レベル
頻度値
低
中
低
中
０
１
高
２
高
低
中
高
低
中
高
１
２
３
２
３
４
次に，表 4 で資産及び頻度値の交わる点を求めることによって，資産／脅威の点数を割り当てる。
資産／脅威の点数を合計して資産合計点を算出する。この図は，システムの一部をなす資産間の
差別化に用いることができる。
表4
資産値
頻度値
０
１
２
３
４
０
１
２
３
４
０
１
２
３
４
１
２
３
４
５
２
３
４
５
６
３
４
５
６
７
４
５
６
７
８
46
最終ステップは，システムの個々の資産の点数をすべて合計して，システムの点数を算出する。
これは，複数のシステムを差別化し，どのシステムの保護に優先順位を与えるべきかを決定する
のに用いることができる。
次の事例では，全ての値は，無作為に選択されている。
システム S は，3 つの資産 A1，A2 及び A3 を有していると仮定する。システム S に適用可能な 2
つの脅威 T1 及び T2 もあると仮定する。A1 の値は 3 とし，同様に A2 の資産値は 2 及び A3 の資
産値は 4 とする。
A1 及び T1 については，脅威の発生可能性は低く，ぜい弱性の悪用のしやすさが中の場合，頻度
値は 1 とする。
（表 3 参照。
）
資産／脅威の点数 A1／T1 は，表 4 から資産値 3 及び頻度値 1 の交点すなわち 4 として導くこと
ができる。同様に，A1／T2 については，脅威の発生可能性は中で，ぜい弱性の悪用のしやすさ
が高の場合，A1／T2 の点数は 6 となる。
合計資産点数 A1T，すなわち 10 を算出することができる。合計資産点数を，資産及び対応する
脅威のそれぞれに対して計算する。合計システム点数は，A1T＋A2T＋A3T を加算して ST とす
る。
異なるシステムは，優先順位を決定するために比較され，1 つのシステム中の異なった資産も優
先順位を決定するために比較される。
事例 4 許容可能リスク及び許容不可リスクの区別
リスクを測定するもう 1 つの方法は，許容可能リスク及び許容不可リスクだけを区別することで
ある。この方法の背景には，リスクの度合いは，処置必要性の緊急度でリスクを階級付けるとき
だけに使用されるということがあり，これは，大した苦労もなく達成できる。
このアプローチでは，容易に利用できるマトリクスは，数値ではなく対応するリスクを許容可能
（T）又は否（N）かを示す記号だけを含む。たとえば，方法 3 のマトリクスは次のように変更す
ることができる。
表５
損害値
頻度値
０
１
２
３
４
０
１
２
３
４
Ｔ
Ｔ
Ｔ
Ｔ
Ｎ
Ｔ
Ｔ
Ｔ
Ｎ
Ｎ
Ｔ
Ｔ
Ｎ
Ｎ
Ｎ
Ｔ
Ｎ
Ｎ
Ｎ
Ｎ
Ｎ
Ｎ
Ｎ
Ｎ
Ｎ
これは，単なる事例であり，許容可能リスク及び許容不可リスクの境界線をどこに引くかは，読
者に任されている。
47
TR X 0036-3 ：2001
（ISO/IEC TR 13335-3 :1998）
IT セキュリティマネジメントのガイドライン−
第 3 部：I T セ キ ュ リ テ ィ マ ネ ジ メ ン ト の た め の 手 法
解説
この解説は，本体及び附属書に記載した事柄，並びにこれらに関連した事柄を説明するもので，
標準情報の一部ではない。
1. 公表の経緯 情報化社会の発展に伴い，各種の事業活動が IT システムに大きく依存するよう
になってきた。このため，情報およびコンピュータ等の重要な資産を扱う IT システムを高い信頼
性のもとで運用・管理することが必要となり，IT システムのための体系的なセキュリティマネジ
メントの確立が急務となっている。
このような状況の中, ISO/IEC によって， ISO/IEC TR 13335‐ 3:1997（ Information
technology− Guidelines for the management of IT Security− Part3 : Technique for the
management of IT Security）が公表された。
この標準化活動は， ISO/IEC JTC1/SC27/WG1 において審議されたが，日本も当初からこの
審議に参画し，多くのコメントを提出し，その作成に寄与してきた。
この標準化活動の完了を受けて，2000 年度から，財団法人日本規格協会では工業技術院の委託
により，情報システムのセキュリティ技術の標準化調査研究委員会を設置して標準情報（TR）の
原案作成を行った。
この標準情報は，TR X 0036-3:2001 として公表するものである。
2. 概要 この標準情報群（TR X 0036）は，IT セキュリティマネジメントの枠組みについて記
述したものであり，第 1 部，第 2 部，第 3 部，第 4 部及び第 5 部から構成されている。
第 1 部 “IT セキュリティの概念及びモデル”では IT セキュリティの基本概念を，第 2 部 “IT
セキュリティのマネジメント及び計画”では IT セキュリティのマネジメント及び計画に関する行
動，並びに役割及び責任に関する内容を，第 3 部 “IT セキュリティマネジメントのための手法”
では IT セキュリティマネジメントを成功させるための推奨する手法を，第 4 部 “セーフガード
の選択”では適切なセーフガードを選択するためのガイドを，最後の第 5 部 “ネットワークセキ
ュリティにおけるマネジメントのガイダンス”では外部との接続及びそれから得られるサービス
を保護するためのセーフガードの選択及びその使用方法等をそれぞれ取り上げている。なお，第
5 部については，ISO/IEC JTC1/SC27/WG1 において現在審議中である。
第 3 部 IT セキュリティマネジメントのための手法では，IT セキュリティのマネジメントを成
功させるための手法を示し，推奨することを目的としており，リスク分析を行うにあたって取り
得る 4 つの戦略（ベースラインアプローチ，非形式的アプローチ，詳細リスク分析及び組合せア
プローチ）のメリット及びデメリットをそれぞれ示している。そして，リスク分析の実施に役立
つ組合せアプローチ及びいくつかの手法を詳細に記述している。一部の組織，特に小規模組識で
は，この標準情報群の第 3 部で提供された全ての手法を，正確に記述とおりの方法で実施するこ
とはできないかもしれない。しかし，重要なのは，これら各手法をその組織に適した方法で実施
することである。
3. その他解説事項
3.1 翻訳における考慮事項
−原標準情報群（ISO/IEC TR 13335）の翻訳にあたり，たとえ原語（英語）に対する日本工業標
準において用いる訳語（日本語）が定義されている場合であっても，一般の文脈でその原語を
カタカナで表記することの方が多いとき又はそれが読者の利便に資すると判断されたときは，
敢えてこの方法を用いた。
−原標準情報群でしばしば用いられている“management”の訳語としては，それが高次又は広
義の意味で用いられている場合には“マネジメント”を採用し，それ以外の場合には“管理”
1
を用いることを原則とした。例えば，セキュリティマネジメント・リスクマネジメントなどと
訳出したものは前者に属し，要員管理・変更管理などとしたものは後者に属する。しかしなが
ら明確に区別しにくい場合も多く，そのときは“マネジメント”をあてていることが多い。
−可能な限り分かりやすい翻訳を目指したが，原文を対照形式で添えて発行して，読者が原文を
容易に確認できるようにした。
3.2 ISO における継続審議状況
−2001 年 1 月現在，TR 13335-5 は審議中である。
−2001 年 1 月現在，TR 13335-1：1996 は改訂作業が行われている。
3.3 用語
3.3.1 用語の定義 この標準情報群で用いる用語は，
この標準情報群の第 1 部3.で定義している。
参考のため，ここに転載する。形式は次のとおり。
原国際標準情報の箇条番号；日本語の用語；
（原国際標準情報の用語）
；日本語の定義
3.1 責任追跡性（accountability）:あるエンティティの動作が，そのエンティティに対して一
意に追跡できることを主張する特性。(JIS X 5004:1991)。
3.2
資産（asset）: 組織に対して価値を持つもの。
3.3 真正性 （authenticity）: 対象またはリソースが要求されているものと同一であること
を保証する特性。真正性は，ユーザ，プロセス，システム，情報などのエンティティに対して
適用する。
3.4 可用性 （availability）: 許可されたエンティティによって要求されたときにアクセスと
使用が可能な特性(JIS X 5004 :1991)。
3.5 ベースラインコントロール（baseline controls）: システムまたは組織のために必要とさ
れる最低限のセーフガード。
3.6 機密性（confidentiality）: 許可されていないの個人，エンティティ，またはプロセスに
対して情報を使用不可または非開示にする特性(JIS X 5004 :1991)。
3.7 データ完全性（data integrity）: 許可されていない方法でデータが改ざんまたは破壊され
ていない特性(JIS X 5004 :1991)。
3.8 影響（impact）: 好ましくない偶発事故の結果。
3.9 完全性（integrity）: データ完全性及びシステム完全性を参照。
3.10 IT セキュリティ（IT security）: 機密性，完全性，可用性，責任追跡性，真正性，及び
信頼性の定義，達成，維持に関するすべてのセキュリティ（aspects）
。
3.11 IT セキュリティポリシー（IT security policy）: 組織及びその IT システムの範囲内で，
重要情報を含む資産をどのように管理，保護，及び分配するかを統制する規則，指令，及び実
践。
3.12 信頼性（reliability）: 矛盾のない計画とおりの動作及び結果を確保する特性
3.13 残存リスク（residual risk）: セーフガードが実施されたあとに残存するリスク。
3.14 リスク（risk）:
2
ある脅威が，資産または資産グループのぜい（脆）弱性を利用して，資産への損失，または損
害を与える可能性
3.15 リスク分析（risk analysis）: セキュリティリスクの識別，セキュリティリスクの程度の
判定，及びセーフガードが必要な領域の識別を実行するプロセス。
3.16 リスクマネジメント（risk management）: IT システムの資源に影響を及ぼす不確かな
事象を識別，制御，除去，または低減する総合的なプロセス。
3.17 セーフガード（safeguard）: リスクを低減する実践，手順，またはメカニズム。
3.18 システム完全性（system integrity）: システムが，意図的または偶発的な不正の操作か
ら妨害されることなく，本来果たすべき機能を滞りなく実行する特性。
3.19 脅威（threat）: システムまたは組織に危害を与える，好ましくない偶発事故の潜在的な
原因。
3.20 ぜい（脆）弱性（vulnerability）: 脅威によって影響を受け得る資産または資産グループ
の弱さ。
3.3.2 訳語 この標準情報群では，この標準情報群の第 1 部 3.で定義された用語以外に，次の訳
語を使用した。
原語
administration
assessment
assessment of risk
authentication
awareness
baseline approach
basic assessments
change management
code of practice
combined approach
commitment
configuration
configuration control
configuration management
contingency plans
corporate IT security officer
corporate IT security policy
cryptography
destructive attack
detailed Risk Analysis
disaster Recovery
eavesdropping
electromagnetic radiation
employee
evaluation
fire, water
訳語
管理
評価、または分析（状況によって使い分ける）
リスクの評価
認証
意識、意識向上
ベースラインアプローチ
基本評価
変更管理
実践規範
組合わせアプローチ
コミットメント
構成
構成制御
構成マネジメント
障害対策計画
企業のITセキュリティ責任者
全社的ITセキュリティポリシー
暗号技術
破壊的攻撃
詳細リスク分析
災害復旧
盗聴
電磁放射
従業員
評価、または分析（状況によって使い分ける）
水害、災害
3
follow-up
high level risk analysis
identification
implementation of safeguards
implementation
incident handling
informal approach
information marking scheme
IT security architecture
IT security forum
IT security plan
IT security recommendations
loss
maintenance
malicious code
management
management commitment
masquerading of user identity
mechanism
media
misuse of resources
models
monitoring
natural disasters
needs analysis
network management
non-repudiation
operational Issues
penetration test
people
personnel
policy Relationships
practice
procedure
process/processes
property
protection requirements
requirement
resource
responsibility
risk acceptance
roles and responsibilities
security architecture
security awareness
security compliance
security elements
フォローアップ
上位レベルリスク分析（初期に実施する概要ﾚ
ﾍﾞﾙの分析）
識別、特定
セーフガードの実施
導入、実施
事件/事故の扱い
非公式アプローチ
情報重要度分類手法
ITセキュリティアーキテクチャ
ITセキュリティ委員会
ITセキュリティ計画
ITセキュリティの推奨事項
喪失
保守
悪意のあるコード
マネジメント、管理、経営管理
経営者のコミットメント（責任）
ユーザのなりすまし
しくみ
記録媒体 又は メディア、記録媒体(使分け
は文脈依存）
リソースの誤用
モデル
モニタリング
自然災害
必要性の分析
ネットワーク管理
否認防止
運用上の事項
ペネトレーションテスト
人
要員（人事管理の場合もある）
ポリシーの相互関係
慣例
手順、手続き
プロセス、過程
特性
保護要求事項
要求事項、要件（使分けは文脈依存）
資源
責任
リスクの容認
役割及び責任
セキュリティアーキテクチャ
セキュリティの意識向上
セキュリティ遵守
セキュリティ要素
4
security officer
security policy
security Program
security Training
software failures
staff
structure
sub-process
summary
theft
traffic overloading
transmission errors
user error
valuation
4.
セキュリティ責任者、セキュリティ部門責任者
(使分けは文脈依存)
セキュリティポリシー
セキュリティ計画（プラン）
セキュリティの訓練
ソフトウェアの欠陥
スタッフ
構成
サブプロセス
まとめ
盗難
トラヒックの過負荷
通信エラー
ユーザエラー
評価、または分析（状況によって使い分ける）
原案作成委員会の構成表 原案作成委員会の構成表を，次に示す。
平成 1 2 年度 情報システムのセキュリティ技術の標準化調査研究委員会 構成表
氏名
所属
（委員長）
苗村 憲司 慶應義塾大学環境情報学部
（幹事）
中尾 康二 株式会社ＫＤＤ研究所
（幹事）
竜田 敏男 日本アイ・ビー・エム株式会社
（幹事）
櫻井 幸一 九州大学大学院システム情報科学研究科
（委員）
岩下 直行 日本銀行金融研究所
植村 泰佳 電子商取引安全技術研究組合
奥田 和男 社団法人日本情報システムユーザー協会
小倉 久宜 財団法人金融情報システムセンター
才所 敏明 株式会社東芝
紫合
治 日本電気株式会社
菅
知之 電子商取引推進協議会
宝木 和夫 株式会社日立製作所
竹田 栄作 三菱電機株式会社
田渕 治樹 富士通株式会社
徳永 英二 ＴＯＫ
西川
満 情報処理振興事業協会
前川
徹 早稲田大学国際情報通信研究センター
森田
光 日本電信電話株式会社
吉田健一郎 財団法人日本品質保証機構
（オブザーバ）東井 芳隆 経済産業省商務情報政策局情報セキュリティ政策室
八田
勲 経済産業省産業技術環境局標準課
（事務局）
山中 正幸 財団法人日本規格協会
平成 1 2 年度 情報システムのセキュリティ技術の標準化調査研究委員会 WG1
（主査）
中尾 康二 株式会社ＫＤＤ研究所
（副主査）
大越 丈弘 三菱電機株式会社
（委員）
榎木 千昭 情報システムコントロール協会
橘和 尚道 日本システム監査人協会
工藤 正康 日本アイ・ビー・エム株式会社
栗田 博司 情報処理振興事業協会
小林 秀樹 社団法人情報サービス産業協会
5
構成表
杉浦
昌
関本
貢
前川
徹
山田 朝彦
山本
明
吉田健一郎
渡辺 展文
（オブザーバ）石井 伸治
平野 芳行
（事務局）
山中 正幸
日本電気株式会社
財団法人日本情報処理開発協会
早稲田大学国際情報通信研究センター
株式会社東芝
沖電気工業株式会社
財団法人日本品質保証機構
財団法人金融情報システムセンター
経済産業省商務情報政策局情報セキュリティ政策室
経済産業省産業技術環境局標準課
財団法人日本規格協会
6
X 5061-3 ：2001
（ISO/IEC 14888-3 ：1999 ）
セキュリティ技術
―
添付型ディジタル署名
―
第 3 部：証明書に基づく機構
解説
この解説は，本体及び附属書に規定・記載した事柄，並びにこれらに関連した事柄を説
明するもので，規格の一部ではない。
1. 制定の経緯（未稿）
2. 概要（未稿）
3. 引用規格と対応（未稿）
4 ．定義
有限可換群(Finite commutative group)
有限集合(finite set)
二項演算(binary operation)
元の位数(order of an element)
定義される(be defined)
帰納的に (再帰的に）(recursively)
5. 特記事項 （未稿）
6. 原案作成委員会の構成表
情報システムのセキュリティ技術標準化調査研究委員会 WG4 の構成表
氏名
（主査）
所属
竜田 敏男
日本アイ・ビー・エム株式会社
小林 邦生
日本電信電話株式会社
近澤
武
三菱電機株式会社
古川
潤
日本電気株式会社
宮崎 真悟
株式会社東芝
平野 芳行
経済産業省産業技術環境局
（事務局） 山中 正幸
財団法人日本規格協会
22

ISO/IEC27001の認証取得済

キリル文字を含む主な文字コード

特定芳香族アミン試験依頼書 - ニッセンケン品質評価センター

PDFファイル 187KB - JISC 日本工業標準調査会

「MS規格説明会」のお知らせ。（2014年3月）＜PDF

バーコード関連の ISO/IEC 及び JIS 規格一覧表

第 12 回 食品成分の分析技能試験 参加試験所の募集

先端分野に関する国際標準化への 取組事例