セキュリティ監査をアジャイルプロジェクトに統合するにはどうすればよいですか？
セキュリティ監査会社に実用的なシステムを提供し、監査を依頼する場合、費用がかかるためプロジェクト中に1回だけ行うと、これは基本的にウォーターフォールです。
セキュリティ監査をウォーターフォールプロジェクトに変えずにアジャイルプロジェクトに統合して、監査失敗リスクを導入するにはどうすればよいですか？
私たちがやりたいことは、詳細なセキュリティ要件を事前に知っていることです。これにより、それらのストーリーを作成（および/または既存のストーリーに統合）し、セキュリティ要件が持っているある程度の自信を与える自動テストを記述できます。満たされました。これはアジャイルな方法です。
しかし問題は、最初の本番デプロイメントがどのように見えるかが本番にデプロイされる直前まで正確にわからない場合、それはアジャイルプロジェクトであるため、セキュリティ監査会社に正確にどのように見えるかを伝えることができないことです。お気に入り。そのため、「任意のシステムに存在する可能性のある脆弱性の数は非常に多いため、絞り込むにはどのように見えるかを知っている必要があるため、どのように見えるかがわかったら戻ってきてください。あなたに要件を与えます。」その場合、アジャイルな方法でそれを行うことはできません。
アジャイルのセキュリティ開発ライフサイクル（SDL）に関するMicrosoftのガイドライン は、プロジェクトの設計、実装、およびリリース中のセキュリティ慣行を推奨しています。使用中の開発方法論に関係なく、セキュリティレビューが完了するまで、コードのどのラインもそれを本番環境にするべきではありません。財務上の制約により、このレベルのセキュリティレビューを専門家が行えない場合、リリースを確定する前に、セキュリティレビューを同僚が実施する必要があります。リリースを確定することは楽しいプロセスになる可能性があります。会社が全社的なハックを主催し、興味深いバグの賞品を配るのを見てきました。
MicrosoftはSDLで多くの作業を行い、Microsoftのセキュリティは向上しています。
簡単に言えば、ソフトウェア開発ライフサイクルにセキュリティを統合することです。設計、実装、およびテストのすべての段階に統合する必要があります。
ソフトウェア開発ライフサイクルにセキュリティを組み込む方法に関する多くのリソースがあります。たとえば、 CigitalのSDLC （7つのタッチポイント）]、 MicrosoftのSDLC 、 OpenSAMMのSDLCを参照してください。 、 [〜＃〜] bsimm [〜＃〜] 、 CERT's Build Security In 、またはこちらの質問 安全なソフトウェア開発 、 安全なソフトウェア開発環境の作成 、 など（または最も軽い）安全な開発ライフサイクル？ 、 どの安全な開発ライフサイクルモデルを選択するか 。
「セキュリティレビュー」は1つではありません。セキュリティレビューにはさまざまな形式があります。ソフトウェア開発ライフサイクルにセキュリティを統合するには、方法の各段階でセキュリティを考慮する必要があり、それらの異なる種類のセキュリティレビューは異なる意味を持ちます。これらの要素には次のものがあります。
設計に関連するアーキテクチャレベルのセキュリティリスクと、設計レベルの欠陥の可能性（Microsoftが「脅威モデリング」と呼んでいるもの）を理解するために、設計をレビューするセキュリティ設計レビューが必要です。デザインを変更する場合にのみ、実装を変更するたびにこれを再確認する必要はありません。
また、セキュリティコードのレビューも必要です。コードをレビューして、セキュリティを損なう可能性のある潜在的な実装レベルのコードの欠陥を特定してください。新しいコードを記述したり、既存のコードを変更したりするときはいつでも、実装のバグについてそのコードを確認する必要があります。
また、セキュリティをテスト作業に統合する必要があります。新しいバージョンをリリースする前に、特に変更された機能に焦点を当てて、そのセキュリティをテストすることができます。
セキュリティモデルがコードベース全体の特定時点の外部監査の概念に基づいている場合は、セキュリティが間違っています。
...そしておそらくあなたも監査を間違って使用しています。しかし、それについては後で説明します。
質問を超えて、セキュリティのためにすべてのコードを監査する必要があります。多くの場合、これは実際には法的要件です。監査期間なしにコードが出荷されることはありません。従来の知識では、そのような監査はライフサイクルのある時点でイベントであることが推奨されますが、より賢明な方法は、コードを監査することです。行く。つまり、すべてのコードは、コードベースにチェックインする前にbeforeのセキュリティ監査を受けます。
理論は単純です。リポジトリはすでに監査されているため、標準の手順としてコンポーネントを再監査する必要はありません。ただし、新しい機能、パッチ、またはバグ修正が提案された場合、適切なメンテナが差分を承認する必要があります。あなたにとって重要なものは何でもサインオフできます。たとえば、Linuxカーネルにはかなり複雑な承認プロセスがあり、品質、シンプルさ、一貫性、パフォーマンスなどの過程でいくつかの承認が必要です。要件は異なる場合がありますが、セキュリティ監査は、その承認プロセス。
この場合、製品をエンドツーエンドで監査するのではなく、差分を監査するだけです。しかし、製品の開発サイクルの過程で行われる何千もの小さな監査は、エンドツーエンドの監査よりもはるかに詳細で包括的なものになります。
完全な製品のエンドツーエンドの監査は確かに役立ち、避けるべきではありません。この監査は、これまで行ってきたパッチレベルの監査中に簡単ではない方法で、製品全体に焦点を当てる必要があります。個々の樹木だけでなく、森全体を時々見たいと思っています。これらの大規模な監査のタイミングは、おそらくメジャーリリース、メジャー変更、またはコンプライアンス認証監査に対応しているはずです。
しかし、パッチレベルの監査を最新に保つことにより、コードが常に検証可能な状態で維持されることを保証できるため、引き続き出荷できます。自信を持って定期的に。
コミット時の承認について
あなたの会社がこれをしていないなら、あなたはすべてを間違っているのです。初期開発中を含め、（特に）すべてのコード変更を少なくとも1人の他の人が承認することを要求することで解決される問題は数十、数百と考えられます。コードのすべての行がどのように機能するかを理解し、コードが正しいことに同意する少なくとも2人の人が常に必要です。
これは、少なくとも単体テストと同じくらい重要です。これを実行していない場合は、すべてを停止して、品質とセキュリティに関するポリシーに再度アクセスしてください。
はい、このプロセスはスケーリングします。上記のように、世界で最も俊敏で成功しているソフトウェア会社のいくつかがそうであるように、世界最大のソフトウェアプロジェクトはそれを使用します。
他の人が示唆したように、セキュリティに関するストーリーを組み込むことができます。そして私は確かにあなたがそうすることをお勧めします。
しかし、外部のチームが来て監査に数週間を費やしていることについて話しているのであれば、それは私にはセキュリティよりも俊敏性についてのようです。
アジャイルは頻繁に出荷することに重点を置いていることを知っています。結局のところ、ソフトウェアが顧客の手元にない場合、フィードバックサイクルをどのように短縮するのでしょうか。しかし、多くの組織にとって、2/3/4週間ごとにリリースすることは単に選択肢ではありません。または、QA/QCレビュープロセスが長く、QA組織はアジャイルに移行する準備ができていません。または、アジャイルライフサイクルに適合しない他の認定要件（ISOなど）があります。
その結果、多くのアジャイルチームは、リリースをイテレーションまたはスプリントから切り離す必要があることを早い段階で発見しました。
つまり、本番環境にプロモートするのではなく、セキュリティ/ QA /何でも専用の環境への変更をプロモートします。そこでコードが認定されたら、それを本番（または次のゲート）に昇格させます。
あなたが「誤用」の物語で構築しているなら、おそらくあなたの欠陥/問題リストは短いはずです。
欠陥が見つかった場合は、重大度に応じて、バックログに入れたり、優先順位を付けて即座に修正することができます。
もちろん、追加の環境は無料ではありませんが、私の経験では、他の環境よりも安価です（通常、チームが互いに足を踏み入れる結果になります）。
誤用ケースを追加します。
システムが示す必要のある機能がある場合は、ユースケースを使用します。システムが表示してはならない機能がある場合は、誤用ケースを使用してください。
「競合他社として、データベースのバックエンドに会社の機密データを問い合わせたいのですが、これは起こらないはずです。」
「私はハクティビストとして、DMZを使用して政府への攻撃を反映させたいと思います。これは起こらないはずです。」.
製品の所有者はこれらのストーリーを他のストーリーと一緒に優先することができますが、他のユーザーストーリーと同様にテストできます。
（私はアジャイルの秘密の謎の初心者ではないことを自由に認めます。アジャイルはメイソンの77階級のようなものになりました。不可解な恐怖を恐れて、破られるべきではない謎と戒めに満ちています）。
ウォーターフォールプロジェクトのように、リリースごとに監査を行うことができます。これを行うことでいくつかの問題を指摘しましたが、多くのセキュリティ会社はアジャイルプロジェクトで非常に効果的に作業できます。ただし、頻繁にリリースする場合、そのコストは非常に高くなる可能性があります。
別のアプローチは、テストを社内に移動することです。スキャンツールを購入すると、独自の監査を実行できます。専門のセキュリティ会社ほど完全ではないかもしれませんが、好きなだけ実行できます。おそらく、それらを夜間ビルドシステムと統合するか、継続的統合を使用して事前コミットフックで実行することもできます。これらのツールには、主に2つのタイプがあります。自動侵入テストである動的アプリケーションセキュリティテスト（DAST）と、自動化されたソースコードレビューである静的アプリケーションセキュリティテスト（SAST）です。 SASTの利点は、結果が開発者の用語で報告されることです：ソースコードファイルと行番号。 DAST/SASTテストツールはアジャイルモデルに非常によく合うと思います。ある意味では、それらはセキュリティの単体テストです。
成熟したセキュリティプロセスを持つ開発チームは、社内テストとサードパーティテストの両方を使用します。 SAST/DASTは、すべてのコードが少なくとも基本的なセキュリティレビューを確実に取得し、問題を早期に発見するために使用されます。侵入テストは定期的に実行され、自動テストでは特定できない複雑な問題を検出しようとします。これは、固定されたスケジュールで行われる場合もあれば、各リリースの変更を見てリスクベースで行われる場合もあります。
あなたの質問はセキュリティ監査についてでした。もちろん、アプリケーションのセキュリティには他の側面もあります。セキュリティを確保するための脅威のモデリングが設計に反映されます。セキュリティを促進する開発ツールとフレームワークを選択し、開発者にこれらのツールを安全に使用するためのトレーニングを提供します。これはウォーターフォール開発の場合と同じですが、アジャイルでは、セキュリティチームを定期的に参加させるよりも、これらのスキルを開発チームに組み込むことが重要です。