構成管理と脆弱性の管理

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

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

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

SSGは、独自にインシデント対応機能を作成したり、組織の既存のチームと定期的に連絡を取ったりして、イベントやアラートに対応する体制を整え、インシデント対応プロセスに定期的に参加します。SSGとインシデント対応チームの間で定期的に打ち合わせをすることで、双方向の情報の流れを維持できます。重要なベンダー(インフラストラクチャ、SaaSなど)との通信チャネルを事前に構築することも非常に重要です。

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

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

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

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

アプリケーションが攻撃されたときにすばやくコードを変更できます。緊急対応チームは、アプリケーション所有者やSSGと共同でコードと攻撃を調査し、解決策を特定し、運用環境のコードを修正(パッチを運用環境に適用する、既知の正常なバージョンにロールバックする、新しいコンテナをデプロイするなど)します。多くの場合、エンジニアリング・チーム自身が緊急対応チームになります。ここでは詳細に定義されたプロセスが必要になります。今まで一度も使用されていなかったプロセスは、実際には役に立ちません。

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

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

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

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

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

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

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

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

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

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

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

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

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

[CMVM3.5: 0] 運用インフラストラクチャのセキュリティ検証を自動化する。

SSGはエンジニアリング・チームと協力して、アプリケーションやインフラストラクチャの展開などの従来のITの仕事に代わる制御されたセルフサービス・プロセスを促進し、セキュリティ属性の検証(合意されたセキュリティ強化など)を作業に含めます。エンジニアは、ネットワーク、コンテナ、マシンのインスタンス作成やデプロイの調整、および以前には専らITの役割であったその他のタスクを担うようになりました。この変更を容易にするために、組織は機械読み取り可能なポリシーとコンフィギュレーション標準を利用して、期待に満たないインフラストラクチャを自動的に検出して報告します。場合によっては、コンプライアンスを実現するために、実行中の環境に自動化によって変更を加えます。多くの場合、組織はマルチクラウド環境やハイブリッド・クラウド環境などのさまざまな環境で単一のポリシーを使用して自動化を管理します。