セキュリティーがプログラマーの責任になる日
（2008/12/25公開）

プロセスを変える

　開発プロセスでセキュリティーを実装しようとする時、多くの組織が遭遇する難しさは、単なる特殊機能のように一足飛びにセキュリティーを追加するわけにはいかないことです。セキュリティーは、プログラミングのサイクル全体に埋め込まなくてはなりません。

　「セキュリティーとは徐々に表れる特性です。つまり、組み立てラインのように、誰かがボルト付けするようにセキュリティーを組み込むものではありません」こう語るのは、コード分析ツールのメーカー、フォーティファイセキュリティー社の主任科学者ブライアン・チェス氏です。「ソフトウエアを安全にするには、開発に含まれるあらゆるパスやプロセスに注目する必要があります」

　それには、多量の時間が余分にかかります。そして、ほぼ確実に、プログラマーにそんな時間はありません。セキュリティーの開発原理をわきまえている上級コーダーであっても、コードの補強より機能や締め切りを重要視する上司にせかされたら、そんな原理はとりあえず無視するはずです。

　「アジャイル開発という理念の下では、短時間でのリリース、頻繁なリリースが目標です。先行的にセキュリティーを構築しようという理念とは相いれません」とグロスマン氏は言います。

　マイクロソフト社のハワード氏の意見では、今後、組織がプログラマーに安全なライティングをさせようと考えるなら、まず企業の経営者層でそのようなプロセスを優先し、徐々に原理を下層へと降ろしていくしか方法はありません。これは経験に基づいた意見です。ハワード氏はマイクロソフト社の社内用セキュリティー開発ライフサイクル（SDL）を開発し、それを全社的に確立する上で大きな働きをしました。SDLは、「決してインプットを信用しない」「インプットを信用しないことを、ファズテストで立証する」「脅威モデリングを実行する」という3大原則を核としています。

　これらの原則を確立するプロジェクトには、何年も要しました。最初は多くのデベロッパーでサポートする必要がありましたが、プログラマーが慣習を日常業務として定着させるにつれて、最終的に状況が変化したとハワード氏は言います。

　「スタッフが急成長しました。セキュリティーが仕事の一部であること、やらなくてはならないことだと認識するようになりました。私たちのほうから開発グループをチェックして、作業が正しく実行されているか確認する必要は、もうありません」

　マイクロソフトはSDLの威力を強く確信しています。そのため、ハワード氏の上司としてセキュリティーエンジニアリング戦略上級ディレクターを務めるスティーブ・リプナー氏とSDLのチームメンバーは、先ごろ、マイクロソフト社が社内で使用している脅威モデリングツールを業界に提供すると発表しました。

事業上のメリット

　セキュアコーディングを目標とした取り組みの成果は、簡単に数値で示せない場合もあるものの、収益に有意な効果を上げることができます。ハワード氏によれば「正確な数字は持っていませんが、テスト費用が以前より減少したことは確実です」プログラマーがサイクルの早い時期に問題点に対処し、その都度修正していくため、テスト回数が減ったことが理由だそうです。

　セキュアコーディングが実現するのは、テスト時間の削減だけではありません。チェス氏は、製品の品質向上が促進される点を指摘します。「多くの場合、セキュリティー上のバグを早期に把握することで、ほかの作業に関する予測を立てやすくなります。このような予測可能性は大きなメリットとなり得ます。同時に、管理水準が上昇しているので、発表した出荷日を守れる公算も大きくなります」

　もっと重要なのは、セキュリティー違反を回避することで、可能性として何百万ドルもの損失を軽減していることです。ハワード氏は、他社の仲間に手を貸して、セキュアコーディングを目的とした200,000ドルの追加予算を納得させた経験があります。リスク管理部門を引き連れて、その投資が保護する情報の価値を示したのが功を奏しました。

　当初は経営陣が二の足を踏んだ出費ですが、それで3000万ドルの資産に対するリスクが軽減されるとリスク管理者が説明した後では、ささいな金額としか思えません。ハワード氏はその時のことを思い出します。プレゼンテーションが終わるや否や、「『どこにサインすればいいのかな？』と聞かれましたよ」

Copyright © 2008 Ziff Davis Enterprise, Inc.
Originally appearing in the U.S. Edition of Baseline. All Rights Reserved.