ランサムウェア ransomware

ランサムウェア ransomware

「ransom」は身代金身、請け金、買い戻し金、賠償金のこと。 ransomwareはパソコンを感染（内容を勝手に暗号化するなど）させ、その復旧（鍵入手など）のためには費用を請求するソフトウエアまたは手口。具体的にはどのようにするのか不明。決済に絡めば身元がばれてしまうのではないか。オレオレ詐欺のように一時的な口座を持つのか？

メールであれ、WEBサイトであれ、身に覚えの無いボタンやアドレスは不用意なクリックしないこと。
日ごろのバックアップも大事。金を払っても一度の支払いで収まる保証は無い。

最近はあまり話題にならない。いたずら以上（現金をせしめること）はやはり難しいのだろう！？

.*.

ISO 27002 :2013関連情報

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以外とやった方が紛れが無いということかな。誰にとって重要な変更なんだろう？。

.*.

何処まで広げるの？ISO27000シリーズ

何処まで広げるの？ISO27000シリーズ

気が付いたらバラバラ中途半端な規格が列を組んでいた。ガイドラインだから実害は無いのでしょうが、参照規格の間は、ともかく、眺めるだけだが、引用規格、適用規格にしてしまうと結構大変なのでは。

• ISO27000：<Terminology>シリーズ全体の概要と用語解説。索引＋辞書？既に発行？
• ISO27001：<Requirement>これが要求規格。BS7799を踏まえて2005年に規格化された。JIS版は翌年2006年リリース。大幅な見直し版が2013年後半にリリースする見込み。JIS版は2014年か。
• ISO27002:<Guideline>実践規格。規範規格。これが所謂管理策の解説書。27001同様大幅見直し中。リリースも同時期を予定。2013年後半。
• ISO27003：<Guideline>実施規格？あまり話題にならない。
• ISO27004：<Guideline>有効性評価に関するガイドライン。ボリュームはあるが内容はない。TQCをやってきた普通の日本企業ではこのガイドは物足りないでしょう。
• ISO27005：<Guideline>リスク管理とあるが31000との関係は？良く分かりません。
• ISO27006：<Requirement>これも要求規格。要求する相手は審査機関・認定機関。審査員も結局この要求を受けることになる。
• ISO27007：<Guideline>審査のための規格。これも案外話題にならない。
• ISO27008：<Guideline>審査員のための規格。残念。これすらも話題にならない。
• ISO27010：<Sector-Specific Guideline>Inter Sector Comm
• ISO27011：<Sector-Specific Guideline>Telecom ISMS　通信事業者向け？
• ISO27013：<Sector-Specific Guideline>ISO20000とISO27001との整合化ガイド？
• ISO27014：<Sector-Specific Guideline>セキュリティガバナンス。何のこと？
• ISO27015：<Sector-Specific Guideline>金融・保険業界向けガイドライン？
• ISO27016：<Sector-Specific Guideline>ISM Economics?さっぱり分からない。
• ISO27017：<Sector-Specific Guideline>クラウドコンピューティング。クラウド事業者向け？クラウド利用者向け？

.*.

世の中には規格を生業（なりわい）とする人たちが結構居るんだなと思う。

.*.

ISMS推進体制における内部監査責任者の位置付け

ISMS推進体制における内部監査責任者の位置付け

まあ、まあ、このタイトルを見れば誰でもははあと来るものです。分かっていてなかなかできないことの一つ。

経営者の意を受けてIS管理責任者が推進の全権を持つ。内部監査もISMS推進の一環だから内部監査責任者はIS管理責任者の下に置く。これじゃ駄目なんですね。

IS管理責任者が正しく事を運んでいるかどうかを経営者に成り代わってチェックするのが内部監査責任者の役割。レポートは直接経営者に行くのです。

IS管理責任者と内部監査責任者は同格対等なんですね。どちらもレポートを経営者に上げる。

.*.

クラウド利用時のISMS問題？

クラウド利用時のISMS問題？

初期の頃は日本の法律で裁けないのが問題でした。クラウドは海外ばかりでしたから。今は国内にクラウドセンターが出来て解消しました。

次はサーバーが特定できないことを問題にしていました。共同利用であることも問題とされています。

クラウドセンター施設の維持も問題にされています。移設、建て替え。同じベンダーでも心配ですが、違うベンダーへ移る場合に何が課題になるのか。

何がベンダーの資産で何が自分たちの資産か、切り分けは上手くできるのか。なかなか現実にならないと課題が見えてこないものです。

.*.

ベンダーにISMSの取得を条件付けるのは当然でしょうね。自分たちが中に入れない分、第三者に中に入ってもらってチェックして欲しい。それも出来れば3年ごとに審査機関を変えてもらう。迎合的審査・癒着型審査の懸念を払拭させたい。

.*.

ISMSの有効性

ISMSの有効性

こんな簡単なテーマはありませんね。

リスク値の総和の最小化。うん？これは失敗。

無理でも金額ベースにすることです。年間期待損失。

経営・事業への貢献度で見る発想もありますが、これは駄目。続かない。一貫性が維持できない。方向まで変わる。

.*.

でもまあ実際にやっている話は聞いたことがありません。

ISMS認証取得でなんとなく営業がやりやすくなった。ぐらいでお茶を濁すのが大半。分かりやすい発想ですが、本末転倒というか問題が摩り替わっていますよ。

.*.


あっと、結果指標は駄目ですよ。事件とか事故の件数。その被害額。このデータは期待損失の検証に使うものでしょうか。そのことを発展させることも出来そうです。予測と実測の乖離の原因を探ることも大事なことです。

（A)実際の投資額、（B)実際の被害額、（C)期待損失（保有リスク・保有潜在損失）。

問い：この３項目の関係を述べよ。好ましい関係と好ましくない関係について論ぜよ！

.*.

KPIの要件

KPIの要件

計測可能ということとKPIとして適切かどうかは別問題。管理策の有効性評価はまあどうってこと無いのですが、本気でやるとなると一つも答えが見つからない。体系的方法論が何処にも提示されていないからでしょうか。

シンプルで客観的で長期的に継続できること。それって何ですか？

いつもやっていること、これまでもやってきたこと、これからもやっていくこと。出来る限りそういうものの中から選択することですね。

もちろん、生産的指標です。結果指標を選択してはいけない。また言えばポジティブ指標はOK、ネガティブ指標はNG、足し算はOK,、引き算はNG。そんな感じ。

教育･周知は必須必達だけど、管理の主役には向かない？　だからKPIには向かない。

全ての管理策（最大133項目）に対して有効性評価は要求されていないと主張する輩がいます。その主張が誰の何の役に立つんでしょうか？　かたや地道に133項目のKPIを作った裏方が居ます。賞賛を贈ります。自分で全対応を放棄するのは勝手ですが正当化まで意図するのは邪悪な発想で軽蔑の対象です。出来ないこととやらないでいいんだと主張するのは全く別です。

取り敢えずは管理目的毎にKPIを作ることでもいいでしょう。

.*.

何の手順ですか？リスクアセスメントのヒント

何の手順ですか？リスクアセスメントのヒント

1. 検討対象の洗い出し。何の検討かというとリスク管理の検討。と言うことは管理対象の洗い出しになるかな。どういう粒の大きさで捉えるか。これも難しい。普通は管理台帳になっているのでわざわざ洗い出す必要はない。問題はこれまで台帳管理してこなかったもの。これまで台帳管理されてきたものも十分かどうか再検討したい。まあ、何が正解か分からないからやり直す覚悟で簡単に済ましてみよう。
2. 管理対象の管理基準と基準がずれた時のインパクト。どうなると困るのか。ISMSならセキュリティ障害。普通で言えばリスク事象でしょうか。脅威と脆弱性との合算（足し算じゃないよ！）で発生する困った状況。ここも行ったり来たりの前提で軽く。
3. 困らないようにする方法の検討。１つ１つのリスク事象について検討を加える。例えば落下事故を想定する場合、物が落ちないようにする。落ちても困らないように下を柔らかくする。ものを丈夫に作って置く。物を使わないで済ます。置き場所を変える。
4. 「管理対象」（普通は資産・資源）→「リスク事象」（複数あります）→「対策案」（1つのリスク事象に対して複数あります）。これを網羅的にリストしておきます。
5. 実施済みの対策案、未実施で実施可能な対策案、実施不可能な対策案に仕分けします。対策案の有効性評価も行います。例えばトータルの有効性が95%に達したら十分とします。しかし何を持って95%なんて判断が出来るでしょう？ここは「筈｣「看做し」の出番。システム化された、機械仕掛けの施策は有効性（50～90%）、人による対策は有効性（30～70%）と置き、独立した複数の管理策の効果はその積とする。などでしょうか。

クライアントがクレームする本当の理由？

クライアントがクレームする本当の理由？

期待値とずれたら相手が誰であれクレームするのがクライアント。費用負担者。お金を出す人は強い？

相手が分かっていても説明するのがコンサル、自分が分かっていても質問するのが審査員。どちらも分かっていない前提で隙間を埋めようとする基本的な行為。

クライアントは分かっていることを説明されて不満を持ち、分かっている筈のことを質問されて不満を持つ。

どうしてこんな些細なことがクレームの理由になるんでしょう？

本当の理由は別にあると考えるべきですね。クライアントはクレームする時に本当の理由はなかなか言わない。理由を知られることで自分の人間性の嫌な部分が顔を出すのを避けたい？

大人の言い方もあります。今度は相手を傷つけることを心配して別の理由を言うケースです。ですが、それすら背後に何があるのか？

直接何らかの被害が出た訳でもないのに、そもそもISMSで無理難題をぶつけられない限り被害はでないものですが、クレームになるのは何故でしょう？

面子ですか？自分の思惑を外す展開になった時？

疑心暗鬼！

自分がベストエフォートサービスを受けていないと感じた時、そのことに疑いを持った時、心の中の鬼は目覚めるのです。

コンサル同士のやり取り（パワーゲーム）、審査員同士のやりとり（パワーゲーム）、はたまたコンサルと審査員とのやり取り（パワーゲーム）を見て聞いてクライアントは疑いの気持ちを目覚めさせる。当人たちはパワーゲームのつもりは無くてもクライアントにはその部分だけが理解できるのでパワーゲームとして理解するのです。

コンサルも審査員も謂わば業界人です。業界人がクライアントの前でいきなりお互いを否定する行為は墓穴を掘るのと同じこと。勝ち負けはありません。負け負けです。訂正が必要な場合は自己否定で入らなければいけません。

どこそこのコンサルや審査のやり方を否定したり、無責任に批評するのは、何れ話は伝わりますから極めて非生産的・非建設的な行為です。もちろん、最悪はクライアントの目の前で他者否定を始めることです。

目の前で始まったパワーゲームを見てクライアントの集中力は一気に切れます。疑心暗鬼をはじめます。最後は自己嫌悪に陥る。

背景にはクライアントの不慣れがあります。初回審査の時、クライアントのISMSの担当が替わった時。担当するコンサルや審査員が替わった時は、特に業界人は意識して発現する必要があります。

既に信頼関係が築かれている場合はこの手のクレームは発生しません。不明なところは適切に質疑応答されて問題が先送りされたり蓄積されたりしないからですね。

.*.

パワーゲーム以外ではまさに基本事項の基本、コミュニケーション問題があります。クライアントにもあり得る問題です。窓口を通して話を進めているつもりで居たのに、相手組織に十分伝わっていなかったケース。問い合わせても無視されたような状況になるケース。

自分が軽く見られたということで、パワーゲームの場合よりも深刻な相手不信に陥ります。ビジネスマンの基本部分ですから、当然です。

.*.

ミスが多いのも行けません。上記の2点ほど深刻ではありませんが、基本能力に対する疑いを招きますから、何かと合わさった時にはマイナスのお手伝いをすることになります。

.*.

情報資産の定義も難しいものですね

情報資産の定義も難しいものですね

情報コンテンツ、意味、メッセージ。これが所謂、情報の本旨に相当する。これらを容易に導くことが出来る整理されたデータ類も情報に準じたものになるであろうと。

情報を保管する道具類も情報資産に含める。

情報利用のために、人間の五感に訴える道具立ても情報資産。ディスプレィ。スピーカー。最も単独では意味が無くてシステムとしての存在だろうが。システムが複合的、広域的であればそのためのネットワークや施設インフラも情報資産。そうなるとCVCFとか自家発まで入る。

インフラがサービスとして外部から提供される場合はそのサービスも情報資産。それにも適切な維持活動が求められる筈だ。

オフィス環境、サイト環境まで、外部との境界に対する手当てを想定すれば情報資産に入る？

そこに超機密情報があるなら、情報の存在や所在（サイト）すら情報資産に入る？

実際、データセンターの中にはテロのターゲットになるのを恐れて、存在すら隠そうとしているものがあるようだ。

.*.

整理すると、

1. 先ず、本質的な情報（メッセージ、意味、情報の本旨）。仮にコンテンツとする。
2. コンテンツの存在を成立させる入れ物。情報コンテンツを記録したメディア。記憶媒体・記録媒体。紙とか、光学ドライブディスク、外付けHDD。USBメモリーなど。しかし、殆どはパソコンやサーバー上にあるでしょう。可搬メディア、固定メディアに分類できるが、クラウド上に据えたものは別の分類がいいだろう。
3. 次は処理系。一時的に情報を扱う道具立て。コンピュータシステム、ネットワークシステム。
4. 最後は施設系。処理系、メディアの保護あるいは利用に供する施設。適用範囲にある施設すべてが納まることになるでしょう。

上記の分類が成立すると、概ね、管理策も整理される。

.*.

大笑いのケース（笑うのは誰？）は、分類表と資産台帳の混同です。分類表があれば、脅威･脆弱性・管理策は類似性を持つのは間違いないが、資産台帳は一つ一つそれを確認するものだということ。個別の状況を踏まえて適切な管理策が当たるようにしなければいけない。

.*.

脅威は何に取り付くのか？

脅威は何に取り付くのか？

脅威とは何であるかを考えると、これはなかなか難しい議論であることに気がつく。変化することも変化しないことも脅威になりうる。人（組織）にとって都合が悪いことは全部脅威だから、しかも結果論で以って過ぎてしまった事象をあれは脅威だったとやるので始末が悪い。また時間的スパンを変えると脅威であったり無かったりするとますます始末が悪い。人（組織）が変われば脅威も変わる。絶対的脅威なんて存在できるのかどうか怪しい。他人の不幸は自分の幸福？でも無いでしょうが、誰かが困っていればそこにはビジネスチャンスがある訳で脅威はチャンスにも成り得るかもしれない。

どうやら脅威は「人」に取り付くようです。「人」の都合に悪いこと、あるいは「人」の目的に取り付く不都合なことが脅威。

ところで、ISMSでは情報資産に対する脅威を洗い出すことになっています。が、資産を見ていきなり脅威を洗うことは出来ないのはこういった事情なんでしょう。

資産もまた人のご都合を達成するために存在するので、人の都合が資産のあるべき状態を決定することになっている筈です。

なんと言うことはないですね。人の都合や目的がプロセスを作り資源を配置し仕事をすることに繋がるのは只の常識？。

目的達成のための業務プロセスが前提とする情報資産の状態を脅かすものが脅威。当該業務プロセスで、情報資産のCIAの側面でどのようでなければいけないかを知ることが先決です。でもこれって情報資産の価値を調べる作業の中に含まれているはずですね。

手順で考えると、

組織は組織目標達成のためにプロセス（ビジネスモデル）を決定し資源を配置する。資源の一部である情報資産もプロセス遂行要件を達成できるレベルで維持される。遂行要件を達成できないときのプロセスインパクト（ビジネスインパクト）が資産価値であり、遂行要件達成を脅かすものが脅威である。

目的を書いて、次にプロセスを書いて、次に資源を書いて、資源のあるべき状態を書く。次に、資源のあるべき状態に対する問題事象（広義の脅威）を書く。

.*.

ここで、脅威は脆弱性の側面を併せ持つことにも留意することが必要です。脅威と脆弱性も相対的な関係があって明確な線引きは容易でありません。ですから上の説明の脅威は広義の脅威（脅威＋脆弱性）と考えておいた方が収まりは良さそうです。規格はセキュリティ障害として括っている。（4.2.1e)2)）

脅威と脆弱性の引き離しは、よく言われる「脅威はコントロールできないが脆弱性はコントロールできる」という言葉に象徴されることが一つの発想になります。盗難というセキュリティ障害（情報の紛失あるいは漏洩）において、泥棒の存在には手を打てないが鍵の掛け忘れには手を打てるとやるわけです。

ところがメールの誤送信（情報漏えいリスク）はどうでしょう。確認洩れ、勘違い、うっかりクリックなど。脅威が人の内面に潜むケース。ヒューマンエラーとする部分。どれだけ教育・周知を繰り返して一定の比率以下には下がりません。コントロール不可？

ヒューマンエラーも脅威として認識し、対策は教育周知ですますのは、50点です。教育周知では収まらないからわざわざヒューマンエラーを脅威としているのですから、例えばプロセスの欠陥と捉えて脆弱性として理解しなければいけません。

.*.

ISMSでマインドマップ(Mind Map)を使うなんて変な気がするが？

ISMSでマインドマップ(Mind Map)を使うなんて変な気がするが？

一方ではISMSが教育システムであることを証明しているような気もする。最もマインドマップのことも理解できているわけではないので、あまり意味のあるコメントではない。

マインドマップは学生の間で流行っていた問題整理術。何処かの番組で紹介されていたように思う。昔の「KJ法」ブレーンストーミングと「魚の骨」分析手法を組み合わせたような方法論。欠点は両手法と同様に、-答えはいくつもあって正解は分からない-と言うことかな。同じメンバー同じテーマでやっても違ったものが出てくる。

「何が情報資産か？」「情報資産とは何か？」

確かにこの問いに答えるのは難しそうだ。「情報とは何か？」と今さら真顔で質問されるとうっかり答えることも出来ない。

.*.

マインドマップは方法論が確立する前の業務領域での最後の駆け込み寺。大事なことは見える化による合議制ということ。そこに表現されるもの合理性のレベルは実はどうでもいいこと。そのメンバーの質で決まるので誰も文句は言えない。

良く見えないもの、概念的なもの、抽象的なものを議論する時、分析する時、あるいは洗い出す時に有効な方法論として捉えておく。前例、経験がない時にも、利用できる。勿論、前例、経験があっても整理・分析するとなると難しいので有効な方法論として利用できそうだ。

マインドマップによる見える化は複数の人の間の理解を助けるし、自分一人でも時間差を置いて眺めることで理解を深めることが出来る利点を持つ。

.*.

方法論が確立したらそれに従うことも大事。

変革を意図したらマインドマップ利用も考慮する。

そういうスタンスでしょうか？

.*.

27001:2013 10. Improvement

Improvement

1.　不適合と是正処置
2.　継続的改善

予防処置が消えている。予防処置の項目で単独に活動している実態が殆ど無いこと、実際の予防処置は、リスクアセスメントとか事業継続管理におけるリスクケース分析の中で実施されていることを、踏まえれば当然かもしれない。

.*.

不適合というのが面白い。

不適合を殆ど出さないのが自慢の審査機関はどうするんだろうね。性根を入れ替えるかな？。クライアントを甘やかしすぎた審査機関は少しずつ論理破綻をきたすかな。口先で誤魔化すかな。

是正の要因は不適合に限るのか？限らないのか？。適合なのに是正することはあるのか？。禅問答だな。不適合の代わりに観察事項しか出さない審査機関があるが、そこでは観察事項を見て是正処置をやることになる。スキーム放棄だな。システム改善に全く貢献しない審査を延々とやっているのだから犯罪的かも。

.*.

しかし、日本的価値観で捉えるとやはり難しい。不適合というのは水準に達していないこと。常識的にやるべきことは全てやっていても事故事象はおきるものであるから、更なる改善を求める場合は「不適合に対する是正」という言い方・捕らえ方はしない。一生懸命なんだから咎めるような言い方は避けたい、と。

ここで「日本的」というのは間違いの元。ここで必要なのは水準、即ちあるべき姿を静的に理解するか動的に理解するかの違いです。何か事故事象が発生した瞬間、有るべき姿そのものが見直されることになる。其の新しい水準に対して不足分は是正処置（狭義）として取り組む必要がある。講義ではあるべき水準の見極めも含むことになるだろう。

.*.

27001:2013 9. Performance Evaluation

Performance Evaluation

普通に訳すと達成度評価。有効性評価が使われるかも。

1.　監視、計測、分析及び評価
2.　内部監査
3.　マネジメントレビュー

マネジメントレビューは経営者自らが評価を行う。

内部監査は経営者から委託された独立した組織が評価を行う。

監視計測分析評価は運用者が運用の一環として行う（適切に運用するためのフィードバック回路）。組織の機能設計の観点から理解すればISMS事務局の仕事になる。

27001:2013 8.Operation

Operation

1.　運用計画と管理：

何処から何処までが運用(Operation)なのかな。日常管理的な部分と、年間の手順、イベントまでを含むのでしょうね。

27001:2013 7. Support

Support

1.　資源
2.　能力：能力または資質
3.　感知：気付いてあげることもサポート？。
4.　コミュニケーション：語彙が広がって訳せないかも。
5.　文書化情報：所謂形式値
5.1.　一般要求
5.2.　作成・更新
5.3.　文書化情報の管理

改訂版では「文書と記録」の形をやめる。両者に本質的な違いを見つけることは困難だから。

27001:2013 6. Planning

Planning

1.　リスクと機会の明確化：
2.　情報セキュリティの目的と目的達成のための計画：

資産の洗い出しからリスク評価までの一連の手順を踏まえてリスクを明確にすることは従来どおりとして、機会(Opportunities)の方は分かり難い。単純に改善機会と捕らえることにするかな。

27001:2013 5. Leadership

Leadership

経営者の責任に相当するかな。

1.　基本要求
2.　経営者の責任
3.　方針：基本方針のこと？
4.　組織の役割、責任、権限

27001:2013 4. Context Of The Organization

Context Of The Organization

従来、4.2.1a)とした部分かな？。適用範囲の理解あるいは記述の重要性を認識して大きな章立てにしたのだろうか。

「組織の枠組みと適用範囲」ぐらいの理解で如何ですか。

1.　組織概要と組織の関係性の理解：

2．関連団体の要求と期待の理解：利害関係者の要求と期待でしょうね。

3.　マネジメントシステムの適用範囲の明確化：従来からの適用範囲。

4.　情報セキュリティマネジメントシステム：推進または管理のための組織。ISMS委員会など。

ISO/IEC 27001の改定まで後2年？

ISO/IEC 27001の改定まで後2年？

改定の話は少しずつ進んでいるようだ。大きく内容が変わるものではないが、今までの規格にあった分かり難さを幾分解消するものになるような気がする。但し、構造は大幅に変わるから、規格に合わせて文書を組み上げてきた組織では、過渡期は大変な思いをするだろう。

加えて、27000シリーズが広がっていくので付いて行くのも容易でない。

そうは言っても、要求規格は27001だけで、残りは全てガイドラインだからその点はISMSに携わる人には助かるというか、優先順位を付けて作業にかかれるかも。一番誰もが気にする27001の改定はWEBを探してもこれだと言うものにお目にかかれない。

今のところは2013年の最終リリースが見込まれているようだ。「ISO 27001:2013」

断片的に飛び交う情報だけでも分かる範囲で並べれば何か見えるかもしれない。

.*.

章立てが変わる。下は適当に拾っているので間違っていると思うが、継続的に眺めて行きたい。

1.　Introduction
2.　Normative References
3.　Terms and Definitions
4.　Context Of The Organization
5.　Leadership
6.　Planning
7.　Support
8.　Operation
9.　Performance Evaluation
10.　Improvement

.*.

ISO27001:2013リリースの目的？

1. 他の9規格とのハーモナイズ。9000, 14000, 20000など。用語の整合化。ここにもっとも時間が割かれたようだ。それは当然でしょう。考え方の違いなど背景にあるもののギャップが埋まらないと言葉は正されない。
2. 章立ての変更
3. 章立ては変わるが内容は80％以上は現行のものと同じらしい。リスクアセスメントは殆ど同じらしい。と言うことは詳細リスクアセスメントとする現行で行くんだろう。誤魔化しのアセスメントで済ますコンサルはそろそろやめては如何かな。
4. リスク対応はISO31000との調整が図れる。ISO31000はリスク管理に関する規範規格かな。
5. 適用宣言書(Statement Of Applicability)がドロップってどういうことだろう。そういう固定的な文書を要求することは止めるということかな。しかし相互参照と整合化は要求されるらしい。と言うことは適用宣言書と言う名前はつけなくても良いが、組織が用意した（用意する）各施策と付属書の管理策との連関は明確であることが要求されるようだ。まあ、現物を見ないと分かりませんが。
6. PDCA(Plan-Do-Check-Action)モデルもドロップする。規格の冒頭に入っている図がなくなるということ。PDCAという言い方もやめるのか。継続的改善は依然要求されるが、改善プロセスを一律に決める必要は無いだろうと言うことでしょう。PDCAも大きな回り方と小さい回り方が交錯するので理念としては理解できても何処まで細分化してもキリが無いものだ。ついでに加えるなら、プランとアクションの部分は重なるので継続的に見る場合はPDCAとすることは返って難しくなるものだ。
7. 外部委託に関するセクションが新たに設定されると言う情報もサイト上にあるがはっきりしない。委託してもISMSの責任を回避できるものではないと言う主旨のものか。

.*.

業務委託先に情報資産を貸与したら？

業務委託先に情報資産を貸与したら?

委託終了時は如何するのですか？

返却、削除、廃棄など決めてあるのでしょうか？

そもそもどういう情報を渡しているか記録がありますか？

それぞれの始末に対してどのような証跡を求めるのでしょうか？

殆どのケースで、ノーコンです。管理箒状態。

.*.

翻って、委託先でなく社内の情報誌散逸いてはどうですか？

どういう情報資産を保有しているか把握していますか？

保管期限がきたらどのように始末するか決めていますか？

始末に対して証跡は何か残していますか？

社内で出来ないことを委託先に求めても方法論がないから結局は出来ないのだ。

.*.

情報資産台帳にヒストリーが刻めるようになっていますか？管理の履歴がみれるか？

毎年、その瞬間のスナップショット。

何が無くなって何が増えたのかすら分からない。

.*.

事業継続管理におけるグッドポイントって何ですか？

事業継続管理におけるグッドポイントって何ですか？

規格どおりにやるとグッドポイントって変じゃないですか。規格どおりにやっている組織が少ないのですか。好きじゃないんだグッドポイントって。お前に言われたくない。何ですか、規格適合性にもレベルがあるんですか。もしあるなら示して欲しいね。そうしたら達成度評価が出来る。気分でグッドポイントなんて言わないで欲しい。

.*.

訓練及び実地を通してPDCAが回って継続的に改善されたらグッドポイントでもいいかな。去年と同じ今年かやらない、毎年やることが変わる、そういう手合いが多い中では当然かもしれない。

.*.

ポイント制にしてみましょう。

1. 事業継続やりますと何処かに書いてあれば1点。
2. 事業継続管理の担当者や体制を決めていれば1点。
3. リスクケーススタディがあれば1点。
4. BCP策定対象を決めていれば1点。
5. BCPが策定されていたら1点。
6. レビューがされていれば1点。
7. BCPのサブセットでも訓練していたら1点。
8. フルセットなら更に1点。
9. 訓練の目標と実績が記録されていたら1点。
10. 課題が抽出されていたら1点。
11. トップマネジメントに報告されていたら1点。
12. 課題に基づいてBCPの見直しがあれば1点。
13. 見直し結果がリスクアセスメントにも反映されていたら1点。
14. BCPのケースが昨年より増えていたら1点。
15. 全社のリスク管理体制の中に位置づいていたら1点。
16. ビジネスパートナーや地域と一緒にやっていたら1点。

書き出すとキリが無い。10点以下でグッドポイントは有り得ないでしょう？

.*.

バックアップ・リストアはセットの管理策です

バックアップ・リストアはセットの管理策です

リストアの保証が無いバックアップには何の意味もない。経費の無駄でしかない。

リストアは怖くて出来ない？

そんなバックアップは止めなさい。年に1～2回はリストアを訓練しなさい。もしくは訓練でなく、バックアップ管理手順の中にリストアを入れる工夫。

バックアップシステムも同様。待機系を動かしたのは導入時に1回だけでは馬鹿と言われる。懲戒解雇でしょう。奇数月はA系、偶数月はB系などとする利用もある。毎月訓練しているのだから。

共有キャビネの鍵管理

共有キャビネの鍵管理

施錠管理するキャビネットがあって、その鍵を利用者全員に配布しておくことの是非。

物がキャビネットとすると、数人（２～３人）のレベルなら違和感が無い。10人を超えたらクレージーな感じだ。5～6人でも普通ではない。

普通の施錠管理はと言えば、誰かが朝開いて、誰かが夕方閉めれば済むこと。機密が高い場合は、誰かは管理職、そうでなければ事務補助の人かな。

鍵を利用した記録を求める審査員が居るらしい。

どういう意味があるんだろう。中の物（文書類、メディア類）が紛失していたらトレースできるだろうか。どうしても記録にこだわる場合は、利用目的（アクセスした情報と用途）も記録しないと意味が無いかな。鍵を各担当に持たせたら、記録をスキップされたらそれまでです。鍵の管理者を別に定めて、記録をとれば一定のトレーサビリティは確保できる。

外部に提出する文書に会社名を入れていない

外部に提出する文書に会社名を入れていない

よくある話。部門名は入れて会社名は入れない。表紙が煩くなるから。封筒とかにも社名はある。

でも文書が一人歩きをすると著作物に対する責任、あるいは権利の問題が出ないとも限らない。しっかり社名も入れておきましょう。

まあ、部署名が入っていれば内容も分かっているのだから、社名は分かるね。大した話ではない。

ソフトウエアライセンス管理台帳の作り方

ソフトウエアライセンス管理台帳の作り方

コンサル先で時々見かける台帳の一つにソフトウエアライセンス管理台帳があります。名称はクライアント様それぞれです。

内容は、買ったライセンス10本として、その10本のライセンスがそれぞれ何処に配布されているかを表にしたものです。配布先としては、部署命であったり、担当者名であったり、パソコン名であったりする訳ですが、これは正しい利用者は誰かをを示したものに過ぎません。

ライセンスを管理しているには違いありませんが、この内容では、コンプライアンス（法令順守）の観点からは不十分です。

「全てのパソコン、サーバー上にどんなソフトがインストールされ利用されているか、もしくは利用可能になっているかを洗い出されること」が先ず最初に必要です。次に、洗い出されたソフトウエアに対してライセンスの裏づけを行います。全て裏づけが取れれば、問題ありませんが、裏づけが取れないものがあれば、不正使用ですから削除します。もしくは事情（削除が出来ない理由がある場合）を説明して即日購入をおこないます。

単純な作業ですが、組織規模が大きい場合は相当苦労することになります。情報システム部門にノウハウが必要です。特に面倒なのがインストールされたソフトウエアとライセンスとの突合せ。一括管理体制を敷く組織では、インストール数とライセンス数のそれぞれの総数を求めて、その比較で済ますことが出来ます。このときは資源管理ツールなどを利用することになります。

部門管理の場合は一括管理と同じよう総数管理のな考え方でもいいですが、ライセンスを個別に識別して個別管理の方法を取ることもできます。

いずれの場合も『網羅性の確保』が課題になります。

.*.

この台帳はパソコンHWの管理にも利用できますし、適切に維持することにより、過剰なライセンス購入を防止できます。またはフリーソフトの管理にも利用できます。

ところが目的別にめいめい勝手に台帳を作りますから、組織全体では極めて無駄な・非効率な管理作業をやることになります。縦割り組織、縦割りの管理の一般的な弊害です。

.*.

Pマーク制度の弊害?

Pマーク制度の弊害?

馬鹿な審査員が馬鹿なことを言って帰る。始末が悪い。個人情報を扱うところだけが馬鹿をやらされるなら我慢も出来るが、関係ない部門まで馬鹿をやらされるから堪ったものでない。こんな制度との付き合いはいい加減にして更新はやめられないか。

悪政の片棒を担いでいるような気がする。

せめてISMSレベルの審査が出来ないものか。

移転審査って何ですか？

移転審査って何ですか？

検索すると審査機関を変えることらしい。今まで審査機関Aだったけど、これから審査機関Bにする。株式の預け替えみたいに簡単に出来る。でも建前だろうね。簡単でなければいけないけど、本当は簡単でないよ。同じ現象を見てOKですねという医者もいれば入院ですと言う医者もいる。医者の目利きだけが違いでなくて病院経営状態も影響する。

そう言えばどこかに凄い会社がありましな。

癒着の隙を作らないために、不満だからと言う理由でなく、3年経過を理由に、いきなり審査機関を変えてしまうのだ。素晴らしい。

引越し魔というのがいましたが、審査機関の引越し、乗り換え、も引越し魔ですね。初年度キャンペーンなんかがあればトータルでお安くいけるのかな。

話を戻して。移転審査は、だから、隣からこちらに来るんだけど不良クライアントでは困るから、一応簡単に確認しますが、それが移転審査ですね。困るのは、事件と事故が多い。放置された重大な不適合。支払いは当然ですね。踏み倒し？

だから、何故、移転するのかしつこく聞いてくる。多いのは相性というか消えない不信感。担当者が嫌で忌避して、また嫌なタイプが来たりすると、変えるしかない。お粗末な理由ですね。お前が嫌がられていたりして。

最近はもっとドライに金が決めて。安いほうへ安いほうへ移転の流れ。安いに向かって転がる移転の流れ。その理由は？

.*.

＜安きに流れる移転の真因＞

審査機関が墓穴を掘っている。

クライアントには継続的改善。絶えざる変革。本質にアプローチ。なんだかんだ正論？を振りまいておいて、審査機関はと言えば、全く対極の態度を取っている。例えば、前任者を否定するな。負担を掛けないように。簡単に手際よく。審査をセレモニー化して、波風立てないで、年貢だけ確実に稼ごうと言うのだから。付加価値審査とよく聞くが、何が付加価値化すら理解していないみたいだ。

本当の付加価値はおもねるしんさではありえない。戦う審査。変化変革を促す審査。現状否定。新しい価値観を提示すること。何がその業界その業務のフロントラインかが見えていなければ新しい価値観は提示できない。

お作法で済ますなぞるだけの審査では泰樹に流れて当然。統合審査、複合審査、言葉は変えても結局、手際よくやるだけの無価値審査。

チェックリストって殆ど無駄じゃないの？

チェックリストって殆ど無駄じゃないの？

ISOの要求事項がある時に、それを展開してチェックリストを作っているのを見かけるが、視点・論点が細部に入ってしまって大枠が抜けてしまう例をよく見る。早く言えば、自分で考えてチェックしていくことを辞めてしまう。思考停止を招く弊害も考えて良さそうだ。

チェックリストなんて教育・経験の少ない人でも一定の成果を得るための方便に過ぎない。

ですから、やたらチェックリストを要求する人がいるが、その人の頭も思考停止に陥っている可能性を考えてあげた方が良い。ただでさえ、ＩＳＭＳの規格はチェックリストみたいな付属書をつけているのだから、これ以上、細かく砕くのはやりすぎでしょう。

何も考えずに規格書通りに確認したほうが余程間違えない。特に何処の誰が作ったか分からないチェックリストなどは発想する世界観が違うのだから、暇なときに眺めるだけで充分でしょう。

.*.

適用宣言書の作り方

 新潟県安吾賞の宣言書はシンプルで分かりやすいですが

適用宣言書の作り方

これはどこかに解説書でも出ているのではないでしょうか。コンサルに出掛けるたびにマトリクス氷河顔を出す。どういう必然性があるんだろう。

脆弱性評価で出てくる。

現在取っている数々の施策(アクティビティActivity)。

リスクアセスメントの結果、新たに導入するいくつかの施策(アクティビティActivity)。

アクティビティの数が数十で収まればいいが、下手すると、数百に及ぶ。手作業の限界かも。数千ってことも組織規模によっては、纏め方によってはあり得る。内容的に重複するアクティビティあるから、これをどのように整理するかもコンサルのノウハウとなる。

一つのアクティビティを取り出して、付属書Aのどの管理策に該当するか確認する。この作業が冒頭のマトリクスを使ってやることになる。横に133個を並べ、たてにアクティビティを並べる。1万個のセルを埋めていく作業になるわけだ。

133個の管理策で、1箇所でもチェックがあれば、それは採用と言う判断。

適用宣言書に記載する内容：

1. 管理策（＃１-１３３）
2. アクティビティ＝管理策の中身として実際に実施している内容。
3. 管理文書＝アクティビティ詳細手順を記載している管理文書。

.*.

単純な作業実見える。脆弱性評価が出来たらの話だから、このマトリクス表に来るまでが又大変なんですね。

.*.

この基本的な手順を何も踏まないで適用宣言書を作っている組織もあります。コンサルも手抜き？　時間が無いからではなくて、クライアントの不理解が原因。

リスクアセスメントの方法論を検討する前提

リスクアセスメントの方法論を検討する前提

何の事前情報も無く、一般的な方法としてリスクアセスメントの方法論を検討することが出来るかと言えば、一般論の範囲では充分可能だ。組織の特性、事業と業務の特性、情報の特性、管理の特性が事前情報として入ることで一般論は修正されることはあるか。充分にあり得ることだ。

しかし、リスクアセスメントの手順なんて何処でも同じはず。前提の何が変わるとリスクアセスメントの何が変わるのだろう？

.*.

適用範囲がどうなっていようが手順の妥当性には変更が生じるわけではないから、リス汗面と手順の検討はいつ始めてもいいはず。手順の妥当性は不変的な価値である。

.*.

トップダウン手順を考えてみよう！

1. 事業ミッション。株主との約束。ビジョン。
2. 事業の構造。外部構造と内部構造と。長期計画。
3. 組織と役割責任と方針展開と年度計画。
4. 具体的な業務と業務プロセス。

どの↑↑↑業務↑↑↑を適用範囲としたか？　または適用範囲の↑↑↑業務↑↑↑をどのように表現したか？

.*.

リスクアセスメントが妥当かどうかは対象となる業務に対するアセスメントかどうかだけであって、手順そのものは殆ど影響を受けない。特に詳細リスクアセスメントの手順は方法論（少なくとも見かけ上の方法論）が確立している。規格はその確立した方法論に沿って策定されている。

簡略化するときに、組織、業務、資産などの特性を踏まえて何処まで可能かの議論を続けることは可能。その場合は、適用範囲の特性を踏まえることになる。

従って、リスクアセスメントの妥当性を見る場合は、組織が何らかの工夫をしている（標準的な詳細リスクアセスメントを採用しない）場合は、適用範囲の特性を抑える必要がある。と言うことになるようだ。

.*.

業務プロセス。対外的に示す業務が基幹プロセス。それを支えるプロセスが支援プロセス。

基幹系は：企画、開発、製造、物流、販売など。

支援系は：管理業務、人事・総務・経理など。

情報は機関化支援か？　支援入れるケースが多い。これが経営上の難しいところです。品質を基幹系に入れるなら、情報も基幹系に入れておかないと間違えます。ISMSは余った人材で間に合わされるだけの、余計な仕事にされてしまう。機能別管理に上手く収める工夫も必要ですね。

.*.

オフィス入室用のキーカードを忘れたら？

オフィス入室用のキーカードを忘れたら？

諸先生の話を聞くと忘れた時の会社側の対応も色々あるようで興味深い。冗談もあります。この頃は電子錠が当たり前になってきている。社員証を兼用する企業もあるようだ。一方、ビルの入館はビル管理会社が方法を決めるので、雑居の場合は一貫性のある入館管理・入室管理ができるか課題も残ります。

カードで入室を管理する以上、カードを忘れる・紛失するのは避けられません。

どないする？

1. 電話で同僚を呼び出して入室。出入りは友連れで済ます。不便しながら一日を黙って過ごす。会社側には特に情報は入らない。
2. 嫌、社員通用口はいつもロックされていないので特に不自由はない。黙っていても分からない。
3. 忘れたことを上司に報告するが、やはり同様に不便な一日を過ごす。上司はその場その日の問題として済ます。
4. カード管理部門が予備カードを用意していて貸し出す。貸し出し管理の記録が残る。
5. セキュリティの弱点に類する記録の一つとしてＩＳＭＳ事務局部門にも報告される。忘れた理由も書く。
6. 忘れたと紛失したは紙一重と理解して、当該カードの利用記録（不正利用の有無）を確認する。休日をはさんでいる時は重要。
7. 不測の事態に備えて、当該カードの利用を一旦ロック（無効化）する。予備カード返却時にロックを解除する。翌日が休日の時は重要。
8. カード管理部門の連絡を受けてからロックするまでの時間、及び利用記録確認までの時間を記録する。
9. 対策として、非接触カードだから携帯フェリカに入れてしまう。
10. 嫌、ついでにパソコン利用キーをパソリ化して全部一緒にしてしまう。
11. こうなるとキーを忘れたら仕事にならないので家まで取りに帰らせる。
12. やはりバイオ認証しかありませんね。

.*.

受託・委託の注意点

受託・委託の注意点

まあ、普通は機密保持契約。次に、再委託の禁止事項。

契約が継続的な場合は、情報システム関連サービスでなくても、情報の受け渡しが有る場合は広く捕らえて、定期的な監査、重要な変化点に対する対応が必要になる。

委託先に対するセキュリティ要求事項＝契約要件を整理することが必要。

＜委託契約＞

機密保持条項を入れること。再委託は禁止または事前に審査・承認を要求すること。随時任意の監査権を入れること。情報セキュリティ要求事項を入れること。この場合は、基本事項・共通事項に加えて、委託時の個別案件毎に設定できるよう別紙書きを前提とする。

事件事故時の緊急対応に関連する要求事項に加えて、事業継続管理の観点からの要求へも配慮したもので無ければいけない。

二兆管理レベルについても定期的な報告を求めること。

◆　契約管理で問題になるのは、

実際の委託業務のオーナー（主管）部門と、契約管理・委託先管理の責任部門が違う場合に発生する連携の不備です。複数の部門が色々な業務をある企業に委託している場合は、どの部門が何に対して責任を負っているのかはっきりしません。業務ごとに異なる要求レベルを無視して適当なアンケートで済ます。結果もフィードバックされない。形だけ規格要求に沿う。

委託先から足元見られるのは必至。もっとも、委託先の方が大企業の場合もありますから、何から何まで言いなりとは行きません。

.*.

可用性の議論

可用性の議論

その情報を必要とする人が必要な時にアクセスできることの実現性を可用性という。

可用性価値とは、必要な時にアクセス出来ないことにより発生する被害相当額の大きさ。

可用性の喪失によって生ずる事態は、顧客クレーム（社会信用や市場機会の喪失）、業務停止に繋がり、それによる損害額が考えられる。

どの程度の時間でアクセスできるかという観点からの価値評価も考えられる。必要な時といっても時間幅が有るとする考え方だ。事態はアナログ的。

最強はリアルタイム。常にその情報にアクセスできる状態。手元あるいは居室内に置く情報。24時間運用のサーバー内に有る情報も最強のカテゴリーに入るでしょう。時間差なし。

最悪はロスト（紛失）で二度とアクセスできない。または手遅れのケース。

管理策の程度で区分する。求められたら直ぐに出せる状態。直ぐそば管理。外部倉庫なら、翌日アクセス。メディアに落としてあるものなら、インデックスがないと分かりにくい。インデックスも外にある場合はもう1日必要。

.*.

可用性の議論が面倒なのは、脅威の頻度の議論と似たところがある。地震の頻度と震度の議論を同時に始めてしまうから何を計測するのかが混乱する。可用性も、震度に相当する時間は場というアナログが入り込んでくるのでややこしくなる。

情報を区分するときに管理項目にアクセス時間をあらかじめ設定しておくことが大事です。管理基準のひとつ。情報の用途が決まればアクセス要件も決まる（筈）。

たとえば、アクセス要件は当日中とした場合、翌日以降になったら被害額はいくらになるか？。被害額の大中小で可用性価値を評価する。被害の最大値で見ておくこと。

.*.

外部参照データは、可用性が高い場合は、内部にも保持するなどの施策が必要になる。

.*.

情報が必要になったときに直ぐ必要なのか一定の時間後に必要なのか。タイミングの要求。これ難しいですね。大方は気付いたときに直ぐに必要になります。この情報は３日後でいいですということは会議などを想定すればありうることですが、問題がすり替わる懸念が有る。重要な決定が必要な会議で求められて直ぐに出せなかったら意味が無い。会議が終わってからこれがその情報ですとこられても後の祭り。もっとも会議場でどの程度決定的かによるので評価はやはり難しい。

情報へのアクセス要求が出て、直ぐに対応が必要なものはAランク。翌日でいいものはBランク。永久にアクセスできなくてもいいものはDランク。とか適当に決める組織がありますが、何か変ですね。これは情報の種別/区分の話で価値評価とは別物です。

アクセスのスピードと被害額の大きさとは別次元の概念です。

ヘルプデスクではレスポンスタイムは秒オーダーで、個別の対応が入っても数分が限界。顧客のクレームに繋がる。

経営者が経営会議などで必要とする計画実績などの情報は同様に数秒、数分のオーダーが期待値です。経営のスピードが落ちる。

例えば、設計作業時に要件情報にアクセスするのはやはり同様に数秒、数分。プロセスのスピードが落ちる。

.*.

可用性の議論が難しいのは情報の質と遅延の程度によりインパクト（損害額）は変わるだろうと思われるからです。

＜この問題を単純化することが出来ます～単純化することが必要です＞

資産価値が[C+I+A]とか[C*I*A]とかの困り者

資産価値が[C+I+A]とか[C*I*A]とかの困り者

資産価値をＣＩＡごとに求めていたので、まあ普通のやり方と思っていたら、最後に、
資産価値＝Ｃ+Ｉ+Ａとか、資産価値＝Ｃ*Ｉ*Ａとか、時には、資産価値＝Ｃの二乗*Ｉ*Ａとかに遭遇することがあるようです。ＣＩＡは野球の選手なら守備率、打率、盗塁成功率のようなもので、全く次元をことにするものですから、これらの数字を直接演算操作しても得られる数字の意味は良く分からないものになります。クライアントとしては総合評価のつもりらしいですが、確かに傾向として、数字が大きいければ管理コストが掛かる情報資産であろうということは推測できるかもしれません。

＜論理破綻の例＞

• 資産価値＝Ｃ＋Ｉ＋Ａ
• 資産価値＝C×Ｉ×Ａ
• 資産価値＝Ｃ*2＋Ｉ＋Ａ
• 資産価値＝C二乗×Ｉ×Ａ

このＣＩＡ次元を喪失させた総合？資産価値をベースにリスクアセスに挑む組織もあるようですが、そうなると完全に論理的破綻となります。2002年前後からＩＳＭＳは始まっていますが、延々と論理破綻のままリスクアセスメントを続けている企業もあるようです。先行企業ですからそれなりにビッグネームのものもあります。そうなると、関係したコンサルとか審査とかの側にも罪がありますね。

論理矛盾（ＣＩＡ次元の喪失）に気付いた組織では総合？資産価値は求めても参考情報として併記するだけで、ＣＩＡごとのリスク評価には使用しません。当然のことです。

.*.

機密性価値だけ二乗するのは機密性を重視しようとするからですが、全く意味の無いことです。理解していないことを公表しているようなものですね。普通に機密性価値に対するリスク評価をやれば済むことです。ＣＩＡ毎にリスク評価、リスク対応の労を惜しむばかりに総合指標を無理やり作り出して無意味なリスク分析に走ろうとするのは今でも少なくないらしい。

.*.

少し脱線しますが、ＣＩＡ毎にリスク評価をやる場合に、Ｃだけ5段階、ＩＡは3段階とするなどの例があります。資産価値×脅威（3段階）×脆弱性（3段階）とすると、Ｃは最大４５レンジ、ＩＡは最大２７レンジになります。リスク値は基本的には期待損失額がベースになる考え方のものですから、レンジがずれていること自体が歪んだ評価になります。当然、同じレンジ幅で無ければいけません。

機密性価値を重視したい場合は、受容レベルをＣについてだけ厳しく設定すれば済むことです。受容レベルはダイナミックファクター。管理上のパラメータですから適宜見直す発想が必要ですが、どうしても永久不滅の固定的な基準として理解してしまう組織があるようです。

.*.

トーマツ方式リスクアセスメントの弱点は本当に弱点か？

トーマツ方式リスクアセスメントの弱点は本当に弱点か？

先ず、

資産の洗い出しはプロセス毎に行う。通常は小さな業務グループ単位に行う。業務プロセス＝業務グループとみなす。資産調査表はインプット情報、アウトプット情報、イン・アウトの無い情報に大別される。洗い出すのは情報コンテンツで、その保管形式（紙、メディア、サーバー）の区分なども入れる。コンテンツ単位で管理者も記載する。調査表と資産台帳は同じ書式。管理者が管理者として了承したら台帳になるようなもの。

ここでの課題は洗い出しの網羅性がどのように確保されているか。おそらく、網羅性の確保には特に拘っていないのだろう。初期段階では大枠で把握できれば充分と見る考え方もある。ただ、何れ手直しが前提とすれば、ＩＳＭＳのシステム構築が出来たとは言いがたい。

通常、台帳と言うものは目的の項目（キー情報）について、1件1葉または1件１行の形で整理されるものですが、トーマツではコンテンツ名がキー情報になります。資産は媒体によって管理の仕方が変わりますが、ここではお構いなし。物理的な実態に照らせば、資産の分類表に見えます。

資産台帳では資産の価値評価は行いません。規格が示す手順と整合しているか分かりません。

次に、

重要な資産については業務プロセスを更に細かく見てリスク評価を行いますが、どれが重要かは主要な情報として捕らえれば自明と言うことで、結局、部門業務プロセスをサブプロセスに落として、先ほどのインプット、アウトプットを並べなおすことになります。

サブプロセス毎に、①脅威、②脅威発生時の被害（資産価値に相当）、③現状の管理策、④脆弱性、⑤リスクレベル（①*②*③）、⑥追加の管理策などを評価していきます。

ここでの懸念は、サブプロセスの評価であって、資産が特定されていないこと、更に資産価値のＣＡＩの側面が曖昧なことです。ここも、規格の要求にあっているか分かりません。リスクが認識されても、どの資産のどの側面（ＣＩＡ）についてのリスクか判断が難しくなります。

この方式は、

当初、ざっくりと全体を把握するには利用できる方法論かもしれません。サブプロセス単位で見るので簡単に着手できるのがポイントでしょう。ベースライン方式による管理策の範囲では有用かもしれません。しかし、将来に渡って継続的に利用するのは適当とは思えません。詳細リスク分析には適していないように見えます。

従って、独断で言えば、更新審査のときもこの方式でリスク評価を実施していたら、既に失敗かもしれません。適材適所の発想が必要で、小学校に上がっても園児服を着ているわけには行かないのと同じことです。

.*.

ワークフローマネジメントの裏づけの無い電子印の取り扱い

ワークフローマネジメントの裏づけの無い電子印の取り扱い

文書の電子化が当たり前になる。企業によっては電子化文書が「正」で、印刷したものは参考文書の扱いにしているところがある。経費節減、環境対策の中ではますます増えてきているでしょう。

赤いデート印が電子化文書にもあると何と無く承認された正式文書の安心感があるが、ワークフロー管理システムを利用して電子印がはめ込まれる場合は朱印と承認の関係が整合付けられるので良いが、中には朱印はただのイメージ図形で勝手にコピペが出来てしまうところもある。

承認の裏づけが無くても朱印イメージが勝手に添付できる運用が好ましい訳は無い。でも、朱印みたいな面倒はしないで単に名前と日付をテキストで記入して済ますケースもある訳だから、要はその文書の性格によって扱いを分けるべきだろう。

改ざんによるリスクが大きいもの。即ち完全性価値が大きいものは確実な承認プロセスを要求すべきだし、そうでなければ厳密性は要求しない。但し、トレーサビリティの確保だけは必要だろう。

.*.

ワークフローマネジメントの裏づけの無い電子印（朱印）を見つけたら、その文書の完全性価値がどのように評価されているか確認することです。もっとも、そのような場合は面倒な電信（朱印イメージ）の使用を止める方が懸命であることに疑いない。

.*.

幼稚なパラドクス：資産細分化によるリスク縮小でリスクアセスを捻じ曲げる詭弁家に要注意！

幼稚なパラドクス：資産細分化によるリスク縮小でリスクアセスを捻じ曲げる詭弁家に要注意！

分かりやすい例え話は「1千万円以上の発注は役員決済、それ以下は部長決済」とした場合、発注を全部1千万円以下に分割して全て部長決済で逃げ切る手法。この手法を盾にとって決済区分を決めても意味が無いと主張する詭弁をコンサルの中にも審査員の中にもいるのだから驚く。本旨を外してこの連中は一体何をやっているのかと疑う。今尚現役でやっているのだから注意あれ。

リスクを探す活動をリスクを隠す活動に摩り替えているので、問題が起きたらクライアントは自分で被害を被るしかないのです。特に某審査機関とそれに連携するコンサルには多いように思います。

.*.

幼稚なパラドクスを展開してリスクアセスメントを否定する輩が後を立たない。ISMS(ISO27000)はリスクアセスメントを基本したＰＤＣＡ型のマネジメント方法論であるにも関わらず、リスクアセスメントの理解が不十分なことを棚に上げて、方法論そのものを否定し始める。

ＩＳＭＳのセミナーなどに出ると最初にぶつかるのがリスクアセスメント。驚くのはＩＳＭＳ審査員の中にもリスクアセスメントを理解できていない人がいること。審査機関の傾向もありそうだ。やたらベースライン方式を薦める審査員は過剰な負荷を軽減するための手助けかと思ったら実は詳細リスクアセスメントを正しく理解していなかっただけと言うのも有るようだ。

.*.

資産価値×脅威の頻度×脆弱性＝リスク値

リスク値は上記の計算式で求めるが受容レベルを設定すること小さなリスクはそのまま受け入れる。

.*.

パラドクスはどのように展開するか。『脅威を細区分（細かく分解）することにより、発生頻度が小さくなり、もたらされるリスク値も小さくなる。結果、全てのリスクは受容される。』

例えば、震度7.00の自身発生頻度、震度7.01の発生頻度、震度7.02の発生頻度と細かく分けてリスク評価をやる分けだ。『どの地震に対しても対策不要が導かれるから、リスクアセスメントの方法論じたいに正当性は無い』と主張する。

火災を例にしても簡単に出来ます。火災の発生頻度を原因別でも現象別でも細かく見ていくとそれぞれの発生頻度は下がるから、いずれ全てのリスクが受容されることになると主張してきます。でも火災はある確率で発生している訳でどの組織もそれなりの対策を実施している。こういう矛盾を持つリスクアセスメントは意味が無いとやる訳です。

こういうパラドクスを弄ぶ詭弁家を時々見かけます。

リスクアセスメントが面倒なものだから、こういう詭弁で以ってリスクアセスメントを手抜きで済まそうとする。馬鹿なコンサルがいて悪乗りしているから始末が悪い。

.*.

さて、如何すればこの詭弁家は退散させられるか？

答えは超簡単。足し算するだけです。リスク値の本質は期待損失（普通は年間期待損失額）です。どのように分解しようとトータルの損失額が減る訳では有りません。トータルが受容できるレベルなら何もしなくて済みますが、実際は受容できないので分解作業を始めるのですが、この分解作業は詭弁のためでなく、施策を有効にするための優先領域を見つけるために行います。

情報資産、脅威、脆弱性をそれぞれどの程度粗くまたは細かく見るかは試行錯誤が必要だろう。キーとなる資産については「粒感」（つぶかん）と表現する人もいる。そのときにポイントとなるのは管理の視点になる。管理者と管理策である。管理者が変わる場合、または管理策が変わる場合は「粒」を変える。

地震なら、建築物の構造の領域は総務部門だろうし、設置された機器類の対策は当該部門となる。機器類の管理者は構造破壊の領域まで見る必要は無い。火災も原因によらず誰が何をするのかで見れば自ずとある塊にならざるを得ない。

.*.

詭弁は手抜きの方便でしかないのが残念。リスク低減のためにどのようにアプローチすべきか紳士に取り組んでもらいたいものだ。

.*.

識別しないという管理策の誤魔化し

識別しないという管理策の誤魔化し

情報資産の識別もしないで管理も何もあったものじゃない。電子化された情報（ソフトコピー）と紙のままの情報（ハードコピー）では扱いは変わる。

＜ハードコピー＞

1. 資産名（必須）
2. 管理責任者（必須）
3. 保管期限（推奨）
4. 機密区分（必須）
5. 保管場所
6. 使用開始
7. 管理部門（必須）

いまだに、「機密文書のラベルを貼るとわざわざ悪意の侵入者に機密文書の所在を教えるようなものだから識別しない」と言う真面目馬鹿の存在していることに驚く。一体、どういうリスク分析をやっているのだろう。

部外者の持ち出しを容易としないためだけなら機密と書かないで色か形を変えたシールでも充分だが、そういう知恵もなさそうだ。

それよりも部外者がアクセスできるところに不用意に機密文書を放置させないことが重要。放置するのは社員だから、確実に社員に注意喚起できなければ意味が無い。リスクは社員の取り扱いにこそあることを認識すべきだ。機密文書が一般文書の中に混じって流出することも懸念すべきだろう。

識別しない管理策もクライアントの無理解だけなら希にあることだが、審査員の中にも同様の発想をしているのがいるから驚き以上だ。適用宣言書でA.7.2.2を採用しておいて、そのことを自分で否定するのを勧めているのだからクライアントも不幸なことだ。

コンサルは取り敢えず傍観するだけです。

.*.

「識別しない」管理策を採用する組織の共通点は単に整理整頓が苦手なだけということもあるようだ。５Ｓ活動が不十分な怠け者たちは、自分たちを正当化するために分けの分からない「識別しない」管理策を持ち出す。

馬鹿な審査員が上乗りする。始末が悪い。ＩＳＯの分野を問わずよくある光景。

.*.