CSO Online recently reported on a study conducted by the Cloud Security Alliance that listed the top twelve threats to cloud computing. The threats range from data breaches, to advanced persistent threats (APTs), to abuse and nefarious uses of cloud services. For example, the report discusses how malicious actors exploit poorly secured or misconfigured cloud services to abuse compute resources for nefarious purposes, such as DDOS attacks or attempts to exfiltrate data as part of a breach.
What’s clear from both the article and the report is that security needs to be a top priority as organizations develop and deploy applications and workloads in the cloud. That means DevOps and security teams need to integrate teams and tools.
DevOps leaders know that security testing is a crucial part of the continuous testing procedure. They also know that they should invest a large amount of effort in building an extensive testing suite in order to identify as many possible security gaps as possible and verify that the implemented protective activities perform as expected.
Unfortunately, simply knowing what needs to be verified, understanding how tests can be implemented as part of the DevOps pipeline, and improving the confidence in software is not enough. In this post, we discuss why security verification should be one of DevOps teams’ primary concerns, and how to promote security as a central component in the application development and delivery processes.
So, Where Is Security in the Pipeline?
In the software world, where rapid deliveries and on-the-fly responses to business requests have become market standards, different agile methodologies define clear steps that help software organizations meet their business goals and requirements. DevOps principles that have emerged from these agile methodologies help operations teams plan, build, and maintain processes that improve deployment frequency, lower the failure rate, and increase release velocity.
DevOps is rapidly improving and expanding beyond these capabilities in the software world. Now, DevOps principles address the application’s entire ecosystem, including code coverage, functional and performance testing, and even production deployment and release. However, a crucial component was left out of the original principals and has yet to be addressed—security verification.
Security verification is the process of testing the application’s technical security controls and any technical security controls in the environment that are relied upon to protect against vulnerabilities, and it plays an important role in nearly every part of the development process. Software code must be carefully reviewed for possible holes, and software components need to be tested to ensure that they will not be misused. Correct permissions need to be configured during the deployment process, and the production environment must be constantly monitored for possible tampering, infiltration, and inappropriate data extraction.
In many organizations, security verification is handled by a dedicated team that is separate from the product team. Since the late 1990s, when security verification methodologies were introduced, security code review and security testing have been the last steps before deploying software in the production environment, and their results were either patched or sometimes ignored, leaving the website or mobile app exposed to cyber attacks.
The Security Piece of the DevOps Puzzle
The DevOps approach is all about shifting left. Automation of the build process, test execution, and deployments are basic DevOps steps, and this automation requires the involvement of the operations team in every step of the R&D process. Security does not have to be left behind.
DevSecOps practices help integrate security into the R&D process by automating security activities and adding them as building blocks to the CI pipeline. DevSecOps was introduced to ensure that both R&D and DevOps would be responsible for the product’s security. This shared responsibility instills confidence that the software is secure because security verification is done continuously. As a result of this consistent verification, the relevant stakeholders know for sure that it is safe to upload every build that passes the release criteria. This DevSecOps practice eliminates the problematic habit of waiting until later in the release process to perform security activities that might demand code changes later, and instead converts the release timeline into a true CI process, wherein security problems are handled as ordinary, day-to-day tasks.
However, all of this is easier said than done. Many organizations that want to verify and understand their application’s security status often fail to properly articulate their expectations. They use well-known “best practices” and define security standards abstractly, without understanding how they affect the product functionality or which activities need to happen in order to ensure that the software actually meets these standards. Each security threat requires a different type of verification, which must be conducted independently. In order to automate security activities, all security requirements must be clear and thoroughly documented so that nothing will be missed in the automation process.
How Is Continuous Security Actually Done?
Once security requirements have been made clear and have been broken down into manageable tasks, DevSecOps suggests that organizations treat security like any other technical feature in a release. Just like code review, security review should be part of the developer commit procedure. The cloud deployment or the installation packaging process should have a similar review process to ensure that they meet security expectations.
These reviews require security professionals to actually be a part of the team so that they know what is being developed and can plan methods to verify code and functionality. Security engineers should also be part of the team so they are able to identify potential problems as early in the release process as possible using a cloud workload protection solution that provides deep, contextual communication flow visibility within the entire application.
The Path Forward
Organizations should not wait for a breach to occur to increase software security. The DevSecOps approach is a path forward to help organizations reduce the risk of breaches. Implementing a detailed security validation plan that can be executed automatically as part of every release (and even as part of the CI process), and integrating cloud workload protection solutions to monitor and enforce security controls is a good first step.