ソフトウェア製品を初期段階(SDLC)から安全にするアプリケーション脅威モデリングについて読みました。しかし、展開フェーズで何か問題が発生した場合でも、それが問題になります。
たとえば、システム管理者は、製品で必要とされていないファイアウォールのポートを開きます。
では、展開時間の脅威を特定するために使用できる方法論はありますか?
通常、ここで行うことは、何らかの形式のテスト手順を展開または展開後のプロセスに統合することです。
これは、不注意で開いたままになっているポートを特定できる単純なポートスキャンのように軽量な場合もあれば、サードパーティと契約して展開されたシステムのセキュリティを確認する完全なサードパーティのセキュリティ評価(侵入テスト)の場合もあります。
あなたがしたい最大のことは、あなたの期待が何であるかを理解し、そして伝えることです。セキュリティモデルでファイアウォールポートを開くことが禁止されている場合、それは文書化されていますか? (余談ですが、ファイアウォールの背後にいるために安全であると期待する場合は、再考することをお勧めしますが、それを例として使用していると思います。)
「セキュリティ操作ガイド」またはコード(たとえば、スクリプト「check_security」またはクラウドスキャナー)で文書化して検証できます。どちらにも用途があり、ガイドは期待を文書化して議論するための良い方法ですが、コードのスケーリングは向上します。
一連の明確な期待が得られたら、それらを検証する方法はたくさんあります。
通常、コードは、本番環境に移行する前に、製品前/ステージング環境の脆弱性に対してテストおよび修正されます。はい、すべての環境が同じというわけではないので、私が取ったいくつかの対策は、Splunk(別名ログ相関ツール)を使用して展開を監視し、展開後{x}時間Webアクティビティと相関させています。 Splunkでのこの相関関係とアラートは、デプロイメントに関する異常なトラフィックとパターンを見つけるのに役立ちました。つまり、エラーの突然の急増、不適切なキャッシュによるメモリの急増などです。
ランタイムアプリケーション自己保護(RASP)を提供するコントラストセキュリティのようなツールもあります。これらは通常、たとえばIISに直接統合され、攻撃をブロックします。IPSまたはWAFとは異なります。