審査に出かける前に、訪問先の部署の概要を把握することは、多くの場合、WEBサイトから容易に出来る。その特徴を踏まえて、予めどの管理策についてチェックするかプランを用意することは、初心者には有効。内部監査の場合は、事務局が用意することが多いが、主体的取り組みを是とするなら、監査員自らも準備してみることは有益。もっとも、事務局が想定していない質問が出て関係部署には迷惑掛けるかもしれない。
<会議室またはテーブル>
「部署名」
「責任者」
「ミッション」~「業務概要」
「組織構成」~「上位・全体組織」・「取引先」
「重要資産」~「重要資産のプロセスフロー」
「管理体系」~「現場で利用している・認識している管理標準」
「重要資産に対する管理策※」
「インシデント・内部監査等指摘事項対応」
<現場>
「テーブル審査で現場確認したもの」
「物理的」~「施設・ゾーニング・ケーブル・鍵管理など」
「資産識別」~「ファイリング、メディア管理」
「人的管理」~「スキル、周知、個人の役割実施状況」・「誓約書など人事」・「インタビュー」
重要資産に対する管理策※
3桁レベル(A.x.x.x)で優先度を付けて10個程度*用意する。前半で確認できなかったものは現場から引き上げてから確認する。審査記録用紙の冒頭に予め記載しておいても不都合は無い。
但し、想定外の重要資産の存在が判明した場合は、その重要度を図って適切に組み替える。特に部門に固有の資産の場合は(他所で聞けないから)、優先してチェックする。この臨機応変な対応が大切。
10個程度*
10個には根拠は無い。あまり多いと現場とのやり取りからより正しい姿を引き出すことが難しくなる。会話が大事。少ないと網羅性が確保しづらくなる。10個は事前準備の量的な目安。現場対応が真の姿。
プロセスベース審査
管理策の当て方:
・主プレイヤー(主)はルールを作る。機能別管理をする。
・客プレイヤー(客)はルールを受け入れて実施する。
A.5:(主)経営者、事務局。(客)一般従業員。取引先。
A.6:(主)経営者、事務局。(客)部門の長。
A.7:(主)事務局。(客)一般従業員。一般部門。
A.8:(主)事務局、人事・教育部門。(客)一般部門。一般従業員。
A.9:(主)事務局。総務部門。情報部門。(客)情報部門。一般部門。
A.10:(主)情報部門。(客)情報部門。一部一般部門もあり得るがこの管理策では見ない。
A.11:(主)事務局。情報部門。一般部門。(客)情報部門。一般部門。一般従業員。
A.12:(主)情報部門。(客)情報部門。
A.13:(主)事務局。(客)情報部門。一般部門。
A.14:(主)事務局。(客)事務局。情報部門。一般部門。
A.15:(主)事務局。法務部門。(客)一般従業員。一般部門。情報部門。
部門へ行って(あるいは来て貰って)、業務概要・適用範囲・重要資産を最初に聞くときに、上記のどの管理策のチェックが重要か判断する。情報部門以外でも情報処理設備を有するときは情報部門に準じたチェックを行う。
その部門に固有の内容を優先してチェック。赤色にした部門。
質問は、直接(いきなり)規格から引き出さないで、規格要求を踏まえたルールの存在から確認する。有れば、それに沿ったチェック。無ければ無くても構わない理由、あるいはそれに関連するリスクアセスメント状況を確認する。結果が妥当ならパス(OK)。ルール上あるいは実施上の問題を認識・合意できれば指摘事項・観察事項としてあげる。
確認する手順としては、管理策に入る前に、これまでの審査・監査での指摘事項の有無、改善状況の確認を行う。改善プロセス(PDCA)が回っているかどうかの確認で最も重要な作業の1つ。
会議室テーブル上での文書と口頭説明による確認と現場の実態・状況の確認は、時間的には半々とする。UKASは現場に出ることを多くするよう指導しているから、会議室は4割程度が望ましい。ただ、その場合の問題が審査記録(メモ・エビデンス)の存在。これの充実を強要すると自然と現場に出づらくなる。審査機関によっては形式化したエビデンスの意味を見直している。
1部門90分とした場合、30分以内に全容確認・文書ベース確認、30分は現場で状況・実態確認。残り30分は全体のまとめ・記録の整理に当てる。必要なら現場チェックの補充を行う。
・主プレイヤー(主)はルールを作る。機能別管理をする。
・客プレイヤー(客)はルールを受け入れて実施する。
A.5:(主)経営者、事務局。(客)一般従業員。取引先。
A.6:(主)経営者、事務局。(客)部門の長。
A.7:(主)事務局。(客)一般従業員。一般部門。
A.8:(主)事務局、人事・教育部門。(客)一般部門。一般従業員。
A.9:(主)事務局。総務部門。情報部門。(客)情報部門。一般部門。
A.10:(主)情報部門。(客)情報部門。一部一般部門もあり得るがこの管理策では見ない。
A.11:(主)事務局。情報部門。一般部門。(客)情報部門。一般部門。一般従業員。
A.12:(主)情報部門。(客)情報部門。
A.13:(主)事務局。(客)情報部門。一般部門。
A.14:(主)事務局。(客)事務局。情報部門。一般部門。
A.15:(主)事務局。法務部門。(客)一般従業員。一般部門。情報部門。
部門へ行って(あるいは来て貰って)、業務概要・適用範囲・重要資産を最初に聞くときに、上記のどの管理策のチェックが重要か判断する。情報部門以外でも情報処理設備を有するときは情報部門に準じたチェックを行う。
その部門に固有の内容を優先してチェック。赤色にした部門。
質問は、直接(いきなり)規格から引き出さないで、規格要求を踏まえたルールの存在から確認する。有れば、それに沿ったチェック。無ければ無くても構わない理由、あるいはそれに関連するリスクアセスメント状況を確認する。結果が妥当ならパス(OK)。ルール上あるいは実施上の問題を認識・合意できれば指摘事項・観察事項としてあげる。
確認する手順としては、管理策に入る前に、これまでの審査・監査での指摘事項の有無、改善状況の確認を行う。改善プロセス(PDCA)が回っているかどうかの確認で最も重要な作業の1つ。
会議室テーブル上での文書と口頭説明による確認と現場の実態・状況の確認は、時間的には半々とする。UKASは現場に出ることを多くするよう指導しているから、会議室は4割程度が望ましい。ただ、その場合の問題が審査記録(メモ・エビデンス)の存在。これの充実を強要すると自然と現場に出づらくなる。審査機関によっては形式化したエビデンスの意味を見直している。
1部門90分とした場合、30分以内に全容確認・文書ベース確認、30分は現場で状況・実態確認。残り30分は全体のまとめ・記録の整理に当てる。必要なら現場チェックの補充を行う。
プロセスベース審査
プロセスベース審査の再考。
プロセスは相対的なものですが、今、相手にしている審査対象を1つのプロセスと見て審査することが出来る。プロセスのスーパーセット(上位概念)とサブセット(下位概念)の理解も必要。IDEF0?の発想で捕らえれば全部共通になる。
ISMSの観点でIDEF0を見ると、
先ず情報の流れを捉える。基本プロセスである情報の受け入れ、情報の加工、情報の吐き出し。コントロールするための情報管理体系。支えるメカニズムである情報システム、関連マニュアル、従業員など。
この全体をもう一度、ISMSの視点で包みなおす。機能別マネジメントの1つ、セキュリティの側面で捕らえなおす。実態はISMSも情報管理体系に埋め込まれてしまうが、ある要件に応えているかどうかを見るために、ISMSのフレームに乗せなおす。
ところが、ISMSあるいはセキュリティの定義が実はとても広いものだから、情報セキュリティからセキュリティを外しても実は同じものになるので分かり難い。ただの情報管理と言ってくれた方が分かりやすい。
構築が終わっていれば管理策はコントロールに既に盛り込まれている(筈)。記録を追えば、その部署の管理策の実施状況が確認できる。即ち、管理策をベースに突っ込む必要はない。プロセスベースと言う訳だ。
本当にそれで良いのか?。これは”筈”に支えられた推論でしかない。
その部署の重要情報資産の特性を見抜き、その特性から予見される管理策の有無・実施の状況を確認すべきだ。ある部分は既に管理マニュアルに反映され、実施の記録もあろうが、ある部分では管理されて居ないかもしれない。
穴が見つかれば、リスクアセスメントに戻って、構築プロセスをトレースする。その中で、仕組み上の結果、実施上の欠陥が指摘できる。
プロセスは相対的なものですが、今、相手にしている審査対象を1つのプロセスと見て審査することが出来る。プロセスのスーパーセット(上位概念)とサブセット(下位概念)の理解も必要。IDEF0?の発想で捕らえれば全部共通になる。
ISMSの観点でIDEF0を見ると、
先ず情報の流れを捉える。基本プロセスである情報の受け入れ、情報の加工、情報の吐き出し。コントロールするための情報管理体系。支えるメカニズムである情報システム、関連マニュアル、従業員など。
この全体をもう一度、ISMSの視点で包みなおす。機能別マネジメントの1つ、セキュリティの側面で捕らえなおす。実態はISMSも情報管理体系に埋め込まれてしまうが、ある要件に応えているかどうかを見るために、ISMSのフレームに乗せなおす。
ところが、ISMSあるいはセキュリティの定義が実はとても広いものだから、情報セキュリティからセキュリティを外しても実は同じものになるので分かり難い。ただの情報管理と言ってくれた方が分かりやすい。
- プロセスの構造を理解する。責任者、スーパーセット、サブセット、役割責任あるいは機能概要、重要な情報の入力・出力・推進機構・統制機構(ICOM)。
- 統制機構(コントロール)の概要、及び統制機構が要求する記録・実態の確認。
構築が終わっていれば管理策はコントロールに既に盛り込まれている(筈)。記録を追えば、その部署の管理策の実施状況が確認できる。即ち、管理策をベースに突っ込む必要はない。プロセスベースと言う訳だ。
本当にそれで良いのか?。これは”筈”に支えられた推論でしかない。
その部署の重要情報資産の特性を見抜き、その特性から予見される管理策の有無・実施の状況を確認すべきだ。ある部分は既に管理マニュアルに反映され、実施の記録もあろうが、ある部分では管理されて居ないかもしれない。
穴が見つかれば、リスクアセスメントに戻って、構築プロセスをトレースする。その中で、仕組み上の結果、実施上の欠陥が指摘できる。
基本方針は何故一枚ものか
基本方針は何故一枚ものか不思議に思う。
周知するには何ページもあったら無理でしょうと悪魔がささやいたから。悪魔が誰かは誰でも知っている。だから中途半端な舌足らずの、はっきり言って出来損ないの方針書が出来上がってしまう。周知する工夫と、明確な方針を作ることは全く別問題。言うべきことは5ページになっても構わないでしょう。
どこかの会社のホームページを見てください。A4サイズ1ページだったら、そこの経営者は自分では何も考えていない可能性があります。もちろん、本当に方針として言うべきことがA4サイズ1枚に収まったら、ミラクルだけど否定はしない。普通は無理。6ポイントを使ったって?。意味有るの?。
周知するには何ページもあったら無理でしょうと悪魔がささやいたから。悪魔が誰かは誰でも知っている。だから中途半端な舌足らずの、はっきり言って出来損ないの方針書が出来上がってしまう。周知する工夫と、明確な方針を作ることは全く別問題。言うべきことは5ページになっても構わないでしょう。
どこかの会社のホームページを見てください。A4サイズ1ページだったら、そこの経営者は自分では何も考えていない可能性があります。もちろん、本当に方針として言うべきことがA4サイズ1枚に収まったら、ミラクルだけど否定はしない。普通は無理。6ポイントを使ったって?。意味有るの?。
4.2.1b)
ここは基本方針。
リスクを評価する基準と言うのが出てくる。”CIAのどれか、複数でも構わない”、としているのが普通。それって本当に基準なの。方針として何か意味を成しているだろうか。当社は機密性だけで良いなんて方針に入れる訳ないでしょう。
CIAは資産特性が決める。
方針に入れるべき「基準」とは?
リスクを評価する基準と言うのが出てくる。”CIAのどれか、複数でも構わない”、としているのが普通。それって本当に基準なの。方針として何か意味を成しているだろうか。当社は機密性だけで良いなんて方針に入れる訳ないでしょう。
CIAは資産特性が決める。
方針に入れるべき「基準」とは?
自己矛盾
ISMSの規格を久し振りに手にしたが、毎回思うことは、この規格は自己矛盾していないかと言う事。
ISMSの運用とISMSの監視が別項目になっている。運用には監視も含むので、運用を別立てにされると論理エンジンがエラーを起こしてしまう。ISMSの見直しも同様だ。
運用には狭義の運用と広義の運用と二本立てとでも言うのだろうか。
まあ、大人の判断としては幹の話と側面の話と意識して捕らえれば良かろうと。
ISMSの運用とISMSの監視が別項目になっている。運用には監視も含むので、運用を別立てにされると論理エンジンがエラーを起こしてしまう。ISMSの見直しも同様だ。
運用には狭義の運用と広義の運用と二本立てとでも言うのだろうか。
まあ、大人の判断としては幹の話と側面の話と意識して捕らえれば良かろうと。
「乃至」という言葉遣い
審査とか監査を受けると、希ですが、その所見なり報告の中で、「乃至」という言葉を見かけることがあります。
その報告者の国語力の問題として見ても適切に使われていることは少ない。よく知らないで使っている可能性が高い。A乃至Bは、AまたはBの意味で生活擁護では通っても、正式(契約等)文書では、A地点とB地点の間の連続する領域も含む。即ち、一連の塊の始点と終点を示して塊全体を現している。
審査・監査は、AからBまでつぶさに全部見ていればA乃至Bも妥当性を持ちうるが、基本はサンプリングでチェックするのだから、個別にピンポイントでどの地点の話しかを明示しないといけない。「乃至」などと、アバウトな表現が出てくるチャンスは少ない筈。
所見を見ると個人に依存している。その人の誤解が不適切な監査報告・審査レポートを生成させている。監査人にクレームするのは嫌だから放置してあるが、レポートをレビューする立場のその監査法人・審査機関のレベルが分かることになる。
その報告者の国語力の問題として見ても適切に使われていることは少ない。よく知らないで使っている可能性が高い。A乃至Bは、AまたはBの意味で生活擁護では通っても、正式(契約等)文書では、A地点とB地点の間の連続する領域も含む。即ち、一連の塊の始点と終点を示して塊全体を現している。
審査・監査は、AからBまでつぶさに全部見ていればA乃至Bも妥当性を持ちうるが、基本はサンプリングでチェックするのだから、個別にピンポイントでどの地点の話しかを明示しないといけない。「乃至」などと、アバウトな表現が出てくるチャンスは少ない筈。
所見を見ると個人に依存している。その人の誤解が不適切な監査報告・審査レポートを生成させている。監査人にクレームするのは嫌だから放置してあるが、レポートをレビューする立場のその監査法人・審査機関のレベルが分かることになる。
始末の悪いメディア管理
携帯電話の中にも、デジタルカメラの中にも、携帯音楽の中にも、小さなマイクロSDが忍んでいるし、USBは面白グッズに姿を変えているし、私物のメディアを管理するのは到底無理。
可搬型のHDDもある。光学メディアもある。個人のノートパソコンもある。PDAの類もある。
これのたな卸し表を某社は作って記載させていたが、手間をかけるだけ愚。
会社の持ち物の管理。やっても良いけど、普通のものならほぼ笊(ザル)だね。逆に、某T社がやっていた一切使用禁止は有効かもしれない。ソフト的、ハード的に穴をふさぐやり方。使えるのは特殊な管理下の部屋だけ。
可搬型のHDDもある。光学メディアもある。個人のノートパソコンもある。PDAの類もある。
これのたな卸し表を某社は作って記載させていたが、手間をかけるだけ愚。
会社の持ち物の管理。やっても良いけど、普通のものならほぼ笊(ザル)だね。逆に、某T社がやっていた一切使用禁止は有効かもしれない。ソフト的、ハード的に穴をふさぐやり方。使えるのは特殊な管理下の部屋だけ。
登録:
投稿 (Atom)
過去 30 日間
-
情報の廃棄 リスク管理では捨てることが重要。余計なものを持たない。管理コストを下げる意味でも重要な概念。 情報には全て捨てる基準を設定しておくこと。その情報を手にしたときに捨てる時期が一目瞭然でなければ成らない。 (1)紙の1枚1枚に書く。やりすぎのケースもあるが。 ...
-
規格ごとに定義が変わっていたら困るけど、時代が進めば定義も変わって当然。だから、規格とは別に整理すべきですね。 資産 (sset) 管理策 (control) 指針 情報処理施設(情報処理設備) 情報セキュリティ 情報セキュリティ事象(information security e...
-
リスク評価の基本が案外出来ていない。何故だろう。無理解な審査員、コンサルタントが普通の思考を阻害しているとしか思えない。 情報セキュリティにおけるリスクとは、情報セキュリティを喪失した時に発生する被害額の期待値。 情報が全く入っていないインストール前のパソコンなら、被害額はパソコ...
-
初回の審査でなければ前回審査時に対して変化点の確認を行う。 しかし、適用範囲に変更はありましたか」と聞いても駄目。適用範囲を理解していないから。噛み砕いて、一つ一つ聞いていくしかない。 4.2.1a) 適用範囲の変更の有無を確認する。事業、契約・法規制、ロケーション、資産、組織に...
-
管理策の審査は項目数が多いために工数がかかる。網羅性の確保と工数制約の狭間で扱いが難しい。 審査員A: 網羅性を重視し特別に時間を割りあてて審査する。現場でないと確認できないもののみ現場。 審査員B: 工数重視。現場/部門審査の中で管理策の幾つかを潰す。 A,Bの是非は難しい。初...
-
外出時・出張時の重要情報 「業者先あるいは客先に出かけて、重要な情報(個人情報のかたまりなど)を受けとったらどうするか」という問題。 カバンに入れて注意して会社に戻る。これが普通。しかし、問題は、自宅に直帰する場合や、そのまま出張する場合。 複数のサイトを回る出張もあれば、複数の...
-
帰る時はパソコンを仕舞う。とか? サーバー室のコンソール端末。サーバー室って結構いろいろな人が出入りするし。
-
> 当初は「ISMS認証規格」をベースにした事例スタディは今なお有意義であり、世の中のデジタル化の傾向が急速に拡大する中ではセキュリティセンスは誰にも欠かせないものと認識されるようになった。 ISMS認証審査をやる人は、規格をベースにしても、普通は自分の行為をベースにしないと、馴...
-
セキュリティのことを第1に考える訓練をしてみる。 何らかの事象(事態、状況、事件、事故、現象など)を捉えて、セキュリティ上の問題課題とその対応をクリアにする訓練。 事象を捉える視点、問題を捉える目線は、基本的にはISMS規格をベースにする。事象におけるセキュリティ問題を明らかにす...
過去 1 年間
-
規格ごとに定義が変わっていたら困るけど、時代が進めば定義も変わって当然。だから、規格とは別に整理すべきですね。 資産 (sset) 管理策 (control) 指針 情報処理施設(情報処理設備) 情報セキュリティ 情報セキュリティ事象(information security e...
-
管理策の審査は項目数が多いために工数がかかる。網羅性の確保と工数制約の狭間で扱いが難しい。 審査員A: 網羅性を重視し特別に時間を割りあてて審査する。現場でないと確認できないもののみ現場。 審査員B: 工数重視。現場/部門審査の中で管理策の幾つかを潰す。 A,Bの是非は難しい。初...
-
帰る時はパソコンを仕舞う。とか? サーバー室のコンソール端末。サーバー室って結構いろいろな人が出入りするし。
-
リスク評価の基本が案外出来ていない。何故だろう。無理解な審査員、コンサルタントが普通の思考を阻害しているとしか思えない。 情報セキュリティにおけるリスクとは、情報セキュリティを喪失した時に発生する被害額の期待値。 情報が全く入っていないインストール前のパソコンなら、被害額はパソコ...
-
> 当初は「ISMS認証規格」をベースにした事例スタディは今なお有意義であり、世の中のデジタル化の傾向が急速に拡大する中ではセキュリティセンスは誰にも欠かせないものと認識されるようになった。 ISMS認証審査をやる人は、規格をベースにしても、普通は自分の行為をベースにしないと、馴...
-
初回の審査でなければ前回審査時に対して変化点の確認を行う。 しかし、適用範囲に変更はありましたか」と聞いても駄目。適用範囲を理解していないから。噛み砕いて、一つ一つ聞いていくしかない。 4.2.1a) 適用範囲の変更の有無を確認する。事業、契約・法規制、ロケーション、資産、組織に...
-
外出時・出張時の重要情報 「業者先あるいは客先に出かけて、重要な情報(個人情報のかたまりなど)を受けとったらどうするか」という問題。 カバンに入れて注意して会社に戻る。これが普通。しかし、問題は、自宅に直帰する場合や、そのまま出張する場合。 複数のサイトを回る出張もあれば、複数の...
-
情報の廃棄 リスク管理では捨てることが重要。余計なものを持たない。管理コストを下げる意味でも重要な概念。 情報には全て捨てる基準を設定しておくこと。その情報を手にしたときに捨てる時期が一目瞭然でなければ成らない。 (1)紙の1枚1枚に書く。やりすぎのケースもあるが。 ...
-
「管理策」 暗号利用の方針を決めろ。と。 「解説」 これ単に方針を決めればいいのかな。方針自体の妥当性・合理性・必然性なども必要ですか。”我が方では暗号は使いません”って宣言するだけでもいいの? 一方で、使う気も無いのに(方針に関係なく)、外部サービスとか、購入したツールが使っ...
-
不在伝達ノート、離席メッセージ帳、営業回覧ノート、セールスメッセージノート、など名前はいろいろ。 目的は、不在者へのメモによる伝達の危うさを回避しようとするもの。伝言メモをノートに書いておく。確実な伝達が可能。机の上に置いたメモは人が歩いた風でもどこかへ行くかも知れない。でも...
人気の投稿
-
規格ごとに定義が変わっていたら困るけど、時代が進めば定義も変わって当然。だから、規格とは別に整理すべきですね。 資産 (sset) 管理策 (control) 指針 情報処理施設(情報処理設備) 情報セキュリティ 情報セキュリティ事象(information security e...
-
外出時・出張時の重要情報 「業者先あるいは客先に出かけて、重要な情報(個人情報のかたまりなど)を受けとったらどうするか」という問題。 カバンに入れて注意して会社に戻る。これが普通。しかし、問題は、自宅に直帰する場合や、そのまま出張する場合。 複数のサイトを回る出張もあれば、複数の...
-
情報の廃棄 リスク管理では捨てることが重要。余計なものを持たない。管理コストを下げる意味でも重要な概念。 情報には全て捨てる基準を設定しておくこと。その情報を手にしたときに捨てる時期が一目瞭然でなければ成らない。 (1)紙の1枚1枚に書く。やりすぎのケースもあるが。 ...
-
管理策の審査は項目数が多いために工数がかかる。網羅性の確保と工数制約の狭間で扱いが難しい。 審査員A: 網羅性を重視し特別に時間を割りあてて審査する。現場でないと確認できないもののみ現場。 審査員B: 工数重視。現場/部門審査の中で管理策の幾つかを潰す。 A,Bの是非は難しい。初...
-
> 当初は「ISMS認証規格」をベースにした事例スタディは今なお有意義であり、世の中のデジタル化の傾向が急速に拡大する中ではセキュリティセンスは誰にも欠かせないものと認識されるようになった。 ISMS認証審査をやる人は、規格をベースにしても、普通は自分の行為をベースにしないと、馴...
-
リスク評価の基本が案外出来ていない。何故だろう。無理解な審査員、コンサルタントが普通の思考を阻害しているとしか思えない。 情報セキュリティにおけるリスクとは、情報セキュリティを喪失した時に発生する被害額の期待値。 情報が全く入っていないインストール前のパソコンなら、被害額はパソコ...
-
帰る時はパソコンを仕舞う。とか? サーバー室のコンソール端末。サーバー室って結構いろいろな人が出入りするし。
-
初回の審査でなければ前回審査時に対して変化点の確認を行う。 しかし、適用範囲に変更はありましたか」と聞いても駄目。適用範囲を理解していないから。噛み砕いて、一つ一つ聞いていくしかない。 4.2.1a) 適用範囲の変更の有無を確認する。事業、契約・法規制、ロケーション、資産、組織に...
-
「目的」 法律違反回避でしょっ?
-
セキュリティ要求事項:これは大事なキーワード。ただ一般的過ぎて単に要件と言うのと変わらなくなるが。 情報セキュリティを始めるには情報セキュリティ要求事項の識別から始めることになる。 情報セキュリティ要求事項の識別方法: 1. 組織のリスクアセスメント。ニュアンス的には組織自体が持...