The Application Security Podcast

Jeff Williams -- The Tech of Runtime Security

• Chris Romeo • Season 10 • Episode 23

Share episode

Jeff Willams of Contrast Security joins Chris and Robert on the Application Security Podcast to discuss runtime security, emphasizing the significance of Interactive Application Security Testing (IAST) in the modern DevOps landscape. After reflecting on the history of OWASP, the conversation turns to the challenges organizations face in managing their application security (AppSec) backlogs. Jeff highlights the alarming number of unresolved issues that often pile up, emphasizing the inefficiencies of traditional security tools.

Jeff champions IAST, and here are a few highlights that he shares. IAST is ideally suited for DevOps by seamlessly transforming regular test cases into security tests. IAST can provide instant feedback, leading to a Mean Time To Repair (MTTR) of just three days across numerous applications. Unlike Static Application Security Testing (SAST) or Dynamic Application Security Testing (DAST), which can take hours or even days, IAST can complete security testing during the build, fitting within the tight SLAs of modern pipelines.

IAST offers developers comprehensive insights, which aids in a better understanding and quicker resolution of the identified issues. It is also adaptable, as IAST can detect vulnerabilities before they are exploited. Jeff argues that IAST's ability to work with existing test cases and provide rapid feedback makes it a perfect fit for the fast-paced DevOps environment.

Jeff emphasizes that while runtime security can be a game-changer, it doesn't replace other essential aspects of AppSec programs, such as training. In conclusion, Jeff Williams champions IAST as a revolutionary tool in the application security domain. Its adaptability, efficiency, and depth of insights make it a must-have in the toolkit of modern developers and security professionals.


Links:

FOLLOW OUR SOCIAL MEDIA:

➜Twitter: @AppSecPodcast
➜LinkedIn: The Application Security Podcast
➜YouTube: https://www.youtube.com/@ApplicationSecurityPodcast

Thanks for Listening!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Chris Romeo:

Jeff Williams is a veteran application security expert who founded and led OWASP, Aspect Security, and Contrast Security. Jeff also created several highly successful open source projects, including jbom, jot, OWASP Top Ten, WebGoat, ESAPI, ASVS, and more. Jeff is an advisor to NIST, CISA, PCI Council, OASIS SARIF, OWASP CycloneDX, OWASP Foundation, and Eclipse Foundation, and advises many companies and agencies on application security. Jeff joins us to explain runtime protection, including both IAST and RASP. He helps us understand the benefits and differences from classic AppSec tools and even helps change my mind about the usefulness of IAST. We hope you enjoy this conversation with Jeff Williams Hey folks. Welcome to another episode of the Application Security podcast. This is Chris Romeo. I'm the CEO of Kerr Ventures, joined by my good friend Robert Hurlbut. Hey, Robert.

Robert Hurlbut:

Hey, Chris. Yeah, Robert Hurlbut and I'm a principal application security architect and threat modeling lead at Aquia. And definitely very glad to be here today as well.

Chris Romeo:

Yeah. And our, uh, our guest today is, uh, well-known name and face within the industry of application security. Also, somebody that I used to work with back when the year started with a 19 on them. That's a little bit of a picture of how old we are now. Now I, I have a lot more gray hair than Jeff Williams does, but

Jeff Williams:

Not really. It's just shorter.

Chris Romeo:

Well, and, and so we normally do security origin stories, but this is Jeff's second visit to the podcast. We did an episode with him back in November, 2018 called The History of OWASP. So if you want to hear the details of Jeff's origin story, you can go there. Um, and we're gonna talk about runtime security today. Um, but Jeff, you, you had kind of given us this note about 1.7 million issue backlog in Veracode and. Without any other details. I was like, okay, let's start here. I wanna unpack, tell us the story behind this, this backlog.

Jeff Williams:

Well, so that story is pretty easy. You could ask just about any CISO or AppSec lead in any company about their AppSec backlog, and the answer you get is not gonna be fun. It's gonna be hundreds of thousands of issues, or in this case, millions of issues that those tools have identified. And they, they just get put into some tracker, right? Sometimes it's Jira, sometimes it's an ASPM. Sometimes it's uh, you know, some spreadsheet or something. But those issues just sit there. They're not really getting triaged or fixed because there's so much lift human work associated with, with doing that. So that's kind of the pattern that that happens. And if you back up, it's kind of obvious that it would happen, right? If you use noisy tools. They're gonna generate a big pile of stuff that needs to be triaged, and nobody has the resources to do it. So you're gonna be generating this giant backlog and it's just gonna sit there. And I think some companies count that as success.

Chris Romeo:

Hmm.

Jeff Williams:

I don't think that works. So, uh, that's, that's why I'm still working in this industry is because it's, it is broken.

Chris Romeo:

What's the root of that problem? Because I remember in the past when tools were, were judged by the volume

Jeff Williams:

Yeah,

Chris Romeo:

of findings that they could create, but like we, it doesn't seem like we grew out of that though. Like that's still, it's still the prominent way that people think about tools, even though it does result in a lot of pain for the people that use the tools.

Jeff Williams:

I think there's two things. The first is just fundamentally SAST and DAST tools aren't that accurate. They're a little different, like DAST tools tend to miss a lot of stuff that's real. SAST tools tend to generate a lot of false positives, uh, but the, the tools themselves are inaccurate because they don't have enough context. So just looking at the source code, you really don't know what that application is doing or how it works. And the same thing with DAST. Just looking at HtDP responses, it's impossible to really see what's going on inside the running code. So you just miss a lot. That means you're gonna generate both over, over identifying things and under identifying things. And anytime your tools aren't accurate, you have to have people involved. And there's just not enough people to do that, so it doesn't scale.

Chris Romeo:

Yeah. How, why do you think, I'm sorry. Go ahead. Go ahead. Finish your thought. Finish your thought.

Jeff Williams:

Well, I think the, uh, the other thing is that people tend to evaluate AppSec tools on one app. And they look at the results and they're like, oh, those are okay. There's some false positives, but I could handle it. And they don't think about what happens when it scales to hundreds or thousands or tens of thousands of applications. And the absolute unmanageability of that when, when it all has to go through a very small number of AppSec experts. So they don't, they don't think about the scaling. They just think about one app at a time, which is really a pretty poor way to think about your AppSec program.

Chris Romeo:

And you're someone who's been around AppSec since the beginning of AppSec, like when, when it became a thing, uh, back in the late nineties. Why do you think the SAST and DAST Technologies that we have haven't gotten better? How, why, why do we still have this, the, the noise problem that exists in this industry? Why hasn't, why hasn't somebody just come up with something better and squash those things completely?

Jeff Williams:

It's, it's actually a really hard problem, and I make this analogy all the time. I say like, evaluating the security of source code is pretty similar to evaluating a contract for loopholes. And it's written in a customized language. There's terms of art in there. There's things that are, you know, are defined externally and you really need expertise to do that job. You need to see it kind of in action. And it's the same problem with source code. There's millions of lines of code and specialized language that has dependencies on stuff that you don't understand, and it's really complicated to to identify. I did, you know, 15 years doing pen testing and code review, and so I was like right there in the code looking at problems. And there's just tons of things that you can't really figure out either statically or with a traditional dynamic tool. Our, our insight was like, the only way to figure it out is to actually watch that code as it's running. Then everything's assembled. Everything's in context, and so there's, there's a bunch of advantages, but like, to your point, SAST tools have reached the limit of their evolution. Like they, they're not gonna get better because there's no more information there to get better with. It's a lack of context. That's the problem.

Robert Hurlbut:

Well, let's, uh, let's take a look at that. Um, what is, uh, runtime security? I know you're, you were talking about it and around it, but let's dive in, you know, and how does it work and how does it compare to some of these other methods?

Jeff Williams:

So runtime security is, it's really two things. One is it's a technical approach to monitoring code as it runs and identifying both vulnerabilities and attacks and other interesting attributes of an application that you wanna detect. Uh, it, it really applies to all the different pieces of application security. So you can do runtime testing. For security, you can do runtime software composition analysis against libraries. You do runtime protection of applications, and you can even do runtime observability that just, you know, identifies how your application works from a security perspective. But it, it sort of covers it, the whole gamut. It's just a different approach than using. Ss, you know, source code or the running application or, you know, manifests, uh, or repos or those kinds of things to generate it. The other piece of it, so that's, that's like the technical aspect of it, but the other piece of it is really more how you think about your AppSec program and building an AppSec program based on runtime data is different because it is much more accurate, it works in real time, and it's very scalable. So you can really empower development teams to do their own security work in a way that people talk about a lot when they say shift left and all this, but static and dynamic are really not very amenable to pushing onto development teams to do their own security because of the inaccuracy problems. WAFs too.

Chris Romeo:

So in your, in your AppSec program that you're building here, are you using SAST, DAST, WAF at all? Or are you just throwing them out and saying, we're not even, we, we shouldn't even, these technologies don't even belong in our pipelines.

Jeff Williams:

So there's a great article I read recently about security as a, as as trying to cover a square box with round stickers. I don't know if you saw it. Uh, I'll send you a link and we can add to the show notes, but there's always gonna be corner cases and like languages that IAST doesn't support, uh, yet is supports a pretty broad range, uh, of languages now, but you know, that doesn't do COBOL. It doesn't do C and C++. So there's like corner cases. So I'm not, I'm never gonna say there's no role for traditional SAST. I do think that DAST is easily replaced by IAST. In fact, IAST is a better DAST. It is a, it is DAST because it works at runtime. It has, you know, an impeller and an analysis engine. The pieces moved around a little bit, but really it's just DAST, uh, with, you know, positioned in a, a better place to get more data. Um, So I, I, I can see the, the need for DAST phasing out and WAFs do, uh, and WAFs overlap with RASP a good bit. Uh, RASP provide really high assurance protection within the, from within the running application,'cause it can be more accurate, has a lot more context. But there's things that WAFs do that RASP can't, like WAFs can look at SSL and things that are upstream from the application and help out there. They also kind of filter out lots of low hanging fruit, obvious attack stuff, and you can do it at your load balancer or your, uh, you know, in your cloud infrastructure somewhere. Maybe it's in your CDN. And so I think there's a, a reasonable role for a kind of a cloud WAF there. But if you want real protection against things like unsafety serialization and XXE, and things that are hard for WAFs to see, like how's a WAF gonna look inside your serialized objects for attacks? Probably not. So you really need that protection inside the running application.

Chris Romeo:

Yeah.

Robert Hurlbut:

Are there

Jeff Williams:

So hopefully that explains it. Like I think of, of runtime security as covering most of the, the box with a big round sticker that covers testing, SCA, protection, and observability. And then there's some corners in the box where there's, there's other things that you need to do.

Robert Hurlbut:

Okay. What about performance though? When, when these are running, uh, along with the code, inside the code and so forth, are there any, is issues there in impact as well?

Jeff Williams:

Yeah, it's a great question and something we get from customers all the time. And IAST and RASP have both come a really long way over the last eight years. Uh, RASP, for instance, is super fast. It takes about 1% of your CPU and memory and so on. So it's, it's actually really efficient that way. And I want you to just think about on the attack side, if you think detecting attacks is important, there's gonna be a performance hit somewhere. It might be in your WAF. Typical WAF takes about a, a millisecond or two to process a request. Uh, RASP takes much less than that, probably about a 10th of that for normal traffic. Um, so I think the impact is, is negligible. Um, and in a test environment IAST is really fast too. It's actually a little slower than RASP because detecting vulnerabilities is actually harder than detecting attacks that are exploiting vulnerabilities. If there someone's exploiting it, you have more information so you can make the judgment quicker. Um, but IAST is really fast. You'll never notice it as part of your normal test cycle. You can finish, uh, and you can finish all your security testing during the build. You know, a SAST run might take hours. A DAST run might take more than hour days, uh, and you can't do that inside a pipeline when your SLA is 15 minutes. So with IAST, you can get much higher quality results. Finish within your normal pipeline. You don't have to start some async process. So at the end of the build, you can test to see whether there were new vulnerabilities found, and you can report back to the developers immediately. They don't have to wait some amount of time to get their findings and triage'em.

Chris Romeo:

Let's, uh, let's unpack this IAST example a little bit'cause I wanna, I wanna. Check some of the things I think I know about IASTand, and get your, your perspective on this. You know, you were a part of the conversation that we had going on on LinkedIn about, uh, why DAST doesn't make any sense anymore. I know. It's, it's, it was a fun conversation and, you know, it was probably the most hate mail I've collected in the last number of years. That's okay. Uh, because I think it's,

Jeff Williams:

DAST vendors, I assume?

Chris Romeo:

There were, there were a few vendors who wanted to argue with me about the, the viability of the DAST technology. Um, but let, so one, one of the reasons that when I, when I thought about DAST and, and I decided, Hey, I'm just not recommending this anymore. It's not gonna be a part of the stack that I think people should use. There's a couple different reasons, but one of the big ones was it just doesn't work in a DevOps world. And, and the way software's being built. Now, if something doesn't work in a DevOps world, you can't. It's just not, it's not viable to use it in my mind. And so I guess one of the things that I thought I knew about, I thought IAST would suffer from the same problem. But I'd love to hear, Jeff, your perspective on why does IAST work at DevOps speed.

Jeff Williams:

Oh man. I mean, IAST is really ideal for DevOps. Uh, And the reason is it turns your normal test cases into security tests. So everything that you do to test your application, whether it's manual testing or automated testing, uh, uh, IAST this in the background, adding security tests to those things. So there's, there's literally nothing that you have to change about the way that you build, test, or deploy code to get value from IAST. The other thing is it doesn't require any security expertise. Like DAST really does. If you wanna get a DAST tool to crawl an app and fill out forms and, you know, properly, uh, traverse the application, you gotta teach it a lot of stuff. IAST really doesn't have that. Anybody could use this. You and Robert and any developer out there could find complex data flow vulnerabilities inside an application because IAST doesn't require vulnerabilities to be exploited.

Chris Romeo:

Yeah.

Jeff Williams:

So just by typing in the word Jeff into a form field, that data and all the other data in that Http request all get tracked in parallel through the application. If any of that data shows up in a SQL query, I ask checks back along that path to see like, Hey, was this data properly escaped or parameterized so that SQL injection would be prevented? And if it is, then nothing happens. But if it hasn't been, you know, the right defense isn't there, then we report a vulnerability with all the details. The Http request, the lines of code, the exact data flow, you can see the actual SQL query that was, you know, goes to the database. So it's, it's much richer, uh, finding for developers. And it appears instantly, like within seconds of just a developer, you know, testing their own code locally, even before they check it in. They can use IAST when they run that code locally, get findings, fix it, and check in clean.

Chris Romeo:

Hmm. So are you using the same detection and rule technology with IAST that you are with RASP, or is it a, are there any differences between those two?

Jeff Williams:

There are some differences and let me talk about how those two things fit together.'cause they're really two sides of the same coin. So the way I think about it, uh, the real problem is that in your stack there are a bunch of over powerful methods, op, my kids would say. And those methods are the core of, of vulnerabilities when developers don't take the proper security precautions before invoking those methods. That's when they introduce vulnerabilities. When attackers can make their attacks, reach those methods, that's where there's a problem. So IAST and RASP at the core, what they do is they, they wrap those methods with what I'll call trust boundary that looks at the data that's coming in and makes decisions based on it. So it's pre, it's actually pretty straightforward checks. If untrusted data makes it to a method that. Say, uh, sends data to the database or calls a our runtime process or, uh, you know, evaluates an expression or whatever. If untrusted data makes it to those things without being properly escaped or parameterized, then that trust boundary flags it and sends an instant notification to the developer. So, It's across the whole stack that this works. And it's really, if, if you think about like, you know, non-viable mechanisms, going back to the orange book, like that's really what we're doing is we're establishing trust boundaries around the, the things that are abused by most vulnerabilities. Same thing for RASP, same trust boundary, except now that trust boundary goes one step further. It says, Hey, is that data that just came into this method, like into the execute query method is, does that data modify the meaning of the query? If it does, then we know that it's an exploit attempt because no untrusted data should ever modify the meaning of your queries. That's the definition of SQL injection, and that's what that trust boundary enforces. So by rolling this out, you can eliminate whole classes of vulnerabilities, uh, run, you know, command injection, SQL injection, XXE, exodus, a bunch of different path, controversial, a bunch of different classes of vulnerabilities. Make sense?

Chris Romeo:

Yeah, yeah. I'm tracking with you. I mean, I see the, the, you know, back on the IAST side as far as being able to use your existing test cases. You're not creating, you, you don't have a security test suite and a functional test suite. You have a test suite that's being run, which you're already running in the pipeline. You know, it's already part of your pipeline process. So, so all basically you're saying with, IAST, all I'm doing is I'm adding an agent to the runtime that's being tested against in the pipeline and it's alerting on that. So it's causing maybe a tiny performance difference, but it's not, it's not taking me minutes or, or hours to days to weeks. Which, I DAST scans could take weeks sometimes, like if, if you, if it's looping and outta control. So, so it sounds like it is a, it is a better mousetrap. It's a better, it is a DevOps friendly way to have to, to still use the technology.

Jeff Williams:

And what we're seeing, the results that we're seeing, and we measure this super carefully, is really positive for this approach, including in DevOps organizations. What we see, the first thing we see is that you find a lot of vulnerabilities with very few false positives. The second thing we see is that those vulnerabilities are getting fixed. And we believe this is because we're giving instant feedback. So our MTTR across, you know, hundreds of thousands of applications is like three days. It's not 290 days like static or 315 days like DAST. MTTR goes way down. And what that does is it. It reduces the backlog. So we see like, you know, the, the line of new vulnerabilities getting discovered and then the line of vulnerabilities being remediated catches up and we automatically detect that those vulnerabilities have been fixed. So once, once you catch up to that line, then the question is like, uh, well how many new vulnerabilities are we introducing? What rate are they coming in at? We're seeing that go down too. So a typical project will introduce like four new vulnerabilities per month per project, which is, that's a decent amount. They pile up pretty quickly if you're not staying on top of it with. With IAST, we see that rate go down, so we're seeing 0.9 new vulnerabilities per month per app after you've been using IAST for a while, so you get to this really healthy place where you've cut your rate of new vulnerabilities dramatically. Your MTTR is really fast and you've worked off your backlog. That's where we want companies to get.

Chris Romeo:

What about reachability? I've heard that I, I've heard that mentioned in the con on the, in the context of runtime security, and, and our listeners know, I've talked about this a number of times. Like I was an early adopter of, of RASP technology. When I, I just looked at it as a small startup and said, this is gold because it I don't have to have all the different layers that we weren't really ready for as a small startup. I could have the one protection device that's gonna sit inside of the runtime and grab a hold of those things. But I, I've, I've, I've heard about reachability in the context of these tools. And so how does reachability play into this versus SAST, DAST and then IAST and RASP as categories?

Jeff Williams:

So reachability analysis is what you want to do if you, you think there's a vulnerability. And you want to try to determine if it's exploitable, right? So there's layers of this, right? If, if you get a static finding, you think there's a vulnerability, but you're not really sure if it's exploitable, right? Uh, happens with library vulnerabilities all the time, right? So you've got some open source library, you know you're using it, but you don't even know. I mean, you know it's in the project, but you don't even know if that code ever runs. And so, uh, There's, there's layers of this, and I would say like, reachability is like the first layer of the analysis. Like it's actually, it means it's, it's theoretically reachable code. It doesn't mean it actually runs, it just means it's like in some part of the control flow, if God knows what happens, that code could possibly run. We try to focus on what code actually runs. And so using, uh, runtime security you can watch the, the application run. We record exactly what libraries are actually used. We record what classes are loaded out of those libraries, and we report that back to you. Turns out only 62%, or actually only, uh, sorry. 62% of libraries never load. That code never runs. Only 38% of of libraries ever even load into memory. And so that other 62% it, it's not really very risky. You can come up with some crazy scenarios to think about why it might be, but generally they involve another vulnerability and then we focus in on the, just the code from those libraries that run. When you look at that app, you know, people always say like, well, 80% of applications are open source. That's super misleading. Iceberg is actually upside down two. If you just look at the code that runs, two thirds of applications are custom code and one third is open source code.

Chris Romeo:

Hmm.

Jeff Williams:

So just if you're focusing your efforts, like keep that in mind. Uh, don't just prioritize library security and think you're done. That would be insane.

Chris Romeo:

So when you think about these types of technologies, I'm curious from your perspective, what is, what, what is what, what are RASP and IAST not good at? I mean, or are they, are they a, a, a, a panacea? They can do, I can do everything that I need in my AppSec program.

Jeff Williams:

Well, from a a, I think there. They're your first best option for doing security testing with IAST and for runtime protection. RASP. I think like you should have those in your stack. That's the, that's where you're gonna get the biggest bang for the buck. I think runtime library analysis is also really interesting, but when you're looking at. Libraries at runtime, they're not really structured the way they are in a manifest. So it actually does help to look at a manifest so you can see which the top level dependencies are and which the transitive dependencies are.'cause generally you can only update the, the route dependencies. Um, so that's a view that, uh, we get statically and I'm not, look, I think it's, uh, You know, as a, as a CISO or an AppSec program lead, you have to place some bets and you gotta try to look for things that are the biggest bang for the buck. Uh, and that's where I think this, this runtime security approach to application security really wins. But there are, uh, you know, there's, there's corner cases. I wouldn't say you should, uh, You know, there's other parts of AppSec that are important. Uh, one thing I think, and I think you agree that's important is threat modeling. Uh, we are doing, so we're, we're doing this runtime observability thing now to try to help organizations get their head around how their applications actually work. And I know if you've done threat models plenty of times, you know that one of the hardest things is gathering the data. That you need in order to be effective at threat modeling. That's what the runtime approach can do. We call it runtime observability, and we can build a digital security blueprint of the security in your application. So that that's where, where you start the threat modeling process is you can start then asking questions about that data. Hey, should this thing have access control on it? Hey, what about this connection out to the internet that we didn't know was there? Stuff like that. Um, There's other aspects to AppSec programs, you know, like champions and, uh, training and so on, that that, you know, runtime security is relevant to, but it's not a replacement for.

Chris Romeo:

Yeah. Some of those other, yeah, kind of programmatic pieces and whatnot. Um, but yeah, I mean, when I, when I think about one being able to recommend one thing for...use small startups as an example'cause they're the ones that tend to not have the ability to support 17 tools in a pipeline

Jeff Williams:

Everybody's in that boat today. I mean, given the macro economy, everyone's looking at consolidating and coming up with a, a great minimal set of tools for their AppSec program.

Chris Romeo:

Yeah, I mean from, and for me, RASP was really that answer that was, I mean, I used, I used SAST tool because I happened to be working in Ruby on Rails. Brakeman was a available open source version of it that we, that we could integrate. Um, and, and we got SCA through MPM audit. And, uh, bundler audit in Ruby, like some of the, the free tools, but RASP was the one thing that I, I saw as, as providing the best gateway for what I was trying to do for the minimal amount of cost. And so that

Jeff Williams:

It's interesting that you, I, most people don't see that the, the production protection piece and the. The shift left, uh, build it secure piece actually overlap. And I think most organizations ought to do both. Like you should do your best to build secure code and also do runtime protection. Uh, but they. You know, if you were perfect at either one of those things, you wouldn't need the other one. If you had perfect runtime protection, you could write whatever code you want and it would just be secure. I think that's not a great strategy. I think balancing those two things is the right strategy. So that's, that's where I come down. But it's, it's interesting that you went right to that.

Chris Romeo:

Yeah. And that's one of the things, um, one, one of the dangers I've heard thrown around that, that an organ organizations could face with RASP is it could become a bit too much of a security blanket. Well, we've got the RASP. I. Okay. You haven't, I'm curious now,'cause you've, you've talked to lots of different companies that are doing this and it was one, it was, this is one of those things that people, it was something that somebody threw out, but there was not really data to back it up. It was like, ah, we could see that could happen. But in your experience, what, what do you see in that area?

Jeff Williams:

I've never even heard developers say that like, oh, we have, you know, RASP in place so we don't have to worry about this SQL injection that the tool just reported. It's, they're really kind of separate initiatives with separate metrics. At this point, I, you know, way back in the dark ages, I think I. Some development teams were like, well, we got a WAF. We don't have to worry about secure coding. But that was foolish then. And it's, it's foolish now. Like I, I, nobody does that.

Chris Romeo:

Yeah. All right. Anything else that we need to know about RASP and IAST and runtime security that we haven't, uh, we haven't kind of found our way into.

Jeff Williams:

No, I think this is a great overview. I'm happy to dive in deeper with, uh, you know, folks that are interested. Um, I do feel like, uh, Most organizations should be thinking about moving to IASTand RASP as a solution rather than sort of the traditional approaches SAST, DAST, and web app firewall.'cause those things just don't give enough assurance, particularly in modern environments. Uh, APIs security is a great example. Uh, it's really tough to get your API secured with SAST, DAST and WAF'cause none of those things really works that well on complex interfaces. And a lot of the new API security products are really just DAST and WAF shoved together in a thing and they're, they didn't really improve the security, but IAST and RASP perfectly on APIs. In fact, most of the applications we secure are composed of APIs on the server side. We've been doing it for, you know, eight years now.

Chris Romeo:

Mm-hmm. Do you ever see, uh, RASP moving outside of the web? Like what about RASP on an iot device or something like that?

Jeff Williams:

You could, I mean, the, the real question is, is what is the policy that you want to enforce? You know, those trust boundaries. What rules do you wanna put in there? Uh, you can, you can use RASP to enforce just about any policy you want. We focus on web apps and web APIs because that's where the most risk is today. But yeah,

Chris Romeo:

Yeah, the technology, I guess the I, the concept can be applied to anywhere, any place you're taking untrusted data from untrustworthy, potentially untrustworthy users. The concept is there.

Jeff Williams:

And you know, it's actually, it's not all just untrusted data, although most attacks come in that form. There's other things like weak encryption and, uh, things that, you know, vulnerabilities that aren't really data related, uh, that. Even lack of security headers on Http responses, like IAST, and RASP can detect and protect against those kinds of things as well.

Chris Romeo:

Hmm. It's funny that, that, that were the, those were the only things, the DAST tools I tested would, it would give me, was like lack of security headers. I'm like, really? I already knew that. I already knew what my security headers were set to. So,

Jeff Williams:

Yeah. Right.

Chris Romeo:

all right, Robert, take us into the lightning round. Ro Robert has become the lightning round guy. Um, for some, somehow, I don't know how

Robert Hurlbut:

Somehow or another.

Chris Romeo:

that, but there you go. Let's take us into these lightning round questions.

Robert Hurlbut:

Very good. Uh, so Jeff, uh, what's your most controversial opinion on application security, and why do you hold that view?

Jeff Williams:

Uh, boy, I've, I've stepped in so many landmines, I just gotta pick one. Um, alright. I. All right, I'll throw one out there.'cause uh, I know Chris likes to throw bombs. Uh, I'll say that, uh, maintaining an AppSec backlog and ASPM in general is an anti-pattern. It's a symptom of a broken AppSec process that's generating more vulnerabilities than it's fixing, and you'll never fix it by dumping all those in a big dumpster somewhere and then periodically trying to sort through and groom and select and build into sprints and refix and retest. You've gotta fix the vulnerability flow problem. You gotta get your flow reduced and your fixed rate increased. Otherwise, you're never gonna get healthy. I. Um, so it, you know, why do I say that?'cause I see it in every organization. It just doesn't work. It's like a way of kicking the can down the road. And, you know, companies that I, I fully believe companies that want to be competitive, the ones that wanna dominate in their sector are gonna be the ones that are best at, at both IT and security as part of that. Um,

Robert Hurlbut:

Okay,

Jeff Williams:

so, yep. I'll, I'll throw that out there. We'll see what the, uh, listeners think.

Robert Hurlbut:

good. Um, next is, uh, what would it say if you could display a single message on a billboard at RSA or Black Hat Conference?

Jeff Williams:

You know, actually I get asked that a lot at my company, but, uh, I think, I think if it was me in charge of marketing, what it would say is build runtime security into your stack. should just be there in your stack. Automatically so that new applications you build are automatically instantly reporting vulnerabilities. They're instantly reporting libraries. They're generating SBOMs automatically. You have observability into how they work. And in production, they're protected against attacks. It's just a way simpler way of, very scalable way of thinking about security. In fact, it's zero trust architecture at the application layer because now the security goes with the workloads wherever they go, they're, they stay secure. You can move a container that has, uh, IASTand RASP installed in it. You can move it from your internal data center into the cloud, and the protection goes with it. It'll keep working no matter where you go. So it just, it's radically simpler and more scalable. And so that's why I say build it into your stack runtime security, build it into your stack.

Robert Hurlbut:

Okay.

Jeff Williams:

Don't deploy without it. If you're, AmEx oriented.

Robert Hurlbut:

Love that. Um, what's your top book recommendation for those interested in security and why do you find it valuable?

Jeff Williams:

Oh man, I just forgot the name of the book I'm reading. It's, uh, by John Wilander, who used to be, uh, a fantastic OWASP contributor, uh, for many years. I wanna say his book is called Insider. Um, but um, it's a, it's a great beach read. It's, uh, hold on. Lemme, I'm looking it up here real quick. Yeah. It's called Identified not insider. It's Identified and, uh, great story about, uh, uh, well I won't give the the plot away, but there's lots of great hacking. In the book that they talk about, uh, you know, how this, this team is sort of fighting against the government and, uh, uh, so far it's been a great read.

Robert Hurlbut:

Very cool.

Chris Romeo:

Yeah. Very cool. So Jeff, we always like to end with a key takeaway or a call to action for our audience. So what, what do you want, uh, the audience to do as a result of this conversation?

Jeff Williams:

Yeah. Check out runtime security, uh, you know, I'd be happy to walk through it with folks. Uh, or, you know, you can do some reading. It's not like I haven't been writing and publishing for the last eight years, so there's a lot of stuff out there. But, uh, learn about runtime security. It's really, uh, you know, like a, it's a cool technology and I'd love to explain that part to you, but it's also really a, a, a foundation for a different kind of AppSec program. And that's where it gets really interesting to me is that we're seeing organizations that are actually getting healthy and getting functional at application security with really concrete results. And I just, I haven't seen that in the industry over the last 20 years. Companies trying to use, you know, traditional tools, they just don't get there. They can't achieve escape velocity and, and actually, Make progress on AppSec. So that's the takeaway. Just check it out. Uh, you know, give it a shot, see if it's, uh, applicable to your enterprise.

Chris Romeo:

Very

Jeff Williams:

And you can play around. But I have an open source project called JOT, which is interesting. If you wanna play around with it. You're a technical person. Uh, if you're a pen tester or a threat modeler, like JOT might really be interesting. If you wanna ask questions about what's going on in your code base and get visibility back about it, uh, JOT is really a fun way to learn about observability and, uh, instrumentation and, and security.

Chris Romeo:

Very cool, Jeff, thanks once again for visiting the application security podcast, helping me to work through some questions about IAST and, and RASP as well. Yeah, and uh, we'll, we'll definitely do this again. We'll see you on the conference circuit somewhere in the next number of months and we'll do this again in the future to, uh, dive into another topic. So thanks for being with us.

Jeff Williams:

good. Love the podcast.

People on this episode

Head Shot

Chris Romeo

Co-host
Head Shot

Robert Hurlbut

Co-host

Podcasts we love

Check out these other fine podcasts recommended by us, not an algorithm.

The Security Table Artwork

The Security Table

Izar Tarandach, Matt Coles, and Chris Romeo