When people start driving, one of the first things they learn is how to set the rear-view and side-view mirrors. Whether driving locally or on the highway, these mirror configurations reduce accident risk because they improve the driver’s visibility into the cars behind and around them.
In the cloud, various technical configurations act similarly. Cloud configurations are the settings, permissions, rules, and policies that determine how cloud resources communicate, who can access them, and how data and services are secured across the environment.
Organizations can improve their cloud security by understanding what a cloud misconfiguration is, identifying risky cloud misconfigurations, and implementing the appropriate mitigation practices.
What is cloud misconfiguration?
A cloud misconfiguration is when the setup of a cloud-based asset violations security best practices, leaving it open to unauthorized access or exploitation. Under the Shared Responsibility Model, Cloud Service Providers (CSPs) manage the security of the physical infrastructure while customers are responsible for managing security in the cloud, like setting identity and access management (IAM) permissions according to the principle of least privilege.
In modern cloud environments, misconfigurations can span across IAM roles, security groups, public APIs, and CI/CD pipelines variables.
Why do cloud misconfigurations happen?
Cloud misconfigurations typically arise when organizations seek to scale cloud deployments rapidly and treat security controls as barriers to implementation. Often, cloud environments rely on Infrastructure as Code (IaC) to deploy cloud resources at scale. Some causes of cloud misconfigurations include:
- Rapid cloud adoption and deployment timelines that prioritize agility and delivery speed.
- Increasing architectural complexity across multi-cloud, hybrid, and containerized environments.
- Misunderstood shared responsibility models between cloud providers and customers.
- Inconsistent configuration standards across teams, environments, or IaC templates.
- Limited visibility into continuously changing cloud assets, permissions, and network exposure.
What is the difference between vulnerabilities and cloud misconfigurations?
In cloud environments, threat actors frequently chain vulnerability and cloud misconfiguration exploits together during an attack. To mitigate risk, organizations should understand the following differences between vulnerabilities and cloud misconfigurations:
- Origin: While vulnerabilities originate from flaws in software, code, libraries, or system design, cloud misconfigurations come from insecure settings, deployment decisions, or operational mistakes.
- Root cause: While vulnerabilities often arise from coding defects, unpatched systems, or insecure components, cloud misconfigurations arise from overly permissive access, incorrect configurations, or gaps in governance.
- Location: While vulnerabilities exist within applications, operating systems, containers, APIs, or software dependencies, cloud misconfigurations exist within cloud resources, IAM policies, storage permissions, networking rules, and infrastructure settings
- Exploitation method: While attackers exploit vulnerabilities using a technical weakness or software flaw, they exploit cloud misconfigurations through exposed services, excessive permissions, or unintended public access.
- Remediation approach: While organizations typically fix vulnerabilities through patching, upgrading, or rewriting code, they typically fix cloud misconfigurations by changing settings, tightening permissions, or redesigning architecture.
- Ownership: While application, platform, or software engineering teams often own fixing vulnerabilities, cloud engineering, DevOps, infrastructure, and security teams often own managing cloud misconfigurations.
- Detection methods: While organizations usually identify vulnerabilities through vulnerability scanning, patch management, or code analysis, they identify cloud misconfigurations through cloud security posture management (CSPM), configuration audits, or IaC scanning.
- Speed of impact: While vulnerabilities may require attackers to develop a specific exploit path or capability, cloud misconfigurations can create immediate exposure, especially when resources are publicly accessible.
- Scale of risk: While vulnerabilities may impact a single application or workload, cloud misconfigurations can affect entire cloud environments if replicated through IaC templates or inherited policies.
Most Common Cloud Misconfigurations Organized By Risk Domain
Cloud misconfigurations can emerge across every layer of a cloud environment, from identity and access management to storage, networking, and workload deployment. By breaking these issues into risk domains, organizations can better understand where exposures occur, how attackers may exploit them, and which security controls are most effective for reducing risk.
Identity and Access Management (IAM)
Attackers often leverage IAM misconfigurations as an initial access point before moving laterally across cloud environments.
Overly Permissive Roles and Policies
When users, services, or roles have broader permissions than they need, attackers who compromise any account can escalate privileges and move lateral across the environment.
Organizations can identify these misconfigurations by:
- Engaging in IAM policy audits for wildcard permissions.
- Reviewing for unused roles that have high privileges.
- Identifying any cases that lack role scoping, like providing no resource-level restrictions.
To mitigate these risks, organizations can:
- Enforce the principle of least privilege using role-based access controls (RBAC).
- Use policy simulators or access analyzers.
- Regularly review and prune unused permissions, like looking at application access and firewall rulesets.
No Multi-Factor Authentication (MFA) for Privileged Accounts
Attackers can successfully gain unauthorized access using credential stuffing or phishing without MFA on critical accounts, like admin and root user ones. This can lead to full environment takeover.
Organizations can identify these misconfigurations by:
- Auditing IAM users and privileged accounts without MFA enabled.
- Reviewing root or global admin accounts for MFA.
- Monitoring authentication logs for repeated login attempts, unusual access patterns, or high-risk sign-ins.
To mitigate these risks, organizations can:
- Enforce MFA requirements through centralized IAM policies.
- Require phishing-resistant MFA methods, such as hardware security keys, for privileged users.
- Disable or restrict access for inactive accounts and regularly review privileged access assignments.
Hardcoded Credentials and Long-Lived Keys
Attackers can use API keys or secrets stored in code, configs, or CI/CD pipelines to gain persistent access. Often, key leaks arise from publicly viewable GitHub repositories or logs.
Organizations can identify these misconfigurations by:
- Scanning repositories for secrets.
- Auditing access keys older than a certain number of days.
- Reviewing environment variables and configurations.
To mitigate these risks, organizations can:
- Use short-lived credentials, like Secret Token Service (STS) temporary credentials or
- Store secrets in a secrets manager.
- Rotate keys regularly
Storage and Data Exposure
Storage and data exposure misconfigurations are among the most common cloud security risks, as improperly secured storage resources can unintentionally expose sensitive data to unauthorized users, external attackers, or the public internet.
Publicly Accessible Storage
As attackers continuously scan cloud environments, they look for publicly accessible storage resources because they can expose sensitive files, credentials, backups, intellectual property, or customer data without requiring authentication.
Organizations can identify these misconfigurations by:
- Scan for publicly accessible assets, like blobs, storage containers, or Amazon S3 buckets.
- Review ACLs, bucket policies, and anonymous access permissions.
- Monitor cloud security posture management (CSPM) tools or storage access logs for unintended public exposure.
To mitigate these risks, organizations can:
- Disable public access by default and enforce private-by-design storage configurations.
- Apply least-privilege access using tightly scoped IAM policies and resource-level permissions.
- Enable continuous monitoring and alerts for any changes that introduce public exposure, like triggering notifications for potential policy or access control list (ACL) drift.
Unencrypted Data-at-Rest
When organizations fail to encrypt storage volumes, databases, or backups, attackers that compromise these locations can immediately use any accessed or exfiltrated data.
Organizations can identify these misconfigurations by:
- Auditing storage services, databases, and backups to verify encryption-at-rest settings are enabled and consistently applied.
- Reviewing database configurations, disk volumes, and snapshot policies for missing or misconfigured encryption controls.
- Using cloud security posture management (CSPM) tools to detect unencrypted assets and policy drift across accounts and regions.
To mitigate these risks, organizations can:
- Enforce encryption by default across all storage, database, and backup services.
- Use centralized key management services (KMS) with strict access controls and audit logging.
- Implement automated key rotation policies and ensure encryption standards are enforced through IaC templates.
Exposed Backups and Snapshots
Attackers can retrieve historical sensitive data from old, publicly accessible snapshots or backups, even if production is secure.
Organizations can identify these misconfigurations by:
- Auditing snapshot and backup sharing permissions across accounts, regions, and external principals.
- Identifying orphaned or unmanaged backups that are no longer tied to active workloads or ownership.
- Reviewing backup configuration logs and access history for unintended exposure or cross-account sharing.
To mitigate these risks, organizations can:
- Restrict backup and snapshot sharing using least-privilege and account-level controls.
- Implement automated lifecycle policies to expire, archive, or delete outdated backups.
- Conduct regular access reviews and enforce governance over backup creation, retention, and sharing policies.
Network and Communication Security
Organizations can experience unintended exposure or untrust traffic between systems with improperly configured cloud networking controls, like firewalls, routing rules, or segmentation policies.
Open Security Groups and Firewall Rules
Unintentionally broad or unrestricted security rules can allow access to services, like SSH, RDP, or databases. Attackers can use brute force attacks or direct service exploitation to compromise the resources.
Organizations can identify these misconfigurations by:
- Reviewing security group and firewall rules for overly broad or unrestricted IP ranges.
- Identifying internet-facing resources and confirming whether exposure is intentional and necessary.
- Using cloud security tools to detect open ports and externally accessible services.
To mitigate these risks, organizations can:
- Restrict access to trusted IP ranges and approved networks only.
- Use controlled access paths such as bastion hosts or VPNs for administrative traffic.
- Adopt zero-trust principles to verify and authorize all access requests regardless of network location.
Lack of Network Segmentation
When organizations design flat networks with no separation between workloads, attackers can freely move across systems once they gain initial unauthorized access.
Organizations can identify these misconfigurations by:
- Reviewing cloud network architecture for flat or overly connected designs without clear separation.
- Checking for missing subnet isolation between environments such as production, development, and testing.
- Looking for unrestricted east-west traffic flows between workloads that should be logically separated.
To mitigate these risks, organizations can:
- Segment environments to isolate production, development, and testing workloads.
- Use private subnets to limit direct exposure between internal systems and external networks.
- Apply microsegmentation policies to control and restrict communication between individual workloads and services.
Unrestricted Outbound Traffic
Unrestricted outbound traffic means that compromised systems can communicate with external attacker-controlled infrastructure without triggering an alert. This misconfiguration increases risks arising from data exfiltration, command-and-control activity, and further malicious downloads.
Organizations can identify these misconfigurations by:
- Reviewing outbound firewall and security group rules for unrestricted “allow all” internet access.
- Analyzing network flow logs to detect unexpected or high-volume external connections.
- Using cloud security tools to flag workloads communicating with unapproved or unknown destinations.
To mitigate these risks, organizations can:
- Restrict outbound traffic to approved domains, IP ranges, or required services only.
- Route external traffic through controlled inspection points such as proxies or secure gateways.
- Continuously monitor and alert on anomalous outbound communication patterns.
Compute and Workload Security
When organizations deploy virtual machines, containers, and application workloads, these activities can have security weaknesses related to insecure configurations, outdated software, or excessive permissions.
Publicly Exposed Management Interfaces
Management interfaces are areas where attackers can gain direct admin access, like admin panels, Kubernetes dashboards, or cloud consoles. If these are exposed to the public internet, they become high-value targets susceptible to brute force attacks, credential reuse, and misconfiguration-based access bypass.
Organizations can identify these misconfigurations by:
- Scanning networks for publicly reachable admin interfaces, dashboards, and management endpoints.
- Reviewing inbound traffic and firewall rules to detect unintended exposure of administrative ports and services.
- Validating whether management systems are restricted to approved networks or access paths.
To mitigate these risks, organizations can:
- Restrict administrative access to private networks, VPNs, or secure access gateways only.
- Disable or remove unused management interfaces and services by default.
- Enforce strong authentication controls, including MFA and role-based access for all admin portals.
Overprivileged Service Accounts
A service account is a non-human identity that applications or services use. WHen these service accounts have more access than they need to function, attackers can compromise the account and inherit the excessive permissions to access sensitive data, modify resources, or move laterally across the environment with the application’s level of trust.
Organizations can identify these misconfigurations by:
- Reviewing service account roles and comparing granted permissions against actual application requirements.
- Flagging accounts with broad, wildcard, or administrative-level access not tied to a specific function.
- Monitoring service account activity for unused, dormant, or unusually high-privilege usage patterns.
To mitigate these risks, organizations can:
- Enforce least privilege by scoping service account permissions strictly to required functions.
- Use workload identity systems or managed identities instead of static credentials.
- Ensure each service account has a clearly defined human identity attached who is responsible for lifecycle and permissions.
Logging, Monitoring, and Detection
When cloud environments lack proper visibility controls, alerting, or log collections, these misconfigurations can make detecting suspicious activity or responding to incidents difficult.
Logging Disabled or Incomplete
When organizations fail to enable or fully configure activity logs, they may miss security-relevant events, like those contained in API calls, network traffic, or administrative actions. When these are misconfigured, organizations struggle with detecting abnormal activity, investigating incidents, and maintaining compliance documentation.
Organizations can identify these misconfigurations by:
- Checking whether key logging sources are enabled across all accounts and regions, like API activity, identity events, and network flows.
- Reviewing log coverage to identify gaps in critical services, workloads, or environments.
- Verifying that logs are being centralized, retained, and protected from tampering or deletion.
To mitigate these risks, organizations can:
- Enable comprehensive logging for all cloud services, including management, identity, and network activity.
- Centralize logs in a secure, immutable storage or SIEM platform for correlation and analysis.
- Define and enforce retention, alerting, and coverage policies to ensure continuous visibility into all environments.
No Alerting on Suspicious Activity
While the organization enabled logging, it did not properly configure the cloud asset to forward, correlate, or generate alerts on security-relevant events.
Organizations can identify these misconfigurations by:
- Verifying whether logs from cloud services are actively ingested into a SIEM or monitoring platform.
- Checking for missing or inactive alert rules on key security events such as privileged access or configuration changes.
- Reviewing detection coverage to identify critical events that are logged but not monitored or alerted on.
To mitigate these risks, organizations can:
- Configure centralized alerting for high-risk events across identity, network, and workload activity.
- Define and maintain detection rules for known attack patterns and abnormal behavior.
- Regularly test and tune alerting logic to ensure timely and relevant incident detection.
Configuration and Governance
When organizations fail to implement, enforce, and apply controls, the lack of governance creates risks like unmanaged changes, policy drift, and unidentified exposures across the environment.
Default Configurations Left in Place
When organizations deploy services with their default configurations, they create risks arising from threat actors who know default passwords or other configurations that they can find online.
Organizations can identify these misconfigurations by:
- Comparing deployed cloud resources against hardened configuration baselines or security benchmarks, like CIS Benchmarks or Security Technical Implementation Guides (STIGs).
- Scanning for default settings such as open ports, sample accounts, or permissive access policies.
- Reviewing new deployments to confirm they have been explicitly configured rather than accepted with vendor defaults.
To mitigate these risks, organizations can:
- Enforce secure-by-default configurations through approved IaC templates.
- Disable or remove insecure default settings during provisioning and deployment pipelines.
- Continuously validate configurations against security baselines using automated compliance and posture management tools.
Misconfigured Infrastructure-as-Code (IaC)
Organizations often use cloud infrastructure templates, like Terraform or CloudFormation. If these have insecure settings, overly permissive access, or incorrect configurations, a single misconfiguration can be reused or scaled across multiple resources or environments.
Organizations can identify these misconfigurations by:
- Scanning IaC templates for insecure settings, excessive permissions, or policy violations before deployment.
- Reviewing CI/CD pipeline activity and deployment histories to identify unapproved templates, outdated modules, or bypassed security checks.
- Monitoring deployed environments for configuration drift between IaC definitions and actual cloud resources.
To mitigate these risks, organizations can:
- Enforce security validation and policy checks within CI/CD pipelines before infrastructure is deployed.
- Use approved, hardened IaC templates and reusable modules for common cloud resources.
- Continuously test and update IaC configurations to align with evolving security standards and cloud architectures.
Graylog: Cloud Security Monitoring for Lean Teams
For lean security teams, maintaining visibility into cloud configurations across rapidly changing environments can be a significant challenge. Graylog enables organizations to centralize all logs, monitor cloud activity in a single location, and implement alerts to help mitigate risk. With Graylog, lean security teams centralize visibility, threat detection, and operational efficiency so they can balance security responsibilities with limited resources.
By combining log collection, event correlation, dashboards, alerts, and risk-based investigation workflows, Graylog enables teams to more quickly detect suspicious access patterns, publicly exposed resources, unusual authentication behavior, and other indicators commonly associated with cloud misconfigurations. Features such as access control auditing, data enrichment, AI-assisted investigations, and scalable data management also support stronger cloud governance without requiring large SOC teams or complex tool stacks.
