DevSecOpsのプロセス

DevSecOps環境やパイプラインの戦略的な各段階には、さまざまなプラクティスを取り入れる必要があります。これらのプラクティスに定められたプロセスでは、開発にセキュリティを組み込みながら、開発者を支援し、迅速なデプロイの妨げにならないようにする必要があります。

デリバリーの摩擦を減らす

Netflixの成功を受けて生まれ、DevSecOps文化を実現する戦略として採用されている考え方の一つに、「舗装された道（Paved Road）」があります。これは、ソフトウェアを構想から本番環境へ移行する際の摩擦を減らすことに注力する考え方です。デリバリープロセスに何らかの影響を与える可能性のある意思決定では、開発者を支援するか、デリバリーの妨げになるかを考慮する必要があります。後者は最小限に抑え、できれば完全に避けるべきです。

DevSecOps文化を確立するうえで重要な要素の一つは、共感を育むことでチーム間の摩擦を取り除くことです。

このアプローチを実現するには組織内の多くの部門の賛同が必要ですが、すべては経営層から始まります。ビジネスリーダーが文化の変革を主導しなければ、変化は起こりません。経営陣は、社内のあらゆる階層で「舗装された道」の原則を採用するよう促す必要があります。安全な製品を迅速に顧客へ届ける責任は全員にあることを、企業の価値観として明確に示しましょう。そうすれば、ソフトウェアデリバリーの負担を軽減するプラクティスを優先しやすくなります。

脅威モデリング

『2020 DevSecOps Insights Report』では、脅威モデリングがチーム全体のコードセキュリティに対する信頼感に大きなプラスの影響を与えることが明らかになりました。しかし、脅威モデリングは長年、非常に手間のかかる作業と見なされてきました。そのため、組織がDevOps／DevSecOpsのアプローチへ移行する際に、脅威モデリングがセキュリティプラクティスから除外されることが少なくありません。それでも、脅威モデリングが開発に与える影響を見過ごしてはなりません。

本来、脅威モデリングは、攻撃者がソフトウェアを標的にした場合に何が起こり得るかを特定するため、開発予定のソフトウェアを検証するものです。この分析の目的は、実装時に検討すべきセキュリティコントロールを開発チームに伝えることです。従来は、アプリケーション全体を対象に広範囲な脅威モデリングが行われてきました。その過程では、データフロー図、詳細な脅威分析フレームワーク、規範的な脅威の優先順位付け手法などが活用されてきました。

しかし、DevSecOpsモデルでは、時間とリソースを要する脅威モデリング手法は開発の妨げになります。一方で、パイプライン内では効率化したアプローチを活用できます。DevSecOpsでは通常、プロダクトバックログ管理など、アジャイル開発のプラクティスを取り入れます。システム全体を設計するのではなく、新機能や拡張機能をユーザーストーリーとしてバックログに追加します。こうした管理しやすい独立した要素が、迅速な開発を可能にします。脅威モデリングにも同じ考え方を適用できます。

脅威モデリングをモノリシックなアプリケーション全体に対して実施するプロセスと捉えるのではなく、バックログの段階でシンプルな脅威モデリングを実践できます。新しいユーザーストーリーを作成する際は、そのストーリーによって新たに発生する、または影響を受ける脅威についての簡単な説明も含めましょう。ストーリーに関わる機密性の高い機能やデータも特定します。この情報をバックログに記載して開発者が参照できるようにすれば、開発を実際に加速させながら脅威モデリングの役割を果たせます。

バージョン管理、メタデータ、オーケストレーション

自動化された環境では、変化だけが唯一の不変要素です。その変化は一貫性があり、追跡可能でなければなりません。すべての変更を追跡するため、DevSecOpsでは適切で変更不可能なバージョン管理を確保する必要があります。迅速な復旧を可能にするため、コードを管理するのと同様に、あらゆるアクションにバージョンを付与します。メタデータ化すれば、運用チームは変更を効率よく追跡し、測定できます。

オーケストレーションソフトウェアは、インフラを再現可能な方法でデプロイできるだけでなく、あらゆるタスクに関する豊富なメタデータも提供します。このメタデータは、オーケストレーションソフトウェア自体だけでなく、統合されたツールにとっても信頼できる情報源になります。バージョン管理と組み合わせることで、オーケストレーションソフトウェアはすべての運用チームにとって強力な情報源となります。

コンプライアンス

コンプライアンス施策は、紙ベースで進める必要はありません。組織はコンプライアンス要件を表すメタデータを作成し、アセットに直接組み込むことができます。また、アセットにタグを付けて望ましいセキュリティアーキテクチャ（ゾーニングなど）を実装するセキュリティポリシーの自動化にも活用できます。

このアプローチにより、大規模なコンプライアンス対応が可能になります。たとえば、新たなGDPRの規則に基づき、侵害発生から72時間以内に対応することも現実的になります。DevSecOpsでコンプライアンス要件をコード化すれば、開発プロセスがコンプライアンスプログラムを推進する役割を果たします。

セキュリティアーキテクチャ

セキュリティアーキテクチャは、各企業固有の一連の原則に基づいています。原則は処理するデータの種類によって異なりますが、ソフトウェアデリバリーをより安全なプラクティスへ導くために、ハイレベルな原則を活用できます。DevSecOpsモデルを採用する組織は、こうしたアーキテクチャを確立し、継続的に更新するプロセスを整備する必要があります。これにより、開発の迅速化とセキュリティ向上を実現できます。

DevSecOps文化の一環としてこれらの原則をコード化し、バックログで参照・確認できるようにすれば、プロダクトマネージャーは計画とそれを支えるアーキテクチャにセキュリティをシームレスに組み込めます。ビジネスプロセスやリソース不足が原因で逸脱が生じる場合は、その内容を記録し、関連するリスクを考慮します。こうした逸脱は最終的に、ほかのバグと同じ方法で対処し、解決まで追跡できます。

インシデント管理

セキュリティインシデントへの対応は、場当たり的、または無計画に行うべきではありません。ワークフロー、対応計画、プレイブック、ランブックを事前に作成することが重要です。これにより、一貫性があり、再現可能で、測定可能なインシデント対応を実現できます。インシデント管理ではメタデータを活用してプロセスを簡素化し、侵害されたアセットを再デプロイするまでの時間を重視する指標へと変更します。プレイブックを作成する際は、あらゆる種類のインシデントを対象とするプロセスを導入します。DevSecOpsがさまざまな機能を統合するように、それを実現するプロセスも統合されるべきです。そのため、インシデント管理プロセスには、運用インシデントとセキュリティインシデントを同じフレームワークで扱える抽象度が必要です。これは、DevSecOpsに不可欠な責任共有の文化を強化するもう一つの有効な取り組みです。

プレイブックをコード化したら、CI/CDパイプラインに統合して自動化できます。DevSecOpsの環境では、プロアクティブかつ先回りした脅威ハンティング、そして脅威や脆弱性の継続的な検出と対応により、重大なインシデントを減らし、軽減策を増やすことができます。ペネトレーションテスト、レッドチーム演習、バグ報奨金プログラムも、侵害リスクを軽減するための追加レイヤーとなります。継続的な検出は有効ですが、組織はアラート疲れに注意しなければなりません。そのため、監視の継続的な改善と、アラートの評価・対応の自動化を促すフィードバックループを確立しましょう。

プロアクティブなセキュリティ評価

組織のDevSecOps手法がどれほど高度になっても、脆弱性を積極的に特定する必要があります。ペネトレーションテストは、定められた範囲内で脆弱性を包括的に特定する取り組みを指す言葉としてよく使われます。レッドチーム演習は、実際の攻撃者の動機や戦術を模倣することに、より重点を置く点で異なります。たとえば、ペネトレーションテストではSQLインジェクション攻撃に脆弱なアプリケーションのページをすべて特定しようとする一方、レッドチーム評価では脆弱なページを1、2か所だけ特定し、その脆弱性を利用してアプリケーションへの攻撃をさらに進める場合があります。

ペネトレーションテスト

ペネトレーションテストは、アプリケーションの脆弱性管理において、成熟度を高める最初の段階となることがよくあります。テストの目的は、何らかの攻撃に対して脆弱である可能性のあるアプリケーション内の領域を特定することです。理想的には、セキュリティ態勢全体を包括的に把握し、リスクの高い脆弱性の修正を目指します。しかし、アプリケーション内の脆弱性を包括的に把握するには時間がかかります。そのためDevSecOpsでは、このテストはセキュリティ衛生の基本要件であるものの、通常は本番環境へのリリース後に実施されます。

レッドチーム演習

レッドチーム評価は、成熟度の高い組織で一般的に実施されています。ペネトレーションテストに追加して行うステップです。レッドチームのアプローチでは、できるだけ多くの脆弱性を見つけることが目的ではありません。攻撃者の手法により近い、目標ベースのアプローチを取ります。対象範囲は通常、単一のアプリケーションに限定されず、環境内のシステム全体に及びます。これにより、複数のシステムにある脆弱性を組み合わせて攻撃を成立させる方法を把握できます。また、攻撃が成功した場合に想定される影響について、より深い文脈を得られます。そのため、従来のペネトレーションテストより高度なスキルと幅広いスキルセットが求められます。DevSecOpsの取り組みが成熟するにつれて、定期的なセキュリティ衛生の一環としてレッドチーム演習を検討するとよいでしょう。

バグ報奨金プログラム

近年、バグ報奨金プログラムへの注目が高まっています。その一因として、クラウドソース型のバグ報奨金プログラムが利用できるようになったことが挙げられます。バグ報奨金プログラムでは、外部のハッカーが組織の環境内の脆弱性を特定するための対象範囲、報告要件、報告方法を定めます。ルールに従って報告したハッカーには、報告した脆弱性に対する「報奨金」が支払われます。

バグ報奨金は、外部の関係者に脆弱性を責任ある方法で報告するよう促す有効な手段であり、脆弱性を特定するための追加レイヤーにもなります。しかし、ペネトレーションテストの代わりとして頼るべきではありません。バグ報奨金プログラムに参加するセキュリティ研究者は、一般に組織の利益を最優先しているわけではありません。脆弱性を網羅的に特定することを目指しておらず、高額の報奨金につながる深刻度の高い脆弱性だけを探す人がほとんどです。

脅威インテリジェンス

環境を構成するコードが増え、コードとして定義・文書化されるにつれて、脅威インテリジェンスの可視性も高まります。多くの組織では、受け取った脅威インテリジェンスを環境内のアセットに効果的に結び付けられる形でITアセットを特定することに苦労しています。DevSecOpsパイプラインから脅威インテリジェンス機能へメタデータを渡すプロセスを構築すれば、組織は適切なインテリジェンスを収集し、リスクの優先度に応じて適切に活用・対応できます。