From DevOps + Security to DevSecOps – Executive Perspective
The term "DevSecOps" represents a movement where security focused people, processes and technologies are integrated as early as possible into the Software Development Life Cycle (SDLC). As an example, why perform static application security testing (SAST) only in Production when SAST can be performed earlier in the SDLC and perhaps prevent security issues from ever reaching Production.
At ISG we are well aware that the word “security” often evokes negative feelings among software engineering teams. It is traditionally associated with additional programming effort, uncertainty, more involved vs. committed team members (Chickens vs. Pigs), last minute changes, and roadblocks on fast moving development and release cycles. Traditionally, security has been disconnected from engineering and in many cases reporting into a completely different department (CFO perhaps) within the organization. Many software organizes are aligning security functions under the CTO as a way to more easily achieve the needed integration of Security Engineers directly into the SDLC.
Intent Solutions Group takes a Proactive Focus on Software Security. Emphasizing a set of DevOps principles enables our developers to learn more about what they are developing and how it can be exploited by others. Rather than blindly following the required security practices and identified security controls (assuming there are security controls in place), developers start to understand how to think about making their applications secure. As a result, they can derive their own creative ways to identify and solve security problems as part of understanding the challenges associated with secure software architecture and development.
Rather than reacting to new attacks, secure software should be proactively focused on surviving by providing reliability with a reduced attack surface while being quick both to deploy and restore. In other words, our developers worry less about being hacked and more about preventing predictable attacks and quickly recovering from cyber incidents as part of their development activities.
In the past, software security focused on the nature and origin of attacks, as well as measures for preventing attacks. However, most attacks-especially sophisticated attacks-can't be anticipated, which means that fixes are bolted on as new attacks are discovered. The inability to anticipate attacks is why we often see patches coming out in response to new zero-day vulnerabilities.
Practicing DevSecOps helps ensure that software absorbs attacks and continues to function. In other words, the software should bend but not break. This shift in thinking from a prevent to a bend-don't-break mindset allows for a lot more flexibility when it comes to dealing with attacks. Ensuring a secure lifecycle requires the development team to focus on things like continuous integration, automation with infrastructure as code, continuous deployment, automated integrated development platform, integrated static code analysis, integrated dynamic code analysis, and secure architecture through secure coding training.
In the past, software security focused on the nature and origin of attacks, as well as measures for preventing attacks. However, most attacks-especially sophisticated attacks-can't be anticipated, which means that fixes are bolted on as new attacks are discovered. The inability to anticipate attacks is why we often see patches coming out in response to new zero-day vulnerabilities.
In the past, software security focused on the nature and origin of attacks, as well as measures for preventing attacks. However, most attacks-especially sophisticated attacks-can't be anticipated, which means that fixes are bolted on as new attacks are discovered. The inability to anticipate attacks is why we often see patches coming out in response to new zero-day vulnerabilities.
Our best practices include but are not limited to the following:
- Adding automated dynamic (DAST) and static application security testing (SAST) techniques, such as fuzz testing and software penetration testing, to the software development cycle or system integration cycle
- Standardizing the integration cycle to reduce the introduction of faults by using CI/CD processes and technologies.
- Introducing security concerns and constraints to software and system development teams at the inception of projects, rather than applying them after the fact. Ideally, we are able to integrate Security Engineering directly into the Scrum teams as a peer team member instead of as a reviewer.
- Implementation of well defined and enforced source code branching techniques, code reviews.
- The integration of automated regression testing frameworks to ensure more of the application code is tested with each build and deployment.
- Increasingly restricted environments with Product treated as much like a read-only environment as possible.
- Surprising, high quality and regular secure architecture and secure coding training can be one of the easiest and most effective tools. DAST and SAST are getting better but typically won’t find logic errors that could result in vulnerabilities.
