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.