第三者によるレビューを

 手順書を作成する場合には,いろいろなリスクを考える。例えばデータのバックアップが無かったらどうなるか,バックアップがあっても壊れたらどうするか,二つ以上バックアップしていても全部壊れたらどうなるか・・・などなど。厳しい管理にするということは,想定するリスクのレアケースをがんがん追い詰めるということでもある。

 手順書を書く人はどうしても追い詰めることに意識が向きがちになる。ブリンカを付けた競走馬のようなもので,目の前の細かいリスクをいかに追い詰めるかということに突っ込み過ぎるきらいがあるのだ。

 突っ込みすぎを回避するために,できれば第三者によるレビューを実施したい(もちろんそういう人材が用意できるかどうか,ということにもよるが)。

 ポリシー,ガイドライン,手順書というフルセットを作成する場合,レビュー回数も多くなるため,専門チームを組んで実施すると効率的だ。しかし,今回は徹底的に手間を省いて,まさにピンポイントで必要最小限の手順書を作成するわけで,回数をこなすことは想定しなくてもよい。

 逆に言えば,そのピンポイントの手順書作成だけは手抜きできないわけだが,「手抜きできない=必ず専門家が必要」というわけではない。専門的な眼が入ることは望ましいが,とはいえ資金や人材調達も必要になってしまう。

 そこで,作成プロセスではなく,レビューに参加してもらうということを考えてみる。レビューは作成よりも短く,手順書の分量などによるが数日程度の作業量で済むはずだ。専門家の関与も,それだけ少なくて済む。

 もちろん,これは逆に作成時に疑問が生じたり迷ったりしても,専門的な助言が得られないということも意味する。が,初歩的な疑問などは数ある外部講習の受講などでカバーできるはずだ。逆に,初歩的な質問を連発しない程度になっておくことが,手順書作成上の必要条件であろう。だとすれば,いずれ受講なりが必要になるはずだ。

 最小限の資金と最小限の労力――。こうでなくては「積極的な手抜き」というコンセプトは完遂しない。

フィードバックを得る方法

 手順書を作成したらそれで終わり,ではもちろんない。

 手順書の通りに実践されているか,手順書に抜けはないか,手順書が複雑すぎないか,ということを検証しなければならない。

 本稿では前提として,「最低でもこの情報だけは管理しましょう」ということにターゲットを絞って話を進めている。従って,例え複雑すぎたとしても,リスク低減の方が優先されなければならない。

 しかし,いったん「こりゃやり過ぎだ」という印象を持たせてしまうと,その時点からサボタージュが始まる。そうならないためには,前回の記事で説明したように,手順書の作成のときから現場の担当者に参画してもらうことが最も効果的だ。

 だが,今回のテーマは“手抜き”である。多忙な現場担当者をアサインせずに効果を上げる虫の良い方法を考えてみよう。

 一つ考えられるのは,手順書の説明を行うタイミングで,実地に実践してフィードバックを得る方法だ。説明時にQ&Aなどを実施すると,良質のフィードバックを得ることができるが,さらに効果的にするためには質問する方と答える方が両方とも「フィードバック」を意識すればよい。Q&Aを行う場合に「これから質疑応答を行いますが,ここでみなさんからいただいた意見やご感想,疑問点については,できる限りこの場でお答えします。必要ならば手順書の改訂を含めて検討させていただきますので,みなさんも出せるだけのご意見はお出しいただきたい」と宣言する。これだけで意識が違うハズだ。また,場の雰囲気などによっては,参加者全員に一言づつ意見をもらうものよいだろう。

 ちょっと小技になるが,改訂履歴に起案者として意見を出した人の名前を入れてもよいだろう。

 もう一つ考えられるのは,アンケートなどの事後のフィードバック手法を採ることだ。手順に慣れてくると,ピンポイントで「この手順は必要無い!」という部分が出てくることがある。それをアンケートで吸い上げる。「どの手順が不要と思うか」という設問を作り,手順書に沿って現場で管理を行っている人にアンケートに応じてもらう。

 もう一つ考えられるのは,監査である。監査というと身構える向きもあるだろうが,仰々しく行うのではなく,いつも運営している手順をそのまま実施してもらう。監査する立場の人間は黙って横で手順を見ている。どこかにぎこちなさがないかどうかアンテナを張り巡らしてチェックするのだ。横でじっと見ているだけで,どの手順に抵抗を感じているか,そのあたりの見極めがついてしまったら,それは余程見直してもらいたがっているものであるはずだ。

 さまざまな理由から現場の人に作成に参加してもらえないのであれば,現場と乖離しない手順にするためにはフォローがとても重要になってくる。手を変え,品を変え,とにかくフィードバックを得るように心がける必要があるだろう。

 あとは,前回のテーマでも説明した宣伝がやはり必要であろう。例えば,使用前と使用後をはっきり分からせるために,手順書を導入する前の管理方法と,手順書による管理方法の違いを明確にすればよいだろう。

 それには,リスク分析のプロセスとリスク分析結果,そしてその結果を受けてどのような判断と論拠で新たな管理手順を構築したか,という点についてできる限り詳細に説明する。つまり,いたずらに手順を複雑化したのではなく,理由と根拠を明らかにして賛同を得るわけだ。これが一番の宣伝になるはずだ。

 手順書を作って,現場の賛同を得て運営する。この点でも労を惜しんではならない。

本稿をまとめると

 最後にここまでの段取りをもう一度まとめてみよう。

(1)情報資産の洗い出しとプライオリティ付け

洗い出し:一般的に言って重要なものはだいたい決っている。オーダーメイドではなく,既製品の資産リストを利用して時間と手間を節約しよう。 既製品リスト:研究開発情報,ビジネスや活動のコア情報,経営系データ,個人情報,不祥事やスキャンダルや経営危機関連情報。

プライオリティ付け:既製品リストのうち,最もないがしろにされているものの優先順位が高い。「個人情報」が該当することが多いと思われる。ただし,「研究開発情報」などでも相応しい管理をされていない場合はそちらを優先する。

(2)リスク分析
IEC/ISO 17799を使って○×付け,ふさわしい管理をされているのかどうかをチェックする。

(3)ポリシー作成
セキュリティ・ポリシー,ガイドライン,手順書のうち,手順書だけを作るようにする。ポリシーは不要ではないものの,こちらも既製品で十分。

(4)ポリシーに従ったガイドライン,もしくは管理手順の作成
ガイドラインは特に必要でない。手順書はアクセス制御を意識して考える。ここは手抜きをしない方がよいだろう。手順書はできればレビューし、運営開始時以降に現場からのフィードバックを吸い上げることが重要だ。

園田 道夫 Michio Sonoda

筆者は情報処理推進機構(IPA)の脆弱性分析ラボ研究員,および日本ネットワークセキュリティ協会(JNSA)の研究員を務める。JNSAではハニーポットワーキンググループ,セキュリティスタジアム企画運営ワーキンググループのリーダーとして活動している。MicrosoftのSecurity MVP。現在セキュリティ夜話(http://www.asahi-net.or.jp/~vp5m-snd/sec/),極楽せきゅあ日記(http://d.hatena.ne.jp/sonodam/)にて連続的に読み物掲載中。