there is recent thread in linkedin "Financial Crime, Risk, Fraud and Security" group that started with recent news item "The 25 Most Dangerous Programming Errors" ... but got into using encryption to "hide" financial transaction information (as part of preventing crooks from harvesting the information and using it to perform fraudulent transactions). One of the questions was about new RDBMS support for being able to do various kinds of queries against encrypted data (w/o having to 1st decrypt the data to perform the query).

A fundamental issue is dual-use of the account number ... the account number has dual-use vulnerability because it is being used for both "something you know" authentication and part of a large number of transaction business processes.

This creates diametrically opposing requirements ... the "something you know" authentication requires that the information be kept confidential and never divulged (especially to "insiders" which account for the majority of the related exploits) ... while the business transaction operations require it to be readily available.

The "encryption" solution attempts to apply pixie dust magic to both simultaneously never divulge the account number and at the same time make it widely available.

ref:
http://www.garlic.com/~lynn/2009.html#60 The 25 Most Dangerous Programming Errors
http://www.garlic.com/~lynn/2009.html#65 The 25 Most Dangerous Programming Errors

Your emphasis - exactly. I read Frank's 'paper' yesterday and I read it very differently. You've missed emphasising "security is essentially risk management" in the first sentence. i.e. Frank IS saying that economic risk is the turning point of the whole thing. This is unsurprising as Frank is part of Ross's group at Cambridge and they were one of the first groups of people to start talking about security as being essentially an issue of economics.

Interestingly you have left "the best till last", the most important statment in your post is,

"the popular claim that the best security is that which is built in from the beginning."

Is actualy correct and proven beyond doubt. From this aspect "security" in software is equivalent to "quality" in a physical product manufacturing process.

However for a number of reasons most "security gurus" chose not to explain that "security" is to a business process what "quality" is to a physical product manufacturing process.

First off is the distinction between producers and consumers and who bares the cost of defects.

It is well known in physical product manufacturing that quality pays in reduced return rates which have a disproportianate effect on proftability. This is due to the asymetric costs of "rework" and "transportation" on defective products. The cost of the "redesign" is usualy marginal to these costs.

The reason this is not true for software companies is that they only suffer the cost of the "redesign". The "transportation" and "rework" costs fall on the consumer.

Therefor to a software company features and time to market is more of a business issue than either quality or security.

So selling security as a quality issue to software companies is going to have little effect as they have externalised the cost onto their consumers.

It is only the long term cost to their reputation and future sales that will be a determining factor.

Secondly selling quality to a non manufacturing business has always been a bit of a hard sell due to the simple fact it does not lend it's self easily to simple metrics. Therfore to the average business person they can not make a ROI calculation on quality.

However some businesses had it effectivly forced on them by their customers. What quickly became clear was that those organisations that took quality to heart found it improved efficiency. Whilst those that paid lip service to it found that efficiency declined.

Most medium or large businesses now accept that quality is an issue of managment that minimises business waste and improves the effectivness of the work force. Effectivly by dealing with issues in a proactive manner at the point they occure not considerably down stream where the costs have grown exponetialy with distance.

As most security practitioners now accept there is no ROI on security in the traditional sense simply because it is all sunk costs with no metrics for accountable return.

You currently have no measurand to determin expenditure except to say it was either not enough or spent incorectly post an event. That is to prove your worth you have to fail or more difficult show why other business failed. This is not going to be an easy sell to managment.

Worse as the majority of new events are due to existing but unknown defects you realy have no ability to predict where to best apply scarce resources except in the broadest terms.

The similarity between security and quality processes to a non producing business make them broadly the same.

So security needs to be sold to the consumer business in the same way as quality. That is as a method of improving efficiency by increasing productivity of the work force and reducing cost.

However to do this the "ICT security staff" need to be able to make a business case to the organisational managment using the language that business managment use.

Only then will the business take security to heart and reap the benifits in efficiency, whilst also excepting that the occasional failure is acceptable due to having the appropriate mitigation procedures in place.
But unfortunatly that is only a small part of the battle.

The consumer businesses need to force security onto the software companies in the same way that quality was initialy forced onto non manufacturing businesses.

Only then will closed source software vendors take the "design in" principle to heart and give it a priority over features and time to market.

I just discovered that George Hara said this over a year earlier in the blog:

There is a crucial step before "threat modelling": business goals, step which can't be separated from security.
...
The business goals above precede and thus define the framework of the future security modeling.