In-Depth

How to "Speak Security" to Executives

Discussing security issues with upper management

Security Strategies sat down with Ernst & Young (E&Y) security expert Mark Doll to discuss how to communicate security issues with upper management, how to determine the proper level of disaster testing, and security spending, among other topics.

Doll, Security and Technology Solutions Partner and Practice Leader at E&Y in New York, is the co-author of the recently released ,Defending the Digital Frontier: A Security Agenda (John Wiley & Sons, February 2003). The book is notable both for prescriptions aimed at executives for treating security strategically, as well as for its introduction by Rudolph Giuliani, the former mayor New York, who now has a security consulting company that’s partnered with E&Y. The book also contains the surprising results of a security survey conducted by an independent firm for E&Y. The survey covered 91 Fortune 500 companies, broken out by industry. Doll explains some of the survey's surprises.

Security Strategies: What's the biggest impediment to security being a boardroom-level issue?

Mark Doll: I think that one of the issues that most CSOs [chief security officers] or CISOs [chief information security officers] have is how to translate their risk into business terms. In essence, they say, “Hey, we had a denial of service attack based upon our slow patch migration process,” which is really what's happened to everybody with Slammer. Not a devastating situation, just a slow patch process. And the executive basically has no idea what that person just said.

How can security administrators translate security for executives?

We talk in the book about tabletop exercises, and sometimes it’s tough to get time from the CEO … but in essence, the CSO prepares a scenario that says, this is going to shut down, that is going to shut down. Hypothetically, we lost 40% of our servers to viruses, Web access is down to a crawl, orders are down to 30 per hour. And here's three or four different technical ways that we can respond. “CEO or CFO, what do you think we should do?” And the CEO generally says, “Well I don't know. I have no context for this particular scenario.”

I think as a change agent, CEOs know what they're going to do if the building blows up, or if there's a wrongful death in their organization, but they have no idea what to do if there's a security problem in the organization.

CSOs must translate security into business terms. Really what you're saying is, “Our ability to defend against the attacks is slower than the attacks, and that is going to cause us a series of downtimes relative to our competitors.”

How do you give CEO’s a language for talking about security?

One of the other scenarios, in the back of the book, is the 29-question questionnaire. It compares 91 Fortune 500 companies. That allows executives to benchmark themselves versus everyone else, and I think that gives context.

Let’s say, because I'm running below the average [by industry] for incident management, if an incident occurs, then we may be the only one, or one of a select few, that gets affected, while most in the industry don’t. I think that's another good change agent tool. It's meant to put in perspective how they compete with their competitors in the industry.

Executives already have a positioning map on the functions and features of their competitors. Here’s one where they can have a positioning statement on security.

How much disaster testing is enough?

It gets hard for companies—anything could go wrong at any time, and you end up with circular logic. We suggest that you back up a step and you identity those critical components where, if they fail, they fail for your competitors, too.

Let's say the Internet gets shut down and there's no IP traffic coming through. That would affect your competitors as much as you, and those are things that we generally recommend you don't protect for because it's just not cost-effective.

You have to divide up the points of failure, but if the trigger points are affecting all people in your industry, then you've gone too far. That's where your test scenario should be.

I think a lot of companies go through this process of saying, “We're going to be up no matter what,” instead of, “We're going to be up when none of our competitors are up.” Go about dealing with it realistically. You have to eliminate the things where if it happened, it would cause the whole industry to crash.

For example, if all of financial services in the U.S. were shut down because of some problem, that would effect every one of those companies in America. Well, if it affects everyone, you're not at a competitive disadvantage. So if you say, well I'm going to try and be up anyway, you sub-optimize your P&L [profit and loss], you sub-optimize your business.

Do many organizations just not set security priorities correctly?

I think really what happens is there's a big emphasis on technology, and not on people and process. In essence, most of the guys working on these kinds of systems are technologists, and they implement the technology, but the business units don't adopt the right procedures, or maybe don't keep on the right maintenance features afterwards.

But in most crisis management, people and process are more import than technology, because the assumption is that technology has failed. So in security you need to look at making all those things equal, if not greater, than the technology piece of the pie.

What does that mean for security spending?

What I find is that most people overspend on technology. So spend one-third each on people, technology, and processes this year. Maybe spend a little less on the technology, [and more on people and processes] because executing well on something is the name of the game for security.

So many organizations need better security plans?

I like to think that there’s a lack of management on these functions, but more of the time I find it's a lack of management of the business processes. “What am I going to do with these IDS logs?” If no one ever looks at them, it's not a business process.

Security on a monitoring basis can be kind of boring. If there aren't any major attacks going on, there are routine logs. So you kind of fall asleep at the wheel, and a new event occurs and you fall for it.

What’s the best way to combat monitoring fatigue?

What many companies are doing is outsourcing their monitoring. I think this is a great idea, to outsource it, because that now allows the aggregation of thousands of companies together, and you get better monitoring, and they alert the other companies before they potentially have a problem.

Secondly, you create interesting jobs for technology people who work this job, because they’re constantly sifting through attacks, and there are more interesting analytics to do with the more interesting data.

Slammer hit a lot of companies hard. What should they have done?

The biggest companies had a breakdown in their process. Their managed security providers said, “Hey, install this patch,” as an early warning defense, and the patch was still going through a series of early testing. So I think the real problem there was the amount of time it takes most companies to install their patches. It's just unacceptable to spend months now; this patch came out in the summer.

For the survey you conducted, how many people in each organization did you speak with to get the security picture?

To get a breadth of security, any one individual can't answer all of the questions. That’s one thing that comes out in the book. Privacy, business continuity, physical security—that’s not one department, that's two to three in most companies. So it’s four or five people contacted in each company to fill out all the data accurately.

Were there any big surprises from the survey?

One thing that caught me by surprise is in the strengths and weaknesses by the nine “security agenda items,” by industry. You find that telecommunications spends [more] and is a lot more capable of the provisioning of users—that’s the entitlement management security agenda. In financial services, incident response rates are much higher. And you kind of think the opposite is true. That in telecommunications (telcos), you'd really want to make sure that only certain people have access to certain systems—you wouldn't want to respond after the fact. In financial organizations, because they're regulated industries and have to report intrusions, they tend to report it from an after-the-fact perspective—how do I stop it when it's going on.

What’s the big-picture read on that?

I think there are social norms of security by industry. And from my empirical research and just going to clients everyday, it is true that financial services companies have big incident response teams, and telcos have large numbers of people that provision users. And it's true that manufacturing has some of the worst security—I think we all know that, but I think we need to take some of the leading practices of best security and apply that.

How can all industries improve?

You have to think past those social norms in industries to see how you're really going to compete. When hiring, cast your net a little wider. If you’re a manufacturer, which scores amongst the lowest, you want to think about a financial services security guy. You need to cross-populate from the best practices of different industries.

Must Read Articles