The innate complexity of managing and orchestrating cloud resources using the tools, APIs, and other services that make up the cloud control plane inherently leads to increased cyber risk. Threat actors are constantly trying to exploit vulnerabilities across the cloud control plane so they can compromise your wider cloud environment. Often, these attacks rely on basic system misconfigurations to achieve further tactics. The good news is that if these misconfigurations are identified quickly, they are affordable, low resource, and often simple to remediate. This article looks at how Cloud Configuration (Config) Reviews help you uncover misconfigurations across your cloud environment, explaining the process they use and the outcomes they can lead to.
Attacking the cloud control plane
The cloud control plane is a critical component of cloud infrastructure, as it governs everything in-flight or being prepared for deployment across you cloud environment. This makes it a prime target for threat actors. Achieving privileged access here can create opportunities to read, manipulate, and destroy key systems regardless of network security controls – and the high risk of misconfiguration means it can often be easily done.
Misconfiguration is the incorrect or suboptimal configuration of an application, system, or other component of an environment. Misconfiguration affects every environment, from traditional on-premise networks to the Internet of Things. In the cloud, misconfigurations include:
- Default accounts and passwords, which are publicly known and therefore open to malicious use.
- Publicly accessible assets containing confidential and/or sensitive data.
- Weak Identity and Access Management (IAM) that increases the probability of credentials being stolen or permissions being misused (intentionally or otherwise).
- Unsecured storage leaving sensitive data exposed to unauthorised access and theft.
- Superfluous services and resources, which increase your unknown attack surface.
A motivated threat actor able to access your cloud control plane can bypass traditional network defences to perform techniques such as modifying account permissions, adding new user accounts, or altering access to target resources from external locations. They may also use system-native capabilities to exfiltrate data or steal compute resource for the purpose of cryptomining.
Fig. 1. Attack Path diagram from a Claranet Cloud Config Review that was used to identify attack vectors leverageable from a compromised developer account.
Cloud Config Reviews: the solution to a common problem
Most cloud security failures are expected to originate from preventable misconfigurations by 2025, so, what can you do to lower that risk? Cloud Config Reviews assess the security posture of your entire cloud control plane, as well as the applications and infrastructure in the underlying data plane, by analysing the configuration of the assets there. A typical assessment will include (but isn’t limited to):
- Industry best practice and benchmarks.
- IAM configuration and privileged identity management (IdM).
- Network security controls and segmentation.
- Public and exposed services.
- Encryption and key management.
- Secure configurations.
- Auditing and logging.
- Account hygiene.
How do they work?
A typical Cloud Config Review is a white box assessment of the systems in your public cloud environments, including:
- Microsoft 365
- Microsoft Azure
- Amazon Web Services (AWS)
- Google Cloud Platform (GCP)
- Google Workspace
In its most basic form, the exercise asks: are the key elements of my cloud tenancy following security and operational best practice for configuration? However, some approaches offer much more depth and contextual insight. Ideally, you’ll work with a consultant who can scope and design a bespoke assessment around your risk and threat profile, your security posture, your maturity (Partial; Risk Informed; Repeatable; Adaptive), and the outcomes you want to achieve. These vary drastically organisation to organisation, which is why customisation is so important.
Our own methodology was designed to help organisations develop from foundational best practice to more advanced testing and to enable those with more maturity to start at a suitably advanced level. Although not strictly tiered, the methodology can be loosely subdivided into levels based on the security outcomes an organisation is looking for.
Level 1: Best Practice Baseline
Maturity level: All
Objective: measure the overall security posture of your control panel accounts, deployed resources, and cloud workloads according to key industry baseline standards for best practice:
- CIS AWS Foundations Benchmark.
- AWS Foundational Security Best Practices Standards.
- CIS Microsoft 365 Foundations Benchmark.
- Office 365 UK Blueprint – Secure Configuration Alignment.
- CIS Microsoft Azure Foundations Benchmark.
- CIS GCP Foundations Benchmark.
Outcome: assurance that all of your major cloud systems are correctly configured so as not to introduce unnecessary cyber risk.
Level 1 is a broad consultative engagement that will provide suitable recommendations to help you achieve the quickest and greatest universal impact by implementing key policies, procedures, and controls. This is a simple way to lower cyber risk by ensuring your organisation isn’t the lowest hanging fruit from the perspective of a threat actor scanning for misconfigurations.
Level 2: Contextual Review
Maturity level: Risk Informed; Repeatable; Adaptive
Objective: extend test coverage to incorporate more cloud services and checks and provide a contextual security assessment of your accounts and service configurations.
Outcome: significantly improve your security posture by hardening cloud resources.
If Level 1 sets the universal baseline for configuration best practice, Level 2 identifies misconfigurations that affect both the control plane and data plane across a broader range of cloud services and assets, based on how they are deployed and used. The assessment considers:
- The context of the systems you use.
- The nature of your organisation.
- Your critical assets and infrastructure.
This level of detail reveals why and how threat actors could gain and further use unauthorised access to key resources, for example, accessing credentials and secrets within AWS Secrets Manager.
Level 3: Contextual Targeted Assessment
Maturity level: Adaptive; Repeatable
Objective: quantify the risk posed by misconfigurations in a scoped cloud system or environment by subjecting it to a targeted, simulated cyber attack.
Outcome: identify and assess the potential impact of misconfigurations within key systems being exploited.
This contextual assessment is like a cloud Penetration Test. It quantifies the real-world impact of a motivated cyber attack attempting to identify and take advantage of a misconfigured system. Doing so helps you understand the level of risk introduced by said system by asking “Can a threat actor with access to our cloud cluster or web service gain a foothold in our cloud environment, change functions, exfiltrate its data, and escalate privileges?”. This an effective way to demonstrate (especially to any sceptical developers and admins) that vulnerabilities aren’t just theoretical and that misconfiguration does tangibly impact your security.
Consultants will work with your admins and developers to review your system architecture and deployment methods. They will conduct Threat Modelling to determine potential entry points and attack paths that threat actors may use. They may also provide an end-to-end assessment of your organisation’s overall cloud security posture by analysing:
- Weaknesses in continuous integration and continuous deployment (CI/CD) process.
- Access to infrastructure components such as Kubernetes.
Cloud configuration security controls
The outputs of a Cloud Configuration Review should include list of prioritised recommendations and proof of concepts that help you understand the origin of your common misconfigurations. Some of the common recommended remediation controls that emerge from these exercises are:
User and credential management
- Enable Multi-Factor Authentication (MFA) by default for all users, without exception. Hardware- and application-based MFA tokens are preferable to SMS.
- Enforce secure password policies and educate users on the importance of good password management and maintenance, e.g., password blacklist, rotation etc.
- Only provide keys that grant additional API access to users that require programmatic access to cloud resources, and not by default. Keep key allocation per user to a maximum of one, except in the case of key rotation.
- Minimise guest and third-party access and apply the principle of least privilege (PoLP). Review accounts regularly and remove them when there is no longer a business case for access.
- Apply context and risk-based profiling to user activity and authentication requests. Restrict access based on IP and device, blocking the use of legacy protocols and services, and denying access based on geographical location.
Privileged identity management
Implement secure privileged identity management (PIM) practices with multiple tiers. Alongside common IAM controls such as MFA and PoLP, these controls could include:
- Cloud-only administrative accounts.
- Dedicated administrative accounts.
- Break-glass access.
- Just-in-time (JIT) access – JIT reduces standing access to privileged accounts, ensuring users only have the privileges to access sensitive accounts when they need it.
Regularly review ownership of privileged roles and disable them when no longer required.
Least privilege
A sensible approach to creating access policies is to start with a deny by default statement, adding additionally individual privileges through a dedicated request and approval process.
A simple naming convention for groups and roles which clearly indicates the level of access granted is recommended to ensure good account hygiene and enhanced maintainability. Apply permissions at the group and role level, not directly to user principals.
Network security controls and firewalls
- Create an “approve/deny” list of IP addresses and restrict internal traffic to reduce opportunities for Lateral Movement. Default deny.
- Use private cloud ‘backbone’ endpoints to connect services to cloud APIs without the need for public internet access.
Encryption
- Secure data in transit and rest with Transport Layer Security (TLS) encryption.
- Use the customer master key (CMK) in addition to platform-managed keys (PMKs) to enable administrators to decouple access to encryption keys from the data they protect (in AWS).
- If your organisation is required to meet strict regulatory compliance standards, cloud Hardware Security Modules (HSM) options are available to provide dedicated devices for managing encryption keys.
Monitor suspicious activities
Implement native or third-party security solutions to monitor for high-risk security events and suspicious activities that may indicate an account compromise
Source code and configuration management
- Subject source code to access control and only provide it to developers and administrators that require it to perform their day-to-day tasks.
- Securely inject secrets into the deployment process by using a native secrets management solution that will encrypt and protect secret data from unauthorised access. Never store secrets in configuration files.
- Use role-based access control, including cross account roles. These can then be assumed when access is required and provide an additional boundary of protection against unauthorised account access. Do not hard code access keys.
Cloud Config Reviews are an important component in any organisation’s security testing programme and can lead quickly to immediate gains for your security posture.
For more information, and to find out what kind of Cloud Config Review would be suitable for your organisation, get in touch below.