Anatomy of a Straight Answer

You're a software developer, going along minding your own business when some crazy security geek (hopefully a coworker rather than a stranger who just stepped in from the Net) has the nerve to discover that your code is broken. There is, he says, a hole. "How bad is it?" you ask. "That depends," he usually says, and continues with a long treatise covering many hypothetical possibilities (but always veering away from firm opinions). Maybe he asks 20 questions about how your customers deploy your product (most of which you can't answer) . Only if he already knows all about the deployment environment and what your customers are doing with the product will he give you a straight answer, and even then it'll probably sound like an answer plus lecture or disclaimer. What is up with that? Why doesn't anybody seem to be able to give a straight answer about how bad a vulnerability is?

The problem, from the security geek's perspective, is that "it depends" is the straight answer. "How bad is it?" depends on at least two things: expectations and environment.

• Expectations because, if Alice believes she is using world-wide Internet photo publishing software, and later it turns out that anyone on the Internet can see the snapshots she added to her photo library, she is unlikely to call this a security problem even if said Internet user can use a technique the software developer didn't intend. But if Alice believes she is using software to share photos with her friends over the Internet, and later her prospective employer Googles her and finds pictures from that one party because the photo sharing site has an anonymous FTP server on the same box, she will be quick to cry security hole.
• Environment because there's nothing wrong with an anonymous FTP server, and nothing wrong with an access-controlled photo sharing site, but put them together in the wrong way, and Alice is out of a job and hopping mad.

Expectations and deployment environment are especially important in evaluating design flaws. It's a design flaw when the system is implemented exactly the way the designer intends, but the design allows unauthorized users to do more than the system owners or legitimate users expect. Given a design and some expectations, how bad the design flaw is (and even whether it exists) is entirely a function of the deployment environment. Likewise, given a design and a deployment environment, the severity of the design flaw (if any) depends entirely on stakeholders' expectations. So, if you ask a security geek how bad a design flaw is, he is going to spend a lot more time looking into stakeholders' expectations and the environment than into the system you asked him to analyze. This may seem weird, but he's looking there because that's where the answers are.

(In the case of an implementation flaw, proportionally more time may be spent figuring out the direct, technical implications of the flaw, mostly because by the time you've identified the existence of a design flaw, you usually have a pretty good idea how it affects this system in isolation. After that, the analysis is the same as for a design flaw. Mitigation, on the other hand, is usually easier since you can fix the bug without changing anything for your legitimate users or relying on protection in the environment. )

-- Brenda