目先の脆弱性（バグ）の修正に追われるのはもう十分？ Black Hatで見た根本的な問題解決のアプローチ：セキュリティ・アディッショナルタイム（24）（2/4 ページ）

2018年8月にセキュリティカンファレンス「Black Hat USA 2018」が開催された。Googleによる基調講演や、「モグラたたきを終わらせ、根本的な原因を解決する」ための取り組みを実践した企業による講演の模様をお届けする。

[高橋睦美，＠IT]

全社で脆弱性に関する共通の言葉と標準を――BlackBerryの取り組み

　Black Hatのセッションといえば、新たな脆弱性に関する刺激的な内容のものが多いが、一方で、Tabriz氏が言うところの「モグラたたきを終わらせ、根本的な原因を解決する」ための取り組みを実践した企業の体験記も紹介された。

　一つはBlackBerryのケースだ。同社のChristine Gadsby氏は「Stop that Release, There's a Vulnerability!」と題するセッションで、「いかに会社全体でソフトウェアのセキュリティ品質を高めていくか」という取り組みを紹介した。

　BlackBerryというとモバイル機器など「ハードウェア」のイメージが強いが、その中ではさまざまなソフトウェアが動作している。複数の異なるOSがあり、機器によってさまざまなバージョンが動いているため、数え上げれば同時に100以上のバージョンが併存する状態だが、同社はそれらを全て管理し、トラックするようにしている。

　Gadsby氏らは2017年から社内で「Software Readiness Review Program」を推進し、セキュリティ面でのレビューを行うことでリリース時の品質担保に取り組んできた。そして、「リリース後に脆弱性を修正するよりも、リリース前、デプロイ前の段階で問題を見つけて修正しておく方がコスト効果が高い」という意識を会社の中に浸透させつつある。なぜなら、脆弱性が見つかってアップデートをリリースしても、「ユーザーはアップデートしたがらない」という事情もあるからだ。

　このプログラムを推進する中で大切にしていることは3つあるという。

　1つ目は、「サポートを得ること」。なぜセキュリティをレビューしなければいけないか、なぜリリースサイクルの中にセキュリティを取り入れるのかを説明し、特に上層部の理解も得て推進することが大切だという。

　2つ目は「脆弱性について定義すること」。セキュリティについて会話するとき、それぞれ異なる定義で議論していては話が進まない。「何が問題で、何を優先すべきか」「攻撃の糸口をどう減らすか」を決めるためにも、組織全体で脆弱性についての「共通言語」を持つべきだとした。

　そして最後は「標準を作ること」。各ソフトウェアのセキュリティに対する姿勢を理解するために、リスクのしきい値を定め、標準化されたテンプレートを持つことが大切だ。その上で初めて、各脆弱性をタグ付けして特定し、トレースすることができる。

　Gadsby氏は一例として、「Should We Ship It?」（SWSI）と呼ぶExcelで作成したテンプレートを紹介した。脆弱性のインパクトや悪用のしやすさ、収入に対する影響、メディア露出に伴うインパクトなどを計算できるテンプレートで、全社共通の基準で問題のインパクトを確認できる。

Gadsby氏が紹介した「Should We Ship It?」テンプレート

　「オープンソースソフトウェア（OSS）やサードパーティーにまたがる問題の特定、修正をどうするか」など課題は残る。しかし、こうした取り組みを通じて開発部門をサポートし、開発プロセスにセキュリティを組み込むことでリリースに含まれていた多くの脆弱性を発見できているのも事実であり、「確実に前進している」とGadsby氏は述べた。

　「セキュアなソフトウェアを作れば、負担が減り、より多くの収入につながる。だから、セキュアに作ろう」（Gadsby氏）