構成管理と脆弱性の管理

構成管理と脆弱性の管理には、アプリケーションのパッチ発行および更新、バージョン管理、不具合の追跡と修正、インシデント処理が含まれます。

構成管理と脆弱性の管理レベル1

[CMVM1.1: 101] インシデント対応の作成または調整。

SSGは、独自にインシデント対応機能を作成したり、組織の既存のチームと定期的に連絡を取ったりして、インシデントに対応する体制を整え、インシデント対応プロセスに定期的に参加します。SSGとインシデント対応チームの間で定期的に打ち合わせをすることで、双方向の情報の流れを維持できます。クラウド・サービス・プロバイダーを参加させる必要がある場合もあります。多くの場合、SSIは、ソフトウェアの脆弱性によって、自分たちの存在が脅かされることに気が付き始めたインシデント対応チームから発展しています。

[CMVM1.2: 102] 運用監視中に検出されたソフトウェア・バグを特定し、開発担当者にフィードバックとして返す。

運用監視中に検出された不具合は、開発担当者にフィードバックとして返されて、開発者の行動を変えるために使用されます。運用環境のログの内容から問題が判明する可能性があります(またはロギングを改善する必要が明らかになる場合があります)。インシデント行動順位決定データを既存のバグ追跡システムに入力する方法を提供する(特別なセキュリティ・フラグを使用する)ことが有効な場合もあります。重要なことは情報ループを閉じて、セキュリティ問題が修正されることです。最善のケースとしては、運用データを基にしてSSDLのプロセスを改善できます。  

構成管理と脆弱性の管理レベル2

[CMVM2.1: 82] 緊急時のコードベースの対応方法が準備されている。

アプリケーションが攻撃されたときにすばやくコードを変更できます。緊急対応チームは、アプリケーション所有者やSSGと共同でコードと攻撃を調査し、解決策を特定し、パッチを運用環境に適用します。多くの場合、特にアジャイル開発方法が使用されている場合は、開発者自身が緊急対応チームになります。非常訓練ではなく、詳細に定義されたプロセスが必要になります。今まで一度も使用されていなかったプロセスは、実際には役に立ちません。

[CMVM2.2: 87] 運用環境で検出されたバグを、修正プロセスで追跡する。

運用環境で検出されたバグは開発者にフィードバックとして返され、既存の不具合管理システムに入力され、修正プロセス中、追跡されます。これを可能にするには、バグ検出担当者とバグ修正担当者の間で双方向のコミュニケーションが必要です。ループが完全に閉じていることを確認します。バグ追跡システム内でセキュリティ・フラグを設定すれば、追跡が容易になります。

[CMVM2.3: 57] アプリケーションの運用環境インベントリを作成する。

組織には、ソフトウェア・デプロイメントのマップがあります。コードを変更する必要が発生した場合、実稼働環境または開発・運用チームは変更をインストールする必要がある箇所をすべて確実に特定できます。複数のプロジェクトの間で共有される共通のコンポーネントについては、あるアプリケーションでエラーが発生した場合に、同じコンポーネントを共有する他のアプリケーションも修正できるよう印を付けます。オープンソース・コンポーネントもコンポーネントであることを意識しておいてください。

構成管理と脆弱性の管理 レベル3

[CMVM3.1: 5] 運用環境で検出されたすべてのソフトウェア・バグを修正する。

組織は、バグ報告がトリガーされた少量の箇所だけでなく、運用環境で検出されたすべてのバグを修正します。これには、新しい種類のバグが検出されたときにコードベース全体を再調査する能力が必要になります。([CR3.3 コードベース全体から特定のバグを修正する能力の開発])を参照してください。これを可能にする方法の1つとしては、自動化されたコード・レビューを使用するためにスキャンでき、デプロイされたバグを総合するルール・セットを作成することです。

[CMVM3.2: 7] 運用環境で検出されたソフトウェア・バグを防止するためSSDLを強化する。

運用環境からの経験を基にSSDLを変更できます。これにより、運用中に検出されたバグの再発生を防止するよう強化されます。このプロセスを体系的に実行するために、各インシデント事後対応に「SSDLにフィードバックする」手順を含めることができます。これは、根本原因解析によって、SDLCのどこでエラーが発生した、またはキャッチされなかったかを特定できる場合に最適です。すべての関係者が参加している、部門を超えたDevOpsチームが存在する場合に適しています。アドホックなアプローチでは十分ではありません。

[CMVM3.3: 9] ソフトウェア・クライシスをシミュレートする。

SSGは、ソフトウェア・インシデント対応能力によって損害が最小限に抑えられるよう、影響の大きいソフトウェア・セキュリティ・クライシスをシミュレートします。シミュレーションによって、特定の脅威を特定し、影響を低減する能力を検証できます。重要なシステムまたはサービスがすでに被害を受けていることを想定し、それに対する組織の対応能力を評価する場合もあります。シミュレーション・モデルによって攻撃がモデル化できたら、どれぐらいの期間で後処理ができるかという点が重要になります。どのような場合も、シミュレーションでは、自然災害や他の種類の非常時対応訓練ではなく、セキュリティに関連するソフトウェアの障害に注目する必要があります。たとえば、データ・センターが全焼した場合の緊急対応チームは、SSGではありません。

[CMVM3.4: 13] バグ検出プログラムを運用する。

組織は、外部の調査会社に脆弱性報告の作成を依頼し、検証され、合意された脆弱性ごとに報酬を支払います。料金は、脆弱性の種類(リモート・コード実行には$10,000かかるのに対し、CSRFは$750です)、悪用の可能性(悪用パターンをデモで見せることができる場合は料金が高くなります)、または特定のサービスおよびソフトウェア・バージョン(一般的にデプロイされている、または重要なサービスでは料金が高くなります)などの複数の要因を基に変動制で決められます。フラグ取得コンテストなどの一時的な、または短期のアクティビティは含まれません。