No170 手順書作成は効果的なセキュリティ事故対策（２）

のっけから余談となりますが、筆者はiPhoneを使っています。

先日、ちょっとしたことからiPhoneの初期化が必要となり、ＰＣ
（パソコン）でバックアップをとり、初期化を行いました。

ここまでは問題なく進み、最後にリストアをしようとしたところ、
リストアができないのです。
「そのiPhoneではまだバックアップを作ってないよ」という冷たい
メッセージが。

かなりパニックになりながら調べたところ、どうやらバックアップ
が途中で失敗しており、正しく作成できていなかったことが判明。
途中で失敗したことも原因は筆者にあったので、仕方がありません。

連絡先電話番号、スケジュール、ブックマークなど復元が面倒な
項目も多く、後悔の念がつのります。そんなとき、カレンダーを
見るとちゃんと来週以降のスケジュールが入っています。

そういえば、iPhoneならiCloudというクラウドサービスで自動
バックアップしていることを思い出し、そちらを確認したところ
２週間ほど古いものながら、完全なバックアップがありました！

無事、２週間前の状態に戻すことができ、ホッとしました。

さんざんエラそうに「バックアップは大切です」などと書きながら
こんなことでは褒められたものではありませんが、改めてバック
アップの大切さとありがたさを感じた次第です。

皆様もこんなことにならないようにお気を付けください。

さて、今回はセキュリティ事故対策の手順書を作り方についての
解説を続けましょう。

1. セキュリティ事故対策の手順書に必要な項目

前回のおさらいをしておきましょう。

セキュリティ事故が起きた時には冷静な行動が取れず、思いがけ
ない行動をとってしまうことがよくあります。

そういった行動の抑制には手順書が有効です。

手順書は全メンバが理解できるように、平易かつ具体的に記述する
ことが大切です。

前回から「メールの添付ファイルを誤って開いた場合」を例として
手順書の作成方法を解説しています。
ここでは、以下の構成で手順書を作っていきます。

Ａ-1：（対象となる）ＰＣのネットワークからの切り離し
Ａ-2：通報
Ｂ：組織内への周知
Ｃ：情報収集と判断
Ｄ：対応をする
Ｅ：社内報告（事後作業）
Ｆ：再発予防策の検討と実施（事後作業）

最初のＡ－１については前回に解説しましたので、今回はＡ－２に
ついて解説しましょう。

2. Ａ-2：通報

怪しいメールの添付ファイルを誤って開くようなセキュリティ事故
は、セキュリティ担当者が知りえない時と場所で発生します。

これに限りません。ノートＰＣの盗難、作業用ＰＣの動作が遅い、
といった事象も当事者からの連絡／報告がなければ知りようがあり
ません。

セキュリティ事故は当事者からの報告を受けるところから始まり
ます。

重要なのはセキュリティ担当者がタイムリーに連絡を受けること
です。

何を当たり前のことを、と思われるかも知れませんが意外に難しい
ことなのです。

3. 通報がうまくいかないケース

連絡がうまく届かないケースはいろいろ考えられます。

例１：
　新人のＡさんが作業中に間違って添付ファイルを開いてしまった。
　こういう時はＸさんに連絡することになっている。
　が、Ｘさんはとてもコワい人だという話なので、こんなことを
　言えば怒られると思い、また実際に何も起きていないので、
　黙っていても問題ないだろうと報告しないことにした。

例２：
　Ａさんが黙っていたことでＸさんにめちゃくちゃ怒られていた
　のを見ていた新人のＢさん。やはり間違って添付ファイルを
　開いてしまった。
　Ａさんの二の舞は嫌なので、ＢさんはＸさんに連絡をしようと
　したが内線番号がわからない。
　じゃあ、本人を探そうと社内をうろついたが、実はＸさんの席
　は所在地の違う支店にあることがわかってガッカリ。
　結局、電話連絡するまで２時間かかり、やっぱりＸさんに
　怒られる結果に。

例３
　連絡先を知らないメンバがいることを知ったＸさん。
　セキュリティ事故発生時の手順書にＸさんの電話番号を書いた
　上で、その手順書を全部署に配布した。
　今度は中堅社員のＣさんが添付ファイルを開いてしまった。
　Ｘさんの電話番号を知るために手順書を探したが、休暇中の
　課長のキャビネット（鍵付き）にあることがわかり、ガッカリ。
　結局総務に電話して番号を教えてもらった。

例４：
　今度は新人のＤさんが、添付ファイルを開いてしまった。
　幸い、手順書が手元にあったので、すぐにＸさんに電話でき
　たのはよかったが、出張で結局連絡がつかなかった。

例５：
　出張中でも問答無用で呼び出せ！と叱られたＤさんを見ていた
　新人のＥさん。これまた添付ファイルを開いてしまった。
　Ｘさんに連絡しようとしたが、病欠だった。
　自宅の電話番号を教えてもらって電話したが、当人もかなり熱が
　ある様子で話をしても要領を得ない。
　Ｘさんも手元に手順書はないようで、その場しのぎな対応に終始
　してしまった。

例６：
　Ｅさんからの連絡を受けても手順書通りの行動がとれなかったＸ
　さん。自分ひとりですべてを行うのは難しいことを自覚し、連絡
　がつかない時のためにＹさんを代役に任命した。
　Ｘさん不在の時にベテランのＦさんが「間違って添付ファイルを
　開いた」と連絡をしてきた。
　たまたま代役のＹさんが席をはずしていたので、電話口のＧさん
　に伝言を依頼した。が、ＧさんはＹさんに伝言を伝え忘れた。

例７：
　Ｇさんが伝言を伝え忘れたことを重く見たＸさんは今後は報告を
　メールでするように周知した。
　ベテランのＨさんが添付ファイルを開いてしまい、Ｘさんに
　メールを送った。しかしメールアドレスが間違っていてエラー
　メールが返ってきた。年配のＨさんはエラーメールの意味がわか
　らず放置してしまった。

いかがでしょうか。
ここまで次々と不幸なパターンに見舞われることはないでしょうが、
どれもありがちな話です。

4. 手順書には日常的にありうるパターンがあれば良い

このように電話連絡ひとつでも、確実に行うのは意外に難しいもの
です。手順書には考えられるパターンをなるべく盛り込みましょう。

とはいえ、あまりに現実離れしたものを入れても意味がありません。
（宇宙人襲来とか日本沈没といった）あらゆる可能性を網羅する
ことなどできません。そんなことに時間を費やすのは無駄ですから。

前回も書いたように、手順書にどこまで書くのかは結構悩ましい
問題です。

あまり「ひょっとしたら」などと考え込まないでください。
よく起きるパターンが含まれていれば、初版としては十分です。
初版は「最初の第一歩」なのです。ショボくても手順書さえあれば
改善はできるのですから。

この場合なら、手順書に盛り込むべきは以下のような内容です。

1)意図しない添付ファイルを開いてしまった場合は、セキュリティ
　担当者に報告する。
2)意図しない添付ファイルを開いた後に何も起きなかった（ように
　見える）場合も報告を必須とする。
3)報告は原則として電話を用いて、セキュリティ担当者に報告する。
4)セキュリティ担当者が不在（出張や休暇を含む）の場合は副担当
　またはセキュリティ責任者を呼び出して報告する。

また、関連する事項として以下のような内容にも触れておくほうが
よいでしょう。
1)報告をした者はＰＣに手を触れない（勝手にさわらない）こと。
2)報告した担当者が叱責を受けることはない。
3)セキュリティ担当者の連絡先を掲示する方法を決めておく。
　・事務室に張り出す、
　・全員メールを送る、
　・回覧で周知するなど

なお、セキュリティ担当者が全員不在の場合の対策については、
組織の事情によって様々に異なります。
例えば、メンバ全員にPHS(病院内などで使われる簡易携帯電話）
を支給していれば「必ず担当者が出る」前提で手順書を書いても
良いでしょう。
逆にセキュリティ担当者は移動が多く、メンバ全員がメールに
親しんでいるなら、メール報告が良いかもしれません。

前回に解説した
「Ａ-1：ＰＣのネットワークからの切り離し」と、今回の「Ａ-2：
通報」の内容は全員が対応できる手順とする必要があります。

今回も１項目の解説だけで終わってしまいました。

次回は「Ｂ：判断をする」以降の作業手順書の作り方について
解説します。
ここからはセキュリティ担当者が主担当となって行う作業が多く
なりますので、また視点が異なってきます。

次回もお楽しみに。

※お知らせ※
　次週の8/10はお休みとさせていただきます。
　本メルマガの次号(171号)は2020/8/17に配信いたします。

このNoteは私が主宰するメルマガ「がんばりすぎないセキュリティ」からの転載です。
誰もが気になるセキュリティに関連するトピックを毎週月曜日の早朝に配信しています。
無料ですので、是非ご登録ください。
https://www.mag2.com/m/0001678731.html