CISA and NSA Cloud Security Best Practices: Deep Dive

Recent cloud security guidance from CISA and the NSA offers a wealth of recommendations to help organizations reduce risk. This blog highlights key takeaways, provides further insights from CIS, and explores how utilizing cloud security posture management (CSPM) and cloud-native application protection program (CNAPP) solutions/services from Tenable can help.

This past spring, Tenable reported that the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) released five best practices documents (found here) that focus on cloud computing cybersecurity. This release was an effort to encourage stronger security measures for organizations with a computing presence in cloud-first, multi-cloud or hybrid environments. These cybersecurity information sheets (CSIs) include numerous specific measures to reduce risk overall, covering some of the most important attack vectors facing cloud computing services.

What’s this all about?

Each of the CSIs focus on a specific cloud service (or suite of services), first identifying the threat and then the MITRE ATT&CK tactics/techniques used by threat actors. They continue by providing detailed guidance on ways to help with reducing the risk of threat actors finding an opening. The best practices align with recommendations that other organizations touch on, such as the Center for Internet Security (CIS) cloud foundations benchmarks. The content in the CSIs underscores the importance of concepts such as least privilege, limiting attack surface area and centralizing logs for auditing purposes, as well as the use of tools like key management services (KMS), multi-factor authentication (MFA), and modern encryption protocols.

Each of the joint CSIs will be summarized below, with some useful information that organizations looking to start or secure a cloud presence can actively use today.

Use Secure Cloud Identity and Access Management Practices

The identity and access management (IAM) document outlines the best practices for access controls, which are central to any good security program but are especially important when developing a public cloud computing environment.

The document highlights several MITRE tactics and techniques malicious actors use when trying to gain access to any environment, but cloud environments that have public-facing access make for an easier target. If the actor wants to gain access, they can use phishing techniques and target accounts that don’t have active MFA. It goes on to outline key considerations of risks once the actor is in the door, and how concepts such as least privilege and separation of duties for access controls can help. TL;DR: drop down to the Best Practices section for a recap on all the best stuff.

What this document does well is speak to critical controls that other organizations, such as CIS, have also spoken to with its cloud foundations benchmarks, and in doing so lends more authority to the benchmark content. Within the cloud foundations content, CIS includes numerous recommendations on controls to help secure access in cloud environments; some examples of these access control recommendations are:

• Amazon Web Services Foundations: Ensure MFA is enabled for the ‘root’ user account.
• Microsoft Azure Foundations: Ensure that the Expiration Date is set for all Keys in RBAC Key Vaults.
• Google Cloud Platform Foundations: Ensure That Service Account Has No Admin Privileges.

Use Secure Cloud Key Management Practices

Next, the CISA/NSA documents cover encryption methodologies, including how to best maintain secure keys and address secrets management. There are definitely tie-ins to the IAM controls with regards to how services accounts authenticate and what those accounts can do when they gain access. Coupled with a well-planned IAM strategy, utilizing KMS in a cloud service provider (CSP) is crucial for smooth and secure infrastructure and operations.

Early in this document you’ll find several important items to consider when setting up a KMS strategy, and while the IAM and KMS functions may differ across CSPs many of these considerations are universal. As such, they will also be found in corresponding CIS benchmark recommendations. This guidance can be found in recommendations on protecting keys (access controls), key/secret rotation and logging/monitoring key usage.

As the document continues, there is a section on where a KMS fits into the most popular cloud service models (ie: infrastructure as a service, platform as a service, or software as a service) and how MITRE classifies the tactics/techniques used by an attacker to gain access or operate once they’re in the door. There is also another best practices summary that highlights key points when implementing and using a KMS solution. Here are some examples of key management recommendations in the CIS cloud foundations benchmarks:

• Amazon Web Services Foundations: Ensure that encryption-at-rest is enabled for RDS Instances. Note: this recommendation includes using AWS KMS keys for encryption purposes.
• Microsoft Azure Foundations: Ensure the Key Vault is Recoverable. 
• Google Cloud Platform Foundations: Ensure KMS Encryption Keys Are Rotated Within a Period of 90 Days.

Implement Network Segmentation and Encryption in Cloud Environments

Segmentation has become a hot topic in recent years with the introduction of micro-segmentation in data centers, as well as with every authority on network security highlighting the necessity of a “deny by default” firewall strategy. This document speaks to those concepts, but also adds encryption in transit to the conversation as the best way to secure data moving across the network or internet when that transit is necessary. After all, it’s always best to not only prevent attackers from accessing an environment, but also ensure that even if they get through the door, they can’t see anything important.

The document details specific recommendations for encrypted communication channels using transport layer security (TLS) 1.2 or greater for application protocols, an IPsec virtual private network (VPN) rather than TLS-based VPNs, and even private connectivity directly to the CSP. Traffic between services, to/from external parties, or between a user and a service should all be encrypted and as isolated as possible. Private access points are available for many of the common services used in the major CSPs, and role-based access control (RBAC) or attribute-based access control (ABAC) can be utilized to limit what that access can do in the environment.

The network segmentation sections detail the importance of network and workload isolation, as it helps prevent lateral movement if an attacker gains access to one system or service. The writers effectively explain the differences between micro- and macro-segmentation, why macro is considered the minimum necessary, and how micro-segmentation is the ideal that organizations should try to reach. Network security engineers have seen this guidance expanded over recent years and the examples given help bridge the gap between the data center and cloud environment.

This document also has some additional links for guidance on the zero trust security model and network infrastructure security in general. The zero trust model fits well into a public cloud or hybrid cloud architecture considering the nature of what most organizations wish to do in those environments.

The guidance given in this document can be found scattered across all of the CIS Foundations benchmarks as well, such as recommending TLS access using version 1.2 or higher, denying specific traffic for security groups, and setting an explicit default deny firewall policy. There are also sections on networking specifically in each benchmark that address firewall rules for the respective CSP. Some examples of CIS recommendations to cover these topics includes:

• Amazon Web Services Foundations: Ensure no Network ACLs allow ingress from 0.0.0.0/0 to remote server administration ports.
• Microsoft Azure Foundations: Ensure 'Enforce SSL connection' is set to 'ENABLED' for PostgreSQL Database Server. 
• Google Cloud Platform Foundations: Ensure That the Default Network Does Not Exist in a Project.

Secure Data in the Cloud

The cloud storage document briefly covers the commonly available types of cloud storage: file/folder (smb/nfs/etc), object (like AWS Simple Storage Service [S3]), and block (mostly used by compute resources or other services provided by the CSP). Again, a common theme here is encryption and access control. Both encryption in transit and at rest are mentioned, with recommendations for TLS 1.2 or higher on data in transit and using a KMS for data at rest. And again, access controls using RBAC or ABAC are highlighted.

Considering this is data storage, an extra layer of security with data access is also recommended: some form of data loss prevention (DLP). DLP systems are often found employed in on-premises data centers. It is common practice to use DLP systems for healthcare, even though they’re not necessarily required for compliance with the Health Insurance Portability and Accountability Act (HIPAA). Other industries with heavy use of personal health information (PHI) and personally identifiable information (/PII) also make use of DLP systems. Auditing for exposure is an important part of DLP functionality, and since most of the larger and well-known cloud computing breaches were related in some way to cloud data storage configuration, this extra layer is very important.

As with recommendations in the other documents, many of the elements here are also included in CIS benchmarks, specifically calling out encryption at rest and in transit as well as proper access controls on storage accounts. In fact, for S3 buckets in AWS, the general recommendation in the CIS Amazon Web Services Foundations Benchmark is to enable the block public access functionality. To read more on this, see the AWS documentation. The recommendation below lines up with this specifically:

• Amazon Web Services Foundations: Ensure that S3 Buckets are configured with 'Block public access (bucket settings)'.

For additional Azure and Google Cloud Platform examples with regards to data encryption and security, see the recommendations below:

• Microsoft Azure Foundations: Ensure Storage for Critical Data are Encrypted with Customer Managed Keys.
• Google Cloud Platform Foundations: Ensure That Cloud Storage Bucket Is Not Anonymously or Publicly Accessible.

Mitigate Risks from Managed Service Providers in Cloud Environments

And finally, since organizations can sometimes struggle with something different than what they’re used to with on-premises data centers, some hire external contractors or managed service providers to help with the transition and continual administration of cloud environments. This document highlights the importance of the threat vector with outside parties getting involved in an organization’s cloud presence. MITRE even documents the Trusted Relationship as being a technique used by malicious actors to gain access with the purpose of establishing administrative control to a particular tenant environment.

In addition to an abundance of caution, there are auditing and access control measures that can go a long way to mitigating some of the risks associated with third-party involvement. While measures like MFA can help in most cases, access controls and monitoring are more effective when a third party is involved in deployments or administrative tasks. The topic then comes full circle, back to having appropriate IAM policies in place to protect the environment and the end users consuming the cloud services.

How Tenable can help

The summaries above are intended to give busy security professionals a quick and useful resource for understanding key points in each CISA/NSA document, as well as how they relate to existing CIS benchmarks. However, it would definitely be worthwhile for security professionals to review the documents carefully when deciding on steps to setup or secure a cloud environment, whether it’s for production use or simply as a testing ground. Most of the content hits on topics that have taken the forefront in cloud security, as well as security in general, in recent years. Securing access to data storage, isolation of workloads and encryption are all concepts that an entry level security engineer should be able to run with, whether they work in a data center or for a cloud-first organization. But, sometimes, there’s more work that needs to be done to find the gaps or misconfigurations.

Tenable Cloud Security and Nessus both include CIS benchmark content as a part of their offerings. Scanning with these products can help identify areas where a cloud environment could be improved upon in line with some of the recommendations provided in these documents. In addition, Tenable Cloud Security has many policies that can be used to scan for misconfigured IAM and our product leads have released numerous blogs around IAM over the years.

Learn more

• Visit the Nessus product page: https://www.tenable.com/products/nessus
• Visit the Tenable Cloud Security product page: https://www.tenable.com/cloud-security
• Visit the Tenable Vulnerability Management product page: https://www.tenable.com/products/vulnerability-management