掲示板お問い合わせランダムジャンプ

Google広告

2011年09月29日
JACO
JACO



日本環境認証機構



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



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



JACO-IS



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



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



.*.



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



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



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



かな?



.*.
[ 投稿者:ISMSNEWS at 12:00 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

ISO26000
ISO26000



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



自分で調べてください。



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



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



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



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



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



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



.*.
[ 投稿者:ISMSNEWS at 11:41 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

ISO20000:2011
ISO20000:2011



ISO20000の2011年改訂版。



あまり関心がありません。ISO20000なんて派生規格?、もどき規格?でしょうか。



業務用途別に最適化するのは当然だから、業界別ガイドラインは必要ですから、否定する理由はありませんが、第三者認証制度を生業とする連中の思惑の方が気になってしようが無い。



ISO27001では不足と言っているようなもので自己矛盾を感じる。



.*.



要はあれこれやるのが面倒なわけです。似て非なることをいろいろやれるのは規格を生業としている方々。一つの企業の中では軸はシンプルに。本来はQMSだけでいいはずなんです。それ以外の専門性については参考規格で十分。



軸を決めて、それに肉付けしていくアプローチの方が現実的。審査ビジネスに集ってくる連中を"必要以上に"設けさせることもありません。



.*.
[ 投稿者:ISMSNEWS at 11:32 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

ラベリングについて
ラベリングについて



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




  1. 属性情報の全てをラベルにすると視認性が落ちる。

  2. 収納場所を変えるとラベルも変えるのでは管理ロスが出る。

  3. 組織変更の度にラベルも変えるのではやはりロスだろう。




バラバラにしてはいけないものはバインダーに綴じる。記録類の台帳、特定プロジェクトの一連の資料類は一塊にするためにバインダーに入れる。

ばらばらにしてもいいもの(資料の時間連続性などを要求しないもの)は、今後はバインダーへの綴じ込みは避ける。ファイルフォルダ、ファイルボックスを中心に利用する。

どちらかと言えば、過去情報はバインダー、現在情報はフォルダ/ボックスがメインになる。



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



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



.*.



具体的な事例




  • 機密性区分:この識別の無いラベリングは考えられません。機密情報であることが外部者にも容易に判別できないようにしたいと言うことと全く識別しないことは別の問題です。何を厳重に管理すべきかが判別できないのは論外です。社外にルールを教える必要はありませんが社内では周知されている必要があります。

  • 管理日:管理開始日・管理終了日・管理見直し日などです。保管期限の場合は定義を明確にする必要があります。保管期限と廃棄処理の関係。

  • ファイル名:出来るだけ具体的に。○○関連資料などは避ける。どうしても纏められない時は××等○○関連資料とする。

  • 管理責任者:大括りの部門名は避ける。直接の担当部署(グループ、課、係りなど)と担当者名。間違っても部門長デートで済まさない。部門長が直接管理するもののみが部門長印で管理。

  • その他は、管理コードなど文書管理規定が要求しているものがあれば記載。

  • ラベルの色識別は視認性を高めるので非常に有用ですが、徹底するのが難しければ、モノクロで徹底するのも良い。意味も無く色を付けたり色を付けなかったりするのは歓迎できない。

  • ラベル位置もいい加減なmのはいけない。保管状態でキャビネを開けたりした時に識別できる位置にラベルが付けられているべき。どこかに書いてあれば良いとするのはラベル付けの目的すら理解していない可能性がある。5Sの常識?。

  • メディア類の保管も基本は同じでも、厄介な問題が残る。内容確認。1つは改竄されていないか、2つは再読み込み可能か。ラベリング自体の問題ではないが、ラベルは内容を表示している前提において内容との合致性をどのように担保するかが問題になる。管理上は結構手間です。



.*.
[ 投稿者:ISMSNEWS at 11:26 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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

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

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

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

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

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

.*.

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

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

.*.
[ 投稿者:ISMSNEWS at 11:24 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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



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



問題って何?



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



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



.*.



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



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



.*.
[ 投稿者:ISMSNEWS at 11:20 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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



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



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



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







 .*.



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



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



.*.



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



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



.*.



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




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



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



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



.*.
[ 投稿者:ISMSNEWS at 11:19 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

2011年09月28日
時間にルーズな会社のISMS?
時間にルーズな会社のISMS?



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



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







.*.



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



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



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



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



.*.
[ 投稿者:ISMSNEWS at 10:57 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

2011年09月25日
データセンターの情報資産
データセンターの情報資産



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



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






  • 外部に情報資産の管理を委託すると考えてよいか?

  • 外部に預けている資産も台帳を作るのか?

  • 管理を委託しているのはリスクの移転に相当するのか?

  • 外部に預けてもリスクアセスメントの対象になるのか?







  1. 情報システム部門はインフラ業務の一部を外部に委託する形になる。リスクの移転を図ったのは情報システム部門である。

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



.*.


[ 投稿者:ISMSNEWS at 10:53 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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



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



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



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



.*.



でも、



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



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



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



.*.
[ 投稿者:ISMSNEWS at 10:50 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

2011年09月24日
RACONTIS(ラコンティス)の功罪
RACONTIS(ラコンティス)の功罪



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



経営者は裸の王様。



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



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



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



.*.



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



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



.*.



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



.*.



(引用記事)
[ 投稿者:ISMSNEWS at 10:48 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

2011年09月23日
ディスカウントされた料金の意味
ディスカウントされた料金の意味





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





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





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





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





.*.





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



.*.

[ 投稿者:ISMSNEWS at 10:46 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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



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



先ず


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



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



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






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



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



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



<よい審査には金も時間もかかる>



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



.*.
[ 投稿者:ISMSNEWS at 10:45 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

2011年09月22日
機密性区分の考え方
機密性区分の考え方



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



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



.*.


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



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



.*.



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



.*.
[ 投稿者:ISMSNEWS at 10:43 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

2011年09月21日
事業拡大とISMS
◆事業拡大とISMS



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



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



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



<留意事項>




  1. ISMS推進ノウハウの伝承を確実にする。特に現場。毎年ISMS担当を変える馬鹿マネジャーが少なくない。飲み会の幹事を回り持ちさせる感覚のマネジャーならそっちを変えてしまえ。

  2. 委員会活動をハイレベルで維持する。特に事業拡大先は後進組だから、週1回は常識。先行しているところも月1回は最低条件。

  3. 文書化の品質を上げる。事業拡大による新規参入が増えて阿吽の呼吸で済ませることがやりにくくなる。隙間の文書化と既存文書の見直し。

  4. 新規組み入れの拡大部門のISMSを誰かが肩代わりしないで、自分で考えて自分でやらせること。先人の悪い見本に染めさせないこと。最初が肝心。[事業+ISMS]でなく[ISMS in 事業]または[事業 in ISMS]に持っていくこと。



.*.

[ 投稿者:ISMSNEWS at 09:41 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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



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



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



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



達成の極意は?




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

  • 役割責任を全うする。



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





<自滅の事例>



  • 内部監査などで不適合の内容を観察で済ませる。口頭指摘で済ませる。温情主義のつもりだろうが仕事を放棄して会社を壊している。

  • 再発防止に踏み込まない是正処置を黙って受け取る本社スタッフ。

  • 本社から指示されたら狙いも背景も理解しないまま黙々と作業する現場。



.*.


[ 投稿者:ISMSNEWS at 09:38 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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



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



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



倉庫の次に見るのは?



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



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



<課題設定>



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




  1. 情報資産に対する管理責任者の割り当て。特に、共同利用される施設・設備・備品など。サーバールームが倉庫になったり、倉庫がサーバールームになったりすることもあります。マネジメントとしては殆ど敗北状態ですね。中には更衣室まで一緒くたのケースもあります。

  2. パブリック(業務・社用)とプライベート(私物)の線引き基準と認可された管理形態。私物はロッカーで居室持込禁止も少なくない。


.*.




[ 投稿者:ISMSNEWS at 09:35 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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



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



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



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




  1. 何かのソフトをインストールする時に、一時的にウイルス対策ソフトの作動を制限し、インストール後にウイルス対策ソフトの作動を復帰させるのを忘れる。

  2. 定義ファイル参照サーバーを社内に設営しておいて、サーバー側の更新を適切に出来ていない。

  3. オフラインで立ち上げた後の処理が適切でない。



.*.



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



<対策>



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



.*.

[ 投稿者:ISMSNEWS at 09:31 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

パソコン資源管理ソフト
パソコン資源管理ソフト





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





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





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





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





一般的な弱点としては、



  • ネットに常時接続されないパソコンの扱い。

  • インストールされないプログラム、スクリプト型への対応。



.*.






<パソコン資源管理ソフトの例>



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







.*.






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





.*.

[ 投稿者:ISMSNEWS at 09:29 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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



時々、聞く話:



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



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



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



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



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



.*.



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



.*.
[ 投稿者:ISMSNEWS at 09:27 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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



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






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






脅威の頻度は年間の発生確率。

脆弱性は脅威の発生に対して受け入れる確率(防御できない確率)

因みに、脅威×脆弱性=実現頻度と理解できる。



.*.



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



ポイント制で、リスク値は最大で4×4×4=64。最小値は1。



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



<リスク値の評価における工夫の例>


  1. 資産価値最大(4)の場合、脅威の頻度(1)、脆弱性(1)以外(=実現頻度1以外)は受容しない。企業存続〜事業存続の瀬戸際に追い込まれる事態を回避するため。資産価値4は無限大に通じると理解しておくことが重要になる。結果、リスク値4のみ受容。またはリスク値8以上は対策を要求。

  2. 資産価値最小(1)の場合、全ての脅威(4)、脆弱性(4)を受け入れる。対策を要求しない。リスク値16まで受容。

  3. 資産価値(3)の場合、中長期的に1回の発生(脅威1×脆弱性4)を下回ることを求める。リスク値12は受容せず、次のレベルとなるリスク値9まで受容。

  4. 資産価値(2)の場合、中長期的に1回の発生を認める。脅威1、脆弱性4。リスク値8まで受容。次のレベルとなるリスク値16は受容しない。



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





.*.

[ 投稿者:ISMSNEWS at 09:17 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

2011年09月20日
脆弱性を検証してみる
脆弱性を検証してみる



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



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



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



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



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



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



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



.*.



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



.*.



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



.*.



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



.*.



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



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



.*.



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



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




  • 中央値:1-4段階なら2.5となる。

  • 業界レベル以上なら2とする。

  • 業界レベル以下なら3とする。

  • 対策未着手または説明責任が付かないレベルなら脆弱性最大のレベル4とする。

  • 体制・経費とも業界最高でリーダー的レベルなら脆弱性最小のレベル1とする。






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



.*.
[ 投稿者:ISMSNEWS at 09:16 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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



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



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






  • 新千歳空港:ターミナルビル3F スーパーラウンジ
    北海道へ行くチャンスは無い訳ではないがお土産を探して時間いっぱいでしょう。

  • 青森空港:ターミナルビル2F エアポートラウンジ
    先ず青森へ行くチャンスが見込めない。

  • 秋田空港:国内線ビル2F ラウンジ「ロイヤルスカイ」
    チャンス見込めず。

  • 仙台空港:ターミナルビル3F ビジネスラウンジ
    仙台へ行くのにここは使わない。仙台から北海道か西日本へ向かう場合だけだろう。利用するチャンスは見込めない。

  • 新潟空港:ターミナルビル3F エアリウムラウンジ
    新潟へ行くのにここは使わない。新潟から北海道か西日本へ向かう場合だけだろう。利用するチャンスは見込めない。

  • 成田第1:第1ターミナル本館5F IASSエグセキュティブラウンジ
    海外へ行くチャンスなし。寂しいな。

  • 成田第2:第2ターミナル本館4F IASSエグセキュティブラウンジ2
    海外へ行くチャンスなし。寂しいな。

  • 羽田第1ターミナル:第1ターミナル2F エアポートラウンジ(北・南)
    第1はJAL系ターミナル。2箇所あるんだ。

  • 羽田第1ターミナル:第1ターミナル1F エアポートラウンジ(中央)
    ここにもあるから南北とあわせて計3箇所か。知らなかった。

  • 羽田第2ターミナル:第2ターミナル2F/3F/4F エアポートラウンジ
    こちらはANA系。同様に3箇所。知らなかった。九州方面へ行くときは南ピア2F、北海道方面へ行くときは北ピア4Fのラウンジ利用が便利かもしれない。

  • 羽田国際線:ターミナル4F Sky Lounge
    利用しないもんね。

  • 中部セントレア:ターミナルビル3F プレミアムラウンジ「セントレア」
    殆ど利用しません。

  • 伊丹空港:2F
    結構利用することもあったはずだけど、ラウンジに行く気にはならない。

  • 関西空港:出国審査前1箇所(3F)、出国審査後3箇所(2F)。

  • 神戸空港:2F
    どうせ便数が少ないから利用することも無いでしょう。

  • 広島空港:2F
    ここも飛行場が遠い。バスの中でラウンジタイム終了。

  • 高松空港:2F
    飛行場が遠いからバスに乗っていて十分リラックスしてしまう。

  • 松山空港:2F

  • 徳島空港:3F
    阿波踊り空港にもラウンジあったのか。知らなかった。キャンセル待ちまで長いのでラウンジ利用は有用だね。

  • 福岡空港:3F
    割とジャストインタイムで付くからラウンジまで行くことは少ない。ここはビール1缶が無料サービスです。

  • 長崎空港:2F

  • 熊本空港:2F

  • 鹿児島空港:2F

  • 那覇空港:1F北
    お土産をチェックしt時間は消えたかな。でもお店が少ないからラウンジ利用も悪くない。

  • ホノルル空港:1F



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





.*.

[ 投稿者:ISMSNEWS at 09:09 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

寸暇を惜しむ諸先生
寸暇を惜しむ諸先生

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

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

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

彼らは、

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

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

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

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

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

.*.

空港ラウンジ

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

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

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

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

.*.
[ 投稿者:ISMSNEWS at 09:07 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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



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






  1. 予防のコスト

  2. 是正のコスト

  3. インシデント対応コスト






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



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



.*.





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



.*.
[ 投稿者:ISMSNEWS at 09:03 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

脅威の発生頻度
脅威の発生頻度

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

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

.*.

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

.*.
[ 投稿者:ISMSNEWS at 09:00 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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

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

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

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

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

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

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

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

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

発生する総工数T=X+Y+Z
Y=X*0.1
Z=X*0.2
T=X*1.3

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

.*.

聞きかじりを繋ぎ合わせると辻褄が合わない。全く変な話。よく聞いてから書き直しだ。
[ 投稿者:ISMSNEWS at 08:52 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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

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

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

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


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

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

.*.

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

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

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

.*.

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

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

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

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

中長期計画のスパンで遭遇する可能性を認める。(1000〜3000日)
年度または2カ年計画のスパンで遭遇する可能性を認める。(300〜600日)
月度または四半期計画の中で遭遇する可能性を認める。(30〜90日)
日次または週次計画の中で遭遇する可能性を認める。(1〜7日)
あまり特殊でない業種業務なら、上記の4段階設定は収まりが良さそうだ。個々の事情を反映して組織の区分とすればいいだろう。

.*.

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

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

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

.*.

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

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

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

.*.
[ 投稿者:ISMSNEWS at 08:50 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

脅威の洗い出し
脅威の洗い出し



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



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



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



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



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



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



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




  • 既存の管理策の効果を上げる。

  • 予定の管理策を実施に移す。

  • 未来の管理策を引き寄せる。



.*.





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








  1. 情報の保管状況から想定できるリスク

  2. 情報の移動方法から想定できるリスク

  3. 情報の利用方法から想定できるリスク

  4. 管理者・利用者等のヒューマンエラーに関連するリスク

  5. 疲労・風化・拡散に伴うエラー

  6. 技術革新・制度改革・イノベーションに伴うリスク



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





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





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





.*.


[ 投稿者:ISMSNEWS at 08:45 | ISMS四方山話 | コメント(0) | トラックバック(0) ]