SDLC Security Foundation

Early, often, & coupled with training

Each system development effort has a unique set of challenges that can instigate deviation from software assurance best practices.  It is the role of engineering professionals to highlight these deficiencies and be staunch proponents of security during the earlier stages of the SDLC.  It is this early involvement that ultimately solidifies the foundation upon which secure system development can occur. Contrastingly, focusing on security solely in the latter stages of development can be likened to pouring foundation near the end of a construction project; you’re setting yourself up for failure.

A 2010 IBM study provides clear fiscal justification for the prioritization of early intervention.  Their study concludes that remediating security issues was 15-100 times less expensive during development and design.

If we all know early involvement is pivotal, then why do we keep making the same mistakes?  Two factors fuel this repetitiously bad behavior. First – large scale development efforts often grow from of niche prototypes.  Engineers can easily become laser focused on functionality in a controlled environment when creating these initial prototypes. The resulting failure to account for external influencing factors makes the system ripe for exploitation by hackers.

The second (arguably more common) distractor from early prioritization of security stems from expense.  Businesses investing in software are taking a taking a hefty monetary risk; investing resources with the hope of ultimately yielding profit.  Some of these ventures will inevitably fail. It therefore takes a lot of gravitas for a company to risk capital early in the SDLC on features that won’t payoff until the system is fully matured and deployed.

Remediation – How do we change the tide?

Companies are justified in their reluctance to focus on security; namely because the manpower needed to solidify sound security processes is expensive.  The good news is that this initial expense does dwindle over time. To achieve executive level buy-in, these initial costs must be seen as only short term expenditures with long term positive fiscal impacts.  

Benefits from these investments quickly radiate to other development efforts within an organization.  For example, a developer deeply ingrained in an SDLC that prioritizes security will learn how to design countermeasures in response to real world adviseral techniquest/tactics.  These defensive coding tactics are solidified early within one development effort and then seamlessly shifted to the next coding effort with no added expenditure. It’s also feasible to assume that these skills can permeate to other business units in the organization via information sharing activities; lunch ‘n learns and all-hands training.  

These benefits can however easily be lost if management falls into one of the common pitfalls.  Well intentioned managers will sometimes spend vast sums of money to purchase “state of the art” tools that bolster security;  static/dynamic code analysis tools alone can have starting costs exceeding $100k. Some of these tools are truly very useful! However, they can also encapsulate fiscal benefits within only a single SDLC.  Over reliance upon these automated tools will likely also stifle sincere technical growth and comprehension among development teams.

Training your development staff is therefore exponentially more beneficial than purchasing tools. Automated tools are great – but only in the hands of a development staff with the technical maturity needed to wield them.  

Bottom line – Companies need to invest in training.  Developers and systems engineers are smart people diligently striving to create the best possible solution.  Increasing their technical prowess will therefore influence their design decisions and daily development efforts.