Security Managers and Modernization Don’t Mix…or Do They? 

The Trump administration recently clarified its management agenda to modernize IT in a 54-page document and initiated the process for distributing the appropriated Technology Modernization Fund, which quickly prompted discussions of how agency personnel plan to achieve their agency’s modernization goals. An increasing reliance on DevOps in the cloud to accelerate new applications and replacement projects is one of the first strategies that come to mind. This is exciting from the perspective of cost-effective and rapid modernization but can be terrifying for security and compliance executives who are tasked with modernizing the security component of the administration’s agenda.

How can security and compliance managers reassert their role in the DevOps process in order to achieve their agency’s security goals and those of the administration? While the “2017 Federal CIO Report” and other sources seem to indicate that an increase in DevOps adoption is steady, with 75 percent of respondents saying it is a top priority, the reality is that secure DevOps is still more of a meta-conversation than it is an actual implementation effort. The very lack of consistent terminology being used across agencies indicates that actual security implementation is lagging behind this move toward DevOps. In a recent search on a popular federal business opportunity website, several terms and spelling variations (DevOpsSec, Devopsec, DevSecOps, SecDevOps) were used to track the growth of DevOps security in the federal government. Only one citation appeared prior to 2018. Of the 10 found in 2018, most were requests for information or pre-request for proposal notices.

In fact, it was not until 2018 that the number of business opportunities each year, just for “DevOps,” rose above two. The good news for advocates of DevOps as a vehicle to modernization is that in Q1 2018, RFIs that required “DevOps” solutions spiked from 2 to 27. Does this dramatic increase in DevOps activity mean that a spike in DevOps security implementation will soon follow? That depends. In order for security leaders to keep pace with DevOps initiatives in the cloud and ensure FISMA compliance, they will need to move (quickly) beyond the terminology and take actual steps toward DevOps security implementation. Below are a few things to consider:

1. If you haven’t already, get a clear understanding of your agency’s current application development status with respect to DevOps adoption. Is your organization still using waterfall, or have you moved to agile? What development projects are in the works vs. what are planned? Don’t wait to be invited into this discussion. In most agencies, if you assert yourself in the discussion now, you will be early enough to transform a DevOps conversation into a DevSecOps conversation from the outset.
2. The dividing line between application development and operations is rapidly disappearing. Because security personnel has traditionally been brought into the process just before going live, security was not a concern at the front end of the development process. Now, it has to be a concern at the front end, because it will soon be impossible to apply security at the end of the process. Why? Simply put, there is no end.
3. Security in a DevOps environment must be automated. Federal security personnel must take on a completely different mindset regarding compliance because you are no longer assessing the compliance of something that is relatively fixed. In a constantly changing environment, automation is not optional. And remember, the goal of automation is to advance progress, not to slow it down.
4. Get familiar with security tools that can be fully integrated into the operation of the most popular automation tools so that you can work within their specific frameworks. Security tools must be integrated early in the development process in order to provide visibility for accurate reporting.
5. Audit, analyze, assess and review with the owner early in the life cycle. You must shift your analysis efforts to the beginning of the process (“to the left”), so that all of the components available for deployment have been assessed and have been determined safe to use.
6. Be ready for full containerization.  Some application environments have moved to environments where everything runs in a container. Consider whether your security solutions will be adaptable to work in a fully containerized environment. Are your solutions able to scan both running and offline containers such as Docker? 

DevOps in the cloud is an effective way to advance modernization for an application development environment. Armed with the right security tools that integrate with leading DevOps tools and work within their frameworks, security personnel have an opportunity to change their role (and others’ perception of their role) for the positive.  Security professionals who are willing to assert themselves, partner with their DevOps teams, and shift their engagement to the left in the development cycle will enable their agencies to release software even faster, because they will not be imposing a traditional (and now largely irrelevant) final security and compliance signoff at the end of the process. Baking security into DevOps can give security personnel the opportunity to finally become an agent of progress, rather than being seen as an inhibitor.

Keren Cummins is the federal director at Tripwire.