JACO

JACO

日本環境認証機構

審査機関のひとつ。メーカー、主に電機労連系メーカーの寄り合いで作った機関では無かったか？。社長は電機メーカー出身者が持ちまわりか？。

企業の裾野が広いので事業的には不安はないが、身内あるいは取引先を審査するので、どうしても厳しいスタンスでの審査になる。一方で馴れ合いが入り込む余地がありそうだ。

JACO-IS

日本情報セキュリティ認証機構

ISMSを担当する別会社。今は存在しない。JACOの一つの部門になった。機能別に会社を分けていたが全体の効率を考えてか一体化に方針を変えたようだ。最初から無理だった。人事面を考慮して別会社にしていただけ。

.*.

厳しいスタンスが残るため、関連企業以外への展開は弱い。コンサルは面倒な審査を嫌うし、構築したシステムを否定されたら、自分の立場も失う。

大企業で程ほどの成功体験を持った人が審査をするので、押し付けに見えるのも災いしている。審査員の現職より、出身母体の肩書きの方がはるかに重要。だからオープニングでは経歴・職歴を丁寧に説明する人が多い。

審査と指導会が混在した印象になるため問題ありだが、発想を変えれば非常に有り難い審査を受けることが出来る。

かな？

.*.

ISO26000

ISO26000

これは社会的責任に関する規格。第三者認証制度の規格ではない。

自分で調べてください。

特に、コンプライアンスを担当する人はしっかり見ておくべきです。

大きな企業に求められる社会的責任は決して小さくないし、すれすれで運転していると企業イメージをスポイルして結果は大損害になりかねません。

国内と海外。両方に目配りが必要です。

それと、パートナー企業の動きも。ライフサイクル的な捉え方をしないと思わぬ責任追及を受けます。

このことは、自分が大企業でなくても結果はあまり変わりません。

大きな業界に組み込まれている以上は、仮に下請けでも、社会への説明責任は常に意識しておくべきことです。

.*.

ISO20000:2011

ISO20000:2011

ISO20000の2011年改訂版。あまり関心がありません。ISO20000なんて派生規格？、もどき規格？でしょうか。業務用途別に最適化するのは当然だから、業界別ガイドラインは必要ですから否定する理由はありませんが、第三者認証制度を生業とする連中の思惑の方が気になってしようが無い。ISO27001では不足と言っているようなもので自己矛盾を感じる。

ラベリングについて

ラベリングについて

ファイリングは古くて新しい問題。誰でも出来るがこれ！っと言った物にはなかなか行き着けない。ラベリングはその要素の一つ。

1. 属性情報の全てをラベルにすると視認性が落ちる。
2. 収納場所を変えるとラベルも変えるのでは管理ロスが出る。
3. 組織変更の度にラベルも変えるのではやはりロスだろう。

バラバラにしてはいけないものはバインダーに綴じる。記録類の台帳、特定プロジェクトの一連の資料類は一塊にするためにバインダーに入れる。
ばらばらにしてもいいもの（資料の時間連続性などを要求しないもの）は、今後はバインダーへの綴じ込みは避ける。ファイルフォルダ、ファイルボックスを中心に利用する。
どちらかと言えば、過去情報はバインダー、現在情報はフォルダ/ボックスがメインになる。

ペーパー1枚1枚にラベルは普通は考えなくてよいが、取り出された時に正しく元の場所に戻れるように資料名（表紙、目次、ヘッダーとかフッターとか）が出来ていればいいでしょう。

ラベルは、バインダー、フォルダー、ボックスに記載される（貼り付けられる）ものです。電子ファイルの場合は、ファイル名あるいはフォルダー名ですが、電子ファイルの場合は属性情報が自動的に（勝手に）付与されるので別の問題が出ます。

.*.

具体的な事例

• 機密性区分：この識別の無いラベリングは考えられません。機密情報であることが外部者にも容易に判別できないようにしたいと言うことと全く識別しないことは別の問題です。何を厳重に管理すべきかが判別できないのは論外です。社外にルールを教える必要はありませんが社内では周知されている必要があります。
• 管理日：管理開始日・管理終了日・管理見直し日などです。保管期限の場合は定義を明確にする必要があります。保管期限と廃棄処理の関係。
• ファイル名：出来るだけ具体的に。○○関連資料などは避ける。どうしても纏められない時は××等○○関連資料とする。
• 管理責任者：大括りの部門名は避ける。直接の担当部署（グループ、課、係りなど）と担当者名。間違っても部門長デートで済まさない。部門長が直接管理するもののみが部門長印で管理。
• その他は、管理コードなど文書管理規定が要求しているものがあれば記載。
• ラベルの色識別は視認性を高めるので非常に有用ですが、徹底するのが難しければ、モノクロで徹底するのも良い。意味も無く色を付けたり色を付けなかったりするのは歓迎できない。
• ラベル位置もいい加減なｍのはいけない。保管状態でキャビネを開けたりした時に識別できる位置にラベルが付けられているべき。どこかに書いてあれば良いとするのはラベル付けの目的すら理解していない可能性がある。５Sの常識？。
• メディア類の保管も基本は同じでも、厄介な問題が残る。内容確認。１つは改竄されていないか、２つは再読み込み可能か。ラベリング自体の問題ではないが、ラベルは内容を表示している前提において内容との合致性をどのように担保するかが問題になる。管理上は結構手間です。

.*.

馬鹿な審査計画が出てくる理由？

馬鹿な審査計画が出てくる理由？

審査中の移動計画は、限られた審査時間の中での移動が前提となるため、簡単ではないのだろうが、下手な組み方をされると、同行するコンサルにも良い迷惑だったりする。勿論、クライアントの事務局が同行するケースもあるから迷惑は2倍。

時には、「コンチハ・サヨナラ」のケースも。現地での審査時間が殆ど取れないということです。こんな審査計画もあるようで、移動計画以前の問題だ。クライアントからすると審査機関で承認された審査計画だから、嘘が入った計画を見て、審査機関そのものに不信感を持っても当然。審査計画のレビュー能力が低いというより、費用と工数に無理を重ねるから計画に矛盾（嘘）がでるのでしょう。

センスの問題もあるかな。

東京本社で、名古屋、大阪、福岡に支社。2チームで4地域をカバーする時に、１つは大阪・名古屋をカバーし、もう一つは東京・福岡をカバーするのが常識？。フライト利用は東京ー福岡間往復。ところが、名古屋・福岡で1チーム、東京・大阪で1チームとする。フライト利用は東京ー福岡間片道のみ。こういうのが出てくることがある。移動料金のミニマム化を考えたプランなら、東京・名古屋で１チームとしなければいけない。センスが悪い。審査計画を作成した審査員のセンスでなく、本末転倒に走る事務局のセンスが悪いのです。目的が経費節減に走った結果です。

何よりも、限られた時間の中で効率的に移動して、より適切な審査を実現することを考えるべきでしょう。

.*.

前者の例は、クライアント（経営者）が被害者。加害者は審査機関（営業？審査員？その他？）。

後者の例は、クライアント（経営者）が被害者。加害者はクライアント（事務局）。

.*.

間違いだらけの更新審査？

間違いだらけの更新審査？

審査の問題ではない。コンサルの問題です。コンサルが居ない場合は事務局の問題です。事務局が只の事務屋さんの場合は経営者の問題です。

問題って何？

更新審査を漫然と受けていることが問題。更新審査までに何をやらなければいけないか検討していない。前回の更新からあるいは初回認証から3年間が経過していることを踏まえて、少なくとも3年間の有効性レビューをやる。その結果、有効性改善のための施策が、次の方針、次の仕組み（マニュアル、管理策）に反映されなければいけない。更新審査の１，２ヶ月前から新たな枠組みでISMS運用が行われていなければいけない。

その新たな枠組みでの状況を第三者視点から確認するのが、更新審査だとするスタンスです。

.*.

初回認証審査では、構築し運用しているものを審査するように先手で準備していたものが、いつの間にか、再構築し運用しているものを審査するような準備になっていない。継続審査と同じで言われたことを後追いで手直しして済ませる態度に摩り替わっている。

審査の問題としたが、審査も悪いに決まっている。次年度に更新を控えたサーベイランスの時に、更新に向けて何を成すべきか正しく説明しているのに出会ったことが無いなどと。実際に、先生諸氏も歯切れが悪くなる。

.*.

文書審査の軽重も知らない

文書審査の軽重も知らない

文書審査はISMS構築の裏づけとなるだけに最も大事な審査要素ですが、初回認証審査と継続審査（サーベイランス）と更新審査では自ずと重みには違いが出る。特に、初回認証審査ではもっとも重要視せざるを得ない。構築が終わると再構築は色々な理由でおいそれとは出来ない。維持審査（継続審査）はその名前の通り構築より維持継続が主眼。

更新審査は3年間を踏まえて、特に作ったシステムの有効性を評価して、システムの再構築（Re-Build)に当たる訳だから、文書審査は重要になる。ここで勘違いしてはいけない。

「更新審査を通じてシステム再構築に向けた文書上の問題を洗い出すのではない！」



 .*.

更新審査の前に実施されるマネジメントレビューを通じて、有効性改善に向けたシステム（ISMS)の見直しが行われ、その一環として文書改定は終了していなければいけない。更新審査は、その改善作業が妥当なものかどうかを確認する立場をとる。コンサルは、マネジメントレビューの準備プロセスにおいて3年間の有効性評価、改善に向けた新たな提案の検討を行わなければいけない。

実際は、周回遅れ以下かも。更新審査で初めて有効性が妥当であったかどうかチェックして、それから文書改定（システム見直し）に入る。悪くすると、改善のための見直しすら実施されない。何故なら、有効性評価に真面目に取り組んでいないケースが殆どだから。

.*.

冒頭タイトルに戻る。更新審査の場合、主要な文書の見直しが行われていないことが明らかな場合は、文書記載事項と実施内容の不整合を調べる審査は殆ど意味が無い。しかし、更新も2回目となれば尚更だ。文書の改定を実施していれば改定箇所の妥当性・合理性・有効性に問題が行くが、変更していなければ、ルールと実態の乖離を見るアプローチは2流3流の審査。

ベテランの多くが2流3流のアプローチを嬉々として続けている。

.*.

基本方針、適用宣言書、マニュアルなど主要文書の見直しをやらない組織、2回目の更新だと6年間も放置したままの組織、そこで文書審査をやる意味はどの程度あるか。有効性改善への取り組みが無いままなのに過去6回の審査で合格を出してきた文書を下敷きに構築されているISMSに対する正しいアプローチは何か？

「実態としての矛盾・問題に対する理解を共有することから始めなければいけない！」

経営者の狙い・目的を達成できているかを実態から客観的に判断すること。これが先決。その上で、現在のシステムの課題を明確にする。

文書に基づく実態の点検ではなく、実態に基づく文書の点検になる。発想・手順は逆にしなければいけない。ベテランでもこの辺が全く理解できていない先生が居るようです。規格→文書→実態の流れしか理解できていない。規格→実態→文書の流れもあることをです。特に、いい加減な文書構築を容認してしまった場合は後者の流れが必須になります。

.*.

時間にルーズな会社のISMS？

時間にルーズな会社のISMS？

コンサルは時間を売っているようなもの。限られた時間で当該クライアントにもっと相応しいソリューションを提供したい。出来ればハートtoハートで。改善のための共感を得ながら達成感もともに味わいたい。と思って訪問させてもらっている。なんてね。

しかし、時間通りに担当者は現れない。嫌々、迷惑そうに遅れて出てくる。現場も同じ。上から言われたから、しようが無く会ってやるんだと。



.*.

審査の時もルーズがちょいちょい顔を出す。

ある先生は時間になっても誰も現れないものだから、わざわざ部門まで出向いて出席をお願いすることがあったとか。どうしてそんなことするの？不適合とか黙って出しておけば良いのに。その先生曰く。審査が成立しないと審査員自身にクレームが来てしまうらしい。

毅然たる態度より、サービス業に徹する態度。中身が変わる訳でもないでしょうが、先生方の世界も難しいんだね、

いずれにしても、時間にルーズな会社は本業もルーズなんだろうね。その内には淘汰されるでしょうから、心配ご無用にござい。

.*.

データセンターの情報資産

データセンターの情報資産

外部のデータセンターを利用することは珍しいことではない。ハウジング、ホスティングでは日本はハウジングが主流だったが、例のクラウドのメリットが理解されるにつれて、ハウジングに拘らない利用者が増えてきた。

データセンターの情報資産の場合、基本的なことで疑問が出ます。

• 外部に情報資産の管理を委託すると考えてよいか？
• 外部に預けている資産も台帳を作るのか？
• 管理を委託しているのはリスクの移転に相当するのか？
• 外部に預けてもリスクアセスメントの対象になるのか？

1. 情報システム部門はインフラ業務の一部を外部に委託する形になる。リスクの移転を図ったのは情報システム部門である。
2. 一般のインフラ利用部門は情報システム部門が準備したインフラを利用すると言うことでは違いはない。自部門が管理する情報資産のリスクアセスメントも変わりなく実施することが必要。

.*.

審査のある日に外出する？

審査のある日に外出する？

兎に角です。仕事以外の面倒が嫌。そういう人は居ます。有能な中堅や管理職に意外と多い。そういう気持ちは伝播します。その部門全体がネガティブな心持になります。コンサルが調査に出かけても本業外として嫌がりますから、審査などは鼻から問題になりません。さっさと外出してしまいます。酷いときは全員。ISMSの担当者以外は本当に全員。残るのはISMS委員と事務局とコンサルだけ。自分でも恥ずかしくなるそうだ。

もっとも、頓珍漢な受け答えのお陰で余計な宿題を貰うくらいなら外出がいい。三十六計逃げるにしかずです。部門長までもが顧客に呼ばれたと言って出かけてしまう。自部門の審査が終わると帰社する。帰社してもコンサルは勿論、審査員にも挨拶も何もしない。門前払いと同様のことが平気でできるのだから、いずれは会社のお荷物になるだろう。と、誰もが思うわけです。

.ところが、下克上の昨今は部門長を残してISMS担当が外出してしまう。担当が居ないからと、どっちにしてもEXCUSEが出る。

.*.

でも、

審査ってそんなに大事なことなの？。そうですね。人間ドックと考えてみてください。人間ドックなら、1ヵ月後に延期は可能ですが、審査はスキップしたら今年はお終い。次は来年、あるかどうかです。待ったなしの人間ドックだと考えると、大事さ加減はある程度理解できるでしょう。

そうなれば、スケジュール調整などは自分でやるでしょう。部門長なら簡単にできること。経営者インタビューに社長は時間を作っていて、只の部門長が時間が作れないことはない。能力が無いんだろう。と思われても止む無しか？。

コンサルにとっても審査は緊張する。下手をすれば自分が恥をかく。しっかり領分を守らない訳には行かない。と言いつつも、同席して審査員に食って掛かるのは、もっと恥晒しだから、単純でない。

.*.

RACONTIS（ラコンティス）の功罪

RACONTIS（ラコンティス）の功罪


ツールを使う問題点は以前にも話が出た。興味深いのは、岡目八目で不利益が見えるのでなく、当事者ご自身が不利益を理解していること。もっとも、後の祭りの場合が殆どだが、建て直しをどうするか課題認識はしっかりしているところも多い。匙を投げて自分の担当の間だけはいい加減を続けるところもあるようだ。


経営者は裸の王様。


子供のオネダリに応えてとうとう家庭教師ロボットを買ってしまった。この頃は宿題などはしっかりやっている。でも学校の試験は駄目。どうも本番に弱い。メンタルの問題か？


嫌、子供が買ったのは宿題ロボット。宿題はばっちり。子供はゲームに励んで学校では人気者。試験の日さえなければ。


さて、ツールは家庭教師か宿題ロボットか。誰でも答えは知っている。


.*.

一番大切なリスクアセスメント。これの意味を知る人は決してツールは使わないし使わせない。ろくに理解もしていない人は安直に飛びつくが、結果を想像できたら、あるいは意味を理解できたら、冷や汗を大量に流しただろうね。


リスクアセスメントは学習の場と理解できるかどうか。全てはそれに掛かっている。ツールにやらせる、事務局が一手に引き受けてやる、ISMS委員がやる。こんな馬鹿あだれもやらない。eラーニングはテストも代わりにやっておきましたから言われて有難うという人はいないでしょう。


.*.


ツール自身には罪はないとよく聞くが、ツールの開発者がよく知らなければ、結局は罪作りなことをしていることになる。


.*.


（引用記事）

ディスカウントされた料金の意味

ディスカウントされた料金の意味

コンサルはあまりディスカウントしない。ディスカウントすれば事業放棄になりかねない。少なくとも値引きなどとは言ってはならない。本当のニーズに立ち会えばディスカウントする必要すらありません。値引きをするようなコンサルはプロの態度でないゆえに結局は門前払い。

審査の方は事情が少し違う。携帯キャリアとかネットワークプロバイダーとかのビジネスと似ている。一度囲い込んでしまえば、金のなる木、安定収入の元になるからだ。コンサルはワンタイム、審査は継続。

ディスカウントに目がくらんで変なものを掴んでしまったらどうしますか。成長機会・改善機会を失って長期的に見ると大損失。セキュリティ事故を起こしてしまうリスクも抱え込んでの話だから、ディスカウントなどに目が眩んだ己をいくら恨んでも取り返しが付かなくなる。

審査のQCDで学んだように、Cを下げればQも下がる。Dを急いでQは下がる。特にコストは全てを支配します。安かろう悪かろうを受け入れるなら、ISMSへの取り組みは無意味。止めなさい。ということらしい。

.*.

安易に値引きしてくる営業・審査機関は要注意。どこの認定機関（認証機関を取り締まるところ）も、ディスカウントなど論外のスタンスです。持っての外という事です。

.*.

審査機関というビジネスの在り方

審査機関というビジネスの在り方

免許皆伝事業ではない。家元事業でもない。検査サービス事業は近い。人間ドック事業も近い。

先ず

• 一番はQ、基準に照らして乖離の度合いを正しく把握し判るように伝えること。
  乖離の度合いによって及ぼす影響を正しく分かりやすく伝えること。
  病気（不適合）のレベルでなければ、改善に向けた助言、回復のための助言。
  病気（不適合）のレベルであれば、治療のためのプログラムに入れる。重度であれば入院などの強制的手段。

• 二番はD、結果を早く伝えること。当日、一定の気かが出ていればよい。1週間後や1ヶ月後では臨場感も失う。何よりも有効性を喪失してしまう。

• 三番はC、負担少なく。コストは問題が多い。

◇

QよりもCとDに拘るのは本末転倒。Qは目に見えないが、CとDはよく見えるから安易にCとDに走る輩の何と多いことか。呆れるばかりである。

Qの中身も情けない。体裁というかパフォーマンスばかりで、手順がスマートならQが高いと勘違いする向きにはこちらが赤面させられるほどだ。

Qの本質を向上させるには十分な業界経験を積まないと無理。若い兄ちゃんを大量に採用して付け焼刃では出来ない。もっとも経験者には自分の成功体験に落ち込む弱点もある。QはCとDがトレードオフになるものだ。CとDに走れば実現できるQは薄っぺらいものになるのは当然の帰結。

＜よい審査には金も時間もかかる＞

当たり前のことです。手品もマジックもありません。

.*.

機密性区分の考え方

機密性区分の考え方

機密性区分で、レベル１は「誰が見ても構わない」（誰が見てもそのことで損害が生じない）であるが、レベル１＝公開情報とすると意味が少し変わってくるので注意すべきだ。『誰が見ても構わないけど公開はしない』情報が行き場を失う心配がある。

公開情報は機密性１で完全性・可用性の価値は高い。公開するからには完全性・可用性に責任が生じる。

.*.

『誰が見ても構わないのに非公開』の情報って何だろう？

他所からもらったチラシとかDMとかですか。『他者が公開した情報』。その情報の完全性・可用性に責任を負わなくても構わないケース。外部文書の一部。外部文書も保管上は相応の可用性・完全性が求められる。

.*.

社内文書で、「公開」する意図を持たない」機密性レベル１の文書は何かあるか？

.*.

事業拡大とISMS

◆事業拡大とISMS

事業拡大に邁進する企業。そこでもISMSに取り組む。経営の意志は事業拡大に伴うマネジメントのレベル低下を防ぐこと。ISMSを維持向上することで、ガバナンス体制を強化し、安心して事業拡大を図ろうと言うものだ。

正しい発想だが、心得違いにご注意。ISMSはコンサルが維持するのではないと言うこと。ましてや審査員は何の役にも立たない。

肝心は経営層の明確な意思と毅然たる態度。企業体質つくりを人任せにしていては事業拡大が成功するわけが無い。必ず足元を掬われる。経営陣は新事業で忙しい。既存事業への目配りは不十分になる。

＜留意事項＞

1. ISMS推進ノウハウの伝承を確実にする。特に現場。毎年ISMS担当を変える馬鹿マネジャーが少なくない。飲み会の幹事を回り持ちさせる感覚のマネジャーならそっちを変えてしまえ。
2. 委員会活動をハイレベルで維持する。特に事業拡大先は後進組だから、週1回は常識。先行しているところも月1回は最低条件。
3. 文書化の品質を上げる。事業拡大による新規参入が増えて阿吽の呼吸で済ませることがやりにくくなる。隙間の文書化と既存文書の見直し。
4. 新規組み入れの拡大部門のISMSを誰かが肩代わりしないで、自分で考えて自分でやらせること。先人の悪い見本に染めさせないこと。最初が肝心。[事業＋ISMS]でなく[ISMS in 事業]または[事業 in ISMS]に持っていくこと。

.*.

ITガバナンスと部門の自走力

ITガバナンスと部門の自走力

いきなり深いテーマになった。この２つは、2つとも成立するケース、片方だけが成立するケース、2つとも成立しないケース。考え方としては、全ての組み合わせがある。

社会的責任を果たすため経営陣による企業統制は強く求められているが、一方では事業力・起業力を高く維持するには部門の自走は欠かせない。両者を矛盾無く達成できればエクセレント企業。普通の企業は片方の成立も難しい。

情報管理機能も同様だ。ISMS維持強化においても命題は共通する。

達成の極意は？

• 役割責任の線引きを明確にする
• 役割責任を全うする。

曖昧にする。弛める。このようなことが入り込むと根底から崩れる。仕事への厳しさと人への思いやりを同居させること。人は緩めても仕事は弛めない。仕事は緊張感と集中力、人はいたわりと寛容。かな？

＜自滅の事例＞

• 内部監査などで不適合の内容を観察で済ませる。口頭指摘で済ませる。温情主義のつもりだろうが仕事を放棄して会社を壊している。
• 再発防止に踏み込まない是正処置を黙って受け取る本社スタッフ。
• 本社から指示されたら狙いも背景も理解しないまま黙々と作業する現場。

.*.

保管倉庫を見れば全てが分かる？

◆保管倉庫を見れば全てが分かる？

コンサルを始める時に立派な能書きを準備するより、クライアントと一緒に倉庫を見てみよう。倉庫の有様を見れば何が課題か考える前に素直に反省から入ることが出来る。共感を持って最初から仕事が出来るわけです。

責任者が明確でない共用部にはマネジメントの隙間がとぐろを巻いて渦高く積み上げられています。

倉庫の次に見るのは？

共用スペースの対極にある個人の引き出し・デスクサイドキャビネット・個人用収納スペース。個人用スペースにはマネジメントが到達できた結果（躾？）が顔を覗かせています。

倉庫も個人スペースも普段は他人に見せることはありませんから管理基準から躾に至るまで、マネジメントの緩みが顔を出しくれます。普段は他人が見ないのでリスクが潜む懸念も大きいと考えた方がいいでしょう。

＜課題設定＞

コンサルとしてどういう問題を提起しどのようなアドバイスを示すべきでしょうか？

1. 情報資産に対する管理責任者の割り当て。特に、共同利用される施設・設備・備品など。サーバールームが倉庫になったり、倉庫がサーバールームになったりすることもあります。マネジメントとしては殆ど敗北状態ですね。中には更衣室まで一緒くたのケースもあります。
2. パブリック（業務・社用）とプライベート（私物）の線引き基準と認可された管理形態。私物はロッカーで居室持込禁止も少なくない。

.*.

ウイルス定義ファイルの更新が止まる

ウイルス定義ファイルの更新が止まる

ウイルス定義ファイルの更新が出来ない。あるいは最新の定義ファイルによるウイルスチェックが出来ない。パソコンを立ち上げれば、自動的に最新の定義ファイルを取り込んで最新の防御体制が取れるはずなのに実際は必ずと言っていいほど抜け漏れがある。何故でしょう？

必須の管理策が、・・・筈の管理策に摩り替わっているからです。ウイルスチェックも、資源管理も、ツールを埋め込んでおけば必ず出来る筈なのですが、筈でしかないのです。

＜ウイルス定義ファイルの更新が止まる主な理由＞

1. 何かのソフトをインストールする時に、一時的にウイルス対策ソフトの作動を制限し、インストール後にウイルス対策ソフトの作動を復帰させるのを忘れる。
2. 定義ファイル参照サーバーを社内に設営しておいて、サーバー側の更新を適切に出来ていない。
3. オフラインで立ち上げた後の処理が適切でない。

.*.

対処法として勘違いしてはいけないことがあります。更新が止まる原因を特定して是正処置を打つのは当然ですが、それで十分と判断するのは早計だということです。原因が特定できない可能性を認めることが必要です。そのことを踏まえて、所謂、水際作戦も施策の一つとして残しておくことです。出なければ「筈だ」の呪縛に掛かります。

＜対策＞

パソコン使用責任者に定期的にウイルス定義ファイルの更新状況を確認してもらう。

.*.

パソコン資源管理ソフト

パソコン資源管理ソフト

パソコン内にインストールされているプログラム類を監視する機能を持つ。何に役立つかと言うと、プログラムのバージョンが適切に更新されているかどうか分かる。保有ライセンスを超えてインストールされていないか分かる。禁止されているプログラム類、ウイニーの類が不正にインストールされていないかが分かる。

各社からリリースされているが、優劣の比較検討については良く知らない。PCに管理ソフトをインストールすると、定期的あるいは何かのイベントのタイミングで監視サーバーに情報が提供される。監視自体はリアルタイムが基本だろう。単に情報収集以外に、強制的にプログラムの配布更新までカバーするものもあるようだ。そこまでやると別の問題を引き起こすのではないかと心配になるが、その辺がメーカーの知恵の出しどころなんでしょう。

アクセス（社外も社内も）情報、ダウンロード情報、などのログが取れる。中にはログだけでなく、出たそのものの控えまで残すものもあるように聞く。

この手のソフトはライセンス料金が高いのが玉に瑕。加えてリソース（ネット帯域、ストレージ）も大食いしそうだ。その内、技術的に確立してくれば安い商品も出回るか、クラウドサービスの範疇に入るかすれば更に普及するだろうか。

一般的な弱点としては、

• ネットに常時接続されないパソコンの扱い。
• インストールされないプログラム、スクリプト型への対応。

.*.

＜パソコン資源管理ソフトの例＞

比較的よく耳にする資源管理ソフト。ビジネス的には現時点では美味しいエリヤかも。他にもあるだろうし、勘違いも含まれるだろうが、比較検討の対象にして良さそうだ。

• LANSCOPE
• LANDesk
• ManagementCore
• QND
• ASSETBASE
• PALLET
• e-Care
• e-Survey

.*.

コンサルもITのプロではないからこの辺の比較評価を踏まえたリコメンドは容易でない。それでも詳細検討するまでもなく、カバーする台数と予算で選択できるソフトは限定されてしまうらしい。

.*.

脆弱性レベル１に対する追加の管理策とは？

脆弱性レベル１に対する追加の管理策とは？

時々、聞く話：

リスクの軽減は脆弱性に対して手を打つことだが、脆弱性１の場合は、既に十分手を尽くしており、管理策の追加は出来ないと言う側面があるから、脆弱性レベル１を要素とするリスク値は受容するケースが多い。受容だから追加の管理策は不要。

しかし、これは机上論。静的にものを捉えた結果でもある。

脆弱性レベル１とは、次から次に管理策を取り込み、貪欲に改善を進めている状態で、コストも掛かる。十分な脅威と受容できないリスク値が残っている限り手を休めてはいけない状態のこと。

受容＝現状維持と間違えないように、継続的改善を求める姿勢を明確にすることがここでは肝心です。

「重要資産の脆弱性レベル1の内容が前年と同じなら疑いを持つべきです。」

.*.

CMMに明るい人は理解は容易なのかもしれない。

.*.

リスク値について考えてみる

リスク値について考えてみる

本来は年間の期待損失額（金額）です。受容する水準は、経営層レベル、部門長レベル、マネジャーレベル、担当者レベルで、それぞれの予算との関連で決めてもいい。小規模企業だと１００万円を超える決済も経営層に行くが、大規模企業なら１億円でも部門長で決済できてしまう。組織規模が反映できるので有効なアプローチに思われる。経営層決済を受容基準にするのか、部門長決済を受容基準にするのか。

• [期待損失額]=[CIAが脅かされた時の損失額]×[脅威の頻度]×[脆弱性]

脅威の頻度は年間の発生確率。
脆弱性は脅威の発生に対して受け入れる確率（防御できない確率）
因みに、脅威×脆弱性＝実現頻度と理解できる。

.*.

金額ベースの評価が困難な場合、ポイント制の評価を採用する組織が多い。むしろ、簡便なポイント制でリスク分析を進めるところが主流だそうだ。

ポイント制で、リスク値は最大で４×４×４＝64。最小値は１。

ポイント制の最大欠陥は金額の大きさ（深刻度）が単なる１－４のランク分けされて、臨場感を欠落させること。小手先を使うことで、リスク値の過小評価が簡単に出来てしまうこと。その為に、いくつかの工夫を施すことになる。

＜リスク値の評価における工夫の例＞

1. 資産価値最大（４）の場合、脅威の頻度（１）、脆弱性（１）以外（＝実現頻度１以外）は受容しない。企業存続～事業存続の瀬戸際に追い込まれる事態を回避するため。資産価値４は無限大に通じると理解しておくことが重要になる。結果、リスク値４のみ受容。またはリスク値８以上は対策を要求。
2. 資産価値最小（１）の場合、全ての脅威（４）、脆弱性（４）を受け入れる。対策を要求しない。リスク値16まで受容。
3. 資産価値（３）の場合、中長期的に１回の発生（脅威１×脆弱性4）を下回ることを求める。リスク値１２は受容せず、次のレベルとなるリスク値９まで受容。
4. 資産価値（２）の場合、中長期的に1回の発生を認める。脅威１、脆弱性４。リスク値８まで受容。次のレベルとなるリスク値16は受容しない。

これを、CIAそれぞれに対して独立して実施する。

.*.

脆弱性を検証してみる

脆弱性を検証してみる

防御力の欠落度合いが脆弱性。

一部に勘違いの向きがある。出来ることに対していくつ出来ていないかの度合いを脆弱性と考えるのは間違い。やるべきことをサボってやらなかった度合いではありません。例えば、方法論として成立している管理策が１０個あって、その内７個を実施している場合に、脆弱性評価を１０分の３とするのは定量化手法としては理解できても、脆弱性が0.3であるかどうか依然不明な訳です。

努力賞の視点では不足。方法論の有無に関わらず、防御できなければ脆弱であるとするのです。そんなことは誰でも承知しているが、脆弱性の度合いを客観的に把握する方法論がありません。

脆弱性の議論には渋滞対策の議論に通じるものがあります。もしくは転移する癌細胞を追い掛け回すようなところです。問題（脅威）は一つの現象であって、本質的な問題に突き当たっていない場合です。

問題（脅威・リスクの現象）に対して対策を整理してみる。既知の対策、未知の対策、また採用した対策、採用していない対策に分類し、次にそれぞれの対策の有効性を評価してみる。

と、既に自己矛盾を来たしていることに気づく。

「脆弱性とは管理策の有効性の欠落の度合いを言う」のかな？。言葉としては間違っていないかもしれませんが方法論的には単に裏返しの表現をしたに過ぎません。「Aを知るにはBを知ることが必要だけど、Bを知るにはAを知る必要がある」と言っているようなもの。自己矛盾でしょう。

.*.

実績から方法論の有効性あるいは脆弱性を評価する発想もあります。このやり方で今までインシデントは発生していない。だから方法論として有効。脆弱性もない。如何？サンプルの規模とインシデントの把握の程度に問題が残ります。

.*.

方法論の故障率も検討する必要があります。既知の管理策の有効性の一部を構成する概念ですが、管理策の中に人が介在する場合はヒューマンエラーを評価する必要があるし、機械化した場合は機械の故障率を評価する必要があります。エラーも故障も無く機能しても１００%食い止めることができるわけではないことは明らかです。その部分が方法論の有効性に相当します。

.*.

脆弱性は防御率の逆数でアナログ的に捉える前提がありますが、一つ一つの事象では脆弱性に付け込まれるか否か、１か０かです。ハッカー集団が狙いを付けたら現時点では防ぎようがありません。未知の管理策が求められます。

.*.

構造的には、１つの資産に複数の脅威、１つの脅威に対して、複数の管理策（既知・未知、実施済み・見実施）があり、管理策はそれぞれの有効性（方法論として確立しているか＝業界に定着した方法論か、及び方法論の故障率を考慮）がある。

未知の方法論に基づく管理策とは？　業界としての共通の課題認識を持つものを未知の方法論として予約しておく。

.*.

発想を変えて脆弱性を見てみる。

インシデント発生時に説明責任が付くであろう業界の常識レベルを中央値として評価を開始する。

• 中央値：１－４段階なら2.5となる。
• 業界レベル以上なら2とする。
• 業界レベル以下なら3とする。
• 対策未着手または説明責任が付かないレベルなら脆弱性最大のレベル4とする。
• 体制・経費とも業界最高でリーダー的レベルなら脆弱性最小のレベル1とする。

このアプローチは簡便で良いが、世間知らずが評価すると何でもレベル１になってしまう欠陥がある。複数の外部コンサルタントや助言サービスを受けることで一人合点を回避できる。

.*.

使ってみようか空港ラウンジ

使ってみようか空港ラウンジ

自分が利用する当てもない空港ラウンジをチェックしてみる。

http://www.saisoncard.co.jp/lineup/lounge.html

• 新千歳空港：ターミナルビル３F　スーパーラウンジ
  北海道へ行くチャンスは無い訳ではないがお土産を探して時間いっぱいでしょう。
• 青森空港：ターミナルビル２F　エアポートラウンジ
  先ず青森へ行くチャンスが見込めない。
• 秋田空港：国内線ビル２F　ラウンジ「ロイヤルスカイ」
  チャンス見込めず。
• 仙台空港：ターミナルビル３F　ビジネスラウンジ
  仙台へ行くのにここは使わない。仙台から北海道か西日本へ向かう場合だけだろう。利用するチャンスは見込めない。
• 新潟空港：ターミナルビル３F　エアリウムラウンジ
  新潟へ行くのにここは使わない。新潟から北海道か西日本へ向かう場合だけだろう。利用するチャンスは見込めない。
• 成田第１：第1ターミナル本館５F　IASSエグセキュティブラウンジ
  海外へ行くチャンスなし。寂しいな。
• 成田第２：第2ターミナル本館４F　IASSエグセキュティブラウンジ２
  海外へ行くチャンスなし。寂しいな。
• 羽田第1ターミナル：第1ターミナル２F　エアポートラウンジ（北・南）
  第1はJAL系ターミナル。2箇所あるんだ。
• 羽田第1ターミナル：第1ターミナル１F　エアポートラウンジ（中央）
  ここにもあるから南北とあわせて計3箇所か。知らなかった。
• 羽田第２ターミナル：第２ターミナル２F/3F/4F　エアポートラウンジ
  こちらはANA系。同様に3箇所。知らなかった。九州方面へ行くときは南ピア２F、北海道方面へ行くときは北ピア４Fのラウンジ利用が便利かもしれない。
• 羽田国際線：ターミナル４F　Sky Lounge
  利用しないもんね。
• 中部セントレア：ターミナルビル３F　プレミアムラウンジ「セントレア」
  殆ど利用しません。
• 伊丹空港：２F
  結構利用することもあったはずだけど、ラウンジに行く気にはならない。
• 関西空港：出国審査前1箇所（３F)、出国審査後3箇所（２F)。
• 神戸空港：２F
  どうせ便数が少ないから利用することも無いでしょう。
• 広島空港：２F
  ここも飛行場が遠い。バスの中でラウンジタイム終了。
• 高松空港：２F
  飛行場が遠いからバスに乗っていて十分リラックスしてしまう。
• 松山空港：２F
• 徳島空港：３F
  阿波踊り空港にもラウンジあったのか。知らなかった。キャンセル待ちまで長いのでラウンジ利用は有用だね。
• 福岡空港：３F
  割とジャストインタイムで付くからラウンジまで行くことは少ない。ここはビール１缶が無料サービスです。
• 長崎空港：２F
• 熊本空港：２F
• 鹿児島空港：２F
• 那覇空港：１F北
  お土産をチェックしt時間は消えたかな。でもお店が少ないからラウンジ利用も悪くない。
• ホノルル空港：１F

出張なら構わないがプライベートでは同伴者1千円は高いね。

.*.

寸暇を惜しむ諸先生

寸暇を惜しむ諸先生

コンサルタントも審査員も時間に追われるのが基本形。時間能率が問われる役務サービス業だから当然のことでもある。

特にコンサルは超高額料金を請求するので、顧客に特化した領域の業務、カスタマイズした部分も手抜きはできない。

一方、審査員は金額は知れているが、持ち時間が限られているので時間能率を追求することになる。

彼らは、

＜ランチタイム＞
お昼休みもさっさと食事を済ませてパソコンに向かう。クライアントと同席のときは雑談というサーベイに勤しみ、クライアントが中座すると途端に仕事モードになる。

＜新幹線・特急列車＞
審査計画/コンサル巡回計画の中でサイトからサイトへする時も、周りの様子を伺いながら仕事を始める。セキュリティを本業にする割には結構大胆な先生もいらっしゃる。新幹線とか特急列車の中は当然。流石に通勤電車レベルだとギブアップするらしい。

＜フライト＞
フライトの中は、列車などに比べると前後左右が接近しているので、慎重になるようだ。

＜喫茶店＞
クライアント先訪問時刻までの時間調整を喫茶店などで行うときも、ゴミ具合と本人の逼迫度によって、やはり大胆になる先生が出現する。マクドナルドなどは無線LANサービスがあって利便性も高い。欠点は空いているマクドナルドが少ないこととか。

＜ホテル＞
ホテルは当然、インターネット接続環境を提供するところになる。机の狭いホテルは嫌われる。机が広くても余計な説明書などが所狭しと並べられたようなホテルも敬遠される。豪傑の先生は、ツインのシングルユースを標準にしている。ツインルームは部屋も広く、テーブルも大きい。シングルユースだと料金もそれほどでない。

.*.

空港ラウンジ

ドリンクサービスもあるし、無線LAN サービスもあるし、スペースもゆったりしていて殆ど申し分ない。しかも、ラウンジはエアポート内の割と不便なところにあるので客が込み合うことも無い。

空港に早めに着くようにしてフライト待ちの時間をユックリ利用したい。もっとも、JAL/ANAのゴールドカードだと、セキュリティチェックを通った後でラウンジが利用できるので利便性は格段。

一番安いセゾンカードは結構厳しいかな？

セゾン空港ラウンジサービス

.*.

情報セキュリティ損失額の算定

情報セキュリティ損失額の算定

コストは管理策の実施に当たって既に発生しているが、インシデントが発生した場合もコストが発生する。

1. 予防のコスト
2. 是正のコスト
3. インシデント対応コスト

どのコストについても満足できる形で把握している組織は少ない。何故か？　そのコストを活用する方法論を持っていないからか？、そのコストを把握する方法論を持っていないからか？、またはその両方か？。

どの組織でも、情報システム投資は膨大なレベルに達している。情報セキュリティ投資は情報システム投資の一部が当てられるケースが多い。が、全てではない。CIO(情報担当役員）が統括したシステム投資のほかに、CISO(セキュリティ担当役員）を置いても、予算統括機能にまで踏み込んでいる例は少ないだろうと思われる。分離することの是非も明確でないし、分離する方法論も明確でないからだ。CISOは名誉職・御意見番・コーディネーターの域を超えられない理由でもある。

.*.


想定外コストである、是正のコストとインシデント対応コストについては、経営の意志として把握に努める必要があるだろう。リスク値（期待損失）との対比となるコスト把握はISMSに取り組む意義の検証に供するデータともなるため極めて重要である。

.*.

脅威の発生頻度

脅威の発生頻度

期待損失を算定する数字になります。普通は年度当たりの期待損失の算定です。発生頻度は、年間の発生頻度として統一しておくことが混乱が無くて分かりやすくなるでしょう。

CIA喪失による損害額をもって資産価値としているから、資産価値と脅威を掛けて導き出すのは期待損害額になる。脅威を年間頻度としておけば、リスク値とするものは年間期待損失になる。

.*.

期待損失は、受容レベル以上・以下に関わらず発生する損失の見込み額であるが、実績と対比することが出来れば、より合理的な施策展開が可能になる（かも知れない）。セキュリティ被害額を算定できるように仕組みを作っている例はあまり見ない。組織における今後の課題の一つになっていくだろう。

.*.

審査時間ってどれくらいですか？

審査は１日７時間？8時間？＋昼食１時間。午前9時スタートで、午前3時間。午後は13時スタートで、午後4時間。17時終了が標準の１人日。昼食時間を30分程度前後させることはよくあるらしい。注意すべきはランチタイムに現場に出ても誰も居ないこととか。

１時間に１０分程度の休憩？は任意。任意と言いつつもヘビースモーカーには欠かせない休憩のようだ。

移動時間は審査時間にカウントしない。ちょっと微妙かも。全体で工数を１０としたら、現地は８割？以上。残りの最大２割は移動時間とか準備時間に当てて良い？または文書審査？

移動時間は審査時間でないのだったら２割を移動に当てるって矛盾していないかい？。標準工数の８割で審査をしても結構ということなの？

準備工数は審査工数に含むの含まないの？

２割を準備工数に入れるのかな。

準備工数が必要という案内は出ていたかな？。全体の１割程度かな？

現地の審査工数X、準備工数Y、移動工数Z。

発生する総工数T＝X＋Y+Z
Y=X*０．１
Z=X*０．２
T=X*1.3

JABのサイトをしっかり見ていないと、諸先生の話だけでは、それぞれ所属する機関毎に異なる内規のようなものが混在して分かり難い。

.*.

聞きかじりを繋ぎ合わせると辻褄が合わない。全く変な話。よく聞いてから書き直しだ。

分かるようで分からない「脅威の発生頻度」

分かるようで分からない「脅威の発生頻度」

この概念のなんと理解し難いことか。諸先生の話を何度聞いても分からない。先ず、脅威の大きさを発生頻度だけで論じることに抵抗を感じる。発生頻度に落とすと言うことは、それ以前に識別された脅威は、脅威の大きさの概念を併せ持つと理解せざるを得ない。

脅威には、「脅威の種類＋脅威の大きさ」があって、その上でそれの発生頻度を見定める形になる。

脅威の種類：地震
脅威の大きさ：震度６
発生頻度：10年に1回
これでワンセット。


脅威の種類：地震
脅威の大きさ：震度３
発生頻度：1月に1回
これでワンセット。

震度３は普通のオフィスでは無視できる。震度６に着目して分析すればよい。ところが、精密作業工程が入る場所では震度３も無視できないが、震度６への対応で包含できるなら無視できる結果になる。では、震度8（？存在するかな）が500年に1回発生する場合は、普通のオフィスはぎギブアップ（リスクの受容）するだろうが、データセンターとか震災時の対策本部では受容とは行かないだろう。ギブアップの場合は、発生時のコンテンジェンシープラン、事業継続計画での対応となる。若干、理解が進んだ気がする。

.*.

地震と言う脅威の発生頻度は何となく分かるとして、インターネット経由する不適切アクセスという脅威は、年に何回というオーダーでなく数分、数秒に1回発生しているが、これも頻度として横並びにしていいのかという疑問が沸く。ここでも、脅威の大きさ（言い換えれば深刻度合い）をどのように捉えるかがポイントになるのだろう。情報資産のCIAを脅かす程度の深刻さをもつアタックの頻度は？と考えると様子はガラッと変わってくる。ファイアウォール（既存の管理策）が働いているからに他ならない。

成程ね。情報資産価値CIAのいずれかに影響を及ぼす程度の脅威、しかも既存の管理策を乗り越えてやって来る脅威（この場合はリスクなんでしょう）についてのみ、頻度を推定すればよいことになる。

ソニーがアノニマスグループに狙われたように特定集団の標的になるケース、既存の管理策に穴が開くケース、新たに発見された脆弱性への攻撃、新たに作り出された手口など。

.*.

と、無理やり考察を続けてきたが、時間軸をどのように区切ればよいかの答えが出せるとは思えない。

脅威の頻度とは何か。インシデントの発生頻度でしょうか？その為の対策の頻度でしょうか？その為の管理スパンのサイズでしょうか？

最低の頻度として、「殆ど発生しない」を入れるのは所謂ナンセンス。必要なら事業継続的な観点の施策を検討すればよい。頻度の管理スパンに入れるのは意味が無い。企業経営における管理スパンを見た方が、時間軸のサイズを捉えるのは分かりやすくなりそうだ。

中長期計画（2年～10年）、長期計画（2年～10年）、中期計画（2年～3年）。2カ年計画、年度計画、上期・下期の半期計画、四半期計画、月度計画、週次計画、日次計画、業種・業務によっては1日をもう少し区分して計画管理するケースもあるだろうが、「計画管理」のスパンは概ねこのような刻みになる。中長期計画に力点を置かない（作成しない）企業もあると聞く。経営のスピードに対する考え方も変わってきているようだ。

• 中長期計画のスパンで遭遇する可能性を認める。（1000～3000日）
• 年度または2カ年計画のスパンで遭遇する可能性を認める。（300～600日）
• 月度または四半期計画の中で遭遇する可能性を認める。（30～90日）
• 日次または週次計画の中で遭遇する可能性を認める。（１～7日）

あまり特殊でない業種業務なら、上記の4段階設定は収まりが良さそうだ。個々の事情を反映して組織の区分とすればいいだろう。

.*.

さてと、次は「頻度の掴み方」です。

例えば、携帯電話を紛失するリスク。脅威は内的・外的を含めて色々ありそうですが、結果紛失することは、年度または中期的スパンで発生する可能性を認めるでしょが、1千人も従業員が居れば、毎月のように紛失事故は有り得る話です。

携帯電話が今後スマートフォン化することを視野に入れれば、個々の頻度は小さくてもカテゴリーで捉えた時の頻度も考慮したくなるものです。「脅威の積み重ね効果」を織り込む方法論が必要に思われます。統計分析的なアプローチを踏まえたカテゴリーリスク・カテゴリー脅威の理解を事務局部門は試行すべきです。

.*.

個々の情報資産に対する脅威・脆弱性だけでリスクを評価していると、カテゴリーに対する適切な施策を打てない懸念があります。詳細リスク分析アプローチの弱点と理解していいでしょう。これを回避するにはベースラインリスク分析アプローチが有効に成ります。

「脅威の積み重ね効果」への対応にはベースライン方式。

「ここの脅威」への対応には詳細方式。

この両方を併用することが必要。ベースラインで全て間に合わせるのは個々の事情が反映されていないので返って無理なやり方を強いることになりかねません。

.*.

脅威の洗い出し

脅威の洗い出し

脅威と脆弱性を分離して理解できるかどうかは案外難しいものだそうです。括ってリスクと表現しても極めて自然に思える。わざわざ分離する意味があるんだろうか。

あるオッサン先生は言ってくれた。自分でコントロールできないものが脅威だと。本当かな?　天気は今の技術ではコントロールできないから脅威。でも、その内、コントロールできるようになれば脆弱性なのか。

コントロールできる領域が広がれば、脅威は萎縮していくのは当然のことかも知れない。管理策のスパンが広がるから、脆弱性の付け入る隙が出てくる。

先ず、情報資産を取り上げて、この資産に対する脅威またはリスクを並べてみる。

実施中の管理策、今後可能な管理策、他社等で方法論として確立している管理策を並べる。方法論が確立していない管理策・アイデアを並べる。

＜脅威・リスク＞＜既存の管理策＞＜予定の管理策＞＜未来の管理策＞

脅威・リスクから防御するためにできることは、

• 既存の管理策の効果を上げる。
• 予定の管理策を実施に移す。
• 未来の管理策を引き寄せる。

.*.

話を戻して。では、「脅威・リスクの洗い出し」はどのようにやりますか？。方法論としては地道にやるしかありません。以下の項目の一部または全て含むリスクを洗い出し、データベース化し、メンテナンスを定期的に行うことが求められます。

1. 情報の保管状況から想定できるリスク
2. 情報の移動方法から想定できるリスク
3. 情報の利用方法から想定できるリスク
4. 管理者・利用者等のヒューマンエラーに関連するリスク
5. 疲労・風化・拡散に伴うエラー
6. 技術革新・制度改革・イノベーションに伴うリスク

以上を手掛かりに、機密性リスク・完全性リスク・可用性リスクの全ての側面について、脅威・リスクを洗い出し、脅威の発生頻度を評価することが求められます。

＜１つの資産＞＜3つの側面＞＜6つの脅威・リスク領域＞＜発生頻度評価＞：既にケーススタディのツリーは膨大な量になりますし、意味も分からなくなります。ここでは網羅的にやるよりも主要なものについて評価することが大事です。可能なら3つの各側面で最大となるもの着目します。

ISMSは継続的な活動ですから、一番目立つものから順番に押さえ込んで行く考え方で十分ですし重要です。最初から網羅的でなくても構わないと理解すること、具体的に歩を進めることが出来ます。漸進ですね。

.*.

Why Not? 情報資産の洗い出し

Why Not? 情報資産の洗い出し

この基本的なことが出来ていない。抜け漏ればかり。何が資産か把握できていなければISMSの後工程は全く無意味になります。コンサルに行っても疲れるだけです。どうして普通に出来ないのでしょう？　


＜洗い出しの抜け洩れの例？＞

1. 静的に保管しているものだけが洗い出される。キャビネットの中だけをリストにしている。
2. 個人管理の資料は洗い出しの対象から外す。デスクの袖のキャビネットが外れる。会社のあるいは業務の情報資産で溢れかえっているのに、不思議なことだ。
3. サーバー内の情報は情報システム担当が管理しているから部門の情報資産から外す。おいおい情シ部は器の管理しかしていないよ。彼らは中身には関与しません。
4. 発送する予定の情報類。一時的に入り口にあるが郵便やとか宅配やが来て回収するからリストに入れないよ。
5. 今日中にお客さんとか営業とか管理部門に届ける資料も同じだ。
6. メディア類。USBメモリー、CD/DVD、テープ類などは、中身が空っぽもあれば、ゴミ情報もあれば、重要情報もあれば、と不確定的ですから始末が悪い。コンテンツを識別して、メディア自体は対象から外す。
7. 共有資料というけど、管理責任者不明の資料。倉庫の隅に積み上げられている。キャビネットの一角に門外不出のように置かれている。時には通路の脇に何年も置きっぱなし。
8. 持ち主不明の資料。部門が解散・分離したときに誰も持っていかなかったもの。部門ミッションが変わって宙に浮いてしまった資料。
9. 前任者から引き継いだけど、内容を理解できていないもの。業務上の資料としての意味が無く、誰かに何かを聞かれた時に困らないように捨てないでいるだけの資料。
10. 資産リストとか資産台帳とかの名前は付けているが単なる分類表・区分表・カテゴリー一覧に過ぎないもので済ませるケース。分類・区分が思いつかないものは全て「その他」区分で済ませる。

.*.

＜業務フロー/業務プロセスに沿った洗い出し＞

業務フロー/業務プロセスを書き出してみる。手順に沿ったフローチャートが出来上がる。

各処理のところで、参照する情報、出力する情報を書き出す。情報の内容・情報の所在、入力または出力の方法も記載する。

単純な作業に思えてなかなか面倒。

先ず、何の障害もなくスムーズにことが運んだ時の基本形。次に、例外のフローを書き加える。例外が夥しいほっど多い。人によってやり方が変わる。

問題は、基本の流れでは業務標準が出来ているが、細かい部分は実に何も決まっていないことに気づく。そういうものらしいです。資産の洗い出し（たな卸し）が、業務標準細則の策定作業に変わるのです。今までいい加減にやってきたことですからしようがありません。

もっとも、洗い出し自体は、複数のやり方が並存しても出来るので、先行して進めても問題はありません。無駄をなくすために、後で、何を標準とするか決めれば済むことです。

.*.

＜洗い出されなかった情報資産の特定＞

必要な情報が洗い出されると同時に、どの業務でも参照されない資産が存在するかどうか。プロセスの合理化を進めると中間生成物のような情報は最後には不要とされるケースが多い。自分たちの管理スペースに存在する情報資産で業務プロセスからの引用が全く無かったものを識別し、一定の見極め期間を置いて廃棄する手順が必要になります。

この場合は、静的な情報資産の洗い出しはやはり必要となる。

業務プロセスIDと情報資産IDがあると想定して、プロセスIDから資産IDを引き当て、また資産IDからプロセスIDを引き当てることが出来る。しかし、机上論の展開はできるが、現実にどの程度可能かは一概に言えないでしょう。意味がある範囲において、意味のあるサイズ（かたまり）に対して、プロセス・情報資産ともやればいいということらしい。軌道修正しながら進めるのが現実的なアプローチでしょう。

.*.

ISMSと5S活動

ISMSと5S活動

5Sってなんでしたか？

5S

http://ja.wikipedia.org/wiki/5S

1. 整理（せいり）いらないものを捨てる
2. 整頓（せいとん）決められた物を決められた場所に置き、いつでも取り出せる状態にしておく
3. 清掃（せいそう）常に掃除をして、職場を清潔に保つ
4. 清潔（せいけつ）3S（上の整理・整頓・清掃）を維持する
5. 躾（しつけ）決められたルール・手順を正しく守る習慣をつける

基本のキ。組織、集団、グループの中に居る時に要求される人間の基本的な振る舞い。行儀よく言っているが、臭い奴、汚い奴、危険な奴、気の触れた奴などとは付き合いたくない。

５Sが出来ていない会社は、トップがいくら格好を付けていても必ず現場に足元を掬われるのは間違いない。現場を見ないで能書き垂れているのだから、自業自得というものだ。

.*.

ISOとかISMSとか言う前にやることあるだろう。机の上に雑然と資料を置いたまま。「重要な資料ではありません」と言うが何の言い訳になると言うのだろう。机の下にも資料類が積み上げられている。「スペースが無くて」と言うがそれで済むのかね。そうでなくても普通に、机の引き出しを開けると、その席の主の仕事振りが分かる。キャビネットとかロッカーを開けると、そのグループの仕事振りが分かる。倉庫を開けるとその会社の仕事振りが分かる。サーバールームが倉庫代わりになっているなんて良くある話、だそうだ。

ISMSの審査員と来たら、情報資産の管理レベルについて、苦しく物申ししているが、中にはケシカランと憤慨して重大な不適合の爆弾を落とす輩まで居る。規格に照らせば疑問が無いわけでもないが、そもそもPDCAを回す意思が組織全体に欠落していると捕らえていると理解すれば重大な不適合とすることが分からないこともない。

重要な情報資産も、販促品も、粗大ゴミも、イベントの小道具も、着替えも、もう何でも入っていて、誰でも出入り自由で、倉庫でござい。倉庫の壁にMDF（通信の出入り口）が着たり、サーバーが設置されていたり。入り口には倉庫とかPRIVATEとか記載して。

コンサルは勿論、審査員も、内部監査員も、業務監査も、全員が素通りして行くらしい。

.*.

５S無視は重大な不適合と心得よ！

.*.

スマートフォンのセキュリティ問題

スマートフォンのセキュリティ問題

スマートフォンとはポケットに入る多機能電話+ノートパソコン。iPhoneはiPod Touchに通信機能を持たせただけのはずが、パラダイムシフトのトリガーになった。ジョブスは見抜いていたんだろうか。

スマホのセキュリティはパソコンのセキュリティと何が違うのか？

ノートＰＣに対する管理策と似たものになる。+携帯電話に対する管理策。

＜装置に対するセキュリティ＞

• ロック機能
  ・本人の側を離れたら自動ロック。
  ・遠隔から強制ロック。
• データ削除
  ・認証失敗をある条件で自動削除
  ・遠隔から強制削除（オフの状態でも削除）
• ハイレベル認証
  ・虹彩・指紋・音声など複数のバイオ認証+ピンコード
• クラウドベース（シンクライアント）
  ・データをスマホ上に保存しない。
• 常時暗号化・圧縮化
  ・メモリ内の情報の暗号化
  ・同時高圧縮
• 自爆装置
  ・ある条件を満たせば自動的に全ての情報を削除し、ファームウエア自体も破壊する。

＜利用に対するセキュリティ＞

• ウイルス対策ソフトは常識
• カメラ・ビデオの不適切利用防止
• 画像・映像・音声のセキュリティチェック（コンテンツチェック）
• 定期インターバル虹彩認証

.*.

「スペクタープロfor Android via メール」がWBSで紹介されていた。ＡＯＳテクノロジーズ社の商品かな。５月発売開始で既に３千本販売。６５００円。

.*.

可用性価値

可用性価値

• レベル１：情報に必要なときにアクセスできなくても損害は発生しない。”必要な時”と言うのが難しい。極端なケースでは、”いつでもいいから提示してください”と言われて、それに対する否定的回答は”いつ提示できるか回答できない”と言うもの。即ち、行方不明状態。保管していない状態。

• レベル2：必要な時にアクセスできない場合、損失は軽度。担当者による説明責任。

• レベル3：必要な時にアクセスできない場合、発生する損失は中度。部門マネジメントによる説明責任。部門長・マネジャーへの懲罰。

• レベル4：必要な時にアクセスできない場合、発生する損失は重度。事業継続が困難。事業継続管理が発動される。顧客情報・個人情報の重要なものを含む。経営上の重要事項を含む。経営陣による説明責任を問われる。マスコミから叩かれる。社長・経営陣への懲罰・交代・失脚。

.*.

可用性性価値で注意を要するのは、アクセス要求に対するレスポンスタイムの長短でレベル区分をする例が多いこと。２時間以内のアクセスレスポンスがレベル３、翌朝までのアクセスレスポンスならレベル２、１週間以内ならレベル１など。被害の大きさとレスポンスタイムの相関は単純には設定できないからだ。

業務プロセス分析による情報資産の洗い出しに置いて、利用者と要求レスポンスとレスポンスアウトした時の被害額（被害レベル）を明らかにしておかなければいけない。

当該情報が複数の業務プロセス、複数の利用者に関連する場合は、その中で最大の被害についてレベル算定することになる。被害最大となる場合のレスポンス要求時間も抑えておくことが必要になる。（ヘルプデスクとかテレフォンセンターでは問い合わせ回答に１分も掛かれば不適当とされるが、それで会社が危機に陥る訳ではない。

可用性価値の難しさは、被害額は想定レスポンスから遅延する程度とある程度相関することによる。

◆　被害額Ａ＝紛失時被害額～レスポンス遅延時被害額。

最大値はレスポンスタイプ無限大に相当する。最小値はプロセス要求を少しでも外した時の被害額。可用性価値は本来はプロセス要求を外した時の被害額で算定すべきだろうが、管理策を適切に選択できるようにするには最大値も考慮する必要がある。リスクアセスメント自体を簡便化するにはレスポンス無限大時の被害額を入れて算定すれば良い。

.*.

完全性価値

完全性価値

• レベル１：情報が不完全（間違い、破損、改ざん、抜け盛れ、バージョン違い等）でも、損害は発生しない。

• レベル2：情報が不完全な場合、発生する損失は軽度。社外の人による取り扱い不可。担当者による説明責任。

• レベル3：情報が不完全な場合、発生する損失は中度。担当部門・部署以外による取り扱い不可の区分。部門マネジメントによる説明責任。部門長・マネジャーへの懲罰。

• レベル4：情報が不完全な場合、発生する損失は重度。事業継続が困難。事業継続管理が発動される。顧客情報・個人情報の重要なものを含む。経営上の重要事項を含む。担当者外の取り扱い禁止。経営陣による説明責任を問われる。マスコミから叩かれる。社長・経営陣への懲罰・交代・失脚。

.*.

完全性価値で注意を要するのは、完全性価値の連鎖を把握できているかどうか。その情報が改ざんされることでどの範囲まで影響が及ぶかを判断できるかどうか。

.*.

完全性価値レベル１の意味：

平気で完全性を１にしている組織があるらしい。完全性を喪失しても全く構わない情報とは何か。二度と利用しない情報のことである。棄てる予定の情報。ハードウエアであれば正しく作動しなくても構わない機器類。間違ったロジックのアルゴリズム。検証されていない方法論。

.*.

機密性価値

機密性価値

• レベル1：誰が見ても構わない。

• レベル2：許可された人以外の人が見た場合、発生する損失は軽度。社外秘レベル。担当者による説明責任。

• レベル3：許可された人以外の人が見た場合、発生する損失は中度。担当部門・部署以外への開示不可の区分。部門マネジメントによる説明責任。部門長・マネジャーへの懲罰。

• レベル4：許可された人以外の人が見た場合、発生する損失は重度。事業継続が困難。事業継続管理が発動される。顧客情報・個人情報の重要なものを含む。経営上の重要事項を含む。担当者外秘の区分。経営陣による説明責任を問われる。マスコミから叩かれる。社長・経営陣への懲罰・交代・失脚。

ISMSのKPI

ISMSのKPI

キー・パフォーマンス・インジケータ。重要な有効性指標、あるいは重要な達成度指標。

この議論は簡単に始められるが、着地させるのは難しい。「目的と方法」論に対する共通理解が得られないと議論が進まない。目的と目標についてすら共有できないのが普通。理念とかビジョンとかを持ち出すと議論は水平線の彼方からやり直す羽目になる。

価値観の軸が一通りでないから、議論はねじれ、退散するしかなくなってしまう。

.*.

しかし、一定の前提をかぶせることで、具体的で建設的な議論は可能となる。

いずれの場合も、社会価値の側面を見失うことのないようにしなければ、長続きできない。

その点では、ＱＭＳとか、ＥＭＳとか、ＩＳＭＳとかのＩＳＯは手ごろ。

.*.

ISMSの価値はよく理解できるとして、目指す方向はリスク値の適正化。但し、リスクを静的に捕らえた適正化で無く、動的に捕らえた適正化です。

規格を丸写し！手抜きのISMS構築は通用するか？

規格を丸写し！手抜きのISMS構築は通用するか？

規格を写しただけの規定～マニュアルで済ます会社。あるいは、コンサルから提示されたサンプルをそのまま利用する会社。

割と普通のこと！。構わない！。写した後の展開が問題。

何処まで実務に落とし込むことが出来るか。規定からのリンクを辿って、最後に一人ひとりの業務マニュアルに行き着けば、仕組みの形としては完成です。これは、所謂、トップダウン手法ですが、殆どの場合、失敗します。新たに組織を作る場合でも難しいでしょう。

実務をベースに規格（ルール化）するのが普通。ボトムアップ手法が現実的で成功する。

.*.

事務局は規格を写して済まし、後は部門任せ。部門は立ち往生。事務局から具体的な個別の指示が出たときだけ本社に付き合う。完全に指示待ち。改善意欲は完全にそがれている。

事務局が楽することを考えたら失敗は当然。

リスクアセスメントは何段階評価にするか？

リスクアセスメントは何段階評価にするか？

手を抜くには３段階。どうせ段階評価なんていい加減な妥協の産物。ここを木目細かくやっても有効性は上がらない。但し、３段階は心理操作が入るので進められない。中心選択が出来ないように偶数段階にするのが今どきの常識。４段階。

資産価値も、脅威も、脆弱性も、全て分かり易いように４段階。

◆　４（価値）×４（脅威）×４（脆弱性）＝６４（リスク値）

脅威と脆弱性を括って被害の発生確率とするケースもある。

◆　４（価値）×４（発生確率）＝１６（リスク値）

しかしこれは分析が更にラフになるから勧められるものではない。特に脆弱性に対するアプローチが曖昧になるのはリスクアセスメント全体のスキームをスポイルするので致命的とも言える。

.*.

面白いことがある。機密性だけ４段階にする話だ。完全性、可用性は３段階にしたまま、機密性だけ４にするというのだ。馬鹿げた話だ。正しい資産価値評価も出来ないし、リスク値の意味まで本質を失ってしまう。

リスク値は本来、期待損失のこと。可能なら被害額を算定するのが正しい。被害額算定の方法論が簡単でないから、段階評価をやっているに過ぎない。だから、ＣＩＡのどの側面を喪失しても、被害額は同じ軸（本来は金額）で求められなければいけない。

ＩＳＭＳが流行りだした初期のころは、ＣＩＡで段階を分けるような間違いの他に、ＣＩＡ各側面の資産価値を足したり、平均値を出したり、あるいは脅威と脆弱性を足したり掛けたりなどと頓珍漢のロジックを組むところがあった。コンサルの罪は重い。審査員も合理性を求めないで見て見ぬ振りだから同罪。と言うか、本質を殆ど理解していない審査員も少なくないようだ。

既に１０年を経過した今の時代でも、その名残を引きずるＩＳＭＳは結構ある。ご都合の見よう見まねの結果です。

.*.

意外と難しい「弱点の報告」！企業文化が邪魔する方法論？

意外と難しい「弱点の報告」！企業文化が邪魔する方法論？

大きい事故の前に、いくつかの小さい事故が起き、小さい事故の前に、いくつかのヒヤリ・ハットが起きる。これ世間の常識。一般論ですから誰でも理解できることですが、実態は如何でしょうか。

1. 大きい事故が起きると、社長がたまらず陣頭指揮を取らざるを得ない。辛いだろうが、カメラと時には罵声を浴びる場に身をさらす。直接、間接に相当の被害が出る。営業も止まってしまう。後手管理もいいところで、場合によっては管理不能に陥る。
2. 小さい事故が起きて手を打つのは普通の会社。こちらもスタンスは後手管理ですね。
3. ヒヤリハットの先手指標で手を打つはエクセレント企業の始まり。

 こんなことは誰も知っていること。問題はどのように先手管理を実現できるかです。

事故の識別：

いろいろなアイデアがあるだろうが、被害額で分けるのは結果指標を使うため、事故当初の識別には向かない。

割と分かりやすいのは、事故が、顧客プロセスに影響するものか、他部門プロセスに影響するものか、自部門内のプロセスに収まっているか、で分けるもの。顧客資産に影響する、他部門資産に影響する、自部門資産にとどまる、で分ける発想も追加していいでしょう。

セキュリティ弱点の報告：

弱点は事故未満だから、収集するのは実はもっと難しい。被害者が発生していないので、即座に騒ぎになる訳でもない。日常的に発生しないので有耶無耶にされることも多い。自分の失敗を打ち明けることになる、または他人の失敗を言いつけることになるので、メンタル的にも抵抗がある。セキュリティの弱点は情報を収集すること自体が難しい。

取り扱いが微妙で難しいものを、事件事故報告書やインシデント報告書の書式で求めるやり方は最低の方法。弱点の報告は無用と宣言しているのと同じレベル。無頓着のきわみ。

先手管理、予防処置の重要ファクターになる弱点の報告は、企業文化（カルチャー）を反映させることも必要で、一概に方法論を示すことには無理がある。参考までにいくつかのアイデアを提示することは可能かもしれない。

.*.

気休めのバックアップ？

気休めのバックアップ？

説明責任を果たす目的だけのバックアップ作業。こと（一大事）に及んでバックアップが有効かどうかは、あっそんなの関係ない。あっそんなの関係ない。

.*.


頻度、範囲、バックアップの方法論、復旧の手順と試験。定期的な確認。

復旧の手順で大事なのは、純粋に、例えばそのハードディスクだけが傷害を起こして、単に新しいものに交換するだけの前提を置くことで済むかどうかの確認です。HDD障害に至るリスクケースをいくつか想定しないと行けません。都合よく壊れてくれるものではありませんから。別のサーバー上で復旧させる必要に迫られることは少なくありません。

.*.

情報セキュリティの目的

情報セキュリティの目的

管理策の目的は規格に書いてある。附属書（Appendix)にはA.5からA.15まで133個も管理策が並ぶが、それぞれに管理目的が書いてある。目的の数だけでも３０～４０項目はあるように思う。実際に数えると39個。結構多い。目的だらけだ。

5.1
6.1
6.2
7.1
7.2
8.1
8.2
8.3
9.1
9.2
10.1
10.2
10.3
10.4
10.5
10.6
10.7
10.8
10.9
10.10
11.1
11.2
11.3
11.4
11.5
11.6
11.7
12.1
12.2
12.3
12.4
12.5
12.6
13.1
13.2
14.1
15.1
15.2
15.3



目的の目的は何だろう？

杓子定規はゴミ審査・カス審査？

杓子定規はゴミ審査・カス審査？

日付がない。承認印がない。ラベルが貼ってない。資産台帳の抜け盛れ。現象面で把握するヒューマン・エラーをそのまま指摘してくれる。

仕組みの問題に訴求できないなら、詰まらない。

期待する状況と異なる状況を見つけるのは第一歩だろうが、そのまま言うだけでは仕組み（ISMS)の審査にならないのではないか。

1. 問題とした現象は果たして本当にリスクが高いのかどうか。無視できるリスクかどうか。気付いていなかったリスクなら、リスク分析の方法論の問題になるが、特に問題としていなければ自明・受容のレベルとして無視してよい。形式主義に走らないこと。
2. 無視できないリスクの場合も、プライオリティは有る。経営・事業の目的、ISMS導入の目的に照らして、方向性があっていれば優先度は高く、連関が少なければ優先度は下げる。
3. 優先度を上げるとは不適合として対策を明確に求める。優先度を下げるとは観察事項として組織判断に委ねる発想。

ここでは大変難しい側面も顔を出す。審査は杓子定規であるべきとする考え方との葛藤だ。付加価値審査は良く耳にする言葉だけど、一体何が付加価値なのか？簡単でないはず。経営者の意図を何処まで理解できると言うのだろう。余計なことに頭を使わないで、ゴミ・カスも含めて、杓子定規こそが正しい態度とする主張にも納得できる。

.:.

2011年8月末成立の改正特許法の影響？

2011年8月末成立の改正特許法の影響？

コンプライアンスは常識であるがISMSで正しく管理するには案外ゴールは高い。大企業で法律の専門化が社内スタッフとしてあるいは顧問弁護士として組織内においてある場合はタイムリーな対応が出来るが、事務局が片手間に対応では追いつかない。アマチュアがタイムリーに正しい対応を図るのは無理なものです。

.*.

改正特許法：

特許所有企業がM&Aで競合に渡っても継続的に使用するには特許利用契約を特許庁に登録する必要が従来はあったが、登録なしで引き継げることが出来る。（利用契約は依然必要？）

真の発明者でない人又は企業による横取り出願への対策も加わった。真の発明者は訴訟を起こして名義を変更できる。特許の大原則である先願主義から一歩抜け出した改正と言うことらしい。

.*.

訴訟時の証拠提出義務を求める米国司法判断の影響？

訴訟時の証拠提出義務を求める米国司法判断の影響？

米国の状況裁判所の判例が記事になっていた。訴えを起こされた側の責任行為。訴えが不当なものであると主張する場合はそれを根拠付ける証拠を提示できなければいけない。のような感じの内容。証拠が出せない場合は隠匿隠蔽しているとみなされる。判例は続けて2件。

.*.

日本の話ではないが影響は出る場合もある。

.*.

見ていて面白い地雷原を歩くような審査

見ていて面白い地雷原を歩くような審査

前任者の前で審査をやらされる審査員がいるが、これは見ていて楽しめる。ベテランの前で新人がやることが多い。規格どおりに真面目に指摘を始めると、突然に前任の審査員が口を挟み始める。どうしてか。都合が悪いらしい。

前任者が見過ごしていたり間違えていたり都合で容認していることがら結構あるようで、新人はそれを踏みつけないように審査をやらされる訳だ。

地雷が無いところを除けて審査すると、抜け漏れがありましたのでとベテランが口を挟む。

こいつらは関西の漫才師かと思わせる。笑いの絶えない明るい雰囲気の審査光景が続く。

.*.

継続的改善-是正と予防の他にあるもの？

継続的改善-是正と予防の他にあるもの？

改善活動は是正処置と予防処置に限らないと言う主張がある。これは正しいか？

正しいも正しくないも是正と予防をどのように定義するかで、あるいは継続的改善の定義をどうするかで決まる。

規格の中に、それぞれ定義があるので、答えは自ずから出る筈ではあるが果たしてどうなるか興味深い。

間違えないホテルの選択

間違えないホテルの選択

• 築年の古いホテルはj敬遠すること。10年以上は絶対NG。出来れば、築5年未満が望ましい。有名なビジネスホテルチェーンでも初期のホテルは既に5年以上経過しているものが増えてきて要注意。勧められない。・東横イン・ロイネット系/リッチモンド系・ルートイン・ワシントン系（結構古いものが多い）・チサン

• 安ホテルは敬遠すること。安かろう悪かろうの妥協が入り込む懸念アリ。ブランドを確立した有名チェーンの安いのはOKだが、やはり初期の段階のものは安かろう悪かろうが残る。壁・ドアが安くて平気で隣室などの騒音が侵入する。隣の部屋の寝息が聞こえるは冗談としても注意したい。訪問先から少し遠くなっても都市部に戻ることが賢明。
  ・地方ビジネス系（木賃宿？）

• 高級老舗は敬遠したい。高級は高額料金のことだが、手入れは行き届いているが老朽設備が残る。加えて、構造がビジネス利用向きになっていない。
  ・観光地

• 団体客が入るホテルは止めておけ。特に中国人の多いホテルはとても煩い。大規模ホテルは採算を維持するために団体を取るために営業が頑張っているが、一般客には迷惑な話だ。不安がある場合は事前にホテルフロントに照会するのがいい。
  ・プリンス系
  ・観光地

• 目安の料金は、1泊素泊まりで5千円以上～1万5千円以下。1万円±2千円程度が望ましい。

• リニューアルの評価は難しい。目減り対策だから空調・バストイレは新しくなるが構造は変えられない。

• 初めての時は、口コミサイトを必ずチェックする。この2～3ヶ月以内の書き込み、1年前の同シーズンの書き込みを見る。清掃、騒音、空調などは特にチェック。書き込みの返信を入れないところは好ましくない。評価が低いところは論外。評価が高いところもやらせ投稿が入り込むので鵜呑みに出来ない。チェーンホテルの評価は、個々のホテルの評価でなく全体評価を乗せるケースがあるので要注意。

• 自分のホテルリストを作っておくこと。適切にメンテナンスすること。

.*.

チェックリストは間違いの元

チェックリストは間違いの元

誰でも作るチェックリスト。役に立つと思って作るが返って問題の原因になることもある。チェックリストで手間が省けるつもりが、漏れを誘発する原因になる。

コンサルは山ほどチェックリストを作って持ってくるが、それで本当に何が網羅されているのか疑問ばかり。チェックリストとの相互関係となるとまるで分からない。

音信不通になった審査員

音信不通になった審査員

コンサルは時々音信不通になる。珍しいことではない。掛け持ちで仕事をするので、特にトラブルに巻き込まれなくても連絡が付かなくなることは多い。後は、問題が起きているケース。冷却期間を置くつもりで応対しないケースも。もっとも、逆効果もあるのでベテランに限った話だ。

いずれにしても、コンサルが音信普通でも直ぐに困ることは少ない。ところが、審査員の場合は通常審査を控えている、あるいは審査中であるため、いきなり連絡できなくなるとかなり深刻に困る。審査が成立しないからだ。認証の期限が迫った更新審査では更に深刻なことになりかねない。

理由で一番多いのは交通機関のトラブル。審査の中の移動もあれば、個人で旅行中に動けなくこともある。

次が急な体調不良。病院に担ぎ込まれていれば救急医療の方から連絡が入るからいいが、半日以上放置された場合は大騒ぎになる。

そういう意味では審査員は気の毒だが、個人があって個人がない。常に健全な状態で連絡はいつでも付くというのが原則になる。

審査機関は審査員に携帯電話を渡し、GPS機能で監視するとともに、審査機関側も24時間体制を持つ必要がある。昔で言えば、ポケベルを持たされる役割の人が必要と言うことだ。実際にも、実質的に似たような運用をしているらしい。

.*.

ＩＳＭＳの失敗事例：ツール依存

ＩＳＭＳの失敗事例：ツール依存

リスクアセスメントツールを利用すると、殆どの場合失敗します。ツールの利用がもたらすものはリスク痴呆人を生み出すだすことで、適切なリスク評価できる訳ではありません。リスクアセスメントは関数電卓をたたいて解を求める行為とは全く違います。リスクアセスメントは学習プロセスと言う理解が必要です。その辺まで考慮した支援ツールが出てくれば少しは話は変わりますが、現在のところでは先ず見当たりません。

コンサルもツールを勧めるケースは少ない。時間がないとかを理由に、ノーマルなアプローチを投げ出すときはツールで済ますのかもしれません。

事務局一括でのリスク評価のときはツール利用の誘惑が誰しも頭を過ぎります。事務局でやるだけで既に失敗ですから、仮にツールを使っても全体への影響は有りません。既に泥沼の中ですから。

/

ＩＳＭＳの失敗事例：事務局独走

ＩＳＭＳの失敗事例：事務局独走


現象として分かり易い失敗事例は、数人の事務局で殆ど一切の作業をやっているケース。


資産の洗い出しから、資産価値評価、リスク分析評価まで事務局でやっている場合は、単にそのことだけで既に失敗と言える。資産は各部門で出して、その後は事務局とか、リスク分析評価だけ事務局と言う例も多いが、ことごとく失敗。


資産の所有者あるいは管理責任者が資産のリスクを理解しない状況では、リスクを理解する活動がスキップされてしまい、リスクを軽減する活動は適切に行えないことが殆どです。加えて、事務局が適切に価値評価・リスク分析評価を出来ることは先ず有り得ない。


ご都合で御造りのリスクアセスメントだけが出来上がりますが、全く意味がありません。


.*.


手間を掛けず簡単に出来るので、こういうやり方を勧めるコンサルも居ます。ベースライン方式？の一環で規格不適合ではないとのことです。知識習得に時間が掛かるので当初はベースライン方式でやって、徐々により適切なやり方に移行していくと説明します。


これは殆どの場合、大嘘です。一旦定着させたものを引き剥がしながら、徐々にやる方が遥かに大変だし、コンサルは手間ばかりで旨みが無いと思えばすっと消えていきます。付き合ってくれても、若いコンサルに引き継いでしまいます。


事務局も、新たな苦労は避けたいから、意味の無い御造りのままにしていずれ誰かにバトンタッチしていきます。後任の事務局はもう何が問題かすら理解することは有りません。結局、失敗の泥沼から抜け出ることは出来ません。


例外は、トップが裸の王様でない場合は、愚かな実態に気づいてやり直しの号令を掛けることで泥沼からの脱出が出来ます。


.*.

ＩＳＭＳの失敗事例：ＩＳＭＳの独立運用

ＩＳＭＳの失敗事例：ＩＳＭＳの独立運用

関西某企業はＩＳＭＳを始めるに当たってセキュリティは品質と同じ仕事を進めるときの基本要件と言い切った。これは大変重要なことで当企業の見識の高さが伺える。品質の作りこみは全社を上げてプロセスの上流から下流まで一つの例外もなしに徹底する。セキュリティの作りこみも同様に取り組むことが必要。

セキュリティ活動を専門性は異なるものの、広い意味で品質活動の一環とするところは少なくない。そういう位置づけが示される場合は失敗は少ない。品質活動自身がおろそかで、マネジメントシステムを考えるのはＩＳＭＳが始めてという場合は、失敗するチャンスが増える。

全ての部門の本来業務の中にセキュリティ関連の項目が自然と入ることが大切です。

例えば、部門とか担当とかの業務マニュアルを作成するときに、セキュリティを達成する活動も明確にされていることですが、それが無いと危ない。全社共通の規定とかガイドラインはあっても、部門の業務プロセスに展開されていなければ、まだ仕事は半分で終わっていることになる。

.*.


仕事(本来業務）とＩＳＭＳが2本立ての場合はほぼ失敗です。

.*.

ＩＳＭＳの失敗事例についての独善的考察？

ＩＳＭＳの失敗事例についての独善的考察？

そもそも失敗とは何か？


失敗とは目論見を達成できないこと。では、どんな目論見があるのか？

《認証取得の目論見》

1. 既存の取引先の要求だから”兎に角”認証取得すること。取引継続のためには最優先だ。
2. 今後の営業活動に有用だから、取引要件だから、やはり”兎に角”認証取得すること。上記と同じだね。
3. セキュリティ事故を起こして企業ブランドを落としたくない。仮にその場合も社会への説明責任を果たしたい。
4. セキュリティを企業体質に取り込んでさらに強い会社にしたい。体面のためでなく、方法論として有益そうだから認証を取得する。不足を感じたら更に有益な方法論を取り込みたい。

《失敗とは？》

1. 目論見が達成できない。1～3の場合は取り敢えず認証が取得され維持されていれば良い。しかし、４の場合は内容が問題になる。
2. コストが過剰。情報化投資は事業規模の数％から事業特性によっては20%前後まで行くから、セキュリティ投資のその内数に収めたい。情報化投資の枠組みの見直しは必要。
3. 事業をスポイルする場合。事業とセキュリティマネジメントのシナジーが得られないだけでなく事業遂行に問題を起こし本末転倒となるケース。

.*.

残留リスクの理解が意外と出来ていない

残留リスクの理解が意外と出来ていない

ベテランの審査員の残留リスクの説明を聞いて驚く。ここには色んなコンサルや審査員が来るから耳学問でそれなりに知識は身につく。相手が素人と思って油断したのかいい加減に説明されてしまった。

「受容レベルを超えたものが残留でそれを経営者に奉告しなければいけない」と。これは間違い。正しく、需要レベルを上回ろうが下回ろうが全ての存在するリスクが残留リスクで、この全体が報告され承認されなければいけない」のだ。

.*.

間違った理解では、受容レベルを超えたものに対する思索だけに注目する。

正しい理解の下では、受容レベルを超えたものへのに対するリスク低減は当然のこととして、全体のリスクの分布状況などを分析し、更なる改善の手掛かりとすることが出来る。統計的にリスクを理解することで包括的、長期的なマネジメントが効果的に進めることが出来る。

どのような資産がリスキーなのか、どの業務がリスキーなのか、トレンドは悪化の方向か改善の方向か、マネジメントの改善に有益な情報が得られる。

.*.

指摘のエスカレーションは適切に出来ているか？

指摘のエスカレーションは適切に出来ているか？

キャリアが長いだけでなく高い見識の方も時に足を運んでいただけるので、話を聞いていても飽きることは無い。

同じような指摘が多く出る場合、一回の審査で複数の同じ指摘が出るケースもあれば、毎年同じような指摘が出るケースもあるが、いずれの場合も、より上位の管理策で指摘するべきです。と言うことですが、なかなか含蓄が有ります。

ラベリングの漏れ、記録類の記載漏れが、毎回のように、しかも件数もそれなりに出ている場合は、それらをコントロールする手順の問題か、監視問題にエスカレートさせなければいけないということです。

監視も日常の運用上のもので収まらなければ、内部監査の品質、有効性へエスカレーションさせます。さらには、是正処置、経営者レビュー（マネジメントレビュー）へエスカレートさせることになります。

エスカレーションさせるのはISMSを運用するクライアント側でも重要ですが、審査員の力量を見るときにも役に立つ観測手段になります。

記録類の漏れ、ラベル付けの漏れ、資産の洗い出しの漏れを繰り返して指摘していたら、その審査員の力量は少し（大いに？）疑っていいらしい。

クライアントの中でも、内部監査の有効性を見るために、どのような指摘が出ているか時間もエリアもスケールアップさせて眺めてみるのは有益な筈です。

拡大と移転ではどちらがナーバスか？

拡大と移転ではどちらがナーバスか？

ナーバスとは神経質になることの意味だが、それは当然移転のケースです。適用範囲を拡大するときは、新しい事業、新しい場所（ロケーション、サイト）などを追加するのですが、追加する部分がどのような状況であれ、拡大審査が終わって認証へ組み込まれるまではISMS制度上の責任は発生しません。

ところが移転の場合は認証されたもの動いてしまうため、動いたことによって認証の根拠を失う可能性を認めない訳にはいきません。移転（引越し中）と移転後は、セキュリティが適切に維持されているかどうかは制度上は誰も保証していません。移転直後に臨時の審査を受け、維持されていることを確認する必要があります。

移転して何もしないと次のサーベイランス（継続審査）とか更新審査のタイミングまで放置されることになります。無免許運転状態。もしくは偽りのライセンスでドライブ。悪いのは勝手に引っ越して何も言わないクライアントですが、審査機関は１００％免罪される訳でもない。正しい契約をして正しい説明をしているか、適切にチェックしているか等が問われる。

審査機関に馬鹿な営業が居たりすると始末が悪い。臨時審査（特別審査）をやると費用がやはり余分に発生するから、クライアントからの問合せに対して次回の審査の時に一緒に見ます。アドオンの費用は発生しませんとやってしまう。らしい。

そういう事情が絡んでくると、勝手に引っ越しておいて連絡もよこさないのは契約内容に違反していますとは出られません。

杓子定規をやると窮屈で嫌われますから、曖昧なままで済ませるケースが多いらしい。

厳密に言えば、引越した瞬間、その場所の認証は一旦切れていることをしっかり認識すること。復活するのは臨時審査で合格した時。復活させないまま、新しい引越し先の住所の入った名刺に認証取得のシンボルマークを印刷するのはコンプライアンス違反に相当するので、本来なら問題は深刻です。

.*.

冒頭の問いに対する回答は「移転」で決まりですが、コンサルや審査のビジネスでは「移転」は少しも美味しくない。専ら売上拡大も望める「拡大」に神経を集中させるのです。

商売人が審査をやっても上手くない訳です。ということらしい。

.*.