Finding the Rhythm for DevSecOps

Interview with Tanya Janca, Senior Cloud Advocate at Microsoft.

Can you please give us a quick intro about yourself?

I am a software-developer-turned-AppSec-person. I want to help people make secure software. I want to help people use the cloud, and other new technologies, securely. I want security to be easier. Doable. And most importantly, within reach.

DevSecOps seems to be in everybody’s mind, how far do you think companies are in their implementation of DevSecOps?

How far do I think the average company is? Not far. I know that some places are still doing the Waterfall Method, and some others are saying they are doing Agile (when in fact they have scrum meetings, skip doing documentation, and do a messy waterfall). I know some companies are doing amazing DevOps or Agile, but their security teams don’t know how to fit into the new culture, ending up left behind. And I’ve heard of some amazing places that are literally inventing DevSecOps as they go, creating newer and more efficient ways to produce secure results, every single day. And many of the successful companies are sharing their recipes for success, which I think is truly inspiring. I can hardly believe some of the amazing tools, information and other resources these companies are giving away. I won’t name names, but Netflix, you know who you are. :-p

In your opinion, what is the single biggest mistake companies and teams are making when trying to implement DevSecOps (and how can they do better)?

I feel the biggest mistake is lack of communication between teams. At some workplaces, the security team is not seen as an ally, but an enemy. Buy in from the security team is absolutely required to have any sort of success in DevSecOps, and that means open and honest communication. Back when I was a developer I referred to a certain member of our security team as “Dr. No” (which in retrospect was not very nice…). I did this because we did not understand where each other was coming from (and all he seemed to say was no)…. But now that the shoe is on the other foot I realize that I did not understand the threats, and he knew nothing about software development. It wasn’t that he *wanted* to say no all the time, it’s that neither of us knew how to meet in the middle. It took a couple years for us to have a good rhythm and for the developers to start calling ‘Dr. No’ by his real name. Trying to shove DevOps down the throat of your security team is not a good way to get what you want. Working together, even if at first it’s prickly, is the best long term plan for success. In my humble opinion.

To add to this, here are a few ideas of how get the two teams to work better together:

• Support both teams with training. Training that relates to the work they do every day. For instance, if you a developer: secure code training. If you design apps: threat modelling and secure design training.
• Create processes that actually work. There should not be a 21-step approval process, and people 4 levels above you in the company hierarchy should not be asked to approve a regular change. Examine all of your processes, especially the security ones, to see if this are effective (do they actually make things secure) and efficient (do they slow down the whole system? If so, they need to be tweaked).
• Give developers and ops security tools and other resources (books, videos, whatever) so they can perform security tasks ore easily as part of their everyday work.

I have a ton of ideas. Please come to my talk so I can tell you the rest! (Shameless plug!)

What are the three first steps that companies and teams can take today to make security part of the development process (technical and non-technical)?

You’ve asked me my favourite question!

1. AppSec Training! (for dev and security). Take a look at these links I have assembled for getting started in application security: https://aka.ms/GettingStartedWithAppSec
2. AppSec Tools! (give developers security tools so they can start fixing things earlier in the dev process, give security people appsec specific tools, not just network tools). I have written a blog post with specific tools: https://aka.ms/DeveloperAndOpsSecurityTools
3. Adding security activities (code review, scanning, threat modelling, whichever you decide is highest priority comes first) into your SDLC or project planning so that developers actually have time to do the activities.

There’s no point in doing step one and two if developers and security people are not allowed to follow through. If management really wants DevSecOps, they need to put their money where their mouth is and give them time to work on it. The 4th invisible step is to encourage all of your developers to participate in OWASP so they can continue to learn about application security, for free.

What recent projects have you been working on?

I’ve just joined Microsoft, so my current focus is “learn all the Microsoft”, from a security perspective. I thought they looked impressive from the outside, and they are even more impressive from the inside. I’m also writing up some new talks, doing research, and planning same new things with my open source project team, OWASP DevSlop (more about this below).

I’m currently prepping for the Open Security Summit, which is an OWASP affiliated annual event where open source security projects can work for a week and collaborate with members of the public. It’s kind of amazing. Microsoft is sponsoring our entire team to have a track centering around DevSecOps, and the DevSlop team certainly plans to make this a very attractive track. 😀

Would you be able to tell us about the DevSlop project you are leading?

Nicole Becher and I are leading an OWASP project that includes Mohammed Imran and Franziska Buehler. We named it “DevSlop”, and by that we mean “Sloppy DevOps”. We want to make intentionally vulnerable DevOps pipelines and teach people how to do security testing on these new types of systems and environments. We want to create very secure DevSecOps pipelines and share them with the world (open source licensing), so that other IT shops don’t have to create their own. We want to teach about where you can do right, or wrong, with Microservices. We feel that OWASP Projects like Juice Shop and Web Goat already do an amazing job of showing developers about application vulnerabilities, and so we decided to concentrate on covering the “other stuff”. If it’s weird, different or new, we’re interested.

If you want to look at what is actually ready, you should get a copy of Pixi, our first module. Pixi is a web app with *very* insecure microservices. To use it go to our FAQ page and it tells you how to use pixi. Basically, you install Git Hub, install Docker, then run 2 lines at your command prompt and it will do the rest: https://www.owasp.org/index.php/OWASP_DevSlop_Project. We also have a video of Nicole and I doing some of the ‘hacks’, so you can follow along and break it with us.

It’s kind of amazing that not only have I’ve met all three of these amazing humans while traveling the world over the past year, but that I somehow talked them into working with me! OWASP has been a very positive influence on my life. I feel very lucky to be a part of it.

Can you tell us about your upcoming talk at DevSecCon Tel Aviv?

“Security Learns to Sprint” is the companion talk to “Security is Everybody’s Job”, which I am giving the week before DevSecCon at DevOpsDays Zurich. “Security is Everybody’s Job” is about what DevOps developers are going to need to change, in order to adjust for adding security to their everyday work. “Security Learns to Sprint” is the security view point. How does the security team need to change in order to still reach their goal (secure software), in a DevOps world? And the short answer is: they need to learn to sprint.