Those of us who are impacted by the world of security suffer under a sort of love-hate relationship with the word; so much of it is how we build applications, but so much of what is labelled security out there in the rest of the world is utter garbage.
So we tend to spend a lot of our time reverse-engineering popular security thought and finding the security bugs in it. I think I've found another one. Consider this very concise and clear description from Frank Stajano, who has published a draft book section seeking comments:
The viewpoint we shall adopt here, which I believe is the only one leading to robust system security engineering, is that security is essentially risk management. In the context of an adversarial situation, and from the viewpoint of the defender, we identify assets (things you want to protect, e.g. the collection of magazines under your bed), threats (bad things that might happen, e.g. someone stealing those magazines), vulnerabilities (weaknesses that might facilitate the occurrence of a threat, e.g. the fact that you rarely close the bedroom window when you go out), attacks (ways a threat can be made to happen, e.g. coming in through the open window and stealing the magazines—as well as, for good measure, that nice new four-wheel suitcase of yours to carry them away with) and risks (the expected loss caused by each attack, corresponding to the value of the asset involved times the probability that the attack will occur). Then we identify suitable safeguards (a priori defences, e.g. welding steel bars across the window to prevent break-ins) and countermeasures (a posteriori defences, e.g. welding steel bars to the window after a break-in has actually occurred4 , or calling the police). Finally, we implement the defences that are still worth implementing after evaluating their effectiveness and comparing their (certain) cost with the (uncertain) risk they mitigate5
(my emphasies.) That's a good description of how the classical security world sees it. We start by saying, "What's your threat model?" Then out of that we build a security model to deal with those threats. The security model then incorporates some knowledge of risks to manage the tradeoffs.
The bit that's missing is the business. Instead of asking "What's your threat model?" as the first question, it should be "What's your business model?" Security asks that last, and only partly, by asking questions like "what's are the risks?"
Calling security "risk management" then is a sort of nod to the point that security has a purpose within business; and by focussing on some risks, this allows the security modellists to preserve their existing model while tying it to the business. But it is still backwards; it is still seeking to add risks at the end, and will still result in "security" being just the annoying monkey on the back.
Instead, the first question should be "What's your business model?"
This unfortunately opens Pandora's box, because that implies that we can understand a business model. Assuming it is the case that your CISO understands a business model, it does rather imply that the only security we should be pushing is that which is from within. From inside the business, that is. The job of the security people is not therefore to teach and build security models, but to improve the abilities of the business people to incorporate good security as they are doing their business.
Which perhaps brings us full circle to the popular claim that the best security is that which is built in from the beginning.
Posted by iang at January 16, 2009 03:51 AM | TrackBackthere 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.
Posted by: Ian at January 16, 2009 01:05 PMInterestingly 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.
Posted by: Clive Robinson at January 18, 2009 03:22 AMI 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.