ソフトウェア・セキュリティ・プログラムのROIを評価する方法

Jul 31, 2021 / 1 min read

Table of Contents

回避できたリスクに着目する
ソフトウェアセキュリティのROIを評価するための4つの項目
ソフトウェアセキュリティの投資効果を高める

セキュリティカンファレンスでは、ソフトウェアセキュリティに投資すれば配当が得られるという宣伝が一般的です。

確かに、「投資」には配当がつきものです。銀行、株式、健康、教育などに資金、時間、労力を投じるのは投資を上回る見返りを期待しているからです。投資の見返りを意味するROI（return on investment）という頭字語が示すとおり、ありふれた概念です。

ところが、投資を行わなかった場合はどうなるかが必ずしも明確ではないため、ROIは測定が困難なことがあります。

ソフトウェアセキュリティの場合は、特にこのことが当てはまります。ソフトウェアにセキュリティを組み込めば組織がハッカーに侵害される可能性がはるかに低くくなるということについては、ほとんど議論の余地がありません。

しかし、実際に起こるかどうかわからない事態に対して果たして資金を投じることができるでしょうか？これまでに侵害された経験が10回あるかもしれません。あるいは1,000回かもしれません。一度もないかもしれません。それを確かめる方法はありません。

シノプシスソフトウェア・インテグリティ・グループの製品管理担当シニア・ディレクターであり、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%の効率向上が見られます」