To start the discussion on why a Secure SDLC is more important now than ever, we need to take a look at the evolution in applications and how they’re being secured. Both applications and the way organizations are tasked with securing them have changed dramatically over the past few decades.
Our modern applications are complex. Apps are now information sharing centers, communicating and collecting data from hundreds of sources in a matter of milliseconds. They’re compiled of in-house code, open source libraries, third-party code and APIs – much of which may come from totally unknown sources; Data is sourced in numerous ways, and sometimes over untrusted networks. Developers have historically not been tasked with ensuring the security of their code, and organizations have historically not properly budgeting application security teams or tools, leaving a huge gap.
And it’s because of these complexities – and the much bigger attack surface they created – that hackers moved from perimeter and network hacking to attacks on applications. While the applications we built and deployed were becoming ever more intricate, security testing processes largely remained the same: Antivirus programs, penetration testing, a Web Application Firewall (WAF) in “advanced” organizations. The number of breaches in total, but especially when looking at hacking attacks, has sharply risen since 2005 – just see the latest Verizon Data Breach Investigation Report graph for a clear visual.
Dig deeper into takeaways from the 2016 Verizon DBIR here.
What Exactly is a Secure SDLC – And How Do I Get There
Improving our security process has to change, if we’re ever going to see a downward trend for application attacks, and perhaps the most successful step you can take towards improving your security is implementing a Secure SDLC, sometimes shortened to SSDLC.
The Secure SDLC is a framework for introducing various aspects of application security – secure coding, security testing, remediation of vulnerabilities, etc. – throughout an organization’s existing SDLC. The idea is to better build security into the application by building security processes into the development cycle.
Learn more about the Secure SDLC here.
Luckily, there are established methodologies you can use as the basis or model for your own Secure SDLC, depending on your development methodology (waterfall or agile) and current processes. These include Microsoft’s SDL, the first of it’s kind, and a great place to start for waterfall-based development processes, along with NIST’s 800-64, Security Considerations in the System Development Life Cycle.
The Three Best Ways to Ensure You Create a Lasting, Strong Secure SDLC
For many, the quest to turn an SDLC into a Secure SDLC probably feels like an impossible task. It’s not going to happen overnight, or even over a month – it will take upwards of a year or two, depending on your current situation, size, and other factors – to fully integrate security throughout your development cycle.
But time and time again, we’re reminded of the importance of building security in. Remember why you’re establishing a Secure SDLC in the first place: The effort, resources, and time you put into forming your Secure SDLC, if done correctly, can drastically cut the effort, resources and time you spend developing and securing every application you’ll conceive of in the future. So, without further ado, here are the three best ways to ensure your Secure SDLC makes it to the future!
Create a plan that involves ALL company stakeholders
The absolute worst thing you could do is to start adding new security processes in the SDLC willy-nilly, with no internal discussions with your team, the developers, the executives. That’s the best way to shoot your Secure SDLC plans right in the foot. A strong Secure SDLC framework can last years and can be flexible and able to change over time or to better fit a changing organization.
But a strong Secure SDLC framework needs to be carefully planned and supported by the organization. Crucial first steps including performing a gap analysis to map out current policies and development milestones and how effective they are, performing an initial risk assessment over your full application portfolio, and determining your Secure SDLC’s goals and measurable KPIs that can be used to measure success of your initiative. Then – make the business case for shifting security to the left and creating your Secure SDLC.
It’s vital to keep each of the aforementioned groups – the security team, development management and upper management – in the loop during this process. Integrating security in your SDLC will not be successful unless you’ve gotten the whole company on board. Without that, your plans for a Secure SDLC will be D.O.A.
Find the best tools and techniques for the job
When you have the rest of the organization on your side, your next step is evaluating your current security tools and processes and seeing what needs to be improved to help both security and development teams better do their jobs.
The right security tools are the ones that developers can easily use and that fit into their current SDLC. Introducing completely new security testing tools (as the case may be) as well as secure coding requirements is going to be an upward battle as it is – making it easy on everyone is a key to making the system work as you wish.
Educate all security stakeholders
All those who design or touch code are security stakeholders in your Secure SDLC. Each of them, from architects to programmers to testers, will at first need your guidance in understanding their role in the Secure SDLC, and then will later need continuous education that should be catered to their specific position and responsibilities.
Your ultimate responsibility in this area is to ensure that the plans you set in motion for a Secure SDLC can and will be followed by the rest of the organization, and that they can each be successful in doing their part in securing your apps. Developers especially need continuous training in secure coding practices.
Read about how Checkmarx helped implement a Secure SDLC here!