セキュリティ ドメイン: 運用セキュリティ

運用セキュリティ ドメインは、ISV が脅威アクターから直面する無数の脅威に対して強力なセキュリティ軽減手法を実装することを保証します。 これは、安全な環境を構築するために、運用環境とソフトウェア開発プロセスを保護するように設計されています。

認識トレーニング

セキュリティ意識のトレーニングは、セキュリティ侵害の 90% 以上に関与する人的エラーに起因するリスクを最小限に抑えるのに役立つため、組織にとって重要です。 これは、従業員がセキュリティ対策と手順の重要性を理解するのに役立ちます。 セキュリティ認識トレーニングが提供されると、潜在的な脅威を認識して対応する方法をユーザーが知っているセキュリティ対応カルチャの重要性が強化されます。 効果的なセキュリティ認識トレーニング プログラムには、ソーシャル エンジニアリング、パスワード管理、プライバシー、物理的なセキュリティなど、ユーザーが直面する可能性があるさまざまなトピックと脅威をカバーするコンテンツを含める必要があります。

コントロール No. 1

次の証拠を提供してください。

• 組織は、情報システム ユーザー (マネージャー、上級幹部、請負業者を含む) に対して、確立されたセキュリティ認識トレーニングを提供します。

  • 新規ユーザー向けの初期トレーニングの一環として。

  • 情報システムの変更で必要な場合。

• 組織が定義した認識トレーニングの頻度。

• 個々の情報システムのセキュリティ認識アクティビティを文書化および監視し、組織が定義した頻度で個々のトレーニング レコードを保持します。

意図: 新しいユーザーのトレーニング

このサブポイントでは、役割に関係なく、すべての従業員と組織に参加する新入社員向けに設計された必須のセキュリティ意識向上トレーニング プログラムを確立することに重点を置いています。 これには、マネージャー、上級幹部、請負業者が含まれます。 セキュリティ認識プログラムには、組織のすべてのメンバーが統一されたセキュリティ標準セットに準拠し、回復力のある情報セキュリティ環境を作成するために、組織の情報セキュリティ プロトコル、ポリシー、ベスト プラクティスに関する基本的な知識を付与するように設計された包括的なカリキュラムが含まれている必要があります。

ガイドライン: 新規ユーザー向けのトレーニング

ほとんどの組織は、プラットフォームベースのセキュリティ認識トレーニングと、ポリシー ドキュメントやレコードなどの管理ドキュメントを組み合わせて利用して、組織全体のすべての従業員のトレーニングの完了を追跡します。 提供された証拠は、従業員がトレーニングを完了したことを示す必要があります。これは、セキュリティ意識の要件を示すサポート ポリシー/手順でバックアップする必要があります。

証拠の例: 新しいユーザーのトレーニング

次のスクリーンショットは、新入社員のオンボードを追跡するために使用されている Confluence プラットフォームを示しています。 新しい従業員の割り当て、役割、部署など、JIRA チケットが発行されました。新しいスターター プロセスでは、セキュリティ意識トレーニングが選択され、2023 年 2 月 28^日 の期日までに完了する必要がある従業員に割り当てられます。

スクリーンショットは、従業員がセキュリティ認識トレーニングを正常に完了したときに Knowb4 によって生成された完了証明書を示しています。 完了日は、割り当てられた期間内の 2023 年 2 月 21^日 です。

意図: 情報システムの変更。

このサブポイントの目的は、組織の情報システムに大きな変更が加えられたときに、アダプティブ セキュリティ認識トレーニングが開始されるようにすることです。 変更は、ソフトウェアの更新、アーキテクチャの変更、または新しい規制要件によって発生する可能性があります。 更新されたトレーニング セッションでは、すべての従業員に新しい変更とその結果がセキュリティ対策に与える影響について通知され、それに応じてアクションと意思決定を適応できるようになります。 このプロアクティブなアプローチは、組織のデジタル資産を、システムの変更によって生じる可能性のある脆弱性から保護するために不可欠です。

ガイドライン: 情報システムの変更。

ほとんどの組織では、プラットフォームベースのセキュリティ認識トレーニングと、ポリシー ドキュメントやレコードなどの管理ドキュメントを組み合わせて、すべての従業員のトレーニングの完了を追跡します。 提供される証拠は、組織のシステムに対するさまざまな変更に基づいて、さまざまな従業員がトレーニングを完了したことを示す必要があります。

証拠の例: 情報システムの変更。

次のスクリーンショットは、さまざまな従業員へのセキュリティ認識トレーニングの割り当てを示し、フィッシング シミュレーションが発生することを示しています。

プラットフォームは、システムの変更が発生したとき、またはテストが失敗するたびに、新しいトレーニングを割り当てるために使用されます。

意図: 認識トレーニングの頻度。

このサブポイントの目的は、定期的なセキュリティ認識トレーニングの組織固有の頻度を定義することです。 これは、毎年、半期、または組織によって異なる間隔でスケジュールできます。 頻度を設定することで、組織は、進化する脅威の状況や、新しい保護対策とポリシーに関するユーザーが定期的に更新されるようにします。 このアプローチは、すべてのユーザーの間で高レベルのセキュリティ意識を維持し、以前のトレーニング コンポーネントを強化するのに役立ちます。

ガイドライン: 認識トレーニングの頻度。

ほとんどの組織には、セキュリティ認識トレーニングの要件と手順の概要と実装、およびトレーニングの頻度を定義するための管理ドキュメントや技術ソリューションが用意されています。 提供される証拠は、定義された期間内にさまざまな認識トレーニングを完了し、組織によって定義された期間が存在することを示す必要があります。

証拠の例: 認識トレーニングの頻度。

次のスクリーンショットは、セキュリティ認識ポリシーのドキュメントのスナップショットと、それが存在し、維持されていることを示しています。 このポリシーでは、ポリシーのスコープ セクションで説明されているように、組織のすべての従業員がセキュリティ認識トレーニングを受ける必要があります。 トレーニングは、関連部門によって年単位で割り当てられ、完了する必要があります。

ポリシー ドキュメントによると、組織のすべての従業員は、毎年 3 つのコース (1 つのトレーニングと 2 つの評価) を、割り当てから 20 日以内に完了する必要があります。 コースは電子メールで送信し、KnowBe4 を通じて割り当てる必要があります。

提供される例は、ポリシーのスナップショットのみを示しています。完全なポリシー ドキュメントが送信されることを想定しています。

2 番目のスクリーンショットは、ポリシーの継続であり、年次トレーニング要件を義務付けるドキュメントのセクションを示しており、組織が定義した認識トレーニングの頻度が毎年に設定されていることを示しています。

次の 2 つのスクリーンショットは、前に説明したトレーニング評価が正常に完了したことを示しています。 スクリーンショットは、2 人の異なる従業員から撮影されました。

意図: ドキュメントと監視。

このサブポイントの目的は、セキュリティ認識トレーニングへの各ユーザーの参加に関する詳細な記録を作成、維持、監視することです。 これらのレコードは、組織が定義した期間にわたって保持する必要があります。 このドキュメントは、規制と内部ポリシーに準拠するための監査可能な証跡として機能します。 監視コンポーネントを使用すると、組織は、

トレーニング、改善のための領域を特定し、ユーザー エンゲージメント レベルを理解します。 定義された期間にわたってこれらのレコードを保持することで、組織は長期的な有効性とコンプライアンスを追跡できます。

ガイドライン: ドキュメントと監視。

セキュリティ認識トレーニングに提供できる証拠は、組織レベルでのトレーニングの実装方法によって異なります。 これには、トレーニングがプラットフォームを介して実行されるか、社内プロセスに基づいて内部的に実行されるかが含まれます。 提供された証拠は、一定期間にわたってすべてのユーザーに対して完了したトレーニングの履歴レコードが存在し、これを追跡する方法を示す必要があります。

証拠の例: ドキュメントと監視。

次のスクリーンショットは、参加日、トレーニングの完了、次のトレーニングのスケジュールなど、各ユーザーの履歴トレーニング レコードを示しています。 このドキュメントの評価は、各従業員のセキュリティ意識のトレーニング 記録が最新の状態に保たれるように、定期的かつ少なくとも年に 1 回実行されます。

マルウェア保護/マルウェア対策

マルウェアは組織に重大なリスクをもたらし、マルウェアの特性に応じて、運用環境に対するセキュリティへの影響が異なる可能性があります。 脅威アクターは、マルウェアが正常に収益化できることを認識しました。これは、ランサムウェア スタイルのマルウェア攻撃の増加によって実現されています。 マルウェアは、脅威アクターが環境を侵害して機密データ (リモート アクセストロイの木馬/ルートキット) を盗むイングレス ポイントを提供するためにも使用できます。 そのため、組織は、これらの脅威から保護するための適切なメカニズムを実装する必要があります。 使用できる防御は、ウイルス対策 (AV)/エンドポイント検出と応答 (EDR)/エンドポイント検出と保護応答 (EDPR)/人工知能 (AI) を使用したヒューリスティック ベースのスキャンです。 マルウェアのリスクを軽減する別の手法を展開している場合は、認定アナリストに、これが意図を満たしているかどうかを確認するユーザーを知らせてください。

コントロール No. 2

マルウェア対策ソリューションがアクティブであり、サンプリングされたすべてのシステム コンポーネントで有効になっており、次の条件を満たすように構成されていることを示す証拠を提供してください。

• オンアクセス スキャンが有効で、署名が 1 日以内に最新であるウイルス対策。

• マルウェアが検出されたときにマルウェアまたはアラートと検疫を自動的にブロックするウイルス対策

または、EDR/EDPR/NGAV の場合:

• 定期的なスキャンが実行されていること。

• は監査ログを生成しています。

• は継続的に最新の状態に保たれ、自己学習機能があります。

• これは、既知のマルウェアをブロックし、マクロの動作に基づいて新しいマルウェアバリアントを識別およびブロックするだけでなく、完全な許容機能を持っています。

意図: オンアクセス スキャン

このサブポイントは、マルウェア対策ソフトウェアがサンプリングされたすべてのシステム コンポーネントにインストールされ、オンアクセス スキャンをアクティブに実行していることを確認するように設計されています。 また、このコントロールでは、マルウェア対策ソリューションの署名データベースが 1 日の期間内に最新の状態に保たれていることも義務付けられています。 最新のシグネチャ データベースは、最新のマルウェアの脅威を特定して軽減し、システム コンポーネントが適切に保護されるようにするために重要です。

ガイドライン: オンアクセス スキャン**.**

評価された環境で AV のアクティブ なインスタンスが実行されていることを示すために、マルウェア対策の使用をサポートするアナリストと合意したサンプル セット内のすべてのデバイスのスクリーンショットを提供します。 スクリーンショットは、マルウェア対策が実行されていることと、マルウェア対策ソフトウェアがアクティブであることを示しているはずです。 マルウェア対策の一元管理コンソールがある場合は、管理コンソールから証拠が提供される可能性があります。 また、サンプリングされたデバイスが接続され、動作していることを示すスクリーンショットを必ず提供してください。

証拠の例: オンアクセス スキャン**.**

次のスクリーンショットは、Windows Server デバイスから取得され、ホスト名 "IaaS-Web-app" に対して "Microsoft Defender" が有効になっていることを示しています。

次のスクリーンショットは、Windows Server デバイスから取得され、Microsoft Defender マルウェア対策セキュリティ インテリジェンスのバージョンが Windows イベント ビューアーからログを更新したことを示しています。 これは、ホスト名 "IaaS-Web-app" の最新の署名を示しています。

このスクリーンショットは、Microsoft Defender マルウェア対策保護の更新プログラムを示す Windows Server デバイスから取得されています。 これにより、脅威定義のバージョン、上に作成されたバージョン、および最後の更新プログラムが明確に表示され、マルウェア定義がホスト名 "IaaS-Web- アプリ" の最新の状態であることを示します。

意図: マルウェア対策ブロック。

このサブポイントの目的は、マルウェア対策ソフトウェアが、検出時にマルウェアを自動的にブロックするか、アラートを生成し、検出されたマルウェアを安全な検疫領域に移動するように構成されていることを確認することです。 これにより、脅威が検出されたときに直ちにアクションが実行され、脆弱性の期間が短縮され、システムの強力なセキュリティ体制が維持されます。

ガイドライン: マルウェア対策ブロック。

マルウェア対策の使用をサポートするサンプル内のすべてのデバイスのスクリーンショットを提供します。 スクリーンショットは、マルウェア対策が実行されており、マルウェア、アラート、または検疫とアラートを自動的にブロックするように構成されていることを示しているはずです。

証拠の例: マルウェア対策ブロック。

次のスクリーンショットは、Microsoft Defender マルウェア対策の場合、ホスト "IaaS-Web-app" が ON としてリアルタイム保護で構成されていることを示しています。 設定が示すように、これにより、マルウェアがデバイスにインストールまたは実行されるのを見つけて停止します。

意図: EDR/NGAV

このサブポイントは、エンドポイント検出と応答 (EDR) または次世代ウイルス対策 (NGAV) が、サンプリングされたすべてのシステム コンポーネントで定期的なスキャンを積極的に実行していることを確認することを目的としています。監査ログは、スキャン アクティビティと結果を追跡するために生成されます。スキャン ソリューションは継続的に更新され、新しい脅威の状況に適応するための自己学習機能を備えています。

ガイドライン: EDR/NGAV

EDR/NGAV ソリューションのスクリーンショットを提供して、サンプリングされたシステムのすべてのエージェントがレポートを作成し、その状態がアクティブであることを示します。

証拠の例: EDR/NGAV

OpenEDR ソリューションの次のスクリーンショットは、ホスト "IaaS-Web-app" のエージェントがアクティブでレポート中であることを示しています。

OpenEDR ソリューションの次のスクリーンショットは、リアルタイム スキャンが有効になっていることを示しています。

次のスクリーンショットは、システム レベルでインストールされたエージェントからリアルタイムで取得された動作メトリックに基づいてアラートが生成されることを示しています。

OpenEDR ソリューションの次のスクリーンショットは、監査ログとアラートの構成と生成を示しています。 2 番目の画像は、ポリシーが有効になっており、イベントが構成されていることを示しています。

OpenEDR ソリューションの次のスクリーンショットは、ソリューションが継続的に最新の状態に保たれていることを示しています。

意図: EDR/NGAV

このサブポイントの焦点は、EDR/NGAV が既知のマルウェアを自動的にブロックし、マクロの動作に基づいて新しいマルウェアバリアントを特定してブロックする機能を持っていることを確認することです。 また、ソリューションに完全な承認機能があることを保証し、組織が信頼できるソフトウェアを許可しながら他のすべてをブロックし、セキュリティのレイヤーを追加できるようにします。

ガイドライン: EDR/NGAV

使用されるソリューションの種類に応じて、ソリューションの構成設定と、ソリューションに Machine Learning/ヒューリスティック機能があること、および検出時にマルウェアをブロックするように構成されていることを示す証拠を提供できます。 構成がソリューションに既定で実装されている場合は、ベンダーのドキュメントで検証する必要があります。

証拠の例: EDR/NGAV

OpenEDR ソリューションの次のスクリーンショットは、セキュリティで保護されたプロファイル v7.4 が、リアルタイム スキャンを適用し、マルウェアをブロックし、検疫するように構成されていることを示しています。

Secure Profile v7.4 構成の次のスクリーンショットは、既知のマルウェアシグネチャをスキャンする従来のマルウェア対策アプローチに基づく "リアルタイム" スキャンと、中レベルに設定された "ヒューリスティック" スキャンの両方を実装していることを示しています。 このソリューションでは、疑わしい、予期しない、または悪意のある方法で動作するファイルとコードを確認することで、マルウェアを検出して削除します。

スキャナーは、アーカイブを解凍して内部のファイルをスキャンするように構成され、アーカイブの下で自身をマスクしている可能性がある潜在的なマルウェアを検出します。さらに、スキャナーは Microsoft Office ファイル内のマイクロ スクリプトをブロックするように構成されています。

次のスクリーンショットは、Secure Profile v.7.4 が Windows Server デバイス 'IaaS-Web-app' ホストに割り当てられていることを示しています。

次のスクリーンショットは、Windows Server デバイス 'IaaS-Web-app' から取得されました。これは、OpenEDR エージェントが有効になっており、ホスト上で実行されていることを示しています。

マルウェア保護/アプリケーション制御

アプリケーション制御は、データを危険にさらす方法で、承認されていないアプリケーションの実行をブロックまたは制限するセキュリティ プラクティスです。 アプリケーション制御は企業のセキュリティ プログラムの重要な部分であり、悪意のあるアクターがアプリケーションの脆弱性を悪用するのを防ぎ、侵害のリスクを軽減するのに役立ちます。 アプリケーション制御を実装することで、アプリケーションがネットワークや機密データを危険にさらした場合にアプリケーションの実行が防止されるため、企業や組織は、アプリケーションの使用に関連するリスクと脅威を大幅に削減できます。 アプリケーション制御は、運用チームとセキュリティ チームに、サイバー リスクを軽減するための信頼性の高い標準化された体系的なアプローチを提供します。 また、IT およびセキュリティ組織がサイバー リスクを効果的に管理するのに役立つ、環境内のアプリケーションの全体像を組織に提供します。

コントロール No. 3

以下を示す証拠を提出してください。

• ビジネス上の正当な理由を持つソフトウェア/アプリケーションの承認済みリストがあります。

  • は存在し、最新の状態に保たれ、

  • 各アプリケーションが承認プロセスを受け、デプロイの前にサインオフする。

• このアプリケーション制御テクノロジは、文書化されているように、サンプリングされたすべてのシステム コンポーネントにわたってアクティブ、有効、および構成されています。

意図: ソフトウェアの一覧

このサブポイントは、承認されたソフトウェアとアプリケーションのリストが組織内に存在し、継続的に最新の状態に保たれることを目的としています。 リストの各ソフトウェアまたはアプリケーションに、その必要性を検証するための文書化されたビジネス上の正当な理由があることを確認します。 この一覧は、ソフトウェアとアプリケーションの展開を規制するための権限のあるリファレンスとして機能するため、セキュリティ リスクを生じる可能性のある未承認または冗長なソフトウェアの排除に役立ちます。

ガイドライン: ソフトウェアの一覧

デジタル ドキュメント (Word、PDF など) として管理されている場合に、ソフトウェアとアプリケーションの承認済みリストを含むドキュメント。 承認されたソフトウェアとアプリケーションのリストがプラットフォームを介して管理されている場合は、プラットフォームのリストのスクリーンショットを提供する必要があります。

証拠の例: ソフトウェア リスト

次のスクリーンショットは、承認されたソフトウェアとアプリケーションの一覧が Confluence Cloud プラットフォームで維持されていることを示しています。

次のスクリーンショットは、要求元、要求日、承認者、承認日、承認日、制御メカニズム、JIRA チケット、システム/資産など、承認されたソフトウェアとアプリケーションの一覧が維持されていることを示しています。

意図: ソフトウェアの承認

このサブポイントの目的は、各ソフトウェア/アプリケーションが組織内での展開の前に正式な承認プロセスを受け取っていることを確認することです。 承認プロセスには、技術的評価とエグゼクティブ サインオフが含まれており、運用と戦略的な両方の観点が考慮されていることを確認する必要があります。 この厳格なプロセスを実施することで、組織は、検証済みの必要なソフトウェアのみをデプロイし、セキュリティの脆弱性を最小限に抑え、ビジネス目標との整合性を確保します。

ガイドライン

承認プロセスに従っていることを示す証拠を提供できます。 これは、署名されたドキュメント、変更制御システム内での追跡、または Azure DevOps/JIRA などを使用して変更要求と承認を追跡することによって提供される場合があります。

証拠の例

次のスクリーンショットは、JIRA Software の完全な承認プロセスを示しています。 ユーザー 'Jane Doe' が、'IaaS-Web-app' サーバーと 'IaaS-VM- Backend' サーバーに 'Qualys Cloud Agent をインストールすることを許可する' という要求を発行しました。 "Andrew Smith" は要求をレビューし、"マルウェア対策のビジネスニーズに基づいて承認されました" というコメントで承認しました。 Qualys によって提供される更新プログラムとパッチ。 承認されるソフトウェア。

次のスクリーンショットは、アプリケーションを運用サーバー上で実行できるようにする前に、Confluence プラットフォームで発行されたチケットを介して承認が付与されていることを示しています。

意図: アプリ制御テクノロジ

このサブポイントでは、アプリケーション制御テクノロジがアクティブであり、有効になり、サンプリングされたすべてのシステム コンポーネントで正しく構成されていることを確認することに重点を置いています。 テクノロジが文書化されたポリシーと手順に従って動作することを確認します。これは、実装とメンテナンスのガイドラインとして機能します。 アクティブ、有効、および適切に構成されたアプリケーション制御テクノロジを使用することで、組織は、承認されていないソフトウェアまたは悪意のあるソフトウェアの実行を防ぎ、システムの全体的なセキュリティ体制を強化するのに役立ちます。

ガイドライン: アプリ制御テクノロジ

アプリケーション制御のセットアップ方法を詳しく説明するドキュメントと、各アプリケーション/プロセスがどのように構成されているかを示す該当するテクノロジからの証拠を提供します。

証拠の例: アプリ制御テクノロジ

次のスクリーンショットは、Windows グループ ポリシー (GPO) が、承認されたソフトウェアとアプリケーションのみを適用するように構成されていることを示しています。

次のスクリーンショットは、パス制御を介して実行できるソフトウェア/アプリケーションを示しています。

注: これらの例では、完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、ログインしているユーザーとシステムの時刻と日付を示す全画面スクリーンショットである必要があります。

パッチ管理/パッチ適用とリスクのランク付け

パッチ管理は、多くの場合、パッチ適用と呼ばれ、堅牢なサイバーセキュリティ戦略の重要な要素です。 これには、ソフトウェア、オペレーティング システム、アプリケーションにパッチまたは更新プログラムを特定、テスト、適用する体系的なプロセスが含まれます。 パッチ管理の主な目的は、セキュリティの脆弱性を軽減し、システムとソフトウェアが潜在的な脅威に対して回復性を維持できるようにすることです。 さらに、パッチ管理には、パッチの優先順位付けの重要な要素であるリスクランク付けが含まれます。 これには、脆弱性の重大度と、組織のセキュリティ体制への潜在的な影響に基づいて脆弱性を評価することが含まれます。 脆弱性にリスク スコアを割り当てることで、組織はリソースを効率的に割り当てることができ、新たな脅威に対する積極的な姿勢を維持しながら、重要でリスクの高い脆弱性への迅速な対処に重点を置くことができます。 効果的なパッチ管理とリスクランク付け戦略は、セキュリティを強化するだけでなく、IT インフラストラクチャの全体的な安定性とパフォーマンスにも貢献し、進化し続けるサイバーセキュリティの脅威に対する組織の回復力を維持するのに役立ちます。

安全なオペレーティング環境を維持するには、アプリケーション/アドオンとサポート システムに適切なパッチが適用されている必要があります。 脅威アクターによって脆弱性が悪用される機会を減らすために、識別 (またはパブリック リリース) と修正プログラムの間の適切な期間を管理する必要があります。 Microsoft 365 認定資格は、"修正プログラム適用ウィンドウ" を規定していません。ただし、認定アナリストは、妥当でない期間、または業界のベスト プラクティスに沿った期間を拒否します。 このセキュリティ制御グループは、アプリケーション/アドインのサード パーティ製ソフトウェア ライブラリとコード ベースにリスクのランク付けに基づいて修正プログラムを適用する必要があり、サービスとしてのプラットフォーム (PaaS) ホスティング環境のスコープでもあります。

コントロール No. 4

パッチ管理ポリシーと手順に関するドキュメントで、次のすべてを定義する証拠を提供します。

• 重大/高および中程度のリスクの脆弱性に適した最小限のパッチ適用期間。

• サポートされていないオペレーティング システムとソフトウェアの使用停止。

• 新しいセキュリティの脆弱性を特定し、リスク スコアを割り当てる方法。

意図: パッチ管理

パッチ管理は、PCI-DSS、ISO 27001、NIST (SP) 800-53、FedRAMP、SOC 2 など、多くのセキュリティ コンプライアンス フレームワークで必要です。 適切なパッチ管理の重要性を強調することはできません

ソフトウェア、ファームウェアのセキュリティと機能の問題を修正し、脆弱性を軽減できるため、悪用の機会の削減に役立ちます。 このコントロールの目的は、脅威アクターが持つ機会の期間を最小限に抑え、スコープ内環境内に存在する可能性のある脆弱性を悪用することです。

パッチ管理ポリシーと手順に関するドキュメントを提供します。このドキュメントでは、次の側面が包括的に説明されています。

• 重大/高および中程度のリスクの脆弱性に適した最小限のパッチ適用期間。

• 組織のパッチ管理ポリシーと手順に関するドキュメントでは、重大/高および中程度のリスクとして分類された脆弱性に適した最小限のパッチ適用期間を明確に定義する必要があります。 このような規定は、脆弱性の識別後にパッチを適用する必要がある最大許容時間を、そのリスク レベルに基づいて確立します。 これらの時間枠を明示的に指定することで、組織はパッチ管理へのアプローチを標準化し、パッチが適用されていない脆弱性に関連するリスクを最小限に抑えました。

• サポートされていないオペレーティング システムとソフトウェアの使用停止。

パッチ管理ポリシーには、サポートされていないオペレーティング システムとソフトウェアの使用停止に関するプロビジョニングが含まれています。 セキュリティ更新プログラムを受信しなくなったオペレーティング システムとソフトウェアは、組織のセキュリティ体制に重大なリスクを与えます。 したがって、この制御により、ポリシードキュメントで定義されているように、そのようなシステムが適時に識別および削除または交換されます。

• 新しいセキュリティの脆弱性を特定し、リスク スコアを割り当てる方法を示す文書化された手順。

パッチ適用はリスクに基づいている必要があります。脆弱性のリスクが高いほど、修復が迅速に行われる必要があります。 特定された脆弱性のリスクランク付けは、このプロセスの不可欠な部分です。 この制御の目的は、特定されたすべての脆弱性がリスクに基づいて適切にランク付けされるように、文書化されたリスクランク付けプロセスが確実に実行されるようにすることです。 組織は通常、ベンダーまたはセキュリティ研究者によって提供される共通脆弱性スコアリング システム (CVSS) レーティングを利用します。 組織が CVSS に依存している場合は、組織が内部リスク評価に基づいてランク付けを変更できるように、プロセス内に再ランク付けメカニズムを含めることをお勧めします。 アプリケーションが環境内にデプロイされている方法によって、この脆弱性が適用されない場合があります。 たとえば、組織が使用していない特定のライブラリに影響を与える Java の脆弱性がリリースされる可能性があります。

注: 純粋なプラットフォームでサービス 'PaaS/Serverless' 環境で実行している場合でも、コード ベース内の脆弱性 (サードパーティ製ライブラリなど) を特定する責任があります。

ガイドライン: パッチ管理

ポリシー ドキュメントを指定します。 特定のコントロールのすべての要素をカバーする組織の定義されたプロセスを詳しく説明するポリシーや手順のドキュメントなどの管理上の証拠を提供する必要があります。

注: 論理的な証拠は、組織の脆弱性管理プログラム (VMP) に関するさらなる洞察を提供するサポート証拠として提供できますが、このコントロールは単独では満たされません。

証拠の例: パッチ管理

次のスクリーンショットは、パッチ管理/リスクランク付けポリシーのスニペットと、さまざまなレベルのリスク カテゴリを示しています。 その後に分類と修復の時間枠が続きます。 注: ISV は、実際のサポート ポリシー/手順のドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

ポリシー ドキュメントをサポートする追加の技術的証拠の例 (省略可能)

脆弱性追跡スプレッドシート、脆弱性技術評価レポート、オンライン管理プラットフォームを通じて発生したチケットのスクリーンショットなどの論理的な証拠により、提供されるポリシー ドキュメントに記載されているプロセスの実装をサポートするために使用される脆弱性の状態と進行状況を追跡します。 次のスクリーンショットは、ソフトウェア構成分析 (SCA) ツールである Snyk を使用して、コード ベースの脆弱性をスキャンすることを示しています。 その後、電子メールによる通知が送信されます。

注: これらの例では完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、ログインしているユーザーとシステムの時刻と日付を示す完全なスクリーンショットである必要があります。

次の 2 つのスクリーンショットは、新しい脆弱性に Snyk によってフラグが設定されたときに受信した電子メール通知の例を示しています。 影響を受けたプロジェクトと、アラートを受信するための割り当てられたユーザーが含まれている電子メールを確認できます。

次のスクリーンショットは、特定された脆弱性を示しています。

注: 前の例では、完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、URL、ログインしているユーザーとシステムの時刻と日付を示す完全なスクリーンショットである必要があります。

証拠の例

次のスクリーンショットは、GitHub セキュリティ ツールが構成され、コード ベース内の脆弱性をスキャンするために有効にされ、アラートが電子メールで送信されていることを示しています。

次に示す電子メール通知は、フラグが設定された問題がプル要求によって自動的に解決されることを確認します。

証拠の例

次のスクリーンショットは、スプレッドシートを使用した内部の技術的評価と脆弱性のランク付けを示しています。

証拠の例

次のスクリーンショットは、検出された脆弱性ごとに DevOps で発生したチケットを示しています。

変更を実装する前に、別の従業員による評価、ランク付け、レビューが行われます。

コントロール No. 5

次の実証可能な証拠を提供します。

1. サンプリングされたすべてのシステム コンポーネントにパッチが適用されます。

2. サポートされていないオペレーティング システムとソフトウェア コンポーネントが使用されていないことを示す証拠を提供します。

意図: サンプリングされたシステム コンポーネント

このサブポイントは、組織内のすべてのサンプリングされたシステム コンポーネントに積極的にパッチが適用されていることを確認するために、検証可能な証拠が確実に提供されることを目的としています。 証拠には、パッチ管理ログ、システム監査レポート、またはパッチが適用されたことを示す文書化された手順が含まれますが、これらに限定されません。 サーバーレス テクノロジまたはサービスとしてのプラットフォーム (PaaS) が採用されている場合は、最新で安全なバージョンのライブラリと依存関係が使用されていることを確認するために、コード ベースを含むように拡張する必要があります。

ガイドライン: サンプリングされたシステム コンポーネント

サンプル内のすべてのデバイスのスクリーンショットを提供し、文書化されたパッチ適用プロセスに沿ってパッチがインストールされていることを示すソフトウェア コンポーネントをサポートします。 さらに、コード ベースのパッチ適用を示すスクリーンショットを提供します。

証拠の例: サンプリングされたシステム コンポーネント

次のスクリーンショットは、Linux オペレーティング システム仮想マシン 'IaaS- VM-Backend' のパッチ適用を示しています。

証拠の例

次のスクリーンショットは、Windows オペレーティング システム仮想マシン 'IaaS-Web-app' のパッチ適用を示しています。

証拠の例

Microsoft Intune、Defender for Cloud などの他のツールから修正プログラムを維持している場合は、これらのツールからスクリーンショットを提供できます。 OpenEDR ソリューションの次のスクリーンショットは、OpenEDR ポータルを介してパッチ管理が実行されることを示しています。

次のスクリーンショットは、スコープ内サーバーのパッチ管理が OpenEDR プラットフォームを介して行われることを示しています。 分類と状態は、パッチ適用が行われることを示す下に表示されます。

次のスクリーンショットは、サーバーに正常にインストールされたパッチのログが生成されることを示しています。

証拠の例

次のスクリーンショットは、コード ベースまたはサード パーティのライブラリの依存関係に Azure DevOps 経由でパッチが適用されていることを示しています。

次のスクリーンショットは、Snyk によって検出された脆弱性の修正が、古いライブラリを解決するためにブランチにコミットされていることを示しています。

次のスクリーンショットは、ライブラリがサポートされているバージョンにアップグレードされたことを示しています。

証拠の例

次のスクリーンショットは、コード ベースのパッチが GitHub Dependabot を介して維持されていることを示しています。 閉じた項目は、修正プログラムが発生し、脆弱性が解決されたことを示します。

意図: サポートされていない OS

ベンダーによって管理されていないソフトウェアは、残業、修正されていない既知の脆弱性に苦しんでいます。 そのため、サポートされていないオペレーティング システムとソフトウェア コンポーネントを運用環境で使用しないでください。 サービスとしてのインフラストラクチャ (IaaS) がデプロイされている場合、このサブポイントの要件は、インフラストラクチャとコード ベースの両方を含むように拡張され、テクノロジ スタックのすべてのレイヤーが、サポートされているソフトウェアの使用に関する組織のポリシーに準拠していることを確認します。

ガイドライン: サポートされていない OS

アナリストが選択したサンプル セット内のすべてのデバイスのスクリーンショットを指定して、実行中の OS のバージョンを示す証拠を収集します (スクリーンショットにはデバイス/サーバーの名前を含めます)。 これに加えて、環境内で実行されているソフトウェア コンポーネントがサポートされているバージョンのソフトウェアを実行していることを示します。 これは、内部脆弱性スキャン レポートの出力 (認証済みスキャンが含まれている場合) や、Snyk、Trivy、NPM 監査などのサード パーティ製ライブラリをチェックするツールの出力を提供することで行うことができます。 PaaS で実行する場合は、サード パーティ製ライブラリの修正プログラムのみを対象にする必要があります。

証拠の例: サポートされていない OS

Azure DevOps NPM 監査の次のスクリーンショットは、サポートされていないライブラリ/依存関係が Web アプリ内で利用されていないことを示しています。

注: 次の例では、完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、URL、ログインしているユーザーとシステムの時刻と日付を示す完全なスクリーンショットである必要があります。

証拠の例

GitHub Dependabot の次のスクリーンショットは、Web アプリ内でライブラリ/依存関係が使用されていないことを示しています。

証拠の例

OpenEDR を使用した Windows オペレーティング システムのソフトウェア インベントリの次のスクリーンショットは、サポートされていないオペレーティング システムまたは古いオペレーティング システムとソフトウェアのバージョンが見つからなかったことを示しています。

証拠の例

次のスクリーンショットは、Windows Server 2019 Datacenter (x64) と OS の完全なバージョン履歴 (Service Pack、ビルド バージョンなど) を示す OS の概要の下にある OpenEDR からのスクリーンショットです。 サポートされていないオペレーティング システムが見つからなかったことを検証します。

証拠の例

Linux オペレーティング システム サーバーの次のスクリーンショットは、ディストリビューター ID、説明、リリース、Codename など、サポートされていない Linux オペレーティング システムが見つからなかったことを検証するすべてのバージョンの詳細を示しています。

証拠の例:

Nessus 脆弱性スキャン レポートの次のスクリーンショットは、サポートされていないオペレーティング システム (OS) とソフトウェアがターゲット コンピューターに見つからなかったことを示しています。

注: 前の例では完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、URL、ログインしたユーザーとシステムの時刻と日付を示す完全なスクリーンショットである必要があります。

脆弱性スキャン

脆弱性スキャンは、組織のコンピューター システム、ネットワーク、Web アプリケーションで考えられる弱点を探して、セキュリティ侵害や機密データの漏洩につながる可能性のある穴を特定します。 脆弱性スキャンは、多くの場合、PCI DSS (ペイメント カード業界データ セキュリティ標準) などの業界標準や政府の規制で必要になります。

「PCI DSS コンプライアンスに関する 2020 セキュリティ メトリック ガイド」と題されたセキュリティ メトリックのレポートには、「組織が攻撃者がシステムを侵害する脆弱性が見られた時点から平均して 166 日かかった」と記載されています。 侵害されると、攻撃者は平均 127 日間機密データにアクセスできるため、このコントロールは、スコープ内環境内の潜在的なセキュリティの弱点を特定することを目的としています。

組織は、定期的な脆弱性評価を導入することで、環境内の弱点や脆弱性を検出でき、悪意のあるアクターが環境を侵害するエントリ ポイントを提供する可能性があります。 脆弱性スキャンは、環境内で不足しているパッチや構成の誤りを特定するのに役立ちます。 これらのスキャンを定期的に実行することで、組織は適切な修復を提供して、これらの脆弱性スキャン ツールによって一般的に取り上げられる問題による侵害のリスクを最小限に抑えることができます。

コントロール No. 6

以下を示す証拠を提出してください。

• 四半期ごとのインフラストラクチャと Web アプリケーションの脆弱性スキャンが実行されます。

• 環境が IaaS、ハイブリッド、またはオンプレミスの場合は、パブリック フットプリント全体 (IP/URL) と内部 IP 範囲に対してスキャンを実行する必要があります。

注: これには、環境の完全な範囲が含まれている必要があります。

意図: 脆弱性スキャン

この制御は、組織がインフラストラクチャと Web アプリケーションの両方を対象として、四半期ごとに脆弱性スキャンを実行することを目的としています。 スキャンは包括的で、パブリック IP や URL などのパブリック フットプリントと内部 IP 範囲の両方をカバーする必要があります。 スキャンの範囲は、組織のインフラストラクチャの性質によって異なります。

• 組織がハイブリッド、オンプレミス、またはサービスとしてのインフラストラクチャ (IaaS) モデルを実装する場合、スキャンには外部パブリック IP/URL と内部 IP 範囲の両方が含まれている必要があります。

• 組織がサービスとしてのプラットフォーム (PaaS) を実装する場合、スキャンには外部パブリック IP/URL のみを含める必要があります。

また、このコントロールでは、スキャンに環境の完全な範囲を含める必要があり、コンポーネントのチェックは解除されません。 目的は、組織のテクノロジ スタックのすべての部分の脆弱性を特定して評価し、包括的なセキュリティを確保することです。

ガイドライン: 脆弱性スキャン

過去 12 か月間に実行された四半期ごとの脆弱性スキャンのフル スキャン レポートを提供します。 レポートには、完全なパブリック フットプリントが含まれており、該当する場合は各内部サブネットが含まれていることを検証するためのターゲットが明確に記載されている必要があります。 四半期ごとにすべてのスキャン レポートを提供します。

証拠の例: 脆弱性スキャン

次のスクリーンショットは、セキュリティで保護されていない開いているポートを識別するために、外部インフラストラクチャで Nmap 経由で実行されるネットワーク検出とポート スキャンを示しています。

注: 完全な脆弱性スキャンを提供する必要があると予想されるため、このコントロールを満たすために Nmap を単独で利用することはできません。 Nmap ポート検出は、以下に示す脆弱性管理プロセスの一部であり、外部インフラストラクチャに対する OpenVAS および OWASP ZAP スキャンによって補完されます。

このスクリーンショットは、構成ミスや未解決の脆弱性を特定するために、OpenVAS を介した外部インフラストラクチャに対する脆弱性スキャンを示しています。

次のスクリーンショットは、動的なアプリケーション セキュリティ テストを示す OWASP ZAP の脆弱性スキャン レポートを示しています。

証拠の例: 脆弱性スキャン

Nessus Essentials の脆弱性スキャン レポートの次のスクリーンショットは、内部インフラストラクチャスキャンが実行されていることを示しています。

前のスクリーンショットは、ホスト VM に対する四半期ごとのスキャン用のフォルダーのセットアップを示しています。

上と下のスクリーンショットは、脆弱性スキャン レポートの出力を示しています。

次のスクリーンショットは、見つかったすべての問題をカバーするレポートの継続を示しています。

コントロール No. 7

以下を示す再スキャン証拠を提供してください。

• コントロール 6 で特定されたすべての脆弱性の修復は、ポリシーで定義されている最小限のパッチ適用期間に合わせて修正されます。

意図: パッチ適用

脆弱性や構成の誤りをすばやく特定、管理、修復できないと、侵害のリスクが高くなり、潜在的なデータ侵害につながる可能性があります。 問題を正しく特定して修復することは、ISO 27001 や PCI DSS など、さまざまなセキュリティ フレームワークのベスト プラクティスに沿った組織の全体的なセキュリティ体制と環境にとって重要と見なされます。

この制御の目的は、組織が再スキャンの信頼できる証拠を確実に提供し、コントロール 6 で特定されたすべての脆弱性が修復されたことを実証することです。 修復は、組織のパッチ管理ポリシーで定義されている最小限のパッチ適用期間と一致している必要があります。

ガイドライン: パッチ適用

コントロール 6 で特定された脆弱性が、コントロール 4 で定義されているパッチ適用ウィンドウに沿って修復されたことを検証する再スキャン レポートを提供します。

証拠の例: 修正プログラムの適用

次のスクリーンショットは、2023 年 8 月 2^日の脆弱性を示すスコープ内環境 (この例では Thor という名前の 1 台のマシン) ^の Nessus スキャンを示しています。

次のスクリーンショットは、問題が解決されたことを示しています。2 日後、パッチ適用ポリシー内で定義された修正プログラムウィンドウ内にあります。

注: 前の例では、完全なスクリーンショットは使用されませんでしたが、すべての ISV が送信されました

証拠のスクリーンショットは、URL、ログインユーザー、システムの時刻と日付を示す完全なスクリーンショットである必要があります。

ネットワーク セキュリティ制御 (NSC)

ネットワーク セキュリティ制御は、ISO 27001、CIS コントロール、NIST サイバーセキュリティ フレームワークなどのサイバー セキュリティ フレームワークの不可欠なコンポーネントです。 組織がサイバー脅威に関連するリスクを管理し、機密データを不正アクセスから保護し、規制要件に準拠し、サイバー脅威をタイムリーに検出して対応し、ビジネス継続性を確保するのに役立ちます。 効果的なネットワーク セキュリティは、組織内外からの広範な脅威から組織の資産を保護します。

コントロール No. 8

次の実証可能な証拠を提供します。

• ネットワーク セキュリティ制御 (NSC) は、スコープ内環境の境界にインストールされ、境界ネットワークと内部ネットワークの間にインストールされます。

ハイブリッド、オンプレミス、IaaS の場合、次の証拠も提供されます。

• すべてのパブリック アクセスは境界ネットワークで終了します。

意図: NSC

このコントロールは、ネットワーク セキュリティ制御 (NSC) が組織のネットワーク トポロジ内の重要な場所にインストールされていることを確認することを目的としています。 具体的には、NSC をスコープ内環境の境界に配置し、境界ネットワークと内部ネットワークの間に配置する必要があります。 この制御の目的は、組織のデジタル資産を保護する効果を最大化するために、これらのセキュリティ メカニズムが正しく位置していることを確認することです。

ガイドライン: NSC

ネットワーク セキュリティ制御 (NSC) が境界にインストールされ、境界ネットワークと内部ネットワークの間で構成されていることを示す証拠を提供する必要があります。 これは、ネットワーク セキュリティ コントロール (NSC) の構成設定のスクリーンショットと、ファイアウォールや Azure ネットワーク セキュリティ グループ (NSG)、Azure Front Door などの同等のテクノロジに適用されるスコープを提供することで実現できます。

証拠の例: NSC

次のスクリーンショットは、Web アプリ 'PaaS-web-app' からのスクリーンショットです。[ネットワーク] ブレードは、すべての受信トラフィックが Azure Front Door を通過している一方で、アプリケーションから他の Azure リソースへのすべてのトラフィックが、VNET 統合を介して Azure NSG 経由でルーティングおよびフィルター処理されていることを示しています。

"アクセス制限" 内の拒否規則により、Front Door (FD) を除く受信が禁止され、トラフィックはアプリケーションに到達する前に FD 経由でルーティングされます。

証拠の例: NSC

次のスクリーンショットは、Azure Front Door の既定のルートと、アプリケーションに到達する前にトラフィックが Front Door 経由でルーティングされることを示しています。 WAF ポリシーも適用されています。

証拠の例: NSC

最初のスクリーンショットは、受信トラフィックと送信トラフィックをフィルター処理するために VNET レベルで適用された Azure ネットワーク セキュリティ グループを示しています。 2 番目のスクリーンショットは、SQL サーバーがインターネット経由でルーティングされず、VNET とプライベート リンクを介して統合されていることを示しています。

これにより、内部トラフィックと通信が、SQL サーバーに到達する前に NSG によってフィルター処理されます。

Intent**:** ハイブリッド、オンプレミス、IaaS

このサブポイントは、ハイブリッド、オンプレミス、またはサービスとしてのインフラストラクチャ (IaaS) モデルを運用する組織にとって不可欠です。 すべてのパブリック アクセスが境界ネットワークで終了することを確認することを目指しています。これは、内部ネットワークへの侵入ポイントを制御し、外部の脅威にさらされる可能性を減らす上で重要です。 コンプライアンスの証拠には、ファイアウォール構成、ネットワーク アクセス制御リスト、またはパブリック アクセスが境界ネットワークを超えて拡張されないという要求を立証できるその他の同様のドキュメントが含まれる場合があります。

証拠の例: ハイブリッド、オンプレミス、IaaS

このスクリーンショットは、SQL サーバーがインターネット経由でルーティング可能ではなく、VNET とプライベート リンクを介して統合されていることを示しています。 これにより、内部トラフィックのみが許可されます。

証拠の例: ハイブリッド、オンプレミス、IaaS

次のスクリーンショットは、スコープ内仮想ネットワーク内でネットワークセグメント化が行われていることを示しています。 次に示すように、VNET は 3 つのサブネットに分割され、それぞれ NSG が適用されます。

パブリック サブネットは境界ネットワークとして機能します。 すべてのパブリック トラフィックはこのサブネットを介してルーティングされ、特定のルールを持つ NSG 経由でフィルター処理され、明示的に定義されたトラフィックのみが許可されます。 バックエンドは、パブリック アクセスのないプライベート サブネットで構成されます。 すべての VM アクセスは、サブネット レベルで独自の NSG が適用されている Bastion ホスト経由でのみ許可されます。

次のスクリーンショットは、インターネットから特定の IP アドレスへのトラフィックがポート 443 でのみ許可されていることを示しています。 さらに、RDP は Bastion IP 範囲から仮想ネットワークへのみ許可されます。

次のスクリーンショットは、バックエンドがインターネット経由でルーティングできない (これは NIC のパブリック IP がないため)、トラフィックが仮想ネットワークと Bastion からのみ許可されていることを示しています。

このスクリーンショットは、メンテナンス目的でのみ Azure Bastion ホストを使用して仮想マシンにアクセスすることを示しています。

コントロール No. 9

• すべてのネットワーク セキュリティ制御 (NSC) は、規則ベース内で明示的に定義されていないトラフィックを削除するように構成されます。

• ネットワーク セキュリティ制御 (NSC) ルール レビューは、少なくとも 6 か月ごとに実行されます。

意図: NSC

このサブポイントにより、組織内のすべてのネットワーク セキュリティ制御 (NSC) が、規則ベース内で明示的に定義されていないネットワーク トラフィックを削除するように構成されます。 目的は、許可されたトラフィックのみを許可し、すべての不特定または潜在的に悪意のあるトラフィックをブロックすることで、ネットワーク 層で最小特権の原則を適用することです。

ガイドライン: NSC

これに対して提供される証拠は、受信規則を示す規則構成と、これらの規則が終了する場所である可能性があります。パブリック IP アドレスをリソースにルーティングするか、受信トラフィックの NAT (ネットワーク アドレス変換) を指定します。

証拠の例: NSC

このスクリーンショットは、既定のルール セットと、すべての NSG の既定のルールをリセットし、すべてのトラフィックが禁止されていることを確認するカスタム の Deny:All ルールを含む NSG 構成を示しています。 追加のカスタム ルールでは、 Deny:All ルールによって許可されるトラフィックが明示的に定義されています。

証拠の例: NSC

次のスクリーンショットは、Azure Front Door がデプロイされ、すべてのトラフィックが Front Door を介してルーティングされることを示しています。 "防止モード" の WAF ポリシーが適用され、潜在的な悪意のあるペイロードの受信トラフィックがフィルター処理され、ブロックされます。

意図: NSC

定期的なレビューがないと、ネットワーク セキュリティコントロール (NSC) が古くなり、効果がなくなり、組織はサイバー攻撃に対して脆弱になる可能性があります。 これにより、データ侵害、機密情報の盗難、およびその他のサイバー セキュリティ インシデントが発生する可能性があります。 定期的な NSC レビューは、リスクの管理、機密データの保護、規制要件への準拠、サイバー脅威の検出と対応をタイムリーに行い、ビジネス継続性を確保するために不可欠です。 このサブポイントでは、ネットワーク セキュリティ制御 (NSC) が少なくとも 6 か月ごとにルール ベース レビューを受ける必要があります。 NSC 構成の有効性と関連性を維持するために、特に動的に変化するネットワーク環境では、定期的なレビューが重要です。

ガイドライン: NSC

提供された証拠は、ルール レビュー会議が発生していることを示す必要があります。 これは、NSC レビューの会議の議事録と、レビューから行われたアクションを示す追加の変更管理証拠を共有することで行うことができます。 申請を確認する認定アナリストは、これらの会議の少なくとも 2 つのレビュー ドキュメント (つまり、6 か月ごとに) を確認する必要があります。日付が存在することを確認してください。

証拠の例: NSC

これらのスクリーンショットは、6 か月間のファイアウォール レビューが存在し、詳細が Confluence Cloud プラットフォームで維持されていることを示しています。

次のスクリーンショットは、すべてのルール レビューに Confluence で作成されたページがあることを示しています。 ルール レビューには、許可されるトラフィック、ポート番号、プロトコルなどを、ビジネス上の正当な理由と共に示す承認済みのルール セット リストが含まれています。

証拠の例: NSC

次のスクリーンショットは、DevOps で保守されている 6 か月間のルール レビューの別の例を示しています。

証拠の例: NSC

このスクリーンショットは、DevOps でルール レビューが実行され、チケットとして記録される例を示しています。

前のスクリーンショットは、確立された文書化されたルールリストとビジネス上の正当な理由を示しています。次の画像は、実際のシステムからのチケット内のルールのスナップショットを示しています。

変更コントロール

確立され理解された変更制御プロセスは、すべての変更が反復可能な構造化されたプロセスを確実に通過するために不可欠です。 すべての変更が構造化されたプロセスを経ることで、組織は、サインオフされる前に、変更が効果的に管理され、ピア レビューされ、適切にテストされていることを確認できます。 これは、システム停止のリスクを最小限に抑えるだけでなく、不適切な変更が導入されることによる潜在的なセキュリティ インシデントのリスクを最小限に抑えるのにも役立ちます。

コントロール No. 10

以下を示す証拠を提出してください。

運用環境に導入された変更は、文書化された変更要求を通じて実装されます。

• 影響を受けます。

• バックアウト手順の詳細。

• テストを実行する必要があります。

• 承認された担当者によるレビューと承認を行います。

意図: 変更コントロール

このコントロールの目的は、要求された変更が慎重に検討され、文書化されていることを確認することです。 これには、変更がシステム/環境のセキュリティに与える影響の評価、問題が発生した場合の復旧に役立つバックアウト手順の文書化、変更の成功を検証するために必要なテストの詳細が含まれます。

適切な承認とサインオフなしで行われる変更を禁止するプロセスを実装する必要があります。 実装する前に変更を承認する必要があり、変更が完了したらサインオフする必要があります。 これにより、変更要求が適切にレビューされ、権限のあるユーザーが変更をサインオフします。

ガイドライン: 変更制御

変更要求のサンプルのスクリーンショットを共有することで、変更の影響の詳細、バックアウト手順、テストが変更要求内で保持されていることを示す証拠を提供できます。

証拠の例: 変更コントロール

次のスクリーンショットは、新しいクロスサイト スクリプティング脆弱性 (XSS) が割り当てられ、変更要求のドキュメントを示しています。 以下のチケットは、解決の過程でチケットに設定または追加された情報を示しています。

次の 2 つのチケットは、システムへの変更の影響と、問題が発生した場合に必要になる可能性があるバックアウト手順を示しています。 変更とバックアウト手順の影響は承認プロセスを経て、テストのために承認されています。

次のスクリーンショットでは、変更のテストが承認され、右側に変更が承認され、テストされていることがわかります。

プロセス全体を通じて、仕事をしている人は、その仕事を報告する人と、実行する作業を承認する人は異なる人であることに注意してください。

次のチケットは、運用環境への実装に対する変更が承認されたことを示しています。 右側のボックスは、テストが機能し、成功し、変更が Prod Environment に実装されたことを示しています。

証拠の例

次のスクリーンショットは、開発者/要求者以外のユーザーによって実装および承認される前に変更を承認する必要があることを示す Jira チケットの例を示しています。 変更は、権限を持つユーザーによって承認されます。 スクリーンショットの右側は、変更が完了すると DP によって署名されたことを示しています。

変更後のチケットでは、完了するとサインオフされ、ジョブが完了して閉じられた状態が表示されます。

注: - これらの例では完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、ユーザーとシステムの時刻と日付を示す URL を示す完全なスクリーンショットである必要があります。

コントロール No. 11

次の証拠を提供してください。

次のことができるように、個別の環境が存在します。

• 開発およびテスト/ステージング環境では、運用環境からの職務の分離が強制されます。

• 職務の分離は、アクセス制御によって強制されます。

• 機密性の高い運用データは、開発またはテスト/ステージング環境内では使用されません。

意図: 個別の環境

ほとんどの組織の開発/テスト環境は、運用環境と同じ活力に構成されていないため、安全性が低くなります。 さらに、セキュリティの問題が発生したり、顧客のサービス提供に悪影響を受けたりする可能性があります。 組織は、職務の分離を強制する個別の環境を維持することで、変更が適切な環境に適用されていることを確認できるため、開発環境/テスト環境を対象とした変更を運用環境に実装することで、エラーのリスクを軽減できます。

アクセス制御は、開発とテストを担当する担当者が運用環境に不要なアクセス権を持たないように構成する必要があります。また、その逆も同様です。 これにより、未承認の変更やデータ公開の可能性が最小限に抑えられます。

開発環境/テスト環境で運用データを使用すると、侵害のリスクが高くなり、組織がデータ侵害や未承認のアクセスにさらされる可能性があります。 この意図では、開発またはテストに使用されるすべてのデータをサニタイズ、匿名化、またはその目的のために特別に生成する必要があります。

ガイドライン: 個別の環境

開発/テスト環境と運用環境で使用されているさまざまな環境を示すスクリーンショットを提供できます。 通常、各環境にアクセスできるユーザーやチームが異なる場合や、アクセスできない場合は、異なる承認サービスを使用して、ユーザーが間違った環境に誤ってログインして変更を適用できないようにします。

証拠の例: 個別の環境

次のスクリーンショットは、開発/テスト用の環境が運用環境から分離されていることを示しています。これは Azure のリソース グループを介して実現されます。これは、リソースをコンテナーに論理的にグループ化する方法です。 分離を実現する他の方法として、さまざまな Azure サブスクリプション、ネットワーク、サブネット化などがあります。

次のスクリーンショットは、開発環境と、このリソース グループ内のリソースを示しています。

次のスクリーンショットは、運用環境と、このリソース グループ内のリソースを示しています。

証拠の例:

次のスクリーンショットは、開発/テスト用の環境が運用環境とは別であることを示しています。 環境の適切な分離は、環境ごとに異なるアクセス許可を持つさまざまなユーザー/グループによって実現されます。

次のスクリーンショットは、開発環境と、このリソース グループにアクセスできるユーザーを示しています。

次のスクリーンショットは、運用環境と、このリソース グループにアクセスできるユーザー (開発環境とは異なる) を示しています。

ガイドライン:

実稼働データベースと開発/テスト データベースに対して同じ SQL クエリの出力のスクリーンショットを共有することで、証拠を提供できます (機密情報を編集します)。 同じコマンドの出力によって、異なるデータ・セットが生成されます。 ファイルが格納されている場合は、両方の環境内のフォルダーの内容を表示しても、異なるデータ セットを示す必要があります。

証拠の例

スクリーンショットは、実稼働データベースからの上位 3 件のレコード (証拠提出の場合は上位 20 件を指定してください) を示しています。

次のスクリーンショットは、開発データベースからの同じクエリを示し、異なるレコードを示しています。

注: この例では完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、URL、ログインしたユーザーとシステムの時刻と日付を示す完全なスクリーンショットである必要があります。

ソフトウェアの開発/展開をセキュリティで保護する

ソフトウェア開発活動に関与する組織は、多くの場合、セキュリティと TTM (市場への時間) の圧力の間で競合する優先順位に直面していますが、ソフトウェア開発ライフサイクル (SDLC) 全体でセキュリティ関連のアクティビティを実装すると、コストを節約できるだけでなく、時間を節約することもできます。 セキュリティが後から取り残された場合、問題は通常、 (DSLC) のテスト フェーズ中にのみ特定されます。多くの場合、修正に時間がかかり、コストがかかる場合があります。 このセキュリティ セクションの目的は、安全なソフトウェア開発プラクティスに従って、開発されたソフトウェアに導入されるコーディングの欠陥のリスクを軽減することです。 さらに、このセクションでは、ソフトウェアの安全な展開に役立ついくつかのコントロールを含めます。

コントロール No. 12

ドキュメントが存在し、次のことが維持されていることを示す証拠を提供してください。

• は、セキュリティで保護されたソフトウェアの開発をサポートしており、OWASP Top 10 や SANS Top 25 CWE など、セキュリティで保護されたコーディングの業界標準やベスト プラクティスが含まれています。

• 開発者は、関連する安全なコーディングと安全なソフトウェア開発トレーニングを毎年受けています。

意図: 安全な開発

組織は、ソフトウェアが安全に開発され、脆弱性から解放されるように、あらゆることを行う必要があります。 これを実現するためのベスト エフォートとして、ソフトウェア開発プロセス全体を通じて安全なコーディング手法と安全な開発を促進するために、堅牢な安全なソフトウェア開発ライフサイクル (SDLC) とセキュア コーディングのベスト プラクティスを確立する必要があります。 目的は、ソフトウェアの脆弱性の数と重大度を減らすことです。

コードを安全に開発するために、すべてのプログラミング言語にコーディングのベスト プラクティスと手法が存在します。 開発者にさまざまな種類のソフトウェア脆弱性クラスと、ソフトウェアへのこれらの脆弱性の導入を停止するために使用できるコーディング手法を教えるために設計された外部トレーニング コースがあります。 このコントロールの目的は、これらの手法をすべての開発者に教え、これらの手法が忘れられないようにしたり、新しい手法を毎年実行して学習したりできるようにすることでもあります。

ガイドライン: セキュリティで保護された開発

安全な開発ライフサイクルが使用されていること、およびすべての開発者が安全なコーディングのベスト プラクティスを促進するためのガイダンスが提供されていることを示す、文書化された SDLC やサポート ドキュメントを提供します。 SDLC の OWASP と OWASP ソフトウェア アシュアランス成熟度モデル (SAMM) を見てみましょう。

証拠の例: セキュリティで保護された開発

セキュリティで保護されたソフトウェア開発ポリシー ドキュメントの例を次に示します。 Contoso のセキュア ソフトウェア開発手順からの抜粋を次に示します。これは、セキュリティで保護された開発とコーディングのプラクティスを示しています。

注: 前の例では、完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、ログインしているユーザーとシステムの時刻と日付を示す完全なスクリーンショットである必要があります。

ガイドライン: 安全な開発トレーニング

外部のトレーニング会社がトレーニングを行う場合は証明書を使用して証拠を提供するか、開発者がトレーニングに参加したことを示すトレーニング日記やその他の成果物のスクリーンショットを提供します。 このトレーニングが内部リソースを介して実行される場合は、トレーニング資料の証拠も提供します。

証拠の例: 安全な開発トレーニング

次のスクリーンショットは、DevOps チームのスタッフに OWASP トップ 10 トレーニング年次トレーニングへの登録を要求するメールです。

次のスクリーンショットは、ビジネス上の正当な理由と承認を得てトレーニングが要求されたことを示しています。 その後、トレーニングから撮影されたスクリーンショットと、その人が年次トレーニングを完了したことを示す完了レコードが続きます。

注: この例では完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、URL、ログインしたユーザーとシステムの時刻と日付を示す完全なスクリーンショットである必要があります。

Control No. 13

コード リポジトリがセキュリティで保護されているため、次のような証拠を提供してください。

• すべてのコード変更は、メイン ブランチにマージされる前に、2 番目のレビュー担当者によってレビューと承認プロセスを受けます。

• 適切なアクセス制御が行われます。

• すべてのアクセスは、多要素認証 (MFA) によって適用されます。

• 運用環境に加えられたすべてのリリースは、デプロイの前にレビューされ、承認されます。

意図: コード レビュー

このサブポイントの目的は、別の開発者によるコード レビューを実行して、ソフトウェアに脆弱性が生じる可能性のあるコーディングミスを特定することです。 コード レビューの実施、テストの実行などを確実に行うために、承認を確立する必要があります。 デプロイの前に。 承認ステップは、制御 12 で定義されている SDLC を支える正しいプロセスが従っていることを検証します。

目的は、すべてのコード変更が、メイン ブランチにマージされる前に、2 番目のレビュー担当者によって厳格なレビューと承認プロセスを受けられるようにすることです。 この二重承認プロセスは品質管理の手段として機能し、コーディング エラー、セキュリティの脆弱性、またはアプリケーションの整合性を損なう可能性のあるその他の問題をキャッチすることを目的としています。

ガイドライン: コード レビュー

コードがピア レビューを受け、運用環境に適用する前に承認する必要があることを示す証拠を提供します。 この証拠は、変更チケットのエクスポートを通じて、コード レビューが行われ、変更が承認されたことを示している場合や、クルーシブルなどのコード レビュー ソフトウェアを通じて行われる可能性があることを示している可能性があります。

証拠の例: コード レビュー

次のチケットは、コードの変更が元の開発者以外のユーザーによるレビューと承認プロセスを受けていることを示すチケットです。 これは、コード レビューが担当者によって要求され、コード レビューのために他のユーザーに割り当てられることを示しています。

次の画像は、画像の右側の強調表示されたセクションで示されているように、コード レビューが元の開発者以外のユーザーに割り当てられたことを示しています。 左側では、コードがレビューされ、コード レビュー担当者によって "PASSED CODE REVIEW" 状態が与えられました。 変更をライブ運用システムに適用する前に、チケットがマネージャーによって承認される必要があります。

次の図は、レビューされたコードがライブ運用システムに実装することが承認されたことを示しています。 コードの変更が完了すると、最終的なジョブはサインオフされます。 プロセス全体を通じて、コードの元の開発者、コードレビュー担当者、および承認とサインオフを行うマネージャーの 3 人が関与しています。 このコントロールの条件を満たすには、チケットがこのプロセスに従うことを期待します。

注: この例では完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、URL、ログインしたユーザーとシステムの時刻と日付を示す完全なスクリーンショットである必要があります。

証拠の例: コード レビュー

上記のプロセスの管理部分に加えて、最新のコード リポジトリとプラットフォームを使用すると、レビューを強制するブランチ ポリシーなどの追加のコントロールを実装して、そのようなレビューが完了するまでマージを実行できないようにすることができます。 次の例は、DevOps でこれを実現する方法を示しています。

次のスクリーンショットは、既定のレビュー担当者が割り当てられ、レビューが自動的に必要であることを示しています。

証拠の例: コード レビュー

ブランチ ポリシーの適用レビューは、Bitbucket でも実現できます。

次のスクリーンショットでは、既定のレビュー担当者が設定されています。 これにより、変更がメイン ブランチに反映される前に、すべてのマージで割り当てられた個人からのレビューが必要になります。

以降の 2 つのスクリーンショットは、適用されている構成設定の例を示しています。 完了したプル要求だけでなく、ユーザー Silvester によって開始され、メイン ブランチにマージされる前に既定のレビュー担当者 Andrew からの承認が必要でした。

証拠が提供されると、エンドツーエンドのプロセスが実証されるという期待があることに注意してください。 注: ブランチ ポリシーが設定されている場合 (またはその他のプログラムによるメソッド/制御)、承認が許可されているチケット/レコードを示すスクリーンショットを提供する必要があります。

意図: 制限付きアクセス

前のコントロールに進み、アクセス制御を実装して、特定のプロジェクトで作業している個々のユーザーにのみアクセスを制限する必要があります。 アクセスを制限することで、未承認の変更が実行されるリスクを制限し、セキュリティで保護されていないコードの変更が発生するリスクを制限できます。 コード リポジトリを保護するには、最小限の特権を持つ方法を使用する必要があります。

ガイドライン: 制限付きアクセス

コード リポジトリからのスクリーンショットを使用して、アクセスが必要な個人 (さまざまな特権を含む) に制限されていることを示す証拠を提供します。

証拠の例: 制限付きアクセス

次のスクリーンショットは、Azure DevOps に実装されているアクセス制御を示しています。 "CloudDemo Team" は 2 人のメンバーを持ち、各メンバーに異なるアクセス許可があることを示します。

注: 次のスクリーンショットは、このコントロールを満たすことが予想される証拠と形式の種類の例を示しています。 これは決して広範囲に及ぶものではありません。実際のケースでは、アクセス制御の実装方法が異なる場合があります。

アクセス許可がグループ レベルで設定されている場合は、Bitbucket の 2 番目の例に示すように、各グループとそのグループのユーザーの証拠を指定する必要があります。

次のスクリーンショットは、"CloudDemo チーム" のメンバーを示しています。

前の画像は、Andrew Smith が以下の Silvester よりもプロジェクト所有者として大幅に高い特権を持っていることを示しています。

証拠の例

次のスクリーンショットでは、Bitbucket に実装されているアクセス制御は、グループ レベルで設定されたアクセス許可によって実現されます。 リポジトリのアクセス レベルには、1 人のユーザーを持つ "管理者" グループと、別のユーザーとの "開発者" グループがあります。

次のスクリーンショットは、各ユーザーが異なるグループに属し、本質的に異なるレベルのアクセス許可を持っていることを示しています。 Andrew Smith は管理者であり、Silvester は開発者グループの一部であり、開発者特権のみを付与します。

意図: MFA

脅威アクターがソフトウェアのコード ベースにアクセスして変更できる場合、脆弱性、バックドア、または悪意のあるコードがコード ベースに導入され、したがってアプリケーションに導入される可能性があります。 この例は既にいくつかの例があり、おそらく最も公表されているのは、2020 年の SolarWinds 攻撃であり、攻撃者は、後に SolarWinds のオリオン ソフトウェア更新プログラムに含まれていたファイルに悪意のあるコードを挿入しました。 18,000 を超える SolarWinds のお客様が悪意のある更新プログラムをインストールし、マルウェアが検出されずに拡散しました。

このサブポイントの目的は、コード リポジトリへのすべてのアクセスが多要素認証 (MFA) によって適用されることを確認することです。

ガイドライン: MFA

すべてのユーザーが MFA を有効にしているコード リポジトリからのスクリーンショットを使用して証拠を提供します。

証拠の例: MFA

コード リポジトリが Azure DevOps に格納および管理されている場合は、テナント レベルでの MFA のセットアップ方法に応じて、AAD から "ユーザーごとの MFA" などの証拠を提供できます。 次のスクリーンショットは、AAD のすべてのユーザーに対して MFA が適用され、これは Azure DevOps にも適用されることを示しています。

証拠の例: MFA

組織が GitHub などのプラットフォームを使用している場合は、次のスクリーンショットに示すように、"Organization" アカウントからの証拠を共有することで 2FA が有効になっていることを示すことができます。

GitHub で組織のすべてのメンバーに 2FA が適用されているかどうかを確認するには、次のスクリーンショットのように、組織の [設定] タブに移動します。

GitHub の [People] タブに移動すると、次のスクリーンショットに示すように、組織内のすべてのユーザーに対して "2FA" が有効になっていることを確認できます。

意図: レビュー

このコントロールの目的は、別の開発者による開発環境へのリリースのレビューを実行して、コーディングの間違いや、脆弱性が発生する可能性のある構成の誤りを特定できるようにすることです。 リリース レビューの実行、テストの実行などを確実に行うために、承認を確立する必要があります。 運用環境でのデプロイの前に。 承認。 ステップは、SDLC 原則を支える正しいプロセスが従っていることを検証できます。

ガイドライン

テスト/開発環境から運用環境へのすべてのリリースが、イニシエーターとは異なる人物/開発者によってレビューされていることを示す証拠を提供します。 これが継続的インテグレーション/継続的デプロイ パイプラインを介して実現された場合、提供される証拠は、レビューが適用される (コード レビューと同じ) ことを示す必要があります。

証拠の例

次のスクリーンショットでは、AZURE DevOps で CI/CD パイプラインが使用されていることを確認できます。パイプラインには、開発と運用環境の 2 つのステージが含まれています。 リリースがトリガーされ、開発環境に正常にデプロイされましたが、まだ 2 番目のステージ (運用) に反映されておらず、Andrew Smith からの承認待ちです。

開発にデプロイされると、セキュリティ テストは、関連するチームによって行われ、割り当てられた個人がデプロイをレビューするための適切な権限を持つユーザーがセカンダリ レビューを実行し、すべての条件が満たされたことに満足した場合にのみ、承認が付与され、リリースが運用環境に行われるようになります。

割り当てられた校閲者が通常受信する電子メール アラート。デプロイ前の条件がトリガーされ、レビューと承認が保留中であることを通知します。

電子メール通知を使用して、レビュー担当者は DevOps のリリース パイプラインに移動し、承認を付与できます。 承認を正当化するコメントが追加されていることがわかります。

2 番目のスクリーンショットでは、承認が付与され、運用環境へのリリースが成功したことが示されています。

次の 2 つのスクリーンショットは、予想される証拠のサンプルを示しています。

この証拠は、過去のリリースを示し、デプロイ前の条件が適用され、運用環境にデプロイする前にレビューと承認が必要であることを示しています。

次のスクリーンショットは、開発と運用の両方で正常にデプロイされたことを確認できる最近のリリースを含むリリースの履歴を示しています。

注: 前の例では、完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、URL を示す完全なスクリーンショットである必要があります。ログインしているユーザーとシステムの時刻と日付。

アカウント管理

セキュリティで保護されたアカウント管理プラクティスは、ユーザー アカウントが情報システム、システム環境、およびデータへのアクセスを許可する基礎を形成する上で重要です。 ユーザー アカウントは、ユーザーの資格情報の侵害によって環境への足掛かりと機密データへのアクセスが提供されるだけでなく、ユーザーの資格情報に管理者権限がある場合は、環境全体またはキー システム全体を管理制御できるため、適切にセキュリティ保護する必要があります。

Control No. 14

次の証拠を提供します。

• 既定の資格情報は、サンプリングされたシステム コンポーネント全体で無効、削除、または変更されます。

• サービス アカウントをセキュリティで保護 (強化) するためのプロセスが整っており、このプロセスに従っています。

意図: 既定の資格情報

これはあまり普及しなくなってきていますが、脅威アクターが既定で十分に文書化されたユーザー資格情報を利用して運用システム コンポーネントを侵害できるインスタンスがまだ存在します。 この一般的な例は、Dell iDRAC (統合された Dell リモート アクセス コントローラー) です。 このシステムを使用すると、Dell Server をリモートで管理できます。これは、脅威アクターがサーバーのオペレーティング システムを制御するために利用できます。 root::calvin の既定の資格情報は文書化されており、多くの場合、脅威アクターによって利用され、組織が使用するシステムにアクセスできます。 このコントロールの目的は、セキュリティを強化するために、既定の資格情報が無効または削除されていることを確認することです。

ガイドライン: 既定の資格情報

このコントロールをサポートするために証拠を収集する方法はさまざまです。 すべてのシステム コンポーネントにわたる構成済みユーザーのスクリーンショットは、コマンド プロンプト (CMD) を使用した Windows の既定のアカウントのスクリーンショットや、Linux /etc/shadow ファイルと /etc/passwd ファイルのスクリーンショットは、アカウントが無効になっているかどうかを示すのに役立ちます。

証拠の例: 既定の資格情報

次のスクリーンショットは、既定のアカウントにロックされたパスワードがあり、新しく作成された/アクティブなアカウントに使用可能なパスワードがあることを示す /etc/shadow ファイルを示しています。

パスワード ハッシュが無効であることを示す '!' などの無効な文字で始まることを確認することで、アカウントが本当に無効になっていることを示すには、/etc/shadow ファイルが必要であることに注意してください。 次のスクリーンショットでは、"L" は、名前付きアカウントのパスワードをロックします。 このオプションは、可能な暗号化された値と一致しない値に変更することでパスワードを無効にします (パスワードの先頭に a! が追加されます)。 "P" は、使用可能なパスワードであることを意味します。

2 番目のスクリーンショットは、Windows サーバーで、すべての既定のアカウントが無効になっていることを示しています。 ターミナル (CMD) で 'net user' コマンドを使用すると、既存の各アカウントの詳細を一覧表示し、これらのすべてのアカウントがアクティブではないことを確認できます。

CMD で net user コマンドを使用すると、すべてのアカウントを表示し、すべての既定のアカウントがアクティブではないことを確認できます。

意図: 既定の資格情報

サービス アカウントは、多くの場合、昇格された特権で構成されるため、脅威アクターの対象になります。 これらのアカウントは、サービス アカウント のパスワードの有効期限が切れる場合が多いため、標準のパスワード ポリシーに従わない場合があります。 そのため、組織内で再利用される脆弱なパスワードまたはパスワードを使用して構成できます。 特に Windows 環境内のもう 1 つの潜在的な問題は、オペレーティング システムがパスワード ハッシュをキャッシュする可能性があります。 これは、次のいずれかの場合に大きな問題になる可能性があります。

• このアカウントは、特権レベルが構成された複数のシステム間でアクセスを使用できるため、サービス アカウントはディレクトリ サービス内で構成されます。

• サービス アカウントはローカルであり、環境内の複数のシステムで同じアカウント/パスワードが使用される可能性があります。

上記の問題は、脅威アクターが環境内のより多くのシステムにアクセスし、特権の昇格や横移動につながる可能性があります。 そのため、サービス アカウントが適切に強化され、セキュリティで保護され、脅威アクターによって引き継がれるのを防ぐか、これらのサービス アカウントの 1 つが侵害されるリスクを制限することを目的としています。 コントロールでは、これらのアカウントを強化するための正式なプロセスが必要です。これには、アクセス許可の制限、複雑なパスワードの使用、定期的な資格情報のローテーションが含まれる場合があります。

ガイドライン

サービス アカウントの強化に役立つ多くのガイドがインターネット上にあります。 証拠は、組織がアカウントのセキュリティ強化を実装した方法を示すスクリーンショットの形式にすることができます。 いくつかの例 (複数の手法が使用されると予想されます) には、次のようなものがあります。

• Active Directory 内の一連のコンピューターにアカウントを制限する

• 対話型サインインが許可されないようにアカウントを設定する

• 非常に複雑なパスワードを設定する

• Active Directory の場合は、"アカウントは機密性が高く委任できません" フラグを有効にします。

証拠の例

個々の環境に依存するサービス アカウントを強化する方法は複数あります。 使用できるメカニズムの一部を次に示します。

次のスクリーンショットは、サービス アカウント "_Prod SQL サービス アカウント" で [アカウントが機密性が高く、接続が委任される] オプションが選択されていることを示しています。

この 2 番目のスクリーンショットは、サービス アカウント "_Prod SQL サービス アカウント" が SQL Server にロックダウンされ、そのサーバーにのみサインインできることを示しています。

この次のスクリーンショットは、サービス アカウント "_Prod SQL サービス アカウント" がサービスとしてのサインインのみを許可されていることを示しています。

注: 前の例では、完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、URL を示す完全なスクリーンショットである必要があります。ログインしているユーザーとシステムの時刻と日付。

コントロール No. 15

次の証拠を提供します。

• 一意のユーザー アカウントは、すべてのユーザーに発行されます。

• 環境内では、ユーザーの最小特権の原則に従っています。

• 強力なパスワード/パスフレーズ ポリシーまたはその他の適切な軽減策が用意されています。

• プロセスが実施され、少なくとも 3 か月ごとに実行され、3 か月以内に使用されていないアカウントを無効または削除します。

意図: セキュリティで保護されたサービス アカウント

このコントロールの目的は説明責任です。 独自の一意のユーザー アカウントを持つユーザーを発行することで、ユーザー アクティビティを個々のユーザーに追跡できるため、ユーザーは自分のアクションに対して責任を負います。

ガイドライン: セキュリティで保護されたサービス アカウント

証拠は、サーバー、コード リポジトリ、クラウド管理プラットフォーム、Active Directory、ファイアウォールなど、スコープ内のシステム コンポーネント全体で構成されたユーザー アカウントを示すスクリーンショットです。

証拠の例: セキュリティで保護されたサービス アカウント

次のスクリーンショットは、スコープ内の Azure 環境用に構成されたユーザー アカウントと、すべてのアカウントが一意であることを示しています。

意図: 特権

ユーザーには、ジョブ機能を満たすために必要な特権のみを提供する必要があります。 これは、ユーザーが意図的または意図せずにアクセスしてはならないデータにアクセスしたり、実行したりするリスクを制限するためです。

悪意のある行為。この原則に従うことで、悪意のある脅威アクターによって標的にされる可能性のある攻撃対象領域 (特権アカウント) も削減されます。

ガイドライン: 特権

ほとんどの組織では、グループを使用して、組織内のチームに基づいて特権を割り当てます。 証拠は、さまざまな特権グループと、これらの特権を必要とするチームのユーザー アカウントのみを示すスクリーンショットです。 通常、これは、必要な特権とビジネス上の正当な理由を持つ各定義済みグループを定義するサポート ポリシー/プロセスと共にバックアップされ、グループ メンバーシップを検証するためのチーム メンバーの階層が正しく構成されていることを確認します。

たとえば、Azure 内では、所有者グループは非常に制限されるため、これは文書化する必要があり、そのグループに割り当てられているユーザーの数が限られている必要があります。 もう 1 つの例としては、コードを変更できるスタッフの数が限られており、この権限が構成されている必要があると見なされるスタッフのメンバーと共に、この権限を持つグループを設定できます。 これは、認定アナリストが構成されたグループなどとドキュメントを相互参照できるように文書化する必要があります。

証拠の例: 特権

次のスクリーンショットは、Azure 環境での最小特権の原則を示しています。

次のスクリーンショットでは、Azure Active Directory (AAD)/Microsoft Entra のさまざまなグループの使用が強調表示されています。 開発者、リード エンジニア、セキュリティ運用の 3 つのセキュリティ グループがあることを確認します。

"開発者" グループに移動すると、グループ レベルでは、割り当てられたロールは "アプリケーション開発者" と "ディレクトリ リーダー" だけです。

次のスクリーンショットは、"Developers" グループのメンバーを示しています。

最後に、次のスクリーンショットは、グループの所有者を示しています。

"開発者" グループとは対照的に、"セキュリティ操作" には、ジョブ要件に沿った "セキュリティ オペレーター" という異なるロールが割り当てられます。

次のスクリーンショットは、"セキュリティ操作" グループに属するさまざまなメンバーが存在することを示しています。

最後に、グループには別の所有者があります。

グローバル管理者は高い特権を持つロールであり、組織はこの種類のアクセスを提供するときに受け入れるリスクのレベルを決定する必要があります。 この例では、このロールを持つユーザーは 2 人だけです。 これは、攻撃対象領域と影響を確実に減らするためです。

意図: パスワード ポリシー

多くの場合、ユーザー資格情報は、組織の環境へのアクセスを試みる脅威アクターによる攻撃の対象となります。 強力なパスワード ポリシーの目的は、脅威アクターがそれらをブルート フォースする可能性を軽減するために、強力なパスワードをユーザーに強制的に選択させようとすることです。 "またはその他の適切な軽減策" を追加する目的は、組織が、NISTSpecial Publication 800-63B などの業界の発展に基づいてユーザーの資格情報を保護するのに役立つ他のセキュリティ対策を実装する可能性があることを認識することです。

ガイドライン: パスワード ポリシー

強力なパスワード ポリシーを示す証拠は、組織グループ ポリシー オブジェクトまたはローカル セキュリティ ポリシー "アカウント ポリシー → パスワード ポリシー" および "アカウント ポリシー →アカウント ロックアウト ポリシー" 設定のスクリーンショットの形式である可能性があります。 証拠は、使用されているテクノロジ、つまり Linux の場合、/etc/pam.d/common-password 構成ファイルである可能性があります。Bitbucket の場合は、管理ポータルの [パスワード ポリシーの管理 |Atlassianサポートなど

証拠の例: パスワード ポリシー

次の証拠は、スコープ内システム コンポーネント "CONTOSO-SRV1" の "ローカル セキュリティ ポリシー" 内で構成されたパスワード ポリシーを示しています。

次のスクリーンショットは、WatchGuard ファイアウォールのアカウント ロックアウト設定を示しています。

WatchGuard ファイアウォールの最小パスフレーズ長の例を次に示します。

注: 前の例では完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、URL、ログインしたユーザーとシステムの時刻と日付を示す完全なスクリーンショットである必要があります。

意図: 非アクティブなアカウント

非アクティブなアカウントは、ユーザーがアカウントにログインしようとしないためフラグが設定されないブルート フォース攻撃の対象になっているか、ユーザーのパスワードが再利用され、インターネット上のユーザー名/パスワード ダンプ内で利用できるパスワード データベース違反によって侵害される場合があります。 脅威アクターがアカウント侵害アクティビティを実行する必要がある攻撃面を減らすために、未使用のアカウントを無効または削除する必要があります。 これらのアカウントは、休暇のプロセスが適切に実行されていない、長期の病気に行くスタッフ、または出産/育児休暇に行くスタッフメンバーが原因である可能性があります。 これらのアカウントを特定する四半期ごとのプロセスを実装することで、組織は攻撃対象を最小限に抑えることができます。

この制御では、定期的なアカウント レビューと未使用アカウントのタイムリーな非アクティブ化を確実に行うことでリスクを軽減することを目的として、過去 3 か月以内に使用されていないアカウントを無効または削除するには、少なくとも 3 か月ごとにプロセスを実施し、それに従う必要があることを義務付けています。

ガイドライン: 非アクティブなアカウント

証拠は 2 倍にする必要があります。

• 最初に、スコープ内環境内のすべてのユーザー アカウントの "最後のログオン" を示すスクリーンショットまたはファイルエクスポート。 これは、ローカル アカウントだけでなく、AAD (Azure Active Directory) などの一元化されたディレクトリ サービス内のアカウントでもかまいません。 これにより、3 か月を超えるアカウントが有効になっていないことが示されます。

• 2 つ目は、四半期ごとのレビュー プロセスの証拠です。これは、ADO (Azure DevOps) または JIRA チケット内でタスクが完了したことを示すドキュメント証拠、またはサインオフする必要がある紙のレコードを通じて行われる可能性があります。

証拠の例: 非アクティブなアカウント

次のスクリーンショットは、アクセス レビューを実行するためにクラウド プラットフォームが使用されていることを示しています。 これは、Azure の ID ガバナンス機能を使用して実現されています。

次のスクリーンショットは、レビュー履歴、レビュー期間、および状態を示しています。

ダッシュボードとメトリックによって、組織のすべてのユーザーであるスコープやレビューの結果、四半期ごとの頻度など、追加の詳細が表示されます。

レビューの結果を評価する場合、イメージは、事前に構成された条件に基づいて推奨されるアクションが提供されたことを示します。 さらに、割り当てられた個人がレビューの決定を手動で適用する必要があります。

次の例では、すべての従業員に対して推奨事項と正当な理由が提供されていることを確認できます。 前述のように、レビューを適用する前に推奨事項を受け入れるか無視するかの決定は、割り当てられた個人によって必要です。 最終的な決定が勧告に反する場合、その理由を説明するための証拠が提供されることを期待します。

コントロール No. 16

コード リポジトリやクラウド管理インターフェイスへのアクセスを含め、すべてのリモート アクセス接続とコンソール以外のすべての管理インターフェイスに対して多要素認証 (MFA) が構成されていることを検証します。

これらの用語の意味

• リモート アクセス – これは、サポート環境へのアクセスに使用されるテクノロジを指します。 たとえば、リモート アクセス IPSec VPN、SSL VPN、Jumpbox/Bastian ホストなどです。

• コンソール以外の管理インターフェイス – これは、システム コンポーネントへのネットワーク管理接続を指します。 これは、リモート デスクトップ、SSH、または Web インターフェイス経由である可能性があります。

• コード リポジトリ – アプリのコード ベースは、アプリにマルウェアを導入する可能性がある悪意のある変更から保護する必要があります。 MFA は、コード リポジトリで構成する必要があります。

• クラウド管理インターフェイス – 一部またはすべての環境がクラウド サービス プロバイダー (CSP) 内でホストされます。 クラウド管理の管理インターフェイスがここに含まれています。

意図: MFA

この制御の目的は、 多要素認証 (MFA) を実装することで、環境への安全なアクセス権を持つ特権アカウントに対するブルート フォース攻撃に対する軽減策を提供することです。 パスワードが侵害された場合でも、MFA メカニズムは引き続きセキュリティで保護され、すべてのアクセスと管理アクションが、承認された信頼できるスタッフ メンバーによってのみ実行されるようにする必要があります。

セキュリティを強化するには、MFA を使用してリモート アクセス接続とコンソール以外の管理インターフェイスの両方にセキュリティレイヤーを追加することが重要です。 リモート アクセス接続は特に未承認のエントリに対して脆弱であり、管理インターフェイスは高い特権機能を制御するため、セキュリティ対策を強化する必要がある重要な領域の両方が作成されます。 さらに、コード リポジトリには機密性の高い開発作業が含まれており、クラウド管理インターフェイスは組織のクラウド リソースに広範なアクセスを提供し、MFA で保護する必要がある重要なポイントを追加します。

ガイドライン: MFA

証拠は、前のカテゴリに適合するすべてのテクノロジで MFA が有効になっていることを示す必要があります。 これは、MFA がシステム レベルで有効になっていることを示すスクリーンショットを通じて発生する可能性があります。 システム レベルでは、MFA が有効になっているアカウントの例だけでなく、すべてのユーザーに対して有効になっているという証拠が必要です。 テクノロジが MFA ソリューションにバックオフされている場合は、それが有効で使用中であることを示す証拠が必要です。 これは何を意味するのかです。このテクノロジが MFA プロバイダーを指す Radius 認証用に設定されている場合は、指している Radius Server が MFA ソリューションであり、それを利用するようにアカウントが構成されていることを証明する必要もあります。

証拠の例: MFA

次のスクリーンショットは、AAD/Entra で MFA 条件付きポリシーを実装して、組織全体で 2 要素認証要件を適用する方法を示しています。 次のポリシーが "オン" であることがわかります。

次のスクリーンショットは、MFA ポリシーが組織内のすべてのユーザーに適用され、これが有効になっていることを示しています。

次のスクリーンショットは、MFA 条件を満たすとアクセス権が付与されることを示しています。 スクリーンショットの右側では、MFA が実装された後にのみユーザーにアクセス権が付与されることがわかります。

証拠の例: MFA

登録時にユーザーが新しいアカウントにアクセスする前に MFA を構成する必要があることを保証する MFA 登録要件など、追加の制御を実装できます。 すべてのユーザーに適用される MFA 登録ポリシーの構成を以下に示します。

除外なしで適用されるポリシーを示す前のスクリーンショットの続きでは、次のスクリーンショットは、すべてのユーザーがポリシーに含まれていることを示しています。

証拠の例: MFA

次のスクリーンショットは、"ユーザーごとの MFA" ページが、すべてのユーザーに対して MFA が適用されていることを示しています。

証拠の例: MFA

次のスクリーンショットは、環境へのリモート アクセスに使用される Pulse Secure で構成された認証領域を示しています。 認証は、MFA サポート用の Duo SaaS サービスによってサポートされます。

このスクリーンショットは、"Duo - Default Route" 認証領域の "Duo-LDAP" を指す追加の認証サーバーが有効になっていることを示しています。

この最後のスクリーンショットは、これが MFA 用 Duo SaaS サービスを指していることを示す Duo-LDAP 認証サーバーの構成を示しています。

注: 前の例では、完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、URL を示す完全なスクリーンショットである必要があります。ログインしているユーザーとシステムの時刻と日付。

セキュリティ イベントのログ記録、確認、およびアラート

セキュリティ イベント ログは、組織のセキュリティ プログラムの不可欠な部分です。 セキュリティ イベントの適切なログ記録と、調整されたアラートとレビュー プロセスは、組織がセキュリティと防御的なセキュリティ戦略を強化するために使用できる侵害または侵害の試行を特定するのに役立ちます。 さらに、適切なログ記録は、組織のインシデント対応機能に役立ちます。これにより、侵害されたデータやユーザーのデータを正確に特定したり、侵害期間を特定したり、政府機関に詳細な分析レポートを提供したりできます。

セキュリティ ログの確認は、セキュリティ違反や偵察アクティビティを示す可能性のあるセキュリティ イベントを組織が特定するのに役立つ重要な機能です。これは、今後何かを示す可能性があります。 これは、手動プロセスを毎日実行するか、SIEM (セキュリティ情報とイベント管理) ソリューションを使用して行うことができます。これは、監査ログを分析し、手動検査のフラグを設定できる相関関係と異常を探すのに役立ちます。

重要なセキュリティ イベントは、データと運用環境への影響を最小限に抑えるために、直ちに調査する必要があります。 アラートは、スタッフに対する潜在的なセキュリティ侵害をすぐに強調し、組織がセキュリティ イベントをできるだけ早く含めることができるように、タイムリーな対応を確保するのに役立ちます。 アラートが効果的に機能していることを確認することで、組織はセキュリティ侵害の影響を最小限に抑えることができるため、重大な侵害が発生する可能性を減らし、組織ブランドに損害を与え、罰金や評判の損害を通じて金銭的損失を課す可能性があります。

コントロール No. 17

次のようなイベントをログに記録するために、スコープ内環境全体でセキュリティ イベント ログが設定されていることを示す証拠を提供してください。

• システム コンポーネントとアプリケーションへのユーザー/秒のアクセス。

• 高い特権を持つユーザーが実行したすべてのアクション。

• 無効な論理アクセス試行。

• 特権アカウントの作成/変更。

• イベント ログの改ざん。

• セキュリティ ツールの無効化。たとえば、イベント ログなどです。

• マルウェア対策ログ記録。たとえば、更新プログラム、マルウェア検出、スキャン エラーなどです。

意図: イベント ログ

試行された侵害と実際の侵害を特定するには、環境を構成するすべてのシステムによって適切なセキュリティ イベント ログが収集されていることが重要です。 このコントロールの目的は、適切な種類のセキュリティ イベントが確実にキャプチャされるようにすることです。これにより、これらのイベントを特定して対応するのに役立つレビューおよびアラート プロセスにフィードできます。

1. このサブポイントでは、ISV がセキュリティ イベント ログを設定して、システム コンポーネントとアプリケーションへのユーザー アクセスのすべてのインスタンスをキャプチャする必要があります。 これは、組織内のシステム コンポーネントとアプリケーションにアクセスしているユーザーを監視するために重要であり、セキュリティと監査の両方の目的で不可欠です。

2. このサブポイントでは、高レベルの特権を持つユーザーによって実行されたすべてのアクションがログに記録される必要があります。 高い特権を持つユーザーは、組織のセキュリティ体制に影響を与える可能性のある大幅な変更を行うことができます。 そのため、アクションの記録を保持することが重要です。

3. このサブポイントでは、システム コンポーネントまたはアプリケーションへの論理アクセスを取得するための無効な試行のログ記録が必要です。 このようなログ記録は、未承認のアクセス試行と潜在的なセキュリティ上の脅威を検出するための主要な方法です。

4. このサブポイントでは、特権アクセス権を持つアカウントの作成または変更をログに記録する必要があります。 この種類のログ記録は、システム アクセスのレベルが高く、攻撃者の対象となる可能性があるアカウントへの変更を追跡するために重要です。

5. このサブポイントでは、イベント ログを改ざんしようとする試みのログ記録が必要です。 ログの改ざんは、未承認のアクティビティを非表示にする方法であるため、そのようなアクションをログに記録して実行することが重要です。

6. このサブポイントには、イベント ログ自体を含むセキュリティ ツールを無効にするアクションのログ記録が必要です。 セキュリティ ツールを無効にすると、攻撃または内部の脅威を示す赤いフラグを指定できます。

7. このサブポイントには、更新プログラム、マルウェア検出、スキャン エラーなど、マルウェア対策ツールに関連するアクティビティのログ記録が必要です。 マルウェア対策ツールの適切な機能と更新は、組織のセキュリティとこれらのアクティビティに関連するログが監視に役立つ上で不可欠です。

ガイドライン: イベント ログ

これらの種類のセキュリティ イベントがキャプチャされることを保証するようにログ記録を構成する方法を示すために、スクリーンショットまたは構成設定を使用して、サンプリングされたすべてのデバイスと関連するシステム コンポーネントに証拠を提供する必要があります。

証拠の例

次のスクリーンショットは、Azure のさまざまなリソースによって生成されたログとメトリックの構成を示しています。その後、一元化された Log Analytic ワークスペースに取り込まれます。

最初のスクリーンショットでは、ログ ストレージの場所が "PaaS-web-app-log-analytics" であることがわかります。

Azure では、次に示すように、Azure リソースで診断設定を有効にして、監査、セキュリティ、診断ログにアクセスできます。 自動的に使用できるアクティビティ ログには、イベント ソース、日付、ユーザー、タイムスタンプ、ソース アドレス、宛先アドレス、およびその他の便利な要素が含まれます。

注: 次の例は、このコントロールを満たすために提供できる証拠の種類を示しています。 これは、組織がスコープ内環境全体でセキュリティ イベント ログを設定する方法によって異なります。 その他の例としては、Azure Sentinel、Datadog などがあります。

Azure App Services でホストされている Web アプリの [診断設定] オプションを使用すると、生成されるログと、それらがストレージと分析のために送信される場所を構成できます。

次のスクリーンショットの [アクセス監査ログ] と [IPSecurity 監査ログ] は、生成され、Log Analytic ワークスペースにキャプチャされるように構成されています。

もう 1 つの例は、同じ一元化された Log Analytic ワークスペースに生成されたログを送信するように構成された Azure Front Door です。

"診断設定" オプションを使用する前と同様に、生成されるログと、それらがストレージと分析のために送信される場所を構成します。 次のスクリーンショットは、'アクセス ログ' と 'WAF ログ' が構成されていることを示しています。

同様に、Azure SQL Server の場合、"診断設定" では、生成されるログと、それらがストレージと分析のために送信される場所を構成できます。

次のスクリーンショットは、SQL サーバーの "監査" ログが生成され、Log Analytics ワークスペースに送信されることを示しています。

証拠の例

AAD/Entra の次のスクリーンショットは、特権ロールと管理者に対して監査ログが生成されていることを示しています。 情報には、状態、アクティビティ、サービス、ターゲット、イニシエーターが含まれます。

次のスクリーンショットは、サインイン ログを示しています。 ログ情報には、IP アドレス、状態、場所、日付が含まれます。

証拠の例

次の例では、Virtual Machines (VM) などのコンピューティング インスタンス用に生成されたログに焦点を当てます。 データ収集ルールが実装され、セキュリティ監査ログを含む Windows イベント ログがキャプチャされます。

次のスクリーンショットは、"Galaxy-Compliance" というサンプリングされたデバイスからの構成設定の別の例を示しています。 この設定は、"ローカル セキュリティ ポリシー" 内で有効になっているさまざまな監査設定を示しています。

次のスクリーンショットは、サンプリングされたデバイス "Galaxy-Compliance" からユーザーがイベント ログをクリアしたイベントを示しています。

注: 前の例は全画面表示のスクリーンショットではないことに注意してください。すべての URL を含む全画面表示のスクリーンショットを送信する必要があります。ユーザーにログインし、証拠の確認のために日時スタンプを送信する必要があります。 Linux ユーザーの場合は、コマンド プロンプトから実行できます。

コントロール No. 18

90 日間のセキュリティ イベント ログが保持されている状態で、少なくとも 30 日分のセキュリティ イベント ログ データがすぐに利用できる証拠を提供します。

意図: イベント ログ

場合によっては、侵害またはセキュリティ イベントとそれを識別する組織との間に時間のギャップがあります。 この制御の目的は、インシデント対応と必要になる可能性のあるフォレンジック調査作業に役立つ履歴イベント データに組織がアクセスできるようにすることです。 組織が 30 日間以上のセキュリティ イベント ログ データを保持していることを確認します。これは、迅速な調査とセキュリティ インシデントへの対応を容易にするために、分析にすぐに利用できます。 さらに、詳細な分析を可能にするために、合計 90 日分のセキュリティ イベント ログが保持されます。

ガイドライン: イベント ログ

通常、証拠は、一元化されたログ ソリューションの構成設定を示し、データが保持される時間を示すことによって行われます。 30 日間分のセキュリティ イベント ログ データは、ソリューション内ですぐに利用できる必要があります。 ただし、データがアーカイブされている場合は、90 日間の価値があることを示す必要があります。 これは、エクスポートされたデータの日付を含むアーカイブ フォルダーを表示することで行うことができます。

証拠の例: イベント ログ

クラウド リソースによって生成されたすべてのログを格納するために一元化された Log Analytic ワークスペースが使用されているコントロール 17 の前の例に従って、ログが各ログ カテゴリの個々のテーブルに格納されていることを以下に確認できます。 さらに、すべてのテーブルの対話型リテンション期間は 90 日です。

次のスクリーンショットは、Log Analytic ワークスペースの保持期間の構成設定を示す追加の証拠を示しています。

証拠の例

次のスクリーンショットは、AlienVault 内で 30 日分のログを使用できる方法を示しています。

注: これは公開されているドキュメントであるため、ファイアウォールのシリアル番号は編集されていますが、アナリストに開示する必要がある個人を特定できる情報 (PII) が含まれている場合を除き、ISV はこの情報をやり直さずに送信する必要があります。

この次のスクリーンショットは、ログの抽出が 5 か月後に行われるのを示すことで、ログが使用可能であることを示しています。

注: これは公開されているドキュメントであるため、パブリック IP アドレスは編集されていますが、ISV には、アナリストと最初に話し合う必要がある個人を特定できる情報 (PII) が含まれていない限り、この情報を何もやり直さずに送信する必要があります。

注: 前の例は全画面表示のスクリーンショットではありません。すべての URL を含む全画面表示のスクリーンショットを送信する必要があります。ユーザーにログインし、証拠の確認のために日時スタンプを送信する必要があります。 Linux ユーザーの場合は、コマンド プロンプトから実行できます。

証拠の例

次のスクリーンショットは、ログ イベントが 30 日間ライブで利用可能で、Azure 内のコールド ストレージで 90 日間保持されることを示しています。

注: 予想されるのは、構成されたリテンション期間を示す構成設定に加えて、90 日間のログのサンプルが提供され、ログが 90 日間保持されていることを検証することです。

注: これらの例は全画面表示のスクリーンショットではありません。すべての URL を含む全画面表示のスクリーンショットを送信し、ユーザーにログインし、証拠の確認のために日時スタンプを送信する必要があります。 Linux ユーザーの場合は、コマンド プロンプトから実行できます。

コントロール No. 19

以下を示す証拠を提出してください。

ログは定期的にレビューされ、レビュー プロセス中に特定された潜在的なセキュリティ イベント/異常が調査され、対処されます。

意図: イベント ログ

このコントロールの目的は、定期的なログ レビューが実行されていることを確認することです。これは、セキュリティ イベント アラートを提供するように構成されたアラート スクリプト/クエリによって取得されない可能性がある異常を特定するために重要です。 また、ログ レビュー中に特定されたすべての異常が調査され、適切な修復またはアクションが実行されます。これには通常、異常にアクションが必要かどうかを特定するためのトリアージ プロセスが含まれます。その後、インシデント対応プロセスを呼び出す必要がある場合があります。

ガイドライン: イベント ログ

証拠はスクリーンショットによって提供され、ログ レビューが行われていることを示します。 これは、毎日完了するフォームを使用するか、JIRA または DevOps チケットを使用して、

関連するコメントが投稿され、これが実行されることを示します。異常にフラグが設定されている場合は、この同じチケット内に文書化して、ログ レビューの一部として識別された異常がフォローアップされ、その後に実行されたアクティビティの詳細を示すことができます。 これにより、実行されているすべてのアクティビティを追跡するために特定の JIRA チケットが発行されるか、ログ レビュー チケット内に文書化される場合があります。 インシデント対応アクションが必要な場合は、インシデント対応プロセスの一部として文書化し、これを示す証拠を提供する必要があります。

証拠の例: イベント ログ

この最初のスクリーンショットは、ユーザーが "Domain Admins" グループに追加された場所を示しています。

この次のスクリーンショットは、失敗したログオン試行の後に成功したログインが続く場所を示しています。これにより、ブルート フォース攻撃の成功が強調される可能性があります。

この最後のスクリーンショットは、ポリシーの設定でパスワード ポリシーの変更が発生した場所を示しているため、アカウント パスワードの有効期限が切れなくなります。

次のスクリーンショットは、チケットが SOC の ServiceNow ツール内で自動的に発生し、上記のルールをトリガーしていることを示しています。

注: これらの例は全画面表示のスクリーンショットではありません。すべての URL を含む全画面表示のスクリーンショットを送信し、ユーザーにログインし、証拠の確認のために日時スタンプを送信する必要があります。 Linux ユーザーの場合は、コマンド プロンプトから実行できます。

コントロール No. 20

以下を示す証拠を提出してください。

アラート ルールは、該当する場合に、次のセキュリティ イベントの調査のためにアラートがトリガーされるように構成されます。

• 特権アカウントの作成/変更。

• Privileged/High risk アクティビティまたは操作。

• マルウェア イベント。

• イベント ログの改ざん。

• IDPS/WAF イベント (構成されている場合)。

意図: アラート

これらは、環境の侵害やデータ侵害を指し示す可能性のあるセキュリティ イベントが発生したことを強調するセキュリティ イベントの一部の種類です。

1. このサブポイントは、特権アカウントの作成または変更時に調査をトリガーするようにアラート ルールが特に構成されていることを確認することです。 特権アカウントの作成または変更の場合は、ログを生成し、新しい特権アカウントが作成されたとき、または既存の特権アカウントのアクセス許可が変更されるたびにアラートをトリガーする必要があります。 これは、承認されていないアクティビティや疑わしいアクティビティを追跡するのに役立ちます。

2. このサブポイントは、特権またはリスクの高いアクティビティまたは操作が実行されたときに、適切な担当者に通知するようにアラート ルールを設定することを目的としています。 特権またはリスクの高いアクティビティまたは操作の場合は、そのようなアクティビティが開始されたときに適切な担当者に通知するようにアラートを設定する必要があります。 これには、ファイアウォール規則の変更、データ転送、機密ファイルへのアクセスが含まれる場合があります。

3. このサブポイントの目的は、マルウェア関連のイベントによってトリガーされるアラート ルールの構成を要求することです。 マルウェア イベントはログに記録されるだけでなく、調査のための即時アラートもトリガーする必要があります。 これらのアラートは、配信元、マルウェアの性質、影響を受けるシステム コンポーネントなどの詳細を含めて、応答時間を短縮するように設計する必要があります。

4. このサブポイントは、イベント ログの改ざんによって調査のための即時アラートがトリガーされるように設計されています。 イベント ログの改ざんについては、ログへの不正アクセスまたはログの変更が検出されたときにアラートをトリガーするようにシステムを構成する必要があります。 これにより、フォレンジック分析とコンプライアンス監査に不可欠なイベント ログの整合性が確保されます。

5. このサブポイントは、侵入検出および防止システム (IDPS) または Web アプリケーション ファイアウォール (WAF) が構成されている場合に、調査のためのアラートをトリガーするように設定されていることを確認する予定です。 侵入検出および防止システム (IDPS) または Web アプリケーション ファイアウォール (WAF) が構成されている場合は、ログインエラーの繰り返し、SQL インジェクション試行、サービス拒否攻撃を示唆するパターンなどの疑わしいアクティビティに対するアラートをトリガーするように設定する必要もあります。

ガイドライン: アラート

証拠は、アラート構成のスクリーンショットと、受信されているアラートの証拠を使用して提供する必要があります。 構成のスクリーンショットには、アラートをトリガーするロジックと、アラートの送信方法が表示されます。 アラートは、SMS、電子メール、Teams チャネル、Slack チャネルなどを介して送信できます。

証拠の例: アラート

次のスクリーンショットは、Azure で構成されているアラートの例を示しています。 最初のスクリーンショットでは、VM が停止して割り当て解除されたときにアラートが発生したことを確認できます。 これは、Azure で構成されているアラートの例を示しており、コントロールの説明で指定されたすべてのイベントに対してアラートが生成されることを示す証拠が提供されることを想定しています。

次のスクリーンショットは、Azure App Service レベルと Azure リソース グループ レベルで行われた管理アクションに対して構成されたアラートを示しています。

証拠の例

Contoso は、Contoso Security によって提供されるサード パーティのセキュリティ オペレーション センター (SOC) を利用します。 この例では、SOC によって利用される AlienVault 内のアラートが、Contoso Security の SOC チーム Sally Gold のメンバーにアラートを送信するように構成されていることを示しています。

次のスクリーンショットは、Sally によって受信されたアラートを示しています。

注: これらの例は全画面表示のスクリーンショットではありません。すべての URL を含む全画面表示のスクリーンショットを送信し、ユーザーにログインし、証拠の確認のために日時スタンプを送信する必要があります。 Linux ユーザーの場合は、コマンド プロンプトから実行できます。

情報セキュリティ リスク管理

情報セキュリティ リスク管理は、すべての組織が少なくとも毎年実行する必要がある重要なアクティビティです。 組織は、脅威を効果的に軽減するためにリスクを理解する必要があります。 効果的なリスク管理がないと、組織は、他の脅威の可能性が高い場合に、重要であると認識する領域にセキュリティ リソースを実装する可能性があります。 効果的なリスク管理は、組織がビジネスに最も脅威を与えるリスクに集中するのに役立ちます。 これは、セキュリティ環境が絶えず変化しているため、脅威とリスクが超過時間を変える可能性があるため、毎年実行する必要があります。 たとえば、最近の COVID-19 ロックダウン中に、リモート作業への移行に伴うフィッシング攻撃が大幅に増加しました。

コントロール No. 21

承認された正式な情報セキュリティ リスク管理ポリシー/プロセスが文書化され、確立されていることを示す証拠を提供します。

意図: リスク管理

組織がリスクを効果的に管理するには、堅牢な情報セキュリティ リスク管理プロセスが重要です。 これにより、組織は環境に対する脅威に対する効果的な軽減策を計画できます。 この制御の目的は、組織が、包括的に文書化された正式に承認された情報セキュリティ リスク管理ポリシーまたはプロセスを持っていることを確認することです。 このポリシーは、組織が情報セキュリティ リスクを特定、評価、管理する方法を概説する必要があります。 ロールと責任、リスク評価の手法、リスク受け入れの基準、リスク軽減の手順を含める必要があります。

注: リスク評価は、一般的なビジネス リスクだけでなく、情報セキュリティ リスクに焦点を当てる必要があります。

ガイドライン: リスク管理

正式に文書化されたリスク評価管理プロセスを提供する必要があります。

証拠の例: リスク管理

次の証拠は、Contoso のリスク評価プロセスの一部のスクリーンショットです。

注: ISV は、単にスクリーンショットを提供するのではなく、実際のサポート ポリシー/プロシージャドキュメントを共有することを期待しています。

注: ISV は、単にスクリーンショットを提供するのではなく、実際のサポート ポリシー/プロシージャドキュメントを共有することを期待しています。

コントロール No. 22

以下を示す証拠を提出してください。

• 正式な会社全体の情報セキュリティ リスク評価は、少なくとも毎年行われます。

または、対象となるリスク分析の場合:

• 対象となるリスク分析が文書化され、実行されます。

  • 従来のコントロールまたは業界のベスト プラクティスが実施されていないすべてのインスタンスについて、少なくとも 12 か月ごとに。

  • 設計/技術的な制限によって、環境に脆弱性が導入されるリスクが生じたり、ユーザーとデータが危険にさらされる場合。

  • 侵害の疑いまたは確認時。

意図: 年次評価

セキュリティの脅威は、環境の変化、提供されるサービスの変更、外部からの影響、セキュリティの脅威環境の進化などに基づいて絶えず変化しています。組織は、少なくとも毎年リスク評価プロセスを実行する必要があります。 脅威が変化する可能性があるため、このプロセスは大幅な変更時にも実行することをお勧めします。

この制御の目的は、組織が、システムの変更中やインシデント、脆弱性検出、インフラストラクチャの変更時などに、少なくとも年に 1 回、正式な会社全体の情報セキュリティ リスク評価や対象となるリスク分析を実施していることを確認することです。この評価には、潜在的な脆弱性と脅威の特定と評価を目的として、すべての組織の資産、プロセス、およびデータが含まれている必要があります。

対象となるリスク分析では、このコントロールは特定のシナリオに対してリスク分析を実行する必要性を強調します。これは、資産、脅威、システム、コントロールなど、より狭い範囲に焦点を当てています。 この目的は、組織がセキュリティのベスト プラクティスやシステム設計の制限からの逸脱によってもたらされるリスクを継続的に評価して特定することです。 制御が不足している場所、技術的制約によって脆弱性が生じる場合、および疑わしいまたは確認されたセキュリティ インシデントに対応して、組織は少なくとも年に 1 回、対象となるリスク分析を実行することで、弱点と露出を特定できます。 これにより、修復作業の優先順位付けと補正制御の実装に関する情報に基づくリスクベースの決定が可能になり、悪用の可能性と影響を最小限に抑えることができます。 目標は、既知のギャップが無期限に無視されるのではなく、リスク対応の方法で対処されていることを示す継続的なデュー デリジェンス、ガイダンス、証拠を提供することです。 これらの対象となるリスク評価を実行すると、時間の経過と共にセキュリティ態勢を積極的に改善する組織のコミットメントが示されます。

ガイドライン: 年次評価

証拠は、バージョン追跡または日付付き証拠によって行われる場合があります。 情報セキュリティ リスク評価プロセス自体の日付ではなく、情報セキュリティ リスク評価の出力を示す証拠を提供する必要があります。

証拠の例: 年次評価

次のスクリーンショットは、リスク評価会議が 6 か月ごとにスケジュールされていることを示しています。

次の 2 つのスクリーンショットは、2 つのリスク評価の会議分の例を示しています。 予想は、レポート/会議の議事録、またはリスク評価のレポートが提供されるということです。

注: このスクリーンショットは、ポリシー/プロセス ドキュメントを示しています。 ISV は、スクリーンショットを提供するだけでなく、実際のサポート ポリシー/プロシージャドキュメントを共有することが期待されています。

注: このスクリーンショットはポリシー/プロセス ドキュメントを示しています。ISV は実際のサポート ポリシー/プロシージャ ドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

コントロール No. 23

情報セキュリティ リスク評価に以下が含まれていることを検証します。

• 影響を受けるシステム コンポーネントまたはリソース。

• 脅威と脆弱性、または等価性。

• 影響と尤度行列または同等の行列。

• リスクレジスタ/リスク治療計画の作成。

意図: リスク評価

リスク評価には、最も重要な IT 資産とその価値を特定するのに役立つシステム コンポーネントとリソースが含まれていることが意図されています。 組織は、ビジネスに対する潜在的な脅威を特定して分析することで、最大の潜在的な影響を与えるリスクと最も高い確率を持つリスクに最初に焦点を当てることができます。 IT インフラストラクチャと関連するコストに対する潜在的な影響を理解することで、経営陣が予算、ポリシー、手順などの情報に基づいた意思決定を行うのに役立ちます。 セキュリティ リスク評価に含めることができるシステム コンポーネントまたはリソースの一覧は次のとおりです。

• サーバー

• Databases

• アプリケーション

• ネットワーク

• データ ストレージ デバイス

• 連絡先

情報セキュリティ リスクを効果的に管理するには、環境とデータに対する脅威と、存在する可能性のある脆弱性に対してリスク評価を行う必要があります。 これにより、組織は重大なリスクをもたらす可能性のある無数の脅威と脆弱性を特定するのに役立ちます。 リスク評価では、影響と尤度の評価を文書化する必要があります。これは、リスク値を特定するために使用できます。 これは、リスク処理に優先順位を付け、全体的なリスク値を減らすのに役立ちます。 適用されている 4 つのリスク処理のうちの 1 つを記録するために、リスク評価を適切に追跡する必要があります。 これらのリスク処理は次のとおりです。

• 回避/終了: ビジネスは、リスクに対処するコストが、サービスから生成された収益よりも多いと判断する場合があります。 そのため、ビジネスはサービスの実行を停止することを選択する場合があります。

• 譲渡/共有: 企業は、処理をサード パーティに移行することで、リスクを第三者に譲渡することを選択できます。

• 受け入れ/容認/保持: ビジネスは、リスクが許容可能であると判断する場合があります。 これは企業のリスクアペタイトに大きく依存し、組織によって異なる場合があります。

• 治療/軽減/変更: ビジネスは、リスクを許容可能なレベルに減らすために軽減制御を実装することを決定します。

ガイドライン: リスク評価

証拠は、既に提供されている情報セキュリティリスク評価プロセスだけでなく、リスク評価プロセスが適切に実行されていることを実証するためのリスク評価(リスクレジスタ/リスク処理計画を使用)の出力によって提供されるべきである。 リスク レジスタには、リスク、脆弱性、影響、および可能性の評価を含める必要があります。

証拠の例: リスク評価

次のスクリーンショットは、脅威と脆弱性が含まれていることを示すリスク レジスタを示しています。 また、影響と可能性が含まれていることも示しています。

注: 完全なリスク評価ドキュメントは、スクリーンショットではなく提供する必要があります。 次のスクリーンショットは、リスク処理計画を示しています。

Control No. 24

次の証拠を提供してください。

• お客様 (ISV) には、ベンダーやビジネス パートナーに関連するリスクを評価および管理するリスク管理プロセスが用意されています。

• ユーザー (ISV) は、内部コントロールのシステムに影響を与える可能性のある変更とリスクを特定して評価できます。

意図: ベンダーとパートナー

ベンダー リスク管理は、ビジネス関係が確立される前と関係の期間を通じて、ビジネス パートナー、サプライヤー、またはサード パーティ ベンダーのリスク態勢を評価する方法です。 ベンダーのリスクを管理することで、組織はビジネス継続性の中断を回避し、財務上の影響を防ぎ、評判を保護し、規制に準拠し、ベンダーとの共同作業に関連するリスクを特定して最小限に抑えることができます。 ベンダーリスクを効果的に管理するには、デューデリジェンス評価、セキュリティに関連する契約上の義務、ベンダーコンプライアンスの継続的な監視を含むプロセスを実施することが重要です。

ガイドライン: ベンダーとパートナー

新しいベンダーや請負業者のオンボード、評価、コンプライアンス チェックなど、ベンダーのリスク評価プロセスを示す証拠を提供できます。

証拠の例: ベンダーとパートナー

次のスクリーンショットは、ベンダーのオンボードと審査プロセスが Confluence で JIRA タスクとして維持されていることを示しています。 新しいベンダーごとに、コンプライアンス体制を確認するために初期リスク評価が行われます。 調達プロセス中にリスク評価アンケートが入力され、ベンダーに提供されるシステムとデータへのアクセスレベルに基づいて全体的なリスクが決定されます。

次のスクリーンショットは、評価の結果と、最初のレビューに基づいて特定された全体的なリスクを示しています。

意図: 内部コントロール

このサブポイントの焦点は、組織の内部コントロール システムに影響を与える可能性のある変更とリスクを認識して評価し、内部コントロールが時間の経過と同時に有効であることを確認することです。 業務が変化するにつれて、内部コントロールが有効でなくなる可能性があります。 リスクは時間の経過と共に進化し、以前は考慮されなかった新しいリスクが出現する可能性があります。 これらのリスクを特定して評価することで、内部コントロールがそれらに対処するように設計されていることを確認できます。 これにより、不正行為やエラーの防止、ビジネス継続性の維持、規制コンプライアンスの確保に役立ちます。

ガイドライン: 内部コントロール

会議の議事録やレポートなどの証拠を提供できます。これにより、ベンダーリスク評価プロセスが定義された期間に更新され、ベンダーの潜在的な変更が確実に考慮され、評価されることを示すことができます。

証拠の例: 内部コントロール

次のスクリーンショットは、承認されたベンダーと請負業者のリストの 3 か月間のレビューを行い、コンプライアンス基準とコンプライアンスレベルがオンボード中の最初の評価と一致していることを示しています。

最初のスクリーンショットは、評価とリスクアンケートを実行するための確立されたガイドラインを示しています。

次のスクリーンショットは、実際のベンダー承認済みリストとそのコンプライアンス レベル、実行された評価、評価者、承認者などを示しています。これは、制御要件を理解するためのベースライン シナリオを提供し、予想される証拠の形式を示すために設計された基本的なベンダー リスク評価の一例にすぎません。 ISV として、組織に適用できる独自の確立されたベンダー リスク評価を提供する必要があります。

セキュリティ インシデント対応

セキュリティ インシデント対応は、セキュリティ インシデントを含む組織が費やす時間を短縮し、組織のデータ流出のレベルを制限できるため、すべての組織にとって重要です。 包括的で詳細なセキュリティ インシデント対応計画を開発することで、この露出を識別時から封じ込め時間まで短縮できます。

IBM の 「データ侵害のコストレポート 2020」というタイトルのレポートでは、平均して、侵害を含めるのにかかった時間は 73 日だったことが強調されています。 さらに、同じレポートは、侵害を受けた組織の最大のコスト削減率を特定し、インシデント対応の準備を行い、

$2,000,000 のコスト削減。 組織は、ISO 27001、NIST、SOC 2、PCI DSS などの業界標準フレームワークを使用して、セキュリティ コンプライアンスのベスト プラクティスに従う必要があります。

コントロール No. 25

組織がインシデントにどのように対応するか、それがどのように維持されているか、およびそれが含まれていることを示す、承認されたセキュリティ インシデント対応計画/手順 (IRP) を指定してください。

• インシデント対応チームの詳細 (連絡先情報を含む)

• 重要な利害関係者、支払いブランドと買収者、規制機関(GDPR の場合は 72 時間など)、監督当局、取締役、顧客、などの関係者へのインシデントおよび外部通信中の内部通信計画

• インシデントの種類に応じて、インシデント分類、封じ込め、軽減、復旧、通常の業務への復帰などのアクティビティの手順。

意図: インテデント応答プラン (IRP)

このコントロールの目的は、明確に文書化された役割、責任、連絡先情報を持つ指定されたインシデント対応チームを含む、正式に文書化されたインシデント対応計画 (IRP) があることを確認することです。 IRP は、インシデントの性質の分類、即時の影響の含む、リスクの軽減、インシデントからの復旧、通常のビジネス操作の復元など、検出から解決までのセキュリティ インシデントを管理するための構造化されたアプローチを提供する必要があります。 各手順は明確なプロトコルで明確に定義され、実行されたアクションが組織のリスク管理戦略とコンプライアンス義務と一致するようにする必要があります。

IRP 内のインシデント対応チームの詳細な仕様により、各チーム メンバーがインシデントを管理する役割を理解し、調整された効率的な対応が可能になります。 IRP を配置することで、組織はセキュリティ インシデント対応をより効率的に管理できます。これにより、最終的には組織のデータ損失の露出を制限し、侵害のコストを削減できます。

組織は、事業を行う国/国 (一般的なデータ保護規則 GDPR など) に基づく違反通知義務、または提供されている機能 (支払いデータが処理されている場合は PCI DSS など) に基づく可能性があります。 タイムリーな通知の失敗は重大な影響を及ぶ可能性があります。したがって、通知義務が確実に満たされるように、インシデント対応計画には、すべての利害関係者とのコミュニケーション、メディア通信プロセス、メディアに話すことができる人と話すことができない人を含む通信プロセスが含まれている必要があります。

ガイドライン: 内部コントロール

インシデント対応計画/手順の完全版を指定します。 インシデント対応計画には、識別から解決までのインシデントを処理するプロセスと、文書化された通信プロセスに関するセクションを含める必要があります。

証拠の例: 内部コントロール

次のスクリーンショットは、Contoso のインシデント対応計画の開始を示しています。

注: 証拠提出の一環として、インシデント対応計画全体を指定する必要があります。

証拠の例: 内部コントロール

次のスクリーンショットは、通信プロセスを示すインシデント対応計画からの抽出を示しています。

コントロール No. 26

以下を示す証拠を提供してください。

インシデント対応チームのすべてのメンバーは、インシデントに対応できる年次トレーニングを受けています。

意図: トレーニング

組織に侵害が含まれる時間が長いほど、データ流出のリスクが高くなり、流出データの量が多くなり、侵害の全体的なコストが大きくなる可能性があります。 組織のインシデント対応チームは、セキュリティ インシデントにタイムリーに対応する機能を備えている必要があります。 定期的なトレーニングを行い、テーブルの上の演習を実行することで、チームはセキュリティ インシデントを迅速かつ効率的に処理する準備を整えます。 このトレーニングでは、潜在的な脅威の特定、初期対応アクション、エスカレーション手順、長期的な軽減戦略など、さまざまな側面をカバーする必要があります。

推奨事項は、インシデント対応チームの内部インシデント対応トレーニングと、情報セキュリティ リスクにリンクする必要がある定期的なテーブルトップ 演習の両方を実行することです

評価を行って、発生する可能性が最も高いセキュリティ インシデントを特定します。 テーブルトップ演習では、実際のシナリオをシミュレートして、プレッシャーの下で対応するチームの能力をテストし、磨く必要があります。 これにより、組織は、セキュリティ侵害やサイバー攻撃を適切に処理する方法をスタッフに確実に認識させることができます。 また、チームは、最も可能性の高いセキュリティ インシデントを迅速に封じ込め、調査するために実行する手順を把握します。

ガイドライン: トレーニング

トレーニング内容を共有することでトレーニングが実行されたことを示す証拠と、参加したユーザーを示すレコード (すべてのインシデント対応チームを含める必要があります) を示す証拠を提供する必要があります。 または、テーブルトップ演習が実行されたことを示すレコードも同様です。このすべてが、証拠が提出されてから 12 か月以内に完了している必要があります。

証拠の例: トレーニング

Contoso は、外部セキュリティ会社を使用してインシデント対応テーブルトップ演習を実行しました。 コンサルティングの一部として生成されたレポートのサンプルを次に示します。

注: 完全なレポートを共有する必要があります。 この演習は、サード パーティ企業がこれを実行するための Microsoft 365 要件がないため、内部的にも実行できます。

注: 完全なレポートを共有する必要があります。 この演習は、サード パーティ企業がこれを実行するための Microsoft 365 要件がないため、内部的にも実行できます。

コントロール No. 27

次の証拠を提供してください。

インシデント対応戦略とサポート ドキュメントは、次のいずれかに基づいてレビューおよび更新されます。

• 卓上演習から学んだ教訓

• インシデントへの対応から学んだ教訓

• 組織の変更

意図: レビューを計画する

時間の経過と共に、インシデント対応計画は、組織の変更に基づいて、または計画の制定時に学習した教訓に基づいて進化する必要があります。 運用環境の変更では、脅威が変化したり、規制要件が変更されたりする可能性があるため、インシデント対応計画の変更が必要になる場合があります。 さらに、テーブルトップの演習と実際のセキュリティ インシデントの対応が行われると、多くの場合、これは改善できるプランの領域を特定できます。 これは計画に組み込む必要があり、このコントロールの目的は、このプロセスが確実に含まれるようにすることです。 このコントロールの目的は、組織のインシデント対応戦略のレビューと更新を義務付け、3 つの異なるトリガーに基づくドキュメントをサポートすることです。

• インシデント対応戦略の有効性をテストするためのシミュレートされた演習が実行された後、特定されたギャップまたは改善のための領域を、既存のインシデント対応計画に直ちに組み込む必要があります。

• 実際のインシデントは、現在の対応戦略の長所と短所に関する貴重な洞察を提供します。 インシデントが発生した場合は、インシデント後のレビューを実行してこれらのレッスンをキャプチャする必要があります。その後、対応戦略と手順を更新するために使用する必要があります。

• 合併、買収、重要な担当者の変更など、組織内の重要な変更は、インシデント対応戦略のレビューをトリガーする必要があります。 これらの組織の変更により、新しいリスクが発生したり、既存のリスクがシフトされたりする可能性があり、それに応じてインシデント対応計画を更新して、有効な状態を維持する必要があります。

ガイドライン: 計画レビュー

これは、多くの場合、セキュリティ インシデントの結果や、学習した教訓が特定され、インシデント対応計画が更新されたテーブルトップ演習の結果を確認することで証明されます。 計画では変更ログを保持する必要があります。これは、学習したレッスンや組織の変更に基づいて実装された変更も参照する必要があります。

証拠の例: 計画レビュー

次のスクリーンショットは、提供されたインシデント対応計画のスクリーンショットです。これには、学習したレッスンや組織の変更に基づく更新に関するセクションが含まれています。

注: これらの例は全画面表示のスクリーンショットではありません。すべての URL を含む全画面表示のスクリーンショットを送信し、ユーザーにログインし、証拠レビューの日時スタンプを送信する必要があります。 Linux ユーザーの場合は、コマンド プロンプトから実行できます。

事業継続計画とディザスター リカバリー計画

ビジネス継続計画とディザスター リカバリー計画は、組織のリスク管理戦略の重要な 2 つの要素です。 事業継続計画は、重要なビジネス機能が災害発生時および災害後も継続して稼働できるように計画を作成するプロセスであり、ディザスター リカバリー計画は、災害から復旧し、通常の業務をできるだけ迅速に復旧するための計画を作成するプロセスです。 どちらの計画も相互に補完し合います。災害や予期しない中断によって生じる運用上の課題に耐える必要があります。 これらの計画は、組織が障害発生時に運用を継続し、評判を保護し、法的要件に準拠し、顧客の信頼を維持し、リスクを効果的に管理し、従業員を安全に保つために役立つため、重要です。

コントロール No. 28

以下を示す証拠を提出してください。

ドキュメントが存在し、維持されています。これは、ビジネス継続計画の概要と次のものが含まれます。

• その役割や責任を含む、関連する担当者の詳細

• 関連するコンティンジェンシー要件と目標を持つビジネス機能

• システムとデータのバックアップ手順、構成、スケジュール/保持

• 回復の優先順位と時間枠のターゲット

• 予期しない予定外の中断が発生した場合に重要な情報システム、ビジネス機能、サービスを運用に戻すために従うアクション、手順、および手順を詳述するコンティンジェンシー 計画

• 最終的な完全なシステム復元をカバーし、元の状態に戻る確立されたプロセス

意図: 事業継続計画

このコントロールの背後にある意図は、ロールと責任が割り当てられた担当者の明確に定義されたリストがビジネス継続計画に含まれていることを確認することです。 これらのロールは、インシデント時の計画の効果的なアクティブ化と実行に不可欠です。

ガイドライン: 事業継続計画

ディザスター リカバリー計画/手順の完全版を指定してください。これには、コントロールの説明で処理されたアウトラインをカバーするセクションが含まれている必要があります。 デジタル バージョンの場合は実際の PDF/WORD ドキュメントを指定します。または、オンライン プラットフォームを通じてプロセスが管理されている場合は、プロセスのエクスポートまたはスクリーンショットを提供します。

証拠の例: ビジネス継続計画

次のスクリーンショットは、ビジネス継続性プランの抽出と、それが存在し、維持されていることを示しています。

注: このスクリーンショットはポリシー/プロセス ドキュメントのスナップショットを示しています。ISV が実際のサポート ポリシー/プロシージャ ドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

次のスクリーンショットは、関連するチーム、連絡先の詳細、実行する手順など、"キー スタッフ" セクションの概要が示されているポリシーの抽出を示しています。

意図: 優先順位付け

このコントロールの目的は、重要度に応じてビジネス機能を文書化して優先順位付けすることです。 これには、計画外の中断中に各関数を維持または迅速に復元するために必要な対応するコンティンジェンシー要件の概要が含まれている必要があります。

ガイドライン: 優先順位付け

ディザスター リカバリー計画/手順の完全版を指定してください。これには、コントロールの説明で処理されたアウトラインをカバーするセクションが含まれている必要があります。 デジタル バージョンの場合は実際の PDF/WORD ドキュメントを指定します。または、オンライン プラットフォームを通じてプロセスが管理されている場合は、プロセスのエクスポートまたはスクリーンショットを提供します。

証拠の例: 優先順位付け

次のスクリーンショットは、ビジネス継続計画の抽出と、ビジネス機能とその重要度レベルの概要、およびコンティンジェンシー 計画が存在する場合を示しています。

注: このスクリーンショットはポリシー/プロセス ドキュメントを示しています。ISV は実際のサポート ポリシー/プロシージャ ドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

意図: バックアップ

このサブポイントの目的は、重要なシステムとデータをバックアップするための文書化された手順を維持することです。 ドキュメントでは、データが現在のデータと取得可能な両方であることを確認するために、構成設定とバックアップ スケジュールと保持ポリシーも指定する必要があります。

ガイドライン: バックアップ

ディザスター リカバリー計画/手順の完全版を指定してください。これには、コントロールの説明で処理されたアウトラインをカバーするセクションが含まれている必要があります。 デジタル バージョンの場合は実際の PDF/WORD ドキュメントを指定します。または、オンライン プラットフォームを通じてプロセスが管理されている場合は、プロセスのエクスポートまたはスクリーンショットを提供します。

証拠の例: バックアップ

次のスクリーンショットは、Contoso のディザスター リカバリー 計画の抽出と、文書化されたバックアップ構成がすべてのシステムに存在することを示しています。 次のスクリーンショットでは、バックアップ スケジュールも概説されていることに注意してください。この例では、ビジネス継続性とディザスター リカバリー計画が連携するディザスター リカバリー 計画の一部としてバックアップ構成が概説されていることに注意してください。

注: このスクリーンショットはポリシー/プロシージャ ドキュメントのスナップショットを示しています。ISV は実際のサポート ポリシー/プロシージャ ドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

意図: タイムライン

このコントロールは、復旧アクションの優先順位付けされたタイムラインを確立することを目的としています。 これらの復旧時間目標 (RTO) は、ビジネスへの影響分析に合わせて調整し、どのシステムと機能を最初に復元する必要があるかを担当者が理解できるように明確に定義する必要があります。

ガイドライン: タイムライン

ディザスター リカバリー計画/手順の完全版を指定してください。これには、コントロールの説明で処理されたアウトラインをカバーするセクションが含まれている必要があります。 デジタル バージョンの場合は実際の PDF/WORD ドキュメントを指定します。または、オンライン プラットフォームを通じてプロセスが管理されている場合は、プロセスのエクスポートまたはスクリーンショットを提供します。

証拠の例: タイムライン

次のスクリーンショットは、ビジネス機能の継続と重要度の分類と、確立された目標復旧時間 (RTO) を示しています。

注: このスクリーンショットはポリシー/プロセス ドキュメントを示しています。ISV は実際のサポート ポリシー/プロシージャ ドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

意図: 回復

この制御は、重要な情報システム、ビジネス機能、およびサービスを運用状態に戻すために従う手順を提供することを目的としています。 これは、迅速かつ効果的なアクションが不可欠な高圧の状況で意思決定を導くために十分に詳しく説明する必要があります。

ガイドライン: 回復

ディザスター リカバリー計画/手順の完全版を指定してください。これには、コントロールの説明で処理されたアウトラインをカバーするセクションが含まれている必要があります。 デジタル バージョンの場合は実際の PDF/WORD ドキュメントを指定します。または、オンライン プラットフォームを通じてプロセスが管理されている場合は、プロセスのエクスポートまたはスクリーンショットを提供します。

証拠の例: 回復

次のスクリーンショットは、ディザスター リカバリー 計画の抜粋と、文書化された復旧計画がすべてのシステムとビジネス機能に存在することを示しています。この例では、ビジネス継続計画とディザスター リカバリー 計画が連携して完全な復旧/復旧を実現するため、システム復旧手順がディザスター リカバリー 計画の一部であることに注意してください。

注: このスクリーンショットはポリシー/プロセス ドキュメントを示しています。ISV は実際のサポート ポリシー/プロシージャ ドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

意図: 検証

この制御ポイントは、事業継続計画に、危機が管理された後にシステムを元の状態に復元する際に組織を導く構造化されたプロセスが含まれていることを目的としています。 これには、システムが完全に運用され、整合性が維持されていることを確認するための検証手順が含まれます。

ガイドライン: 検証

ディザスター リカバリー計画/手順の完全版を指定してください。これには、コントロールの説明で処理されたアウトラインをカバーするセクションが含まれている必要があります。 デジタル バージョンの場合は実際の PDF/WORD ドキュメントを指定します。または、オンライン プラットフォームを通じてプロセスが管理されている場合は、プロセスのエクスポートまたはスクリーンショットを提供します。

証拠の例: 検証

次のスクリーンショットは、事業継続計画ポリシーに記載されている復旧プロセスと、実行する手順/アクションを示しています。

注: このスクリーンショットはポリシー/プロシージャ ドキュメントのスナップショットを示しています。ISV は実際のサポート ポリシー/プロシージャ ドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

コントロール No. 29

以下を示す証拠を提出してください。

ドキュメントは存在し、維持されています。これはディザスター リカバリー 計画の概要を示し、少なくとも以下を含みます。

• その役割や責任を含む、関連する担当者の詳細

• 関連するコンティンジェンシー要件と目標を持つビジネス機能

• システムとデータのバックアップ手順、構成、スケジュール/保持

• 回復の優先順位と時間枠のターゲット

• 予期しない予定外の中断が発生した場合に重要な情報システム、ビジネス機能、サービスを運用に戻すために従うアクション、手順、および手順を詳述するコンティンジェンシー 計画

• 最終的な完全なシステム復元をカバーし、元の状態に戻る確立されたプロセス

意図: DRP

このコントロールの目的は、ディザスター リカバリー チームの各メンバーに対して、十分に文書化された役割と責任を持つことです。 また、ディザスター シナリオ中に適切な担当者によって問題が迅速に昇格および解決されるように、エスカレーション プロセスの概要も示す必要があります。

ガイドライン: DRP

ディザスター リカバリー計画/手順の完全版を指定してください。これには、コントロールの説明で処理されたアウトラインをカバーするセクションが含まれている必要があります。 デジタル バージョンの場合は実際の PDF/WORD ドキュメントを指定します。または、オンライン プラットフォームを通じてプロセスが管理されている場合は、プロセスのエクスポートまたはスクリーンショットを提供します。

証拠の例: DRP

次のスクリーンショットは、ディザスター リカバリー 計画の抽出と、それが存在し、維持されていることを示しています。

注: このスクリーンショットはポリシー/プロセス ドキュメントを示しています。ISV は実際のサポート ポリシー/プロシージャ ドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

次のスクリーンショットは、関連するチーム、連絡先の詳細、エスカレーションの手順など、"コンティンジェンシー プラン" の概要が示されているポリシーの抽出を示しています。

意図: インベントリ

このコントロールの背後にある目的は、ビジネス運用をサポートするために重要なすべての情報システムの最新のインベントリ リストを維持することです。 この一覧は、ディザスター リカバリー作業中に優先順位を付ける必要があるシステムを理解するための基本です。

ガイドライン: インベントリ

ディザスター リカバリー計画/手順の完全版を指定してください。これには、コントロールの説明で処理されたアウトラインをカバーするセクションが含まれている必要があります。 デジタル バージョンの場合は実際の PDF/WORD ドキュメントを指定します。または、オンライン プラットフォームを通じてプロセスが管理されている場合は、プロセスのエクスポートまたはスクリーンショットを提供します。

証拠の例: インベントリ

次のスクリーンショットは、DRP の抽出と、重要なシステムとその重要度レベル、およびシステム機能のインベントリが存在することを示しています。

注: このスクリーンショットはポリシー/プロセス ドキュメントを示しています。ISV は実際のサポート ポリシー/プロシージャ ドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

次のスクリーンショットは、分類とサービスの重要度の定義を示しています。

注: このスクリーンショットはポリシー/プロセス ドキュメントを示しています。ISV は実際のサポート ポリシー/プロシージャ ドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

意図: バックアップ

この制御では、システムとデータのバックアップに対して適切に定義された手順が実施されている必要があります。 これらの手順では、障害や障害が発生した場合にすべての重要なデータを確実に復元できるように、バックアップの頻度、構成、場所の概要を説明する必要があります。

ガイドライン: バックアップ

ディザスター リカバリー計画/手順の完全版を指定してください。これには、コントロールの説明で処理されたアウトラインをカバーするセクションが含まれている必要があります。 デジタル バージョンの場合は実際の PDF/WORD ドキュメントを指定します。または、オンライン プラットフォームを通じてプロセスが管理されている場合は、プロセスのエクスポートまたはスクリーンショットを提供します。

証拠の例: バックアップ

次のスクリーンショットは、ディザスター リカバリー 計画の抽出と、文書化されたバックアップ構成がすべてのシステムに存在することを示しています。 バックアップ スケジュールの概要も以下に示します。

注: このスクリーンショットは、ポリシー/プロセス ドキュメントのスナップショットを示しています。ISV が実際のサポート ポリシー/プロシージャ ドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

意図: 回復

この制御では、重要なシステムとデータを復元するための手順の概要を示す包括的な復旧計画が必要です。 これはディザスター リカバリー チームのロードマップとして機能し、すべての復旧アクションが事前に計画され、ビジネス操作の復元に効果的であることを保証します。

ガイドライン: 回復

ディザスター リカバリー計画/手順の完全版を指定してください。これには、コントロールの説明で処理されたアウトラインをカバーするセクションが含まれている必要があります。 デジタル バージョンの場合は実際の PDF/WORD ドキュメントを指定します。または、オンライン プラットフォームを通じてプロセスが管理されている場合は、プロセスのエクスポートまたはスクリーンショットを提供します。

証拠の例: 回復

次のスクリーンショットは、ディザスター リカバリー 計画の抽出と、機器の交換とシステムの回復手順と手順が存在し、文書化されていること、復旧期間、クラウド インフラストラクチャを復元するためのアクションなどを含む復旧手順を示しています。

注: このスクリーンショットは、ポリシー/プロセス ドキュメントのスナップショットを示しています。ISV が実際のサポート ポリシー/プロシージャ ドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

コントロール No. 30

以下を示す証拠を提出してください。

ビジネス継続計画とディザスター リカバリー 計画は、少なくとも 12 か月ごとにレビューされ、悪影響が生じても有効であり続け、次に基づいて更新されます。

• 計画の年次レビュー。

• 関連するすべての担当者は、コンティンジェンシー 計画で割り当てられた役割と責任に関するトレーニングを受けます。

• プランは、ビジネス継続性またはディザスター リカバリーの演習を通じてテストされます。

• テスト結果は、演習や組織の変更から学んだ教訓を含めて文書化されています。

意図: 年次レビュー

この制御の目的は、ビジネス継続性とディザスター リカバリー計画が毎年レビューされるようにすることです。 レビューでは、計画がまだ有効で正確であり、現在のビジネス目標と技術的なアーキテクチャと一致していることを確認する必要があります。

目的: 年次トレーニング

この制御では、ビジネス継続計画とディザスター リカバリー 計画で指定された役割を持つすべての個人が毎年適切なトレーニングを受ける必要があります。 目標は、障害やビジネスの中断が発生した場合に、責任を認識し、効果的に実行できるようにすることです。

意図: 演習

ここでの目的は、実際の演習を通じて、ビジネス継続性とディザスター リカバリー計画の有効性を検証することです。 これらの演習は、組織がビジネス運用を維持または復元できる程度をテストするために、さまざまな不利な条件をシミュレートするように設計する必要があります。

意図: 分析

最後のコントロール ポイントは、うまく機能した内容とうまくいかなかったもののの分析など、すべてのテスト結果を徹底的に文書化することを目的としています。 学習した教訓を計画に組み込み、組織の回復性を向上させるために、すべての欠点に直ちに対処する必要があります。

ガイドライン: レビュー

レポート、会議ノート、毎年のビジネス継続性とディザスター リカバリー計画の演習の出力などの証拠は、レビューのために提供する必要があります。

証拠の例: レビュー

次のスクリーンショットは、ビジネス継続性とディザスター リカバリー 計画の訓練 (演習) のレポート出力を示しています。この演習では、チームがビジネス継続性とディザスター リカバリー計画を制定し、ビジネス機能とシステム運用の正常な復旧までの状況をチュートリアルできます。

注: これらのスクリーンショットは、ポリシー/プロセス ドキュメントのスナップショットを示しています。ISV は、単にスクリーンショットを提供するのではなく、実際のサポート ポリシー/プロシージャ ドキュメントを共有することが想定されています。

注: これらのスクリーンショットは、ポリシー/プロセス ドキュメントのスナップショットを示しています。ISV は、単にスクリーンショットを提供するのではなく、実際のサポート ポリシー/プロシージャ ドキュメントを共有することが想定されています。

詳細情報

• サンプル証拠ガイド - 概要
• 証拠のサンプル ガイド - データのセキュリティとプライバシー