[0:23] A quick privacy note: as this webinar may involve sharing sensitive information, we kindly ask all participants to respect the confidentiality of the information presented, and please do not record, distribute, or use any part of this webinar without explicit permission from the organizers and presenters. With that, I’d like to welcome everyone to...
[0:23] A quick privacy note: as this webinar may involve sharing sensitive information, we kindly ask all participants to respect the confidentiality of the information presented, and please do not record, distribute, or use any part of this webinar without explicit permission from the organizers and presenters. With that, I’d like to welcome everyone to our webinar on the multivendor versus single platform approach. My name is Boaz Barzel, and I’m honored to have this discussion alongside this esteemed panel. Many organizations face the critical decision of choosing between a multivendor strategy and a single platform approach, and not just in cyber security, we see it everywhere. Both approaches have unique advantages and challenges, and the right choice can significantly impact an organization’s security posture, operational efficiency, and overall risk management. If you asked me what’s better, I’d answer, like everyone, “it depends.” Every organization starts with the path that’s right for them: they can start with a specific vendor for a specific use case and grow it into a multivendor approach, or immediately choose a platform approach, depending on where they are. You might value customization and flexibility, tailoring your stack to specific needs where a platform won’t fit; but with multiple tools it becomes difficult to manage everything, so you might get a platform to simplify and improve integration, and then add innovative point tools on top. So whether you choose a platform or a multivendor approach, you’ll find yourself moving between the two.
[2:52] Let me introduce our speakers and let each introduce themselves. I’ll start with you, Jean.
[2:59] Hello everybody, I’m chief information security officer at the bank Banque Internationale à Luxembourg, and since 2001 I’ve been working as a CISO in a number of financial institutions in Luxembourg. I have a master’s degree in information security from the University of Luxembourg, advanced knowledge at the DORA and NIS2 level, and my hobbies are biometric security and golf.
[3:34] Fantastic, thank you Jean. Adam?
[3:42] Hi everyone, my name is Adam Saunders. I’ve been working in information security for around 25, 26 years. Like Jean I’ve been a CISO and I’m also a fan of golf. I’ve worked multiple fields rather than sticking in one area: defense, finance, gaming and betting (I was security operations manager and compliance manager for the national lottery in the UK), and most recently hospitality and currently construction.
[4:18] Very nice, thank you Adam. Hritik?
[4:28] Thanks. I’m Hritik, a senior security engineer at CRED, a financial startup in our country, where I’ve been heading our Ops group, trying to automate our security as much as we can, because with scale you need that. I’m really interested in open-source projects and solutions for security, because when you see what the solution is and how it works, it makes sense whether you need it or not.
[5:08] Thank you. Ovidiu?
[5:17] Thanks, much appreciated. Unfortunately I’m not a golf player, it seems I need to expand my profile. I’ve been working in the industry for approximately 16 years; I started as a security engineer, working for different types of organizations from private to government, and today I work with an organization that connects the best talent on the market with the organizations looking for such talent. I lead their security department across all the security domains, from incident response to architecture, application security, and GRC.
[6:13] Very good, thank you Ovidiu. And last but not least, Cassio.
[6:21] Hey everyone, thank you for the invitation. As a good Brazilian, I’m a football player. I’ve been two decades on the road; I started as a software developer, but it’s much more fun to look into code that’s vulnerable or has a problem you didn’t build yourself, which is why I migrated to application security. Today I work at Backbase, which actually is not financial; we create banking systems but we’re not a bank, banks are our customers. I was also a teacher at some universities back in Brazil, I help lead some international conferences and run some meetups, and I’m really engaged with the community, sharing knowledge. My whole focus now is to help companies build secure software, because our lives depend on it.
[7:17] I love golf, I love soccer or football depending on which country you’re in. From these diverse backgrounds, I’d like to start with you, Cassio: can you tell us about the trends you see in cyber security that influence the choice between a single or a multivendor approach with a single platform?
[7:50] Sure. One of the pain points regarding this topic is the management itself. In the application security context, to manage one code-scanning solution, then an application scanner like a DAST, then a container scanner, then an SCA solution, all these tools that assess your code or application, the more the better, but on the other hand you need people to handle all this, plus dealing with all the outputs, vulnerabilities, and risks the tools find. What I see trending now is companies looking for a way to either consolidate, you push a button and have all your scanners, or push a button and fix all the problems you find across all those tools. So consolidation is the trend companies are looking for to solve this.
[9:11] That’s interesting; I’d also love to press a button and fix things, more than just code. Jean, from your experience, what are the key benefits and drawbacks of the multivendor approach?
[9:44] For me, multisourcing can offer many advantages: it increases competition and bargaining power, reduces dependency risk, and enhances innovation and flexibility. By having multiple suppliers you can leverage their prices, quality, and delivery times to get the best deal. Here in Luxembourg I work a lot with my network, because it’s very interesting to share our ideas and problems with the other CISOs. Another benefit is that diversifying your sources can reduce the impact of supply disruptions and mitigate the risk of losing your competitive edge or intellectual property.
[10:43] Very good. Adam, what’s your take?
[10:52] Throughout my career I’ve worked in environments with both. My personal preference is always multivendor, because with multiple products you can build up a nice overlap: if one vendor is particularly good in one area, you can reinforce areas where other vendors aren’t as strong. But at the end of the day it comes down to budget, team resources, and your risk matrix. If you’re a small company with small teams, a single vendor is much easier, gives you a complete picture, and meets your risk profile; large companies with more complex environments benefit from a multivendor approach.
[11:39] Really good. We see a lot of vendors come into the market that are very innovative, bringing their own take on solving a problem, and you can combine those, but then you get into challenges around how well you integrate them. Hritik, can you talk about innovative technologies and tools that recently emerged and are impacting AppSec?
[12:13] AppSec has been around as far back as we can think, and in the early days most of it was manual: manual code reviews of whatever ships out to your customers, which isn’t always maintainable or scalable when you have thousands of repositories. But new tools, like Semgrep which came around 2019, an open-source tool, are fantastic at SAST rule writing, and competitors followed, like CodeQL, with open-source and closed-source competitors. I wouldn’t take a side yet in SAST, but SAST tools are pretty amazing now, so you can automate a lot of what security engineers were doing in code reviews, saving a huge amount of their bandwidth if your engineers know how to write SAST rules. And there are open-source tools that try to automate the SAST rules themselves. Coming back to multivendor or single vendor, you can’t expect a single vendor to adopt so many tools; the market is flooded. And with the ongoing Cyber Resilience Act we have mandatory SBOM and SCA analysis, so tools for these are pretty interesting and important.
[14:18] That leads to my next question. Ovidiu, how do you ensure there are no security gaps or overlaps in coverage in a multivendor approach?
[14:35] That’s a very difficult question to answer positively. I’ll piggyback on Adam’s answer: it all depends on the security or company maturity at the time you start engaging with the tools. Startup organizations without strict regulatory requirements will prioritize cash flow into generating business and developing the market, so their decision is easier. For more mature organizations with multiple platforms, it’s up to their digitalization status: organizations still operating traditionally with an on-prem data center start changing their processes to be more cloud-native, and that’s where they see the existing tools aren’t compatible with the new ways of working. So it’s not an easy answer; ensuring coverage between tools covers all the blind spots is more associated with the maturity of the company and of the specific team onboarding that journey.
[16:55] Interesting. Adam wants to comment.
[17:03] Absolutely, it’s to do with the journey, but in terms of avoiding gaps or overlaps, sometimes overlaps are good; defense in depth is a historical concept that still applies in modern application security and cloud environments. The best way to find where your gaps are, and this works for both single and multivendor, is to test, whether it’s testing code or more traditional infrastructure perimeters. The only way you’ll ever find gaps is by testing, and it doesn’t matter if it’s a single vendor (they may have blind spots) or multivendor (you might have gaps between overlapping technologies).
[17:52] Ovidiu, you wanted to add?
[17:55] I just wanted to comment on Adam’s statement: all the security you’re performing, all the controls and assessments, must be evidence-driven. If you live a security organization just by deploying a tool or writing a policy or defining controls without actually having evidence-driven security, you’re bound to have those blind spots.
[18:30] True, and in a broader look, when you have multiple tools, the testing to find the gaps can sometimes be initiated by a third-party group so we’re not biased. I’d like to talk about best practices from an integration perspective. Jean, how do you overcome integration issues between multiple solutions?
[18:53] Good question. Multisourcing can come with challenges such as increased complexity and cost; managing multiple suppliers means dedicating more time, money, and resources to coordinating, communicating, and monitoring their performance and compliance. As a best practice, Luxembourg is a small country, and if you need part of your IT, it’s important to choose vendors who have the intelligence to work together and know each other. It’s also important to be clear about what you want and expect when you choose multiple vendors; this reduces the risk that if there’s a problem, each vendor blames the other. They are in the service of the bank, and the issue at the end is the resolution of the problem. So it’s about trust, and it’s important to establish that at the first step.
[20:18] Interesting. I understand that from a vendor side we encounter these situations. Cassio, can you help with the risks associated with a multivendor approach?
[20:49] Good point. I’d bring a reflection to the audience. When we talk about cars, there’s no car where the whole brand builds the whole car; each piece comes from a different vendor, and we need an SBOM to understand where they’re from. But when you have a problem you go to the brand, not to each supplier of each piece. When it comes to cyber security or the cloud, you have a problem on your network or your VPCs, you talk to Microsoft, to AWS, to Amazon, and they handle everything for you even though they use other technology in the background. In our area, we should have something like that: if I rely on some ASPM that has functionality they didn’t build themselves, using open source or another enterprise solution, but if I have a problem they’ll be responsible for me, then I’m relying on a single vendor as a relationship of trust, even though in the background, and that’s the reality, no single vendor can build the whole AppSec or cyber security area, it’s impossible. So one of the main risks is to handle everything; your attack surface, management, and access management are already a mess, so you don’t need more. If you have one vendor you can rely on, one name that’s your support and trust, even though there’s multiple technology behind it, that would cut or eliminate this kind of risk. As with the car example, you get an expired piece or a mechanical problem; it’s the same with software and solutions, but someone is looking at that for you, and that’s what we want, this risk management to be away from us.
[23:12] Ovidiu, you wanted to add?
[23:20] I believe the multivendor effort to aggregate everything into a single platform is only as good as the collaboration between the providers when it comes to the data they give access to. Imagine you have a general tool ingesting data and metrics from your different security solutions; the value it brings from aggregating that data is very dependent on the data the different vendors are motivated to share between themselves. Imagine you have an innovative solution and someone wants to integrate with you; in today’s world data is power, so are you willing to share all the knowledge and data with someone who can understand it and say, “I can build a product on the same data and deliver the same outputs,” and then stop the integration? So integration is very complex. At the same time, each vendor won’t redo solutions from scratch because it’s reinventing the wheel. If you look at recent market purchases over the last six months, Fortinet acquired Lacework, Wiz acquired two companies, Palo Alto acquired different organizations, Cisco acquired Splunk. That overall integration, if you want to offer that capability to customers, the easiest way to deliver a good product is through acquisition, because you have access to the full data; if you base yourself on open trust integration, your integration might not be as good or meet customer expectations.
[26:04] I want to take this further. We talked about acquisitions and multivendor integration, similar to OX where we integrate with a lot of tools and connectors and still bring value on top. Hritik, if a vendor makes an acquisition, integrates it, and brings you a single platform, what do you see as the primary risks of that single-platform approach?
[26:52] Let’s say some acquisition happened and you have that situation. Then you have the problem of “trust, but verify.” Say I’m trusting that third-party vendor with my entire security, giving off 60 to 80% of my security headache to them because they have a multivendor architecture in place. But that level of trust is really tough to achieve. If you’re a financial corporation, you can’t hand over everything for them to analyze; there are country regulations and international laws protecting that. So when you have your internal security team, they want to trust the project but also verify it whenever they can, and that verification becomes a big problem. Consider acquisitions: in a single-vendor lock-in that’s working fine, but if my organization acquires a different organization, a lot of new code bases come into contact, and how do you figure out the same integration levels with these new acquisitions in a single-vendor approach? That becomes a huge problem, because you’re trusting someone else for the entire thing, and now you have to do a whole round of trust with the new developer and security teams. To build that trust you need to verify, so you need to verify the multivendor underlying whatever transparent vendor you’re using up front. One more important thing is downtime; you don’t want your security to go down ever. In a single-vendor approach, the guarantee of nothing going down is again a promise that comes as trust, and you need to verify it, which takes time and familiarity with the individual components of that multivendor approach.
[30:39] Interesting; it takes time to build trust. We encounter cases where prospects question existing customers, building trust through those networks. We’ve covered the drawbacks and advantages of single platform versus multivendor. We have a question from the audience: can anyone share real-world examples where multiplatform worked better than a single approach, or the opposite?
[31:37] I’ll start. Today I work at Backbase, and even though I’m a big supporter of a single vendor, we have so many customizations; the way we deliver software for one team is totally different from another, and the way we scan is heavily customized, with scripts generating SBOMs to upload to a solution to get results into the vulnerability management system. We have so many customizations that a single vendor would not fit; we evaluated a few solutions, and to customize on a single vendor would be a billionaire project, not feasible. So for us it’s much easier to have specific vendors for specific problems, and other problems we fix ourselves with automation. We’re not creating our own SAST solution, but we benefit from one SAST from the market for specific customizations. There’s another question regarding costs: if we’re not buying everything to fix everything, we save money; I just need to fix problem A and B, and the rest I handle my way, instead of buying one expensive solution that can’t fix all the problems. So that’s one use case where multivendor is more feasible for us.
[33:35] Adam, want to elaborate?
[33:35] Taking on from where Cassio was getting to on cost, and answering the Q&A question: when it comes to deployment, going multivendor is more expensive than a single vendor; I’ve worked in both environments enough to tell you multivendor will always be more expensive to deploy. Where you see the financial benefits of multivendor is at renewals, because you can play vendors off against each other; they know if you’re multivendor you’re willing to look around and potentially change. A single-vendor market is closed; it’s very difficult to replace everything in one go. So that’s where we’ve often found real savings, at renewals.
[34:32] How do you account for the effort of maintenance, integration, and managing multivendor support and relationships?
[34:54] I take that into account, which is why multivendor is more expensive: it’s not just the purchase, it’s implementing multiple systems multiple times, training costs, deployment costs, different platforms, different ways of operating, different logging, not centralized, so you need additional layers to centralize and integrate them into a seamless mesh, which adds up at deployment. Where you get the benefits is, as already said, if you only have a couple of focused areas of real concern: with a single vendor, they might not have the right solution, or it might not work the way you want, and you might have to buy an entire enterprise-wide solution to fix a problem tied to a single business unit.
[35:56] Hritik, you wanted to add?
[36:04] I’d second Adam that cost goes high with multivendor, but considering not everyone is rich, some startups have to start with less than nothing, and security, honestly, is not the first thing startups look at, painful as that is. But startups do want to get by the compliance regulations, to protect customer data. When you’re starting you don’t have a lot of options to verify; you just trust. Cloud platforms like AWS and GCP offer certain SBOM export mechanisms, PagerDuty integrations, or CloudWatch, things that help with security even when you don’t have much bandwidth, maybe one person looking at the entire security posture. So if you’re a startup short on bandwidth, it’s best to go with a single-vendor approach, and when you grow out of it and need to verify things with a proper in-house security team, you can grow into a multivendor approach.
[37:38] Exactly, and as you grow you keep moving between single and multivendor depending on the area. Let’s use the remaining time to talk about solutions and the future. Jean, what new security technologies are you planning to implement in the near future, and why?
[38:24] I like a sentence: “trust does not exclude control.” Before, we sent third parties self-assessments that we had to trust, and it’s very difficult to see if they’re really good. This year we decided to use a new solution. As you know, DORA requires us to evaluate our third-party providers, and we recently implemented a solution that evaluates third parties using only public data, like a hacker would. With it I get information on control measures and performance measures, the attack surface, misconfiguration of critical ports, whether DMARC, DKIM, or SPF are well configured, and for the web whether TLS and SSL are vulnerable to known attacks or too permissive. And we look for vulnerabilities with everyday control; it’s interesting for our own exposure, but also to see whether other vendors remediate their vulnerabilities. When I ask my IT “is it okay?” they say “yes, yes,” but with this solution I can see the day after whether the vulnerability is still there. It’s important because, as I said, trust does not exclude control, and we have to be sure that when we work with third parties there’s no risk for us.
[40:36] Good point: how do we maintain control even as we add more platforms and trust multiple vendors? Cassio, how do you evaluate and select a platform approach versus a multivendor approach for your organization’s security and goals?
[41:12] If I followed my own instincts I’d have the Tony Stark mindset, neurotic about security, wanting the best of everything. But I follow the company’s appetite, because it’s a business decision. So I build a list of requirements the business needs, and based on those I find vendors that fit them specifically; if one can fix all the problems, perfect, if not, it’ll be a multivendor approach. And if those requirements are simple enough, we might fix them ourselves and not go for any vendor. So my approach is: list of requirements, which vendors fit, then cost, integrations, and so on. Usually companies don’t have this maturity; they say “I need a code scanner,” but why? “I need to find SQL injections,” okay, that’s your requirement, you don’t need a scanner with 1,000 rules, you just need the OWASP Top 10. So clarity on requirements is what I’d suggest teams worry about.
[43:30] Ovidiu?
[43:32] I agree it depends on the maturity of your organization. In my situation, I’ve covered the engineering aspects: a tool that provides meaningful information, performance, toxic combinations, and reduces the time engineers and service owners spend triaging whether something is a true or false positive. Once you cover the engineering basics, you enable the engineers and managers to operate and digest the data; then you go into risk and compliance and provide the tools for that. Once those are covered, the next logical step is a quantitative approach: what does that ocean of data mean quantitatively, because all the security investment has to be transmitted to senior leadership, your CFO, CTO, COO, who don’t speak engineering, they speak cost and risk tolerance and how much money they’re willing to lose to enable the business. So the strategy is: enable the engineering teams to digest the data, then risk and compliance, then apply quantitative calculations. We work with an existing provider that covers those things, and we don’t consider them a vendor or provider but rather a partner, because it allows us to influence their product roadmap, and they’re willing to adjust their product to our needs. That’s associated with the trust relationship: you trust, you verify, but then that company stops being a vendor and becomes a partner for your business.
[46:25] I love this point, becoming a partner and building a partnership. We do that a lot with our customers; our roadmap is heavily based on the information and requests we get from customers, so we prioritize them to build a relationship, not just as a vendor but creating mutual success. The number one goal for us as a vendor is to help our customers be successful; that’s how the relationship is built and trust is gained, not just with these customers but others. With the time we have left, I’d like each of you to give a best practice around a multivendor or single-vendor approach, around relationships, performance, or anything you like, one takeaway for our audience. Hritik, you’ll start.
[47:57] With a single vendor like AWS, you don’t really have transparency of what’s running in the background; you have some confidence certain things are running, but not total transparency that it’s exactly this version of this software. In that case I don’t think you have many options or best practices; you just need to do security. But when you grow into a multivendor approach, or a single vendor transparently backed by many vendors where you can individually pick or turn those on and off depending on your use cases, you have a lot of extensibility. If a single vendor gives you 10 other vendors, that single vendor is essentially part of your own team. You want knowledge transfer across your entire security team, so you don’t just trust the new entity; you want your team to know the vendors being used. If the single vendor uses a static analysis tool or a vulnerable-code-detection tool, you’d want to know those tools in detail, so you evaluate the specific tools, and see the single vendor as the aggregator giving you insights, but the information is something you need to trust to begin with. So evaluate the multivendors they use first, then the single vendor.
[50:52] Thank you. Ovidiu?
[51:00] It might be that I’m biased, but what I like to do is think about the output and the outcome; each solution has an output and a final outcome. For an EDR solution, the output generates alerts and stops some breaches, and the final outcome reduces the time your engineers allocate to that. So I use output, outcome, and then best-in-class: take the three most renowned solutions that are outperforming, validate all of them, and take the one most in line with your general strategy, architecture, and existing controls, because at the end of the day you’ll need to aggregate and correlate that data in your data lake. So for me it’s output, outcome, best-in-class.
[52:26] Great point. Adam?
[52:34] I very much agree with Ovidiu: make sure you know what you want. My biggest advice is don’t go looking at technologies first; the moment you start looking at technologies, you’re letting the technologies dictate your requirements. Go to the business, understand your requirements, the budget, and the risks you’re trying to fix. Once you have a clear picture, start looking at vendors and speaking to trusted partners, whether multiple or single vendor, get their advice, and always check it back against your initial requirements. The final piece of advice: before you commit or put it to the board for financing, ask yourself one honest question, if this was my money, if I owned this company, would I invest this money in this product?
[53:45] Great question, and it’s important to understand that even though we’re not spending our own money, it’s the company’s money, which makes it part of the company, which makes it kind of our money. Cassio?
[54:07] I’d follow what Adam said: if you don’t understand and have a clear picture of the requirements, it’s like Alice in Wonderland, when she meets the rabbit and asks which way to go, and he asks where she’s going, and she says “I don’t know,” so he says any path is okay, because you don’t know where you’re going so it doesn’t matter. I actually have that as my screensaver. So it doesn’t matter where you’re going if you don’t know where you’re going.
[54:49] Great point. Jean?
[54:56] For me, the best strategy is: when determining whether to use multisourcing or single sourcing, there’s no one-size-fits-all answer. It’s important to consider your business objectives and priorities, the supplier market characteristics, supply chain requirements and constraints, and supplier relationship preferences and capabilities. By weighing the pros and cons of both strategies you can decide which suits your situation better. You may also use a hybrid approach, using both strategies for different items or segments of your supply chain. For instance, single sourcing may be beneficial for strategic items that are unique or high risk, while multisourcing may be more suitable for non-strategic items that are common or low risk.
[56:01] Very good. We have a few more questions; let’s spend a minute on quick answers. Ovidiu, how can a company know that the outcome they want and the outcome they need are the same?
[56:21] That’s part of your due diligence. Your business has an objective; the security strategy needs to support the business objectives. So all your activities, adopt OKRs and link them to those security strategies in order to support the organization, so all the outcomes you generate must support that.
[57:00] Due diligence is the key word, both internal and external. Adam, final one: sometimes companies don’t even know what the budget is, so how can they make sure they’re setting the right one?
[57:30] I’ve yet to work for a company that has ever known what its budget should be, and it’s never enough. The way you look at it: what’s the problem you’re trying to fix, what’s the potential cost to the company if it goes wrong, and what revenue will be generated by being able to deliver? From that you can work out a rough order of magnitude. The easy rule of thumb is that about 10% of your IT spend should be spent on security; most companies would be lucky to get 3 or 4%. And if they say that’s too much, ask how many days they could operate without an IT solution, without their data centers, without cloud access, or if they lost their customer data. That gives you an idea of how much is appropriate to spend.
[58:40] Good tip. We’re at time. I’d like to thank the audience for joining, and our panel, Hritik, Ovidiu, Adam, Cassio, and Jean, thank you for joining us. I’ll see you in our next episode, so stay tuned. Thank you very much.
[59:02] Thank you, bye everyone.
