Securing a core banking move to the cloud
Moving a core banking system to the cloud changes who can reach what. One misconfigured permission can give an attacker inside the network a route to payments. This bank wanted proof that its new platform was safe before customers were switched over, and go-live was six weeks away.
The situation
The bank was moving its core banking system to Kubernetes (a platform that runs applications in containers) on Amazon Web Services. It was largely a lift-and-shift, meaning the applications moved mostly as they were. New identity and access management (IAM) rules were added, and older batch jobs were carried across. The main worry was that a misconfiguration could let someone on the internal network gain higher privileges and reach the payment switch.
What we tested
We ran three pieces of work side by side.
The first was an assumed-breach internal penetration test. We started from an ordinary segment of the corporate network, as if an attacker already had a foothold, and tried to reach the core. The test followed MITRE ATT&CK, a public catalogue of techniques used by real attackers.
The second was a secure code review of the new microservices. Automated static analysis (SAST) was combined with manual review of the authorization logic, which decides who is allowed to do what.
The third was a review of the cloud configuration against the CIS AWS Foundations Benchmark.
What we found
The internal test uncovered a critical privilege escalation path toward the core. The code review found a way to bypass the isAdmin check, which would let an ordinary user act as an administrator. The cloud review found a storage bucket (S3) open to the public and IAM roles with far more permissions than they needed.
What changed afterwards
The bank patched the escalation path, and our retest confirmed it was closed before go-live. We also left a hardening baseline for future development sprints, mapped to ISO/IEC 27001:2022 Annex A.8 and SOC 2 control CC6.1, so new services start from secure settings. The bank’s security operations center added detection for lateral movement, which is an attacker hopping from one system to the next inside the network.
Planning a similar migration?
Test before go-live, while fixes are still cheap to make. Put the application code, the cloud settings and the internal network in one scope. Attackers chain weaknesses across all three, so testing them separately can miss the path that matters.