Many organizations believe that once their cloud environment is configured, their job is done. But this “set it and forget it” mentality can lead to major security vulnerabilities. Cloud environments are dynamic and require regular updates and reviews – to adapt to new threats and changes. Not staying on top of your cloud configurations can leave you with outdated security measures and put you at increased risk.
Another common misconception is that an initial entry point breach isn’t likely to happen to you. Organizations often set up security controls to restrict user logins and limit access to development environments. This in turn results in these controls being often treated as a complete security boundary that cannot be crossed. However, that is not entirely true. Attackers are becoming increasingly sophisticated, which is why it’s crucial to operate under the assumption that a breach can, and eventually will, happen to you. This mindset will help you evaluate the potential impact of a breach and implement measures to minimize damage.
Ready to see what we typically encounter in our engagements? Let’s dive in!
It’s crucial to operate under the assumption that a breach can, and eventually will, happen to you.
#1 Excessive privileges
One of the most common problems in cloud environments is the granting of excessive privileges to users and machine accounts. This misconfiguration can lead to privilege escalation, where a malicious actor gains higher-level access than intended. Cloud providers offer thousands of granular permissions, making it hard for administrators to fully understand the potential impact of each one.
For example, an application might only need permissions to read and write in a specific storage bucket or database resource but it might be granted additional, unnecessary permissions, increasing the risk if the account is compromised. The solution involves carefully reviewing and limiting permissions to the minimum level necessary for each role. This process can be time-consuming, especially for larger organizations, but it’s key to maintaining security.
Here are some practical ways to limit excessive privileges
- Segregation of organizational workloads:
Where possible, different applications and the resources required by them should be provisioned into their own granular unit (AWS account, Azure subscription or GCP project, etc.). This would provide a strong control to minimize the impact of excessive permissions and limit the impact of a compromised identity. - Review current permissions:
Regularly audit the permissions granted to users and machine accounts. Identify and remove any unnecessary privileges. - Implement role-based access control (RBAC):
Use RBAC to assign group permissions based on roles within an environment and the level of access appropriate to that workload. This helps ensure that users only have access to what they need. - Use temporary credentials:
Where possible, use temporary credentials that expire after a certain period. This reduces the risk of long-term exposure. - Automate where possible:
Utilize automation tools to help manage and review permissions. While some manual review is always necessary, automation can significantly reduce your workload.
#2 Poor secrets management
Another common misconfiguration that impacts organizations of all sizes is poor secrets management. This issue often leads to privileged escalation opportunities within a cloud environment. With the widespread adoption of cloud infrastructure, ClickOps is just no longer practical, especially for organizations running multiple projects. As a result, many companies have turned to infrastructure as code (or IaC) to manage their cloud environments.
IaC allows you to define your company’s cloud infrastructure using templates in a human-readable code format. These templates define how your cloud environment should look and how individual resources should be configured. But while this approach does simplify the management of large estates, it can also introduce poor development practices, such as storing credentials or secrets in plain text within these templates.
The risks of poor secrets management
Storing secrets in plain text is a major security risk. Any user with access to these files can potentially use the exposed credentials to perform unauthorized actions on resources they typically wouldn’t have access to. For example, if a storage bucket’s credentials are stored in plain text, an attacker could gain access to sensitive data stored in that bucket. Similarly, hard-coded credentials could allow unauthorized access to other applications or services, leading to data breaches or other security incidents.
Follow these steps to improve secrets management
- Use secure key storage:
Store secrets in secure key management services or vaults. These services provide a secure way to manage and access secrets without exposing them in plain text. - Reference secrets securely:
Instead of hard-coding secrets into templates, reference them from secure storage. This way, the actual secrets are fetched dynamically during execution, reducing the risk of exposure. - Regular audits:
Conduct regular audits of your IaC templates and other deployment scripts to ensure no secrets are stored in plain text. Automated tools can help you identify and remediate these issues. - Educate developers:
Make sure your developers understand the importance of secure secrets management and follow best practices when writing IaC templates.
#3 Long-lived credentials
Closely related to poor secrets management is the issue of long-lived credentials. While not inherently a vulnerability, long-lived credentials can pose significant security risks if not managed properly. These credentials, which have long expiry windows, can be exposed in various ways, such as being accidentally committed to public code repositories, left unprotected in deployment templates or more generally insecurely handled by human users.
Take these practical steps to mitigate the risks of long-lived credentials
- Avoid storing credentials in plain text:
As with secrets, avoid storing long-lived credentials in plain text. Use secure storage solutions instead.
- Use short-term credentials:
Where possible, use short-term credentials that expire after a short period. For example, AWS recommends using temporary credentials gained from a federated identity provider instead of using long-lived IAM user credentials.
- Regularly rotate credentials:
Implement a policy to regularly rotate machine credentials to minimize the risk of exposure.
- Monitor and audit:
Continuously monitor and audit the use of credentials to detect any unauthorized access or anomalies.
#4 Exposure of public endpoints
Cloud providers design their services to be user-friendly and easily manageable, often more so than traditional on-premise infrastructure. But this convenience comes with its own set of risks. One of the biggest is that resources in the cloud often have public endpoints, making them accessible from anywhere in the world.
The risks of public endpoints
Public endpoints let users interact with cloud resources directly via the Internet. While this is convenient for management purposes, it also means that if an attacker gains access to your environment, they can do whatever they want from wherever they may be. For example, if an attacker compromises your account, they could log in from another country and make changes to your resources without any geographical restrictions.
This issue is particularly prevalent in Azure, where public endpoints are often the default configuration for many resources. However, many organizations don’t need these endpoints to be public and would benefit greatly from restricting access.
Here are some simple tips on how to manage public endpoints
- Restrict access with IP Allow Lists:
Configure endpoints to only be accessible from specific IP addresses. That way you can control who can access your resources based on their IP location.
- Use private endpoints:
Where possible, make endpoints private so that they are only accessible from within your cloud environment. This adds an additional layer of security by limiting external access.
- Regular audits:
Conduct regular audits of your cloud environment to identify and secure any public endpoints that don’t need to be exposed.
- Assume compromise:
Work under the assumption that your environment could be compromised. By restricting public endpoints, you’ll limit the potential damage an attacker can do if they gain access.
Here’s an example
Imagine a storage bucket that contains sensitive data. If this bucket has a public endpoint, anyone with the right credentials can access it from anywhere. By restricting access to specific IP addresses or making the endpoint private, you’ll ensure that only authorized users within your network can interact with that data. This will greatly reduce the risk of unauthorized access and data breaches.
#5 Overly exposed internal networking
The last cloud misconfiguration on our list is overly exposed internal networking. This issue has been around for years, even in traditional on-premise networks. Organizations do often focus heavily on protecting their environments from external threats with robust perimeter defenses. But once an attacker gains a foothold inside your network, most of those internal protections aren’t enough to keep you safe.
The risks of overly exposed internal networking
In many cloud environments, internal network segmentation isn’t implemented to the level that it should be. Engineers might allow certain IP ranges to communicate freely for testing purposes, or resources might be deployed in a flat network structure. This lack of internal segmentation means that if an attacker compromises one resource, they can potentially move laterally within the network, accessing other resources that should be isolated.
For example, if an attacker compromises a virtual machine (VM) in the cloud, they could use it as a stepping stone to reach other sensitive applications or data. Without proper internal network segmentation, an attacker can move freely, increasing the risk of a significant breach.
Follow these steps to improve your internal network segmentation
- Implement network segmentation:
Divide your cloud environment into smaller, isolated segments. Make sure that only necessary communication is allowed between these segments.
- Use security groups and network ACLs:
Use security groups and network access control lists (ACLs) to define and enforce network traffic rules. This will help you restrict unnecessary communication between resources.
- Regularly review and update your network policies:
Conduct regular reviews of your network policies to make sure that they are up-to-date and reflect the current needs of your environment. Remove any unnecessary permissions or access.
- Keep an assume breach mindset:
Work under the assumption that a breach is possible. Evaluate the potential impact of a compromised resource and implement controls to minimize the blast radius.
Here’s an example
Consider an application that only needs to communicate with a database and a few other services. By segmenting the network and restricting the application’s communication to only these necessary services, you’ll be reducing the risk of lateral movement by an attacker. If the application is compromised, the attacker would have limited access and would be unable to reach other resources.
You don’t have to do it alone – WithSecure Consulting can help
As the digital landscape evolves, avoiding these top 5 misconfigurations in the cloud will help your organization stay safe in an increasingly complicated and threat-laden world.
Here’s how we can help.
Assumed breach assessments
Think it can’t happen to you? Think again. We help organizations conduct assumed breach assessments by simulating attacks as specific user personas within your company. It’s a strategic service designed to identify potential actions from that user’s perspective and addresses vulnerabilities. It helps you identify issues and resolve them comprehensively – before a real breach happens.
Collaborative exercises
Staying on top of security – together. Collaborative exercises with a security consultancy like WithSecure Consulting are invaluable to keeping your organization and sensitive data safe. These exercises offer fresh perspectives, helping you to identify and fix any misconfiguration issues you may have. Initial assumptions made during the setup of a cloud environment may no longer be relevant as services and features change. Regular reviews and updates are key to maintaining a secure environment.
The value of fresh perspectives
Having a fresh pair of eyes review your cloud environment can reveal things your team may have missed. Our security consultants can help you understand why certain configurations were set up in the first place and, when needed, propose more secure alternatives. Together, we’ll ensure that your environment is always secure and up-to-date with the latest best practices.
Challenging assumptions
Cloud environments are complex, and it’s crucial to question assumptions about service operations. Organizations should continuously review and understand the exact risks posed by their cloud configurations. Through our research-driven approach, we help companies in identifying the gap between what cloud providers claim is possible and what is practically achievable – essentially, the difference between theoretical and practical functionality.
Misconfigurations in cloud environments often occur due to misunderstood nuances to how cloud resources operate in any provider and due to a lack of regular holistic auditing of the deployed resources.
By assuming that breaches are possible, evaluating user access, conducting assumed breach assessments, and collaborating with security experts, you can significantly enhance your organization’s cloud security posture. This proactive approach will not only secure your environment but also make it more resilient against potential attacks.
If you would like to hear more about how we can help you protect your cloud environment, don’t hesitate to contact us!
Our Cloud Security experts are happy to help.
