Security First: 2008

リスク評価の基本

リスク評価の基本が案外出来ていない。何故だろう。無理解な審査員、コンサルタントが普通の思考を阻害しているとしか思えない。

情報セキュリティにおけるリスクとは、情報セキュリティを喪失した時に発生する被害額の期待値。

情報が全く入っていないインストール前のパソコンなら、被害額はパソコン本体のお値段でそれが期待値の最大値。もっとも、買い替えの時間的ロスを入れるともっと大きい数字になるだろう。

コンテンツは複雑でセキュリティの喪失状況によるし、客観的な損失額の評価が簡単に出来ない。そこで、事前の策としては金額の代わりにレベル区分を与えた。

Value(価値）は金額またはレベル区分（金額を推定できるレベル区分）。

Threat（脅威）は、最初に識別され、評価される。年間予算で計画を組む前提なら評価は年間の発生頻度を出しておく。

Vulnerability（脆弱性）は、識別された脅威に対する被害確率。その脅威が現実のものとなった場合に、発生する被害の大きさの比率。全損となる場合は１、１０％を失う場合は０．１、全く影響を受けない場合は０となる。

資産Aの年間の被害額の期待値は、価値A×脅威A１×脆弱性A１＋価値A×脅威A2×脆弱性A2+・・・・。

これをCIA独立してやるのだから際限も無い。だから普通は主要な資産（主要な価値、脅威、脆弱性）に絞るし、金額ベースでなく、レベル区分ベースに置き換える。このレベル区分が本質を見失う要因になることが多い。

脆弱性は確率で、０．０～１．０を区分分けする。
脅威は年間の発生回数で、０回～ｘｘｘ回（最大3桁程度）を区分分けする。
価値は損害額で、０円～ｘｘｘ億円（組織の全体価値）を区分分けする。

この3つの関係はCIAで一致させておくこと。Cを重視するからと言ってレベル区分を変更する組織がある。変えて良さそうなのはCの価値だが、金額換算がベースにあればテンプレート事態は全く影響を受けない。

計算は掛け算とサンメンションしか存在しない。

個々の脅威と脆弱性から問題（リスク値が受容レベルを超えているケース）を探すには掛け算だけでよい。
サンメンションは個々の脅威脆弱性の関係はクリアしているが、総合トータルして危険な資産を発見するのに利用できる。残留リスクを積極的に評価する手法である。この段階までハイレベルな取り組みを行っているISMS組織は今まで1社しか見ていない。

さて、

リスクアセスメントの事例を見るとどうしてこうも無意味な計算式が、マトリクスが策定されてしまうのだろうかと思うことがある。複雑化され合理性を失った計算式を見ると、論理性の無い、それでいて傲慢な管理職の存在が目に浮かぶ。厚顔無恥の御仁。それが経営者か、管理責任者か、コンサルタントか、審査員か、興味深い。

リスクを取り込まない適用範囲

リスクを取り込まない適用範囲にお目にかかると非常に残念です。

リスク受容基準を高くして問題を顕在化させない。問題を検出できない内部監査。報告に終始するマネジメントレビュー。リスク対応計画が周知事項伝達事項のみ。弱点を報告しないあるいは収集しない。いろいろ考えますが、これらは全て目的を忘れて、空回りさせるだけのPDCA。

しかし、もっと酷いのは適用範囲そのものをリスクのない領域に設定している組織。

よく耳にするのが、最初のシステム構築はモデルシステム～リードシステムとして進めたいから、問題の無いところで設定したい。その後、PDCAを回しつつ準じ拡大していきたいとする考え。しかし、翌年も翌々年も遂には更新のときも、当初のモデルのまま。何も変わらずに。でもその会社は認証取得していますと世間には言う訳だ。これが一番危ない。錯誤を生むことにもなるから。

※

組織の長が一方的に悪いのではない。審査員の方も適切な方向を示すべきだし、コンサルは更に具体的手順を示すべきだ。

見ていると、審査員は青二才。経験も年齢もないから、指導的な幅のあるコメントは示せない。ただの事務処理をやっているだけにしか見えない。コンサルも余計な口出しをして仕事を失いたくないのだろう。

仮にこういう事例ならどうだろう。本社には集中管理されたデータ。しかし、現場にはその元データである個人情報が、社員、アルバイト入り乱れて作成、処理されている。全国に散らばる現場。組織人数も大半が現場。其れなのに適用範囲は本社だけ。最高責任者は組織のトップではない。

スコープの記載も曖昧になるだろう。本社の人間、会社を代表する人間の名刺にはロゴマークが入る。意図的な錯誤誘発行為に見える。

｜部署ではどのようなISMS教育が行われているか？

各部署の部員が受ける教育の概要を問われる。

部員の構成を確認する。
指導的立場の人、内部監査担当、機密情報に触る人、一般部員、出入りする人・常駐する適用範囲外の人。
それぞれに求められる力量を確認する。
求める力量に対応した教育計画の存在を確認する。
実施状況を確認する。使ったテキスト・掛けた時間・担当した講師（講師の力量も）
実施結果を確認する。目標とする時期まで終えたか。教育を受けないでセキュリティに触る業務についていないか。配属までに終えているか。抜け漏れが無いかチェックしているか。効果測定は実施されているか。未達の場合の対応は打たれているか。

※

教育は事務局が一手に引き受けることが多い。だから上記の質問は全て事務局にスルーパスして良さそうだ。

しかし、それが十分かどうか。部署固有の要求事項の有無に注意を払う必要がある。本来は部署固有のものも事務局にすくい上げて汎用化・一般化して全体の教育に反映させていくのが望ましい。

｜組織の概要はどのようですか？

組織の概要を聞くことで以下概略を確認する。

適用範囲との連関。スコープ外の内容が含まれて居ないかを確認する。（4.2.1a))
重要な情報資産の存在→資産台帳への反映。(A.7.1.1)
重要な情報資産の受け入れあるいは受け渡しの方法→適切な管理策が講じられているか。(A.10.3.2、A.10.8.1-3)
人数規模＝潜在的なリスクの大きさ。(5.2.2)
役割構成。（5.1c)、A.6.1.3)
外部サービスの利用。(A.10.2.1-3)
取引先・顧客。（A.6.2.1-3)

｜内部監査の実施結果はどうでしたか？

監査計画の存在、チェックリストの準備（6a)、6b)、段落)
アサイン者の妥当性（力量、身内監査、教育）（5.2.2）
結果の記録、記載されたチェックリスト、記録の承認（4.3.3）
手書きの記録をパソコンで打ち直していることが多いが、その場合はタイプミスや改ざんが入り込む懸念がある。記録は紙のまま、イメージで読み込んだものとする、ファイルロックを掛けるとか工夫が必要。管理データの作成と記録の保存を混在させない工夫が必要。
結果の報告（報告書、指示事項）
マネジメントレビューへのインプット（7.2a)）
指摘事項と是正確認（8.2）

｜有効性評価はどのように行っていますか？

有効性評価についてはいずれ27000シリーズで参照ガイドがリリースされる。それとの連関は不確かだが、JIPDECがガイドを出しているものがある。

http://www.isms.jipdec.jp/doc/JIP-ISMS111-21.pdf

ISMSユーザーズガイド7章（P96)「有効性の測定」を参照すると、あまりに複雑な内容で面食らう。ガイドというよりミス･リードの懸念がある。前半で行っていることとサンプルで最後に示している目次構成の対応関係も分からない。まあ、対応させていないと言う答えだろうが、それではガイドとして中途半端。

マネジメントシステムのレビューには当然その内容として有効性評価が含まれている。それは経営品質から各サブシステムまで同じ。だから、ISMSだけを取り上げてユニークな仕組みを作ることの是非は組織ごとに検討されなければならない。

ガイドを見ていて気になるのはデカルト的な発想を進めていること。プロセスを分解していくことが果たして目的に近づく道なのかどうかです。プロセスを細切れにすると返って目的を見失う。あるいは目的との連関が曖昧になる。そういうリスクも踏まえた分析であるべきです。

※

トップダウンアプローチ。

測定プロセスだけが唐突に出てきても駄目で、方針・施策展開との連関で有効性測定も展開されなければいけない。その意味では、方針に有効性を示唆する内容を求める必要がある。あるいは、マネジメントレビューのアウトプットにて明確にされるべき事項です。

4.2.1b)の中で、

１）項では、有効性評価の指標を示唆すべき。
３）項では、上位の経営目標・管理目標（経営品質）との連関を示唆すべき。

｜文書の変更はありましたか？

｜文書の変更はありましたか？

文書は定期的に見直す見直し規定がある。その手順に乗っているかどうか。
版管理・更新管理・保管/廃棄管理・周知・承認について確認。

4.3.2文書管理のa)～j)の確認

｜新たなシステムの導入はありましたか

｜新たなシステムの導入はありましたか

新たにパソコンを買い入れた、サーバーを買い入れた、システムの導入をした場合は、

資産が登録管理されているか（A.7.1.1）
資産利用の許可が管理されているか（A.7.1.3)
システム受け入れの手続きを踏んでいるか（A.10.3.2）

これらは当然、リスクアセスメントサイクルにも反映されている必要がある。導入時期の後にリスクアセスのタイミングがあればリスク分析を見ることになる。

一連のリスクアセスメント（4.2.1c)～）に新たな資産が反映されていればそれで良い。

｜リスク値が基準を超えたらどうしますか？

リスク対応計画の策定(4.2.2a))
リスク対応の選択肢（4.2.1ｆ))
追加の管理策の選択(4.2.1g))

｜.審査時の質問と確認

審査では、審査員が色々質問してくる。資料の提示を求めたり説明を求めたりしながら、まるで潜水艦ゲーム。説明の連関で質問してくることもあれば唐突に方向違いの質問も出てくる。こちらが身構える前に矢が放たれると思わず本音で回答する。そこに前の質問回答との矛盾があると戻って再確認。なんてね。

だから飾るのは愚行。隠し通せたとして誰のためにもならない。馬鹿馬鹿しい。指摘事項の件数を管理特性に入れる馬鹿マネジャーに振り回されることになる。事件事故ゼロを管理特性に入れると隠し事が増えるだけに終わる。管理指標はポジティブ指標を選ぶべき。ネガティブ指標を選ぶと失敗する。

質問が何を意図しているかを理解するのは悪くないだろう。適切な答えにつながるから。方向違いの回答をして墓穴？を掘ることもない。別に嘘をつく訳ではないのだから。

「｜」でリードするタイトルに質問を入れてみる。ラベルで規格番号が入るから簡単なクイズになるでしょうか。

ISMSの有効性

経営の期待に応えている。

即ち、

事業継続上の不安が押さえ込まれている。
事件事故が防止されている。
リスクが押さえ込まれている。
変化に追従できている。
常に最新の状態である。

即ち、ISMSが適切に運用されていること。

でも、誰が適切かどうか判断するんだろう。

マネジメントレビュー
即ち、経営者自らが判断すること。
外部の審査・監査
これは難しい。
・特に審査機関は要注意。限られた工数の中で、サンプリングの前提でささっと見ていくが形骸化・パターン化・表層化して本質に目が届かない。
・コンサルは日頃付き合いのあるところは上手くない。
・日頃付き合いの無い、しかし能力のある個人コンサル（少人数コンサル）が良いだろう。時間をかけてじっくり見てもらう。

更新審査

更新審査は3年経過毎に実施される。

更新審査で特に意識されるのは「有効性」。有効性とは何か。

規格でストレートで表現される有効性は、管理策の有効性。

「管理策の有効性」も2段階の構造を持つ。１つは「管理目的」に対する有効性、もう1つは管理策の実行に対する有効性。管理策は組織としての具体的な施策に展開されるが妥当な施策展開とその実施でなければならない。(4.2.2d))

管理目的は、リスク低減そのものだから、リスク値の低下を持って有効性評価とする向きも多い。丼だね。施策が有効でも別のリスクが出ればリスクは上がる。その辺の識別をしておかないと適切なレビューは出来ない。

ISMS自体の有効性。こちらはリスク値が下がることで良さそうだ。全体の有効性は丼で十分。一方で上を見た視点もある。ISMSは機能別管理の１つの機能。その上にあるのは経営目標。経営から見て十分役割を果たしているかと言う視点。

事業継続上の不安が無い状態。事件事故が無い状態。どこから見ても安心。社会的信頼を勝ち得た状態。経営が行う顧客アンケートのセキュリティの項目のポイントが高い状態。もっとも、これは更新審査の枠組みで捕らえることでない。経営品質など上位概念での問題だ。

｜適用範囲に変更はありましたか

初回の審査でなければ前回審査時に対して変化点の確認を行う。

しかし、適用範囲に変更はありましたか」と聞いても駄目。適用範囲を理解していないから。噛み砕いて、一つ一つ聞いていくしかない。

4.2.1a)
適用範囲の変更の有無を確認する。事業、契約・法規制、ロケーション、資産、組織についての変更の有無。

媒体の持出

オフィスには媒体がどれくらいあるか。

フロッピー、CD、DVD、そのうちBDも。USB。CF。SD。SDはカメラやPDAや携帯音楽。携帯そのものにも。外付けのHDD。

それらは会社のものか個人のものか。どのように識別するの。今どれだけあるの。

加えて、その中身は何が入っているの。入っているものも時々刻々変わり得る。

こんな状況でどんな管理が成立するのか。

持出記録が成立する前提が押さえられていなければ労力の無駄だ。メディアそのものの価値は無視できる当世なら、ネットワークと同じく単なる媒介ルートに過ぎない。誰も物理的にケーブルのチェックはしない。

システムとメディアとの接点管理しか存在しない。特定のパソコン以外は一切禁止する。ハード的にもソフト的にメディアの読み込みは禁止するしかあるまい。

パソコン自体もメディアと同じ扱いになる。ネットに接続する段階でチェックする。ネット～サーバーにアクセスする段階でチェックする。

※

メディアを適用範囲の外へ持ち出す時は基本は空にする。持ち込む時も。適用範囲内に保管する時も。例外は「情報」を持ち出す時、「情報」を持ち込む時。「情報」を保管する時。

・持ち出す時は、サーバーからのダウンロードと照合する。持出サーバー、持出フラグ、持出検閲ネットなどを使う。

・持ち込む時は、サーバーへのアップロードと照合する。検疫、持ち込みフラグ、など。

・保管は両方向の管理。保管状況管理。バックアップ基準との関連で適切な管理状況にあるか。

※

適用範囲の外に出たメディアの保護

暗号、パスワード。丈夫な入れ物。置き引き防止。メディア個体の管理（登録）。

蛻の殻（もぬけのから）

監査だってあちこちいろいろ出かける。会社が大きいと現場も色々。いきなり出かけるわけではないが、嫌、いきなり出かけないからか、行くと事務所はもぬけの殻というのが結構多い。大概は客先へ出かけている。朝は居たとか、夕方には戻るとか、忙しいのだ。よくある話。

オフィスに居ないのが正常という意味での、究極は派遣型ビジネスでしょう。客先に常駐する訳で、オフィスに帰るのは給料袋貰うか表彰状でも貰うかの時しかない。まあ、本籍がオフィスで現住所は客先と言う訳だ。大手メーカーの設計部の一角にそういう常駐者のスペースがある。簡易仕切りを置くときもある。

で、ＩＳＭＳなんですが、本籍が有るだけの人を適用範囲に入れてＩＳＭＳを取りたいと言うから難しい。

ＩＳＭＳの目的からすれば、現住所であるその常駐先でのＩＳＭＳにこそ入るべきで、本籍地のＩＳＭＳは本質とは言いがたい。

判別は、ＰＤＣＡが回せる範囲かどうか、責任をもってリスクに対処できるかどうか、責任区分を明確にできるかどうかでするしか有るまい。

※

隙間のような業務、例えば勤怠管理しかしない派遣先での仕事を捕らえて、適用範囲に入れてもしようがあるまい。設計でも、顧客対応でも、その人の本来業務という柱が派遣受け入れ先の管理下にあるなら、派遣先のＩＳＭＳに入れるべきだ。

むしろ、積極的に本籍側のＩＳＭＳから除外すべきだ。無理やり入れることで、本籍側からも現住所側から適当に距離を置かれて真空地帯になるリスクを生む。

識別しない識別

識別しない識別は時々あることです。重要と書いた資産は重要だから盗難に遭いやすい、標的になりやすい。文字は止めて赤色マークをつけても目立つから駄目だと。重要かどうかは現場の人間は分かっているのだから、外部の人にわかるような識別はしない。

現場のちょっと物の分かった風のマネジャーが吐く意見として珍しくない。紙ファイルでもこういう話は出るし、メディアでも出る。メディアは都度パソコンにかけないと何が入っているか分からない。そういう状態でも構わないと主張し始める。

識別してリスクを把握して管理策を打つという基本的な流れの最初の一歩で躓くことになる。ＩＳＭＳを避けて通るのがこの人の狙い。困ったことにこの人はＩＳＭＳの管理責任者だった。経営者にも現場にも良い人でいたい管理責任者は、だから実態の無いワッペンだけの認証を取得することになる。それも重大事故が起きるまでの間だが。まあロシアンルーレットに乗って仕事をしているようなものですね。

会議室にネット環境が無い。仕様がないからＬＡＮケーブルを床に這わせて会議室テーブルまで持っていく。パソコンがネットワーク利用出来る。会議の間、数時間だけのこと。ケーブルに特に保護はしない。これって、ＩＳＭＳ的には、どうなるの？

誰でも簡単にＬＡＮ延長が出来るのはゾーニングとか意味を成さない。
通路にケーブルが横たわるから躓く･破損させる懸念がある。

一番は、ＩＳＭＳの内部監査をやっている日でも業務優先でケーブルが横たわること。配線工事を許可を取ってやれば済むのにしない。この会議室テーブルは実ｈあいつもこんな使い方をしている。現象は些細なこと。問題はセキュリティに対する感性が緩むこと。いつの間にか見慣れた景色になってしまった。

プロセスベース審査

審査に出かける前に、訪問先の部署の概要を把握することは、多くの場合、ＷＥＢサイトから容易に出来る。その特徴を踏まえて、予めどの管理策についてチェックするかプランを用意することは、初心者には有効。内部監査の場合は、事務局が用意することが多いが、主体的取り組みを是とするなら、監査員自らも準備してみることは有益。もっとも、事務局が想定していない質問が出て関係部署には迷惑掛けるかもしれない。

＜会議室またはテーブル＞
「部署名」
「責任者」
「ミッション」～「業務概要」
「組織構成」～「上位・全体組織」・「取引先」
「重要資産」～「重要資産のプロセスフロー」
「管理体系」～「現場で利用している・認識している管理標準」
「重要資産に対する管理策※」
「インシデント・内部監査等指摘事項対応」

＜現場＞
「テーブル審査で現場確認したもの」
「物理的」～「施設・ゾーニング・ケーブル・鍵管理など」
「資産識別」～「ファイリング、メディア管理」
「人的管理」～「スキル、周知、個人の役割実施状況」・「誓約書など人事」・「インタビュー」

重要資産に対する管理策※

３桁レベル（A.x.x.x)で優先度を付けて１０個程度*用意する。前半で確認できなかったものは現場から引き上げてから確認する。審査記録用紙の冒頭に予め記載しておいても不都合は無い。

但し、想定外の重要資産の存在が判明した場合は、その重要度を図って適切に組み替える。特に部門に固有の資産の場合は（他所で聞けないから）、優先してチェックする。この臨機応変な対応が大切。

１０個程度*

１０個には根拠は無い。あまり多いと現場とのやり取りからより正しい姿を引き出すことが難しくなる。会話が大事。少ないと網羅性が確保しづらくなる。１０個は事前準備の量的な目安。現場対応が真の姿。

プロセスベース審査

管理策の当て方：

・主プレイヤー（主）はルールを作る。機能別管理をする。
・客プレイヤー（客）はルールを受け入れて実施する。

Ａ.5：（主）経営者、事務局。（客）一般従業員。取引先。
Ａ.6：（主）経営者、事務局。（客）部門の長。
Ａ.7：（主）事務局。（客）一般従業員。一般部門。
Ａ.8：（主）事務局、人事・教育部門。（客）一般部門。一般従業員。
Ａ.9：（主）事務局。総務部門。情報部門。（客）情報部門。一般部門。
Ａ.10：（主）情報部門。（客）情報部門。一部一般部門もあり得るがこの管理策では見ない。
Ａ.11：（主）事務局。情報部門。一般部門。（客）情報部門。一般部門。一般従業員。
Ａ.12：（主）情報部門。（客）情報部門。
Ａ.13：（主）事務局。（客）情報部門。一般部門。
Ａ.14：（主）事務局。（客）事務局。情報部門。一般部門。
Ａ.15：（主）事務局。法務部門。（客）一般従業員。一般部門。情報部門。

部門へ行って（あるいは来て貰って）、業務概要・適用範囲・重要資産を最初に聞くときに、上記のどの管理策のチェックが重要か判断する。情報部門以外でも情報処理設備を有するときは情報部門に準じたチェックを行う。

その部門に固有の内容を優先してチェック。赤色にした部門。

質問は、直接（いきなり）規格から引き出さないで、規格要求を踏まえたルールの存在から確認する。有れば、それに沿ったチェック。無ければ無くても構わない理由、あるいはそれに関連するリスクアセスメント状況を確認する。結果が妥当ならパス（ＯＫ）。ルール上あるいは実施上の問題を認識・合意できれば指摘事項・観察事項としてあげる。

確認する手順としては、管理策に入る前に、これまでの審査・監査での指摘事項の有無、改善状況の確認を行う。改善プロセス（ＰＤＣＡ）が回っているかどうかの確認で最も重要な作業の１つ。

会議室テーブル上での文書と口頭説明による確認と現場の実態・状況の確認は、時間的には半々とする。ＵＫＡＳは現場に出ることを多くするよう指導しているから、会議室は４割程度が望ましい。ただ、その場合の問題が審査記録（メモ・エビデンス）の存在。これの充実を強要すると自然と現場に出づらくなる。審査機関によっては形式化したエビデンスの意味を見直している。

１部門９０分とした場合、３０分以内に全容確認・文書ベース確認、３０分は現場で状況・実態確認。残り３０分は全体のまとめ・記録の整理に当てる。必要なら現場チェックの補充を行う。

プロセスベース審査

プロセスベース審査の再考。

プロセスは相対的なものですが、今、相手にしている審査対象を１つのプロセスと見て審査することが出来る。プロセスのスーパーセット（上位概念）とサブセット（下位概念）の理解も必要。ＩＤＥＦ０？の発想で捕らえれば全部共通になる。

ＩＳＭＳの観点でＩＤＥＦ０を見ると、

先ず情報の流れを捉える。基本プロセスである情報の受け入れ、情報の加工、情報の吐き出し。コントロールするための情報管理体系。支えるメカニズムである情報システム、関連マニュアル、従業員など。

この全体をもう一度、ＩＳＭＳの視点で包みなおす。機能別マネジメントの１つ、セキュリティの側面で捕らえなおす。実態はＩＳＭＳも情報管理体系に埋め込まれてしまうが、ある要件に応えているかどうかを見るために、ＩＳＭＳのフレームに乗せなおす。

ところが、ＩＳＭＳあるいはセキュリティの定義が実はとても広いものだから、情報セキュリティからセキュリティを外しても実は同じものになるので分かり難い。ただの情報管理と言ってくれた方が分かりやすい。

プロセスの構造を理解する。責任者、スーパーセット、サブセット、役割責任あるいは機能概要、重要な情報の入力・出力・推進機構・統制機構（ＩＣＯＭ）。
統制機構（コントロール）の概要、及び統制機構が要求する記録・実態の確認。

さてと、管理策との関係は？

構築が終わっていれば管理策はコントロールに既に盛り込まれている（筈）。記録を追えば、その部署の管理策の実施状況が確認できる。即ち、管理策をベースに突っ込む必要はない。プロセスベースと言う訳だ。

本当にそれで良いのか？。これは”筈”に支えられた推論でしかない。

その部署の重要情報資産の特性を見抜き、その特性から予見される管理策の有無・実施の状況を確認すべきだ。ある部分は既に管理マニュアルに反映され、実施の記録もあろうが、ある部分では管理されて居ないかもしれない。

穴が見つかれば、リスクアセスメントに戻って、構築プロセスをトレースする。その中で、仕組み上の結果、実施上の欠陥が指摘できる。

基本方針は何故一枚ものか

基本方針は何故一枚ものか不思議に思う。

周知するには何ページもあったら無理でしょうと悪魔がささやいたから。悪魔が誰かは誰でも知っている。だから中途半端な舌足らずの、はっきり言って出来損ないの方針書が出来上がってしまう。周知する工夫と、明確な方針を作ることは全く別問題。言うべきことは５ページになっても構わないでしょう。

どこかの会社のホームページを見てください。Ａ４サイズ１ページだったら、そこの経営者は自分では何も考えていない可能性があります。もちろん、本当に方針として言うべきことがＡ４サイズ１枚に収まったら、ミラクルだけど否定はしない。普通は無理。６ポイントを使ったって？。意味有るの？。

4.2.1b)

ここは基本方針。

リスクを評価する基準と言うのが出てくる。”ＣＩＡのどれか、複数でも構わない”、としているのが普通。それって本当に基準なの。方針として何か意味を成しているだろうか。当社は機密性だけで良いなんて方針に入れる訳ないでしょう。

ＣＩＡは資産特性が決める。

方針に入れるべき「基準」とは？

自己矛盾

ＩＳＭＳの規格を久し振りに手にしたが、毎回思うことは、この規格は自己矛盾していないかと言う事。

ＩＳＭＳの運用とＩＳＭＳの監視が別項目になっている。運用には監視も含むので、運用を別立てにされると論理エンジンがエラーを起こしてしまう。ＩＳＭＳの見直しも同様だ。

運用には狭義の運用と広義の運用と二本立てとでも言うのだろうか。

まあ、大人の判断としては幹の話と側面の話と意識して捕らえれば良かろうと。

「乃至」という言葉遣い

審査とか監査を受けると、希ですが、その所見なり報告の中で、「乃至」という言葉を見かけることがあります。

その報告者の国語力の問題として見ても適切に使われていることは少ない。よく知らないで使っている可能性が高い。Ａ乃至Ｂは、ＡまたはＢの意味で生活擁護では通っても、正式（契約等）文書では、Ａ地点とＢ地点の間の連続する領域も含む。即ち、一連の塊の始点と終点を示して塊全体を現している。

審査・監査は、ＡからＢまでつぶさに全部見ていればＡ乃至Ｂも妥当性を持ちうるが、基本はサンプリングでチェックするのだから、個別にピンポイントでどの地点の話しかを明示しないといけない。「乃至」などと、アバウトな表現が出てくるチャンスは少ない筈。

所見を見ると個人に依存している。その人の誤解が不適切な監査報告・審査レポートを生成させている。監査人にクレームするのは嫌だから放置してあるが、レポートをレビューする立場のその監査法人・審査機関のレベルが分かることになる。

始末の悪いメディア管理

携帯電話の中にも、デジタルカメラの中にも、携帯音楽の中にも、小さなマイクロＳＤが忍んでいるし、ＵＳＢは面白グッズに姿を変えているし、私物のメディアを管理するのは到底無理。

可搬型のＨＤＤもある。光学メディアもある。個人のノートパソコンもある。ＰＤＡの類もある。

これのたな卸し表を某社は作って記載させていたが、手間をかけるだけ愚。

会社の持ち物の管理。やっても良いけど、普通のものならほぼ笊（ザル）だね。逆に、某Ｔ社がやっていた一切使用禁止は有効かもしれない。ソフト的、ハード的に穴をふさぐやり方。使えるのは特殊な管理下の部屋だけ。

メディアの識別

内部監査であれ何であれ、各現場を回ると目に付くのが無造作に置かれたメディア。フロッピーは減ったとは言えパソコンとかサーバーの側の机の引き出しを開けると出てくる。CDRも生なのか何か入っているのか分からないものが出てくる。始末が悪いのがUSBで、形もばらばらで、サイズも小さい。

ある部署では、識別（ラベリング）も何もしない理由が、重要と書いたり印をつけると重要と分かって持ち出されるから敢えて識別しないと強弁していた。都度、パソコンに掛けて内容を確認すると。結局、何が持ち出されても分からない状態でリスク受容らしいが、呆れるばかり。もちろんNGだけど、これでその部署の責任者なんだから先は長いというしかありません。

本題：メディアの識別の問題は内容が可変であることが、本質的な問題です。空ならごみでも消しきれていなければ重要資産。その可変性が結局管理を放棄させています。

審査ノウハウ：現場審査

審査ノウハウというほどのものではない。監査とか審査とか、あるいは現場診断とかを実施した場合に、「普通じゃないな」と感じる場面に遭遇する。そこでのやり方が他の現場で見てきたのとは多少違う場合です。

他の現場が、他部門であることもあれば、他社の場合もあります。多少違うのは当然ですが、それでも尚、違和感が残る場合です。通常は合理性、妥当性、適切性などの価値観に触ってくるものです。

で、首をかしげながらも一応メモを取って、場合によっては後で質問できるようにして、次の現場に向かってしまうことがあります。

既に、失敗というか間違っていますね。後で聞いても、殆どの場合、確認にはなりません。既に現場ではありませんから、実際のところ指摘なんてものはできません。守るも攻めるも現場が命です。

現場では、

業務のあるいは管理の実態を聞く、見る。
それら現場の実態は何に基づいての作業によるものかを確認する。現場が使っている作業標準です。
決めたとおりにやっていれば、現場の（作業者の）問題は無い。
現場で使う作業標準（現場で作成した作業標準）に不自然なものがあれば、何に基づいて作成したかを聞く。現場作業標準が共通の標準書（普通は規定）に基づいているか確認する。
規定に沿っていれば現場の標準は問題ない。
次は規定そのものの成り立ちを見る。規格適合性ですね。
で、残念ながら？、規定は規格に適合している。と。

コンサルは不自然を解消するためにさらに深堀をしますが、審査はこれでお仕舞いです。本当？　実力が無いとこういう役立たずな審査になってしまいます。最初の直感は正しくても原因を推定できないのです。でも、現場審査のプロセス自体はこれが正しいのです。

現場審査に入る前に文書審査で、規定類が規格適合していることを先に確認します。ここはまだ机上論です。

電子メールのセキュリティ

電子メールのセキュリティ対策

パソコン上に余計なメールを持ち込まないためにWEBメールを使うのも一つの方法。Webメールはまたパソコンの容量を圧迫しないので、有用。

電子メール関連の管理策は、

10.4.1ウイルス対策
10.4.2モバイルコード対策
10.8.4メッセージの完全性

Webメールのセキュリティ機能

フィルタリング・振り分け→識別
メール拒否設定
フィッシング対策

対応関係が分からない。

主要なWebメールは殆どセキュリティに配慮しているがそれぞれ特徴がある。組み合わせて（＝各Webを直列スルーさせて）より高いセキュリティを目指したい。

Gmail
Windows Live Mail
Yahoo! Mail
Mail@nifty

4.3.2i)と4.3.2j)の違い

違いがよくわからない。どちらかひとつで足りるのではないかな？

4.3.2d)と4.3.2f)の違い

可用性の観点で違いがいまいち理解できない。

4.2.3g)

監視および見直しから検出されたことを踏まえて、セキュリティ計画を更新することが、この項目の要求事項になっているが、さてと困った。この「セキュリティ計画」って何を指すんでしょう。英文を見るとsecurity plansになっているからセキュリティ関連の諸計画としても良さそうです。

リスク対応計画
セキュリティに関する教育計画
運用を管理する中で生まれる年間計画
セキュリティ調整のための運営計画

など何でも必要なものに反映させることになりますね。

4.2.4a)

改善をやれといっているが、何処から引っ張り出す改善なんだろう？

4.2.3b)

4.2.3b)では、ISMSの有効性の定期的な見直しが出て来るがイメージが湧かない。これって、マネジメントレビューでは駄目なのかな。もしくは内部監査では駄目なのかな。

待てよ、これらは、まあ、年次だわね。普通、システムを監視していて、手直しの判断を年次でやる会社は無いでしょう。ミニマム月次で報告レビューでしょう。厳しい会社、変化の多い会社なら週次になります。勿論、大型投資･戦略的なシステム変更は年次に近いものでも止むを得ないでしょうが。

しかし、しかしです。測定基準・評価基準の見直しは年度の途中でやると変になる。見直しの材料は短いインターバルで集めて良いが、根っこの見直しは年次でも良いでしょう。

と言うことは、ここの管理策の肝は、見直しの材料として、十分であったかどうかですね。

「見直し材料」

セキュリティ監査の結果
インシデント
有効性測定の結果
提案
利害関係者からのフィードバック

規格解釈｜4.2.2b)と4.2.2c)の違い

4.2.2はISMSの導入と運用

これのb)項とc)項の違いが分からない。と言うことはリスク対応計画が良く分かっていないことになる。世の中のISMSを見たり聞いたりすると（極めて少ないサンプルには違いないが）、リスク対応計画と管理策の違いを本質的に理解しているところは少ない。リスク改善に繋がるのでどちらであっても結果には大きく影響しないから特に問題にする必要は無いということでしょう。でも正しく理解しておくことも大事ですから、少しトライしてみます。

4.2.2c) 管理策の実施：
既に策定されている管理策の整然たる遂行。
4.2.2a) リスク対応計画の立案：
システム（ISMS)の構築レベルが不十分で管理策の実施に入れる状態にない場合、不足分の工事をやる必要がありますがそのプラン（リスク対応計画）の立案を行うことです。
4.2.2b) リスク対応計画の実施：
プランの実施です。これによりシステム（ISMS)は変化し（改善され）目的の水準に達します。
リスク対応はシステムに変化を及ぼす。管理策はシステム自身は変化しない。管理策を黙々やっていくだけではシステムの改善は行われません。毎年チャレンジ項目を決めてリスク対応計画として消化していくことが大事です。

資産台帳と分類表

「よくある勘違い」

資産目録、資産台帳を作成していると、この手間が大変。同じようなものがずらっと並ぶ。現場部門が非協力的で、事務局が一手に引き受ける場合は、特に大変。で、共通項をまとめたマスターリストみたいなものを作って、例外だけを追記してもらう。部門はマスターと現物との突合せはやらない。
リスクアセスも事務局でまとめてやってしまうので、分類表と変わらない台帳が生き残る。
要因はトップの指示が現場でなく事務局に行ってしまうことにある。トップの意識･目論見･目的が認証取得だけに走ると陥るケース。苦し紛れの勘違いですね。

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

資産の重要性評価ロジックは素直に、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)についても３年スパンでは網羅していることが望ましい。ただ、２桁までの管理（数年度にまたがる管理）は適切な管理システムがないと難しい。

プロセスベース審査

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

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

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

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

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

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

手順：

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

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

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

管理策の審査

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

方法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　情報セキュリティ基本方針文書

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

記載すべき事項：

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

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

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　箇条の構成

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

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

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

3.2　セキュリティカテゴリ

以下を含む。

管理目的
管理策

17799 2 用語及び定義

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

資産 (sset)
管理策 (control)
指針
情報処理施設（情報処理設備）
情報セキュリティ
情報セキュリティ事象(information security event):特定の状態の発生。脅威・脆弱性の存在を、可能性も含めて、示す事象。
情報セキュリティインシデント：望ましくない情報セキュリティ事象。
方針
リスク：事象の発生確率と事象の結果の組み合わせ。結果を言うだけではリスクの説明として不十分と言うこと？
リスク分析：リスク因子の特定、リスク算定のための系統的取り組み。
リスクアセスメント：リスク分析からリスク評価まで。
リスク評価：重大さの決定
リスクマネジメント：リスクアセスメント、リスク対応、受容、コミュニケーションまで。
リスク対応
第三者
脅威(threat)
脆弱性(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を使うアイデアに対してあれは使えないと切り捨てる輩がいる。そういう輩こそ切り捨てなければいけない。本番直前ではもう何も出来まいが。

Security 1st

セキュリティのことを第１に考える訓練をしてみる。

何らかの事象（事態、状況、事件、事故、現象など）を捉えて、セキュリティ上の問題課題とその対応をクリアにする訓練。

事象を捉える視点、問題を捉える目線は、基本的にはＩＳＭＳ規格をベースにする。事象におけるセキュリティ問題を明らかにするために発するクエスチョンは規格項目番号を念頭において行わなければならない。

そのクエスチョンに対する回答はどのようなものが期待されるかも合わせて示さなければ役に立たないだろうが、審査員とコンサルタントでは踏み込みの度合いあるいはスタンスは変わってくるが、組織オーナーとして有用なものを示すことが必要。

◆1.プロセスの理解

事象の顛末、事業概要、業務概要をプロセスとして捉え理解する。この場合、プロセスモデルはＩＤＥＦ０の手法が分かり易い。ＩＣＯＭの４要素、プロセスオーナー～問題の所有者、目的～視点～問題の２要素。全部で６要素を理解する。時系列で、人、物、金、情報の流れを把握する。

◆2.セキュリティリスクの想定

プロセス理解の過程で、全てのセキュリティリスクの想定する。具体的には、プロセス概要の説明を受けながら、懸念されること、押さえで確認すべきことをリストする。

◆Ｑ＆Ａ

当該プロセスで適切なセキュリティ上の管理策がとられているかどうかを質問する。ここは高等技術が要求される。セキュリティリスクの仮説に基づいてプロセスの詳細を聞きただす作業になるからだ。大きな塊のプロセスに漠然とリスク懸念をぶつけても、管理策の課題は拾えない。第１段階審査になってしまいます。

管理策のサンプリングチェックです。ここでは、全体（各セッション合計）としてカバーできていれば良いが、規格の大項目は全て網羅させて置きたい。

◆ベストプラクティスの用意

質問をして相手が正解を答えてくれれば良いが、規格を理解できていない場合は、或いは問題は理解していても方法論、解法を知らない場合は、適切な指針が必要。業界事例としてのベストプラクティスの提示が求められる。