Sullivan Tuck 0:00

Welcome to Conversations with CISOs, Security Leaders, and Technology Executives, where we sit down with a leader shaping cybersecurity in enterprise technology. Today I'm joined by Kenneth Foster to discuss Build, Buy, or Partner, Making Better Security Capability Decisions. Ken, thank you for taking the time to join me today. To get us started, could you introduce yourself and tell us a little bit about your background and your current role?

Kenneth Foster 0:22

Yeah, so Ken Foster, I've been in the technology space for a little over thirty years. Started out before we called it cybersecurity in the mid-90s while I was still in the US Navy. And then have worked at a variety of verticals and different size companies over the last thirty years, either as a CISO, a GRC leader, a deputy CISO, an engineer. I've ran IT and infrastructure. So I kind of bring a varied background to the space, you know, today I'm working for ICM Cyber. I'm the VP of engineering and professional services and strategic advisory. You know, so I get to sit down now, I get to sit down and talk with my peers, which I was doing anyway, but now I do it as a full time job, and get to talk about strategy and dealing with the problems we've been dealing with, specifically like we're gonna be talking about today, is get through the real question of what works, what doesn't work, what gotchas I've ran into over the years, what gotchas that I've talked to people about, and try to help guide people into a better strategic discussion and a better roadmap to fill their gaps.

Sullivan Tuck 1:35

Excellent. So as you said, you've led security from both inside large organizations and now you help organizations build security capabilities. So when a leader is deciding whether to build, buy, or partner, where do you tell them to start?

Kenneth Foster 1:47

So I think the real thing is almost all these conversations kind of start in the wrong area, right? They're like, we got all these capabilities we need to build and we can build all these capabilities and you're like. That's the wrong place to start. Right? It's when what happens in the second year? What happens after we build it? Right? 'Cause that's typically the question I'm telling everybody right now. Yes, in the last five years you can now build faster and probably lower cost than it's going to be to buy a product, right? The cost of build has come down. The cost of buying has not really come down much, right? So the problem is if you don't think about year two, who owns it and specifically who owns that, you know, what's the budget in the over time because you're you have to budget about twenty to thirty percent of that build cost in the initial build to maintain the product over time. And then, you know, if you can't have an owner and fund it over the over that period of time, then your build has an expiration date and it's going to die. So the real question is, is how are you going to maintain this over time? Right? It's the easy question is you're hearing a lot of people, I can just build that, it's easier and it's cheaper. Well, they're a hundred percent correct. It is easier and cheaper to build today. But that year two, year three and hell it isn't even year two or year three now with the rate of change. It's actually six, eight, twelve months down the road, am I gonna have turnover on who built this? Do I have the capability of keeping up with the APIs as they change? Do I have capability of keeping up with schema drift? All of these things have to go into that question. And if you're not going into that do I build or do I buy conversation with all that in mind, you should never you're not ready to build. This just what it is. You're not ready to build. Right? So

Sullivan Tuck 3:54

Hm. So when leaders are evaluating a new security capability, what is a framework or criteria that they should use to decide whether they should build it internally, buy as a product or address through a trusted partner?

Kenneth Foster 4:07

So I think there's a couple very simple things you can think about. Now you can get very detailed in this side of it. You can get way deep into the frameworks, whether you're regulated, unregulated, you're in a sensitive data environment, you're in a manufacturing environment, you're in a tech environment, right? But I think simply you can get it down to about three questions, maybe a fourth one if you want on there, right? Kind of call it the fingerprint test, you know, is this built for something truly inside my walls? Is it custom to me? And is it going to is the business logic something that could be abused? What is my control planes or acquisitions I've got planned and stuff going to do that? So does it, is it going to be something that is specifically fingerprinted to me, or is it just a generic? And this more the this also goes on both sides, right? Do I need it that fingerprint that's very custom to me, or can I have something that's a little more generic, it's a little more industry let's call it industry specific, and that's probably coming from a partner more than it is from a from buying a product. But if I'm building or having a partner build it for me, you know, how custom is this to my environment, right? So that's probably the first thing you want to have a conversation about. And go, you know, are you paying a premium to reinvent something that's pretty much a commodity now? Right? I'm gonna use data tagging and classification as a great example, right? There's a ton of people who are doing that now. I consider that a commodity thing. Can I build it internally with today's AI tools and coding? Absolutely. Question is, is what again you got to go back to that first question. Yes, I can initially build it cheaper than buying, but do I have the capability to keep it maintained over time? And am I going to lose that talent at some part? And as things change, can I keep up on that that thing on that process, can I keep it moving forward and keep it running operationally and not broke. I heard a great line one time it says, don't fall in love with the agent you built today. Because more than likely within twelve months it'll be quietly broken or completely non-functional. So you have to be willing to give your baby up, right? And and move forward. Kinda test two is who owns the tempo of change? Is it you that wants to control the change or are you buying a product that's going to change rapidly and can you survive that change? Right? Because we've all been, especially if you're using a shared SaaS model, right, where the underlying infrastructure is going to get updated at a regular pace and you don't control that. Have you built so much custom stuff in or had so much custom tweaking that when that change happens, it's either going to break your product or your environment or you're left vulnerable because you can't move forward because of that and you're having to ask for exceptions to keep yourself on an old version. We've been all going through that for years on that shared SaaS model. So it's the same thing as you're building and buying this, right? Is how are we going to control the update pace? And how prepared are we to keep up with the pace that of today on how fast we need to keep it up to date and keep it moving. You know, and then the simpler one is who gets called at two AM? Who's taking that call, right? Depending on what gets broken. Who's is it in some way of are we staffed internally to take that call and to be able to fix it that quick is our partner staffed to do that? And that's always a question you should be asking your vendors if you're buying it, is if I have a major problem at two AM in the morning, who do I contact? Who is my point of contact? So you're not really getting away from that basic argument about owning a product is who gets that phone call? And then you know, I think the other thing is then what's your motive? Why did we build this? You know because procurement takes nine months, that's probably not the right answer. You know, or a vendor won't return our calls, or we think we're smarter than the vendor. You know, those are all things that happen sometimes when we're like, we'll just build it. These people don't understand us and we'll just build it. I would argue anytime you have a conversation with a partner or a vendor, or your internal teams that have to support each other, and they go, we'll just build it because nobody understands what we're doing. One, I would argue your not clearing your expectations and your requirements you're not doing a good job of building out use cases you're not doing a great job of laying out what are your must-haves not setting expectations and deliverable timelines correctly. You know and then let's be honest in any enterprise any larger company there's going to be so many internal politics and internal gotchas on this not only if you're building it yourself or you're having a partner help you or you're buying a product. I've seen so many products that get bad reps with companies has nothing to do with the product. It has to do with that just what I went back to nobody being very clear about what the motive is, why they're doing it. They haven't cleared it with all the other internal pieces that are going to all have to get together, right, to mesh that stuff together. Like, if you're relying on the identity team that doesn't belong with security, if you're relying on the

Kenneth Foster 9:48

network access team that may not be part of security. You're reliant on a business application team, an HR team, you know, all across the board. Everybody has to be together. Same thing has to happen if you're building. So those relationships really matter, and I think there's been a lot of product that has gotten bad names, not because the product doesn't work. Now, they're definitely product that gets oversold especially in today's world, right? We've got a lot of things on the market that their marketing has outrun their capabilities or their roadmap greatly. But there's also on the other side of it, if I'm the CISO and my team, are we clear? Have we been clear and communicating our expectations on what we expect this thing to deliver at the end? And again, this a broad problem in the AI world right now. Everybody wants to use AI or has been told they have to be using AI, but normally one of my questions to them is, what do you expect it to do? And rarely do I get a good answer. I get, we don't know yet. We're just gonna we're just gonna see what happens,

Sullivan Tuck 11:00

We need to put it on the website.

Kenneth Foster 11:00

right? We're gonna put it on the website or internally it's like we're gonna throw out a bunch of stuff to people and see if somebody builds something really cool. Well if there's no clear expectations and no clear outcomes for that, to me it's just churn. That now you've, not only is the business churning, the security teams are churning, your infrastructure teams are churning, it's just this massive amount of churn for very, very little return on investment because nobody actually knows what they want it to do. And then we're still pretty immature in this agent world of today and understanding what the agents are actually capable of, what it really takes to maintain that infrastructure, and then the big gotcha today is how much does it actually cost to run it? Whether I'm running it on a partner or vendors environment or if I'm running it on my own internal environment, what's the actual cost of this? Tokenomics is is a tokenomics has become a real surprise for a lot of people.

Sullivan Tuck 12:04

So to piggyback on the being clear from a security side about what capabilities you require, where have you seen both from your previous experience in security and now from the vendor side, where do people tend to be least clear when they're making these decisions?

Kenneth Foster 12:20

I think there's a there's a real hard conversation to have sometimes when you're talking with teams and they've got a pie in the sky, we want all these things. And you go, okay, well there may be five technologies, may even be ten or more, that do the basic things you want to. The real trick is setting down and asking the deeper questions. If this then, right? If if you want to move data from point A to point B and you want all these rule sets around it and what's the feedback loop on it, what's the reporting? How are you going to govern it? How are you going to make sure it's doing the right thing? How how are you going to govern change management? How are you going to understand how your identities are you prepared for the drift that is going to happen? Not only in your schema, in your environment, if you're connecting to external APIs or using MCP servers, what is going to happen as those drift over time. I mean, we all know every API changes eventually, right? They're going to have changes as they move. And if you're not in the weeds asking those questions and prepared, you should go into a meeting with your team if you're building, your partner if they're helping you, or the product that you're buying, and whether that's through the product, it's the OEM itself or through a partner that you're buying through, you should work with them and they should be working with you especially that's my point of view with the partners is they should be working with you to develop what good looks like. What is success if we're gonna do it and you should always do a POV, right? you know, no offense to any OEM on the market, but I've heard, it only takes two hours to set it up and get it running so many times and then it never runs. It takes months of work to get it. And most of them also don't understand a lot of times for me to do a POV, especially if it requires identity access, it requires network access, it requires data access. That's the same as me buying it from an internal process when I'm sitting on the customer side. So I need to be able going into it and understand this is not going to be a three hour flip a switch, I'm gonna start sending you data and you're going to do all this magic stuff for me. So we need to be honest and transparent on both sides. Me as a CISO and my team need to be very clear on what our use cases are, what we're trying to accomplish, what it's going to take to actually make this, because you know, if you've got to connect into our identity system and we're a regulated industry, what are the requirements and how long is that going to take? Hey, if I gotta make a change on the endpoint, did I have the desktop team involved? Right? Or did was this security doing something in a vacuum? Right? If I need to connect into one of our hell if I can need to connect into Salesforce to get data out of it. Have I involved the Salesforce team? Have I involved those guys to bring it in? I may have to get legal involved. I'm you know, I'm definitely gonna have to get legal involved, but I'm gonna have to get legal involved. I'm gonna have to have all these people involved. Is everybody clear on what we're trying to accomplish? There's so many times that this thing goes sideways because none of that was discussed in the initial thing. And I put that on both sides. The partners and the OEMs are not asking those questions, and the CISO internal teams are not forthcoming with these are all the steps it's going to take to make this happen and then what does good look like like I said having a clear having a clear set of expectations for what we expect out of a POV and what how does it align how are we going to measure that use case that we've laid out so let's have a defined set of use cases. Let's say what means successful with that use case, what means not successful with that use case.

Sullivan Tuck 16:11

So from the partnership side, when an organization decides that partnership is the right approach, what should they expect from their partner? What should they expect them to leave behind after the engagement?

Kenneth Foster 16:20

I think a lot of what we just talked about, right, is making sure all these expectations and from a partner standpoint be we should be asking you the questions that you didn't ask. Cause then hopefully as a partner, they've seen enough of these implementations at enough different customers and they or and enough in your vertical or your thing. Now it's everybody's gonna be a little unique, right? That's that's the one thing about big companies or even small companies. Everybody is kind of their own unique snowflake, right? Because there's little nuances to the way everybody's environments are configured and how they're doing stuff. But it's it's our job as partners, to make sure we're making you aware of the things you haven't asked and the things that you may have forgotten about. It's a big part of why I took this role, is because sitting in that seat for so long and watching stuff flail and learning over time is like, we forgot to ask this, or this good partner did this, and this bad partner did this, or the OEMs who always oversell typically oversell their capabilities. Ha ha. If you tell me you can build a new custom connector in two weeks you better be able to deliver on two weeks and not twelve weeks later we're going what happened to the two week window right so and that's where your partner can also help because they can re they should be researching all this technology and have a good understanding of the breadth the capabilities of all the technologies that if you're looking at a single technology they should be able to give you based on your use cases based on on all of the people who are saying they're playing in this area, they should be able to come back to you and agnostically give you the data and say, based on your use cases and what we've seen pre POV, these are the two or three I would probably focus on and get rid of the other fifteen that are in the area because they just don't meet they don't meet half your requirements, right? And it takes a lot of reading of documentation. It takes a lot of effort. And you know, but the thing, truth is, is over the years I've been doing a lot of that anyway, so I've kind of kept a data my I have my own personal database that I keep up, which is the value I think I'm bringing from that discussion is I can help you look at a lot of technology and go, well, I've installed that one, I've implemented it, I turned that one down, or I've got a friend who went through a horror story with this one, or I've gotten some that have said this was the best thing I've ever bought. It did everything they said they could do. It hit all the right marks. We were able to get it deployed with no issues. But most of the time when that second conversation happens, they did that legwork up front or their partner did that legwork up front in conjunction with them to get all those questions answered right and then you should be having regular touch points with your partner. It should never be a sell you a widget sell you a thing and then you never hear from them again until it's renewal time. They should be helping you go down the road. And depending on how you build that partnership out, granted, there's probably going to be some cost associated with that. If you want more care and feeding over the road, right? Because you may be buying a bucket of hours where they come in and help you tune and help you move that along. And I think sometimes that's where the real differentiation between build or buy, right? Because even if a partner's helping you build or helping you buy, them having the expertise to be the long term touch point personal relationship that they can come in and help you tweak it and tune it over time and if the schema changes or if an API changes, they can quickly come in and augment your team in a way that allows you to take advantage of that cost reduction that you did up front on maybe building it yourself, but can be that staff augmentation and it's not really staff, but it's the kind of that white glove service so to speak down the road and go all right we can drop a person in and help you get past this and help you maintain year two, year three and make sure that you're staying on top of the latest technology. Right? And again, like I said, don't get married to your don't get married to your agent or your model because they're changing too fast right now. So you know and again I think it's I think a partner who will deliver bad news to you and tell you what you don't want to hear sometimes if you've got a partner who has a good if you've got if you really want to take advantage of a partner sometimes they're the sounding board that's going to tell you your baby's ugly and this is why your baby's ugly and this why you Ha ha. keep running into this problem. Let's discuss let's discuss how to make that better and what are the roadblocks that are keeping you from being better because I've seen a lot of relationships and partnerships get ruined over the years because it's a transactional relationship, it's not that real relationship. And I think if you've spent enough time building the relationship, you both know each other's capabilities, you both start to learn each other's environments, you both understand how each other look at things. And sometimes you just need to be the voice of reason and the voice of honesty. And if you can get to that relationship level, it becomes a very good partnership over a long run. And then you can, you know, now you've built that trusted relationship where hey my job as a partner is to make you look good. That's what I always told the partners I was working with. Your job's to make me look good because I don't have the resources and the time to deal with this. That's why I hired you. Right? That's why I brought you in. Because I last thing I want to be doing standing in front of the board explaining why a project or a big bucket of money I spent didn't go. Right? And if it ultimately comes out that the reason it didn't go well was because I didn't do my job and my due diligence up front as the CISO or the somebody on the security team, we didn't ask the right questions, and then it comes to light that we didn't ask the right questions, well that makes us look really bad. 'Cause it makes us look like we don't know what we're doing. Now, and you know, so I think that's a thing. Again, I'm gonna go back to clear deliverables, clear handoffs, clear transfers of responsibilities, regular touch points. And those touch points don't have to be anything official, although you know, a nice QBR is great, but you I should you shouldn't only hear from me at QBRs, renewal times, or when it's hit the fan. I should be just every now and then reaching out to you and go, hey, how's everything going? Any any new projects, right? Or or how is this project going? Have you run into anything that we didn't see or are there things that are starting to worry you? So we can be proactive, right? Because there's you're not going to close every gap. You build it, buy it, partner, you're never going to close every gap. I like to say this, as a CISO I always operated with more risk than I was comfortable with because I had to. Right? Because if I to get to the risk level that I'm comfortable with, I've probably broken the revenue generating thing that the company does. Right? So there's

Sullivan Tuck 23:57

Probably. I had a guest the other day say no no CISO buys based on risk, they buy based on the budget that they have. Because otherwise you would use

Kenneth Foster 24:06

There's a there is a part of that but there is a there's a there's also an I think the part of that is missing and it's a great quote but I think the part of that is missing is I will reduce risk to the point that the budget allows me to. Right?

Sullivan Tuck 24:20

Right, yes.

Kenneth Foster 24:21

So now that becomes a prioritization discussion with the board and everybody else and go, Well, we got ten problems. You've given me a budget that I can fix two and these are the most important ones. So you just have to understand, I'm still gonna have eight things that are a problem. That I am going to come back to you later in the year and ask for more budget. And I want you to be I want everybody to be clear, if something happens because of those eight things that we haven't taken care of, we were all aware of it. Nobody can come back and say we did not know that that existed. Because nothing we do, and especially internally, should be a surprise to anybody. Right? And because you don't want to be the security leader that has somebody coming to you and go, how did you let that happen? Why didn't we do that? you know, what you can do is go back to them and go, We took we discussed this. We decided together that we didn't have the budget or the resources to attack this problem, so we only did these. These we knew existed. We've all talked about it. This why this happened. Hopefully you have a documentation and the paper trail and the discussions to allow that. You should never be afraid as a leader in security to say, hey, we have a problem. is it our number one problem? Maybe not. But making sure they're aware of that risk exists and it's illuminated and they they are clear on what that risk is and what it's going to cost to fix it is one of your most important jobs. That's where you become a that's where the CISO role really is a sales role. It's just an internal sales role. So you're selling your strategy and your plan to the board for the resources. So you get a lot of experience on selling your strategy when you're setting it those senior leadership roles.

Sullivan Tuck 26:20

So as we wrap up, shifting from outsourcing security capabilities and using partners, when do organizations know that it's time to actually bring something in and perform it internally?

Kenneth Foster 26:36

I think when it becomes boring, right? When it's gotten to a run rate that there's not a great change of there's not a great rate of change. You can write a job description around it now because you have that down, you know what the person who needs to operate it is, right? You know, you've got more business context built into it than the domain context, right? So if you've got it to the point where it's so tied into the way you run your business, like I said, and you can write a job description around it for a person to operate and maintain that, it's probably time to take it internal. Because now you understand what it's going to take to keep this operationally long time, long term, and you're probably at that point ready to staff it. And as, you know, we all hear in our world, right, AI is going to change the way we you know, a well, we hear AI's going to eliminate positions, realistically it's just gonna change what those positions do. So as we maybe take get agents to do what we expect them to do and we get them operational, now we have maybe an extra body or two that is not fully focusing on that thing all day. We can now say, Hey, now you pick up this thing we've built you're now going to be the person responsible for it operating the thing we built and keeping it up to date. So you can what you're doing, a couple things. You're upskilling your staff, you're giving them a reason to stay with you and grow within your company. Two, you're increasing your capabilities because as you automate, as you build agents to take things, you're now able to keep upskilling your staff and moving them into more important roles within the company that is very contextually driven for your business. And when you get to a really contextual driven security tooling and security processes, you become so much more effective. Right? Because now you're able to build much better, tighter alerting that has less false positives that are very accurate, that you can then build automated IR around. You can build automated things around it because you know how that thing works in your environment. You know what the context is around it. And you know, that's the stuff that I think is most important, right? And cost typically is not the right reason. Right? If you think it's cheaper, if you're just trying to bring it internal from a partner because it's gonna be cheaper, that's the wrong approach. Just you all that other stuff is the right approach. Do I truly have a program built around this that my internal team can handle and do I have the resources to assign to this full time and to keep up with? so that's one of the things I would say that's the biggest things I would say. Again, it's when it's predictable, when it becomes a, and that's why I said when it's boring. It's predictable, you know what the outcomes are gonna go, you know when you know how things are going to change over time, that's when it's probably time to move it internal. As long as you have that budget to bring that stuff on.

Sullivan Tuck 30:13

So I did want to actually ask one last question. Looking back across your career, what is one security capability that you think too many organizations try to build themselves when they really shouldn't?

Kenneth Foster 30:24

Ooh.

Kenneth Foster 30:34

That's a hard one because a lot of the stuff I've seen people try to build internally is because they thought they could just it goes back to what we were talking about. I think it's the twenty four seven detection and response, right? Because you that one is one that's very difficult to build internally. Right, but a lot of people think they can and they always underestimate the amount of people that they need to truly run a twenty four seven detection and response. Right? 'cause genuine round the clock holidays, vacations, training, sick time, competing priorities. I need a body doing this, and hey, I've seen you do this and you're smart at it. I'm gonna pluck you out of that and put you over here, right? That one is a very difficult one. I think that one gets brought in house too much thinking it's going to be this massive cost savings. And in the long term, the math is always the opposite. it's way more expensive to build that internally than it is to probably outsource to someone who can because they're not only managing you typically in that thing you're probably gonna get it depends on the size of your enterprise but most of the time they're gonna be able to spread a shift across your environment. They may have one or two people on that shift that are dedicated to you and maybe two other two or three other customers and they've spent the time building in their automation and stuff to be able to hand that off. And the second half of that is the outsource is your incident response command. Not that you shouldn't outsource and bring in really good talented at IR, but the decision layer of incident response, that should almost always be in-house, not outsourced. The reason is if you outsource it, the command that incident leader if they're outsourced is going to be making decisions that you know the ins and outs of your leadership of how that works internally. I think an incident command, incident response leader almost always has to be in sourced. Now you may hire a really good outsourced IR. You probably have one on retainer and they're going to be your hands on keyboards experts at doing something, but you're the one typically that's going to be making the decisions on whether they chase something, whether they shut a production system off, whether they cut off a customer, when do we communicate out, all that should be handled in house.

Sullivan Tuck 33:28

All right. Well thank you very much. Thank you everybody for watching. If you enjoyed this conversation, be sure to like, subscribe, and leave a comment with your thoughts or suggestions for future guests and topics. And thank you again to Ken Foster for joining us today.

Kenneth Foster 33:40

Yeah, appreciate it, Sullivan. Great to have a great conversation.