この記事は、セキュリティチームとテクノロジ チームが開発セキュリティ規範を確立し、最新化するのに役立ちます。 この規範は、セキュリティ、エンジニアリング、テクノロジの各チームが、イノベーションを遅らせることなく、ソフトウェアが安全に設計、構築、統合、デプロイされるようにするのに役立ちます。
セキュリティ規範 は、関連するセキュリティ作業のグループであり、組織がテクノロジ資産全体にわたって一貫してセキュリティ成果を提供するのに役立ちます。 セキュリティ導入モデル内では、規範によって ビジネス シナリオ と 技術実装の間の橋渡しが可能になり、セキュリティ投資が セキュリティ導入モデルの一部として実際の測定可能な結果に変換されます。
なぜこの規範?
ソフトウェアは、ID、データ、インフラストラクチャ、およびビジネス プロセスと深く相互接続されています。 開発のセキュリティが脆弱または一貫性がない場合、各ソフトウェア リリースでは、攻撃者が悪用して広範な組織資産にアクセスできる新しい脆弱性が発生する可能性があります。
効果的な開発セキュリティ規範がなければ、組織は一般的に次のことが発生します。
- 開発中に発生したソフトウェアの脆弱性によるリスクの増加。
- ID とデータ間の横移動を可能にするアプリケーションの侵害。
- 事業運営と収益の中断。
- お客様および規制対象データの露出または不正使用。
- 長期的なリスクと修復コストを増加させる技術的負債の蓄積。
堅固な開発セキュリティの規律によって、リリースのたびにリスクが積み増されるのではなく、確実に低減されます。
ミッションと成果
開発セキュリティ規範は、内部またはパートナーによって開発されたすべてのソフトウェアが、配信やイノベーションを遅らせることなく、セキュリティ標準に合わせて設計、構築、統合、デプロイされるようにすることで、組織のリスクを軽減します。
この規範を成熟する組織は、次のことを実現します。
- 遅れて追加されるのではなく、開発プロセスに組み込まれているセキュリティ。
- 設計と実装の欠陥の以前の識別と修復。
- より予測可能で安全なリリース サイクル。
- 手直し、緊急修正、運用の中断を減らしました。
- 時間の経過に伴う技術的負債とセキュリティ負債の蓄積を減らします。
開発セキュリティにより、定期的にリセットされるのではなく、リリースごとにセキュリティ体制が継続的に改善されます。
チーム作業の変更
開発セキュリティ規範は、開発者や製品チームを満たすことが重要です。つまり、開発プロセスに遅延段階の制御、摩擦の多いレビュー プロセスを導入したり、セキュリティをスキップしたりするのではなく、既存の開発ワークフローにセキュリティを統合することに重点を置きます。
このアプローチは、多くの場合、問題の修正が容易でコストが低い場合に、 左にシフトし、考え方、設計、実装の早い段階でセキュリティ思考を導入すると説明されます。 左にシフトしても、プロセスの早い段階でノーと言うわけではありません。 代わりに、製品の意思決定を改善し、ソリューションがセキュリティとビジネスの要件を満たしていることを確認するために、セキュリティに関する情報に基づいた議論を早期に導入します。
主な原則は次のとおりです。
- 早期統合: 単なるテストではなく、考え方と設計時のセキュリティを検討する
- 開発者との連携: 開発チームやプロダクトチームがすでに使っている環境に合わせる
- 小規模で増分的な変更: 自動化と低摩擦の改善を優先する
- 継続的な改善: マイルストーンではなく、セキュリティを継続的な規範として扱う
時間の経過と同時に、一貫した統合により、防火訓練が減少し、速度が遅くなるのではなく、配送が高速化されます。
この規範を適用する方法
開発セキュリティ規範を効果的に適用するには、組織全体でセキュリティで保護されたアプリケーションとサービスを構築および維持するための一貫したアプローチを確立することに重点を置きます。
-
ビジネス リスクに合わせた安全な開発戦略を定義する
セキュリティ侵害のリスクを軽減し、重要なビジネス機能を保護するために、アプリケーションとサービスを設計、構築、保守する方法に関する明確なアプローチを確立します。 -
開発およびエンジニアリング プロセスにセキュリティを埋め込む
セキュリティ プラクティスが、事後適用されるのではなく、計画、設計、開発、展開の各アクティビティに統合されていることを確認します。 -
標準化された安全な開発プラクティスを確立する
セキュリティで保護されたコーディング、テスト、リリースのプラクティスがチームやプロジェクト間で一貫して適用されるように、明確なガイダンスを提供します。 -
開発セキュリティを重要な資産とビジネス シナリオに合わせる
価値の高い資産と主要なビジネス運用をサポートするアプリケーションとサービスの保護に優先順位を付けます。 -
リスク、脆弱性、フィードバックに基づいて継続的に改善する
脆弱性、インシデント、テスト結果からの分析情報を使用して、開発プラクティスを強化し、時間の経過と同時にリスクを軽減します。
変更の管理
最新の開発セキュリティは、通常、DevSecOps アプローチを通じて実装されます。このアプローチでは、アジャイル配信と、リリース前の基本的なガバナンスと品質プラクティスが組み合わせられます。
DevSecOps では、速度とセキュリティを選択するのではなく、開発ライフサイクルの重要な側面をセキュリティで保護し、迅速なリリース サイクルを妨げずに緊急のリスクを軽減することに重点を置いています。
設計をセキュリティで保護 する – 実証済みのセキュリティ設計パターンを使用し、脅威モデリングを通じて設計を検証します。 コードをセキュリティで保護する – セキュリティで保護されたコーディングプラクティスに従い、ソフトウェアと依存関係を検証します。 パイプラインをセキュリティで保護する – パイプライン プロセスを検証し、CI/CD システムを侵害や未承認の変更から保護します。 パイプラインと、パイプラインを通過するソフトウェアに対する変更の追跡可能性を確保します。 セキュリティで保護された操作 – デプロイされたワークロードが、構成、修正プログラムの適用、運用のベスト プラクティスに従っていることを確認します。
チームは、開発、セキュリティ、運用間のコラボレーションを継続的に改善し、機能配信の目標と信頼性とリスクの軽減のバランスを取ることで、成果を向上させることができます。
この継続的な増分改善は、作業の運用 (ライフサイクルで生成されたソフトウェア コード) と開発ライフサイクル自体の成熟の両方に適用する必要があります。
DevSecOps プロセスを定義する
開発セキュリティは、通常、完全な形式ではなく、時間の経過と同時に進化する DevSecOps 運用モデルを通じて実装されます。 DevSecOps は、開発、セキュリティ、運用を組み合わせて、継続的な改善を通じてより良い結果を達成します。
ほとんどの組織は、次のステージを進めます。
開発 (開発) – 最初の運用リリースでは、コア ビジネス要件を満たす最小限に実行可能な製品 (MVP) を提供することに重点を置いています。 DevOps – 最初のリリース後、チームは継続的デリバリーを通じて迅速なイテレーション、運用の安定性、ガバナンスに重点を置きます。 DevSecOps – コラボレーションが成熟すると、開発、セキュリティ、運用が連携してプロセスを継続的に調整し、速度、リスク、信頼性のバランスを取ります。
この進行により、組織は機敏性やイノベーションを犠牲にすることなく、セキュリティの成果を向上させることができます。
セキュリティで保護された MVP ベースラインを確立する
このモデルの重要なステップは、開発、セキュリティ、運用の観点から、実行可能な最小限の製品 (MVP) を構成するものを定義することです。 この共有ベースラインを確立すると、チーム間で明確になり、時間の経過と同時に一貫した改善が可能になります。
| コンポーネント | 詳細情報 |
|---|---|
| Dev(elopment) | ソフトウェアが最低限のビジネス要件と機能要件を満たしていることを確認します。 |
| Sec(urity) | ソフトウェアが最低限のセキュリティとコンプライアンスの要件を満たしていることを確認します。 |
| Op(eration)s | ソフトウェアが最小限の品質、信頼性、運用上の準備要件を満たしていることを確認します。 |
MVP の要件は組織や業界によって異なり、リスクアペタイト、規制の露出、ビジネスの重要度の影響を受けます。 多くの場合、これらの要件は、組織、脅威ランドスケープ、配信モデルの変化に応じて進化します。
継続的なソフトウェアの改善
最初の運用リリース後、ワークロードは継続的な改善サイクルに移行します。 このフェーズでは、開発、セキュリティ、運用により、ソフトウェアと配信プロセスの両方が調整されます。 セキュリティの取り組みは次の点に重点を置く。
- 他のエンジニアリング作業と同じツールと優先順位付けモデルを使用して、開発ワークフローにセキュリティをネイティブに統合する
- 標準的なリリース サイクルの一環として、セキュリティバグを迅速に特定し、優先順位を付け、修正します。
このアプローチは、prPaved Paths などの Microsoft Secure Future Initiative (SFI) の学習と一致します。セキュリティで保護されたプラクティスは、外部から強制されるのではなく、プラットフォームとプロセスに組み込まれます。
時間の経過とともに、この継続的な学習は、チームが要件を調整し、コラボレーションを合理化し、配信速度、セキュリティ、信頼性のバランスを取るのに役立ちます。
規範の役割とコラボレーター
Dev Security 規範は、通常、アプリと製品開発を行うチームによって実行されます。
通常、この規範の主な役割は次のとおりです。
- テクノロジの提供と製品マネージャー
- ソフトウェア開発者 (AI 開発を含む)
- ソフトウェア セキュリティ エンジニア
- DevOps とプラットフォーム エンジニア
- テストと品質エンジニアリングの役割
- サプライ チェーンと依存関係のセキュリティ ロール
主なコラボレーターは次のとおりです。
- ビジネスと技術のリーダーシップ – スポンサーシップと優先順位付けを提供する
- アーキテクチャの役割 – 安全な設計と統合の決定をガイドする
- セキュリティ戦略、統合、ガバナンス規範の役割 – ポリシー、教育、監視を提供する
- インフラストラクチャチームとプラットフォームチーム - 安全な開発環境を有効にする
- セキュリティ運用 (SecOps) – アプリケーションが攻撃されたときに監視して対応する
他の規範との連携
開発セキュリティは、他の SAF 規範と緊密に統合されています。
- アクセスと ID – 開発者、ワークロード、サービス ID を保護します。
- インフラストラクチャ セキュリティ – アプリケーションとパイプラインを実行しているプラットフォームをセキュリティで保護します。
- データセキュリティ – ソフトウェアライフサイクル全体を通して機密データが確実に保護されます。
- SecOps – アプリケーション レベルの攻撃を検出して対応します。
- セキュリティ戦略、統合、ガバナンス – 開発プラクティスを企業のリスクの優先順位に合わせます。
これらの規範を組み合わせることで、ソフトウェア セキュリティは、より広範なビジネスとセキュリティの成果をサポートします。
テクノロジの柱との連携
開発セキュリティ規範の戦略を実行するには、複数のテクノロジの柱にわたるセキュリティ制御が必要です。
テクノロジの柱との連携には、次のものが含まれます。
- ID: 開発者とワークロードの ID と資格情報を保護します。
- エンドポイント: 開発者ワークステーションをセキュリティで保護し、システムを構築します。
- インフラストラクチャ: コード、パイプライン、ワークロードをホストするプラットフォームを保護します。
- アプリ: 開発セキュリティ プラクティスの主な焦点を提供します。
- データ: アプリケーションによって使用、生成、および格納されるデータを保護します。
- ネットワーク: 信頼されていないネットワーク上で安全に動作するようにソフトウェアを設計します。
- AI: 最新のアプリケーションで使用される AI コンポーネントとモデルをセキュリティで保護します。
この幅広さにより、この分野は現実の攻撃経路に対処できるようになります。
次は何ですか?
開発セキュリティ戦略の追加ガイダンスは、 開発セキュリティ戦略にあります。
ワークショップを受ける
Microsoft Unified では、組織が開発セキュリティ規範を最新化するのに役立つ、エキスパート主導のワークショップが提供されています。 これらのワークショップには次のものが含まれます。
- アーキテクチャと戦略のワークショップ - セキュリティ導入フレームワーク (SAF) - アーキテクチャ設計セッション: インフラストラクチャと開発のセキュリティ ワークショップ では、開発セキュリティの最新化とインフラストラクチャ セキュリティとの統合を加速することに重点を置いています。 このワークショップは、主要な学習とベスト プラクティスに焦点を当てた 4 時間未満のディスカッションとして利用できます。
- テクノロジ導入ワークショップ: Microsoft Unified には、組織が、この図に示すように、Microsoft開発セキュリティ テクノロジの使用について学習、計画、実装、最適化するためのワークショップがあります。
Microsoft セキュリティ開発ライフサイクルを確認する
Microsoft継続的セキュリティ開発ライフサイクルは、ソフトウェアを安全に開発するための方法論を提供します。 セキュリティ開発ライフサイクル (SDL) は、セキュリティを DevOps プロセス (DevSecOps アプローチとも呼ばれます) に統合するために使用Microsoftアプローチです。 SAF 開発セキュリティ ガイダンスは、SDL のアプローチとプラクティスを組織に適応するのに役立ちます。
SDL アプローチで説明されているプラクティスは、クラシック ウォーターフォールから最新の DevOps アプローチまで、あらゆる種類のソフトウェア開発とすべてのプラットフォームに適用できます。 この一般的に適用可能なソフトウェア セキュリティ アプローチは、あらゆる種類のソフトウェアとプラットフォームで機能します。
詳細については、「Microsoft セキュリティ開発ライフサイクル (SDL)を参照してください。
効果的な開発セキュリティでは、
次のステップ
DevOps から DevSecOps への移行について説明します。