Financial Cryptography

13 reasons why security is not a "Requirement"

Jeremy Epstein asked someone why they didn't ask "is it secure?" in the evaluation of a security product. This someone, a government procurer, had no answer other than surprise! Why is this, more generally, Epstein asks? Here's his list:

• People assume the vendor takes care of it.
• They don't know that they should ask.
• They don't know what to ask for.
• They're uncomfortable with the technology.
• They've made a conscious risk assessment.
• They think they're safe.
• They use vulnerability metrics.
• They simply don't believe vendor claims are trustworthy.
• They have reduced security requirements in the POC.
• They don't think it's their job.
• They know that their organization doesn't care.
• They think standards take care of the problem.
• They perform their own testing.

Check the main article for his reasoning on all of these questions. It is encouraging to hear such open questioning of the security world; readers here will know that I advance the Hypotheses that neither vendor nor purchaser know whether a product is "secure". See 8 and 3 above, in that order.

One quibble. In asking "why not," we do enter a troublesome area, scientifically speaking. There are always a hundred reasons not to do something but figuring out which are the real factors and which are the rationalisations is hard. Generally, we as people do better at answering why we actively do something in the positive sense, than why we don't.

If the question had been placed in the context of one of requirements ("why are you buying a security product") and results ("did the one you purchased meet your requirements") then more sense might have come out of it. Which is to say that not all security requirements should be viewed through the narrow lens of security but perhaps through the wider lens of procurement.

Quibbles aside, an encouraging development.

Posted by iang at January 1, 2006 02:38 PM | TrackBack