記ドコモ口座に端を発したキャッシュレス決済サービス問題キャッシュレス決済サービスに関連した不正引き出し事件が世間を騒がせています。最初はドコモ口座の問題として扱われましたが、連携している銀行側の問題に視点が移り、各種スマホ決済サービスも巻き込んだ大きな問題に発展しています。銀行口座番号と暗証番号がわかれば犯罪が成立してしまう場合があること、SMS認証をしていても銀行の口座を持っている本人を認証する仕組みになっていないことなど、脆弱な箇所があったようです。これらの仕組みを導入するうえでどのようなセキュリティ対策の検討が行われたのかはわからず、この件での深掘りはしませんが、一般的に企業でITを導入する際のセキュリティ検討プロセスには、疑問を感じることが多くあります。本投稿では上記事件とは別として、IT導入時によくあるセキュリティ検討の問題に触れてみたいと思います。一般的に業務システムや情報系システムなどの導入では、非機能要件定義の中でセキュリティについての要件を定義します。以下のようなテーマについて、システムに必要なセキュリティ対策を検討します。ユーザー企業側の立場で、導入ベンダーが主導する非機能要件定義の場に参加することがよくあるのですが、ほとんどの場合、「パスワードポリシーはどうしますか?」、「データを暗号化できますが、どうしますか?」、「この役割にこの権限を割り当てますが、いいですか?」など、単発の確認の連続になります。このように聞かれても、適切に判断することは困難です。どのくらいガチガチに設定すべきなのか、ここを緩めたら何がまずくなるのか、などがわからずにとりあえず個別個別で決めてしまうと、結果的にデコボコの激しい、不適切なセキュリティ対策になってしまいます。理想的なセキュリティ要件定義の流れ足りないのは、リスクという観点です。リスクという観点でのセキュリティ対策の大まかな流れを表現すると、以下のようになります。このシステムで扱う「守るべき情報」を特定します。リスクを明確化する上記の「守るべき情報」におけるリスクを、様々な角度から洗い出し、整理します。リスクの特性として、その情報における「脅威」と、管理上の問題などによる「脆弱性」によって「発生の可能性」が導き出され、その情報の重要性などによって「発生した際の影響度」が導き出されます。リスクに対応する上記で整理された各リスクに対し、「発生の可能性を抑える」、「発生した際の影響度を抑える」、「リスクを受容する」、「その情報の取り扱いを中止する」などの対策を検討します。この流れの3で、ようやく「認証をどのような方法で行うべきか?」、「データを暗号化すべきか?」などの対策手段が見えてきます。そのため、要件定義の場でいきなりこれらのことを聞かれても、リスクを明確化できていないため、答えるのが困難なのです。問題は、「上記1~3を誰が行うべきか?」です。~「シナリオ」の活用~」でも書きましたが、導入ベンダーとしてのゴールは「製品の導入」です。導入する製品の数々の機能から逆算し、最終的に細かい設定項目を明確にするための設計を行い、その設計につなげるための要件定義を行います。そこにはリスクという発想は少なく、導入するための設計、導入するための要件定義になってしまいます。上記のようなリスク観点での検討を抜いてセキュリティ要件を定義してしまうと、むやみに多重防御が厚い箇所と、対策が不十分な箇所が生まれてしまい、適切とは言えない環境になってしまいます。導入ベンダー側でリスク観点での検討が行われないことを想定し、ユーザー企業としてこのプロセスを確立し、いつでも実施できるようにしておくことをお勧めします。