Security Boulevard Chat: Update on Security & Compliance From Chef
In this Security Boulevard Chat we speak with Dominik Richter and Dan Hauenstein of Chef. Dan and Dominik give us an update on the latest capabilities that Chef is building into its products to help with automating security & compliance.
Some of these tools are open source and some are not, but together they give Chef users the ability to “shift left” with security and compliance entering the software development life cycle (SDLC) earlier.
As usual, the streaming audio player of our chat is immediately below and the transcript of the conversation follows that. Enjoy!
Audio
Transcript
Alan Shimel: Hello, everyone, this is Alan Shimel, and I’m here for a combined DevOps.com and Security Boulevard Chat with two folks from our friends at Chef. I’d like to welcome Dominik Richter and Dan Hauenstein—if I mispronounced, I apologize. Dan, Dominik—welcome.
Dan Hauenstein: Thanks, Alan. Great to be here.
Dominik Richter: Glad to be here. Thank you.
Shimel: Great. Great. Dan, why don’t we start off with you, if you can tell our audience a little bit of your background.
Hauenstein: Yeah, sure. Again, I’m Dan Hauenstein, so you got the pronunciation exactly right, and I’m responsible for product marketing at Chef. And, in my background, I’ve been at a variety of high-tech, primarily enterprise software companies that kinda cross operations data and security, including Micromuse, IBM and Hortonworks.
Shimel: Fantastic. And Dominik, how about you?
Richter: Hi. I’m a product manager at Chef. I am the co-founder of the InSpec open-source project, which is compliance as code as well as other forms of testing, and also co-creator of Chef Compliance, one of the founding members of dev-sec.io and a few other things.
Shimel: Excellent. So, guys—topic for today’s webinar is around DevSecOps, but specifically, how we’re seeing sort of security, not just shifting left, but we’re seeing security come into the Dev and DevOps world, right? And in my mind, there’s two elements of it. It’s the security people moving to Dev and DevOps, but it’s also the Dev and DevOps folks sort of welcoming security and making security part of their job.
Now, Chef is one of the leaders in this, right? You guys, I think with the acquisition of Dominik’s company—what was it, about a year and a half ago now, Dominik, maybe more?
Richter: It’s actually two years ago by now, a little more than two years ago.
Shimel: Alright. Time flies when you’re having fun—but it was some time ago. Chef was very early on in moving this compliances code and moving security, you know, left into the Dev space. Dan, I’m wondering, what are you guys seeing there, and where is the battle lines today?
Hauenstein: Yeah, well, you know, it’s all driven by the role that software plays in almost every company today. Everybody is trying to make that digital transformation, they’re interacting with their customers through software. And when we, as Chef, talk about the things you need to get right in order to have success in that space and compete effectively, you talk about speed, efficiency, and risk. So, how quickly do you bring new ideas to market? How much re-work does that cause and how quickly can you fix it? And then, are you introducing vulnerabilities when you do that?
So, all the three of those work together, and for us, it was pretty natural, with that being the goal that we’re trying to help companies achieve—pretty natural to bring security together with that, try and help with this shift left. The issue is that it still crosses organizational lines to a large extent, so there’s a lot of work that we see having to be done around just organizational understanding of what each team does and how working together in a bit of a different way can benefit both sides. It doesn’t have to be these conflicting goals of speed versus risk where if you’re faster, you’re riskier. If you’re lower risk, you’re slower. That doesn’t have to be that way.
Shimel: I get it. So, guys—and Dominik, this really is a question for you—one of the issues is, do you go from developers to the security team, or do you go from the security team to the developers? And, you know, Chef’s strong point or Chef’s base is obviously in the development and the DevOps world. How are you outreaching, if you will, to the security people to bring them into the fold, here?
Richter: Yeah, that’s a very good question. Actually, if you look at the original company that we created that Chef then acquired, we reached out to the security people first, because most of InSpec’s foundation is actually built for auditors, primarily, and then we actually took the next step and introduced more of the developers in the DevOps side to it.
We have been DevOps engineers for a long time, and when we introduced it, it was a way to cope with the security requirements that we were getting and answer them in a more efficient way. These days, if we look at how Chef approaches this field, we are mostly connected to an existing base of DevOps practitioners—people who are really good at code, at scripting, and at automation. And they’re usually faced with a number of security requirements—well, it’s really compliance requirements—that they have to fulfill.
So, when they are faced with these, they [Laughter] actually have to interact with their security departments or with auditors. And many of them, these days, feel the same way that we felt back then. We have a high degree of automation, we are not doing things as manually as we used to. So, if we already describe our infrastructure as code, if we codified most of these things, if we are moving automatically, then how do we capture this space?
Now, in answering that question, many people approached us about the solution that we offer, and that’s how we started to talk to the security folks as well as the auditors as well. So, we bring it up from the perspective of the people who need to operate it and start the conversation there.
You may think it’s mostly just around a tool, but what I noticed during the last two years is that it’s very often also about how we work together, how these two departments interact and collaborate, really. And I think this has changed to a large degree.
Shimel: Got it.
Hauenstein: I’ll just add on that, Alan. In a recent project that we were working on with a very large financial services organization, part of the thinking was originally that the security team would be driving a lot of the decisions around this. But we really found that the operations team there are the ones more responsible for maintaining compliance and production, for going and remediating the issues around compliance and then delivering it back to that information security team.
So, it turned out that it was the operations team largely driving and kind of bringing the security team along. The good news is, now those teams are really starting to look at better ways to collaborate and work together.
Shimel: Got it. So, guys, let me just say that one of the challenges that we see—you know, and my background comes from the security side of things as well—is just getting everyone to agree that security, No. 1, is everyone’s responsibility, but, No. 2, that we really are on the same team.
And I think, unfortunately, the security folks are probably more guilty of this than the developers or the DevOps teams in that it’s very hard for security folks to give up—not control, though that might be part of it, but to acknowledge that these people care about security as well and they’re doing, they’re gonna do their job around it, right? That security is their responsibility, too.
At the end of the day, there’s very much an us and them that needs to be overcome, and you know, as I said earlier, Dan, right—Chef is not a traditional security company. How do you, have you run into this at all in security teams, or not really?
Hauenstein: No, I definitely have run into it. In fact, at a recent event, there was a security team member in the audience—this was a large organization that we work with, and doing an event to cross multiple members of their teams. And after kind of talking through this compliance as code and shift left concepts, one of the security team members came up and said, “You know, we’re pretty frustrated. We’ve had these types of abilities to scan and check for vulnerabilities for some time, but no one cares.”
And I think the message here is that, you know, that capability isn’t new, but integrating that into the DevOps workflow and then bridging this gap between these teams, that’s what’s new and that’s what we need to [Cross talk].
Shimel: And that people do care, right?
Hauenstein: Yeah.
Shimel: I think another piece of it, though—and Dominik, I’m interested in your opinion—is if we could automate that, right? So that it doesn’t have to be someone’s job to do the scan. The scan gets done when the code gets checked in or at some trigger event, we scan that code automatically. And then, whatever the code finds in the way of bugs, vulnerabilities, errors, whatever, gets assigned out to someone, whether that be on the developer team or the security team, I don’t know. But the automation aspect of it, I think, is a key piece of it.
Richter: Yeah, and I may actually split up my answer, here. I’m gonna go, first of all, to the thing that you just said and then to what we are hinting at, at the moment, which is continuous compliance.
So, first of all, I have a pen testing background, so for me, I actually came from pen testing first, then into DevOps. I can tell you that we had a number of tools that we used to automate—actually, my thesis back in the day was around automating all the security testing tools that we had and how we can get easy results from them.
The problem I’ve always seen is that (a) many of these tools were privy only to security folks. They were very limited in the way that they’re talking to people or exposing the information. Usually, also, handled in a very, very privileged way, which means that access to that information was highly restricted, and the only thing that we gave to security people were, you know, reports, docs, and so on.
It limited the amount of discussions you would have, and if you kill the discussion, then you don’t get a really good risk evaluation. So, that’s one of the problems.
The other problem is that the tools which we used back then, they weren’t really offering solutions. There were false positives in there, or results in there, that took hours and hours to fully analyze. And even then, I could present you with the findings as a security expert, but I couldn’t really help you in understanding how to get to the solution.
Now, if we don’t talk about that path to the solution, then sometimes we’ll just throw out a critical finding that there is no way to properly solve in a reasonable amount of time. And that brings up the barriers. That creates more barriers between security and DevOps or Operations than it solves.
With InSpec, we’ve actually gone the route—I mean, InSpec and Chef—we’ve gone the route to facilitate communication, to make sure that both sides actually talk about the same pieces of code that they are looking at. If you have a control, then it’s not just limited to security experts any more, but a DevOps expert can look at it because they understand how these tests work, and now we can actually talk about what is really being looked at, how we can change that, whether we need a different evaluation in this profile, should we skip this for the time being, or how we should handle this.
So, that’s the first part of the answer. The second part is continuous compliance. So, previously—I remember this in my old job—we were working at a telco and we were developing a new core cloud network. And, as we were completing it, I vividly remember that dreadful Friday when I was coming in, and I was on the DevOps side then, that we had to get an approval from Security. And it was around noon that I finally got the green checkbox. I went out to celebrate later that day, and we felt really good on that Friday.
However, it turns out on Monday, a few code changes emerged, and those code changes made some serious modifications to the systems that we had just pushed through a security test. They actually changed many of the controls and turned it into a really, really bad state. However, nobody cared at that point, because we had officially received our green mark. Security was happy, but gave us a, you know, one of those seals where they say, “As long as you don’t change anything, you get this approval.”
Now, nobody wakes the sleeping dogs, so—
Shimel: Yep!
Richter: —that was an issue. So, the way that we envisioned this to go is actually differently. We believe that you should—and you mentioned this—you should always and continuously check whenever your changes in a way, whether that’s still in compliance
If you have a—like, let’s say a CI/CD pipeline where all the changes to your infrastructure automation go through, then as part of that pipeline, you can continuously test for the compliance of your components before they hit your production environments. So, you can catch issues earlier, you can facilitate those discussions really, really early, and you can actually get to a state where you don’t have the big bang, everything needs to be frozen for free weeks, nobody is able to touch code any more while Security looks at everything.
You get out of that rut that slows your organization, you get into a mode where you can continuously changes, because that’s what we want is faster delivery and be secure at the same time.
Shimel: Got it, got it. And that—you know, Dominik, that really story right there actually sums up a lot of experience that I think folks have had, both in Dealing with the Security team, as well as the Security team dealing with the DevOps team.
But guys, as I promised you before we got started, we were gonna try to hold this at 15 minutes, and we’re at about 17 or 18 already. So, we’re gonna need to wrap up. Maybe perhaps we can have you both back on at another DevSecOps type of discussion or maybe go a little deeper.
But for now—Dominik Richter, Dan Hauenstein, thanks so much for being our guests on this chat. We’d love to hear more about Chef’s DevSecOps adventure, so hopefully, we’ll see you both on DevOps.com and Security Boulevard.
Hauenstein: Sounds great. Thank you.
Richter: Thank you so much, Alan.
Shimel: Thank you, guys. Guys, this is Alan Shimel for DevOps.Com and Security Boulevard. Hope to see you soon on another chat.
