Yesterday I wrote about how some of the recent security incidents seemed to play on old school social engineering like phishing & unaware users. I suggested that for 2009, re-training users of both the old & new potential perils of the internet might be worth doing. Today, lets look specifically at the Heartland breach and how F5 technology would be able to prevent this.

Let's set it up a little. High-end Criminals have moved on from trying to steal a couple credit cards from a single merchant to attempting breaches of these large payment processing firms. 100 million transactions a month is much more attractive than the Dry Cleaners down the street. They go where the data is. Another contributing factor is PCI. PCI is great at setting minimum requirements and an excellent starting point for securing electronic transactions. PCI requires encryption of sensitive data over the Public infrastructure but PCI does not require encrypted transmission on Private networks. This is where the breach occurred. With very little info to go on (as they haven't released much) it seems that a phishing scam got the crooks on the network, they installed a sniffer and were able to see the sensitive data passing in clear text. Visa & MasterCard noticed something fishy and alerted Heartland. By then, the damage was done.

So could this have been prevented? Most experts agree that an additional layer of encryption on the internal transmissions would have prevented the sniffer from seeing actual data. Some would argue that requiring encryption on the private systems would be costly...but so is a breach.

Now, could this have been prevented with F5 solutions? Yes, with BIG-IP Secure Access Manager (SAM). BIG-IP SAM is a high-performance, flexible platform for Unified Security along with granular Identity and Access Management (IAM) capabilities. BIG-IP SAM uses SSL technology to encrypt data and provides policy-based, secure access to enterprise applications for any client. In fact, the same FirePass DevCentral SDK is fully compatible with BIG-IP SAM. (we do have an updated SDK coming with additional examples (e.g. Vista gadget example), and documentation updated to cover BIG-IP SAM.) But, even the existing SDK works great if you replace references to FirePass with SAM. There are also a few scripts for administrators looking to build this into Linux-based appliances or embedded systems. The API is useful if you’d like to build the secure access function directly into client-side financial applications.

How would this work? Our new BIG-IP Secure Access Client (running in the background, auto-connecting/reconnecting) along with BIG-IP SAM or BIG-IP LTM + SAM add-on (to provide authentication, authorization, confidentiality, and access control) can be a great fit for protecting sensitive internal servers or networks (e.g. access to financial or HR internal networks). The client can configured with location-awareness, for example, to always have the Secure Access Client connected. You can then configure split-tunneling so that “only” the traffic to particular networks/subnets or servers go over the secure tunnel - such as sensitive 'batch' transaction data. All other traffic is routed in normal way to the internal network.

For example, if within your infrastructure all financial servers were on a particular network/subnet, you’d put a BIG-IP SAM or BIG-IP LTM + SAM in front of this network/subnet. Then, deploy the Secure Access Client, and configure split-tunneling so that only traffic to this particular network is routed over the Secure Access tunnel. Since the client is running in the background (systray), users (or even the lone server) will not have to do anything special. The traffic to the protected network is sent over a SSL tunnel running in the background, while normal internal traffic is unaffected.

So, if you're processing sensitive data, need to be 'more' than PCI compliant and don't want to end up in the headlines, F5 can help.

ps