On August 11 and 13 this year, Cosmos Bank, one of the largest cooperative banks in India, came under cyber-attack. With over 14,000 fraudulent debit card ATM transactions, Cosmos Bank lost INR 80.5 crores and another INR 13.5 crore (around USD 13.5 million) through two SWIFT transactions to an entity in Hong Kong. The total loss stood at INR 94 crores or USD 13.5 million.
Incidentally, a couple of days before the attack, the FBI issued an ATM cash-out blitz, warning banks of an unlimited cash-out possibility.
“Historic compromises have included small-to-medium size financial institutions, likely due to less robust implementation of cyber security controls, budgets, or third-party vendor vulnerabilities,” the alert continues. “The FBI expects the ubiquity of this activity to continue or possibly increase in the near future.”
This article provides an overview of how the attack may have happened, and how it can be effectively prevented using a zero-trust security approach.
Anatomy of the Attack
- According to media reports, nine years’ worth of Visa and RuPay cards and associated accounts have been compromised.
- This compromised data may have been used by the hackers to create clone cards that enabled the fraudulent ATM cash-outs.
- This also means that the attackers may have been in the bank’s network for months together (high dwell time), moving laterally and finding the vulnerabilities in the system to stage the attack.
- Though the origin of the attack within the bank network is unclear, it’s alleged to have been triggered by a malware infection, which spread laterally and affected the system responsible for authorizing ATM payment requests.
- The malware may have created an ATM proxy server from a compromised VM that automatically authorized all fraudulent transaction requests, without connecting to the DB server or Core Banking System.
Best Practices to Prevent Sophisticated Frauds
In zero-trust all network traffic is UNTRUSTED, unless otherwise explicitly allowed.
This means that security professionals must ensure that all resources are accessed securely regardless of location, adopt a least privilege strategy and strictly enforce access control, and inspect and log all traffic. – Forrester, 2016
Visualize Cross-Segment Traffic: If the malware has infected a user workstation in your bank, it will try to explore other vulnerabilities in the network, spread laterally and send information back to the hacker’s command and control center. Maintain all-round visibility of ‘who’s talking to who’, to visualize the suspicious traffic between the infected system and the command and control center.
However, this is easier said than done if you juggle around with multiple visualization tools and don’t have a centralized console to monitor everything in one place. Also, even if there’s a connection initiated by the infected system to other critical resources, it’s difficult to narrow down to a conclusion without having a sense of context – i.e., is the workstation authorized to connect to the database server directly, and through this specific port?
Segment the Bank Network: Use micro-segmentation (tip: types of data center micro-segmentation) to separate administrative, non-banking, banking and critical environments into segments, governed by separate security policies. Even if a malware infects a workstation in the non-banking environment, the lateral movement is contained within that segment, protecting your critical environments from the lateral attack. The malware cannot spread to the critical segments of your network, compromise a VM or bare-metal server to extract and exfiltrate sensitive data.
But, segmenting using VLAN/ACLs or internal firewalls adds several layers of operational complexity – no easy thing fighting with thousands of ACLs and firewall rules. Not to mention the possibility of human errors and misconfigurations.
Orchestrate Policies: Once you’ve segmented the network, define resource access policies based on intent, and keep them up-to-date. Carefully defined policies can help control which resource can be accessed by who and from which segment or department in your network. Before even enforcing the defined policies, the changes in the security posture of the segments should be observed and assessed enabling further tweaks. Even if the attacker has somehow managed to install the malware, he wouldn’t have been able to identify and communicate with critical banking servers in the network that is protected with intent-based security policies.
This is no easy task to achieve if you’re dealing with network-level constructs such as IPs, VLAN memberships, ACLs and firewall rules. If a resource moves, the policies will have to be manually modified for that resource – imagine doing this for thousands of resources in your dynamic banking environment.
Tamper-Proof all Endpoints: Always apply the latest patches to all endpoints in order to plug the known vulnerabilities. Ensure that all endpoints have the latest version of the virus signature definitions.
However, what if your endpoints are running on legacy systems with unpatched/unsupported applications? What if your ATM kiosks are still running on Windows XP?
Though zero trust is the best approach to protect your bank from sophisticated cyber fraud, getting there can be cumbersome, time-consuming and error-prone using traditional security solutions.
ColorTokens can simplify your bank’s security journey – contact us to see how.
Download the solution brief to see how ColorTokens can protect your bank.