2012年01月25日
ドコモの不通話トラブルが都内で発生！ＩＳＭＳではどう見るか？
本日（2012/1/25）都内で４時間ほど、どこも携帯が利用できなくなった。メールなども繋がりにくい状態が続いた。
携帯電話を事業上・業務上のキーファクターとしているものを調べる。本日発生したトラブルでどのような事態が起きたかどうか見る。事業継続計画が策定されていたら、適切に作動したかを調べる。
業務上には、緊急時の対応も考慮する。緊急時の連絡を携帯を前提としていないか。そのときのリスクの見極め。
安否連絡システムを導入しているところでは、その実効性を改めて検証すること。
スマホが普及すれば、人が特定の場所で集中的にケータイを使い始めれば、急速に通信機器に負荷が掛かって、いつでも何処でも起こりうる事態です。通信機器の不具合もありえます。
.*.
本日（2012/1/25）都内で４時間ほど、どこも携帯が利用できなくなった。メールなども繋がりにくい状態が続いた。
携帯電話を事業上・業務上のキーファクターとしているものを調べる。本日発生したトラブルでどのような事態が起きたかどうか見る。事業継続計画が策定されていたら、適切に作動したかを調べる。
業務上には、緊急時の対応も考慮する。緊急時の連絡を携帯を前提としていないか。そのときのリスクの見極め。
安否連絡システムを導入しているところでは、その実効性を改めて検証すること。
スマホが普及すれば、人が特定の場所で集中的にケータイを使い始めれば、急速に通信機器に負荷が掛かって、いつでも何処でも起こりうる事態です。通信機器の不具合もありえます。
.*.
不正アクセス禁止法改正案
フィッシング手口＝ＩＤやパスワードなどの情報を収集するだけ、または保持するだけで犯罪になる。
現行法では実害が発生しない限り訴えることが出来ないらしい。
これはＩＳＭＳとしてはどうなるか？
不用意な情報収集はリスクが伴うということ。
会員登録時、問い合わせ時などに、必要ないだろうと思われる情報まで集めているが、何らかの線引きが求められるかもしれない。
.*.
フィッシング手口＝ＩＤやパスワードなどの情報を収集するだけ、または保持するだけで犯罪になる。
現行法では実害が発生しない限り訴えることが出来ないらしい。
これはＩＳＭＳとしてはどうなるか？
不用意な情報収集はリスクが伴うということ。
会員登録時、問い合わせ時などに、必要ないだろうと思われる情報まで集めているが、何らかの線引きが求められるかもしれない。
.*.
2012年01月19日
ウイルス定義ファイルの更新日を確認する
ウイルス守対策ソフトのウイルス定義ファイル〜ウイルスパターンファイルの更新日付の確認はとても重要なことです。パターンコードだけが表示されるのでは新しいのか古いのか分かりません。状況にもよりますが、1日に何度も更新されて当たり前の昨今では、時間（時刻）も必要でしょう。
多くの人は情報システム部門で設定しているので、ユーザーは特に何もしなくて良いと思い込んでいます。正しく更新されている「筈」で済ませています。「然うは問屋が卸さない」のがセキュリティの世界です。
シマンテック（ノートン）は分かりやすい。
マイクロソフトのエッセンシャルも分かりやすい。
アヴァスト！も分かりやすい。
例外的にトレンドマイクロのウイルスバスターは分かり難い。どうなっているの？
「ウイルスバスター ウイルス定義ファイル 更新日付」
色々探しても良く分からない。何が最新かはトレンドマイクロの何処のページを見ればよいかの案内が有るが、問題は自分のパソコンに最新が来ているかどうかを知ること。不親切なサイトあるいは不親切なウイルスバスターのコンソールを見ていて気分が悪くなった。正しくタイムリーにリリースさせることが出来ないから分かり難くしている訳でもないだろうが、探して見つからないのは嫌なものだ。
ウイルスバスターを利用しない理由の一端はこの辺にあるのだろう。マカフィーもそう言えば利用しないね。
ウイルス守対策ソフトのウイルス定義ファイル〜ウイルスパターンファイルの更新日付の確認はとても重要なことです。パターンコードだけが表示されるのでは新しいのか古いのか分かりません。状況にもよりますが、1日に何度も更新されて当たり前の昨今では、時間（時刻）も必要でしょう。
多くの人は情報システム部門で設定しているので、ユーザーは特に何もしなくて良いと思い込んでいます。正しく更新されている「筈」で済ませています。「然うは問屋が卸さない」のがセキュリティの世界です。
シマンテック（ノートン）は分かりやすい。
マイクロソフトのエッセンシャルも分かりやすい。
アヴァスト！も分かりやすい。
例外的にトレンドマイクロのウイルスバスターは分かり難い。どうなっているの？
「ウイルスバスター ウイルス定義ファイル 更新日付」
色々探しても良く分からない。何が最新かはトレンドマイクロの何処のページを見ればよいかの案内が有るが、問題は自分のパソコンに最新が来ているかどうかを知ること。不親切なサイトあるいは不親切なウイルスバスターのコンソールを見ていて気分が悪くなった。正しくタイムリーにリリースさせることが出来ないから分かり難くしている訳でもないだろうが、探して見つからないのは嫌なものだ。
ウイルスバスターを利用しない理由の一端はこの辺にあるのだろう。マカフィーもそう言えば利用しないね。
2012年01月17日
手抜かりの多い「記録の管理」
記録の管理がまるで分かっていないことに気がつかされる。書式の枠を埋めてバインダーに閉じてキャビネットに収容して施錠。期限がきたら廃棄する。これが記録の管理ですか。ただのISMSごっこではあ〜りませんか。
コンピューターの各種ログも同じ。監視カメラのビデオ情報も同じ。℡応答時の音声データの記録も同じ。入室時の電子錠のデータも同じ。
保管も管理には違いないが、そこで得られる効用はトレーサビリティだけ。何か問題が起きた場合、原因究明に利用できるというもの。基本的には後の祭り。社会に対して説明責任を果たすことも出来ない。
.*.
ISMSの規格を見ても、記録管理におけるダイナミズムの観点がなかなか読み取れない。当たり前すぎる問題だから？ 嫌、記録に対する概念が実は確立されていないからですね。狭義の記録は活動結果を示すデータ的なもの。活動のための計画は記録か文書かはっきりしない。年度方針は記録ですか、文書ですか。両者を分ける定義は実は存在しません。無理に分けても意味を成さないと言った方が正しいでしょうか。
ISO27001：2013では文書と記録をもっと統一的に扱うようにチャレンジします。
.*.
さて、ここでは、「記録の目的」を明確にせよ、あるいは正しく理解せよと申し上げたい。また実際に記録を取り始めた時には、果たして、目的を達成できる記録内容かどうかも常々チェックすることが必要であることも申し上げたい。
好き嫌いの問題はありますが、「超監視社会」の実現です。SF映画でよく表現される不愉快な社会の実現ですから、その内、人に優しいセキュリティが議論される時代が来るかもしれませんね。
.*.
但し、当初の目的とは違ったことに記録を利用しようとする時は注意が必要です。データの特性･素性、目的外利用の可否など。
.*.
記録の管理がまるで分かっていないことに気がつかされる。書式の枠を埋めてバインダーに閉じてキャビネットに収容して施錠。期限がきたら廃棄する。これが記録の管理ですか。ただのISMSごっこではあ〜りませんか。
コンピューターの各種ログも同じ。監視カメラのビデオ情報も同じ。℡応答時の音声データの記録も同じ。入室時の電子錠のデータも同じ。
保管も管理には違いないが、そこで得られる効用はトレーサビリティだけ。何か問題が起きた場合、原因究明に利用できるというもの。基本的には後の祭り。社会に対して説明責任を果たすことも出来ない。
.*.
ISMSの規格を見ても、記録管理におけるダイナミズムの観点がなかなか読み取れない。当たり前すぎる問題だから？ 嫌、記録に対する概念が実は確立されていないからですね。狭義の記録は活動結果を示すデータ的なもの。活動のための計画は記録か文書かはっきりしない。年度方針は記録ですか、文書ですか。両者を分ける定義は実は存在しません。無理に分けても意味を成さないと言った方が正しいでしょうか。
ISO27001：2013では文書と記録をもっと統一的に扱うようにチャレンジします。
.*.
さて、ここでは、「記録の目的」を明確にせよ、あるいは正しく理解せよと申し上げたい。また実際に記録を取り始めた時には、果たして、目的を達成できる記録内容かどうかも常々チェックすることが必要であることも申し上げたい。
好き嫌いの問題はありますが、「超監視社会」の実現です。SF映画でよく表現される不愉快な社会の実現ですから、その内、人に優しいセキュリティが議論される時代が来るかもしれませんね。
.*.
但し、当初の目的とは違ったことに記録を利用しようとする時は注意が必要です。データの特性･素性、目的外利用の可否など。
.*.
International Register of ISMS Certificates
http://www.iso27001certificates.com/
.*.
ちんけ（チンケ？）なサイトです。素人が作ったような。殆どメンテナンスされていない。事務的に作っただけで、サイト運営に関する情熱がまるで伝わってこない。使いやすさも何も考えていない。というか、そもそもここに登録しても何の意味もなさそうだ。
認証機関の名称も古いままだ。
どの程度ここは正しいのか？いい加減なサイトに見える。
誰がどのように使うサイトなんだろう。認証を取得していることを照明する訳じゃないでしょうし、意味無いね。
こんなところに登録していると、逆に、品位が低く見られる。
海外のISMSが日本とはまるで違ったレベルのものだということも理解できる。
.*.
登録を取り消しておいたほうが良さそうに見える。
ここのサイト運営の責任者は不真面目で失礼な感じだ。嫌だね。
.*.
こんなサイトへの登録を進める人が居たらその人を疑うね。
.*.
http://www.iso27001certificates.com/
.*.
ちんけ（チンケ？）なサイトです。素人が作ったような。殆どメンテナンスされていない。事務的に作っただけで、サイト運営に関する情熱がまるで伝わってこない。使いやすさも何も考えていない。というか、そもそもここに登録しても何の意味もなさそうだ。
認証機関の名称も古いままだ。
どの程度ここは正しいのか？いい加減なサイトに見える。
誰がどのように使うサイトなんだろう。認証を取得していることを照明する訳じゃないでしょうし、意味無いね。
こんなところに登録していると、逆に、品位が低く見られる。
海外のISMSが日本とはまるで違ったレベルのものだということも理解できる。
.*.
登録を取り消しておいたほうが良さそうに見える。
ここのサイト運営の責任者は不真面目で失礼な感じだ。嫌だね。
.*.
こんなサイトへの登録を進める人が居たらその人を疑うね。
.*.
2012年01月16日
ＡＳＲエーエスアールの話が良く出てくる
でも評判が今一。何故だろう。噂では工数単価が相当安いということだが、審査業界の秩序破壊という意味で悪評判なのか、審査の質が悪いという意味で悪評判なのか、本当のところはよく分からない。
既存の審査機関は敷居が高い。こういう新手の審査機関が敷居が低いのかもしれない。結果、ＩＳＭＳの普及に貢献することになるかもしれない。
ただ、優秀な審査員が待遇の悪い審査機関に行くとも思えない。玉石の石も結構混じるのではないか懸念される。石が審査した結果は、認証そのものを混乱させてクライアントまで迷惑を受ける羽目になるかもしれない。昔から「安物買いの銭失い」というから慎重な態度が望まれますね。審査員を慎重に吟味することです。そういう権利はありますから。
いずれにしても客観的なデータあるいは事実を確認したいものです。
.*.
結局は高く付く結果になるかも知れないＡＳＲに飛びついてしまう理由は簡単です。
ＩＳＭＳ取得は入札条件、取引条件にＩＳＭＳ認証取得が入り始めたからです。大企業ばかりならそのような条件が入っても既に取得済みなら何も変わりませんが、下請けの下請けを繰り返せば如何しても中小企業にお鉢は回ってきます。
小さいところがＩＳＯをやるのは想像以上に負担です。実務的にも心理的にも。そう言う時に、安い、従って手順もシンプルな審査は重宝することになります。
簡便な審査は、手抜きではなければ有効なわけですから、先を見ない限りは取り敢えずＯＫですね。
.*.
審査機関を見張る認定機関ＪＩＰＤＥＣの出方が問題になります。
.*.
エーエスアール株式会社
http://www.armsr.co.jp/
中途採用もやっている。どれくらいの給与水準でしょうか？
.*.
（追記）
本当にしつこいくらいASRの検索が多い。どちらかといえばネガティブな用語と一緒に検索されている。何があったのだろう。何が起きているのだろう。不健全なことが無いことを願うものです。
でも評判が今一。何故だろう。噂では工数単価が相当安いということだが、審査業界の秩序破壊という意味で悪評判なのか、審査の質が悪いという意味で悪評判なのか、本当のところはよく分からない。
既存の審査機関は敷居が高い。こういう新手の審査機関が敷居が低いのかもしれない。結果、ＩＳＭＳの普及に貢献することになるかもしれない。
ただ、優秀な審査員が待遇の悪い審査機関に行くとも思えない。玉石の石も結構混じるのではないか懸念される。石が審査した結果は、認証そのものを混乱させてクライアントまで迷惑を受ける羽目になるかもしれない。昔から「安物買いの銭失い」というから慎重な態度が望まれますね。審査員を慎重に吟味することです。そういう権利はありますから。
いずれにしても客観的なデータあるいは事実を確認したいものです。
.*.
結局は高く付く結果になるかも知れないＡＳＲに飛びついてしまう理由は簡単です。
ＩＳＭＳ取得は入札条件、取引条件にＩＳＭＳ認証取得が入り始めたからです。大企業ばかりならそのような条件が入っても既に取得済みなら何も変わりませんが、下請けの下請けを繰り返せば如何しても中小企業にお鉢は回ってきます。
小さいところがＩＳＯをやるのは想像以上に負担です。実務的にも心理的にも。そう言う時に、安い、従って手順もシンプルな審査は重宝することになります。
簡便な審査は、手抜きではなければ有効なわけですから、先を見ない限りは取り敢えずＯＫですね。
.*.
審査機関を見張る認定機関ＪＩＰＤＥＣの出方が問題になります。
.*.
エーエスアール株式会社
http://www.armsr.co.jp/
中途採用もやっている。どれくらいの給与水準でしょうか？
.*.
（追記）
本当にしつこいくらいASRの検索が多い。どちらかといえばネガティブな用語と一緒に検索されている。何があったのだろう。何が起きているのだろう。不健全なことが無いことを願うものです。
2012年01月15日
ＮＰＯ日本ネットワークセキュリティ協会
http://www.jnsa.org/
社会に貢献するようなことをいろいろやっている。セキュリティ教育（eラーニング）なども無料で提供しているようだ。
.*.
情報セキュリティインシデントに関する調査報告書〜発生確率編〜
NPO 日本ネットワークセキュリティ協会
セキュリティ被害調査ワーキンググループ
2011年3月31日
http://www.jnsa.org/result/incident/data/2010incident_survey_probability.pdf
.*.
http://www.jnsa.org/
社会に貢献するようなことをいろいろやっている。セキュリティ教育（eラーニング）なども無料で提供しているようだ。
.*.
情報セキュリティインシデントに関する調査報告書〜発生確率編〜
NPO 日本ネットワークセキュリティ協会
セキュリティ被害調査ワーキンググループ
2011年3月31日
http://www.jnsa.org/result/incident/data/2010incident_survey_probability.pdf
.*.
遠隔診断用及び環境設定用ポートの保護とは？
コンピューターを外部と接続させるポートには幾つかあるらしい。このポートは脆弱性の一つにされることもあるため適切に保護しなければならない。相手を特定したり、通信プロトコルを特定したり、多分、するんでしょう。
遠隔診断、環境設定用のポートは漬け込まれたときのリスクが大きい（コンピューターを乗っ取られてしまう）ので、ポートに対する保護策は重要である。
ところが、時々、この管理策を採用しないと表明する組織があるのには驚かされる。適用宣言書の除外項目に平気で入ってくる。何もしないで放置するのは有り得ない話ですよ。当組織ではこのポートは使っていない。だけで済ましてしまう。使えなくしてあれば立派な管理策です。使わないから放置してある？
どうぞこのコンピューターを乗っ取ってくださいとやる組織は有りませんから、ほぼ全組織が採用する管理策になります。
.*.
取引先の適用宣言書を見て、仮に管理策（A.11.4.4）が適用除外になっていたら、その組織は何か怪しいと思っていいでしょう。兎に角、何らかの事情を抱えた会社と言うことになります。
.*.
コンピューターを外部と接続させるポートには幾つかあるらしい。このポートは脆弱性の一つにされることもあるため適切に保護しなければならない。相手を特定したり、通信プロトコルを特定したり、多分、するんでしょう。
遠隔診断、環境設定用のポートは漬け込まれたときのリスクが大きい（コンピューターを乗っ取られてしまう）ので、ポートに対する保護策は重要である。
ところが、時々、この管理策を採用しないと表明する組織があるのには驚かされる。適用宣言書の除外項目に平気で入ってくる。何もしないで放置するのは有り得ない話ですよ。当組織ではこのポートは使っていない。だけで済ましてしまう。使えなくしてあれば立派な管理策です。使わないから放置してある？
どうぞこのコンピューターを乗っ取ってくださいとやる組織は有りませんから、ほぼ全組織が採用する管理策になります。
.*.
取引先の適用宣言書を見て、仮に管理策（A.11.4.4）が適用除外になっていたら、その組織は何か怪しいと思っていいでしょう。兎に角、何らかの事情を抱えた会社と言うことになります。
.*.
2012年01月14日
独立したレビューとは？
独立とは何が何に対して独立か。ＩＳＭＳを推進している人（組織）に対して客観性を維持できる人・組織あるいは場の意味で独立していること。
普通に考えればマネジメントレビューが一番近い。この時に重要なのは内部監査責任者の立ち位置である。
マネジメントレビューでは情報セキュリティ管理責任者が経営者に報告し指示を受ける訳だが、情報セキュリティ管理責任者の一方的な言い分・報告をベースにしていたのでは客観性は維持されないくい。内部監査責任者が情報セキュリティ管理責任者と対等なスタンスでカウンター報告が同時にされなければいけない。
内部監査責任者が情報セキュリティ管理責任者の配下のものであってはならない。
繰り返すことになるが、マネジメントレビューの場で、内部監査結果報告が情報セキュリティ管理責任者からなされてはいけない。
マネジメントレビューの前に、内部監査責任者は監査計画および監査結果についての承認を経営者から得ることが望ましい。内部監査責任者は経営者に成り代わってＩＳＭＳを点検しなければいけない。
.*.
初期段階、規模の小さな組織では、ＩＳＭＳの事務局の人間が内部監査まで担当している。開発製造担当が品質保証も兼務しているようなもの。
工程能力の関係で止むを得ない状況だが、こういう場合もどのようにして客観性を確保するかが工夫のしどころです。
.*.
独立とは何が何に対して独立か。ＩＳＭＳを推進している人（組織）に対して客観性を維持できる人・組織あるいは場の意味で独立していること。
普通に考えればマネジメントレビューが一番近い。この時に重要なのは内部監査責任者の立ち位置である。
マネジメントレビューでは情報セキュリティ管理責任者が経営者に報告し指示を受ける訳だが、情報セキュリティ管理責任者の一方的な言い分・報告をベースにしていたのでは客観性は維持されないくい。内部監査責任者が情報セキュリティ管理責任者と対等なスタンスでカウンター報告が同時にされなければいけない。
内部監査責任者が情報セキュリティ管理責任者の配下のものであってはならない。
繰り返すことになるが、マネジメントレビューの場で、内部監査結果報告が情報セキュリティ管理責任者からなされてはいけない。
マネジメントレビューの前に、内部監査責任者は監査計画および監査結果についての承認を経営者から得ることが望ましい。内部監査責任者は経営者に成り代わってＩＳＭＳを点検しなければいけない。
.*.
初期段階、規模の小さな組織では、ＩＳＭＳの事務局の人間が内部監査まで担当している。開発製造担当が品質保証も兼務しているようなもの。
工程能力の関係で止むを得ない状況だが、こういう場合もどのようにして客観性を確保するかが工夫のしどころです。
.*.
審査所見に記載された部門名の意味？
色々な審査会社の色々な審査報告を見るときっと想像以上に違いの大きさに驚くのではないだろうか。
審査所見に部門名が書いてある。
この部門名は何を意味するのか？ある部門へ行って審査をして出てきた問題を所見にする場合に、その部門名を記載しますが、その時の部門名の持つ意味は、単に問題を時間・場所・プログラムのコマを示していることになる。問題の所有者、問題解決の責任者としての部門名ではない。
その問題は他の時間･場所・プログラムのコマでも検出される可能性がある。審査は基本的にサンプリングで行われるため、現実に検出されるのが1箇所にとどまる場合もある。勿論、その部門の固有の問題であればその部門でしか検出されない。
検出される問題が1箇所か複数個所かはあまり重要でない。決定的ではない。複数箇所は重大だが、1箇所なら重大でないと決めて掛かって安心は出来ないと言うことです。
ところで、
時々、部門名のほかに事務局を併記している所見を見かける。これが如何しても分かりません。この審査員は部門名（発見場所）の他に、事務局と記載することで何を説明しようとしているのでしょう？
まさか、部門固有の問題か共通の問題かを説明しているのではないでしょうね。
そうなると部門名の意味が全く変わってくる。誰が対策すべきかを指示していることになりかねない。立派な越権行為？
複数個所で同様の指摘がある場合に事務局と記載しているものもある。事務局への注意喚起をしているつもりだろうが冗談ではない。サンプリングでしかやってない審査では件数の多少によらず事務局は全てを精査せざるを得ない。
要は審査員が余計なノイズを入れてはいけないということ。
複数部門で同様の問題が検出された場合は、最初の部門名を書くか、幾つかを併記し、それを超える場合はその他で括れば充分だろう。
色々な審査会社の色々な審査報告を見るときっと想像以上に違いの大きさに驚くのではないだろうか。
審査所見に部門名が書いてある。
この部門名は何を意味するのか？ある部門へ行って審査をして出てきた問題を所見にする場合に、その部門名を記載しますが、その時の部門名の持つ意味は、単に問題を時間・場所・プログラムのコマを示していることになる。問題の所有者、問題解決の責任者としての部門名ではない。
その問題は他の時間･場所・プログラムのコマでも検出される可能性がある。審査は基本的にサンプリングで行われるため、現実に検出されるのが1箇所にとどまる場合もある。勿論、その部門の固有の問題であればその部門でしか検出されない。
検出される問題が1箇所か複数個所かはあまり重要でない。決定的ではない。複数箇所は重大だが、1箇所なら重大でないと決めて掛かって安心は出来ないと言うことです。
ところで、
時々、部門名のほかに事務局を併記している所見を見かける。これが如何しても分かりません。この審査員は部門名（発見場所）の他に、事務局と記載することで何を説明しようとしているのでしょう？
まさか、部門固有の問題か共通の問題かを説明しているのではないでしょうね。
そうなると部門名の意味が全く変わってくる。誰が対策すべきかを指示していることになりかねない。立派な越権行為？
複数個所で同様の指摘がある場合に事務局と記載しているものもある。事務局への注意喚起をしているつもりだろうが冗談ではない。サンプリングでしかやってない審査では件数の多少によらず事務局は全てを精査せざるを得ない。
要は審査員が余計なノイズを入れてはいけないということ。
複数部門で同様の問題が検出された場合は、最初の部門名を書くか、幾つかを併記し、それを超える場合はその他で括れば充分だろう。
パソコンの適切な管理：アップデート（更新）
マイクロソフトWindowsのアップデート
マイクロソフトOfficeのアップデート
ウイルス対策ソフトの更新（プログラムの更新とウイルス低後ファイルの更新）
アドビの各種アプリケーション
ＢＩＯＳアップデート
要は使っている全てのソフトウエア、ファームウエア、データ類の更新が確実に行える方法論ｇひつようになる。明確な手順が求められる。パソコンに限らない。サーバーも周辺機器も同様の考え方が求められる。脆弱性の管理。
マイクロソフトWindowsのアップデート
マイクロソフトOfficeのアップデート
ウイルス対策ソフトの更新（プログラムの更新とウイルス低後ファイルの更新）
アドビの各種アプリケーション
ＢＩＯＳアップデート
要は使っている全てのソフトウエア、ファームウエア、データ類の更新が確実に行える方法論ｇひつようになる。明確な手順が求められる。パソコンに限らない。サーバーも周辺機器も同様の考え方が求められる。脆弱性の管理。
2012年01月09日
クラウド利用時のコンプライアンス
クラウド環境利用に関連して生じる法的問題・課題について日経に記事が出ている。（詳しい生地は日経電子版にあるのかな？）
要点は３つ。
コンテンツをクラウドに保存して利用する場合。そのサービスを提供する業者はコンテンツ（著作物）の複製権、公衆送信権を侵害していると見做される恐れがあるというもの。
クラウド環境のグローバル利用の場合は、国家機密など国際的な平和や安全に関わるもの･技術の国際間取引では担当大臣の許可が必要とする外為法への抵触の懸念がある。大臣の許認可基準が明確でない。
個人情報をクラウド上で扱う場合（クラウド上でなくても同じですが）、EUのデータ保護指令のように個人情報保護水準をEU同等することを求められるなど、個人情報を海外に保管することへの制約がある。（個人情報保護については日本はEUより低水準とされている）
.*.
「ISMS」ではどうなるんでしょう？
① 直ぐに思い浮かぶのが、準拠法令の洗い出し。コンテンツサービス事業、クラウドの国際利用（海外クラウドの利用、海外からの国内クラウド利用）、個人情報管理でのクラウド利用などが事業・業務に収まる場合は適切に洗い出されていることですね。
② コンプライアンス違反とならないようにする規定・手順が明確にされていること。これは難しい。特にコンテンツサービスに絡むところは、著作権を持っているコンテンツかどうかはサービス業者からは分からないから。利用規約で健全な利用義務を入れてその内容として著作権法あるいは公衆送信法？に抵触しないことを求めておく必要がある。しかし、やりすぎると利用者が現れなくなるだろうから容易ではない。
.*.
クラウド環境利用に関連して生じる法的問題・課題について日経に記事が出ている。（詳しい生地は日経電子版にあるのかな？）
要点は３つ。
コンテンツをクラウドに保存して利用する場合。そのサービスを提供する業者はコンテンツ（著作物）の複製権、公衆送信権を侵害していると見做される恐れがあるというもの。
クラウド環境のグローバル利用の場合は、国家機密など国際的な平和や安全に関わるもの･技術の国際間取引では担当大臣の許可が必要とする外為法への抵触の懸念がある。大臣の許認可基準が明確でない。
個人情報をクラウド上で扱う場合（クラウド上でなくても同じですが）、EUのデータ保護指令のように個人情報保護水準をEU同等することを求められるなど、個人情報を海外に保管することへの制約がある。（個人情報保護については日本はEUより低水準とされている）
.*.
「ISMS」ではどうなるんでしょう？
① 直ぐに思い浮かぶのが、準拠法令の洗い出し。コンテンツサービス事業、クラウドの国際利用（海外クラウドの利用、海外からの国内クラウド利用）、個人情報管理でのクラウド利用などが事業・業務に収まる場合は適切に洗い出されていることですね。
② コンプライアンス違反とならないようにする規定・手順が明確にされていること。これは難しい。特にコンテンツサービスに絡むところは、著作権を持っているコンテンツかどうかはサービス業者からは分からないから。利用規約で健全な利用義務を入れてその内容として著作権法あるいは公衆送信法？に抵触しないことを求めておく必要がある。しかし、やりすぎると利用者が現れなくなるだろうから容易ではない。
.*.
2012年01月07日
グッドポイントを多発させる審査員
グッドポイントを多発させる審査員を希に見かける。困ったものです。
規格違反は比較的明確ですが、何がグッドか何がエクセレントかは相対的要素が大きくて明確でないことが多いからです。また言えばAさんにとって良いやり方がBさんにとっても良いやり方かどうかは全く分かりません。
その辺は落合博満のベストセラー「采配」にも要領よく記載されている。面白いものだ。
何も課題が見つけられずに書くことが無くて、しようがないから適当にグッドポイントでも書いたり、スタッフのやる気を引き出すためのご褒美的なグッドポイントを書いたり。もっとも指摘が無ければ無いで済ます普通の（健全な）審査員も居るようです。
.*.
グッドポイントを多発させる審査員を希に見かける。困ったものです。
規格違反は比較的明確ですが、何がグッドか何がエクセレントかは相対的要素が大きくて明確でないことが多いからです。また言えばAさんにとって良いやり方がBさんにとっても良いやり方かどうかは全く分かりません。
その辺は落合博満のベストセラー「采配」にも要領よく記載されている。面白いものだ。
何も課題が見つけられずに書くことが無くて、しようがないから適当にグッドポイントでも書いたり、スタッフのやる気を引き出すためのご褒美的なグッドポイントを書いたり。もっとも指摘が無ければ無いで済ます普通の（健全な）審査員も居るようです。
.*.
バックアップメディアの管理要件
システムサイズが大きくなる一方ですからメディアにバックアップを取ることは少なくなった。それでもシステム直結のストレージでは電気的ショックで消失する懸念がゼロにならない。だからミニマムのところでメディアにもバックアップを取る。
復元できることが基本要件
復元できるには、再読み込みできること。読み込んだデータを受け止めるシステムが存在すること。
メディアの素性が明確であること。何が入っているのか。記録データが特定できること。抜け漏れが生じていないことが確認できること。
同じメディアを何度も書き換えて使用する場合は基本レベルの日常管理も重要。物理的破損も含めて。
そのメディアはいつまで利用するか、今の内容はいつ記録されたものか、今必要なバックアップメディアに合致するか（抜け漏れは無いか）、復元テストはいつ実施されたか（期日のほかにシステムバージョンも）、などキリが無い。
システムサイズが大きくなる一方ですからメディアにバックアップを取ることは少なくなった。それでもシステム直結のストレージでは電気的ショックで消失する懸念がゼロにならない。だからミニマムのところでメディアにもバックアップを取る。
復元できることが基本要件
復元できるには、再読み込みできること。読み込んだデータを受け止めるシステムが存在すること。
メディアの素性が明確であること。何が入っているのか。記録データが特定できること。抜け漏れが生じていないことが確認できること。
同じメディアを何度も書き換えて使用する場合は基本レベルの日常管理も重要。物理的破損も含めて。
そのメディアはいつまで利用するか、今の内容はいつ記録されたものか、今必要なバックアップメディアに合致するか（抜け漏れは無いか）、復元テストはいつ実施されたか（期日のほかにシステムバージョンも）、などキリが無い。
電子メールの管理策
電子メールにファイルを添付するときに、重要度に応じて保護策（暗号化？）を要求する話を聞く。愚かしい。重要度の判断くらいいい加減なものは無い。
添付文書は自動的に暗号化されるべき。そういうシステムも世間にはあるらしい。パスワードは自動的に発信者に届けられる。もっとも、費用が掛かるのが玉に瑕だろう。
電子メールにファイルを添付するときに、重要度に応じて保護策（暗号化？）を要求する話を聞く。愚かしい。重要度の判断くらいいい加減なものは無い。
添付文書は自動的に暗号化されるべき。そういうシステムも世間にはあるらしい。パスワードは自動的に発信者に届けられる。もっとも、費用が掛かるのが玉に瑕だろう。
どれくらい重要？媒体（記録メディア）の管理
媒体、最近はもっぱらＵＳＢメモリ。昔はフロッピーディスク。ＭＯ、ＣＤＲ、ＤＶＤ。最近は大容量の外付けＨＤＤあるいはＳＳＤ。主にデータの受け渡しで利用します。
通常は内容は削除して保管します。しかも、施錠管理です。中が空っぽのメディア管理ってそんなに重要ですか？
員数管理も良くやりますが、勝手に行方不明になっていたら問題でしょうか。確かに、目的外の利用の可能性があるから勝手になくなるのは拙いでしょう。
メモリー系ストレージ系のものは携帯電話、デジカメ、音楽プレイヤーにもありますし、個人のＵＳＢメモリーもあるわけで、悪意が働けば殆ど無力？
媒体、最近はもっぱらＵＳＢメモリ。昔はフロッピーディスク。ＭＯ、ＣＤＲ、ＤＶＤ。最近は大容量の外付けＨＤＤあるいはＳＳＤ。主にデータの受け渡しで利用します。
通常は内容は削除して保管します。しかも、施錠管理です。中が空っぽのメディア管理ってそんなに重要ですか？
員数管理も良くやりますが、勝手に行方不明になっていたら問題でしょうか。確かに、目的外の利用の可能性があるから勝手になくなるのは拙いでしょう。
メモリー系ストレージ系のものは携帯電話、デジカメ、音楽プレイヤーにもありますし、個人のＵＳＢメモリーもあるわけで、悪意が働けば殆ど無力？
2011年12月28日
ランサムウェア ransomware
「ransom」は身代金身、請け金、買い戻し金、賠償金のこと。 ransomwareはパソコンを感染（内容を勝手に暗号化するなど）させ、その復旧（鍵入手など）のためには費用を請求するソフトウエアまたは手口。具体的にはどのようにするのか不明。決済に絡めば身元がばれてしまうのではないか。オレオレ詐欺のように一時的な口座を持つのか？
メールであれ、WEBサイトであれ、身に覚えの無いボタンやアドレスは不用意なクリックしないこと。
日ごろのバックアップも大事。金を払っても一度の支払いで収まる保証は無い。
最近はあまり話題にならない。いたずら以上（現金をせしめること）はやはり難しいのだろう！？
.*.
「ransom」は身代金身、請け金、買い戻し金、賠償金のこと。 ransomwareはパソコンを感染（内容を勝手に暗号化するなど）させ、その復旧（鍵入手など）のためには費用を請求するソフトウエアまたは手口。具体的にはどのようにするのか不明。決済に絡めば身元がばれてしまうのではないか。オレオレ詐欺のように一時的な口座を持つのか？
メールであれ、WEBサイトであれ、身に覚えの無いボタンやアドレスは不用意なクリックしないこと。
日ごろのバックアップも大事。金を払っても一度の支払いで収まる保証は無い。
最近はあまり話題にならない。いたずら以上（現金をせしめること）はやはり難しいのだろう！？
.*.
ISO 27002 :2013関連情報
いろいろ資料が回ってきた。これからも結構大変だね。こういう大事な資料を継続的に入手できないものだろうか。定期的にサイトを閲覧するしかないかな。頑張っている人がたくさんいるんだ。感謝ですね。
さてと、
要求規格ISO27001附属書(Appendix:A)とガイド規格27002は同じものです。付属書の内容を管理策として採用したら要求規格に準じた扱いが求められますからしっかり理解しておくことが必要ですね。重要。
このISO27002も大幅に見直されているので、ISMSマニュアルを整備している団体では結構影響を受けます。管理策と社内規定を読み替え表で整合を取っているところはその表を見直すことから始めます。ダイレクトに管理策にそって規定類を整備しているところは、暫定的に読み替え表を採用することになるでしょう。
読み替え表は、適用宣言書の形態をとることが多いですが、2013版ではあ、その名前の文書は要求されないかもしれません。単に、採用管理策一覧ぐらいで落ち着くかも。
＜変化＞
6.1.1 Management commitment to information security (ドロップ）大事なことだけど管理策としては馴染まないということかな？
6.1.2 Information security co-ordination (ドロップ）6.1.1に同じく？
8.1.1 Roles and responsibilities (ドロップ）雇用前に限らないから？
11.4 Network security (ドロップ）理由は分からない。ネットワーク管理策として何処かで括るのかな。
12.2 Correct processing in application (ドロップ）理由は分かるような気がする。この要求事項をISMSレベルの管理で問題にするのは違和感があるから。せいぜいQMS領域かと。
Third Party （用語見直し）そもそも何が問題になったのだろう？
Asset （用語見直し）そもそも何が問題になったのだろう？
Supplier relationship Management （省立て追加）
Management of application services on networks （省立て追加）
5.1.1 Information security policy document→Detailed policies for information security （変更）ISMSポリシーという言葉は依然残るのだろうか。この5.1.1のポリシー（複数）は本文のポリシーの下位に来るものだということは想像できる。仮に詳細方針あるいは展開方針あるいは個別方針として、何処までカバーしていなければいけないかは今後の検討。今のISMS方針の実態が極めて固定的なこと（一度決めたら殆ど見直されないこと）を踏まえると、こちらは具体的で年度変化を反映させたもの、年度目標を反映させたものであることが求められてしかるべく。
8. employees, contractors and third party users→employees and external party users （変更）A,B,C・・とやるよりAとA以外とやった方が紛れが無いということかな。誰にとって重要な変更なんだろう？。
いろいろ資料が回ってきた。これからも結構大変だね。こういう大事な資料を継続的に入手できないものだろうか。定期的にサイトを閲覧するしかないかな。頑張っている人がたくさんいるんだ。感謝ですね。
さてと、
要求規格ISO27001附属書(Appendix:A)とガイド規格27002は同じものです。付属書の内容を管理策として採用したら要求規格に準じた扱いが求められますからしっかり理解しておくことが必要ですね。重要。
このISO27002も大幅に見直されているので、ISMSマニュアルを整備している団体では結構影響を受けます。管理策と社内規定を読み替え表で整合を取っているところはその表を見直すことから始めます。ダイレクトに管理策にそって規定類を整備しているところは、暫定的に読み替え表を採用することになるでしょう。
読み替え表は、適用宣言書の形態をとることが多いですが、2013版ではあ、その名前の文書は要求されないかもしれません。単に、採用管理策一覧ぐらいで落ち着くかも。
＜変化＞
6.1.1 Management commitment to information security (ドロップ）大事なことだけど管理策としては馴染まないということかな？
6.1.2 Information security co-ordination (ドロップ）6.1.1に同じく？
8.1.1 Roles and responsibilities (ドロップ）雇用前に限らないから？
11.4 Network security (ドロップ）理由は分からない。ネットワーク管理策として何処かで括るのかな。
12.2 Correct processing in application (ドロップ）理由は分かるような気がする。この要求事項をISMSレベルの管理で問題にするのは違和感があるから。せいぜいQMS領域かと。
Third Party （用語見直し）そもそも何が問題になったのだろう？
Asset （用語見直し）そもそも何が問題になったのだろう？
Supplier relationship Management （省立て追加）
Management of application services on networks （省立て追加）
5.1.1 Information security policy document→Detailed policies for information security （変更）ISMSポリシーという言葉は依然残るのだろうか。この5.1.1のポリシー（複数）は本文のポリシーの下位に来るものだということは想像できる。仮に詳細方針あるいは展開方針あるいは個別方針として、何処までカバーしていなければいけないかは今後の検討。今のISMS方針の実態が極めて固定的なこと（一度決めたら殆ど見直されないこと）を踏まえると、こちらは具体的で年度変化を反映させたもの、年度目標を反映させたものであることが求められてしかるべく。
8. employees, contractors and third party users→employees and external party users （変更）A,B,C・・とやるよりAとA以外とやった方が紛れが無いということかな。誰にとって重要な変更なんだろう？。
何処まで広げるの？ISO27000シリーズ
気が付いたらバラバラ中途半端な規格が列を組んでいた。ガイドラインだから実害は無いのでしょうが、参照規格の間は、ともかく、眺めるだけだが、引用規格、適用規格にしてしまうと結構大変なのでは。
ISO27000：シリーズ全体の概要と用語解説。索引＋辞書？既に発行？
ISO27001：これが要求規格。BS7799を踏まえて2005年に規格化された。JIS版は翌年2006年リリース。大幅な見直し版が2013年後半にリリースする見込み。JIS版は2014年か。
ISO27002:実践規格。規範規格。これが所謂管理策の解説書。27001同様大幅見直し中。リリースも同時期を予定。2013年後半。
ISO27003：実施規格？あまり話題にならない。
ISO27004：有効性評価に関するガイドライン。ボリュームはあるが内容はない。TQCをやってきた普通の日本企業ではこのガイドは物足りないでしょう。
ISO27005：リスク管理とあるが31000との関係は？良く分かりません。
ISO27006：これも要求規格。要求する相手は審査機関・認定機関。審査員も結局この要求を受けることになる。
ISO27007：審査のための規格。これも案外話題にならない。
ISO27008：審査員のための規格。残念。これすらも話題にならない。
ISO27010：Inter Sector Comm
ISO27011：Telecom ISMS 通信事業者向け？
ISO27013：ISO20000とISO27001との整合化ガイド？
ISO27014：セキュリティガバナンス。何のこと？
ISO27015：金融・保険業界向けガイドライン？
ISO27016：ISM Economics?さっぱり分からない。
ISO27017：クラウドコンピューティング。クラウド事業者向け？クラウド利用者向け？
.*.
世の中には規格を生業（なりわい）とする人たちが結構居るんだなと思う。
.*.
気が付いたらバラバラ中途半端な規格が列を組んでいた。ガイドラインだから実害は無いのでしょうが、参照規格の間は、ともかく、眺めるだけだが、引用規格、適用規格にしてしまうと結構大変なのでは。
ISO27000：
ISO27001：
ISO27002:
ISO27003：
ISO27004：
ISO27005：
ISO27006：
ISO27007：
ISO27008：
ISO27010：
ISO27011：
ISO27013：
ISO27014：
ISO27015：
ISO27016：
ISO27017：
.*.
世の中には規格を生業（なりわい）とする人たちが結構居るんだなと思う。
.*.
ISMS推進体制における内部監査責任者の位置付け
まあ、まあ、このタイトルを見れば誰でもははあと来るものです。分かっていてなかなかできないことの一つ。
経営者の意を受けてIS管理責任者が推進の全権を持つ。内部監査もISMS推進の一環だから内部監査責任者はIS管理責任者の下に置く。これじゃ駄目なんですね。
IS管理責任者が正しく事を運んでいるかどうかを経営者に成り代わってチェックするのが内部監査責任者の役割。レポートは直接経営者に行くのです。
IS管理責任者と内部監査責任者は同格対等なんですね。どちらもレポートを経営者に上げる。
.*.
まあ、まあ、このタイトルを見れば誰でもははあと来るものです。分かっていてなかなかできないことの一つ。
経営者の意を受けてIS管理責任者が推進の全権を持つ。内部監査もISMS推進の一環だから内部監査責任者はIS管理責任者の下に置く。これじゃ駄目なんですね。
IS管理責任者が正しく事を運んでいるかどうかを経営者に成り代わってチェックするのが内部監査責任者の役割。レポートは直接経営者に行くのです。
IS管理責任者と内部監査責任者は同格対等なんですね。どちらもレポートを経営者に上げる。
.*.
2011年12月27日
統合審査に固執したＢＳＩジャパンの失敗
統合審査とは複数の規格に対して一度の審査で済まそうというもの。審査のための負担が軽減できることがセールスポイントです。
個別に審査するとそれぞれ準備とかがあります。部門もコンサルもつど時間を作る必要があります。品質も環境も情報も、関係の無い会社はありませんから、それが一度で済むと考えたら魅力的です。
＜失敗の検証＞
管理を統合するときのベースが何か。これは品質管理しかありえないのです。第三者認証制度におけるカスタマーベースは実は圧倒的に品質が多いのです。歴史的にも品質が先行しています。付き合いも古く信頼も厚い世界ができているのです。
品質は取っていて情報がこれからの企業は、品質と同じ審査・コンサルで情報を取りに行きます。
品質も情報も取っているところが統合するときはイニシアティブは品質側が取ります。
情報は取っていて、品質を新たに取るときは、まさにこのカテゴリーがＢＳＩのねらい目で、情報をベースに品質を取り込みたいと考えても、実は無理な相談です。品質管理（＝基幹系事業の本体）と情報管理（＝支援系部門）では最初から喧嘩になりません。統合は困難ですし、統合する場合は品質側の都合に合わせるしかありません。
統合審査を戦略的に位置づけたのは企業の基幹プロセス、支援プロセスを理解していないＢＳＩジャパンの弱点を露呈したようなものです。
もう一つの失敗は何もいい結果を残さないということです。
コンサルも企業側もそれぞれ専門の担当が必要なわけですから審査員だけが一人何役をやっても意味がありません。特定の審査員のゆがみ（誰にも得意不得意はあります）が全てに反映することにもなりますから、審査の健全性がだんだん怪しくなります。審査員を分けることでカバーできていたものができなくなります。
結局、統合審査は品質に強いＪＱＡにとって魅力的な手法でしかありませんでした。多分。
.*.
誰のための統合審査か？
クライアントを抱え込む手段。審査員不足を補う手段。審査効率だけを追求する審査機関の御都合なやり方に過ぎない。クライアント側は別担当。同時にやれば待ち時間ばかり増えて内容的には非効率な審査でしかない。
出来の悪い審査員（不適合も観察で済ます審査員）がきて、ISMSだけでなく、QMSとかEMSとかでもやられたら会社のマネジメント水準は一気に下がってしまう。複数の審査員による多様な視点すら失ってしまう。ばかげた話だ。
.*.
クラウド利用時のISMS問題？
初期の頃は日本の法律で裁けないのが問題でした。クラウドは海外ばかりでしたから。今は国内にクラウドセンターが出来て解消しました。
次はサーバーが特定できないことを問題にしていました。共同利用であることも問題とされています。
クラウドセンター施設の維持も問題にされています。移設、建て替え。同じベンダーでも心配ですが、違うベンダーへ移る場合に何が課題になるのか。
何がベンダーの資産で何が自分たちの資産か、切り分けは上手くできるのか。なかなか現実にならないと課題が見えてこないものです。
.*.
ベンダーにISMSの取得を条件付けるのは当然でしょうね。自分たちが中に入れない分、第三者に中に入ってもらってチェックして欲しい。それも出来れば3年ごとに審査機関を変えてもらう。迎合的審査・癒着型審査の懸念を払拭させたい。
.*.
初期の頃は日本の法律で裁けないのが問題でした。クラウドは海外ばかりでしたから。今は国内にクラウドセンターが出来て解消しました。
次はサーバーが特定できないことを問題にしていました。共同利用であることも問題とされています。
クラウドセンター施設の維持も問題にされています。移設、建て替え。同じベンダーでも心配ですが、違うベンダーへ移る場合に何が課題になるのか。
何がベンダーの資産で何が自分たちの資産か、切り分けは上手くできるのか。なかなか現実にならないと課題が見えてこないものです。
.*.
ベンダーにISMSの取得を条件付けるのは当然でしょうね。自分たちが中に入れない分、第三者に中に入ってもらってチェックして欲しい。それも出来れば3年ごとに審査機関を変えてもらう。迎合的審査・癒着型審査の懸念を払拭させたい。
.*.
ISMSの有効性
こんな簡単なテーマはありませんね。
リスク値の総和の最小化。うん？これは失敗。
無理でも金額ベースにすることです。年間期待損失。
経営・事業への貢献度で見る発想もありますが、これは駄目。続かない。一貫性が維持できない。方向まで変わる。
.*.
でもまあ実際にやっている話は聞いたことがありません。
ISMS認証取得でなんとなく営業がやりやすくなった。ぐらいでお茶を濁すのが大半。分かりやすい発想ですが、本末転倒というか問題が摩り替わっていますよ。
.*.
あっと、結果指標は駄目ですよ。事件とか事故の件数。その被害額。このデータは期待損失の検証に使うものでしょうか。そのことを発展させることも出来そうです。予測と実測の乖離の原因を探ることも大事なことです。
（A)実際の投資額、（B)実際の被害額、（C)期待損失（保有リスク・保有潜在損失）。
問い：この３項目の関係を述べよ。好ましい関係と好ましくない関係について論ぜよ！
.*.
こんな簡単なテーマはありませんね。
リスク値の総和の最小化。うん？これは失敗。
無理でも金額ベースにすることです。年間期待損失。
経営・事業への貢献度で見る発想もありますが、これは駄目。続かない。一貫性が維持できない。方向まで変わる。
.*.
でもまあ実際にやっている話は聞いたことがありません。
ISMS認証取得でなんとなく営業がやりやすくなった。ぐらいでお茶を濁すのが大半。分かりやすい発想ですが、本末転倒というか問題が摩り替わっていますよ。
.*.
あっと、結果指標は駄目ですよ。事件とか事故の件数。その被害額。このデータは期待損失の検証に使うものでしょうか。そのことを発展させることも出来そうです。予測と実測の乖離の原因を探ることも大事なことです。
（A)実際の投資額、（B)実際の被害額、（C)期待損失（保有リスク・保有潜在損失）。
問い：この３項目の関係を述べよ。好ましい関係と好ましくない関係について論ぜよ！
.*.
KPIの要件
計測可能ということとKPIとして適切かどうかは別問題。管理策の有効性評価はまあどうってこと無いのですが、本気でやるとなると一つも答えが見つからない。体系的方法論が何処にも提示されていないからでしょうか。
シンプルで客観的で長期的に継続できること。それって何ですか？
いつもやっていること、これまでもやってきたこと、これからもやっていくこと。出来る限りそういうものの中から選択することですね。
もちろん、生産的指標です。結果指標を選択してはいけない。また言えばポジティブ指標はOK、ネガティブ指標はNG、足し算はOK,、引き算はNG。そんな感じ。
教育･周知は必須必達だけど、管理の主役には向かない？ だからKPIには向かない。
全ての管理策（最大133項目）に対して有効性評価は要求されていないと主張する輩がいます。その主張が誰の何の役に立つんでしょうか？ かたや地道に133項目のKPIを作った裏方が居ます。賞賛を贈ります。自分で全対応を放棄するのは勝手ですが正当化まで意図するのは邪悪な発想で軽蔑の対象です。出来ないこととやらないでいいんだと主張するのは全く別です。
取り敢えずは管理目的毎にKPIを作ることでもいいでしょう。
.*.
計測可能ということとKPIとして適切かどうかは別問題。管理策の有効性評価はまあどうってこと無いのですが、本気でやるとなると一つも答えが見つからない。体系的方法論が何処にも提示されていないからでしょうか。
シンプルで客観的で長期的に継続できること。それって何ですか？
いつもやっていること、これまでもやってきたこと、これからもやっていくこと。出来る限りそういうものの中から選択することですね。
もちろん、生産的指標です。結果指標を選択してはいけない。また言えばポジティブ指標はOK、ネガティブ指標はNG、足し算はOK,、引き算はNG。そんな感じ。
教育･周知は必須必達だけど、管理の主役には向かない？ だからKPIには向かない。
全ての管理策（最大133項目）に対して有効性評価は要求されていないと主張する輩がいます。その主張が誰の何の役に立つんでしょうか？ かたや地道に133項目のKPIを作った裏方が居ます。賞賛を贈ります。自分で全対応を放棄するのは勝手ですが正当化まで意図するのは邪悪な発想で軽蔑の対象です。出来ないこととやらないでいいんだと主張するのは全く別です。
取り敢えずは管理目的毎にKPIを作ることでもいいでしょう。
.*.
何の手順ですか？リスクアセスメントのヒント
検討対象の洗い出し。何の検討かというとリスク管理の検討。と言うことは管理対象の洗い出しになるかな。どういう粒の大きさで捉えるか。これも難しい。普通は管理台帳になっているのでわざわざ洗い出す必要はない。問題はこれまで台帳管理してこなかったもの。これまで台帳管理されてきたものも十分かどうか再検討したい。まあ、何が正解か分からないからやり直す覚悟で簡単に済ましてみよう。
管理対象の管理基準と基準がずれた時のインパクト。どうなると困るのか。ISMSならセキュリティ障害。普通で言えばリスク事象でしょうか。脅威と脆弱性との合算（足し算じゃないよ！）で発生する困った状況。ここも行ったり来たりの前提で軽く。
困らないようにする方法の検討。１つ１つのリスク事象について検討を加える。例えば落下事故を想定する場合、物が落ちないようにする。落ちても困らないように下を柔らかくする。ものを丈夫に作って置く。物を使わないで済ます。置き場所を変える。
「管理対象」（普通は資産・資源）→「リスク事象」（複数あります）→「対策案」（1つのリスク事象に対して複数あります）。これを網羅的にリストしておきます。
実施済みの対策案、未実施で実施可能な対策案、実施不可能な対策案に仕分けします。対策案の有効性評価も行います。例えばトータルの有効性が95%に達したら十分とします。しかし何を持って95%なんて判断が出来るでしょう？ここは「筈｣「看做し」の出番。システム化された、機械仕掛けの施策は有効性（50〜90%）、人による対策は有効性（30〜70%）と置き、独立した複数の管理策の効果はその積とする。などでしょうか。
検討対象の洗い出し。何の検討かというとリスク管理の検討。と言うことは管理対象の洗い出しになるかな。どういう粒の大きさで捉えるか。これも難しい。普通は管理台帳になっているのでわざわざ洗い出す必要はない。問題はこれまで台帳管理してこなかったもの。これまで台帳管理されてきたものも十分かどうか再検討したい。まあ、何が正解か分からないからやり直す覚悟で簡単に済ましてみよう。
管理対象の管理基準と基準がずれた時のインパクト。どうなると困るのか。ISMSならセキュリティ障害。普通で言えばリスク事象でしょうか。脅威と脆弱性との合算（足し算じゃないよ！）で発生する困った状況。ここも行ったり来たりの前提で軽く。
困らないようにする方法の検討。１つ１つのリスク事象について検討を加える。例えば落下事故を想定する場合、物が落ちないようにする。落ちても困らないように下を柔らかくする。ものを丈夫に作って置く。物を使わないで済ます。置き場所を変える。
「管理対象」（普通は資産・資源）→「リスク事象」（複数あります）→「対策案」（1つのリスク事象に対して複数あります）。これを網羅的にリストしておきます。
実施済みの対策案、未実施で実施可能な対策案、実施不可能な対策案に仕分けします。対策案の有効性評価も行います。例えばトータルの有効性が95%に達したら十分とします。しかし何を持って95%なんて判断が出来るでしょう？ここは「筈｣「看做し」の出番。システム化された、機械仕掛けの施策は有効性（50〜90%）、人による対策は有効性（30〜70%）と置き、独立した複数の管理策の効果はその積とする。などでしょうか。
2011年12月26日
クライアントがクレームする本当の理由？
期待値とずれたら相手が誰であれクレームするのがクライアント。費用負担者。お金を出す人は強い？
相手が分かっていても説明するのがコンサル、自分が分かっていても質問するのが審査員。どちらも分かっていない前提で隙間を埋めようとする基本的な行為。
クライアントは分かっていることを説明されて不満を持ち、分かっている筈のことを質問されて不満を持つ。
どうしてこんな些細なことがクレームの理由になるんでしょう？
本当の理由は別にあると考えるべきですね。クライアントはクレームする時に本当の理由はなかなか言わない。理由を知られることで自分の人間性の嫌な部分が顔を出すのを避けたい？
大人の言い方もあります。今度は相手を傷つけることを心配して別の理由を言うケースです。ですが、それすら背後に何があるのか？
直接何らかの被害が出た訳でもないのに、そもそもISMSで無理難題をぶつけられない限り被害はでないものですが、クレームになるのは何故でしょう？
面子ですか？自分の思惑を外す展開になった時？
疑心暗鬼！
自分がベストエフォートサービスを受けていないと感じた時、そのことに疑いを持った時、心の中の鬼は目覚めるのです。
コンサル同士のやり取り（パワーゲーム）、審査員同士のやりとり（パワーゲーム）、はたまたコンサルと審査員とのやり取り（パワーゲーム）を見て聞いてクライアントは疑いの気持ちを目覚めさせる。当人たちはパワーゲームのつもりは無くてもクライアントにはその部分だけが理解できるのでパワーゲームとして理解するのです。
コンサルも審査員も謂わば業界人です。業界人がクライアントの前でいきなりお互いを否定する行為は墓穴を掘るのと同じこと。勝ち負けはありません。負け負けです。訂正が必要な場合は自己否定で入らなければいけません。
どこそこのコンサルや審査のやり方を否定したり、無責任に批評するのは、何れ話は伝わりますから極めて非生産的・非建設的な行為です。もちろん、最悪はクライアントの目の前で他者否定を始めることです。
目の前で始まったパワーゲームを見てクライアントの集中力は一気に切れます。疑心暗鬼をはじめます。最後は自己嫌悪に陥る。
背景にはクライアントの不慣れがあります。初回審査の時、クライアントのISMSの担当が替わった時。担当するコンサルや審査員が替わった時は、特に業界人は意識して発現する必要があります。
既に信頼関係が築かれている場合はこの手のクレームは発生しません。不明なところは適切に質疑応答されて問題が先送りされたり蓄積されたりしないからですね。
.*.
パワーゲーム以外ではまさに基本事項の基本、コミュニケーション問題があります。クライアントにもあり得る問題です。窓口を通して話を進めているつもりで居たのに、相手組織に十分伝わっていなかったケース。問い合わせても無視されたような状況になるケース。
自分が軽く見られたということで、パワーゲームの場合よりも深刻な相手不信に陥ります。ビジネスマンの基本部分ですから、当然です。
.*.
ミスが多いのも行けません。上記の2点ほど深刻ではありませんが、基本能力に対する疑いを招きますから、何かと合わさった時にはマイナスのお手伝いをすることになります。
.*.
期待値とずれたら相手が誰であれクレームするのがクライアント。費用負担者。お金を出す人は強い？
相手が分かっていても説明するのがコンサル、自分が分かっていても質問するのが審査員。どちらも分かっていない前提で隙間を埋めようとする基本的な行為。
クライアントは分かっていることを説明されて不満を持ち、分かっている筈のことを質問されて不満を持つ。
どうしてこんな些細なことがクレームの理由になるんでしょう？
本当の理由は別にあると考えるべきですね。クライアントはクレームする時に本当の理由はなかなか言わない。理由を知られることで自分の人間性の嫌な部分が顔を出すのを避けたい？
大人の言い方もあります。今度は相手を傷つけることを心配して別の理由を言うケースです。ですが、それすら背後に何があるのか？
直接何らかの被害が出た訳でもないのに、そもそもISMSで無理難題をぶつけられない限り被害はでないものですが、クレームになるのは何故でしょう？
面子ですか？自分の思惑を外す展開になった時？
疑心暗鬼！
自分がベストエフォートサービスを受けていないと感じた時、そのことに疑いを持った時、心の中の鬼は目覚めるのです。
コンサル同士のやり取り（パワーゲーム）、審査員同士のやりとり（パワーゲーム）、はたまたコンサルと審査員とのやり取り（パワーゲーム）を見て聞いてクライアントは疑いの気持ちを目覚めさせる。当人たちはパワーゲームのつもりは無くてもクライアントにはその部分だけが理解できるのでパワーゲームとして理解するのです。
コンサルも審査員も謂わば業界人です。業界人がクライアントの前でいきなりお互いを否定する行為は墓穴を掘るのと同じこと。勝ち負けはありません。負け負けです。訂正が必要な場合は自己否定で入らなければいけません。
どこそこのコンサルや審査のやり方を否定したり、無責任に批評するのは、何れ話は伝わりますから極めて非生産的・非建設的な行為です。もちろん、最悪はクライアントの目の前で他者否定を始めることです。
目の前で始まったパワーゲームを見てクライアントの集中力は一気に切れます。疑心暗鬼をはじめます。最後は自己嫌悪に陥る。
背景にはクライアントの不慣れがあります。初回審査の時、クライアントのISMSの担当が替わった時。担当するコンサルや審査員が替わった時は、特に業界人は意識して発現する必要があります。
既に信頼関係が築かれている場合はこの手のクレームは発生しません。不明なところは適切に質疑応答されて問題が先送りされたり蓄積されたりしないからですね。
.*.
パワーゲーム以外ではまさに基本事項の基本、コミュニケーション問題があります。クライアントにもあり得る問題です。窓口を通して話を進めているつもりで居たのに、相手組織に十分伝わっていなかったケース。問い合わせても無視されたような状況になるケース。
自分が軽く見られたということで、パワーゲームの場合よりも深刻な相手不信に陥ります。ビジネスマンの基本部分ですから、当然です。
.*.
ミスが多いのも行けません。上記の2点ほど深刻ではありませんが、基本能力に対する疑いを招きますから、何かと合わさった時にはマイナスのお手伝いをすることになります。
.*.
情報資産の定義も難しいものですね
情報コンテンツ、意味、メッセージ。これが所謂、情報の本旨に相当する。これらを容易に導くことが出来る整理されたデータ類も情報に準じたものになるであろうと。
情報を保管する道具類も情報資産に含める。
情報利用のために、人間の五感に訴える道具立ても情報資産。ディスプレィ。スピーカー。最も単独では意味が無くてシステムとしての存在だろうが。システムが複合的、広域的であればそのためのネットワークや施設インフラも情報資産。そうなるとCVCFとか自家発まで入る。
インフラがサービスとして外部から提供される場合はそのサービスも情報資産。それにも適切な維持活動が求められる筈だ。
オフィス環境、サイト環境まで、外部との境界に対する手当てを想定すれば情報資産に入る？
そこに超機密情報があるなら、情報の存在や所在（サイト）すら情報資産に入る？
実際、データセンターの中にはテロのターゲットになるのを恐れて、存在すら隠そうとしているものがあるようだ。
.*.
整理すると、
先ず、本質的な情報（メッセージ、意味、情報の本旨）。仮にコンテンツとする。
コンテンツの存在を成立させる入れ物。情報コンテンツを記録したメディア。記憶媒体・記録媒体。紙とか、光学ドライブディスク、外付けHDD。USBメモリーなど。しかし、殆どはパソコンやサーバー上にあるでしょう。可搬メディア、固定メディアに分類できるが、クラウド上に据えたものは別の分類がいいだろう。
次は処理系。一時的に情報を扱う道具立て。コンピュータシステム、ネットワークシステム。
最後は施設系。処理系、メディアの保護あるいは利用に供する施設。適用範囲にある施設すべてが納まることになるでしょう。
上記の分類が成立すると、概ね、管理策も整理される。
.*.
大笑いのケース（笑うのは誰？）は、分類表と資産台帳の混同です。分類表があれば、脅威･脆弱性・管理策は類似性を持つのは間違いないが、資産台帳は一つ一つそれを確認するものだということ。個別の状況を踏まえて適切な管理策が当たるようにしなければいけない。
.*.
情報コンテンツ、意味、メッセージ。これが所謂、情報の本旨に相当する。これらを容易に導くことが出来る整理されたデータ類も情報に準じたものになるであろうと。
情報を保管する道具類も情報資産に含める。
情報利用のために、人間の五感に訴える道具立ても情報資産。ディスプレィ。スピーカー。最も単独では意味が無くてシステムとしての存在だろうが。システムが複合的、広域的であればそのためのネットワークや施設インフラも情報資産。そうなるとCVCFとか自家発まで入る。
インフラがサービスとして外部から提供される場合はそのサービスも情報資産。それにも適切な維持活動が求められる筈だ。
オフィス環境、サイト環境まで、外部との境界に対する手当てを想定すれば情報資産に入る？
そこに超機密情報があるなら、情報の存在や所在（サイト）すら情報資産に入る？
実際、データセンターの中にはテロのターゲットになるのを恐れて、存在すら隠そうとしているものがあるようだ。
.*.
整理すると、
先ず、本質的な情報（メッセージ、意味、情報の本旨）。仮にコンテンツとする。
コンテンツの存在を成立させる入れ物。情報コンテンツを記録したメディア。記憶媒体・記録媒体。紙とか、光学ドライブディスク、外付けHDD。USBメモリーなど。しかし、殆どはパソコンやサーバー上にあるでしょう。可搬メディア、固定メディアに分類できるが、クラウド上に据えたものは別の分類がいいだろう。
次は処理系。一時的に情報を扱う道具立て。コンピュータシステム、ネットワークシステム。
最後は施設系。処理系、メディアの保護あるいは利用に供する施設。適用範囲にある施設すべてが納まることになるでしょう。
上記の分類が成立すると、概ね、管理策も整理される。
.*.
大笑いのケース（笑うのは誰？）は、分類表と資産台帳の混同です。分類表があれば、脅威･脆弱性・管理策は類似性を持つのは間違いないが、資産台帳は一つ一つそれを確認するものだということ。個別の状況を踏まえて適切な管理策が当たるようにしなければいけない。
.*.
脅威は何に取り付くのか？
脅威とは何であるかを考えると、これはなかなか難しい議論であることに気がつく。変化することも変化しないことも脅威になりうる。人（組織）にとって都合が悪いことは全部脅威だから、しかも結果論で以って過ぎてしまった事象をあれは脅威だったとやるので始末が悪い。また時間的スパンを変えると脅威であったり無かったりするとますます始末が悪い。人（組織）が変われば脅威も変わる。絶対的脅威なんて存在できるのかどうか怪しい。他人の不幸は自分の幸福？でも無いでしょうが、誰かが困っていればそこにはビジネスチャンスがある訳で脅威はチャンスにも成り得るかもしれない。
どうやら脅威は「人」に取り付くようです。「人」の都合に悪いこと、あるいは「人」の目的に取り付く不都合なことが脅威。
ところで、ISMSでは情報資産に対する脅威を洗い出すことになっています。が、資産を見ていきなり脅威を洗うことは出来ないのはこういった事情なんでしょう。
資産もまた人のご都合を達成するために存在するので、人の都合が資産のあるべき状態を決定することになっている筈です。
なんと言うことはないですね。人の都合や目的がプロセスを作り資源を配置し仕事をすることに繋がるのは只の常識？。
目的達成のための業務プロセスが前提とする情報資産の状態を脅かすものが脅威。当該業務プロセスで、情報資産のCIAの側面でどのようでなければいけないかを知ることが先決です。でもこれって情報資産の価値を調べる作業の中に含まれているはずですね。
手順で考えると、
組織は組織目標達成のためにプロセス（ビジネスモデル）を決定し資源を配置する。資源の一部である情報資産もプロセス遂行要件を達成できるレベルで維持される。遂行要件を達成できないときのプロセスインパクト（ビジネスインパクト）が資産価値であり、遂行要件達成を脅かすものが脅威である。
目的を書いて、次にプロセスを書いて、次に資源を書いて、資源のあるべき状態を書く。次に、資源のあるべき状態に対する問題事象（広義の脅威）を書く。
.*.
ここで、脅威は脆弱性の側面を併せ持つことにも留意することが必要です。脅威と脆弱性も相対的な関係があって明確な線引きは容易でありません。ですから上の説明の脅威は広義の脅威（脅威＋脆弱性）と考えておいた方が収まりは良さそうです。規格はセキュリティ障害として括っている。（4.2.1e)2)）
脅威と脆弱性の引き離しは、よく言われる「脅威はコントロールできないが脆弱性はコントロールできる」という言葉に象徴されることが一つの発想になります。盗難というセキュリティ障害（情報の紛失あるいは漏洩）において、泥棒の存在には手を打てないが鍵の掛け忘れには手を打てるとやるわけです。
ところがメールの誤送信（情報漏えいリスク）はどうでしょう。確認洩れ、勘違い、うっかりクリックなど。脅威が人の内面に潜むケース。ヒューマンエラーとする部分。どれだけ教育・周知を繰り返して一定の比率以下には下がりません。コントロール不可？
ヒューマンエラーも脅威として認識し、対策は教育周知ですますのは、50点です。教育周知では収まらないからわざわざヒューマンエラーを脅威としているのですから、例えばプロセスの欠陥と捉えて脆弱性として理解しなければいけません。
.*.
脅威とは何であるかを考えると、これはなかなか難しい議論であることに気がつく。変化することも変化しないことも脅威になりうる。人（組織）にとって都合が悪いことは全部脅威だから、しかも結果論で以って過ぎてしまった事象をあれは脅威だったとやるので始末が悪い。また時間的スパンを変えると脅威であったり無かったりするとますます始末が悪い。人（組織）が変われば脅威も変わる。絶対的脅威なんて存在できるのかどうか怪しい。他人の不幸は自分の幸福？でも無いでしょうが、誰かが困っていればそこにはビジネスチャンスがある訳で脅威はチャンスにも成り得るかもしれない。
どうやら脅威は「人」に取り付くようです。「人」の都合に悪いこと、あるいは「人」の目的に取り付く不都合なことが脅威。
ところで、ISMSでは情報資産に対する脅威を洗い出すことになっています。が、資産を見ていきなり脅威を洗うことは出来ないのはこういった事情なんでしょう。
資産もまた人のご都合を達成するために存在するので、人の都合が資産のあるべき状態を決定することになっている筈です。
なんと言うことはないですね。人の都合や目的がプロセスを作り資源を配置し仕事をすることに繋がるのは只の常識？。
目的達成のための業務プロセスが前提とする情報資産の状態を脅かすものが脅威。当該業務プロセスで、情報資産のCIAの側面でどのようでなければいけないかを知ることが先決です。でもこれって情報資産の価値を調べる作業の中に含まれているはずですね。
手順で考えると、
組織は組織目標達成のためにプロセス（ビジネスモデル）を決定し資源を配置する。資源の一部である情報資産もプロセス遂行要件を達成できるレベルで維持される。遂行要件を達成できないときのプロセスインパクト（ビジネスインパクト）が資産価値であり、遂行要件達成を脅かすものが脅威である。
目的を書いて、次にプロセスを書いて、次に資源を書いて、資源のあるべき状態を書く。次に、資源のあるべき状態に対する問題事象（広義の脅威）を書く。
.*.
ここで、脅威は脆弱性の側面を併せ持つことにも留意することが必要です。脅威と脆弱性も相対的な関係があって明確な線引きは容易でありません。ですから上の説明の脅威は広義の脅威（脅威＋脆弱性）と考えておいた方が収まりは良さそうです。規格はセキュリティ障害として括っている。（4.2.1e)2)）
脅威と脆弱性の引き離しは、よく言われる「脅威はコントロールできないが脆弱性はコントロールできる」という言葉に象徴されることが一つの発想になります。盗難というセキュリティ障害（情報の紛失あるいは漏洩）において、泥棒の存在には手を打てないが鍵の掛け忘れには手を打てるとやるわけです。
ところがメールの誤送信（情報漏えいリスク）はどうでしょう。確認洩れ、勘違い、うっかりクリックなど。脅威が人の内面に潜むケース。ヒューマンエラーとする部分。どれだけ教育・周知を繰り返して一定の比率以下には下がりません。コントロール不可？
ヒューマンエラーも脅威として認識し、対策は教育周知ですますのは、50点です。教育周知では収まらないからわざわざヒューマンエラーを脅威としているのですから、例えばプロセスの欠陥と捉えて脆弱性として理解しなければいけません。
.*.
2011年12月25日
ISMSでマインドマップ(Mind Map)を使うなんて変な気がするが？
一方ではISMSが教育システムであることを証明しているような気もする。最もマインドマップのことも理解できているわけではないので、あまり意味のあるコメントではない。
マインドマップは学生の間で流行っていた問題整理術。何処かの番組で紹介されていたように思う。昔の「KJ法」ブレーンストーミングと「魚の骨」分析手法を組み合わせたような方法論。欠点は両手法と同様に、-答えはいくつもあって正解は分からない-と言うことかな。同じメンバー同じテーマでやっても違ったものが出てくる。
「何が情報資産か？」「情報資産とは何か？」
確かにこの問いに答えるのは難しそうだ。「情報とは何か？」と今さら真顔で質問されるとうっかり答えることも出来ない。
.*.
マインドマップは方法論が確立する前の業務領域での最後の駆け込み寺。大事なことは見える化による合議制ということ。そこに表現されるもの合理性のレベルは実はどうでもいいこと。そのメンバーの質で決まるので誰も文句は言えない。
良く見えないもの、概念的なもの、抽象的なものを議論する時、分析する時、あるいは洗い出す時に有効な方法論として捉えておく。前例、経験がない時にも、利用できる。勿論、前例、経験があっても整理・分析するとなると難しいので有効な方法論として利用できそうだ。
マインドマップによる見える化は複数の人の間の理解を助けるし、自分一人でも時間差を置いて眺めることで理解を深めることが出来る利点を持つ。
.*.
方法論が確立したらそれに従うことも大事。
変革を意図したらマインドマップ利用も考慮する。
そういうスタンスでしょうか？
.*.
一方ではISMSが教育システムであることを証明しているような気もする。最もマインドマップのことも理解できているわけではないので、あまり意味のあるコメントではない。
マインドマップは学生の間で流行っていた問題整理術。何処かの番組で紹介されていたように思う。昔の「KJ法」ブレーンストーミングと「魚の骨」分析手法を組み合わせたような方法論。欠点は両手法と同様に、-答えはいくつもあって正解は分からない-と言うことかな。同じメンバー同じテーマでやっても違ったものが出てくる。
「何が情報資産か？」「情報資産とは何か？」
確かにこの問いに答えるのは難しそうだ。「情報とは何か？」と今さら真顔で質問されるとうっかり答えることも出来ない。
.*.
マインドマップは方法論が確立する前の業務領域での最後の駆け込み寺。大事なことは見える化による合議制ということ。そこに表現されるもの合理性のレベルは実はどうでもいいこと。そのメンバーの質で決まるので誰も文句は言えない。
良く見えないもの、概念的なもの、抽象的なものを議論する時、分析する時、あるいは洗い出す時に有効な方法論として捉えておく。前例、経験がない時にも、利用できる。勿論、前例、経験があっても整理・分析するとなると難しいので有効な方法論として利用できそうだ。
マインドマップによる見える化は複数の人の間の理解を助けるし、自分一人でも時間差を置いて眺めることで理解を深めることが出来る利点を持つ。
.*.
方法論が確立したらそれに従うことも大事。
変革を意図したらマインドマップ利用も考慮する。
そういうスタンスでしょうか？
.*.
