Holy Crap! Heartland, a card processing service for more that 250,000 small businesses discloses a malware generated breach on inauguration day. The scope is unfathomable. If each of the customers had only 10 credit card customers…you do the math.
Like vultures feeding on roadkill, no doubt every security vendor will call on Heartland telling them how they can help but because many of them are based on ports and protocols, their promises and claims will go unfulfilled.
Could Palo Alto Networks have helped – hard to say without knowing what happened. But at the risk of calling ourselves vultures, here’s my assessment of how we might have been able to help:
- Isolate the servers: Using security interfaces, VLANs and security zones, we could have isolated the servers and then applied policies to control both who and what had access to those servers. Because of our ability to see and control applications, users and content, the policies would have been far more granular than port-based solution policies.
- Control applications accessing the servers: With the ability to ID more than 750 applications, we may have been able to apply access control rules for the servers that allowed only certain applications MS-SQL, Oracle, Sybase) to access it, thereby stopping the malware from getting to the server.
- Control the users accessing the servers: Because we can leverage the user data in Active Directory as the basis of the security policy, we may have been able to stop the malware from accessing the server by controlling the specific users who had access.
- Prevent threat from accessing the servers: Using high speed threat prevention, policies can be applied to monitor inbound traffic (to the servers) for all manner of threats, blocking them when they are found.
- Watch for CC#s: Leveraging the in-depth traffic analysis we perform, we can detect CC# and SSN patterns in the traffic and alert on the detection or block the traffic altogether. So in the case of Heartland, we could have set a policy that monitored the traffic outbound from the server, looking for card holder data and alerting or blocking the traffic.
- Monitor and log the traffic: Like any security device, we collect a wealth of log data – but the key difference is that the data we have is based on actual applications, uses and content as opposed to IP addresses, ports and protocols. The result is a far richer and meaningful set of data that can be used for daily analysis or in the worst case, forensics. In the Heartland case, an admin might have been able to see unusual application activity from the server farm. From a forensics perspective, they would have at their fingertips the name of the applications, the users and the types of threats that were accessing (or attempting) the servers.
Without knowing their environment, the assessment is purely hypothetical, but worth taking a look at because it is not the first breach of this type (malware intercepting card data) – the same thing happened at Hannaford supermarkets last year – and it certainly won’t be the last. It’s time to fix the firewall.