Where does Security fit in DevOps?

By Eric Minick, DevOps Evangelist, IBM and Diana Kelley, Application Security Strategist, IBM Security Systems

Organizations are under increased pressure to continuously create and deploy innovative products, software, and apps that meet the highest standards in quality and assurance. This added pressure, combined with the fact that in today’s ever-connected world there are more avenues than ever before for data breaches and hacker attacks, makes it increasingly important to embed security throughout the entire development process.

Development and Operations teams came together to deliver DevOps techniques due to the need for organizations to be agile and continuously develop innovative products. However, , more often than not, security and DevOps teams are siloed , leaving a gap in the product and application lifecycle management process which makes it challenging to ensure an app or piece of software is secured appropriately.  To combat this challenge, organizations need to start incorporating security at the developer level and working it into the initial build cycle.

From DevOps to DevSecOps

Not many people will argue with the fact the building secure products should be a top priority for any organization. The main question comes down to – how do I do it? Traditionally, the development cycle went as follows:

1. Developers build the software

2. Software is tested then bugs are fixed

3. Security team tests it and fixes accordingly

4. Product is released

While security is addressed in the traditional model, today’s connected world requires security to be ingrained throughout the entire process. Organizations must emphasize the importance of security the same way any other functionality such as enabling speed of delivery or overall performance is called out.

By following some of the below key strategies, organizations can transform DevOps into DevSecOps and bridge the gap in the development process:

– Engage Developers & Engineers: Security teams will need to spend more time with developers. Engage them with their own language. Explain the associated risk with any product, but focus on how you can help them release more often and get security engrained. Time spent working on a problem together builds confidence and trust. They will be more likely to come to you with questions around security rather than trying to avoid or circumvent your team.

– Developers invite Security to project kick-offs: Nothing is more frustrating than a late breaking security concern. Bring security specialists into early discussions around a new application. They can figure out the appropriate security rules, whether you will need two-factor authentication, special care of data in transit or at rest, etc. This is also the same patterns development teams should follow for working with operations in ensuring applications can be kept running, backed up, etc.

– Help build secure, reusable platforms: Security professionals and the infrastructure teams should work together to define infrastructure patterns that are properly patched and configured and able to be automatically leveraged. If the easiest server to test on is a secure one, your teams will ultimately use those secure patterns too. You can add checks to the infrastructure definitions to automatically execute configuration policies.

– Continuously scan code throughout integration:  A simple check to find unreachable code can flag massive security bugs during the development process. The amount of time spent uncovering fixes or security concerns in a continuous integration loop is paramount to successful DevSecOps environment. However, if scans will significantly lengthen build times, then they should be included as a secondary phase or as part of nightly run rather than the core build loop.

– Build dynamic scans into your automated tests: Dynamic security tools and scanners should run as part of an early round of automated testing. The goal is to detect new issues while there are only a handful of changes to the software since the last scan. This will simplify determining where the problem was introduced and getting it resolved.

When securing software and services the goal is always to identify potential issues, resolve them and then figure out why they occurred. There is nothing different when working toward DevSecOps environments.

Ultimately, the goal is to bring checks closer to the developer for faster feedback and quicker resolutions. Just as operations and testing have increasingly been embedded into the development process and taught developers stronger testing practices, security professionals need to focus on being enablers of change, and partners for engineering. By introducing these best practices to your teams, it will become easier to promote more collaboration so everyone can do their part to keep systems secure.

Diana Kelley is the Executive Security Advisor (ESA) for IBM Security Systems. As ESA she leverages her 25 years of IT security experience to provide advice and guidance to CISOs and security professionals in briefings. She also works closely with the IBM Security Systems product management teams to help set strategic vision and direction for the portfolio. She has contributed to the IBM X-Force report and frequently publishes on the SecurityIntelligence and SmarterPlanet blogs. She is a current faculty member with IANS Research where she leads forums and symposiums on topics including Compliance and Risk, Mobile, Security in the Cloud, DevOps, Security Awareness and Application Security and serves on the Advisory Board for the Executive Women’s Forum and on the IBM Network Science Research Center Smart Grid Advisory Group.

Eric Minick is a lead consultant and DevOps Evangelist who joined IBM through the recent acquisition of UrbanCode. Over the past decade, he has been at the forefront of the continuous integration, delivery and DevOps space. With a background in development and testing, Eric’s true passion is in helping other teams deliver better. Today, Eric works closely with IT organizations that are trying to improve their build, deployment and release processes providing both technical expertise and process design guidance.