06
06.1
06.1.1
06.1.1b)
04.2a)
04
04.2
04.2a)
ＩＳＭＳに関連する利害関係者の決定
.*.
interested parties ：利害関係者
消費者（顧客）、従業員、株主、債権者、仕入先、得意先、地域社会、行政機関など。ステークホルダー（英: stakeholder）に同じ。
従業員には従業員の家族も意識すること。従業員をいい加減に扱う会社は家族から提訴を受ける。株主には上場企業の場合は現在の株式保有者だけでなく投資家まで考慮する必要が有ります。
.*.
04.2
04.2a)
ＩＳＭＳに関連する利害関係者の決定
.*.
interested parties ：利害関係者
消費者（顧客）、従業員、株主、債権者、仕入先、得意先、地域社会、行政機関など。ステークホルダー（英: stakeholder）に同じ。
従業員には従業員の家族も意識すること。従業員をいい加減に扱う会社は家族から提訴を受ける。株主には上場企業の場合は現在の株式保有者だけでなく投資家まで考慮する必要が有ります。
.*.
0.2 他のマネジメントシステム規格との両立性
0
0.2
他のマネジメントシステム規格との両立性
• ISO/IEC専門業務用指針の附属書SLで定義されている「上位構造（ハイレベルストラ クチャー）、共通テキスト、共通用語」を採用
• ISO/IEC専門業務用指針
0.2
他のマネジメントシステム規格との両立性
• ISO/IEC専門業務用指針の附属書SLで定義されている「上位構造（ハイレベルストラ クチャー）、共通テキスト、共通用語」を採用
• ISO/IEC専門業務用指針
詳細リスクアセスメント手順
27001：2005では具体的に記述されていたが、27001：13では一般的な表現に止め（とどめ）られている。ＩＳＯ31000との整合性。
表現が一般的ということと内容が手抜きで良いということは別。結局、リスクを洗い出すための合理的な手順が要求される。一般要求でも、解は情報セキュリティの問題に対する解が求められる。
前規格の方法論以外に適切なものがあれば構わないが説明責任が出てくる。その分、新規格はやり難い。
表現が一般的ということと内容が手抜きで良いということは別。結局、リスクを洗い出すための合理的な手順が要求される。一般要求でも、解は情報セキュリティの問題に対する解が求められる。
前規格の方法論以外に適切なものがあれば構わないが説明責任が出てくる。その分、新規格はやり難い。
10.1 不適合及び是正処置
.jpg)
10
10.1
不適合及び是正処置
ここは手間だけど簡単？
不適合がおきたら、不適合の処置と再発防止（是正処置）をやりなさい。不適合を管理しなさい。
さて、
不適合って何？
不適合はどのように把握できるの？
「9.能力評価(Perfomance Evaluation)」の問題かな？
監視項目を決めて受容レンジから逸脱したら不適合？。マネジメントレビューに提示される不適合ってなんだろう？。ＩＳＭＳの不適合を検出できるのだろうか。
マネジメントレビューや内部監査が年１回ですから、普通の場合、不適合が是正に繋がるのは、9.1．の監視から10.1の是正処置への流れになります。個々が問題です。
なんとなく、9.1と１０.1の間にはギャップがありますね。9.1では不適合の言葉が出てきませんから処置が曖昧になります。この構造は前バージョンでも同じこと。もしくは9.1の網羅性に疑問が残ります。
.*.
全日本柔道連盟で女子選手の上げた声を受け止めて処理することが出来なかった事例を思い浮かべればよくわかるだろう。メディアに情報がリークされて漸く問題の大きさを理解した組織。これはまだ幸運なほうで普通の組織では表に問題が出ることはない。想定外のことには対応できないのです。問題は封じられたままだ。
.*.
不適合
10. 改善：Improvement
改善：Improvement
改善なんて普通ですか？。改善と改革はどうちがうのか？という問いにぶつかることがある。現状より良くするんだったら、改革も改善の内と捕らえる訳だ。其の問いに応える方が、現在のトレンドの中で徐々に行うのが改善で、改革は方法論から見直したもので効果も劇的に変わるものとする。どちらも正しい。ここでの改善は全部含めます。
さてと、世間には改善か改悪か分からないものも少なくありません。単に方法論を入れ替えただけで別の問題の要因になることすらあります。改善のような顔をしていて実は誰かの特定の問題に手を売っただけというケースもあります。
改善とは何か？＝何が問題か？
発生した現象と本質原因の関係は仮説でしかないことも理解しなければいけない。
.*.
コミュニケーションの改善、教育の改善など人間系の管理策しか出てこなければ、多分、不正解。人間はいい加減なものだからです。人間は間違える存在であること
.*.
改善なんて普通ですか？。改善と改革はどうちがうのか？という問いにぶつかることがある。現状より良くするんだったら、改革も改善の内と捕らえる訳だ。其の問いに応える方が、現在のトレンドの中で徐々に行うのが改善で、改革は方法論から見直したもので効果も劇的に変わるものとする。どちらも正しい。ここでの改善は全部含めます。
さてと、世間には改善か改悪か分からないものも少なくありません。単に方法論を入れ替えただけで別の問題の要因になることすらあります。改善のような顔をしていて実は誰かの特定の問題に手を売っただけというケースもあります。
改善とは何か？＝何が問題か？
発生した現象と本質原因の関係は仮説でしかないことも理解しなければいけない。
.*.
コミュニケーションの改善、教育の改善など人間系の管理策しか出てこなければ、多分、不正解。人間はいい加減なものだからです。人間は間違える存在であること
.*.
6.1.2 情報セキュリティリスクアセスメント
06
06.1
06.1.2
情報セキュリティリスクアセスメント
リスクアセスメントプロセスを定義すること：
a) リスク基準の確立
b) リスクアセスメントの実施基準の決定
c) リスクアセスメントが一貫性、妥当性、比較可能性。
d) リスクを特定する。
1）適用範囲内の資産のＣＩＡ喪失時のリスクを予め決めた手順を適用して特定する。
リスクアセスメントプロセスの適用。変な言い方だな。英語圏のものの言い方なんだろう。
前の規格バージョンでは、情報資産、資産価値、脅威、脆弱性の用語の本質理解には難しい面があった。
先ず、資産価値は資産の価値でなく資産価値を損ねたときの影響度を資産価値としていたから分かりにくい。１億円の工作機械を持っていて資産価値はいくらか？答えは１億円でなく、工作機械が使えないときのビジネス機会損失額だから鼻から難しかった訳です。
脅威と脆弱性も絡み合う関係にあるので分離できません。無理矢理、自分でコントロールできないものを脅威、コントロール出来るものを脆弱性とやっていますが、ただの方便に過ぎないことは誰でもわかりますし、その線引き作業が時間の無駄だ。
2） リスクオーナーを特定
リスクオーナーとは？経営品質などで言うところの「問題の所有者」のことでしょう。リスク（被害･損害）の回避、解消、軽減を行うべき直接の責任者。経営から権限と責任を委託されている人。リスクオーナーの概念の導入は企業の機能配置、役割責任の曖昧さを修復できる期待がある。
e) 情報セキュリティリスクの分析
1）特定されたリスクが生じた場合の潜在的な結果の評価
• 特定されたリスクの現実的な発生可能性の評価
• リスクレベルの決定
f) 情報セキュリティリスクの評価
• 分析されたリスクをリスク基準と比較し、リスク対応の優先順位を決定
06.1
06.1.2
情報セキュリティリスクアセスメント
リスクアセスメントプロセスを定義すること：
a) リスク基準の確立
b) リスクアセスメントの実施基準の決定
c) リスクアセスメントが一貫性、妥当性、比較可能性。
d) リスクを特定する。
1）適用範囲内の資産のＣＩＡ喪失時のリスクを予め決めた手順を適用して特定する。
リスクアセスメントプロセスの適用。変な言い方だな。英語圏のものの言い方なんだろう。
前の規格バージョンでは、情報資産、資産価値、脅威、脆弱性の用語の本質理解には難しい面があった。
先ず、資産価値は資産の価値でなく資産価値を損ねたときの影響度を資産価値としていたから分かりにくい。１億円の工作機械を持っていて資産価値はいくらか？答えは１億円でなく、工作機械が使えないときのビジネス機会損失額だから鼻から難しかった訳です。
脅威と脆弱性も絡み合う関係にあるので分離できません。無理矢理、自分でコントロールできないものを脅威、コントロール出来るものを脆弱性とやっていますが、ただの方便に過ぎないことは誰でもわかりますし、その線引き作業が時間の無駄だ。
2） リスクオーナーを特定
リスクオーナーとは？経営品質などで言うところの「問題の所有者」のことでしょう。リスク（被害･損害）の回避、解消、軽減を行うべき直接の責任者。経営から権限と責任を委託されている人。リスクオーナーの概念の導入は企業の機能配置、役割責任の曖昧さを修復できる期待がある。
e) 情報セキュリティリスクの分析
1）特定されたリスクが生じた場合の潜在的な結果の評価
• 特定されたリスクの現実的な発生可能性の評価
• リスクレベルの決定
f) 情報セキュリティリスクの評価
• 分析されたリスクをリスク基準と比較し、リスク対応の優先順位を決定
6.1.1 一般
06
06.1
06.1.1
一般
06.1.1a)
06.1.1b)
「リスク＆オポチュニティ」
これでワンフレーズです。リスクだけでも実はリスク＆オポチュニティなんですが、普通リスクは悪い意味で使われることが多いので、敢えて、リスクとオポチュニティとセットで用語にしているのですね。だから、ここのリスクはネガティブに振れるリスクでポジティブに振れるリスクはオポチュニティとしているだけです。
従来のリスク（下振れも上振れも含む）と本質は同義です。
しかしながら、実際問題ではオポの部分の評価は難しい。リスクを小さく見る裏返しだからだ。既存の管理策を評価することがＩＳＯ化のときに明記されたが、これもオポの一環と見て差し支えない。
リスクもオポも不確実なものであり、リスク低減あるいはオポ実現にはそれを確実にする施策が求められる。
狭義の発想でいくなら、リスクは現在の管理策の脆弱性評価であり、オポは新たな管理策への期待値評価である。
新たな管理策に対する脆弱性評価はリスクの部、既存の管理策に対する脆弱性が別要因で下がる、また脅威が別要因で下がるならオポに入る。
-
テナントが手を打つのでなくビルオーナーが入館システムを改善するのはオポです。改悪の場合はリスク。
脅威そのものの変動を見る。従来はどちらかといえば脅威は管理対象外として評価は一面的だった。
6.1.1b)
旧バージョン8.3予防処置が消えたといって騒いでいる人が居るがその輩は旧バージョンの理解が出来ていなかった可能性がある。もともと旧バージョン規格は重複していたのですよ。「リスクアセスメント」（リスク対応も含め）と「予防処置」と「事業継続管理」は基本的に被って（かぶって）いましたから。
もう一つの勘違いは、PDCAサイクルの中での予防処置の位置づけを動的に見るか静的にみるかの違いです。リスクアセスを年１回のイベントに位置づけてしまった人は今回は混乱することでしょう。
06.1
06.1.1
一般
06.1.1a)
06.1.1b)
「リスク＆オポチュニティ」
これでワンフレーズです。リスクだけでも実はリスク＆オポチュニティなんですが、普通リスクは悪い意味で使われることが多いので、敢えて、リスクとオポチュニティとセットで用語にしているのですね。だから、ここのリスクはネガティブに振れるリスクでポジティブに振れるリスクはオポチュニティとしているだけです。
従来のリスク（下振れも上振れも含む）と本質は同義です。
しかしながら、実際問題ではオポの部分の評価は難しい。リスクを小さく見る裏返しだからだ。既存の管理策を評価することがＩＳＯ化のときに明記されたが、これもオポの一環と見て差し支えない。
リスクもオポも不確実なものであり、リスク低減あるいはオポ実現にはそれを確実にする施策が求められる。
狭義の発想でいくなら、リスクは現在の管理策の脆弱性評価であり、オポは新たな管理策への期待値評価である。
新たな管理策に対する脆弱性評価はリスクの部、既存の管理策に対する脆弱性が別要因で下がる、また脅威が別要因で下がるならオポに入る。
-
テナントが手を打つのでなくビルオーナーが入館システムを改善するのはオポです。改悪の場合はリスク。
脅威そのものの変動を見る。従来はどちらかといえば脅威は管理対象外として評価は一面的だった。
6.1.1b)
旧バージョン8.3予防処置が消えたといって騒いでいる人が居るがその輩は旧バージョンの理解が出来ていなかった可能性がある。もともと旧バージョン規格は重複していたのですよ。「リスクアセスメント」（リスク対応も含め）と「予防処置」と「事業継続管理」は基本的に被って（かぶって）いましたから。
もう一つの勘違いは、PDCAサイクルの中での予防処置の位置づけを動的に見るか静的にみるかの違いです。リスクアセスを年１回のイベントに位置づけてしまった人は今回は混乱することでしょう。
4.2 利害関係者のニーズ及び期待の理解
04
04.2
利害関係者のニーズ及び期待の理解
ニーズと期待が難しい。
契約があるものならそこに規定されている訳だが、単にニーズ期待ではぼんやりとしたものになるだろう。理解する方法論が提供されなければいけない。其の方法論の妥当性が検証されなければいけない。
利害関係者が特定についても同様だ。小規模事業者ならまだ良いとしても大規模事業者となれば適切な方法論が維持されなければ利害関係者は洗いきれないだろう。
04.2
利害関係者のニーズ及び期待の理解
ニーズと期待が難しい。
契約があるものならそこに規定されている訳だが、単にニーズ期待ではぼんやりとしたものになるだろう。理解する方法論が提供されなければいけない。其の方法論の妥当性が検証されなければいけない。
利害関係者が特定についても同様だ。小規模事業者ならまだ良いとしても大規模事業者となれば適切な方法論が維持されなければ利害関係者は洗いきれないだろう。
4.1 組織及びその連関状況の理解
04
04.1
組織及びその連関状況の理解
Organization⇒組織
Context⇒連関
要求事項「組織の外部･内部の課題を決定すること」
前バージョン8.3予防処置が入る？。
少しニュンスが異なる。
マネジメントシステムは1年サイクルと決まった訳ではないが、多くは1年サイクルで大きなＰＤＣＡを回している。その中でも不適合があれば是正処置、あるいは他山の石でもあれば予防処置を行う。
この4.1の課題の決定が、日々のことなら旧版の8.3を含むといえるが、年度サイクルの作業なら、前年度総括したものが入るだけで緊急的な予防処置は含まれない。油断すると穴が開くので注意することだ。
なお、予防処置は6.1へも反映される。
.*.
課題決定の方法論としては
ＩＳＯ31000の5.3.1を参照することを求めている。
ＩＳＯ31000
.*.
04.1
組織及びその連関状況の理解
Organization⇒組織
Context⇒連関
要求事項「組織の外部･内部の課題を決定すること」
前バージョン8.3予防処置が入る？。
少しニュンスが異なる。
マネジメントシステムは1年サイクルと決まった訳ではないが、多くは1年サイクルで大きなＰＤＣＡを回している。その中でも不適合があれば是正処置、あるいは他山の石でもあれば予防処置を行う。
この4.1の課題の決定が、日々のことなら旧版の8.3を含むといえるが、年度サイクルの作業なら、前年度総括したものが入るだけで緊急的な予防処置は含まれない。油断すると穴が開くので注意することだ。
なお、予防処置は6.1へも反映される。
.*.
課題決定の方法論としては
ＩＳＯ31000の5.3.1を参照することを求めている。
ＩＳＯ31000
.*.
4 組織の状況
4. 組織の状況
旧バージョン4.2.1a)の密度が濃すぎたから丁度よくなった。リスクアセスに関する重複も少し解消されたかもしれない。
- 4.1 組織及びその状況の理解
外部及び内部の課題を決定は、旧バージョンの8.3予防処置と同じな訳はありません。むしろリスクアセスメントの方が近い概念だ。旧バージョン4.2.1a)の事業・組織・所在地・資産・技術の特徴はここに入る。
- 4.2 利害関係者のニーズ及び期待の理解
利害関係者の要求事項を把握。法的、規制要求事項、契約上の義務はステークホルダーの要求事項に含まれることは確実。
- 4.3 情報セキュリティマネジメントシステムの適用範囲の決定
「4.1」「4.2」を踏まえてＩＳＭＳ適用範囲を決める。管理スパン（責任範囲・権限の範囲・・・）を決める。
- 4.4 情報セキュリティマネジメントシステム
ここはなに。ＩＳＭＳの現状ですか。
***
3 用語及び定義
用語、定義は見直しが行われている。アップToデートの一環と規格間の整合性の確保。用語は２７０００にもあるのでそちらが引用される。個別の用語定義はない。ちなみに前バージョンは１+６個の用語定義が記載されていた。どういう基準で選択された用語かは分からなかった。
ＩＳＭＳ基本方針が情報セキュリティ方針に変更。意図は？。単に分かりやすい一般名にしただけかな。
ＩＳＭＳの目的も同様に情報セキュリティの目的に変更。
※
「言葉/用語」というものは最初は名詞として使われていても流布するにつれて徐々に動詞的にも使われる。「方針」も「目的」も本来は管理（マネジメント）に対するものだから従来の定義の方が正しい。ところが「セキュリティ」という言葉自体にセキュリティの維持であるとか確保するとかの意味が入ってきて直接「方針」『目的」を繋いでも違和感がなくなってきたのだろう。
+
ＩＳＭＳ基本方針が情報セキュリティ方針に変更。意図は？。単に分かりやすい一般名にしただけかな。
ＩＳＭＳの目的も同様に情報セキュリティの目的に変更。
※
「言葉/用語」というものは最初は名詞として使われていても流布するにつれて徐々に動詞的にも使われる。「方針」も「目的」も本来は管理（マネジメント）に対するものだから従来の定義の方が正しい。ところが「セキュリティ」という言葉自体にセキュリティの維持であるとか確保するとかの意味が入ってきて直接「方針」『目的」を繋いでも違和感がなくなってきたのだろう。
+
2 引用規格
飲用規格から27002が外れたって？規格の構成・位置づけを修正しているから当然。シリーズ規格27000が替わりに入る。管理策の部分はもともと引用するものであるまい。
ISO/IEC 27000
（情報技術－セキュリティ技術－情報セキュリティマネジメントシステム－概要及び用語）
ISO/IEC 27000
（情報技術－セキュリティ技術－情報セキュリティマネジメントシステム－概要及び用語）
0 序文
プロセスアプローチ
前バージョンでは0.2プロセスアプローチとしてＰＤＣＡが紹介されていた。ＴＱＣの骨子が回りまわってＩＳＭＳにまで入り込んでいたのが、目出度くＲＥＪＥＣＴされた訳だ。
改善の方法論はいくつもあるし、問題の特性によって程度も替わる。ＰＤＣＡの誤解・誤用もある。特にＴＱＣの歴史を持たない海外では杓子定規が入ると手に負えなくなる。
某審査機関などは既にＴＱＣが何かも知らない若い連中が中堅になっているから既にプロセスアプローチの意味さえ理解できていない。加えて文言が外されるので例のいびつな審査が更に強化されることになるだろう。
前バージョンでは0.2プロセスアプローチとしてＰＤＣＡが紹介されていた。ＴＱＣの骨子が回りまわってＩＳＭＳにまで入り込んでいたのが、目出度くＲＥＪＥＣＴされた訳だ。
改善の方法論はいくつもあるし、問題の特性によって程度も替わる。ＰＤＣＡの誤解・誤用もある。特にＴＱＣの歴史を持たない海外では杓子定規が入ると手に負えなくなる。
某審査機関などは既にＴＱＣが何かも知らない若い連中が中堅になっているから既にプロセスアプローチの意味さえ理解できていない。加えて文言が外されるので例のいびつな審査が更に強化されることになるだろう。
登録:
投稿 (Atom)
BLOGLIST(B)
-
-
-
-
-
経緯 - 経緯： 審査員になるために必要な常識を抑えること。学習の一環としてのページ制作。共同学習の場作り。スタートはそんなものだった。 審査員のあるべき姿はそこには無く、見たくないものばかりが並んでいる。 非常識まかり通る。 非常識は個々の審査員に由来する。 審査員の行動は審査機関が糸を引く。 法の番人が法を...11 年前
-
