My question to Jamie Rees had to do with "selling" security's value to your client as part of the application development process. (Because we all know we should make apps. secure from the ground up, right? But, then, we also know that we're supposed to floss every night, too. And we all know how that plays out for most people. Your faithful blogger included.)
I was thinking of I/T security in terms of risk management. To wit: A data breach costs money. If data related to financial information (credit card numbers, Social Security / Social Insurance numbers, bank account numbers), the company whose data was leaked is typically on the hook for years of credit monitoring for each person affected.
Then there are the lump-sum costs. Things like the hit to customer goodwill (which sounds really squishy, but there are accountants who specialise in quantifying that in hard cash). Finding and patching the weaknesses in the system does not come cheap either. Depending on the industry, third-party audits might be required. And if the security lapses were super-egregious, heads will roll, which entails (at a minimum) the costs of hiring and training.
So I figured that this could be gelled down to a simple formula:
Average cost per breach * Likelihood of breach per year = Annual risk
If that "annual risk" (quantified in dollars) is greater than the budgeted amount for security in the Statement of Work, it should be a no-brainer, right?
Jamie Rees had a few thoughts and suggestions, including the nugget that in security more than anything else, you have to protect yourself from entropy. Because waiting until a crisis to fix a hole means that you will focus on that crisis alone. But once that energy's expended, organisational fatigue will guarantee that there will few (if any) resources spent on proactively preventing the next crisis. (Sound familiar?)
But as I was digesting this all down for my notes, someone else raised a hand and asked the question as it should have been phrased in the first place: "How do I sell my clients on security without selling fear?" And, wham! Synapses linked up, proverbial light bulbs went on. (For all I know, the heavens opened to the sound of angel-choirs. But Suite 201 of the Venn Centre is really, really well-soundproofed, so don't quote me on that.)
For the record, Mr. Rees's answer boiled down to mapping security to the project goals. (Like, I might add, y'do for everything. We're All About the goals, not the features here.)
But what hit me was security, really, is just another facet of Quality Assurance. A very specific facet, it's true--and one perhaps almost large enough to overshadow its general category.
But the thing that's Quality Assurance has proven over and over since Dr. Deming pioneered the discipline is that quality ultimately pays for itself. Namely, because focusing on quality forces you to take a hard look at your organisation and its processes. A relentless focus on quality allows far less room for the politics of personality--which includes the always-regretable "rock star" culture. And it has no mercy for the "But we've always done it that way" argument.
So, when pitching my services to future clients, you can bet that I will be pointing out how developing an application for their business buys them process consulting from an unbiased 3rd party as part of the package. And all for the low, low cost of higher quality. :~)
