単純なWebサイト、デスクトップアプリケーション、複雑な3リンクシステムなどのソフトウェアシステムを開発する場合、遅かれ早かれ、セキュリティの問題が発生します。 開発中のシステムが何らかの方法で攻撃されることを排除することはできません。 さらに、システムの種類、その複雑さ、適用される技術的ソリューション、攻撃ベクトル、およびその結果は、性質が大きく異なる場合があります。 おそらく、チームの誰かが開発したシステムのセキュリティ分析を実行し、モデリングが実行される場合があります。 これらの質問を後で残しておくと、さらに悪化します。 システムが商用操作モードでハッキングされ、急いで発見された欠陥の修正を作成する必要がある場合、結果は非常に悲惨なものになる可能性があります。 明らかに、セキュリティ関連の問題は、要件分析やアーキテクチャモデリングなど、システムの最も初期の段階から対処するのが最適です。 しかし、システムのライフサイクル全体を通してこれを行うことが最善であり、これらの問題に対処するために設計された開発プロセスに特別なステップを統合します。 これらのプロセスの1つがセキュリティ開発ライフサイクルです。これは、開発されたシステムのセキュリティを改善することを目的とした一連のプラクティスです。
セキュリティ開発ライフサイクルとは
SDLは、開発したシステムに必要なレベルのセキュリティを確認できるプロセスです。 SDLは、チームのトレーニング、開発されたシステムのセキュリティの分析、およびセキュリティの改善を目的としたメカニズムの実装に関連するレポートと直接的なアクションの準備を目的としたプラクティスに基づいています。 具体的な手順の形でのこれらのプラクティスは、使い慣れたスパイラルソフトウェア開発サイクルに簡単に適合します。
これらのプラクティスの一部だけで、開発中のシステムのセキュリティを改善できます。 しかし、開発プロセスの一部として使用すると、結果が大幅に向上し、コストを削減できることが経験からわかっています。
SDLを実装する前に：トレーニング
すべてのチームメンバーは、開発を直接開始する前に、安全トレーニングを受け、この分野の現在の傾向に関連する重要なポイントを調査する必要があります。 このトレーニングの基本レベルには次のものが含まれます。
安全な設計
- 攻撃エリアの削減
- 深い防御
- 最小特権の原則
- デフォルトのセキュリティ
次のトピックを含む脅威モデリング：
- 脅威モデルの概要
- 設計に対する脅威モデルの影響
- 脅威モデルに基づく脅威モデルの制限
次のトピックを含む安全なコーディング：
- バッファオーバーフロー（CおよびC ++アプリケーションの場合）
- 整数演算エラー（CおよびC ++アプリケーションの場合）
- クロスサイトスクリプティング（Webアプリケーション用）
- SQLインジェクション（データベースと対話するアプリケーション用）
- 弱い暗号
次のトピックを含むセキュリティテスト：
- セキュリティテストと機能テストの違い
- リスク監査
- セキュリティテスト方法
次のトピックを含むプライバシーの確保：
- 個人情報の種類
- プライバシー：設計のベストプラクティス
- リスク監査
- プライバシー：ベストプラクティス
- プライバシー：ベストテストプラクティス
もちろん、これらのトピックを学習するときは、役割（テスター、開発者、マネージャー、アナリスト）を考慮する必要がありますが、すべてのチームメンバーがこのトレーニングを受けることが非常に重要です。
要件分析：セキュリティコンテキストで考慮すべき事項
システム要件の分析レベルですでに、セキュリティに関連する重要な側面を考慮する必要があります。 同時に、「安全要件」と「セキュリティ要件」を区別することが重要です。 SDLには特定のプラクティスセットがあり、これらのプラクティスのいくつかである「要件のセキュリティとプライバシーの分析」は、要件分析の段階で適用できます。 このプラクティスは、セキュリティ関連の問題の詳細な調査を必要とする機能要件を識別することを目的としています。 このような監査には、次の情報が含まれる場合があります。
- ソフトウェアのどの部分がリリース前に脅威分析を必要としますか？
- ソフトウェアのどの部分がセキュリティのコンテキストで設計分析を必要としますか？
- ソフトウェアのどの部分が、独立したグループによる侵入の脅威の追加分析を必要としますか？
- 軽減できる追加の安全性の問題とリスクはありますか？
- セキュリティコンテキストでのファジーテストの境界。
- 個人データの開示の脅威のレベルは何ですか？
安全設計
アプリケーションを設計するとき、アプリケーションのセキュリティを向上させるのに役立つ多くのプラクティスを適用することもできます。 まず第一に、これは攻撃の可能性のある表面積の縮小（Attack Surface Reduction）と脅威のモデリングです。 これら2つの概念は密接な関係にありますが、最初のメカニズムでは、攻撃者が未知のセキュリティホールを悪用する能力を積極的に低下させます。 起こりうる攻撃の領域を減らすために、レイヤーごとの防御メカニズムと最小特権の原則を適用できます。 脅威のモデリングは、どのシステムコンポーネントが攻撃ベクトルと見なされるかを示しています。 脅威のモデリングに便利なツールは、STRIDE分類に基づいたMicrosoftスレッドモデリングツールです。
セキュリティ実装
通常、実装フェーズはプロジェクトの最も時間のかかる部分です。 このタスクを容易にするために、多くのツール、テクノロジー、および市販のコンポーネントが使用されます。 セキュリティのコンテキストでは、このツールキットのリストが事前に記録されていることが重要です。 推奨されるアプローチは、実装中に許可されるツールのリストを作成することです。 安全でない、または廃止された機能およびコンポーネントの使用を除外するか、具体的に指定することが可能な場合。 さらに、静的コード分析などの自動化ツールの使用も重要です。
セキュリティ検証（テスト）フェーズ
このフェーズでは、動的コード分析（実行時）などのプラクティスを使用して、関数の異常な動作、メモリ破損、特権関数の使用、その他の重大な問題をすばやく特定できます。 この問題を解決するのに役立つツールの1つはAppVerifierです。 標準の機能テストに加えて、フローティングテストを追加する必要があります。フローティングテストは、不正なデータ、不正な形式のパラメーター、および異常な動作を引き起こす可能性があるその他の条件を入力するモードでアプリケーションをテストするように設計されていますが、同時にシステムは安全な状態にある必要があります。 また、この段階では、生成されたモデルの正確性を検証するために、前のフェーズでシミュレートされた攻撃ベクトルを検証することが重要です。
セキュリティリリースリリースフェーズ
この段階では、特定された脅威または侵入に対する相互作用と反応の順序が宣言されるセキュリティインシデントの対応計画を作成することが重要です。 最終リリース（RTM、RTW）は、展開前の設計段階で合意されたすべての展開前のセキュリティ条件を満たしている必要があります。 そうでない場合は、すべての機能要件が満たされていても、セキュリティ関連の問題を修正するために標準の開発サイクルを繰り返す必要があります。
次は何ですか
もちろん、このノートではSDLの最も基本的な側面のみを明らかにしており、アプリケーションを成功させるにはさらなる研究が必要です。 MSDNセキュリティセンターが役立ちます。
SDLの詳細については、明日のMicrosoft Secure Software Development Conferenceのライブブロードキャストをご覧ください。 その中には、Alex Lucasによる「安全なSDL開発サイクルの進化」、Glenn Pitaveyaによる「SDLの実装」による報告があります。