Securing DevOps with Julien Vehent

Micro Focus Contributor
Micro Focus Contributor
2 0 1,502

Micro Focus Fortify is proud to be the exclusive sponsor of the TestGuild Security podcast hosted by Joe Colantonio. This weekly podcast, dropping every Thursday, aims to be 30 minutes or less, interview-style series speaking with some of the top Security Testing experts in the field.

Securing DevOps with Julien Vehent.jpgThis episode of the TestGuild Security Podcast, Securing DevOps: Security in the Cloud, features Julien Vehent. Julien is a French computer security engineer who leads the Firefox Operations Security team at Mozilla. He specializes in web application security, cloud infrastructure, cryptography and risk management. He is the author of “Security DevOps”, published at Manning in 2018. In this interview, he discusses the three areas of his book: securing DevOps, watching for anomalies and protecting services against attacks, and maturing DevOps security. Here’s a summary of his main points:

Securing DevOps: Why is it crucial?

“I think it's the only way we're ever going to have secure product and secure services. (…) with software you have from the very beginning to consider how it can be misused, what impact it could have if it gets attacked, etc. etc. and bake these controls directly into the software, the service, the infrastructure themselves. So gradually over time, what we're going to see is that organizations that resist attacks and that provide secure software are the ones who are taking security seriously and integrates security considerations as part of their software design. We use the term “shifting left” in the industry, which really refers to moving the security discussion to the beginning of the software engineering lifecycle, the SDLC. (…) It gets cheaper over time because at first what most organizations that adopt this type of security integration do is that they first focus on the technical aspects. (…) But over time they start creating a culture of security in their organization. They start talking to the developers earlier and earlier, they start talking to their operations team earlier and earlier, and the cost of having those security discussions and of shaping software to be secure reduces over time.”

”It's fairly simple for a team of engineers to just sit around the table once in a while and look at an application and ask: how would we attack this from the outside? What are the risks? What is the most dangerous thing that could happen to this application? And that usually gives a lot of interesting pointers. There is no risk framework involved with just asking: what do we need to be worried about here and the solutions usually come naturally.

What tools to use to help with security testing?

 “We started using checklists, security checklists specifically, a few years ago. (…) The way we use security checklists is that we essentially have a master checklist that we will give to developers every time they start a new project. And that has everything from like infrastructure security, security headers, TLS configurations, common issues we find when developers implement API’s in AWS for example. (…) that checklist is a mix of industry best practices, but also issues we've learned about both from our own security work but also from a bug bounty programs. And we want to tell the devs to watch out for them. (…) So when they start a new project, we'll take the checklist and we will discard the stuff that doesn't apply to them. (…) And over time, the checklist that we end up giving to developers actually becomes shorter and shorter because we're implementing better default and better core infrastructure, better paved road for everyone. So, they have to worry about less and less of the security perimeter.

[Bug Bounty]. “You basically tell people to come hack you for money. Mozilla has had a bug bounty program both for Firefox itself and for the Web services we run for maybe 15 years now (…) And we really have a good relationship with a lot of researchers. What we got from it, is essentially when we create (…) new application services, we can without putting any money upfront, expose those services to a population of fairly skilled security researchers and they would go look for bugs. And if they find bugs, they will report them to us privately. So, we have time to patch them and we'll pay them money to thank them.”

It's harder for me to recommend one specific tool that does this well because what I found is that it is often better for organizations to build their own tools and build their own test suites and to actually collaborate with the operations teams and the developers on what those security tests should be.”

What is test drive security?

I think the main idea behind it was really to push security engineers to define the security controls that they want to see implemented everywhere from the beginning. And then to let developers essentially go through the fading tests and fix them over time. So, the same way you would do tests you've been developing, you write your unit tests first and then you go implement the functions here, you would have your security tests.” (…) . But the goal here is to tell the developers which tests are failing and to have enough documentation that they understand why the test is failing and how to fix it and why that's important so that they can go fix it. And by the time the application reaches production, it has all of the passing tests done. I'll be honest, I've had mixed success with this approach. (…) What works well is, like I said, the checklist works well and letting developers essentially self-assess when they feel they're ready. And we do that by exposing our security risk to them.

One piece of advice for the security DevOps Testing efforts

“The piece of advice I would give people implementing a security strategy in their DevOps organization is to break the barriers between teams as early as possible. The most important aspect of building a successful security organization inside DevOps team is to be able to talk to people often and about everything. (…) One thing that often lacks in security organizations is that they're not necessarily trusted by their peers because they're too far away because they're trying to do everything through tests and through bug reports and etc. And that's not how you build trust. So, if you want to really build a successful security organization, break the barriers, go work directly with the developers, directly with the operators, share their successes and their failures and really create a cohesive group.

Hear Julien Vehent’s full interview on Securing DevOps.

 

About Micro Focus Fortify

Fortify offers an end-to-end application security solution that secures and protects code throughout the entire development lifecycle of any type of software—from development to testing, release to production and every iteration in between. Fortify static, dynamic, interactive, and runtime security testing technologies are available on premise or on demand, offering organizations the flexibility needed to build an end-to-end software security assurance program.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.