We all know the story -- we find out about a security issue that we feel is important, so we walk into the boss's office and explain the situation in hopes that we can get the resources to fix the problem.

But instead of congratulating us on our dedication, the boss looks at us as though we're speaking some freaky language... Klingon or Elvish, perhaps...

The problem is that we might just as well be speaking Elvish, because to the business people of the world -- and I'm lumping the boss into that group -- ''geek speak'' is indistinguishable from Elvish.

The bottom line is that we explained the problem in technological terms so we lost our battle before it ever began.

In this hypothetical situation, you might say, ''One of our IDS sensors just picked up a possible SQL worm hitting our server farm on the DMZ.'' Your boss hears, ''One of the flayrods is out of skew on the treddle again.''

We've failed to answer the most important question: So what?

We've erroneously believed that our job was to protect the computer and network systems, when, in fact, our job is to protect the business data and business processes that reside on the computer and network systems. There lies our failure and our path to success.

I see two possible ways out of this problem. We could teach the boss to speak Elvish (or geek speak, but getting the boss to speak Elvish would be way more fun), or we could learn to talk''biz speak''. I think we're far more likely to succeed at the latter than the former.

We have to learn to put business issues into business terms so the business people can make the important business decisions. Yes, it is that important.

When we think that we're explaining the heart of the problem by describing the technical situation, we're actually obfuscating the pertinent details to the business decision makers. That doesn't help our cause and it doesn't help the decision makers to make their decisions. Of course, they are going to turn down our request for resources!

Incidentally, I've been using the ''we'' term throughout this piece because I see this mistake repeatedly throughout the IT Security world. I expect it's even more pervasive than that.

A wise former boss of mine once convinced me to start collecting incident data in terms of what the U.S. Deptartment of Defense calls ''mission impact''. After a lot of pain and errors, we managed to start doing just that. Lo and behold, our incident reports started getting noticed by the senior-most decision makers at the Pentagon. It had worked.

This may all sound simple to you, but I assure you it's not simple and it indeed takes significant practice to perfect. Even then, you'll still find yourself making temporary lapses into geek speak when talking to the boss. So, I've put together a few tips to keep in mind:

  • When you're delving into an incident, vulnerability, or other IT security issue, by all means collect all of the technical data. You're going to need that, without a doubt. Chances are, though, that you won't need to share that very far up the management chain -- one tier up at most.
  • While you're collecting that technical data, ask some business questions. What does this system do? What kind of business information is on this database? What business process does this server support? Has there or could there by any impact to the process or data due to this issue?
  • You're more than likely to have to repeat the previous step at least once or twice. The system administrators you're talking to will, without a doubt, tell you the system is, for example, a database server, a middleware app server, or something similar. Don't be alarmed or put off by that. Keep asking the questions, but try re-phrasing them. Try asking different people. Find out who the ''business owner'' of the system is and ask that person, if necessary.
  • When you're putting your presentation to the boss together, however formal or informal it may be, run it through the ''geek filter'' a couple of times before presenting it to the boss. Look for things like operating system names, application server names, and such. Change those immediately, or at least tone them down into their most basic tech terms.

    So, following these pointers, we might see something like this.

    Original: ''One of our IDS sensors just picked up a possible SQL worm hitting our server farm on the DMZ.''

    Improved: ''Our customer database is under attack from a worm on the Internet. I've verified that the worm is a significant threat and that our customer data could become stolen or altered without our authorization if the worm hits our systems. I recommend we get IT to test and install a software patch ahead of their normal monthly schedule.''

    That sounds a lot better than ''One of the flayrods is out of skew on the treddle again'', don't you think?

    Kenneth van Wyk, a 19-year veteran of IT security, is the prinicpal consultant for KRvW Associates, LLC. The co-author of two security-related books, he has worked at CERT, as well as at the U.S. Department of Defense.