The DevOps philosophy prescribes an increase in communication and collaboration between software development and operations teams to realize better outcomes in software development and delivery endeavors. In addition to bringing development and operations closer together, information security teams should be similarly integrated into DevOps-practicing teams. An automated way of performing complete software security assessments during continuous integration (CI) and continuous delivery (CD) does not exist yet, but this blog post describes how we can apply DevOps principles to application security assessments and integrate the results of those activities with CI/CD.

A Timely, Sustainable Cadence

During the development phase of a new software project, the information security team should assess the security risk the new software presents to the organization and conduct security assessments throughout its development. To quickly develop and deploy new features to production, an organization must be assured that the security assessments are performed in a cadence that is timely enough to minimize security risk and also sustainable by limited resources of a security team.

Automation is one of the main aspects of DevOps, but a lot of the tasks required to conduct a proper software security assessment on a given application remain manual. For this reason, proper application security assessments remain out-of-band of the continuous integration/continuous delivery development pipeline. If an organization is performing continuous delivery, how can it be assured that the software it is deploying to production does not contain security risks?

Certain code changes, such as new application programming interface (API) endpoints, or changes to authentication, warrant a manual security assessment before the change is migrated to production. Other types of changes, such as making a visual style change, may not necessitate a manual security assessment. For example, it would make no sense to conduct a full, manual security assessment on an application if the only change to it since the previous security assessment was to modify a visual style or add some small feature that does not affect the security profile of the application.

The decision on whether or not a manual security assessment is required also depends on the kind of application and the kind of data the application handles. For example, an internal application that doesn't touch any sensitive data, such as customer information, trade secrets, PCI, or HIPAA-sensitive data, and is only accessible via the company's intranet should be treated differently than a publically facing web application that perhaps handles sensitive data. Due to the number of applications needing security assessments and the amount of work required to conduct these security assessments, application security teams do not have the bandwidth to manually assess each and every change that gets deployed into production. With application stakeholders' help, security teams should evaluate and catalog their organization's applications. This catalog should contain for each application their threat models, relative riskiness of data they touch, and how the application can be accessed by users.

Before a new piece of software is released into production, a security assessment should be conducted. From the time the security assessment is initially conducted, another full security assessment should only be conducted if a change was made that alters the security profile of the application. Changing the mechanism of authentication or authorization or adding an integration with a new external system are examples of changes that may warrant a new manual security assessment.

The development continuous integration pipeline should be outfitted with a mechanism to detect when a change is made to the application that warrants a closer look by security. This mechanism is the security controller seen in Figure 1 below. The security controller should inform the information security team that a security-sensitive change was made and schedule a manual security assessment. Until such an assessment is made, a hold can be placed on automatic deployments to production environments.

After the assessment is completed, the information security system can notify the continuous integration/continuous delivery system that it is now OK to deploy that application as seen in Figure 2 below.

If a small change that does not warrant another manual security assessment is made to an application, a production deployment is allowed as seen in Figure 3 below.

If a large change to an application is made that warrants another security scan, the production deployment is blocked, and a notification is sent to the security team to conduct a security assessment, as seen in Figure 4 below.

After the assessment is completed and satisfied, the block is released.

Integrating the development continuous integration and continuous delivery system with a security controller allows an organization to automatically store all the code changes that contributed to a build upon which a security assessment was completed. After an assessment, all code changes that have occurred since then can be tracked. In the event of a security incident, a reliable log stating the sequence of events that happened to a particular application allows for a faster, easier investigation and mitigation of a security problem. All changes to an application that were deployed after a manual security assessment can be made visible by integrating the continuous integration, deployment, and security controller systems. Locating and addressing a security vulnerability in an application can be like finding a needle in a haystack. By knowing everything that happened to an application since the last security assessment, the size of that haystack can be greatly reduced.

Complete application security assessment automation is not yet a reality, and the need for manual assessments still exists. By integrating DevOps CI/CD systems with security systems that track security assessments, we can improve the security of our software release process and simplify our security incident response.

Every two weeks, the SEI will publish a new blog post that offers technical guidelines and practical advice for DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below.

Additional Resources

To view the webinar DevOps Security: Ignore It As Much As You Would Ignore Regular Security by Chris Taschner and Tim Palko, please click here.

To view the webinar Culture Shock: Unlocking DevOps with Collaboration and Communicationwith 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.