2011年11月19日
主任審査員が審査チーム全体の最終判断を下す
主任所見あるいはリーダー所見とは審査チーム全体としての総合所見であり、最終判定所見である。結論を含む。
個別所見は、各審査員・各審査チーム個々の部署・現場での審査で出される。不適合も含まれる。中には重大な不適合の指摘も出されるが、最終的にどのように取り扱うかは主任審査員に委ねられる。主任審査員を審査チームリーダーあるいは単にリーダーとしているところもある。審査機関ごとに若干言い方は異なるようだ。
.*.
主任が常にベストな判断できるベストの力量を持っている訳ではない。主任あるいはリーダーの負担はそれなりに多いため、持ち回りにしているところもある。経験も力量も大したことのない輩が主任あるいはリーダーになるケースは決して珍しくない。
平穏無事の審査なら問題ないが、中には判断の難しいケースもある。不幸はそのような時に起きる。と書いてみたものの、ベテランが主任の時でも、馬鹿な判断が無いわけではないから、不幸が起きる問題の本質は別のところにあるのだろう。
.*.
主任所見あるいはリーダー所見とは審査チーム全体としての総合所見であり、最終判定所見である。結論を含む。
個別所見は、各審査員・各審査チーム個々の部署・現場での審査で出される。不適合も含まれる。中には重大な不適合の指摘も出されるが、最終的にどのように取り扱うかは主任審査員に委ねられる。主任審査員を審査チームリーダーあるいは単にリーダーとしているところもある。審査機関ごとに若干言い方は異なるようだ。
.*.
主任が常にベストな判断できるベストの力量を持っている訳ではない。主任あるいはリーダーの負担はそれなりに多いため、持ち回りにしているところもある。経験も力量も大したことのない輩が主任あるいはリーダーになるケースは決して珍しくない。
平穏無事の審査なら問題ないが、中には判断の難しいケースもある。不幸はそのような時に起きる。と書いてみたものの、ベテランが主任の時でも、馬鹿な判断が無いわけではないから、不幸が起きる問題の本質は別のところにあるのだろう。
.*.
2011年11月18日
マネジメントレビューって誰がやるんでしょうか？
分かり切ったことを聞かれると戸惑うかと思えば、案外グッドクエスチョンかも。マネジメントをどのように訳すかで確かにニュアンスは違ってくる。経営者レビューと訳しておけば簡単だった。というより経営者の本気も見えてきただろうに。マネジメントレビューなどとしてしまったから、当事者責任の曖昧なセレモニーになってしまっている。らしいです。
マネジメントレビュー＝経営者レビューの本質は？それほど大袈裟に構えるものでもないでしょうが、経営者の意図が達成できたかを経営者自らがレビューすることぐらいに考えておきましょうか。
.*.
では、経営者は自らの意図を明確にしているか？
大事なことですが、目的と目標と、共になかなか明確でない。基本方針を作ってみたものの、一般的で当たり前すぎて、世間面ばかり気にしていて、レビューの下敷きにできる代物でない。自分でレビューすれば良くわかる。誰が書いても一般論ならこうなるだろうぐらいのぬるい表現の方針で済ましている。自分の必至の思いが見当たらない。
それに気づいた経営者が取るのは、毎年の見直しは放棄して、ビジョンみたいなものだから毎年見直しと行かないから、別に年度方針と年度目標を作る。これは立派な気付きです。「実際はこれこそがISMS基本方針。年度年度の環境変化（社内も社外も）を踏まえて、見直しを行うものなんです。」と言っていたベテランに脱帽。
.*.
経営者はどのようにレビューするのか。目標さえ明確にしていれば簡単。目標と実績。ギャップと対策。それぞれに分析が必要だが、作業の手順自体は単純だね。
規格の第7章マネジメントレビューには懇切丁寧にレビューのインプットとアウトプットの項目が記載されているが、この各項目の消化がレビューの主眼になると全体像が掴みにくくなる。改革マネジメントのフレームワークを利用することで解消できると思われる。エー・デルタ・ティー（AΔT）の活用。
「ヨキニハカラエ」で済ませたい経営者レビューでも一通りのことは出来るが、深みが無いので形式的なレビューに終始するのは止むを得ない。上司を選べない身を恨むべし。
.*.
分かり切ったことを聞かれると戸惑うかと思えば、案外グッドクエスチョンかも。マネジメントをどのように訳すかで確かにニュアンスは違ってくる。経営者レビューと訳しておけば簡単だった。というより経営者の本気も見えてきただろうに。マネジメントレビューなどとしてしまったから、当事者責任の曖昧なセレモニーになってしまっている。らしいです。
マネジメントレビュー＝経営者レビューの本質は？それほど大袈裟に構えるものでもないでしょうが、経営者の意図が達成できたかを経営者自らがレビューすることぐらいに考えておきましょうか。
.*.
では、経営者は自らの意図を明確にしているか？
大事なことですが、目的と目標と、共になかなか明確でない。基本方針を作ってみたものの、一般的で当たり前すぎて、世間面ばかり気にしていて、レビューの下敷きにできる代物でない。自分でレビューすれば良くわかる。誰が書いても一般論ならこうなるだろうぐらいのぬるい表現の方針で済ましている。自分の必至の思いが見当たらない。
それに気づいた経営者が取るのは、毎年の見直しは放棄して、ビジョンみたいなものだから毎年見直しと行かないから、別に年度方針と年度目標を作る。これは立派な気付きです。「実際はこれこそがISMS基本方針。年度年度の環境変化（社内も社外も）を踏まえて、見直しを行うものなんです。」と言っていたベテランに脱帽。
.*.
経営者はどのようにレビューするのか。目標さえ明確にしていれば簡単。目標と実績。ギャップと対策。それぞれに分析が必要だが、作業の手順自体は単純だね。
規格の第7章マネジメントレビューには懇切丁寧にレビューのインプットとアウトプットの項目が記載されているが、この各項目の消化がレビューの主眼になると全体像が掴みにくくなる。改革マネジメントのフレームワークを利用することで解消できると思われる。エー・デルタ・ティー（AΔT）の活用。
「ヨキニハカラエ」で済ませたい経営者レビューでも一通りのことは出来るが、深みが無いので形式的なレビューに終始するのは止むを得ない。上司を選べない身を恨むべし。
.*.
スマホ時代のIT資源管理〜IT資産管理に関する考察
単に管理対象が増えるだけかな。スマホの場合、特に何に留意すべきだろうか。
.*.
私物の携帯電話が会社の中に入ってくるようになると、会社は、携帯電話の使用を禁止するか、そしてまたは、携帯電話を貸与するかの判断を迫られるようになった。携帯は普遍的な連絡手段であり、既に、外出時等の業務の一部は携帯の上に載っていたから、使用禁止は現実的な選択ではなくなっていた。使用禁止は出来ない。貸与するか。私物利用を認めるかしかない。金持ちは貸与し、貧乏は私物利用を認める。私物利用でも会社関係先への通話は会社が補填する制度を持つところもある。
.*.
スマホも携帯の延長上にある。会社が携帯を貸与していても個人のスマホが入りだす。会社が貸与する携帯がビジネスツール化の一環でスマホになる。携帯自身がスマホ化する。小型PCがポケットに収まるのは時間の問題。そういう前提で、これからの資源管理は検討されなければいけない。
.*.
スマホ(iPhone)の歴史を考えると、タブレット端末(iPad)やハイレベルの携帯音楽プレイヤー(iPod)を考慮するのは当然だし、ストレージの強化とWiFi機能まで持ち始めたやデジカメも無視することは出来ない。USBインタフェース、WiFiインタフェース、大容量メモリ（フラッシュメモリなど）を有する小型機器の類もIT資産の洗い出しの対象に入れるべきでしょう。
.*.
プログラムを実行できる機器類
内容を変更可能なストレージを有する機器類
取り出し可能メディアを装填可能な機器類
外部通信可能な機器類（有線・無線）
メディア（FD,CD/DVD等光学ディスク,USBメモリ、外付けディスク（上記に重複）、フラッシュメモリ、など）
プログラム類（OS、アプリ類）
情報コンテンツ
利用サービス
ライセンス（機器類、プログラム類、コンテンツ類、サービス類）
.*.
資源管理ツールの多くはクライアントソフトを機器類にインストールして、接続されているハードウエア、ソフトウエアの情報を収集する。
基本は「ものの存在」の管理。あるべきものがあるべき状態で存在するか。余計なものが存在しないか。
次には「ものの動作」の管理。許可された動作か。適切な頻度か。
.*.
今一番の問題は、スマホに対するスタンスを決めかねていること。さっさと管理対象資産として位置づけること。業務に必要なら貸与が基本。どうしても、私物のスマホについては許可する場合は資産台帳に反映させ、管理ツールを受け入れることが条件になる。嫌なら私物持込は禁止。（これは携帯でも同様のスタンスが必要）
次に、スマホまで含めた資源管理ツールの導入。PCと別立てでも構わない。適切なものが無ければ自己申告からでも始めることになる。
.*.
単に管理対象が増えるだけかな。スマホの場合、特に何に留意すべきだろうか。
.*.
私物の携帯電話が会社の中に入ってくるようになると、会社は、携帯電話の使用を禁止するか、そしてまたは、携帯電話を貸与するかの判断を迫られるようになった。携帯は普遍的な連絡手段であり、既に、外出時等の業務の一部は携帯の上に載っていたから、使用禁止は現実的な選択ではなくなっていた。使用禁止は出来ない。貸与するか。私物利用を認めるかしかない。金持ちは貸与し、貧乏は私物利用を認める。私物利用でも会社関係先への通話は会社が補填する制度を持つところもある。
.*.
スマホも携帯の延長上にある。会社が携帯を貸与していても個人のスマホが入りだす。会社が貸与する携帯がビジネスツール化の一環でスマホになる。携帯自身がスマホ化する。小型PCがポケットに収まるのは時間の問題。そういう前提で、これからの資源管理は検討されなければいけない。
.*.
スマホ(iPhone)の歴史を考えると、タブレット端末(iPad)やハイレベルの携帯音楽プレイヤー(iPod)を考慮するのは当然だし、ストレージの強化とWiFi機能まで持ち始めたやデジカメも無視することは出来ない。USBインタフェース、WiFiインタフェース、大容量メモリ（フラッシュメモリなど）を有する小型機器の類もIT資産の洗い出しの対象に入れるべきでしょう。
.*.
プログラムを実行できる機器類
内容を変更可能なストレージを有する機器類
取り出し可能メディアを装填可能な機器類
外部通信可能な機器類（有線・無線）
メディア（FD,CD/DVD等光学ディスク,USBメモリ、外付けディスク（上記に重複）、フラッシュメモリ、など）
プログラム類（OS、アプリ類）
情報コンテンツ
利用サービス
ライセンス（機器類、プログラム類、コンテンツ類、サービス類）
.*.
資源管理ツールの多くはクライアントソフトを機器類にインストールして、接続されているハードウエア、ソフトウエアの情報を収集する。
基本は「ものの存在」の管理。あるべきものがあるべき状態で存在するか。余計なものが存在しないか。
次には「ものの動作」の管理。許可された動作か。適切な頻度か。
.*.
今一番の問題は、スマホに対するスタンスを決めかねていること。さっさと管理対象資産として位置づけること。業務に必要なら貸与が基本。どうしても、私物のスマホについては許可する場合は資産台帳に反映させ、管理ツールを受け入れることが条件になる。嫌なら私物持込は禁止。（これは携帯でも同様のスタンスが必要）
次に、スマホまで含めた資源管理ツールの導入。PCと別立てでも構わない。適切なものが無ければ自己申告からでも始めることになる。
.*.
2011年11月17日
サイバーテロ対策手段としてのホワイトハット(White Hat)について
システム構築の技術とシステム脆弱性対策の技術とは本来一環をなすっものであるが、現状においてはそれぞれ専門性を有する特異な分野の集合であるから、バランスの考え方が求められる。
従来、限られたリソースで、兎に角、形だけでも作り上げ、何とか動いているように見えればリリースを承認してきた。殆どのシステム開発は、とりあえず動いているだけで、バグの塊。デバッグはユーザー（クライアント）を巻き込んでやるのが常識の時代もあった。
今は、流石に、開発のクオリティも向上して、現地調整（運用テスト）の期間は短縮されるし、内容も運用性評価に近いものになっている。ここでの、主なテスターは企業内ユーザー。導入プロジェクトメンバーであったり、パイロット導入部門のユーザーである。視点はユーザビリティ。
セキュリティの評価は、開発フェーズでも、運用テストフェーズでも全くやっていない訳ではないが、極めて基本的なレベルのものでしかない。ハッキングに対する脆弱性が何処にあるのかすら十分検討できていない。そういう専門家が居ないのだから当然。
企業内のシステムは純粋に１つが存在するのでなく、複数のシステムが同居している。非常に込み入った環境で相互運用のためにあちこちにインタフェースを実現している。そういう脆弱なものであるから、書物に紹介されている定番もののセキュリティ対策だけでは追いつかない。
最近は外部アタック（ハッキングテスト）を請け負う企業も出てきた。やらないよりはましだが、脆弱性検出の確立は高くないと思われる。
ホワイトハットはハッカーの善玉と言うべき存在。悪玉をブラックハットと言うかどうかは知らない。あるいはレッドはっととか。ハッカー技術者を採用して、開発段階、テスト運用の段階で協力を得る。社内の関連システムとの相互運用環境でのテストも非常に重要であると思われる。
フェースブックは既に有名人を採用してニュースになったが、グーグルも同様にホワイトハットの協力を得ているようだ。テストサイトを有意義なメッセージを提供した場合は相応の報酬を支払っているらしい。
ホワイトハットに相当する人材は国内にどれくらい存在するか、どのようにコンタクトできるか、どのような契約が相応しいか、加えて、本当にホワイトかの心証を得られるかという問題（？）もある。距離感の問題です。やはり、一つの専門技術としてITベンダーは養成して行くことになるのではないだろうか。
ただ、方法論はさておき、セキュリティに対して開発投資のバランスを欠いていては社会的説明責任はもはや負えない時代になっているということを企業経営者は強く認識する必要があります。
.*.
変な時代になった。ハッカー経験者だけど、更生したいと思っている人が今求められている。ホワイトハット・コンソーシアムでも開催されるのかな。
.*.
システム構築の技術とシステム脆弱性対策の技術とは本来一環をなすっものであるが、現状においてはそれぞれ専門性を有する特異な分野の集合であるから、バランスの考え方が求められる。
従来、限られたリソースで、兎に角、形だけでも作り上げ、何とか動いているように見えればリリースを承認してきた。殆どのシステム開発は、とりあえず動いているだけで、バグの塊。デバッグはユーザー（クライアント）を巻き込んでやるのが常識の時代もあった。
今は、流石に、開発のクオリティも向上して、現地調整（運用テスト）の期間は短縮されるし、内容も運用性評価に近いものになっている。ここでの、主なテスターは企業内ユーザー。導入プロジェクトメンバーであったり、パイロット導入部門のユーザーである。視点はユーザビリティ。
セキュリティの評価は、開発フェーズでも、運用テストフェーズでも全くやっていない訳ではないが、極めて基本的なレベルのものでしかない。ハッキングに対する脆弱性が何処にあるのかすら十分検討できていない。そういう専門家が居ないのだから当然。
企業内のシステムは純粋に１つが存在するのでなく、複数のシステムが同居している。非常に込み入った環境で相互運用のためにあちこちにインタフェースを実現している。そういう脆弱なものであるから、書物に紹介されている定番もののセキュリティ対策だけでは追いつかない。
最近は外部アタック（ハッキングテスト）を請け負う企業も出てきた。やらないよりはましだが、脆弱性検出の確立は高くないと思われる。
ホワイトハットはハッカーの善玉と言うべき存在。悪玉をブラックハットと言うかどうかは知らない。あるいはレッドはっととか。ハッカー技術者を採用して、開発段階、テスト運用の段階で協力を得る。社内の関連システムとの相互運用環境でのテストも非常に重要であると思われる。
フェースブックは既に有名人を採用してニュースになったが、グーグルも同様にホワイトハットの協力を得ているようだ。テストサイトを有意義なメッセージを提供した場合は相応の報酬を支払っているらしい。
ホワイトハットに相当する人材は国内にどれくらい存在するか、どのようにコンタクトできるか、どのような契約が相応しいか、加えて、本当にホワイトかの心証を得られるかという問題（？）もある。距離感の問題です。やはり、一つの専門技術としてITベンダーは養成して行くことになるのではないだろうか。
ただ、方法論はさておき、セキュリティに対して開発投資のバランスを欠いていては社会的説明責任はもはや負えない時代になっているということを企業経営者は強く認識する必要があります。
.*.
変な時代になった。ハッカー経験者だけど、更生したいと思っている人が今求められている。ホワイトハット・コンソーシアムでも開催されるのかな。
.*.
2011年11月16日
内線携帯電話の不思議な光景
内線電話、PHSを利用してワイヤレスにしているところもある。所謂、内線ピッチと言う奴ですね。外出時は普通の携帯電話として利用することもできる。内線に限定しても当然ですが社外にも電話は可能。電話番号簿をサーバーで管理できるかも知れない。でも少なくとも履歴は残りそうだ。
携帯電話は情報の塊。携帯電話を机の上に置きっ放しにして帰る人はまず居ない。ところが、内線ピッチを机の上に置いたまま帰るのを目にすることがある。10年前ならいざ知らず、今時は非常識の一つ。社会的な説明責任は負えない。にも関わらず、今でも机上に置いたまま。書類などはきれいに片付けてクリアデスクを徹底しているのに、ノートPCとか携帯電話が簡単に持ち出せるように置いてあるのはとても不思議な光景です。
どういうリスクアセスメントをやると放置帰宅がOKになるのか。ISMSが根っ子から歪んでいる可能性もある。コンサルというものは助言は出来ても、業務慣習まで変えるのは容易くない。
.*.
IPフォン利用によるコスト低減が狙いの内線ピッチはいずれスマホに切り替わるだろう。外でもIPフォン利用でコストセーブ。スマートフォンですと入り込む情報量も桁違いに増える可能性がありますから、しっかりリスク対応するでしょう。
.*.
内線電話、PHSを利用してワイヤレスにしているところもある。所謂、内線ピッチと言う奴ですね。外出時は普通の携帯電話として利用することもできる。内線に限定しても当然ですが社外にも電話は可能。電話番号簿をサーバーで管理できるかも知れない。でも少なくとも履歴は残りそうだ。
携帯電話は情報の塊。携帯電話を机の上に置きっ放しにして帰る人はまず居ない。ところが、内線ピッチを机の上に置いたまま帰るのを目にすることがある。10年前ならいざ知らず、今時は非常識の一つ。社会的な説明責任は負えない。にも関わらず、今でも机上に置いたまま。書類などはきれいに片付けてクリアデスクを徹底しているのに、ノートPCとか携帯電話が簡単に持ち出せるように置いてあるのはとても不思議な光景です。
どういうリスクアセスメントをやると放置帰宅がOKになるのか。ISMSが根っ子から歪んでいる可能性もある。コンサルというものは助言は出来ても、業務慣習まで変えるのは容易くない。
.*.
IPフォン利用によるコスト低減が狙いの内線ピッチはいずれスマホに切り替わるだろう。外でもIPフォン利用でコストセーブ。スマートフォンですと入り込む情報量も桁違いに増える可能性がありますから、しっかりリスク対応するでしょう。
.*.
組織内パソコン管理の盲点？
言い尽くされているが、「共有パソコン」あるいは「特定業務用パソコン」の管理が盲点になることがある。
自分専用の業務用パソコンは当人が毎日使うためそれなりに管理される。管理責任者が明確で情報システム部門からの各種お知らせにも随時対応できる。
そもそも、管理対象として認識されているか。抜け漏れの懸念。パソコン台帳の用途欄への適切な記載。
最も基本な日常管理。電源のオンオフ。
PCなら施錠管理（ワイヤロックまたはキャビネット利用）。最近のスリムPCはケーブルを外せば簡単に持ち運び可能。
スクリーンセーバーロックの有効化。
ウイルス対策ソフトの更新（プログラムとデータ）。電源を入れれば自動的にアップデートされると信じても、設定ミスがあればそれまで。ウイルス対策ソフト接続先サーバーを社内に置く場合のアドレス変更管理、接続のタイミング（時刻）を決めている場合の接続漏れ管理。
OS及びアプリケーション類の最新版への更新。
ライセンス管理。普通はオフラインの場合は資源管理ソフトの利用にも工夫が必要。
フリーソフト、スクリプト系アプリの管理も必要。
容量管理。あるいはパフォーマンス管理。用途によっては中古PCの使い回し（あるいは放置）が不適切な場合も有り得る。
ファイル管理。共有PC内に残すファイルの制限。適宜確実に削除しているか。
ファイルのバックアップ管理。
関連するメディア類の管理。
持ち出し管理あるいは所在確認。
アカウント管理。共有IDとパスワードの利用に対する制限。アドミ権限の付与ルール。
利用ログの管理。自動生成の場合、適切に保管されるか。
普通のパソコン管理と変わらないが共有であったり、不使用期間が長かったりすると、より慎重な（確実な）取り扱いが求められる。
.*.
言い尽くされているが、「共有パソコン」あるいは「特定業務用パソコン」の管理が盲点になることがある。
自分専用の業務用パソコンは当人が毎日使うためそれなりに管理される。管理責任者が明確で情報システム部門からの各種お知らせにも随時対応できる。
そもそも、管理対象として認識されているか。抜け漏れの懸念。パソコン台帳の用途欄への適切な記載。
最も基本な日常管理。電源のオンオフ。
PCなら施錠管理（ワイヤロックまたはキャビネット利用）。最近のスリムPCはケーブルを外せば簡単に持ち運び可能。
スクリーンセーバーロックの有効化。
ウイルス対策ソフトの更新（プログラムとデータ）。電源を入れれば自動的にアップデートされると信じても、設定ミスがあればそれまで。ウイルス対策ソフト接続先サーバーを社内に置く場合のアドレス変更管理、接続のタイミング（時刻）を決めている場合の接続漏れ管理。
OS及びアプリケーション類の最新版への更新。
ライセンス管理。普通はオフラインの場合は資源管理ソフトの利用にも工夫が必要。
フリーソフト、スクリプト系アプリの管理も必要。
容量管理。あるいはパフォーマンス管理。用途によっては中古PCの使い回し（あるいは放置）が不適切な場合も有り得る。
ファイル管理。共有PC内に残すファイルの制限。適宜確実に削除しているか。
ファイルのバックアップ管理。
関連するメディア類の管理。
持ち出し管理あるいは所在確認。
アカウント管理。共有IDとパスワードの利用に対する制限。アドミ権限の付与ルール。
利用ログの管理。自動生成の場合、適切に保管されるか。
普通のパソコン管理と変わらないが共有であったり、不使用期間が長かったりすると、より慎重な（確実な）取り扱いが求められる。
.*.
2011年11月14日
情報漏洩を抑制する施策とは
その前に、情報システムから情報が漏えいする可能性とは何でしょう。
適用範囲内の人の操作、ご操作や悪意のある操作は、これは防ぎようがない。権限管理とかトレーサビリティの確保で牽制は出来る。
ここではシステム自体の脆弱性について考える。A.12.5.4の管理策の意図はシステムが保有する情報が容易に漏洩することのないようにシステムを作りこめということ。ある意味、常識の話。
具体的な施策は何でしょう？情報漏えいのリスク自体が、変な話、日進月歩ですから特定のテクニカルな施策を並べても意味がない。
まあ、基本的には、
ウイルス対策。クライアントPCは勿論、サーバー系でも必要。メール、WEBアクセスを含む。ここの勘所は、全てのルート（侵入経路）をカバーする手順を持つこと。今後はネットワーク接続型の設備・施設（従来はIT機器として認識してこなかったもの）への考慮も求められる。
システムの脆弱性管理。OSパッチ、基幹ソフト（DB、ERPなど）修正版などの適切な適用手順。サーバー系、PC系。
ハッキング対策。専門技術者によるハッキングテストを手順として備えること。最近のソニーの事例（アノニマスグループによるゲームサイト攻撃）でも分かるように開発者とハッカーでは技術の性格が異なるため定期的なテストが必要。以前とは違って、今のネットベースのシステム社会では必須アイテムになっている。（テストハッカーという新しい職業が誕生したことになる）
暗号化技術の利用。通信路の暗号化、メディアの暗号化、ファイルの暗号化。
.*.
その前に、情報システムから情報が漏えいする可能性とは何でしょう。
適用範囲内の人の操作、ご操作や悪意のある操作は、これは防ぎようがない。権限管理とかトレーサビリティの確保で牽制は出来る。
ここではシステム自体の脆弱性について考える。A.12.5.4の管理策の意図はシステムが保有する情報が容易に漏洩することのないようにシステムを作りこめということ。ある意味、常識の話。
具体的な施策は何でしょう？情報漏えいのリスク自体が、変な話、日進月歩ですから特定のテクニカルな施策を並べても意味がない。
まあ、基本的には、
ウイルス対策。クライアントPCは勿論、サーバー系でも必要。メール、WEBアクセスを含む。ここの勘所は、全てのルート（侵入経路）をカバーする手順を持つこと。今後はネットワーク接続型の設備・施設（従来はIT機器として認識してこなかったもの）への考慮も求められる。
システムの脆弱性管理。OSパッチ、基幹ソフト（DB、ERPなど）修正版などの適切な適用手順。サーバー系、PC系。
ハッキング対策。専門技術者によるハッキングテストを手順として備えること。最近のソニーの事例（アノニマスグループによるゲームサイト攻撃）でも分かるように開発者とハッカーでは技術の性格が異なるため定期的なテストが必要。以前とは違って、今のネットベースのシステム社会では必須アイテムになっている。（テストハッカーという新しい職業が誕生したことになる）
暗号化技術の利用。通信路の暗号化、メディアの暗号化、ファイルの暗号化。
.*.
ASR ：エイエスアール株式会社
あまり馴染みのない会社ですが、設立は２０００年。審査機関として１０年以上の経験があるのかな？
http://www.armsr.co.jp/index.html
２０１１年１１月の審査実績がJIPDECのデータでは38件。この件数では審査員のスキル維持もなかなか難しいかもしれない。セミナーとかの場を使うなどして工夫しているんでしょう。
.*.
この会社から破格の料金でISMS審査を受けることが出来るとしたらどうしますか？
ISMS認証などどこの審査機関でとっても全部同じと思っていいのか、やはり一定の基準を考えるべきか。審査機関を変更すること自体はきわめて容易に出来ると聞くので、最初のお金が掛かるとき（初回認証審査）は安い審査機関を使って、維持状態（更新審査・維持審査）になったら実績のある審査機関に移って、少しずつ世間水準へ持っていくとかするのは、作戦として如何なんだろう。
.*.
審査機関について何と無く言えそうなこと：
実績があれば安心には違いない。自分が世間全体の何処にいるか分かる。
実績が少ない処は、特定の理由で存在している可能性があるので、多分、同じ理由を持たない場合は馴染まないのではないか。
最初に管理の仕組みを間違えると後で直すのは大変。コンサルも同じ。悪法もいったん成立すると改訂には何倍も労力が掛かる例え。
何でもOKの審査機関では結局役に立たない。
審査効率優先の審査機関も企業の役には立たないのではないか。時間とお金を少し節約できてもいい加減なコンサルや審査では後で自分が苦労する。
.*.
寄り道ばかりだけど、このASRという審査機関もある意味ではお客様ですし、セキュリティを改善する意味ではパートナーの一つかもしれない。と言うことで、是非、頑張って良い仕事をしていただきたいですね。
.*.
あまり馴染みのない会社ですが、設立は２０００年。審査機関として１０年以上の経験があるのかな？
http://www.armsr.co.jp/index.html
２０１１年１１月の審査実績がJIPDECのデータでは38件。この件数では審査員のスキル維持もなかなか難しいかもしれない。セミナーとかの場を使うなどして工夫しているんでしょう。
.*.
この会社から破格の料金でISMS審査を受けることが出来るとしたらどうしますか？
ISMS認証などどこの審査機関でとっても全部同じと思っていいのか、やはり一定の基準を考えるべきか。審査機関を変更すること自体はきわめて容易に出来ると聞くので、最初のお金が掛かるとき（初回認証審査）は安い審査機関を使って、維持状態（更新審査・維持審査）になったら実績のある審査機関に移って、少しずつ世間水準へ持っていくとかするのは、作戦として如何なんだろう。
.*.
審査機関について何と無く言えそうなこと：
実績があれば安心には違いない。自分が世間全体の何処にいるか分かる。
実績が少ない処は、特定の理由で存在している可能性があるので、多分、同じ理由を持たない場合は馴染まないのではないか。
最初に管理の仕組みを間違えると後で直すのは大変。コンサルも同じ。悪法もいったん成立すると改訂には何倍も労力が掛かる例え。
何でもOKの審査機関では結局役に立たない。
審査効率優先の審査機関も企業の役には立たないのではないか。時間とお金を少し節約できてもいい加減なコンサルや審査では後で自分が苦労する。
.*.
寄り道ばかりだけど、このASRという審査機関もある意味ではお客様ですし、セキュリティを改善する意味ではパートナーの一つかもしれない。と言うことで、是非、頑張って良い仕事をしていただきたいですね。
.*.
企業における電子メールの保管と検閲
電子メール意外にもWEBアプリケーションを利用した外部との情報交換は容易に可能。社員が外部と電子的な情報の交換を行う場合に、これを捕捉し必要な検閲を行うとともに、必要な期間保管することが重要である。その他、メディアを経由した情報交換も外部と看做して同様に検閲と保管が求められる。
これを徹底してやっている企業はまだ少ない。一部でも取り込んでいる企業は既に相当数あるようだ。これも、専用のツールの導入することになりコストの壁が立ちはだかる。
保管期限は当該社員の在籍期間、及び退職後１０年。アメリカ国防総省の話みたいだね。
いずれにしても、ISMSではこのような管理策が必要か、どのレベルで必要かを（リスクアセスメントとの関連において）明確にすることになるが、費用対効果の視点が入ると消えてしまうのが大半。
.*.
トレーサビリティの確保はどの程度のレベルで必要か。これはリスクアセスメントからは導き出せない場合でも組織として決定しておくことが重要でしょう。
.*.
電子メール意外にもWEBアプリケーションを利用した外部との情報交換は容易に可能。社員が外部と電子的な情報の交換を行う場合に、これを捕捉し必要な検閲を行うとともに、必要な期間保管することが重要である。その他、メディアを経由した情報交換も外部と看做して同様に検閲と保管が求められる。
これを徹底してやっている企業はまだ少ない。一部でも取り込んでいる企業は既に相当数あるようだ。これも、専用のツールの導入することになりコストの壁が立ちはだかる。
保管期限は当該社員の在籍期間、及び退職後１０年。アメリカ国防総省の話みたいだね。
いずれにしても、ISMSではこのような管理策が必要か、どのレベルで必要かを（リスクアセスメントとの関連において）明確にすることになるが、費用対効果の視点が入ると消えてしまうのが大半。
.*.
トレーサビリティの確保はどの程度のレベルで必要か。これはリスクアセスメントからは導き出せない場合でも組織として決定しておくことが重要でしょう。
.*.
シン・クライアントの導入によるセキュリティ強化策
一時ほどシン・クライアント(Thin Client)の話題が出なくなった。下火になった訳ではない。依然として有効な手段との認識は有る。しかし、問題はコスト。初期投資がかかりすぎる。端末もサーバーも特殊使用になるため、台数が限られる。結果的には量産効果も出ないので、コストは高いまま。導入は進まない。
シン・クライアント（略してシンクラ？）の要点は、ローカルにデータを保存しないこと。データの集中管理。部門には一切の電子データが存在しない状況を作り上げること。ワンライティングとペーパーレスでよく管理されたサーバー上の電子データのみが存在する。データを集中させるとリスクに対しては情報とセキュリティの専門家集団が、十分なリソースのもとに管理することで対応する。
貧乏会社はどうするか？
普通のパソコンのシンクラ的運用をおこなう。
基本的にパソコンにデータはダウンロードさせずにいきなりサーバーから開く。止む無く、ダウンロードした場合も、適宜アップロード、午前または午後の業務終了時にはアップロードとPC内ファイルの削除を行う。勿論、部門サーバーなどは認めない。
業務アプリケーションも順次WEBアプリケーション型に改修する。
オフィスアプリケーションも同様。グーグルの企業向けサービスを導入するところも増えてきた。
ノーマルなPCをシンクライアント的運用に供するためのソフトウエアもリリースされているかもしれない。
.*.
シンクライアントの弱点は外出・出張など社外へ持ち出した時の対応でしたが、ブロードバンドが普及した今はG3回戦で会社に接続することでクリアできる。電波が利用できない時は、限定的に情報の持ち出しの管理策が必要になります。その場合もPC上にはデータは保管しない形になるでしょう。
.*.
シンクライアントソリューションと対極にあるアプローチは丸ごと暗号化ツール。SafeBoot(（今はMcAfee Endpoint Encryptionというらしい。買収されたのか）が代表例。SafeBootを利用することを前提にパソコン上に何を保管しても構わないとする考え方を取るところもあるようだ。
今やHDDはテラバイトの時代。セーフブートの強度が如何ほどか分からないが、一切合切を乗せて持ち歩くのはやはり問題でしょう。中を覗ける手段が正規の利用者にはあるのだから、第三者も中も覗ける方法はあることになる。
やはり、管理策のベースはシンクライアント型にし、止むを得ない場合において、セーフブート利用というのが現在の技術レベルでは適切な落としどころではないだろうか。
.*.
ところで、これは、管理策のどの項目に該当するんですか？
一時ほどシン・クライアント(Thin Client)の話題が出なくなった。下火になった訳ではない。依然として有効な手段との認識は有る。しかし、問題はコスト。初期投資がかかりすぎる。端末もサーバーも特殊使用になるため、台数が限られる。結果的には量産効果も出ないので、コストは高いまま。導入は進まない。
シン・クライアント（略してシンクラ？）の要点は、ローカルにデータを保存しないこと。データの集中管理。部門には一切の電子データが存在しない状況を作り上げること。ワンライティングとペーパーレスでよく管理されたサーバー上の電子データのみが存在する。データを集中させるとリスクに対しては情報とセキュリティの専門家集団が、十分なリソースのもとに管理することで対応する。
貧乏会社はどうするか？
普通のパソコンのシンクラ的運用をおこなう。
基本的にパソコンにデータはダウンロードさせずにいきなりサーバーから開く。止む無く、ダウンロードした場合も、適宜アップロード、午前または午後の業務終了時にはアップロードとPC内ファイルの削除を行う。勿論、部門サーバーなどは認めない。
業務アプリケーションも順次WEBアプリケーション型に改修する。
オフィスアプリケーションも同様。グーグルの企業向けサービスを導入するところも増えてきた。
ノーマルなPCをシンクライアント的運用に供するためのソフトウエアもリリースされているかもしれない。
.*.
シンクライアントの弱点は外出・出張など社外へ持ち出した時の対応でしたが、ブロードバンドが普及した今はG3回戦で会社に接続することでクリアできる。電波が利用できない時は、限定的に情報の持ち出しの管理策が必要になります。その場合もPC上にはデータは保管しない形になるでしょう。
.*.
シンクライアントソリューションと対極にあるアプローチは丸ごと暗号化ツール。SafeBoot(（今はMcAfee Endpoint Encryptionというらしい。買収されたのか）が代表例。SafeBootを利用することを前提にパソコン上に何を保管しても構わないとする考え方を取るところもあるようだ。
今やHDDはテラバイトの時代。セーフブートの強度が如何ほどか分からないが、一切合切を乗せて持ち歩くのはやはり問題でしょう。中を覗ける手段が正規の利用者にはあるのだから、第三者も中も覗ける方法はあることになる。
やはり、管理策のベースはシンクライアント型にし、止むを得ない場合において、セーフブート利用というのが現在の技術レベルでは適切な落としどころではないだろうか。
.*.
ところで、これは、管理策のどの項目に該当するんですか？
内部監査責任者の位置づけを正しく理解したい
コンサルに出向くとISMSの組織図を最初に見ることになるが、どうも変な感じの体制図が出てくる。内部監査責任者の位置づけが、実態で書かれていて、べき論では記載されていないようだ。
内部監査責任者に会社の重鎮を持ってくることは希（まれ）。どうしても、経験者だけれど閑職に近い人を持ってきてしまう。もしくは情報セキュリティ管理責任者の配下の事務局メンバーが兼務。
会社でのポジションの上下と関係なく、役割で見る事が基本。経営者はISMS導入と運用を情報セキュリティ（IS)管理責任者に指示する（託す）。一方でIS管理責任者の仕事ぶりのチェックを第三者に指示する（託す）。内部監査は内部監査責任者が経営者の名代として行うものである。経営者はその両方から報告を受け次の経営判断を供していくことになる。
内部監査責任者の報告先はあくまでも経営者である。組織図もそのように明示することが必要。下手なところはIS管理責任者の下に内部監査責任者が位置付いている。論外。独立性、客観性を失った監査には何の価値もない。
.*.
年齢は行っていても会社ではほぼ平社員の内部監査責任者が直接経営陣に報告あるいは調整を行うことが出来るかどうか。会社の事情によっては難しいところもあるかもしれないが、与えられた仕事だからやっていただくしかないところです。この役割を担う適切な人材が居るか居ないかもその組織にとっては要点です。
.*.
審査計画で、内部監査責任者との時間を取らないものが時々見受けられるが、計画としてお粗末に見える。情報システム〜ITインフラ部門の長と内部間責任者の時間をスキップできる審査など考え難い。
.*.
コンサルに出向くとISMSの組織図を最初に見ることになるが、どうも変な感じの体制図が出てくる。内部監査責任者の位置づけが、実態で書かれていて、べき論では記載されていないようだ。
内部監査責任者に会社の重鎮を持ってくることは希（まれ）。どうしても、経験者だけれど閑職に近い人を持ってきてしまう。もしくは情報セキュリティ管理責任者の配下の事務局メンバーが兼務。
会社でのポジションの上下と関係なく、役割で見る事が基本。経営者はISMS導入と運用を情報セキュリティ（IS)管理責任者に指示する（託す）。一方でIS管理責任者の仕事ぶりのチェックを第三者に指示する（託す）。内部監査は内部監査責任者が経営者の名代として行うものである。経営者はその両方から報告を受け次の経営判断を供していくことになる。
内部監査責任者の報告先はあくまでも経営者である。組織図もそのように明示することが必要。下手なところはIS管理責任者の下に内部監査責任者が位置付いている。論外。独立性、客観性を失った監査には何の価値もない。
.*.
年齢は行っていても会社ではほぼ平社員の内部監査責任者が直接経営陣に報告あるいは調整を行うことが出来るかどうか。会社の事情によっては難しいところもあるかもしれないが、与えられた仕事だからやっていただくしかないところです。この役割を担う適切な人材が居るか居ないかもその組織にとっては要点です。
.*.
審査計画で、内部監査責任者との時間を取らないものが時々見受けられるが、計画としてお粗末に見える。情報システム〜ITインフラ部門の長と内部間責任者の時間をスキップできる審査など考え難い。
.*.
「識別しない」と言う管理策の不可解
重要な情報資産を何処に保管しているか。これは容易に他人に教えることは出来ない。警備員の人数も教えるわけには行かない。でも、粘り強くコンタクトあるいは監視を続ければ、適用範囲の外の人間からでもある程度の推定は出来る。
一旦、適用範囲の中に入ると情報資産は識別されて、何が重要で何が重要でないかが分かる。社外秘、機密、秘、持出禁止、重要などとスタンプされたりシールが張られたりする。ここでも容易に極秘と判別されるのは、不測の事態ではリスクを持つことになると言う理由で、色分けされたシールで識別するようにするところもある。
ときどき話題になるのは「識別しない」という方法論の有効性。バインダーでもメディアでもいいが、中に入っている情報が重要なものか重要でないものかを分からないように敢えて識別しないと主張するクライアントがいるらしい。これは強弁である。でもこの強弁を審査員にぶつけると鳩が豆鉄砲を食らったが如く、びっくりしてすごすご引き返すことが結構あるらしい。
単にラベル付けの問題なら大騒ぎすることもない。識別はしているがラベルは貼らない。それだけの話だから。
情報資産のタイトルがあれば識別になる。タイトルから台帳を探れば、CIAの要求レベルと必要な管理策が分かる。メディアであればパソコンから中を覗けば同様に情報資産の管理要件が把握できる。パスワードをつける対象か、施錠管理の対象かなどは台帳に戻れば簡単に把握出来る。これこそが強弁である。ラベル付をサボる言い訳を理屈にしてみただけで、実効性はない。バーコードのシールが張られていてバーコードリーダーを持ち歩く現場なら可能性を否定できないが通常のオフィスでは難しい。
機密性区分を識別しない。ラベル付けもやらない。これは重大な不適合に相当する。特に重要な機密性資産については不可欠。
面白いのは識別･ラベル付を放棄しておいて、管理策の内容が異なるケース。例えば、秘密情報資産は施錠管理しなさい。秘密情報資産以外は施錠管理の必要はない。としておいて、この両者の識別･ラベル付けは不要とすると、書庫に収まる資産は正しく収まっているかどうか、都度最新の台帳で確認することになるが、現実的には無理、
結論は単純。『管理策が異なる場合は管理策に応じた容易さをもって識別（区分認識）が可能でなければいけない』というものです。
.*.
重要な情報資産を何処に保管しているか。これは容易に他人に教えることは出来ない。警備員の人数も教えるわけには行かない。でも、粘り強くコンタクトあるいは監視を続ければ、適用範囲の外の人間からでもある程度の推定は出来る。
一旦、適用範囲の中に入ると情報資産は識別されて、何が重要で何が重要でないかが分かる。社外秘、機密、秘、持出禁止、重要などとスタンプされたりシールが張られたりする。ここでも容易に極秘と判別されるのは、不測の事態ではリスクを持つことになると言う理由で、色分けされたシールで識別するようにするところもある。
ときどき話題になるのは「識別しない」という方法論の有効性。バインダーでもメディアでもいいが、中に入っている情報が重要なものか重要でないものかを分からないように敢えて識別しないと主張するクライアントがいるらしい。これは強弁である。でもこの強弁を審査員にぶつけると鳩が豆鉄砲を食らったが如く、びっくりしてすごすご引き返すことが結構あるらしい。
単にラベル付けの問題なら大騒ぎすることもない。識別はしているがラベルは貼らない。それだけの話だから。
情報資産のタイトルがあれば識別になる。タイトルから台帳を探れば、CIAの要求レベルと必要な管理策が分かる。メディアであればパソコンから中を覗けば同様に情報資産の管理要件が把握できる。パスワードをつける対象か、施錠管理の対象かなどは台帳に戻れば簡単に把握出来る。これこそが強弁である。ラベル付をサボる言い訳を理屈にしてみただけで、実効性はない。バーコードのシールが張られていてバーコードリーダーを持ち歩く現場なら可能性を否定できないが通常のオフィスでは難しい。
機密性区分を識別しない。ラベル付けもやらない。これは重大な不適合に相当する。特に重要な機密性資産については不可欠。
面白いのは識別･ラベル付を放棄しておいて、管理策の内容が異なるケース。例えば、秘密情報資産は施錠管理しなさい。秘密情報資産以外は施錠管理の必要はない。としておいて、この両者の識別･ラベル付けは不要とすると、書庫に収まる資産は正しく収まっているかどうか、都度最新の台帳で確認することになるが、現実的には無理、
結論は単純。『管理策が異なる場合は管理策に応じた容易さをもって識別（区分認識）が可能でなければいけない』というものです。
.*.
2011年11月13日
PDF過信で墓穴を掘るISMS組織
セキュリティに染まると文書はPDFが横行？する。PDFだと文書の意図しない利用を軽減できると踏んでいるからだろう。ファイルサイズも少し小さくなるので更に好ましい。
申込書、調査書、登録書、報告書の類は、この頃はPDFのものをダウンロードして使うことが多くなる。これは、ダウンロードして印刷して、その植えに手書きで必要事項を記載して郵送する。郵便代が掛かるのが嫌ならスキャンしてPDF（只の画像）にしてアップロードまたは電子メールする。
WEBフォームでやれば、余計な印刷も発生しないし、インプット情報もデジタルのまま利用できる。転記とかで情報が摩り替わる心配も少ない。環境面でもセキュリティ面でもPDF利用にビハインドがあるが、最初にインプットされたPDFのイメージに洗脳されて正しい判断すら脅かされている。
セキュリティがCIAの側面を持つことに再度思い起こして欲しいね。
.*.
ただ単に紙ベースで処理（捺印する程度？）して後は束ねて保管するだけが目的なら何も問題ない。トレーサビリティ以上は求めないと言うことですね。
.*.
セキュリティに染まると文書はPDFが横行？する。PDFだと文書の意図しない利用を軽減できると踏んでいるからだろう。ファイルサイズも少し小さくなるので更に好ましい。
申込書、調査書、登録書、報告書の類は、この頃はPDFのものをダウンロードして使うことが多くなる。これは、ダウンロードして印刷して、その植えに手書きで必要事項を記載して郵送する。郵便代が掛かるのが嫌ならスキャンしてPDF（只の画像）にしてアップロードまたは電子メールする。
WEBフォームでやれば、余計な印刷も発生しないし、インプット情報もデジタルのまま利用できる。転記とかで情報が摩り替わる心配も少ない。環境面でもセキュリティ面でもPDF利用にビハインドがあるが、最初にインプットされたPDFのイメージに洗脳されて正しい判断すら脅かされている。
セキュリティがCIAの側面を持つことに再度思い起こして欲しいね。
.*.
ただ単に紙ベースで処理（捺印する程度？）して後は束ねて保管するだけが目的なら何も問題ない。トレーサビリティ以上は求めないと言うことですね。
.*.
フリーソフトを目の敵にする組織のISMS
時代を実態を理解していない。グーグルはフリーソフトの代表、マイクロソフトもフリーウエアをいくつも出している。ダウンロードで提供するものは危ないと言うならインターネットも使えない。古い頭の人がなまじISMSの推進役に付くと時代錯誤の管理策が顔を出す。現場はある日突然に管理策が降ってくるので堪らない。IT部門に限らずIT系企業にはISMS推進員の及びも付かない技術的な理解者、セキュリティを熟知したものがいるのに、突然、会社のツールと言う形で降りてくるから全く困ったことになる。
新しい管理策を降ろす時に、1）初期レビュー機関を設定すること。周知から実施までのヒアリング期間。2）新しい管理策の必要な理由と、方法論の妥当性についての検討結果を明確にすること。技術音痴のISMS担当が馬鹿な管理策にしがみ付くのを回避できる。
.*.
改善活動でよく目にする間違いが一般解と特定解の混同。新たな管理策は何処かの問題を拾って是正するために出されることが多いが、それを全員に適用することの有意性については殆ど検討されない。新たな管理策はその適用対象・条件をより明確に限定的にすることが必要である。少なくとも例外の有無を明示的に探し結果を反映すべきである。
例外の無いルールは無いと言われるくらいの現実が分かっていても、トップは気合一発で全社全員に適用と格好良く判断するが、慎重さに欠ける姿勢は幼くも見える。
.*.
時代を実態を理解していない。グーグルはフリーソフトの代表、マイクロソフトもフリーウエアをいくつも出している。ダウンロードで提供するものは危ないと言うならインターネットも使えない。古い頭の人がなまじISMSの推進役に付くと時代錯誤の管理策が顔を出す。現場はある日突然に管理策が降ってくるので堪らない。IT部門に限らずIT系企業にはISMS推進員の及びも付かない技術的な理解者、セキュリティを熟知したものがいるのに、突然、会社のツールと言う形で降りてくるから全く困ったことになる。
新しい管理策を降ろす時に、1）初期レビュー機関を設定すること。周知から実施までのヒアリング期間。2）新しい管理策の必要な理由と、方法論の妥当性についての検討結果を明確にすること。技術音痴のISMS担当が馬鹿な管理策にしがみ付くのを回避できる。
.*.
改善活動でよく目にする間違いが一般解と特定解の混同。新たな管理策は何処かの問題を拾って是正するために出されることが多いが、それを全員に適用することの有意性については殆ど検討されない。新たな管理策はその適用対象・条件をより明確に限定的にすることが必要である。少なくとも例外の有無を明示的に探し結果を反映すべきである。
例外の無いルールは無いと言われるくらいの現実が分かっていても、トップは気合一発で全社全員に適用と格好良く判断するが、慎重さに欠ける姿勢は幼くも見える。
.*.
2011年11月11日
ファームウエアにもウイルスは潜み込むか
Duqu（ドゥークー）の話題が出たついでに、組み込みソフトにもウイルスが入るかの話になった。ROMもRAMもある。意図しない不具合はバグ、意図した不具合はウイルスの類ということになるのかな。バグが入る込む可能性がある限りウイルスの類も入り込むチャンスはある。オンラインネットワークの環境にあるかどうかは問題ではない。
根本的な違いは？
不具合をもたらす人が内部者か外部者かのちがい。内部の確信犯の場合は、実に容易く（たやすく）ウイルスを忍ばせることが出来る。外部者がウイルスを忍ばせることが出来るチャンスはどれくらいあるだろうか？
先ず、コード量の大きさを認識すべきである。多くのモジュールは安全性を確認して統合される。モジュールにウイルスが潜むチャンスはあるか。既存モジュールを流用しているつもりで摩り替わるチャンスはあるか。開発環境はセキュアな環境として運営される。開発環境に侵入されるチャンスはあるか。委託先も同様のセキュアな環境か。メンテナンスフェーズに入っても同様にセキュアな手順が維持できるか。更新ソフトを移送する手順に弱点は無いか。ローカルLAN、プライベートLANのつもりが別のネットに繋がっていないか。
設備・施設自体の広がりも認識すべきである。単独・集中型のハイテク設備・施設は最早少ないでしょう。分散型、連携・連動型、遠隔監視、遠隔保守など、これらは全てその機能性能発揮のトレードオフとして脆弱性を提供していると思われる。
安全地帯があると信じてスタートすること自体が無謀である。安全地帯は何処にもない前提でスタートすることが必要。核施設など国家的重要施設に限らず、ハイテク印刷装置にしてもソフトウエアの固まりだから意識しておいて良いでしょう。
.*.
でもファームウエアに入り込んだウイルスって記憶にありません。
.*.
Duqu（ドゥークー）の話題が出たついでに、組み込みソフトにもウイルスが入るかの話になった。ROMもRAMもある。意図しない不具合はバグ、意図した不具合はウイルスの類ということになるのかな。バグが入る込む可能性がある限りウイルスの類も入り込むチャンスはある。オンラインネットワークの環境にあるかどうかは問題ではない。
根本的な違いは？
不具合をもたらす人が内部者か外部者かのちがい。内部の確信犯の場合は、実に容易く（たやすく）ウイルスを忍ばせることが出来る。外部者がウイルスを忍ばせることが出来るチャンスはどれくらいあるだろうか？
先ず、コード量の大きさを認識すべきである。多くのモジュールは安全性を確認して統合される。モジュールにウイルスが潜むチャンスはあるか。既存モジュールを流用しているつもりで摩り替わるチャンスはあるか。開発環境はセキュアな環境として運営される。開発環境に侵入されるチャンスはあるか。委託先も同様のセキュアな環境か。メンテナンスフェーズに入っても同様にセキュアな手順が維持できるか。更新ソフトを移送する手順に弱点は無いか。ローカルLAN、プライベートLANのつもりが別のネットに繋がっていないか。
設備・施設自体の広がりも認識すべきである。単独・集中型のハイテク設備・施設は最早少ないでしょう。分散型、連携・連動型、遠隔監視、遠隔保守など、これらは全てその機能性能発揮のトレードオフとして脆弱性を提供していると思われる。
安全地帯があると信じてスタートすること自体が無謀である。安全地帯は何処にもない前提でスタートすることが必要。核施設など国家的重要施設に限らず、ハイテク印刷装置にしてもソフトウエアの固まりだから意識しておいて良いでしょう。
.*.
でもファームウエアに入り込んだウイルスって記憶にありません。
.*.
初回審査は、文書審査、初動審査、本審査の順で進められる。
文書審査
文書審査は、重要文書（ISMS構築の要点となる文書）を審査するもので、審査員が当該組織を訪問しない。ISMSマニュアルに相当する文書類、特にリスクアセスメント関連、適用範囲関連は重要である。基本的なスキームのミスはISMS活動全体への影響が大きいため、早い段階で問題の有無を確認するものです。
文書審査は、資料を審査機関に送ることになるが、そのこと自体がリスクを伴うものであるため、電子環境の利用なども一部実施されている。リスクの質が変わるだけで、必ずしも軽減されるわけではない。印刷コストなどの軽減は図れる期待がある。電子環境での文書審査は、俯瞰性が下がるため審査員には必ずしも歓迎されていないようだ。
文書審査時に求める文書類は審査機関毎に定めている。
文書審査の前に予備審査あるいは予備調査が実施されることもある。審査という名称は相応しくないということで最近は調査辺りの用語としている。一種のコンサル行為に相当するという懸念を払うためだが、やっていることは変わりはない。審査を受けることが出来るかどうかの見極め。
審査機関によっては、予備調査に出た人（審査員）は、審査を担当しないというルールを設定している。予備調査にコンサル的側面が入ることを避けるためである。この程度でも受審出来るとした人が、審査の中でこれでは駄目ですとは言えない空と言うのが基本的な理由。（事務局が内部監査をやるのと似た構造ですね）
審査機関によってはお構いなし。クライアントから見れば安心では有るが、いい加減差を見逃しはしないでしょう。「それなりの付き合い」になるのでしょうね。
初動審査
文書審査で、是正が済むと初動審査で往査の形になる。現場に入る。メインサイトの訪問。文書の是正確認とサンプリングした部署の訪問も行う。リスクアセスメントの実際の状況も確認する。教育計画、内部監査計画（または実績）、事業継続計画（予定）についても確認する。運用計画の全体を見る。既に、ISMSの運用を開始しているところも有るが、計画に指摘が入ることもあるので、多くの場合は初動審査の指摘を踏まえて是正後に運用開始の日程を組む。初動審査では本審査のねらい目を見極めることも目的になっている。当該組織の重要リスク領域と管理策が有効に働くかの視点で本審査計画の概要を検討する。
本審査の日程もここで最終確認する。初動審査と本審査の間があまり短いと運用期間が短くなって色々無理矛盾が出てくるので要注意。そのため、無理を承知で初動審査前に運用を開始するケースも出てくる。手戻りのリスクを咥え込むので勧められないが時間切れ見切りのケース。
本審査
文書審査、初動審査で確認したことも含めて、ISMSの運用を審査する。マネジメントレビュー（インプットとアウトプット、特にトップの指示事項の取り扱い）、内部監査、それに伴う是正、リスクアセスメントとリスク対応計画の進捗、事業継続計画の訓練と是正、有効性指標とデータ収集、採用・退職を含む人的セキュリティ、サイトは全て訪問する。データセンターなど重要資産を外部に預けてある場合はその管理状況の確認も行う。
マネジメントレビューなどキーアクティビティが欠落すると重大な不適合で再審査。
本審査では審査員チームとして認証の是非判断が行われます。（最終判定は判定委員会）
経営者インタビュー
トップインタビューはマネジメントレビューの関連があるので本審査冒頭に実施することが多い。インタビューの狙いは、トップがISMSにどの程度関与しているかを直接伺うことであるが、もっと基本的なところでは、トップのISMSに対する意志（狙い・価値観）を正しく理解すること。
規格適合性というクールな側面と、トップの意志が現場で正しく具現しているかというホットな側面がある。その意味では、経営者インタビューの形式は取らなくても、初動審査の段階で「トップ懇談」の機会を設けることは有意義である。経営者インタビューでも余計な緊張を強いられずより有意義と言えます。
.*.
第1段階、第2段階だけで進める審査もあります。訪問による文書審査と初動審査を第1段階。第2段階は本審査と同じ内容です。手順がコンパクトでクライアントの負担が一見小さいように見えますが、全体のマネジメントスキームへの影響が大きいため、慎重に手順を踏む方が後々の負担は抑えることが出来ます。手軽に簡易型で進めてしまうと、手軽な簡易型からより有効性の高いマネジメントに移行することが出来にくくなります。
ここは手軽に一件落着を目指すコンサルと審査員と事務局の利害が一致して経営者が置いてけぼりを食らう勘定になるので要注意のうえにも要注意です。更に第三者的な立場のアドバイザーを活用するところでしょう。
.*.
文書審査
文書審査は、重要文書（ISMS構築の要点となる文書）を審査するもので、審査員が当該組織を訪問しない。ISMSマニュアルに相当する文書類、特にリスクアセスメント関連、適用範囲関連は重要である。基本的なスキームのミスはISMS活動全体への影響が大きいため、早い段階で問題の有無を確認するものです。
文書審査は、資料を審査機関に送ることになるが、そのこと自体がリスクを伴うものであるため、電子環境の利用なども一部実施されている。リスクの質が変わるだけで、必ずしも軽減されるわけではない。印刷コストなどの軽減は図れる期待がある。電子環境での文書審査は、俯瞰性が下がるため審査員には必ずしも歓迎されていないようだ。
文書審査時に求める文書類は審査機関毎に定めている。
文書審査の前に予備審査あるいは予備調査が実施されることもある。審査という名称は相応しくないということで最近は調査辺りの用語としている。一種のコンサル行為に相当するという懸念を払うためだが、やっていることは変わりはない。審査を受けることが出来るかどうかの見極め。
審査機関によっては、予備調査に出た人（審査員）は、審査を担当しないというルールを設定している。予備調査にコンサル的側面が入ることを避けるためである。この程度でも受審出来るとした人が、審査の中でこれでは駄目ですとは言えない空と言うのが基本的な理由。（事務局が内部監査をやるのと似た構造ですね）
審査機関によってはお構いなし。クライアントから見れば安心では有るが、いい加減差を見逃しはしないでしょう。「それなりの付き合い」になるのでしょうね。
初動審査
文書審査で、是正が済むと初動審査で往査の形になる。現場に入る。メインサイトの訪問。文書の是正確認とサンプリングした部署の訪問も行う。リスクアセスメントの実際の状況も確認する。教育計画、内部監査計画（または実績）、事業継続計画（予定）についても確認する。運用計画の全体を見る。既に、ISMSの運用を開始しているところも有るが、計画に指摘が入ることもあるので、多くの場合は初動審査の指摘を踏まえて是正後に運用開始の日程を組む。初動審査では本審査のねらい目を見極めることも目的になっている。当該組織の重要リスク領域と管理策が有効に働くかの視点で本審査計画の概要を検討する。
本審査の日程もここで最終確認する。初動審査と本審査の間があまり短いと運用期間が短くなって色々無理矛盾が出てくるので要注意。そのため、無理を承知で初動審査前に運用を開始するケースも出てくる。手戻りのリスクを咥え込むので勧められないが時間切れ見切りのケース。
本審査
文書審査、初動審査で確認したことも含めて、ISMSの運用を審査する。マネジメントレビュー（インプットとアウトプット、特にトップの指示事項の取り扱い）、内部監査、それに伴う是正、リスクアセスメントとリスク対応計画の進捗、事業継続計画の訓練と是正、有効性指標とデータ収集、採用・退職を含む人的セキュリティ、サイトは全て訪問する。データセンターなど重要資産を外部に預けてある場合はその管理状況の確認も行う。
マネジメントレビューなどキーアクティビティが欠落すると重大な不適合で再審査。
本審査では審査員チームとして認証の是非判断が行われます。（最終判定は判定委員会）
経営者インタビュー
トップインタビューはマネジメントレビューの関連があるので本審査冒頭に実施することが多い。インタビューの狙いは、トップがISMSにどの程度関与しているかを直接伺うことであるが、もっと基本的なところでは、トップのISMSに対する意志（狙い・価値観）を正しく理解すること。
規格適合性というクールな側面と、トップの意志が現場で正しく具現しているかというホットな側面がある。その意味では、経営者インタビューの形式は取らなくても、初動審査の段階で「トップ懇談」の機会を設けることは有意義である。経営者インタビューでも余計な緊張を強いられずより有意義と言えます。
.*.
第1段階、第2段階だけで進める審査もあります。訪問による文書審査と初動審査を第1段階。第2段階は本審査と同じ内容です。手順がコンパクトでクライアントの負担が一見小さいように見えますが、全体のマネジメントスキームへの影響が大きいため、慎重に手順を踏む方が後々の負担は抑えることが出来ます。手軽に簡易型で進めてしまうと、手軽な簡易型からより有効性の高いマネジメントに移行することが出来にくくなります。
ここは手軽に一件落着を目指すコンサルと審査員と事務局の利害が一致して経営者が置いてけぼりを食らう勘定になるので要注意のうえにも要注意です。更に第三者的な立場のアドバイザーを活用するところでしょう。
.*.
2011年11月10日
「残留リスクの承認」で具体的にはどうするのか？
先ず、残留リスクのおさらい。全ての存在するリスクです。受容基準、受容水準を超えたものだけが残留リスクではありません。ベテラン（何の？）でも間違えていることが多いそうです。
何故、受容しているリスク状況もトップは知る必要があるか。設定した受容水準の検証のためです。リスクポテンシャルの正しい理解のために全容を把握します。
受容基準を超えたものはリスク低減等の対策が求められますが、その時に何らかの投資が伴うため、投資の承認も何処かで必要になります。それが残留リスクの承認の場と同時である必要はありません。場合によっては「やり過ぎ」になります。
リスクの分布状況。統計データ。図表があれば尚良い。
受容レベルを超えたリスク（資産と管理状況とリスク値）。
受容水準~受容基準の見直し提案。
リスク対応検討対象資産の提案。
残留リスク承認のエビデンスは議事録。どの会議体でも構わないがトップの指示事項も反映させたものが好ましい。
分厚いリスク分析表の表紙にトップの承認印を貰うなどは、承認の形式だけを求めたもので、事務局の工程能力の無さを露呈したものになる。
.*.
そこまでやる必要ないよ。という輩もいます。甘言には注意すべきです。
.*.
先ず、残留リスクのおさらい。全ての存在するリスクです。受容基準、受容水準を超えたものだけが残留リスクではありません。ベテラン（何の？）でも間違えていることが多いそうです。
何故、受容しているリスク状況もトップは知る必要があるか。設定した受容水準の検証のためです。リスクポテンシャルの正しい理解のために全容を把握します。
受容基準を超えたものはリスク低減等の対策が求められますが、その時に何らかの投資が伴うため、投資の承認も何処かで必要になります。それが残留リスクの承認の場と同時である必要はありません。場合によっては「やり過ぎ」になります。
リスクの分布状況。統計データ。図表があれば尚良い。
受容レベルを超えたリスク（資産と管理状況とリスク値）。
受容水準~受容基準の見直し提案。
リスク対応検討対象資産の提案。
残留リスク承認のエビデンスは議事録。どの会議体でも構わないがトップの指示事項も反映させたものが好ましい。
分厚いリスク分析表の表紙にトップの承認印を貰うなどは、承認の形式だけを求めたもので、事務局の工程能力の無さを露呈したものになる。
.*.
そこまでやる必要ないよ。という輩もいます。甘言には注意すべきです。
.*.
2011年11月08日
東芝が開発したクラウド向け暗号化技術の紹介が日経に出ていたが読んでもさっぱり分からない。暗号化してあるものをそのまま更に暗号化できるとあるが、こんなことは以前から出来たはず。何が新しいと言うか、東芝の工夫か分かりたい。
「再暗号化技術」とあるので、このキーワードでいくつか記事を探してみるかな。
「再暗号化技術」
http://www.toshiba-sol.co.jp/sol/cloud/cloud_tech.htm
.*.
「再暗号化技術」とあるので、このキーワードでいくつか記事を探してみるかな。
「再暗号化技術」
http://www.toshiba-sol.co.jp/sol/cloud/cloud_tech.htm
.*.
暗号化通信経路を公開して、多方面からのアタック（盗聴攻撃）を掛けてもらい、安全性の確認を行うもの。情報通信研究機構（あまり聞いたことない）、NTTなどが、米欧の研究グループと協力して、11月中旬から始めるらしい。
マネー関連、医療関連の通信路上のセキュリティは現状では極めて脆弱であるらしいから、早期の実用化が待たれる。
マネー関連、医療関連の通信路上のセキュリティは現状では極めて脆弱であるらしいから、早期の実用化が待たれる。
2011年11月05日
値引きをする審査
審査機関の中には不適切な審査費用を提示するところがあるそうだ。所謂、値引き。審査機関が売り上げ・利益を追求しすぎるのも不健全だが、採算度外視するのも不適切だ。
適切なコスト負担を求めないのは、不適切な審査を誘発する要因になりかねない。
工数の妥当性をJABやJIPDECは煩く言うらしいが、費用そのものもしっかり監視すべきでしょう。不動産業界・建築業界などでは、単価まで把握しているのではないだろうか。全て、オープンにしてはどうだろう。
極端な値引きや不適切な価格競争は第三者認証制度を根っ子から破壊していく懸念があります。
.*.
審査機関の中には不適切な審査費用を提示するところがあるそうだ。所謂、値引き。審査機関が売り上げ・利益を追求しすぎるのも不健全だが、採算度外視するのも不適切だ。
適切なコスト負担を求めないのは、不適切な審査を誘発する要因になりかねない。
工数の妥当性をJABやJIPDECは煩く言うらしいが、費用そのものもしっかり監視すべきでしょう。不動産業界・建築業界などでは、単価まで把握しているのではないだろうか。全て、オープンにしてはどうだろう。
極端な値引きや不適切な価格競争は第三者認証制度を根っ子から破壊していく懸念があります。
.*.
ISO17021
何の規格ですか？
審査機関または審査員に対しての要求事項を纏めたものらしい。コンサルに対する要求事項を纏めたものも在るらしい。本当？
.*.
何の規格ですか？
審査機関または審査員に対しての要求事項を纏めたものらしい。コンサルに対する要求事項を纏めたものも在るらしい。本当？
.*.
情報システム部が適用範囲外。で如何する？
何処の会社も命運は情報システム部が握っていると言っても過言ではない。ところが、情報システム部に”ぴかいち”の人材が配されることは先ず有りません。事業部門とか営業部門とかの花形部門で勤まらなくなった人たちの納まり先という側面が残る。コミュニケーションが不得意な人は物を触っていろということかな。
情報システム部ぐらいストレスの多い部門はない。バックオーダーが積み上がって、いつの間にか全社で一番の金食い部門になる。そして権力まで持つようになっている。会社の中のお役所と警察を一緒にしたような嫌われ部門になっている。態度は横柄で傍若無人。「ISMS？そんなもんやっている暇なんか有りません!」ときっぱり拒否してくる。馬鹿につける薬はありません。
逆もある。率先してISMSに取り組みところもある。情報システム部門トップのマネジメント脳がどうなっているかに左右される。CIOとCISOとかを置く企業はまだ望みはあるが、ただただ忙しいだけの一部門の場合はISMSへの取り組みは先ず期待できない。
.*.
情報システム部門が適用範囲に入らないISMSが出来上がる。
.*.
情報インフラを管理しないある事業部門が適用範囲になる。電子情報をどのように守るかは、責任ある対応は無理。情報システム部というブラックボックスに依存する。資産は理解しても、脅威も脆弱性も理解できない。馬鹿げた構造になるわけだ。
似たようなことが今流行している。クラウド。情報システム部門サービスが外部に行くわけだ。自分たちの情報資産の管理を他人に委ねるのは、適用範囲外の情報システム部に依存するのと同じ構造だ。
経産省のガイドラインはクラウド事業者にもISMS取得を期待していたと思う。
ISMS取得企業が情報システム部門を適用範囲外に置くのは犯罪的？は言い過ぎとしても、経営者の姿勢は非難されてもいいだろう。ISMS取得と相反することをやっているんだから。情報セキュリティマネジメントにもっとも重要な部署を外して情報セキュリティマネジメントをやりますなんて世間をおちょくっている。
.*.
「クラウドサービス利用のための情報セキュリティマネジメントガイドライン」（経産省）を参考に管理していくしかないでしょう。全く馬鹿げたことです。
.*.
何処の会社も命運は情報システム部が握っていると言っても過言ではない。ところが、情報システム部に”ぴかいち”の人材が配されることは先ず有りません。事業部門とか営業部門とかの花形部門で勤まらなくなった人たちの納まり先という側面が残る。コミュニケーションが不得意な人は物を触っていろということかな。
情報システム部ぐらいストレスの多い部門はない。バックオーダーが積み上がって、いつの間にか全社で一番の金食い部門になる。そして権力まで持つようになっている。会社の中のお役所と警察を一緒にしたような嫌われ部門になっている。態度は横柄で傍若無人。「ISMS？そんなもんやっている暇なんか有りません!」ときっぱり拒否してくる。馬鹿につける薬はありません。
逆もある。率先してISMSに取り組みところもある。情報システム部門トップのマネジメント脳がどうなっているかに左右される。CIOとCISOとかを置く企業はまだ望みはあるが、ただただ忙しいだけの一部門の場合はISMSへの取り組みは先ず期待できない。
.*.
情報システム部門が適用範囲に入らないISMSが出来上がる。
.*.
情報インフラを管理しないある事業部門が適用範囲になる。電子情報をどのように守るかは、責任ある対応は無理。情報システム部というブラックボックスに依存する。資産は理解しても、脅威も脆弱性も理解できない。馬鹿げた構造になるわけだ。
似たようなことが今流行している。クラウド。情報システム部門サービスが外部に行くわけだ。自分たちの情報資産の管理を他人に委ねるのは、適用範囲外の情報システム部に依存するのと同じ構造だ。
経産省のガイドラインはクラウド事業者にもISMS取得を期待していたと思う。
ISMS取得企業が情報システム部門を適用範囲外に置くのは犯罪的？は言い過ぎとしても、経営者の姿勢は非難されてもいいだろう。ISMS取得と相反することをやっているんだから。情報セキュリティマネジメントにもっとも重要な部署を外して情報セキュリティマネジメントをやりますなんて世間をおちょくっている。
.*.
「クラウドサービス利用のための情報セキュリティマネジメントガイドライン」（経産省）を参考に管理していくしかないでしょう。全く馬鹿げたことです。
.*.
2011年11月04日
個人情報の保管方法として最低限の管理策は暗号化。万一、流出することがあっても、そのままでは内容が分からないようにしておく。
通常、外部とのやり取りは暗号化しても、社内のサーバー内では利便性を考えて、暗号・パスワードは外しておくものだが、特定のファイルは常時暗号化という施策をとることが求められる。
＜特に注意を要する個人情報＞
クレカ、購買暦、家族情報、パスワード、身体・健康・病歴、借金、犯罪歴、学業成績、宗教・信条
.*.
個人情報以外でも重要なファイルを常時暗号化対象に指定することは有用と思われる。例えば、機密性資産価値を最重要に評価したもの。
.*.
通常、外部とのやり取りは暗号化しても、社内のサーバー内では利便性を考えて、暗号・パスワードは外しておくものだが、特定のファイルは常時暗号化という施策をとることが求められる。
＜特に注意を要する個人情報＞
クレカ、購買暦、家族情報、パスワード、身体・健康・病歴、借金、犯罪歴、学業成績、宗教・信条
.*.
個人情報以外でも重要なファイルを常時暗号化対象に指定することは有用と思われる。例えば、機密性資産価値を最重要に評価したもの。
.*.
要観察から外れたら、そのことは明確に宣言して欲しい。何のフォローもしない審査員（審査機関？）がいるけど、いい加減じゃないか。是正を求めないということと、観察するしないを一緒くたに扱わないで欲しい。本当にどうでもいいことなら最初から何も言ってほしくない。
リスクアセスメントを検証する=リアリティチェックのやり方
リスクアセスメントの基本的な方法論は、(1) CIA喪失による被害額（資産価値）、(2) 脅威（被害を発生させる要因）、(3) 脆弱性（脅威の発生に対する防御能力）をそれぞれレベル分けして、その積を以って(4) リスク値とする。(1)x(2)x(3)=(4) 資産別、CIA別の定量化評価を行うテーブルまたはシートを「リスクアセスメントシート（期待被害額算定表）」として管理することもある。
これは出来るだけ客観的にリスク状況を理解するための方法論であるが、(1)(2)(3)のどの要素として正しく理解することは出来ない。レベルの定義付けも厳密には無理。従ってリスク値もそれなりの曖昧さを伴うものであることは承知しておくべきだ。
＜検証方法＞
先ず、日常の業務の中でセキュリティリスクとして認識している（情報管理に関連して心配、懸念、あるいは不満に感じている）こと/ものを記述してもらう。特に上位職についている人の声を貰う。ISMS委員がインタビューする方法でも良い。
次に、その懸念している状況を、(1)x(2)x(3)=(4)の形式で構造的に理解し、最初に作ったリスクアセスメントシート（(1)x(2)x(3)=(4)）にマッピングしてみる。
これを「リスクアセスメントのリアリティチェック」と称します。
上手く整合していれば結構ハイレベルのリスクアセスが実施できたことになる。箸も棒にも掛からなければ、殆ど意味の無いリスクアセスメントの可能性がある。
.*.
ツールを利用した機械的なリスクアセスメントは殆ど役に立たない。
.*.
リスクアセスメントの基本的な方法論は、(1) CIA喪失による被害額（資産価値）、(2) 脅威（被害を発生させる要因）、(3) 脆弱性（脅威の発生に対する防御能力）をそれぞれレベル分けして、その積を以って(4) リスク値とする。(1)x(2)x(3)=(4) 資産別、CIA別の定量化評価を行うテーブルまたはシートを「リスクアセスメントシート（期待被害額算定表）」として管理することもある。
これは出来るだけ客観的にリスク状況を理解するための方法論であるが、(1)(2)(3)のどの要素として正しく理解することは出来ない。レベルの定義付けも厳密には無理。従ってリスク値もそれなりの曖昧さを伴うものであることは承知しておくべきだ。
＜検証方法＞
先ず、日常の業務の中でセキュリティリスクとして認識している（情報管理に関連して心配、懸念、あるいは不満に感じている）こと/ものを記述してもらう。特に上位職についている人の声を貰う。ISMS委員がインタビューする方法でも良い。
次に、その懸念している状況を、(1)x(2)x(3)=(4)の形式で構造的に理解し、最初に作ったリスクアセスメントシート（(1)x(2)x(3)=(4)）にマッピングしてみる。
これを「リスクアセスメントのリアリティチェック」と称します。
上手く整合していれば結構ハイレベルのリスクアセスが実施できたことになる。箸も棒にも掛からなければ、殆ど意味の無いリスクアセスメントの可能性がある。
.*.
ツールを利用した機械的なリスクアセスメントは殆ど役に立たない。
.*.
2011年11月03日
資産の洗い出しは単純な作業なだけに、直ぐに手抜きを考えてしまう。だからと言って馬鹿丁寧に洗い出し作業をやって、資産数が10万件を超えたりするのも考え物だ。
業務プロセスに基づいて、各プロセスが参照あるいは出力する情報を洗い出すやりかたは、考え方は分かりやすいので、皆さん飛びつくが、業務プロセスを網羅的に洗い出す方法論の裏づけが無いので、結果は惨憺たるもの。
不定期プロセス、例外処理、低頻度プロセスなどは、通常プロセスの10倍も20倍もあると覚悟したほうがいい。コンサルが提示する超シンプルなフロー図で仕事が終わると思ったら、事務局は勤まらない。会社の仕事を全く理解していない証拠。無理です。？
メイン・プロセス、サブ・プロセス、階層構造、ICOM。業務プロセスをどのように表現していくか、それ自体が結構なテーマになってしまいます。
プロセスベースのフロー型の洗い出し手順に加えて、スペースベースのストック型の洗い出し手順は依然として重要。相互チェックの役割を果たすことも出来る。スペースベース洗い出しで難しいのは、住居の住人が特定されているもののほかに、住居の住人が不特定のものがあること。所謂、一時預かりの類です。
フローとストックを考慮した資産の洗い出しは、両方を付き合わせることで精度を高めることが出来ます。片方だけで済ませている洗い出しでは抜け漏れが多く、結局、リスクアセスメントの有効性を維持できません。特にフロー型（プロセスベース）は洗い出された資産が重複するため、識別は慎重を要する。
.*.
情報資産の洗い出しにもフロー＆ストックの発想（方法論）が必要ということです。
.*.
業務プロセスに基づいて、各プロセスが参照あるいは出力する情報を洗い出すやりかたは、考え方は分かりやすいので、皆さん飛びつくが、業務プロセスを網羅的に洗い出す方法論の裏づけが無いので、結果は惨憺たるもの。
不定期プロセス、例外処理、低頻度プロセスなどは、通常プロセスの10倍も20倍もあると覚悟したほうがいい。コンサルが提示する超シンプルなフロー図で仕事が終わると思ったら、事務局は勤まらない。会社の仕事を全く理解していない証拠。無理です。？
メイン・プロセス、サブ・プロセス、階層構造、ICOM。業務プロセスをどのように表現していくか、それ自体が結構なテーマになってしまいます。
プロセスベースのフロー型の洗い出し手順に加えて、スペースベースのストック型の洗い出し手順は依然として重要。相互チェックの役割を果たすことも出来る。スペースベース洗い出しで難しいのは、住居の住人が特定されているもののほかに、住居の住人が不特定のものがあること。所謂、一時預かりの類です。
フローとストックを考慮した資産の洗い出しは、両方を付き合わせることで精度を高めることが出来ます。片方だけで済ませている洗い出しでは抜け漏れが多く、結局、リスクアセスメントの有効性を維持できません。特にフロー型（プロセスベース）は洗い出された資産が重複するため、識別は慎重を要する。
.*.
情報資産の洗い出しにもフロー＆ストックの発想（方法論）が必要ということです。
.*.
2011年11月01日
審査員がやってくる。部門審査だとか。会議室に呼び出される。テーブルの向こう側に審査員は陣取る。脇に事務局員が座る。こちらはまるで被告席。取調べ尋問みたい。ぞろぞろと並んで座る。
とまあ何と言うこと。我らが部門長様は審査員の前に座らない。最初に列の端っこに座ってしまう。うっかりすると向こう側に座りかねない。譲り合いの精神を発揮して審査員の前だけ空席になる。空席になった椅子が外されて、末席指定席の若手が文字通り矢面にすわることに。
馬鹿馬鹿しい。こんな上司連中と誰が真面目に仕事をするものか。
冷や汗をかきながらインタビューに答えていると、末席に逃げた部門長からいきなり叱責が飛んでくる。そういう受け答えでは駄目だと言うのだ。挙句の果てには解説者か評論家みたいに補足説明を始める。ますます馬鹿馬鹿しくなる。
隣の部では、インタビューの受け答えは全て部門長。細かいところの確認だけ担当者に聞いてきたとか。上司も選びたいものだ。
.*.
何処にでもよくある話です。
.*.
コンサルの席は一番末席、あるいはテーブルには付かないで壁際の補助椅子にずっと離れて座るので苦労はありません。審査への干渉をしないことを明確にしています。
中にはテーブルに座ってあたかも社員のように受け答えをしているコンサルの話も聞きますが、論外中の論外。コンサルとして失敗したことを露呈しているだけですから、さっさと変更すべきですね。
.*.
とまあ何と言うこと。我らが部門長様は審査員の前に座らない。最初に列の端っこに座ってしまう。うっかりすると向こう側に座りかねない。譲り合いの精神を発揮して審査員の前だけ空席になる。空席になった椅子が外されて、末席指定席の若手が文字通り矢面にすわることに。
馬鹿馬鹿しい。こんな上司連中と誰が真面目に仕事をするものか。
冷や汗をかきながらインタビューに答えていると、末席に逃げた部門長からいきなり叱責が飛んでくる。そういう受け答えでは駄目だと言うのだ。挙句の果てには解説者か評論家みたいに補足説明を始める。ますます馬鹿馬鹿しくなる。
隣の部では、インタビューの受け答えは全て部門長。細かいところの確認だけ担当者に聞いてきたとか。上司も選びたいものだ。
.*.
何処にでもよくある話です。
.*.
コンサルの席は一番末席、あるいはテーブルには付かないで壁際の補助椅子にずっと離れて座るので苦労はありません。審査への干渉をしないことを明確にしています。
中にはテーブルに座ってあたかも社員のように受け答えをしているコンサルの話も聞きますが、論外中の論外。コンサルとして失敗したことを露呈しているだけですから、さっさと変更すべきですね。
.*.
2011年10月29日
問われるBCMSの有効性？BCMとBCPの違い
M（エム）とP（ピー）の違い。マネジメントとプランの違い。全社は言わば手順であり後者は手順の生成物。
TQMとTQCの関係にも似ている。TQCは何もマネジメントの概念が無かった訳ではないが現実的なアプローチの積み重ねで作り上げた全体で、全体の体系化への関心は薄かった。そこを英国人に見抜かれて、逆利用されてしまったのが第三者認証制度のQMS(ISO9000シリーズ)だから日本人にとっては複雑だ。
事業継続についても、代替案とか復旧案とか、各テーマについての方法論は検討されていたが、これについても第三者認証制度の枠組みでリリースしてしまった。単なる規範にとどめなかったことで、反対意見も少なくなかったようです。BCMS（ISO25999?)。
事業は1社で全てのプロセスを実現できる訳でないから、必ず企業連携になる。その中には重要なものも含まれるが、その相手先がダウンすると一緒にダウンするのでは困る。パートナーとして十分な資質を持っているかを、二者監査でなく第三者監査で担保しようと言うもの。
しかし、事業継続性の担保を第三者にゆだねることが出来るか。審査機関はあくまで規格適合性という枠組みだけでの物言いしかしない。事業継続に関する責任は何も負わない。それでいて混同しやすい認証を付与する。事業継続という問題と第三者認証制度がそぐわない理由である。他の規格もスキーム的には同じだが、問題の質・大きさをもっと理解すべきである。
バリューチェーンを組む時に、相手がBCMS認証を受けているとどうなるか。安心してしまいがちだ。より徹底して文書と現場を確認すべきだ。それに耐えれる準備をしているくらいに理解したほうが良い。
.*.
BCMSの認証取得数が伸びない理由は、そもそもBCMSの有効性に疑問が残るから。注文が欲しい立場ではこれを取得したら商売が増えるともくろむのだろうか？注文を出す側はこの認証を持っていれば安心できると考えるのだろうか？
バリューチェーンが地球規模のときに、優先順位もそれぞれ異なる中で、どのようなマネジメント求められるか。本当の答えが何か分からない中での第三者認証制度としてのBCMSのリリースは多分に認証ビジネスに配慮したものといえなくもない？弊害が出なければ良いですね。
.*.
規範規格の参考文書として眺めてもらって、提携先・取引先との交渉で留意する利用の仕方が現実的かもしれない。
.*.
M（エム）とP（ピー）の違い。マネジメントとプランの違い。全社は言わば手順であり後者は手順の生成物。
TQMとTQCの関係にも似ている。TQCは何もマネジメントの概念が無かった訳ではないが現実的なアプローチの積み重ねで作り上げた全体で、全体の体系化への関心は薄かった。そこを英国人に見抜かれて、逆利用されてしまったのが第三者認証制度のQMS(ISO9000シリーズ)だから日本人にとっては複雑だ。
事業継続についても、代替案とか復旧案とか、各テーマについての方法論は検討されていたが、これについても第三者認証制度の枠組みでリリースしてしまった。単なる規範にとどめなかったことで、反対意見も少なくなかったようです。BCMS（ISO25999?)。
事業は1社で全てのプロセスを実現できる訳でないから、必ず企業連携になる。その中には重要なものも含まれるが、その相手先がダウンすると一緒にダウンするのでは困る。パートナーとして十分な資質を持っているかを、二者監査でなく第三者監査で担保しようと言うもの。
しかし、事業継続性の担保を第三者にゆだねることが出来るか。審査機関はあくまで規格適合性という枠組みだけでの物言いしかしない。事業継続に関する責任は何も負わない。それでいて混同しやすい認証を付与する。事業継続という問題と第三者認証制度がそぐわない理由である。他の規格もスキーム的には同じだが、問題の質・大きさをもっと理解すべきである。
バリューチェーンを組む時に、相手がBCMS認証を受けているとどうなるか。安心してしまいがちだ。より徹底して文書と現場を確認すべきだ。それに耐えれる準備をしているくらいに理解したほうが良い。
.*.
BCMSの認証取得数が伸びない理由は、そもそもBCMSの有効性に疑問が残るから。注文が欲しい立場ではこれを取得したら商売が増えるともくろむのだろうか？注文を出す側はこの認証を持っていれば安心できると考えるのだろうか？
バリューチェーンが地球規模のときに、優先順位もそれぞれ異なる中で、どのようなマネジメント求められるか。本当の答えが何か分からない中での第三者認証制度としてのBCMSのリリースは多分に認証ビジネスに配慮したものといえなくもない？弊害が出なければ良いですね。
.*.
規範規格の参考文書として眺めてもらって、提携先・取引先との交渉で留意する利用の仕方が現実的かもしれない。
.*.
2011年10月28日
日本規格協会
ＪＡＴＥ（ジェート）
真面目・地味・信頼。
審査員資格のケアをする機能組織JRCAを中に持っている。
ＪＡＴＥ（ジェート）
真面目・地味・信頼。
審査員資格のケアをする機能組織JRCAを中に持っている。
