Summary Bullets:

• Misusing certificates for data leakage prevention (DLP) purposes is not a good idea
• Deploying big data analytics to weed out deviant data and traffic behavior is much less intrusive

I have been talking to several MSSPs in connection with their rollouts of DLP services. A pressing issue for them is to explain to customers how effective their DLP services actually are. Two weeks ago Trustwave, an SSL certificate authority, confessed to selling a subordinate root certificate that allowed a customer to monitor employees’ Web communications – even if the staffers relied on HTTPS. Trustwave explains that the man-in-the-middle gear was designed as tamper-proof and limited to its unnamed client’s compound. I would suspect that other certificate authorities have issued similar certificates to enterprise customers for DLP purposes. Despite these precautions, Trustwave revoked the offending certificate admitting that the whole approach was ill conceived.

An alternative approach is to enlist the big data analytical capabilities of the MSSPs combined with their real-time malware scanning. Most recently, I’ve come across the IBM QRadar platform slated for launch in March – developed at Q1 Labs and acquired by IBM last fall. This platform will draw information from the IBM X-Force threat repository, which combs through some 13 billion security events a day. With its data-crunching capacity QRadar will be able to monitor and corroborate suspicious activity across multiple locations and users, more specifically the software will look for activity exhibiting unusual traffic patterns or changes. Enterprise or MSSP security teams can then determine whether activity patterns exhibited by a given user are consistent with the user’s role and permissions within the organization. Using information from IBM X-Force, the system will be able to combine reports of live malware threats fed into it from 400 different sources. With this kind of information, security teams can find malware faster, and get a higher probability of unauthorized or suspicious activity at the database layer – such as a database administrator accessing credit card tables during off-hours – correlated with anomalous activity detected at the network layer, such as credit card records being sent to unfamiliar servers on the public Internet. This type of monitoring is less direct than the solution exemplified by Trustwave and does not breach the confidence of users with VPN or HTTPS traffic connections. White hat violations of Internet users’ confidence can have far reaching knock-on effects that are detrimental to overall trust – this should not be undertaken lightly  – and certainly not routinely.