I’ve quietly been compiling a list of “laws” for my paradigm on security. I like lists of “laws;” they help put one into a proper mindset where questions are answered before they’re asked, leaving time for more important things. I used to have such a list of laws when it came to dating girls back when I was in college. They were great, but I’m still unmarried so maybe they worked too well…oops!
One of my little laws (they do frollick in a quiet pasture like my little ponies) sobs a lot these days:
Security is not an enabler except in three cases. First, when the organization is in the business of security (software, hardware, services…). Second, when security is required for the business path to exist. Third, when economic forces suggest that security is the cost-effective answer (e.g. cost of security is less than the cost of fines or lawsuits for breaches).
I often hear about how security should be an enabler and not an inhibitor. I don’t buy that. In regards to the second case above, this only happens when a regulation, expectation, or law exists that places an economic leverage on the organization to meet a level of security, which can then allow business to occur. This is a natural extension of the inverse relationship between usability and security. This says to me all other security efforts are not enablers, so move on to more important matters and proper frames of mind.