Configuration security testing case study: a bank’s move to the cloud

Many cloud breaches start with a careless setting rather than a software flaw. A storage bucket left readable, a dashboard with no login, a firewall rule open to the whole internet. This bank was moving to Amazon Web Services (AWS) quickly, and it wanted to find settings like these before anyone else did.

ILLUSTRATION: WHAT WE CHECKED AGAINST THE BASELINE

Servers

Cloud access

Containers

API gateway

vs Baseline

Moving fast with half the guardrails

The bank had 120 AWS accounts, a managed Kubernetes platform for running containerized applications (EKS), managed databases, an API gateway and more than 400 virtual servers. Infrastructure as code (IaC, where servers and networks are defined in files and built automatically) was only half adopted. The rest had been set up by hand.

Two reviews were coming. One was against OJK’s guidelines for cloud use by financial institutions (OJK is Indonesia’s financial services regulator). The other was an ISO/IEC 27001 review of technical controls (Annex A.8). The bank had to show that its settings met a defined standard and stayed that way.

Checking every setting against a standard

We compared the bank’s configuration with two baselines. The first was the CIS Benchmarks, widely used published hardening guides. The second was the bank’s own hardening standard. Coverage included the AWS accounts, Kubernetes, Linux and Windows servers, databases, the firewall and gateway, and encryption and web security headers.

We reviewed the code that builds the infrastructure (Terraform, CloudFormation and Helm). We also checked the live environment for drift, where the running system no longer matches the approved design. Each finding was ranked by risk and came with a short code snippet to fix it.

Where the settings were dangerous

We found more than 300 configuration problems. These were the worst.

  • Four storage buckets were labelled private, but their access policies let anyone read them. One held customers’ e-statement PDFs.
  • The Kubernetes dashboard and the ArgoCD deployment tool were reachable without single sign-on. On one console, the default username and password (admin/admin) still worked.
  • 38 firewall rules (AWS security groups) were open to the whole internet, one of them on a database port.
  • Audit logging (CloudTrail) was switched off in 17 accounts, so activity there left no record.

For the bank, the first item meant customers’ financial documents were open to the public. The last meant that if something went wrong in those accounts, there would be little evidence of what had happened.

Three causes behind 300 problems

Almost all of the problems came from three causes. A server image with insecure settings had been copied again and again. Access policies used wildcards that granted everything. Kubernetes settings were not managed centrally, so each team’s values drifted.

The bank corrected the buckets, access policies and firewall rules. It added organization-wide guardrails in AWS (service control policies) and checks in its build pipeline that reject insecure configuration before it is deployed. It also published a hardened standard server image and a Kubernetes baseline. When we retested, 12 items remained open, all of them low risk.

Drift checks now run continuously and alert the team when a live setting moves away from the baseline. The same checks produce per-account evidence for the OJK and ISO/IEC 27001 reviews.

Any organization whose cloud estate grew faster than its governance will probably find similar settings, and they are far cheaper to fix before an attacker finds them.