PUBLIC - Multi Cloud Security Maturity Roadmap - DRAFT - Feb'23

	A	B	C	D	E	F	G
1	Multi Cloud Security Maturity Roadmap
2	version 0.1, 19 February 2023
3	Aashish Aacharya (AJ), Adam Chou, Almahdi Sahad, Ashish Rajan, Claude Mandy, David Levitsky, Frank Graziano, Kyhle Öhlinger, Paul Schwarzenberger, Shawn Tolidano
4	This Roadmap is built with the NIST CyberSecurity Framework (CSF) framework as a foundation. This document is a guide for any organization to map their level of maturity in a Multi Cloud environment. Organizations should be able to select the appropriate level suited for them from this document and use it to map to their internal maturity framework with to plan, implement and improve their maturity.
5	Dictionary: - Cloud - Compute capabaility provided as a service by CSPs. - CSP - Cloud Service Provider e.g Amazon Web Services, Microsoft Azure, Google Cloud etc - CLI - Command Line Interface for interacting with available Application Programmable Interface (APIs) using commands & credentials to authenticate requests
6	NIST CSF Functions	Category	Level 0	Level 1	Level 2	Level 3	Level 4
7			Initial Visibility	Effective	Foundational	Efficient	Optimized

8	Identify	Asset management and ownership	- All Workload and processes that create resources in any CSP have been attributed to a Business owner. - New Workload and processes in CSPs are created using a pre-defined process (manual) - Repository of Current State of Workload resources in CSPs	- Identify Account owners/team - Security policy on assets have been defined.	- Business processes are defined, implemented, and adhered to. The process should categorize findings by severity with various SLAs for each category. - SLAs have been defined by the business, based on the amount of risk it is willing to accept for any resource - Discovery of Orphan and New Assets is done by a pre-defined (manual) process - Asset Management Repository for Cloud to track the current state of resource	- Automated method to identify resources that are compliant with policy - Resource hygine with ownership information easily available on resources - Identify Assets and Business Risk Level of Assets hosted in CSP - Integration with CSP Billing to valiidate - Integration with Accounts & Finance or a capability to prevent Shadow Cloud IT - Enforce labeling for business owners, team_name etc for all resources with automation	- All resources are under automated management. Security policies are enforced via automation processes. - Discovery of Orphan and New Assets is done by automated process - Monitoring Change of State of existing resources in CSPs with alerts based on risk level - Prevention and Alerting on Assets created withouth Business Owners
9		Cloud Environment (s)	- Identify all CSPs used in organization, and owning groups/Business Units/Teams - Ensure All CSPs have billing that includes support from CSP - Ensure All CSPs have incident response support included - Ensure All CSPs Security Notifications/Advisories are sent to a managed group email/communication channel to ensure effective response	- Establish org-wide process for CSP selection - Define and Ensure a list of known CSPs is maintained to prevent any CSPs which may not be managed by the organization - Define a Data Classification for the type of Data that can be shared with or stored in which CSP - Define selection of selective CSP services in a service Catalog which are allowed to be used - Define a process for new CSP services to be reviewed and assessed before being allowed to use in production environments	- Clear Understanding of the business or technical drivers for using more than one cloud. - Establish org-wide process for new CSP selection - Identify potential consolidation to reduce number of cloud environments across organization - Identify Trust Boundaries between CSPs and On-premise for type of data, user types that can access particular CSPs only	- Identify potential consolidation to reduce number of cloud environments across organization - Using Automated Policies to prevent CSP services not compliant to businiess required compliance standard from being used (More under Detection tab of this Matrix Model) - Using Automated Policies to prevent CSP new network connections to be established - Using Automated Policies to prevent new Identity creation (more under Identity tab of this Matrix Model)	- Self Service Catalog option for CSPs for employees to add new CSP services for production/development use - Integration with Billing for new CSPs services - Monitoring and Alerting for CSP services not compliant to businiess required compliance standard from being used - Monitoring and Alerting for CSP new network connections to be established - Monitoring and Alerting for new Identity creation (more under Identity tab of this Matrix Model)
10		Governance	- Compliance frameworks applicable for CSPs have been defined. - List of Common CSP services used in each CSPs have been established - Group Owner/Business Owner for resources that require compliance have been established	- Collect CSP Security attestation documents to understand the shared responsibility model. - Compliance frameworks applicable for CSPs have been defined. - Define Approved CSP regions to operate have been selected in each cloud - Define Compliant CSP services that are approved for production use. - Address and create a disposition for CUECs (Complementary User Entity Control), if applicable	- Overarching policies have been defined (management, patching, etc.) - Governance and decision making authority for each cloud defined. - Manual Audit Process defined for CSP period reviews - Manual Process defined for adding new compliant CSP services to be allowed for use in production environments - Technical Risk Matrix defined for resources and services hosted in CSP based on business risk tolerance - Labeling resources in CSP that require compliance with business owners and compliance standard	- Define a Unified Governance and Decision making authority across all clouds - Automate periodic Evidence collection for internal resources in CSP - JIT (Just in time) access for Auditor to create Cloud environment snapshot - Semi-automatic process to collect evidence from Cloud - central location that stores the currrent state of resources that require compliance oversight	- Governance combined with management reporting to ensure teams prioritise compliance - Monitoring and Alerting for change of compliance status for any resources in CSPs - Monitoring and Alerting for change in currrent state of resources that require compliance oversight - Monitoring and Alerting on new services being created in Compliance restricted CSPs
11		Risk Assessment	- Develop a standard risk assessment template to assess the suitability of each CSP to specific workloads	- Define a Risk Matrix for CSP to CSP for how the risk associated to a vulnerability would be measured in terms of frequency and business impact. - Define a Risk Matrix for On-premise to CSP for how the risk associated to a vulnerability would be measured in terms of frequency and business impact. - Define a Risk Register for each CSP or combined based on the organization structure	- All threats per CSP (internal & external) are asssessed and reviewed by the organization - All vulnerabilities once identified are document in a formal Risk Regiser with an Action Plan - Conduct individual risk assessments per CSP on periodic basis. - External/Internal Audit of existing risks in the Risk Register per CSP on a periodic basis	- Conduct individual and aggregate risk assessments per CSP and across CSP's. - Document exit strategy and plan for each CSP - Conduct Periodic Business Continuity Planning excercise per CSP	- Continiously update individual and aggegrate risk assessmenets with results from continious control monitoring across each CSP.
12		Risk Management Strategy	- Risk management processes are established, managed, and agreed to by organizational stakeholders per CSP	- Organizational risk tolerance per CSP is determined and clearly expressed across the organization	- The organization’s determination of risk tolerance per CSP is informed by its role in critical infrastructure and sector specific risk analysis	"- The organization’s determination of risk tolerance per CSP is quantified periodically based on measurable business impact such as revenue and data at risk. - Periodic review of the risk tolerance per CSP to reduce or increase the tolerance level based on it's risk posture
13		Supply Chain Management Risk	- List of current 3rd Party suppliers (including CSP's)	- Have a process defined for onboarding 3rd party services not limited to Iac Tool, CI/CD tools, Secret Management, IDP etc - Have an approved vendor list of 3rd party services - Have a process defined for offboarding 3rd party services - Have a current contact list from 3rd party service to reach out for any security incidents	- Industry Standard based Access for 3rd party (e.g SAML etc) - Consolidate and Standardise Vendors performing the same function - Suppliers and third party partners across information systems, components, and services are identified, prioritized, and assessed using a cyber supply chain risk assessment process - Define communication expectation from 3rd party as part of contract in case of a cybersecurity incident at the 3rd party	- Periodic review and rightsizing of least privilege access provided to 3rd parties.	- Continuous automated rightsizing of least privilege access provided to 3rd parties based on usage of permissions. - Response and recovery planning and testing are conducted with suppliers and third-party providers
14	Protection & Prevention	Identity and Access management	- Visibility of Users that can access any of the CSPs in the business - Establish list of current active users per CSPs - Establish a single Source of Truth for Users in the organisation for all CSPs	- Define Onboarding and Offboarding process for user to get access to CSP(s) - Defined standards and policy for provisioning of Machine users in production environment per CSP - Centralized IDP for all clouds to enable Authentication using standards like Single Sign On (SAML etc) - Disable or limit the use of Default Cloud Administrator accounts in CSP (root user in AWS,Azure Account Administrator etc) - Manual User Access Review Audits to be conducted - Audit capability in place for all actions performed by Users per CSP	- Define User/Machine Permission based on Roles (RBAC) to be provisioned, when a new instance/account of CSP is assigned to a business for use. - Alerts are enabled for login of CSP Admin User(s) including CSP provided default Admin User(s) - Periodic review of User Access per CSP (Automated through IDP review) - Permission Role definition is manually reviewed periodically per CSP - Enable 2 Factor authentication for CLi, API & Console access of CSP - Well defined access grant/revoke process per CSP for 3rd party services (monitoring, observability, log aggregation etc)	- Central Security Policy for User access defined across all CSPs - Centralised Policy Engine for granting and managing users access to resources - Access to a centralised entitlement management tool for all identifies across CSPs to monitor for over privilege access per CSP - Privileged access is limited to a control zone providing just-in-time access to resources - Baselines established for common access patterns. Controls implemented to monitor and/or proactively deny uncommon access types where applicable. - Define process for revoking access incase of incident - Periodic reporting of who has access to what	- Eliminate long term credentials with temporary credentials - Enforce Centralised Security Policy for Access across all CSPs Organizations. - Alert and automatically limit user access based on user related malicious activites detected through a central entitlement management tool - Auto rotate access keys (where needed, sometimes keys are required due to application needs) - Multi-Cloud Zero Trust across multiple IDP - Integration to HR systems is implemented across all CSPs to grant or revoke or terminate access automatically - User and entity behavior analytics spans all CSPs
15		Data protection	Data inventory of data stores has been created with native classification tags assigned to individual data stores in each cloud	- Define CSP regions & services that are compliant for use to match compliance needs like GDPR or similar - Data discovery and classification tools (such as AWS Macie or other DSPM tools) are used to validate the location of data in each cloud. - Data Owners/Stewards are named and understand their responsibilites and nuances per cloud - Development of backup policy and SLAs	- Encryption at rest and in transit is enabled across services. - Enable data activity logs on data stores to record data operations. - Process defined on Data Usage to prevent Data Sprawling across the organzation - Procedure defined per data classification for when used or provided to a CSP - A program is identified to define and implement Data Sovereignty requirements - Disable the use of CSP Regions as non-compliant where the data classfication is not accepted as per organization data policies - DLP tools deployed in each CSP with a centralized policy engine to identify potential breach	- Continuous rightsizing of Least privilege access to data. - Single data posture view across all clouds - Backup data when possible or set mechanisms for data recovery (eg WORM model, archival, life cycle policy, bucket replications etc) - Regular testing of data recovery capability against RTO & RPO SLAs of the organization	- Encryption at rest and transit enforced by default where possible - Auto Deletion/Quarrantine of resources per CSP that do not have encryption enabled. - Traffic analysis in place to identify data exfiltration and cross account operations through the corporate network and when communicating with CSPs. - Enforce additional authentication on modify/update/delete permissions for any data storage type
16		Infrastructure Security	- Document the type of infrastructure services in use per CSP (e.g servers, containers, serverless etc) - List of users/roles/teams that can provision infrastructure per CSP - Built-in reporting tools for each CSP (Security Hub, Security Command Center, Defender for Cloud) is in use to identify current posture. - Register an active group email address for security advisory newsletter or reporting per CSP	- Define org policies for use of CSP region(s) including regions that should not be active or used for production purposes e.g. deployment to authorised regions only - Scan environment for current security posture - vulnerabilities, misconfigurations and risks - Audit Access to Cloud infrastructure (cli vs console vs ssh/telnet etc) - Identify & document network availability status list of all infrastructure (only internet facing workloads) - Define the standard for use of Infrastructure as Code to deploy infrastructure (e.g Cloud provided vs 3rd party etc)	- Define policies for the use of Machine user permissions (e.g Instance Roles in AWS, Service Principles in Azure etc) e.g labeling, role scope definition per application or per services etc - Identify & document network availability status list of all infrastructure (private facing, on-premise connected & internet facing workloads) - Define process for securing IaaS, PaaS services in use per CSP - Establish a secure Access Control procedure to access workload infrastructure in cloud e.g Secure bastion host (logging, monitoring etc) Bast if certificate based authentication used (like AWS SSM, Teleport, AWS IAM/SSO based RDS access) vs SSH/RDP (which needs ports opened and often shared credentials/keys) - Where applicable a security product for workload protection is implemented per CSP to monitor for real time threat on the infrastructure e.g Endpoint protection, IDS, IPS, Anti-Virus etc - Either CSP provided or 3rd party vulnerabilities management software is available to monitor OS images for vulnerabilities - Layer 3/7 protection (DDoS Protection etc) for internet facing infrastructure resources - Built-in reporting tools for each cloud (Security Hub, Security Command Center, Defender for Cloud) is implemented	- Infrastructure is build using Cloud Native capabilities with Infrastrucutre as Code using pre-defined state for the infrastrucutre - IaC code is scanned for vulnerabilities before being deployed - Infrastructure is deployed through a CI/CD pipeline with security guardrails to prevent a vulnerable OS or vulnerable infrastructure to be deployed as part of the infrastructure deployment process - All security logging of infrastructure and any 3rd party security agents on the infrastrucutre is also centralised in a log aggregation product - Define policies to prevent any critical misconfigurations (e.g. public resources, trust relationships with unknown accounts or 3rd parties, security group open inbound 0.0.0.0/0 for predefined/sensitive ports) - Centralised Policy Engine for granting and managing which machine users/Orchestration tools or similar can provision infrastructure to CSPs - Maintain a Service Catalog of pre-approved patterns to automatically provision cloud services as per company security policy	- Security operations has access to cloud security posture tooling to monitor for potential incidents in cloud with custom queries capabilities prioritising key assets of organisation to detect and respond to infrastructure vulnerabilities - Trigger an Alarm for a misconfiguration which when auto-remediated send a notification to a communication platform (e.g slack/Teams etc) about the action taken and any further action required. - Create Alarms based on security best practices for effective cloud posture management by prevention first approach - Automation using IaC to build all infrasructure
17		Network security	- An up-to-date network architecture diagram exists - Identify group that approves or makes changes to network topology	- Discover and Document on-premise network zones connected to CSP(s) - Identify and document current list of all public or internet facing zones with workloads - Discover and Document any overlapping CIDR Ranges between CSPs and On-premise - Discover and Document any difference in NTP (Network Time Protocol) between CSPs compared to on-premise	- Define process for establishing new or modifying existing network connections from on-premise to CSP - Define network policies for production environments to limit un-authorized changes to network - Define on-premise network or data centre exit point (e.g AWS Direct connect, Express Route, InterConnect etc)that are acceptable to be extended for communication to CSP(s) - Define the network zones from on-premise that can access CSP(s) - Define network policies for private or public communication between CSP(s) used by the organization to host workload - Enforce and manage egress access to the internet from all cloud compute resources for all CSPs - Use centralized firewalls or proxies for internet facing endpoint/resources in CSP - Establishment of approved network design patterns for common use cases (e.g VPCs, Vnets, and their respective components) - Establishment of acceptable inter-Virtual network, inter-account, and inter-CSP connectivity and communication criteria.	- Log DNS records (eg Route53 inbound logs) and Outbound (eg originating from VPC, recursive resolvers query logging). Super important for investigations as well - Centralized ingress and egress logs (i.e. Network security logs, layer 7 traffic exposed to DDoS etc) for monitoring - Centralised Policy Engine for managing real time network access to resources - DLP tools deployed in each CSP with a centralized policy engine to identify potential breach - Define the same NTP across all environment of CSP and on-premise	- Monitor and raise alerts on unexpected network behaviour e.g Usage spike, bitcoin mining dns query etc - Define process to updated alerts based on services - Auto remediation of network changes that don't comply with pre-defined network security policies
18		Application and workload protection	- Workload inventory exists per CSP - List of All Application Workload based on business importance level per CSP - Identify a current Solution Architecture of the application deployed per CSP and the business owner	- Security posture review of All internet facing Application Workload based on business importance level per CSP - Discover and document the programming languages used to deploy application - Discover and document the security gates/guardrails in IaC or the exising application deployment process	- Code Repositories (with IaC and Application code) are scanned for any saved secrets/passwords etc - Define IaC to code practice for deploying applications and workloads into CSP - Implement compute runtime monitoring tools such as EDR on VMs, runtime inspection on containers. - Implement vulnerability scanning on application code and OS being deployed into the production environment - Implement "shift-left" principle of identifying the vulnerabilities (e.g vulnerable dependent library, static code, dynamic code analysis etc) - Implement a Threat Model framework to be used by developers deploying the workload - Implement a central workload protection capability for hosts running the application workload - A manual approval process for deployment into highly critical production application workload - An automated approval process for deployment of small trivial changes into production - Establish a Threat modelling process across all application development teams	- Security Guardrails embedded into the CI/CD Deployment pipeline to prevent any vulnerable IaC, vulnerable Application Code to be deployed - Mean time to detection & Mean time to remediation is measured to track effiiciency of application and workload protection - Security Champions program is defined to "shift-left" and stop vulnerabilities from beind deployed by developers and engineers across the application deployment pipeline to all CSPs (e.g no secrets being deployed, no vulnerable depedency, no failed static test etc)	- Single Cloud Workload Protection Platform across all clouds - Auto Backup of IaC in secure site - IaaC (shift left), CICD scanning - Code signing using Digital signature for all commits to code repository to ensure no tampering was performed - MFA enforcement/approval process for any commits/changes/deployments and/or two-person pull requests for merges to deployment branch
19		Zero Trust	- Awareness of all Zero Trust initiatives across enterprise	- Pre-requisites for Zero Trust solution: single identity source, managed devices, solution for internal network apps	- Policy based access enforcement for humans based on identity, location, device status, application, for initial cloud	- Policy based access enforcement for humans based on identity, location, device status, application, for all clouds	- Add policy enforcement for data according to sensitivity/classification, add zero trust for machines (service accounts)
20		Team skills and training	- Pockets of expertise in each Cloud, often in different parts of the business - Team should have understanding of common CSP components and services used in the organization. - Team should understand the security best practice of common CSP services in use in the organization - Team has Basic ability to query security and non-security events in each cloud.	- Identify the current cloud certification level per CSP(s) across the team - Identify the breath of exposure to cloud native security services from CSP across the team - Identify the breath of exposure to working with building and managing security capabilities in CSP across the team	- Some team members certified in more than one of the Cloud Environments in use - Team members certified in at least one of the Cloud Environments in use - Access to Cloud Certification Training from CSP - Access to Training from CSP directly - Threat modelling exercises common among teams - Establish a Community of Practice (COP) or Guild functions with Chapter Leads	- Regular training budget allocated for attending cloud security conferences	- Internal training session conducted to inform wider organization on security best practices - Internal red team team exercises simulating threats in collaboration with defenders to test detection and response (includes wider organization member in the excercise)
21
22	Detect	Threat Detection	- Logging is enabled and collected from core workload and infrastructure services such as API logging, network flow logs, Cloud User Audit logs etc. - Baseline of network operations and expected data flows for users and services should be established, managed and updated periodically to distinguish from security threat behaviour	- Enable Cloud Native Threat Detection services per CSP (e.g AWS Guardduty, Azure Sentinel, etc - potential alternative is turn on CSP detection capabilities in other CSPs)	- Logging strategy has been defined for all Cloud Threat sources (e.g Amazon GuardDuty, GCP Security Command Center, Microsoft Defender suite etc) - Event Data source relevant for security events per application workload hosted in CSP is defined and collected - Detected events are analyzed to understand attack targets, methods and potential impact - Define Incident Alert threshold for response to known threats per CSP. - Begin to enable monitoring around common threats in respective cloud - Relevant Cloud Threat Detection service logs/events are collected centrally in Cloud event aggregation tools e.g AWS Security Hub etc	- Centralized SIEM / log aggregation tool/Data Lake collects, correlates & analyse logs from all clouds & other security source that exist in the orgnization. - Threat intelligence feeds are enriching security events - Third party logs are ingested and monitored to detect security events (for example, IDP logs from 3rd party, security logs from 3rd party etc) - Strategy to implement alerts for deviation from known state (if IaC is being used to deploy infrastructure)	- Centralized SIEM with fine-tuned alerts prioritising key assets of organisation, periodically tested by Red Team - Detection process are continously improved across all CSPs in use within the organization - Continuously test detections to ensure accuracy of rules and test response runbooks
23		Cloud Security Assurance	- Compliance reporting to Industry Security Benchmark(e.g NIST,CIS, ISO 27001, SOC2 etc)/ Compliance Standards from built-in tools from each cloud provider(Security Hub, Security Command Center, Defender for Cloud)	- Improve compliance levels, e.g. 50% of Industry Security Benchmark tests passing - Conduct Penetration Test for all application workload and their APIs - Point in time Assessment of Cloud Accounts/Tenant/Organization for security posture, backup, disaster recovery capabilities	- Improve compliance levels, e.g. 90% of Industry Security Benchmark checks passing etc - Periodic Penetration Testing of all application workload & their APIs to maintain risk exposure level - Periodic Disaster Recovery and Business Continuity test are conducted and documented on all systems	- Centralised compliance reporting to Industry Security Benchmark for all clouds, e.g. using CSPM tool - Use of Infrastructure as Code framework to drive Compliance to security policy as code - Monitoring enabled for Mean time to resolve and Mean time to detect - Mapping Controls for GRC Modelling across multiple compliance frameworks for ease of compliance by staff (e.g Adode CCF etc)	- Add customised reporting, e.g. mean time to fix per team
24		Vulnerability management	- Asset inventory has been created with all assets requiring vuln management per CSP	- All Public/internet facing resources are identified along with potential misconfigurations - All OS images have been scanned/assessed for a point in time vulnerability status report - All Cloud Accounts/Tenants/Organizations etc have been scanned/assessed for a point in time vulnerability status report	- Vulnerability management using built-in tools of Cloud provider, e.g. Azure or Google Container Registry image scanning, Amazon Inspector etc is run at various point during an application lifecycle - Severity of events from the CSP vulnerability management tool is defined to only action relevant issues	- Vulnerability Scans are collected & monitored from a central location - Agentless vulnerability management approach from all CSPs in a central location - Results from vulnerability scans have attribute actions and are assigned in an actionable way to the correct stakeholders in a unified way. This could be Jira, this could be Slack, this could be something custom. - The resolving vulnerability process/method should be auditable and reportable in such a way as to ensure organization SLAs for services is maintained.	- Use context (production, Internet facing, privileged cloud role) to determine criticality of vulnerability to business - Automated vulnerability management/patch cadence - Enforcing Golden Compute Images/OS baseline images for machines per CSP (AMIs, VM Images, etc.) - Use of centralised posture management capability to monitor and alert on vulnerabilities across all CSPs
25		Cloud service secure baseline configuration	- Understand the services offered by the CSP.	- Maintain a catalog of all company certified services. Review periodically for changes from the CSP.	- Disable regions and services that do not meet regulatory or compliance requirements, or create unmitigated residual risk across all CSPs. - Understand the field of use for each service, especially as they relate to data governance.	- Review each cloud service against pillars of the CSP recommended Cloud Architecture framework. - Document the secure baseline configurations for each service. - Deploy a least privilege model for using sensitive services/actions/resources. Avoid creating toxic combinations of access (i.e. allowing the same principal unchecked access to update DNS and issue TLS Certificates)	- Use cloud configuration tooling in the Infrastructure as Code pipeline & cloud runtime to alert and/or enforce the secure baseline configuration for every service. - Build autoremediation for high confidence issues. - Manually verify and then trigger scripts for medium/low confidence findings to avoid remediation of false positives, especially in production environments. - Automate the change record process that will document the before and after state of each remediation activity.
26
27	Respond	Incident Response	- Incident Response Plans per CSP exists and are documented - Monitor behaviors and system in a coordinated way - Identify the risks associated with a security event. Develop a Cyber Risk Management Strategy framework to understand achieveable RPO/RTO.	- Incident management teams have been defined. This should also include executive, legal, communications teams, etc. and not just "tech" team - Document log retention policies for all CSPs e.g Archive/Purge old logs. Understand the impact to IR teams due to missing logs or having to recall archived logs. - Document incident category per CSP - All notification from detection systems are investigated	- All incidents are contained, mitigated, and assessed for impact - Define Incident Response Policy to determine the severity an incident would require, relevant roles, and who would take specific roles and responsibilites during an incident - Define Incident Response Plans development to match Incident category - Incident Runbooks have been created for core services. Removal of resources based on incidents is defined - Institute Incident management tool (like notification system) for on time escalations	- Automation of user account deactivation is in place. Runbooks created for services that the organization uses. - Document all external service accounts that have access to the customer's systems. Develop automated 'panic button' to disconnect any compromised 3rd parties connected across all of the customer's cloud infrastructures. - Incident Response Plan uses cases are tested periodically for efficiency, accuracy of documentation.	- Automated collection of forensic evidence and host isolation
28
29	Recover	Recovery Planning	- Every application owner understands and adheres to their respective RPO (Recovery Point Objective) & RTO (Recovery Time Objective) - Recent Recovery activity communication exists for both internal and external stakeholders where relevant	- Define RTO & RPO per application workload and application owners	- A disaster recovery plan should be outlined & documented for each CSP. - A disaster recovery trial run is conducted periodically to ensure accuracy of documentation and accuracy of system capability to recover within RTO, RPO SLAs - Backups and redundancy are in place per CSP - Backups are tested periodically & documentd to measure against their respective RTO, RPO timeline	- Disaster recovery plans in place across regions - Tabletop or Test RTO timelines. Use diverse archecture patterns to develop business continutity plans when predicted RTO exceeds tolerable levels. Maintain a warm site for applications, either in a different CSP or isolated from the main application in the same CSP, for Business Continuity if the estimated RTO extends beyond what is tolerable by the business.	- Periodic Live Fire / table top exercises are conducted internally to test efficiency of processes. Test both Business Continuity and Disaster Recovery scenarios.
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100