The SOC in the NOC | SecOps Vision 2024

Hey everyone, welcome to our keynote panel here on our sec, very first SecOps virtual event. We're really glad you can join us, but I'm also thrilled to have such a, a distinguished panel here for our keynote panel to discuss. I, you know, one of the nice things about being in security as long as I am and have been is I, I've known, met a lot of great people, and I'm happy to have some of them here with me.

com and, uh, cloud native, now Tech strong, AI, digital, CXO, and of course, tech Strong TV and tech, strong learning tech, strong research. Um, today's panel is called the SOC in the Knock, kind of DR ish. And, um, before I introduce our panel, let me tell you why we're doing this panel.

com for nine or 10 years. We're gonna be doing our RSA DevSecOps event in May this year. I think it's gonna be the eighth year.

Several of the people on our panel have spoken at this in years past. For eight years, I've been trying to convince the security community that we need DevSecOps, that DevOps and security go together, and DevSecOps is the key to it. And over the last two, three years, we've made tremendous progress.

People understand that DevSecOps is real, that DevSecOps is a thing that DevSecOps shifting left, really is part of our software. No S-S-D-L-C, software development, lifecycle software, supply chain security, s bombs, shift left. These are all phrases that we all use regularly.

Now, well just when we got there, surprise, we're gonna change the rules. Let me throw something else into the mix. SecOps, what is SecOps?

I just got my head around Dev SecOps. Well, we're gonna examine that today, and I got a great paddle here to, to bring you on with it. Let me, um, let me introduce you to, to our panel members.

I'm gonna start off with my friend Larry Mar Eroni. I'll try to say like his grandma, but his grandma probably cooks better than I did. I, she probably cooked better than I can and says the name better.

But Larry, welcome. Why don't you introduce yourself to the audience? Uh, yeah, thanks.

Thanks, Alan. I love, I love doing these, these things with you. So, so there's two things that, that me people would benefit from knowing about my background.

First of all, I was the head of application security at Comcast for five years, and I basically was hired to replace the traditional way of doing application security with a more code centric, developer centric approach. And, and I, I didn't get very far away from the devs sec part of DevSecOps into the SecOps part, but I did get somewhat into that. And I, I've certainly done more of that since I left.

And the second thing to know about me is I'm a developer. I write code almost every day. I'm the primary author of a dozen open source projects, one of which gets a million downloads a month.

And so I have credibility. I'm not just preaching. I'm practicing what I preach in these things.

I love it. But Larry, you're not at Comcast anymore. Why don't we tell 'em about your present position, Right?

So now I am at Contrast Security, essentially helping other companies do the same sort of thing we did at Comcast. Absolutely. Thank you.

And thank you for joining us. Next up, one of my favorite people in the world, Carolyn, Carolyn Wong with Cobalt. Carolyn, welcome.

Why don't you introduce yourself? What a pleasure to be with this group today. My name is Caroline Wong.

I'm currently the Chief Strategy Officer at Cobalt. We are an offensive security testing company. I began my information security career at eBay and Zynga.

And so naturally have been thinking about things like application security, software security, devs, DevSecOps, DevOps, et cetera, for a long time now, um, one of my favorite things that I get to do is teach about cybersecurity. Um, and so I'm the instructor for a number of LinkedIn learning courses, uh, including a series on the oasp top 10. I love it.

And, and you're being, you know, not to embarrass you, but that LinkedIn class is probably one of the most popular LinkedIn learning classes. I forgot the insane amount of people who have taken it. But, um, congratulations.

And, and if you haven't, go check out Caroline's class. Next up, I want to introduce you to Ori Bendit, who I, I will say Ori is joining us from Israel today, and we're happy and thrilled that he's able to join us. Ori welcome.

Why don't you to tell us a little bit about yourself and your company? Thanks, Alan. So I've been in the, um, high tech company, uh, in the IT tech industry for the last 20 years.

I started my career as an engineering manager, and I was a QA manager for a couple of years. And in the last 10 years, I switched over to product management. I had a few stops in the way.

And the last four years I'm managing, um, I'm the VP of product management at Checkmarks. We are the application security and leader. Check marks is one of the pioneers and veterans in this area started back in 2 0 0 6.

And, uh, we help customers write better and secure code as they move. You know, you mentioned DevSecOps to the cloud mostly. So this is about me and check marks.

Excellent. Ori, thank you for joining us. Last, but certainly not least, is another good friend of mine, my friend Tracy Bannon.

Tracy, why don't you, uh, introduce yourself. Um, hi there everybody. And like Carolyn, I am just thrilled with the folks who are on the panel today.

This is gonna be a really rock solid conversation. My background is a couple of decades. As a software architect and engineer, I love to solve really tough problems with software, but that also means that I have to expand past software to people, process tech.

You guys have often heard me say, jokingly say that I'm Dev married to ops. And that started years ago when my husband and I were at AccuWeather together, and he was operations and I was part of the engineering staff. And I learned so much from that, that has carried forward.

Security has always been a part of my, um, my approach. And I think Alan and I really get along well when we start to talk about DevOps, DevSecOps, why did anybody think that they were very different? Um, you know, I work now with the Mitre Corporation.

They are federally funded research and development. You probably have heard about them from the attack framework. They manage the CVE database, so very steeped, um, in, in security on a, on a day-to-day basis.

Uh, I'm an author, a mentor. I spend a lot of time just helping people solve really tough problems. So let's get at this today, guys.

Fantastic. Thank you. Thank all of you.

So let, let's start with the, like, the fundamental nugget here. What is SecOps? What does SecOps mean to you?

What, what should our audience think of when they hear SecOps? And then we'll con once we could define that, then we'll try to contrast it with DevSecOps, right? I think that's a good place for us to start.

So Caroline, I'm gonna ask you, because you always have the answers. When, when you, when we say SecOps, what is, what is SecOps to you? SecOps, from my perspective, is quite simple.

It's figuring out what to do when something goes wrong. Historically, the sock, the knock, their job is to keep a lookout and monitor things and make sure that if something looks suspicious, that they're on it right away. Making sure that if a security incident is occurring, that they're responding.

Um, and so I think that SecOps simply is keeping an eye out and paying attention to when stuff goes wrong and when stuff inevitably does go wrong, knowing what to do next. Fair rest of the panel. Any comments, thoughts, additions, subtractions to that?

What is the definition of SecOps? I would just have a simple, oh, go ahead, Larry. No, go ahead, Tracy.

I was just gonna say, a a simple way that I explained to folks is these are the people who are protecting the moat, right? They are protecting the castle. Um, whether you, regardless as the, as to the type of security concerns that you have, these are the folks who are actively protecting.

And we wanna bring that information backwards to help us do a better job with how we design and deliver and operate. Um, essentially. Go ahead, Larry.

Yeah, so I, I, let's drill down to that. I, I agree with the, the, that, that both of those definitions, however, I, I think the world is evolving a little bit when you, when you, when you include the concept of DevSecOps and you, and you sort of say, well, DevOps is really what we've been doing, sorry, DevOps and, and devs SEC is what we've really been doing in our world for the most part. When you, when you just look at the second, the two, the last two thirds of DevSecOps, you know, what does that mean?

It is part of that definition. And, and so that expands it, I think, a little bit now, uh, beyond where it was. It's not just incident response.

It's not just network level things. And, and even when it is those things, they're doing it more with code now than they used to before. And so things like the SRE movement and the new label, mm-Hmm.

Platform engineering all come into play, I think more when you talk about SecOps today. Yeah. And, And I, I, I, I think what Larry mentioned is, is a great point because with cloud native technologies, we see more and more parts of the system that was usually interactive or even manual.

And, and you know, the best example is infrastructure is code, right? You have infrastructure cloud resources that are now being saved as code. You put them in gi you have versioning, you have all the goodies that you can get from code, and it's part of your, you know, entire application.

And a simple change that in the past, you know, if we talk about five, 10 years ago, would take probably a week or so, to change, is now in every developer's hands. And all you need to do is make a simple mistake and all of a sudden you have 4 22 that you forgot open. And God forbid what, what can happen in production.

Well, I agree with you, Ori. All of the things that we're gonna be talking about today are really steeped in our ability to automate them. Now, that's one of the most impressive and, and fast moving aspects of this.

But I wanna tease back just a little bit. It's always really bugged me that we use the word DevOps. It's actually made me even more infuriated when we said DevSecOps, because I said I'm married to ops.

We have not given the diligence and the focus on the actual operations, we say that we're going to bring them and make them part shift, left, meaning start involvement as early as possible. DevOps and DevSecOps have traditionally focused more folks can argue, but can focus more on development, fast development, fast design, improving the quality and less on all of the security concerns. Less about continuous protection, less about looking at the cost of defects that are breaches in operations, less about threat prevention.

We haven't looked at that in the same way. So now we are talking about operations and security because they are out there in the forefront and are not, uh, as steeped in the early phases of development, though we do need to start to merge that. I, I agree there.

I mean, in, in my mind, and, and let me try to kind of tie a bow on this segment of the panel as I'm not gonna get into the religious war of DevOps is more dev centric than ops centric, because there's arguments to be made on both. But when I think of DevSecOps specifically, I tend to think of pre-deployment security, right? Doing things like, like scanning and all, you know, contrast, cobalt check marks.

You all have a, a variety of different scan solutions that you offer. And so many of, and one of the big things is that these scans are now being done pre-deployment. They're being done at the IDE when code is being written.

They're being done in Git when the stuff is, is, you know, committed to Git, they're being done as part of that CICD process. And that is, that's, you know, that's huge from when I was doing security 25 years ago. We, if you, if you scanned after you've deployed, you were still ahead of the game.

But, um, so when we talk to F SecOps, we tend to think, you know, left of that deployment of point. And then when we talk SecOps, in my mind, it's kind of to the right of the deployment, uh, singularity, if you will now. But what I think makes SecOps special or that we need to do is the, the things we talk about in DevOps, and I think it was Tracy who said things like automation and continuous and, and that kind of stuff.

We are continuing that left to right. Right? And it doesn't stop at deployment.

We're continuously monitoring, we're continuously testing, we're continuously scanning, we're continuous, continuously reacting, iterating, reiterating, feedbacking, and doing it again. And to me, that's what's special about SecOps. Security's always been part of the ops kind of mindset, right?

I, you know, we had a soc Yeah. More so than the dev mindset, arguably. Absolutely.

Mm-Hmm, absolutely. Security was more, has more in common with, with the ops folks than they did dev originally. Mm-Hmm.

But the lessons and, and successes we've had in dev, let's call it devs sec, right? DevSecOps, the lessons we've won in devs sec need to be, and, and those kinds of mentalities need to be applied in SecOps. Well, couldn't we say, instead of continuing to say we need to shift things left, I I, I think you've heard me say this, Alan, I think we've been on a conversation where he said, you know, shift, ubiquitously shift everywhere.

There is not any one Thing. They shift smart now. Yeah.

Smart. Same, same idea. Yeah.

Yeah. But it's, it's being intentional. You're, you're absolutely right that security has more traditionally been on the right hand side.

And if they got involved with dev and, and the upfront definition, it was oftentimes a Bolton, it wasn't as as much of a concern. Now we are thinking about design in depth. We, uh, and so there's a better marriage that's happening.

There is more collaboration that's necessary, but I'm gonna go back to operations day by day, understanding what's happening. Not just reacting, but proactively leveraging some of the new tools that really help us get after, where's the trend? What is the new threat that's on the horizon?

And how are we going to identify that? Now, that's a another piece that is going to help see a differentiation, I believe, between SecOps and DevOps or DevSecOps. I think we're going to see just, um, a continued explosion on the operations side.

I love that. Tracy. I, you know, I, I think though there's a, there's a distinction between the reacting and responding aspect of SecOps and the prevention part of SecOps.

And, and I think that the prevention part is really a matter of quality. And so you, you like to say you're dev married to ops, I'm Dev, married to qa, my wife is sitting in the office right there, and she's a, you know, comes from a QA background, coding oriented qa, so automation, qa. So, so very much aligned with what, what I I'm talking about here.

So security is an aspect of, quality is a phrase I use all the time. I, I think that's incredibly powerful because if you wanna prevent future occurrences, you have to take the occurrences and analyze them, and you have to do three things. You have to do one, the thing that most socks are sort of really geared up to, and that is sort of contain the problem and, and, and immediately sort of address the, the immediate thing that's happening.

But the two and the three are the ones that are actually more powerful. And, and that is that you, you identify that thing that cause that root cause for that problem. And you try to find and fix those everywhere else in your, in your organization.

And then this third step is the most important you put in place something, some change that will prevent you from ever having that vulnerability again in the future. And that's sort of the concept of quality. And, and I, I also, I also have to comment because I loved what Tracy said, there is no left or right anymore.

Okay. You know, because it's, to me, it's kind of the infinite loop of Dev DevOps because it start pre-production, but it doesn't end when you push to production. It only starts, and it's, to me, it's a, I mean, Larry, you said shift smarts.

Uh, check mark says shift everywhere. To me it's about connecting the dots. You have one dot, which is the repo, but you also have the other one, which is what you have running in runtime.

And if you continue to have this separation between the two words, if you want it, it's, it's gonna be a nightmare to fix. Because once things hit, you know, your software, no team, that's too late. And then you need to pick up the phone and tell, I don't know, John, the developer or data developer, what to fix.

And it's already too late. And because you are running so fast, you don't have time to do that. So to me, it's really about connecting the dots as fast as possible.

I, I think that's the ideal we're all shooting for, but we've got organizations with, with job people within specific job responsibilities. Mm-Hmm. And you've got organizational structures and see, and the roles, and they actually have a domain, they have a invested interest in protecting.

So if you read up on Mann's laws of organizational behavior, you know, basically the organization is designed to resist changes to the status quo. And so what you're describing is a fundamental huge change to the status quo. And so I think there's sort of like, um, how do you get from where we are today to there?

And I think this conversation is really more about sort of what's the next few steps of that transition to this ideal that you sort of identified. I'm gonna throw one thing out there, Larry, that's, that dovetails with what you said. Every time we come up with another name, another pho name, another set of phonemes, all snuggled together, it sets off, uh, an absolute sandstorm, right?

That blinds everybody and they're not quite sure what to do with it. I'm gonna throw this out at the beginning for people to just keep in their mind, a SecOps is not the answer. DevOps is not the answer.

SRE is not the answer. Take a step back, I put my architect hat on. Define the problem.

What are we trying to get after? Where's the risk in our flow, right? In our overall flow in what we're doing?

Where's the risk? Let's get after that risk. And we're gonna look at this new set of principles that come from SecOps.

We're going to look at the principles that come from DevOps. We're gonna look at the principles of sre, we're gonna look at the principles from all kinds of other things, and then we'll solve the problem. I always get worried that we're gonna create another team.

So we have the SRE team, plus the SecOps team, plus the operations team, plus the other security audit organization over here, plus the development group, plus somebody running their DevOps pipelines. Just saying, don't do that. Well, it it, it's job security.

I'm sorry, go ahead, Larry. No, but the, I mean the, the, the, the sort of exact opposite of what you described, Tracy is what ORI is sort of, sort of describing it. It's this, you build it, you run it kind of way of thinking.

And so it's one big engineering team that does development and testing and, and pen testing and, and, uh, operations, et cetera. And I don't, I don't think that's realistic in most organizations today. And so that's where I think these sort of new roles, like mm-hmm.

DevOps is not a role, it's a philosophy, right? Exactly. But it got, it got turned into a role in a, in a, a team at a lot of organizations.

And that was a counter, that was a, a, a bad way to go. That was a, you know, uh, well, I'm not gonna say ORI is wrong though. I'm gonna say there might be a perfect situation where that can happen.

In a lot of my world, I deal a lot with different kinds of governments, US government, foreign national governments, our partners state and local, uh, in the United States, primarily for the last five, six years, been focusing there. And I can tell you, it ain't gonna be one big group that all rallies around everything together. It's, it's not structurally possible.

However, the private sector and some of the non-for-profit, not-for-profits, non-profits, you have different opportunities. It could work, but I, I don't see it in some of the larger organizations. And to your point, Conway's Law or, um, Mann's Law, they apply here.

I would love to introduce some colors into our conversation. So I notice that we're talking a lot about directions. We're talking about left, we're talking about, right?

We're talking about infinity and circles and everything getting smudged together. And from a security perspective, I want to introduce these concepts of the red team who is offensive security, thinking like an attacker and the blue team who is defensive security. And from a security perspective, there is actually this concept of purple teaming where the red team is attacking the blue team is at the same time defending.

And there is this way in which the teams are working in a coordinated manner, such that the blue team is saying, okay, do we actually have the correct defenses and monitoring in order to tell what the red team is doing? Um, and those teams, I believe, in order to work most effectively together, really need to work with each other in alignment. Um, one comment that I'll make that I notice about red teaming and blue teaming is that some folks focus a little too heavily, in my opinion, on red teaming because it is fun and sexy to find problems.

What I think is really important is blue teaming, even though sometimes the work may not be quite as flashy, may not be quite as full of fireworks, it's still extremely important to put one brick on top of another and ensure that you've got a strong foundation and really strong detection processes. You know, what's interesting about that, Caroline, is I look at contrast and cobalt and check marks. There's a lot of red team, uh, lineage there, right?

I, I think all three of these companies started with some red team, uh, backgrounds. Yeah. J Jeff, Jeff Williams, our founder aspect security was I fan testing, uh, you know, company essentially.

Yeah. And, and fan testing is kind of the ultimate red team. And I remember when that's what check marks was.

I mean, I remember when I'm, I'm I'm that old. I remember when check marks launched and what they were about. It was, it was the same kind of thing coming out of, you know, uh, pen testing and, and, and testing like that.

Um, is the, is is, is the action in blue and purple now, is that part of like the maturation process here of moving? I do think there's a maturation. When I look at all of the different security standards, compliance standards, frameworks, best practices, one of the things that really frustrates me is that so many of these things say you should do a scan, you should do a pen test.

And while I don't disagree with that at all, I think that the important thing is that you've gotta fix your findings and then you've gotta put preventative things in place so that you're not continuing to reintroduce and just having these issues exist and just be there that you already know about. One of the things at Cobalt, cobalt does a lot of pen testing. And via our platform, one of the things that we're very passionate about is supporting our customers and getting those findings remediated.

We're like all about the fixing. Um, because the finding without the fixing doesn't actually increase your security posture. It's ne negative value, actually.

'cause it creates a liability for you, right? I mean the, the Equifax guys got fired not because they got hacked so much as they knew about the vulnerabilities that got them hacked, and they didn't do anything about it for months. And that, that, that's really the big sin, essentially, is having findings but not rapidly resolving them.

Carolyn, you taught me something in a conversation that we had a couple of months ago. You said, um, about security being sexy or not. Sometimes it's arduous and it's tough to put those fixes into place.

It isn't as flashy as, Hey, I found a bug. Hey, I found an issue. But which is more important, you know, the, the finger in the moat, right?

Or the finger in the wall, rather, that's keeping the water from coming in. Um, you know, or the person that's standing back and and appreciating the trickle of water, right? There is, there's an appreciation for us to grow.

And I think that's something that you were, was really hit me hard about how important it is. And sometimes we don't, we don't take it that way. Sometimes we put too much emphasis on, on the red team, that purple team is really growing in, in adoption, by the way, that whole concept that you've been, you've been talking about seeing it more and more.

So I, I'm gonna jump in here. 2003, uh, I'm a co-founder of a company called Still Secure. And we come up with a product called Van Vulnerability Access and Management, and is when Nessus is still open source.

We're writing our own Nale scripts and, and we're doing this. We knew this problem then. That was 20 years ago, almost 21 years ago.

We, it was the same problem guys. It was the same problem. Yeah.

We could scan till the cows come home and every time we scan, we'd have a yellow pages. That's an old word too. A big fat book full of, of vulnerabilities, right?

And you could start working on those in January 1st, and you would finish December 31st, right? You had a whole year and then you could start over again on January 1st, and you never even finished it by December 31st. Then I remember a, a guy, a friend of mine, giddy Cohen, I don't know if you guys know Giddy, giddy, started Skybox Security, right?

Uh, still around Mo Mordecai, Mo Mo Rosen is now the CEO there, he came out with this great thing, these three D attack maps that would show you it wasn't enough that there was a vulnerability. There had to be a path to act. There had to be an exploit available.

There had to be a path to reach that vulnerability. It had to be exploitable. And so in that way, and we could show what got you more bang for the buck, right?

What if I fix this, I'll close off these 200 vulnerable systems will be fixed, right? So this is not a new problem in security. This is an age old problem in security in that we have more problems, more vulnerabilities, more things that our scans turn up then we can shake a stick at, right?

And, and those folks in the sock and knock, that's, I I think that's where the action is in SecOps. How do I best bang for the buck take what they found in these pen tests and in my runtime environments until we could get 'em fixed, you know, further left in my runtime environments, how do I minimize and manage my risks there? Isn't that a point that Larry and Carolyn and Ori were hitting on earlier, Alan?

And that is our ability to automate, to proactively automate right? To, to auto scale auto fix, right? That ability to self-heal, all of those things agree with you.

20 years ago, 25 years ago when I was involved in that scanning process of security and coming up with those yellow pages, that is, it was a very different time in our ability to act on it and our ability to predict it. So I think that that's a differentiator for us now, which is probably why we're, we're having this conversation. We have the ability to get after it faster.

Yes. You Think, are we Larry? Yeah, I I know, I think Tracy's absolutely right.

The technology, you know, sort of were hints of it that we wanted to sort of have this auto healing capability. Well, so at contrast, we've shifted, you know, it started with aspects security as this red teaming and as, as Carolyn sort of described, it sort of shifted over to be more blue teaming preventing, but, but then we ran into this problem of we were finding vulnerabilities. Our tool contrast tool finds vulnerabilities, but then, you know, getting the developers to fix them rapidly was, you know, it was social and the organizational resistance to that, but as well as technical and time constraints that were hard constraints to it.

So the interesting thing that we did, I think, is that we've shifted to calling it runtime security and the same technology we use to, to do data flow analysis to find vulnerabilities. We're actually modifying the code as it as it gets loaded. Well, why not just modify it also to block attacks to essentially fix the vulnerability at runtime.

And that's what, that's what we're doing now. And it, you know, we, we don't fix a hundred percent of all the vulnerabilities, but, but if you look at the top ones that cause the most damage, we fix a large portion of those top ones that cause the most damage. And so that basically takes the burden off of developers needing to fix them rapidly.

So it's at least saving them, sort of that worry about the time dimension. Um, but even for legacy apps, you have no developers on it fixes it permanently for those, for those folks as well. That's gonna be a really interesting balance between those two.

I'm sorry, Orie, just between the, no, no. Do developers fix it now? W will this automated tool fix it for me?

Do I actually need to go back to that code base? Or do I just start to depend on this automated tool? No, I, I think, I think you wanna fix it.

I mean, maybe, maybe my dev sec world, you know, background is sort of forcing me to say that, causing me to say that 'cause 'cause some of the folks, you know, with more of a SecOps background would say, nah, you never need to fix it permanently. Let's just let the tool keep running. Well what if it, what if it ends up in an environment where that tool is not running?

And that's my, that's my point. So, yeah. Yeah.

Stepped on you. Ori, I wanted you to, I stepped On you. No, I just, I wanted to say, because Alan hit the point, like it's always in security.

The problem was priorities. Okay, how do I prioritize? Because systems get more complex, you know, we have more moving parts.

I no longer have the time to fix everything. I don't want to waste my developer's time. So if I have five, where do I start?

If I have 50, where do I start? And again, I, I do like what Larry mentioned with runtime and, and auto healing. And I think, you know, we didn't mention ai, which is strange because this is everything I've been hearing this year about insecurity is ai, but as technology will will move to, to improve, it's really about, if you heard the term, especially on, on the application security side, it called call to cloud.

And again, it's about connecting the dots. So it's about taking what you have running in production and, and then making sure that your developers focus on that. And if you can also add AI to auto remediate, why not?

So you can make sure that your developers spend the, the five minutes that they don't like, but they have to spend on fixing vulnerabilities on what matters most. Caroline, did you wanna say something? I do.

So I think this automation and manual work thing is so interesting. Um, and I think that the idea that autom remediation and that self-healing is possible is very exciting. And I think that there are cases for which that totally works.

I also think that there is a risk involved. That's important for us to go into it with eyes wide open. There's actually a new category in the Oasp top 10 from 2021, which has to do with data integrity and software failures.

And this is all about, okay, so if what you're automating is good, then great, but what if there's the possibility that an attacker might kind of get in there and automate bad stuff and automate it really, really quickly. So it's just something that we need to take into consideration. I do think that if I take a step back, there's an opportunity similar to what Ori was saying for security folks to prioritize.

And I think that of the hundreds and thousands of security practitioners that I've met throughout my career, so many security people are kind of obsessed with completeness and perfection. They're all about knowing every single vulnerability in that enormous stack of papers, when really there might be an opportunity to spend more time trying to convince executive management that you need a certain amount of resources and investment to focus on the fixing and the preventing. Um, so I actually think that part of it is related to a business problem and security folks having an opportunity to learn how to talk to the business more effectively in order to appropriately allocate resources.

Fair, fair enough. Um, so ai, it got mentioned, uh, here in our little chat on the sideline, Larry timed it in at 44 minutes. Okay, that's a lot longer than I thought we'd make it 'cause it comes up.

But, but all, all kidding aside, all kidding aside, doesn't this scream for AI being a viable helper here, can, I mean, can't AI do this for us? Yeah, so one of the co-founders of Contrast Arshan, he, he formed a new company essentially that is now focused on auto remediation, basically modifying the code to fix it. ai.

ai, Hey, Yeah, he's acon great guy. Um, you know, and so, so you've got, um, uh, you've got this people working on this sort of modify the code auto remediation. I, I think what, what's, what's interesting about what we're doing is we're doing it at runtime.

So we're not, we're not permanently fixing the problem, which requires a process of approval and all that. We're essentially just fixing it at runtime to prevent the attacks, and we're only blocking it if it actually is attacked. So it's, it, it's not a heavyweight thing.

It's not actually causing any, any slowdown in the running. And so I, I think that's, that's, and I think more of the self-healing concepts that Tracy was talking about earlier are really more like what we're talking. So AI is good in both cases.

Mm-Hmm. I think the, the, the vulnerability fixing one is sort of got tool vendors and it's moving along nicely. I don't think the sort of runtime is actually happening as much as I think it, it, it should.

I don't wanna raise my hand and say, Hey guys, as much as I love AI and Al will tell you I'm all in, how do I apply it across the entire SDLC from vision to fielded operations? I'm all in, whether it's generative, whether it's ai, ml doesn't matter, they're still models, they're still prone to errors, they're still prone to security issues, they're still prone to poisoning. So to Ari's point in our chat, we have to keep the humans in the loop.

We can accelerate, we can filter, we can reduce noise, and there will always be for the foreseeable future, a human need to validate, to verify, right? That what those findings are. So we're not kicking people out, we're going to have to upskill them, right?

To help them with these new tools. Okay, let me, let me interject some other randomness into our call, into our discussion today. Speaking of tools we have tools that are kind of, you know, SecOps tools, right?

Observability, five years ago, no one knew what Observ, we called it different things, but things like observability, uh, as a SecOps tool, soar, SOAR, soar, um, these are tools and categories of tools rather, where we're saying, Hey, this, this can help in SecOps. Where do you guys see that fitting into this? And where is, where does it fit into our continuum that we've been talking about the red, blue, purple, if we're gonna go colors, right?

Or is this just something else, you know, non-linear. No, I think interjected, I think it's a very good fit for this conversation of SecOps. So, so, um, you know, just, yeah, I shouldn't be talking about contrast so much here, but it's coming up again.

So we just introduced an observability offering using this same runtime technology we use for detecting vulnerabilities and protecting against attacks. We now can create a, a real security blueprint of the system and including microservices and, and all of that, show it in a graph view every time we demo this in a real situation, uh, literally I've seen it demoed three times where, um, going against a real set of system, this brand new product, so not a huge sample set, but every single time someone from the customer says that's wrong. There is no connection between that system and that database.

And we're like, oh, well, we observed it and we can show you the line of code where it actually does make the connection to that database. And then they go, oh, we haven't been protecting about that. We didn't identify that as a lateral movement possibility.

And, and so, so basically tools help you with basically as cognitive prosthetics, we think we have a block diagram of the whole architecture, but it's wrong. It's missing pieces. And the actual observed architecture is really what you should be analyzing and, and using in your operational decision making.

Fair. Tracy, you had a comment on this. Just that, just that observability, we've had tools for a good bit before it was coined observability.

If I think about, uh, and I'm not with Dynatrace, but think about using Dynatrace more than a decade to ago, to have the hooks in to see exactly what was happening across distributed applications across all of the transactional steps across multiple servers, right? That was a starting place for this. And they have evolved other tools similar to them that were considered AppSec are now continuing on.

We used to have to turn them off. We would turn them on because they, they did create a heavier load in production and would bog down production. But that was one way that we would have that observability.

So there is history and lineage, and to everybody's point, our tech is getting better, our compute is getting much more powerful. So good ideas that we've had in the past that we were not necessarily able to action on in the, the depth that we are now. We're getting there, we're getting there.

I think we have sort of the, the Tracy, you have the, the opposite problem. A lot of times I see like, like I'm talking to clients nowadays who have 22 agents running in production and they're like, we're not adding a 23rd. Uh, you know, and so what, which one of those 22 can you replace the functionality of is we're not installing you unless you have a, you, you, you replace, you know, hopefully you replace three or four of 'em and, and we, we reduce our load.

But yeah, yeah, it is a problem. That's a lot. Just throw some More compute at it.

Budget's not an issue. Well, yeah, I think knowing how much the compute cost is changing the conversation from, oh, it's bad 'cause we, it's gonna cost us more to, oh, let's calculate exactly how much more cloud spend we'll have. And so is this risk reduction worth that spend in addition to the tool costs as well.

So Absolutely. Guys, we're, we're about outta time here. I have to apologize, but we have a whole day of sessions and I can't make this battle the whole day.

But Larry, Caroline, Ori, Tracy, thank you all very much for joining us, most of all. To our audience, thank you for listening in. We hope you've enjoyed this.

Um, it is available on demand if you want to see the, uh, replay, but you know, enjoy the rest of your day. Here at our SecOps event. Uh, this is Alan Shimmel for Techstrong.

We're out.