標的型メールは見抜くことが難しい。は誤りです

セキュリティ担当者の仕事を楽にする秘訣は、自走する組織を作ることにあり!

不審なメールを受け取ったら、上長などにエスカレーション(報告)すること。というルールを設けている組織は多いことと思います。

しかし、そのルールに基づいて実際に報告が上がってきたとしても、上がってきた報告の全てについて、いつ、どんな時でも、タイムリーかつ適切に対応が取れるか?というと、また別の話です。

「ひとり情シス」ではありませんが、専任のセキュリティ担当者はおらず、有事の時は特定の担当者が本業と二足のわらじで対応を行わざるを得ないような組織だと、何でもかんでも報告が上がってくるような状況は「さすがに耐えられない」かもしれません。

報告を受けること自体は簡単ですが、報告を受けたら受けたで、

事実の確認、
影響範囲の調査、
必要な対応や対策の検討と実施

などなど、何らかのアクションを取らざるをえなくなります。その業務量が膨大なものになれば、いくら担当者がタフな人だったとしても、いつまでも続けられるものではないでしょう。

報告を上げてもらうこと自体は大事なことですが、報告が上がってきたら上がってきたで、それをきちんと消化できる仕組みと体制がなければ、特定の担当者(つまりあなた)にしわ寄せが行くだけ。

それゆえに、報告を上げてもらうよりも、報告が上がってこずに済むような仕組みを作ること、例えば、高い確率でマルウェアをブロックしてくれるセキュリティ対策機器を導入したり、セキュリティ監視をアウトソーシングしたりといったことについて考えるのが第一の関心事。という担当者の方もいらっしゃるかと思います。

また、従業員は自分の業務に専念できるようにすることこそ理想なのだから、セキュリティなんて気にしなくても良いようにするべき。だから、全てシステムで対処する事こそ、あるべき姿だ。と主張する方もいます。

しかし、そうしたことができるのは予算が潤沢な組織だけ。人も予算もない組織は一体どうしたらよいのでしょうか?

報告は上げてもらうようにする。それも、質の高い形で。

やみくもに「報告を上げろ」では、上がってくる報告は玉石混交となるのは目に見えています。

「ウィルスメールを開いてしまったみたいなんですが、どうすればいいでしょうか・・・」

なんていうのは、ありがちな報告ですが、セキュリティ担当者にとっては、勘弁して欲しい報告の形の一つです。

なぜなら、開いてしまったのが本当にウィルスなのかどうかわからないし、仮にウィルスだったとしても、どれほどの被害をもたらすものなのか全くわからないからです。

報告を上げてくれた従業員にヒアリングしても、具体的に何を開いてしまったのか?要領を得ない答えでよくわからない、さらに、開いてしまったファイルが残っているかどうか尋ねると、まずいと思ったので削除してしまった。と返ってきて、開いてしまったファイルそのもの(検体)を確認することもできない。しかし、「ウィルスメールを開いてしまったみたい」と報告してきている以上、影響範囲を確認するためにも、何を開いてしまったのか?を突き止めないといけない。

そのような状況から取られることになる手間と時間、そして時には費用はかなりのものになりますが、その結果、実際に開いたのはウィルスメールではなく、ただのスパムメールで、何の影響も発生していなかった。となれば、会社的には結果オーライですが、対応に関わり、時間と手間が無駄に取られてしまっただけ。となった担当者にしてみれば「勘弁してくれよ・・・」というのが本音でしょう。

セキュリティ担当者としてはそれも仕事のうち、何もなかった事が一番良いのだから、そんなことをいちいち気にしていたら始まらない。という意見もあるでしょうが、毎回毎回そんなことばかりがしょっちゅう続けば、心が折れてしまうようなことになったとしても不思議ではないと思います。

でも、報告が全く上がってこなければ、現場のパソコンがウィルスに感染していたとしても気づかないし、社内に注意喚起を出すといったこともできません。

社内で起きていることの情報は的確に掴みたい。でも、手間と時間だけが無駄に取られてしまうような報告は勘弁して欲しい。

だから、報告は「とにかく上げてもらう」ではなく、「質の高い形でどんどん上げてもらう」ようにするが理想の形と言えます。

質の高い報告を上げてもらうには、「管理」と「コントロール」という考え方から抜け出すこと

セキュリティ対策と言うと、あれを守れ、これを守れ、これこれを報告しろ、など、被害を出さないために「管理」する、決めたことを守らせるために社員を「コントロール」する、といったやり方をしてしまいがちです。

「管理」と「コントロール」は指示を出す側からすると楽な方法ですが、指示を出される側からすると嫌気を感じるものです。当然、そこに信頼関係など生まれようもありません。

表面上は会社側の出した指示に従っていても、信頼関係は築かれていないので、イザという時にセキュリティ担当者が苦労していても、他の社員は対岸の火事のようにしか思わず、被害を出してしまった社員に対しては「おまえのせいで・・・」と白い目を向けるようなことが起きたりします。

そういった状況では、報告を受けるセキュリティ担当者がどれだけ苦労する事になるか?なんてことは全く考えず、とにかく報告を上げることが目的となって、大事なことが抜け落ちている報告が上がってきたり、大事な情報が隠されてしまうといったことが起こりえます。

実際、あなたもそんな経験をした、また、そんな状況になっているのを目にしたことはないでしょうか?

現場から質の高い報告を上げてもらうには、現場の社員一人一人が、報告を受ける担当者、そして、その後の対応を取ることになる他の社員のことを考え、彼らが動きやすいよう、自分ができることを行い、必要になるだろう情報を報告として上げることこそ、自分がするべきことだ。と、常に意識してもらえる環境を作ることです。

そして、それにはお互いの間に信頼関係を築くことが何よりも欠かせません。

セキュリティ事故は現場で起きるものであるからこそ、現場にいる各従業員それぞれが大切な役割を担っていること、また、各従業員の対応が重要であることを理解してもらい、セキュリティ事故を起こさないために、自分には何ができるか?そして、自分はどうすべきか?を自ら考えて行動できるよう、環境を整え、そうした雰囲気を醸成し、社内に信頼関係の輪を広げることこそ、セキュリティ担当者が意識して実践すべきことであると考えます。

言うは易し、行うは難し、だけれど、先達から学べることは沢山ある

セキュリティ絡みの事故が起きた時、現場の社員が問題の切り分けと適切な処置を行ってくれていて、報告が上がってきた時には各部署と連携してスムーズな対処ができるような状況になっていれば、セキュリティ担当者の負担もだいぶ軽減されますよね。

現場からは「ウィルスメールを開いちゃったみたいなんですけどぉ~」なんて報告が上がってくるのみで、事実の確認から何からを全てセキュリティ担当者がやらなければならなくなる状況に比べたら雲泥の差です。

しかし、組織の現状をそんな理想に近づけたいと思ってはいても、言うは易し、行うは難しで、理想と現実は違う。そんなこと実際にはできやしない。そう思っている方も少なくないと思います。

そこで、一見、不可能と思われるようなことを実際に現実のものにした実例について書かれた一冊の本をご紹介します。
それは、「まんが ハーバードが絶賛した 新幹線清掃チームのやる気革命」(宝島社)という、ストーリー漫画型の読みやすいビジネス書です。

本のタイトルだけを見ると、

新幹線清掃チームのやる気とセキュリティ?一体何の関係があるの?

と思う方もいらっしゃるかもしれません。確かに、清掃業とセキュリティでは、全く違う業種ですが、あらゆる仕事はチームワークであること、そして、言われたことだけしかしない社員ではなく、一人一人が自ら考え、主体的に動くことができる社員がいる組織こそが成長していく組織である。ということを考えれば、根っことなる部分は「人」であり、人を動かす組織を作るために必要となる根幹は、業種に寄らず共通です。

新幹線の清掃なんて場末の仕事、「汚い、きつい、危険」の3Kが揃った現場で、ただ黙々と言われたことをこなすだけだった清掃員の仕事を、ハーバード大から絶賛され、「セブン・ミニッツ・ミラクル」と呼ばれるほどに生まれ変わらせた実例には、セキュリティ担当者にとっても参考になること、また、自社でも見習いたいと思えるようなことが幾つも含まれています。

セキュリティという技術や知識にだけ目を向けてしまうと、良い実例はなかなか無かったりしますが、何事も「人」によって為されることであることに着目すれば、参考となるものは幾らでもあります。

製造業におけるQC活動
成果を上げる営業チーム作り
デスマーチに陥らないプロジェクトマネジメント手法
お客様から支持されるお店作り

などなど、先達が取り組み、残してきた知恵や産み出した成功例は世の中には沢山あります。そうした先達の知恵を拝借し、組織に取り入れていけば、小さくとも成せることは必ずあるはずです。

何でも自分でやろうとしたら、あっという間に限界に達してしまいますが、社員一人一人が、お互いに信頼して協力し合える関係ができていれば、自分だけでは到底できないと思えるようなこともできるようになります。不可能と思えるようなことが可能になり、そこに奇跡が生まれるのです。

そしてそれは、あなたにもできるかもしれない事。次のミラクルを、あなたの手で産み出してみませんか?

(Visited 58 times, 11 visits today)
←前の記事へ(
→次の記事へ(