I am really happy to say that the latest IEEE Security & Privacy Journal (subscribe if you don't already - $29/year), has a great article called Cost Effective Security, its by my friend Johan Peeters and Paul Dyson. It is not really possible to overstate the importance of cost effectiveness in security. The classic IT security approach of "its perfect or its broken" is a bridge that leads nowhere. Its not a strategy for security, its a CYA. If you can't operationalize and implement your security strategy, then you don't have a security strategy. Its all about tradeoffs, ideally in some sort strategic context that helps you make progress over time, like a security architecture blueprint.
This is what makes me grateful that Johan and Paul wrote Cost Effective Security, they understand the logistics of software development, and describe ways to move forward and improve security in the real world. Additionally, they show how to account for security in an Agile process so it is not just a Big design up front exercise. One of the main issues, the authors tackle is the art and science of creating abuser stories and associating them with user stories in an Agile process. This is very important for three reasons.
1) It gets security out of the passis auditor only mode, where they come in and a) bless or b) complain about a system; and into an active collaborator and implementer -- this is the future for security groups who want to add value to their enterprise.
2) It gets security involved on day 1 of the development project, not the last week before go live when it is too late.
3) It helps security make real, live business tradeoffs anchored in a business value assessment.
The anchoring is provided, not by a "perfect security policy", but by understanding the user stories and their business goals, and then mapping abuser stories to them.
The specification and prioritization of nonfunctional requirements has so far been a somewhat black art in agile development projects. Agile’s fundamental goal is that development projects should deliver systems that are “fit for purpose” rather than ones that deliver grand technical solutions at the expense of functionality or fail to deliver anything at all, but the definition of "fit for a purpose" must include the system's non-functional requirements.
Agile is about early delivery of business value, security needs to get out of the ivory tower, stop building bridges that lead nowhere, and into the business of delivering value, security services that exist in a business context.
See Johan's blog on "Dreams and Nightmares" for some additional thoughts on associating non-functional requirements in an Agile project.
I'll mail them the same question I'm going to ask here...
One of the nice things about a website is that you can tailor your defenses more appropriately to the current threat model knowing that at last theoretically you'll have the option to update your defenses for new threats a a later date, thus deferring investment. You don't always have this choice when you ship client software since you don't have a single place to update.
That said - its a hard balancing act without lots of monitoring where to spend the resources up front to get it "right" and or future-proof and where to spend just enough for now and wait for threats to materialize.
Unlike architectures, scalability, and even functionality security can be an all/nothing proposition. You don't always get a second chance, once the data has been breached you're done for. This makes determining the right security investment a lot tricker under this sort of agile model...
Posted by: Andy Steingruebl | September 18, 2007 at 10:24 PM
I agree, there is no putting the genie back in the bottle. This is not unique to security. Examples spring to mind such as the electronic payment network failing on a busy pre-Christmas Saturday due to overload. You cannot undo that.
These kinds of system characteristics therefore need to be dealt with based on the expected cost of a mishap. Expected cost is defined as the cost of the failure or breach if it were to occur times the probability of an occurrence. I will not deny that both terms are difficult to estimate, but that is not a reason not to do it - just as plans are never executed exactly as they were drawn up, they are still useful. As you become more experienced in making estimates, the more accurate they are likely to be and therefore the more useful, especially if you feed back data on actual incidents into your estimating.
Posted by: Johan Peeters | September 25, 2007 at 02:20 PM