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.
What about the case where the application of security allows an organisation to pursue new business models that would otherwise not be viable due to the untreated risk level? The example of load agents being able to process applications in a customers location (or home) in real time rather than having to collect the data in the field and then process on return to the office? This model gives the loaning organisation greater flexibility and opportunity to take market share by appearing to be more responsive, but without appropriate security controls the risk level would not be viable.