Security and Compliance Blogs
Security & compliance of business operations are critical in this age of rising cyber threats, increasing compliance regulations, and rapid technological change. SAP customers, partners and SAP employees put great effort in to meet those risks and work towards effective security outcomes and cyber resilient systems. We benefit from each others' challenges and successes to protect the business processes and services we all depend on. Join us here for blog posts and thought leadership regarding the security and compliance of SAP software and cloud services, as well as secure development, deployment, and operational practices, whether on-premise or cloud.
cancel
Showing results for 
Search instead for 
Did you mean: 
npbrennan
Employee
Employee

nsa-cisa-cloud.png

By Niall Brennan and Jay Thoden van Velzen, Office of the CSO, SAP Global Security & Cloud Compliance

On March 7th, the US National Security Agency (NSA) published 10 strategies for securing cloud landscapes. Each strategy was detailed in a separate Cybersecurity Information Sheet (CSI), six of which were crafted jointly with the Cybersecurity and Infrastructure Security Agency (CISA). Collectively, these 10 strategies are an important contribution to cloud security, especially since the recommendations are agnostic of cloud platform and cover Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS) cloud services. 

As the digital ecosystem rapidly evolves toward greater interconnectivity and migration to hybrid and multi-cloud environments, the threat landscape has become increasingly complicated. The role of responsible central authorities in establishing and encouraging the use of cybersecurity “best practices” has never been more critical and active collaboration among all stakeholders, including government, industry, academia, and the research communities, in adopting and normalizing such practices are the best path to safer and more secure digital environments. SAP regularly collaborates with NSA and CISA though the Enduring Security Framework (ESF) and Joint Cyber Defense Collaborative (JCDC) public – private partnerships and applauds their leadership role with this announcement. 

 

Top 10 Cloud Security Mitigation Strategies 

Helpfully, eight of the strategies are mapped to MITRE ATT&CK® adversary tactics and techniques, as well as D3FEND™ cybersecurity countermeasures (we have marked those in the list below with a “*”). Many organizations, including SAP, use the ATT&CK® and D3FEND™ matrices to structure their security programs. These references are likely not included in the first and sixth strategies because there are no obvious matches for them (yet). 

  1. Uphold the cloud shared responsibility model
  2. Use secure cloud identity and access management practices (Joint with CISA)*
  3. Use secure cloud key management practices (Joint with CISA)*
  4. Implement network segmentation and encryption in cloud environments (Joint with CISA)*
  5. Secure data in the cloud (Joint with CISA)*
  6. Defending continuous integration/continuous delivery environments (Joint with CISA)
  7. Enforce secure automated deployment practices through infrastructure as code*
  8. Account for complexities introduced by hybrid cloud and multi-cloud environments*
  9. Mitigate risks from managed service providers in cloud environments (Joint with CISA)*
  10. Manage cloud logs for effective threat hunting*

The discussion of the cloud shared responsibility model helps determine where the responsibility is to manage different tactics, techniques, and countermeasures. For Continuous Integration/Continuous Delivery (CI/CD) environments Software Deployment Tools (T1072) is likely the best fit, but it could be argued it lacks a sub-technique for precision. 

These strategies are very useful recommendations and provide strong confirmation that we at SAP have been on the right path in the development of our own cloud security programs. The mitigation strategies cover several areas where SAP has already implemented controls to remediate their associated risks and will be of great use to those working through cloud security challenges now. 

 

Shared or Separated Security Model 

The collection starts with a discussion of the Shared Security Model for cloud security. SAP is a SaaS and PaaS cloud service provider, but most of those cloud services run on public cloud providers like Amazon Web Services (AWS), Azure, Google Cloud (GCP) and Alibaba Cloud. Therefore, we need to adjust this model to one that covers three different parties, rather than two. 

shared-separated-resp-model-sap.pngShared or Separated Security Model for SAP cloud solutions deployed in public cloud landscapes 

 The use of “shared” can be misleading. The three parties in this diagram have separate and distinct responsibilities for different parts of the solution stack. SAP needs to secure the IaaS and PaaS services used in the landscape, as well as the system configuration, secure provisioning, and cloud operations of the SAP solutions. That covers the primary scope of the mitigating strategies published by the NSA and CISA. In addition, SAP covers multiple security functions across the layers of the stack, as well as SAP’s corporate network, IT, and data centers, as well as the physical safety of our employees and facilities. 

 

SAP’s Approach for Mitigating Strategies 

In the sections below, we cover how SAP manages several main recommendations from the NSA/CISA remediation strategies. In past Security and Compliance blogs, we have covered the cloud guardrails that protect SAP and its customers against common cloud threats by making cloud accounts, subscriptions and projects more secure-by-default. Considering the size and scope of the landscape they apply to, they are perhaps our most effective security controls. Most of the examples below are enforced by these guardrails. 

Cloud Identity and Access Management (IAM) 

Enforced by the cloud guardrails, all cloud administrators must have SAP-provisioned identities. It is, therefore, not possible for adversaries to create their own accounts under other domain names. Cloud administrators must authenticate with their SAP identities using MFA on an SAP-enrolled device. In addition, SAP has a variety of phishing detection and defensive measures in place. 

Cloud Logs 

Cloud audit logs are centrally collected from all cloud accounts for ingestion into the central SIEM platform, where these logs are processed and enriched with asset inventory and organizational metadata. That makes them available for threat detection and hunting, alongside other security scanning data sources. 

Key Management 

Cloud guardrails enforce the secure configuration of cloud provider Key Management Services (KMS). SAP offers customers several key management options, through software or hardware key storage, as well as SAP Data Custodian, which allows customers to manage keys themselves. 

Encryption and Network Segmentation 

Transport Layer Security (TLS) 1.2+ with the weak cyphers removed is enforced on network connections for cloud infrastructure. That includes access to storage. Encryption-at-rest is enforced on disk volumes and storage buckets, where that is not already the default provided by the public cloud service provider.  

Many of SAP’s cloud solutions are deployed “single tenant”. That means that customers have their own instance of the cloud solution. For SAP S/4HANA Cloud Private Edition that includes tenant isolation by cloud account, which means there is no network path to other landscapes other than the customer’s corporate network. In other single tenant solutions, separate instances are segmented into isolated Virtual Private Clouds (VPCs). SAP blocks several common administration ports from the internet, including Secure Shell (SSH) and Remote Desktop Protocol (RDP). 

Infrastructure as Code and CI/CD 

The scale at which SAP operates means that we have long since moved to automated deployments through Infrastructure as Code (IaC) and CI/CD pipelines for SAP cloud solutions. This ensures that deployments are the same across instances, that the same release is deployed as has gone through development and pre-production testing and can be restored or rolled back more easily in case of incidents. IaC is checked into source code repositories just like any other code and managed through the secure Software Development and Operations Lifecycle (SDOL). 

 

Mitigate Risks From Managed Service Providers (MSPs) 

A particularly interesting and welcome strategy in the list is the ninth on mitigating risks from managed service providers. This recommends exercising due diligence, considering the provider’s security posture, and establishing audit mechanisms when choosing service providers. The concept of shared responsibility for risk must be fully understood in the MSP/customer relationship. A clear delineation and acceptance of responsibility for individual risk elements between the MSP and its customer should be an essential foundation of the relationship. The trust and transparency engendered through audit mechanisms, such as SOC 2, further contributes to a secure environment. SAP does this with its service providers, and we expect to be held to the same standards by our customers. SAP customers and prospects considering SAP cloud solutions as well as alternatives should use this strategy as a guide in their evaluations. 

 

More Information 

The following resources provide more information on SAP’s cloud security practices, including the cloud guardrails mentioned in the article. Given how many of the NSA/CISA mitigation strategies they can help with, we strongly recommend organizations to explore implementing similar controls. Visit the SAP Trust Center for broader information on security, compliance, privacy, and cloud service performance.  

1 Comment