This is only a mere personal collection of similar requirements for the finance, car, and medical industries based upon regulations depicting requirements on Cloud & Datacenter operations. These tables are just copy-pasted from publicly accessible resources and will change over time when it comes to their recommendations and legislative criteria. Use this table as just a hint and initial guidance on what to think of when it comes to the level of risk and controls you need to implement based on regulatory demands. (and to identify how the legislator might write hard guidelines for you to comply with.)
I've updated the tables for "Teamsdagen"-presentation (21-09-2022) for you to consume freely. This table is a personal collection of mine outside the scope of my employment and comes AS-IS.
Legislative Example
An example of "compliance regulation" in the form of "recommendation" to regulation bodies or instances... These recommendations intend to clarify the EU-wide supervisory expectations if institutions intend to adopt cloud computing, so as to allow them to leverage the benefits of using cloud services while ensuring that any related risks are adequately identified and managed.
3.2.3. Use of third-party providers 7. Without prejudice to the EBA Guidelines on outsourcing arrangements(EBA/GL/2019/02) and Article 19 of PSD2, financial institutions should ensure the effectiveness of the risk-mitigating measures as defined by their risk management framework, including the measures set out in these guidelines, when operational functions of payment services and/or ICT services and ICT systems of any activity are outsourced, including to group entities, or when using third parties. 8. To ensure continuity of ICT services and ICT systems, financial institutions should ensure that contracts and service level agreements (both for normal circumstances as well as in the event of service disruption — see also Section 3.7.2) with providers (outsourcing providers, group entities, or third party providers) include the following: a) appropriate and proportionate information security-related objectives and measures including requirements such as minimum cybersecurity requirements; specifications of the financial institution’s data life cycle; any requirements regarding data encryption, network security and security monitoring processes, and the location of data centres; b) operational and security incident handling procedures including escalation and reporting. 9. Financial institutions should monitor and seek assurance on the level of compliance of these providers with the security objectives, measures and performance targets of the financial institution.
Governance
| Control | Workloads | Material Workloads |
|---|---|---|
| Organisational Considerations for the Management of CSPs | The initiative should design and implement a suitable governance body and roles, where appropriate with representatives of both the CSP and the company. The governance body should be empowered to oversee adherence to SLAs, review KPIs and KRIs, incidents, security incidents, and other relevant matters to the risks associated with outsourcing. This governance body should meet periodically, the frequency determined by the materiality of the arrangement. | Where critical services have been outsourced representation on the governance body should be of appropriately senior technology and business representatives. |
| It is recommended that metrics provide a complete view, both where controls are owned and operated by the initiative or the CSP. Interfaces to internal governance bodies should also be considered for company-owned controls. | A single point of contact from the CSP should be formally identified and given a sufficient mandate. | |
| Execution of oversight of cloud outsourcing arrangements requires a specific skill-set. Initiatives should be mindful that when outsourcing that key staff and roles are identified and that their knowledge is kept up to date by training or other methods. | A defined escalation procedure should be put in place for both the CSP and the company to use. | |
| Initiatives should consider creating a specific role to execute oversight of cloud outsourcing arrangements. | ||
| When performing due diligence activities, or during Audits and regulatory inspections it is recommended to use appointed individuals and a central point to coordinate activities between the CSP, the company, and the auditor. | ||
| Any incremental changes to outsourcing controls should be managed via the governance forum. | ||
| Control Assessment & Monitoring | Prior to embarking on any cloud outsourcing arrangement a thorough technical risk assessment of key controls should be performed based on the use cases. | Initiatives should assess their existing controls assurance framework for the suitability of managing cloud outsourcing. Key procedural controls must be identified, mapped and effectiveness thresholds defined. |
| Where possible the initiatives should ensure that a control failure triggers automated response and notification. | Establish Management Information and dashboard material for reporting on control assessments. Define an appropriate oversight and escalation model to execute remediation activities that take into consideration both the company and CSP-owned activities. | |
| The initiatives should consider leveraging the controls available in the cloud environment to enforce consistent security standards and baselines as well as automated remediation where possible. | Initiatives should consider the use of analytics with machine learning (ML) and other best-in-breed technologies to develop baselines for compliance checks to highlight and avoid non-compliance. | |
| Billing | It is recommended that the initiative have a centralized governance structure to manage master subscriptions and control how that is provisioned for specific workloads. | Monitoring of key services based on SLAs should be in place and regularly reviewed by the initiative to identify usage anomalies, particularly where compound SLAs exist. |
| Ensure that all assets in the cloud are identified, have clear ownership assigned, and are rated for their asset classification. | Protocols should be in place with the CSP to prevent cessation of services based on quotas being exceeded. | |
| Do not use the CSP's master account to centrally manage the costs, create sub-accounts that are aligned to the finance structure of the company | ||
| Ensure there is training and educational material for users of the cloud environment which is tailored to help them understand the best adoption methods and prevent wasteful use of cloud resources. | ||
| Work with CSPs to create usage reports at regular intervals which are made available to account owners and for presentation to appropriate governance forums. Ensure that these reports are consumed in line with technology financials and internal billing standards. | ||
| Define quotas for each sub-account and put in place alerts or triggers for accounts once a threshold of spending has been reached | ||
| Cloud usage total cost of ownership should consider both software licensing, compute and storage costs, but also maintenance and corporate/enterprise support. | ||
| Organisations should ensure that sufficient funds are available to cover licensing costs, and that controls are in place to prevent key services from being shut down. | ||
Engineering Requirements
| Control | Workloads | Material Workloads |
|---|---|---|
| Cloud Architectural Reference Solutions & Practices |
It is recommended to use the company's existing technology architecture governance to set standards and approve cloud patterns but the company should leverage the CSP expertise for Cloud design patterns. Initiatives should document the implementation and chosen architectures. | |
| The company should review business and technology requirements when developing cloud reference architectures. Business Requirement Documents (BRDs) and System Requirement Documents (SRDs) should be published and periodically reviewed. | ||
| Where end users (e.g. the initiative using SaaS) are able to select and deploy these architectures directly an appropriate approval workflow should be in place. | ||
| A user role should exist which allows designated staff to develop and maintain cloud architectural patterns. Access rights to create non-standard architectures should be strictly controlled. | ||
| Initiatives must consider adopting the commonly available architectural references in the area of availability and resiliency, security, authentication, performance, operations, and management. | ||
| The security architecture deployed in the Cloud environment takes into account the risks associated with Cloud connectivity, logical segregation, and public access. | ||
| Virtualisation, Containerisation and DevOps (or DevSecOps) | The initiative should define a standard for containerization and DevOps methodologies. While the CSP may provide the tools for the initiative to manage and administer containers, the initiative is responsible for authorizing which ones are available for use. | If the source code repository is hosted at the company, the binaries should be compiled on-premise, and only the source code artifacts shall be versioned, (signed is optional yet recommended) and sent to the CSP. |
| Roles and responsibilities between the CSP and Initiative for the container strategy must be agreed upon and documented for operational references. Ensure that source code repositories are defined and managed at both the Initiative (and/or at the company) and the CSP | Integrity checks should be performed on container templates and any inconsistencies made detectable prior to use. | |
| The initiative should carefully define its user access and authentication strategy, particularly for administrative users who have the ability to manage and change these fundamental tools supporting its cloud ecosystem. | The initiative should have the appropriate checks to prevent production data from being used during testing in non-production environments. The use of synthetic data is strongly recommended. Masked data should be used as a last resort. Production data must not be used. | |
| The container images should contain a standard set of configurations that are designed and signed off by the initiative. Standards should be created for both production and non-production images. | ||
| The ability to add security and vulnerability patching where applicable to the containers and virtual machine are done to the base image in a controlled manner and adheres to the standard change management process. | ||
| Ensure that changes to the container images are fully audited. | ||
| The CI/CD pipeline should be configured to perform the correct actions and activities against the designated environments. This could be to both containers and virtual machines. | ||
| Security and vulnerabilities should be validated and tested using automation to perform testing. | ||
| Align any code deployment and configuration changes to the company's change management process. | ||
| Resiliency in Cloud Architectures | Initiatives could maximize the redundancy by designing and distributing their production workloads across the available clusters within each region. (depending on availability classification and regulatory needs) | Initiatives should design their workload to leverage available functionalities such as containerization and auto-scaling to automate the swift recovery of their services. |
| Initiatives should implement automated health checks and monitoring to detect service faults or outages in the cloud environment. | Initiatives should also adopt fault-tolerant techniques such as Retry, Circuit Breakers, and Bulkhead Isolation in the design of their workload which is sensitive to faults or failures. | |
| Where possible, initiatives should design their workload and applications to automatically handle known exceptions or failures to ensure their cloud service can recover swiftly in an event of an incident. (depending on Availability classification) | For workloads that are sensitive to latency, Initiatives should implement the workload in the region that is closest to their customers or consider options to optimize customer experience (such as content delivery networks) while maintaining regulatory compliance. | |
| For workloads that require higher availability, initiatives should consider distributing the workload across multiple regions. At minimum, initiatives should make plans to recover their services in a different region to mitigate against the regional service outages. | ||
| While data within each region is automatically replicated across the available clusters, initiatives should consider strategies for replicating data across regions to ensure data availability in an event of failures or service faults within each region. | ||
| Initiatives should put in place a contingency or resumption plan for its critical services in an event of a total outage of cloud services. Some of the options that the initiative should consider include implementing critical workload on two different CSPs or retention of on-premise capabilities for added resiliency. | ||
| Network Architectures | Initiatives should implement measures to secure the cloud and on-premise environments to mitigate contagion risks (lateral movement). Controls should be implemented between the cloud and the company's on-premise environment and at the ingress/egress points to mitigate against such threats. | Dedicated network connectivity should be implemented from the company to the cloud environment, and remote administrator access to the cloud environment over the Internet should be restricted. |
| It is considered best practice for administrative interfaces to be on a segregated management network that is not accessible from the operational subnets. | The controls in the cloud environment should be equivalent if not more secure than the company's on-premise environment regardless of information class. | |
| Network access and security controls such as firewalls, IPS, advanced threat protection, and web proxy should be implemented to secure the on-premise environment from the cloud. | Initiatives should consider rerouting the cloud traffic through the company's on-premise environment to benefit from existing on-premise security controls. | |
| The initiative and the company should have network access and advance threat protection controls implemented in the security network segment to filter and secure access to the cloud environment. | Initiatives should ensure that a dedicated security network segment is set up to control all ingress and egress traffic from the cloud environment. | |
| (Non-zero trust environments) VPN or direct network connection should be implemented to secure the traffic between the cloud and on-premise environments where possible. IP source and destination restrictions should also be considered. | Micro Segmentation should be considered when using Software Defined Networks. | |
| Initiatives should monitor and control the access, where possible, to their cloud environment. | All internet traffic should be routed through a dedicated security network segment. All other network segments in the cloud environment should not have direct access to the Internet. | |
| Initiatives should implement an internal monitoring control to detect the unauthorized adoption of cloud services. | ||
| Initiatives should consider network segregation of workloads based on their type (production, test, development) and purpose (user, server, interface, critical infrastructure segments). | ||
| Initiatives should consider the implementation of application layer DDoS attack protection and web application firewall to secure the cloud-based application as required. | ||
| Initiatives should regularly review firewall rules and access lists, especially after network or architectural changes that may make certain rules redundant. Rulesets should have defined owners. | ||
| Cryptography & Key Management | Keys should be rotated regularly in accordance with the industry best practices. Certificate revocation should also be tested from time to time. | Initiatives should generate their own unique cryptographic keys and secure the keys in the Cloud environment. (no default keys but at minimum customer configured) |
| Detailed policies and procedures should be in place to govern the lifecycle of cryptographic material from generation, storage, usage, revocation, expiration, and renewal, to archival of cryptographic keys. (Crypto-periods) | At a minimum, the cloud-based HSM or SSM should meet the FIPS 140-3 and Common Criteria for cryptographic products. | |
| Backups of cryptographic material should be considered. These should ensure that the keys cannot be compromised and are subject to strict oversight and segregation of duties principles. No one key custodian should have access to the entire key. | Where encryption is used, the encryption keys should be stored separately from virtual images and information assets. (retrieve on use - keep in memory, not stored on non-volatile disk-space) | |
| Never re-use private keys for other purposes. Generate new key material for each engagement. | Initiatives should consider HSM as a service or in special use-cases, deploy their own HSM for particularly critical workloads. | |
| Carefully designed processes including appropriate key ceremonies should be in place if cryptographic keys and SSL private key containers belonging to the company need to be introduced into the CSP environment. (BYOK/HYOK scenarios) | ||
| Offline storage in a suitably secure and fireproof environment should be considered for critical cryptographic material, the loss of which may materially impact the company's ability to recover data or operate. This should be included in disaster recovery planning scenarios. | ||
| The company should leverage systems backed by FIPS 140-2 Level 3 validated HSMs (or equivalent) to secure their cryptographic keys, and access to management of the key material and HSMs should be secured with multi-factor authentication. | ||
| Access to the HSM or Key-Management Services should be secured using multi-factor authentication. | ||
| Encryption | Sensitive data including data backups should be subjected to appropriate encryption controls both in-motion and at-rest. | Stringent control should be exercised over cryptographic keys to ensure that secret keys are generated and managed securely, for instance within a Hardware Security Module (HSM). |
| Details on the encryption algorithms, corresponding key lengths, data flows, and processing logic should be appropriately reviewed by subject matter experts to identify potential weaknesses and points of exposure. | Details on the location, ownership, and management of the encryption keys and HSM should be agreed upon between the initiative and the CSP. The initiative should take into consideration the need and ability to administer the cryptographic keys and the HSMs themselves. | |
| Colocated HSMs and other cryptographic material should be stored on segregated secure networks where access is carefully controlled, and are not accessible from subnets used by CSP’s other customers or for everyday staff access. The contents of the HSM as a Service should only be reachable by the initiatives tenant and protected using tenant isolation techniques. | When using a Content Delivery Network, ensure there are appropriate controls in place for the encryption key and certificate management. At the very minimum use validated certificates from the company-approved suppliers to ensure identity controls and key management operations are in place. Secure certificate management protocols must be adhered to. | |
| Encryption keys used for the encryption of company data should be unique and not shared by other users of the cloud service. | Carefully designed processes including appropriate key ceremonies should be in place if cryptographic keys and private key containers belonging to the company or the initiative, needs to be introduced into the CSP environment. | |
| Never share or use wildcard or multi-name certificates. Limit the common-name/alternative name to the scope of service delivery and create new certificates of other engagements. | ||
| Other guidance on encryption requirements can be retrieved from the security team | ||
| Tokenisation | Careful risk assessment and evaluation should be performed on the tokenization solution to identify unique characteristics and all interactions and access to the sensitive data. | |
| The CSP must not have any means to restore the tokens to the original data values such as access or control over the tokenization system or tokenization logic. | ||
| Systems that perform tokenization should remain under the direct management of the initiative. | ||
| Identity and User Management | For each Cloud deployment there will be at least one master or global administrator account. This account shall be under lock and key and only be used in case of disaster recovery or other purposes/exceptions. Regular accounts / Identity and Access Management must be in place leveraging the user rights that come with these accounts; instead. | |
| Identity and Access management should be a paramount consideration when performing a cloud outsourcing arrangement and should incorporate both technical and business user access management. A clear business owner should be identified to ensure accountability, and ownership of each role defined. | ||
| The company's Identity and Access management policies and standards should be applied in full in the CSP for Production and UAT environments used by the initiative to ensure consistency. | ||
| For end users, especially where corporate users are concerned, federation of Active Directory or other federated "Security Assertion Markup Language" credentials should be used to allow the company's existing processes and infrastructure to be leveraged. | ||
| Where federation is used, or another cloud-based directory leveraged, the directory synchronization model, security requirements, and redundancy controls for any synchronization tools should be reviewed and approved by the company's technology architecture governance committee. | ||
| Where access is via the internet Conditional Access, MFA, and IP source restrictions are strongly recommended. | ||
| Where identity and access management assets reside in the cloud, strategies should be created and tested for migration or exit planning. | ||
| Scenarios that address recovery from a Cloud directory compromise and synchronization with on-premise platforms should be added to disaster recovery and cyber security playbooks. | ||
| Integration with personnel system directory tools should be considered to ensure timely disabling of user's primary access, or to trigger a review of access rights for potentially toxic combinations. | ||
| User Access Administration should be subject to strict segregation of duties and maker/checker controls, especially where the CSP has access to or is managing systems or software. Changes in role access rights should be regularly reviewed by an independent assurance function or the role’s owner. | ||
| Access and usage of service, generic, and administrator accounts should be controlled via appropriate privileged user access management controls and activities logged for review. | ||
| Where development, QA, and production environments exist in the Cloud, access should be strictly controlled. Developers and Testers should not have any write access to production environments. Production support should have limited read access in accordance with their responsibilities. | ||
| Privileged Access Management | Users with privileged system access should be clearly defined and subject to regular user access reviews. | There should be a mechanism in place to detect when unauthorized accounts are created that can access criticality-rated information assets. |
| Privileged User access should be clearly tracked and reported, and be linked to an agreed and approved change request when related to the company data. Note it is not always necessary for the CSP to disclose change requests to the company | Multifactor authentication should be mandated for privileged access to material workloads. | |
| The Privileged User Administration function should be subject to segregation of duties and separate from any user administrator function. | ||
| Privileged User Access should be in line with the company policies on Privileged Access Management. There may be high-risk situations where a break glass procedure is required and dual controls circumvented. These situations should be defined in advance and subject to rigorous after-the-face reviews to provide assurance that no erroneous or unauthorized changes were introduced. | ||
| Multifactor authentication must be implemented and adhered to for all privileged access. | ||
| Administrative Remote Access | Detailed documentation of all systems remote access procedures including security controls management. This documentation should be regularly reviewed to ensure accuracy and currency. | Initiatives should implement a direct private connection from their data center to the cloud environment, and restrict all direct remote access to the cloud environment over the Internet (when considering IaaS and leveraging existing on-premise infrastructure), or apply Zero-Trust Conditional Access. |
| All interfaces to cloud computing infrastructure should be consistent where possible so that remote access controls are uniformly controlled. | Where Internet access to the CSP cloud management console cannot be disabled, initiatives should implement a complex password and multi-factor authentication for the login account. These accounts should be limited to emergencies only and not used to support day-to-day operations. The MFA secret should be stored with the credentials. | |
| These interfaces should provide discrete segregated data flows to ensure that there is a secured and auditable method of accessing systems and data. | As the administrator account to the CSP cloud management console cannot be locked out, initiatives should monitor for unauthorized access to the accounts or password guessing attempts to break into the account. Initiatives should consider changing the password periodically (biennially). (Min 32 chars random string azAZ09!"#%&.-_) | |
| Remote access security measures such as two-factor authentication, and Virtual Private Network (VPN) encryption should be implemented. | The company and initiatives should consider restricting access to certain parts of the network by remote access users. Remote Access and Jump boxes should also be considered for additional security. | |
| Where possible remote access network traffic should have a defined source and destination. | ||
| End User Computing device controls should be considered, for instance, access only from recognized hardware using machine authentication, or virtual desktop interfaces to reduce the risk of malware contamination or unauthorized access. | ||
| Privileged remote access should only be permitted by authorized exception or break glass procedures and be time-bound. Privileged remote access is inherently risky and must be strictly controlled. | ||
| All privileged remote access is to be reviewed for appropriateness by independent and qualified personnel. | ||
| Data Loss Prevention | The initiative should review their local information asset classification framework compared to the company controls and ensure that those encompass considerations for their cloud usage. The initiative may wish to consider enhanced controls for high-value information assets that reside in the cloud such as strong encryption, tokenization, and logical segregation. | The initiative should perform periodic reviews of the users that are able to approve exceptions to DLP policies. |
| Where data in-transit crosses cloud deployments, and data-loss-prevention techniques used are not information-centric, content inspection technologies should be deployed to identify and, where appropriate, quarantine information assets that contain personal data or customer information. Policies containing the identification criteria should have defined owners and be subject to periodic review. | The initiative should monitor the ingress and egress points for the use or adoption of unsanctioned cloud services or shadow IT to support internal business processes or operations. | |
| Where cloud services are accessible via the Internet, data loss prevention controls such as cloud access security broker should be implemented to monitor and control the access of the information. | Data loss prevention controls should be implemented to secure access from the internet to the cloud services, and control downloading and extraction of information from the cloud services. | |
| The initiative should analyze changes in the use of the cloud services to detect suspicious and anomalous activities in the cloud environment and unusual access to the data. | ||
| The initiative should have a Data Loss Governance and risk management framework defined which should integrate with its capabilities in the cloud. Templates and patterns for sensitive data should be defined, and metrics regularly reviewed. An appropriate consequence management framework should also be defined and agreed upon between the CSP and the initiative. | ||
| Source Code Reviews | Guidelines for secure by design software development should be clearly defined and all developers trained on these approaches. Common considerations include coding approaches to ensure that OWASP Top 10 security risks do not occur and that applications are fail-safe in the event of unexpected behavior. | For source code relating to material systems it is recommended that enhanced reviews including manual source code review are performed. |
| Content version controls and strict processes for the migration of source code from one environment to another should be clearly defined as part of a release management process. | The source code should be updated and tested regularly for new security and vulnerabilities. | |
| Segregation of duties can be accomplished in an automated fashion by introducing a CI/CD pipeline for controlled testing across the different environments | Where source code is used for any material purposes, it is strongly recommended to perform a risk assessment to determine if it is necessary to compile binaries within the company's own networks and copy the binaries into the Cloud. The recommendation is to compile on the company's network and push the artifacts to the cloud or use specialized approved services (Azure DevOps is pending review and not approved yet). | |
| Access to source code repositories and privileged access to the development and testing environments are restricted to only specific authorized individuals. | ||
| Unencrypted customer data should not be used for testing in the Cloud environment. Test data must be de-personalized before it is transferred into the CSP’s environment. | ||
| The processes supporting release management should ensure that source code which has been subjected to reviews (automated or manual) and cannot be tampered with by the author after it has been reviewed. | ||
| Automated source code applications should be regularly updated and reviewed to ensure the currency and accuracy of their findings. | ||
| Penetration testing | CSP penetration test reports can be used to gain assurance over the security of underlying systems but the scope should be reviewed to fully understand what has been tested to ensure that the final testing encompasses all of the systems involved in the provision of the service(s). | The initiative should consider using a Red Teaming approach to testing the CSP's environment. It is also recommended that testing is performed on live systems subject to safety protocols to prevent any disruption of service. |
| The tests should take into consideration threats that are unique to cloud computing, such as hypervisor jumping and weak application program interfaces. | The pentesting scope should include application upstream and downstream dependencies, as well as any centralized release management or source code systems that the application utilizes. | |
| Testers should be aware of typical security issues that are particular to cloud environments and virtualization in order to have an understanding of the types of issues that may exist in such an environment. | ||
| Initiatives should engage the CSP prior to engaging PT to understand any technical limitations of testing and ensure awareness. | ||
| All vulnerabilities should be risk assessed, tracked and managed/treated appropriately. | ||
| Where the vulnerability is on a system not managed by the initiative, there needs to be an agreed-upon remediation SLA that the CSP aligns to and discloses to the company and the initiative. | ||
| In case responsibility for penetration tests on CSP side (i.e. in a SaaS model) proper governance over this program should be in place. The initiative should ensure that all weaknesses and vulnerabilities are identified, risk assessment is conducted and gaps are closed with priority adequate for specific risk rating and in agreed timelines. Closing gaps | ||
| conditions may be regulated by the service contract between CSP and the company. In case of gaps that cannot be mitigated an exception process should be triggered. | ||
| Security Monitoring Events | Secure and robust security logging infrastructure should be leveraged. Consolidation of logs to a centralized system should be in place to ensure that the integrity and availability of the logs are maintained. | Appropriate monitoring infrastructure such as a Security Incident and Event Monitoring (SIEM) system should be in place to provide automatic analysis, correlation, and triage of security logs from the various monitoring systems. |
| The centralized log server should be secured and segregated from the operational environment to prevent unauthorized or accidental purging of the log information. | Initiatives should identify specific cloud security incident scenarios and develop specific correlation rules to detect such events. Where necessary, log parsers and correlation rules should be customized for such events and incidents. | |
| Logs should be streamed back to the company for security-incident and event correlation. | An approach to leverage the data from the CSP's SIEM architecture into the company's Intrusion Detection capability should be considered if possible. | |
| Initiatives should consider the use of security analytics with machine learning capabilities to develop a baseline to detect potential anomalies in the cloud environment. | ||
| Initiatives should ensure that CSPs have snapshots of critical databases or systems of record for disaster recovery/business continuity (and based on need bases, stored outside the Private Cloud boundary in a different account) | ||
| Securing logs and backups | The initiative shall ensure that the application development teams shall not log customer identifying data (references as hashes or sessions are allowed) | Snapshots should be considered to enhance RPO capabilities, particularly for critical databases or systems of record. These should be timed ahead of key activities such as cut-off times or End of Day batch procedures. Snapshots are not a replacement for backups or cold storage. |
| Initiatives should establish requirements for forensic investigation including how to ensure that log data can be acquired in a streamlined sound manner. | ||
| Initiatives should have the appropriate access control in place for backups and log data. | ||
| Initiatives should consider the contents of backups and encrypt sensitive data where appropriate. | ||
| Initiatives should give due consideration to the management of encryption keys used for backup purposes. | ||
| The capability to recover data in a usable form should be regularly tested by the initiative. Such restoration tests must be conducted securely to minimize any risk of data leakage. | ||
Operations
| Control | Workloads | Material Workloads |
|---|---|---|
| Change Management | Change management procedures should be mutually agreed upon between the CSP and the initiative. Such procedures should be formalized, and include change request and approval procedures, as well as a reporting component. | Initiatives should ensure that there is a process in place and scenarios defined where the CSP is required to notify in advance of changes to critical services. Where appropriate, initiatives should consider opportunities to test the deployment before those changes are implemented in their environment. |
| Procedures for emergency and standard changes should be agreed upon, including the roles and responsibilities, and defined change windows for patching and software releases. | Change management governance should be incorporated into regular Service Level Management meetings. | |
| Where Dev(Sec)Ops practices are being used, conditions and scenarios that allow automated testing and releases should be defined. It is important to ensure that there is a full audit trail, the record of the changes, and evidence of pre-approval. | Initiatives should review the change management procedures of the CSP, which should be independently assessed in line with ISEA 3402, SOC2 or other controls assessments. | |
| Initiatives should ensure that CSPs have well-defined change windows, testing and rollback plans, and an internal signoff procedure for any material changes that need to be implemented by the CSP. This can be evidenced via independent control testing. | ||
| Initiatives should consider conducting post-change testing where critical business functions may be impacted, including documented and evidenced test cases. | ||
| Configuration Management | Roles for the configuration of the cloud environment should be clearly defined, and segregation of duties should be considered for the design of the cloud roles for both the initiative and CSP. | Initiatives should create environmental baselines, establish a process to review the baselines periodically and monitor deviations from the baselines. These metrics should be reported at the Cloud governance forum and to appropriate service owners. |
| At a minimum, the infrastructure, security, and application roles should be segregated to prevent environmental changes which would allow the security controls to be bypassed. | Where possible, initiatives should implement auto-remediation to revert the environment to the baseline configurations where strict enforcement of the baselines is required. | |
| Privilege for the infrastructure changes should be managed centrally, and the configuration of the environment should be closely monitored for unauthorized changes. | ||
| Initiatives should consider establishing standard server images for consistent and secure creation of new servers | ||
| Key environment changes should be monitored and automated alerts should be triggered to alert the security or the infrastructure team. | ||
| Initiatives should consider auto-remediation for high-impact changes such as the configuration of internet gateways or server images. | ||
| Events Management | Initiatives should ensure there is a framework for event categorization, impact, responsibility, and the actions taken to address them. | SLAs for critical events should be established between the initiative and the CSP. This should be done in accordance with an escalation (and responsibility) matrix to notify the appropriate parties. |
| Appropriate detection mechanisms should be in place at the network, system, and application level to analyze events that could affect the security and stability of the cloud service. | Events that have been rated as material should be immediately visible in network or technology operations centers so that they can be responded to in a timely manner. | |
| Security and technology events and the various levels of severity should be appropriately defined and ownership agreed between the company and the CSP. | The initiative should define playbooks for recovery scenarios along with key roles and task ownership. | |
| Initiatives should consider the use of automated ticketing upon the detection of an incident to improve turnaround for the response team. | ||
| Incident and Problem Management | Criteria and performance requirements i.e. SLA for the escalation, notification, containment, and closure of relevant security and technology incidents should be appropriately defined and agreed upon between the initiative and the CSP, especially where regulatory instruments such as Directives and Notices stipulate timelines | A Computer Emergency Response Team (CERT) or Security Incident Response Team (SIRT) should be in place to provide timely responses to security incidents. Coordination between the CSP and the company's teams should be formalized. |
| Lessons Learned and other learning points captured from past incidents as knowledge articles for continuous improvement of the process. | Appropriate security systems and measures, such as network intrusion detection/prevention systems (NIDPS), web application firewall (WAF), DDoS mitigation, and data leakage prevention systems, should be deployed at strategic locations to detect and mitigate security breaches and ongoing attacks. | |
| Access to appropriate reports on relevant incidents and root cause analysis should be agreed upon between the company and the CSP. Where the CSP has commercial, security, or intellectual property reasons to not disclose such reports directly to the company, the use of a mutually acceptable independent 3rd party can be agreed upon. | Based on the materiality of the outsourcing arrangement, integration into a Security Operations Centre (SOC) and/or Technology Operations Centre (TOC) operating on a 24x7 basis should be strongly recommended to provide active monitoring of security events, technology incidents and ensure timely escalation and management of issues. | |
| CSP should provide reasonable access to the necessary information to assist in any company investigation arising due to an incident in the cloud, to the extent that it does not contravene any other legal obligations. | While it is recognized that it is usually the company's responsibility to identify a relevant incident under Notice 644, there are situations where systems or applications designated Critical may be fully managed by the CSP, particularly SaaS or white-labeling. In these situations, a contractual requirement should be included to ensure notification to the company as soon as possible after the detection of a | |
| Incidents that have been considered to have a material impact on the company should be subject to formalized post-incident reviews and problem management. | relevant incident. This as the company is then required to notify relevant authorities usually within 1 hour of receiving this notification. The CSP should include as much information as possible in this notification to allow for the required regulatory submission. If all data points are not available at that time the CSP should ensure these are delivered within a reasonable timeframe, which should not exceed 24 hours after the original notification. | |
| Where commonly occurring incidents become formally recognized as systemic issues, Problem Management should be put in place to ensure that appropriate remediation is identified and implemented. | Review and testing of the incident response plan should be conducted on a regular basis by the CSP and involve the company where appropriate | |
| Metrics on incidents and problem tickets should be regularly reviewed and discussed at the Cloud governance boards. | ||
| Capacity Management | The initiative should define a monitoring and metrics strategy with the CSP and leverage the monitoring capabilities provided by the CSP and define appropriate metrics for its applications. | Automated increase for quotas for material workloads should be considered and thresholds regularly reviewed for appropriateness |
| The initiatives technology operations team should monitor and review capacity utilization and review where capacity may be at risk. | the company and the initiative needs to ensure that business strategies and requirements, including special events such as index rebalancing, are taken into consideration when reviewing the capacity of their workloads. | |
| Planning for upgrades, and enhancements including funding requests should be regularly discussed in internal governance forums. | ||
| Patching and Continuous Vulnerability Management | The initiative should maintain an inventory of the software used in the cloud environment, and track the vulnerabilities announced by the respective technology vendors. This should be aligned with the company standards where applicable/possible. | Initiatives should conduct a periodic assessment to identify new vulnerabilities and schedule the patching activities to remediate the vulnerabilities in accordance with their criticality. |
| The software inventory should also be used to track the software life cycle so that informed decisions can be made to replace or have mitigating controls. | In events where the patches cannot be applied to address the vulnerabilities promptly, Initiatives should consider the use of security controls (e.g. network access control, intrusion prevention systems) to mitigate the risk of exploitation. | |
| Where possible, initiatives should containerize or feature their applications in the cloud environment to facilitate prompt patching while minimizing the impact on the cloud workload. | Initiatives should ensure that there is a robust process in place to review and remediate any vulnerabilities in a timely manner and prioritize the vulnerabilities of standard workloads | |
| Where possible, automated and continuous patching or ever-green patch management shall be employed to reduce the time to live between patch release and deployment. | An exception process needs to be created for any vulnerabilities that cannot be remediated. | |
| Initiatives should work with the CSP and understand capabilities in their offerings that would help best with vulnerability and patching management. | ||
| The CSP should be able to demonstrate the status of their compliance with published vulnerabilities and their ability to patch when required. | ||
| Collaborative Disaster Recovery Testing | The CSP should develop disaster recovery and business continuity plans and where appropriate share the plans with the company (this is usually not possible with big providers but an explanation of how and expectancy management is key). | The initiative should develop disaster recovery plans for its assets in the Cloud, and test these at least annually. Tests should be validated for accuracy, completeness, and validity of recovery procedures. |
| Ensure that all changes in the computing environment are reflected in the disaster recovery plan and that all facilities are available. | The initiative and CSP personnel involved in disaster recovery procedures should be aware of their responsibilities and capable of executing them. These should be tested at least annually. | |
| There should be a communications plan or an automated call tree that covers both CSP and the company. | CSPs should obtain necessary certifications for disaster recovery (e.g. ISO27001 and validated against ISO27018) and their processes should be audited by independent third parties with such audit reports made available to the company. | |
| Ensure that the company's Crisis Management Team (CMT) is fully aware of the CSP's recovery plan. | When performing DR testing with the CSP, consider doing spot checks or testing on short notice to validate their level of readiness for an actual disaster event. | |
| Ensure that any deficiencies noted during testing are recorded, and the implementation of corrective actions is monitored via the appropriate governance bodies. | ||
| Various disaster recovery scenarios including both component failure, full site loss, and partial failures should be incorporated into the testing plan. These scenarios should be tested according to a strategy defined by the bank in line with its business continuity policy. | ||
| The scalable and redundant nature of cloud outsourcing arrangements allows for more rigorous testing, including the failure of active-active configurations. It is recommended to regularly test these capabilities and to keep services failing over for an extended period of time to validate operational stability. |