ISO/IEC27001:2013の改訂のポイントと分野別ISMS … 27001 ISMS 要求事項（Requirements） ISO/IEC 27001の適用範囲（Scope）の記述（抜粋）： ... 27001

ISO/IEC27001:2013の改訂のポイントと分野別ISMS規格”ISO/IEC27017”の

意義と解説ISO/IEC 27017: International Standard (IS)

Code of practice for information security controls

based on ISO/IEC 27002 for cloud services

工学院大学情報学部

ISO/IEC JTC1/SC27/WG1国内主査

ISO/IEC 27017 Project Editor

クラウド・セキュリティコントロール専門委員会委員長やまさきさとる

山﨑哲

Copyright SC27/WG1 Japan, 2015 1

2015/3/24

JTC1

SC7 SC17 SC27 SC37

国際標準の組織（セキュリティはISO/IEC SC27 in JTC1）

BiometricsSecurityIC card

TC68

Finance

International Organization for Standardization

International ElectrotechnicalCommission

2

Software

国際標準化機構

国際電気標準会議

Copyright SC27/WG1 Japan, 2015

WG formation in SC27

WG1:ISO/IEC 27000 ISMS family of standardsWG2: Security technology, mechanism

WG3: Security evaluation criteria

WG4:

・ Network security

・Application security

・ BCP services, others

WG5：・ Privacy

・ Identity management

・ Biometrics

3Copyright SC27/WG1 Japan, 2015

ご説明内容 – 全体


Part 1. ISO/IEC27001:2013の改訂のポイント

（Slide 5 ～ Slide 59）

Part 2. 分野別ISMS規格”ISO/IEC27017”の意義と解説

（Slide 60 ～ Slide 106）

ご説明内容 – Part1 (ISO/IEC27001:2013)


1. 情報セキュリティマネジメントシステムの意義と国際標準化の経緯

a. 情報セキュリティマネジメントシステム（ISMS）の意義

b. ISMS要求事項規格ISO/IEC27001とその関連規格の動向

c. ISO/IEC 27001, 27002の審議経過

2. ISO/IEC27001の改訂の趣旨と主要な改訂点

a. マネジメントシステム規格の共通化の適用

b. 情報セキュリティ目的の導入による「ISO31000:2009リスクマネジメント-原則及び指針」に基づく情報セキュリティリスクアセスメント及びリスク対応

c. 分野別ISMSへの拡張

d. パフォーマンス及び有効性の評価

3. 改訂後のISO/IEC27001におけるトップマネジメントの役割

6

(1)マネジメントシステムとは何か

方針、目的及びその目的を達成するためのプロセスを確立するための、相互に関連する又は相互に作用する、組織の一連の要素

(2) ISMSとは何か

情報セキュリティ分野におけるマネジメントシステムが、情報セキュリティマネジメントシステム(ISMS)である。

従って、ISMSとは、情報セキュリティの確立、実施、維持、

継続的な改善によって、その組織の目的を達成するプロセスを確立するための、相互に関連又は相互に作用する一連の要素（組織の構造、役割及び責任、計画、運用など）のことである。



ISMSによる情報セキュリティ対策（経営陣の方針から管理策への展開）

経営陣

管理者・従業員

情報セキュリティ方針

情報セキュリティ目的・目標

a. 情報セキュリティマネジメントシステム（ISMS）の意義- 要素１：情報セキュリティ目的・目標の設定 -

管理策の決定・実施


これまでの情報セキュリティ対策

情報セキュリティリスクアセスメントとリスク対応

管理策の決定・実施

情報セキュリティリスクアセスメントとリスク対応


部門

セキュリティ委員会

部門

CISO

社長

セキュリティ委員


グループ会社


法務ＩＴ

プライバシー

部門


情報セキュリティ・

スタッフ組織

グループ会社


情報セキュリティを統括するトップマネジメント（ＣＩＳＯ）の設置

トップマネジメント：最高位(highest level)で組織（Organization）を指揮（Direct）し、管理（Control）する個人又は人々の集まり

（事例）


a. 情報セキュリティマネジメントシステム（ISMS）の意義- 要素２：トップマネジメント（CISO）の設置 -

ISO/IEC 27001

ISMS要求事項（Requirements）

ISO/IEC 27001の適用範囲（Scope）の記述

（抜粋）：この規格は，組織の状況の下で，ISMS を確立し，実施し，維持し，継続的に改善するための要求事項について規定する。この規格は，組織のニーズに応じて調整した情報セキュリティのリスクアセスメント及びリスク対応を行うための要求事項についても規定する。

・・・・・・

JIS規格（JISQ27001）はISO/IEC 27001と“一致している”(IDT)

注記この規格の対応国際規格及びその対応の程度を表す記号を，次に示す。

ISO/IEC 27001:2013，Information technology － Security techniques －Information security management systems－Requirements（IDT）

なお，対応の程度を表す記号“IDT”は，ISO/IEC Guide 21-1 に基づき，“一致している”ことを示す。

9

b. ISMS要求事項規格ISO/IEC27001と

その関連規格の動向


ISO/IEC27000 ISMSファミリー規格は、ISO/IEC27001（ISMS要求事項）を支援する規格群である

用語

要求事項

27000

Overview and

Vocabulary

27006 Audit &

certification

bodies

27001

ISMS

Requirements

ガイドライン

分野別

ガイドライン

27005

Risk

Management

27002

Code of

Practice

27003Implementation

Guidance

27004

Management

Measurement

27011

Telecom

ISMS

ISMSファミリー規格の関係

27007

Auditing

Guidelines

：発行済み

SP

発行

27016

ISM

Economics

27008

Guidance for

auditors

27010

Inter-sector

comm

27017

Cloud

computing

27013

20000 &

27001

27014

security

governance

27015

Finance-

insurance

DIS

発行

DIS

10

CD1

2014年10月

CD1 WD3

DISCD2

WD1 WD1

DIS

27009 Sector-specific

application of 27001 -

Requirements

CD2


b. ISMS要求事項規格ISO/IEC27001と

その関連規格の動向


SC27meetingの審議の概要年２回の開催 WG1～WG5 of SC27

50+ヵ国、150+人程度の参加会議ではEditing meeting

各国より提出されたコメントによる編集会議会議後は、編集会議の結果のまとめ

(Resolutions）と新しいTextが配布

2012年 2013年5月 10月 4月 10月

Sophia

Antipolis,

France

Incheon,

Korea

Stockholm,

SwedenRome,

Italy

27001,27002

10月1日発行27001,27002

FDIS

27001,27002

DIS

27001CD3

27002CD1

2008年に改訂活動を開始

3月

JIS規格発行

2014年














① ISOのマネジメントシステム規格（以降MSSと言う）– 品質： ISO 9001:2008

– 環境： ISO 14001:2004

– 情報セキュリティ： ISO/IEC 27001:2005

– ITサービス： ISO/IEC 20000-1

– 事業継続： ISO 22301:2012 等

② 共通化の目的

– 組織が複数のマネジメントシステムを導入することを考慮して、マネジメントシステム間の整合性向上を図り、組織の負担を軽減する。

（注）それぞれのマネジメントシステム規格は、今後も独立して存在する。


a. マネジメントシステム規格の共通化の適用- MSS共通化の目的 -

③共通化の方法

– 新たに開発あるいは改訂するマネジメントシステム規格に対して、上位構造、共通テキストと共通用語定義の使用を義務付け。

– このための上位構造、共通テキストと共通用語定義を下記文書で規定している。ISO/IEC Directives, Part 1, Consolidated ISO Supplement –

Procedures specific to ISO, Third edition, 2012

Annex SL (Normative) Proposals for management system

standards

– Appendix 2 (normative) High level structure, identical

core text and common terms and core definitions for

use in Management Systems Standards

– 27001:2013でこの上位構造、共通テキストと共通用語定義を適用している。


a. マネジメントシステム規格の共通化の適用- MSS共通化の方法 -

上位構造は、全てのMSS規格に共通の目次であり、このレベルでは、ISMSの色が見えない。

ISO/IEC 27001:2013（改訂版）

0 序文

1 適用範囲

2 引用規格

3 用語及び定義

4 組織の状況

5 リーダーシップ

6 計画

7 支援

8 運用

9 パフォーマンス評価

10 改善

附属書 A （規定）管理目的及び管理策

ISO/IEC 27001:2005

0 序文

1 適用範囲

2 引用規格

3 用語及び定義

4 情報セキュリティマネジメントシステム

5 経営陣の責任

6 ISMS内部監査

7 ISMSのマネジメントレビュー

8 ISMSの改善

附属書 A（規定）管理目的及び管理策

a. マネジメントシステム規格の共通化の適用- 上位構造の適用 -


MSの骨格のプロセス

共通テキストに対して、XXXを「情報セキュリティ」に置き換え、「情報セキュリティ固有の内容のテキスト」を変更・追加する。4. 組織の状況

4.1 組織及びその状況の理解

4.2 利害関係者のリーズ及び期待の理解

4.3 情報セキュリティマネジメントシステムの適用範囲の決定

組織は，ISMS の適用範囲を定めるために，その境界及び適用可能性を決定しなければならない。この適用範囲を決定するとき，組織は，次の事項を考慮しなければならない。

a) 4.1 に規定する外部及び内部の課題

b) 4.2 に規定する要求事項

c) 組織が実施する活動と他の組織が実施する活動との間のインタフェース及び依存関係

ISMS の適用範囲は，文書化した情報として利用可能な状態にしておかなければならない。

XXXを情報セキュリティに置き換え

共通テキストに追加したテキスト

a. マネジメントシステム規格の共通化の適用- 共通テキストの適用 -


共通用語定義と、ISO/IEC27000 family of

standardsの用語との関係

Annex SL

共通用語及び定義

リスクマネジメント関連の用語ISO Guide73, ISO31000

27000ファミリー規格

各規格で使用される共通用語及び定義

ISO/IEC27000 概要及び用語用語及び定義

a. マネジメントシステム規格の共通化の適用- 共通用語の設定 -


共通用語定義の設定と各マネジメントシステムとの関係ISOのマネジメントシステム規格全体（例えば、ISMS, QMS,

EMS）で共通に使用する用語と定義を設定計画に関連する用語

• organization

• risk

• objective

• policy

• top management

運用に関連する用語• process

• outsource

パフォーマンス評価に関連する用語• measurement

• audit

改善に関連する用語• corrective action

Terms related to “plan”

risk organization

policy top management

Concept diagram

a. マネジメントシステム規格の共通化の適用- 共通用語の設定 -


a. マネジメントシステム規格の共通化の適用- 引用規格（Normative references） -

① 次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成する。この引用規格は，その最新版（追補を含む。）を適用する。

ISO/IEC 27000，Information technology－Security techniques－Information security management systems－ Overview and

vocabulary

引用規格は、ここで指定された規格のテキストを重複して記述することなく、規格の一部を構成することができる。従って、27001の要求事項に対して、引用規格の本文のテキストも要求事項となる。

一方、注記（Note）は、要求事項を説明したり注釈などの情報を提供するもので、これ自身要求事項ではないが、要求事項の理解を助けるものである。

解説














ISO/IEC27001:2005年版

ISO/IEC27001：2013年版

リスクの定義＝目的に対する不確かさの影響

組織の状況の理解（課題,範囲,方針,目的）

リスクアセスメント

リスク特定

リスク対応（7つの選択肢）

リスク分析

リスク評価

リスク源事象及びそれらの原因起こりうる結果

ISMSの適用範囲、ISMS基本方針

リスクアセスメント

リスク特定

リスク対応（４つの選択肢）

リスク分析

リスク評価

資産脅威及びぜい弱性CIAの喪失が及ぼす影響

情報の機密性、完全性:

及び可用性の喪失に伴うリスクの特定

情報セキュリティ目的及び計画策定（なし）

(1) ISO/IEC 27001:2013要求事項の特徴- ISO/IEC27001: 2013年版と2005年版の比較 -


重要

① 結果：目的に影響を与える事象の結末

② 起こりやすさ：何かが起こる可能性


ISO/IEC27001:2005年版 ISO/IEC27001：2013年版


リスク値＝結果 X 起こりやすさ

リスク特定＝リスク源、事象、その原因

① リスク源：リスクを生じさせる力を潜在的に持っている要素

② 事象：周辺状況の出現又は変化

③ その原因：事象の原因

なし

リスク値＝資産 X 脅威 X ぜい弱性

リスク特定＝資産、脅威、ぜい弱性

① 資産を特定する

② 資産に対する脅威を特定する

③ 脅威がつけ込むかもしれないぜい弱性を特定する

① 資産：CIAレベル

② 脅威：脅威レベル

③ ぜい弱性：ぜい弱性レベル

(1) ISO/IEC 27001:2013要求事項の特徴- ISO/IEC27001: 2013年版と2005年版の比較 -

(1) ISO/IEC 27001:2013要求事項の特徴- 組織の状況の理解と機会の導入 -

組織の状況の理解

ISO/IEC27001:2013のまず4章において、ISMSの意図した成果の達成（情報セキュリティ目的につながる）に必要な能力に影響を与える課題に関して、外部環境、及び内部環境について理解する。

① 外部環境とは、社会、政治、金融等の組織外部の環境

② 内部環境とは、組織体制、役割、情報システム等の組織内部の環境

「機会」の概念の導入

ISO/IEC27001:2013では、例えば、ネットビジネスに乗り出すこ

とにより、「ネット取引による売り上げの拡大」のような「機会」（情報セキュリティ目的につながる）が増加するが、同時に、情報セキュリティリスクが生じる。

① 機会を増加させるためには、リスクが生じる

② リスクと機会は、因果関係と考える


(2) 情報セキュリティマネジメントシステムへのISO 31000の適用

新しい時代に対応したISO 31000に基づくリスクアセスメント及びリスク対応

ISMSにおける新しい「リスクの定義」に基づくリスクアセスメント及びリスク対応：

① リスクの定義の変更：目的に対する不確かさの影響

② リスクの特定の変更：リスク源、事象及びその原因

③ リスク値の変更：結果と起こりやすさの組み合わせ

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

4 組織の状況

5 リーダーシップ

6 計画

7 支援

8 運用

9 パフォーマンス評価

10 改善

ISMSプロセスへの組み入れ• 情報セキュリティリスクアセスメント• 情報セキュリティリスク対応


情報セキュリティ方針と目的の設定• 外部、内部の課題の洗い出し• 情報セキュリティ目的の設定

• 企業活動に貢献するための情報セキュリティ目的の確立（事例）

情報セキュリティ目的(組織の最高位）

情報セキュリティ目的(営業部門）

情報セキュリティ目的(データセンター）

情報セキュリティ目的(クラウドサービス）

お客様に影響するインシデントを減らしクラウドサービス事業の信頼性を確保する（インシデント=前年比50%）

お客様情報を含む営業社員のパソコンの紛失インシデントの減少（前年比50％）

システム要因によるクラウドサービス事業顧客に影響するインシデントの減少（前年比50％）

お客様サービス提供前に必ずSLAを締結（サービス毎に100%）

1. 実施事項2. 必要な資源3. 責任者4. 達成期限5. 結果の評価方法




クラウドサービス事業者の事例

クラウドサービス事業者（営業部門）の事例

(3) 事業方針・情報セキュリティ方針を実現するための情報セキュリティ目的・目標の設定

経営陣による情報セキュリティ方針

経営陣による事業方針

顧客機密情報保護

物理環境セキュリティ

PCセキュリティ

委託先・再委託先管理

退職時の情報資産保護

顧客個人情報保護

インシデント管理

（情報セキュリティ目的・目標）

数個から十数個を設定する

①保護すべき情報

②仕組み

③情報セキュリティ実施結果（例えば、PC紛失）

（社長方針）

（情報セキュリティに関するCISO方針）

技術･製品情報保護

お客様苦情管理

（事例）



リスクの定義及び目的の設定に関する要求事項① リスクの定義：（ISO/IEC27000）

目的に対する不確かさの影響

② 目的の設定に関する要求事項：（ISO/IEC27001）

5 リーダシップ

5.1 リーダーシップ及びコミットメント

トップマネジメントは，・・ISMS に関するリーダーシップ及びコミットメントを実証・・・。

a. 情報セキュリティ方針及び情報セキュリティ目的を確立し，それらが組織の戦略的な方向性と両立することを確実にする。

b. ・・・・

5.2 方針

トップマネジメントは，・・情報セキュリティ方針を確立・・・・。

a) 組織の目的に対して適切である。

b) 情報セキュリティ目的（6.2 参照）を含むか，又は情報セキュリティ目的の設定のための枠組みを示す。

6.2 情報セキュリティ目的及びそれを達成するための計画策定

組織は，関連する部門及び階層において，情報セキュリティ目的を確立しなければならない。情報セキュリティ目的は，次の事項を満たさなければならない。



企業活動に貢献するための情報セキュリティ目的(Information

security objectives)の設定と実施（6.2 情報セキュリティ目的及びそれを達成す

るための計画策定）

① 組織の情報セキュリティ目的の構造：

組織で、情報セキュリティ目的の設定のための枠組を確立

トップマネジメントが設定する組織の最高位の情報セキュリティ目的

最高位の情報セキュリティ目的から関連する部門及び階層までの情報セキュリティ目的を展開

② 情報セキュリティ目的の要件：

情報セキュリティ方針と整合している。

測定可能である。情報セキュリティ目的を定めて、測定可能な目標を設定して、進めていくのが、有効な進め方である。

適用される情報セキュリティ要求事項，並びにリスクアセスメント及びリスク対応の結果を考慮に入れる。

③ 情報セキュリティ目的を達成するための計画：

実施事項

必要な資源

責任者

達成期限

結果の評価方法



(4) ISO/IEC 31000によるリスクアセスメントプロセス- リスク特定、リスク分析、リスク評価-


リスクアセスメント:6.1.2

組織の状況の確定:

4.1,4.2,4.3,6.1.1,6.2

リスク特定:c)

リスク対応:6.1.3,6.2

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

7.

4

モニタリング及びレビュー:

9

リスク分析:d)

リスク評価:e)（注）

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

（ISO/IEC31000

から引用）


リスク源

事象と原因

起こりやすさ（likelihood）

結果（Consequence）

情報セキュリティ目的

社員の教育不足(security awareness)

パソコンの取扱い手順の不足

「パソコンの紛失」と「例えば社員の飲酒」

（Cの場合）さらに事象として、PC Loginパスワードが弱く侵入した場合、お客様から預かったお客様情報が漏えいし、お客様の信頼を失墜、場合により損害賠償（Aの場合）お客様から預かったお客様情報を紛失し、お客様の事業を継続できず、場合により損害賠償

目的に影響を与えるリスク因子

お客様に影響するインシデントを減らしクラウドサービス事業の信頼性を確保する（営業社員のパソコンの紛失インシデントの減少：前年比50％）

情報のCIA

の喪失

ある一連の周辺状況の出現又は変化

目的に影響を与える事象の結末

何かが起こる可能性

CIAレベル

クラウドサービス事業者（営業部門）の事例

(4) ISO/IEC 31000によるリスクアセスメントプロセス- クラウドサービス事業者（営業部門）の事例-


(4) ISO/IEC 31000によるリスクアセスメントプロセス- パソコン紛失の事例-


E1-1

飲酒によるPCの紛失

E2-1

Loginを通過してPCへ侵入

E3-1

情報を取得して漏洩

RS1-1

教育不足RS2-1

脆弱PSWD

RS3-1

非暗号

E1-2

盗難によるPCの紛失

E2-2

Loginを通過してPCへ侵入

E3-2

情報を削除して紛失

RS1-1

物理環境RS2-1

脆弱PSWD

RS3-1

バックアップ

C1（結果）

L1-1（起こりやすさ）






C2（結果）

L1-1XL2-1XL3-1

（起こりやすさ）

L1-2XL2-2XL3-2

（起こりやすさ）

X

X

同じ起こりやすさを使用

（Cの場合）さらに事象として、PC Loginパスワードが弱く侵

入した場合、お客様から預かったお客様情報が漏えいし、お客様の信頼を失墜、場合により損害賠償

（Aの場合）お客様から預

かったお客様情報を紛失し、お客様の事業を継続できず、場合により損害賠償

「6.1.2 情報セキュリティリスクアセスメント」の要求事項

c) 次によって情報セキュリティリスクを特定する。

1) ISMS の適用範囲内における情報の機密性，完全性及び可用性の喪失に伴うリスクを特定するために，情報セキュリティリスクアセスメントのプロセスを適用する。

2) これらのリスク所有者を特定する。

d) 次によって情報セキュリティリスクを分析する。

1) 6.1.12 c) 1) で特定されたリスクが実際に生じた場合に起こり得る結果についてアセスメントを行う。

2) 6.1.12 c) 1) で特定されたリスクの現実的な起こりやすさについてアセスメントを行う。

3) リスクのレベルを決定する。

e) 次によって情報セキュリティリスクを評価する。

1) 分析したリスク分析の結果と 6.1.2 a) で確立したリスク基準とを比較する。

2) リスク対応のために，分析したリスクの優先順位付けを行う。


(4) ISO/IEC 31000によるリスクアセスメントプロセス- ISO/IEC 27001 ISMS要求事項 6.1.2 -

ISMSの適用範囲、目的に関連する情報

リスクアセスメントに関連する用語の定義① リスクの定義：（ISO/IEC27000）

目的に対する不確かさの影響

② リスクの特定の定義：（ISO/IEC27000）

リスク（2.68）を発見，認識及び記述するプロセス。

注記 1 リスク特定には，リスク源，事象，それらの原因及び起こり得る結果の特定が含まれる。

リスク源：それ自体又はほかとの組み合わせによって、リスクを生じさせる力を本来潜在的に持っている要素

事象：ある一連の周辺状況の出現又は変化。

③ リスクレベルの定義：（ISO/IEC27000）

結果（2.14）とその起こりやすさ（2.45）の組合せとして表現される，リスク（2.68）の大きさ。

結果：目的（2.56）に影響を与える事象（2.25）の結末（outcome）

起こりやすさ：何かが起こる可能性


(4) ISO/IEC 31000によるリスクアセスメントプロセス- ISO/IEC 27000 用語の定義 -


１．会社内情報• 会社内機密情報厳格な管理を要する情報• 会社内機密情報• 会社内機密情報以外

２．お客様機密情報• 機密保持契約対象• 機密保持契約対象でないが機密にする• 上記以外

３．社員個人情報• 社員センシティブ情報• 社員関連情報• 社員コンタクト情報

４．お客様個人情報• 個人顧客情報• 法人担当者センシティブ情報• 法人担当者関連情報• 法人担当者コンタクト情報

A部門お客様機密保持契約対象 →管理策１

部門毎に管理策の内容やレベルが違う

A部門 B部門 C部門 D部門

B部門お客様機密保持契約対象 →管理策２

C部門お客様機密保持契約対象 →管理策３

D部門お客様機密保持契約対象 →管理策４

リスク基準（事例）

事例(1)：リスクアセスメントの対象リスク基準： ①情報資産の分類

• 目的に依ってリスクアセスメント対象が違う

• 詳細リスク分析には、登録された個々の情報資産が適用される


１．ネットワークシステム• 有線LAN、無線LAN、クラウドネットワーク等

２．インフラ• 共用DB、Web、クラウドサービス等

３．業務アプリケーション• 人事、経理等アプリケーション等

４．ソフトウェア・パッケージ購入、開発、Free software等

５．サーバ• ファイルサーバ、業務サーバ、部門サーバ等

６．PC等ワークステーション• 会社所有、部門所有、委託先等

７．ポータブル記憶媒体• 部門所有、紙等

８．その他の機器・印刷装置等

９．機器／システムをサポートするＵｔｉｌｉｔｙ• ＵＰＳ、発電機、冷却装置等

A部門携行中のUSB上に

NDA対象が保管→管理策１

B部門携行中のUSB上に

NDA対象が保管→管理策２

C部門携行中のUSB上に

NDA対象が保管→管理策３

D部門携行中のUSB上に

NDA対象が保管→管理策４

A部門 B部門 C部門 D部門

事例(2)：リスクアセスメントの対象リスク基準： ②関連するその他の資産の分類

部門毎に管理策の内容やレベルが違うリスク基準（事例）

目的に依ってリスクアセスメント対象が違

う

保管形態の設定の要領– 「②関連するその他の資産」として定義した資産から選択して、①の情報資産がどのような資産に保管されるか、取り扱われるかを指定する

– 情報資産がどこに保管されるか、どこで取り扱われるかを定義するものである

– 一つの情報資産に対して、複数の保管形態が考えられるときは、複数記述する

事例(3)：リスクアセスメントの対象リスク基準：保管形態の設定

例えば、普段センターの共用DBに保管しているが、PC

に保管して携行する場合は、下記の通り、複数通り記述する情報資産： NDA対象お客様受領資料

・保管形態：共用DB 保管場所：社内情報資産： NDA対象お客様受領資料

• 保管形態:PC 保管場所：携行同じ情報資産で、保管形態、保管場所が違う場合は、複数通り記述

目的に依ってリスクアセスメント対象が違う


保管場所の設定要領– 情報資産を保管した資産や取り扱われる資産を物理的に保管する場所を定義する。基本的に、社内、社外、移動中等、わかりやすい定義が良い

– リスク基準

社内

お客様

プロジェクトルーム

委託先

再委託先

再々委託先以降（再々委託先及びそれ以降全て）

携行

事例(4)：リスクアセスメントの対象リスク基準：保管場所の設定

リスク基準（事例）

目的に依ってリスクアセスメント対象が違う


情報セキュリティリスクの特定

リスクレベル計算のためのデータ分析（事件・事故/セキュリティ内部監査/有効性測定等の

分析結果から）

営業PC

セキュリティ

PC紛失 4

4

情報セキュリティリスクの分析

事象原因リスク源結果目的・目標

3

2

起こりやすさ

ウィルス更新不足

ウィルス

事象原因

営業PC

セキュリティ

PC紛失研修・規則不足

リスク源結果

4

4更新不足

目的・目標アセス対象

アセス対象

PC/携行

PC/Net

飲酒危険Web

飲酒

危険Web

顧客情/報/PC/携行顧客情報/PC/Net

事象リスク源

3

2

原因

PC紛失

ウィルス更新不足

起こりやすさ

アセス対象

飲酒

危険Web

顧客情/報/PC/携行顧客情報/PC/Net


事例(5)：リスクアセスメントプロセス- リスク特定とリスク分析 -

研修・規則不足

研修・規則不足

リスク値の算出

– リスク値＝「結果」＋「起こりやすさ」

リスクを許容できない範囲（例）

– 太枠内がリスクレベルである。

– リスク受容レベルを５未満とする、従って、５以上はリスク対応を検討する。

起こりやすさ（発生可能性）

結果（影響度）

まれに発生する

たまに起きるときどき起きる

繰り返し起きる

１２３４

影響極小１２３４５

影響小２３４５６

影響中３４５６７

影響大４５６７８


事例(5)：リスクアセスメントプロセス- リスク分析及び評価：リスク値計算例 -

７つのリスク対応の選択肢：

① リスクを発生させる活動を開始しない、または継続しないと決定することによって、そのリスクを回避（avoid）すること；

② リスクを取る（take）または増加（increase）させることにより、機会を追求すること；

③ リスク源（risk source）を取り除くこと；

④ 起こりやすさ（likelihood）を変えること；

⑤ 結果（consequence）を変えること；

⑥ 一つまたは複数の他者とそのリスクを共有（share）すること；および

⑦ 充分な情報を得たうえでの決定により、そのリスクを保有（retain）すること。


(5) ISO/IEC 31000によるリスク対応のプロセス- ７つのリスク対応の選択肢 -













グーグルの法人向けサービス、セキュリティ規格「ISO27001」を取得（日経2012/5/30）

グーグルの法人向けサービス、セキュリティ規格「ＩＳＯ 27001」を取得対象はＧｏｏｇｌｅＡｐｐｓｆｏｒＢｕｓｉｎｅｓｓ 2012/5/30 6:30 情報元日本経済新聞電子版

米グーグルは2012年5月29日、同社の法人向けWebサービス「Google Apps for Business」が、情報セキュリティの国際規格「ISO 27001」の認定を取得したことを発表した。

ISO 27001は、情報セキュリティマネジメントシステム（ISMS）の国際規格。ISMSとは、情報を適切に管理するための体制のこと。認証機関による審査を受けて、適切な情報管理体制を構築し運用していると認定されれば、ISO 27001認定を取得できる。

今回取得したISO 27001認定は、Google Apps for Businessを対象としたもの。同サービスを提供するデータセンターやオフィス、インフラ、アプリケーションなどにおいて、適切な情報管理が行わ

れていると認められた。但し、クラウド事業分野固有のISMSではない。一般的ISMSでは不十分です。これまでのISMS プラス ISO/IEC27017（事例）が必要

認定を取得したのは2012年5月初旬。その後、グーグル社内で発表内容を調整し、今回の公表に至ったという。

同サービスがISO 27001認定を取得したことで、「ユーザーは、今まで以上に安心して利用できるようになる。また、契約の条件として、サービス提供者にISO 27001認定を求める法人でも、Google Apps for Businessを問題なく利用できるようになる」（米グーグルエンタープライズセキュリティ担当統括責任者のエラン・ファイゲンバウム氏）。


ISO/IEC 27000 ファミリー規格で、Sector specific

standards（分野別指針）が増加している。– ISO/IEC 27010: 組織間コミュニティ（業界団体等）向け

– ISO/IEC 27011: 通信事業者向け

– ISO/IEC 27015: 金融サービス向け

– ISO/IEC 27017: クラウドコンピューティング向け

– ISO/IEC 27018: クラウドコンピューティングにおけるPII情報の管理

– ISO/IEC 27019: エネルギー業界におけるプロセスコントロール

Sector specific standard と ISO/IEC 27002 の関係– ISO/IEC 27002 を前提として、

– 分野固有の管理策、実施の手引、又は関連情報を追加することにより、

– ISO/IEC 27002 を当該分野向けに拡張している。

(1) 分野別ISMSにおけるSector specific standard


この新規プロジェクトにより Sector specific control set

standard を用いたISMS認証の制度が整備されると、次のような分野対応のISMS認証が成立することになる。

– ISMS認証(General) : ISO/IEC 27001

– ISMS認証(for CSC) : ISO/IEC 27001 + 27017 (CSC)

– ISMS認証(for CSP) : ISO/IEC 27001 + 27017 (CSP)

– ISMS認証(for Telecom): ISO/IEC 27001 + 27011

– ISMS認証(for Telecom+CSP): ISO/IEC 27001 + 27011 +

27017(CSP)

(2) Sector specific standardによる分野別ISMS認証


ISMS要求事項

27017 Cloud Security

Controls

Other sector specific

controls (27011 etc.)

ISO/IEC 27001

ISMS Requirements (Main Body)

Annex A ( based on 27002)

27017 Cloud Security Control setは、情報セキュリティリスクアセスメント、情報セキュリティリスク対応の結果、27001 Annex Aとともに、必要な管理策を決定するために参照される

27017は、同時に他の分野別管理策（例えば、27011）とともに、組み合わせて、使用することができる

分野別管理策（Sector specific controls）


(3) 分野別ISMSを確立する国際規格の事例- ISO/IEC 27017 (クラウド事業者、クラウド利用者) -

ISMS要求事項

27017 Cloud

Security Controls

ISO/IEC 27001 (extended by 27009)

Determine required controls

Compare with 27001 Annex A and

(sector-specific control sets)

Produce SoA

分野別管理策セット

認証組織に対する要求事項

ISO/IEC 27006

Certification

documents (+SoA

Version, Sector-

specific control ID)

分野別標準に対する要求事項

ISO/IEC 27009

Rule for Sector-

specific standards

• Requirements

• Control sets

27011 Telecom

Org. Controls


27002 Information security Controls


(4) 分野別ISMSを確立するための国際規格群- ISO/IEC 27001, 27006, 27009及び分野別管理策セットの関係 -

管理策の選択について

– ISO/IEC 27001:2005 の場合 (4.2.1 g)：

このプロセスの一部として、Annex A の中から、特定した要求事項を満たすために適切なように、管理目的及び管理策を選択しなければならない。

(5) 分野別ISMS確立のためのISO/IEC27001の整備① ISO/IEC27001:2005からの拡張


管理策の選択について– ISO/IEC 27001:2013 の場合 (6.1.3 b), c), d) ):

組織は，次の事項を行うために，情報セキュリティリスク対応のプロセスを定め，適用しなければならない。

a) ・・・・・・

b) 選定した情報セキュリティリスク対応の選択肢の実施に必要な全ての管理策を決定する。

注記組織は，必要な管理策を設計するか，又は任意の情報源の中から管理策を特定することができる。

c) 6.1.3 b) で決定した管理策を附属書 A に示す管理策と比較し，必要な管理策が見落とされていないことを検証する。

・・・・

d) 次を含む適用宣言書を作成する。

－必要な管理策［6.1.3 の b) 及び c) 参照］及びそれらの管理策を含めた理由

－それらの管理策を実施しているか否か

－附属書 A に規定する管理策を除外した理由

– リスク対応選択肢を実施するために必要な全ての管理策を決定

– Annex A 以外の管理策群の使用も想定している。ただし、Annex Aとの対応付けを要求している。

– 必要な管理策を含んでいるSoAの作成（produce）を要求している

(5) 分野別ISMS確立のためのISO/IEC27001の整備② Annex A以外の管理策使用の許容














2013年版では、「選択した管理策又は一群の管理策」と「それらの測定をどのように利用するかを規定する」は削除されている。評価は、情報セキュリティパフォーマンス及びISMSの有効性の評価が要求されており、そのための測定は、その一つのステップとして定義されている。

9.1 監視、測定、分析及び評価：(9.1 c), d)は新規、それ以外は改訂）9.1では、情報セキュリティパフォーマンス及びISMSの有効性を評価することが

要求されており、そのために監視、測定、分析及び評価することが要求されている。パフォーマンスは、ISO/IEC27000では「測定可能な結果」と定義され、その注記に「活動，プロセス，製品（サービスを含む。），システム，又は組織の運営管理」と記述されている。また、有効性は、「計画した活動を実行し，計画した結果を達成した程度」と定義されており、従って、ISMSの有効性評価のためには、評価可能な目的・目標を策定することが必要である。

9.2 内部監査：（改訂）旧版から具体的な要求事項は省略されたが、内容的に大きな変更はない。

9.3 マネジメントレビュー：( 9.3 c)の4)）は新規、それ以外は改訂)インプット、アウトプットの具体的な要求項目が削除されたが、年間のISMSの

活動計画に合わせ、事前にどのような内容をインプットし何をレビューし、何をアウトプットするかを定めることが要求されている。

「9. パフォーマンス評価(Performance evaluation)」

解説


箇条9. パフォーマンスを評価する

1) 情報セキュリティパフォーマンス不適合及び是正処置監視及び測定結果監査結果情報セキュリティ目的の達成

2) ISMSの有効性情報セキュリティ目的の達成するために計画し実

施した管理策の実施状況と、情報セキュリティ目的の達成状況との比較

「9. パフォーマンス評価(Performance evaluation)」


監視、測定、分析、評価

51

対策前リスクレベル

対策後リスクレベル

①有効性の測定＝計画した活動の実施度

対応策の実施

②有効性の測定＝計画した結果（目的）の達成度

Planned activities

are realized

Planned results are achieved

(Objectives)

Before After

有効性の定義

計画した活動を実行し，計画した結果を達成した程度

ISO/IEC27000:2014

(1) ISMSの有効性評価の定義有効性の定義、ISMSにおける有効性の評価


PCセキュリティ（PCのセキュリティ設定の遵守）：

目的：不正なPCへの物理的、ネットワーク上の侵入から防ぐ。そのために、PCのセキュリティ設定が、会社全体の共通のルールに基づいた設定値になっていること、及びそれを維持すること。

測定項目(Measure)：接続PCのセキュリティ設定遵守率分子/分母＝設定遵守台数/接続全PC台数

目標値(Target)：目標値 100％

管理値(Indicator)： Green zone 100%～ Yellow zone 99%～ Red zone 96%～ 0%

実装（Imple）するべきISMS管理目的・管理策： A6.2/A.6.2.1、A.6.2.2 A9.3/A.9.3.1 A11.2/A.11.2.5、A.11.2.6、A.11.2.7、A.11.2.8、A.11.2.9 A12.2/A.12.2.1 A18.2/A.18.2.2

目的（Objectives）の設定

（監視及び改善アクションの例） 99%以下になると、違反者に個別に設

定改善を要求するメールを出す。→要因を特定し、要因に関連する対策をアドバイス（例えば、Screen

saver） 96%以下になると、非常事態宣言。部

門長宛、違反者のName listを添付して改善要求のメールを出す。→要因を特定し具体的対策を指定して、メールを出す。

→改善されない場合は、毎週出す。

（注）ISO/IEC 27001:2013の改訂に伴い、ISO/IEC 27004の改訂が進められている

リスクアセスメント及びリスク対応により管理目的・管理策へ展開される。その結果、管理値が決まる

事例

経営陣

目的・目標「PCセキュリティ」を実践した事例

(2) 事例：目的・目標「 PCセキュリティの強化」の有効性


経営陣から従業員まで含めた“監視、測定、分析、評価”を可能とする体制を構築することにより、セキュリティの見える化を指向した的確にセキュリティの改善アクションが取れる運用管理を実施することが要求されている。


CISO

社長

経営会議

部門部門



部門


セキュリティスタッフ組織

監視測定収集計算分析評価報告改善アクションの指示

改善アクションの実施

実施しないとペナルティ

報告改善アクション案の提示

報告

Web公表

改善指示

改善指示

報告

管理策（対応策）のインプリと運用

目的の達成/

管理値による改善指示

事例

(3) 監視、測定、分析、評価の手順情報セキュリティパフォーマンスとISMS有効性の評価の体制














経営陣の方針から管理策への展開

経営陣


経営陣のコミットメント

リスクアセスメント及び

リスク対応

(1) 情報セキュリティ目的・目標の設定の意義「経営陣と管理者・従業員とのパイプ役となる情報セキュリティ目的・目標を設定する」

情報セキュリティ方針

情報セキュリティ目的・目標

管理策

経営陣と管理者・従業員が、情報セキュリティ目的・目標を共有することでコミュニケーションギャップをなくす

経営戦略に基づく情報セキュリティの基本方針

直接的な結びつきが弱い。


部門


部門

CISO

社長



グループ会社


法務ＩＴ

プライバシー

部門


情報セキュリティ・

スタッフ組織

グループ会社


(2) 内部組織の要素- 情報セキュリティの取り組み体制 -

（事例）


情報セキュリティを統括するトップマネジメント（ＣＩＳＯ）の設置

関連する物理セキュリティ・ITセキュリティ・プライバシーを統括

セキュリティ委員会は各部門及び各グループ会社から代表者（委員）を選出

グループ企業全体で共通に遵守すべき規程類

グループ全体で統一した管理体系

明確な責任分担と内部統制

ITセキュリティ管理体系

（例えば）グループにおける一企業は、グループ企業全体で共通に遵守すべき規程類と整合性を取って、グループ企業特有の規程を追加

お客様情報の保護

先進的なワークスタイル

ＩＳＭＳフレームワークに基づくマネジメント

グループ共通の基本方針

グループ共通の標準

グループ共通のプロシージャ

社長方針

グループ全体のコンプライアンス行動指針

グループ企業としての規定体系を明確にする必要があります。例えば、グループ企業共通に遵守すべき規程類とグループ企業特有の規程類を、全体で整合性を取って実施します。

（事例）

(2) 内部組織の要素- グループ企業としての規定体系 -


企業・組織

取引先、顧客、従業員、社会等株主

CEO方針

情報セキュリティ対策

情報セキュリティ目的・目標設定

目的・目標達成度・実施度

管理目的・管理策の展開監視＆レビュー

経営陣

CISO

管理者従業員

CIO方針 CFO方針 CLO方針

CISO方針

(2) 内部組織の要素- 情報セキュリティガバナンス組織とＣＩＳＯ -



ご説明内容 – Part2 (ISO/IEC DIS27017)

1. クラウドセキュリティの国際標準化の経緯

a. SC27 meetingと国際標準化の経緯

b. 日本からの国際標準化の提案

c. クラウド関係の国際標準化のための役割の合意

d. クラウド関係国際標準の開発スケジュールと国際協力体制

2. 安全なクラウドサービスのためにISO/IEC27017の果たす役割

a. ISO/IEC27017の適用範囲（Scope）

b. ISO/IEC27017とISMS認証との関係

c. ISO/IEC27017とISO/IEC27002との関係

d. ISO/IEC27017の構造

e. ISO/IEC27017で使用するクラウドコンピューティングの用語

f. ISO/IEC27017のISO/IEC27001:2013に基づくリスクマネジメントのプロセス（参照：Part 1: ISO/IEC 27001:2013）

3. ISO/IEC27017の追加のセキュリティ管理策と実施の手引き（事例）


SC27meetingの審議の概要年２回の開催 WG1～WG5 of SC27

50+ヵ国、150+人程度の参加会議ではEditing meeting

各国より提出されたコメントによる編集会議会議後は、編集会議の結果のまとめ

(Resolutions）と新しいTextが配布

2013年 2014年4月 10月 4月 10月

Mexico City,

Mexico

Hong

Kong,

China

27017CD127017WD5

2011年10月にNPを承認、規格制定作業を開始

Sophia

Antipolis,

France

Incheon,

Korea,

Korea

27017CD2 27017DIS


クラウド利用者クラウド事業者

セキュリティ対策に関するフィードバックが不足（特に海外の場合）

クラウドの課題：クラウド事業者のセキュリティ対策に関する情報に関して、クラウド利用者へのフィードバックが、充分でない

クラウド事業者（米国）

クラウド事業者（中国）

b. 日本からの国際標準化の提案クラウド事業者のセキュリティ対策情報が不足


クラウドの課題を解決するためには、基準（Criteria）に基づいて、クラウドの利用者と事業者の間で、（国際環境において）共通の

理解を実現するための仕組みの確立が必要である

クラウド利用者クラウド事業者

セキュリティ対策に関する共通の理解を実

現する

基準（criteria）に基づく仕組み ISMS

利用者からどのようなことが要求されているか?

クラウド事業者のセキュリティ対策は、何で、どの程度のものか?

b. 日本からの国際標準化の提案基準に基づく共通の理解を得る仕組みの提案

クラウド事業者利用している他の事業者のセキュリティ対策はどの程度のものか?


C. クラウド関係の国際標準化のための役割の合意

SC38 (17788, 17789)(Terminology, Architecture)

ISO/IEC27017

(Security

control)

ISO/IEC27036-4

(Cloud for

Supplier

management)

ISO/IEC27018

(PII protection

control)

Based on

ISO/IEC27002

ISO/IEC27036

(Part1 – Part3)Based on

ISO/IEC29100

SC27/WG4 SC27/WG1 SC27/WG5


d. クラウド関係国際標準の開発スケジュールと国際協力体制- ISO/IEC27017プロジェクト開発スケジュール -

The following ISO/IEC 27017 schedule was endorsed by JTC1

(SC27N13407).

• NP approved 2011-08

• WD1 2011-10 (editing session started)

• WD2 2011-10（Nairobi）

• WD3 2012-05（Stockholm）

• WD4 2012-10（Rome）

• WD5 2013-04（Sophia Antipolice）

• CD1 2013-10（Incheon）

• CD2 2014-04（Hong Kong）

• DIS 2014-10（Mexico City）

• FDIS 2015-04（Kuching）

• IS 2015-10（発行）


日本米国英国

主要国

主要組織

ITU-T SC38 CSA ISACA TREsPASS

中国フランス

ドイツ韓国シンガポール

オーストラリア

クラウドセキュリティの国際標準化は、多くの国と、主要な関係組織の協力により実施されています

d. クラウド関係国際標準の開発スケジュールと国際協力体制- ISO/IEC27017プロジェクトの国際協力体制 -


ご説明内容















Cloud Service Partner

Cloud Service

Provider

Cloud Service

Customer

Cloud

Service

User

a. ISO/IEC27017の適用範囲（Scope）- ISO/IEC17789:Reference architectureから -

Cloud

Service

Developer

Cloud

Auditor

Cloud

Service

Broker

27017

Scope

外

27017

Scope

内


ISMS要求事項

27017 Cloud Security

Controls

Other sector specific

controls (27011 etc.)

ISO/IEC 27001

ISMS Requirements (Main Body)

Annex A ( based on 27002)

27017 Cloud Security Control setは、情報セキュリティリスクアセスメント、情報セキュリティリスク対応の結果、27001 Annex Aとともに、必要な管理策を決定するために参照される

27017は、同時に他の分野別管理策（例えば、27011）とともに、組み合わせて、使用することができる

分野別管理策（Sector specific controls）

b. ISO/IEC27017とISMS認証との関係- ISO/IEC27001と分野別標準及び分野別管理策 -


b. ISO/IEC27017とISMS認証との関係- ISMSユーザにとっての分野別ISMS認証の意義 -


クラウド利用者クラウド事業者-A

普通のISMS認証では、クラウド固有のセキュリティ対策は、カバーされていない

クラウド事業者のセキュリティ対策は、何で、どの程度のものかを知ることができる。

クラウド事業者-B クラウド利用者に対して、クラウド固有のセキュリティ対策を、どの程度提供すればよいか、知ることができる。

クラウド事業者分野のISMS認証

普通のISMS認証

クラウド利用者とクラウド事業者の間のコミュニケーションの手段＝ ISMS

ISMS要求事項

27017 Cloud

Security Controls

ISO/IEC 27001 (extended by 27009)

Determine required controls

Compare with 27001 Annex A and

(sector-specific control sets)

Produce SoA


認証組織に対する要求事項

ISO/IEC 27006

Certification

documents (+SoA

Version, Sector-

specific control ID)

分野別標準に対する要求事項

ISO/IEC 27009

Rule for Sector-

specific standards

• Requirements

• Control sets

27011 Telecom

Org. Controls


27002 Information security Controls

b. ISO/IEC27017とISMS認証との関係- ISO/IEC27001とISO/IEC27009, 27006の関係 -


ISO/IEC 27009は、分野別標準の要求事項を定義したものです。

• ISO/IEC 27009タイトル：“Sector-specific application of ISO/IEC 27001 – Requirements”

• 分野別ISMS認証を達成するためには、ISO/IEC 27001及び分野別標準を合わせて適用：– ISMS認証(General) : ISO/IEC 27001

– ISMS認証(for CSC) : ISO/IEC 27001 + 27017 (CSC)

– ISMS認証(for CSP) : ISO/IEC 27001 + 27017 (CSP)

– ISMS認証(for Telecom): ISO/IEC 27001 + 27011

– ISMS認証(for Telecom+CSP): ISO/IEC 27001 + 27011 +

27017(CSP)

b. ISO/IEC27017とISMS認証との関係- 分野別ISMS認証を定義するISO/IEC27009 -


(1) タイトル

ISO/IEC 27002


ISO/IEC 27017



c. ISO/IEC27017とISO/IEC27002の関係


27002及び27017の箇条(Clauses)は、同じ

5 Information security polices (管理策事例0 1. 5.1.1)

6 Organization of information security

7 Human resource security

8 Asset management

9 Access control

10 Cryptography

11 Physical and environmental security

12 Operations security (管理策事例2. 12.3.1)

13 Communications security

14 System acquisition, development and maintenance

15 Supplier relationships

16 Information security incident management

17 Information security aspects of business continuity management

18 Compliance (管理策事例3. 18.1.1)

Annex A (27017) Cloud Service Extended Control Set(管理策事例1 CLD9.5.1)

（2）箇条(Clauses)の関係


Control

Implementation

guidance

Other information

ISO/IEC27002

Objective

+ specific Imple-

mentation guidance

+ Other information

ISO/IEC27017

New Control

New Objective

（本文）（本文）（Annex A）

+ specific Imple-

mentation guidance

+ Other information

Control

Objective

ISO/IEC27017



全て新しく追加（Objectives、

Controls,

imple.guida, other）

Controlの下に追加（ Implementation

guidance 及び other

information ）

(3) 27017 specific to cloud services



ISO/IEC 27017の構造は、Control（管理策）毎に、Implementation

guidance（導入の手引き）を、テーブル形式で記述する。

a. 各Control（管理策）の様式• Each subclause

Control X.X.X and the associated implementation guidance and other information specified

in ISO/IEC 27002 apply. The following sector-specific implementation guidance also

applies.

• Subclause header

Implementation guidance for cloud services

Other information for cloud services.

b. Implementation guidanceはテーブル形式

• Type1

• Type2

c. Annex Aの番号の付け方• 27009 defines as rules, ‘A unique identifies shall be used, and 27011 as example’.

• 27011 uses ‘TEL.’, and therefore ‘CLD. X.X.X’ is used

Cloud service customer Cloud service provider

Implementation guidance Implementation guidance

Cloud service customer Cloud service provider

Implementation guidance


e. ISO/IEC27017で使用するクラウドコンピューティングの用語 - Normative references -

2. 引用規格

次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成する。この引用規格は，その最新版（追補を含む。）を適用する。

• ISO/IEC 27000, Information technology - Security techniques -

Information security management systems - Overview and

vocabulary

• Y.3500 | ISO/IEC 17788, Information technology - Cloud

computing - Overview and vocabulary

• Y.3502 | ISO/IEC 17789, Information technology - Cloud

computing - Reference architecture

• ISO/IEC 27002:2013, Information technology - Security

techniques - Code of practice for information security controls


Terms and definitions specific to cloud computing (ISO/IEC17788)

• Cloud Computing3.2.5 cloud computing:

( Intentionally blank )

• Cloud Service3.2.8 cloud service:


e. ISO/IEC27017で使用するクラウドコンピューティングの用語(SC38:ISO/IEC17788)


Infrastructure

Capabilities

Type

IaaS PaaS SaaS NaaS ・・・・・

Platform

Capabilities

Type

Application

Capabilities

Type

Cloud Service Categories




• Cloud Capabilities Type3.2.4 cloud capabilities type:


• Cloud Service Category3.2.10 cloud service category:




Cloud Service Partner

(但し、27017では適用しない）

Cloud Service

Provider

Cloud Service

Customer

Cloud

Service

User




• Cloud Service Customer3.2.11 cloud service customer:


• Cloud Service Provider3.2.15 cloud service provider:


• Cloud Service Partner3.2.14 cloud service partner:


• Cloud Service User3.2.17 cloud service user:







• Cloud service customer data3.2.12 Cloud service customer data:





• Cloud service customer derived data3.2.13 Cloud service customer derived data





• cloud service administrator


• cloud service business manager


• cloud service integrator


• peer cloud service provider




Terms and definitions specific to cloud computing (ISO/IEC17023, ISO/IEC 27040)

• virtual machine (ISO/IEC 17023)


• data breach (ISO/IEC 27040)


• secure multi-tenancy (ISO/IEC 27040)


ご説明内容















f. ISO/IEC27017のISO/IEC27001:2013に基づくリスクマネジメントのプロセス

88

リスクアセスメント:6.1.2

組織の状況の確定:

4.1,4.2,4.3,6.1.1,6.2

リスク特定:c)

リスク対応:6.1.3,6.2

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

7.

4

モニタリング及びレビュー:

9

リスク分析:d)

リスク評価:e)（注）

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

（ISO/IEC31000

から引用）

ISO/IEC27017のリスクマネジメントプロセスISO/IEC27001:2013

に基づく（詳細は参照： Part1の2）


ご説明内容















クラウドコンピューティング環境で、一般的に懸念されるリスクが潜む環境は以下の場合が考えられ、「リスクアセスメント対象」を説明する記述として、以下の環境を考慮する。

1. コンピューティング資源の一部を共有し、その上に個々の利用者が管理するシステムが構築されるなど、事業者と利用者関係が緊密かつ複雑である。(管理策事例 1）

2. クラウドコンピューティングサービスは、その提供の仕組みの詳細を利用者が知ることがなくても手軽に利用できる半面、利用者にブラックボックスとなっている。

3. オンプレミスとクラウドコンピューティングサービス、あるクラウドコンピューティングサービスと他のクラウドコンピューティングサービスの併用など、多様な利用があり、それらの間の整合性が取りにくい。（管理策事例２）

4. 膨大な利用者が一つの資源を共有している。

5. 仮想化技術を幅広く取り入れており、その結果として、一瞬にして環境が変わる（数千台のサーバが一瞬に消えるなど）。

6. 論理環境と物理環境が多様に入り組んだ複雑で巨大なコンピュータシステムである。

7. 資源がグローバルに分散配置されている。（管理策事例３）

8. クラウドコンピューティングサービス上に他のクラウドコンピューティングサービスが行われるなど、クラウドを組み合わせたサービスが存在する。

事例(1) リスクアセスメントの対象事例：リスクアセスメントの対象（クラウドコンピューティング）


クラウドサービス利用者クラウドサービス事業者リスク源 Loss of governance

Responsibility ambiguity

Isolation failure

Vendor lock-in（管理策事例2）

Compliance and legal risks

Handling of security incidents

Management interface

vulnerability

Data protection

Malicious behaviour of

insiders

Business failure of the

provider

Service unavailability

Migration and integration

failures

Evolutionary risks

Cross-border issues

Insecure or incomplete data

deletion

Responsibility ambiguity

Inconsistency and conflict of

protection mechanisms

Isolation failure（管理策事例1）

Unauthorized access to the

provider's systems.

Jurisdictional conflict（管理策事例3）

Insider Threats

Supply Chain vulnerability

事例(2) リスク源の事例参照：リスク源の事例（クラウドコンピューティング）


事例(3) ISO/IEC27017の管理策事例


管理策No. 管理策内容実施の手引き

管理策事例0 5.1.1 ポリシー

管理策事例1 CLD9.5.1 仮想環境の保護

管理策事例2 12.3.1 バックアップ

管理策事例3 18.1.1 法的要求事項、法域

CSC CSP

○ ○

○

○ ○

○ ○

事例1（事象及びその原因: Loginを通過してCSPへの侵入、リスク源: CSPのmulti-tenantの分離のぜい弱性、結果：CSC1のデータ紛失）

事象及びその原因

結果考え方（事例）

事例：CSC2からCSPへの侵入、及びCSC2から悪意の運用管理によりCSC1へのデータアクセス・紛失

事例：CSP multi-tenantの分離のぜい弱性（不完全さ）

事例：CSC1のデータにアクセスされデータが削除、その結果、信頼性喪失

CSC

1 CSP

CSC

2

CSPのmulti-tenant

の分離のぜい弱性

リスク源

データ紛失が発生（CSC1のアクセス制御の変更なし）

CSC2からCSPへ侵入

CSPへの侵入（Direct Threat：multi-tenantのクラウドへ侵入、その後CSC1のデータにアクセス・削除）

事例１：リスクの特定の手順参照：事例1.（クラウドコンピューティング）

リスクアセスメント対象

事例：コンピューティング資源の一部共有

（注）

リスクの特定は、各組織の情報セキュリティ目的の下で実施される


事例2（事象及びその原因：CSCデータ破壊によるシステム停止, リスク源：CSPロックイン（lock-in）、結果：システム停止後、再開できない）

事例：データ破壊(CSC)及びシステム停止（CSC）。データ破壊がシステム停止に直結。

事例：CSP（開発）のlock-in

取得していたバックアップが使用できず、システ停止後、再開始できない

CSCCSP

1

CSP

2

CSP(開発)

クラウドの範囲

直接クラウドに属さないがクラウドのソフトを開発したCSPがlock-inの場合

データ破壊が発生当該クラウドの使用を中止して別システム（例えば別クラウド、又は自社システム）に移行。取っていたバックアップデータを使用しようとしたが、lock-inのため、使用できない（システム停止による運用の継続ができない）

事例2：リスクの特定の手順参照：事例2.（クラウドコンピューティング）

考え方（事例）


事例：異なるサービス間の整合性

結果リスク源

（注）




事例3（事象及びその原因: CSPの国で事件によりCSPに保管していた情報がCSCの情報が漏えい、リスク源：法域の不一致（jurisdictional conflict）、結果：CSC1の個人情報漏えい）

事例：CSPで事件発生(CSP)。この原因は、セキュリティに関係なし。

事例：CSP jurisdictional conflict

事例：CSC1の個人情報漏えい

CSC

1CSP

CSPの法域（例えば米国）

CSPの法域で事件(セキュリティと関係ない)が発生、法律によ

りデータ閲覧、その結果、CSCの個人情報漏えい（CSCとCSP

の法域のConflictが発生）

CSCの法域でCSPを使用。CSCの利用者は、CSCの法律が適用されると考える（CSCの個人情報漏えいが発生）

事例3：リスクの特定の手順参照：事例3.（クラウドコンピューティング）

考え方（事例）


事例：資源のグローバルな分散配置

結果リスク源

（注）




事例(3) ISO/IEC27017の追加の管理策事例


管理策番号管理策の内容リスク源

CLD.6.3.1 Shared responsibilityCompliance and legal risks

Malicious behavior of insiders

CLD.8.1.5 Removal of assetsResponsibility of ambiguity

Data protection

CLD.9.5.1Segregation in virtual

computing environmentsIsolation failure

CLD.9.5.2 Virtual machine hardening


protection mechanism

Isolation failure

CLD.12.1.5 Critical operations

Evolutionary risks

Insecure or incomplete data

deletion

CLD.12.4.5 Monitoring cloud services Data protection

CLD.13.1.4Consistent virtual and

physical networks


protection mechanism

おわりに

ご清聴有難うございました。

工学院大学情報学部

ISO/IEC JTC1/SC27/WG1国内主査

ISO/IEC 27017 Project Editor

クラウド・セキュリティコントロール専門委員会委員長

山﨑哲


ISO/IEC27001:2013の改訂のポイントと 分野別ISMS … 27001 ISMS 要求事項（Requirements） ISO/IEC 27001の適用範囲（Scope）の記述 （抜粋）： ... 27001

Documents

ISO/IEC27001:2013の改訂のポイントと分野別ISMS … 27001 ISMS 要求事項（Requirements） ISO/IEC 27001の適用範囲（Scope）の記述（抜粋）： ... 27001