You are here

You are here

3 DevSecOps tenets: How to deliver security from day one

DJ Schleen Senior Manager, Software Security , Rally Health

DevOps presents an unprecedented opportunity for security teams to engage with developers and IT Ops to deliver high-quality, secure software to consumers.

But while the industry appears to have somewhat accepted the term "DevSecOps" to describe the addition of security into the DevOps mix, some organizations still might wonder what exactly it means.

In planning my talk for the All Day DevOps conference on October 24, I’ve spent a lot of time contemplating what DevSecOps should mean to the organizations I work with on a daily basis. My view is deepened by the fact that I’ve worn many hats while working with various agile and DevOps teams. I’ve played the role of Scrum master, application lifecycle management and ITIL consultant, and enterprise architect.

For the last five years, I've taken on a security-centric role, where my No. 1 mandate is to reduce risk in the enterprise. This experience has provided a valuable perspective on integrating security into DevOps. 

Here are three suggestions that I'll be digging into in more depth during my presentation at All Day DevOps.


1. Mitigate risk

If you can successfully mitigate security risk in an organization, you can come fairly close to effortlessly checking off many of the items on your compliance checklists. That being said (and possibly being extremely optimistic), mitigating risk can often be quite difficult to accomplish. It can be challenging to document and communicate to internal and external stakeholders. 

There are many sources of risk to an organization that may need to be considered by security teams as they define and evolve their corporate security programs. These include strategic risk, compliance risk, financial risk, operational risk, and reputational risk. 

A key opportunity when looking at each of these risks is to determine how an organization's security program can plug into your software development lifecycle and pull out KPIs to quantify your risk exposure. 

[ Special Coverage: All in on All Day DevOps ]

2. Secure your product from the get-go

Next, take a look at the product that is being developed and released to consumers. Above all, when that product leaves the assembly line, it needs to be functional, tested, and secure.

I like to compare application security to buying a new car: Once you drive the car off the lot, it depreciates in value. It's the same with application security: When the product leaves the shelf you can no longer attest that it's secure.

3. Containerization is key

A plethora of tools are available for penetration testers and ethical hackers to use as they evaluate application security. Unfortunately, most of these are extremely old, based on an idea that is on life support, or so complicated that installation and configuration are a nightmare. And so I saw an opportunity: 

Containerize all the things.

As an example, one of the tools that I use regularly to create penetration test reports is built with dependencies on Ruby 2.1.5. As everyone should know, there are a plethora of vulnerabilities out there targeted at this platform, but, more importantly, it's no longer supported. To any organization, use of such a tool introduces unnecessary risks into the business—and, as a security professional, I know that relying on it puts my customers and employer at risk as well.

Taming the beast

Regardless of the fact that I’m not a big fan of Ruby (that's a conversation for another day), what I decided to do was containerize the beast. I won't get into the headaches and lost hours of my life spent doing it, but I will post a separate article on it when I release the code on GitHub.

In my talk at the All Day DevOps online conference, I plan to dig into how I dealt with mitigating the security risks with compensating controls. Registration is free for the 24-hour event, so I hope you all can hear my discussion about automated container cycling and how it can be used to frustrate hackers, kill the zero-day, and pull KPIs out of other toolsets into your software development lifecycle.


Keep learning

Read more articles about: SecurityData Security