リスクアセスメントの合理性

資産の重要性評価ロジックは素直に、C,I,A個々の評価であるにも拘らず妙なことをする組織が後を絶たない。資産を３色のフィルターで見る癖が人間にはないから無理も無いが、ISMSをやる以上は分けて見る目を持たないといけない。

• 審査員A：重要視する要素（CIAのいずれか一つ）だけで評価しても構わない。
• 審査員B：CIAを完全に独立して評価すること。
• 審査員C：上のどちらでも構わないし、C*I*Aでも、C*C*I*Aでも、C+I+Aでも構わない。要は組織が納得して決めている方法なら問わない。
  

規格が求めている独立した評価はCIAを認識すれば十分とする考え方が基本ですが、方針・受容基準・受容レベル等から評価ロジックに論理性が認められないケースが審査を受けるときに問題になります。これは本当はロジックの問題ではなくて工数の問題なのです。最初から厳密にやると工数がかかりすぎるし、現場の状況とのギャップが大きい過ぎる。

当初は工数のかからない方法をとり、善事改善のアプローチを取るのが普通の感覚。

チェックリスト

審査員A:

• 審査員が手にしているチェックリストを見せてもらった。何のことは無い、規格を写して、メモ欄を作っただけだ。

審査員B:

• チェックリストは白紙の紙。それにせっせと番号を書いていた。

3.1 残留リスク

残留リスクの理解が今一正しく浸透していない。「残留リスクなし」の記載があるが、それは「資産なし」と同義ですよ。

受容水準を上回るリスクが問題になりリスク対応の対象になるので、これをクリアしたら「残留リスクなし」と報告したいものですが、残留リスクはリスク対応をしても尚残るリスクのことです。リスク受容水準を少し変えると又顔を出すものですね。

※

受容基準・受容レベル、リスク評価、リスク対応、リスク低減のサイクリックな流れは、大手企業でもしんどい。中小企業は無理。無理でないようにするには、規格適用（審査）の考え方も幅を持たないと無理。

※

残留リスクが正しく報告されると、

• 受容水準の設定の妥当性を検証でき、有効な見直しが可能になる。
• 領域別（機能、部門、資産分類等）の特性が把握でき、次の手が打てる。
  

審査比較：管理策

管理策の審査は項目数が多いために工数がかかる。網羅性の確保と工数制約の狭間で扱いが難しい。

審査員A:

• 網羅性を重視し特別に時間を割りあてて審査する。現場でないと確認できないもののみ現場。

審査員B：

• 工数重視。現場/部門審査の中で管理策の幾つかを潰す。

A,Bの是非は難しい。初回は工数よりは網羅性を確保してもらいたい。

審査比較：経営者インタビュー

経営者インタビューが審査の１項目に入るが、取って付けたような時間で馴染めない。

審査員A：

• 規格「5　経営陣の責任」の項目を、約１ページの内容を忠実に聞いてくる。事前にここを聞くと言っているから構わないけど、型どおりでつまらないし、事務局に聞いてよ言いたい。
• チェックリストは特に用意しない。規格書のみ。

審査員B：

• 規格5項は事務局に聞く内容だから特に前提としない。経営者には目的・狙い・成果への評価・審査員への期待・今後の取り組み・そのたホットな状況を踏まえたもの。
• チェックリストは都度特性に配慮して準備。共通する事項も当然ある。

管理策を暗記する

管理策は一応１３３個あるらしい。
カテゴリーはA5からA15まで１１個ある。
管理目的は３９個かな。
１３３個を覚えると言うのは全部ひっくるめて１８３個覚えることになる。
無目的では大変だがボケ防止にはなるかと。

えぃ！や～っと！

5	基本方針
5.1	基本方針
5.1.1	方針書
5.1.2	レビュー
6	組織
6.1	内部組織
6.1.1	経営陣の役割責任
6.1.2	調整
6.1.3	役割責任
6.1.4	施設に対する認可
6.1.5	機密保持契約
6.1.6	関係当局との連絡
6.1.7	専門組織との連絡
6.1.8	独立したレビュー
6.2	外部組織
6.2.1	外部組織に関連したリスク
6.2.2	顧客対応時のセキュリティ
6.2.3	第３者契約時の背きゅうり亭
7	資産
7.1	責任
7.1.1	目録
7.1.2	資産の保有者
7.1.3	資産利用の許可
7.2	分類
7.2.1	分類の指針
7.2.2	ラベル付けと取り扱い
8	人的セキュリティ
8.1	雇用前
8.1.1	役割責任
8.1.2	選考
8.1.3	雇用条件
8.2	雇用中
8.2.1	経営者の責任
8.2.2	意識向上･教育訓練
8.2.3	懲戒手続き
8.3	雇用の終了
8.3.1	雇用終了の責任
8.3.2	資産の返却
8.3.3	アクセス嫌の削除
9	物理的環境的セキュリティ
9.1	領域に対するセキュリティ
9.1.1	セキュリティ境界
9.1.2	入退管理
9.1.3	オフィス・室･施設のセキュリティ
9.1.4	外部･環境からの脅威への保護
9.1.5	セキュリティエリアでの作業
9.1.6	一般立ち入り・受け渡し
9.2	装置に対するセキュリティ
9.2.1	設置
9.2.2	支援ユーティリティ
9.2.3	ケーブル
9.2.4	保守
9.2.5	構外に設置された装置
9.2.6	廃棄・再利用
9.2.7	移動
10	通信及び運用
10.1	運用手順と責任
10.1.1	操作手順
10.1.2	変更管理
10.1.3	職務の分離
10.1.4	環境の分離
10.2	第三者サービス
10.2.1	サービス契約
10.2.2	レビュー
10.2.3	第三者サービスの変更管理
10.3	システムの計画と受け入れ
10.3.1	容量･能力の管理
10.3.2	システムの受け入れ
10.4	悪意の在るコード・モバイルコード管理
10.4.1	悪意の在るコードの管理
10.4.2	モバイルコードの管理
10.5	バックアップ
10.5.1	バックアップ
10.6	ネットワークのセキュリティ
10.6.1	ネットワークのセキュリティ
10.6.2	ネットワークサービスのセキュリティ
10.7	媒体の管理
10.7.1	方針
10.7.2	媒体の処分・再利用
10.7.3	情報の取り扱い
10.7.4	システム文書の取り扱い
10.8	情報の交換
10.8.1	方針
10.8.2	合意
10.8.3	配送中媒体の管理
10.8.4	電子的メッセージの管理
10.8.5	業務システムの管理
10.9	電子商取引の管理
10.9.1	電子商取引
10.9.2	オンライン取引
10.9.3	公開情報
10.10	監視
10.10.1	監査の記録
10.10.2	システムの状況
10.10.3	記録の保護
10.10.4	作業の記録
10.10.5	障害の記録
10.10.6	クロックの整合
11	アクセス制御
11.1	アクセス制御ポリシー
11.1.1	アクセス制御ポリシー
11.2	アクセス権の管理
11.2.1	利用者登録
11.2.2	特権者の管理
11.2.3	パスワードの管理
11.2.4	アクセス権のレビュー
11.3	利用者の責任
11.3.1	パスワードの利用
11.3.2	無人状態装置の管理
11.3.3	クリアデスク・クリアスクリーン
11.4	ネットワークアクセス制御
11.4.1	方針
11.4.2	外部アクセスへの認証
11.4.3	装置の識別
11.4.4	遠隔診断ポート
11.4.5	領域の管理
11.4.6	接続制御
11.4.7	経路制御
11.5	OSアクセス制御
11.5.1	ログオン手順
11.5.2	利用者識別と認証
11.5.3	パスワード管理システム
11.5.4	システムユーティリティの使用
11.5.5	タイムアウト
11.5.6	接続時間
11.6	業務ソフトアクセス制御
11.6.1	情報へのアクセス制御
11.6.2	システムの隔離
11.7	モバイル・テレワーク対応
11.7.1	モバコン対応
11.7.2	テレワーク対応
12	システムの取得開発保守
12.1	セキュリティ要求事項
12.1.1	セキュリティ要求事項
12.2	正確な処理
12.2.1	インプット
12.2.2	内部処理
12.2.3	メッセージの完全性
12.2.4	アウトプット
12.3	暗号による管理
12.3.1	利用方針
12.3.2	かぎ管理
12.4	システムファイルのセキュリティ
12.4.1	運用ソフトウエアの管理（変更管理）
12.4.2	試験データ管理
12.4.3	ソースプログラムの管理
12.5	開発及び支援プロセスのセキュリティ
12.5.1	変更管理
12.5.2	OS変更時管理
12.5.3	パッケージの変更管理
12.5.4	情報漏えい（隠れチャネル等）
12.5.5	外部委託
12.6	技術的脆弱性管理
12.6.1	技術的脆弱性管理
13	インシデント管理
13.1	情報セキュリティ事象と弱点の報告
13.1.1	事象の報告
13.1.2	弱点の報告
13.2	インシデント管理
13.2.1	責任及び手順
13.2.2	学習
13.2.3	証拠の収集
14	事業継続管理
14.1	事業継続管理におけるセキュリティの側面
14.1.1	組み込み
14.1.2	リスクアセスメント
14.1.3	計画策定と実施
14.1.4	枠組みの維持
14.15	訓練・再評価
15	順守（コンプライアンス)
15.1	法的要求事項
15.1.1	識別
15.1.2	知的財産権取り扱い手順
15.1.3	記録の保護
15.1.4	個人情報取り扱い手順
15.1.5	情報処理施設誤用防止
15.1.6	暗号規制への対応
15.2	セキュリティ方針・標準・技術的順守
15.2.1	セキュリティ方針・標準順守
15.2.2	技術的順守
15.3	監査対応
15.3.1	監査対応
15.3.2	監査ツール

A.05.1.2 情報セキュリティ基本方針のレビュー

A.05.1 情報セキュリティ基本方針

A.11.3.3 クリアデスク･クリアスクリーン方針

A.11.3.2 無人状態にある利用者装置

帰る時はパソコンを仕舞う。とか？

サーバー室のコンソール端末。サーバー室って結構いろいろな人が出入りするし。

A.11.3.1 パスワードの利用

A.11.3 利用者の責任

「目的」

• 許可されていないアクセス
• システム損傷
• 盗難

「解説」

• 前提に、明確な取り決め、周知の教育･訓練もあるはずだ。
  

A.11.2.4 利用者アクセス権のレビュー

岡本さん、ここ違っていたな。アクセスポリシーには固有名詞はいらない。役職名は入っていて良いが。

ポリシーのレビューと、実際のユーザー登録者のレビューと別になっている。後者（当項目）は具体的な人名入りのもの。

A.11.2.3 利用者パスワードの管理

パスワードの割り当ては、正式なプロセスによること。

この頃はシステムに組み込みだけど何か。ではそのツールが承認されたものであることだね。

A.11.2.2 特権管理

特権は制約すること。

でも、これ、一人にしてしまうと別問題が出るんで、何か考え方を用意しておきたいね。

A.11.2.1 利用者登録

「管理策」

• アクセスの正しい許可・禁止のための、登録及び登録削除の正式な手順を備える。

「解説」

• 全ての情報システム、及びサービスに対して、手続きを持っていること。
  

A.11.1 アクセス制御に対する業務上の要求事項

「目的」

• 情報のアクセスを制御する。

「解説」

• ってタイトルのままだな。
  

A.11.2 利用者アクセス管理

「目的」

• 認可者へのアクセスの確実化、非認可者のアクセスの禁止

「解説」

• 
  

A.11.1.1 アクセス制御方針

「管理策」

• 業務要求、セキュリティ要求に基づいて方針を確立、文書化、レビューせよと。

「解説」

• ってことは文書化要求だ。文書化された方針が存在する。
• 方針の策定プロセスには触れていないが、レビューについてはエビデンス要求が出るかもしれない。
• 見直し規定も必要だろう。

A.12.6.1 技術的脆弱性の管理

「管理策」

• 技術的な脆弱性に関する情報収集を速やかに行う。
• リスク評価すること。
• 適切な手段を講じること。

「解説」

• 関連する手順。MSとの契約。役割設定。など。
• パッチがMSから出ているのに長い間放置していたのが理由でウイルスまたはハッカーに襲われた事例はある。
  

A.12.5.5 外部委託によるソフトウエア開発

「管理策」

• 外部委託開発の監督監視をやれ。と。

「解説」

• 結構難しい。普通は定期的な報告で済ます。開発現場への立ち入りとかは嫌がることが多い。
• それで、発注側はスペースを用意してそこで開発をやってもらうケースが多い。これだと一応監督監視できる。
• 手間を掛けないのがアウトソースなのに監督監視で手間を掛けるのは現場は嫌がる。

「審査」

• 委託開発契約書。監督監視に関する事項。必要時の監査権などは重要。
• 契約前提の情報セキュリティ要求事項も。これはA.6.2.3に関連するかな。

A.12.5.4 情報の漏洩

「管理策」

• 情報漏えいを抑止しろと。

「解説」

• 普通だな。ここだけ特別な管理策があるかな。開発仕様もデータを含めなければ特別に重要ではない。ただ、競合会社に渡るのは好ましくは無いが。まあ、普通のことをここにも摘要するくらいでしょう。
  

A.12.5.3 パッケージソフトウエアの変更に対する制限

「管理策」

• 変更は抑止し必要なものに限ること。

「解説」

• どこでも必要最小限を想定して変更するが失敗は繰り返される。
• 変更が多い場合は最初からオープンシステムですって？。金は掛かるし、リスクは軽減されないよ。
• 承認プロセスで上位者を入れるようにするくらい。結構、効果あり。
• 「主客転倒」。本来はプロセスにあわせてツールを用意するが、それをやりすぎると余計な変更を始める。ベストツールを決めたら、今度はツールにプロセスを合わせるのが健全なチェンジコントロール。結果的にベストプラクティスの導入を図れる。筈。

「審査」

• 方針または手順の有無。
• 最近のパッケージ導入時の変更実績と方針・手順との整合。

A.12.5.2 オペレーティングシステム変更後の業務用ソフトウエアの技術的レビュー

「管理策」

• OS変更時は、運用・セキュリティに悪影響が無いようにレビューし試験しろと。

「解説」

• いちゃもんじゃないけどタイトルだと”変更後のレビュー”では手遅れ。翻訳ミスでしょう。
• これも変更管理A.12.5.1の一環ですね。
• 影響が大きいので特に取り上げていると考えましょう。

A.12.5.1 変更管理手順

「管理策」

• 変更は正式な変更管理手順に従うこと。と。

「解説」

• 情報セキュリティ以前の問題。品質トラブルは殆どがここです。
• ただ、手順があれば防げる訳でもないのが本当の問題かな。
• ”変更管理”としてはA.10.1.2でも出てくるが、そちらは運用の変更です。例として分かり易いのはサービス時間の変更など。
  

A.12.4.3 プログラムソースコードへのアクセス制御

「管理策」

• アクセスを制限しろ。と。

「解説」

• 誰でも触れるようでは話にならない。厳密にやるなら変更管理ツールを入れるのね。
• 決め事を明確にする。手順に落とす。運用する。監視する。レビューする。といつものパターン。
  

A.12.4.2 システム試験データの保護

「管理策」

• 試験データを管理しなさいと。

「解説」

• 情報漏えい事件が発生する可能性の大きいところです。サンプリング、マスキング、速やかな削除、アクセス管理など。
• 開発者からすると後ろ向きに見えるので手を抜くのもこの辺です。加えて試験作業はよく外注する部分でもあります。それがまた事故に繋がっています。
  

「審査」

• 取り扱いルール、手順書の存在。
• サンプリングとかマスキングの基準に対して実際の試験データを見て一致度を見る。現場でやると手間が掛かるのでケースバイケース。
  

A.12.4.1 運用ソフトの管理

「管理策」

• 管理手順を備えろ。と。

「解説」

• 何も無いことは大きな組織では少ない。
• 小さい場合（大会社でも部門システムの場合）は個人の担当者に任せっぱなしで手順が明確になっていない。
• 変更が頻繁い行われる場合。何が相当するかな？テスト環境用システム？
• 担当者の異動・緊急事態に対応できなくなる。納得しない向きには引継ぎ書と理解してもらえば納得してもらえる。
  

A.12.3.2 かぎ管理

「管理策」

• かぎ管理をやれ。と。暗号技術利用支援のため。

「解説」

• 公開鍵と秘密鍵と。誰にどの鍵をわたしたか、再発行はどうするか、有効期限はどうするか、などでしょうか。利用するには決めなければいけないことがいろいろありそうです。

• 奥が深いから、組織のニーズに合わせて仕組みを作ってもらうしかない。

A.12.3.1 暗号による管理策の利用方針

「管理策」

暗号利用の方針を決めろ。と。

「解説」

これ単に方針を決めればいいのかな。方針自体の妥当性・合理性・必然性なども必要ですか。”我が方では暗号は使いません”って宣言するだけでもいいの？　

一方で、使う気も無いのに（方針に関係なく）、外部サービスとか、購入したツールが使っているケースもある。

今時は、外部への添付メールは暗号化（アタッシェ等のフリーソフトもあるし)しておくのはマナーに近い。

「審査」

• 方針の内容
• 現場での摘要（運用）状況

A.12.2.4 出力データの妥当性確認

「解説」

承認プロセスがあれば妥当性確認をやっていることになるね。

A.12.2.3 メッセージの完全性

「解説」

これって管理策？　適切な管理策を実装しなさいとあるから「目的」みたいだね。

署名の話はここじゃないはずだが。ここだったかな？

A.12.2.2 内部処理の管理

「管理」

内部処理のミス、故意（悪意？）による情報の破壊から防止する。妥当性確認の機能をソフトウエアに組み込む。

「解説」

実際はどうやるのかな。事前にテストはする訳だし、リリース後もアクセス権で押えているのだから、監視ソフトのようなものを入れるのか。アウトプットデータの合理性はA.1.2.2.4でやるからねまあ、このアクセス権違反の監視ソフトくらいが相当するか。

A.12.2.1 入力データの妥当性確認

「管理策」

「解説」

実際は難しいね。昔（今でも？）は合理性チェックのルーチンを入れていたかな。でも、間違え・勘違いだと入ってしまう。

株式の売買でも以前大きなミスがあって銀行、東証、富士通？の間で係争があった。間違いに気づいたら訂正できるのは当然ですね。東証のシステムはそれもできなかった。

A.12.1.1 セキュリティ要求事項の分析および仕様化

「管理策」

システムの新規開発、既存システムの改善（＝変更）にあたっては、セキュリティ要求事項を明確にして仕様化する。

「解説」

方法論には立ち入らない。結果としてらしきものの記載が仕様にあれば良い。ここの管理策は1個だけ？　将来的にはもっと立ち入るのか、要求事項は散々言っているから、たんなる文書化要求で収めるのか。

A.12.6 技術的な脆弱性管理

「目的」

公開された技術的な脆弱性の悪用から生じるリスクの軽減

A.12.5 開発および支援プロセスにおけるセキュリティ

「目的」

• 業務用ソフトウエアシステムのソフトと情報のセキュリティって返って難しいね、表現が。タイトルの方が分かりやすい。

「解説」

• だいたい何処の会社にも開発標準と言うものがある。それは商品開発では必須だから必ず在る。
• 企業内の情報システムの開発標準は、外注一本やりだと無い可能性がある。あってもレビュープロセスを繋ぐだけの貧弱なケース。
• 多いケースは商品開発プロセスのエッセンスを貰って社内システム用に宛てる。

A.12.4 システムファイルのセキュリティ

「目的」
システムファイルのセキュリティ確保

つまらないね。

A.12.3 暗号による管理策

「目的」
情報の機密性、真正性、完全性を保護する。

「解説」
重要な情報は暗号を使え。

A.12.2 業務用ソフトウエアでの正確な処理

「目的」

情報の誤り、消失、認可外の変更、誤用の防止。

A.12.1 情報システムのセキュリティ要求事項

「目的」

セキュリティは情報システム不可欠要素ですか。

A.13.2.3 証拠の収集

「管理策」
インシデント後の法的処置がある場合は、証拠の収集、保全、提出を行う。

「解説」
インシデント毎に何を証拠として収集・保全するのか、予め決めておかないと対応できない。

A.13.2.2 情報セキュリティインシデントからの学習

「管理策」
インシデントの形態、規模・頻度を定量化し監視できる仕組みを整備する。

「解説」
タイトルと管理策の記述と合わないね。分類、体系化、統計化とかをやるのが学習なのかな。

仕組みの整備が学習？　監視の効率を上げるように学習すると言っているのかな？

A.13.2.1 責任及び手順

「管理策」

インシデント対応を迅速、効果的、体系的に行うこと。を]確実にする。

「解説」

インシデント管理手順書、フロー図、体制表、支援システムなどが存在する。何処の組織でも。

3.5 情報セキュリティ事象

information security event

システム、ネットワーク、サービスに生じた特定の状態の発生。

方針への違反。管理策の不具合。セキュリティに関連するかもしれない未知の状況。

「解説」

なんて書いてあっても分からないね。

と言うのはセキュリティ事象の報告(A.13.1.2)とセキュリティの弱点の報告(A.13.1.2)が別にに記載されているからです。つまり、この２つは何処で線引きするのかですね。

ここでは、以下のように理解しておきます。

• 事象は所謂ファインディング（Findings）です。認識した事実としての事象。
• 弱点は所謂メッセージ(Messages)です。セキュリティを維持する上での弱点であると評価した情報です。ですから、脆弱性に相当するものになります。現行管理策の不十分さを指すと。

A.13.1.2 セキュリティの弱点の報告

「管理策」

「解説」

ちょっと、事象と弱点ってどう違うの？

• 事象は評価未然の発見･認識した上手く行っていない事柄。事象は単なる（やばそうな）ファインディング。原因とか対策とかに留意しない報告。
• 弱点は事象の要因となった弱点、または事象は発生していないが発見された弱点。弱点は脅威と脆弱性の観点で捉えるほうが分かりよい。原因、対策への考慮がある。

こんなところでどうでしょう。

A.13.1.1 情報セキュリティ事象の報告

「管理策」

速やかな報告。

「解説」

事象の定義が必要。
連絡ルート（誰が誰にどのように）

「審査」

規格の条文だけで判決を出すのは議論を呼んで良くない。一番いいのは組織が規格をこのように解釈しましたと示す組織自身の規定への違反を言うこと。もっと、規定を改悪されては元も子もないで、誘導はしっかりと。

A.13.2 情報セキュリティインシデントの管理及びその改善

「目的」

一貫性のある効果的な取り組みを実現するため。

「解説」

インシデント管理の実施と改善。

A.13.1 情報セキュリティの事象及び弱点の報告

「目的」

時期を逸しない是正処置を行うための、情報セキュリティ事象及び弱点の連絡を確実にする。

「解説」

やばそうなことは早め早めに連絡するのだ。これはBCMとの関連も深い。気付きの感性ですね。

A.14.1.4 事業継続計画策定の枠組み

「管理策」

全ての事業継続計画の整合性、矛盾の回避、優先度の特定のために、一つの枠組みを維持すること。

「解説」

その枠組みとは何を指すのか？　

計画書の構成を共通にすることと理解している人もいるが、それは本質的なことではない。間違い。

正しくは、全体を一つの体系（＝枠組み）に収めること。目的毎に個別に独立して策定するとか、部門毎に策定するとかして、全体を束ねる考え方が無いものは不適切と言うことです。

27001から組織全体のBCMの枠組みに収めることを要求していますから、体系的な管理の要求は強まったと思われます。

「審査」

実際の審査では、本質的な要求を理解しながらも、BCP策定要件が明確かどうかを見るにとどめます。組織の実力がまだ追いついていませんから。

A.14.1.5 事業継続計画の試験、維持及び再評価

最新で効果的な計画であることを確実にするため。

これは分かりやすいね。

実施してレビューしてリプランするのだ。

4.3.1e)

「要求」

文書化要求の一般。

ISMS要求文書の一つに「リスクアセスメント結果報告」を入れる。

「解説」

4.2.3d)

「要求」

ISMSの監視及び見直しの１項。定期的にリスクアセスメントの見直しを行うこと。残留リスクも見直す。受容リスク水準の見直しも行う。

見直しの前提として、１）組織、２）技術、３）事業（目的・プロセス）、４）脅威、５）管理策の有効性、６）外部事象の変化を考慮する。

「解説」

見直す中身は具体的には何か？これが案外難しい。

A.14.1.3 情報セキュリティを組み込んだ事業継続計画の策定及び実施

「管理策」

面白いな。ここの管理策は"事象発生後"の施策を、計画として策定し実施すること。プレで実施する管理策は入らない。

「解説」

･戦略は？

A.14.1.2とA.14.1.3の間にはギャップがある。どの事象に対して計画を用意するのか。戦略的検討があるはず。前の規格にはあったし、25999にもある。まあ、しかし、どちらかに入っていれば済むことだが。

・事前の管理策は？

転ばぬ先の知恵、予防保全については、何処に入れるのか。通常、組織は事前対策に目を奪われがち。その場合は通常の管理策に入れれば済むはずだ。”事後の管理策”がこぼれるケースが多い。

A.14.1.2 事業継続及びリスクアセスメント

「管理策」

リスク事象を特定する。

事象、事象による業務中断の発生確率、業務中断の影響、影響の一部として情報セキュリティへの影響も明確にする。

A.14.1.1 事業継続管理手続きへの情報セキュリティの組込み

「管理策」

少し手順が広がったかな。

• 組織全体の事業継続のために
• 情報セキュリティへの要求事項を明らかにし
• 実施のための手続き策定し
• 維持する。

「解説」

• 25999BCMSを読んだりすると返って混乱しそうです。
• 組織全体の事業継続って、ここで言う組織は「適用範囲の組織」？。またはそれを包含する「経営全体の組織」？。どちらでしょう？。愚問かな。どちらにしても適用範囲に戻すことになって同じことですから。現実的な解を求めるなら、「適用範囲の組織」を考慮すれば十分でしょう。
• 
  

「審査」

• ここでは管理の枠組みの確認ができればよい。
• 枠組みとは全体の中での情報セキュリティの位置づけ。
• 全体のBCM手順。またはA.14.1.2-A.14.1.5をサマリーしたものでも良い。
  

A.14.1 事業継続管理における情報セキュリティの側面

「目的」

情報システムの故障や災害被害から、事業活動が中断することへの対処。

「解説」

規格を読むと返って難しく感じる。情報システムを止めない、止めても事業プロセスに関わる部分は保護する、直ぐに復旧する、のかな。

重要なのは、事業継続管理BCMは、情報システムを含めて全体の管理の枠組みがあるから、その中での位置づけ、整合性は確保しなければならない。

A.15.1.5 情報処理施設の誤用防止

「管理策」

認可外利用の阻止。

「解説」

• 会社が貸与しているパソコンでゲームをやる。
• サーバーに猥褻（わいせつ）なデータを保管する。
• サーバールームを倉庫代わり、休憩室代わりに使う。
  

「審査」

A.15.1.4 個人データ及び個人情報の保護

「管理策」

• 個人情報保護法。

「解説」

• ５０００件あれば保護法の適用を受ける。

「審査」

• リスクアセスメント時にどのように識別しているか。
• 識別されたもの。
• 件数。
• 取り扱いルールの有無、内容。
• ルールに基づく記録。

A.15.1.3 組織の記録の保護

「管理策」

重要な記録は保護する。改ざん、消失、破壊からの保護。

「解説」

法的要求事項が求める保護対象記録が重要な記録。これが先ず明確なこと。記録を残していないと、法的問題に対抗できない。

A.15.2.2 技術的順守点検

「管理策」

情報システムの点検。

「解説」

侵入テスト、脆弱性アセスメント。フリーの診断ツール（利用の是非は残る）を使っての点検も今の時代は可能。

内部監査をやっていればOKにする人がいます。自己矛盾ですね。内部監査の内容として何をやっているかが問題。

「審査」

情報システム部門（場合により、セキュリティ部門、品質部門、リスク管理部門）の審査時に、技術的点検のエビデンスを求めます。

A.15.2 セキュリティ方針及び標準の順守、ならびに技術的順守

「目的」

A.15.2.1 セキュリティ方針及び標準の順守

「管理策」

「解説」

自分で決めたISMS関連のルールを守るということなら、始めの一歩に戻るみたいな管理策だが、ぴんとこないね。

17799を読むと順守の状況のレビューを求めているようだ。事象・事態に対して、原因の特定、是正処置（再発防止策）の評価、実施、レビューとサイクルを回すこと。

A.10.10での監視に関する管理策との連関で見るらしい。A.15.2.1を個別に取り出す理由が理解できない。

「審査」

この項目だけユニークに取り出す審査は無いでしょう。A.10、A.13の中で押さえるから。

A.15.1.2 知的財産権（ＩＰＲ）

「管理策」

知的財産権があるものを識別する？
権利関係のあるソフトを識別する？

法規制は、契約は？

一番多いのはソフトウエアのライセンス契約の順守のチェック。映像・画像なども対象になるが、それらも結局ライセンス契約を結ぶ。

情報資産台帳で、特性として知的財産、あるいはライセンス契約の有無を記載したほうが良い。しかし、なかなか連動した管理は見当たらない。データベースも中途半端になっている。難しいのだ。

さてと、

ライセンス台帳を示してＯＫにしている人が居る。買った分しかインストールしていなければＯＫだから、インストール数を確認する手順を持っていないと駄目なんですが、どういうつもりでしょう。最も、何もやっていないよりはマシだろうね。

4.2.1a) 適用範囲

4.2.1a) 適用範囲

適用範囲を少なくとも５つの観点から情報セキュリティとの関連で特徴を明らかにすること；

①事業、②組織、③ロケーション、④資産、⑤技術

①顧客やパートナー企業との関連、ビジネスプロセス、商品・サービスの観点から、ＩＳＭＳの適用範囲を定義すること。

②組織体制、役割分担、関連部門とのIF

③地理的・地域的（洪水低地/構想ビル/飲食街/ギャンブル場）、敷地的（門/塀/カメラ/守衛/電磁波漏洩）、建物構造（耐火/耐震/雑居ビル）、階層断面図（昇降機/階段/非常階段）、フロア構造（ドア/窓/業務GRパーティション）。重要な情報資産の配置（サーバー/PC/PBX/アンテナ類/シュレッダー/プリンター/コピー/FAX/廃棄物処理場）。

④どうも情報資産だけで話を済ませることが多い。事業上の資産は事業の特徴で述べる。

⑤技術の記載は難しい。イメージが湧かないから。情報セキュリティに関連する重要な技術要素となると、ネットワーク関連、暗号化関連、認証関連かな。ネットワーク情報資産でもあるからその辺の整理は必要か。研究開発に関連する技術はやはり事業上の特徴、または情報資産の特徴として記述した方が分かり易い。

※ 所謂「適用範囲」。此れは思った以上に重要。プロジェクトで言えばスコープに相当するところ。最初のボタンで何度も試行錯誤して収まるのが実態ではなかろうか。

A.15.1.1 摘要法令の識別

「管理策」

順守しなければならない法令を洗うといって、全ての法律は守らなければいけないから、ここでは何を識別するかというと、事業特性・業務特性から判断して特に注意を払うべき法令として何を認識しているかということになる。

法律は運用されるものであるため、定期的に見直しておかないと罠に嵌ることになる。（罠というのは強豪だったり、官憲だったり、犯罪者）

その法律の内容を全部を問題にすることも無くて、その中で情報セキュリティ要求事項は何かということになる。

その上で、順守のための取り組み方法を文書化しておく。

ということはこれは文書化要求だ。

A.15.1 法的要求事項の順守

「目的」

法律違反回避でしょっ？

A.15 コンプライアンス

A.14 事業継続管理

A.13 セキュリティインシデントの管理

A.12 情報システムの取得、開発及び保守

「解説」

ここは頭出しが結構難。「情報システム」ってどこからどこまでを指すのか。

商品としての「情報システム」は含まない。と言うが、「情報システム」を開発生産する支援情報システムは含むのか。これは業務支援システムなのだが、含まないとやると他の業務支援システムまで含まなくなって変。含むとやると、ヘルプデスク環境、テスト環境は含むことになる。これって商品に近いものだけど、それらは結構手作りですね。

幹の議論はOKだが、枝葉に入ると苦労しそうだ。素直に商品になって外に出て行くもの意外は全て対象にしておくのが、リスク管理上は妥当でしょうね。

A.11 アクセス制御

A.10 通信及び運用管理

A.9 物理的及び環境的セキュリティ

A.8.3 雇用の終了又は変更

「目的」

8.3.1
8.3.2
8.3.3

先ず責任ですか。この責任とは終了プロセスの責任者ですね、多分。

止める人には返してもらう。

アクセス権の削除。施設もネットも。

A.08.2 雇用期間中

「目的」

役割責任を定め、適切な能力、意識を維持することなんでしょうね。

経営者の責任、教育・意識向上、懲戒

これだけで良いのかな？

A.08.1.3 雇用条件

「管理策」

雇用契約書。ISMS遵守について同意、署名。誓約書にしているところが多い。後付だった関係でしょう。社員が守るべきはISMSだけじゃないからね。

派遣の場合は、やはりISMSだけ切り出しての誓約書になるか。

A.08.1.2 選考あるいは採用

「管理策」

ぴんとこない管理策だ。選考或いは採用は法的・倫理的に妥当な手順を踏みなさいとある。

となると関連法令、規則、倫理上の留意点は何かを予め抑えておくのだろうか。

過去に犯罪を犯したかどうか、問題の無い方法で調べなければならない。

これは、組織が直接社員として採用する場合は兎も角、アウトソース（派遣で組織の中に入ってくる場合）などが絡むと、同じレベルを要求するのは難しそうだ。責任逃れするためにも契約書の中には入れておくんだろうね。

A.08.1.1 役割及び責任

「管理策」

ISMS上の役割を文書化しておくことって言って、これは社内規定でいいのかな？

この管理策は手順の管理策だな。まず要件を明確にしておけと言っているだけ。要件は変わるものだから当然見直しの要素も含まれるでしょう。

A.8.1 雇用前

「目的」

ISMSを理解出来る人・実行できる人を入れることで、リスク提言を図る。

内部犯罪７割。トロイの木馬ではないが中に入れてしまったら駄目なんです。ですから、ここは一番重要。

A.8 人的資源のセキュリティ

A.7.2 情報の分類

A.7.1は情報に対する責任、オーナーシップを明確にしなさいと。その狙いは、ここで言う分類を行う責任者を明確にするということ。

分類とは、重要か重要でないか。特定用途か一般用途か。目視あるいは適当な方法で判別できること。

面白いことがあった。重要なものに重要と書くとそれが狙われるから重要と書かない。で、どうするかというとマークをつける。管理番号の頭（末尾でもいい）のコードで識別する。ままごとだね。重要なものにはきっぱりと色も鮮やかに重要と書くのですよ。迂闊に持ち歩けない雰囲気。犯罪は７割が内部ですからね。その人に対するけん制です。何か勘違いしたコンサルかコンサル風の審査員が吹き込んだのでしょう。

もっと酷いケースもある。まったく識別しない。机の上に放置されたCDROMは誰が管理するのか、重要なものかどうか、パソコンで読んでみるまでわからない。識別しない識別と強弁たれて涼しい顔をしている人がいる。面倒なことをやらないための屁理屈。ファイルロッカーの中も同じ。背表紙には何も識別コード/マークは無い。

分類という始めの一歩が実は大変に難しい。ある意味ではISMSの自己矛盾の露呈になっているかも。識別、ラベル付けはやり直しが難しいからね。

A.7.1 資産に対する責任

「目的」
組織の資産の保護って言って、これは情報資産ですか、普通の資産ですか。昔からよく分からないところです。

例の審査機関の人の説明では鼻から情報資産に特定しているけど、あれは間違いですね。事業組織が持つ全ての資産なんです。

7.1.1では全てを識別し
7.1.2から情報資産についての管理策になります。

もっとも、7.1.1で識別されたリストは既に情報資産です。

A.7 資産の管理

A.6.2 外部組織

外部の組織に依存する情報セキュリティがある場合、情報セキュリティを確保するために適切な管理或いは働きかけが必要。

ネットワークは大概は外部依存。

アウトソースも含まれるが、開発のアウトソースはこの項目の範疇外。運用時だから、サービスのアウトソースでしょう。

防犯・防災等の関連で、公的機関とのやり取りがある場合は、A.6.1.6「関係当局との連絡」で洗っておく。勘違いしないように。

4.2.1 ISMSの確立

A.6.1.2 情報セキュリティの調整

情報セキュリティ活動を効果的に進めるための調整。

委員会、連絡会、通常の運営会の常設的なテーマ（議題）でも良い。組織の規模、権限委譲の範囲などに応じたものであれば良い。

組織図、役割体制表、議事録などを確認。定期開催であれば日程表（年間計画）の中に入っていても良い。

調整の実を見るには、アクション（指示事項）が適切にフォローされているかもポイントになる。

A.6.1.1 情報セキュリティに対する経営者の責任

A.6.1 内部組織

審査の心得：質問の仕方3

プロセスベース審査での質問の要領：

IDEF0を参考にすると分かりよい。

• プロセスの名前*
• プロセスのオーナー*
• プロセスのミッション*
• 組織構造（体制・人数規模・役割編成）*
• プロセス（内部の作業手順。５W1H) **
  
• インプット（何処から何がインプットされるか。５W1H）**
• アウトプット（何処へ何をアウトプットするか。５W1H)**
• 資産**
• 法規制・契約・事業上の要求の有無。*
• インシデント（事件事故ヒヤリハット）、不適合の有無（内部監査・前回審査・内部統制）*

現場担当者からのインタビュー：

• 教育・方針の周知の結果・機密漏えい防止に関する契約あるいは誓約
• 管理資産と保管
• クリアデスク･クリアスクリーン
• アクセス制御（可能または不可能）
• ウイルス対策ソフト
• フリーソフト等のインストール
  

審査の心得：質問の仕方2

審査は審査する方も審査を受ける方も時間との戦い。その時間内に問題が無ければ受審側の勝ち？！。なんてことは無いですが、だって改善の機会を失う訳ですからね。でも、まあ安堵するのも人情です。

質問する側も受け答えする側も的確であること。無駄が無いこと。余計な質問、世間話は無用です。勿論、人間としての円滑なコミュニケーションを確保するための関心を持つことやある程度のリアクションは当然に必要なことです。人柄の部分ですからそれは自然に出るでしょう。ここではそれは無視します。

的確な質問とは：規格の何の確認しているか明確にして質問すること。自然な流れでの質問には熟練を要するものですから、新人の審査員（内部監査員も同じですよ）は、質問の冒頭で復唱してもいいです。例えば、「”4.2.2f)で規格は運用を管理するとしていますが”、運用の管理策にはどのようなものがありますか」。”　"上の句をつける。但しこの例では漠然としているので現場向けでなく、事務局向けですね。

「”A.10.3.1容量・能力の管理と言う管理策がありますが、当部門で管理するシステムの運用では、この観点ではどのように管理していますか？」。もっと踏み込んで「管理基準は？」「計測の実態･記録は？」とやる。

注意：プロセスベース審査はプロセス審査ではない。規格要求引き出すテンプレートとしてプロセスを使うだけ。プロセスもIDEFレベル0を想定すれば、部門(名）が特定された時点でプロセスは既に設定されたようなもの。だから、部門の特性に配慮した確認作業を始めればよい。

事業上・業務上の目的達成との関連で見ないと枝葉末節に目が行ってしまう懸念がありますから、プロセスベースを常に意識することが大事です。

巨大な部門を一つのブロック（レベル０）で処理したら？。それは審査計画に適切性を欠いていることになる。従って、JISかISOの周辺で、どれだけの人数規模に対して何工数が妥当とのガイドは出ているので、審査計画ではそれを参考にすべきだ。

プロセスベース審査2

網羅性を確保するには、管理策の１桁項目（A.x)での網羅性は必須。２桁項目(A.x.x)についても３年スパンでは網羅していることが望ましい。ただ、２桁までの管理（数年度にまたがる管理）は適切な管理システムがないと難しい。

プロセスベース審査

現場の業務プロセスに沿って行う審査。

プロセスベースに対してどんな審査があるかと言うと規格ベースがある。要求規格だから要求をクリアしているかどうかを規格に沿って確認していく方法。

規格ベースは鼻から規格の順番でやるので、事務局を相手にするシステム構築の部分は自然な流れで審査が出来るが、管理策からは現場の審査になるためある意味ではぶつ切り審査になる傾向がある。

規格ベースで管理策の審査をやった後も、やはり現場に入って運用の実態を確認することになる。現場運用のルールと実態の２段階審査になっていてそれなりの合理性はある。

規格と言うテンプレートの上で実態（プロセス)を眺めるのが規格ベース審査。それに対してプロセスをテンプレートにして規格（要求対応）を見るのがプロセスベース審査。但し、プロセスベースでも網羅性の観点は外せないから、根っこにあるのは当然だが規格になる。

プロセスベースが必要な理由は、複数規格の審査を同時行うには規格ベースでは成立しないと言う基本的な問題があるため。結果プロセスベースしか存在しない。

手順：

1. 業務（プロセス）の概要を聞く。物・人・金・情報の動き。インとアウト。付加価値。組織の役割責任と体制。この辺はどのプロセスでも共通の事項。
2. 摘要規格の観点から、脅威・脆弱性・リスク認識、管理策（部門規定）の妥当性と運用の実態（記録・設備状況・保管状況等）の適切性を確認する。
3. 確認はサンプリングになるため、網羅性を確保することを念頭に予め部門ごとに規格（特に管理策）のどの部分を質問するかチェックリストを用意する。

プロセスベースのメリット：

1. 複数規格同時審査を可能とすることだけでなく、
2. 合理的なサンプリングの結果、個々の審査でも審査の効率改善に有効。
3. 重要なプロセスに沿った確認が多くなり結果的に重要資産の審査が出来る。（重箱の隅を突く審査からの脱却）

管理策の審査

管理策は１３３項目もある。その殆どがリスク対応として採用されている。この審査をどのように行うか。

方法A：

• 管理策項目をカテゴリー分けして、カテゴリー毎に担当主管部門の審査を行う。管理策項目に対する網羅性を確保できる。
• 現場審査は部門に対する網羅性の観点で計画を組む。
• 長所-網羅性を確保できること。審査スキルを問わない。
• 短所-審査工数は多くなる。

方法B：

• どの管理項目はどの部門・どの機能で受けているかのリストを用意する。
• どの部門を回れば管理策審査についての網羅性を達成できるかを把握し、部門審査（現場審査）計画に反映する。
• 長所-時間効率が良い。
• 短所-準備工数が掛かる。審査スキルを問う。
  

審査の枠組み２

• システムの審査：文書体系がその記載事項も含めて妥当か。この中には当然管理策も入ってくる。
  

• 管理策の審査：文書化された管理策はシステムの審査に含める。管理策の運用の審査は内容によってはシステムの審査に含めるものと現場の審査に含めるものとがある。

• 現場の審査：現場部門における実施状況の審査ですから、現場の長または担当者が質問する相手になる。現場に摘要される規範と運用状況。ここで少々混乱するが、現場にも構築プロセスに関わる活動とルールを遂行する活動と２面性があること。この構築プロセスの部分は「システムの審査」に含めておきたい。
  

※注：ここでは「審査」「監査」は通常の場合は同義で捉えてください。

審査の枠組み１

審査の枠組みは、書類審査-現場審査とか、第１段階審査-第２段階審査とか、書類-初動-本審査とか、の手順を踏みます。慎重を期す旨ではこれに予備審査が加わります。

1st Stage:仕組みの審査と2nd Stage:運用の審査。

ここで問題は仕組みは行き成り存在するのでなく構築プロセスを回してようやく仕組みになりうる要素があること。クルマの始動も行き成りエンジンの力で自走にはなりませんから、セルモーターに相当する部分の仕事があります。この部分が予備審査の実態でしょう。

審査の心得：質問の仕方

審査は事実を把握理解するために、文書に目を通す、話を聞く、現場を見る。どの文書、どの話、どの現場にするかは、サンプリングして決めるしかない。一切合切を見たり聞いたりは出来ないから、部分から全体を判断する。

「審査の心得」としては、「質問の仕方」が重要な意味を持つ。興味本位（技術的なこと、ビジネス的なこと、を含めた一般的な質問は目的達成の導入部であってミニマムに押さえる事が必要です。

A.6.1.1 情報セキュリティに対する経営陣の責任

6.1.1　情報セキュリティに対する経営陣の責任

これも本文。事務局、管理スタッフの管理策。

A.6.1 内部組織

6.1.1　情報セキュリティに対する経営陣の責任

６ 情報セキュリティのための組織

6.1　内部組織
6.1.1　情報セキュリティに対する経営陣の責任

A.5.1.2 情報セキュリティ方針のレビュー

「管理策」

• 予め定められた間隔＝定期的にレビュー
• 重大な変化が発生した場合にレビュー

「審査・監査」

• ルールの有無。定期的の定義＝年１回か、年２回か。レビューの時期は明確か
• マネジメントレビューの側面では規格本文
  

A.5.1.1 情報セキュリティ基本方針文書

これは内容的には規格本分の方が分かりよい。こちらは情報が多くなって返って分かりにくい。

記載すべき事項：

1. 適用範囲。定義。
2. 事業上の目的との関連
3. リスクアセスメントの枠組み
4. 方針・原則
5. 責任の定義
6. 方針を支持する文書の参照

本分にある５項目と似ているので混乱する場合もあるが、要求規格（本分）に沿う方が分かりやすい。

A.05 セキュリティ基本方針

A.5.1　情報セキュリティ基本方針

方針を策定して文書化しなさい、レビューしなさいと言っているだけ。だな。

A.5.1.1　情報セキュリティ基本方針文書

実際の文書を見せてもらう。

A.5.1.2　情報セキュリティ基本方針のレビュー

改定履歴。

17799 4 リスクアセスメント及びリスク対応

4.1　セキュリティリスクアセスメント

これは規格本文（27001）のサマリーになっている感じ。
4.2.1c)以降。

4.2　セキュリティリスク対応

ここも同じだね。

3 規格の構成

3.1　箇条の構成

全部で１１か条。セキュリティカテゴリーって何かな。目的に相当するものかな。

1. 基本方針（１）
2. 組織（２）
3. 資産（２）
4. 人的セキュリティ（３）
5. 物理的環境的セキュリティ（２）
6. 通信及び運用の管理（１０）
7. アクセス制御（７）
8. 情報システムの取得・開発・保守（６）
9. インシデント管理（２）
10. 事業継続管理（１）
11. 遵守（順法？）（３）

全部で（３９）カテゴリ。

3.2　セキュリティカテゴリ

以下を含む。

1. 管理目的
2. 管理策
   

17799 2 用語及び定義

規格ごとに定義が変わっていたら困るけど、時代が進めば定義も変わって当然。だから、規格とは別に整理すべきですね。

1. 資産 (sset)
2. 管理策 (control)
3. 指針
4. 情報処理施設（情報処理設備）
5. 情報セキュリティ
6. 情報セキュリティ事象(information security event):特定の状態の発生。脅威・脆弱性の存在を、可能性も含めて、示す事象。
7. 情報セキュリティインシデント：望ましくない情報セキュリティ事象。
8. 方針
9. リスク：事象の発生確率と事象の結果の組み合わせ。結果を言うだけではリスクの説明として不十分と言うこと？
10. リスク分析：リスク因子の特定、リスク算定のための系統的取り組み。
11. リスクアセスメント：リスク分析からリスク評価まで。
12. リスク評価：重大さの決定
13. リスクマネジメント：リスクアセスメント、リスク対応、受容、コミュニケーションまで。
14. リスク対応
15. 第三者
16. 脅威(threat)
17. 脆弱性(vulnerability)

17799 0.8 組織固有の方針の開発

規格の個々の箇条に対する組織の取り組みを対応表として用意することは有用。除外したもの、追加したもの。

適応宣言書の一歩前の資料になるかな。

17799 0.7 重要な成功要因

a)事業目的と基本方針の整合性
b)組織の文化に見合った取り組みと枠組み：これは難しい。所謂さじ加減だから、結果論でしか判断できない。
c)管理者層からの指示・関与
d)情報セキュリティへの理解
e)全員への普及
f)手引きの配布
g)資金
h)教育
i)インシデント管理プロセスの確立
j)PDCAを回すための測定システム

あまり面白くない。

17799 0.6 情報セキュリティの出発点

情報セキュリティ活動を開始する時、最初の手がかりとなる有効な管理策は何かと考えなさい。と言うことのようだ。

法的要求事項から来る管理策が分かり易い。

a)個人情報及びデータの保護：
社員、取引先、顧客などの個人情報として何があって、どのような管理になっているか。

b)組織の記録の保護。
記録はもっと広範だから定義「組織の記録とは」で間違えると大変。

c)知的財産
有形のものは分かりやすい。

トップダウンで落とし込まれてくる管理策も出発点として分かりやすい。

a)基本方針
b)役割
c)行動規範・教育事項
d)業務ソフト開発要件
e)技術的脆弱性管理：これは対応する役割部門の設定が難しいが強いて言えば検査部門・監査部門になるか。そこの業務標準に収まるものだ。
f)事業継続管理：これも部門役割との対応が難しい。特に日本の企業には意識が根付いていない。だから情報部門だけでの事業継続管理になりがちだが機能しない。
g)事件事故の管理：各部門がばらばらに取り組んでいる。取り敢えずはそれを集めてみるか。

17799 0.5 管理策の選択

リスクが受容できるレベルにまで提言するように管理策を選択する。

リスク･レベル：全く観念的です。リスクと言っても千差万別。同じ皿の上には並べられない。ですから金額で説明できたら返って分かり易いかもしれない。

管理策：巡回パトロールを管理策に入れても毎日か毎時間かなど結構アナログ。これがリスクにどのように影響するかも分からない。ただのお呪い・迷信の類かもしれないし。

管理策自身が法に照らして妥当なことは当然要求される。

管理策とリスクレベルの因果関係が簡単に分かるわけは無い。でも始めることが大事だ。

ただ、分からないの正直なところだから、普通の着地は世間並み。最先端の企業で無い限り世間並みは大事なポイントだ。仮に、世間が１００社なら、トップ１０のレベルは参考にとどめ直接は目指さない。次の２０を目標にしていいだろう。で、自分が真ん中の４０に入っていることを確認しておくこと。

後ろの２０にいたら先ずはレベル（平均）を達成すること。

最後の１０に入っていたら組織の責任者が自ら指揮をとるなど最優先課題に設定することが必要でしょう。

17799 0.4 セキュリティリスクアセスメント

体系的に行う。結果（主力）は識別されたセキュリティ要求事項となる。

17799 0.3 セキュリティ要求事項を確立する方法

セキュリティ要求事項：これは大事なキーワード。ただ一般的過ぎて単に要件と言うのと変わらなくなるが。

情報セキュリティを始めるには情報セキュリティ要求事項の識別から始めることになる。

情報セキュリティ要求事項の識別方法：

1.　組織のリスクアセスメント。ニュアンス的には組織自体が持っている内部的な弱点の抽出。
2.　法令、規約、契約上の要求。社会的文化環境からの要請。法に触れなくても緊急事態に地域活動をやらなかったら社会からは大きな避難を浴びる。
3.　情報システムあるいは情報管理に影響を及ぼす事業場の要求。

17799 序文 0.2 情報セキュリティは何故必要か

凄いことを自問してきた。

情報が無ければ事業は成立しないのは当然でしょ。管理された情報でないとまずいのも当然。嘘の情報では会社は回らない。

しかし、情報は危ういものであることも事実。意識して保護してやらないと情報そのものが情報としての意味を失う。

誰かと共有するには必要なインフラも相応のレベルが必要になる。ある組織にクローズした問題では収まらない場合もある。

17799 序文 0.1 情報セキュリティとは何か

・情報とは事業の基礎をなすもの。適切な保護が必要。「情報システム及びネットワークのセキュリティに関するOECDガイドライン」

http://www.mofa.go.jp/mofaj/gaiko/oecd/security_gl.html

http://www.meti.go.jp/policy/netsecurity/oecd2002.htm

・情報の形態によらず、常に適切に保護されることが望ましい。

・情報を脅威から保護することを情報セキュリティと言い、その目的は、事業継続、事業リスクの最小化、事業機会の最大化。マイナスを減らし、プラスを伸ばす。

・情報セキュリティは、適切な管理策を実施することにより達成する。実施に当たっては、他の事業管理プロセスと合わせて実施するのが望ましい。

17799 前書き

ISO17799:2000を改定したのがISO17799:2005

ISO17799=ISO27002?

ISMSってピンと来ないね。取り敢えずISO17799を

ISMSってピンと来ないね。取り敢えずISO17799を見てみる。

17799はリスク対応のための管理策を解説したもの。１３３項目ある。これで足りなければ追加の施策を入れてよい。それがISMSの考え方。

内部統制のテンプレートにISMSとか17799を使うアイデアに対してあれは使えないと切り捨てる輩がいる。そういう輩こそ切り捨てなければいけない。本番直前ではもう何も出来まいが。