Securing the Company That Secures Everyone Else

Jad: Welcome to Trust at Speed, a show about the people building, securing, and governing the future of tech. I'm your host, Jad Boutros. In this series, we sit down with leading experts across privacy, security, and AI to unpack hard-earned lessons and explore how they're navigating an ever-changing landscape.

‍

Today we're joined by Daniel Chromek, Chief Information Security Officer at ESET. Daniel has built ESET's internal security organization from the ground up over 17 years and counting, bringing a deeply pragmatic, engineering-first approach to enterprise risk, application security, and governing AI at machine speed. Daniel, welcome to the show.

‍

Daniel: Hello everyone, thank you for having me.

‍

Jad: Thank you for being here. Daniel, I want to start with some questions about working as a security leader for an organization that builds security software. There's a common assumption that securing a security vendor must be a breeze, because security is the core business. In reality, security software operates with elevated privileges, which makes you a higher-value target. How do you think about the unique pressures of securing the very type of company that's built to secure others?

‍

Daniel: I think it's a situation where you have certain benefits in your hands, and of course there are some downsides that come with this setup. As you mentioned, the software we develop runs in privileged mode, which means that if we do something wrong, it can really affect a lot of customers, and really hard. We've seen that with other vendors having issues with their products in past years.

‍

The benefit is that you have really well-educated employees, because they're experts in their domain areas, and it's easier to explain to them why certain security rules should be applied. I also have the benefit of quite expert C-level management. Not all of our C-level managers came from R&D, but quite a lot of them did. So I can easily explain and sell security topics to management, compared to maybe a standard company where that understanding is missing, and my fellow CISOs need to start from the very basics and build up from there. So it's not one way or the other. It's a combination.

‍

Jad: That's a great insight. You brought up that other players in the same space have suffered some very visible issues. Not necessarily a security breach, but potentially preventing the normal functioning of computers around the world. Some of them were very, very visible. Did you feel you had to use that example to trigger more changes within the organization, or was it just something you were following without necessarily having to make changes?

‍

Daniel: It was definitely followed, because every situation that happens around security vendors, and namely endpoint security vendors, should be evaluated by our internal teams. Not just internal security, but also by R&D teams, to really improve the processes and tools used to deliver the product, updates, feeds, and whatever else goes to customers. That way we can guarantee not just the security of what comes out of us, but also the quality.

‍

In the past we've seen various scenarios, like leaks of personal data, leaks of source code, and problems with updates. This is something we can learn from, because it's less painful to learn from other companies' mistakes than from our own. That's why we watch the market carefully, to see what's going on, whether it's something that could happen to us, and how to prevent it.

‍

Jad: Fantastic. That's a great quote, by the way: learning from other people's mistakes to reduce your own. I like that quite a bit, and I love that you're iterating on what's happening in the market.

‍

On the same theme, Daniel, as the CISO of a company that provides security software, it feels like you might be wearing two different hats. One is focused on ensuring the company and its products are safe. But given your expertise in what the company is selling, maybe you're also providing feedback on product features, or even helping sell the software to customers. Is that something you experience? And if so, how do you balance those two hats?

‍

Daniel: Yes, it is. Early adoption of our own products and services is part of our security strategy. We love to be customer number one, so we can provide feedback on really early versions of our software and services, even before they're published to the beta stage. If it's stable enough that we can run it without worrying about taking production down, we love to test it and slowly build up the base of machines where the software is deployed in later, more mature versions.

‍

That way we can catch not only the bugs that come with basically every piece of software and report them quickly to R&D, but also give feedback from a security team that really works with the software back to product teams, developers, and UX, so they can incorporate our ideas into the software development lifecycle itself.

‍

Jad: That's fantastic. That's a strong collaboration between your team and product and engineering. Do you also sometimes wear a sales hat? I imagine you get looped in. Or did they decide early on not to make Daniel suffer through these?

‍

Daniel: Oh, I'm a very bad salesman, no. Sometimes I'm invited to conversations with sales if the customer is big enough and wants some kind of assurance that goes beyond traditional audit reports or other compliance checks. That's when we do these meetings at the CISO-to-CISO level. But it's quite rare.

‍

The point of a meeting like that is not to sell the product, but to sell trust: that we're a company that has the practices in place. Whether the product is good is something the customer should evaluate, because we're not aware of their use case. But we can say: this is what we do, this is what we may plan for the future to be even better at security, and this is how we can show you that our internal security program is mature enough to provide sustainable results. At the end of the day, it's about assuring that the products and services are at the desired level of security.

‍

Jad: That's wonderful. I love that notion, and it's also the thinking behind our podcast: building trust, and what that enables you to do. Thank you, Daniel.

‍

I want to switch gears a little bit. I'm curious for your thoughts on leadership, and maybe even board expectations, on the CISO role today. You've been CISO at ESET for a very long time, so you've likely seen changes. Do you find that executive leadership or the board have different expectations of the CISO role today, with the explosion of AI, than they did even a few years ago? Do you feel the job is changing, or that the way you present risk metrics, for example, is evolving?

‍

Daniel: The role is definitely evolving to fit the purpose: what does the company need from security? There are many initiatives running within ESET, like new products and new services. I wouldn't call that daily bread and butter, but it's something standard as the company grows its portfolio, and management's expectation, once again, is that the security and overall resilience of products and services are at the desired level.

‍

Then there are initiatives that have been booming in recent years, and I would group them into certain areas.

‍

One is company growth through M&A. We purchased our previous distributors, or exclusive partners, in countries like the Netherlands and France. We'll expand the number of our offices, and of course we need to onboard these companies into our portfolio. This has happened in the past, but it's not something we encounter every year, so it's a bit of a new situation for us.

‍

The second is certainly AI. AI is booming everywhere. We see it in most of the business projects we support. There are tools coming from R&D, from sales, from marketing, and they all have some kind of AI features built in. The security team is expected to provide guidance on how these tools, and the use cases behind them, should be approached, because in the EU we have regulation like the AI Act that limits what can be done with AI.

‍

That brings us to another area: compliance and regulation. This is a growing trend in the EU. The EU is really good at bringing in new regulations. We have a lot of new things on our table, and management's expectation is that we'll be compliant, so we need to make it happen.

‍

And last but not least is business continuity and resilience. The situation here in Europe is changing dramatically because of the Russian invasion of Ukraine and continuous threats coming from Russia, in both the digital and physical worlds. We've seen attacks in both recently, and we need to prepare ourselves so we can sustain such a threat and continue to provide our services, develop our products, analyze malware, and provide updates to our customers.

‍

All these aspects are changing, and with them, management's expectations of internal security are changing too.

‍

Jad: Fantastic. There's a lot to unpack in that, so let me try to get some additional thoughts from you. First, you mentioned acquiring distributors and growing offices. M&A activity tends to be heavy on security teams. What's your experience been like? Do you have any tips or advice for smaller organizations dealing with M&A for the first time? How should security leaders think about it?

‍

Daniel: That's quite a difficult question, because every company has a different approach. If security leaders are invited into the decision about whether the M&A should happen, that's great, because they can perform at least some initial assessment to see what's ahead of them.

‍

Bringing the new company on board without leaving people in the new organization dissatisfied or worried about their situation is definitely a challenging task. We have checklists and processes for covering certain areas, like policies, tool sets, rebuilding the infrastructure, things like that. But all these changes need to be done together with good communication toward our new colleagues, because we don't want to scare them and we don't want to lose them. We're not buying the company because they have servers. We're buying it because they have great people, and we want to keep them.

‍

So my advice would be: checklists are fine, but balance them, and communicate really well and really often. You can't communicate too much. That would be the main success factor.

‍

Jad: I really like that. Focusing on people is so important. It can make or break the acquisition and the value that comes out of it. Is it also a two-way street? Do you find you can learn things from them that you incorporate into your own team and thinking?

‍

Daniel: Yes, definitely, especially with ESET Netherlands. They have great leadership with Dave Maasland, and they have a great culture. They're people with a really strong security mindset, and they were offering services that ESET hadn't offered in the past. That's one reason we approached them and acquired them, and we can definitely learn from their experience. For example, they were selling and providing SOC as a service to customers in the Netherlands, and we'd definitely like to take their experience handling SOC incidents and events into our own 24/7 SOC for internal security.

‍

Jad: Terrific. You also brought up another angle as part of working with leadership and their expectations: the AI explosion. Obviously, all the different teams within an organization want to use AI more, and that puts more strain on how you govern all of it. It's even more important when your own product offering relies heavily on AI, whether for threat detection or data analysis. AI governance is still a pretty new field. Do you have any tips or advice for organizations starting to spin up an AI governance program? What should they be thinking about, what has worked, and what challenges should they be aware of?

‍

Daniel: I would say the governance itself is already quite well described in standards. We have standards like ISO 42001, if I'm correct, which can be used to manage or govern AI.

‍

The problem, of course, is in the details. At the end of the day, you'll have a new tool on the table for review, and you need to somehow assess the situation. That can be done using existing frameworks. OWASP has a good one, and there are others you can use.

‍

That leads to problem number two. Once you've reviewed the new tools, you'll probably spot some problems, with the terms of service, or around the AI itself, like whether there are guardrails in place or not. And once you have that list of problems, you may realize that in certain situations there are limited options for what you can do to fix them, because there's no single platform to defend. It's always case by case.

‍

It's not like, okay, we're all on a single network, let's segment it, put up the firewall and the IPS, and we have basic network security covered. With AI, you have a different situation for developers using coding agents, compared to sales, who have a CRM system with built-in AI or an integrated AI model that evaluates and does something, compared to a chatbot published on the website providing assistance to users. You can't deploy a single control to fix the problem in all these situations. That's why you need to go case by case, and that complicates the setup in terms of managing different tools and getting the same quality from each tool, so it really does the job at the level you want.

‍

Jad: I can only imagine how challenging that balancing act is, when you see problems with certain providers or approaches, but you also see the benefit for the business, and you're stuck in the middle trying to figure out what you can do about it. Do you have any advice for organizations struggling to find that line?

‍

Daniel: I think that's why security is not a technical issue, but a business issue. We need to take all these technical and organizational problems and be really good communicators toward the business, so they can understand. Okay, we'd love to deploy this chatbot because we want to lower the number of tickets coming to customer care. That's great, that's legit, and we'll save some money because we don't need to hire more customer care agents. On the other hand, here's the risk behind that, and here's the shame if something goes wrong. So let's discuss where we can meet in the middle.

‍

Jad: Perfect. Staying with the theme of AI, it can obviously significantly impact the scale and ability of different teams within an organization to accomplish tasks that used to take longer, or to innovate faster. What has your experience been? What are you seeing in the market when it comes to using AI meaningfully within security teams? Where do you feel AI has actually contributed in clear ways to make the security team better at what it does? Or where have you seen it fail, more hype than reality?

‍

Daniel: If I may praise our own products, we've had a module for malware detection for many years that is basically a trained AI. That module has quite good detection capability. It's of course not the single line of defense within the product, but it's one of the important ones.

‍

That's where I see the value of AI: classifying not just files, like malware files and clean files, but also things like events for SOC triage, or any kind of data where you need to find patterns that can't be seen by people because the overall picture is too complex. AI can spot those patterns for us and help with detection.

‍

The use cases we'd love to have covered, but haven't been successful with so far, are things like analyzing unstructured text. For example, all contracts need to be reviewed for security, and I would love to have some kind of AI security lawyer checking contracts against our standards. The results have been quite disappointing so far, so we're definitely trying to improve in this area.

‍

The hope we see is in a similar problem the compliance team has. You have questionnaires you need to fill out based on a knowledge base, and AI can prefill those questionnaires from the knowledge base quite well. It's not perfect, but it's definitely worth using because it saves time. If we can train the model, or twist it around, to provide similar quality for these other use cases, that would be awesome.

‍

Jad: That's terrific. One of the things being talked about a lot in the security space is how the automation of vulnerability detection, and of exploits for those vulnerabilities, is now a forcing function to patch at machine speed. It's somewhat controversial. I'm curious for your thoughts. What are you seeing in the market? Are security teams truly focusing on accelerating patching so they remain resilient against newly discovered vulnerabilities? Or are you seeing teams take other approaches?

‍

Daniel: The short answer would be yes, but you simply can't patch fast enough. What you can do is minimize the attack surface. Basically, close the firewall ports where you don't need them, so the vulnerability is still there, but it's not reachable by an attacker, and you have more time to patch. It's not reasonable to expect our IT teams to deploy patches within fifteen minutes. You can't do it.

‍

Jad: Has that need shaped how you prioritize work within your team?

‍

Daniel: We've definitely improved the triage of vulnerabilities, so we really pinpoint IT teams' attention on what actually matters. If you've worked with any vulnerability scanner in the past, you know it's quite noisy: oh, there are so many high vulnerabilities. Okay, there are, but some of them, for example, are only locally exploitable if you have an account on the machine, which only a couple of admins have, so the real impact is low. Compare that to a situation where the problem is in a web server that's publicly available from the internet, and you really need to patch the vulnerability fast, or at least have some kind of virtual patching on the WAF to prevent exploitation.

‍

Jad: Perfect. I'm curious whether you're seeing changes in the way the security team collaborates with product and engineering today, given that AI tools have dramatically increased the velocity of execution and innovation. There's increasing pressure not to be a bottleneck to the business when it comes to securing the product offering. Have you been thinking about how best to collaborate with those teams, add guardrails, and not be a bottleneck?

‍

Daniel: Yes. We have a team of skilled people, but of course we can't scale the team at unlimited speed. You always have capacity limits. So for software development lifecycle security, we're really pushing on automation: automate as much as possible, and provide development teams with information that's as reasonable as possible.

‍

We don't want to flood them with thousands of vulnerabilities from SAST. We need to narrow down what the key problem is and what mitigations are applicable, so they don't have to think, okay, what should I do with this report? Once we can automate a check within the process and provide the result with better quality, we don't need to spend so much of people's time on both sides clarifying what a finding is about.

‍

That helps us focus on the areas where automation is problematic. Usually that's things like architecture reviews, where you really need someone to look at the diagram to understand the context. If some part of the diagram looks like this, what's the impact on other systems, and on the software itself? So it's really about automating the boring stuff and pointing your team at the interesting stuff.

‍

Jad: Fantastic. Is it fair to say that when you mention architecture reviews, it's really about coming in earlier in the development lifecycle and giving feedback where it's more actionable? Is that how you think through it?

‍

Daniel: Yes, because the earlier you spot the problem, the more cost-efficient the fix.

‍

Jad: Perfect. I have one last question for you, Daniel, before I let you go. I can see most of what's written on your T-shirt, but not the end. Is it meant to be a joke? Enlighten us.

‍

Daniel: Yes, this is a T-shirt we gave as an award for our awareness surveys in the past. Basically, the people who click through our challenges may receive this kind of T-shirt.

‍

Jad: That's amazing. Daniel, if people want to stay in contact with you and follow your work: you're one of the rare people I see on LinkedIn who posts in two different languages. Obviously some people speak multiple languages, but posting in them, I find very impressive. Do you recommend they connect with you or follow you on LinkedIn? Or is there another way?

‍

Daniel: Yes, they can reach out through LinkedIn and we can connect. I post in two languages because we have a great community of CISOs here in Slovakia, and we're basically dealing with similar problems, related to regulations and business continuity management. We may be from different sectors, but the problems are the same or similar. So this is our supporting circle to share information and exchange good practices.

‍

Plus, many of the things ESET does have a worldwide impact, so that's why I also combine the content with English posts. I try not to spam people, so I just pinpoint the things I deem important.

‍

Jad: Daniel, thank you so much for joining our show and sharing your insights. I found it incredibly engaging, and I look forward to our listeners having the chance to hear it. Daniel, thank you so much.

‍

Daniel: Thank you for having me once again.