DevOps Chat: Shifting Security Left and Right, With Contrast Security
So much is happening on shifting security left, but what about shift right? Jeff Williams, CTO of Contrast Security, gives us a great update on the state of DevSecOps, shift left, shift right and appsec, as well as DataOps.
Jeff is one of the sharpest people in the cyberworld, so this DevOps Chat is worth your time to hear what he is thinking.
Transcript
Alan Shimel: Hey, everyone, it’s Alan Shimel for DevOps.com and Security Boulevard. You’re listening to another DevOps Chat. I’ve got a really special chat lined up today. I’m joined by my friend, Jeff Williams, Founder—Jeff, is it CEO or CTO, I forget, of Contrast Security?
Jeff Williams: I’m a CTO. Who wants that CEO job? That’s a terrible job.
Shimel: Yeah, no, you’re the second person in two days to tell me that. [Laughter] Yeah, no, I went back to my natural CTO role. But anyway, Jeff—you know, Jeff, in a lot of ways, whether he’s CEO or CTO, and here, CTO, is the guy behind Contrast and a lot of the kinda groundbreaking and a novel, innovative approach to security and testing that contrast has pioneered.
Jeff, welcome to DevOps Chat.
Williams: Thanks, Alan. Good to talk to you again.
Shimel: Alright. So, Jeff—look, if people want to find out about Contrast Security, I’m gonna tell them to go to the web and check it out. We’re gonna talk a little bit about what Contrast does, but I really wanted to frame it in—hey, let’s educate the audience today a little bit. If you’re DevOps folks out there who are interested in DevSecOps, we’re gonna talk about two interesting technologies that are related that I think you need to know about. And if you’re security folk out there looking to, you know, maybe in DevSecOps or move, shift left into DevSecOps, these are must-haves for you. Primarily, we’re talking about IAST, right, and RASP. Jeff, give me the spelling of, the initials for RASP.
Williams: Yeah, so, RASP is Runtime Application Self Protection, that’s R-A-S-P, and IAST is Interactive Application Security Testing, or IAST.
Shimel: Perfect. Jeff, why do people need to know about these things?
Williams: Well, I think both Applications Security Testing and Application Self Protection are really important. And, you know, people talk a lot about shifting left, that’s kinda the IAST direction, but they should also be thinking about shifting right into production with Application Self Protection, because most organizations have no idea what’s going on in production. So, anyway, let me back up.
Shimel: Sure.
Williams: In 2002, people are starting to worry about Applications Security. OASP is just getting started, you know, we’re building the OASP Top Ten and WebGoat and stuff like that. And some new products have come out. We’ve got, really, three whole new classes of product come out—static analysis, dynamic analysis, and web application firewalls all came out about that same time.
Shimel: Yep.
Williams: And that’s what we’ve been living with. And they’re all interesting, but they’re all really kind of flawed. There’s two major problems. First is, they’re inaccurate, because they don’t have the full picture, right? None of those tools has all of the information you need to identify vulnerabilities, like static can only see the code, dynamic can only see HTTP traffic, OWASP can only see HTTP traffic. We didn’t even know about SCA tools or software composition analysis tools back then. Those are tools that analyze your open source libraries.
But all those tools only see kinda one view of the problem, and so they all make mistakes. And when you have inaccuracies, you have to have experts to come in and clean it up. And I made a lot of money, I ran a consulting company that, we ran those tools, we did pen tests and coder views, and you have to have experts if you’re gonna use that process.
So, now, you know, zoom forward 15 years and development has accelerated dramatically, people are using tons of libraries, they’re building code much faster, we’ve got automated pipelines. And those tools look like dinosaurs. They just don’t fit. You can try to “integrate” static or dynamic scanning into your pipeline, but it’s really a square peg, round hole. Those tools are slow, they’re inaccurate so you’ve gotta have people involved with tailoring and tuning them and weeding out the false positives and all that. So, it just doesn’t fit very well.
So, that brings us to IAST and RASP. So, about five years ago, we launched Contrast, and our idea was, if we could get inside the running application, just like a debugger—like an APM tool, like New Relic or AppDynamics, like a profile. If we could get inside the run time like that, we could observe both vulnerabilities and attacks really easily and super accurately, and then we could do real time decisions on whether things are vulnerable or whether things are being attacked.
And so, we started these two new classes of product. This IAST is for finding vulnerabilities at run time, so from within the running application, and then RASP is for identifying attacks and preventing them from exploiting your application, also from within the run time. So, there’s a variety of products out there. Contrast is one, but there’s other providers of IAST and RASP. Contrast’s unique thing is that we do IAST and RASP and SCA all in a single platform, but the big benefit of these classes of products, IAST and RASP, are that they’re more accurate and they’re real time, so they’re much more compatible with the way people are building code.
Shimel: Absolutely. So, I think, Jeff, you started us off here and, you know, let’s just recap. So, on the first day, maybe, or the second day or the third day, God created static and dynamic testing.
Williams: Yeah.
Shimel: As well as web app firewalls. And for a long time—and look, I’m gonna put the time frames around these, it’s gotta be around, what, 2006, ’07, maybe?
Williams: I mean, even earlier, like 2002 and ’03, the first tools started coming out, and that’s all we’ve had, all the way up ‘til—
Shimel: Right, and that was the CER.
Williams: – three or four years ago. Yeah.
Shimel: And, you know, cracks start to appear. No one’s here to throw dirt on them or to say that they don’t serve purposes and so forth, but you know, we continually try to hone our tools as well as our skills, and that’s why tools like IAST and RASP, in that category, now start to supplement—would you say they supplement or replace dynamic and static?
Williams: Well, the way we do it, they replace it. You know, different vendors do different approaches here. But we do a little bit of static and a little bit of dynamic, and a lot of IAST, all from within a single agent that executes at run time. So, in a way, what we’ve done is helped solve some of the deployment problems with static and dynamic and added this huge new capability of IAST to our agent. So, in that sense, I think you can replace your existing tools with a unified product.
On the RASP side, it’s a little different. You know, there’s a little bit different use cases for OAuth and for RASP. So, you know, I like the idea of having a cloud OAuth out there that’s protecting everything with a kind of high level rule set, not tailored but just generic stuff to filter out a lot of the noise, maybe handle some of the DDoS attacks, SSL issues, maybe.
But if you really want to block attacks, then you need RASP. RASP is right there in the application, it understands the context, and can do a much better job of identifying what’s a real attack and what’s a probe and what’s legit traffic.
Shimel: Mm-hmm. Fair enough. Now, so, Jeff, how do—so, I’ve got to assume it’s the security folks who are implementing these tools, not the DevOps teams or the developers, or am I wrong?
Williams: Well, I mean, there’s different models. You know, sort of more traditional organizations, the security team leads the charge and probably buys the product and then is in charge of facilitating it with development teams and operations teams.
But, you know, more modern development shops where you really do have development, security, and operations working together, they’re really heading down that DevSecOps path. There, I think, is—you know, an opportunity for the development teams to really kinda lead the way, and they’re the ones that are getting the product. They’re deploying—I mean, IAST and RASP are easier to deploy than static and dynamic by a mile. It’s just exactly the same way you’d deploy New Relic or AppDynamics. You know, you just add the agent to your application, restart, and it goes to work in the background, finding vulnerabilities and blocking attacks. And so, it’s something that development teams can do for themselves.
So, in those kinds of organizations, we typically implement sort of a self-service model where dev teams can come get it, come use it, can get the benefit and, really, start committing clean code so they move security way left and then they can also get that extra protection in production.
Shimel: Yeah. And that brings up something, Jeff, that I think is worth noting, and that is kind of the dynamics of the DevSecOps practice that we see in enterprises and so forth. That it really is, there’s a handoff that takes place here, right? Security teams often, it may be their budget, it may be you need their approval, it may be that they’re the selectors of the tools that these teams are gonna use. But ultimately, I think the success of a good DevSecOps tools is really dependent on getting the DevOps team—the developers, the QA, the test people, and the Ops folks—on board with it, and comfortable using the product.
Williams: Yeah, that’s right. So, you know, I spent many years being in the critical path, right? Doing the pen testing, doing the code reviews and so on, and I realize it doesn’t scale. It’s never gonna scale that way. We have to get the security folks off the critical path, and they need to take a role not finding the bugs and dealing with the vulnerabilities themselves, but empowering development teams to do that for themselves.
So, they need to become coaches and tool smiths more than the person in the weeds that’s finding the XSS and finding the SQL injection and so on.
Shimel: Agreed. I mean, and there’s a couple reasons for that, and let’s hit those. Number one, I think it’s just a sheer numbers problem. We just don’t have enough security people to—
Williams: Yeah, the economics are totally broken. You can’t make it work.
Shimel: No. It’s—yeah, it doesn’t work. But secondly, I think, frankly, security people tend to become bottlenecks. Not just because there’s too few of them, but by their nature, they maybe try to hold onto things a little tighter than we may want them to.
Williams: I think that’s probably true.
Shimel: Yeah, maybe. I mean, you know, just saying.
Williams: Occupational hazard.
Shimel: Yeah, just saying, but—so, let me ask you then, you know, in the case of contrast, how, you know, when you’re going into an organization, is that pretty much the path it follows?
Williams: Typically, we have to work with the AppSec team, for sure, but we also always bring in the development team representatives, because we want to make sure they’re bought in. You know, if the AppSec team buys it and the developers the it, it’s never gonna work. And that’s kind of the path that static followed. [Laughter]
Shimel: Right.
Williams: But, you know, we’ve built a tool that we designed for developers from the first day. We expect them to be able to use it without any support from anybody. They should be able to find and fix their own vulnerabilities. And we’ve really put our money where our mouth is, there. We made a free version of Contrast anybody can use called our community edition. It’s full powered and you can use it on one application, so it’s—you know, you can go try IAST and RASP and SCA today for free, forever.
Shimel: Great. I mean, and—well, you might as well give the URL if we’re gonna do that. Where can they go try that for free, Jeff?
Williams: Oh, sure. Yeah, it’s at www.ContrastSecurity.com/ce for Community Edition.
Shimel: Okay. Hey, I’d like to turn our conversation in another direction, if I can, or, you know, in a different topic. So, you know, you and I have both been in security a really long time and we—you know, there was a period, I would say, over the last 7, maybe more years, 10 years, where there were a lot of security people who said, “Hey, if it’s not about app security, I don’t want to—it’s not relevant,” right? That app security was kinda the final frontier in security.
Williams: Sure.
Shimel: And it—look, there’s no doubt. I mean, we live in an application centric world, so of course, application security is important. But one of the things I’m seeing, especially from the DevOps side and maybe from the Container Journal with Kubernetes and all service meshes and all this kinda stuff is that data is making a big comeback, right? Whether you wanna call it DataOps or somehow wrapped around AIOps with ML and all this stuff, but, you know, the importance of protecting the data is, again, becoming—maybe that was something that somehow we didn’t focus on as part of app security, but we’re certainly seeing a renewed focus on it now. What do you think about that?
Williams: Well, I think what I’d say is that security is always most interesting at the margin, right? So, when we were doing this big transformation from desktop apps over to the web, that was where the really super interesting work happens. But, you know, over time, things get commoditized, right? So, you know, we don’t worry too much about hardening desktops any more. That was a big service back in the early 2000s. You’d pay a lot of money to make sure all your machines are hardened. But it’s been commoditized somewhat.
So, whenever there’s disruptive change in a particular area, that’s when we see a lot of interesting security work has to happen. And so I think, most recently, that’s kind of data and ML/AI and—you know, we still see a lot of people still focused on lift and shift cloud transformation kinda things. You know, there’s a growing recognition that libraries are a real concern.
And so, you know, I’d say AppSec is interesting because it’s always the top layer, right? Like, it keeps floating up the stack where the innovation is. So, you know, we’re not looking at people worried about securing the deployment of their app server as much as we’re worried about, now, people are refactoring monoliths into APIs and there’s a bunch of interesting new security challenges to make sure your APIs are all secure.
So, I’d say that’s kinda what’s driving where all the interesting security research is done in our market. But it doesn’t mean that those other things are unimportant, it means that they’re just—you know, we’ve got them pretty well figured out and under control, they’re a well-developed product in that space and, you know, we’ll wait a bunch of years for something else to disrupt it.
Shimel: Yeah, agreed. I wanted to bring up another kinda megatrend, if you will. I don’t wanna call it a megatrend, but it’s really a gravity well that seems to be sucking so much technology and tools around, you know, orbiting around it, and that’s Kubernetes. What effect has the whole KubeCon—you know, Cloud Native is up your alley, but the whole Kubernetes kinda movement in terms of cloud infrastructure. How is that affecting what you guys are doing at Contrast?
Williams: Well, it’s interesting. It doesn’t affect us directly, and I think of sort of infrastructure security as everything below the app layer. All the platform that’s required to run the code, and I think Kubernetes is really interesting because it’s making that infrastructure really standard, really software driven and easier to manage and all that. But it doesn’t really affect what we do, because we’re focused on that, you know, from the app server and up.
Shimel: Right.
Williams: Which, it runs great in Kubernetes, it runs great in regular raw containers, it runs on metal, it runs in the cloud, it runs in elastic environments. We go wherever the app runs, and it doesn’t matter that much to us what happens underneath it.
Again, I think it’s super interesting, and we are focused on making sure we’re super easy to deploy in those environments. Like, we want to make Contrast sort of run with Contrast, have a button that just says, “Run with Contrast” in every environment—AWS, Azure.
Shimel: Sure.
Williams: We’re doing a ton of work in Azure, pivotal containers and everything, so.
Shimel: Yeah, look, this week out at VMworld, right, clearly DevOps and Kubernetes containers is the way to go. But I’m not talking about just pure running in a Kube environment, I’m talking about the data feed, if you will. Or not the data feed, but in terms of managing my infrastructure, in terms of managing my app, getting that feed of info from Contrast—
Williams: Yeah.
Shimel: – so that I don’t have too many screens, you know what I mean? One of the nice things about Kubernetes is, all of these tools kinda are feeding their data feed into it, so you’re able to orchestrate and manage across a very scalable, large distribution.
Williams: Well, that’s interesting. I mean, Contrast is a really great sensor for, in operations, for who’s attacking you, what systems are being targeted, what attack vectors are being used, and most often, I see people taking that information and either analyzing it right in Contrast or else they feed it into their SIM and they get kinda application visibility there.
But I think you’re right that there is an interesting role for feeding that into your Kubernetes management and if you see something getting attacked or has been compromised, then you can respond much faster in that kind of environment.
Shimel: Yep. Agreed, agreed. So, Jeff, you know, we’re coming into fall and we were talking beforehand about traveling around the world, kinda spreading the message—what do you see coming up as we head into the last quarter of the year next year on the horizon in terms of maybe either threats or new innovation or with Contrast or without. It sounds like I’m ordering a CAT scan—with Contrast or without Contrast, right?
Williams: Yeah.
Shimel: Interested in your thoughts there.
Williams: Well, I think the news cycle is gonna be dominated a lot by election security. We’ve got a big election coming up in the States, as you probably know. So, we’re absolutely not prepared for that. I did some work on election systems over the years. I know some of the risks. We’ve got old technology that wasn’t really designed with the right threat in mind. So, I think that’s gonna dominate the news cycle.
But in terms of new security technology, I think we’ll see a lot of consolidation. You know, there’s just—there’s so many vendors out there that are doing the same thing. You know, there’s Clampitt, there’s a dozen, two dozen software composition analysis products out there and, you know, that just doesn’t make sense to me. So, I think, you know, we’ll start to see some of that consolidation.
I’m interested in serverless. I think that’s gonna be a really big area. We’ve already seen a number of our customers that are investigating serverless. Some of them are, you know, they’re building out apps on serverless, so it’s gonna be really interesting and big, and I think that’s gonna be an area for security to really expand into as that technology grows.
Shimel: Yeah. No, we’re definitely seeing that here, all the time.
Williams: Yeah.
Shimel: Interesting stuff. Jeff, we’re past time, to tell you the truth, but I had a feeling this one was gonna go past time. We always—our conversations always seem to meander around. Hey, man—continued success with Contrast. As I told you off mic, I run into people talking about Contrast all the time, though there are players in IAST and RASP, you guys—it’s kinda your category. So, congratulations on that, keep up the great work, and we’ll check in with you soon.
Williams: Well, thanks, Alan. Great to talk to you as always, and I’ll see you out there.
Shimel: Yeah, we’ll see you on the circuit, as they say.
Williams: That’s right. [Laughter]
Shimel: Hey, Jeff Williams, CTO of Contrast Security, here on DevOps Chat. This is Alan Shimel. Thanks for joining us. Have a great day, everyone.
