When discussing security in DevOps, we often focus on the security tools instead of the DevSecOps process itself. In this DevOps Chat, ZeroNorth CEO John Worrall takes us to the root of “why” DevSecOps, focusing on the business benefit, gain and measurement of what we seek to accomplish through DevSecOps. John advocates we concentrate on the process and data enabling us to assess risk, prioritize the most beneficial security work and for decision making to creating business value.
As usual, the streaming audio is immediately below, followed by the transcript of our conversation.
Transcript
Mitch Ashley: I have the pleasure of being joined by John Worrell, who is CEO of ZeroNorth. Welcome, John, good to be talking with you today.
John Worrell: Thank you, Mitch. Good to be here as well.
Ashley: And we’re talking about security and DevOps, DevSecOps. But before we get to that topic, would you tell us a little bit about yourself, let our audience know a little bit about ZeroNorth, too?
Worrell: Sure, I’d be happy to, Mitch. I’m John Worrell, CEO of ZeroNorth. We’re in the DevSecOps space, maybe with a different approach that, a lot of times people focus on tooling. We believe that you need to kinda build a process out first for DevSecOps to actually have business value, and I’d like to maybe talk through that with you, Mitch.
Ashley: That’d be excellent. I’m all about the business value, too. [Laughter] So, let’s talk about that. So, usually, when you say DevSecOps, it’s about shift left, how you need to get to the security people working with the software folks, how do you help developers write more secure code? You get to the tooling conversation.
So, I think you’re talking about—well, let’s stop for a minute and ask why are we doing all that stuff? Yes, let’s create better app security, but why do we need to make this a process that produces, maybe, some business value, measurable results, those kinda things?
Worrell: Yeah, you bet. That’s exactly right. We’re all for the tooling, we’re all for building the bridges between security and the Dev teams. But you have to have an objective in mind, and you have to have some help along the way. You have to have some data along the way that’s gonna actually get you there to pull all that together.
One of the best quotes I ever heard that got applied to this was channeling your inner Deming, which is, you know, if you can’t describe what you’re doing as a process, you don’t know what you’re doing, right, and there is a real lot of truth to that. If you step back and look at AppSec over the years, it’s been very tool-centric, very sporadic, anything but a process. When you look at DevOps, it’s a process, it’s repeatable, it’s scalable. It’s kind of a self-learning or positive flow of information with telemetry so you can get better and better at it over time just by learning from your past experiences.
And when you think about integrating security into Dev to drive DevSecOps, you have to think about it the same way, and I think that’s where it all starts. This is a process, this is not a tool selection, this is not just a scan or an integration, it’s that process that you need to build first, and then you can start building out your tooling, your technology underneath that.
Ashley: You have a really good point, and if I’m being over general here and generalizing this, as security professionals, we kind of think of, “Let’s buy boxes, let’s buy software, let’s put functions into the network, into software, and not into the software development process that will solve our security problem.”
But security is not just people attacking you, it’s also how you do your work and making sure you create a secure environment, you operate securely, write secure code. So, I think you’re spot on about the process and how you can do that consistently, referring back to Deming, right?
Worrell: Yep.
Ashley: You can’t manage what you can’t measure, your adaptation of that phrase. So, talk to us a little bit about how do you make that real? When you talk with people, how do you help them sort of elevate the conversation to that and then get on the right track?
Worrell: So, I think it starts out with that process conversation and whichever analogy you’d like to us for that. Think about it this way—the process, in our view, works like this. You’re gonna set some kind of a governance standard for your organization. You can’t have each Dev team setting their own or each business unit setting their own, you’re gonna wanna try to get global visibility so you can actually have effective global risk management. And we’ll start that as a kinda catch-all for the business objective—but in a sense, that really captures what we’re trying to do with DevSecOps. You need global risk management across your organization. That means you have to have some visibility into it, but you have to have a way to impact your current state to make it better, and you need a process to drive that in a continuous way.
It starts with setting some governance standards and saying, “Okay, what is our ideal objective for our top tier applications? What is our ideal objective or governance model we wanna put around our mid-tier?” or whatever the application categorization might be. Then you wanna make sure you’ve got a continuous process to build the data that’s gonna inform you, whether or not you’re actually meeting those objectives. You have to look at performance reporting so you can measure how you’re doing against that.
And then you have to be able to action that intelligence to say, yeah, that data is helpful to me for a number of reasons. Number one, I get visualization of risk, I can get prioritized remediation if I do this right so my developers can make intelligent business decisions about which vulnerabilities get fixed now before we progress the build and through the build. The third piece of that is, which teams need what kind of training on security coding, good security coding practices? Instead of trying to treat everybody the same, use this telemetry to say, “You know what? Team A is struggling with cross-site scripting. Let’s go do a lunch and learn with those guys and watch the immediate impact we’re gonna get from that” and then let the process continue and go all through. There’s a lot of technology in there, there’s a lot of things in there, but it starts with the process.
The next piece that’s really critical is the data that comes out of that, right?
Ashley: I was just gonna ask you about the data part of it. [Laughter]
Worrell: [Laughter] That data drives everything. It drives so much. You know, we had talked about this idea that you’ve got different tooling—well, sure you do. You want the best tool that you can get, you want best of breed. But trying to pull those tools or the data from those tools into some meaningful, actionable intelligence is a key step in the process, right? You wanna take different data points and put them together so you get a complete view of what the risk posture is for that particular target or entity or application you’re working with.
We talk about the analogy of the blind man and the elephant. You have four blind men all experiencing an elephant from different places, and they all can come up with a different understanding of what they’re really touching and trying to investigate. And it’s a perfect analogy for a multi-tool environment when you’re scanning across the pipeline that, if you just look at one experience or one tool, you’re not gonna get a complete view of what’s going on.
Imagine the difference of being able to just do static scanning and realize that you’ve got all these highs and criticals, but not compare that with your dynamic. So, a lot of those highs and criticals may not be exposed in my environment, right? I wanna pull those together.
I’m trying to understand, number one, where the risk is, but I’m also trying to optimize my developer productivity and making sure they’re not fixing a bunch of stuff that doesn’t need to get fixed, if I’ve got a compensated control in place or it’s just not exposed already. That’s not high on my list. I want to really focus in on what’s valuable.
So, that data can be used for making good business decisions on risk. It can be used for prioritizing remediation. That data can be used for, you know, call it the wall of fame, wall of shame. It’s how do you really measure and incent and reward your business units for meeting their risk management targets, right? Again, how do you help those that are lagging behind, how do you help them get better?
And that, to me, built into this process, is where you get real business value. You’re getting the faster delivery of software, you’re getting the better developer productivity out of this, you’re getting that risk management layer and visibility you need, but you’ve got it as a process, and you can measure week to week, month to month, quarter to quarter, how much better you’re getting at it. That, to me, is a real business solution.
Ashley: You know, you described a lot, so let’s unpack some of those things. The third piece of it usually is, you know, you talk about people process and technology people. What are the kinds of roles of people who are gonna be using that kind of information, that kind of data? Because we’re often talking about getting security information into the developer’s hands so they can fix things, but you’re also talking about, “Well, what should we fix? Let’s not waste our time on things that don’t matter, right? The environment secures against cross-site scripting, so let’s not worry a much about maybe that as something that can be exploited.” Who uses that information?
And then I guess the third part of it is, it’s about continuous improvement, that’s a cyclical process of, “Are we getting better? Are we getting value? Is there benefit to the work we’re putting in on this?”
Worrell: You bet. So, you’ve actually said a lot there, too, so, I’ll try to—
Ashley: I did. I’m just following your lead, John. [Laughter]
Worrell: Yeah. [Laughter] Good, we can confuse each other in this whole process.
So, you know, if we start with this idea of the continuous improvement, just kinda going backwards here, the whole goal is to have that process, which is a continual healing process, if you will, you’re always gonna get better. DevOps does that with telemetry about, “What is the productivity of my developers? What are my key metrics on how many story points I’m taking down, how many am I delivering, and am I getting better, sprint after sprint after sprint?” All great stuff—the same model plays out in security.
That ties back to one of your comments about the role of the CISO. You mentioned, you know, typically, security guys, via technology, they deploy it. And that works or a proactive control, which is what security’s been doing so much for. My days of running the product for RSA SecurID and working at CyberArk and any kind of blocking technology or control—it is. You buy it, you deploy it, you set it and forget it, for the most part, and it works, right?
By the same token, this isn’t really responding on the SOC side, either, right? This is not responding to an in process attack, this is a different approach to security. And I think the reason that’s important is, number one, businesses are demanding more business metrics, business telemetry out of their security programs, what am I getting for my investment? How do I know I’m investing in the right things? Am I spending in the right places? All of those things are really important, right?
And the role of the CISO, by definition, is evolving as well. And you can see the people that were running security teams 10 years ago are very different than the model who’s out there now. Many people have grown into that role. Other people have come from the business side of the house, and they’re not the technology experts that were good at configuring firewalls that were really trying to deliver business value to the organization. And if you’re gonna step from infrastructure into the world of application security, you need to be able to have value to the business, and this data is a great way to deliver value to the business.
Ashley: Really important point, because the CISO role is evolving, and oftentimes, it’s becoming a CIO/CISO kind of role, which means you’re getting into the application stack, not just the network stack. Not saying that they weren’t worried about the app stack, but now you’re getting much more into the nitty gritty of it. And are your security people software people? Well, not necessarily, but they are very accustomed to getting data and responding to that data, and in this case, maybe helping development teams, developers, others with understanding what the true severity, not what some scanning tool might say, right?
Worrell: You bet.
Ashley: Which is sort of our history with vulnerability management, [Laughter] to really help them understand, “Okay, great”—and then demonstrating to the business, to compliance, to whoever you may need to be reporting to, it could be customers as well, to say, “Here’s what we’re doing. Here’s the actions that resulted from investment in these tools, people, and processes.”
Worrell: And that customer angle is actually really important. And I hate to use the word SolarWinds, but I’ll use it. It’s just put, yet again, a big spotlight on software supply chain, software security, and how critical that is. And so many organizations now are asking of us, as well as our customers, “What is your software development process? Prove to me you’ve got one.” Right? Great use of this data.
When you think about your business line risk owners, the people that are actually responsible for data, they work for the GM or the SVP of that business unit, they’ve got the risk management challenge. They need this data to do their job well. If you take that data to the board, our data is being used as part of the quarterly board package to talk about how they are addressing and how they are improving the risk posture of the organization.
And then, I wanna go down, really, one level deeper. Because when you think about this, you know, integrating into the DevOps process means that it’s not necessarily just about the developer making that independent decision. Typically, there’s a product owner in there some place that’s gonna be making some decision about what’s gonna get done now versus what’s gonna get done later, right?
So, being able to feed that product owner with the data they need to help do the triage and make those decisions, that’s another great use case of this data we’re pulling together.
Ashley: You know, you mentioned a lot of roles, too, including the product person. In your experience with ZeroNorth—and I really appreciate your background in security, too, so we can relate about those days as well—what’s most often, when people come to ZeroNorth and say, “Hey, we need your help, here’s what we need your help with?” Is it the software team, is it the product team, is it the compliance group, is it the CISO/CIO? Usually, what’s that initial driver for engaging with you.
Worrell: Yeah, there’s probably two different ones we hear most commonly. One is, “Hey, I’ve got a somewhat mature program, I’m running two or three different tools. I can’t make heads or tails out of the data, or if I try to do it, it’s manual, I can only do it once a quarter or once a month, it’s just too labor intensive. So, I think I’m getting good, I’ve got a decent process right now for scanning, but I wanna start pulling that data together.”
The second use case is those that wanna start out on building what we would call a federated or a shared governance model, and it’s led by the security team, perhaps, but they know they’ve gotta bring in the business line owners into this process, or business line risk owners into the process. And they say, “Hey, can you help me get data out there so I’ve got a single source of vulnerability truth or my applications?” And I’m looking at the same data that they’re looking at, we’re all making decisions off that same set of data so we can build a governance model that makes sense.
The security guys wanna work in partnership with the business owners and the people that are actually doing the software development and risk owners in the business. But that relationship is gonna get built on having really good data and everyone using the same data. I think that’s another use case.
The third one, which is a variation of that, is people that are coming in and really saying, “Hey, listen, I need to go to full DevSecOps right away. I know that I can put this layer of reporting and analytics on top of my current tooling and that’s a great start, and I’m gonna build this over time.” It’s a fine strategy. Other people are coming in because they’re just getting started or they just have a business imperative to do it and they’re saying, “We’re going to DevSecOps right now, and we wanna do the pipeline integrations as well as the reporting and analytics that we’ve been talking about so that I do get that data in real time, I do have a consistent scanning process, it is automated, I don’t have to worry about the developer forgetting or not doing it, and I’m gonna get that data value out of this in that particular way.”
Ashley: Yeah, “Help me accelerate through the learning curve instead of making all those mistakes myself to get to DevSecOps, if you will.”
Worrell: You bet, you bet.
Ashley: That second example especially kind of is a multiplication of the first one, which is, you have Dev teams with all this data, maybe it’s the primary group—usually, it’s multiple, right? How do you pull it together into something? They can’t make sense of it. How do you do that across the enterprise to meet compliance requirements or even just your own internal assessment and reporting up the management chain maybe to the board.
Worrell: You bet. If you step back, the biggest concern we get out of just about everyone we talk to is a CISO or a Risk Manager saying, “Hey, help me, I’m flying blind. I don’t know what highs and criticals I’ve got in my production environment right now. I just don’t know. I don’t have visibility into it. And for me to get it, it takes too much effort, and once I get it, it’s outdated, because it’s 30 days old. I’m pushing code every day” or every week or whatever it might be.
And that is the primary motivator or so many people who just say, “Gimme that visibility, and that’s the starting point. And then at least I know what I’m dealing with and then I can start building out a program that’s gonna help me address that over time.”
Ashley: You know, you brought up SolarWinds, so I’ll bring up COVID. What have you seen happening over the last 12 to 18 months with the acceleration to the cloud, acceleration of digital transformation projects? Has it taken these same issues and just made them even more visible critical to address, or have new problems emerged?
Worrell: I think it’s more of an acceleration of the entire process. In general, COVID has driven people to be more comfortable or more reliant on relationships with their customers, with their partners, with their employees. And that means more software, by definition.
So, as digital transformation accelerates because of more online interaction and new business models that this opens up, it’s just really accelerated the pace and some of the maturity of people coming. The types of questions we’re getting from our prospects now are much more advanced than they were a year ago. And that just shows that the market is really getting smart about this and they’re kind of moving beyond the tool only approach to say, “Okay, how do I get some business value out of this that can really, really help us move our risk management program forward?
Ashley: That’s one of many indicators I see, kind of data points that are saying the technology groups, the software groups are getting out from under, looking at themselves and starting, trying to get aligned with the business and meet where the business is headed.
Worrell: And as a big consumer of software, as we all are in our lives today, I’m really happy to see that, right? I mean, that’s what I—I know it’s gonna take bringing the two together and working cooperatively in that federated or shared model to make this work, and I’m really happy to see that kind of a progress. Because, like you and everybody else, software just drives so much of our daily experience.
Ashley: It is. Can’t do much without it these days. Well, it’s been great talking with you, John. Where can folks learn more about ZeroNorth?
Worrell: Well, that’s easy, ZeroNorth.io. We’d be happy to talk to you. Take a look, see what we have, and if we can help you out or you wanna hear more about it, we’d love to chat with you. Thank you very much.
Ashley: Yeah, I think we’ve had a great conversation. Hopefully, that’ll spark some folks to elevate that conversation with you and the ZeroNorth team, so take care, we’ll talk to you again soon.
Worrell: Thank you, Mitch. I appreciate it.
Ashley: You bet.
