Secure development is the process of authoring software in such a way as to embrace information security at every stage of the cycle. By addressing information security issues at the design and prototype stages, huge savings in development costs can be made. Additionally, projects can be delivered faster, and post implementation maintenance costs can be minimised. There are a number of ways that this can be undertaken, but the most common procedures involve phased security assessments and reviews that encompass knowledge share; design assessment; component, system, user interface and production testing and regular security health checks.
It has long been documented that security issues & vulnerabilities identified within applications commonly derive from development or design flaws. Although consuming between 5-15% of a project’s overall budget, organisations have learnt that the savings yielded by phased security assessments far outweigh the costs of performing them. Empirical data and industry studies have shown that the absolute cost of fixing a security issue decreases significantly, relative to how early that it is identified in the development cycle.
For example, research conducted by The MIT Sloane School of Management and @stake revealed some interesting statistics: on average organisations caught only a quarter of their software security holes and typically had 7 significant bugs within their enterprise software. These findings verified that fixing the same defects during the testing phase would cost 7 times less than after deployment. Further, that building security into software engineering at the design stage would net a 21% ROSI; waiting until the implementation stage would reduce that to 15% and at the testing stage, the ROSI would fall to 12%. IBM reported similar findings - the cost to fix an error found after product release was 4 to 5 times as much as one uncovered during design, and up to 100 times more than one identified in the design phase.
With all the financial benefits associated with introducing phased security assessments at every stage of the development cycle, it is disappointing that more organisations are not introducing this proactive approach as part of their standard software development procedure. Certainly a lack of education and immaturity in their business, audit and software development processes could possibly provide one explanation. However, not all organisations are naïve in this respect and the question as to why some are choosing to ignore best practice recommendations begs to be asked.
Perhaps one answer could be because organisations have a polarised response to secure development; some will wholeheartedly embrace it and dynamically alter their approach to business processes and controls, whilst others will be blinkered, rejecting it as a costly exercise, too difficult to implement successfully.