We've been talking about the principles of the Agile Manifesto and how security needs to be addressed as well. The principles are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
In this post:
Customer collaboration over contract negotiation
Traditional contracting processes haven't done a very good job of integrating security as a requirement. Instead they tend to rely on general indemnifications and liabilities to be dredged up after something bad happens and used as clubs and shields to do organizational battle. Obviously this isn't a terribly healthy or productive way to address the issue...
The real solution is to address security up front and then
throughout the process. In theory you could add security requirements to
the contracting process. OWASP had some folks doing work in this area a while back, in fact. However real security has to be implemented during system
development and working with the customer is the perfect way to do this - if you keep the customer focused on security.
Agile methodologies have made a point of aggressively incorporating customer
input and customer feedback into the development process. This leads to
developing software that meets the customer's functional needs. However,
none of the Agile methodologies I have looked at specifically address customers' security requirements
and that is an area of focus that needs to be proactively addressed in any
secure methodology.
You could argue that security requirements should be naturally addressed when building user stories or use cases, but that isn't enough because teams haven't been doing this. This has to be a specific TODO item to address because if it isn't then security will fall by the wayside as the customer focuses on all the cool new functionality they want to include in the next iteration.
Asking questions about security forces you to ask
questions about risk and so "Planning Game" sessions need to include
a risk budget as well as a level of effort budget. Ask customers to make
specific decisions about how much risk they are willing to take on and keep
them informed about the consequences of the features being built. Make sure that customers understand what they are asking for and what the security implications will be. Force the customer to make rankings of what types of data are more valuable or sensitive than others.
The Agile folks are right - using contracts as weapons is a poor approach to getting useful business systems developed and put into production. The increased focus on collaboration is great for addressing business concerns but Agile practicioners need to explicitly address security issues. Customers are certainly capable of making decisions about risk and security, but it is the responsibility of the developers to force the issue.
Comments