Explain Security To Business People

How do you effectively explain security to business people?

I have encountered many cases of ReinventingTheWheel in dealing with the security aspect in software projects, and often find it difficult to explain to business people that it is better to use well-established, widely available algorithms/protocols. They trust us enough to let us choose the algorithms/protocols for doing their project, yet when it comes to security, NotInventedHere seems to be the common attitude.

How do you explain to them that well-established encryption algorithms, well-established key exchange protocols, etc, will be much better than whatever homebrew scheme they cook up themselves in a couple of meetings?

There's some discussion about making security into end-user-oriented stories over at SecurityIsHard.

The problem seems similar, but you have to make business people understand why their ad hoc schemes are not enough before they are willing to spend the time and effort to quantify the requirements through user stories.

However, one point raised in SecurityIsHard seems helpful, and that is to look at whom we are guarding against. One extreme is someone with unlimited resources - obviously no system will be secure against that. The other extreme is perhaps something like a random janitor picking up your thrown away disk containing sensitive data. The answer is something in between. From my experience, this basic question was never thought of when business people talk about security - most are doing it because they have security audits to pass, and others think of "secure" as a general, implicit requirement similar to "reliable", or "expandable".

Which "basic question"? I'm not sure what you mean. How come you've got business people making decision about algorithms (security or otherwise) anyway? Security _is_ ultimately a business issue, so you need to find some way of explaining it to them

First, YES, security is a business issue, and many decisions should be may by business people. The reason I started this page is that I find it very difficult to explain security to business people and hope for some advice on how to do it.

By "basic question", I mean "Whom are we guarding against?". Are we guarding against crackers from the internet? Are we guarding against former employees leaking data to competitors? Are we guarding against industrial spies or criminals? Depending on other system requirements, there may be very cheap, simple and effective defense against each one of these (e.g., for a system with no real need to connect to the internet, simply disconnect the whole system from the internet is already extremely effective against internet crackers). But often, business people thinks that "the system should be secure" is all that needs to be said.

Imagine your customer trying to come up with their own scheme to deal with HighAvailability? issues. They will probably come up with ways that are either expensive and ineffective, or simple and ineffective. There are existing ways to handle many HighAvailability? requirements, but usually you have to specify the need (such as 24x7 no downtime, or max 1hr downtime per month, etc) before you can decide how to do it.

The cases I encountered with security is like that (as mentioned in ReinventingTheWheel), in one case, my client insisted on creating their own encryption and key distribution methods. They have reasons, but IMHO, those are not good enough reasons and what they did does not fully address their concerns either. Yet I find that it is extremely hard to explain why their scheme is no better and probably much worse than most existing freely available protocols and implementations.

For the "Why should we not use our own home-grown algorithm?" question, here are some answers that business people can understand:

The well-known algorithms have been studied, reviewed, and tested for years by experts in many companies and many applications. Do you really think you can do better than they can with only your company's resources?
Implementations of well-known algorithms are available off the shelf, and usually cost little or nothing. Compare that with the cost of implementing and thoroughly debugging your own implementation.
If you use a standard algorithm, your system can interoperate with other systems that use the same algorithm.
You can hire people off the street who know how the algorithm works, or buy some books about it for your existing employees.

Here are some rhetorical questions you can use to get business people to start thinking about security issues:

How valuable to you is the data or resource you are protecting? How valuable would it be to somebody else? How much are you willing to invest in protecting it, and how much do you think others would be willing to invest to try to break your security?
Are you going to have people monitoring the system to detect when attacks occur? How many people? 24/7?
When you detect an attack or a breach, what are you going to do about it?
Which employees will you trust with various levels of access? (Give specific names of people if you can; answers like "the System Administrators" or "the people who need it" are not useful.)
How much are you willing to invest in training people to use the system in an effective and responsible manner?

Thanks for the ideas.

I have already gone through some of them, here are their (wrong) reasons in respond to those questions:

"We know our algorithms is not as good as available ones, but given our constraints (machine too slow, algorithms not available in COBOL for our mainframes, etc), using home-grown algorithms is the best alternative."

Quantify Problem: Unless I can quantify how much worst their home-grown algorithm is, I cannot convince them this "tradeoff" is not a good one.

Additional Problem: Even if I spend the effort to find the weakness in their home-grown algorithm (and I am no security expert), they can either come up with another one, or we will be faced with their constraint (machine too slow, etc), so I either solve that for them too or let them do their home-grown solution. Even though I am sure their performance problem is really due to bad programming, I am in no position to do their programming job for other unrelated reasons.

Interoperate with other systems is not a requirement at all, it is even better if people off the street do not know the algorithm (SecurityThroughObscurity mindset at work, they even think hiding a public key will improve security).
For the how valuable question, they probably never thought of it. It is never mentioned in any requirements. Even if they come up with some values (say, it is worth a million), it will go back to the "Quantify Problem" again -- How can I quantify how much resource can break their home-grown algorithm (it take $x to break your algorithm) without actually breaking it?

Am I missing something? If the business person hires you and asks for a homegrown security system, why don't you give them one?

I (well, actually the company I am working for) was hired to help finish a system and will be responsible for its maintenance. The security is one part of the system. If the security is breached after the system is finished, we will be responsible for fixing it. We could try some self-protection moves, such as having the client claim responsibility for future security problem, but that's just blame shifting and we don't want to do that (at least not yet).

Another reasonable response might be: professional standards. We're not going to knowingly provide you a solution that doesn't work, even if that's what you ask for. And as far as security is concerned, homegrown doesn't work. I'd be interested in a principled reason why one should knowingly provide an inappropriate solution.

Thanks for the idea. But I see 2 difficulties dicussing it that way:

(1) Given that there is no stated requirements for the security level (see the "basic question" above), and we cannot quantify the exact "security level" of different approaches, it is hard to backup the claim that their homegrown solution "doesn't work".

(2) With a tight schedule (well, schedules are always tight), talking about "principle" won't get much response from business people.

Maybe a business person might understand it in terms of core competency. Tell him "If we write our own cryptography we're making a bet that in the long-term we get more bang for our buck by doing it ourselves, than by reaping the benefits of other people's work. Do you actually think that we contain enough cryptographic brainpower in this company to make this bet worth it? Are we a cryptography company, or are we a technical company that needs cryptography for one small part of our operations?"

See recast of the problem below, even if they are convinced, we will only be forced to take up their work (Solution 2).

Thanks a lot for all the ideas. They helped me clear up the problem in my mind. I think the basic problem boils down to this:

Premise 1: Client's programming team has trouble with method X (the standard), due to whatever reasons.

Premise 2: Client propose using method Y (homegrown).

Problem 1: Homegrown method is not secure.

Problem 2: I cannot quantify how "less secure" is the homegrown method vs standard method.

Problem 3: We may be responsible to fix future security problems.

Solution 1 (Cover our ass): Ask the client to agree to be responsible for future security problems since they insist on using method Y. We will be willing to be held responsible if method X is used instead.

Downside: If security problem do appears, it will damage our reputation and our relationship with the client.

Solution 2 (Take up their work): If the client can be convinced that method X will have no problem running on client's hardware, they will use method X. The only way to do that is to do their programming team's work and implement (or find existing usable implementation of) method X into their system.

Downside: We will be taking up extra work and become responsible for another part of the system, which we are not prepared to do so (i.e., no testing environment prepared, etc).

Solution 3 (Ideal case): Convince the client they should use method X, client's programming team implements method X.

Downside: No real downside, just unlikely to happen given Premise 1.

Any other proposed solution is welcomed. Seems like I have been beating my head against the wall trying to get to Solution 3, perhaps I should explore the implications of trying Solution 1 :(

Obviously, its not an ideal situation. I think that the best approach in a situation like this is to give your professional recommendation and let them know that if they veer from this recommendation that any hours you spend fixing subsequent problems will cost them extra. (Solution 1) This sounds unfriendly and unhelpful, but you should protect yourself unless you're really desperate for the work. It's not blame-shifting, it's picking your own work conditions. If you make an honest attempt to offer your best advice, and your client disregards it anyway, why is it your fault? You are under no obligation, ethical or legal, to give away your hours for free because of somebody else's pigheadedness.

As far as reputation, I don't know that I would worry so much about that. Most security breaches are kept very hush-hush, aren't they?

Keep in mind, also, that in the long-term a client like this might not be that good for you anyway. Aren't you supposed to be hired for your expertise? What kind of a client hires an expert and then overrides his expert opinion? Why do they even want you around? And consider this: If you work hard to create a quality product, will they be able to tell that it's quality, and will they be appropriately appreciative in terms of future business?

An update. We finally choose Solution 1, which I now call "Cover our ass" solution. The product is going out of the door, but I have heard rumors that finally someone knowledgeable in the client company have found this out and has voiced objections. I will try to keep this page updated.

One of the problems techs make for themselves trying to get business people to respond to security issues is that both the business people and most security "gurus" focus on confidentiality (keeping secrets) and availability (disaster recovery).

In fact, the biggest ITSec and ComSec risks are associated with integrity, e.g. identity theft. I find it a lot easier to get people's attention with loss of integrity stories than with anything else. I doesn't matter that you have no secrets to keep, or that the data on your web site is all public anyway; what could happen if somebody changed it?

The risks cover simple defacement (embarrassing), through redirecting selected pages (really embarrassing and possibly offensive to your target audience), to subtle changes (say, to a published price plan on a key product line) that aren't evident until you realize you are losing business.

Focus on integrity.

--MarcThibault

CategorySecurity