アプリケーションセキュリティ  情報セキュリティ

インドの情報セキュリティの大家が書き下ろした最新のセキュリティ書籍の一部をオンライン書籍としてご紹介します。書籍の情報は、こちらをご覧ください。

Security Development Life Cycle (SDL)

Microsoft は、毎月のようにセキュリティ パッチと更新プログラムをリリースしています。このように更新を行う多くの理由の 1 つは、アプリケーションとオペレーティング システムをハッキングの試みから守ることです。

アプリケーションを少しでも安定した安全なものにするため、Microsoft で作成されるすべてのソフトウェアは、13 ステージからなる厳格な Security Development Lifecycle の対象となります。CMMI、Agile、ISO 15408 Common Criteria など、多くのソフトウェア開発方法論が市場に出回っていますが、ソフトウェアのセキュリティのみを対象としたものはありません。

SDL が正式に定められたのは 2004 年ですが、その背後には長い歴史があります。SDL が Microsoft で成功したのは、Bill Gates 氏が直々にトップダウンで推進したためです。

Microsoft から出版されている書籍『The Security Development LifeCycle』(Howard と Lipner 共著) および Microsoft が公開しているこのトピックについての他のホワイト ペーパーによってのみ、このセキュリティ開発プロセスを公式に知ることができます。SDL は安全なソフトウェアの作成手順に関して優れた洞察を提供することから、SDL を公開することで Microsoft の評価は高まりました。Microsoft によると、この 13 ステージの手法のおかげで、セキュリティの欠陥が 50% 以上減少したそうです。SDL は、攻撃者が Windows オペレーティング システムおよび他の Microsoft 製品の攻撃から手を引くようになった多くの理由の 1 つです。攻撃者は、今ではアプリケーションにセキュリティ コードが実装されておらず得られるものも多い、ビジネス アプリケーションを対象にしています。

さらに、Microsoft は、コード レビューは良いとしながらも、1 日に 1,100 行以上もの C++ コードをレビューするのはほとんど不可能であることも認めています。複数の異なる方法論を適用して、アプリケーションの抜け穴を検査する必要があります。1 つの方法だけでは十分ではありません。

それでは、過去数年にわたって発展してきた 13 ステージのプロセスを見ていきましょう。

ステージ 0 : 教育と認識

SDL が大きな成功を収めた理由の 1 つはこのステージにあります。プログラマが一連の攻撃のことを熟知していなければ、コードを守ることなどできません。たとえば、今日最も多い Web 攻撃はクロス サイト スクリプティング、つまり XSS です。XSS 攻撃が成功するには、多くの条件が成立している必要があります。コーダーは、XSS 攻撃に使用される領域に通じている場合にのみ、防御メカニズムを使用できます。知らないことを防ぐことはできません。

Microsoft のすべてのプログラマは、1 年間に決まった数のトレーニング コースを受けます。各コースは、開発者がセキュリティの重要性を理解するよう、副社長の言葉で始まります。当然のことながら、Microsoft で働くプログラマの数は多いので、これらのコースのほとんどはオンラインで実施され、さらに、『Writing Secure Code』(Mike Howard 著) を読むことが全員に義務付けられます。このように、ステージ 0 はすべての SDL ステージの基礎になります。

ステージ 1 : プロジェクトの開始

プロジェクトが始まることで、SDL が物理的に開始します。SDL には大量のリソースが必要なので、このステージでの最初の質問は「プロジェクトは SDL の範囲に含まれるか」ということです。通常、Microsoft のすべての製品は Personally Identifiable Information (PII) を扱っているので、SDL の対象範囲に含まれます。また、SDL はネットワーク コードと関係のある製品もカバーします。

SDL が必要であることが保証されると、セキュリティ アドバイザと共にセキュリティ リーダーシップ チームが設けられます。そして、セキュリティとプライバシーのバグを追跡するフィールドが、バグ追跡データベースに追加されます。これで下準備は完了です。

ステージ 2 : 設計のベスト プラクティスを定義してそれに従う

SDL の主な目的は次の 2 つです。

· コードを開発する前にソフトウェアの脆弱性の数を減らす

· コードを開発した後で表面化していないセキュリティ バグの重大性を小さくする

どのような場合でも、セキュリティ機能を組み込むために製品の使いやすさが損なわれてはならず、その逆も許されません。適正なバランスを実現する必要があります。たとえば、Windows XP ファイアウォールを使用するのが非常に困難な場合は、それをセキュリティの観点で考えるのではなく、単純にオフにします。つまり、コード設計のベスト プラクティスに従う必要があります。

セキュリティ バグがまったくないコードを作成することは不可能なので、コードの損害の数と重大さを減らすことに真剣に取り組む必要があります。このステージでは、Attack Surface Analysis (ASA) と Attack Surface Reduction (ASR) の概念を実装します。

この場合の実例は IIS 6.0 です。IIS 6.0 は IIS 5.0 より概念的にはるかに安全であると評価されています。IIS 6.0 は、設計フェーズにおいて、多くの機能を無効にすることで攻撃対象領域を減らしたため、IIS 5.0 よりも被る損害が小さくなっています。OS のインストール時に IIS をインストールする必要のないホーム ユーザーがいます。Windows XP のインストール時に、IIS が事前にインストールされることはありません。

また、IIS を単にハード ディスクからファイルをフェッチする Web サーバーとして使用する場合があります。簡単に実現できるよう、静的なコンテンツのみが提供されます。このような場合には、サーバーは動的なコンテンツを提供する必要はありません。このため、インストール時には、既定で、動的コンテンツ オプションはオフになっています。TRACE のような機能は必要ないので、既定でオフにする必要があります。

必要のない特殊なオプションのチェックボックスをオフにすることで、攻撃対象領域は劇的に減少します。最終的な結果として、機能が既定でオフになっているので、ほとんどの IIS サーバーは攻撃が発生しても影響を受けません。また、機能が必要なユーザーはいくつか面倒な作業を行うことでオプションを調節できます。結果として、ほとんどの Web サイトは十分に安全で適切に保護されます。

外界に向けて公開されるコードはいっそうの注意が必要であり、したがって適切に識別する必要があります。システムへのすべての侵入口と信頼レベルを、正しく洗い出す必要があります。さらに、チームが独自の認証および認可の方式を作成できないようにする必要があります。

複数の層で、データベース サーバーへの接続のような重要なコードを保護するさまざまな方法を用いて、多層防御 (defense-in-depth) 戦略を採用する必要があります。この作業をスタンドアロン方式で行うと、アプリケーション全体がたやすく脆弱になる可能性があります。ファイアウォールは簡単に無効にできるので、ファイアウォールを唯一の防衛線にはできないことを肝に銘じる必要があります。

ActiveX のような古い技術は休ませて、.Net を使用する必要があります。新しい技術のアップグレードと開発により、製品の抜け穴が解決されています。.Net Framework は、セキュリティ機能を考慮して設計されています。

これまでに解説したセキュリティ原則に従い、全ユーザーに制限付きのアクセスを許可する必要があります。さらに、ユーザーが最低限の権限でアプリケーションを実行するようにします。次に、可能な場合は常に最強のアクセス コントロール リストを使用します。また、適切なネットワーク プロトコルを使用する方が安全です。たとえば、TCP はスプーフィングが容易ではないので、UDP ではなく TCP を使うようにします。

書式文字列攻撃 (format strings attack) のようなバグはリリース後何年も経ってからソフトウェアを攻撃するので、将来の計画は設計フェーズで行うのが最善です。

ここではほんのいくつかの点を示しただけですが、指摘したいのは設計フェーズでバグの解決に十分な時間をかけることで、企業にとってはセキュリティの向上と経費の節約になるということです。

ステージ 3 : 製品リスク評価

このステージでは、製品に対するセキュリティ フレームワークの構築におけるコストの要素に注目します。マネージャは要件を満たす異なるオプションを調査し、各選択肢の最善の使用方法を検討します。通常リスク評価は経営レベルで行われ、価値があると思われる製品のセキュリティを確保するためのリソースが投入されます。リスクが高いコンポーネントには、より多くの投資が必要です。PII は、法律で定められたコンプライアンスの観点からも基本的に重要です。

ステージ 4 : リスク分析

このステージでは、脅威のモデリングを行う必要があります。周囲に潜む脅威をコーダーが認識していなければ、身を守るコードは作成できません。したがって、実際の脅威モデルを作成します。Microsoft では、この問題に関して Threat Analysis and Modeling (TAM) という名前のダウンロード可能なツールを提供しています。また、脅威モデリングについての本も出版しています。

脅威モデルでは、入力と信頼レベルを説明する簡単なデータ フロー図を作成します。脅威が検出されたら、セキュリティ アドバイザは緩和策を転送、処置、または終了する必要があるかどうかを明らかにする必要があります。これは保護するデータの基盤を形成することになるので、SDL の中でも最も時間のかかる重要なフェーズの 1 つです。

情報資産を保護することは、基本的にこれらの資産の所有権を保護することです。ISO 27001 では、防御メカニズムのことを CIA (Confidentiality, Integrity and Availability : 機密性、完全性、可用性) と呼んでいます。Microsoft では、STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of service and Elevation of privilege : スプーフィング、改ざん、否認、情報漏洩、サービス拒否、権限の不正取得) と呼んでいます。

ステージ 5 : エンド ユーザー向けのドキュメント、ツール、ベスト プラクティスの作成

製品の使用とセキュリティの意味について顧客に情報を提供する、製品についての詳細なドキュメントを用意する必要があります。ユーザーは、構成の設定およびそれが変更された場合の影響について知らされる必要があります。選択肢について説明する詳細なドキュメントをユーザーに提供する必要があります。ユーザーの入力を受け取ると共に、ユーザーが構成オプションを有効または無効のどちらにすればよいのかを判断するための情報を提供するように、セキュリティ構成ウィザードを設計できます。たとえば、不必要なサービスの有効化/無効化や、ポートの遮断/開放などです。

ステージ 6 : 安全なコーディングの実践

プログラマは、コードをコンパイルするときに最新のコンパイラを使用することの重要性を認識するよう、コンパイラによって追加される防御についての教育を受ける必要があります。また、ソース コード分析ツールを使用して、strcpy や strcat などの禁止された関数の使用を検出し、コードを攻撃から守る必要があります。安全なコーディングのためのチェックリストを定期的に更新することは、過去の誤りをコーダーが学習するのに役立ちます。

ステージ 7 : セキュリティ テストのポリシー

このステージは、アプリケーションをテストするときに開始します。ファジング (Fuzzing ) とは、アプリケーションにランダムな不正入力を与えて、動作を観察する技法のことです。このような方法により、プログラムの全セキュリティ バグの 25% 以上を発見できます。アプリケーションで使用されているすべてのファイル形式、ネットワーク プロトコル、ユーザー入力などを、10 万件以上のランダム データでテストする必要があります。これらのテストの結果で、セキュリティ違反を検査します。ここで必要なことは適切な侵入テストです。

ステージ 8 : セキュリティ プッシュ

セキュリティ プッシュは、すべての企業のすべての製品に適用できるとは限りません。ここでは、レガシー コードに関するセキュリティ バグにのみ焦点を当てます。注目するのは、バグの修正ではなくバグを発見することです。レガシー コードをレビューし脅威モデルを更新して、攻撃対象領域を小さくする手段を発見します。

ステージ 9 : 最終セキュリティ レビュー

ステージ 9 では、中央のセキュリティ チームが、セキュリティ開発ライフサイクルのすべてのステージが厳密に遵守されたかどうかを確認します。SDL のすべての規則を調査し、結果を検証します。いずれかのステージおよび製品に少しでも不備があった場合は出荷されません。

ステージ 10 : セキュリティ対応計画

開発チームは検査ラウンドに合格してしまえばそれ以上必要なことはないと考えているので、このステージは見落とされることがよくあります。しかし、チームは製品を出荷した後でバグが発見されたときの応答とバグ レポートを待機する作業計画を用意する必要があります。すべてのコード違反またはセキュリティ侵害を直ちにコーダーに報告し、コーダーはそれをバグ追跡データベースに追加します。

ステージ 11 : 製品リリース

最後に、製品をリリースします。SDL は必ず、期待に応えてくれることでしょう。

ステージ 12 : セキュリティ対応の実行

ステージ 10 の計画を実行します。バグが報告されたら、コーダーは計画ステージで採用された戦略を実施して、バグを修正する必要があります。

まさに、論より証拠です。SDL は Microsoft ではうまくいったので、他の環境でもうまくいくものと確信しています。

私たちすべてが理解しなければならないのは、セキュリティは特殊な分野であり、知識が限られているということです。それでは、この世界への扉を開きアプリケーションを保護する場合のセキュリティのさまざまな側面を明らかにすることにします。

では、.Net Framework を使用してアプリケーションを保護する旅にお付き合いください。