In this Brand Story, hosts Marco and Sean discuss the concept of "shift left" in application security with guest Peter Klimek from Imperva, exploring the challenges and benefits of early vulnerability identification. Have we gone too far?
In this Brand Story episode, hosts Marco and Sean have a thought-provoking discussion with Peter Klimek from Imperva about the concept of "shift left" in application security. Have we gone too far?
The conversation revolves around the challenges and benefits of identifying vulnerabilities earlier in the software development lifecycle and the need for collaboration between development and security teams. Peter emphasizes the importance of finding a balance between tools and human expertise in addressing vulnerabilities. He highlights the common issue of organizations having a backlog of vulnerabilities that need to be fixed, rather than a problem of finding vulnerabilities—it's "easy" to find them, harder to fix them all.
The conversation also touches on the measurement of closure velocity and the significance of development team velocity as a core metric in application security. They discuss the role of APIs, platform engineering, and infrastructure as code in improving collaboration, automation, and trust in systems.
Peter draws a parallel between guardrails on a highway and the need for guardrails in application security, emphasizing the importance of providing development teams with time to address critical vulnerabilities. They also explore the challenges of coordinating multiple teams and the role of operations in orchestrating the development and security processes.
The need for a defensive mindset and the importance of leveraging the guardrails Peter noted to prevent fatal vulnerabilities is also discussed as they emphasize the significance of collaboration, measurement, and a balance between development and security teams in implementing shift left practices effectively.
The episode provides valuable insights into the nuances, challenges, and benefits of integrating shift left practices into application security, while emphasizing the need for collaboration, balance, and the ethical use of tools.
Note: This story contains promotional content. Learn more.
Guest: Peter Klimek, Director of Technology - Office of the CTO at Imperva [@Imperva]
On LinkedIn | https://www.linkedin.com/in/peter-klimek-37588962/
Resources
Learn more about Imperva and their offering: https://itspm.ag/imperva277117988
DevOps Research and Assessment (DORA): https://dora.dev
2023 Imperva Bad Bot Report: https://itspm.ag/impervv0sg
47.4% of internet traffic wasn’t human in 2022! Get the research from @Imperva to learn how bots are taking over the internet.
The Impact Of Log4j Since Its Disclosure | Steps Businesses Can Take To Maintain Software Supply Chain Security:
From Enrolling In College To Gambling, Traveling, And Shopping, Evasive Bad Bots Are A Major Source Of Online Fraud | The Bad Bot Report 2022 | An Imperva Brand Story With Ryan Windham:
Catch more stories from Imperva at https://www.itspmagazine.com/directory/imperva
Are you interested in telling your story?
https://www.itspmagazine.com/telling-your-story
Please note that this transcript was created using AI technology and may contain inaccuracies or deviations from the original audio file. The transcript is provided for informational purposes only and should not be relied upon as a substitute for the original recording as errors may exist. At this time we provide it “as it is” and we hope it can be useful for our audience.
_________________________________________
[00:00:00] Sean Martin: Marco.
[00:00:03] Marco Ciappelli: Sean.
[00:00:04] Sean Martin: Have you, uh, adjusted your sprinklers for, uh, the, the coming winter in California?
[00:00:10] Marco Ciappelli: Yeah, because they were just, uh, they're just like watering, uh, one side of the garden. So I had a really, really nice green side and a really dry one. And, uh, I think, I think I overdid it.
[00:00:25] Sean Martin: Yeah. Do you, do you spend most of your time in the green side or the?
The dirty brown side.
[00:00:29] Marco Ciappelli: Oh, you know, I love dirt.
[00:00:33] Sean Martin: Uh, well people are probably as usual wondering what the heck are these two guys on about? Um, well, let's just say marco that that i'm gonna take a wild guess that you uh, you shifted your sprinklers left It may be just a little too far and maybe it's too much We're going to talk about that concept of shift left, which seems to apply to everything these days for some reason.
And, uh, we're, we're going to question that, uh, that a little bit today with our good friend, Peter Klimek from Imperva. How are you, Peter?
[00:01:06] Peter Klimek: Doing great. Thanks for having me back on the show.
[00:01:08] Marco Ciappelli: How is your garden?
[00:01:11] Peter Klimek: My wife is uh, she's quite the green thumb. So it has taken over our entire yard we don't have much yard left actually at this point. So...
[00:01:20] Sean Martin: look at that and you have the the grace of Some rain to help you so you probably don't need as much spring clearing as Marco might
[00:01:30] Peter Klimek: There's no shortage of rain in in the Pacific Northwest here. Exactly.
[00:01:34] Sean Martin: Exactly. All right. Well, we're not here to talk about rain, um, although it seems like, uh, seems like it's been raining a lot in some places, but, uh, at least in New York, it is, but, um, anyway, we're talking about shifting left and, uh, Peter, you, you spent a lot of time in, in the AppSec world and, and looking at security of data in all places and everywhere it goes and, and everywhere it's being touched and, uh, we, we try to address security of data through the apps, As early as possible, which I understand why, why shift left is important, but, um, we're going to find out what your thoughts on that are first, a few words from you on who Peter is for those that didn't catch the previous episode where you're on, but, uh, a few words about what you're up to at Imperva and, and maybe even a glimpse into why this topic came up.
[00:02:36] Peter Klimek: Yeah, so I'm, I'm a director of technology within the Office of CTO at Imperva. And so I spend my days, uh, mostly working with some of our largest customers across the globe and helping them to address their application security issues and challenges that they see, uh, pretty much across the board. My background is as a developer.
Uh, I have formerly been on the other side of the fence, having built out application security programs, through effectively shifting left. Uh, and so I got to see and experience this firsthand. And then, of course, in my day to day role, uh, we tend to be on the more kind of proactive defender side. Where we're actively mitigating threat campaigns and attacks and helping organizations basically respond to those threats.
And so, uh, it gives me a good purview into what we're seeing and what we're hearing. And part of the reason why this topic came up was because, um, I was actually doing another podcast interview with a developer publication and the host had asked me a question and the question was something along the lines of, we're hearing a lot of pushback.
Around shift left. And it was actually the first I'd probably heard it. Um, but it was curious cause it came from a developer publication, uh, not security focused. And so I started to go around and ask some of the different CISOs that I was working with just to kind of. Give me their thoughts on that question and why they were hearing some of it.
And it was one of those questions where once I finally asked the question, I got that, Oh, I'm so glad someone's saying that because yes, you know, we, we are hearing this where we are getting a lot of pushback from our development teams. And so. That was really what kind of cued me into there might be something here, and there might be worth something discussing a little bit more detail, and we'll get into, I think, the specifics of it, but I think the way that I've been coining it is really, we kind of hit peak shift left.
[00:04:26] Marco Ciappelli: Yeah, you guys are gonna, definitely gonna go into some, uh... More like the technicality, but I am more curious for people listening right now that may not be the developers, not much into the software development, but more on the business side. Uh, and I'm sure they're using it too, because I have used it and I barely know what it means.
So, you know, it's a buzzword. It's good. You threw it there. I'm going to shift left. Yeah. Let's do it. But, let's start with a little bit of an introduction of what the concept even means. And, and, and are we still applying in something that nowadays makes sense? I mean, we're not where in time this started.
So if you can kind of like give a little intro on that, it will be very helpful. Yeah,
[00:05:13] Peter Klimek: I'd say the, the Genesis for shift left was really probably about somewhere 10, 15 years ago. So it's been a while now and really it was a reflection of the need to identify Code vulnerability, software vulnerabilities earlier in the software development life cycle, or the SDLC, as you'll commonly hear it referred to.
And Microsoft is really one of the pioneers here. Microsoft had released something called the Microsoft SDL, which was, they called it the secure development life cycle. And this kind of set the framework for how security teams should think about working with development teams around securing software.
And over the course of the year, since in that timeframe, what this is really kind of manifested with is using a lot of tools that bring those security checks closer to the developer. Uh, so effectively things like source competition, source composition, analysis, static analysis, dynamic analysis, all of those.
AST related words. Um, those are really the tools that a lot of security professionals are using. And the goal here is basically that for a development team it's cheaper and easier to fix a vulnerability closer to the time at which the vulnerability is created. Uh, and there's a couple of reasons why.
First and foremost, effectively the developer that wrote the code often is going to be most familiar with it and so they can go right back in and fix that line of code even before it gets to production. Similarly, if you have vulnerabilities that really kind of sit and they dwell in production for a long time, it takes a lot of work for a developer to get into the mindset of going in and actually kind of relearning what the code is, understanding how it works, especially if they didn't write it.
Where it can really be difficult for development teams to go back and fix some of those vulnerabilities. And so shift left was really a process of by moving this and shifting that further into the development life cycle, we can reduce the cost of it. We can reduce the total number of vulnerabilities and I don't know a single security professional that would disagree with that notion.
[00:07:14] Sean Martin: Yeah. And I'm going to stay looking back in time for a moment because many moons ago, I spent a number of years in quality assurance engineering where my whole job was. Shifting left, I guess, before shift left was a thing and it wasn't security focused, but I was looking at the code to figure out, was it operating like it was supposed to, could it be abused?
Could it be misused? Could it be manipulated to do something that it wasn't supposed to? And also at the same time, starting to, to refine the waterfall model of development and starting to look at agile. And so the, the concept that we're talking about here isn't new. For developers, but somehow it seemed to take off as a, as a shift left term.
Once we attached security to it and we, and we threw the sec and in between the DevOps and became DevSecOps and all this other stuff. So is it a phenomenon that, that because we had another team that it, yes. And when I was in QA, we had a nice collaborative competitive collaborative environment, but security coming in, maybe change the scene a bit.
I don't know if you can just. Share some thoughts on the culture and why it became such a big, big movement.
[00:08:34] Peter Klimek: I, I'll give you first my kind of, I guess, uh, somewhat cynical, uh, answer to that, but I, I think that's actually closer to the truth in a lot of instances, um, the cynical answer, I think in a lot of instances really comes down to the fact that there were a lot of marketing budgets that were associated with it and specifically from kind of the security vendors.
And so shift left was a very easy concept to really kind of wrap your head around. It had a very clear, tangible benefit. And so that's probably the first thing that really came down to it. Um, now I think the, the other thing that we really saw was most security professionals. are not developers and they don't have a development background.
Um, even within AppSec professionals, a lot of them don't necessarily have a development background. And so, the kind of shifting the tooling and putting the tooling in the hands of the development teams really shifted the burden. from the security teams over to the development teams. And I think that was really one of the bigger kind of shifts for it was instead of it just being this instance where they're finding these vulnerabilities in production but not really knowing what to do with them, they could just put the tools in the hands of the development teams and let the development teams kind of go and find the vulnerabilities themselves and then be responsible for fixing them as well.
[00:09:47] Marco Ciappelli: And everybody wants an excuse to... Take the responsibility off their shoulder, right?
[00:09:53] Peter Klimek: Exactly. Exactly.
[00:09:55] Marco Ciappelli: So when is that, you know, at the beginning, Sean, you mentioned, you know, it's at a certain point it peaks and when it becomes. The problem instead of solving is not the panacea that resolve everything, right?
So I think that's the reason why you're kind of like pushing back on that right now. So where, where does it find its limits? And then we can even try to pinpoint how to Realize that this is actually happening.
[00:10:25] Peter Klimek: So this, this, I think was what really led me down to that deeper conversation that I had with CISOs and various security professionals is really to figure out what were those limits and what was kind of that tipping point.
Um, I think the first one is to kind of first just explore what are the limitations of shift left and specifically some of the tooling that's involved in shift left. Um, Sean, you, you said it perfectly, actually, when you were working in QA, one of your jobs was really finding ways in which the application was abused almost in terms of the, the ways that users were kind of doing things that they probably shouldn't have.
And shift left tools are really good at finding certain common patterns. So they'll find vulnerabilities like a SQL injection or a remote code execution, or those types of vulnerabilities that follow mostly just implementation flaws. It's a way that the developer just didn't do something that they should have done properly.
It's a fairly, you know, trivial code fix for them to go back and do it. And those tools are very, very adept at finding them. The problem is those tools. Can't find things that are really related to the business context of the application. So they don't understand really what a user should or should not be allowed to do because they don't understand what the context is of the actual business users.
And this is where we kind of see the challenge with some of the shift left tooling and some of the, the idea behind shifting everything left is you're basically shifting all these tools in, there's certain vulnerabilities that you can find, but at the same time, it's not everything. And so having that balance to your approach is really the first part of it.
Uh, and I'll just give you a case in point there. If you go and look at the OWASP API top 10, uh, which just was refreshed for 2023 and you look at the vulnerability classifications or the design issues that they have in there. Uh, four of the top ten are related to authorization and authentication. Uh, authorization issues tend to be more of a business logic vulnerability because it's really tied to what the application is supposed to do.
Uh, and then another two of the vulnerabilities are specifically related to how resources are being consumed within the application. So those are things that you can't really go in and find until the application is in production. And so I think that's really kind of a indicative of what we see with the shift left methodology is it's just leaving a lot on the table and security teams are still somewhat vulnerable to that.
[00:12:54] Sean Martin: That's a good point. And, so many different ways to look at this. So I'll start with this. We can get into some of the other views, visuals, but you describe a set of activities that you. Really can't shift left or you can only shift them left so far. And I'm wondering, um, from the viewpoint of a development team and a security team collaborating on these, on these efforts, where, where are they, I guess, where, where, what are they trying to shift left?
Or are they assuming things are shifted left enough? And they can just kind of wipe their hands. I guess my point is we, we take a, we take a model, we embrace it. We pile as much into that as we can because we see it's working for a lot of things. And then we move on to something else, right? Because we're so busy.
So I think we, we put a lot of trust in the model and, and therefore leave some things out that That shouldn't shouldn't be left out. So we're exposing our program stuff because we're trusting something too much perhaps So, I don't know you gave a couple of examples the API example But are there ways for teams to kind of figure out how they should model the model?
In a way that's right for, for their team.
[00:14:17] Peter Klimek: Yeah. The, the big thing around like a lot of the tooling is there tools that are designed to find the flaws. Um, they're really more of things that you can use to identify issues early on, but it's still, the onus is really still on the development teams to actually go in and.
Fix the vulnerabilities and get those into, uh, the actual changes in. And so this is really where the first issue that we see comes up, uh, in a lot of instances where development teams have gone and they found all the vulnerabilities or security teams have run these scans and they have these huge backlogs of vulnerabilities now that need to be fixed.
And more often than not, that's actually the core problem that the CISO has. So every CISO I talked to, the problem was never. That we can't find the vulnerabilities. The problem was always, we can't fix the vulnerabilities that we've already found. So that's really where you've hit that first inflection point, basically, where adding more tools to the problem, unless the tools are going in and using something like generative AI to fix the vulnerabilities, is not going to necessarily be the problem solver that you actually need today.
[00:15:22] Marco Ciappelli: Do you have a, you know, without mentioning companies or organization, give us an kind of like a case study, like something that you run into recently. Maybe that can give an example of how there has been maybe a too much of it. Shift left.
[00:15:40] Peter Klimek: Um, I don't have a specific case study. Um, just because simply for what we do, we don't measure or attract kind of vulnerabilities over time in there.
Uh, but I think for organizations, what they will find is when they go through and they look at all of the various tools, they'll be able to see kind of the closure rates and they'll be able to see the usually it's the delta. of new vulnerabilities that created versus closed and by and large, after you've implemented these tools, the goal is you don't want any net new vulnerabilities created.
And over time, you want to buy down on that debt that you've already created. And so that's really where I think for organizations independently, they should be looking at what does that closure velocity look like? And is that actually going down over time? Is it at an acceptable rate? Or are you basically stuck in kind of a purgatory?
Is it, is it stalled out and your development team simply aren't going in and fixing anything anymore?
[00:16:33] Sean Martin: So I like to look at things visually and uh, which may help people listening to the podcast as well. So we, we, Marco alluded to it. I think you mentioned it, the, uh, kind of the wave or you mentioned peak earlier. So to me, there's, there's a maturity level or a peak, as you mentioned, a peak level for Shift left.
And so it could be maturity level of the team, maturity level of the tools, um, how capable those two together are in, in delivering the results. Um, if we overlay that with the crossing the chasm. My, my question to you is how well, so I alluded to it earlier that it seemed to take off like really, really well.
Um, so have most people cross the chasm, most organizations cross the chasm and where do you think they are on, on the peak? Obviously you're saying we've, we've a lot of, a lot of places may have crossed the peak, but is it a real challenge at this point do you think?
[00:17:40] Peter Klimek: I think we're, we're probably in the crossing the chasm kind of example.
I think we're at the laggards at this point. A vast majority of organizations we talk to are already doing something. They've already adopted the tools. They've already implemented them. And now they might be covering off some edge cases. They might be covering off some new scenarios. But that's really, I think, they have a fairly robust process in.
Where the prioritization, I think, now needs to shift is to optimizing some of the things they have. And really starting to measure how their development teams are actually getting and getting to a point of closing the vulnerabilities, as well as the other tasks and responsibilities of the security team.
So kind of getting the security teams back into more of a defender mindset. To be able to actively go and to buy their security teams a little bit more time.
[00:18:31] Marco Ciappelli: So how do you define success when you, when you look at that, is there like some rules that we can apply?
[00:18:39] Peter Klimek: Yeah, the way that I look at it is I personally like to look at.
Development team velocity is really the, the core metric that I would want to track. And I think it's the core metric that I think that a lot of security professionals need to get a little bit more closely aligned to. Uh, and there's some specific reasons for this. So development team for velocity, first and foremost, the way that you can look at this is really a handful of things that get measured.
So how long does it take the development team to make changes? Uh, how often are they deploying code to production? Uh, what does their failure percentage rate look like? And if they make an issue, how long does it take them to restore that? So these, these are good metrics that basically measure, uh, really the, the more like dev ops y portion of the development conversation.
How quickly your teams are able to measure it, to move, uh, and get code into production. And the reason why I really personally like development team velocity is because first and foremost, if they have a small lead time for changes or they deploy frequently. What this means is that if there is a critical vulnerability that comes up, something on the magnitude of a log4shell or a struts vulnerability, then that just means that they're going to be able to get It fixes into production very quickly.
And so this is something that security teams should definitely be prioritizing and looking towards in the case of the shift left tooling that you put in place and shift left. I think is a very important part of this, but most importantly, it shouldn't be slowing down any of these processes. It should be speeding them up.
So if you're going in and you introduce some tools and those tools are actually taking 24 plus hours to run and development teams can't do their deployments because these tools are taking too long to run, then you've probably slowed down their processes. So those are the big things that I would look for, at least personally.
In terms of measuring, uh, out development teams. And if, for anyone that's listening and they're interested in, in more information around these, I didn't just make those statistics up or those key metrics up. Um, that all comes from, uh, the DevOps Research and Assessment, uh, organizations, uh, dora. dev. Um, this is an organization that's run by Google.
They academically study various DevOps organizations to identify best practices. And these are the four key metrics that they use to evaluate the velocity and the performance of development teams.
[00:20:59] Sean Martin: So speaking of velocity and performance, uh, we, especially as engineers, we like to automate stuff as well, right?
Um, so. Talk to me a bit about the relationship, the impact of APIs, the concept of platform engineering infrastructure as code, some of these things that will help us get the velocity we need and share resources and, and be more collaborative with each other and automate a ton of stuff. But maybe, again, amplifying the trust in the systems we have and the models that we've employed. Um, I don't know, tell me, talk to me a little bit about that in terms of those connection points.
[00:21:49] Peter Klimek: Yeah, all those things I feel like are taking. Uh, the idea of reusing, uh, components and especially reusing best practices and design patterns that have already been established and approved in the organization and giving teams a way to be able to repeat and deploy them very quickly.
And this, this is a noble goal. I think this is great for security teams because it gives you more consistency. around how organizations are deploying and pushing changes through an organization. Uh, and it really, it actually, I think it follows fairly closely to what we saw as best practices on the application security side, where fairly commonly what a lot of security teams would do is they would have pre approved libraries.
That development teams could just go and pick and use off the shelf and not have to worry about kind of deeper security reviews or code vulnerabilities in those. Um, and so this is really, I think, a pattern of that, but then extending it beyond just the application security domain into the broader infrastructure.
And more than anything, why I think this is important is because the way software is developed has really changed over the years, where before we kind of looked at building these very large monolithic applications and they had, you know, all the bells and whistles and everything was kind of packaged in or they were running on, you know, huge JVMs and that type of infrastructure to now these more modular, uh, microservices based organizations and integrating a lot of third party services.
And so that interconnection, that more infrastructure as code really becomes part of the code of the actual overall system. And so I do view them as really an extension of it and an important part. And I think that's really kind of where we get into more of like the sec that gets put in that DevSecOps side of it, where you're now looking really beyond just the individual.
Application components that are developed by your teams and now the entire ecosystem of services that connect together.
[00:23:40] Marco Ciappelli: Well, you, you just went there and I was actually was going to go even more back in time than that. Thinking a finite product, right? Like here is your software in a box. And if there is actually by the box, yeah.
Yeah, buy the box. And then, you know, if there's something broken, you'll, we'll fix it in, you know, the, the old, the 0. 4, whatever it is. And, and now of course, you see update all the time, uh, even your phone and, you know, anything it's a fixed vulnerability you'll know, they download it.
That's the big thing. Keep, keep it updated and patch it. And I'm wondering, If some people may think, uh, yeah, you know, maybe we don't need to look so much into, I mean, it's okay to go with some flaw because we can fix it on the go and I'm connecting to what you say, the speed of getting on the market, giving in the hands of the user.
So I don't know, again, I'm not the tech guy here, but am I on to something from a business perspective?
[00:24:50] Peter Klimek: You are, but there's one critical thing I would add. And that is, in all of these instances, you want to make sure that you have the appropriate guardrails in place. And, and I think this is like a really good example where like, if you think of like an Apple device, for instance, you know, Apple can now push out security patches and they get them out there very quickly.
But then your iPhone also actually has various technologies and protections in place where they can fairly rapidly respond or make it very difficult for attackers to find vulnerabilities and exploit them in the first place. And I view this in the same way. So, and this is, I mentioned before that for security teams, getting back to more of a defensive minded, uh, defensive mindset is really where I kind of look at it and it's, it's building these guardrails for the developers.
We know that mistakes will happen. We know vulnerabilities will get to production. It's, it's just going to be the nature of things, but much like guardrails on a highway, what are they designed to do? Well, they're designed to keep you on the highway and prevent you from doing anything that's really fatal.
And I think that's really where the key insight is for a lot of CISOs right now and why they're kind of looking at how we're shifting our budgets. How are we thinking about our tooling that we're implementing? It's more about. Providing those guardrails. And second, when something major does happen, when we get another struts, when we get another log, log for shell, how much time can they buy their development teams?
Uh, and part of the reason why I think the time is really important and why it's important to go back and do things like the Dora assessments and understand those metrics is because if you have a development team where their deployment frequency or their lead time to changes is one month, you need to buy them one month of time to go and get this fix into production.
Your teams that are only take, they can do it on the hour. Those teams, you don't need to worry too much about it. You can still, you need to have protections in place for them, depending on the criticality of the business application, but ultimately that's where it really comes down as being very important is making sure that your controls align to the risk that's actually identified there.
[00:26:49] Sean Martin: And this is where the, the, for me, the ops come in, because it's no longer of coordinating, orchestrating all this stuff and systems to boot. And, um, yeah, if, if. You might have a team that can develop stuff, but one of the, one of the metrics that we had in, in quality assurance was how often did a bug reintroduce itself or break something else in the process or eat up memory or take down other systems or take down the network, which can mess up a bunch of different things.
And when you're talking about like a log for shell, where you're replacing a log for J. You're, you're touching a lot of apps. So how many apps, how many teams are you talking about here? And how are you coordinating all of that? And do you have enough time to prepare and deliver? So any thoughts on the, on the ops, which then of course leads in, leads into some of the response as well.
So having the guardrails and having the. The, uh, the team response team ready.
[00:28:00] Peter Klimek: Yeah, probably the most important thing here is to really do a full audit effectively on what your coverage level looks like. And so, uh, and what I mean by coverage level here is, so most organizations, if they think about kind of security, they'll, they'll tend to over rotate or hyper focus on things like the OWASP top 10, but the OWASP top 10 is really only kind of a small subset of the threat landscape now.
Uh, your applications and APIs are going to be under DDoS attack. Uh, you have automated threats. Uh, so the, you might hear this referred to as like the OOP top 20, which is the OWASP automated threats. You have the API related vulnerabilities from the API top 10. We have various supply chain threats that come in.
And so it's a very, the attack landscape itself is much wider than it used to be. And then that's not even pulling in all of the infrastructure related issues that you might have to worry about as well. And so I think where, where it's a good place to start is to look at what is being covered by what, what tools are we identifying or what vulnerabilities are we identifying and fixing with our shift left tools?
And what are our gaps? One of the things I think that's really important here to, to think about is, um, Some of these vulnerabilities are not code level vulnerabilities. They're not things that your developers can go and code themselves out of. If you look at account takeover attacks, for instance, that's a really good example.
It it's your users having, you know, reused passwords. Uh, you're no amount of developer coding is going to be something that can go and mitigate that. You need to have third party systems that are really going and evaluating for those threats. And really kind of tying it into the overall authentication process.
Um, the same thing applies for like fake account creation, uh, and some of the other business logic vulnerabilities. And so I think those are the types of things that you want to identify pretty quickly is where in your threat model, are you accounting for these things? Is it something that you can account for and shift left?
Great. Do it there. If it's not, then those are the things you should need to focus on. How do we actually go and respond to this in production when we find these things?
[00:30:02] Marco Ciappelli: I like to code themself out of it. I never heard it before. I'm going to code myself out of this. Uh, no, thinking about the guardrail and you can't put the guardrail on everything, right?
I mean, if your landscape, it's, it's immense, then, you know, you need to focus on, on something specific and how you make that decision. I think that's, that's kind of key, knowing what you have to protect more than anything else, because it can't protect everything, I guess.
[00:30:34] Peter Klimek: Absolutely. I think, I think that's really what it does come down to, um, in a lot of instances, um, organizations have to make that decision based on the actual risk profile of their applications.
There's some applications that will be non negotiable, you know, they absolutely need to have it, um, you know, it's, it's, to use the highway analogy and go further, it's a, you know, very twisty turny highway that. Has a lot of, you know, cactus patch at the bottom of it. Uh, and, and those are the things that, you, of course you want to, you want to look for, but, um, yeah, I think at the same time though, there are certain organizations and applications where as long as you just have kind of some robust processes in place, you go through some checks.
Then I think you can have a lower kind of, or I guess a higher risk tolerance for those different services. Um, good example here is I'm thinking static facing web assets, things that don't actually process input users, you know, things that you're hosting on a CDN, those are, they have a really low risk profile versus some of the other applications that you might have in your organization.
[00:31:35] Sean Martin: Yeah, for me, it, it, it seems to always boil down to scope, right? Cause you don't have infinite team and, and resources and time. So you got to figure out what scope is appropriate so that you can shift left to that right level of scope, put the guardrails in for the right level of scope and have the response ready, that same level of scope, which of course matters to the business.
It's not just what matters to engineers and security folks. Um, I want to. I want to go, as we start to wrap up here, maybe some thoughts from you or some insights from you of conversations you had. And as you talk about, when you're talking to students, you ask them about the concept of shift left and is it too much?
Have we gone too far? I want to get your... Perspective and not necessarily looking for names or anything here that it's going to give anything away, but how, how those conversations then turn to here's how we are reevaluating our current environment. Here's how we are re educating, retraining our team.
Here's how we are retooling. Here's how we're updating our processes to. Adjust for our new, better, more current, relevant understanding of what shift left is and where we sit on that continue.
[00:32:55] Peter Klimek: Yeah, I'll give you one, uh, that I just had, uh, recently with a customer and I thought this was just a great way that they did it.
Um, they, they actually looked at a... Uh, a data breach, a very, very large data breach related to API, uh, related vulnerabilities. Um, that happened last year. And what the security team did is they basically said, okay, we know the technical details of how the attack happened. And now let's think about it in our, in our shoes.
Could we have detected the same attack? And they said, no, could we have figured out where we were vulnerable to the same attack? And they said, no. And this is ultimately when they decided that it was time to start up a conversation around bringing in and augmenting their existing stack to provide specialized protection for this vulnerability.
Um, and in their case, this was really about understanding where all of their APIs were. Um, they had a broad sense, they were, you know, already had things like a WAF in front of their APIs that were already doing static code analysis for them. But they didn't really understand and they didn't have a good view of what the actual makeup of those APIs looked like.
And so getting that deep discovery and classification of all the API endpoints, that was really the first step for them. Then when they had that in place, they could start going in and looking at, okay, now do we have sensitive or risky APIs? So APIs that are exposing sensitive data or APIs that just have risky behavior, because the risky behavior was what they had identified that the vulnerability really alluded to.
It was an API that exposed sensitive data that had a broken authentication. So it didn't properly authenticate the users. And that was really what they were looking for. So I like this idea though, of being able to take a common example, something that you see, something that you question that you don't know if you can necessarily go and defend your organization against.
And using that as your model to evaluate the existing controls that you have in place. Uh, in their case, they just used the API breach because it was really big. It generated a lot of news in their country and there were big fines associated with it. So their board was asking about it. Um, but the same thing applies to any other vulnerability that you see, something that you know that your business might be, uh, vulnerable to.
Um, you know, if you're a ticket broker and you, you know, solve the Taylor Swift issues, that might be a good example of how do we actually. Handle things like bots for big drops for, you know, big product launches. Um, I think putting yourselves in those examples and kind of tabletop exercising it and almost really creating like a threat model for that is really one of the things that security teams can do to put themselves in figuring out where their gaps are.
[00:35:30] Sean Martin: Yeah, I love it. And, uh, of course bringing in ops and Deb. In those tabletops so they can see how, uh, how it all comes together. And the thing you've mentioned that I think is, I think you say that word a lot here, I think is important is the need to think it's easy to, we've jumped on this bandwagon. Had great success with it.
We're able to, to show that we haven't slowed down Dev too much. We're releasing faster than ever. We're, we're finding and closing bones. Somehow we're doing that fast. We still have a backlog, but we're proving, we're showing, showing demonstrated results and success. So we don't need to change things. And I think, I think sometimes that's when it's most important to pause and say, do we need to change things?
Uh, don't, don't get too settled in, into one frame of mind or one mode, because that's, that's when... Complacency will come back and bite you. And to me, that's where partnerships like, uh, like what you offer at Imperva and the conversations you have with the executives and the security and engineering leaders to break them free of their current thinking and say, have you thought about, and have you prepared for, you may not need to do anything, you may have thought about it, you may have already addressed it.
Just that pause of, have you thought about this could change the game for. Better guardrails, better response. Shift some of those things right to, uh, not all the way from left, but some things right, so that you can kind of balance things out a bit. Better gardens. Better, greener gardens all the way around.
That's what we want for everybody. Especially in states with no water. Sprinkle the heck out of everybody.
[00:37:22] Marco Ciappelli: Well, you know, it comes to the bottom. You know, I'm going to... Remember that when we were preparing for this, I just went on chat GPT and said, give me some, some example of what like metaphor for shift left.
That's why actually we started with the garden. We're not completely crazy. We kind of got in, but there's, but there are other ideas. And, and I think the bottom line is each single one of this metaphor was that that can be. That the fact that we need to consider that there is too much of something is usually not a good thing so that balance, I think, is the key and that common sense that we brought into the conversation as well, but also the partnership with someone that can help you to detach yourself.
Use a third party perspective, um, point of view and really address things that maybe you can't see from the inside.
[00:38:15] Peter Klimek: So I think at the end of this, Marco, I think you're going to get a drip irrigation system for your garden.
[00:38:21] Marco Ciappelli: Or just going to make a desert garden and that's it.
[00:38:26] Sean Martin: Nice one. Well, uh, an intriguing and, uh, thought provoking conversation for sure, Peter.
And, uh, always fun to chat with you. Hopefully. Folks enjoyed this and, uh, of course, our main goal with ITSP magazine and with these episodes is to get people to think, as I kind of closed with earlier, and, uh, to continue thinking about this, we're going to include a link to the DORA site that you mentioned and any other resources you and the Imperva team think would be helpful to shift left where appropriate, put the guardrails in, and Set up ops and response to succeed all in support of the business.
Of course. Um, don't sit on your haunches, think, think differently, folks. So thanks. Uh, thanks again, Peter. Thanks everybody for listening. Uh, stay tuned, subscribe, and, uh, be sure to connect with the, the Imperva team.