セキュリティ ベースライン規範におけるリスク許容度のメトリックとインジケーターRisk tolerance metrics and indicators in the Security Baseline discipline

セキュリティ ベースライン規範に関連するビジネス リスク許容度を定量化することについて説明します。Learn to quantify business risk tolerance associated with the Security Baseline discipline. メトリックとインジケーターを定義すると、この規範の成熟に投資するためのビジネス ケースの作成に役立ちます。Defining metrics and indicators helps to create a business case for investing in the maturity of this discipline.

メトリックMetrics

セキュリティ ベースライン規範は、一般に、クラウド デプロイの潜在的脆弱性を特定することに焦点を合わせています。The Security Baseline discipline generally focuses on identifying potential vulnerabilities in your cloud deployments. リスク分析の一部として、セキュリティ環境に関連するデータを収集し、直面しているリスクの程度と、計画されているクラウド デプロイにとってセキュリティ ベースライン規範への投資がどれだけ重要であるかを特定することができます。As part of your risk analysis you'll want to gather data related to your security environment to determine how much risk you face, and how important investment in your Security Baseline discipline is for your planned cloud deployments.

すべての組織には、異なるセキュリティ環境と要件、および異なるセキュリティ データの潜在ソースがあります。Every organization has different security environments and requirements and different potential sources of security data. セキュリティ ベースライン規範内のリスク許容度の評価に役立てるために収集する必要がある有用なメトリックの例を以下に示します。The following are examples of useful metrics that you should gather to help evaluate risk tolerance within the Security Baseline discipline:

  • データ分類: 組織のプライバシー、コンプライアンス、またはビジネス インパクトの基準に従って分類されていない、クラウドに格納されたデータとサービスの数。Data classification: Number of cloud-stored data and services that are unclassified according to on your organization's privacy, compliance, or business impact standards.
  • 機密性の高いデータ ストアの数: 機密データが含まれていて、保護する必要があるストレージ エンドポイントまたはデータベースの数。Number of sensitive data stores: Number of storage endpoints or databases that contain sensitive data and should be protected.
  • 暗号化されていないデータ ストアの数: 暗号化されていない機密性の高いデータ ストアの数。Number of unencrypted data stores: Number of sensitive data stores that are not encrypted.
  • 攻撃対象領域: クラウドでホストされるデータ ソース、サービス、およびアプリケーションの合計数。Attack surface: How many total data sources, services, and applications will be cloud-hosted. それらのデータ ソースの何パーセントが機密情報に分類されるか。What percentage of these data sources are classified as sensitive? それらのアプリケーションとサービスのうち何パーセントがミッション クリティカルか。What percentage of these applications and services are mission-critical?
  • 対象となる基準: セキュリティ チームによって定義されたセキュリティ基準の数。Covered standards: Number of security standards defined by the security team.
  • 対象となるリソース: セキュリティ基準の対象となるデプロイされた資産。Covered resources: Deployed assets that are covered by security standards.
  • 基準への全体的なコンプライアンス: セキュリティ基準へのコンプライアンス準拠の比率。Overall standards compliance: Ratio of compliance adherence to security standards.
  • 重大度別の攻撃: 分散型サービス拒否 (DDoS) 攻撃などを通じて、クラウドでホストされるサービスを妨害する組織的攻撃がインフラストラクチャに対して試みられた回数。Attacks by severity: How many coordinated attempts to disrupt your cloud-hosted services, such as through distributed denial of service (DDoS) attacks, does your infrastructure experience? それらの攻撃の大きさと重大度。What is the size and severity of these attacks?
  • マルウェア対策: 必要なすべてのマルウェア対策、ファイアウォール、またはその他のセキュリティ ソフトウェアがインストールされているデプロイ済み仮想マシン (VM) の割合。Malware protection: Percentage of deployed virtual machines (VMs) that have all required anti-malware, firewall, or other security software installed.
  • 修正プログラムの待ち時間: VM で OS とソフトウェアの修正プログラムが適用されてからの経過時間。Patch latency: How long has it been since VMs have had OS and software patches applied.
  • セキュリティの正常性に関する推奨事項: デプロイ済みリソースの正常性の基準を解決するためのセキュリティ ソフトウェアの推奨事項の数 (重大度別)。Security health recommendations: Number of security software recommendations for resolving health standards for deployed resources, organized by severity.

リスク許容度インジケーターRisk tolerance indicators

クラウド プラットフォームには、小規模のデプロイ チームが、大規模な追加計画を行わずに基本的なセキュリティ設定を構成できるようにする、機能のベースライン セットが用意されています。Cloud platforms provide a baseline set of features that enable small deployment teams to configure basic security settings without extensive additional planning. その結果、機密データを含まない小規模な開発/テストまたは実験用の最初のワークロードは、相対的に低いリスク レベルを表し、正式なセキュリティ ベースライン ポリシーに関して多くを必要としない可能性が高くなります。As a result, small dev/test or experimental first workloads that do not include sensitive data represent a relatively low level of risk, and will likely not need much in the way of formal Security Baseline policy. 重要なデータやミッション クリティカルな機能がクラウドに移動されるとすぐにセキュリティ リスクが増加し、それらのリスクの許容度は急速に縮小します。As soon as important data or mission-critical functionality is moved to the cloud, security risks increase, while tolerance for those risks diminishes rapidly. クラウドにデプロイされるデータと機能が増えるほど、セキュリティ ベースライン規範への投資を増加する必要性が高くなります。As more of your data and functionality is deployed to the cloud, the more likely you need an increased investment in the Security Baseline discipline.

クラウド導入の初期段階で、IT セキュリティ チームおよびビジネス利害関係者と協力して、セキュリティに関連したビジネス リスクを特定し、セキュリティ リスク許容度の受け入れ可能なベースラインを判断してください。In the early stages of cloud adoption, work with your IT security team and business stakeholders to identify business risks related to security, then determine an acceptable baseline for security risk tolerance. クラウド導入フレームワークのこのセクションでは例を提供しますが、お客様の会社またはデプロイの詳細なリスクおよびベースラインは異なる可能性があります。This section of the Cloud Adoption Framework provides examples, but the detailed risks and baselines for your company or deployments may be different.

ベースラインが決まったら、特定したリスクでの許容できない増加を表す最小ベンチマークを確立します。Once you have a baseline, establish minimum benchmarks representing an unacceptable increase in your identified risks. これらのベンチマークは、それらのリスクを修正するためのアクションが必要となるタイミングを知るためのトリガーとして機能します。These benchmarks act as triggers for when you need to take action to remediate these risks. 前述のようなセキュリティ メトリックがセキュリティ ベースライン規範への投資の増加をどのように正当化できるかについてのいくつかの例を以下に示します。The following are a few examples of how security metrics, such as those discussed above, can justify an increased investment in the Security Baseline discipline.

  • ミッション クリティカルなワークロードのトリガー。Mission-critical workloads trigger. ミッション クリティカルなワークロードをクラウドにデプロイする企業は、潜在的なサービスの中断や機密データの開示を防ぐためにセキュリティ ベースライン規範に投資する必要があります。A company deploying mission-critical workloads to the cloud should invest in the Security Baseline discipline to prevent potential disruption of service or sensitive data exposure.
  • 保護されたデータのトリガー。Protected data trigger. 機密データや個人データに分類できるデータ、またはそれ以外の規制対象となるデータをクラウドでホストしている企業。A company hosting data on the cloud that can be classified as confidential, private, or otherwise subject to regulatory concerns. そのデータが失われたり、公開されたり、盗まれたりしないように、セキュリティ ベースライン規範が必要です。They need a Security Baseline discipline to ensure that this data is not subject to loss, exposure, or theft.
  • 外部からの攻撃のトリガー。External attacks trigger. ネットワーク インフラストラクチャに対する重大な攻撃を 1 か月につき x 回経験している企業は、セキュリティ ベースライン規範を活用できます。A company that experiences serious attacks against their network infrastructure x times per month could benefit from the Security Baseline discipline.
  • 基準のコンプライアンスのトリガー。Standards compliance trigger. x% を超えるリソースがセキュリティ基準のコンプライアンスを順守していない企業は、IT インフラストラクチャ全体にわたり一貫して基準が確実に適用されるようにするために、セキュリティ ベースライン規範に投資する必要があります。A company with more than x% of resources out of security standards compliance should invest in the Security Baseline discipline to ensure standards are applied consistently across your IT infrastructure.
  • クラウド資産サイズのトリガー。Cloud estate size trigger. x を超えるアプリケーション、サービス、またはデータ ソースをホストしている企業。A company hosting more than x applications, services, or data sources. 大規模なクラウド デプロイは、攻撃対象領域全体が、不正アクセスやその他の外部の脅威から適切に保護されるようにするために、セキュリティ ベースライン規範への投資を活用できます。Large cloud deployments can benefit from investment in the Security Baseline discipline to ensure that their overall attack surface is properly protected against unauthorized access or other external threats.
  • セキュリティ ソフトウェア コンプライアンスのトリガー。Security software compliance trigger. すべての必要なセキュリティ ソフトウェアがインストールされているデプロイ済み仮想マシンが x% 未満の企業。A company where less than x% of deployed virtual machines have all required security software installed. すべてのソフトウェアで一貫してソフトウェアがインストールされるようにするために、セキュリティ ベースライン規範を使用できます。A Security Baseline discipline can be used to ensure software is installed consistently on all software.
  • 修正プログラムのトリガー。Patching trigger. デプロイ済み仮想マシンまたはサービスに、OS やソフトウェアの修正プログラムが過去 x 日間適用されていない企業。A company where deployed virtual machines or services where OS or software patches have not been applied in the last x days. 必要なスケジュール内で修正プログラムが最新状態になるようにするためにセキュリティ ベースライン規範を使用できます。A Security Baseline discipline can be used to ensure patching is kept up-to-date within a required schedule.
  • セキュリティ重視Security-focused. 一部の企業には、テストや実験的なワークロードについても、強力なセキュリティおよびデータ機密性の要件があります。Some companies will have strong security and data confidentiality requirements even for test and experimental workloads. それらの企業は、デプロイを開始する前に、セキュリティ ベースライン規範に投資する必要があります。These companies will need to invest in the Security Baseline discipline before any deployments can begin.

リスク許容度とセキュリティ ベースライン規範への投資レベルを測定するために使用する正確なメトリックとトリガーは組織固有のものとなりますが、上記の例は、クラウド ガバナンス チーム内での協議を行うための有用な開始点として機能するはずです。The exact metrics and triggers you use to gauge risk tolerance and the level of investment in the Security Baseline discipline will be specific to your organization, but the examples above should serve as a useful base for discussion within your cloud governance team.

次のステップNext steps

セキュリティ ベースライン規範テンプレートを使用して、現在のクラウド導入計画に整合するメトリックと許容度インジケーターを文書化します。Use the Security Baseline discipline template to document metrics and tolerance indicators that align to the current cloud adoption plan.

クラウドの導入計画に合致する特定のビジネス上のリスクに対処する独自のポリシーを作成するための開始点として、セキュリティ ベースライン ポリシーのサンプルを確認します。Review sample Security Baseline policies as a starting point to develop your own policies to address specific business risks aligned with your cloud adoption plans.