Consolidation vs. Best of Breed
Yosef Beck breaks down how security leaders should decide between consolidated platforms and specialized tools by starting with business requirements, operating capacity, and measurable outcomes rather than simply chasing fewer tools or more features.
The right security stack is not the one with the fewest tools or the most specialized capabilities. It is the one your organization can operate effectively and prove is delivering the business, operational, and security outcomes it set out to achieve.
Episode Chapters & Full Transcript
Select any chapter or transcript timestamp to begin watching from that exact point in the episode.
Full Transcript
Welcome to Conversations with CISOs, Security Leaders and Technology Executives, where we sit down with the leaders shaping cybersecurity and enterprise technology. Today I'm joined by Yosef Beck to discuss consolidation versus best of breed and how security leaders should decide. Yosef, thank you for taking the time to join me today. Before we get started, could you introduce yourself and tell us a little bit about your background and your current role?
Thank you, Sullivan, for having me. I appreciate it. My name is
Yosef Beck. I've been in Atlanta for over thirty years. I spent about
five and a half years at Georgia Tech and went into business consulting
with IBM as my first real job out of college.
From there, I moved to a local consulting firm called Jabian Consulting,
specializing in business consulting. I spent the last three years or so
of my time there focused on risk management and cybersecurity, then
moved into industry with one of my clients, IHG.
I spent a number of years in their security organization. I first ran
hotel compliance, then took over corporate compliance. I moved into
security architecture and also took on security engineering and,
finally, data security.
I'm now at CRH, Cement Roadstone Holdings, and I've been here a little
over two years. I have two different responsibilities. First, I'm the
liaison between our top-level corporate function and our Americas
business units. I work closely with our CIOs and local security teams
to make sure they're aligned with where we're trying to go at the
corporate level.
Additionally, I'm responsible for incident response, threat hunting,
and penetration testing globally.
Excellent. As you stated, you've led security across global organizations with thousands of locations and massive technology environments. When someone asks whether they should consolidate their security stack or invest in best-of-breed tools, where should they start?
I always like to start with business requirements. What are you trying
to accomplish and why? Are you trying to reduce costs? Are you trying
to optimize operations?
Once you understand the drivers from the business perspective, I move
on to the operating model. What can you realistically operate given
your existing people and current capabilities?
If you have one engineer and they need the simplicity that comes with a
consolidated security stack, and you don't have the ability to staff up
to support best-of-breed tools, then your answer is sitting in front of
you. There's no need to do any fancy calculations. Go with a
consolidated security stack.
But if you're an organization that's built to scale and you're
underperforming, start with a current-state assessment of your tools.
Score them. Once you know where you stand from a tooling perspective
and from a rationalization, standardization, and centralization
perspective, you can determine what makes the most sense for your
organization.
People will often talk about tool sprawl as if it's automatically a problem. In your experience, when does having more specialized tools create value, and when do they become operational debt?
I think it goes back to people. If the specialized tool is going to
exceed your team's ability to manage the number of integrations,
alerts, dashboards, or workflows effectively, then the tool is no
longer helpful. It's become a risk.
It's operational debt that you're going to keep paying unless something
changes from a people, process, or tooling perspective.
If an organization chooses to have best-of-breed tools, can you have a large stack that is actually well consolidated when it comes to the operational aspect?
Yes and no. You're always going to have constraints around people,
time, and money, so you're going to have to balance those and focus on
what is achievable for where you are.
If a consolidated, centralized stack is what you've got, there's no
reason it can't meet your objectives. Depending on the situation, you
might have to pull some of those levers to make it work, but you can
still achieve the desired business outcomes.
How do you go about consolidating on the operational side, even though you may have separate tools for different things, and make sure everything flows cohesively for your team?
A couple of things. One is going back again to your requirements, both
business and technical, and looking at what you actually need from the
tools.
From a technical-fit and complexity perspective, how well does the tool
work technically? How complex is it to take care of? Functionally, how
well does it meet your security-control objectives? Does it complement
or integrate with other existing tooling?
You're never going to have one consolidated stack from one vendor. That
might be a utopia for some people, but it's just not possible. There's
no vendor out there that does everything. There are some that get close,
but not everything, and certainly not everything well.
You're still going to have to integrate with other things, even outside
security. Your ticketing system, for example, isn't necessarily going
to be provided by a security vendor.
You also have to look at tool health. Whether it's a current-state or
future-state tool, how well will it help you meet required SLAs? How
many failures, incidents, or trouble tickets does it generate?
If you've already deployed it, how good is your coverage? Maybe you've
reached eighty percent. What's it going to take to reach the remaining
twenty percent of your estate?
You should also look at vendor support. If you're consolidating and
relying more heavily on one vendor, they better meet your needs and be
responsive.
Last but not least is how well you as an organization actually
understand and leverage that tool. The last thing I want is shelfware,
where I've paid for something and we're not getting the value from it.
Look at the current state of documentation. Do you have a runbook? Are
you enforcing and maintaining naming and tagging conventions? How well
have you deployed it? Is it working for you, and what's your ability to
continue enhancing it and keeping it performing?
As a security stack, all of it needs to meet those requirements to some
degree, depending on what you're trying to accomplish.
When security leaders are making purchasing decisions and evaluating a consolidated stack versus best of breed, beyond the actual licensing cost, what are some other costs that security leaders tend to underestimate when evaluating security products?
Would you be upset if I said people, process, and technology again?
There are so many switching costs you have to consider.
I think the one that we as leaders are most consistently poor at
estimating is people cost. It's not just training costs. There's a
change-management aspect of getting people to buy into and
enthusiastically adopt your new system.
There's also ramp-up time from a people perspective. At what point do
you start getting real performance and a return on investment out of
that new tool? Figuring out when that's going to occur and predicting
it reasonably well is something we're not very good at.
There's also a real cognitive load that you have to consider with any
new tool. Every new console, every new alert format, and every new
workflow introduces friction for the teams.
We're in security. We're all stretched thin by default, and we're asked
to do more with less. Any tool that's going to increase operational
complexity is going to continue costing more every day that you use it.
In this case, less is almost always more because it's actionable and
something you can support. I really do think people are at the heart of
it.
On the flip side of less is more, are there any scenarios where you think more is more, where best of breed consistently outperforms those consolidated platforms?
Yes. I think in emerging security fields. Think of data security or AI security. AI is at the top of everybody's mind, obviously, but data
security really only took off as a discipline with dedicated tooling
maybe four or five years ago.
AI is very much in its infancy. There are a million startups, it feels
like, all over the space. Nobody has had an opportunity to commoditize
or standardize the tooling.
There are always going to be cutting-edge startups that help drive the
field toward standardization and consolidation. That's where you're
going to see best-of-breed solutions because they're niche, and they're
going to outperform a consolidated platform that's been around much
longer.
Anytime there's a new emerging security field, I think you should be
looking at those best-of-breed, or at least new, solutions.
When it comes to evaluating those solutions, vendors love feature comparison charts. When you're evaluating products, what do you believe matters more than just that feature checklist?
I'm going to go back to my very first answer again. Business outcomes
are what's going to matter. The way you achieve those outcomes is by
having strong requirements.
Requirements are not just technical. They should include things like a
definition of team effectiveness and a requirement to reach that metric
within a defined period of time.
It's great to say your team will be one hundred percent effective, but
if it takes a hundred years to get there, that's not a great ROI. A
vendor can promise the moon when it comes to capabilities, but how fast
will they actually help you achieve those capabilities?
I would not conduct an RFP to compare vendors or products without
strong requirements, and those requirements should be linked directly
to business outcomes. Otherwise, in my opinion, you're always going to
end up with a subpar product or vendor.
When you've gone through that evaluation process, selected your vendor, and deployed the new tool, what metrics tell you that the decision was successful versus unsuccessful?
I think this is a critical question. Being a business consultant for ten
years and now having been in industry almost as long, I have personally
never seen this properly measured or answered.
A typical analysis is superficial: are the lights green? Is data
flowing? If yes, people say the platform is deployed and working, and
that's a successful deployment.
That's how most deployments go. We get through the actual deployment,
maybe have smoke testing afterward and a support period for a short
amount of time, but as long as people can access it, we'll say it's
done.
A more advanced analysis might take it a step further and ask: is my
team faster? Are they more efficient than they were before? How has
this mitigated security gaps and reduced risk?
Those are good questions, but you typically don't have the data to
really back them up. You have a gut feeling that you're moving faster,
or you say you closed a thousand more tickets than you did with the
last system. But are you really comparing apples to apples?
To do this properly, you need to do what's called a benefits realization
analysis, where you set clear expectations for what benefits you're
going to achieve before you make any changes.
You measure and baseline your current tooling before you make the
changes. You're doing this not just from an operational-performance
perspective, but also from a financial perspective.
Then you use the same measurements you used for the baseline and run
them again after implementation.
Post-implementation, you conduct a periodic review of those benefits
realized. It isn't one and done. You might do it six months afterward,
a year afterward, and continue asking: did I achieve what I set out to
achieve?
Another key piece, coming from my science background, is that you can't
use project resources to do that measurement because they're the ones
working on the project. You have to plan ahead as a leader and say,
“I'm going to do this review. I'm going to use the same metrics before
and after, and I'm going to use additional people so I don't impact the
project itself.”
It becomes part of business as usual to make sure those benefits are
continuously achieved.
It's not a review of IT or security's performance. It's really a
measurement of the readiness of the business to get value from that new
deployment. I haven't personally seen this done often, but I think it
would be the right way if you really wanted to make sure you were
meeting your business objectives.
How soon after implementation should you expect to see those metrics improving? When should you expect to see the results from your purchase?
It's a hard question to answer. It depends on the product, the timeline
to implement, and what your change-management plan looks like.
If it's an ERP implementation, for example, it can take years to deploy
if you've got a huge business. You have different modules, different
capabilities, and different business units.
For each piece, you're going to have to evaluate what makes sense and
when you expect to achieve the business objective.
If you've set a goal that six months afterward you're going to be at one
hundred percent effectiveness, then you should probably measure it at
one month, three months, and six months to make sure you're on track.
You might even need to measure it monthly.
For organizations that cannot afford dozens of specialized security tools but also don't want to sacrifice capability, where should they start? What is your advice for security leaders trying to find that right balance? Is there a framework or criteria you might use?
I think there are a couple of questions. First, when you're trying to
find the right balance, you need to understand your business.
How do you make money? What do you need to protect within that business
so it can keep making money efficiently?
Then use your knowledge of the risks to prioritize how you staff your
people and where you invest in specialized tools. Again, it's tied back
to your business risks, or you're not going to provide as much value as
you otherwise could.
If there's a framework for making those decisions, start with the
business requirements. Those should include the benefits you want to
achieve.
Make sure your operating model can achieve those requirements if you
give it the right tools. Figure out your current state and what your
existing tools provide.
Review those tools from a rationalization, standardization, and
centralization perspective. Make sure they're aligned with your
business requirements. Every tool should have a defined reason for
whether you're keeping it or getting rid of it.
That gives you a clear roadmap of which tools you're going to keep and
where you still have gaps.
Where should companies refuse to compromise? Where are the capabilities that are worth paying that premium for?
It's a personalized answer, but ultimately it comes down to where you
are as an organization, whether that's a security organization, a
broader IT organization, or the business as a whole.
Where are you overwhelmed? Where can you no longer keep up with your
existing tools or with the business demanding that you do more with
less?
If you've got gaps where you can no longer provide what needs to be
provided from a business perspective, that's where you need to focus and
determine whether you need to consolidate tooling or add a specialized
tool.
Again, it's applying the same framework and asking what you need based
on what you're trying to accomplish from a business-objective
perspective.
As we wrap up, are there security domains where you think consolidation is generally a better option and areas where best of breed makes more sense? Whether that's application security, vulnerability management, AI security, third-party risk management, or something else?
I think there are two answers because AI is an interesting one that
we're all grappling with.
From an AI perspective, I don't think at this point you'll be able to
get it into a consolidated tool stack until you have your data available
in one solution. That doesn't necessarily mean it all has to live in one
data lake, but you have to have the right access for AI to be able to
process and act on it.
AI is going to have to evolve. We all know it is evolving. It's
basically brand new, and we don't know where it's going to go at this
point.
More generally, specialized tools are going to be much more helpful
where you have emerging security needs, and AI is obviously one of
them.
Having point solutions to meet gaps is definitely necessary, but
consolidation is going to make it easier to gain operational efficiencies and allow your team to focus on those point solutions.
It's a balancing act. The more point solutions you have, the more people
you're going to need and the higher your costs. You might get better
outcomes, but you have to balance that with all of your other
constraints.
All right. Well, thank you very much, and thank you everybody for watching. If you enjoyed this conversation, be sure to like, subscribe, and leave a comment with your thoughts and suggestions for future guests and topics. And thank you again to Yosef Beck for joining us.
Happy to do it. Thank you so much.
Conversations With CISOs, Security Leaders & Technology Executives
Hear practical conversations with the executives responsible for protecting complex organizations. Each episode explores leadership, risk management, infrastructure, incident response, governance, and the decisions security leaders make every day.