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



この広告は30日以上更新がないブログに表示されております。 新しい記事を書くことで広告を消すことができます。

Google広告

2012年04月10日
ISO17021の2011改定
ISO17021の2011改定

何がどのように改定された歯知らない。この規格は審査員又は審査機関にたいするものだから。

これを手掛かりに認定基幹は審査機関を厳しく監視する。結果、審査機関の問題行為は減る。

問題行為とは癒着、なれあい、。

暗躍型のコンサルが困る事態ならほんものだけど、あまり影響は出ていない。多分。
[ 投稿者:ISMSNEWS at 16:07 | (道草) | コメント(0) | トラックバック(0) ]

2011年07月15日
出かけましょう!歩きましょう!
出かけましょう!歩きましょう!

パソコン、ゲーム、スマホで済ますスタイルは絶対にいけない。デジタル時代は放っておいても情報はやってくる。放っておいても管理されてしまう。むしろアナログ的に生きて人間性の生の部分を維持しましょう。
[ 投稿者:ISMSNEWS at 11:07 | (道草) | コメント(0) | トラックバック(0) ]

Smart Magic Security
Smart Magic Security

格好良い魔法のようなセキュリティ管理?

中身は?

成程ね。第三者認証制度の盲点を突いているな。確かに、第三者とは言っても何時の間にか第三者でなくなっている。只のサービス業じゃないか。ということね。
[ 投稿者:ISMSNEWS at 11:02 | (道草) | コメント(0) | トラックバック(0) ]

2011年07月01日
風呂屋の隣2
風呂屋の隣が飲み屋。売れるのは牛乳。意外な客として先生が多い。似たような話が毎晩繰り返される。先生方が直接経験したこと、ただ聞いただけの話し。面白かろうと勝手に作った話。

成る程。これが四方山話というものか。

虚虚実実の繰り返される話は妙な空気を作って伝染病みたいに、人から人へ移っていく。

こちらは場末の女給みたいだけど、一応学校は出ている。何の警戒心も無く、声も潜めず。いい加減な話をしていることに少し腹立たしくもなる。

メモしてみることした。そうすれば客と話をあわせることも出来るようになる。
[ 投稿者:ISMSNEWS at 00:27 | (道草) | コメント(0) | トラックバック(0) ]

風呂屋の隣
風呂屋の隣の飲み屋。飲み屋と言っても牛乳が一番売れる飲み屋。湯上りのほてりを冷まして、次はアルコールで温めなおすなんて、人間らしい。酒は日本酒もビールも洋酒も何でも置いてある。まるでいい加減な飲み屋。つまみは乾きもので済まされたり。

どう言う訳か、出張者のたまり場になっている。一週間いてビジネスホテルからわざわざこの風呂屋に足を運ぶ連中。彼らはカラオケよりも客の悪口でもないが残念をしきりに口にする。語り口は先生様。会社は別でも客の悪口の話は共通らしく変に盛り上がる。

先生方は大方は年配の紳士といった雰囲気。若い人も混じる。若い人は二色。使い走りのような小気味良い反応をする人と、如何にもエリート然とした雰囲気の人。能書きが達者なだけで、傍から見ていても気分はよくない。時に、女の先生が入ったりもするが、盛り上がり方は変わる。女といっても年齢は相当なんだけど、異性が混じると意識しないではいられないらしい。

しかし、まあ、人が変わっても会社が変わっても、似たような話を延々繰り返すだけで、テープを巻きなおしてみている感じ。駄目だ駄目だといっている人が一番駄目に見えてくる。

所謂、コンサルタントの先生。どう言う訳か審査員の先生も混じる。コンサルタントは二枚舌どころか全身が舌で出来ているような、一体何が本当の本音かは皆目分らないようにも思う。コンサルという種族はどこまで行っても実が無い寂しい人たちのようにも見える。

口先商売の先生に共通する特性?なのか、必ず何処かで線を引いて其処から先へは梃子でも行こうとしない。当事者にならない。

.*.
[ 投稿者:ISMSNEWS at 00:14 | (道草) | コメント(0) | トラックバック(0) ]

2010年06月10日
モバイルコードに対する管理策
モバイルコードに対する管理策

この頃は広くフリーソフト全般に対する管理策として理解することが多い。

ホワイトリスト方式とブラックリスト方式があるが、セキュリティを意識したらホワイトリスト方式が普通でしょう。

依然は管理工数の関係でぶらっくをリスト方式が採用するところが多かったが、最近はホワイトリスト方式の採用が増えてきた。

いずれにしても情報システム部門の検証を踏まえてリストにアップされる。

企業規模に比べて情報部門が貧弱な場合は、開発元が明確、アップデートが定期的にされている、業界の実績があるなどの条件を栗すれば部門判断で導入を認めるところもある。

どのような場合でも、基幹ネットワークから分離されたテスト環境を持つことは必須であるが、担当者の意識が無防備なことが余程懸念される。一生懸命に頑張っていることとシステムの脆弱性とは何も関係ないということに気づいてほしい物だ。
[ 投稿者:ISMSNEWS at 00:02 | (道草) | コメント(0) | トラックバック(0) ]

2010年04月13日
4.3.1 c)項とg)項の違いは?
(久しぶりに戻ってきました)

4.3.1 c)項とg)項の違いは?


4.3.1一般のところで、c)項とg)項の要求の違いが分からない。分かりにくい。

g)項は管理策の実施手順。有効性評価手順、計画策定手順でも、なんでもかでも良くて、組織が必要なら文書化して良いよというレベル。

c)項はISMSを支える手順だから、ISMSマニュアルのような上位文書。

問題は2つ。

1つ目は、c)項とg)項の間に線引きが明確に出来るか。厳密な線引きは必要ないし、厳密な線引きはやりようがない。組織の判断で、カテゴリー分けが必要ならやれば良い。

2つ目は、133項の管理策全てに対して手順の文書化が必要か。認証機関や審査員によって答えが違う。1行書きも含めれば全て何らかの説明は必要と考えるのが実際的。項目xxについてはあちこち読んで感じて下さいの乗りでは無理でしょう。
[ 投稿者:ISMSNEWS at 01:34 | (道草) | コメント(0) | トラックバック(0) ]

2008年03月10日
ISO不正企業排除!
経済産業省は不祥事が相次ぐ中でのISOの信用回復に動き始めた。ということに成るかな。JAB等の国際規格運用を厳格化することで要請が入るだろう。

効率一辺倒の今の審査を見直すチャンスでもある訳だが、審査機関の過当競争にどのように歯止めを掛けるかが問題。

実は極めて簡単です。

サイトに掛ける審査工数を、増やすようにガイドすることです。サイトが分散しても纏めて見積もってしまうこと(そのほうが安くなるからですが)を戒める。

規格の厳格な運用とか型どおりに言っているだけでは、結局問題は見過ごされる。経産省に識人がいないから既存の枠組みを好む勢力に適当にごまかされてしまうかもしれないが、この単純な本質に入ってこないと目的は達成できない。

続きを読む ...
 
[ 投稿者:ISMSNEWS at 17:58 | (道草) | コメント(0) | トラックバック(0) ]

2007年11月02日
持ち出せば失う
外に持ち出せば、忘れるか、奪われるか、破損させるかして、結局のところ失うことになる。

http://www.asahi.com/national/update/1102/TKY200711020112.html?ref=rss

後を絶たない。

・出かけても持ち出さない。
・出かけない。

会議は最先端の電話会議、テレビ会議。専門の宅配業者。

*

肌身離さず! ウエラブルですか? まず無理ね。

*

逆転の発想�
なくしても大丈夫。超暗号化。

*

逆転の発想�
ネット上に預けっぱなしにしておいて必要時に鍵で開けて見るだけにする。本当に大事な資料は置けない。所詮仕事レベルは置ける。安全なインターネット環境を準備し、社員はシンクライアント相当のマシンを持ち出して、必要時にアクセスして利用する。シームレス・セキュリティ。社内も社外も同じインフラ。イントラ・インターネット環境。会社の情報部門が構築するのが普通と考えがちだ
が、そんなノウハウは企業情報システム部門にはない。だから、KDDI、ニフティ、グーグル、IBMなどに委託することになる。モバイル端末も社内社外
シームレス仕様になるだろう。

端末(ハンディ多機能端末)、バイオ、PIN(暗証コード)。端末はID付き(ノード認証付き)プラス位置情報付き。位置はゾーンセキュリティを社内社外でダイナミックに設定する。

最近多いIC付きIDカードは単独では、其のカードを奪われればアウト。他と組み合わせればセキュリティは上がるが、ベストパートナーとして生き残る可能性は小さい。PKI署名情報を格納していても、それは端末に入れれば済むこと。

ICカードはただのパッシブなツールでシームレス管理には向かない。アクティブツールの端末であること。電話の届かないところでは、モバイルシンクラも使えないから。

ローカルに蓄えた情報は認めない。認める場合は自然揮発型(時間経過OR再起動の早いタイミングで自動消去)。

「モバイルシンクラ(ノード)+多機能端末(ノード+位置)+バイオ+PIN」の全てが揃って始めて利用可能。

如何?
[ 投稿者:ISMSNEWS at 21:01 | (道草) | コメント(0) | トラックバック(0) ]

2007年10月26日
フォレンジック
フォレンジックと言う聴きなれない言葉に出会うが直ぐに忘れてしまう。

「法的に有効な手段で過去に発生した事象を立証することが可能になる」ことがらかな。

改ざんが行なわれた、アクセスがあった、メールが送られた、などの情報システムの利用に関わる事象を合理的に証明可能とする活動が、多分、デジタル・フォレンジックかな。

法的な問題が発生した時に、確実に相手(加害者)を訴えることが出来る、あるいは、訴えられた時に抗弁できる材料として用意すること。

近頃、電話をすると証拠のために録音しますとメッセージが出ることがある。これは変ないたずら電話などは防止できてしまう。

ところで、証拠を集めまくった時に、自分に非がある材料も集めてしまう。この場合、隠蔽・隠匿しても良いのかな?

[ 投稿者:ISMSNEWS at 20:04 | (道草) | コメント(0) | トラックバック(0) ]

2007年10月04日
ISO1007
ISO1007

「品質管理-構成管理の指針」と言うものらしい。構成管理って実はあまり馴染みがないので基本を押さえたいが、指針の中で構成管理の定義を以下のように行なっているらしい。

***/+/***

「構成管理とは,製品の構成を文書化するものである。構成管理は,ライフサイクルの全段階で,識別及びトレーサビリティ,その物理的及び機能的要求事項の達成状況並びに正確な情報へのアクセスをもたらす。構成管理は,組織の規模並びに,製品の複雑さ及び性質に基いて実施できる。構成管理は,ISO9001 に規定されている製品識別及びトレーサビリティ要求事項を満たすために使用することができる。」

***/+/***

これってとっても大変なこと。

しかし、意識していなくても都度開発現場でやっていた。レベルはバラバラ。組織としての取組みは弱い。そうでもない。コンフィギュレーションマネジャーなんか置いていたりするから、商品開発ではしっかりやっている。問題は社内情報システムはもともとかき集め的な要素があるので、この辺のマネジメントは弱い。

だから、担当が変わるとこぼれる物もあったはず。

規格にするのはそれを許さない業界の姿勢。これは要求規格ではなくて規範規格だろう。

ISMSでは、17799の12.4.3.の実現の時に記載(宣言)してしまえば要求規格になる。ただ、12.4.3はプログラムソースコードのアクセス制御の切り口での要求なので構成管理全体の要求に答えるものではない。

*

構成管理と変更管理の整合化:

構成管理と変更管理はものの本をつまみ読みするとどうも上下がはっきりしない。一度ここで関連を整理しておきたい。

今の変更管理はシステム変更というイベント(プロジェクト)を立上げ・実施し・完了させるための手順を明確にすることに主眼が行っている。承認プロセス
である。正しい要求を正しくレビューし実行し確認する。

一方、構成管理は、システムのライフサイクルを通じて、構成内容(構成方法、環境、パフォーマンス、不具合などシステムを確実に実現させるために必要な一切の情報を含む)を管理するもの。

変更イベントの出発点と終了点の間の手順は変更管理、出発点の状況と終了点の状況の管理は構成管理のスパンと理解して良さそうだ。ストックとフローの関係のイメージで宜しいかと。

***/+/***

構成管理は、システムをターミネートしてから一定期間保管する。構成管理のスタートポイントは遅くとも最初にシステムインテグレーションを行なうシステムテストの段階から始めなければならない。

構成管理の担当者は構成(インテグレーション)を識別し、システムの各バージョンの構成の内容を台帳で管理すること。

不具合対応時に参照する性格のものであるため、台帳は容易に参照できるように考慮すること。

システム主管はシステムの構成管理を行なうとともに、その内容を構成管理統括担当提出すること。構成管理統括担当はシステムのシステムテスト開始からターミネートまで構成管理データの保管を行なうこと。

構成管理としては以下の内容を含めること。システムの特性により適宜追加すること。

・システム名、システムインテグレーション識別名
・文書構成:文書名、版番号、発効日・改定日
・ソフトウエア構成:プログラムタイトル、ファイル名、バージョン、日付
・ハードウエア構成:
・ネットワーク構成:
文書には設計書・手順書・テスト結果・不具合情報・前バージョンとの差異などシステムの機能的・物理的特性の管理に関するもの一切を含める。

構成管理情報の改ざんが行なわれると、トラブル時のトレースあるいはシステム変更が正しく出来ない。構成管理の独立した担当が望ましいが、兼務でやる場合は、結果を構成管理統括担当に提示し、他による改ざんが出来ない手当てが必要である。

***/+/***

(規則案)

上記でいいだろうか。

各システムの主管は、システムの構成管理を行なうこと。バージョンの変更が生じた時は、その構成を明確にし、全バージョンとの差異を容易に理解できるようにすること。

***/+/***

[ 投稿者:ISMSNEWS at 21:24 | (道草) | コメント(0) | トラックバック(0) ]

JIS X 0160
JIS X 0160 あまり目にしたことのないナンバーです。ネットで見ると国際規格「ISO/IEC 12207:1995 Information technology - Software life cycle process」を日本語に翻訳したものとのこと。1996年発行ってその後の見直しはどうなっているのか知らん。



・取得プロセス
・供給プロセス
・開発プロセス
・運用プロセス
・保守プロセス

これが普通の開発運用のフェーズ。



・文章化プロセス
・構成管理プロセス
・品質保証プロセス
・検証プロセス
・妥当性確認プロセス
・共同レビュープロセス
・監査プロセス
・問題解決プロセス

これは支援プロセス又は管理プロセスですね。これもプロジェクト単位のプロセス。



・管理プロセス
・環境整備プロセス
・改善プロセス
・教育訓練プロセス
・修正プロセス

マネジメントプロセス。年度計画のイメージですね。組織単位のプロセスと見てもいいかな。



今更、規格を読む気にもならないが、今まで特に困ることもなかったから無視していいのかな?

[ 投稿者:ISMSNEWS at 21:20 | (道草) | コメント(0) | トラックバック(0) ]

2007年09月11日
ISMS拡大時の注意事項
ISMSを部分的に取得してから、漸次拡大は普通のシナリオですが、注意すべきことがあります。

先行して”作ってしまった”ISMSに拘ると失敗します。

一言で言えば、適用範囲の特性に見合ったISMSでないものを無理やり当てはめる懸念があるということです。

腕力が十分あれば別ですが、普通は拡大すると、どうでも良い部署も取り込みますから、最初のISMSが必ずしも適当でありません。一端、最初のものを捨てるくらいに考えないと失敗します。これも、審査機関〜審査員が下手だと最初に作ったものに拘って是正が効きません。事務局も作り直しは普通嫌がります。

でも作り直しが一番まともで理にかないます。

この簡単なことに気付く組織は少なくありません。手間を惜しむと高く付くというより、お仕着せのISMSではPDCAは回りません。事務局だけが体裁を取り繕って空回りさせている無意味なISMSになります。

[ 投稿者:ISMSNEWS at 10:06 | (道草) | コメント(0) | トラックバック(0) ]

2007年09月07日
One Management System
「一つのマネジメントシステム」

ISO9000から始まって、ISO14000、ISO27000と来て、今後もどんどんマネジメントシステムの認証制度が出てくる見込みですが、一体、いつまで?どこまで?やれば気が済むのでしょうね。

認証ビジネスのために、あれもこれも振り回されているのか、それだと困ったものです。

実際に、世の中で問題が出て、其れへの対応が不十分だから、個別に専門的に対応している。これは、何かを運用を誤ったからです。認証制度がビジネス的にメリットする人は構わず広げていったですが、流石に過ちに気が付いて、今度は統合マネジメントを言い始めた。最悪ですね。恥の上塗りみたいなもの。問題を更に悪くしている。

[ 投稿者:ISMSNEWS at 17:35 | (道草) | コメント(0) | トラックバック(0) ]

意味の無いリスクアセスメント
ISMSを始めようとすると、手始めに問題になるのがリスクアセスメント。特に、変な審査機関というか審査員にぶつかると、ただのリスクアセスメントでは収まらず最悪。所謂、潔癖症症候群の審査員先生です。PDCAが回り始める前に息絶えます。この手の先生を素早く見抜いて、さっさと忌避できれば、深手の傷を負わずに済みますが、その見抜く方法は、適用範囲の確認のときに簡単に出来ます。リスクアセスの結果が適用範囲の記述に反映しているようなことを期待している節を見せる審査員先生は要注意と言うか即忌避ですね。

意味の無いリスクアセスメントになるのは、全点網羅型の資産台帳が出発点で
す。潔癖先生の言い分は、どのように重要な資産を洗い出したかを明確に!ですが、全ての失敗はここから始まります。そこが潔癖先生ならではです。

ではどうするか。

取り敢えず重要と思われるもの。そのカテゴリーあるいは定義を先に決めてしまう。方針の一環として、プロセス特性に応じた内容でも共通のものでも構わな
い。適用範囲を拡大しながら進めるときは、成長に応じて識別要求を区分しても構わない。

一気にやって負荷を掛けないこと。少しずつ進める。トップを諌める。急発進・急ブレーキは怪我の元。

それでも、意味の無いリスクアセスメント

それは既に分かっていることしか分からないと言う現実です。リスクアセスメントと言う形を記録で作っても、新たな発見は殆んど有りません。それはリスクアセスメントのスキームがそうなっているからです。即ち、リスクアセスメントでは既に認識できている脅威・脆弱性を並べる訳で、新しいものは殆んどの場合ありません。最初から問題と分かっているものを単にリスク評価シート等の構造図上に展開したに過ぎないからです。

トップの「四の五の分析なんかやってないで、さっさと対策してよ」になる訳です。

身体で感じているリスクを文書・記録にする作業だと割り切れば、負担も無く
さっさと出来ます。

「リスクアセスメントとは、未知のリスクを発見する手順でなく、既知のリスクを構造的にあるいは定量的に理解する手順」

網羅性の呪縛から漸く抜け出ることが出来ます。

ではリスクはどこで認識されるか。通常の業務プロセスの中で認識できます。というより其処でしか本当のリスクは見えてこない。もっとも感性を磨く活動なんかは当然必要ですが、いずれにしても現場です。

[ 投稿者:ISMSNEWS at 15:50 | (道草) | コメント(0) | トラックバック(0) ]

2007年08月28日
ISO規格の相互関係
ISO規格が複数出てきて微妙にカバー領域が重なる。気分が悪いので簡単に整理しておくことにした。

スタート:「組織の目的達成」が基本命題。

・目的が達成できる度合い=リスクであることを考えるとRMS。

・目的達成の仕組み=プロセス品質であることを考えるとQMS。

結果からのアプローチと手段からのアプローチの差で、基本命題を素直に受けている。

リスクは期待とのギャップであるが誰の期待かを考えた時に、経営者(組織)の期待とステークホルダー(経営者を含む全ての関与者)の期待の両方あるが、組織は誰のものかを踏まえれば後者の視点が求められる。CSR
その他の規格:BCMS、EMS、ISMS、ITSMS、・・・は特定問題に対する専門的な要求を取り込むための特定問題の側面のアプローチと見たほうが収まりが良い。

QMSは極めて汎用的な形で規格を設定できているが、RMSに相当する規格は明確でない。近いポジションはBCMSとかSRMS(CSRのISO26000。マルチステークホルダの概念:消費者まで含めて関与者が参加する経営のあり方も入って来ているのが特徴的)とか。SRMSは目的達成は全員ハッピーな形=民主主義?で、それを脅かすものは全てリスクとする。?

事業継続は、まだサービスを提供する側の視点での捉え方。SRMSはサービスの受けての視点だから、結果管理に近いので、さらに信用とか印象とかまで入り込むことも有り得るので、結果指標としては今のところ最有力と考えて良さそう。ただ、SRMSが認証規格かガイドラインかは気になるが、数値化された結果指標として、誰の目にも明らかな達成度が公開されることになるであろうから、認証する必要すらないかもしれない。

尚、統合マネジメントシステムIMSは、単に枠組み上あるいは書式上の統一化であって、本質的な意味を持つものではないので、ここでの問題とは直接関係なさそうだ。

という事で、やはり、判定する側から見たら、QMSの審査〜プロセスの審査が、組織から見たら品質マニュアルの作り込みが大事というか必須ですね。

[ 投稿者:ISMSNEWS at 13:10 | (道草) | コメント(0) | トラックバック(0) ]

2007年07月30日
Organization vs. Management
ISO関連の規格を見ると良くお目にかかる用語に「Organization」と「Management」がある。「Organization shall ...」とか「Management shall...」とか。日本語化された規格では同じ意味で使われている様に見えることがある。どの規格の何処とは思い出せないから、解説していた人または書物の問題かもしれない。

ここでは直訳で「組織」と「経営者」と読み替えてみる。其の方が現実的で正しいからです。問題は意味することの理解です。

「組織はレビューをすること」とある場合は、組織の役割責任、あるいは組織の活動計画に、レビューの項目が入っていることを要求します。計画的に内部監査が行なわれることなどが該当します。

「経営者はレビューをすること」とある場合は、経営者によるレビューですか
ら、組織レビューも一切を含めて、経営者自身によるレビューが実施されることが要求です。

もっと難しいのはマネジメントがあちこちで使われていること。

[ 投稿者:ISMSNEWS at 19:13 | (道草) | コメント(0) | トラックバック(0) ]

2007年07月28日
JIPDECの県別ISMS認証取得事業者数
JIPDECの県別ISMS認証取得事業者数の表はいつ見ても変。間違っている。この表を作った人は日本人じゃないね。そうか超偏見の持ち主。公共の仕事に携わるのは止めた方が良いと思いますが、如何でしょうか。

従来の分け方を無視してやるとデータの意味が変わってしまう。さっさと普通に戻しなさい。関東、中部、近畿の区分ぐらい理解してからやって欲しいね。要するに中部をまるで分かっていない。中部甲信越、中部北陸とあってここから外すのは山梨だけです。後は全部中部です。

顔が東京向いたら全部関東にしているようですが、そう言うことをしたら、沖縄も北海道も関東になりますね。分けている意味が無いでしょう。

関東から3つ、及び近畿から1つを外して中部に入れること。


[ 投稿者:ISMSNEWS at 11:06 | (道草) | コメント(0) | トラックバック(0) ]

2007年07月11日
お題は「審査」
鮮やかな感動を伝える一句を頼みます。
[ 投稿者:ISMSNEWS at 19:22 | (道草) | コメント(0) | トラックバック(0) ]

2007年06月13日
関西人のリスク感覚
まだ噂だから本当のところは分からない。以前にも流れていた噂ですね。あの大手企業がISMSを本格的に始めるらしい。グループ総がかりでの取り組みはチャレンジ。拍手。情報セキュリティなら当然とも言えるけどなかなかどうして出来ないこと。

がしかし、問題は選んだ審査機関でしょうね。例の規格の一字一句に拘ることで有名なところらしい。

周り回ってこちらにも来てくれたりしたら、勘弁ですわ。

思い出すだけで嫌になる。

はっきり言うてはた迷惑ですが。会社もやるのは構わんけど考えて欲しい。

まあ形式的で何もならんこと分かってから修正ですか?




幸さんが泣いてますよ。
[ 投稿者:ISMSNEWS at 20:29 | (道草) | コメント(0) | トラックバック(0) ]

2007年05月23日
功を焦った認証取得
功を焦った認証取得はどういう結果を招くか。ある人には耳の痛い話。

組織を切り刻んでの取得はよくある話。これは方向がまとまった組織全体への拡大を意識している限り問題にならない。

厄介なのはシステムを刻んだ場合。特定のシステムを適用範囲とした場合はやがて収拾が付かなくなる。

取得を急ぐ場合は特定プロジェクト、特定システムだけで安直に取得に走る。困ったことにそう言った事を焚き付けるのが審査機関ですから。始末が悪いのです。

功を焦ったのは審査機関ですからね。

そういうことに気付いたらさっさと返上すべきです。何の価値も無いだけでなく返って歪んだマネジメントになり組織に取って害となります。

[ 投稿者:ISMSNEWS at 20:46 | (道草) | コメント(0) | トラックバック(0) ]

2007年05月22日
IMS
囲い込み戦略に使おうと各社が躍起になるなか、一歩リードしたのは圧倒的な檀家集団を抱える品質協会です。
サイトのオセロゲームでなく、規格ごとひっくり返すやり方だ。管理の基本の品質の檀家ベースを使って統合の名の下に環境もセキュリティーも取り込む算段ですね。
BSIはそのため又しても新たな規格作りに入る。PAS99がそれです。規格を作ったからと言って特にアドバンテージが有るわけではありません。

リーダーとフォロアー、その境が難しい。
[ 投稿者:ISMSNEWS at 08:35 | (道草) | コメント(0) | トラックバック(0) ]

2006年12月06日
適用範囲外指摘
滅多にないことだが外部インターフェイスを見ていて適用範囲外領域の問題を見つけて指摘する審査員がいます。審査員の経験不足が前提にあってのことですが、普通は所謂インターフェイスの管理策として適用範囲内の管理策の問題に視点を変えて問題の本質を確認します。

しかし始末の悪い審査員が加わるとしかもベテランの場合は悲惨です。一旦思い込んだら規格解釈の問題に土俵を換えてでも指摘を撤回することはありません。

ベテランで始末が悪い審査員はいえば札付きですから表に出てこないのですが、忙しい時期に借り出されて表にでてくるのです。

ISMSの事務局は札付きが申請されたら拒否するのが大切な仕事ですね。

オフ会のオフ会では、その審査機関を選んだ段階で既にミスをしていると笑い者にされていた。

確かに。

打算で始めたISMSは打算の根拠が曖昧になった段階でいろいろな所を足掛かりに破綻していくものですね。

適用範囲外の指摘は是正確認のステップまで続くので審査の有効性はいよいよ妖しくなります。

審査機関によっては判定会議がありますがセレモニーに過ぎないし記録に残した物を変えることはまずありません。

適用範囲内の問題を指摘出来ない時はオブザベーションとするのが常識ですね。そして札付きを抱えて送り込むような審査機関を選ばないのも常識です。

数社の審査機関の人からそれとなく話しを聞けば直ぐ分かることです。それも出来ない人は事務局には向いていないかも知れませんね。
[ 投稿者:ISMSNEWS at 09:09 | (道草) | コメント(0) | トラックバック(0) ]

2006年10月21日
内部監査人資格
内部監査人資格CIA
世界で六万人。

アイエスエムエスとは別物です。
[ 投稿者:ISMSNEWS at 14:19 | (道草) | コメント(0) | トラックバック(0) ]

2006年10月09日
Jの神話
ある審査機関Jで聞いた話。半分嘘です。Jの神話。サーベイランスでは仕組みの問題に触れない。仕組みを初回で合格させているから仕組みの問題を指摘すると自分が見落としたことがあからさまになる。だから言えない。更新は三年後だからその時のは仕組みに触る事も言うらしい。二年目も三年目も同じデショ。根拠に乏しい。手抜きを容認させるためのただの言い訳ですね。

入口は規格と首っ引き。その後は枝葉末節でお茶を濁す。こんな認証貰っても有り難くも何でもない。

そもそも他人の判断で進めてお客さんに責任果たせますか、。
[ 投稿者:ISMSNEWS at 14:20 | (道草) | コメント(0) | トラックバック(0) ]

2006年10月05日
オフィス移転の情報セキュリティ
オフィスの移転、オフィスの引越し

そのような時にも情報セキュリティ問題は避けて通ることは出来ません。

情報セキュリティ問題に対処する基本は常にリスクアセスメントにあります。

1)先ずは、移動させる情報資産の洗い出しを行います。
・資産は引越し荷物ですから明確です。
・書類、メディア、パソコン/サーバー
・ケーブルとかディスプレィなどコンテンツに関係ないものは通常の引越しレベルで問題ないでしょう。

2)次に、脅威の洗い出しを行いますが、そのためには以下の状況・プロセスを押さえます。
・移動時の梱包形態
・取り扱い業者
・車両の特性
・運搬ルート
・当日中に作業が終わらなければ、何処で一泊させるか。

3)脅威・脆弱性
�輸送時の事故または不注意による破損(普通の引越しでも此れは確率が高い)
�大手企業の引越しの場合は大量のOA機器を狙っての窃盗(あまり聞いたことは無いがリスクケースとして想定できる)
窃盗は輸送時と一時保管時が考えられる。
�紛失。小物のメディアが何かに紛れて紛失するケース。

�については、
・身元のしっかりした人であることを確認しておく。(確認してもらう)
・輸送時の一時預かり倉庫は鍵の施錠管理、24時間守衛体制などを確認する。不足なら守衛を立てる。
・輸送車とオフィスの間にバッファをおく場合は見張りを付ける。
等の施策で十分であろう。(テロの余蘊赤く新藩についてのリスクは受容する)

�については、
・機密性より、完全性の問題。だから、対策は、本当に重要なファイルは予めバックアップを取る。バックアップの取り方はイントラネット上のファイルサーバを利用するのが一番楽。其処に収まらない場合は、メディアに抜いてセキュリティデリバリーサービスを利用するか、それでも心配な機密情報の場合は自分でジュラルミンケースに腕鍵を付けて手持ちする。銀行の貸し金庫にでも預ける(映画並み)。心配馬鹿に付き合っているとキリがないが、そう言う情報がゼロでもないからやってもらってよい。きっとセコム辺りがサービスしてくれるだろう。電子情報ならサーバーの容量を増やせば済むが、ハードコピーはそうは行かない。

�については、
紛失は始末が悪い。ある確率で必ず発生する。大事なものは只の備品と同じ扱いにしないで、何処にも紛れない工夫をすること。必要なら自分で運ぶ。



引越し2日のために、暗号化ソフトを入れるとか、バックアップサーバーを増量するとか、メディアに改めて抜くとかは、おかしな話だ。「あつものに懲りて膾を吹く」会社は案外真面目に取り組むかもしれない。まあ、だからIT業界は救われているんだろうね。

本当に重要なコンテンツなら日頃から、HDDは引越ししなくてもいつでもクラッシュするチャンスがある訳だから、バックアップを取っているはず。もし取っていなければ今すぐ実施してもらえばよいこと。

日頃やっていないで済ましたことを引越し・移転で大騒ぎして、責任転嫁を図るのは不届き千万ですね。



と言うことで、共有ファイルサーバーには既に重要情報は収まっているし、それでも足りない(容量的または完全性の意味で)場合は、別にメディアに落とされて大事に管理されているはず。

ファイルサーバーは運が良ければ運ばなくて良いし、そのメディアはセキュリティデリバリーを頼めば済むこと。

引越し・移転の実行委員は特に騒ぐ必要も無いことです。



こう言うときに騒ぐのはいつも同じ人ですね。情報セキュリティから合理性を外すとこうなるという見本みたいな。
[ 投稿者:ISMSNEWS at 20:16 | (道草) | コメント(0) | トラックバック(0) ]

2006年08月22日
ソックス法と情報セキュリティ
ソックス法のリスク分析にISMSは使えるか?

ソックス対応で洗い出したプロセスから、情報資産の洗い出しに一度落とし、リスク分析に繋ぐ。

逆かも知れない。最初に財務諸表に関係する資産が洗い出しされた、そのリスク分析をプロセスの視点でチェックし脅威脆弱性に繋ぐ。

しかし、IT統制ではシステムが洗い出しされる。システムを資産と見るかシステムを分解して行くかはそこのやり方だろう。

開発フェーズと運用フェーズがある。そこは要注意だ。
[ 投稿者:ISMSNEWS at 21:21 | (道草) | コメント(0) | トラックバック(0) ]

2006年08月03日
データセキュリティ基準
ペイメントカード業界・データセキュリティ基準、PCI DSSは国際カード五社が共同で策定したクレジットカード情報保護に関する国際基準。

取引先への遵守要請を始めた。
[ 投稿者:ISMSNEWS at 12:18 | (道草) | コメント(0) | トラックバック(0) ]

2006年07月24日
ISO15489
ISO15489はレコードマネジメント関する国際標準。

レコードの「真正性」「信頼性」「完全性」「利便性」の確保についてのガイド
レコードの生成から処理(利用?)・保管・保存・廃棄までのライフサイクルの中での管理ガイド。要求規格ではない。文書管理に対する記録管理に近い概念か、トータルな文書管理に近い概念かは未確認。

マネジメントシステムの国際標準では文書管理・記録管理についての要求が含まれるのでその時のレベルとして求められる内容はこのISO15489を踏まえていることが一つの目処となるであろう。

2001年に制定されたものが現在改訂作業中の様子。2001年版のJIS化:JIS X
0902-1、-2は2005年に行われた。

今回のISO15489改訂でマネジメントシステム(ISO9000/14000/27000)との関連をどのように記載するかは関心の持たれる所です。
[ 投稿者:ISMSNEWS at 21:04 | (道草) | コメント(0) | トラックバック(0) ]