これは漠然とした質問ですが、チームがセキュリティを継続的デリバリー/展開とどのように統合しているかに関するブログや情報を探しています。AWSに1日に複数回デプロイしており、チームがフローにセキュリティを追加する方法を探しています。
チームがキュウリを使用してnmapテストを行ったプレゼンテーションを見たことがあります。これは私が探しているものではありませんが、トラフィックを受け入れるロードバランサーに入る前に、アプリノードがデプロイされた後の自動テストである可能性があります。
これは漠然とした質問ですが、チームがセキュリティを継続的デリバリー/展開とどのように統合しているかに関するブログや情報を探しています。AWSに1日に複数回デプロイしており、チームがフローにセキュリティを追加する方法を探しています。
チームがキュウリを使用してnmapテストを行ったプレゼンテーションを見たことがあります。これは私が探しているものではありませんが、トラフィックを受け入れるロードバランサーに入る前に、アプリノードがデプロイされた後の自動テストである可能性があります。
私の最後の会社である LMAX では、セキュリティ機能を他の機能と同様に扱い、それらの機能の受け入れテストを自動化しました。
システムの他のユーザーと同じチャネルを介してシステムとやり取りする受け入れテストを作成し、システムのセキュリティ規定が期待どおりに機能することを証明しました。
そのため、あるテストでは、ログオンが成功した場合、システムの他の機能が使用可能であると断言できます。別の人は、ログオンに失敗した場合、セキュリティで保護された機能にアクセスできなかったと主張するでしょう - 本当に簡単です.
秘訣は、受け入れテストが実際のユーザーと同じ通信チャネルを介してシステムと対話すること、またはアプリケーションのメイン ロジックへの特別なトリックや裏口、特に裏技やバックドアがないことを確認することです。 -セキュリティ機能をバイパスできるドア;-)
ログオンは些細な例ですが、このアプローチはあらゆるユーザー レベルのセキュリティ機能 (実際にはあらゆる機能) に適用できます。
もちろん、バッファオーバーフローのチェック、SQL インジェクションなど、他のクラスのセキュリティ問題もあります。これの多くは、アプリケーションを安全に設計することに関するものです。たとえば、アプリケーションを階層化して責任を明確に分離します。
アプリケーションに適している場合は、これらのクラスのセキュリティ要件のテストを受け入れテストに含めることもできます。または、展開パイプラインに追加のステップを追加して、これらの種類の露出のテストを実行することもできます。これはアプリケーションの性質によって異なります。おそらく、ほとんどのアプリの受け入れテストに追加し、インジェクションを試行するテストケースを自動生成できるアプリ専用のパイプライン ステージ アプローチを採用します。たとえば、すべての入力フィールドについて Web アプリを検索します。ゴミを注入しようとしていますか?
これはあなたが探しているものではないかもしれませんが、効果的なセキュリティ テストの鍵は、設計時や実装などで製品に組み込むことです。アプリケーションのすべてのレベルで、単体テストと同じようにセキュリティ テストをコーディングします。このアプローチを使用すると、セキュリティ テストは一般的なアプリケーション テストと変わりません。
事前にパッケージ化されたセキュリティ テストは優れているため、使用する必要があります (ほとんどの組織は QA チェックの直前にこれを行います) が、組み込みのテストほど効果的ではありません。これは、開発者のようにセキュリティの「危険ゾーン」を知っている人は誰もいないためです (または、少なくともそうすべきです。彼らが本を読んでいない場合は。Web アプリについては、「The Web Application Hacker's Handbook」を強くお勧めします。他のアプリC/C++ を使用していない場合でも、Robert Seacord による "Secure Coding in C and C++"をお勧めします. Seacord の本の第 2 版が4 月に出ますのでお待ちください)。
設計時に考慮しない限り、セキュリティは有効になりません。すでに失敗している場合は、セキュリティ テストを通常のアプリ テストに統合してみてください。
編集:
Web アプリに対して (順不同で) 実行する、いくつかの優れた既定のスキャナー (スピーチとして無料のもの、ビールとして無料のもの、まったく無料ではないもの) があります。これらは一般的な既存の脆弱性を検出しますが、Web アプリに固有の脆弱性は検出しません。
Mozillaでこれに取り組む方法は、OWASP ZAPを介して(機能的な)回帰テストをプロキシし、REST APIを介してすべて制御できるZAPスパイダー、アクティブおよびパッシブスキャナーを使用することです。
このプロセスに関するビデオを録画しました:http ://www.youtube.com/watch?v = ZWSLFHpg1SoそしてZAPwikiに詳細があります:http ://code.google.com/p/zaproxy/wiki/ SecRegTests
このアプローチにより、セキュリティツール(この場合はZAP)は、アプリケーションの使用方法を「学習」することができ、一般に、単なるスパイダリングよりも効果的です。
もちろん、自動スキャンは潜在的な脆弱性のサブセットのみを検出しますが、セキュリティ担当者がより「興味深い」問題に集中できることを意味します:)