Getting the NAC: Cisco’s Bob Gleichauf at the London Gartner IT Security Summit

Robert Gleichauf is responsible for the development of secure network infrastructures across Cisco’s product line. Most recently, he led the development of Cisco’s Network Admission Control (NAC) initiative.
Bob has led other security initiatives at Cisco, including overseeing the R&D for Cisco’s Intrusion Detection System (IDS) product line, and the migration of IDS technology into the Cisco Catalyst 6000 platform.
Gleichauf joined Cisco with the WheelGroup acquisition in 1998, where he was the head of product engineering. Prior to WheelGroup, he was a senior engineering manager at startup IQ Software, which developed database report writing tools.
He recently spoke at the Gartner IT Security Summit in London, and spoke to Brian McKenna for Infosecurity about the trials of decrypting data in crisis situations, security officers of a new type, and the challenge of vendor interoperability.

You said at this event that a lot of classic security stuff is now being operationalized, leaving security specialists to focus strategically on things like insider threat, intellectual property control, and so on. Interesting, but where does Cisco play into that shift?

It may be that Cisco waits till the market gets to a certain size that makes sense for a company of our kind and size to go after. What is top of mind for leading company executives is not necessarily top of budget. Now, the control of intellectual property is something that IT departments are starting to fund for. It’s top of mind for boards, and now the IT department is being told what to do.

But there is a variation between what is being talked about and how much money is being spent. We see a mixture of opportunistic deployments, or tweaking of products, and then there is confusion about what they should do in some areas.

Just putting encryption in place on your data servers is not a solution. It is a punch list item for an audit. So if your senior management is worried about a singularity that leads to litigation they care about your keeping them safe from that.

There are a lot of breaches occurring even when data is encrypted on the disk. The areas where the breaches occur are typically somewhere else. This is why I am interested in these areas because they are more of a systems problem. How much of this is technology and how much of it cannot be addressed by technology at all. The company is trying to be careful about rushing into a market unless we can add some value.

This morning [18 September] you described the data leakage problem as having a ‘flavour of the year’ quality. You seemed quite sceptical.

The data leakage problem has been around since I was in college — at least! It’s top of mind now because of regulation. But there have rarely been good solutions to it. In fact some of the solutions we have are actually are making IT operations more brittle.

For example, take tape back up procedures. Tapes are usually recovered under crisis conditions. You have to go to an archive off site, and retrieve the tapes by courier. By the time they are recovered the IT staff is stressed, you sometimes get media failure and you have to get around that, and so on.

Now, you add bulk encryption. So you have to worry — is the data integrity there? Because, it’s based on an encrypted file, not on the original content. And the media is encrypted based on keys that may be physically located elsewhere. Moreover, the master key for the keys stored for the media is also elsewhere. You’ve added a set of layers of complexity.

So, say you unencrypt the data. The corporation has an audit requirement for bulk encryption, so that is what you have got. But while you were doing that, an enterprising application business unit, running Siebel or Oracle, has done encryption at the application layer too.

Remember this may be seven year old data. The people from back then may be gone. We’ve added two layers of complexity to a process that is prone to failure anyway. And you need to do it faster. So, yes you have passed the audit, and that is fine as long as there is no crisis.

But where do we have crisis? Warfare situations. Our two countries have active units in the Middle East. I have heard of situations where field officers are using out of band mechanisms to communicate information in lieu of data that they are getting from their standard channels that is encrypted. Why? Because they are having problems unencrypting the data. Why? Because the field units are given applications that were deployed by parts of their services that did requirements based security. Parts did encryption in transit in bulk. Other parts encrypted for the application.

So, you’ve got layered encryption problems. First lieutenants and young captains are struggling to get access to data quickly enough because of the security overhead. There was no systems design applied to meeting the security requirements, so it has become more brittle.

All of this requires new types of IT security people who, on the front end are figuring out the back end problem. This is about dealing with the lifecycle of a transaction process.

We talk about solving a problem based on an atomic transaction. Rarely is a security event based on an atomic transaction. The authentication of a user to pull data out of a data server is usually fine. Sometimes passwords get stolen, but technology doesn’t help with that.

The problem lies with the meta transactions from the point where the data is pulled down to a device. The industry is not dealing with those meta transactions: they are hard to define, hard to deploy, and hard to sell.

The kind people being hired in security teams these days is changing, you said this morning. What from and to?

Let’s take the anti-virus, anti-worm problem. Historically we have been hiring people who are specialists in desktop security — who understand how to patch things. Who know how to respond after the fact, to remediate systems, to recover data. They know how to maintain and run an existing patch update process.

That’s now been converged into an operational model that is somewhat brute force, but is okay for what it is designed to do. In lieu of that now there are some approaches that are more proactive, that require you to think ahead of time what are the rules you might write to establish defences, to minimize the problems you are going to have. Writing policies requires you to understand the business a priori. That’s versus the legacy response mechanisms where you don’t have to understand the business, you just have to understand how to patch and rebuild.

If you are to understand the business and write policies for it you need different kinds of relationship into the company, and you need people who are thinking more like architects. You have to understand how to express the policy, understand precedents, rules and how a policy may conflict. It’s not easy.

A lot of vendors will come, in three years or so, to compete in the policy space, with more comprehensive and compelling tools for doing policy-based definitions, and the diagnostics to fine tune policies.

Is Cisco doing this internally?

Yes, we have intrusion prevention products in the network, on the desk top and on the server. Those are starting to share information with one another. That means your security people need to get into a conversation about who is responsible for the deployment of those. Who is going to define the policies about how those technologies will interact. It creates a new dynamic.

There is value in that. Take the way SSL is disrupting the ownership of enforcement of policies. SSL end to end make it hard for the network people to enforce policies because they lose visibility into traffic. If you also have a presence on the desk top or the server where you can re-establish visibility then you should be able to share information. There should be a feedback loop and then you can take action on the network, say, that you see on the desktop.

In an earlier interview with the magazine this year you urged IT vendors to grow up and co-operate more. Have you seen progress on that in recent months? How is that coming along?

I’m not sure if it is still coming along. I may even be wrong about the advisability of this. It may just be that the incentives in the industry are such that it just does not work.

Let’s go to NAC. There are 100 partners signed up to be part of the NAC framework. The degree to which those vendors have benefited is uneven because the pick up to attach to the framework has been modest.

There are reasons for that.

One reason is that the stability of the NAC relative to its complexity is such that there are too many moving parts for higher level adoption. Another is that the degree to which customers are ready to deploy NAC is limited, but it’s starting. I have every confidence that NAC solutions will start to make their way into the marketplace, but it is a very slow ramp.

Is it working to participate? For some vendors more than others. Will it sustain itself? We’ll see. I refuse to accept that it won’t work long term.

What could happen is that we stumble and we come back to it. But I don’t see how we can solve real problems unless vendors start interoperating at a higher level. If you look at the NAC/NAP announcement -- three years ago I would not have believed we could have pulled that off. But here we have with a cross licensing agreement that gives us options.

On the buy side of things, customers have an ability to influence us more than they realize. My advice would be that you get all stakeholders in the room. Customers have done a miserable job of educating vendors about what they really need.