SecOps Evolution: A CISO’s Guide to an AI SOC

The evolution of security operations from legacy tooling to the agentic era is happening, though at varying paces depending on the organization in question. This episode dives into how:

• Cybersecurity and risk are viewed differently across hospitality, healthcare, and SaaS
• Operationalizing the security stack requires a better understanding of existing tooling and implementation
• AI, AI in the SOC, and the future of AppSec are evolving
  

You can watch the episode now!

‍

Kamal Shah: Hello everyone, and welcome! Welcome to the latest episode of Security Amplified, where we get to talk about all things AI and cybersecurity.

So security teams have spent the last decade buying more tools, hiring more analysts, and still getting burned out. Today's guest made a deliberate bet on a different path. So please join me in welcoming Steve Lukose to the podcast.

Steve is currently a CISO at Sunrise Senior Living, where he joined in August of 2025. And prior to that, he served as CISO at Clari, and before that he held several engineering leadership roles at Endgame and Elastic. He's also an investor at SVCI, a group of CISOs that operates as an angel investor syndicate, and sits on the cyber advisory board for Bain Capital Ventures. So welcome to the podcast, Steve.

Steve Lukose: Hey, Kamal — thanks for having me!

Kamal Shah: So Steve, let's dive right in.

Security & Risk in SaaS vs. Healthcare & Hospitality

Kamal Shah: You've been a security leader and a practitioner at SaaS companies like Clari, and now in a healthcare organization. So how is security and risk similar or different across these two very different industries?

Steve Lukose: So I think one of the most interesting parts of it is that the fundamentals are largely the same. Especially on the security.

The risk posture is very different, but the fundamentals of what we're trying to do, from a program perspective, really aren't that different. It's just the shape of the data, the shape of the organization, the shape of the processes. You know what your risk profile is. That's where I think the real differences are. And a lot of it is really the shape of your workforce. So in a SaaS company, you're staffed with mostly engineers and go to market resources.

In the healthcare vertical, you have... Well, healthcare and hospitality. Senior Living's really the intersection of hospitality and healthcare. So you have a lot more personas than if you're just thinking about like a traditional hospital system. We have all the things around hospitality, very similar to hotels, and there's the way like the financial structures work, but then you also have the care aspect of it, which is super important. And that has a little bit more regulatory oversight than maybe what you're doing, depending on the use cases, in SaaS.

So in SaaS, highly technical workforce. Earlier companies probably have more homogeneous systems. So you know, endpoints, APIs, a lot of very modern tech and you don't necessarily have some of the legacy baggage from IT systems have been running for 10, 15, 20, 30 years.

And in healthcare, organization shape a lot of different personas, not necessarily as technical. And then you have just a lot of systems that have been around 10, 15, 20 years. Not everyone even knows how they were set up, what they were set up for because a lot of these things were created long before modern design patterns fully documented in code exist.

So the shape of what you're protecting is very different.

And sometimes your optionality is more limited because, you know, some of the latest and greatest tools only work with modern platforms, modern APIs, and we don't necessarily always have that. So you need to have an array of tools to protect and, you know, bring that technology where we are.

Attacks More Common in Healthcare

Kamal Shah: Makes perfect sense. Steve, is there a particular type of attack that you see more in healthcare than you saw in a SaaS company like Clari? For example, we hear a lot about ransomware being very prevalent. Are healthcare organizations being targeted with ransomware? Is that a fair assessment or is just not accurate?

Steve Lukose: I think it's a fair assessment, but I also think part of it is the technology that's common in healthcare versus in maybe other verticals.

So a lot of the ransomware uh that is coming out is on the market, is targeting Windows machines, whereas in tech companies you probably have a very low percentage of them, and you also probably have very little data on the endpoint.

In healthcare, you're gonna have more applications on the endpoint and you're gonna have that inner domain. So like one of the things that you have to look about is also like, how is everything interconnected? So in a very large enterprise, you probably have Windows domain, you also are gonna have cloud identity functions and things like that. But there's, it's a much easier from ransomware to then laterally move. And I think that's probably why it's more targeted. Whereas you would see that type of stuff even in SaaS companies, it's just, they'll spray it anywhere. It's gonna link and actually work in certain environments better than others. And I think it's just the technologies that they're using for ransomware. And then the consequences because it's probably easier to laterally move, is just gonna be not just healthcare companies, but any, like large enterprises that have a stack in shape that's more on-prem, more on endpoint, and more Windows native.

Yeah. But with that, like the types of attacks though, like we just see a lot of spoofing, like a lot of spoofing attempts in email.

Because you gotta remember, it's also, it's not just the vertical, but it's very different business to business versus business to consumer. It's just a much wider surface because everything we have has to be available to the end consumer.

Whereas in B2B, your core applications are behind. You know who your customer is, and it's much harder for adversaries to just get access to your platforms 'cause they're just not generally available on the internet.

Kamal Shah: Great insights. Thank you.

Cybersecurity Considerations in M&A

Along the same line, Steve, you've also been in the trenches across several companies on the M&A side, right?

So you have bought companies and were responsible for integrating them from a security, risk, compliance perspective, and you also have been acquired a couple of times. So what advice would you give to other security practitioners and leaders who may be about to navigate a M&A process?

Steve Lukose: Yeah, so when you're looking to acquire another organization, I think one of the things in security that we often do is we look at the technology and the security products and protocols that are in that company.

And I think the more interesting and relevant pieces is actually the core technology and the people and processes that are around it.

So the security stack is interesting, and you can always learn on how they've adapted, given the situations they have. But I think the core learnings and assessments is really like, what is the fundamental technology? How clean are their processes? How well are they documented? So a lot of the things you would just look at for general reliability, how fragmented is it, how siloed is it? What's the frequency of changes? It's really interesting when you look at the systems that are available and are part of the core, like how often are they changed? Have they not been changed in many months? So a lot of it is around people; you look at, hey, are the people who made all the changes this, are they on the actual employee roster still?

So these are like the types of things that I think are really, really important for the security team to have an understanding of, 'cause then you have a much better understanding of what you're getting into. And when you actually tie those integrations together, is being able to marry the people with the core technology.

And then, you know, ultimately you want to have a consolidated security stack is wherever you can. So some of the tools they may have in there will likely get swapped out, but it's really the core. More focusing on the people and process and less so on the technology. And that really gives you a much better sense of what their maturity is.

'cause you're not gonna find that in compliance docs. You're not gonna find that in audit. You're gonna find it in the where when you can look inside the box and see how are these processes actually working and do they know how they're actually working? And that's really informative.

Prepping to be acquired or prepping to do a merger... it's kind of a similar exercise as you really wanna understand how that organization is set up and where the different pieces will naturally intersect. So you have like some core IT systems around identity, but then, you know, if it's tech company, you're gonna be stitching together applications.

Like where are those natural points? Where is there likely to be really difficult parts for, you know most likely authorization, not authentication. And I think a lot of people overlook this when they're like sizing up companies, just how important identity is to the core user experience in an application.

And if you don't have identity, right, it's really hard to grow a platform. And so you really gotta look at that very, very closely, because it's not just how do I secure this product, but it's also like, well, when this thing is married together, will it be an experience that's actually good fundamentally for the business?

Like, will it actually help growth or is this gonna be a problem where we're gonna be, keep going back to this, or we're not gonna be able to support a lot of things in the core thesis for the, for the merger or the acquisition in the first place.

Operationalizing the Security Stack

Kamal Shah: Speaking of technology stack, today you see enterprises deploying a wide range of technologies, right? You mentioned identity. There's endpoint or EDR products. There's cloud security, there's email, phishing, DLP, network security, and so on. More tooling does mean more visibility, but it also means more alerts, right? And therefore noise for your team to sift through a vast attack surface.

So when you think about operationalizing these tools and you think about the impact to your security operations team. How do you think about gaps or opportunities and how did you think about solving them?

Steve Lukose: So one, one of the things I think is super important is like whenever we bring in new tools is we gotta like, put a lot of thought around the process behind how we're gonna operate the tools and where they're gonna fit into the platform.

Sometimes you can, you know, you go off the tendencies for the teams that are selling those products.

You go off on tangents and you, you lose focus on like, hey, what, what's the real reason we're bringing in? What are the outcomes we're gonna try and drive. And then understand. Hey, with this tool, when it adds new alerts, features, whatever the case may be, how are they gonna fit into the overall process and plan and, and do they actually fit?

And I think it's just super important as you're sizing up any component that you're gonna add in and is like, how does it fit into the workflows? How does it change the workflows? Does that change my staffing on this or in another area? And without that, what ends up happening is, yeah, you just end up having a tool that has very low adoption because you know, you didn't do the hard work to figure out like, how does this really fit in to solve whatever component it is.

And it could be like, how does it fit into reporting? We're not gonna go to a separate tool to do reporting. We do reporting as a business here. So like, are we getting the appropriate data here.

Or in a workflow, in a process like the notification scheme, if something's happening, like how, how do you inform like this cohort of team members, this cohort of team members and tools don't naturally do that or fit into a process that naturally do that?

I think it's really, really hard.

And you're gonna have that because everyone has fragmented sets of IT systems, and not every product will naturally play with all of them. And so you do see that, but I think you always have to step back and be like, how does this actually fit in the overall program and do we have to make people or process changes for it to actually work?

Kamal Shah: That's a great point, Steve. We had a prospect recently where they were trying to, the CIO was keen on implementing insider threat capabilities.

And so they said, okay, we're gonna buy a tool. We have a enterprise license from a vendor. They have a insider threat or DLP module that we gotta implement it. And they didn't really think through what it.

It was gonna take to operationalize it. And when they went to operationalize it, their security operations team said, okay, great. You wanna do this? And based on the alerts we are expecting, we need four additional headcount.

And, and the headcount wasn't budgeted for, for, that project. And so, you know, they had to then go back and say, okay, how do we go and find the headcount? How do we operationalize it? Because at the end of the day, as you said, it's about delivering outcomes and not about deploying another security tool for security tool's sake.

Steve Lukose: Yeah, it's super important. Headcount, or if you rely or work with a lot of partners, is that, how does it change their model or support you know, 'cause it could be like part of a net expansion and, you know, a services area that's like not fit in with the tool and then yeah.

Then you either made an investment that you're not gonna yield much from, or you have to like kind of revisit and get it rolled up into the next budget cycle, which is super painful for the teams. 'cause, you know, they brought something in, they're very excited about it.

Then it's just kinda, you know, sitting on the back burner or sitting like not actually reaping the rewards that they would've put in the business case and not delivering the value, that they've probably sold to the rest of the teams internally.

Shortfalls of SIEM & SOAR

Kamal Shah: Speaking of operationalizing security tools, there has been an enormous spend over the past decade on SIEM and SOAR. Technologies or solutions, and in your view, where do those investments work and where did they fall short?

Steve Lukose: So I mean, SIEM has been... I think people have been talking about that being like overly expensive and not delivering the value you know, that is talked about for forever.

And you know, one is, is that I think when people are setting up ingesting into SIEMs, they don't necessarily know they're just throwing data in there without, you know, a predetermined outcome that they're looking to solve for.

And so what does that result in? It results in like huge SIEM bills or huge stacks that you gotta deploy. It's much harder to query. It's much harder to actually get information out of it. I think that's partly... it comes down to a lot of times, and this is something we all need to do as security practitioners, is that you really have to understand the systems that you're monitoring.

You know, it's like, if I think about observability, which I think is very close to the SIEM world, if I was building an application and I just threw like default monitoring on everything and I didn't really know much about that application, the observability is not gonna really help me, right? Because I don't know how this thing's supposed to behave.

And the same thing goes for security tools. The reason you need a bunch of 'em is actually people configuring them either in the security side or in the IT side, don't understand fully the different attributes of whatever technology that they're managing, right?

And it's not necessarily a fault of them.

Some of these platforms are massive, have hundreds, thousands of features. But that's what adversaries are looking for is, is that they understand how these products work. They're looking for gaps in configuration or interoperability, and then that's how they get in or that's how they exfil data.

And so I think to get more value out of these products, those that are securing, those are implementing, need to have deeper understanding of those products. SIEM is supposed to like just help you forensically go back and get that telemetry, but without really knowing the core tenets of what you're looking for, like we could get the same value, I assume probably ingest 10% of what we actually ingest.

But no one's really sure of what things they really need and why. Especially when you interact more. And then what ends up happening is, is that you write all these rules and one they just fire "alert, alert, alert, alert, alert," and you know, not all of them are actionable. And that's kind of like the problem with it to begin with.

SOAR is supposed to then what?

Take all those and do some automation, run playbooks around it. So it's just kind of building some deterministic response for all those SIEM events.

So I think, you know, it kind of just gets rolled up.

A lot of people say garbage in, garbage out. Well, you know, if you have a whole bunch of alerts that don't mean anything, and then you write a whole lot of automation, you're building a stack that's not really outcome based.

It's more of just activity based.

Kamal Shah: A hundred percent. It's a common complaint that we hear from our customers. We've even had customers say that, you know, SIEM or SOAR is dead.

Drivers of Agentic AI & AI SOC Platform Adoption

Kamal Shah: During your time at Clari, Steve, you evaluated and you onboarded Prophet AI as your AI SOC platform of choice. And we are truly grateful for the partnership.

And what we are beginning to see now is that more and more organizations are comfortable adopting agentic AI solutions to streamline security operations. So the question for you to, to kick off the discussion around agentic AI SOC platforms is: how did you think about the evaluation process and, you know, before we even get to the evaluation process, what were the business drivers that led you to the process of evaluating agentic AI SOC solutions?

Steve Lukose: First, we'll look at the team and where we had, so you structure a team and in that team, you know, we have like kind of three core areas.

In a SaaS company, you have the GRC component is there. And part of their mantra is assuring the customer. So it's not just doing all the governance, risk and compliance, but it's also making sure that our customers know the story about all the things that we're doing to have a secure platform and a secure program.

And then you have application security, the core tenet, really helping the engineers build the product properly, making sure it's adequately protected.

And then building security services. So you can do IT response, incident response, security response. And then you have security operations and one of the core drivers and decisions we had is, is that we really wanted to double down on application security. And that's where we wanted to put most of the security headcount and budget is because we are a software platform, and we're gonna spend most of that budget and make most of the investment around making sure that our customer's data is safe.

That's the number one priority, and you need a lot of AppSec to do that.

What that meant is AppSec had to support the operations side of the business, and I didn't want them chasing alerts and we didn't want them chasing alerts. We wanted them spending more time with our engineering teams, making sure we had the most secure code we had.

We had the proper governance and restrictions around all our data sets for our customers. So we didn't have a lot of headcount to be delivered to managing operations. And so with that, we needed a way to make sure that we weren't allowing too many incidents to pile up. But you want your best resources to focus on R&D and engineering and not necessarily doing repetitive process and tasks.

So we wanted to find a system that could scale based on the way we wanted to deploy our operating model. And we wanted to make sure that we are covering and we wanted to make sure any actionable alert was getting actioned immediately. Not an hour from when it came, not two hours, not a day.

With traditional methods of doing it, we weren't gonna be able to do that as well as we wanted to, or we were going to have to have people focus on tasks that I think they, you know, they could bring more value doing other things.

Kamal Shah: So it was essentially a productivity and a cost effectiveness argument for the team, balancing risk with resource allocation. And

Steve Lukose: that was the thesis, for sure is, is that we wanted to be able to yield better productivity and we wanted to make sure that we could focus on really keeping our AppSec folks as close to core engineering as possible.

Once we got into it, the scope expanded a little bit. So we came early.

So there was quite a few more unknowns on how will this look like? And so we were learning as part of that process.

So I think, you know, we talked about like kind of the initial business problem, the initial thesis, but then we learned a few things.

I think one of the most interesting things I learned from that exercise was, is that, you know, over the last 10, 20 years, the security industry itself has architected all of their alerting and tooling based on the fact that we have humans triage all these alerts. And you only have so much capacity to do that, and no one likes to deal with alert that may or may not be the five alarm fire.

And what we realized is that actually we could retune some of our alerts because we don't have to worry about burning out or annoying someone for doing, uh, looking at something that's probably a minor but, could be something. And I think in industry as a whole we kind of largely ignored a lot of those, or we'd retune alerts so they weren't as noisy. But when you're using AI to action these things or evaluate these things, false positives aren't as big of a problem.

Whereas like this is one of the things that any tooling vendor, what is it? CSPM or if it's EDR or any of those, like it's false positives, false positives. Like no one wants them. And it's kind of changes the math a little bit because you don't necessarily care as much because you're not putting your staff through the pain of dealing with them.

You can kind of arbite all of them. And I think that was just kind of a really interesting kind of aha that the team solely got to as there watching it in action.

Kamal Shah: Absolutely. We see so many customers that are suppressing alerts because the team is overwhelmed with the number of alerts, right? So you turn them off, you suppress them, or it goes into a backlog, and then they clear, try to clear it once a quarter.

And these are not just low, but medium severity alerts. And it's an issue that's keeping people up at night, but now with, with AI, it truly does allow you to increase the aperture of what you look for to make sure there's nothing that's that's lurking in your environment.

Steve Lukose: Oh yeah.

Kamal Shah: So when you think about investing in a Prophet AI, and you have to now think about, okay, what's the ROI that we have achieved and how do we demonstrate that ROI to the executive team and to your board. What metrics, uh, did you think about and what metrics should your peers think about as they look to quantify the benefits of an agentic AI SOC platform?

Steve Lukose: I think there's two lenses to look at it.

One, I think the productivity one I think is fairly straightforward, right? So typically you're gonna staff specific sizes of incident response teams, and you're probably gonna do them in multiple geos for, you know, follow the sun in 24/7. So, like, what does that minimum base case look like?

And then they usually scale by the number of things. So there are backlogs, you know, you have metrics on different businesses measure it differently. Some it's gonna be by the backlog. Some, it's just gonna be the number of like concurrent things that need to be processed. The amount of handoffs.

However you're running that you're gonna have some level of metrics to determine whether or not you need to add headcount to those teams. Alright, so how does that calculation change? And that kind of gives you the value, 'cause it's somewhat of a competition for labor than it is for any software tool.

So I think the productivity is fairly straightforward. It's just based on how you do your, your staff and modeling.

I think the other one that is really interesting is, is that oftentimes we all make trade-offs on what systems we monitor at certain levels, right? So can you expand the aperture? Like you're gonna always, you know, double down, triple down on your crown jewels and your tier one assets.

But can you put a higher level of assurance on systems that may not have that, first class in whatever your company is. And I think where you can make adjustments in your risk posture is the other way that we will talk about it with the, the executive team is, hey, we're bringing this protection that we've always had over here 'cause we've needed it, but now we're de-risking other parts of the business that we otherwise used to not have as much oversight over.

Kamal Shah: Yeah. We've also seen customers think about it in the context of mean time to investigate. You know, as you mentioned earlier, how long does the alert sit in a queue before it gets picked up and, before it gets triaged and investigated.

What we are beginning to see is the breakout time of an alert of a cyber crime, according to CrowdStrike, has shrunk dramatically over the last couple of years from, you know, 48 hours to 24 hours, to a few hours to now, the latest reports that, that it's less than 30 minutes. So you can imagine the risk if it's gonna take you 30 minutes to an hour before somebody on your team or even your outsourced managed detection and response or MSSP provider can pick up that alert and triage and investigate it, and by the time they get to it, the damage might be done. Right. So the speed and velocity and the complexity of these alerts also is another driver that we are seeing from our customers.

Blast from the Past: the Evolution of AI in Security

So we talked about metrics, we talked about the impact that AI is having in the industry, and now just a little bit of a blast from the past: two years ago, Steve, you were on stage at RSA with " Phishing LLMs: Reeling in the Machine," and that was midway midpoint from when ChatGPT initially was launched to where we are today. And so as you think about the impact of AI on security. What do you think has changed in the last three years, and what do you think it's headed in the future?

Steve Lukose: Yeah. I guess RSA is coming up next week.

Yeah, so I don't think a lot of the core principles I talked about in that presentation really have changed. So, and a lot of what I was talking about there is, is that at the time, it's still really hyped on what you can and can't do.

Like people were kind of really figuring out what use cases like make sense for AI and even the frontier models were a lot less mature than they are today. And you know, at the same time there's this intersection where there's all this new kind of AI technology or slot to kind of protect the AI workflows that didn't really exist in enterprise anyway.

And back to what I was saying earlier about a lot of the security gaps we have is really just a lack of deep understanding of some of the major and huge platforms that we manage. And, you know, at the time a lot of folks really didn't know the basics of how models worked, how they're assembled, so we break down and if you break down like a lot of the core stacks and you know, there, it's even similar when you're running agents, but you know, you, you have a model gateway, an API gateway. You have your models, your application law, and then you get data. It's like a three tier application.

I'm oversimplifying it a little bit, but, and it's so really, like, so how do we, based on what we know and how we protect applications, alright, looking at each layer in the stack, what in our existing menu of security protections do we apply in each spot?

And the punchline is, is a lot of our existing technology naturally adapts very well to these technologies.

I think the one area where there'll be new tools and players because it very much changes: authorization. And you know, now we're gonna have all these different personas that are non-humans taking actions. So I think there will be some really interesting tooling and security enhancements there.

But the vast majority of these systems can be protected with existing or like preexisting techniques that we've had for a long time.

And you know, why did so many like I think the MITRE framework had like hundreds of different like AI type exploits and it was like, alright, this technology's only existed a year. How is there so many so already?

Because the attackers are just adapting what they've always done and just using this to augment it and they're looking for the same gaps. And models you can attack with semantics. They don't necessarily have to write the code, and the same cat and mouse game will continue to go on.

So I think the core principles of that stand. It's just as we're learning more and as more of these technologies actually mature where they're gonna be in production is, there's nuances to how they work. And I think there's gonna be some great companies that design systems that really protect the way work actually happens with AI.

And we're starting to see how agentic flows may work in a true enterprise. I don't think there's very few enterprises that are really there yet. But I think the way they will operate will kind of start to crystallize over the next year or two.

Kamal Shah: Yeah, absolutely. And there's always an interesting debate. Around, you know, how many, how much of these capabilities will be embedded or provided by the model providers or the frontier labs themselves, because they want to make sure that they remove a barrier to increasing the adoption of AI versus, Hey, we're gonna rely on security tools because we're gonna use multiple models and we need one vendor that can provide us with those capabilities across multiple frontier models that we are using in our environment.

Steve Lukose: Yeah, and I think the frontier labs are even like one of the things we talked about like we use, you know, social logins or Google logins or Microsoft provided logins for a lot of things. So in the enterprise it might be your core IP provider and consumer it's using the big social platforms well.

These labs are gonna want to do that too, because then I can bring the inference to the app. So, you know it kind of de-risks and like, the app provider can just provide the specialties that they have, but then they don't have to forecast how much someone's going to use or not use it because the consumer is bringing the inference versus the app provider.

I think we might see that more and more in B2B Tech as well, where the customer is gonna bring their inference to the application versus the application, bringing the inference to the customer.

So it'll be interesting to see how you can put security controls around in that environment.

And then you know, how companies are gonna be able to bring inference to the problem versus the reverse, which is I think traditionally how we consume SaaS.

The Future of AppSec

Kamal Shah: Interesting for sure. One last question from me, Steve, before we get into rapid fire set of questions. You mentioned AppSec as being very near and dear to you. And as you know, a lot of folks are now using coding agents, whether it's Claude Code or Codex or Cursor to generate code and software engineers are becoming very good at prompting.

And then I'm sure you followed the announcement that Claude came out with Claude Code security and wiped out billions from security companies market cap.

Controversial question: do you feel that AppSec is dead? Given that the majority of the code moving forward, maybe not now, maybe two years from now, is gonna be written by these coding agents, and therefore they're in the best position to provide the security needed from an application standpoint?

Steve Lukose: I don't think AppSec is dead at all. I think what AppSec practitioners will be doing will change quite a bit over the next couple of years. I think it'll hurt some of the preexisting kind of code scanning companies or companies doing SEA, and companies doing pure static analysis.

I think those segments are gonna get disrupted for sure.

What I think will change a lot with AppSec is they're just gonna be a lot closer to the design, right? So you can build the system, you can code it, you can, you know, write beautiful modules for how you're doing it, but if the design doesn't meet the use case, does the authorization buckets make sense for what you're trying to do?

Like those types of architectural decisions, I think is where App Sec is gonna be spending a lot more time. And so spending a lot more time with the product managers and the business, users and the requirements to make sure that we're building those security functions upfront and building 'em in a way that'll adapt to like, make things true platforms.

'cause that's ultimately what makes a lot of these like technology platforms successful is like, what's all the interoperability? And how do you adapt that for, you know, current use cases, all basically human users. And then you might have a service user or two, but the scope and the agency that a service user is gonna have is gonna change dramatically.

So how do you think through those permission models so you can then go and take that into enterprise and actually be successful. That's where I think most AppSec practitioners will be spending a lot of time.

And yeah, all the kind of code security, there's still gonna be oversight on how code is merged and architecturally how is it all fitting together.

Eventually I think models will eat up some of that as well, but that's gonna take a lot more time.

Kamal Shah: Yeah, completely agree. I don't think any function is going away, but the provider for that function might, might evolve as these frontier labs add more and more capabilities.

Steve Lukose: Yeah, I mean, I mean, it's the same thing for the, like as a former software engineer, I've been in leadership for quite some time, so I don't get to or don't have time to code anymore. But now when I do do things, it the way you would do it is completely different, right? Like the activity, I'm not gonna.

It used to be like, you know, you figure out a problem that you wanna solve, then you draw up what that might look like, how the different components will intersect, and then you start building parts of it piece by piece, line by line. But now you do the same exercise in thinking about the problem conceptually, how you solve it, but the last app I wrote was entirely by voice.

I was just talking to the model and then you do this iterative thing. So security is gonna change the same as the folks are gonna be doing those functions and acting with that agency, but the activity is gonna be completely different.

Rapid Fire & Conclusion

Kamal Shah: Absolutely. And on that note, let's get into the rapid fire round, Steve.

So first question, what's the one role or experience from your resume that most people overlook, but you think shaped you the most?

Steve Lukose: Yeah. Actually I don't even know if it's on my resume anymore 'cause it was kind of earlier in my career, but I don't know if it was experience. I think people like really shape how you think about things, how you solve. And I, I had a, a leader quite earlier in my career that took me under his wing.

And I think I learned more in the year and a half I was working with him than, you know, in many other kind of experiences I had. So I think, I mean, one thing is just especially early in your career, seek out good mentors and then spend a lot of time with 'em. It like dramatically, I think, shapes the trajectory of what you might other be exposed to if you didn't do that.

Kamal Shah: Plus one to that I had a similar experience, early, early in my career when I was at Federal Express or FedEx. And the VP there took me under his wings and that had a profound impact on my career.

Steve Lukose: Yeah.

Kamal Shah: Which security tool or category will be obsolete in the next couple of years because of AI?

Steve Lukose: I don't think it'll be obsolete, but it will be completely rethought is DLP.

So DLP is, I don't know, for, especially for security practice, which is like an awful experience. Like it doesn't matter the vendor that it's doesn't fit in well with the business. And I think, AI is gonna make that far more capable and actually might like. I think with the new technology we have available, I think companies might actually be able to realize the vision of what DLP was supposed to be. So I see that being disrupted for sure. So I don't think it's gonna go away. I think someone might actually solve the problem. So pretty excited about that.

Kamal Shah: Awesome. What's your beverage of choice?

Steve Lukose: So I drink at an like an obnoxious amount of cold brew. You know, I probably drink like four of these massive cups a day. So at some point I think the caffeine meter will go off the charts, but I'll keep doing it until a doctor tells me I can't.

Kamal Shah: I love it. What have you recently read or listened to that you would recommend?

Steve Lukose: There's a book I go back to every once in a while. I think it just, it helps when I'm thinking about like, team dynamics. It's "Amp It Up" by Frank Slootman, the former CEO of Snowflake. It has a lot of really good principles in there around thinking about teams and how to move fast, but do it in an intentional way.

And so I find every once in a while I just go back to that and I recently read it and I'll probably give it to some of the folks on my staff. I think it's a fantastic book about just about thinking about teams and just managing a pace, but not doing it in a way that you burn folks out either.

Kamal Shah: I love the book. And finally, a destination you're looking forward to traveling to, or a vacation that you're thinking about that you'd recommend others take?

Steve Lukose: So I'm super excited that most of you are going to RSA next week. I'll be, a few days later, I'm instead going off to South Africa and doing safari. Super excited about it. Been there in the past, but this is the first time we're taking the kids there. So, beautiful, beautiful country. zyou got, you know, the whole aspects of the safari, but then you have the wine regions down near Cape Town. It's just, it's a wonderful place.

Kamal Shah: Yeah. Stellenbosch region, right. So, wishing you a great trip, have a blast, and thank you so much for joining Steve!

Steve Lukose: All right. Thanks Kamal. Thanks for having me.

‍