James Berthoty (00:01)
Hello everyone and welcome to the inaugural episode of SecOps Confidential, the podcast that gives a real practitioner talk on security operations, how to do it, how to set it up, how to manage a program effectively from top to bottom. Today I am so glad to be joined by Patrick McKinney, who's the VP of Security at Invisible. And Patrick, I'll let you introduce yourself a little bit more as well, but you have an illustrious career.
Doing program management across brands everyone knows from Coinbase to Salesforce to Dropbox, tools we've all used. So thank you so much for joining us and I'm excited to dig into security operations.
Patrick McKinney (00:41)
Yeah, thanks for having me. Excited to be here. Like you said, yeah, I've been in a lot of companies that people have recognized. Before that, it was the federal sector. So I've got a little bit of public and private sector experience. And it's been a fun 20 years so far.
James Berthoty (00:56)
Yeah, and really like we can even just start with that. How have you seen security operations change over that 20-year period? I feel like it's just gotta be a whirlwind in some ways and then in other ways it's like I don't know, Splunk is Splunk, so yeah.
Patrick McKinney (01:10)
Yeah, I think you're right. Think there's still always that how do you get ahead of things as much as you possibly can, whether back in the day was trying to make sure you had signal coverage across all of your environment and tools that are bringing in less noise than signal, and making sure you had runbooks to address anything and doing more of the detection. Think a lot of the stuff you're seeing now with tools that are coming out.
They're trying to get even more ahead by doing policy-level blocking to reduce the need for runbooks and response and try to proactively block as much as you can. Mean, obviously the introduction of AI coding, now you have to keep up with AI coding tools and everything like that. So I think the evolution's been interesting, but I think you're still at the end of the day, the goal has been the same, and that is to get ahead as much as you possibly can and be able to respond to everything you can't get ahead of.
James Berthoty (02:05)
Yeah, I think that's a good way to put it. And today we're mostly going to be talking about how to build these security operations programs. And the struggle that I've consistently run into, like part of my background is working at an MDR that primarily was focused on enterprise clients, but I've also helped build a SOC 2 automation competitive product. So I was working with a ton of startups doing their first like, no, what's a SOC 2? How do we fix it? Well, it's like getting into security for the first time. And something that I always found to be a major challenge in working with small to mid-market companies is like, when should they build a security operations program? Because typically it's like the CTO is sort of responsible for it. And then like maybe they hire a DevOps-y, DevSecOps kind of person. But when do you start building out the like, all right, we're gonna deploy XDR and SIEMs and build a more full-fledged operations program.
Patrick McKinney (02:59)
Yeah, that's a really good point. That's actually the story and how I came into Invisible. They were running this at the CTO and head of IT level and basically just became overwhelming for them to manage while doing their actual jobs as CTO and head of IT. So I came in and really what I think to answer the question on what's the order of operations in which you implement these things. Think it does. It's very company-specific. It's very nuanced based on what products you're selling.
Who your customer base is. Is your customer base already very mature? Is it very lean and scrappy startup-y world? Obviously meeting compliance controls and compliance requirements, you could do them in different ways. You don't necessarily have to bring in $500,000 worth of tools as soon as you can to meet these goals. You can meet them through existing tooling or processes. So I think it becomes kind of a guess-test-and-revise on how can we scale for these different security requirements we have to meet not only for compliance and for sales purposes, but also to really build a security program that goes beyond compliance.
James Berthoty (04:07)
So it sounds like you're suggesting sort of like an organic approach to growing a program where, you know, I'll put it in more like cloud-native terms for more startups these days, right? Where it's like, you've got something managing CloudTrail logs. Maybe you're doing like Athena querying off the start. And then maybe you start to hit limitations with that. And that's when you start looking for like a cloud SIEM or like some kind of CNAPP tooling or just something to help accelerate that.
Patrick McKinney (04:30)
Okay.
James Berthoty (04:35)
Response time, is that sort of like the flow you see happening?
Patrick McKinney (04:38)
Yeah, exactly. Yeah. And I came in, I came in when I came into Invisible, I came in with a checklist of things I wanted to do. You everybody comes in, I'm going to build this state-of-the-art security program. Then I got, you know, finance is like, okay, slow down, you know, everybody else is like, hey, we don't have a lot of engineering resources to throw at that. So it's like, okay, so it's just me to start. Okay, great. And doing that, I was like, well, what tools do I have to leverage and what can I do? You know, we had a GRC tool that was
decent enough at vulnerability checking. And so we were using that to start until we brought in a better tool that had more capabilities and more, and allowed us to rank better on our vulnerabilities. Let us prioritize smarter than just the GRC tool. And I think that's kind of the approach you take across the board in order to maximize security coverage is basically where it is.
James Berthoty (05:26)
And then how do you just from like a leadership standpoint, how do you build the case to grow that budget over time and not just get forgotten about?
Patrick McKinney (05:36)
The never-ending battle. So I've been lucky enough in my career to work for some folks that have taught me that tying dollar amounts to risk and tying dollar amounts to resolutions is really the way to talk to the business. The business doesn't understand, we've got X amount of APTs coming in and if we get popped by those, it's going to be bad. They don't understand that. But when you sit there and say, well, security can factor into multiple areas of the business and that is revenue retention as well as garnering trust in your customers for better and quicker turnaround times with your sales cycles as well as potentially even generating revenue through
just helping the business essentially stay pristine in the market. You don't have any major incidents that pop up in the media and stuff like that. So I've been doing a mix of tying my programs and my headcount assets and my tooling towards goals that will either retain revenue or help us build new revenue through gaining compliance frameworks that will get us into new businesses. There's public sector frameworks, there's privacy frameworks in different countries that you have to abide by now and things like that. You can't just go after them as a one person with no tool type security team.
James Berthoty (06:54)
Yeah, that's I think something that I've seen develop maybe more over the last five years and tell me if you've seen this as well or if you think it actually goes back longer than this. I've been surprised by the success of certain security startups focused on creating web pages just to communicate your trust portfolio. Because as an engineer, I was like, this doesn't—why is why are we buying this? Right. This isn't like doing anything. But really, I think what it's doing is communicating to customers, building trust and part of that customer retention story is your security program and it's part of building the trust of the brand portfolio more broadly and not just as like a thing that stops breaches from happening.
Patrick McKinney (07:35)
Yeah, you're 100% right. Mean, we've actually been touted for having a trust center at our stage in the life cycle, as well as I'm now seeing, even beyond just general security trust centers, we're seeing privacy-specific trust centers pop up on companies. Shout out to my alma mater, Dropbox. They have a great one. Tolga does a great job there. And I think you're gonna see now, you're gonna start seeing AI-specific content on trust centers because a lot of companies are becoming more aware of the use of AI and they want to understand really intrinsically, where is my data going? How is it being protected? Is it being trained on all these different things? And so you're going to have to have an AI trust center as well as your privacy trust center, as well as your general security posture trust center. So I think these external sites are going to start to become not only very useful, but they're going to become way more sophisticated.
James Berthoty (08:28)
Yeah, that's, actually, I'm glad you said that because I forgot about even seeing one of those demos recently, again, thinking like, why is this like an arbitrary trust score attached to like what model of a ChatGPT we're using, model, what Anthropic model are we using? But I think it connects back to that point of just communicating clearly to make people feel the more trust that's there. For someone who's like got more of an engineering background or even like a program management background, like what are the ways to start trying to build that more business-centric approach to justifying what your team is doing?
Patrick McKinney (09:08)
Yeah, I think some of the ways are, mean, at this point you have to go beyond the table stakes. Like, hey, we have to get a SOC 2. And they're like, great, go spend the least amount of money to get a SOC 2 report. We’re all, my GRC friends, close your ears. But SOC 2 is table stakes. It's a race to the bottom in terms of selling that from a GRC perspective. So I think what you need to do now is go beyond just the compliance framework and start, even if you're not actually going for an ISO 27001, or you're not actually going for a NIST framework,
or any of those, you need to start building your documentation and your programs towards those before you're ready to audit. And I think without just saying, you know, we need to use revenue retention as the only lever to build a security program, there needs to be—the security team needs to be in touch with the business in terms of where they're selling. If you're selling into the FinTech or the health care market, there are absolutely regulations you have to abide by. And those regulations do require certain maturity within your security program.
If you're just selling to the general companies of the world that don't require these, there are still areas that those companies will care about much more, whether it's data security, whether it's data security, data retention, whether it's encryption, whether it's all these things, and documenting that, taking an entire inventory of your systems and your business's capabilities from a security perspective, I think are the best way to start, and then tying that to areas that the business is going towards, just staying in contact with the business and knowing where they're going and then trying to meet them as they're going that way and really tying those together. It greases the skids with finance and say, okay, well, if we have to do that for sales, this makes sense. It's an investment we're willing to do.
James Berthoty (10:46)
Yeah.
Well, then let's, you know, there's plenty more we could talk about on the SOC 2, just because that's my background or part of it. But instead I want to back up to thinking about even if you've seen specific triggers over your career that make it very easy to begin talking about either like purchasing an MDR contract, starting up your own security operations program. Like I've just found different. So like something that I found in the AppSec world is like,
Patrick McKinney (11:13)
Mm-hmm.
James Berthoty (11:16)
tying yourself to like the DevSecOps maturity model or the software maturity model from OWASP and like that is a very useful lever for getting funding and maturing an AppSec program. Have you seen anything similar on the security operations side that's like really given you a strong movement in maturity to follow for like getting budget and building this out over time?
Patrick McKinney (11:37)
There's definitely, yeah, so along the lines of like OWASP and DevOps security, DevSecOps security models, there's also some, you know, we're getting into the public sector as a company. So CMMC is the public sector maturity model that we're also trying to go along with. There's CIS, there's NIST, there's all those. And when it comes to things like MDR, and when it comes to managed detection and response tooling, for me, it was about, it was, I want to say it was a no-brainer in my head, but then we got it on paper and we actually,
you know, put it out there, that it just saves money early on to go with a managed detection and response type tool. And when you're doing these maturity models, you want to meet all the requirements you possibly can of these maturity models without spending as much money as you need to or as you would have to. So MDR tools like Exaforce that are out there right now, you know, they're fantastic that they provide the human and AI and technology capabilities all in one package and I don't have to hire to chase the sun because hiring to do it is not only a logistical complexity, it's an expensive complexity to add to it too. Bringing those in, while it's a big number, it's a big ticket item out of your list of security tools, it justifies itself in how it pays for itself with the lack of hiring you have to do.
James Berthoty (12:57)
Well, that's, think something, you since I've worked at an MDR, I think I was very tempted at times to be like disillusioned by the service because I would see like, every MDR has this, this is no slight against anyone, but like, you've got like a new analyst who's in training and they're giving really bad responses to stuff or like things aren't getting routed to the right person, like mistakes happen and an internal team has to deal with it. So there are like headaches that I want us to talk about in terms of thinking about like, do I build out my own SOC versus an MDR?
But I think what you're getting at is what I've always thought is like the fuzzy math makes it make like total sense because if you're looking at building your own SOC, it's like analyst, detection engineer, and SIEM engineer, and that's like, you know, three to 500,000 a year in salary. Plus you throw like a Splunk license on top, which ain't cheap. And then if you throw a CrowdStrike on top, that also ain't cheap. And you're already like a million dollars out the door before you've even like done anything, just to have like the most basic sort of bare bones setup.
Patrick McKinney (13:45)
Yep.
James Berthoty (13:52)
And so to me, that's where like an MDR contract for anywhere in the six figures just starts to make sense for people. Is that sort of how you think about it or like, there gotchas around trying to do that fuzzy math or yeah, what are your thoughts on that?
Patrick McKinney (14:07)
No, you're exactly right. I looked at it purely from a headcount perspective and that alone made it worth it. And then you add in the extra tooling. Mean, some stuff you're going to end up buying anyway, like CrowdStrike or SentinelOne, one of those EDR tools. You're going to buy those anyway for your company because you need them. But having an MDR company, especially it already has the tooling built in with them, you may not have to purchase a Splunk because they have enough capabilities to cover a traditional SIEM, or they may be a traditional SIEM in that case. So it's interesting what you brought up, like the how the sausage is made with an MDR. I've never worked for an MDR, but that's definitely something where, I think even having junior analysts and training them up, it's a hard thing to do in any case. I think having an army of SOC analysts training up a SOC analyst makes way more easy than
than having a team that's kind of doing all of security and having like maybe one or two people to train a new person. So while I'm sure it was frustrating on the MDR side, it definitely would probably be a little more frustrating on a team that may or may only have one or two people to carry the weight of training.
James Berthoty (15:17)
Well, that's even if we, you know, I don't want to focus only on Exaforce, even though they're the ones providing the podcast here. Like if I even just brought it to anyone in the AI SOC sort of category, I think what's making this so interesting is that most, the MDR framework for many years, and tell me if you've seen differently, is basically like they are reselling you all of these different tools plus their managed services on top. And so you still end up having to buy Splunk, CrowdStrike, SentinelOne, whatever, XDR, like whatever category of tools that they're reselling and then you're paying for their managed service on top of it. But I think now because there's a lot of new data architectures out there, there are some new, especially with like the AI SOC category, sort of changing the way MDRs work where like they can also function as this like sort of data platform, SOC platform, SIEM type experience that's covering also a lot of gaps on the tool side, instead of also having to bring in like now you're stuck with all these contracts for a bunch of vendors out the gate as well.
Patrick McKinney (16:21)
Yeah, exactly. Becomes, you know, we've seen the trend over time of like consolidation. We're trying to get as many features as we can into one. Then there was a trend of, I only want to buy the best in brand. So people were going back to segregated tools. And I think now with AI and essentially centralized data with AI on top, you are going to start seeing more of that consolidation. And I think it's going to be done more intelligently this time. Think without, instead of like, you know, people being like, I'm going to build a SIEM and then I'm going to throw a lightweight EDR tool on it and then a lightweight MDM tool on it. Now they're just saying, go buy what you need, ingest it into this, and then we'll put all of our detection response, AI capabilities on top of that. And I think you're exactly right. Think the way the AI SOC world is looking now, you have to have that base platform of data consumption, data lake, if you will, of security information. And then on top of that, you put the different detections, the different lenses that you can use because I think some of these SOC tools, these AI SOC tools are not just your traditional AI SOC, but some of them can be more investigation tools and like insider threat components or insider threat tooling that we may not want to go purchase on its own. We have it now as part of this AI SOC.
James Berthoty (17:37)
And that's, I wanna ask one question about AI and then, cause I don't, I'm not a huge like, you know, let's spend the next hour pontificating on LLM stuff. But I do wanna ask about something that I think has been underestim, under emphasized within the AI SOC idea, is there is a big emphasis on like cost savings and the idea that like, you don't have to hire as many analysts. But I think that what the real value is, is that when you're working, like, like, like we were talking about earlier, the MDR has,
the same problem internal SOCs do as far as like, how do you train? How do you hire? How do you scale at the level you need to? And a lot of companies infrastructures now are really complicated where you've got like a really ingrained Java apps, Kubernetes deployments across multiple regions. And like the idea that like a first semester SOC analyst is going to be able to handle like a Log4j style attack in real time and understand what's happening I think is really limited. And so to me, the value in the AI is actually in like the quality of the investigation because it's not limited by, like there's plenty, like if you have a C++ incident, I'm not your guy. Like I can mess with some other AppSec stuff. But that's, I'm wondering if since you're using some of these tools, have you seen the results, not just from like a time savings perspective, but from like an analysis quality baseline perspective go up?
Patrick McKinney (18:38)
Yeah.
Yeah, I think you're exactly right. Think, you know, in terms of using the actual AI on a day-to-day basis, it's very much the investigations part and being able to query data quickly and in mass is really the game changer. I think at the end of the day, too, the human element and we believe at Invisible that humans in the loop is an absolute necessity right now to AI being adopted. So having humans in the loop from a SOC perspective is something that we expect.
And you know, baselining the behavior to train the AI is a human ability to do that. We work with our, we work with Exaforce when we're working with them to get this baseline behavior kind of tuned is we work with the humans to do that. And then when it comes to, I need to look this stuff up, we absolutely go to the Exabot and we say, hey, can you query all these things? Give me the last 10,000 entries of this, that, and the other. And it pulls it back and you know, a couple.
Couple minutes, let alone, you ask human to do that. It's going to take him probably about closer to 10, 15 minutes to at least get you a minimal answer. So yeah.
James Berthoty (19:53)
Well, to me, that goes to the heart of the MDR conflict. The MDR was very good about having an open relationship with the customer. That was one of the primary points where you had access to the logs, you had access to the queries, you had access to the analyst tickets. But there's a lot of MDRs out there that are total black box where you just get an alert and you have no ability to see any of the raw logs themselves. Typically, because on their backend, they're more like... managing their own Elastic Stack or something that has all of the customer data in it so they don't have a way to give that to customers in an easy way. But I think it's another benefit here of the AI SOC product plus MDR experience is that you have that same open experience where it's not like you're getting some alert handed to you and then there's no follow-up you can do.
Patrick McKinney (20:45)
Yeah, yeah, no, I think you're right. I think the black box worlds are going away as much as they are. I we've been very candid and very open with our company. Think seeing an MDR as an extension of your security, they have to know all the things and we need to know what they're doing so that we can make sure that not only are they doing what we need them to do, but that we can compensate on our side for what they're not doing. And that's not a bad thing. Mean, no one tool is going to do everything. We need to make sure that
If there's other gaps in what we are looking for for an overall program, and then we just take what they're doing and say, OK, these gaps are met, now let's go do the rest of it on our side. That's kind of the partnership that we're looking for now with AI tools across the board, because AI is obviously more than just MDR SOCs, but across the board with security tools that are implementing AI.
James Berthoty (21:36)
Well, let's, let me, now that we've gone down there, let me back up again to more of this like mapping out of security operations, like how you're building a program. I think the first major decision is, and I'm curious if you've ever seen like the open source decision where it's like, you either are gonna start going down this MDR SIEM path, or you're gonna try to build like an ELK stack in house, or like use Wazuh and Security Onion and like all these different like hacky open source type solutions. And I'm curious, if you've had any experience with like seeing those decisions like in the long run, how they've worked out and, and yet.
Patrick McKinney (22:14)
Yeah, so I have. And I think the main thing that people forget, some people forget, not the ones that are in the trenches, is that there's operational overhead with open source tooling. And there's still a cost to it, obviously, hosting. You have compute costs and things like that in AWS and GCP. And you're underlying your support costs across the board if you're into paying for those. So contrary to popular belief, open source is not always free.
But I think when you actually map out the cost of SaaS versus open source and you start saying, if you come in and you're a first security hire or you're one of the first two, I think it really needs to, you're not only looking at a budget from a money perspective, you need to look at a budget from a time perspective. And your time in a day is finite, even if you work 15 hours a day, like you have a finite amount of time, you have to not only do SecOps, but you also have to do sec innovation. You have to build that program out. So if you have two people and you're running four open source tools, and that's taken up eight to 10 hours of your day to maintain and do operations on those, then you're not giving yourself much time to build the program out. So I absolutely think there's a trade-off to both. Paying for SaaS tools, it's easier to spin up. You just integrate them in, and boom, we can start working with them. They'll do a lot of things automation-wise that will help you out, but there's a money cost to them. Probably a cheaper but still non-zero amount of cost is doing the open source, but also you have the operation overhead, you have your time to budget. I think folks that are going into, if you're gonna become a first or second or third security hire at a company, I think you need to honestly look at your budget from your time as well as your money aspect and really make that trade off and that balance.
James Berthoty (23:57)
Yeah, I think something that I've seen the most often is typically when open source is chosen, there's like a particular engineer who is particularly strong at a specific thing and they manage to deploy it and manage it like no problem. And it's actually a good thing for the business. It's saving money and it's legitimately good. But then when they leave, it's like a slow, like one to five year process before like a new hire comes in who is usually in a more mature place to say like, this isn't working for our team, it's too out of date, we can't fix it, we need to decommission this and just go with a vendor. And I think that's, the thing that I think I would advise the CISOs is like to keep in mind the like blind spot that you're getting because engineers tend to pick the open source things that they feel the best at, right? Like I could go orchestrate an open source DevSecOps pipeline because like that's the thing I'm the best at that I feel the most comfortable with. But then you would end up with this massive like, real time visibility blind spot and just like instead have this obsession over like pipeline stuff. Yeah, that's kind of how I break it up.
Patrick McKinney (24:57)
Hmm.
Yeah, think when it comes to something that I've been trying to practice and one of my mentors had taught me to do this, you know, back when I was at Salesforce is like, you have to forecast and not just forecast spend, not just forecast, you know, resource bandwidth, but you have to forecast, like you said, turnover, what that's going to do to your landscape, making sure that anybody who comes into the environment can learn your environment relatively quickly or with less friction. So building an environment that, you know, isn't every best piece of technology that you could possibly have, but it becomes more, I can move pieces in and out of my organization. And as they come in, they can learn this very quickly, pick it up, so we don't have that six month onboarding lead time. You could have maybe a two to three month onboarding lead time and things like that. So I try to focus on that, obviously with security.
Especially running a security organization, you get a lot of things coming at you sideways fairly often and you have to adapt to that. So when you actually get a chance to breathe and sit down and look at your program overall, okay, where are the points where if somebody on my team were to win the lottery and not be here tomorrow and I have to put somebody in their place, what's going to be hard for them? Where are we lacking documentation? Where do we need to actually have our vendor help us with better onboarding for the tool? Because now that we're all onboarded, we haven't thought about that. But the minute you bring somebody else on, what's the onboarding look like for your tool? And giving that feedback to vendors is, I think, very important, but also keeping your own documentation, things like that, is very important.
James Berthoty (26:41)
Yeah, I think there's definitely a layer of like just from friends that I still have at prior companies. I feel like there are some like James projects lurking in the shadows at some of my former employers, but then like ultimately they do get taken over typically by a more scalable effort that's there. And so I want to talk about I think the next major decision that someone makes because I think a lot of mid-sized companies feel pretty compelled into that MDR route or doing some sort of lightweight internal SecOps program like.
When do you think is the next decision point of like, do we need to build a stronger internal program? And then like, do you phase off the MDR as you grow in maturity of your internal program? Or do you just continue to like build more of like a partnership together as you're building it over time?
Patrick McKinney (27:28)
Yeah, think when you're making that decision to off-board SaaS, build in-house, or off-board managed services and hire in-house, I think there needs to be some sort of financial look, obviously, like, you know, is my spend with this MDR pretty consistent? Are we only going up 10% every year versus what's the jump to pull in-house and hire around the world at a quality which you're still getting from that MDR? And I think that
The other thing is what severity or high level of data that you're bringing in from customers that you want to make sure is not going out? Do you have any contractual obligations to where you cannot have an MDR as you're compensating security team or tooling? Believe it or not, we've actually had a customer contract say like, originally like we won't allow this, this and the other at a previous company I was at and we had to say, okay, well, you know, we either have to staff a small SOC in house because our MDR SOC at that company was absolutely like, you know, basically an extension of our security team or we can't have the contract. At the end of the day, we basically, we staffed a small SOC to handle just that one customer, but also compliment the MDR. So now we had an in-house SOC and an MDR SOC. I think it's going to be different for every company. Think as long as you're not consistently going up 50% year over year with your MDR, I think it's one of those things that's going to probably stay with you the longest because it is such a big jump to do that in-house as compared to what you're already paying an MDR and the fact that you can put that forecast model and you can forecast your spend with an MDR for probably the next X amount of years. Mean, knowing if you have a 10% ramp every year and that's your 10% ramp, you know your ramp for the next 10 years if you stay with them.
And bringing in-house, it's one of those, you not only now have to bring in the hiring, but you have to bring in a leader of that function. Leaders of those functions are obviously more expensive than just analysts. So you have to have somebody to lead it, you have operational overhead. And then with that also comes what tooling gaps do we now have to fill internally that the MDR was filling for us? So like you said, Splunk licenses are no joke. If you end up leaving your MDR and they had a SIEM or SIEM-like capabilities that was good enough and now you gotta go buy a SIEM, you know, even the Panthers of the world now are starting to become pricey. Yeah, think that's the inflection point definitely has to be, are you ready to absorb that cost and operational overhead to do this? But, also, but noting what it gains you in terms of being able to house your data and house your customers data internally and not have to worry about any sort of third party call out.
James Berthoty (30:07)
Yeah, this is typically when I've done this transition, it's been an organic experience. And I'm just wondering if you think this is actually good that this happened or if this is like just like what happens at organizations where both from an MDR perspective and just from like an MSP perspective, I've often come in as like the person who works with the MDR for a little bit and then identify like, they're actually like not providing a lot of value here.
And then slowly transitioning to an in-house team to run it. And I do think there are good, strong MSP/MDR providers out there. That's just been how it's worked out where I think when you get someone who's really strong in the role and feels comfortable with the tools, has connections to make strong hires in-house for some of these things, that's the trend that happens with organizations. Do you think that that ends up being like a good transition period or strategy or is that sort of like short-sighted?
Patrick McKinney (31:10)
Yeah, I mean, I think it absolutely could be a great thing for a company. Think when you like you said, if you find somebody who's in that space that has the notoriety and can bring in those hires that are strong, they can bring in SOC analysts at all levels that are very, very strong. The other thing you get when you bring in-house, you now have an internal employee that can be closer to the business side. So if the business says, hey, we're going to go, we're going to start selling to a FinTech, you know, the FinTech world or to the healthcare world, that brings new challenges. And yes, you can communicate that with your MDR and your MDR probably has general playbooks for dealing with healthcare data or with financial technology data or with financial technology executives should something arise. Like they probably have general runbooks, but having an in-house leader to tailor that experience based on the company to your customers, I think it absolutely is a smart play when it's needed.
And I think that will be the next evolution of the MDR. It's like, we're getting AI to make the tooling better and to level up the AI SOC analysts. Now it seems like, well, let's make this a boutique curated experience based on your customer profiles, your sales pipelines, what industries you're going into. And let's make sure we can be there as a compliment to the CISO when he has to talk to the customers or to your SecEng, SecOps teams when they have to defend against things.
James Berthoty (32:34)
Yeah, and let me now bring to just some future-oriented trends. Since you guys are using an AI SOC tool and have some familiarity with the options there, what do you think about the general trends and the future of the security operations space just from a tooling perspective? From my perspective, we just have a lot of these tools that have been around forever. And the hard part of getting off of them is that they're the industry standard. Like there are people whose entire careers are managing CrowdStrike and Splunk. It's very easy skill set to hire for and to scale. Like those are the pros, but like they've also just been around for a long time. So I'm just curious how you're viewing like if there's evolutions happening as far as tooling, like we see a lot of data pipeline type tools out there, like detection engineering tools that sort of sit separately from there and sort of like try to augment that core experience or just how you're how you're seeing like if the security stack in the SOC is changing.
Patrick McKinney (33:36)
Yeah, absolutely. And it's great because I get to work with, I get to talk to a lot of different companies that are coming up in the world of security tooling and seeing what they're doing. I think with the invention of Cursor and Claude Code and all these things, you're going to start seeing incumbents come into this space very, very quickly. And you're going to start seeing a lot of your legacy staples, staple tooling that's been around. You're going to start seeing it get challenged. Think a lot of people are kind of fed up with some of the crazy expenses that are coming with the tools that you have to have, the Splunks, the Oktas, the CrowdStrikes. So I think you're going to start seeing newer companies come on board that are building from scratch and build better because a lot of these legacy companies either have to acquire, integrate or rebuild the AI functionality into their systems. And it may not go as smoothly as planned. But yeah, to your
To what you were saying, we employ a mix of the legacy world and a mix of the new age world here at Invisible and we're trying always to keep our eye on what's coming up. I'm not against talking to a Series A company and bringing their tooling in if it looks like it's gonna be great and it's gonna really, really help us, it's gonna up level and the stuff that they're competing against is kinda like, yeah, it's been there in the market for a while but they're not really giving us much more and the price is 5X.
And so I think you're seeing a lot of AppSec tooling that's coming along right now where they're trying to build agents to cut the code for you and put it into your CI/CD pipeline. Most CISOs will not let it auto push you. Obviously, you have to have a human in the loop to review that code and make sure it's not gonna break anything. I think you're trying to see a lot more. And every time that I advise a company or I talk to a company, I think the best way to sell the CISOs, and I think it's also a trend that you're gonna see with a lot of new tooling, is save headcount, save time. We don't want to not hire. That's not the goal is to not hire, but it is to grow lean as possible. We're in a, not to get too high level, we're in a world now where layoffs are becoming the norm. So we want to grow as lean as possible so we don't have to lay off. And using AI tooling and really helping people have those superpowers with tooling is something that I think is really important to that not having layoffs and things like that. So I think that the trend with tooling right now and the catch up trend with legacy tooling is they're trying to, the legacy tooling is actually trying to catch up to what's now being built because what's being built is great and it's cool and it's helpful, it's helpful, it's lean and it's cheap. Obviously they don't have the years and years and years of hardening experience and trust gaining experience and profile that these companies have, but what's out there is really great. And I think these legacy tools are gonna have to catch up with that, they're either gonna have to re-architect some things or they're going to have to just admit to themselves internally that this product is going to die if we don't adapt to the new age of AI and really go back and rethink things.
James Berthoty (36:29)
Yeah, I think even more than the cost saving piece, like something that I've just experienced is that typically in security, it's hard because there's so much demand for the skill set that's always the rarest, right? Like right now, the greatest security need is companies are rushing to deploy AI and they want like security experts to do AI. We saw this with cloud, we saw this with AppSec, like, and it's not that like,
like they're just hard roles to hire for in general. Like I've worked at places where we've had a job role posted for like a year and it's just been because there's like no applications because the skillset is so niche that we're like looking for on that front. And so even more than just like, we saving like junior analysts sort of head count? It's much more like, how do we even, how does a mid-market size company attract an AI security expert when the AI companies that are incredibly well funded are offering, you know, million dollar plus packages to everyone that's around them in the vicinity. And so to me, just look at it as like also, like there's a corollary to like a lot of the CNAPP industry was basically like, how do we democratize cloud security expertise so that other organizations can get it when the skillset was relatively new? And I think there's a similar thing happening here where a lot of the skillset for AI and application is just so niche.
Especially on the runtime side, that like that's really the opportunity from an operations perspective. So I do want to ask too, how you're thinking about, and this is sort of out there, but I think the way that application runtime context has gotten more essential to businesses as far as like doing things like fraud detection, exploitation detection, but that skill set has seemed so foreign to traditional security operations professionals where it's like.
Managing Windows alerts on laptops, for example, like how are you trying to be forward thinking in terms of like building that runtime orientation to handle like the evolving AI cloud application stack?
Patrick McKinney (38:36)
Yeah, I'm not ashamed to say this, that I consult with MSPs. Consult with managed service providers and security firms that are staying on the cutting edge of this stuff. I will absolutely bring them in to assess our environments. I will bring them in to consult and say, hey, are we doing the right thing? I'm not going to pretend I know it all. I don't think there's a single CISO or head of security that knows everything. And so think having those people, huh?
James Berthoty (39:02)
That'd be the dangerous one.
The dangerous one would be the one saying like, yes, I don't need that.
Patrick McKinney (39:06)
The dangerous one, exactly, exactly.
Yeah, so having those, having a mix of tooling and managed service providers that you trust to come in and give you that expertise and that lends into your environment, I think is incredibly crucial. We're working on building a lot of different things with regards to runtime across the board. Fraud's something that we have a dedicated function to. We're also looking at things like AI red teaming around biasness and prompt injection and all the stuff that comes with AI. Once again, you're right, AI security experts that you can hire dedicated to that is hard, but there's tooling out there that they're developing to try, like you say, and democratize the ability to do a lot of these things and give you as much coverage as you possibly can with like 90% confidence. Maybe, is it 100% confidence? Most people won't ever say that because they'll be legally obligated to uphold that. I think building, like you said, the tooling out to democratize the functionality. Bringing in a really trusted confidence in the MSP world, and then also just constantly reassessing your program and making sure you're covering these areas is the high level way that I would tackle this.
James Berthoty (40:16)
When I think I want to wrap up with this as far as like the thing you just hinted on is something that I've always found to be an interesting thing within security where there's this like radical love hate vendor thing where so much of the work we do is totally dependent on vendors because it's like they're the ones like an MDR provider who is seeing alerts across thousands of companies is the only one that can put out an alert saying like, hey, there's a major threat campaign happening against the retail sector or something.
Like they're the only ones who can do it. But at the same time, like security has a well-known, like we're so tired of vendors, they're selling snake oil, they're selling FUD. And so like, what's the way to like open a CISO's heart and wallet when it comes to like falling in one category or the other of like a loved partner versus like a hated over it vendor.
Patrick McKinney (40:46)
Don't think you'll ever fall into one category blindly. Think there's definitely going to be those sales folks, those marketing folks that are overly aggressive in your LinkedIn DMs that, you know, if you don't respond to 10 DMs, the 11th DM is not going to make it, you know. But I think white papers really go a long way with me and my team. Think showing that you've gone down the technical route and documented and shown proof that your product is actually working is incredible. Showing POC value in ROI quickly. I don't think every tool needs to be ROI in five minutes, but ROI in 20 days, 15 days is still really great. And just don't over promise. Don't over promise. Don't tell me that if I buy you, I don't have to worry about other things. Don't ever tell us CISOs don't have to worry. We've worried since we were kids. That's what put us into this role to begin with.
But I think, yeah, just doing the due diligence of documenting everything and white papering as much as you possibly can around your tool. I get impressed when people have multiple white papers that stand up to the sniff test. And provided they can integrate with our environment and provide value within a normal amount of time, that's a high level on how you're gonna get my business.
James Berthoty (42:28)
Yep, well, thank you so much for your time today. I really appreciate all of the insights across all of that stuff. Hopefully now anyone listening to this, whether they're big companies, small companies, starting, mid-level, or advanced in their journey knows sort of what's going on and where to take it. So thank you so much.
Patrick McKinney (42:31)
Yeah, absolutely.
Absolutely happy to be here. Thanks for having me.
