Don't Let Data Drive Your Compliance Efforts

Last week Dark Reading had a chance to catch up with governance, risk, and compliance (GRC) expert Doug Landoll at the RSA Conference to talk about trends he's seeing from customers, partners, and prospects as they navigate new challenges in 2012. A former analyst at the NSA and a longtime consultant currently acting as a security architect for Accuvant, Landoll is the author of The Security Risk Assessment Handbook.

DR: From the compliance side of the house, what are you hearing from prospects and customers at the show?
Landoll: In compliance, I'm seeing a couple of different things. It continues to be a driver for a lot of security programs in that it's one of the first things that C-levels see necessary for funding security. We wish it would be the other way around. We wish it would be protection of business assets. But it can be used to motivate and develop a secure security program no matter what the driver is because I've yet to see a compliance regulation that tells you to do something stupid.

It may not give you clear guidance, and sometimes you look for better interpretations, but at the end of the day, we want stronger passwords and patched systems. These are good things, not bad things. I'll take those as drivers. The other thing I'm seeing is a lot of security programs that have already gotten over that hump. The organization has hired a real CISO; what I mean by real is that they don't report inside of IT -- and they've implemented their security operations.

The tougher thing is the governance piece because business units are used to standing on their own. And there are big functions within the organizations that drive those different business units, like finance, but they're not used to being driven by outside requirements, like security. So that's where the CISO needs to take that leadership and be in an environment acceptable of that leadership.

DR: How do you advise your clients to fill that governance leadership gap?
Landoll: If there's a CISO in place, I want to make them successful. I want to help them navigate that management and political atmosphere because you can think of politics as a four-letter word, but it's a job description. You've got to understand it and utilize it.

One of the ways we help them do that is to help them set up governance. So what other business units need to be involved in making these decisions and monitoring policy exceptions and accepting the risk -- and that sort of stuff. We help them come up with an overall plan that accounts for all the business units, and really starting from business objectives and not IT objectives. You don't start off saying, 'Here's my security plan. I need to secure the database, and I need to make sure that hackers can't get in, etc.' That's a bottom-up. What you really need to start off with is, 'I need to understand from the business how we make money; therefore, what are my sensitive assets, what are my critical systems, and then what's the need?'

Because you can talk in general that we need to protect them, but you need to get more specific, like, 'How soon do you need to bring this system back up if it comes down?' and, 'Are you going to pursue an investigation and spend money to find out who the hacker was?'

In some organizations it's a 'yes,' and in some it's a 'no.' But you've got to figure that out.

DR: Do you have some tips for our readers about how to start that process of asking the right questions?
Landoll: I would say, in general, align your objectives. Find out what makes your boss successful and then align yourself the same way.

You can even start by uncovering some objectives they might not know they have. For example, in a recent engagement where I was helping set up IT governance, one of the questions I asked all the business units was, 'Are you aware of all the policy exceptions that have been granted in the organization?'

At first they'd say 'yes' and I'd say, 'Well, how would you find those?' And they'd say, 'Well, I'd have to go through my email.' So you're not really tracking them. You're aware of the decision when it was made, but you couldn't say, 'I granted an exception, I'm giving it six months, then I'm revisiting it.'

So you want to control exceptions because you've set a policy and you need to know what you need to get into place to get everyone aligned with it. So educate them so that they can articulate their objectives and then align yourself. Start giving them their reports and say, 'Hre are all the ones you've granted. Here are some compensating controls that you can put in place for those.' Don't just grant them. Put something else in place.

DR: Have you seen any interesting GRC plays on the show floor?
Landoll: There's a lot of point solutions out there. I'm not a big fan of point solutions. You're going to have to have them when you need them as things are evolving, like mobile devices and mobile management. That's going to be a point for now. But I don't get driven in my security program development by technology. That's the wrong way. You need to think about your security program, then see what technology is out there. If it's not there, put in procedures.

DR: Where do you think the biggest GRC gaps exist technology-wise?
Landoll: One thing is affordability of GRC tools. That needs to get affordable. I think people need them. It is tough to manage all those regulations, to set your policies, your objectives, and to roll up some kind of enterprise risk that managers can drill back down. Everybody needs this.

DR: And it's so complicated they usually need to hire someone like you, right?
Landoll: Sometimes, and sometimes not. It's never going to be the point where real small businesses are going to hire people like us. But they need a solution, too. It should be the businesses that have complex business environments, new requirements, that sort of thing. They're the ones that need to hire consultants. But if you're doing what everyone else is doing, there should be some products or some easier solutions out there for you. I don't know that it's simple yet. It's still some heavy lifting. Don't get me wrong -- people need these tools, absolutely. But it's a big decision for them. And they need to find the budget right now.

DR: Not to mention there are so many moving parts to contend with.
Landoll: I'm really pleased with the way the tools themselves bring them together. I like the way they bring those moving parts together. I'd like to see it in the hands of more organizations instead of just the enterprise. I think it's moving into the medium business, and I'd encourage that. The more we can bring that there, the easier my job is.

DR: One of the buzzwords du jour of the show is 'big data.' What does big data mean for security, compliance, and monitoring
Landoll: I think big data is such an amorphous term; it has no meaning to me right now. I don't know what someone's talking about when they're talking about that. It's something around the consolidation and use of data. But I'm not a big fan of letting data drive you. We've seen that with IDS systems, SIEM systems, etc., saying 'We've got all this data, let's make a chart and try to figure out what it tells us.'

Don't let the data drive you.

What you should be doing is saying, 'Here's the business problem I need to solve, the element of my business I need to manage,' and then think about what data you need to manage that. And you'll find out if it's already being produced. Chances are, it's being produced already or it's really easy to get. And then there's going to be a whole bunch of data out there that's superfluous, and you're wasting your time tracking it.

DR: It does seem like a lot of times security monitoring drives the client's compliance and risk programs rather than the other way around.
Landoll: Yeah, I think so. If you break down the compliance requirements in a PCI or a HIPAA, it's clear there's some technology requirements, in which case I'd love to have some data, but there's a ton of requirements that are outside of it. When's the last time you saw somebody's security dashboard include security awareness training? Or policy updates? Or anything along those lines. That's a requirement in HIPAA just like everything else.

Furthermore, the security dashboard probably includes a lot of things that aren't a HIPAA requirement.

So what are we doing here? We're letting the data drive us. That's the wrong way.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.