What is the best development method for security?

In answer to someone on CISSPforum asking for advice about the impact of various software development lifecycles, methods or (as if we need another ology) methodologies, I asserted that the SDLC method affects the way or the manner in which infosec is achieved (spec'd, built, confirmed, delivered, used, managed, monitored, maintained ...) more than how effective it ends up being.

There are pros and cons to all the methods - different strengths and weaknesses, different purposes, opportunities, risks and constraints. Software or systems development involves a load of trade-off and compromises. For example, if information risks absolutely must be minimized, formal methods are a good way to achieve that ... at huge cost in terms of both the investment of money and time for the development, and the functionality and rigidity of the developed system. However, an even better way to minimize the risk is to avoid using software, sidestepping the whole issue!

In most circumstances, I would argue that other factors are more significant in relation to the information security achieved in the developed system than the choice of development method e.g.:

• Governance, management and compliance arrangements, especially around the extended dev team and the key stakeholders;
• Strategies (e.g. business drivers for information security), priorities, resources available (including maturity, skills and competence on infosec matters - not just $$$);
• Policies and standards, especially good security practices embedding sound principles such as:
• Don't bolt it on - build security in;
• Be information risk-driven;
• Address CIA and other security, privacy, compliance and related matters;
• Secure the whole system, not just the software;
• Focus on important security requirements and controls, taking additional care, increasing both strength and assurance over those;
• Later security, in anticipation of layers being breached: make it harder and more costly for adversaries and incidents to occur;
• Trust but verify;
• Accept that perfect or absolute security is literally unachievable, and security maturity is more quest than goal, hence provide for resilience, recovery and contingency as well as incident management and continuous improvement.
• Well-defined critical decision points, sometimes known as hurdles, stage gates etc., plus the associated criteria and assurance requirements, plus the associated management processes to measure progress, handle issues, re-prioritize ...;
• Corporate culture, attitudes towards information risk, infosec, cybersec, IT, compliance etc., among management, the intended system users, IT and the dev team, plus awareness and training;
• Documentation: more than simply red tape, good quality documentation on information risk and security indicates a mature, considered, rational approach, facilitates wider involvement plus review and authorization, captures good practices and helps those not closely involved with the project appreciate what is being developed, how and why;
• Systems thinking: alongside people, hardware, networks and other system, and dynamics, the software is just part of the bigger thing being developed;
• Team working: high performance teamwork can achieve more, better security and higher quality products with the same resources, especially if the extended team includes a wide range of experts, users, administrators, managers and more;
• Suitable metrics, such that 'more, better security and higher quality products' is more than just a hand-waving notion, becoming criteria, measures and drivers;
• Risk and change management practices and attitudes, maturity, support, drive etc.;
• Most of all, the deep understanding that underpins sound requirements specs, planning and execution, and leadership: infosec is an integral part not a bolt-on, ideally to the point that it is taken for granted by all concerned that It Will Be Done Properly.

I would love an opportunity to try out dev-races, where two or more development teams set out in parallel to build and deliver whatever it is, in friendly competition with each other. They will all have the same fixed specs for some aspects of the delivery, but latitude to innovate in other respects e.g. methods/approaches.  At the appropriate points during the project, the 'losers' admit defeat and either depart or join the 'winners', pushing through the final, toughest activities together on the home straight.  At first glance, it sounds like it will double the costs ... but that's only for the early stages, and has the advantages of improving both motivation and the end product.  Personally, from both the security and business perspectives, I see more investment in the early stages as an opportunity more than a cost!