サイバーセキュリティが損なわれる原因(3)ー脆弱性検査をすれば脆弱性は完全に見つけることができるか

　今回のコラムでも、前回に引き続き、サイバーセキュリティが損なわれる原因について、あらためて解説してみたいと思います。
　前回のコラムでは、「出所不明のデータ」と「チェックの甘いプログラム」を組み合わせると脆弱になる、という例と、「重要情報」と「出所不明のデータ」をパソコン単体で混在して扱う、その組み合わせ方が脆弱なのだ、という話をしました。情報管理という言葉は、これまでは機密情報とそうでない情報を峻別して扱う、という意味で使われてきたと思いますが、これからは出所不明のファイルに潜むリスクを認識して、機密情報でなくても情報管理を徹底していきたいですね。

　ではソフトウェア脆弱性について、もう少し話を続けることにしましょう。前回までのコラムの内容をふまえて、仕様がしっかり練られたソフトウェアで、組み合わせに気をつければ脆弱性の心配はないのでしょうか？

　ソフト開発会社にとって不都合なことに、ほとんどの作りたてのソフトウェアにはバグが含まれています。そして、バグがあるソフトウェアというのは、バグを「ある方向に」発現させることができれば脆弱なソフトウェアになります。この「ある方向に」というところは技術的にとても深い領域であり、一見軽微に見えるバグを情報漏洩やサービス停止につながる深刻な脆弱性に転化させてしまう技術研究（脆弱性研究）が世界中で活発に行われています。残念ながら、このような脆弱性研究はセキュリティ専門家の領域だと考えられていて、ソフト開発会社で働いていても、最新の脆弱性研究の動向を把握している開発者は少ないのです。

　もちろん、ソフト開発者もテストをします。ユニットテスト、結合テスト、などの言葉は、ソフト開発を外注した方なら必ず耳にしたことがあるでしょう。しかし、ソフトの作り手が自分たちの目線で作ったテストには、必ずといっていいほど、作り手の想定に基づいて都合のいい仮定が置かれています。「このシステムの入力は画像ファイルである」「入力は５０文字以内である」「乱数は予測できない」等々。。本当でしょうか。

　残念ながら、セキュリティ専門家はこういった仮定を聞いただけで、脆弱性が発現しそうな条件をただちに思い浮かべることができます。
　理想的には、ソフト開発会社にもセキュリティに詳しい人がいて、こういった雑多な脆弱性を未然に潰しておくことが望ましいのですが、そのような真の意味での熟練開発者はまだまだ足りない状況です。

　理想を追うのはやめにして、ここは現実を直視しましょう。ソフト開発会社はソフトウェアの機能や性能を追求するのがどうやらミッションだとすると、ソフトウェアの安全性を追求する仕事は別の会社に頼まなければなりません。
　というわけで、ここ１０年ほど、脆弱性検査が専門業務としてひろく認知され、ビジネスとしても引っ張りだこの状況です。

　ソフト開発会社が「テストしました」というとき、それはユニットテストや結合テスト等を指しており、ソフトウェアの機能や性能が目的に合致していることを確かめているにすぎません。仕様書に「セキュリティテストまでちゃんとやれ」と書いていれば別ですが、費用や納期を考えると難しいことも多いでしょう。
　そもそも、ソフトウェアの作り手が万能であると信じるのは無理があるというものです。セキュリティも考えましたよ、と言われても鵜呑みにするのは危険です。前々回のコラムや前回のコラムを読んで、「チェックの厳しいプログラミング言語」を使って、「出所不明のデータ」の取り扱いに気をつけていれば、セキュリティについても「頑張った気になる」人もいますから。もちろんそれだけでは甚だ不十分です。
　餅は餅屋で、最新の脆弱性研究の成果をふまえた脆弱性検査をやってもらえるよう、セキュリティ専門家に依頼すべきでしょう。

　脆弱性は検査をすれば、ある程度は見つけることができます。しかし検査工程と言えば、遅れに遅れた開発と、待ちに待った運用の間に挟まれた、かなり時間的制約と予算的制約の大きな工程となることも少なくありません。限られた予算と時間の中で、どれほどの脆弱性を見つけることができるでしょうか。完全に見つけることは難しいと言えるでしょう。

　では検査工程にかなりの予算と時間を割けば、脆弱性は完全に見つかるのでしょうか。

　残念ながら脆弱性研究は日進月歩で、検査をしたあとで新たな種類の脆弱性が世に出ることもあります。というわけで「脆弱性を完全に潰しました」という報告は大抵の場合、眉唾ものです。せいぜい、「現時点で公に知られている脆弱性について検査したところ、検査条件のもとでは発見されませんでした」というのが妥当な説明でしょう。
　実際には、８００種類以上ある脆弱性すべての有無を周到にチェックするのはコストも時間もかかるので、一般的によく観測される脆弱性の主要２５分類だけチェックするとか、主要１０分類だけチェックする、といった乱暴な検査がまかり通っています。ビジネスなので、理想を追うのをやめにして、妥当なコストとスケジュールの範囲内で、それなりの検査をする、という妥協がまかり通っているんですね。
　こんな状況なので、検査漏れは必ずある、と考えて良いでしょう。

　発注者としては絶対に聞きたくない言葉です。しかし、現実を直視するのがビジネスなら、工期短縮や検査コスト削減のしわ寄せが検査漏れにつながる、という現実も直視すべきでしょう。

　出荷前検査で脆弱性が完全に見つかることはない、という前提に立つと、出荷後に脆弱性を報告してくれる善意のハッカーを味方につけることの重要性がよくわかると思います。最近、善意のハッカーが脆弱性を指摘してくれた場合に報奨金（バグ・バウンティ）を払う、という制度をつくる企業が増えてきましたが、これはそういうことなんですね。もちろん人任せではダメで、発注者であっても納品されたソフトの脆弱性を自分たちで見つけられるのが理想でしょう。

　今回はこれくらいにしておきましょう。次回のコラムからは、セキュリティ専門家でなくても知っておきたいソフトウェア以外の脆弱性について紹介したいと思います。

■関連ページ
【アクセリアのセキュリティ関連サービス】
　・WAFサービス（Scutum）
　・サイバーリスクに備える保険