「ない」ではなく「つくる」～情報セキュリティの「答え」についてのお話～
情報セキュリティを仕事としていると、「情報セキュリティには答えがない」という表現を時々使うことがあります。ということで、今回はこの「答え」についてのお話。
＜欲しがりな経営者＞
「情報セキュリティに答えがない」というのと同じような意味合いなのですが、
・情報セキュリティには万能薬がない。
・情報セキュリティには「魔法の杖」や「銀の弾丸」はない。
という表現もあります。
これはこれで合っていて、必要となるセキュリティ対策は、それぞれの組織の状況によって変わるので、「これがあれば大丈夫」という「唯一の解答」はないということなのです。
まあ、それでも過去には（今でも？）、
・このセキュリティ製品を入れれば、情報セキュリティはOK！
・うちの会社に任せてもらえればセキュリティは大丈夫！
みたいな広告をしている会社が多かったような気がします。
セキュリティ業界がこんなこと言っていたらいけないので、最近は少なくなっていると思うのですが。
とはいえ、セキュリティ対策をしたい組織というか経営者しては答えが欲しい、というか答えが必要なわけです。
経営者としては、人とお金をかけてセキュリティ対策を導入しなくてはいけないわけで、何をどのくらい？という「答え」がないと、いけないわけですから。
そのため、経営者としては何とかして答えを見つける、というか答えを「つくる」ということをしなくてはいけないのです。
＜公的な「ガイドライン」の存在＞
さて、そんな経営者の味方というか、「とりあえず、このセキュリティ対策やっておいて」というような感じの「公的（標準的？）なガイドライン」がいくつかあります。
PCI DSS（クレジットカード業界向け、セキュリティ基準）
FISCシステム安全対策基準（金融機関向けのシステムの基準）
IPA中小企業の情報セキュリティ対策ガイドライン
などなど。
まあ、これらのガイドラインが自分の会社にとっての「答え」なのか？は別に考えるとして、これらのガイドラインは、「答え」の一つ（？）としてその発行母体の組織が発行したわけです。
では、これらのガイドラインはどうやって出来たのでしょうか？
＜必要なのは「合意」＞
ガイドラインの多くがそうなのですが、公的なガイドラインを作成する場合、
ガイドライン案（ドラフト）を作る人
ガイドライン案（ドラフト）を審議/レビューする人
ガイドライン案（ドラフト）を最終的にガイドラインとして承認する人
が関わっています。
で、主に３は形式的な手続きになる場合も多いので、実際に作っていると言えるのは、１と２の人になります。
ということで、これらのガイドラインは１、２、３の人が最終的に「この内容でよい」と「合意」したために、ガイドラインになっているわけです。
このことは実は組織における情報セキュリティでも同じで、最終的に関係者間で「合意」した内容が情報セキュリティの「答え」なのです。
では、どうやったら関係者間で合意を取れるのか？ということが重要になります。
＜合意を取るための「論理性」＞
ガイドラインのほうでいえば、１の人が作ったガイドライン案（ドラフト）の内容について２の人が納得すれば、「合意」に繋がります。
では、２の人はどうすれば納得するか？ということですが、２の人も「なんとなくだけど、これでOK」とはいかないわけで（多分）、きちんと納得する「理由」が必要になります。その理由は、ガイドラインの内容について、「こういう理由だからこの内容になる」という説明ができるということが必要になるのです。
つまり、ガイドラインの内容に「理由」という論理性が必要になるのであり、個別の会社における「答え」においても、その答えを導き出した理由という論理が重要になる。
突き詰めれば、セキュリティ対策を行う理由について納得のできる説明を試行錯誤して作っていくことが、会社での情報セキュリティの答えを「つくる」ことになるのです。