セキュリティ対策の実装はソフトウェア開発ライフサイクル（SDLC）の成功を確実にするための最優先事項です。
まず第一に、開発の全工程を通じてステークホルダーとの良好な関係を維持することが重要です。ステークホルダーの立場に立ってその期待を理解し、これに対応することで最終製品の成功が保証され、ソフトウェア・セキュリティの設計と組み込みのクリティカリティが強化されます。
良好な関係は土壇場で想定外の結果を招く可能性を軽減します。
SDLCの全工程を貫くもう一つの要素として、要件のトレーサビリティ（追跡機能）を設ける必要があります。これにより、SDLCの全工程を通じてすべての要件（特にセキュリティ要件）を確実にトレースし、ギャップが生じることを防ぎます。また、すべての要件に対応する明確なテスト目標とテスト・ケースを作成するための指針にもなります。トレーサビリティによって顧客による最終製品の受け入れも容易になり、すべての要件が満たされ、テスト済みであるという信用も得られます。
以上はSDLCの全工程に関わる要素ですが、次に、ソフトウェア開発ライフサイクルのフェーズごとにさらに詳細なセキュリティを組み込む10の方法をご紹介します。
1. 環境を評価する
SDLCフェーズ：要件収集
この工程は真の顧客ニーズをよく理解することから始まります。その方法は次のとおりです。
- スコープと境界を定める
- ステークホルダーを特定する
- プロセスギャップを特定する
- 組織とプロジェクトのスコープに応じた規模のセキュリティ指向のプロセスを設ける
2. 業界標準のセキュリティモデルを取り入れる
SDLCフェーズ：要件収集
構築するソフトウェアに最初からセキュリティを組み込みます。これはライフサイクルの終盤になって予算や納期の目標に対するマイナス要因となることが多い「テスト-パッチ-再テスト」の反復を削減する最も経済的な方法です。
信頼できるマチュリティモデルをSDLCに組み込んで、組織にベストプラクティスとセキュリティ設計原則を取り入れます。Building Security In Maturity Model（BSIMM）は、現状のセキュリティ対策の長所と短所を特定する尺度となるツールです。BSIMMの評価はデータドリブンの目標の策定に役立ちます。
3. ソフトウェアセキュリティに関する人材教育を行う
SDLCフェーズ：要件収集
非セキュアな設計・開発のやり方を削減するため、プロジェクトに携わるすべての要員がソフトウェアセキュリティの標準を熟知し、常に最新情報に通じているようにします。人材トレーニングへの投資の規模は、全体的な組織に応じて、また着手する各ソフトウェア開発プロジェクトのスコープに応じて調整可能です。そのメリットは、全ソフトウェア開発プロジェクトにわたってスタッフの教育が行き届き、全社的な資産になり得るという点にあります。
4. ソフトウェアセキュリティの責任を分担する
SDLCフェーズ：要件収集
ソフトウェアセキュリティをSDLCに確実に組み込むため、正式に責任を割り当てます。組織の規模によっては、策定されたセキュリティ対策の教育、評価、実施を組織全体に行き渡らせる効果的な方法としてソフトウェア・セキュリティ・グループ（SSG）の創設が考えられます。これは組織の規模が大きくなってもセキュリティの低下や完全な無視を招くことなく変更管理とリスク管理を維持するためのカギとなります。
SSGはソフトウェアセキュリティ分野の専門家としての役割を果たし、SDLCの重大な段階での第三者によるセキュリティ評価の実施を円滑にします。
5. セキュリティ主体の要件収集を行う
SDLCフェーズ：要件収集
初期フェーズに含まれるセキュリティ要件定義の作成に合わせて組織のアプローチを調整します。このアプローチはSDLC全体に確実なセキュリティ意識を植え付けるために役立ちます。悪用のケースと誤用のケースを作成し、要件収集フェーズで初期のリスク分析を行って、SDLCのその他のフェーズにおけるセキュリティアクティビティを促進します。これにより、要件定義を作成する際の焦点がテスト可能性に移ります。
6. 包括的なリスク管理プロセスを策定する
SDLCフェーズ：要件収集
SDLCの成功には、重大なリスクを特定して緩和計画を実行することが重要です。これは以下の目的のためにも重要な要素です。
- 適切なセキュリティ設計を確保する
- SDLCの実施に際して以下の面に関する効果的な指針を確保する
- スコープクリープの管理
- 予算と納期の目標遵守
- ステークホルダーとの良好な関係構築
7. アーキテクチャのレビューと脅威モデリングを行う
SDLCフェーズ：設計
設計工程の早期段階で設計の欠陥を見つけて修正する方が、ソフトウェアのデプロイ後になってから欠陥のある設計の実装にパッチを適用するよりもはるかに経済的です。脅威モデリングとともに、アーキテクチャ・リスク分析も設計の欠陥を検出するために必須のツールです。欠陥の特定には以下の方法を用います。
- 基本的な設計原則の解析
- アタックサーフェスの評価
- 各種の脅威エージェントの列挙
- セキュリティ対策の弱点とギャップの特定
8. 実装時のコードレビューを行う
SDLCフェーズ：実装
リリースゲートの通過条件として、セキュアコーディング標準と静的コード解析に加え、セキュアコード・レビューを行います。これにより、完成品に紛れ込むバグの数が激減します。効果的な欠陥阻止・管理システムも不具合の解決のための優先順位付けと追跡に役立ちます。
9. テスト計画とペネトレーションテストを実行する
SDLCフェーズ：検証
テスト計画は検証フェーズで実行し、製品がランタイムのシナリオで想定どおりの機能を果たすことを検証します。ペネトレーションテストにより、以下のような各種の悪用ケースに製品がどう対処するかを評価します。
- 不正な形式の入力の処理
- ビジネスロジックの欠陥
- 認証/認可/バイパスの試み
- 全般的なセキュリティ体制
10. ソフトウェア製品をデプロイする
SDLCフェーズ：デプロイ/保守
デプロイ計画を作成します。これは総合的なQAテストと受け入れテストの完了後、本番環境へのリリースを問題なく行うために不可欠です。デプロイ計画では、ソフトウェアの動作環境とコンフィグレーションや起動手順を詳細に規定する必要があります。
この段階でソフトウェアの保守および変更管理プロセスの計画を定め、製造から生じたバグや機能強化要求に効率的に対応できるようにしておきます。
また、このフェーズでロールバック計画と災害復旧要件を定めておくと、顧客からの持続的な信頼の確保に役立ちます。
追記：インシデント・レスポンス・グループ/計画の立ち上げ
脅威の状況は絶えず変化しています。脆弱性が発見されるのは時間の問題です。インシデントレスポンス計画とその計画の実行を準備するグループは、デプロイされた製品および企業のセキュリティを確保するために不可欠です。インシデント・レスポンス・グループは損害の可能性を阻止または低減するため、インシデントに効果的かつ迅速に対応する必要があります。また、このグループは将来のイテレーションや新製品のためにSDLCのフローをさかのぼる必要がある場合のセキュリティのベストプラクティスに関する重要な情報源でもあります。
アジャイルSDLCを活用している組織にとって、4つの主要原則をプロセスに追加することが重大なセキュリティ対策を無理なく効果的な方法で統合するためにどう役立つかをご覧ください。
