DevSecOps: Building continuous security into IT and app infrastructures

In this podcast recorded at RSA Conference 2017, Chris Carlson, VP of Product Management, Cloud Agent Platform at Qualys, talks about DevSecOps.

Instead of making security a trade-off at the end of the cycle when it’s already in production, how can we bring security into the development process, bring security into the DevOps process and make security part of the entire process line from a continuous integration point of view?

Here’s a transcript of the podcast for your convenience.

Hi, this is Chris Carlson from Qualys. I’m the VP of Product Management and in this Help Net Security podcast, we‘ll be talking about DevSecOps. And DevSecOps is how you can build continuous security into IT and application infrastructures.

There’s a big convergence that’s happening with agile development technologies, where development teams are now moving from waterfall development methods and are moving into more agile methods to do development and move to the cloud as part of the company’s digital transformation. Part of that new dev development cycle, or now being called DevOps is using new security tools to understand how they can fit into that process. So if you think of DevOps as an assembly line, as a manufacturing pipeline, the way that software has been originally built from initial requirements gathering. to design, then do some development and then launched into the marketplace takes too long and doesn’t account for the speed at which other competitors are entering the business.

So what’s happening is with agile development, they’re starting to do more frequent releases, and they call that sprint in terms of the development cycle. This accounts for requirement changes that come in during the process. This accounts for customer turnover – so you may be developing for one big customer, and then, you know, they change the requirements and they may not actually go with your technology. And also accounts for technology innovation. And technology innovation is not just about a certain module or a certain stack. It can also be about a new way to develop and deploy and offer services. So maybe you’re developing web applications and you’re using a multi-page web interface and then there’s a new way to go with a single-page design, and using a new, a client-side UI framework. And knowing that earlier and be able to adjust to it, you can actually offer new lines of business and new capabilities.

But what has happened with the new agile development process using automation in the DevOps process to do continuous integration, to do continuous deployment, the time between requirements, development and push to production has completely decreased in terms of time to market.

From a security point of view, where does that leave security? Traditionally, when security has been on the backside of a development project. We do some security, maybe as part of the dev cycle, with maybe a static code analysis, maybe an audit just before it gets released in production – usually all the security issues, the vulnerabilities, the appsec issues are found in production. That changes the economics of how you can take care of the security issues.

If you think about the business owner, or you think about the business unit that has funded the development of that new application which we’re launching in the marketplace, they will pay for to fix defects in functional use cases. Let’s say there’s a new mobile banking application that you launch and for some reasons, you can’t submit payments less than 99 cents. You know that will be the first thing which they fix as part of a functional release. If that same application has a web backend in that uses an outdated version of Java that’s vulnerable, will the application owner or the business owner actually pay for the patching, the regression, the testing to certify the entire stack on that new version of Java? Most likely the answer is no in common cases, so then that’s where security teams have to put risk metrics and the likelihood of exploits, and impact to the business if there is a security breach. Then the risk team has to look for it.

Instead of making security a trade-off at the end of the cycle when it’s already in production, how can we bring security into the development process, bring security into the DevOps process and make security part of the entire process line from a continuous integration point of view? And that’s been happening now at companies of all sizes; you don’t have to be companies born in the cloud. You don’t have to only do things in a certain cloud provider – you can do for on prem technology, and that new paradigm is called DevSecOps.

DevSecOps which integrates security as part of the development process, and what business people are using to describe this new paradigm of DevOps and digital transformation is a term called ‘shift left’. And shift left is really moving earlier in the timeframe. How can we move from a digital transformation earlier in the time frame so we can out-compete with our competitors? How can we move earlier in the digital transformation so we can out-innovate new companies who do not have the legacy infrastructure that we do? If you apply shift left to security, we have to be careful of one thing: applying shift left to security is not doing the same security things earlier.

Applying shift left to security, and part of DevSecOps allows you to do different things earlier and better things earlier. So if we think about how you can apply security earlier in DevOps process, that is part of that continuous integration. In order to do and apply security earlier and in a better way, we need to make sure that we are not a process blocker to the development teams. When you have development teams using things like Hudson, using things like Bamboo to do continuous integration, and you have development teams and DevOps teams using things like Ansible to quickly build, test, integrate and deploy, how can security say ‘No, you have to stop your complete automation so we can look at it?’ the answer is you have to bring security into that automation process. You have to look at tools that have APIs, you have to look at tools that can allow for self-service, you have to look at tools that give the feedback loop to the developer, not the security person. In fact, there’s actually a psychological component when you bring security into the DevOps process.

Security, in many cases, is about a score card. And if a score card is red, then people get upset. So how do you have a score card of errors and defects of your developer who’s building the code that may have errors? The best way to do that is to not broadcast it in an audit report that goes up to the board of directors. It’s not just bringing in APIs and automation and self-service into the DevOps process, but how can you give the reporting to the developer themselves so they can fix the issue? Therefore no red alerts go up into the upper management. When that happens, that actually then starts to get security teams embedded in with the development teams.

There’s no difference between a functional defect or a software defect. There are defects in security. So, this gives you a picture of what DevOps is. It’s how people are talking about shift left from a digital transformation and shift left security.

I will leave you with some areas that you can apply to your own practice today. This week, after you hear this podcast, take an accounting of your current security tools. You may have 30 tools, you may have 50 tools, take an accounting and see which tools are DevOps friendly. There may be some tools that you currently use in your security team that has a very nice UI. Pretty pictures and fantastic graphs, but doesn’t have an API to allow you to integrate into the DevOps process. There may be another security tool that has the oldest interface, and frankly not very pretty – but has an API that you can integrate in that process. So take an accounting of your security tools, are they DevOps friendly?

Identify development teams within your organization that are open into bringing in areas of security as part of the DevOps process. In some cases, the highest visibility DevOps project might not be your first one. There may be a lot of business pressures to get out there correctly, there may be a lot of things in terms of time scales or competitive natures – so identify development team that is open, agile, friendly, willing to work with you and start to get quick wins. Also think about that maybe cloud and on premise has a different way of approaching it. There may be cloud security tools that you are using that has open APIs but those friendly developer projects that you identified are on prem projects, so make that tradeoff.

Once you then get that accounting of your security tools, identify those development teams, what you can do with the next 3 months is start with a first project. Now, when you start with a first project, don’t think of it as a tool integration. You want to show that bringing security into the DevOps process earlier, the shift left security actually impacts the metrics of delivering high-quality security projects.

If you can start to do analysis of metrics, if there already is this project that has deployed and you’re already doing things like vulnerability assessment and policy compliance against that project in production, now you have a list of vulnerabilities. So when they work on their second release or their next update, and you can start to track vulnerabilities that identify it earlier in the process and then fix them earlier in the process, you have now down an avoidance metrics – now we’ve identified that these 10 vulnerabilities or these 4 vulnerabilities do not need to be fixed in production because they never made it into production in the first place. So that measuring outcomes is very important.

I mentioned before: get a list and accounting of your security tools. So in the next 3 months after hearing this podcast, I recommend hold a vendor summit with your security vendors. Ask all your vendors to come in, sit down at one time, tell them what you’re trying to do and optimize your environment. Maybe you would not want to bring in the sales people from your vendors as part of the vendors summit – bring in product management. Bring in the sales engineers – if you can, bring in developers and explain ‘This is how we’re doing DevOps’ These are the DevOps tools that we’re looking to actually use. We require APIs in this fashion. If you have APIs but they’re not published, perhaps you can document them and make them a supportive capability that you can bring in.

You’ve shown success with one project, you’ve shown success with metrics, you’ve seen your tools that you currently have that can be integrated – and then, now we can see what the next 6 months are. And in the next 6 months you really need to take a hard look that maybe some of those security tools and vendors don’t make the cut. Maybe they’re not ready to be put into the DevOps process. Maybe another vendor has better tools for that. Maybe another vendor can go from on premise to cloud, to end-point with the same API and that is probably the right vendor to bring in that place. And then that’s when you start to implement those self-service and those APIs. Bring it into a continuous model. Show a reduction in your security budgets by consolidating those vendor tools into a set of capabilities that can be programmatically added as part of that process. Expand to more projects – show that security is not a process blocker, but is an innovator to bring high-quality, high-security projects to the market for your business customers, for your business owners as part of the digital transformation process for your company.

And the last thing which I would recommend is be active in the DevSecOps community. Take a participation in conferences. Maybe some of you can do this podcast 6 months from now, and show what you have done in terms of bringing in security to the DevOps process, and be a champion for DevSecOps. Thank you very much!