Ask Why Until They Slap You

As I mentioned last week, real benefit is subjective. I would derive no benefit whatsoever from tickets to a football game. Curling, on the other hand, is intriguing; attending a curling match would benefit me a great deal. In this case, based on the relative sizes of the curling and football industries in the United States, I am almost certainly in the minority. What meets one person's needs perfectly may not do a thing for someone else.

Furthermore, attending a curling match would benefit me because I like observing human, real-time approaches to infinitely variable analog control problems, whereas someone else might benefit by the opportunity to cheer for her son, who is playing on one of the teams. Which is to say, a single solution can have very different benefits for different people.

So how does one tell if, say, a security SaaS provides real benefit? If you're considering a security product, the steps go:

1. Decide what you actually need.
2. Determine whether the technological controls provided by the solution you are considering will get you that.

Those are both pretty big topics, so this week, let's delve into deciding what you actually need. Erik Simmons, Intel's requirements guru, has a surprisingly effective suggestion for eliciting the real requirements: Ask why until they slap you.

Requirements Guy: Why do you want to buy a product that filters bad HTTP stuff out?
Customer: Because I don't want my employees running malicious Javascript, installing Trojan horses, catching viruses, ...

Vendors in conversation with potential customers would probably stop here if they do everything mentioned (which of course we do), since being slapped by your customer is not what most people set out to do in the morning. But you, evaluating us, should not stop.

Requirements Guy: Why not?
Customer (giving Requirements Guy a funny look): Because that would be BAD! Everyone knows that!
Requirements Guy: Why would it be bad?
Customer (enunciating very clearly & speaking louder and louder): My employees would be unable to get any work done. My IT department would need more people to clean up the mess. My super-secret company data would go flying off to the four winds and all the regulatory agencies that apply in my line of work would shout at me. My name would be on the front page of the Wall Street Journal!

Requirements Guy is getting warm. He has unearthed several underlying concerns that are candidates for what Customer actually needs. But right now, only one of these concerns (people outside the company getting a copy of confidential corporate data) refers to an asset that can be directly manipulated by a computer. He needs to keep going to nail down the other concerns in a way that is useful for considering security benefit. Let's do one more.

Requirements Guy: Why wouldn't your employees be able to do their work?
Customer: Their computers wouldn't work!
Requirements Guy: Why would that stop the employees from getting their work done?
Customer: Their computers are the only way to get at all the corporate information they have to look at and create.

This time, Requirements Guy should really stop: one more why, and he's done for. He has an underlying asset (corporate information) and concern (availability), so let's say that the second concern this customer cares about is availability of information. You would need to follow up those other leads until you feel you've covered the important things you need.

Security can't ever give you the whole benefit you're looking for, only stop attackers from taking the benefit away. Therefore, to finish defining the security benefit you're looking for, you need one more thing: an attacker. For this purpose, the important part about an attacker is: before they start attacking, where are they in relation to your system and what can they already do? In this case, let's say you are expecting an attacker on the Internet (a good idea), and you assume he can control content on Web sites your employees visit. You would need to keep following leads to come up with a complete list of attackers you care about. For now, the benefit you are looking for becomes "Keep an attacker who controls Internet web sites my employees visit from denying my employees access to my corporate information." This is not going to be the only security benefit you want, but I'll use it as an example next week when I talk about figuring out whether controls a vendor offers make the benefit you want possible.

Now let's suppose I'm Zscaler. As a security SaaS, how do I ensure that I'm providing real benefit? The steps go:

1. Derive the underlying concerns of a substantial set of my customers or prospective customers.
2. Ensure the technological controls I provide can be configured to meet those underlying concerns in the space I've set out to protect.

This doesn't mean the controls can't do anything else, but it sets a minimum bar for the benefit provided by the controls. This, I'm happy to say, is exactly what Zscaler is doing; the hypothetical customer scenario above is one example.

--Brenda