Podcast Transcript

Welcome to Cyber at the Top, a podcast from RSAC that unpacks real experiences, lessons learned, and practical strategies from CISOs at some of the world's leading organizations.

Choosing the right cybersecurity partners has become increasingly more complex as security leaders navigate crowded markets, very bold marketing claims in some cases, and rapidly evolving technologies. In today's episode, I'm joined by Tal Ahat, a leader who brings both CISO and CTO experience to the table, most recently at Carlsberg Group. He offers a practical lens on how to evaluate providers beyond the buzzwords. We'll discuss what it took for him to find out who is the right partner. How do you look for that right partner? How do you balance innovation with stability?

And how do you ensure providers truly support your security strategy after the contract is signed? Let's get started. Tal, thanks so much for being here.

Thank you for having me.

Let's start out with just just a simple question. Can you tell us a little bit more about your role at Carlsberg Group?

Sure. So my role, which...

Well, I left the company back in May. So up until that point, I was first... The first ever CISO for the company. There was a security team there, but there wasn't someone set up as a CISO. And then after two years, I was also... I also got the responsibility to run IT infrastructure, in what we call the machine shop, you know, the the part that no one ever sees. But when it's not working, you get a lot of issues. So running running the running the important part of IT as far as I'm concerned.

That's great. I mean, that... That's kind of unusual that you're running the factory, so to speak, as well as security. Right? Not a lot of people get that experience.

And and I'm curious from that perspective, why has choosing the right cybersecurity partners become so complex today? It feels like it's harder than ever.

I think there's a there's a few reasons for that. First of all, if you look at the never ending arms race between the attackers and the defenders, the...

It feels like the rhythm has become even more extreme the last few years. What's...

If you think about a few years ago where sandboxing was the very big hype. Right? The the likes of FireEye, I...

It was it was like everyone was sitting there and said, that's like science fiction, and I have to have it. It was so expensive and so innovative and so difficult to implement. And today, it's so mainstream that I don't think anyone makes that solution as a stand alone anymore. The the the thing is that you keep running not only after new attacks, but also about the defensive technologies is that what do these guys actually do?

What problem do they solve? Can I put another piece of technology in my never ending ecosystem? Is it gonna destabilize something else? Is it going to cause me issues which I'm not foreseeing right now?

So that technology...

The technological environment is becoming more and more difficult.

In parallel to that, there are so many players out there that are trying to do good, in most cases, in in cybersecurity, both in services and technology. It is becoming really difficult to differentiate between who's actually delivering, who's actually being innovative, and is actually listening to what it is you're asking them to do and which one is just trying to make a quick buck and and vanish towards the sunset. Not that it's bad doing a quick buck, but, you know, you wanna get something out of it as well as the customer.

Oh my gosh. It's so difficult, especially as somebody who's new to security. I think about the show floor, for example, at RSAC conference. You've got football field size of vendor booths. They're all over the place. You've got hundreds and hundreds of vendors.

They're they're all cloud native, AI first, you know, any buzzword you can pick.

And I'm curious, because you've got the technology experience as well as the security experience, how did that background as both CSO and CTO shape the way that you evaluate technology providers and vendors?

I think the...

I would say both advantage...

Disadvantage of managing both sides of the floor, both the security bits and the operational bits of IT makes you understand much more about the impact that the technologies are having on your wider IT organization and and the users as well and the challenges involving implementing this kind of technology. So you...

You're getting to a point where you, as a CISO, you can't just implement, you know, the latest and the the greatest in cyber technology and just tell the ops team to implement it and put the change request and and, you know, go on to your weekend. Because when you create that problem, you're gonna deal with that as well. On the other side of that one, when you're looking from the IT operations bit, you can't just, you know, when something doesn't work, just open all the firewall rules to allow all the traffic, and then you'll be done with it because you're gonna deal with the security issues coming out of that.

So the stability that is required and the wider understanding of what thing is impacting which other kind of tool that you have in your in your wider IT state that's becoming...

It complicates your life, but I think, ultimately, it makes your decision more mature.

And the company is doing better for it because it's more stable and it's more clear... Clean what it is that you are doing.

Makes total sense. And and so when you look for a potential provider or vendor, what are some of the first things that you assess to determine whether they're a good fit?

Well, I think the first and and foremost is that are they solving an issue that I actually need solving. You will be surprised how much that's not a standard thing. I've seen quite a lot of practitioners. In in many of cases, they're they're lucky because they either have the the the width of resources to actually invest in new things just because they're new, so staying ahead of the curve.

And they also have the the support in the organization to try new stuff even if they don't solve necessarily a specific thing. From my perspective, I always looked at, am I solving something that I need solving, or am I improving something in my existing estate? So it can be something out of context. So that's that's the first and foremost thing.

I think the the next thing that you do is that... And that's something that I try very, very hard to do, especially when you deal with new start ups, is you either look for references from people that you trust.

When I say people, trust someone from the industry, or you try to figure out who the the founders of the company are. And and I'm I'm talking, of course, not on the mainstream or the big players, you know, like the Palo Alto's and Microsoft's world because, you know, you you always trust what they're doing, that they know what they're doing coming, hopefully. So more of the newer companies, which are less mainstream. You will be surprised how much...

Oh, you're not surprised. How much the opinions of security practitioners can be different from all the opinions of the various analysts that you're dealing with. So, you know, all the reports you're getting about which company is doing well against which company, in most cases, they're not giving me a lot of useful information.

But when I find out if a CSOA or CSOB are working with them and I can have a conversation with them, the ad gives me a real good information about how practical it is, what kind of issues they saw, and that's a good opening for me to actually go into a further discussion with that company. I had one specific case where I I had a CISO friend calling me and running from big enterprise, and he said, I just implemented a new solution. No one ever heard about them. They're doing something outstanding. You need to talk with them. And I did, and it wasn't an outstanding solution. I ended up buying them.

And they actually sold me an issue that they know that I need solving. That was a bit of an unusual thing.

It makes a lot of sense what you say. And we actually see it in the behavior of people that go to the conference, especially folks who are decision makers inside of the business, a lot of their time is networking. They're finding others, they're trying to calibrate with them, they're asking them about vendors, or how did you solve this particular challenge?

It's such a communal thing, security, I think, based on what you're saying.

And I'm wondering, what advice would you give to somebody who's trying to sift through all the marketing noise and find real capability. You talked about talking to others, talking to peers, or evaluating the founders.

But imagine you've got a project that you have budget approved for, like a zero trust project, or we're gonna secure AI, and we're gonna bring it in house. And everybody and their cousin has those things in their description.

What what other resources can people go to, you think?

I think at least try to go into the technical discussion from a very early stage. Right? If you're sitting in the initial pitch and you have a salesperson that is giving you half an hour of size why this is important and why phishing is horrible thing and why AI is the big next thing. And, you know, the things that you've been listening for the last fifty...

Well, not fifty, but the last thirty years, then, you know, the bit...

They're they're wasting your time a little bit. And when you start asking the technical questions quite early in the pitch, and you realize based on the answers whether they actually understand what it is they're selling and they believe their solution, and whether they can go to the nitty gritty details even, you know, just for the point of interest from the...

For me and the the person or the technical people I'm bringing with me, that's a good sign for me. If it's a salesperson or sales team that have very little technical knowledge and are trying to do the normal sales pitch that we are the bestest, and we are the greatest, and, you know, you buy us. We solve everything.

It's two days to implement. You're ticking the box, and you're done. And we make you a huge amount of ROI, then that's already turning me off. Right?

Because I've heard all these things before. So it's really sifting through the marketing noise from the actual content that you need to hear. And I think the second thing, is really important, is if you can do it, go for a technical proof of concept as soon as you can. It doesn't need to be the entire company.

It doesn't need to be huge. But if you just play with the solution, even in in a closed demo environment to begin with, you get very good feeling for...

If the solution is actually doing what it's supposed to do. Of course, there's more steps on the way, and you need to see what the solution is scaling up to deal with the entire enterprise. But that's already giving you two data points which can be very useful for a decision whether you wanna go into a more deeper conversation with that group.

That's great. That makes a lot of sense. And and, you know, I'm I'm wondering just to unpack some of the early signals that you might get. Like, let's say you do this proof of concept.

You've talked to them. You've gone into the technical details early. But some of those signals that after you sign a PO, after this person, this company is an actual partner of yours, they're under contract, that they're going to be a good partner. They're going to be there in the hard times as well as the good times.

I'm sure you've developed a set of signals or things that you look for, and I'll just give you a personal example. So I've been the program chair for RSAC conference for eighteen years now, and we get, I don't know, maybe 3,000 submissions to come in from around the world. You have the short abstract and the long abstract. There is a tell always in the long abstract if it's submitted by a vendor, and they're not just trying to share knowledge, like they're actually trying to sort of sell a product, which we don't allow through this process.

The way you can tell, it's like a poker tell, is the last sentence of the long abstract. It always ends with, and we'll show you an example of an optimal solution that's been implemented to solve this problem. It's like as soon as you see that, you know. What signals do you look for from a vendor when you're evaluating them, I guess, before you sign the purchase order that they're gonna be with you for the long haul, that they've got the right security maturity, that they're aligned with how you're thinking and the problems that your company has?

I think one one thing that is quite obvious is how realistic their plan of implementation is. So, normally, when I go... Especially with with large scale programs, you ask for the implementation team to actually be present in the negotiation or in the presentation, or at least the person is gonna run the program.

And if that person is sending you...

You know, they come with a reasonable Gantt, and they said this will take us nine months. This will take us half a year. These are the steps, and this is what we need from you in order for this to succeed because this is not a one way Street, then I already feel better about it. Because you see that person is not trying to sell you fairy tales.

They're trying to really do what's right for you as a customer. On the other side of that, you have companies that say, we'll do it in three months and zero risk or very low risk. What do you need from us? Nothing.

You know, we need a steering committee of.

And, you know, after you've implemented these kind of projects for many years, you know that there's nothing is going along according to your plan ever. There's always things that will fall down. There's always gonna... Things gonna break. And and it's fine. It's part of it's part of the the the life of implementing large scale IT project. But as long as the other party does not recognize that there are going to be issues and they're ready to deal with them, that's a big warning sign for me because they're trying to look as optimal as they can, but they don't show me they can actually deal with crises.

That that that makes so much sense. So just the realism from them on... And and does it compute with you based on your experience in security? Like, does that... What this person's saying actually line up to what you actually expected?

And maybe another question along those lines, how do you ensure that a provider aligns with your organization strategy and your risk tolerance and your operating model? Because those are those are very different, you know, company to company. How do you know if there's alignment there? May... Maybe you get it out of that same process, out of the operational folks being in the room during the discussion.

I think it's that one, but it's also...

It's part of the negotiation that you do when you already signed the contract. Each company is is always trying to make lives easy for itself. And for me as a customer, I can't allow a third party provider to bring their own operational model to overlay that on top of mine. Because by the end of it, I need to be able to keep an eye on stability, on resiliency, to report to my management how things going, and I can't use another reporting system.

So from my perspective, I need to be able for them to liaise to whatever system I have in place in terms of service calls, in terms of the definitions of what an incident is, in terms of SLAs, and that's something I have to negotiate. There's always room to move left and right a little bit. Right? Because I can't force them completely to give up on what it is they they need to do, but they have to align somehow to my...

I don't wanna say values because it's not values, but let's call it my IT core values in order to operate.

In terms of alignment to, strategy and culture, I think something that works really is that you actually open up and you talk with them. As soon as all the NDAs are signed, everything is ready, you need to treat them as a partner, not as a supplier. So that means you tell them what it is you are about to do in the next six months. You tell them how they can, help you with that one.

You tell them whether they see any kind of risks to their service or maybe even to the wider services. And, of course, these kind of relationship, the the bigger the scope of that vendor, then the bigger the conversation is going to be. If I have a vendor that's doing something relatively niche, of course, I'm not gonna open the entire IT strategy. But if I have a strategic vendor that they operate most of my states and they're responsible for my MDR, for example, and my operations.

And I'm definitely gonna have a concession with them because they might have insights that I don't have because they work on a wider market than me. Let's say I'm going to now invest in a new s s four HANA real estate, And I wanted to tell me what kind of risk they're seeing in in in the sense of security monitoring. Right? They've done it before.

I haven't done it before. So as an example.

I wanna ask you about startups because you you started off by talking about how dynamic this space is. You know, you've got well resourced attackers that are constantly changing. They're upping their game. You've got new technology that's being brought into the business.

I'll hit AI only because it's the, you know, it's the buzzword of the day. It's sort of, you know, this big disruptive force.

How do you think about net new problems? Like, I'm thinking about securing AI itself, things like model integrity and how do you deal with prompt injection. Probably, you're dealing with startups in this space because it's a relatively new problem. Eventually the more mature players will be in it.

But how do you balance when you're evaluating a startup that maybe has a solution that you feel like you need the stability of that company versus their ability to provide something that's a net new solution. It's like, are are they are they stable enough as a business? How do you check that? What's your appetite for bringing in sort of very new companies into the business?

Would love to get your view on how do you evaluate a new entrant in the space and say, they gonna be around even?

Yeah. It's always a bit of a risk with startups, but I think you can't really avoid working with startups today if you wanna keep more or less in line with what's happening in the market. AI is a very good example because this is run very, very fast, and almost all of the significant players in the field today are start ups or, let's say...

I don't...

I wanna say mature start ups, but we've only been dealing this for the last two years. Right? So a mature start up here would be a two year old company, essentially. I I think there's there's a few things you can look at.

First, if you want to implement the solution, what is the operational risk of implementing that in the company? Are you going to cause more damage than good? And I had...

I I work quite a lot of startups, and I also seen a couple of VCs, you know, to evaluate new startups. If it's a brand new startup, you will not give it right permissions on operational systems, or you will not allow to automate processes just because, you know, they put something wrong in their code and half the company is going down. So, normally, you start with these kinds of contracts or these evaluations with a read only visibility type of solutions, advice kind of solutions, but you're not allowing them to automate anything. And over time, when you get a sense of how good the startup is, the people, the knowledge, and whether they're able to retain their people as well over time, then you're starting to give them a bit more permission, maybe in specific units, specific departments.

You take time until you actually do the whole enterprise just to lower the risks. In parallel to that, you look at the founders, and that's what I mentioned before. Some of them today are already past several exits, so they are very, very experienced in that field. And, of course, that makes me trust them more that they know what they're doing.

And I think also you look at the...

At who is actually supporting the background, whether you know the the investors, either VCs or angel investors. If they have already advisers in their advisory board that you can trust that they're keeping them a bit grounded. One thing I see quite a lot is that they might have a brilliant idea, brilliant technology, but it's not feasible in in the real world to actually implement the way that they want to operate. And then you need someone to keep them grounded.

This is where you look at their advisory as well. And and, again, like with the base solution, you just play with the technology and play a lot of it, and you grow gradually with the with the company.

So both you can enjoy. Right? And you don't just take too much risk.

Now let me ask you about price. Because at at the end of the day, you're looking at a solution. You like it. There's going to be a discussion and a negotiation on price.

When you're evaluating cost of a solution that you're gonna bring into the enterprise, how should CSOs assess that value beyond the price tag?

Like, how do you how do you think about value versus actual cost? And maybe how do you communicate it to other stakeholders internally?

Yeah. It's always a difficult one. I think, first and foremost, to all the CISO out there is that the the price you're getting from the vendor, the initial one is probably 30% higher than what you're actually going to pay. Right?

So don't be don't be shy on this one and just negotiate as extensively as you can and bring in your procurement people. They're not your enemy. They're your allies in that sense. I think they would...

I I would say there are very broadly two types of price tags when you look at security solutions. One is a pure cost to the organization.

You can't put any ROI against it. This is something you put to lower risks. I mean, you could say that the value is risk lowering. You can't always do the price tag, but you can kind of estimate.

And I had many conversations, like that with the with the company's management or board and said, look. We are investing right now, let's say, for example, on active directory backup or intra backup or, you know, tertiary backup. Not because I like doing that, it's a headache, but because if we have another not data event, I want to recover from it. Right?

And that's something they can relate to, especially with my last company where, you know, Cosmic is literally down the road from Maersk. Then you have the other type of solutions, which can either bring you a real ROI, say, digital identity solutions. In many case, they can actually improve a lot of the onboarding and offboarding solutions and actually lower the cost you have, or they can improve the life quality of the users, which does the big value there, which even if we don't put a price tag there, I think we can't be discarded. It's it's quite important.

So, for example, when you invest in a very convenient two factor authentication authentication solution or a passwordless authentication solution, you're making the users your allies because they wanna use it. It's much easy to use that than actually start putting, you know, that 12 character password that changes every twenty two hours. You can't repeat the 25 past passwords. You know, everyone's gonna hate you for that one.

But if you make it easy for them, they will want to cooperate with you. They don't want, Nesse, to be, you know, bad corporate citizens. So that, I think, also has quite a lot of value. So all in all, the value is the cost the the cost of the solution, the cost of you implementing it because that's also on top of whatever it is you're gonna pay the vendor, and how much value you bring to the organization in the sense of ROI, peace of mind, or better life for the users.

So let let me get get into a a rubber meets the road. So now you've convinced yourself this is a great solution, we want to bring it in. The price matches the value or is less than the value, and we need it. Right? You know, we've got a real risk to buy down.

How do you evaluate whether a partner or a vendor can integrate effectively into your tech stack? And I ask this because there's probably limited capacity to do full blown proof of concepts, right? Because then you could really figure it out. How do you sort of weed out early the folks that maybe you shouldn't even go to a proof of concept, not because you don't like the solution, but because you know it's not gonna integrate with all of the back end systems that you have or the cloud providers that you've chosen. What what are some of the things you do to evaluate that?

I think in in a sense, it actually got easier last few years because it's a trend which I find very positive in the industry that most newer systems talk with almost everything else. Right? They are like APIs and and standards everyone supports, so it's... It got easier than it used to be. It's not still not easy, but easier. I think the the few things you need to look at, first of all, is whether they can connect to your IT service system, right, the service styles of the world because most enterprises will be using something like that. And this is where you're going to manage all of your IT operations, and that solution, whatever it's going to be, is going to become part of it. So that's first and foremost.

The other thing is that you need to define a few core systems that whatever solution you're buying has to talk with it, no... With... Without any negotiation involved. So for example, if you... If it has to talk to your IDP, then it has to talk with the IDP. Right? You... You're not gonna make any concession and and and, you know, introducing Okta when you're using Entra. Right? Just because one one provider doesn't wanna work. I had one example that's... To to give an example of this one, that I had a phishing simulation provider that I really wanted to work with, but they were not willing or they couldn't interface with the email reporting... With the phishing reporting button I was using, which was something that came from the email security company we were using.

And I told them, look. As much as I wanna work with you, I'm not going to introduce a new phishing reporting button because I spent a long time training the users to actually know where to press. You wouldn't you wouldn't believe how much of a headache it is to now... To tell people to use another button because the one they're used to is vanishing.

There's a few other technical reasons, but I will just assist with it. One thing also that I think you really need to look at that, maybe more for multinationals, is it which languages does the solution support, especially if it's user facing?

Because that one, you will be surprised how much that's not not a common thing. I mean, everyone supports English, obviously. But when you start asking them about supporting Mandarin or Vietnamese or all sort of languages which are either non Latin or less standard, the answers are becoming very, very different here. Right?

And I had, for example, a discussion with quite a well known DSPM solution, which I want to test. They told me we're only supporting English. That was the end the discussion. Right?

Because most of my data at that point was actually not in English. So what am I gonna do with that solution?

And somewhat related to that, and that's becoming a more and more of a challenge in the last, I would say, five to ten years, is the regulatory environment.

Can your solution adhere to the regulations in the various jurisdiction you're working? And let's say that everyone knows... Most people know how to operate within the EU. Most people know how to operate from The US. Most people know the main stuff.

But not a lot of people know how to operate in Mainland China. And when you have a huge operating in Mainland China, you have to know how to operate within the regulatory environment over there, and that's not easy. So there are big vendors out there. You know, not only big ones. There are definitely vendors out there that know, and there's some of this that explicitly want to avoid operating that environment because it's it's not it's not easy. And that's another telltale that for multinational, you need to keep an eye on as well.

And over the years, I'm sure you've seen a lot of mistakes. And so I I... I'm wondering, what are the some of the most common mistakes that you see organizations make when selecting or onboarding a provider?

Probably the first one is not using it or at least not using it great one, actually.

Or not using it to capacity because you buy something and then it ends up being, like, a nice server sitting with blinking blue lights somewhere on your rack, and you're not actually using anything. Right? It's just sitting there getting getting dust on it. So if you buy something, make sure that you don't only...

You're not only going to use it, but also use all the features or at least most of the features that you actually need. Don't just buy licenses to, to make yourself look good. I think a classic example is a Microsoft e five. Right?

A lot of organizations buy the e five without actually understanding how much technologies or different technologies are involved in there. They end up using Defender for Endpoint. They end up using, you know, the main the main stack of identity. But it's like, doesn't other things you're not even using, which are great, but you're not using them.

So I think this is definitely that one. I think the other one is making sure that you keep the partner or the vendor interested along the life cycle of the of the contract. I think you see that, and I think you see that especially with service companies that the interest from the vendor goes down over time, especially when you're talking about long contracts. The support has become a bit sluggish.

Innovation is going down the drain. You don't really have governance meeting anymore, and the quality of the contract is going down. So instead of you actually keeping good relationship, mutual updates, and you keep to a point where you can get to the end of the contract and either decide that you continue with them or part as friends, you know, in in a good way, you know, people just get sick of each other both on the vendor side and from the customer side. That's not a good way to to manage relationship.

Brings me to another question I wanted to ask you, which is related to this, this ongoing relationship.

How do you make sure that there's good governance in place after the contract's signed? Like, I'm sure there's a fair amount of diligence that you do before you sign the contract, and the questionnaires, sometimes third parties that go in and evaluate the company or the product or the solution.

But when the contract's signed, the vendor or the provider could go and change certain things on the back end, and it's different from what it was when you originally signed up with them. Any tips for how do you get that ongoing governance of these providers?

I think that probably the most important tip would be when you sign or when you negotiate the contract, have someone who is a specialist contract management person to actually look or help you write the contract. Right? Because by the end of it, we are mostly...

You know, we're IT people. We're security people. We don't necessarily know all the angles of how to manage large scale contracts. If you have someone to put the right governance in place and all the SLAs and the expectations and how would the contract look like when you want to change it or what the vendor needs to do when they wanna change something or what you need to do when you want to change something.

When you have this kind of control that both parties are reasonably happy with, say, reasonably because you're not gonna be 100% happy with this kind of contract, then you should be okay. Right? Because then you have the regular meetings. You have the vendor that knows that they have to deliver something, and, you know, that you also have obligations as part of this relationship.

You know? And that's something I think a lot of people forget. When you sign the contract, you can't just do like this. Okay.

Now it's your problem. Right? You know, we...

I bought a from you. Go and deliver. You have to be an active part of this as well. And if you're not part of it, it's not going to succeed.

And if you have this kind of good bilateral relationship and you treat the other side as a partner and you keep them abreast of what's actually happening in your organization or your projects, then it should be okay. Not always, but in most cases.

Let me expand on that. In most cases, can you share a time when a provider exceeded or failed your expectations and and what you learned from it?

I had a very substantial MDR slash security operations provider, which ran most of my state, and they were they were amazing. And they were amazing because they really wanted to deliver what's best for the customer and not looking all the time at the oil...

Most of the time at the commercial angle of it. Right? You have companies by the end of it, people. They want to deliver...

They wanna maximize on their income, which is fine. It's an approach. But by the end of it, that's not necessarily something you always need. And with these guys, I always had a very practical answer.

I came to them one day and I said, you know, I wanna look at our SIM. It's it's starting to age a little bit. Do we need to look at that solution, which is really, like, cutting edge? And they said, no.

And the reason we say no is because you are actually getting a maximum what you need. You don't need anything more at this stage. We are keeping an eye on the market when we think you need to go to something which is substantially more expensive. We'll tell you that.

They could have said yes, and, you know, increase their income by about 20% easy. But they were the people that they valued their professionalism much more than the income, again, to an extent, that they had.

On the flip side of that, I had another provider, which they got to the point where they... I don't know what it was. Maybe it was because it was a long course. It was running out. They didn't care anymore. And we... They actually caused a couple of significant security incidents because of lack of caring.

And and I was having an escalation call with their head of operations for Europe, and you could see the guy either doesn't understand what I was telling him or didn't care. And and I was telling him, you basically, you put my entire Western European network in risk. Right? That's potentially tens of million euros. Why are you guys not rushing to fix it? And that was... I mean, they knew they were already on the way out, but it's also kind of added a a note next to their name that I'm gonna be very careful working with them in the future in in other capacity because of that lack of caring.

Yeah. I love these two examples. Right? Because one of the pieces of advice that you gave at the very beginning was talk to others that have gone through the journey with this company.

And imagine, you know, that first one, the MDR provider, they're gonna get great references because if they do it with you, they're gonna do it with others, and it's just... It's naturally gonna build their business.

The other place, you know, the references are gonna come out bad. It just highlights the importance of what you said, that it's important to connect with others and talk to them.

I think people forget how small and how tribal the security industry is, and these things go around. And I I definitely saw that in the in the last RSAC that I went to, last April that it's San Francisco. Right? You go on the mainstream in San Francisco, and you have, like, 10 different people calling your name.

It's like, I haven't seen you in fifteen years. I haven't seen you in two years. And it's like a big old reunion, meeting. So it's like that, and words on good or bad will go around.

It really will. I I I couldn't agree with you more, and it's... Underscores the importance of getting together and having that community.

And and one one last question for you. If you had to give another CISO one piece of advice about selecting the right cybersecurity partners, what would it be? I mean, you had so many great nuggets during this discussion. What's the biggest thing? The single biggest thing?

Choose a vendor or a partner that you can see yourself sitting with in on... You know, in a in a pub five years from now and still get engaged by them.

If you've done that, then then you're gonna be okay.

I love that the pub test.

It has to be. Right? The pub test. Yeah. Yeah. That was great.

Tal, thank you so much for being here. Thanks for being a part of this. And listeners, thanks for tuning in. Please keep the conversation going on our RSAC membership platform by visiting 1rsac.com/membership.

And be sure to check 1rsac.com for new content posted year round. Tal, I can't tell you how much I enjoyed this and just the great wisdom that you're giving to our audience. So really, really appreciate it.

Thank you.