ソフトウェア・セキュリティ・プログラムのROIを評価する方法
侵害の回避を目標にしてしまうと、ソフトウェア・セキュリティ・プログラムのROIを算出することは困難です。この記事では、アプリケーション・セキュリティ・プログラムの投資効果（ROI）を高めるための着眼点をご紹介します。
セキュリティ・カンファレンスでは、ソフトウェア・セキュリティに投資すれば配当が得られるという宣伝が一般的です。
確かに、「投資」には配当がつきものです。銀行、株式、健康、教育などに資金、時間、労力を投じるのは投資を上回る見返りを期待しているからです。投資の見返りを意味するROI（return on investment）という頭字語が示すとおり、ありふれた概念です。
ところが、投資を行わなかった場合はどうなるかが必ずしも明確ではないため、ROIは測定が困難なことがあります。
ソフトウェア・セキュリティの場合は、特にこのことが当てはまります。ソフトウェアにセキュリティを組み込めば組織がハッカーに侵害される可能性がはるかに低くくなるということについては、ほとんど議論の余地がありません。
しかし、実際に起こるかどうかわからない事態に対して果たして資金を投じることができるでしょうか？ これまでに侵害された経験が10回あるかもしれません。あるいは1,000回かもしれません。一度もないかもしれません。それを確かめる方法はありません。
シノプシス・ソフトウェア・インテグリティ・グループの製品管理担当シニア・ディレクターであり、Synopsys Intelligent Orchestration開発リーダーでもあるMeera Raoは、オートメーション、ツール、プロセス、コンサルティングに多大な投資をしたものの、費やした時間とコストの見返りに何のメリットが得られたかわからない、という顧客の声をよく耳にすると言います。
回避されたリスクに着目する
そんなときは、「自分が回避できたものは何か？」という表現で自問してみる方が適切かもしれません。正確なROIを定量的に計算することは無理かもしれませんが、ソフトウェア・セキュリティに投資しないことによるリスクは明白です。ハッカーがソフトウェアの脆弱性を悪用して個人、組織、公益事業、政府に大きな被害をもたらす可能性がある災難が見出しに取り上げられています。
そのため、Raoは、構築するソフトウェアのセキュリティ強化は不当なコストセンターではなく、建物を物理的に警備することと同等の価値があるという事実に着目することを勧めています。コスト効率、スピード、効果が向上すれば、投資価値（ROI）は高くなります。
ソフトウェア・セキュリティのROIを評価するための4つの項目
Raoによると、開発チームが遅滞なくソフトウェアにセキュリティを組み込むために戦略、人、プロセス、技術という「4つのバケット」を連携させることで、ソフトウェア・セキュリティの投資効果（ROI）が実現します。
1. 戦略
Raoは、コードが実行される前、つまり、欠陥への対処がはるかに容易で修正コストが比較的低いソフトウェア開発ライフサイクル（SDLC）の初期段階で、静的解析などの自動セキュリティ・テストを用いてコードをテストすることにより、高いROIが実現すると指摘します。
「何年も前から、ペネトレーション・テストが終わった後、あるいは当社による手動コード・レビューが完了した後、SDLCの終盤になってからこうした欠陥が見つかっているということを[顧客に]指摘しています。これは12年前の話ですが、4〜6週間の時間がかかりました」
現在では、開発者がコードを作成または組み立てる、より早い段階で、テストを実行しています。「これにより修正コストが低減します。後工程での修正は、早い段階での修正の6〜7倍のコストがかかります」とRaoは言います。
もう一つの戦略として、自動テスト・ツールを構成し、重大な欠陥またはビルドするアプリケーションに直接関連する欠陥のみにフラグを設定する方法があります。「ツールを使うことで、非常に多くの欠陥が見つかります」とRaoは言います。「そのすべてを修正する必要があるでしょうか？ 答えはノーです」
「ツールをパイプラインで自動化すれば、すべての欠陥に優先順位を付けることができます。欠陥の発見と修正のバランスが取れて、無駄な作業が省けるからです」
2. 人
ソフトウェア・セキュリティのROI向上のもう一つの要素は、開発チーム内に1人または2人の「セキュリティ・チャンピオン（推進リーダー）」を育成し、チームのパフォーマンスを高めることです。これにより、正式なセキュリティ・チーム（SSG：ソフトウェア・セキュリティ・グループ）が開発チームに直接関与する必要性が少なくなります。しかも意見の対立が減ります。
「セキュリティ・チャンピオンはトリアージのための時間の削減に貢献します。SSGがすべての結果をトリアージする必要があるとすれば、年に3〜4回客先に出向いて3〜4週間そこに滞在し、すべての結果をトリアージして基準を作成する必要があります。しかし、各グループに1人の開発者がセキュリティ・チャンピオンとして組み込まれていれば、その人にトリアージを任せることができます」とRaoは言います。
また、開発者は外部チームのメンバーよりも自分のチームのメンバーとの信頼関係が強いので、コミュニケーションがスムーズになり、組織にROIがもたらされるいうこともRaoは指摘しています。
3. プロセス
「ポリシーをコード化」して設定することで、ルール、品質ゲート、その他のポリシーをテストとともに自動化できます。
最初にセキュリティ・テスト・ツールを自動化します。「テクノロジー、言語、フレームワークについての知識があれば、各ツールに対応してすべてのパイプラインを適切に最適化できます」とRaoは言います。
次に、ルールポリシーを自動化します。「以前は手動で意思決定を行っていたため、重大な脆弱性の修正に10日かかったり、90日ごとにペネトレーション・テストを行う必要があったりしましたが、現在ではすべて自動化してパイプラインに投入することができます」
最後にゲートを自動化します。「私たちが相談を受けているすべての組織は、質の高いゲートを備え、現在ではパイプラインにセキュリティ・ゲートを設けています。組織の意思決定に従ってゲートを設定し、ビルドは分割しないで、重大な脆弱性が見つかった場合に通知のみ行うということが必要です。」
コード化したポリシーの使用例として、金融業界の顧客が、アップデートや新機能をリリースした競合企業に顧客を奪われないために競って同様の機能を製造する場合が挙げられます。
「お客様には、そのためのプロジェクトでXSSやSQLインジェクションなどの重大な脆弱性が見つかり次第、当社に通知するとともに、本番環境への移行も進めたいという意向がありました。そこで、ファイアウォール・ルールの更新などのコントロールを追加するという話が出ました。そのため、パイプライン内の自動化されたポリシーで、重大な脆弱性が見つかるたびにファイアウォール・チームにEメール通知が送信されるようにしました」とRaoは言います。
4. テクノロジ
Raoは、すべてのテストとポリシーの実装結果を追跡することで効率化が可能なことがわかると言います。その鍵は指標にあるとも言います。
「開発段階ですべての問題を早期に修正し、脆弱性が減少傾向にあるかどうかを把握する必要があります」 とRaoは言います。
トレンドラインが適切な方向を向いていないことを示す指標がある場合は、「微調整します。早いうちに失敗し、手戻りして、微調整します。静的解析で設定したルールが多過ぎた可能性があります」
指標を選別して使用することが重要です。微調整があまりに多方向に及ぶと、テスト・ツールからの過剰な通知で開発者の気が挫かれる場合と同様のことが起こる可能性があります。
「以前は、開発チームにすべての指標のダンプを提供していましたが、現在は、見つかった問題をすべて通知することは変わりませんが、すべてを一遍に通知しないようにしています」
また、ペネトレーション・テストや手動コード・レビューなどの手動アクティビティを用いて指標を1つのダッシュボードにまとめて表示すれば、作業が簡素化されます。
「例えば、指標ごとにファイルの保存形式がPDF、Jira、SonarQubeなど異なる場合、資料として経営幹部に見せるために毎月担当者がすべての指標を収集しなければなりません」
「最初はダッシュボードの内容を判断するのに時間がかかりますが、そのうち測定して微調整することができるようになります。最初の頃と見え方が変わらない場合は、まだまだトレーニングが必要かもしれません」
最初のうちはこのような指標分析の設定に、場合によっては1モジュールに60時間程度の時間がかかる可能性があるものの、マチュリティ・アクション・プラン（MAP）を活用すれば、その時間を大幅に短縮できると、Raoは指摘しています。「MAPを作成し、パイロットを実行するには2〜3週間かかる可能性があります」
「でも、言語、ツール、テクノロジなどの知識があれば、パイロットが完成した後、導入にかかる時間はアプリケーションごとに2～3時間程度です。静的解析では効率が900%向上し、動的解析では400%の効率向上が見られます」
ソフトウェア・セキュリティの投資効果を高める
総体的にROIへの「反映が迅速化し、測定可能性と修正の迅速化を確実にし、これらの手動による意思決定を合わせてプロセスが明確に定義されます」
サイバー攻撃を防ぐことでどれだけのコストと頭痛の種を削減できたかを知るすべはたぶんないでしょう。
しかし本当のところ、知りたいと思う人もいないでしょう。
