“Unreasonable Security Practices,” You Say? It Depends. (Pt. 2)

by Taher Elgamal
Chief Security Officer
Axway

(Continued from Part 1.)

About Security Information and Event Management Systems, Discini writes, “These are my favorite because what they actually do is collect garbage from all the other point solutions and spit out garbage on the other end.”

These systems go by several similar names, but whether you call them security event management, security information management or security information event management systems (SEM, SIM or SIEM systems), they’re all the same thing. They’re meant to help you analyze activity on your network and build alerts so you can stop bad things from happening. It’s a technology based on log aggregation, which means that logs throughout the enterprise are collected, normalized in a single format, and then organized in a single database. You can then query this database to find something in particular.

SIEM systems aren’t as bad as Discini makes them sound. If you know what you’re doing, you can craft queries that are useful. You just have to craft the queries correctly so you can get meaningful data out of the “garbage” (as he calls it). That said, I’m not a fan of that space.

Finally, about Data Leakage Protection, Discini writes, “It’s unreasonable to believe you are going to effectively stop data from leaking at a single egress point. Look around you — chances are you will see people with mobiles and myriad technologies and routes out of the brick and mortar walls of your organization, which means they can steal data all day long and pass it out of the enterprise out of band, and there is no way you’re going to know. DLP is marginally effective and hence, unreasonable.”

DLP gives you the compliance you need, but not the security. Regulations require private individual information, like consumer information, to be protected, and if that information leaks outside your organization and you are deemed at fault, you will be charged a fine. Most people who wanted to be compliant with the regulation installed these things because they primarily wanted to be compliant, so here, Discini is both right and wrong.

If all you’re looking for is to be compliant, DLP’s your man. But if you actually want to really stop information from leaking, DLP’s not going to help you, because basically, all these solutions provide is a different layer of an infrastructure, in your network, that tries to collect information from all over the place and find out where it’s coming from or going to. Any attempt to do something with that information is a Herculean effort.

My philosophy on DLP is this: it should be embedded inside your pipe—architecturally, that’s the right way to go about things. If you actually build applications in a way where DLP is in the middle of the application, then you can implement the policy correctly, because you’re actually in the data flow. That’s how a successful email product works. You can implement a policy in the middle of the data file that demands, “If you see Event A, take Action B.”

However, if you’re sitting in the network and trying to find out what the bad guy intended to do, that’s really not possible. (If you’re in an email thread, of course you know where the email’s supposed to go, because you have the email address right in front of you.) Ultimately, if you truly want a security angle, it’s better to implement DLP piecemeal in each application.