TL;DR
- Compliance dashboards from cloud providers are helpful, but they don’t catch every attack that happens in the real world.
- Third-party integrations and dependencies, infrastructure as code pipelines, and permission management make for very risky blind spots.
- Use both config reviews and custom threat actor simulations to figure out how an attacker could really get in.
- Turn on provider security tools, test them regularly, and think of not just what’s in the cloud, but how it gets there, as part of your attack surface.
Introduction
Cloud compliance frameworks are a good place to start. Dashboards that show how your estate compares to benchmarks like CIS and vendor-specific best practice checks are available from most major cloud providers. These tools let teams quickly see how clean their configurations are and how easy it is to spot obvious gaps. But following the rules and doing things the right way doesn’t mean you can’t be attacked.
Real-world compromises often come from places a checklist will not highlight. It may not be obvious to an automated scanner that a role is over-privileged, or that a process has access to credentials that could be abused.
That’s why a combination of config reviews and human-led threat actor simulations should be part of a modern cloud security program along with compliance.
What compliance dashboards can and can’t do
Provider dashboards make things easier. They are a cheap way to see how you compare to common standards. Provider dashboards are beneficial for maintaining hygiene, and having a high number of green indicators will make it more difficult for someone to break in compared to not using them at all.
Cloud-Native Application Protection Platforms (CNAPP) and Cloud Security Posture Management (CSPM) tools are also useful in identifying risks in the environment.
Although, even if everything appears to be green, situations can occur where a determined attacker could still get in. Compliance checks are based on certain rules and look for known misconfigurations. They often don’t take into account the nuances of user rights management, deployment pipelines, the way developers work, or the third-party code or integrations that are needed for your cloud platform to function.
Attack surfaces that aren’t obvious in modern cloud environments
Cloud environments have changed quickly. Development teams now commonly use automated pipelines and infrastructure as code to deploy at a large scale. Many times, those pipelines live on external platforms like GitHub or GitLab. Connecting code repositories to cloud accounts creates a new, sometimes risky relationship. Even when native code and pipeline management services like Azure DevOps and AWS CodeCommit/CodePipeline are used, we have seen issues that have led to compromises.
If a developer’s personal access token (PAT) is leaked, a pipeline is returning sensitive information in logs or artifacts, or a runner is operating with higher privileges than the developer calling the pipeline for example, then the compliance dashboards won’t always help.
We are also increasingly seeing supply chain attacks. Generally, the code base for third-party libraries will be out of your control and not monitored. If a library is compromised, it is common for the malicious version to be automatically ingested and deployed into unsuspecting environments.
This year, a widely used open-source action called “tj-actions/changed-files” was compromised. The code performed by this action was modified to dump sensitive variables used by the pipelines into log files for anyone with access to the logs to read. That action was used by about 23,000 repositories. Any business that used this action as part of their pipelines was at risk of being exposed, even if their cloud console said everything was compliant. Luckily it appeared that the secrets were not exfiltrated to a third party, so if your code repository was private, the damage was somewhat limited.
Another example was the CircleCI breach in late 2022. In this case a well trusted third party was compromised through a single developer. This led to many secrets and other sensitive data being compromised. The affected clients using this service would not have had any immediate alerts in their own dashboards, as it was out of their hands. Another example of your compliance dashboard not showing the whole picture.
What should you do?
Turn on and use security tools for providers, deploy CNAPP and CSPM tools. Use the dashboards to understand your risk and exposure. They are a helpful tool for keeping things clean. I’m always surprised on engagements when I see even the basic tiers of the security dashboard not being enabled.
But also look at the bigger picture…
Your infrastructure as code and deployment pipelines should be seen as part of your attack surface, as well as your dependencies on third parties. Ensure only those that need to make changes to code bases can, enforce approvals through branch policies, and review the permissions that the pipelines have.
Lock down dependencies from other people. Keep an eye on the open-source parts and actions that your builds need. For actions that run in CI, use minimal privilege design.
Run custom pen tests and threat actor simulations to emulate realistic attacker behaviours that are unique to your business. Start with the entry points that are most likely to be attacked, like services that are open to the public or developer credentials and then follow the paths that an attacker would most likely take.
Why custom testing is important
Your compliance checks should be there to ensure you are as secure as possible, but threat actor simulations should be performed to test those defences in the real world.
Testing should be specific and tailored to your environment. Think about what an attacker is most likely to take advantage of in your situation and identify what could happen if something were compromised. That could be a web service that is open to the public, developer credentials that are leaked, or a build action that has been hacked. Bespoke scenarios are useful because they use the client’s real situation to find the attack paths that are most likely and have the most effect.
Conclusion and what to do next
Cloud compliance dashboards help secure environments, there’s no doubt about that. They should be turned on and used. But don’t stop there. Add independent config reviews for external validation, and run tailored threat actor simulations to test your defences in real-world situations.
Ensure your attack surface includes not just what is in the cloud, but how it got there and any dependencies you have.
Use all the tools at your disposal to arrive at a place where you are confident in your security, then let the pen testers act as a real-world threat actor to test those defences.
