2011年09月21日
リスク値について考えてみる
本来は年間の期待損失額（金額）です。受容する水準は、経営層レベル、部門長レベル、マネジャーレベル、担当者レベルで、それぞれの予算との関連で決めてもいい。小規模企業だと１００万円を超える決済も経営層に行くが、大規模企業なら１億円でも部門長で決済できてしまう。組織規模が反映できるので有効なアプローチに思われる。経営層決済を受容基準にするのか、部門長決済を受容基準にするのか。
- [期待損失額]=[CIAが脅かされた時の損失額]×[脅威の頻度]×[脆弱性]
脅威の頻度は年間の発生確率。
脆弱性は脅威の発生に対して受け入れる確率（防御できない確率）
因みに、脅威×脆弱性＝実現頻度と理解できる。
.*.
金額ベースの評価が困難な場合、ポイント制の評価を採用する組織が多い。むしろ、簡便なポイント制でリスク分析を進めるところが主流だそうだ。
ポイント制で、リスク値は最大で４×４×４＝64。最小値は１。
ポイント制の最大欠陥は金額の大きさ（深刻度）が単なる１-４のランク分けされて、臨場感を欠落させること。小手先を使うことで、リスク値の過小評価が簡単に出来てしまうこと。その為に、いくつかの工夫を施すことになる。
＜リスク値の評価における工夫の例＞
- 資産価値最大（４）の場合、脅威の頻度（１）、脆弱性（１）以外（＝実現頻度１以外）は受容しない。企業存続〜事業存続の瀬戸際に追い込まれる事態を回避するため。資産価値４は無限大に通じると理解しておくことが重要になる。結果、リスク値４のみ受容。またはリスク値８以上は対策を要求。
- 資産価値最小（１）の場合、全ての脅威（４）、脆弱性（４）を受け入れる。対策を要求しない。リスク値16まで受容。
- 資産価値（３）の場合、中長期的に１回の発生（脅威１×脆弱性4）を下回ることを求める。リスク値１２は受容せず、次のレベルとなるリスク値９まで受容。
- 資産価値（２）の場合、中長期的に1回の発生を認める。脅威１、脆弱性４。リスク値８まで受容。次のレベルとなるリスク値16は受容しない。
これを、CIAそれぞれに対して独立して実施する。
.*.
2011年09月20日
脆弱性を検証してみる
防御力の欠落度合いが脆弱性。
一部に勘違いの向きがある。出来ることに対していくつ出来ていないかの度合いを脆弱性と考えるのは間違い。やるべきことをサボってやらなかった度合いではありません。例えば、方法論として成立している管理策が１０個あって、その内７個を実施している場合に、脆弱性評価を１０分の３とするのは定量化手法としては理解できても、脆弱性が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のゴールドカードだと、セキュリティチェックを通った後でラウンジが利用できるので利便性は格段。
一番安いセゾンカードは結構厳しいかな？
セゾン空港ラウンジサービス
.*.
情報セキュリティ損失額の算定
コストは管理策の実施に当たって既に発生しているが、インシデントが発生した場合もコストが発生する。
- 予防のコスト
- 是正のコスト
- インシデント対応コスト
どのコストについても満足できる形で把握している組織は少ない。何故か？ そのコストを活用する方法論を持っていないからか？、そのコストを把握する方法論を持っていないからか？、またはその両方か？。
どの組織でも、情報システム投資は膨大なレベルに達している。情報セキュリティ投資は情報システム投資の一部が当てられるケースが多い。が、全てではない。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千人も従業員が居れば、毎月のように紛失事故は有り得る話です。
携帯電話が今後スマートフォン化することを視野に入れれば、個々の頻度は小さくてもカテゴリーで捉えた時の頻度も考慮したくなるものです。「脅威の積み重ね効果」を織り込む方法論が必要に思われます。統計分析的なアプローチを踏まえたカテゴリーリスク・カテゴリー脅威の理解を事務局部門は試行すべきです。
.*.
個々の情報資産に対する脅威・脆弱性だけでリスクを評価していると、カテゴリーに対する適切な施策を打てない懸念があります。詳細リスク分析アプローチの弱点と理解していいでしょう。これを回避するにはベースラインリスク分析アプローチが有効に成ります。
「脅威の積み重ね効果」への対応にはベースライン方式。
「ここの脅威」への対応には詳細方式。
この両方を併用することが必要。ベースラインで全て間に合わせるのは個々の事情が反映されていないので返って無理なやり方を強いることになりかねません。
.*.
脅威の洗い出し
脅威と脆弱性を分離して理解できるかどうかは案外難しいものだそうです。括ってリスクと表現しても極めて自然に思える。わざわざ分離する意味があるんだろうか。
あるオッサン先生は言ってくれた。自分でコントロールできないものが脅威だと。本当かな? 天気は今の技術ではコントロールできないから脅威。でも、その内、コントロールできるようになれば脆弱性なのか。
コントロールできる領域が広がれば、脅威は萎縮していくのは当然のことかも知れない。管理策のスパンが広がるから、脆弱性の付け入る隙が出てくる。
先ず、情報資産を取り上げて、この資産に対する脅威またはリスクを並べてみる。
実施中の管理策、今後可能な管理策、他社等で方法論として確立している管理策を並べる。方法論が確立していない管理策・アイデアを並べる。
＜脅威・リスク＞＜既存の管理策＞＜予定の管理策＞＜未来の管理策＞
脅威・リスクから防御するためにできることは、
- 既存の管理策の効果を上げる。
- 予定の管理策を実施に移す。
- 未来の管理策を引き寄せる。
.*.
話を戻して。では、「脅威・リスクの洗い出し」はどのようにやりますか？。方法論としては地道にやるしかありません。以下の項目の一部または全て含むリスクを洗い出し、データベース化し、メンテナンスを定期的に行うことが求められます。
- 情報の保管状況から想定できるリスク
- 情報の移動方法から想定できるリスク
- 情報の利用方法から想定できるリスク
- 管理者・利用者等のヒューマンエラーに関連するリスク
- 疲労・風化・拡散に伴うエラー
- 技術革新・制度改革・イノベーションに伴うリスク
以上を手掛かりに、機密性リスク・完全性リスク・可用性リスクの全ての側面について、脅威・リスクを洗い出し、脅威の発生頻度を評価することが求められます。
＜１つの資産＞＜3つの側面＞＜6つの脅威・リスク領域＞＜発生頻度評価＞：既にケーススタディのツリーは膨大な量になりますし、意味も分からなくなります。ここでは網羅的にやるよりも主要なものについて評価することが大事です。可能なら3つの各側面で最大となるもの着目します。
ISMSは継続的な活動ですから、一番目立つものから順番に押さえ込んで行く考え方で十分ですし重要です。最初から網羅的でなくても構わないと理解すること、具体的に歩を進めることが出来ます。漸進ですね。
.*.
2011年09月18日
Why Not? 情報資産の洗い出し
この基本的なことが出来ていない。抜け漏ればかり。何が資産か把握できていなければISMSの後工程は全く無意味になります。コンサルに行っても疲れるだけです。どうして普通に出来ないのでしょう？
＜洗い出しの抜け洩れの例？＞
- 静的に保管しているものだけが洗い出される。キャビネットの中だけをリストにしている。
- 個人管理の資料は洗い出しの対象から外す。デスクの袖のキャビネットが外れる。会社のあるいは業務の情報資産で溢れかえっているのに、不思議なことだ。
- サーバー内の情報は情報システム担当が管理しているから部門の情報資産から外す。おいおい情シ部は器の管理しかしていないよ。彼らは中身には関与しません。
- 発送する予定の情報類。一時的に入り口にあるが郵便やとか宅配やが来て回収するからリストに入れないよ。
- 今日中にお客さんとか営業とか管理部門に届ける資料も同じだ。
- メディア類。USBメモリー、CD/DVD、テープ類などは、中身が空っぽもあれば、ゴミ情報もあれば、重要情報もあれば、と不確定的ですから始末が悪い。コンテンツを識別して、メディア自体は対象から外す。
- 共有資料というけど、管理責任者不明の資料。倉庫の隅に積み上げられている。キャビネットの一角に門外不出のように置かれている。時には通路の脇に何年も置きっぱなし。
- 持ち主不明の資料。部門が解散・分離したときに誰も持っていかなかったもの。部門ミッションが変わって宙に浮いてしまった資料。
- 前任者から引き継いだけど、内容を理解できていないもの。業務上の資料としての意味が無く、誰かに何かを聞かれた時に困らないように捨てないでいるだけの資料。
- 資産リストとか資産台帳とかの名前は付けているが単なる分類表・区分表・カテゴリー一覧に過ぎないもので済ませるケース。分類・区分が思いつかないものは全て「その他」区分で済ませる。
.*.
＜業務フロー/業務プロセスに沿った洗い出し＞
業務フロー/業務プロセスを書き出してみる。手順に沿ったフローチャートが出来上がる。
各処理のところで、参照する情報、出力する情報を書き出す。情報の内容・情報の所在、入力または出力の方法も記載する。
単純な作業に思えてなかなか面倒。
先ず、何の障害もなくスムーズにことが運んだ時の基本形。次に、例外のフローを書き加える。例外が夥しいほっど多い。人によってやり方が変わる。
問題は、基本の流れでは業務標準が出来ているが、細かい部分は実に何も決まっていないことに気づく。そういうものらしいです。資産の洗い出し（たな卸し）が、業務標準細則の策定作業に変わるのです。今までいい加減にやってきたことですからしようがありません。
もっとも、洗い出し自体は、複数のやり方が並存しても出来るので、先行して進めても問題はありません。無駄をなくすために、後で、何を標準とするか決めれば済むことです。
.*.
＜洗い出されなかった情報資産の特定＞
必要な情報が洗い出されると同時に、どの業務でも参照されない資産が存在するかどうか。プロセスの合理化を進めると中間生成物のような情報は最後には不要とされるケースが多い。自分たちの管理スペースに存在する情報資産で業務プロセスからの引用が全く無かったものを識別し、一定の見極め期間を置いて廃棄する手順が必要になります。
この場合は、静的な情報資産の洗い出しはやはり必要となる。
業務プロセスIDと情報資産IDがあると想定して、プロセスIDから資産IDを引き当て、また資産IDからプロセスIDを引き当てることが出来る。しかし、机上論の展開はできるが、現実にどの程度可能かは一概に言えないでしょう。意味がある範囲において、意味のあるサイズ（かたまり）に対して、プロセス・情報資産ともやればいいということらしい。軌道修正しながら進めるのが現実的なアプローチでしょう。
.*.
ISMSと5S活動5Sってなんでしたか？
5S
- 整理（せいり）いらないものを捨てる
- 整頓（せいとん）決められた物を決められた場所に置き、いつでも取り出せる状態にしておく
- 清掃（せいそう）常に掃除をして、職場を清潔に保つ
- 清潔（せいけつ）3S（上の整理・整頓・清掃）を維持する
- 躾（しつけ）決められたルール・手順を正しく守る習慣をつける
基本のキ。組織、集団、グループの中に居る時に要求される人間の基本的な振る舞い。行儀よく言っているが、臭い奴、汚い奴、危険な奴、気の触れた奴などとは付き合いたくない。
５Sが出来ていない会社は、トップがいくら格好を付けていても必ず現場に足元を掬われるのは間違いない。現場を見ないで能書き垂れているのだから、自業自得というものだ。
.*.
ISOとかISMSとか言う前にやることあるだろう。机の上に雑然と資料を置いたまま。「重要な資料ではありません」と言うが何の言い訳になると言うのだろう。机の下にも資料類が積み上げられている。「スペースが無くて」と言うがそれで済むのかね。そうでなくても普通に、机の引き出しを開けると、その席の主の仕事振りが分かる。キャビネットとかロッカーを開けると、そのグループの仕事振りが分かる。倉庫を開けるとその会社の仕事振りが分かる。サーバールームが倉庫代わりになっているなんて良くある話、だそうだ。
ISMSの審査員と来たら、情報資産の管理レベルについて、苦しく物申ししているが、中にはケシカランと憤慨して重大な不適合の爆弾を落とす輩まで居る。規格に照らせば疑問が無いわけでもないが、そもそもPDCAを回す意思が組織全体に欠落していると捕らえていると理解すれば重大な不適合とすることが分からないこともない。
重要な情報資産も、販促品も、粗大ゴミも、イベントの小道具も、着替えも、もう何でも入っていて、誰でも出入り自由で、倉庫でござい。倉庫の壁にMDF（通信の出入り口）が着たり、サーバーが設置されていたり。入り口には倉庫とかPRIVATEとか記載して。
コンサルは勿論、審査員も、内部監査員も、業務監査も、全員が素通りして行くらしい。
.*.
５S無視は重大な不適合と心得よ！
.*.
2011年09月16日
スマートフォンのセキュリティ問題スマートフォンとはポケットに入る多機能電話+ノートパソコン。iPhoneはiPod Touchに通信機能を持たせただけのはずが、パラダイムシフトのトリガーになった。ジョブスは見抜いていたんだろうか。
スマホのセキュリティはパソコンのセキュリティと何が違うのか？
ノートＰＣに対する管理策と似たものになる。+携帯電話に対する管理策。
＜装置に対するセキュリティ＞
- ロック機能
・本人の側を離れたら自動ロック。
・遠隔から強制ロック。
- データ削除
・認証失敗をある条件で自動削除
・遠隔から強制削除（オフの状態でも削除）
- ハイレベル認証
・虹彩・指紋・音声など複数のバイオ認証+ピンコード
- クラウドベース（シンクライアント）
・データをスマホ上に保存しない。
- 常時暗号化・圧縮化
・メモリ内の情報の暗号化
・同時高圧縮
- 自爆装置
・ある条件を満たせば自動的に全ての情報を削除し、ファームウエア自体も破壊する。
＜利用に対するセキュリティ＞
- ウイルス対策ソフトは常識
- カメラ・ビデオの不適切利用防止
- 画像・映像・音声のセキュリティチェック（コンテンツチェック）
- 定期インターバル虹彩認証
.*.
「スペクタープロfor Android via メール」がWBSで紹介されていた。
ＡＯＳテクノロジーズ社の商品かな。５月発売開始で既に３千本販売。６５００円。
.*.
2011年09月15日
リスクアセスメントは何段階評価にするか？
手を抜くには３段階。どうせ段階評価なんていい加減な妥協の産物。ここを木目細かくやっても有効性は上がらない。但し、３段階は心理操作が入るので進められない。中心選択が出来ないように偶数段階にするのが今どきの常識。４段階。
資産価値も、脅威も、脆弱性も、全て分かり易いように４段階。
◆ ４（価値）×４（脅威）×４（脆弱性）＝６４（リスク値）
脅威と脆弱性を括って被害の発生確率とするケースもある。
◆ ４（価値）×４（発生確率）＝１６（リスク値）
しかしこれは分析が更にラフになるから勧められるものではない。特に脆弱性に対するアプローチが曖昧になるのはリスクアセスメント全体のスキームをスポイルするので致命的とも言える。
.*.
面白いことがある。機密性だけ４段階にする話だ。完全性、可用性は３段階にしたまま、機密性だけ４にするというのだ。馬鹿げた話だ。正しい資産価値評価も出来ないし、リスク値の意味まで本質を失ってしまう。
リスク値は本来、期待損失のこと。可能なら被害額を算定するのが正しい。被害額算定の方法論が簡単でないから、段階評価をやっているに過ぎない。だから、ＣＩＡのどの側面を喪失しても、被害額は同じ軸（本来は金額）で求められなければいけない。
ＩＳＭＳが流行りだした初期のころは、ＣＩＡで段階を分けるような間違いの他に、ＣＩＡ各側面の資産価値を足したり、平均値を出したり、あるいは脅威と脆弱性を足したり掛けたりなどと頓珍漢のロジックを組むところがあった。コンサルの罪は重い。審査員も合理性を求めないで見て見ぬ振りだから同罪。と言うか、本質を殆ど理解していない審査員も少なくないようだ。
既に１０年を経過した今の時代でも、その名残を引きずるＩＳＭＳは結構ある。ご都合の見よう見まねの結果です。
.*.
可用性価値
- レベル１：情報に必要なときにアクセスできなくても損害は発生しない。”必要な時”と言うのが難しい。極端なケースでは、”いつでもいいから提示してください”と言われて、それに対する否定的回答は”いつ提示できるか回答できない”と言うもの。即ち、行方不明状態。保管していない状態。
- レベル2：必要な時にアクセスできない場合、損失は軽度。担当者による説明責任。
- レベル3：必要な時にアクセスできない場合、発生する損失は中度。部門マネジメントによる説明責任。部門長・マネジャーへの懲罰。
- レベル4：必要な時にアクセスできない場合、発生する損失は重度。事業継続が困難。事業継続管理が発動される。顧客情報・個人情報の重要なものを含む。経営上の重要事項を含む。経営陣による説明責任を問われる。マスコミから叩かれる。社長・経営陣への懲罰・交代・失脚。
可用性性価値で注意を要するのは、アクセス要求に対するレスポンスタイムの長短でレベル区分をする例が多いこと。２時間以内のアクセスレスポンスがレベル３、翌朝までのアクセスレスポンスならレベル２、１週間以内ならレベル１など。被害の大きさとレスポンスタイムの相関は単純には設定できないからだ。
業務プロセス分析による情報資産の洗い出しに置いて、利用者と要求レスポンスとレスポンスアウトした時の被害額（被害レベル）を明らかにしておかなければいけない。
当該情報が複数の業務プロセス、複数の利用者に関連する場合は、その中で最大の被害についてレベル算定することになる。被害最大となる場合のレスポンス要求時間も抑えておくことが必要になる。（ヘルプデスクとかテレフォンセンターでは問い合わせ回答に１分も掛かれば不適当とされるが、それで会社が危機に陥る訳ではない。
可用性価値の難しさは、被害額は想定レスポンスから遅延する程度とある程度相関することによる。
◆ 被害額Ａ＝紛失時被害額〜レスポンス遅延時被害額。
最大値はレスポンスタイプ無限大に相当する。最小値はプロセス要求を少しでも外した時の被害額。可用性価値は本来はプロセス要求を外した時の被害額で算定すべきだろうが、管理策を適切に選択できるようにするには最大値も考慮する必要がある。リスクアセスメント自体を簡便化するにはレスポンス無限大時の被害額を入れて算定すれば良い。
完全性価値
- レベル１：情報が不完全（間違い、破損、改ざん、抜け盛れ、バージョン違い等）でも、損害は発生しない。
- レベル2：情報が不完全な場合、発生する損失は軽度。社外の人による取り扱い不可。担当者による説明責任。
- レベル3：情報が不完全な場合、発生する損失は中度。担当部門・部署以外による取り扱い不可の区分。部門マネジメントによる説明責任。部門長・マネジャーへの懲罰。
- レベル4：情報が不完全な場合、発生する損失は重度。事業継続が困難。事業継続管理が発動される。顧客情報・個人情報の重要なものを含む。経営上の重要事項を含む。担当者外の取り扱い禁止。経営陣による説明責任を問われる。マスコミから叩かれる。社長・経営陣への懲罰・交代・失脚。
.*.
完全性価値で注意を要するのは、完全性価値の連鎖を把握できているかどうか。その情報が改ざんされることでどの範囲まで影響が及ぶかを判断できるかどうか。
.*.
完全性価値レベル１の意味：
平気で完全性を１にしている組織があるらしい。完全性を喪失しても全く構わない情報とは何か。二度と利用しない情報のことである。棄てる予定の情報。ハードウエアであれば正しく作動しなくても構わない機器類。間違ったロジックのアルゴリズム。検証されていない方法論。
.*.
機密性価値
- レベル2：許可された人以外の人が見た場合、発生する損失は軽度。社外秘レベル。担当者による説明責任。
- レベル3：許可された人以外の人が見た場合、発生する損失は中度。担当部門・部署以外への開示不可の区分。部門マネジメントによる説明責任。部門長・マネジャーへの懲罰。
- レベル4：許可された人以外の人が見た場合、発生する損失は重度。事業継続が困難。事業継続管理が発動される。顧客情報・個人情報の重要なものを含む。経営上の重要事項を含む。担当者外秘の区分。経営陣による説明責任を問われる。マスコミから叩かれる。社長・経営陣への懲罰・交代・失脚。
ISMSのKPI
キー・パフォーマンス・インジケータ。重要な有効性指標、あるいは重要な達成度指標。
この議論は簡単に始められるが、着地させるのは難しい。「目的と方法」論に対する共通理解が得られないと議論が進まない。目的と目標についてすら共有できないのが普通。理念とかビジョンとかを持ち出すと議論は水平線の彼方からやり直す羽目になる。
価値観の軸が一通りでないから、議論はねじれ、退散するしかなくなってしまう。
.*.
しかし、一定の前提をかぶせることで、具体的で建設的な議論は可能となる。
いずれの場合も、社会価値の側面を見失うことのないようにしなければ、長続きできない。
その点では、ＱＭＳとか、ＥＭＳとか、ＩＳＭＳとかのＩＳＯは手ごろ。
.*.
ISMSの価値はよく理解できるとして、目指す方向はリスク値の適正化。但し、リスクを静的に捕らえた適正化で無く、動的に捕らえた適正化です。
手抜きのISMS構築は通用するか？
規格を写しただけの規定〜マニュアルで済ます会社。あるいは、コンサルから提示されたサンプルをそのまま利用する会社。
割と普通のこと！。構わない！。写した後の展開が問題。何処まで実務に落とし込むことが出来るか。規定からのリンクを辿って、最後に一人ひとりの業務マニュアルに行き着けば、仕組みの形としては完成です。
ここ、皮肉に言ってますよ。もらい物のマニュアルは絵に書いた餅。これに実態を合わせるなんて出来っこありません。もらい物で形を作っているようではまだ始まってもいない。
規格を写して後は部門任せ。部門は個別の指示が出たときだけ本社に付き合う。完全に指示待ち。
やる気があるのは誰か？さっぱり分からない。コンサル泣かせ？。コンサルの腕の見せ所？。
＜結論＞
手抜きは通用する分けない。そのことを一番わかっているのは手抜きした本人です。
ですから、こんな疑問すら出てこないのです。
何段階評価にするか？
手を抜くには３段階。どうせ段階評価なんていい加減な妥協の産物。ここを木目細かくやっても有効性は上がらない。但し、３段階は心理操作が入るので進められない。中心選択が出来ないように偶数段階にするのが今どきの常識。４段階。
資産価値も、脅威も、脆弱性も、全て分かり易いように４段階。
◆ ４（価値）×４（脅威）×４（脆弱性）＝６４（リスク値）
脅威と脆弱性を括って被害の発生確率とするケースもある。
◆ ４（価値）×４（発生確率）＝１６（リスク値）
しかしこれは分析が更にラフになるから勧められるものではない。特に脆弱性に対するアプローチが曖昧になるのはリスクアセスメント全体のスキームをスポイルするので致命的とも言える。
.*.
面白いことがある。機密性だけ４段階にする話だ。完全性、可用性は３段階にしたまま、機密性だけ４にするというのだ。馬鹿げた話だ。正しい資産価値評価も出来ないし、リスク値の意味まで本質を失ってしまう。
リスク値は本来、期待損失のこと。可能なら被害額を算定するのが正しい。被害額算定の方法論が簡単でないから、段階評価をやっているに過ぎない。だから、ＣＩＡのどの側面を喪失しても、被害額は同じ軸（本来は金額）で求められなければいけない。
ＩＳＭＳが流行りだした初期のころは、ＣＩＡで段階を分けるような間違いの他に、ＣＩＡ各側面の資産価値を足したり、平均値を出したり、あるいは脅威と脆弱性を足したり掛けたりなどと頓珍漢のロジックを組むところがあった。コンサルの罪は重い。審査員も合理性を求めないで見て見ぬ振りだから同罪。と言うか、本質を殆ど理解していない審査員も少なくないようだ。
既に１０年を経過した今の時代でも、その名残を引きずるＩＳＭＳは結構ある。ご都合の見よう見まねの結果です。
.*.
手抜きのISMS構築は通用するか？
規格を写しただけの規定〜マニュアルで済ます会社。あるいは、コンサルから提示されたサンプルをそのまま利用する会社。
割と普通のこと！。構わない！。写した後の展開が問題。
何処まで実務に落とし込むことが出来るか。規定からのリンクを辿って、最後に一人ひとりの業務マニュアルに行き着けば、仕組みの形としては完成です。これは、所謂、トップダウン手法ですが、殆どの場合、失敗します。新たに組織を作る場合でも難しいでしょう。
実務をベースに規格（ルール化）するのが普通。ボトムアップ手法が現実的で成功する。
.*.
事務局は規格を写して済まし、後は部門任せ。部門は立ち往生。事務局から具体的な個別の指示が出たときだけ本社に付き合う。完全に指示待ち。改善意欲は完全にそがれている。
事務局が楽することを考えたら失敗は当然。
2011年09月13日
意外と難しい「弱点の報告」！企業文化が邪魔する方法論？
大きい事故の前に、いくつかの小さい事故が起き、小さい事故の前に、いくつかのヒヤリ・ハットが起きる。これ世間の常識。一般論ですから誰でも理解できることですが、実態は如何でしょうか。
大きい事故が起きると、社長がたまらず陣頭指揮を取らざるを得ない。辛いだろうが、カメラと時には罵声を浴びる場に身をさらす。直接、間接に相当の被害が出る。営業も止まってしまう。後手管理もいいところで、場合によっては管理不能に陥る。
小さい事故が起きて手を打つのは普通の会社。こちらもスタンスは後手管理ですね。
ヒヤリハットの先手指標で手を打つはエクセレント企業の始まり。
こんなことは誰も知っていること。問題はどのように先手管理を実現できるかです。
事故の識別：
いろいろなアイデアがあるだろうが、被害額で分けるのは結果指標を使うため、事故当初の識別には向かない。
割と分かりやすいのは、事故が、顧客プロセスに影響するものか、他部門プロセスに影響するものか、自部門内のプロセスに収まっているか、で分けるもの。顧客資産に影響する、他部門資産に影響する、自部門資産にとどまる、で分ける発想も追加していいでしょう。
セキュリティ弱点の報告：
弱点は事故未満だから、収集するのは実はもっと難しい。被害者が発生していないので、即座に騒ぎになる訳でもない。日常的に発生しないので有耶無耶にされることも多い。自分の失敗を打ち明けることになる、または他人の失敗を言いつけることになるので、メンタル的にも抵抗がある。セキュリティの弱点は情報を収集すること自体が難しい。
取り扱いが微妙で難しいものを、事件事故報告書やインシデント報告書の書式で求めるやり方は最低の方法。弱点の報告は無用と宣言しているのと同じレベル。無頓着のきわみ。
先手管理、予防処置の重要ファクターになる弱点の報告は、企業文化（カルチャー）を反映させることも必要で、一概に方法論を示すことには無理がある。参考までにいくつかのアイデアを提示することは可能かもしれない。
.*.
気休めのバックアップ？
説明責任を果たす目的だけのバックアップ作業。こと（一大事）に及んでバックアップが有効かどうかは、あっそんなの関係ない。あっそんなの関係ない。
.*.
頻度、範囲、バックアップの方法論、復旧の手順と試験。定期的な確認。
復旧の手順で大事なのは、純粋に、例えばそのハードディスクだけが傷害を起こして、単に新しいものに交換するだけの前提を置くことで済むかどうかの確認です。HDD障害に至るリスクケースをいくつか想定しないと行けません。都合よく壊れてくれるものではありませんから。別のサーバー上で復旧させる必要に迫られることは少なくありません。
.*.
2011年09月09日
情報セキュリティの目的
管理策の目的は規格に書いてある。附属書（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)の審査にならないのではないか。
問題とした現象は果たして本当にリスクが高いのかどうか。無視できるリスクかどうか。気付いていなかったリスクなら、リスク分析の方法論の問題になるが、特に問題としていなければ自明・受容のレベルとして無視してよい。形式主義に走らないこと。
無視できないリスクの場合も、プライオリティは有る。経営・事業の目的、ISMS導入の目的に照らして、方向性があっていれば優先度は高く、連関が少なければ優先度は下げる。
優先度を上げるとは不適合として対策を明確に求める。優先度を下げるとは観察事項として組織判断に委ねる発想。
ここでは大変難しい側面も顔を出す。審査は杓子定規であるべきとする考え方との葛藤だ。付加価値審査は良く耳にする言葉だけど、一体何が付加価値なのか？簡単でないはず。経営者の意図を何処まで理解できると言うのだろう。余計なことに頭を使わないで、ゴミ・カスも含めて、杓子定規こそが正しい態度とする主張にも納得できる。
.:.
2011年8月末成立の改正特許法の影響？
コンプライアンスは常識であるがISMSで正しく管理するには案外ゴールは高い。大企業で法律の専門化が社内スタッフとしてあるいは顧問弁護士として組織内においてある場合はタイムリーな対応が出来るが、事務局が片手間に対応では追いつかない。アマチュアがタイムリーに正しい対応を図るのは無理なものです。
.*.
改正特許法：
特許所有企業がM&Aで競合に渡っても継続的に使用するには特許利用契約を特許庁に登録する必要が従来はあったが、登録なしで引き継げることが出来る。（利用契約は依然必要？）
真の発明者でない人又は企業による横取り出願への対策も加わった。真の発明者は訴訟を起こして名義を変更できる。特許の大原則である先願主義から一歩抜け出した改正と言うことらしい。
.*.
訴訟時の証拠提出義務を求める米国司法判断の影響？
米国の状況裁判所の判例が記事になっていた。訴えを起こされた側の責任行為。訴えが不当なものであると主張する場合はそれを根拠付ける証拠を提示できなければいけない。のような感じの内容。証拠が出せない場合は隠匿隠蔽しているとみなされる。判例は続けて2件。
.*.
日本の話ではないが影響は出る場合もある。
.*.
2011年09月07日
見ていて面白い地雷原を歩くような審査
前任者の前で審査をやらされる審査員がいるが、これは見ていて楽しめる。ベテランの前で新人がやることが多い。規格どおりに真面目に指摘を始めると、突然に前任の審査員が口を挟み始める。どうしてか。都合が悪いらしい。
前任者が見過ごしていたり間違えていたり都合で容認していることがら結構あるようで、新人はそれを踏みつけないように審査をやらされる訳だ。
地雷が無いところを除けて審査すると、抜け漏れがありましたのでとベテランが口を挟む。
こいつらは関西の漫才師かと思わせる。笑いの絶えない明るい雰囲気の審査光景が続く。
.*.
継続的改善-是正と予防の他にあるもの？
改善活動は是正処置と予防処置に限らないと言う主張がある。これは正しいか？
正しいも正しくないも是正と予防をどのように定義するかで、あるいは継続的改善の定義をどうするかで決まる。
規格の中に、それぞれ定義があるので、答えは自ずから出る筈ではあるが果たしてどうなるか興味深い。
間違えないホテルの選択
- 築年の古いホテルはj敬遠すること。10年以上は絶対NG。出来れば、築5年未満が望ましい。有名なビジネスホテルチェーンでも初期のホテルは既に5年以上経過しているものが増えてきて要注意。勧められない。・東横イン・ロイネット系/リッチモンド系・ルートイン・ワシントン系（結構古いものが多い）・チサン
- 安ホテルは敬遠すること。安かろう悪かろうの妥協が入り込む懸念アリ。ブランドを確立した有名チェーンの安いのはOKだが、やはり初期の段階のものは安かろう悪かろうが残る。壁・ドアが安くて平気で隣室などの騒音が侵入する。隣の部屋の寝息が聞こえるは冗談としても注意したい。訪問先から少し遠くなっても都市部に戻ることが賢明。
・地方ビジネス系（木賃宿？）
- 高級老舗は敬遠したい。高級は高額料金のことだが、手入れは行き届いているが老朽設備が残る。加えて、構造がビジネス利用向きになっていない。
・観光地
- 団体客が入るホテルは止めておけ。特に中国人の多いホテルはとても煩い。大規模ホテルは採算を維持するために団体を取るために営業が頑張っているが、一般客には迷惑な話だ。不安がある場合は事前にホテルフロントに照会するのがいい。
・プリンス系
・観光地
- 目安の料金は、1泊素泊まりで5千円以上〜1万5千円以下。1万円±2千円程度が望ましい。
- リニューアルの評価は難しい。目減り対策だから空調・バストイレは新しくなるが構造は変えられない。
- 初めての時は、口コミサイトを必ずチェックする。この2〜3ヶ月以内の書き込み、1年前の同シーズンの書き込みを見る。清掃、騒音、空調などは特にチェック。書き込みの返信を入れないところは好ましくない。評価が低いところは論外。評価が高いところもやらせ投稿が入り込むので鵜呑みに出来ない。チェーンホテルの評価は、個々のホテルの評価でなく全体評価を乗せるケースがあるので要注意。
- 自分のホテルリストを作っておくこと。適切にメンテナンスすること。
.*.
