アクセリアは、インターネットやサイバーセキュリティを専門とするスペシャリストが身近におりますので、知見にたけた専門家協力の元、お客様のご要望に沿ったソリューションのご提案も得意としております。また、弊社Webサイトでは、「サイバーレジリエンス」と題し専門家によるコラムも連載しております。
ECのミカタでも、コラムをご紹介させていただくことになりました。皆さまの効果的な対策につなげるためのヒントになれば幸いです。

●公開済みのコラム
　サイバーセキュリティに求められる バランス感覚
　https://ecnomikata.com/company_blog/15023/

　サイバーセキュリティが損なわれる原因を理解する(1)
　https://ecnomikata.com/company_blog/15410/

　サイバーセキュリティが損なわれる原因を理解する(2)
　https://ecnomikata.com/company_blog/15703/

アクセリア株式会社
https://www.accelia.net/

仕様や組み合わせ以外の脆弱性の心配がある

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

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

最新の脆弱性研究の動向を把握している開発者は少ない

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

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

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

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

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

ソフトウェア検査に予算と時間を割いても、脆弱性は完全には見つからない

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

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

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

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

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

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

コラムは以上となります。

ITエンジニア向け動画配信サービスcrash.academy

アクセリアが運営するITエンジニア向け動画配信サービスcrash.academyでは、著者の門林 雄基が講師をつとめる「標準サイバーセキュリティ」シリーズで、サイバーセキュリティの基礎概念を学ぶことができます。
この機会に是非講座を受講いただき、更なるレベルアップを実現していただければと存じます。
http://crash.academy/

著者

門林 雄基

アクセリア株式会社 主幹研究員
奈良先端科学技術大学院大学 情報科学研究科 教授
Adjunct Professor, Unitec Institute of Technology, New Zealand
日欧国際共同研究「EUNITYプロジェクト」日本側研究代表
WIDEプロジェクトボードメンバー