Leveraging the DPI capabilities of its NetWitness acquisition, RSA provides a peek at what it believes the future of ESIM might look like.
By now you’ve no doubt heard of the recent breach of RSA’s infrastructure and potential data loss related to its SecureID line of products. In an effort to help its customers, RSA has sent out the following list of recommendations:
One thing that surprised me is the two highlighted entries (items 5 & 6) that expressly call out SIEM as a recommended platform for monitoring subsequent breaches as a result of RSA’s breach. Now I know that RSA has its own SIEM product (enVision), but this is the first set of post-breach recommendations that suggested SIEM as a supportive monitoring tool that I can remember that didn’t come from a pure-play SIEM vendor – which is why I wanted to blog about it. RSA has a portfolio of products and it took the time to mention SIEM in 2 of its 9 bullet points.
Photo: RSA SecurID tokens (br2dotcom/Flickr)
Recently, LendingTree announced that several former employees may have provided passwords to a handful of lenders which, in turn, allowed the lenders to access sensitive customer information between October 2006 and early 2008. The passwords allowed the lenders to access files that contained sensitive loan request data for LendingTree customers. The loan request data contained such sensitive information as names, addresses, email addresses, telephone numbers, Social Security numbers, and income and employment information.
How was this breach discovered? LendingTree stated that:
Our internal security uncovered this situation. We began an internal investigation and reported it to the authorities. We continue to assist the authorities and are telling our customers as soon as it was possible to do so.
This insider data breach begs the question: “Why couldn’t the employees trading this information have been caught in the act?”
In all honesty, I can’t think of a good reason why they couldn’t have been caught in the act. If proper security safeguards had been implemented this could have all been avoided. What safeguards you might ask?
A proactive data leakage awareness initiative, combined with a well researched acceptable use policy, could have been implemented. Both should detail the acceptable use of company, and customer, information in an easy to follow format. Although it’s been proven, time and time again, that company policies and awareness training will not stop the most dedicated employees from exploiting sensitive data, shouldn’t you explain to your employees how to spot someone not following the policy? It’s in the best interest of most employees to protect their company and customers. Some people might hate their jobs, but the odds are that most employees want/need their jobs and will do what’s right to protect them.
Training, training, and more training. If your security operations staff isn’t properly trained to handle incidents, in a timely and process-driven manner, then you are simply asking for trouble. There are numerous training options available that teach proper incident handling techniques. Everyone involved with handling incidents in your company, from the manager to the lowly security operations grunt, should take advantage of these training opportunities. Here are some words of wisdom:
Based on a 2006 InfoWatch survey on Global Data Leakage, 23% of data leaks are performed with malicious intent. The other 77% results from the actions of undisciplined employees. The bottom line is that you don’t want to focus only on leaks that occurred due to malicious intent. The responsible thing to do would be to ensure that you are watching all sensitive information attempting to leave your network. (Extrusion Detection is not a new idea here people…it’s been around for quite some time now). You might say, “Well that’s a lot of information to watch”, and you’d be correct. Fortunately there are powerful solutions available to help you with your problem.
A properly implemented Security Incident and Event Management (SIEM) solution helps you keep a trained eye on your network. This trained eye can alert the security operations staff of any suspicious, or potential malicious, activity on your network 24/7/365. Being able to correlate and normalize the device (e.g. IDS, firewall, etc.), application (e.g. Microsoft Exchange, Squid Web Proxy, etc.), and operating system (e.g. Windows XP, Red Hat Linux, etc.) logs with collected network level flows (e.g. NetFlow, sFlow, raw packet capture, etc.) provides the security operations staff with a complete view of the network they were hired to secure and protect.
I can only assume that someone had tipped off the folks at LendingTree that in turn, pulled the trigger on the investigation. Unfortunately, by the time they discovered the who and the how the damage had already been done. I hope for the sake of LendingTree, and their customers, a full review of their process and procedures will occur. Additionally, I truly hope that they are able to implement the necessary safeguards to change from a reactive monitoring posture to one that is proactive. If another breach should occur (and the odds are it will), I hope that it doesn’t take another 1.5 years to resolve.