Augmenting Native Cloud Service Provider Security

Last updated at Mon, 08 Jan 2024 21:18:56 GMT

Most organizations already have some level of cloud infrastructure services—infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), function-as-a-service (FaaS) or serverless—and as more workloads migrate to and are built on the cloud, the top cloud security concern for any organization is a data breach.

To underscore this point, breaches caused by cloud misconfigurations in 2018 and 2019 exposed nearly 33.4 billion records in total. According to a Ponemon Institute report, the average cost per lost record is $150. Multiplied by the number of records exposed, misconfigurations cost companies worldwide nearly $5 trillion in 2018 and 2019 alone.

Many noteworthy data breaches in recent history were due to misconfigurations and mistakes made by the Cloud Service Provider (CSP) customer, not due to vulnerabilities or failures in the underlying CSP. It drives the question: Are current approaches to managing cloud security controls sufficient to prevent a breach? Put another way, what do organizations need to do to augment or boost their current cloud security approach to manage breach risk at an acceptable level in the cloud?

Leveraging native CSP security controls is essential, and, for some cloud implementations, it is sufficient to manage public cloud workload risk. However, for most enterprises, these controls alone do not adequately address the core aspects of cloud security: audit, visibility, protection, detection, and automation.

This blog post investigates why aligning cloud complexity with organizational risk appetite is key to determining when and how to augment native CSP security controls.

Most cloud breaches are due to misconfigurations

Breaches of data in the cloud are on the rise, not breaches of the underlying cloud provider’s infrastructure. This distinction is vitally important and requires an explicit understanding of the underlying shared responsibility model between the CSP and the CSP customer. The CSP is responsible for—and typically successful in—securing the underlying components of cloud services it provides. The customer is responsible for securing how it uses the cloud services, including properly configuring identity and access management (IAM), storage and compute settings, threat analysis and defense, and the security of the application and data processed and stored on the cloud. If the underlying cloud infrastructure is secure, responsibility for cloud breach must lie with the cloud customer.

Cloud breaches are typically due to misconfigurations—therefore, organizations must implement controls that quickly (and automatically) prevent or detect and remediate these errors. To this end, CSPs offer a plethora of security controls. For example, Amazon AWS provides more than 30 different cloud security-related services, including GuardDuty, CloudTrail, CloudWatch, and many others. These controls are essential and play a primary role in secure cloud configurations, though it’s important to note that simply turning them on does not guarantee secure cloud configurations.

Achieving and maintaining secure cloud configurations is a dynamic and continuous process. At a base level, there is the configuration of the cloud infrastructure (e.g., blocking SSH ports and IAM). Next, there is the configuration of the CSP security controls (e.g., enabling log monitoring and encryption). And, finally, SecOps teams must address changes to settings (e.g., detecting and acting on a threat actor turning off logging to cover their tracks).

So, which controls detect and prevent misconfigurations? To answer this question, we align CSP controls against core aspects of cloud security:

• Audit
• Visibility
• Protection
• Detection

These core aspects build on the NIST Cybersecurity Framework (NIST CSF). To augment the NIST CSF and better align it to cloud security, we include automation as a core aspect. Automation is so central to cloud operations that there are a series of controls necessary to monitor, track, and enforce automation functions.

CSP security controls

The following table lists the CSP security controls available from the three major CSPs: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). These tools are necessary to manage and protect cloud workloads because, often, particularly for detective controls, these tools can provide visibility and control at a level not possible with external tools. For example, AWS GuardDuty leverages DNS logs, which aren’t made public to external security services. These detective tools enable users to derive insights from attack patterns and techniques so they can act more quickly. In the case of AWS, organizations use services like Inspector for vulnerability scanning or GuardDuty for network intrusion.

Essential and sufficient ... to a point

CSP security controls address audit, visibility, protection, detection, and automation requirements …. to a point. There is an inverse relationship between the effectiveness of these controls and the complexity of the cloud environment. To illustrate, AWS CloudTrail does an excellent job as an audit control service, recording events (e.g., API calls, AWS SDKs, command line tools, AWS Management console, and other AWS services). Of course, CloudTrail is only useful when turned on and—not surprisingly—an attacker’s first move is often disabling CloudTrail. Blocking this threat requires detective controls to identify when CloudTrail is turned off, preventive controls to prevent services from starting without CloudTrail enabled, and reactive controls to restart CloudTrail in the event of misconfiguration or malicious action.

To accomplish these tasks natively on AWS requires the following steps (and similar steps in multi-cloud scenarios across multiple cloud providers using their specific approaches):

1. Writing Lambdas to orchestrate these actions
2. Programming CloudFormation to make sure all infrastructure templates have CloudTrail enabled
3. Setting CloudWatch to alert on a CloudTrail stop action
4. Relying on GuardDuty to detect and respond to the action

Yes, this is only four steps, but consider that logging is just one of the hundreds of requirements for ongoing cloud security, and the complexity of managing this at scale across multiple clouds is greatly magnified. To provide some perspective, this requirement equates to the Center for Internet Security (CIS) requirement 6.2 “Activate audit logging.” There are seven CIS audit logging requirements to be set, validated, and rechecked regularly in AWS.

Complying with seven requirements is still not an excessive demand for a SecOps team, but if you add in a GCP workload, the number doubles. Deploy workloads across all three clouds, and the requirements more than triple. And, this is just the underlying configuration, not the additional AWS Lambdas, Azure Functions, and GCP Cloud Functions necessary to detect log setting changes and the resulting reset actions. Considering that this is only one of nearly 200 CIS recommendations, implementing these recommendations, particularly across a multi-cloud environment, becomes a considerable task.

A pre-script-ion for brittle security

Automation of cloud services is a double-edged sword. On one hand, automation drives better security by automating security controls with dramatic, tangible benefits. Automating security can reduce the incidence of a breach, and, according to a 2018 Ponemon report, businesses that have security automation reduce the cost of a breach by 35 percent. On the flip side of the automation sword, misconfigurations that involve automated cloud provisioning can act as a force multiplier. In other words, things can go very well or very poorly, very quickly, due to automation. For example, provisioning of serverless computing (e.g., AWS Lambda) without proper automation of dynamic and static code testing could result in vulnerable code launching into production quickly and quietly.

Sure, it is possible to write hundreds of scripts using cloud-native tools to enforce CIS benchmarks and detect and respond to changes to manage cloud risk. However, not only is this a brittle and unsustainable strategy, as complexity increases, relying entirely on CSP toolsets becomes unmanageable for the following reasons:

1. Writing JSON or YAML code for Lambdas and functions ties up senior security resources (a resource in critically short supply). Further, custom development required to write these scripts often ties to a single individual on the SecOps team. Without significant governance and discipline to treat these scripts with the same level of management as application code (i.e., policy as code), this may result in a single point of failure when said individual becomes too busy or moves on to a new job.
2. Organizations need a unified approach to security and compliance for auditors and executives. There is a lack of consistency of toolsets across availability zones, regions, or organizational level, depending upon the CSP.
3. Managing compliance (from a configuration standpoint) across different providers and cloud environments raises the likelihood of compliance gaps.
4. Coordination of remediation action to address misconfigurations and compliance gaps becomes disjointed and siloed when solely relying upon CSP controls in a complex cloud environment.

Learn more about Cloud Compliance

Managing risk against cloud complexity

As the complexity of your cloud environment increases, so too does the opportunity for such error. As shown in Figure 1, the relationship between CSP security controls, cloud complexity, and risk is not a simple straight-line equation. As complexity increases, so too does risk, but organizations may be at very high risk even in a basic cloud environment.

At point A, organizations deploying cloud workloads without implementing CSP security controls are assuming a level of risk way above the corporate risk appetite. One open SSH port or one weak AWS Management Console password is all it takes to give adversaries a natural entry point.

Point B is the sweet spot for CSP security controls. For an organization with minimal public cloud complexity (i.e., number of workloads, clouds, zones, etc.), proper and diligent implementation of CSP security controls is necessary and sufficient to bring cloud risk below the corporate risk appetite level and on par with on-premises IT workload risk. A CSP will argue that its intrinsic security posture makes it possible for lower risk in the cloud than on-premises for organizations at this level of cloud complexity.

As complexity increases (point C), the CSP controls remain essential but rapidly become insufficient in relation to risk. The challenges of managing controls across diverse cloud environments with different approaches, capabilities, user interfaces, and architectures make it impractical and unsustainable to rely on CSP controls alone. Even those organizations that are single cloud today can quickly become multi-cloud due to changes in business requirements, developer preferences, or merger and acquisition activities. The goal of enterprise security should be to adopt a forward-looking cloud security approach that enables and supports rapid business shifts. This security approach accelerates corporate innovation and profitability.

Gaining security effectiveness while managing risk

If your organization is further to the right on the chart, the ideal way to normalize cloud risk is augmenting CSP security controls with a unifying security control layer. This unifying security control layer facilitates the right balance of audit, visibility, protection, detection, and automation as a basis for managing risk in the cloud. For example, audit is only as effective as visibility, since one can only record what one sees. Similarly, organizations must balance protection and detection controls. Both are essential to blocking a breach. However, heavy-handed protective controls can drive up IT friction by putting limits on developers—for example, instituting rules that prevent all SSH and RDP ports (blocking test and development access) versus a more nuanced rule set that prevents RDP/SSH in a specific context  in production only.

Rapid7's InsightCloudSec provides a unification layer to work in concert with underlying CSP security controls. By leveraging a unified resource model, InsightCloudSec delivers universal monitoring and controls across clouds including AWS, Azure, GCP, Alibaba Cloud, and Kubernetes. InsightCloudSec monitors and remediates cloud and container misconfigurations, policy violations, and IAM challenges, allowing customers to achieve continuous security and compliance and realize the benefits of cloud and container technology.

InsightCloudSec sits inside the virtual private cloud, providing the visibility, governance, and trust necessary to address cloud security.

As shown in Figure 2, adding a solution like InsightCloudSec allows an organization to keep cloud risk below its enterprise risk appetite. By balancing and augmenting the audit, visibility, protection, detection, and automation aspects of CSP controls, InsightCloudSec improves cloud security by:

• Sitting inside the VPC with protected visibility of Continuous Integration/Continuous Deployment activity. Placing guardrails to guide DevOps in safely provisioning and configuring resources.
• Adding a unified compliance configuration management layer across clouds for maintaining compliance with standards and regulatory requirements, including PCI-DSS, HIPAA, GDPR, SOC 2, ISO 27001, CSA CCM, and CIS benchmarks.
• Simplifying risk management through extensive use of controls and automated workflows that align with security standards like NIST CSF and NIST 800-53, reducing both the level of work and the SecOps resources necessary when compared to managing risk with CSP security tools alone.
• Automating protective security control establishment and enforcement to strengthen and support detective controls.

Breaches of cloud data are on the rise, and misconfigurations of cloud workloads (including serverless workloads) and CSP user interfaces to manage the workloads are the primary causes. The good news is that CSPs provide a wide range of comprehensive security tools to help manage the audit, visibility, protection, detection, and automation of these workloads. The not-so-good news is that achieving the right balance of cloud security is increasingly difficult, particularly as the cloud environment’s complexity rises. For simple cloud environments—with security controls set properly—CSP tools are sufficient to manage enterprise risk in the cloud. For more complex deployments, organizations require a unifying security control layer to balance and boost the audit, visibility, protection, detection, and automation aspects of CSP controls to manage enterprise risk in the cloud.