DevOps practitioners often omit security testing when building their DevOps pipelines because security is often linked with slow-moving business units and outdated policies. These characteristics conflict with the overall goal of DevOps, which is to improve the software delivery process. However, security plays an important role in the software development lifecycle and must be addressed in all applications. Incorporating security into different stages of the DevOps pipeline will not only start to automate security, but will allow your security process to become traceable and easily repeatable. For instance, static code analysis could be done on each code commit, and penetration testing could be completed as part of the deployment phase. In this blog post, I will present two common tools that can be used during deployment that allow for automated security tests: Gauntlt and OWASP Zed Attack Proxy (ZAP).

These tools allow developers and operators to automatically run common attacks when deploying a web application into production. Applying these tools is an easy way to protect your web application from the most common and most easily executed attacks, and it will keep your consumers and content safe. These tools are not mutually exclusive. Gauntlt allows team members to write custom attacks for each specific web application, and ZAP has a pre-determined set of attacks and scanners that perform tests that cover the most popular vulnerabilities in web applications.

Gauntlt

Gauntlt is a security testing tool that incorporates existing organizational tools that are used for security testing, i.e. nmap. This tool is built on the Cucumber framework and provides an easy to read language that gives users the ability to write their own attacks. Gauntlt also provides example attacks for most common attacks on its Github repo. A Gauntlt attack file consists of primarily two sections: the background and the scenarios. The background section ensures that the packages needed for the attacks are installed and that developers can connect to the host that is being tested for security. The scenario section is where the attacks, or tests, are actually performed. Operational staff can have an unlimited number of scenarios, but it is best practice to have a small number of them. That way each attack file will not get too broad.

I have prepared a short walkthrough that shows how to set up to run Gauntlt tests for your web application. I will be using the Gauntlt starter kit to set up the environment quickly. You will need Vagrant, VirtualBox, and Git installed on your local machine for this demo.

1. To clone the Gauntlt starter kit, open a terminal window and type
   git clone https://github.com/kontostathisk/gauntlt-starter-kit.git
   
2. To access the correct directory for Vagrantfile, type
   cd ./gauntlt-starter-kit/vagrant/gauntlt/
   
   
3. To build your box with all of the necessary packages pre-installed, type
   vagrant up
   
   
4. To access your box and and run the attacks, type
   vagrant ssh
   
   
5. To access the directory of simple attacks that have been pre-written, type
   cd /vagrant/attacks
   
   
6. To run the nmap security test, type
   gauntlt nmap

This simple example shows a Gauntlt attack file with only one scenario. You can see in the background section that we have to make sure that nmap is installed and that we can ping scanme.nmap.org. The green text indicates that the nmap package is installed and we can make a connection to an external server. The scenario shown gets a network map of google.com, and we check to make sure that port 80 is open, as it should be.

7. To run all of your files that have an ".attack" file extension, type gauntlt. This command will show you the nmap attack file explained as well as a sslyze attack on google.com:443.

The last step is where DevOps really comes into play because with just one simple command you could potentially run thousands of security tests, scans, and attacks that are specifically written for your application.

Integrating Gauntlt into your continuous integration (CI) server is another way to automate security for your application. There are several ways to incorporate Gauntlt into your DevOps pipeline. The first is to start with the walkthrough above and allow Gauntlt to run on its own box and incorporate a build step in your CI server that tells the Gauntlt box to run its suite of attacks after the application has been deployed. Another way to incorporate Gauntlt into you DevOps pipeline is to run the attacks directly in the CI box as one of the build steps.

Here is a set up that uses Travis CI, which builds a project and runs several Gauntlt attacks on the server. Once you navigate to that page you can see the yaml that is being used to configure the Travis box and the different attack files that are being used by Gauntlt. This build shows the process of the CI server when running security tests. As you scroll down, you can see the Gauntlt attacks being run, and they are all passing the Gauntlt tests. If any of those security tests fails, the entire build would fail and prevent you from deploying your insecure application. Here is an example of a build that failed because of a failed security test. The code for this build is hosted here. You can fork these two repositories and change things up slightly to get a better understanding of the technology. The Travis CI Getting Started Guide provides simple steps to getting up and running with Travis CI.

OWASP ZAP

ZAP is used to test for the most common vulnerabilities that accompany web applications. For instance, SQL injection and cross-site scripting are two types of attacks that can be prevented with the use of ZAP. You can also leverage ZAP in several different ways. There is a UI available on the downloads page. When you install and open this application, you will see a quick-start screen that will allow you to run ZAP's extensive tests on your application. You can also run ZAP in headless mode by running it in the command line with the -daemon flag. This option allows for easy integration into your CI server because you will be able to run ZAP by including a post-build step specifically for ZAP. The last option is only available if you are using Jenkins as your CI server because there is a ZAP plug-in specifically for Jenkins. All you have to do is download the plug-in from the Jenkins plug-in manager and add a post-build step. These last two options will allow you to automatically run ZAP after you build your application.

After ZAP has completed its testing, it will generate an XML, or HTML, report that will give you a nice representation of the security vulnerabilities that are present in your application. The following is an example of what one of these reports would look like:

This section of the report shows that on five occasions while ZAP was navigating this web application, it detected an error, or warning, message that might disclose information about the file structure of the application. ZAP is giving this notification a medium threat level, which the orange bar indicates. The bar will be yellow if it is a low threat notification and red if it is a high threat notification.

ZAP is a really useful tool that can give you important information about vulnerabilities present in your application while offering easy integration into your CI server, even more so if you are using Jenkins.

Wrapping Up and Looking Ahead

Security is often perceived as a weakness of DevOps. Using the tools described in this posting, however, can improve security. Gauntlt and OWASP ZAP are both powerful tools that can be used effectively together and do not require large amounts of time to be implemented. In fact, they are easier to incorporate than most security tools available for the traditional software development lifecycle. These tools can alsobe leveraged to help build secure applications while offering all of the other benefits that DevOps brings to the table. Securing your DevOps pipeline will go a long way in maintaining a reliable product without sacrificing automated software delivery.

Additional Resources

To view the webinar DevOps Panel Discussion featuring Kevin Fall, Hasan Yasar, and Joseph D. Yankel, please click here.

To view the webinar Culture Shock: Unlocking DevOps with Collaboration and Communication with Aaron Volkmann and Todd Waits please click here.

To view the webinar What DevOps is Not! with Hasan Yasar and C. Aaron Cois, please click here.

To listen to the podcast DevOps: Transform Development and Operations for Fast, Secure Deployments featuring Gene Kim and Julia Allen, please click here.

To read all of the blog posts in our DevOps series, please click here.