VP, Hybrid Cloud Practice
In today’s digital age, security is more important than ever. The business forces driving the adoption of DevOps have everything to do with providing customers with superior experiences, providing the agility to adapt to market changes, and increasing the digital resiliency of an organization. These are make-or-break issues for top enterprise leadership.
A study conducted by researchers with North Carolina State University’s ERM Initiative found that the attitude held by 300 top CXOs of companies that enterprise executives see these digital delivery issues as their top concern in the coming year.
The study found that these leaders agreed the number one risk enterprises face is right-sizing legacy IT and existing operations to compete against digital-native competitors. That risk of digital disruption is existential and is ranked above any kind of regulatory or cybersecurity concerns.
“Enabling change continues to be a significant priority for just about every organization on the planet, for change has become a way of life for most companies,” the report explained. “Resistance to necessary change spawned by disruptive innovations that alter business fundamentals can be lethal.”
CISOs and IT security leaders need to be mindful that resisting DevOps means resisting the necessary change to adapt. DevOps practices and tools are some of the most powerful forces for change available to an organization. If CISOs and IT security are focusing on bringing value to their organization and to senior leadership, they’ve got to understand that their priorities must line up with this fact of the IT universe.
IT security leaders must adjust to DevOps and not the other way around. This means finding ways to help the organization deliver software faster, with appropriate controls built into this streamlined process — meaning DevSecOps. This is what CEOs demand of security and risk leadership today, and is reflected by numerous studies.
A recent survey conducted by ThreatStack showed that 68% of companies report their CEOs demand that DevOps and security teams don’t do anything to slow down impede the business. Another by Freeform Dynamics on behalf of Checkmarx found that at 76% of organizations, executives don’t care how organizations deliver quickly, frequently, and safely—they just want them to get it done.
In this article, we’ll explore what DevSecOps is and why you should care about adding security into your application development process. We’ll also discuss areas where you might want to consider investing to improve your organization’s cybersecurity posture. Finally, we’ll talk about some ways that you can get started right away on implementing DevSecOps at your company!
What is DevSecOps and why should you care about security in the development process?
DevOps is a term that is used to describe the collaborative effort of the Development and Operations team members to improve the flow of information and shorten the software development life cycle (SDLC). The goal of DevOps is to improve the quality of the product and speed up the time it takes to get a product to market.
The biggest obstacle to achieving those goals is Security, which has been traditionally the job of either the Operations or a standalone Security team. By integrating security into the DevOps process from the beginning, you can benefit from a shorter development life cycle to improve overall product quality as well as security. Having security involved in DevOps, security is better aligned with the business goals and outcomes. This means embracing the efficiency of DevOps but gaining the assurance and speed of DevSecOps.
Traditionally, security has had a hard enough time trying to secure an application development at the end of a traditional waterfall process. Tying to chase after the speeding train of DevOps will be nearly impossible—unless security gets on for the ride.
To be successful in including security in the SDLC without slowing delivery, security must be embedded not bolted on at the end. However, once an organization begins adopting DevOps, it’s an even greater issue because of the accelerated delivery speed DevOps provides.
However, as more and more businesses are moving to the cloud, security has become a paramount concern. To ensure that your data is safe and secure, you need to add security to the DevOps process. By doing so, you can help to ensure that your product is not only released faster with better quality but also secure.
How can you get started on implementing DevSecOps at your company?
As with any transformational change, the adoption and transition to DevOps provide IT security leaders the unprecedented opportunity to reengineer security processes and mindsets in the mold that they’ve always wanted. When an organization is already radically changing how software is delivered it’s a natural time to architect and embed security into that process as it undergoes that transformation.
This is the fundamental case for DevSecOps— it’s a favorable way to finally trojan horse all the security improvements and enhancements into the IT organization for which IT security executives have been advocating for years.
One of the best ways to get started on implementing DevSecOps at your company is to start with small changes. You can begin by integrating security into your development process in a more automated way. This can help to streamline the process and make it more efficient. You can also make sure that security is considered from the beginning of the development process, and not as an afterthought.
At first, there may be pushback to the changes, but reframing the changes as being focused on ensuring a quality user experience, in the long run, can alleviate concerns. Now, it’s become less of a security concern and become more about quality assurance.
Taking a Page From DevOps
Development and Operations teams are using DevOps to deliver faster. Development can make a change and have it tested and deployed as fast as they want. So, why shouldn’t security be?
According to a Veracode State of Software Security report, once software vulnerabilities are identified, organizations take 472 days to fix 75% of software vulnerabilities found. That means the remaining 25% of vulnerabilities persist for at least 15 months after being discovered. To put this into perspective, research by RAND Corporation found that it takes just 22 days for attackers to exploit vulnerabilities.
IT security executives should care about DevSecOps because it is an exceedingly effective engine for making real progress in identifying and addressing security flaws. The emphasis in DevOps is on deploying faster and making incremental improvements to software through continuous changes.
Embracing DevSecOps turns that lens around on fixing vulnerabilities, and IT executives will find that development teams can now make swift changes to address security vulnerabilities. DevSecOps isn’t just optimal for an occasional fire drill but is also critical to sustaining a long-term and expedited reduction of flaws over time.
With DevSecOps, enterprises are identifying and fixing flaws continuously throughout an application lifecycle. The process is just another part of the continuous improvement of the application. The outcome is that far more of the vulnerabilities will be resolved compared to organizations that only scan and deploy security fixes outside of an application release.
How can the vulnerabilities be found to begin with? While there are a host of automated tools available, each with unique benefits, that are commonly used in the agile software development cycle, it’s not a question of which tools, but which scanning methodologies should be used.
While DevOps tends to focus on the application side of delivery, a comprehensive DevSecOps strategy needs to focus not only on application development but also the underlying infrastructure. The question is, what scans or frameworks should be used. While there are a number of scans or frameworks available, there are foundational ones available.
What is Static Application Security Testing (SAST)?
Static application security testing (SAST), or white-box testing, is a testing methodology that analyzes source code to find security vulnerabilities that open an application susceptible to attack. A SAST scan is performed before code compilation.
Using SAST scanning developers can now identify vulnerabilities during development and resolve issues. Doing so mitigates the possibility of passing on vulnerabilities to the final release of the application. A key part of SAST tools is to provide developers real-time feedback as they code, helping them fix issues before they pass the code to the next phase of the SDLC.
What is Dynamic Application Security Testing (DAST)?
Unlike SAST, dynamic application security testing (DAST) is black-box testing because it is performed from the outside in. DAST identifies vulnerabilities of a running application by scanning web pages, and locating web services endpoints, inputs and outputs. Additionally, since DAST is black-box testing the analysis works to simulate penetration testing to uncover exploitable vulnerabilities and business logic issues from a hacker’s point of view.
It should be noted that because DAST tends to happen later in the SDLC, vulnerabilities are identified later in the development process and may result in remediation being rushed or delayed.
What is Software Composition Analysis (SCA)?
Software composition analysis (SCA) scanning is used to locate weaknesses in proprietary code and vulnerabilities in open source code. More and more developers are using open source libraries, therefore increasing the need for SCA. The SCA scan identifies software licenses, deprecated dependencies, known vulnerabilities, and potential exploits.
SCA enables development teams to continue to use prepackaged code without introducing vulnerabilities. This is because SCA allows teams to measure and manage the exposure and license compliance of an application. What also makes SCA powerful is that it can be used with cloud-native technologies and architectures, including containerized environments. This automates the detection of publicly disclosed vulnerabilities within your containers and prevents those available in public registries, such as Docker Hub, from being used.
The ability to identify vulnerabilities in development is critical to reducing application risks – all of which can be a potential entry point for malicious actors, as we’ve learned from the Equifax and SolarWinds breaches.
What is Open Web Application Security Project (OWASP)?
OWASP scanning detects a wide range of vulnerabilities and is typically referred to as ‘OWASP Top 10’. The 10, refers to 10 categories a vulnerability is classified as. The 10 categories are broad and cover not only application vulnerabilities, but also infrastructure configuration vulnerabilities. This is important to make sure load balancers, proxy servers, web servers, etc. don’t introduce vulnerabilities that increase an organization’s attack surface.
Including OWASP scanning as part of the development process, both developers and infrastructure teams can be alerted to and remediate vulnerabilities earlier in the SDLC. This is especially true when organizations use infrastructure-as-code (IaC) and configuration-as-code (CaC) methodologies and tools.
What are Center For Internet Security (CIS) Benchmarks?
Center for Internet Security (CIS) Benchmarks recommended configurations for a broad range of infrastructure components such as operating systems, server software, and cloud resources, to name a few. While CIS Benchmarks may be more stringent than a company requires, they are a good baseline to start or measure against to determine an organization’s security posture.
For DevSecOps, the usage of CIS Benchmarks should be used as part of IaC and CaC. CIS scanning does not need to be part of the build and release process. Instead, it should take place as the operations and security teams are defining an organization’s infrastructure.
For organizations that adhere to regulations and compliance, CIS Benchmarks are a must. Many industry frameworks recognize the CIS Benchmarks, including the Payment Card Industry (PCI), HIPAA, and even the Department of Defense (DoD) Cloud Computing Security Requirements Guide (SRG).
What are Security Technical Implementation Guides (STIG)?
The Security Technical Implementation Guides (STIG) are similar to CIS Benchmarks. The difference being that STIG is defined by the Defense Information Systems Agency (DISA).
Both CIS and STIG are trusted worldwide. In fact, The DoD Cloud Computing Security Requirements Guide (SRG), version 1, Release 3 states: “Impact Level 2: While the use of STIGs and SRGs by CSPs is preferable, industry-standard baselines such as those provided by the Center for Internet Security (CIS) Benchmarks are an acceptable alternative to the STIGs and SRGs.” STIG and CIS are focused on system configuration instead of the process to measure and apply changes. Organizations must be aware that whether using STIG or CIS, it’s nearly impossible to adhere to the standards while having a system that performs as expected. Organizations will need to make trade-offs and mitigating controls when the standards cannot be applied in their entirety.
What is Zero Trust?
Zero Trust, the term first coined by John Kindervag of Forrester in 2010, means to never implicitly trust anything within or outside of an organization’s ecosystem. Therefore, everything needs to be verified and authenticated. Zero Trust is applied at all layers of an application – from data to the user experience.
Adopting DevSecOps emphasizes security throughout the SDLC. Implementing Zero Trust as part of DevSecOps focuses on creating applications, environments, and infrastructure consistently while enforcing a level of distrust on users and systems that attempt to gain access.
With the proliferation of cybercrime and data breaches, organizations are faced with an uphill battle when it comes to protecting their intellectual property and customer data. DevSecOps can be a key component in helping organizations protect themselves from these threats by creating safer products.
Whether an organization is in the cloud, on-premises, or hybrid, application attacks will continue to increase. As organizations rely on applications to maintain business continuity, security teams should consider how and which security controls can be integrated with DevOps without impacting productivity. However, the security market is often shrouded by acronyms and buzzwords.
With the increase in automated security testing tools that offer scanning capabilities such as SAST, DAST, and SCA, or using baselines like CIS Benchmarks or STIG to implement Zero Trust, it’s important to understand the difference between each practice, and when to use them in the SDLC.
DevSecOps is the convergence of software development and IT operations with security and aims to continuously build, test, secure, and release software. Understandably, DevOps is becoming an integral part of any business as it facilitates delivering new products to end-users faster and driving increased revenue. However, failure to secure these digital assets can open an organization to cyberattacks. Which may result in operational downtime, loss of customer trust, and scrutiny by regulatory bodies. The continued increase in application attacks proves that enterprises must proactively address security issues earlier in the SDLC.
An important part of implementing DevSecOps is getting buy-in from all members of your team. Everyone needs to be on board with the new security measures for them to be effective. And finally, you need to make sure that you have the right tools and resources in place to support your security. With the right planning and execution application delivery will be faster and more secure than ever before.
If you’d like to find out about our services & how we can help your organization today,
click here for more information.