Security, Pt 2: Axway Connections ’09 Predictions Panel

Axway CTO Dave Bennett, Taher Elgamal, Bernard Debauche and Joe Fisher continue to discuss security and make predictions.

Security, Pt 1: Axway Connections ’09 Predictions Panel

Axway CTO Dave Bennett, Taher Elgamal, Bernard Debauche and Joe Fisher discuss security and make predictions.

Convergence: Axway Connections ’09 Predictions Panel

Axway CTO Dave Bennett, Taher Elgamal, Bernard Debauche and Joe Fisher discuss convergence and make predictions.

GRC: Axway Connections ’09 Predictions Panel

Axway CTO Dave Bennett, Taher Elgamal, Bernard Debauche and Joe Fisher discuss governance, risk, and compliance and make predictions.

Levers for Growth: Axway Connections ’09 Predictions Panel

Axway CTO Dave Bennett, Taher Elgamal, Bernard Debauche and Joe Fisher discuss levers for growth and make predictions. 

“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.

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

by Taher Elgamal
Chief Security Officer
Axway

Sonny Discini wrote a smart, entertaining piece for EnterpriseITPlanet.com this week titled “4 Unreasonable Security Practices You’re Probably Following.”

But are they really all that unreasonable?

It depends.

About antivirus initiatives, Discini writes, “If you were a police officer and I handed you a bullet-proof vest and told you that it was effective 18 percent of the time or less, how much confidence would you have in the solution?”

First off, it’s not 18 percent.

I think the consensus on this number is more like 30-plus percent. Even so, isn’t 18 percent better than zero percent? Alternatives to antivirus solutions are in their early stages at this point, and these solutions aim to identify behaviors that don’t look proper. But those alternatives haven’t matured yet (not by a long shot), so until those alternatives have matured, I’d say that, if you’re an enterprise, you will still want to get this 30 percent.

“It never actually works right,” Discini writes about the concept of an intrusion detection system, “and you are always messing with it trying to get it right. Your environment is constantly changing, and hence, you will never stop this tuning process.”

That’s absolutely correct. Intrusion detection has never really worked.

Philosophically speaking, antivirus and intrusion detection are similar because they both look for known patterns.

But intrusion detection is such a general thing that you really have to do a lot of professional services work before, in the middle, and after implementing it in order to get the information you want.

If you don’t, you get way too many false positives. I’m talking 100,000 alerts a day. No organization can do anything with that information. So I agree with Discini—it never works well for an enterprise. I’ve seen it work well in government applications, where a whole staff is dedicated to it. The staff recognizes the technologies, works with the technologies, and knows the technologies inside and out. But commercially, it’s not easy to use. It’s a whole other story.

So why is it still sold to enterprises? Two reasons. First, intrusion detection is generally a smaller part of a larger software package, a technology a larger company inherited when it bought an intrusion detection company (the fate of all intrusion detection companies, by the way). The technology is offered as a “value add.” Second, some technologists are simply in love with technology, and they don’t actually recognize the fact that what they’re creating might be difficult for the normal IT guy to run.

In Part 2 of this blog entry, we’ll take a look at the other two security practices Discini believes are unreasonable.