Back in 2004, I wrote a blog about secure development or what we now refer to as DevSecOps. Owning a leading penetration firm, we were doing a lot of evangelising about the secure development lifecycle (SDLC). Anyway, although the blog is well on its way to entering its second decade, I think it's just as relevant today as they was then and with pertinent lessons to learn. And, this is why I want to share it with you.
Here's what I wrote.
Secure Development: a polarised response
Thankfully these days' assessing the security of an application prior to implementation is a normal process for most organisations. Organisations accept the view that the earlier in the implementation cycle that security issues are identified, the greater the return on investment (ROI). However, with such a mature attitude to implementation, it is hard to understand why organisations are not applying the same principals to the software development cycle as a whole. In fact currently there are only a limited few that are following best practice recommendations in regard to secure development and reaping the financial rewards that increased development controls bring.
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 (penetration tests) 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 and 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.
Typically an organisation's culture has largely determined whether a program of secure development has been implemented. Organisations that possess conventional cultures usually present the most resistance to any sort of change implementation, let alone security. Their environments are dogmatic and strictly compartmentalised along departmental boundaries. They are comfortable leaving the software development process as it is – systematically separated out into planning, design, testing and implementation; addressing the security aspect of the project at the 11th hour or worse still, once projects have gone live.
Organisations such as these remain culturally static until they are driven by a new business need or are subjected to a compelling event.
Whilst an organisation's culture can't be changed overnight, there are some organisations that have moved into a more proactive mode and successfully adopted secure development integration. Their achievements have resulted from assuming a culture of shared beliefs, values and behaviours. And, their environments are filled with positive change enforcement.
For example, they educate their personnel in the benefits of early secure development implementation. Thus, Project Leaders and their Managers promote a team atmosphere where work is produced as defect-free as possible before being passed to the next development stage or to the customer. By encouraging a level of mutual respect they have overcome the suspicion and opposition that software engineers have had of security auditors – the party responsible for identifying vulnerabilities and weaknesses within their software. Consequently as problems found are seen to be with the product and not the producers each participant is receptive to suggestions for improvement and progress occurs more quickly. Operating in this manner also provides the opportunity for knowledge share; by establishing effective forums less experienced team members are able to increase their learning while still making useful contributions. Ultimately though, they recognise that spending the time on quality activities up front will save time for the whole organisation in the long run, as well as increasing customer satisfaction by releasing cleaner products in version 1.0.
To conclude, effective secure development will only become more widespread when organisations receive better education. To achieve this, security consultancies need to adopt an active campaign, and the media need to provide coverage. Software Development Managers must also prepare their departments for change; they need to understand the benefits of early secure development implementation and be able to eliminate any animosity or suspicion their teams may have of security consultancies.
Through fuller integration of security and development activities, the effectiveness and efficiency of security assessment will be increased and streamlined, the associated costs greatly reduced and organisations will enjoy the return on security investments (ROSI) at a greater rate. Until then, however, those organisations that are already using secure development implementation early in their development cycles will be able to continue to reap greater advantages over their competition.
Now I want to hear from you…
Tell me, in the comments below, are you seeing more progress when it comes to DevSecOps? Or, is getting buy-in still an uphill struggle? I'm especially keen to hear from those who've been using secure software development tools, like Secure Code Warror. Are they helping?
And, if you want to continue the conversation, plus others, AND believe in building a more diverse and inclusive security industry, join my IN Security Tribe.
