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

Google広告

2011年12月28日
ランサムウェア ransomware
ランサムウェア ransomware

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

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

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

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

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以外とやった方が紛れが無いということかな。誰にとって重要な変更なんだろう?。
[ 投稿者:ISMSNEWS at 11:44 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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

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


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

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

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

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

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

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

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

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

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

2011年12月27日
統合審査に固執したBSIジャパンの失敗


統合審査に固執したBSIジャパンの失敗

統合審査とは複数の規格に対して一度の審査で済まそうというもの。審査のための負担が軽減できることがセールスポイントです。

個別に審査するとそれぞれ準備とかがあります。部門もコンサルもつど時間を作る必要があります。品質も環境も情報も、関係の無い会社はありませんから、それが一度で済むと考えたら魅力的です。

<失敗の検証>

管理を統合するときのベースが何か。これは品質管理しかありえないのです。第三者認証制度におけるカスタマーベースは実は圧倒的に品質が多いのです。歴史的にも品質が先行しています。付き合いも古く信頼も厚い世界ができているのです。

品質は取っていて情報がこれからの企業は、品質と同じ審査・コンサルで情報を取りに行きます。

品質も情報も取っているところが統合するときはイニシアティブは品質側が取ります。

情報は取っていて、品質を新たに取るときは、まさにこのカテゴリーがBSIのねらい目で、情報をベースに品質を取り込みたいと考えても、実は無理な相談です。品質管理(=基幹系事業の本体)と情報管理(=支援系部門)では最初から喧嘩になりません。統合は困難ですし、統合する場合は品質側の都合に合わせるしかありません。

統合審査を戦略的に位置づけたのは企業の基幹プロセス、支援プロセスを理解していないBSIジャパンの弱点を露呈したようなものです。

もう一つの失敗は何もいい結果を残さないということです。

コンサルも企業側もそれぞれ専門の担当が必要なわけですから審査員だけが一人何役をやっても意味がありません。特定の審査員のゆがみ(誰にも得意不得意はあります)が全てに反映することにもなりますから、審査の健全性がだんだん怪しくなります。審査員を分けることでカバーできていたものができなくなります。

結局、統合審査は品質に強いJQAにとって魅力的な手法でしかありませんでした。多分。

.*.

誰のための統合審査か?

クライアントを抱え込む手段。審査員不足を補う手段。審査効率だけを追求する審査機関の御都合なやり方に過ぎない。クライアント側は別担当。同時にやれば待ち時間ばかり増えて内容的には非効率な審査でしかない。

出来の悪い審査員(不適合も観察で済ます審査員)がきて、ISMSだけでなく、QMSとかEMSとかでもやられたら会社のマネジメント水準は一気に下がってしまう。複数の審査員による多様な視点すら失ってしまう。ばかげた話だ。

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

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

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

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

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

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

.*.

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

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

ISMSの有効性
ISMSの有効性

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

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

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

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

.*.

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

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

.*.


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

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

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

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

KPIの要件
KPIの要件

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

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

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

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

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

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

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

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

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


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

2011年12月26日
クライアントがクレームする本当の理由?
クライアントがクレームする本当の理由?

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

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

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

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

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

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

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

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

疑心暗鬼!

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

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

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

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

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

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

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

.*.

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

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

.*.

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

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

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

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

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

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

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

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

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

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

.*.

整理すると、


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

.*.

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

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

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

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

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

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

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

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

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

手順で考えると、

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

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

.*.

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

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

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

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

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

2011年12月25日
ISMSでマインドマップ(Mind Map)を使うなんて変な気がするが?
ISMSでマインドマップ(Mind Map)を使うなんて変な気がするが?

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

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

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

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

.*.

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

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

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

.*.

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

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

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

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

2011年12月23日
27001:2013 10. Improvement
Improvement

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

予防処置が消えている。予防処置の項目で単独に活動している実態が殆ど無いこと、実際の予防処置は、リスクアセスメントとか事業継続管理にけるリスクケース分析の中で実施されていることを、踏まえれば当然かもしれない。
[ 投稿者:ISMSNEWS at 22:40 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

27001:2013 8.Operation
Operation

1. 運用計画と管理:

何処から何処までが運用(Operation)なのかな。日常管理的な部分と、年間の手順、イベントまでを含むのでしょうね。
[ 投稿者:ISMSNEWS at 22:35 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

27001:2013 7. Support
Support

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

改訂版では「文書と記録」の形をやめる。両者に本質的な違いを見つけることは困難だから。
[ 投稿者:ISMSNEWS at 22:34 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

27001:2013 6. Planning
Planning

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

資産の洗い出しからリスク評価までの一連の手順を踏まえてリスクを明確にすることは従来どおりとして、機会(Opportunities)の方は分かり難い。単純に改善機会と捕らえることにするかな。
[ 投稿者:ISMSNEWS at 22:33 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

27001:2013 5. Leadership
Leadership

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

1. 基本要求
2. 経営者の責任
3. 方針:基本方針のこと?
4. 組織の役割、責任、権限
[ 投稿者:ISMSNEWS at 22:31 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

27001:2013 4. Context Of The Organization
Context Of The Organization

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

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

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

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

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

4. 情報セキュリティマネジメントシステム:推進または管理のための組織。ISMS委員会など。
[ 投稿者:ISMSNEWS at 22:30 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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リリースの目的?


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

2011年12月19日
業務委託先に情報資産を貸与したら?
業務委託先に情報資産を貸与したら?

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

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

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

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

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

.*.

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

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

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

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

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

.*.

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

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

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

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

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

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

.*.

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

.*.

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

事業継続やりますと何処かに書いてあれば1点。
事業継続管理の担当者や体制を決めていれば1点。
リスクケーススタディがあれば1点。
BCP策定対象を決めていれば1点。
BCPが策定されていたら1点。
レビューがされていれば1点。
BCPのサブセットでも訓練していたら1点。
フルセットなら更に1点。
訓練の目標と実績が記録されていたら1点。
課題が抽出されていたら1点。
トップマネジメントに報告されていたら1点。
課題に基づいてBCPの見直しがあれば1点。
見直し結果がリスクアセスメントにも反映されていたら1点。
BCPのケースが昨年より増えていたら1点。
全社のリスク管理体制の中に位置づいていたら1点。
ビジネスパートナーや地域と一緒にやっていたら1点。
書き出すとキリが無い。10点以下でグッドポイントは有り得ないでしょう?

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

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

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

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

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

バックアップシステムも同様。待機系を動かしたのは導入時に1回だけでは馬鹿と言われる。懲戒解雇でしょう。奇数月はA系、偶数月はB系などとする利用もある。毎月訓練しているのだから。
[ 投稿者:ISMSNEWS at 22:20 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

共有キャビネの鍵管理
共有キャビネの鍵管理

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

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

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

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

どういう意味があるんだろう。中の物(文書類、メディア類)が紛失していたらトレースできるだろうか。どうしても記録にこだわる場合は、利用目的(アクセスした情報と用途)も記録しないと意味が無いかな。鍵を各担当に持たせたら、記録をスキップされたらそれまでです。鍵の管理者を別に定めて、記録をとれば一定のトレーサビリティは確保できる。
[ 投稿者:ISMSNEWS at 22:18 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

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

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

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

まあ、部署名が入っていれば内容も分かっているのだから、社名は分かるね。大した話ではない。
[ 投稿者:ISMSNEWS at 22:14 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

2011年12月17日
ソフトウエアライセンス管理台帳の作り方
ソフトウエアライセンス管理台帳の作り方

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

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

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

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

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

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

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

.*.

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

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

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

2011年12月16日
Pマーク制度の弊害?
Pマーク制度の弊害?

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

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

せめてISMSレベルの審査が出来ないものか。
[ 投稿者:ISMSNEWS at 22:11 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

2011年12月12日
移転審査って何ですか?
移転審査って何ですか?

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

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

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

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

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

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

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

.*.

<安きに流れる移転の真因>

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

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

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

お作法で済ますなぞるだけの審査では泰樹に流れて当然。統合審査、複合審査、言葉は変えても結局、手際よくやるだけの無価値審査。
[ 投稿者:ISMSNEWS at 22:05 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

2011年12月11日
チェックリストって殆ど無駄じゃないの?
チェックリストって殆ど無駄じゃないの?

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

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

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

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

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