Microsoft 365 認定 - サンプル証拠ガイド

概要

このガイドは、MICROSOFT 365 認定コントロールごとに必要な証拠の種類と詳細レベルの例を ISV に提供するために作成されています。 このドキュメントで共有されている例は、コントロールが満たされていることを示すために使用できる唯一の証拠を表すものではなく、必要な証拠の種類のガイドラインとしてのみ機能します。

注: 要件を満たすために使用される実際のインターフェイス、スクリーンショット、ドキュメントは、製品の使用、システムのセットアップ、および内部プロセスによって異なります。 さらに、ポリシーまたは手順のドキュメントが必要な場合、ISV は実際のドキュメントを送信するために必要であり、一部の例に示されているようにスクリーンショットは必要ありません。

認定には、提出が必要な 2 つのセクションがあります。

1. 初期ドキュメント提出: 評価のスコープを設定するために必要な、高いレベルのドキュメントの小さなセット。
2. 証拠提出: 認定評価のスコープ内の各コントロールに必要な証拠の完全なセット。

ヒント

Microsoft 365 (ACAT) 用アプリ コンプライアンス自動化ツールを試して、証拠の収集と制御の検証を自動化することで、Microsoft 365 認定を達成するための高速パスを実現してください。 ACAT によって完全に自動化される制御について詳しく説明します。

構造

このドキュメントは、パートナー センターでの認定中に表示されるコントロールに直接マップされます。 このドキュメントで提供されるガイダンスの詳細は次のとおりです。

• セキュリティ ドメイン: すべてのコントロールがグループ化される 3 つのセキュリティ ドメイン:アプリケーション セキュリティ、運用セキュリティ、およびデータ セキュリティとプライバシー。
• コントロール: = 評価アクティビティの説明 - これらのコントロールと関連する番号 (No.) は、Microsoft 365 認定チェックリストから直接取得されます。
• 意図: = セキュリティ制御がプログラム内に含まれる理由と、軽減を目的とする特定のリスクの意図。 この情報は、収集する必要がある証拠の種類と、ISV が注意を払い、その証拠を生成する上で認識と理解を持つ必要があるものを理解するために、コントロールの背後にある推論を ISV に提供することを期待しています。
• 証拠ガイドラインの例: = Microsoft 365 認定チェックリスト スプレッドシートの証拠収集タスクのガイドに役立てるために、ISV は、それを使用する認定アナリストが使用できる証拠の種類の例を明確に確認し、コントロールが配置され維持されていることを確実に判断できます。これは、決して網羅的ではありません。
• 証拠の例: = このセクションでは、Microsoft 365 認定チェックリスト スプレッドシート内の各コントロールに対してキャプチャされた潜在的な証拠のスクリーンショットと画像の例を示します。具体的には、オペレーショナル セキュリティとデータ セキュリティとプライバシー セキュリティ ドメイン (スプレッドシート内のタブ) です。 例内の赤い矢印とボックスがある情報は、コントロールを満たすために必要な要件をさらに理解するのに役立ちます。

セキュリティ ドメイン: アプリケーション セキュリティ

コントロール 1 - コントロール 16:

Application Security ドメインのコントロールは、アプリに未解決の脆弱性がないことを示す、過去 12 か月以内に発行された侵入テスト レポートに満足できます。 唯一必要な提出は、信頼できる独立した会社によるクリーンレポートです。

セキュリティ ドメイン: 運用セキュリティ/セキュリティで保護された開発

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

マルウェア対策 - ウイルス対策

コントロール #1: ウイルス対策のプラクティスと手順を管理するポリシー ドキュメントを提供します。

• 意図: このコントロールの目的は、コンピューター ウイルスからの脅威を考慮するときに直面する問題に対する ISV の理解を評価することです。 ISV は、ウイルス対策ポリシーとプロセスを開発する際に業界のベスト プラクティスを確立して使用することで、マルウェアが直面するリスクを軽減するorganizationの能力に合わせて調整されたリソースを提供し、ウイルス検出と排除のベスト プラクティスを示し、文書化されたポリシーがorganizationとその従業員に推奨されるセキュリティ ガイダンスを提供することを示す証拠を提供します。 ISV がマルウェア対策を展開する方法のポリシーと手順を文書化することで、環境へのマルウェアのリスクを軽減するために、このテクノロジの一貫したロールアウトとメンテナンスが保証されます。
• 証拠ガイドラインの例: ウイルス対策/マルウェア対策のベスト プラクティスを促進するためにインフラストラクチャ内に実装されたプロセスと手順を詳しく説明したウイルス対策/マルウェア対策ポリシーのコピーを提供します。 証拠の例
• 証拠の例:

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

コントロール #2: サンプリングされたすべてのシステム コンポーネントでウイルス対策ソフトウェアが実行されていることを実証できる証拠を提供します。

• 意図: ウイルス対策 (AV) (またはマルウェア対策) を環境内で実行して、攻撃が増加する可能性がある、または認識していない可能性があるサイバー セキュリティ リスクから保護することが重要です。高度と数値の両方で攻撃が増加している可能性があります。 AV をその使用をサポートするすべてのシステム コンポーネントに展開すると、環境にマルウェア対策が導入されるリスクの一部を軽減するのに役立ちます。 アクティビティ グループが環境に足がかりを得るために攻撃のベクトルを提供するには、保護されていないエンドポイントが 1 つだけ必要です。 したがって、AV は、この種の脅威から保護するために、いくつかの防御層の 1 つとして使用する必要があります。
• 証拠ガイドラインの例: 評価された環境で AV のアクティブなインスタンスが実行されていることを証明する。 ウイルス対策プロセスの実行、ウイルス対策ソフトウェアがアクティブになっている、またはウイルス対策の一元的な管理コンソールがある場合は、その管理コンソールからそれを実証できる可能性がある、ウイルス対策の使用をサポートするサンプル内のすべてのデバイスのスクリーンショットを提供します。 管理コンソールを使用している場合は、サンプリングされたデバイスが接続され、動作していることをスクリーンショットに示してください。
• 証拠例 1: 次のスクリーンショットは、Azure Security Centerから取得されています。マルウェア対策拡張機能が "MSPGPRODAZUR01" という名前の VM にデプロイされていることを示しています。

• 証拠例 2

次のスクリーンショットは、Windows 10 デバイスから取得されており、ホスト名 "クララネット-SBU-WM" に対して "リアルタイム保護" がオンになっていることを示しています。

コントロール #3: すべての環境 (1 日以内) にウイルス対策署名が最新の状態であることを実証可能な証拠を提供します。

• 意図: 毎日何十万もの新しいマルウェアと望ましくない可能性のあるアプリケーション (PUA) が特定されます。 新しくリリースされたマルウェアに対して適切な保護を提供するには、新しくリリースされたマルウェアを考慮して AV 署名を定期的に更新する必要があります。
• この制御は、ISV が環境のセキュリティと古い AV がセキュリティに与える影響を考慮に入れているかどうかを確認するために存在します。
• 証拠ガイドラインの例: サンプリングされた各デバイスからウイルス対策ログ ファイルを提供し、更新プログラムが毎日適用されることを示します。
• 証拠の例: 次のスクリーンショットは、更新プログラムである 'Event 2000, Windows Defender' を表示して、少なくとも毎日更新するMicrosoft Defenderを示しています。 ホスト名が表示され、これはスコープ内システム "クララネット-SBU-WM" から取得されたことを示しています。

メモ： 提供される証拠には、より長い期間にわたって毎日の更新を表示するために、ログのエクスポートを含める必要があります。 一部のウイルス対策製品では更新ログ ファイルが生成されるため、これらのファイルを指定するか、イベント ビューアーからログをエクスポートする必要があります。

制御 #4: サンプリングされたすべてのシステム コンポーネントでオンアクセス スキャンまたは定期的スキャンを実行するようにウイルス対策が構成されていることを実証できる証拠を提供します。

メモ： アクセス時のスキャンが有効になっていない場合は、毎日のスキャンとalerting_の最小値が有効_be 必要があります 。

• 意図: このコントロールの目的は、マルウェアが環境への影響を最小限に抑えるために迅速に識別されるようにすることです。 オンアクセススキャンが実行され、マルウェアを自動的にブロックする場合、これはウイルス対策ソフトウェアによって知られているマルウェア感染を停止するのに役立ちます。 サービスの停止を引き起こす誤検知のリスクのためにオンアクセス スキャンが望ましくない場合は、被害を最小限に抑えるために、マルウェア感染に対するタイムリーな対応を確保するために、適切な毎日 (またはそれ以上) のスキャンとアラートメカニズムを実装する必要があります。
• 証拠ガイドラインの例: ウイルス対策をサポート するサンプル内のすべてのデバイス のスクリーンショットを提供します。ウイルス対策がデバイスで実行されており、オンアクセス (リアルタイム スキャン) スキャン用に構成されていることを示します。または、定期的なスキャンが毎日のスキャンに対して有効になっていることを示すスクリーンショットを提供 するか 、アラートが構成され、サンプル 内のすべてのデバイス の最終スキャン日が示されています。
• 証拠の例: 次のスクリーンショットは、ホストに対してリアルタイム保護が有効になっていることを示しています。"クララネット-SBU-WM" です。

コントロール #5: マルウェアや検疫を自動的にブロックし、サンプリングされたすべてのシステム コンポーネント全体でアラートを生成するようにウイルス対策が構成されていることを実証可能な証拠を提供します。

• 意図: マルウェアの洗練は、さまざまな程度の破壊と共に常に進化しています。 この制御の目的は、マルウェアの実行を停止し、潜在的に壊滅的なペイロードの実行を停止するか、自動ブロックがオプションではない場合は、マルウェアが潜在的なマルウェア感染に警告してすぐに対応することで大混乱を引き起こす可能性がある時間を制限することです。

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

• 証拠 1 の例: 次のスクリーンショットは、ホスト "クララネット-SBU-WM" が、Microsoft Defender ウイルス対策に対してリアルタイム保護で構成されていることを示しています。 設定が示すように、これにより、マルウェアがデバイスにインストールまたは実行されるのを見つけて停止します。

コントロール #6: デプロイされる前にアプリケーションが承認されていることを示す証拠を提供します。

• 意図: アプリケーション制御を使用すると、オペレーティング システムでの実行が許可されている各アプリケーション/プロセスが、organizationによって承認されます。 このコントロールの目的は、どのアプリケーション/プロセスを実行できるかを承認するための承認プロセスが確実に行われるようにすることです。

• 証拠ガイドラインの例: 承認プロセスに従っていることを示す証拠を提供できます。 これは、署名されたドキュメントで提供されたり、変更管理システム内で追跡されたり、Azure DevOps や JIRA などを使用してこれらの要求と承認を追跡したりできます。

• 証拠の例: 次のスクリーンショットは、環境内での実行を許可された各アプリケーションが承認プロセスに従っていることを、管理による承認を示しています。 これは Contoso の紙ベースのプロセスですが、他のメカニズムが使用される場合があります。

コントロール #7: ビジネス上の正当な理由を持つ承認済みアプリケーションの完全な一覧が存在し、維持されていることを示す証拠を提供します。

• 意図: 組織は、承認されたすべてのアプリケーションの一覧と、アプリケーション/プロセスが承認された理由に関する情報を保持することが重要です。 これにより、構成が最新の状態に保たれ、ベースラインに対して確認して、未承認のアプリケーション/プロセスが構成されていないことを確認できます。

• 証拠ガイドラインの例: 承認されたアプリケーション/プロセスの文書化された一覧とビジネス上の正当な理由を提供します。

• 証拠の例: 次のスクリーンショットは、ビジネス上の正当な理由を持つ承認済みアプリケーションの一覧です。

メモ： このスクリーンショットはドキュメントを示しています。ISV が実際のサポート ドキュメントを共有し、スクリーンショットを提供しないことを期待しています。

コントロール #8: アプリケーション制御ソフトウェアが特定のアプリケーション制御メカニズムを満たすように構成されていることを詳しく説明するサポート ドキュメントを提供します。

• 意図: アプリケーション制御テクノロジの構成は、テクノロジを維持する方法、つまり、アプリケーション/プロセスを追加および削除する方法のプロセスと共に文書化する必要があります。 このドキュメントの一部として、使用されるメカニズムの種類は、アプリケーション/プロセスごとに詳しく説明する必要があります。 これにより、次のコントロールにフィードされ、テクノロジがドキュメントに記載されているように構成されます。

• 証拠ガイドラインの例: アプリケーション制御の設定方法と、各アプリケーション/プロセスがテクノロジ内でどのように構成されているかを詳しく説明するサポート ドキュメントを提供します。

• 証拠の例: 次のスクリーンショットは、アプリケーション コントロールの実装に使用される制御メカニズムの一覧です。 以下では、1 つのアプリが証明書コントロールを使用しており、他のアプリはファイル パスを使用していることがわかります。

メモ： このスクリーンショットはドキュメントを示しています。ISV が実際のサポート ドキュメントを共有し、スクリーンショットを提供しないことを期待しています。

コントロール #9: サンプリングされたすべてのシステム コンポーネントから文書化されているようにアプリケーション制御が構成されていることを示す証拠を提供します。

• 意図: この目的は、ドキュメントに従ってアプリケーション制御がサンプル全体で構成されていることを検証することです。

• 証拠ガイドラインの例: サンプル 内のすべてのデバイス のスクリーンショットを提供して、アプリケーション コントロールが構成されアクティブ化されていることを示します。 これにより、マシン名、所属するグループ、およびそれらのグループとマシンに適用されるアプリケーション制御ポリシーが表示されます。

• 証拠の例: 次のスクリーンショットは、ソフトウェア制限ポリシーが有効になっているグループ ポリシー オブジェクトを示しています。

次のスクリーンショットは、上記のコントロールに沿った構成を示しています。

次のスクリーンショットは、Microsoft 365 環境と、この GPO オブジェクト 'ドメイン コンピューター設定' に適用されているスコープ内に含まれるコンピューターを示しています。

この最後のスクリーンショットは、スコープ内サーバー "DBServer1" が上のスクリーンショット内の OU 内にあることを示しています。

パッチ管理 – リスクランキング

セキュリティの脆弱性の迅速な識別と修復は、環境またはアプリケーションを損なうアクティビティ グループのリスクを最小限に抑えるのに役立ちます。 パッチ管理は、リスクのランク付けと修正プログラムの 2 つのセクションに分かれています。 これら 3 つのコントロールは、セキュリティの脆弱性の識別をカバーし、発生するリスクに応じてランク付けします。

このセキュリティ制御グループは、アプリケーション/アドインのサード パーティ製ソフトウェア ライブラリとコード ベースにリスクのランク付けに基づいて修正プログラムを適用する必要があるため、サービスとしてのプラットフォーム (PaaS) ホスティング環境のスコープ内にあります。

コントロール #10: 新しいセキュリティ脆弱性を特定し、リスク スコアを割り当てる方法を管理するポリシー ドキュメントを提供します。

• 意図: このコントロールの目的は、セキュリティの脆弱性を迅速に特定し、アクティビティ グループがこれらの脆弱性を悪用する機会を減らすためのサポート ドキュメントを用意することです。 組織で使用されているすべてのシステム コンポーネントをカバーする脆弱性を特定するには、堅牢なメカニズムを用意する必要があります。たとえば、オペレーティング システム (Windows Server、Ubuntu など)、アプリケーション (Tomcat、MS Exchange、SolarWinds など)、コードの依存関係 (AngularJS、jQuery など)。 組織は、資産内の脆弱性をタイムリーに特定するだけでなく、脆弱性が存在するリスクに基づいて適切な期間内に修復が確実に実行されるように脆弱性をランク付けする必要があります。

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

• 証拠ガイドラインの例: サポート ドキュメントを提供します (スクリーンショットではありません)

• 証拠の例: このスクリーンショットは、リスクランク付けポリシーのスニペットを示しています。

メモ： このスクリーンショットはポリシー/プロセス ドキュメントを示しています。ISV が実際のサポート ポリシー/プロシージャ ドキュメントを共有し、screenshot._を提供しないことを想定しています

コントロール #11: 新しいセキュリティの脆弱性がどのように識別されるかを示す証拠を提供します。

• 意図: このコントロールの目的は、プロセスに従っていることを確認し、環境全体で新しいセキュリティの脆弱性を特定するのに十分な堅牢性を確保することです。 これはオペレーティング システムだけではありません。これには、環境内で実行されているアプリケーションと、コードの依存関係が含まれる場合があります。

• 証拠ガイドラインの例: 証拠は、メーリング リストへのサブスクリプションを表示し、新しくリリースされた脆弱性のセキュリティ ソースを手動で確認することで提供される可能性があります (つまり、JIRA または Azure DevOps のアクティビティのタイムスタンプで適切に追跡する必要があります)。古いソフトウェアを見つけるツール (たとえば、古いソフトウェア ライブラリを探すときに Snyk になる可能性があります)。 または、古いソフトウェアを識別する認証されたスキャンを使用して Nessus である可能性があります。

メモ Nessus を使用する場合は、脆弱性を迅速に特定するために、これを定期的に実行する必要があります。 少なくとも毎週お勧めします。

• 証拠の例: このスクリーンショットは、メーリング グループがセキュリティの脆弱性の通知に使用されていることを示しています。

コントロール #12: すべての脆弱性が特定されるとリスク ランク付けが割り当てられていることを示す証拠を提供します。

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

• 証拠ガイドラインの例: スクリーンショットなどの方法で証拠を提供します。たとえば、DevOps/Jira は、脆弱性がリスクランク付けプロセスを通過し、organizationによって適切なリスクランク付けが割り当てられていることを示しています。

• 証拠の例: このスクリーンショットは、列 D 内で発生するリスクランク付けと列 F と G の再ランク付けを示しています。organizationがリスク評価を実行し、リスクをダウングレードできることを判断する必要があります。 リスク評価の再順位付けの証拠は、サポート証拠として提供する必要があります

パッチ管理 – パッチ適用

以下のコントロールは、Patch Management のパッチ適用要素用です。 安全なオペレーティング環境を維持するには、アプリケーション/アドオンとサポート システムに適切なパッチが適用されている必要があります。 "アクティビティ グループ" によって脆弱性が悪用される機会を減らすために、識別 (またはパブリック リリース) と修正プログラムの間の適切な期間を管理する必要があります。 Microsoft 365 認定資格では "修正プログラム適用期間" は規定されていませんが、認定アナリストは妥当でない期間を拒否します。

このセキュリティ制御グループは、アプリケーション/アドインのサード パーティ製ソフトウェア ライブラリとコード ベースにリスクのランク付けに基づいて修正プログラムを適用する必要があるため、サービスとしてのプラットフォーム (PaaS) ホスティング環境のスコープ内にあります。

制御 #13: 重大、高、中のリスクの脆弱性に対する適切な最小限のパッチ適用期間を含む、スコープ内のシステム コンポーネントのパッチ適用に関するポリシー ドキュメントを提供します。サポートされていないオペレーティング システムとソフトウェアの使用停止。

• 意図: パッチ管理は、PCI-DSS、ISO 27001、NIST (SP) 800-53 など、多くのセキュリティ コンプライアンス フレームワークで必要です。 適切なパッチ管理の重要性は、ソフトウェア、ファームウェアのセキュリティと機能の問題を修正し、脆弱性を軽減できるため、ストレスを超えることはできません。これは、悪用の機会の削減に役立ちます。 この制御の目的は、アクティビティ グループがスコープ内環境内に存在する可能性がある脆弱性を悪用する機会の期間を最小限に抑えるためです。

• 証拠ガイドラインの例: パッチ管理のプロセスを詳しく説明するすべてのポリシーと手順のコピーを提供します。 これには、最小限のパッチ適用ウィンドウのセクションが含まれている必要があり、サポートされていないオペレーティング システムとソフトウェアを環境内で使用しないでください。

• 証拠の例: ポリシー ドキュメントの例を次に示します。

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

コントロール #14: サンプリングされたすべてのシステム コンポーネントにパッチが適用されていることを示す証拠を提供します。

メモ： 任意のソフトウェア/サード パーティ製ライブラリを含めます。

• 意図: 脆弱性にパッチを適用すると、情報テクノロジ インフラストラクチャ (ハードウェア、ソフトウェア、サービス) の一部を形成する異なるモジュールが最新の状態に保たれ、既知の脆弱性から解放されます。 脆弱性の詳細のリリースと修正プログラムの適用の間のセキュリティ インシデントの可能性を最小限に抑えるには、できるだけ早く修正プログラムを適用する必要があります。 これは、脆弱性の悪用が野生にあると知られている場合にさらに重要です。

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

• 証拠の例: 次のスクリーンショットは、スコープ 内のシステム コンポーネント "クララネット-SBU-WM" が、パッチ適用ポリシーに従って Windows 更新プログラムを実行していることを示しています。

メモ： スコープ内のすべてのシステム コンポーネントの修正プログラムが証拠である必要があります。 これには、次のようなものが含まれます。OS 更新、Application/Component 更新 (i.e__.、_ Apache Tomcat、OpenSSL など)、ソフトウェアの依存関係 (JQuery、AngularJS など) など。

コントロール #15: サポートされていないオペレーティング システムとソフトウェア コンポーネントが環境内で使用されていないことを示す証拠を提供します。

• 意図: ベンダーによって管理されていないソフトウェアは、残業中に、修正されていない既知の脆弱性に苦しんでいます。 そのため、サポートされていないオペレーティング システムとソフトウェア コンポーネントを運用環境で使用しないでください。

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

• 証拠例: 次の証拠は、Nessus が問題にフラグを設定していないため、スコープ内システム コンポーネント THOR がベンダーによってサポートされているソフトウェアを実行していることを示しています。

メモ： 完全なレポートは、認定アナリストと共有する必要があります。

• 証拠 2 の例

このスクリーンショットは、スコープ内のシステム コンポーネント "QUORUMNET-SBU-WM" がサポートされている Windows バージョンで実行されていることを示しています。

• 証拠 3 の例

次のスクリーンショットは Trivy 出力のスクリーンショットで、完全なレポートにはサポートされていないアプリケーションは一覧表示されません。

メモ： 完全なレポートは、認定アナリストと共有する必要があります。

脆弱性スキャン

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

制御 #16: 四半期ごとのインフラストラクチャと Web アプリケーションの脆弱性スキャン レポートを提供します。 スキャンは、パブリック フットプリント全体 (IP アドレスと URL) と内部 IP 範囲に対して実行する必要があります。

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

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

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

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

• 証拠の例: 証拠の例は、使用されているスキャン ツールからスキャン レポートを提供することです。 各四半期のスキャン レポートは、レビューのために提供する必要があります。 スキャンには、環境全体のシステム コンポーネントを含める必要があります。すべての内部サブネットと、環境で使用できるすべてのパブリック IP アドレス/URL。

コントロール #17: 脆弱性スキャン中に特定された脆弱性の修復が、文書化されたパッチ適用期間に沿って修正されるという実証可能な証拠を提供します。

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

• 証拠ガイドラインの例: 脆弱性スキャンから検出された脆弱性のサンプルが、上記のコントロール 13 で既に提供されているパッチ適用ウィンドウに沿って修復されることを示す適切な成果物 (つまりスクリーンショット) を提供します。

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

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

メモ： この制御のために、サーティフィケーション アナリストは、過去 12 か月間の四半期ごとの脆弱性スキャン レポートと修復を確認する必要があります。

ファイアウォール

ファイアウォールは、多くの場合、信頼された (内部ネットワーク)、信頼されていない (インターネット) 環境、および半信頼 (DMZ) 環境の間にセキュリティ境界を提供します。 これらは通常、組織の多層防御セキュリティ戦略内の最初の防御ラインであり、イングレス サービスとエグレス サービスのトラフィック フローを制御し、不要なトラフィックをブロックするように設計されています。 これらのデバイスは、効果的に動作し、環境を危険にさらす可能性のある構成ミスから解放されるように、厳しく制御する必要があります。

制御 #18: ファイアウォール管理のプラクティスと手順を管理するポリシー ドキュメントを提供します。

• 意図: ファイアウォールは、階層化されたセキュリティ (多層防御) 戦略における重要な防御の第一線であり、信頼されていないネットワーク ゾーンから環境を保護します。 ファイアウォールは通常、IP アドレスとプロトコル/ポートに基づいてトラフィック フローを制御します。さらに機能豊富なファイアウォールでは、アプリケーション トラフィックを検査して、アクセスされるアプリケーションに基づく誤用、脆弱性、脅威から保護することで、追加の "アプリケーション 層" 防御を提供することもできます。 これらの保護はファイアウォールの構成と同じくらい優れているため、強力なファイアウォール ポリシーとサポート手順を実施して、内部資産を適切に保護するように構成する必要があります。 たとえば、ANY ソースから ANY 宛先へのすべてのトラフィックを許可する規則を持つファイアウォールは、ルーターとして機能するだけです。

• 証拠ガイドラインの例: 完全なファイアウォール ポリシー/手順サポート ドキュメントを提供します。 このドキュメントでは、以下のすべての点と、環境に適用できるその他のベスト プラクティスについて説明する必要があります。

• 証拠の例: 以下は、必要なファイアウォール ポリシー ドキュメントの種類の例です (これはデモであり、完了していない可能性があります)。

コントロール #19: 運用環境へのインストール前に既定の管理資格情報が変更されたことを実証可能な証拠を提供します。

• 意図: 組織は、デバイスまたはソフトウェアの構成中に構成される既定の管理資格情報をベンダーが提供することを念頭に置く必要があります。 既定の資格情報は、多くの場合、ベンダーによって一般公開され、外部アクティビティ グループに環境を侵害する機会を提供できます。 たとえば、インターネット上で既定の iDrac (統合 Dell リモート アクセス コントローラー) 資格情報を簡単に検索すると、 root::calvin が既定のユーザー名とパスワードとして強調表示されます。 これにより、リモート サーバー管理にリモート アクセスできるようになります。 この制御の目的は、デバイス/アプリケーションのセキュリティ強化中に変更されていない既定のベンダー資格情報を使用して、環境が攻撃を受けないようにすることです。

• 証拠ガイドラインの例

• これは、Certification Analyst が既定の資格情報を使用してスコープ内デバイスに対して認証を試みることができるスクリーンシェアリング セッションで証明できます。

• 証拠の例

次のスクリーンショットは、WatchGuard ファイアウォールの無効なユーザー名/パスワードから認定アナリストに表示される内容を示しています。

制御 20: ファイアウォールがスコープ内環境の境界にインストールされ、境界ネットワーク (DMZ、非武装地帯、およびスクリーン サブネットとも呼ばれます) と内部信頼されたネットワークの間にインストールされていることを実証可能な証拠を提供します。

• 意図: ファイアウォールは、異なるセキュリティ レベルの異なるネットワーク ゾーン間のトラフィックを制御する機能を提供します。 すべての環境がインターネットに接続されているため、ファイアウォールは、インターネットとスコープ内環境の間の境界にインストールする必要があります。 さらに、信頼されていない DMZ (De-Militarized Zone) ネットワークと内部信頼されたネットワークの間にファイアウォールをインストールする必要があります。 DMZ は通常、インターネットからのトラフィックを処理するために使用されるため、攻撃の対象となります。 DMZ を実装し、ファイアウォールを使用してトラフィック フローを制御することで、DMZ の侵害は、内部信頼されたネットワークと企業/顧客データの侵害を必ずしも意味しません。 組織が侵害を迅速に特定し、アクティビティ グループが内部の信頼できるネットワークをさらに侵害する機会を最小限に抑えられるように、適切なログ記録とアラートを作成する必要があります。 この制御の目的は、信頼されたネットワークと信頼できないネットワークの間に適切な制御があることを確認することです。

• 証拠ガイドラインの例: DMZ が配置されていることを示すファイアウォール構成ファイルまたはスクリーンショットを使用して証拠を提供する必要があります。 これは、環境をサポートするさまざまなネットワークを示す提供されたアーキテクチャ図と一致する必要があります。 ファイアウォール上のネットワーク インターフェイスのスクリーンショット。初期ドキュメント送信の一部として既に提供されているネットワーク ダイアグラムと組み合わせて、この証拠を提供する必要があります。

• 証拠の例: 2 つの DMZ を示す WatchGuard ファイアウォールのスクリーンショットを次に示します。1 つは受信サービス (DMZ という名前)、もう 1 つはジャンプボックス (Bastian Host) を提供しています。

制御 21: すべてのパブリック アクセスが非武装地帯 (DMZ) で終了するという実証可能な証拠を提供します。

• 意図: パブリックにアクセス可能なリソースは、無数の攻撃に対して開かれています。 既に説明したように、DMZ の目的は、機密データを含む可能性がある信頼されていない内部ネットワークから信頼されていないネットワークをセグメント化することです。 DMZ は、外部アクティビティ グループによって侵害されることからパブリックにアクセスできるホストの大きなリスクがあるため、信頼度が低いと見なされます。 パブリック アクセスは、内部リソースとデータの保護に役立つファイアウォールによって適切にセグメント化された、信頼されていないこれらのネットワークで常に終了する必要があります。 この制御の目的は、信頼されていない内部ネットワーク上のリソースが公開されているかのように、信頼されていない DMZ 内ですべてのパブリック アクセスが終了するようにすることです。これらのリソースの侵害により、機密性の高いデータが保持されているネットワークへの足掛かりがアクティビティ グループに提供されます。

• 証拠ガイドラインの例

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

• 証拠の例

次のスクリーンショットでは、3 つの受信規則があり、それぞれが DMZ サブネットである 10.0.3.x サブネットと 10.0.4.x サブネットへの NAT を示しています

コントロール 22: ファイアウォール経由で許可されたすべてのトラフィックが承認プロセスを通過するという実証可能な証拠を提供します。

• 意図: ファイアウォールは、信頼されていないトラフィックと内部リソースの間、および異なる信頼レベルのネットワーク間の防御的な障壁であるため、ファイアウォールを安全に構成し、ビジネス操作に必要なトラフィックのみを有効にする必要があります。 不要なトラフィック フローや過度に許容されるトラフィック フローを許可することで、これらのさまざまなネットワーク ゾーンの境界における防御の弱点が生じる可能性があります。 すべてのファイアウォールの変更に対して堅牢な承認プロセスを確立することで、環境に重大なリスクをもたらすルールを導入するリスクが軽減されます。 Verizon の 2020 データ侵害調査レポート では、構成ミスを含む "Error's" が、一貫して年々増加している唯一のアクションの種類であることが強調されています。

• 証拠ガイドラインの例: 証拠は、承認されているファイアウォール変更要求を示すドキュメントの形式にすることができます。これは、CAB (変更アドバイザーボード) 会議から数分、またはすべての変更を追跡する変更制御システムによって行うことができます。

• 証拠の例: 次のスクリーンショットは、紙ベースのプロセスを使用して要求および承認されているファイアウォール規則の変更を示しています。 これは、たとえば DevOps や Jira などを使用して実現できます。

制御 23: ファイアウォール規則ベースが明示的に定義されていないトラフィックを削除するように構成されていることを実証可能な証拠として提供します。

• 意図: ほとんどのファイアウォールは、一致するルールを見つけるためにトップダウンアプローチでルールを処理します。 ルールが一致すると、そのルールのアクションが適用され、ルールのそれ以降のすべての処理が停止します。 一致するルールが見つからない場合、既定ではトラフィックは拒否されます。 このコントロールの目的は、一致するルールが見つからない場合にファイアウォールが既定でトラフィックを削除しない場合、ルール ベースには、 すべての ファイアウォール リストの末尾に "すべて拒否" ルールを含める必要があります。 これは、規則を処理するときにファイアウォールが既定で既定の許可状態にならないようにするため、明示的に定義されていないトラフィックを許可します。

• 証拠ガイドラインの例: 証拠は、ファイアウォール構成を使用するか、最後に "すべて拒否" 規則を示すすべてのファイアウォール規則を示すスクリーンショットで提供できます。または、ファイアウォールが既定で規則に一致しないトラフィックを削除した場合は、すべてのファイアウォール規則のスクリーンショットとベンダー管理ガイドへのリンクを指定して、ファイアウォールが既定で一致しないすべてのトラフィックをドロップすることを強調します。

• 証拠の例: 以下は、すべてのトラフィックを許可するように規則が構成されていないことを示す WatchGuard ファイアウォール規則ベースのスクリーンショットです。 WatchGuard は既定で一致しないトラフィックをドロップするため、最後に拒否ルールはありません。

次の WatchGuard ヘルプ センターのリンク。 https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/policies/policies_about_c.html には、次の情報が含まれます。

コントロール 24: ファイアウォールがすべてのコンソール以外の管理インターフェイスで強力な暗号化のみをサポートするという実証可能な証拠を提供します。

• 意図: 管理トラフィックの中間者攻撃を軽減するには、コンソール以外のすべての管理インターフェイスで強力な暗号化のみをサポートする必要があります。 このコントロールのメイン目的は、非コンソール接続がセットアップされるときに管理資格情報を保護することです。 また、これにより、接続への傍受から保護したり、管理機能を再生してデバイスを再構成したり、偵察の一部としてしたりするのにも役立ちます。

• 証拠ガイドラインの例: 構成でコンソール以外の管理インターフェイスの暗号化構成が提供される場合は、ファイアウォール構成を指定します (すべてのデバイスに構成可能なオプションとして含まれるわけではありません)。 これが構成内にない場合は、デバイスにコマンドを発行して、これらの接続に対して構成されている内容を表示できる場合があります。 一部のベンダーは、この情報を記事内で公開する可能性があるため、この情報を証拠する方法でもあります。 最後に、サポートされている暗号化を出力するツールを実行する必要がある場合があります。

• 証拠例: 次のスクリーンショットは、TCP ポート 8080 の WatchGuard ファイアウォールの Web 管理 インターフェイスに対する SSLScan の出力を示しています。 これは、AES-128 ビットの最小暗号化暗号を持つ TLS 1.2 以降を示しています。

注: WatchGuard ファイアウォールは、SSH (TCP ポート 4118) と WatchGuard システム マネージャー (TCP ポート 4105 & 4117) を使用した管理機能もサポートします。 これらのコンソール以外の管理インターフェイスの証拠も提供する必要があります。

コントロール 25: 少なくとも 6 か月ごとにファイアウォール規則のレビューを実行していることを示す証拠を提供します。

• 意図: 時間の経過と共に、スコープ内環境を持つシステム コンポーネントで構成が不気味になるリスクがあります。 これにより、多くの場合、環境に対する侵害のリスクを高める可能性のある、セキュリティ侵害や構成の誤りが発生する可能性があります。 構成のクリープは、トラブルシューティングに役立つ一時的な変更、アドホックな機能の変更に対する一時的な変更など、さまざまな理由で導入される可能性があります。これにより、クイック修正を導入する必要があるために過度に許容される可能性がある問題に対する迅速な修正が導入されます。 たとえば、緊急の問題を克服するための一時的なファイアウォール規則 "すべて許可" を導入できます。 このコントロールの目的は 2 つあります。最初に、セキュリティが発生する可能性がある構成の誤りがある場所を特定し、もう 1 つは不要になり、そのため削除できるファイアウォール規則を特定するのに役立ちます。つまり、サービスが廃止されたが、ファイアウォール規則が残されている場合です。

• 証拠ガイドラインの例: 証拠は、レビュー会議が行われていることを示すことができる必要があります。 これは、ファイアウォール レビューの会議の議事録と、レビューから実行されたアクションを示す追加の変更制御証拠を共有することで行うことができます。 これらの会議のうち少なくとも 2 つ (つまり、6 か月ごとに) を表示する必要がある場合は、日付が存在することを確認します。

• 証拠の例: 次のスクリーンショットは、2021 年 1 月に行われたファイアウォール レビューの証拠を示しています。

次のスクリーンショットは、2021 年 7 月にファイアウォール レビューが行われた証拠を示しています。

ファイアウォール – WAF

Web Application Firewall (WAF) をソリューションにデプロイすることは省略可能です。 WAF が使用されている場合、これは "Operational Security" セキュリティ ドメイン内のスコアリング マトリックスの追加クレジットとしてカウントされます。 WAF は、Web トラフィックを検査して、インターネットと公開された Web アプリケーション間の Web トラフィックをフィルター処理および監視して、Web アプリケーション固有の攻撃を特定できます。 Web アプリケーションは、SQL インジェクション (SQLi)、クロス サイト スクリプティング (XSS)、クロス サイト要求フォージェリ (CSRF/XSRF) などの Web アプリケーションに固有の多くの攻撃に苦しむ可能性があります。また、WAF は、攻撃や潜在的な侵害から Web アプリケーションを保護するために、これらの種類の悪意のあるペイロードから保護するように設計されています。

コントロール 26: Web Application Firewall (WAF) がアクティブに監視、アラート、および悪意のあるトラフィックをブロックするように構成されていることを示す証拠を提供します。

• 意図: このコントロールは、WAF がすべての受信 Web 接続に対して配置されていること、および悪意のあるトラフィックをブロックまたはアラートするように構成されていることを確認するために用意されています。 Web トラフィックに対して追加の防御層を提供するには、すべての受信 Web 接続に対して WAF を構成する必要があります。それ以外の場合、外部アクティビティ グループは、この追加の保護層を提供するように設計された WAF をバイパスできます。 WAF が悪意のあるトラフィックを積極的にブロックするように構成されていない場合、WAF は、潜在的な悪意のあるトラフィックに迅速に対応して環境のセキュリティを維持し、攻撃を停止できるスタッフに即時アラートを提供できる必要があります。

• 証拠ガイドラインの例: WAF からの構成出力を提供します。これは、サービスを提供する受信 Web 接続を強調表示し、構成によって悪意のあるトラフィックがアクティブにブロックされているか、監視とアラートを行っています。 または、特定の設定のスクリーンショットを共有して、このコントロールを満たしているorganizationを示すことができます。

• 証拠の例: 次のスクリーンショットは、Contoso Production Azure Application Gateway WAF ポリシーが有効になっており、悪意のあるトラフィックがアクティブに削除される "防止" モード用に構成されていることを示しています。

次のスクリーンショットは、フロントエンド IP 構成を示しています

メモ： 証拠は、環境で使用されるすべてのパブリック IP を示して、すべてのイングレス ポイントがカバーされていることを確認する必要があります。そのため、このスクリーンショットも含まれています。

次のスクリーンショットは、この WAF を使用した受信 Web 接続を示しています。

次のスクリーンショットは、api.contoso.com サービス用であることを示すContoso_AppGW_CoreRulesを示しています。

制御 27: WAF が SSL オフロードをサポートしていることを実証可能な証拠を提供します。

• 意図: SSL オフロードをサポートするように WAF を構成する機能が重要です。それ以外の場合、WAF は HTTPS トラフィックを検査できません。 これらの環境では HTTPS トラフィックをサポートする必要があるため、これは WAF にとって HTTPS トラフィック内の悪意のあるペイロードを特定して停止できるようにするための重要な機能です。

• 証拠ガイドラインの例: 構成のエクスポートまたは SSL オフロードがサポートおよび構成されていることを示すスクリーンショットを介して構成の証拠を提供します。

• 証拠の例: Azure Application Gateway内で、SSL リスナーが有効な SSL オフロードの構成については、「TLS 終了の概要」および「Microsoft Docsを使用したエンド ツー エンド TLS」ページApplication Gateway参照してください。 次のスクリーンショットは、Contoso Production Azure Application Gateway用に構成されたこのスクリーンショットです。

コントロール 28: 'OWASP Core Rule Set (3.0 または 3.1) に従って、WAF が次の脆弱性の一部またはすべてのクラスから保護されていることを示す証拠を提供します。

• プロトコルとエンコードの問題、

• ヘッダーの挿入、要求の密輸、応答の分割、

• ファイルトラバーサル攻撃とパストラバーサル攻撃、

• リモート ファイルインクルード (RFI) 攻撃、

• リモート コード実行攻撃、

• PHP インジェクション攻撃、

• クロスサイト スクリプティング攻撃、

• SQL インジェクション攻撃、

• セッション固定攻撃。

• 意図: 一般的な脆弱性クラスの攻撃ペイロードを識別するように WAF を構成する必要があります。 この制御は、OWASP Core 規則セットを活用することで、脆弱性クラスの適切な検出を確実に行う予定です。

• 証拠ガイドラインの例: 構成のエクスポートを介して構成の証拠を提供するか、スクリーンショットを使用して、上記で特定されたほとんどの脆弱性クラスがスキャンの対象になっていることを示します。

• 証拠の例: 次のスクリーンショットは、Contoso Production Azure Application Gateway WAF ポリシーが OWASP Core Rule Set バージョン 3.2 に対してスキャンするように構成されていることを示しています。

変更コントロール

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

コントロール 29: 変更制御プロセスを管理するポリシー ドキュメントを提供します。

• 意図: セキュリティで保護された環境とセキュリティで保護されたアプリケーションを維持するには、すべてのインフラストラクチャとコードの変更が強力な監督と定義されたプロセスで確実に実行されるように、堅牢な変更制御プロセスを確立する必要があります。 これにより、変更が文書化され、セキュリティへの影響が考慮され、変更に与えるセキュリティへの影響が考慮されます。この目的は、環境とアプリケーション開発の両方のプラクティス内のすべての変更に対して、セキュリティで保護された一貫性のあるアプローチが確実に行われるように、変更管理プロセスが文書化されていることを確認することです。

• 証拠ガイドラインの例: 文書化された変更管理ポリシー/手順は、認定アナリストと共有する必要があります。

• 証拠の例: 次に、変更管理ポリシーの例の開始を示します。 評価の一環として、完全なポリシーと手順を指定してください。

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

コントロール 30: 開発環境とテスト環境が運用環境からの職務の分離を強制するという実証可能な証拠を提供します。

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

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

• 証拠の例: 次のスクリーンショットは、Contoso の TEST 環境の Azure サブスクリプションを示しています。

次のスクリーンショットは、Contoso の "PRODUCTION" 環境用の別の Azure サブスクリプションを示しています。

コントロール 31: 機密性の高い運用データが開発環境またはテスト環境内で使用されていないことを実証可能な証拠を提供します。

• 意図: 既に説明したように、組織は開発環境と同じ勢いで開発/テスト環境のセキュリティ対策を実装しません。 そのため、これらの開発/テスト環境で機密性の高い運用データを利用することで、侵害のリスクが高まり、これらの開発環境/テスト環境内でライブ/機密データを使用しないようにする必要があります。

メモ： 開発/テスト環境でライブ データを使用できます。開発/テストは評価の範囲内に含まれるため、Microsoft 365 認定コントロールに対してセキュリティを評価できます。

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

• 証拠の例: 次のスクリーンショットは、運用データベースの上位 3 つのレコード (証拠提出の場合は上位 20 件を指定してください) を示しています。

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

これは、データ セットが異なっていることを示しています。

コントロール 32: 文書化された変更要求に、変更の影響、バックアウト手順の詳細、実行されるテストが含まれていることを実証可能な証拠を提供します。

• 意図: このコントロールの目的は、要求されている変更に思考が入っていることを確認することです。 変更がシステム/環境のセキュリティに与える影響を考慮し、明確に文書化する必要があります。何か問題が発生した場合は、復旧に役立つバックアウト手順を文書化する必要があります。また、変更が成功したことを検証するために必要なテストの詳細についても考慮し、文書化する必要があります。

• 証拠ガイドラインの例: 証拠は、変更要求のサンプルをエクスポートするか、紙の変更要求を提供するか、変更要求内で保持されているこれら 3 つの詳細を示す変更要求のスクリーンショットを提供することによって提供できます。

• 証拠例: 次の図は、新しいクロスサイト スクリプティング脆弱性 (XSS) が割り当てられ、変更要求のドキュメントを示しています。

以下のチケットは、解決の過程でチケットに設定または追加された情報を示しています。

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

画面の左側で、変更のテストが承認されたことを確認できます。右側には、変更が承認され、テストされていることがわかります。

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

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

コントロール 33: 変更要求が承認およびサインアウト プロセスを受けるという実証可能な証拠を提供します。

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

• 証拠ガイドラインの例: 証拠は、変更要求のサンプルのエクスポート、紙の変更要求の提供、または変更が承認されたことを示す変更要求のスクリーンショットを、実装前に提供し、完了後に変更がサインオフされたことを示すことによって提供できます。

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

以下のチケットでは、変更が完了するとサインオフされ、ジョブが完了して閉じられたことがわかります。

セキュリティで保護されたソフトウェアの開発/展開

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

コントロール 34: OWASP Top 10 や SANS Top 25 CWE などの一般的な脆弱性クラスに対するセキュリティで保護されたコーディングのベスト プラクティス ガイダンスなど、セキュリティで保護されたソフトウェアの開発と展開をサポートするポリシーと手順を提供します。

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

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

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

メモ： これらのスクリーンショットは、セキュリティで保護されたソフトウェア開発ドキュメントを示しています。ISV が実際のサポート ドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

コントロール 35: コードの変更が 2 番目のレビュー担当者によってレビューと承認プロセスを受けているという実証可能な証拠を提供します。

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

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

• 証拠の例

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

次の図は、下の画像の右側にある強調表示されたセクションに示すように、コード レビューが元の開発者以外のユーザーに割り当てられたことを示しています。 左側では、コードがレビューされ、コード レビュー担当者によって "PASSED CODE REVIEW" 状態が与えられていることがわかります。

変更をライブ運用システムに適用する前に、チケットがマネージャーによって承認される必要があります。

上の図は、レビューされたコードがライブ運用システムに実装される承認を受けていることを示しています。

コードの変更が完了すると、上の図に示すように、最終的なジョブはサインアウトされます。

プロセス全体を通じて、コードの元の開発者、コードレビュー担当者、マネージャーの 3 人が関与し、承認とサインアウトが行われます。このコントロールの条件を満たすためには、チケットがこのプロセスに従うことを期待します。 コード レビューの変更制御プロセスに関与する 3 人以上のユーザーのうち。

コントロール 36: 開発者がセキュリティで保護されたソフトウェア開発トレーニングを毎年受けているという実証可能な証拠を提供します。

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

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

• 証拠の例: DevOps チームのスタッフを OWASP Top 10 Training Annual Training に登録することを要求する電子メールを次に示します

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

コントロール 37: コード リポジトリが多要素認証 (MFA) で保護されていることを実証できる証拠を提供します。

• 意図: アクティビティ グループがソフトウェアのコード ベースにアクセスして変更できる場合は、脆弱性、バックドア、または悪意のあるコードをコード ベースに導入し、そのためアプリケーションに導入する可能性があります。 これは既にいくつかの例があり、おそらく最も公表されているのは、M.E.Doc と呼ばれるウクライナの税務ソフトウェアへの侵害された更新を通じて感染したと伝えられている NotPetya ランサムウェア攻撃です ( 「What is'tPetya」を参照)。

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

• 証拠の例: 次のスクリーンショットは、8 人の GitLab ユーザーすべてで MFA が有効になっていることを示しています。

コントロール 38: コード リポジトリをセキュリティで保護するためにアクセス制御が実施されていることを示す証拠を提供します。

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

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

• 証拠の例: 次のスクリーンショットは、GitLab の "Customers" プロジェクトのメンバーを示しています。これは Contoso "Customer Portal" です。 スクリーンショットに示すように、ユーザーはプロジェクトへのアクセスを制限するために異なる "ロール" を持っています。

アカウントの管理

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

コントロール 39: アカウント管理のプラクティスと手順を管理するポリシー ドキュメントを提供します。

• 意図: ユーザー アカウントは引き続きアクティビティ グループの対象となり、多くの場合、データ侵害の原因になります。 過剰に制限されたアカウントを構成することで、組織は、アクティビティ グループがデータ侵害を実行するために使用できる "特権" アカウントのプールを増やすだけでなく、特定の特権を必要とする脆弱性の悪用が成功するリスクを高めることもできます。

• BeyondTrust は、前年の Microsoft セキュリティの脆弱性を分析し、管理者権限を持つユーザー アカウントに依存するこれらの脆弱性の詳細な割合を分析する"Microsoft 脆弱性レポート" を毎年生成します。 最近のブログ記事「新しい Microsoft 脆弱性レポートは脆弱性の 48% の増加を明らかにします & 最小限の特権で軽減する方法」では、インターネット エクスプローラーの重大な脆弱性の 90%、Microsoft Edge の重大な脆弱性の 85%、Microsoft Outlook の重大な脆弱性の 100% が管理者権限を削除することで軽減されました。 セキュリティで保護されたアカウント管理をサポートするには、セキュリティのベスト プラクティスを促進するサポート ポリシーと手順を確実に実施し、これらの脅威を軽減する必要があります。

• 証拠ガイドラインの例: アカウント管理のプラクティスをカバーする文書化されたポリシーと手順のドキュメントを提供します。 少なくとも、対象となるトピックは、Microsoft 365 認定資格内のコントロールに合わせて調整する必要があります。

• 証拠の例: 次のスクリーンショットは、Contoso のアカウント管理ポリシーの例を示しています。

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

コントロール 40: 既定の資格情報が、サンプリングされたシステム コンポーネント全体で無効、削除、または変更されていることを示す証拠を提供します。

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

• 証拠ガイドラインの例: このコントロールをサポートするために証拠を収集する方法はさまざまです。 すべてのシステム コンポーネントで構成されたユーザーのスクリーンショットは、つまり、Linux /etc/shadow ファイルと /etc/passwd ファイルのスクリーンショットが、アカウントが無効になっているかどうかを示すのに役立ちます。 パスワード ハッシュが無効であることを示す '!' などの無効な文字で始まることを確認することで、アカウントが本当に無効になっていることを示すには、/etc/shadow ファイルが必要であることに注意してください。 アドバイスは、パスワードの数文字のみを無効にし、残りの部分を編集することです。 その他のオプションは、評価者が既定の資格情報を手動で試すことができるスクリーンシェアリング セッションの場合です。たとえば、Dell iDRAC に関する上記の説明では、評価者は既定の資格情報を使用してすべての Dell iDRAC インターフェイスに対して認証を試みる必要があります。

• 証拠の例: 次のスクリーンショットは、スコープ内システム コンポーネント "クララネット-SBU-WM" 用に構成されたユーザー アカウントを示しています。 には、いくつかの既定のアカウントが表示されます。ただし、管理者、DefaultAccount、およびゲストは、これらのアカウントが無効になっていることを示す次のスクリーンショットです。

次のスクリーンショットは、スコープ内のシステム コンポーネント "クララネット-SBU-WM" で管理者アカウントが無効になっていることを示しています。

次のスクリーンショットは、スコープ内のシステム コンポーネント "クララネット-SBU-WM" でゲスト アカウントが無効になっていることを示しています。

次のスクリーンショットは、スコープ内のシステム コンポーネント "クララネット-SBU-WM" で DefaultAccount が無効になっていることを示しています。

コントロール 41: アカウントの作成、変更、削除が確立された承認プロセスを経る実証可能な証拠を提供します。

• 意図: 目的は、すべてのアカウント管理アクティビティが承認され、アカウント特権が最小限の特権原則を維持し、アカウント管理アクティビティを適切に確認および追跡できるようにするためのプロセスを確立することです。

• 証拠ガイドラインの例: 証拠は、通常、変更要求チケット、ITSM (IT サービス管理) 要求、またはアカウントの作成、変更、または削除の要求が承認プロセスを経たことを示す書類の形式になります。

• 証拠の例: 次の画像は、DevOps チームに対する新しいスターターのアカウント作成を示しています。これは、開発環境へのアクセス権を持たない運用環境のアクセス許可に基づいてロールベースのアクセス制御設定を行う必要があり、その他すべてに対する標準の非特権アクセス権を持っている必要があります。

アカウントの作成は、アカウントが作成され、チケットが閉じられた後に承認プロセスとサインアウト プロセスを経ました。

コントロール 42: 3 か月以内に使用されていないアカウントを無効または削除するためのプロセスが実施されていることを示す証拠を提供します。

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

• 証拠ガイドラインの例: 証拠は 2 倍にする必要があります。 まず、スコープ内環境内のすべてのユーザー アカウントの "最後のサインイン" を示すスクリーンショットまたはファイルエクスポート。 これは、ローカル アカウントだけでなく、Microsoft Entra IDなどの一元化されたディレクトリ サービス内のアカウントでもかまいません。 これにより、3 か月を超えるアカウントが有効になっていないことが示されます。 第 2 に、四半期ごとのレビュー プロセスの証拠です。これは、ADO (Azure DevOps) または JIRA チケット内、またはサインオフする必要がある紙のレコードを通じて、タスクが完了したことを示すドキュメント証拠である可能性があります。

• 証拠の例: この最初のスクリーンショットは、Microsoft Entra ID内のユーザーの最後のサインイン属性を表示するために四半期ごとに実行されるスクリプトの出力を示しています。

上のスクリーンショットに示すように、2 人のユーザーがしばらくログインしていないと表示されています。 次の 2 つのスクリーンショットは、これら 2 人のユーザーが無効になっていることを示しています。

コントロール 43: ユーザーの資格情報を保護するための強力なパスワード ポリシーまたはその他の適切な軽減策が実施されていることを実証可能な証拠を提供します。 最小ガイドラインとして次を使用する必要があります。

• パスワードの最小長は 8 文字

• 10 回以下の試行のアカウント ロックアウトしきい値

• 少なくとも 5 つのパスワードのパスワード履歴

• 強力なパスワードの使用の適用

• 意図: 既に説明したように、ユーザー資格情報は、多くの場合、organizationの環境へのアクセスを試みるアクティビティ グループによる攻撃のターゲットです。 強力なパスワード ポリシーの目的は、ユーザーに強力なパスワードの選択を強制して、アクティビティ グループが強制的にブルート フォースできる可能性を軽減することです。 "またはその他の適切な軽減策" を追加する目的は、組織が"NIST Special Publication 800-63B" などの業界の発展に基づいてユーザーの資格情報を保護するのに役立つ他のセキュリティ対策を実装する可能性があることを認識することです。

• 証拠ガイドラインの例: 強力なパスワード ポリシーを示す証拠は、組織のグループ ポリシー オブジェクトまたはローカル セキュリティ ポリシー "アカウント ポリシー à パスワード ポリシー" および "アカウント ポリシー à アカウント ロックアウト ポリシー" 設定のスクリーンショットの形式である可能性があります。 証拠は、使用されているテクノロジに依存します。つまり、Linux の場合は、/etc/pam.d/common-password 構成ファイル、BitBucket の場合は、管理 ポータル () 内の "認証ポリシー" セクションなどhttps://support.atlassian.com/security-and-access-policies/docs/manage-your-password-policy/です。

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

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

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

コントロール 44: 一意のユーザー アカウントがすべてのユーザーに発行されていることを示す証拠を提供します。

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

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

• 証拠の例: 次のスクリーンショットは、スコープ内システム コンポーネント "クララネット-SBU-WM" 用に構成されたユーザー アカウントを示しています。

次のスクリーンショットは、スコープ内のシステム コンポーネント "クララネット-SBU-WM" で管理者アカウントが無効になっていることを示しています。

次のスクリーンショットは、スコープ内のシステム コンポーネント "クララネット-SBU-WM" でゲスト アカウントが無効になっていることを示しています。

次のスクリーンショットは、スコープ内のシステム コンポーネント "クララネット-SBU-WM" で DefaultAccount が無効になっていることを示しています。

コントロール 45: 環境内で最小限の特権原則が従われていることを実証可能な証拠を提供します。

• 意図: ユーザーには、ジョブ機能を満たすために必要な特権のみを提供する必要があります。 これは、ユーザーが意図しないデータに意図的にアクセスしたり、悪意のある行為を実行したりするリスクを制限するためです。この原則に従うことで、悪意のあるアクティビティ グループの対象となる可能性のある攻撃対象領域 (つまり特権アカウント) も削減されます。

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

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

• 証拠の例: 次のスクリーンショットは、環境がジョブ関数に従って割り当てられたグループで構成されていることを示しています。

次のスクリーンショットは、ユーザーがジョブ機能に基づいてグループに割り当てられていることを示しています。

コントロール 46: サービス アカウントをセキュリティで保護または強化するためのプロセスが実施されており、プロセスが従っていることを示す証拠を提供します。

• 意図: サービス アカウントは、多くの場合、昇格された特権で構成されるため、アクティビティ グループの対象になります。 これらのアカウントは、サービス アカウント のパスワードの有効期限が切れる場合が多いため、標準のパスワード ポリシーに従わない場合があります。 そのため、organization内で再利用される脆弱なパスワードまたはパスワードを使用して構成できます。 特に Windows 環境内のもう 1 つの潜在的な問題は、オペレーティング システムがパスワード ハッシュをキャッシュする可能性があります。 これは、サービス アカウントがディレクトリ サービス内で構成されている場合に大きな問題になる可能性があります。このアカウントは、特権レベルが構成された複数のシステム間でアクセスを使用できるため、またはサービス アカウントがローカルである場合、環境内の複数のシステムで同じアカウント/パスワードが使用される可能性があります。 上記の問題は、アクティビティ グループが環境内のより多くのシステムにアクセスし、特権の昇格や横移動につながる可能性があります。 そのため、サービス アカウントが適切に強化され、セキュリティで保護され、アクティビティ グループによって引き継がれるのを防ぐか、これらのサービス アカウントの 1 つが侵害されるリスクを制限することを目的としています。

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

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

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

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

• Active Directory の場合は、"アカウントは機密性が高く委任できません" フラグを有効にします。 これらの手法については、次の記事「カード所有者データ環境のセグメント化と共有 Active Directory」で説明します。

• 証拠の例: サービス アカウントを強化する方法は複数あり、個々の環境に依存します。 使用される環境に適したメカニズムは、この証拠を確認するのに役立つアカウント管理ポリシー/手順ドキュメントに記載されています。 使用できるメカニズムの一部を次に示します。

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

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

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

コントロール 47: MFA がすべてのリモート アクセス接続とすべてのコンソール以外の管理インターフェイスに対して構成されていることを示す証拠を提供します。

次のように定義された用語:

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

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

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

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

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

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

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

証拠 2 の例: 次のスクリーンショットは、すべての Azure ユーザーが MFA を有効にしていることを示しています。

注: MFA が有効になっていることを示すために、コンソール以外のすべての接続の証拠を提供する必要があります。 そのため、たとえば、サーバーやその他のシステム コンポーネント (つまりファイアウォール) に RDP または SSH を実行する場合などです。

コントロール 48: すべてのリモート アクセス接続とすべてのコンソール以外の管理インターフェイス (コード リポジトリやクラウド管理インターフェイスへのアクセスを含む) に対して強力な暗号化が構成されていることを実証可能な証拠を提供します。

次のように定義された用語:

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

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

• 意図: この制御の目的は、中間者攻撃から保護するために、すべての管理トラフィックが適切に暗号化されるようにすることです。

• 証拠ガイドラインの例: 証拠は、リモート アクセス テクノロジ、RDP、SSH、Web 管理 インターフェイスの暗号化設定を示すスクリーンショットで提供できます。 Web 管理 インターフェイスの場合、Qualys SSL Labs スキャナー (パブリックにアクセスできる場合、つまり、クラウド管理インターフェイス、SaaS コード リポジトリ、または SSL VPN 接続) を使用できます。

• 証拠の例: 次の証拠は、"高レベル" の設定で構成されている "Webserver01" の RDP 暗号化レベルを示しています。 ヘルプ テキストに示すように、これは強力な 128 ビット暗号化 (Microsoft Windows RDP の最上位レベル) を使用しています。

次の証拠は、RDP トランスポート セキュリティが "Webserver01" で TLS 1.0 を使用するように構成されていることも示しています (Windows Server の場合は最も高くなります)。

コントロール 49: MFA を使用して、すべてのパブリック ドメイン ネーム サービス (DNS) レコードを管理および管理するために使用する管理ポータルを保護する実証可能な証拠を提供します。

• 意図: 悪意のあるアクティビティ グループがパブリック DNS レコードにアクセスできる場合、アプリで使用される URL を変更したり、マニフェスト ファイルが悪意のあるコードを導入したり、ユーザー トラフィックをアクター コントロールの下のエンドポイントに誘導したりするリスクがあります。 これにより、ユーザー データが失われたり、アプリのユーザー ベース全体でマルウェアやランサムウェアの感染が発生したりする可能性があります。

• 証拠ガイドラインの例: パブリック DNS 管理ポータルが MFA によって保護されていることを示す証拠を提供します。 パブリック DNS がスコープ内環境内のサーバーでホストされている場合 (つまり、organizationによって制御および運用されている) 場合でも、ドメイン名が登録されたどこかに管理 ポータルが存在し、DNS レコードは "マネージド" であり、DNS サーバーを独自のインフラストラクチャにポイントしている可能性があります。 この場合、ドメイン DNS レコードを変更できる場合は、ドメイン レジストラー管理インターフェイスで MFA を有効にする必要があります。 管理インターフェイスがシステム レベル (つまり、すべての特権アカウント) で MFA に対して有効になっていることを示すスクリーンショットを提供する必要があります。

• 証拠の例: 次のスクリーンショットは、Microsoft Azure for Contoso Corporation 内で DNS が管理されている contoso.com を示しています。

メモ： IP アドレスはプライベート RFC 1918 アドレスであり、パブリックにルーティングされません。 これは、デモンストレーションのみを目的としています。

次のスクリーンショットは、すべての Azure ユーザーが MFA を有効にしていることを示しています。

侵入検出と防止 (オプション)

ゲートウェイの侵入検出および防止システム (IDPS) は、無数のインターネット ベースおよび内部の脅威に対する追加の保護層を提供できます。 これらのシステムは、これらの脅威が成功するのを防ぐのに役立ち、組織がこれらのアクティブな脅威から環境をさらに保護するための追加の防御戦略を実装できるように、侵害の試みを生きるために組織に警告するための重要なアラート機能を提供できます。

このセクションは追加のクレジット用であるため、省略可能です。 これは要件ではありません。ただし、完了した場合、評価には、環境と、設定したコントロールと標準のより完全な画像が表示されます。

コントロール 50: 侵入検出および防止システム (IDPS) がスコープ内環境の境界にデプロイされていることを実証可能な証拠を提供します。

• 意図: 一部のソースでは、内部の脅威が外部のアクティビティ グループによる脅威を超えていると説明されていますが、インサイダーの脅威には過失も含まれます。人的エラーは前年比で増加しています。 スコープ内環境の境界に IDPS をインストールする目的は、多くの場合、これらの種類の脅威で使用される性質と手法のために、IDPS メカニズムを介して外部の脅威を検出できることです。

• 証拠ガイドラインの例: IDPS が境界にインストールされていることを示す証拠を提供する必要があります。これは、NextGen ファイアウォールを実行している場合はファイアウォールに直接インストールするか、デプロイされたセンサーによってすべてのトラフィックが確認されるようにミラースイッチ ポートで構成されたデプロイ IDPS センサーによって行われる可能性があります。 IDPS センサーが使用されている場合は、センサーがすべての外部トラフィック フローを確認できることを示すために、追加の証拠を提供する必要がある場合があります。

• 証拠の例: 次のスクリーンショットは、WatchGuard ファイアウォールで IDPS 機能が有効になっていることを示しています。

次の追加のスクリーンショットは、WatchGuard Firewall の構成内のすべてのルールで IDPS が有効になっていることを示しています。

コントロール 51: IDPS 署名が最新の状態 (24 時間以内) に保持されていることを示す証拠を提供します。

• 意図: IDPS には複数の操作モードがありますが、最も一般的なのは、攻撃トラフィックを識別するために署名を使用することです。 攻撃が進化し、新しい脆弱性が特定されるにつれて、適切な保護を提供するために IDPS 署名が最新の状態に保たれていることが重要です。 このコントロールの目的は、IDPS が維持されていることを確認することです。

• 証拠ガイドラインの例: 証拠には、IDPS が少なくとも毎日署名を更新するように構成されており、最後の更新が表示されていることを示すスクリーンショットが含まれている可能性があります。

• 証拠の例: このスクリーンショットでは、IDPS 署名が過去 24 時間以内に更新されたことは示されていませんが、1 週間前の最新バージョン (18__th 5 月に収集された証拠) がインストールされていることを示しています。 これは、次のスクリーンショットと組み合わせることで、署名が 24 時間以内に最新の状態に保たれたことを示しています。

制御 52: IDPS がすべての受信 Web トラフィックの TLS 検査をサポートするように構成されていることを示す証拠を提供します。

• 意図: IDPS は署名に依存するため、攻撃トラフィックを識別するためにすべてのトラフィック フローを検査できる必要があります。 TLS トラフィックは暗号化されているため、IDPS はトラフィックを適切に検査できません。 これは、Web サービスに共通する無数の脅威があるため、HTTPS トラフィックにとって重要です。 この制御の目的は、暗号化されたトラフィック フローで IDPS を検査できるようにすることです。

• 証拠ガイドラインの例: 暗号化された TLS トラフィックも IDPS ソリューションによって検査されていることを示すスクリーンショットを使用して証拠を提供する必要があります。

• 証拠の例: このスクリーンショットは、ファイアウォール上の HTTPS 規則を示しています

次のスクリーンショットは、IDPS がこれらのルールで有効になっていることを示しています。

次のスクリーンショットは、コンテンツ検査を有効にするために使用される "Inbound_Bot_Traffic" ルールに "プロキシ アクション" が適用されていることを示しています。

次のスクリーンショットは、コンテンツ検査が有効になっていることを示しています。

制御 53: IDPS がすべての受信トラフィック フローを監視するように構成されていることを示す証拠を提供します。

• 意図: 既に説明したように、すべての受信トラフィック フローを IDPS によって監視して、任意の形式の攻撃トラフィックを識別することが重要です。

• 証拠ガイドラインの例: すべての受信トラフィック フローが監視されていることを示すために、スクリーンショットを使用した証拠を提供する必要があります。 これは、すべての受信規則が IDPS に対して有効になっていることを示す NextGen ファイアウォールを使用する場合があります。または、IDPS センサーを使用して、すべてのトラフィックが IDPS センサーに到達するように構成されていることを示します。

• 証拠の例: このスクリーンショットは、IDPS がすべての WatchGuard ファイアウォールの規則 (ポリシー) で構成されていることを示しています。

制御 54: IDPS がすべての送信トラフィック フローを監視するように構成されていることを示す証拠を提供します。

• 意図: 既に説明したように、すべての送信トラフィック フローが IDPS によって監視され、任意の形式の攻撃トラフィックを識別することが重要です。 一部の IDPS システムでは、すべての送信トラフィックを監視することで、内部侵害の可能性を特定することもできます。 これは、"Command and Control" エンドポイント宛てのトラフィックを識別することで実行できます。

• 証拠ガイドラインの例: すべての送信トラフィック フローが監視されていることを示すために、スクリーンショットを使用した証拠を提供する必要があります。 これは、すべての送信規則が IDPS に対して有効になっていることを示す NextGen ファイアウォールを使用する場合があります。または、IDPS センサーを使用して、すべてのトラフィックが IDPS センサーに到達するように構成されていることを示します。

• 証拠の例: このスクリーンショットは、IDPS がすべての WatchGuard ファイアウォールの規則 (ポリシー) で構成されていることを示しています。

• 証拠 2 の例: Azure は、サード パーティ製アプリを介して IDPS を提供します。 次の例では、Netwatcher パケット キャプチャを使用してパケットをキャプチャし、Open-Source IDS ツールである Suricata と共に使用しています。

Network Watcherおよび Suricata などのオープンソース IDS ツールによって提供されるパケット キャプチャを組み合わせることで、さまざまな脅威に対してネットワーク侵入検出を実行できます。 次の図は、Suricata インターフェイスを示しています。

署名はアラートをトリガーするために使用され、簡単にインストールおよび更新できます。 次の図は、いくつかの署名のスナップショットを示しています。

次の図は、Sentinel SIEM/SOAR を使用して、Netwatcher と Suricata のサード パーティ製ソフトウェアの IDPS 設定を監視する方法を示しています。

• 証拠例 3: 次の図は、CLI を使用して、侵入検出用のオーバーライド侵入シグネチャまたはバイパス ルールを追加する方法を示しています

次の図は、CLI を使用してすべての侵入検出構成を一覧表示する方法を示しています

• 証拠 4 の例: Azure は最近、Azure Firewall Premium という名前の IDPS を提供し始めました。これにより、TLS、脅威インテリジェンス、IDPS をポリシー経由で構成できますが、受信 SSL 接続で IDPS がサポートされていないAzure Firewall、受信トラフィックの SSL オフロードには Front Door またはアプリケーション ゲートウェイを引き続き使用する必要があることに注意してください。

次の例では、ポリシー ルールの構成と TLS 検査、IDPS モードに既定の Premium 設定が使用されています。脅威インテリジェンスはすべて、Vnet の保護と共に有効になっています。

セキュリティ イベント ログ

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

コントロール 55: セキュリティ イベント ログを管理するベスト プラクティスと手順に関するポリシー ドキュメントを提供します。

• 意図: セキュリティ イベント ログは、organizationのセキュリティ プログラムの重要な機能です。 組織がベンダーや業界で推奨されるプラクティスに沿ってログ記録制御を確実に実装できるように、明確さと一貫性を提供するために、ポリシーと手順を実施する必要があります。 これにより、潜在的または実際のセキュリティ イベントを特定するのに役立つだけでなく、インシデント対応アクティビティがセキュリティ侵害の程度を特定するのにも役立つ、関連する詳細なログが確実に使用されるようになります。

• 証拠ガイドラインの例: セキュリティ イベント ログのベスト プラクティスに関する文書化されたポリシーと手順に関するドキュメントを組織に提供します。

• 証拠の例: ログ 記録ポリシー/プロシージャからの抽出を次に示します。

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

コントロール 56: 次のイベントをログに記録するために、サンプリングされたすべてのシステム コンポーネントに対してセキュリティ イベント ログが設定されていることを示す実証可能な証拠を提供します。

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

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

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

• 特権アカウントの作成または変更

• イベント ログの改ざん

• マルウェア対策やイベント ログ記録などのセキュリティ ツールの無効化

• マルウェア対策ログ (更新プログラム、マルウェア検出、スキャン エラーなど)

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

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

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

• 証拠 1 の例: 次のスクリーンショットは、"VICTIM1-WINDOWS" と呼ばれるサンプリングされたデバイスのいずれかからの構成設定を示しています。 この設定には、[ローカル セキュリティ ポリシー ]  [ローカル ポリシー]  [監査ポリシー] の設定内で有効になっているさまざまな監査設定が表示されます。

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

この最後のスクリーンショットは、一元化されたログ ソリューション内にログ メッセージが表示されていることを示しています。

注: スクリーンショットは、サンプリングされたすべてのシステム コンポーネントで必要であり、上記のすべてのセキュリティ イベントを証明する必要があります。

コントロール 57: ログに記録されたセキュリティ イベントに次の最小情報が含まれていることを示す証拠を提供します。

• User

• イベントの種類

• 日時

• 成功または失敗のインジケーター

• 影響を受けるシステムを識別するラベル

• 意図: ログに記録されたセキュリティ イベントは、攻撃トラフィックが成功したかどうか、アクセスされた情報、どのレベル、誰が責任を負ったか、どこから発生したかなどを判断するのに役立つ十分な情報を提供する必要があります。

• 証拠ガイドラインの例: 証拠には、これらの種類のセキュリティ イベントを示すすべてのシステム コンポーネントのログのサンプルが表示されます。 ログには、上記のすべての情報が含まれている必要があります。

• 証拠の例: 次のスクリーンショットは、スコープ内のシステム コンポーネント "SEGSVR02" からの Windows イベント ビューアー内のセキュリティ イベントからの情報を示しています。

注: スクリーンショットは、サンプリングされたすべてのシステム コンポーネント全体で必要であり、上記のコントロールに詳しく説明されているすべてのセキュリティ イベントを証明 する必要があります 。 上記のコントロールに対して収集された証拠もこのコントロールを満たし、ログ情報の適切な詳細が提供される可能性があります。

コントロール 58: サンプリングされたすべてのシステム コンポーネントが、同じプライマリ サーバーとセカンダリ サーバーに時間同期されていることを実証できる証拠を提供します。

• 意図: ログ記録の重要なコンポーネントは、すべてのシステムのログに、すべて同期されているシステム クロックがあることを確認することです。これは、侵害やデータ侵害を追跡するために調査が必要な場合に重要です。 重要なログを見逃す可能性があり、追跡が困難になるため、ログのタイムスタンプの程度が異なる場合、さまざまなシステムを介してイベントを追跡することはほぼ不可能になる可能性があります。

• 証拠ガイドラインの例: 理想的には、時間同期トポロジを維持する必要があります。これは、資産間での時間の同期方法を示します。 その後、サンプリングされたシステム コンポーネント全体の時刻同期設定のスクリーンショットを使用して証拠を提供できます。 これにより、すべての時刻同期が同じプライマリ (またはセカンダリサーバーの場合) に同期されます。

• 証拠の例: この図は、使用中の時刻同期トポロジを示しています。

次のスクリーンショットは、時刻ソースとして time.windows.com を指す、NTP サーバーとして構成された WatchGuard を示しています。

この最後のスクリーンショットは、スコープ内のシステム コンポーネントである "クララネット-SBU-WM" が、NTP が WatchGuard Firewall (10.0.1.1) であるプライマリ サーバーを指すように構成されていることを示しています。

コントロール 59: 公開システムが使用されている場合に、境界ネットワーク内ではなく一元化されたログ 記録ソリューションにセキュリティ イベント ログが送信されていることを示す証拠を提供します。

• 意図: このコントロールの意図は、DMZ とログ エンドポイントの間で論理的または物理的な分離を確保することです。 DMZ が公開されている場合、これは外部アクティビティ グループに公開されるため、環境内の他のコンポーネントよりもリスクが高くなります。 DMZ コンポーネントが侵害された場合は、セキュリティ侵害を隠すためにアクティビティ グループがログを改ざんするのを防ぐだけでなく、必要なフォレンジック調査作業を支援するために、ログ データの整合性を維持する必要があります。 DMZ の外部のシステムにログを記録することで、DMZ からのトラフィックをこれらのセキュリティ システムに制限するために使用されるセキュリティ制御は、悪意のあるアクティビティや改ざんの試行からそれらを保護するのに役立つ必要があります。

• 証拠ガイドラインの例: DMZ の外部にある一元化されたログ ソリューションに送信されるログが直ちに (またはすぐに近い) よう構成されていることを示す、スクリーンショットまたは構成設定を証拠に提供する必要があります。 ログが一元化されたログ ソリューションに出荷されるまでに時間がかかるほど、処理アクターがローカル ログを改ざんしてから出荷する必要がある時間が長くなるため、ログのほぼ即時の出荷を探しています。

• 証拠例: Contoso DMZ システムは、ログ ファイルの配布に NXLog を利用します。 次のスクリーンショットは、すべての DMZ サーバーの管理に使用される "DESKTOP-7S65PN" DMZ ジャンプボックスで実行されている "nxlog" サービスを示しています。

次のスクリーンショットは、nxlog.conf ファイルからの抽出を示しています。宛先が、AlienVault への出荷に使用される 10.0.1.250 のアプリケーション サブネット内の内部ログ コレクターであることを示しています。

NXLog (https://nxlog.co/documentation/nxlog-user-guide/modes.html) の次の URL は、次の抽出によってログ配布がリアルタイムで行われることを示しています。

コントロール 60: ログ データの不正な改ざんから一元化されたログ ソリューションが保護されていることを示す実証可能な証拠を提供します。

• 意図: ログ デバイスと集中ログ ソリューションの間で論理的/物理的な分離が行われることが多いですが、誰かがログを改ざんしてアクティビティを非表示にしようとするリスクが残っています。 この制御の目的は、一元化されたログ ソリューションに対して管理アクションを実行できるユーザーの数を制限するための適切な承認メカニズムを確保することです。

• 証拠ガイドラインの例: 通常、証拠は、一元化されたログ ソリューションの承認と認証の構成を示すスクリーンショットで、ユーザーが仕事の役割/機能に必要なものに制限されていることを示しています。

• 証拠の例: Contoso のアウトソーシング SOC は、一元化された SIEM ツールとして AlienVault を利用しています。 AlienVault は 2018 年に AT&T によって購入され、現在は USM Anywhere によって購入されました。 次の Web ページ (https://cybersecurity.att.com/documentation/usm-anywhere/deployment-guide/admin/usm-anywhere-data-security.htm) では、USM Anywhere が不正な改ざんからデータを保護する方法について説明します。 次のリンク (https://cybersecurity.att.com/documentation/usm-appliance/raw-logs/raw-log-management.htm) は、USM Anywhere 製品がアーカイブされたログの整合性を保証する方法を示しています。

メモ： SIEM が内部の場合は、ログ データへのアクセスが、ジョブのニーズに基づいて一部のユーザーに制限されていること、およびプラットフォーム自体が改ざんから保護されていることを示す証拠を提供する必要があります (ほとんどのソリューションはこれをログ ソリューションの機能に組み込みます)。

コントロール 61: 90 日間のセキュリティ イベント ログが保持され、少なくとも 30 日間のセキュリティ イベント ログ データがすぐに利用可能であるという実証可能な証拠を提供します。

• 意図: 場合によっては、侵害またはセキュリティ イベントと、それを識別するorganizationの間に時間差があります。 この制御の目的は、organizationがインシデント対応と必要になる可能性のあるフォレンジック調査作業に役立つ履歴イベント データにアクセスできるようにすることです。

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

• 証拠 1 の例: 次のスクリーンショットは、AlienVault 内で 30 日分のログが使用可能であることを示しています。

注: これは公開されているドキュメントであるため、ファイアウォールのシリアル番号は編集されていますが、個人を特定できる情報が含まれていない限り、編集されたスクリーンショットをサポートする ISV は想定されません。

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

注: これは公開されているドキュメントであるため、パブリック IP アドレスは編集されていますが、個人を特定できる情報が含まれていない限り、編集されたスクリーンショットをサポートする ISV は想定されません。

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

セキュリティ イベント ログ レビュー

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

コントロール 62: ログ レビューのプラクティスと手順を管理するポリシー ドキュメントを提供します。

• 意図: IBM の 「データ侵害レポート 2020 のコスト」というタイトルのレポートでは、データ侵害を特定して含める平均時間が 280 日かかる可能性があることを強調しています。これは、侵害が 315 日と報告される悪意のあるアクティビティ グループによる場合の方が大きいことを強調しています。 データ侵害の平均コストが数百万ドルに上ると報告されるため、このデータ侵害ライフサイクルは、データへの公開期間を最小限に抑えるだけでなく、アクティビティ グループが環境からデータを流出させる期間を短縮するために削減することが重要です。 この期間を短縮することで、組織はデータ侵害の全体的なコストを削減できます。

• 堅牢なレビューとアラート プロセスを実装することで、組織はデータ侵害ライフサイクルの中で、より早く侵害を特定し、organizationへの影響を最小限に抑える機能を備えています。 さらに、強力なプロセスは、侵害の試行を特定するのに役立つ可能性があります。これにより、組織はセキュリティ防御メカニズムを強化して、この増加した脅威を軽減して、攻撃キャンペーンによる侵害の可能性をさらに減らすことができます。

• 証拠ガイドラインの例: ログ レビューのベスト プラクティスに関する文書化されたポリシーと手順のドキュメントを組織に提供します。

• 証拠の例: ログ レビュー ポリシー/プロシージャからの抽出を次に示します。

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

コントロール 63: 潜在的なセキュリティ イベントを特定するために、人間または自動化されたツールによってログが毎日レビューされる実証可能な証拠を提供します。

• 意図: このコントロールの目的は、毎日のログ レビューが実行されていることを確認することです。これは、セキュリティ イベント アラートを提供するように構成されたアラート スクリプト/クエリによって取得されない可能性がある異常を特定するために重要です。

• 証拠ガイドラインの例: 証拠は通常、スクリーンショットまたはスクリーンシェアによって提供され、ログ レビューが行われていることを示します。 これは、毎日完了するフォームを使用するか、JIRA または DevOps チケットを使用して関連するコメントが投稿され、これが毎日行われることを示しています。 たとえば、週単位の JIRA チケットは、毎日のログ レビューの結果を毎日投稿する "毎日のログ レビュー W/C 26th June 2021" を作成できます。 異常にフラグが設定されている場合は、この同じチケット内で文書化して、1 つの JIRA 内の次のコントロールすべてを示すことができます。

• 自動化されたツールが使用されている場合は、スクリーンショットの証拠を提供して、構成された自動化を示し、自動化が実行されており、誰かが自動出力を確認することを示す追加の証拠を提供できます。

• 証拠の例: Contoso は、ログの相関関係とレビューのためにサード パーティの SOC プロバイダーであるクララネット サイバー セキュリティを利用しています。 AlienVault は、潜在的なセキュリティ イベントを強調する可能性がある異常なログとチェーン イベントの自動ログ分析を提供する機能を備えた SOC プロバイダーによって使用されます。 次の 3 つのスクリーンショットは、AlienVault 内の相関ルールを示しています。

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

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

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

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

コントロール 64: 潜在的なセキュリティ イベントと異常が調査および修復されていることを実証可能な証拠を提供します。

• 意図: 意図は、毎日のログ レビュー プロセス中に特定されたすべての異常が調査され、適切な修復またはアクションが実行されるということです。これには通常、異常にアクションが必要かどうかを特定するためのトリアージ プロセスが含まれます。その後、インシデント対応プロセスを呼び出す必要がある場合があります。

• 証拠ガイドラインの例: 毎日のログ レビューの一部として識別された異常がフォローアップされていることを示すスクリーンショットを含む証拠を提供する必要があります。 既に説明したように、これは、異常にフラグが設定され、その後に実行されたアクティビティの詳細を示す JIRA チケットを通じて行われる可能性があります。 これにより、実行されているすべてのアクティビティを追跡するために特定の JIRA チケットが引き上げられるか、毎日のログ レビュー チケット内に文書化される場合があります。 インシデント対応アクションが必要な場合は、インシデント対応プロセスの一部として文書化し、これを示す証拠を提供する必要があります。

• 証拠の例: 次のスクリーンショットの例は、クララネット サイバー セキュリティ MDR (マネージド検出と応答) SOC によって ServiceNow 内で追跡されているセキュリティ アラートを示しています。

この次のスクリーンショットは、ServiceNow カスタマー ポータル内の更新プログラムを通じて David Ashton @ Contoso によって解決されたことを示しています。

セキュリティ イベントアラート

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

コントロール 65: セキュリティ イベントアラートのプラクティスと手順を管理するポリシー ドキュメントを提供します。

• 意図: 環境の侵害やデータ侵害を示す可能性があるため、organizationからの即時応答を必要とする主要なセキュリティ イベントにアラートを使用する必要があります。 アラート プロセスに関する強力なプロセスを文書化して、これが一貫した反復可能な方法で実行されるようにする必要があります。 これにより、"データ侵害ライフサイクル" のタイムラインを減らすことができます。

• 証拠ガイドラインの例: セキュリティ イベント アラートのベスト プラクティスに関する文書化されたポリシーと手順のドキュメントを組織に提供します。

• 証拠の例: セキュリティ イベント アラート ポリシー/プロシージャからの抽出を次に示します。 評価をサポートするために、ポリシーと手順に関する完全なドキュメントを入力してください。

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

コントロール 66: 次の種類のセキュリティ イベントの即時トリアージに対してアラートがトリガーされるという実証可能な証拠を提供します。

• 特権アカウントの作成または変更

• ウイルスまたはマルウェアのイベント

• イベント ログの改ざん

• IDPS または WAF イベント (構成されている場合)

• 意図: 上記は、環境の侵害やデータ侵害を指し示す可能性のあるセキュリティ イベントが発生したことを強調する可能性がある、いくつかの種類のセキュリティ イベントの一覧です。

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

• 証拠の例: Contoso は、 クララネット サイバー セキュリティによって提供されるサード パーティの SOC を利用しています。 次の例は、SOC によって利用される AlienVault 内のアラートが、クララネット サイバー セキュリティの SOC チームのメンバーである Dan Turner にアラートを送信するように構成されていることを示しています。

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

コントロール 67: セキュリティ アラートに対応するために、スタッフが常に常に毎日利用可能であることを示す実証可能な証拠を提供します。

• 意図: セキュリティ アラートをできるだけ早くトリアージして、環境やデータへの公開を制限することが重要です。 スタッフは、アラートに対応し、侵害が特定された場合に重要な調査作業を提供するために常に利用できる必要があります。 このプロセスが迅速に開始されると、セキュリティ インシデントを迅速に含め、データを保護したり、侵害の影響を制限したりできます。
• 証拠ガイドラインの例: セキュリティ アラートに対応するために、スタッフのメンバーが 24 時間利用可能であることを示す証拠を提供する必要があります。 これは、オンコールの rota を使用する場合があります。
• 証拠の例: 次のスクリーンショットは、Contoso の 2020 年 12 月のオンコール rota を示しています。 クララネット サイバー セキュリティ SOC チームは、Contoso のオンコール チームのメンバーに警告します。

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

情報セキュリティ リスク管理は、すべての組織が少なくとも毎年実行する必要がある重要なアクティビティです。 組織は、これらの脅威を効果的に軽減するために、脅威とリスクを理解する必要があります。 効果的なリスク管理がなければ、組織は、重要であると認識される領域にセキュリティのベスト プラクティスを実装し、他の脅威の可能性がはるかに高く、そのため軽減する必要がある場合に、これらの領域にリソース、時間、お金を投資する可能性があります。 効果的なリスク管理は、組織がビジネスに最も脅威を与えるリスクに集中するのに役立ちます。 これは、セキュリティ環境が絶えず変化しているため、脅威とリスクが超過時間を変える可能性があるため、毎年実行する必要があります。 この良い例は、フィッシング攻撃の大幅な増加と、数百人または数千人の労働者のためのリモート作業の大量(および高速)ロールアウトを見たCOVID-19で見ることができます。

コントロール 68: 正式な情報セキュリティ リスク管理プロセスが確立されていることを示す証拠を提供します。

• 意図: 上で説明したように、組織がリスクを効果的に管理するために、堅牢な情報セキュリティ リスク管理プロセスが重要です。 これにより、組織は環境に対する脅威に対する効果的な軽減策を計画できます。

リスク評価には、一般的な "ビジネス" リスクだけでなく、情報セキュリティ リスクも含まれていることが重要です。

• 証拠ガイドラインの例: 正式に文書化されたリスク評価管理プロセスを提供する必要があります。
• 証拠の例: 次の証拠は、Contoso のリスク評価プロセスの一部のスクリーンショットです。

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

コントロール 69: 正式なリスク評価が少なくとも毎年行われるという実証可能な証拠を提供します。

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

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

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

これら 2 つのスクリーンショットは、2 つのリスク評価会議の会議の議事録を示しています。

コントロール 70: 情報セキュリティ リスク評価に脅威、脆弱性、または同等のものが含まれているという実証可能な証拠を提供します。

• 意図: 情報セキュリティ リスク評価は、環境とデータに対する脅威と、存在する可能性のある脆弱性に対して実行する必要があります。 これにより、組織は重大なリスクをもたらす可能性のある無数の脅威/脆弱性を特定するのに役立ちます。
• 証拠ガイドラインの例: 証拠は、既に提供されている情報セキュリティ リスク評価プロセスだけでなく、リスクと脆弱性を含むリスク評価 (リスク レジスタ/リスク処理計画を使用) の出力によって提供する必要があります。
• 証拠の例: 次のスクリーンショットは、脅威と脆弱性が含まれていることを示すリスク レジスタを示しています。

メモ： 完全なリスク評価ドキュメントは、スクリーンショットの代わりに提供する必要があります。

コントロール 71: 情報セキュリティ リスク評価に影響、尤度リスク マトリックス、または同等のものが含まれているという実証可能な証拠を提供します。

• 意図: 情報セキュリティ リスク評価では、影響と可能性の評価を文書化する必要があります。 これらのマトリックスは、通常、リスク値を減らすためにリスク処理の優先順位を付けるためにorganizationで使用できるリスク値を特定するために使用されます。
• 証拠ガイドラインの例: 証拠は、既に提供されている情報セキュリティ リスク評価プロセスだけでなく、影響と可能性の評価を含むリスク評価 (リスク レジスタ/リスク処理計画を使用) の出力によって提供する必要があります。
• 証拠の例: 次のスクリーンショットは、影響と可能性を示すリスク レジスタを示しています。

メモ： 完全なリスクassessment_ _document__ationは、スクリーンショットの代わりに指定する必要があります。

コントロール 72: 情報セキュリティ リスク評価にリスク レジスタと治療計画が含まれているという実証可能な証拠を提供します。

• 意図: 組織はリスクを効果的に管理する必要があります。 これは、適用されている 4 つのリスク処理のうちの 1 つの記録を提供するために、適切に追跡する必要があります。 リスク処理は次のとおりです。
• 回避/終了 : ビジネスは、リスクに対処するコストが、サービスから生成された収益よりも多いと判断する場合があります。 そのため、ビジネスはサービスの実行を停止することを選択する場合があります。
• 譲渡/共有 : 企業は、処理をサードパーティに移行することで、リスクを第三者に譲渡することを選択できます。
• 受け入れ/容認/保持 : ビジネスは、リスクが許容可能であると判断する場合があります。 これは企業のリスクアペタイトに大きく依存し、organizationによって異なる場合があります。
• 治療/軽減/変更 : ビジネスは、リスクを許容可能なレベルに減らすために軽減制御を実装することにしました。
• このコントロールの目的は、organizationがリスク評価を実行し、それに応じて対応していることを保証することです。
• 証拠ガイドラインの例: リスク評価プロセスが適切に実行されていることを示すために、リスク治療計画/リスク レジスタ (または同等のもの) を提供する必要があります。
• 証拠の例: Contoso のリスク レジスタを次に示します。

メモ： 完全なリスク評価ドキュメントは、スクリーンショットの代わりに提供する必要があります。

次のスクリーンショットは、リスク処理計画を示しています。

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

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

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

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

コントロール 73: セキュリティ インシデント対応計画 (IRP) を指定します。

• 意図: 既に説明したように、このコントロールの目的は、正式に文書化されたインシデント対応計画を要求することです。 これにより、セキュリティ インシデント対応をより効率的に管理するのに役立ちます。これにより、最終的に組織のデータ損失の露出を制限し、侵害のコストを削減できます。
• 証拠ガイドラインの例: インシデント対応計画/手順の完全版を提供します。 これには、次のコントロールで説明されている文書化された通信プロセスが含まれている必要があります。
• 証拠の例: 次のスクリーンショットは、Contoso のインシデント対応計画の開始を示しています。 証拠提出の一環として、インシデント対応計画全体を指定する必要があります。

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

コントロール 74: セキュリティ IRP には、支払いブランドや買収者、規制機関、監督機関、取締役、顧客など、主要な利害関係者にタイムリーな通知を確実にするために文書化された通信プロセスが含まれていることを実証可能な証拠を提供します。

• 意図: 組織は、事業を行う国/国 (たとえば、一般的なデータ保護規則) に基づいて違反通知義務を持つ可能性があります。GDPR)、または提供されている機能に基づいています (たとえば、支払いデータが処理される場合は PCI DSS)。 タイムリーな通知の失敗は重大な影響を及ぶ可能性があるため、通知義務を確実に満たすため、インシデント対応計画には、すべての関係者とのコミュニケーション、メディア通信プロセス、メディアと話すことができるユーザーと話し合えないユーザーを含む通信プロセスが含まれている必要があります。
• 証拠ガイドラインの例: 通信プロセスをカバーするセクションを含める必要があるインシデント対応計画/手順の完全なバージョンを指定します。
• 証拠の例: 次のスクリーンショットは、通信プロセスを示すインシデント対応計画からの抽出を示しています。

コントロール 75: インシデント対応チームのすべてのメンバーが年次トレーニングまたはテーブル トップ演習を完了したことを実証可能な証拠を提供します。

• 意図: 既に説明したように、organizationに侵害が含まれる時間が長いほど、データ流出のリスクが高くなり、流出データの量が多くなり、侵害の全体的なコストが高くなる可能性があります。 organizationのインシデント対応チームは、セキュリティ インシデントにタイムリーに対応する機能を備えている必要があります。 定期的なトレーニングを行い、テーブルトップ演習を実行することで、チームはセキュリティ インシデントを迅速かつ効率的に処理できます。

• 推奨事項は、インシデント対応チームの内部インシデント対応トレーニング と 、発生する可能性が最も高いセキュリティ インシデントを特定するために情報セキュリティ リスク評価にリンクする必要がある定期的なテーブルトップ演習の両方を実行することです。 これにより、チームは、最も可能性の高いセキュリティ インシデントを迅速に封じ込め、調査するために実行する手順を把握できます。

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

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

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

コントロール 76: 学習したレッスンまたは組織の変更に基づいてセキュリティ IRP が更新されていることを示す実証可能な証拠を提供します。

• 意図: 時間の経過と共に、インシデント対応計画 (IRP) は、組織の変更に基づいて、または IRP を制定するときに学習した教訓に基づいて進化する必要があります。 運用環境の変更では、脅威が変化したり、規制要件が変更されたりする可能性があるため、IRP の変更が必要になる場合があります。 さらに、テーブルトップの演習と実際のセキュリティ インシデントの対応が行われると、多くの場合、これは改善できる IRP の領域を識別できます。 これはプランに組み込む必要があり、このコントロールの目的は、このプロセスが IRP に含まれていることを確認することです。

• 証拠ガイドラインの例: これは、多くの場合、セキュリティ インシデントまたは学習したレッスンが識別され、IRP の更新プログラム内で結果が得られたテーブルトップ演習の結果を確認することで証明されます。 IRP は変更ログを保持する必要があります。これは、学習したレッスンや組織の変更に基づいて実装された変更も参照する必要があります。

• 証拠の例: 次のスクリーンショットは、提供された IRP からのものであり、学習したレッスンやorganizationの変更に基づいて IRP を更新するセクションが含まれています。

IRP 変更ログには、2021 年 7 月に実行された卓上演習の背面に更新が行われていることが示されています。

セキュリティ ドメイン: データ処理のセキュリティとプライバシー

このセキュリティ ドメインは、Microsoft 365 から使用されるデータが転送中と保存時の両方で適切に保護されるようにするために含まれています。 また、このドメインは、EU 市民のプライバシーに関する一般的なデータ保護規則 (GDPR) に従って、消費者 (データ主体) のプライバシーに関する懸念が ISV によって満たされていることを保証します。

転送中のデータ

Microsoft 365 で開発されたアプリ/アドインの接続要件により、通信はパブリック ネットワーク (インターネット) 経由で行われます。 このため、転送中のデータを適切に保護する必要があります。 このセクションでは、インターネット経由のデータ通信の保護について説明します。

制御 1: TLS 構成が TLS プロファイル構成要件内の暗号化要件を満たすか、または超えているという実証可能な証拠を提供 します。

• 意図: このコントロールの目的は、organizationによって使用されている Microsoft 365 データが安全に送信されるようにすることです。 TLS プロファイル構成では、中間者攻撃に対するトラフィックのセキュリティを確保するために、TLS 固有の要件が定義されています。

• 証拠ガイドラインの例: これを証明する最も簡単な方法は、 Qualys SSL Server Test ツールを、標準以外のポートで実行されるものも含め、 すべての Web リスナーに対して実行することです。

• [ボードに結果を表示しない] オプションをオンにしてください。これにより、URL が Web サイトに追加されなくなります。

• TLS プロファイル構成要件内の個々のチェックを示す証拠を提供することもできます。 構成設定は、スクリプトやソフトウェア ツールと共に使用して、特定の設定の一部 (TLS 圧縮が無効になっている) の証拠を提供するのに役立ちます。

• 証拠の例: 次のスクリーンショットは、 www.clara.net:443 Web リスナーの結果を示しています。

注: 認定アナリストは、TLS プロファイル構成要件のすべての要件が満たされていることを確認するために、完全な出力を確認します (完全なスキャン出力のスクリーンショットを提供してください)。 _what証拠 が 提供されたDepending_、アナリストは独自の Qualys スキャンを実行できます。

• 証拠 2 の例: 次のスクリーンショットは、TLS 1.2 がストレージに構成されていることを示しています。

メモ： このスクリーンショットだけでは、この要件を満たすことはできません。

• 証拠 3 の例: 次のスクリーンショットは、TLS V1.3 がサーバーでのみ有効になっていることを示しています。

この例では、レジストリ キーを使用して、次のように値を調整してプロトコルを無効または有効にします。

バイナリ: 0 - off 1 - on

16 進数: 0x00000000 - off 0xffffffff - on

注 : - この方法を理解していない場合は使用しないでください。Microsoft (Microsoft) は、この例を使用したり、この例に従ったり、その使用がシステムに与える影響について責任を負いません。 ここでは、TLS が有効か無効かを示す別の方法を示すだけです。

注: これらのスクリーンショットだけでは、この要件を満たすことはできません。

コントロール 2: Web 要求を処理するすべてのパブリック向けサービスで TLS 圧縮が無効になっていることを示す証拠を提供します。

• 意図: TLS 圧縮に影響する特定の TLS の脆弱性である CRIME (CVE-2012-4929) があります。 このため、業界の推奨事項は、この機能をオフにすることです。

• 証拠ガイドラインの例: Qualys SSL Labs ツールを使用して証拠にすることができます。

• 証拠の例: 次のスクリーンショットは、Qualys SSL Labs ツールを使用してこれを示しています。

コントロール 3: TLS HTTP の厳格なトランスポート セキュリティが有効になっており、すべてのサイトで = 15552000 に >構成されていることを実証可能な証拠を提供します。

• 意図: HTTP Strict Transport Security (HSTS) は、"Strict-Transport-Security" という名前の HTTPS 応答ヘッダー フィールドを使用して TLS 接続を強制することで、中間者攻撃から Web サイトを保護するように設計されたセキュリティ メカニズムです。

• 証拠ガイドラインの例: Qualys SSL Labs ツールまたはその他のツールや Web ブラウザー アドインを使用して証拠にすることができます。

• 証拠の例: 次のスクリーンショットは、 www.microsoft.com Web サイトの "HTTP Header Spy" という Web ブラウザー アドインを介してこれを示しています。

保存データ

Microsoft 365 プラットフォームから使用されるデータが ISV によって格納される場合は、データを適切に保護する必要があります。 このセクションでは、データベースとファイル ストアに格納されるデータの保護要件について説明します。

コントロール 4: 保存データが、AES、Blowfish、TDES、128 ビット、256 ビットの暗号化キー サイズなどの暗号化アルゴリズムを使用して、暗号化プロファイル要件と共にインラインで暗号化されていることを実証可能な証拠を提供します。

• 意図: 一部の古い暗号化アルゴリズムには、いくつかの暗号化の弱点が含まれていることがわかっています。これにより、アクティビティ グループがキーを知らなくてもデータを復号化できる可能性が高くなります。 このため、この制御の目的は、保存されている Microsoft 365 データを保護するために、業界で受け入れられる暗号化アルゴリズムのみを使用することです。

• 証拠ガイドラインの例: 証拠は、データベースやその他のストレージの場所内の Microsoft 365 データを保護するために使用されている暗号化を示すスクリーンショットを使用して提供できます。 この証拠は、暗号化構成が Microsoft 365 認定資格の 暗号化プロファイル構成要件 に沿った状態であることを示している必要があります。

• 証拠の例: 次のスクリーンショットは、Contoso Database で TDE (Transparent Data Encryption) が有効になっていることを示しています。 2 番目のスクリーンショットは、Azure TDE に AES 256 暗号化が使用されていることを示す Microsoft ドキュメント ページ 'SQL Database、SQL Managed Instance、Azure Synapse Analytics の透過的なデータ暗号化) を示しています。

• 証拠 2 の例: 次のスクリーンショットは、BLOB とファイルの暗号化を使用して構成された Azure Storage を示しています。 次のスクリーンショットは、Azure Storage が暗号化に AES-256 を使用していることを示す Microsoft Docs ページ "保存データの Azure Storage 暗号化" を示しています。

コントロール 5: ハッシュ関数またはメッセージ認証 (HMAC-SHA1) が暗号化プロファイル要件を使用して保存データをインラインで保護するためにのみ使用されることを実証可能な証拠を提供します。

• 意図: 暗号化アルゴリズムと同様に、一部のハッシュ関数とメッセージ認証アルゴリズムは、暗号化の弱点を持つアルゴリズムに基づいています。 このコントロールの目的は、ハッシュがデータ保護メカニズムとして使用されている場合に、Microsoft 365 データが強力なハッシュ関数で保護されるようにすることです。 これが環境やアプリケーションで使用されていない場合は、これを裏付ける証拠を提供する必要があります。

• 証拠ガイドラインの例: 証拠は、ハッシュ関数が機能しているコードのスニペットを示すスクリーンショットの形式である可能性があります。

• 証拠の例: Contoso は、アプリケーション内でハッシュ機能を利用します。 次のスクリーンショットは、SHA256 がハッシュ関数の一部として使用されていることを示しています。

コントロール 6: データの保護に使用されるストレージの場所や暗号化など、保存されているすべてのデータのインベントリを提供します。

• 意図: データを適切に保護するには、組織が使用している環境やシステムのデータと、データが格納されている場所を認識する必要があります。 これが完全に理解され、文書化されると、組織は適切なデータ保護を実装するだけでなく、データが配置されている場所を統合して保護をより効果的に実装できるようになります。 さらに、データをできるだけ少ない場所に統合する場合は、適切なロールベースのアクセス制御 (ロールベースのアクセス制御) を実装して、必要に応じて少数の従業員にアクセスを制限する方が簡単です。

• 証拠ガイドラインの例: 証拠は、ドキュメントを使用して提供するか、内部システム (SharePoint または Confluence) からエクスポートし、使用されたすべてのデータ、すべてのストレージの場所、実装されている暗号化のレベルを詳しく説明する必要があります。

• 証拠の例: 次のスクリーンショットは、データ型を示すドキュメントの例を示しています。

データの保持と破棄

ISV が Microsoft 365 データを使用して格納する場合、アクティビティ グループが ISV 環境を侵害した場合、これはデータ侵害のリスクになります。 このリスクを最小限に抑えるために、組織は、配信サービスに必要なデータのみを保持し、将来使用される可能性のあるデータは保持しないようにする必要があります。 さらに、データは、データがキャプチャされたサービスを提供するために必要な期間だけ保持する必要があります。 データ保持期間を定義し、ユーザーと通信する必要があります。 定義された保持期間を超えたデータは、データを再構築または回復できないように安全に削除する必要があります。

コントロール 7: 承認および文書化されたデータ保持期間が正式に確立されていることを示す証拠を提供します。

• 意図: 文書化および従った保持ポリシーは、一般的なデータ保護規則 (EU GDPR) やデータ保護法 (英国 DPA 2018) などのデータプライバシーに関する法律など、一部の法的義務を満たすだけでなく、組織のリスクを制限するためにも重要です。 組織のデータ要件と、ビジネスが機能を実行するために必要なデータの時間を理解することで、組織は、その有用性が期限切れになるとデータが適切に破棄されるようにすることができます。 格納されるデータの量を減らすことで、組織はデータ侵害が発生した場合に公開されるデータの量を減らしています。 これにより、全体的な影響が制限されます。

• 多くの場合、組織は単にデータを格納します。ただし、organizationがサービスやビジネス機能を実行するためにデータを必要としない場合は、組織のリスクが不必要に増加するため、データを格納しないでください。

• 証拠ガイドラインの例: ビジネスがビジネス機能を実行できるように、(すべてのデータ型をカバーする必要がある) データを保持する必要がある期間を明確に説明する完全なデータ保持ポリシーを提供します。

• 証拠の例: 次のスクリーンショットは、Contoso のデータ保持ポリシーを示しています。

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

コントロール 8: 保持データが定義された保持期間と一致する実証可能な証拠を提供します。

• 意図: このコントロールの目的は、定義されたデータ保持期間が満たされていることを単に検証することです。 既に説明したように、組織にはこれを満たす法的義務があるだけでなく、必要なデータを保持することで、データ侵害が発生した場合にorganizationに対するリスクを軽減するのに役立ちます。

• 証拠ガイドラインの例: 保存されているデータ (データベース、ファイル共有、アーカイブなど) が、定義されたデータ保持ポリシーを超えていないことを示すスクリーンショットの証拠 (またはスクリーン共有経由) を提供します。 たとえば、日付フィールドを含むデータベース レコードのスクリーンショット、最も古いレコード順で検索されたスクリーンショット、保持期間内のタイムスタンプを示すファイル ストレージの場所などがあります。

メモ： 個人/機密の顧客データは、スクリーンショット内で編集する必要があります。

• 証拠の例: 次の証拠は、データベース内の最も古いレコードを表示するために、'DATE_TRANSACTION' フィールドで昇順で並べ替えられたデータベース テーブルの内容を示す SQL クエリを示しています。 これは、データが定義された保持期間を超えない 2 か月前である必要があります。

メモ： これはテスト データベースであるため、その中に多くの履歴データはありません。

コントロール 9: 保持期間後にデータを安全に削除するためのプロセスが実施されていることを示す証拠を提供します。

• 意図: このコントロールの目的は、保持期間を超えるデータを削除するために使用されるメカニズムが安全に行われるようにすることです。 削除されたデータは、回復される場合があります。そのため、削除プロセスは、削除後にデータを復旧できないように十分な堅牢性が必要です。

• 証拠ガイドラインの例: 削除プロセスがプログラムによって実行される場合は、これを実行するために使用されるスクリプトのスクリーンショットを提供します。 スケジュールに従って実行される場合は、スケジュールを示すスクリーンショットを提供します。 たとえば、ファイル共有内のファイルを削除するスクリプトを CRON ジョブとして構成し、実行されるスケジュールとスクリプトを示す CRON ジョブをスクリーンショットし、使用するコマンドを示すスクリプトを提供します。

• 証拠 1 の例: これは、日付に基づいて保持されているすべてのデータ レコードを削除するために使用できる単純なスクリプトです。WHERE DateAdd は -30 日であり、選択したデータ保持日の 30 日より前のすべての保持レコードが消去されます。 スクリプトが必要ですが、実行されているジョブと結果の証拠も必要であることに注意してください。

• 証拠例 2: 以下は、コントロール 7 の Contoso Data Retention Plan から取得されています。これは、データの破棄に使用される手順を示しています。

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

• 証拠 3 の例: この例では、Runbook が作成され、Azure で対応するスケジュールが作成され、データ レコード保持ポリシーの有効期限が切れてから 30 日後に作成された終了日を持つレコードを安全に削除します。 このジョブは、月の最終日に毎月実行されるように設定されます。

次のウィンドウは、Runbook がレコードを検索するように編集され、スクリプトのように表示されていない削除コマンドを持っていることがわかります。 これらのスクリーンショットの完全な URL とユーザー名が表示されている必要があることに注意してください。削除前のレコード数のスクリーンショットと削除後のレコード数のスクリーンショットを表示するには ISV が必要です。 これらのスクリーンショットは、これがアプローチできるさまざまな方法の純粋な例です。

データ アクセス管理

データ アクセスでは、データが悪意を持って侵害されたり、誤って侵害されたりする可能性を減らすために、必要な人数に制限する必要があります。 データと暗号化キーへのアクセスは、仕事の役割を果たすためにアクセスするための正当なビジネス ニーズを持つユーザーに限定する必要があります。 これは十分に文書化する必要があり、アクセスを要求するための十分に確立されたプロセスを実装する必要があります。 データと暗号化キーへのアクセスは、最小限の特権原則に従う必要があります。

コントロール 10:Pビジネス上の正当な理由を含め、データまたは暗号化キーへのアクセス権を持つすべての個人のリストを表示します。

• 意図: 組織は、データキーと暗号化キーへのアクセスを可能な限り少数の従業員に制限する必要があります。 この制御の目的は、データや暗号化キーへの従業員のアクセスが、そのアクセスに対する明確なビジネス ニーズを持つ従業員に制限されるようにすることです。

• 証拠ガイドラインの例: データや暗号化キーへのアクセス権を持つすべての従業員と、これらの個人がアクセス権を持つ理由のビジネス上の正当な理由を文書化する内部システムのドキュメントまたはスクリーンショット。 この一覧は、次のコントロールのサンプル ユーザーに対して認定アナリストによって使用されます。

• 証拠の例: 次のドキュメントは、データへのアクセス権とビジネス上の正当な理由を持つユーザーの文書化された一覧を示しています。

コントロール 11: データまたは暗号化キーへのアクセス権を持つサンプリングされた個人が正式に承認されたことを示す証拠を提供し、ジョブ機能に必要な特権を詳細に示します。

• 意図: データキーや暗号化キーへのアクセスを許可するプロセスには、承認を含める必要があります。個人のアクセス権がジョブ機能に必要であることを確認します。 これにより、アクセスの真の理由のない従業員に不要なアクセス権が付与されないようにします。

• 証拠ガイドラインの例: 通常、前のコントロールに対して提供された証拠は、このコントロールをサポートするのに役立ちます。 提供されたドキュメントに正式な承認がない場合、証拠は、Azure DevOps や Jira などのツール内のアクセスに対して発行および承認される変更要求で構成される可能性があります。

• 証拠例: この画像のセットは、コントロール 10 の上記のリストに対して作成および承認された Jira Tickets を示し、機密データや暗号化キーへのアクセスを許可または拒否します。

この画像は、システム バックエンド環境で暗号化キーの Sam Daily 承認を取得するための要求が Jira で作成されたことを示しています。 これは、書面による承認が得られた上の 10 を制御する次の手順として行われます。

これは、Sam Daily アクセス権を付与する要求が、Jon Smith によって管理の人によって承認されたことを示しています。これは、コントロール 10 で確認できます。 (承認は、変更要求を許可するための十分な権限を持つユーザーから得られる必要があります。別の開発者にすることはできません)。

上記は、このプロセスの Jira のワークフローを示しています。自動化された承認プロセスを経ていなければ、完了として何も追加できないことに注意してください。

上記のプロジェクト ボードは、Sam Daily の暗号化キーへのアクセスに対する承認が与えられていることを示しています。 バックログの下には、Sam Daily の要求の承認と、作業を行うために割り当てられたユーザーが表示されます。

このコントロールの要件を満たすには、これらのすべてのスクリーンショットまたは同様のスクリーンショットと、コントロール要件を満たしていることを示す説明を表示する必要があります。

• 証拠 2 の例: 次の例では、運用 DB に対するユーザーに対して管理者アクセス許可とフル コントロールアクセス許可が要求されています。 要求は、画像の右側に表示されるように承認のために送信され、これは左側に表示されるように承認されています。

上記では、アクセスが承認され、完了したとおりにサインオフされていることがわかります。

コントロール 12: データまたは暗号化キーへのアクセス権を持つサンプリングされた個人が、承認に含まれる特権のみを持っているという実証可能な証拠を提供します。

• 意図: このコントロールの目的は、ドキュメントに従ってデータや暗号化キーのアクセスが構成されていることを確認することです。

• 証拠ガイドラインの例: 証拠は、サンプリングされた個人に付与されたデータや暗号化キーのアクセス特権を示すスクリーンショットを使用して提供できます。 証拠はすべてのデータの場所をカバーする必要があります。

• 証拠の例: このスクリーンショットは、前のコントロールの証拠に従って、この同じユーザーの承認要求に対して相互参照されるユーザー "John Smith" に付与されるアクセス許可を示しています。

コントロール 13: 顧客データが共有されているすべてのサード パーティの一覧を提供します。

• 意図: サード パーティが Microsoft 365 データの保存または処理に使用される場合、これらのエンティティは重大なリスクを伴う可能性があります。 組織は、これらの第三者がデータを安全に保存/処理し、GDPR の下でデータ 処理者などとして、法的義務を確実に遵守できるように、適切なサード パーティのデュー デリジェンスと管理プロセスを開発する必要があります。

• 組織は、次の一部またはすべてとデータを共有するすべてのサード パーティの一覧を保持する必要があります。

• どのサービスが提供されているか

• 共有されるデータ、

• データが共有される理由

• キー連絡先情報 (つまり、プライマリ連絡先、侵害通知連絡先、DPO など)

• 契約の更新/有効期限

• 法的/コンプライアンス義務 (つまり、GDPR、HIPPA、PCI DSS、FedRamp など)

• 証拠ガイドラインの例: Microsoft 365 データを共有 するすべての サード パーティを詳しく説明するドキュメントを提供します。

メモ： サード パーティが使用されていない場合は、上級リーダーシップ チームのメンバーが書面 (電子メール) で確認する必要があります。

• 証拠 1 の例

• 証拠 2 の例: このスクリーンショットは、Microsoft 365 データの処理にサード パーティが使用されていないことを確認するシニア リーダーシップ チームのメンバーの電子メールの例を示しています。

コントロール 14: 顧客データを使用するすべてのサード パーティが共有契約を締結していることを示す証拠を提供します。

• 意図: Microsoft 365 データがサード パーティと共有されている場合は、データが適切かつ安全に処理されていることが重要です。 第三者が必要な場合にのみデータを処理し、セキュリティ上の義務を理解するために、データ共有契約を締結する必要があります。 組織のセキュリティは、最も弱いリンクと同じくらい強力です。 このコントロールの目的は、サード パーティが組織の脆弱なリンクにならないようにすることです。

• 証拠ガイドラインの例: 第三者と実施されているデータ共有契約を共有します。

• 証拠の例: 次のスクリーンショットは、単純なデータ共有契約の例を示しています。

メモ： 完全な契約はスクリーンショットではなく共有する必要があります。

GDPR

ほとんどの組織は、ヨーロッパ市民 (データ主体) データの可能性があるデータを処理します。 任意のデータ主体のデータが処理される場合、組織は一般データ保護規則 (GDPR) を満たす必要があります。 これは、データ コントローラー (ユーザーが直接データをキャプチャしている) またはデータ プロセッサ (データ コントローラーの代わりにこのデータを処理している) の両方に適用されます。 このセクションでは、規制全体については説明しませんが、GDPR の重要な要素の一部に取り組み、organizationが GDPR を真剣に受け止めているという保証を得るのに役立ちます。

制御 15: 文書化されたサブジェクト アクセス要求 (SAR) プロセスを提供し、データ主体が SA を発生できることを示す証拠を提供します。

• 意図: GDPR には、データ主体のデータを処理する組織が満たす必要がある特定の義務が含まれています。 組織がサブジェクト アクセス要求 (SA) を管理する義務は、記事 12.3 の下で、要求に応答するために SAR の受信の 1 か月をデータ 管理者に提供する記事 12 に含まれています。 延長は、必要に応じてさらに 2 か月間許可されます。 organizationがデータ プロセッサとして機能している場合でも、顧客 (データ コントローラー) が SA の義務を果たすのに役立つ必要があります。

• 証拠ガイドラインの例: SA を処理するための文書化されたプロセスを提供します。

• 証拠の例: 次の例は、SAR を処理するための文書化されたプロセスを示しています。

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

コントロール 16: SAR に応答するときに、データ主体のデータのすべての場所を特定できる実証可能な証拠を提供します。

• 意図: このコントロールの目的は、organizationに、すべてのデータ主体のデータを識別するための堅牢なメカニズムが用意されていることを確認することです。 これは、すべてのデータ ストレージが十分に文書化されているため、手動プロセスである場合もあれば、SA プロセスの一部としてすべてのデータを確実に配置するために他のツールを使用することもできます。

• 証拠ガイドラインの例: 証拠は、すべてのデータの場所の一覧と、すべてのデータの場所を検索するための文書化されたプロセスによって提供される場合があります。 これには、データを検索するために必要なコマンドが含まれます。つまり、SQL の場所が含まれている場合は、特定の SQL ステートメントが詳細に表示され、データが正しく見つかることを確認します。

• 証拠の例: 次のスクリーンショットは、上記の SAR のプロシージャからのスニペットであり、データがどのように見つかるかを示しています。

次の 4 つの画像は、クエリが実行された ISV データの場所と、SA 要求に準拠するためにストレージから削除する必要があるファイルまたは BLOB へのドリルダウンに使用されたストレージ エクスプローラーを示しています。

このクエリは、使用中のストレージ アカウントを確認します。 Resource Graph エクスプローラー (Kusto) または PowerShell (下記参照) を使用して、ストレージ、BLOB、またはファイルのクエリを実行して削除できます。

上の図は、削除する必要があるクライアントの BLOB コンテナー内で見つかったデータを示しています。下の図は、BLOB 内の情報を削除または論理的に削除するアクションを示しています。

コントロール 17: 次のように、必要なすべての要素を含める必要があるプライバシー通知へのリンクを指定します。

• 会社の詳細 (名前、住所など)。

• 処理される個人データの種類について詳しくは、以下を参照してください。

• 個人データの処理の適法性について詳しくは、以下を参照してください。

• データ主体の権限の詳細:

  • 通知を受ける権利、
  • データ主体によるアクセス権、
  • 消去する権利、
  • 処理の制限を受ける権利、
  • データの移植性に対する権利
  • オブジェクトに対する権限、
  • プロファイリングを含む、自動化された意思決定に関連する権利。

• 個人データの保持期間の詳細。

• 意図: GDPR の第 13 条には、個人データの取得時にデータ主体に提供する必要がある特定の情報が含まれています。 この制御の目的は、組織のデータ プライバシーに関する通知で、第 13 条に含まれる重要な情報の一部をデータ主体に確実に提供することです。

• 証拠ガイドラインの例: これは通常、データのプライバシーに関する通知を提供することによって提供されます。 認定アナリストはこれを確認して、コントロール内で提供されるすべての情報がデータプライバシー通知に含まれていることを確認します。

• 証拠の例

上記および隣接するプライバシー通知の画像は、GDPR の第 13 条を含むオンライン プライバシー ポリシーの例を示しています。

以下は、前に示したプライバシーに関する通知と組み合わせて使用できるデータ保護ポリシーです。

上の Azure の画像は、バックエンド環境に格納されているデータに対する GDPR のコンプライアンス要件を満たすように Azure がどのように構成されているかを示しています。 ポリシー (Azure Blueprints からカスタム作成または構築できます) を使用すると、ISV はクライアントのデータが正しく格納され、設定されたメトリックとアラートによってのみアクセス可能になり、コンプライアンスが保証され、コンプライアンス マネージャー ダッシュボードに準拠していないデータまたはユーザー アクセスが表示されます。

ブック

Murdoch D. (2018) Blue Team Handbook: Incident Response Edition: Cyber Security Incident Responder の要約フィールド ガイド。 2nd Edition、Publisher: CreateSpace Independent Publishing Platform。

関連情報

• アクション詐欺サイバー犯罪の報告: https://www.actionfraud.police.uk/ (08/02/21 にアクセス)。
• Eu。 (2021) 利用可能なデータ コントローラーの GDPR チェックリスト: https://gdpr.eu/checklist/ (01/02/21 にアクセス)。
• マイクロソフト。 (2018) イベント ログ (Windows インストーラー) で利用可能: イベント ログ (Windows インストーラー) (アクセス: 23/12/20)。
• 肯定的なテクノロジ。 (2020) セキュリティで保護されたソフトウェア開発にアプローチする方法: https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/(アクセス: 21/12/20)。
• 欧州議会および2016年4月27日の理事会の2016/679は、個人データの処理およびそのようなデータの自由な移動に関する自然人の保護に関する規制(EU)、 および廃止ディレクティブ 95/46/EC (一般的なデータ保護規則) (EEA の関連性を持つテキスト) (2016) で https://www.legislation.gov.uk/eur/2016/679/contents 利用できます(アクセス日: 11/01/2021)。
• セキュリティ メトリック。 (2020) PCI DSS コンプライアンスのセキュリティ メトリック ガイド。 利用可能: https://info.securitymetrics.com/pci-guide-2020(アクセス日: 01/06/21)。
• Williams J. OWASP リスク ランキングは、次 https://owasp.org/www-community/OWASP_Risk_Rating_Methodology のページで入手できます (アクセス日: 08/12/20)。
• Qualys。 (2014) SSL Labs: 信頼の新しいグレード (T) と不一致 (M) の https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-mismatch-m-issues 問題が利用可能です(アクセス日: 29/01/21)。
• NIST SP800-61r2: コンピューター セキュリティ インシデント処理ガイドは、次https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final のページで入手できます (24/01/21 にアクセス)。

Microsoft ドキュメントから取得した画像

• https://www.sans.org/information-security-policy/(18/02/21 にアクセス)。 の動作分析と異常検出の取得 (16/02/21 にアクセス)。 「 Azure Monitor アラートとは」 で (17/02/21 にアクセス)。 の 動作分析と異常検出を取得 します (22/02/21 にアクセス)。 [Microsoft Defender for Cloud のセキュリティ アラートの管理と対応 ] (24/02/21 にアクセス)。 [Microsoft Defender for Cloud のセキュリティ アラートの管理と対応 ] (24/02/21 にアクセス)。
• https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html「クイック スタート: 詳細の構成」の「ポリシー割り当てを作成して非準拠リソースを識別する」の「SQL Database、SQL Managed Instance、Azure Synapse Analytics の透過的なデータ暗号化」の「Azure Information Protectionとは」Azure SQL データベースの脅威保護