Your Security Stack Is Only as Good as Its Configuration

Zach Frankhouser, Globalgig’s NetSec Practice Lead, spoke with Adam Riccitelli, an Incident Response Lead at S&P Global, about the gap between deploying a security control and making it effective.

Their conversation exposed a familiar pattern: tools left on default settings, old policies carried into new platforms, and controls that are only improved after an incident reveals what they missed.

The Tool Changed. The Way It Was Used Did Not.

Zach: What I see pretty consistently is organizations investing heavily across EDR, SSE, firewalls, and the wider security stack, then assuming the technology will deliver the expected protection once it is installed.

Adam: A lot of the time, it comes down to configuration, or the lack of it.

Take EDR. A company buys the platform, rolls it out across the environment, and assumes it is going to work straight out of the box.

But nobody has tuned it. Nobody has written custom rules or adjusted the policies. Without that work, it is not going to detect everything the organization expects.

Zach: We see the same thing with firewalls.

I recently worked with an organization making a significant investment to move from Cisco ASA firewalls to Layer 7–capable next-generation firewalls.

Yet the initial instinct was to carry the old ASA policies straight across unchanged, keeping the same focus on ports, protocols, and familiar indicators rather than using the richer application, user, and traffic context available in the new platform.

We helped the team step back and reconsider what the new firewalls actually needed to do, which policies still made sense and how to use the additional visibility, rather than simply recreating the old environment on a newer platform.

Because buying a Layer 7 firewall does not automatically mean you are operating at Layer 7.

Without changing the policy model, the organization would have paid for more advanced capabilities while continuing to operate much as it had before. The technology would have changed, but the organization’s understanding of the environment would have remained the same.

That matters because these platforms are a significant investment. If the operating model does not change with the technology, the organization may never achieve the security or business outcomes used to justify the transformation.

When “Just Enough” Becomes Permanent

The problem is not always poor planning or teams taking the easy option.

Security controls operate inside complex, live environments. Enabling stricter enforcement too quickly can block legitimate activity, interrupt important applications, and create disruption across the business.

Zach: A lot of organizations do not have a clear picture of the environment they are trying to protect. It has usually evolved over years through acquisitions, mergers, quick fixes, and technology introduced by different teams at different times.

Along the way, rules and exceptions build up. The people who originally understood why they were put in place move on, and the documentation does not always keep up.

If the environment is still holding together, even if it is far from optimal, there is an understandable reluctance to change anything and risk breaking it.

Adam: If you do not go through a period of whitelisting and you roll something out aggressively across a large environment, you will break things.

Teams may not even know what they have affected if the right monitoring is not in place.

Zach: I understand why teams handling security policy themselves sometimes start with the vendor defaults. During a migration, rebuilding the entire policy configuration from scratch, on top of everything else the team is managing, may not be realistic.

Deployment of default configs is not necessarily the problem. The problem is when nobody comes back after the migration to tailor the configuration and keep it aligned as the organization changes.

Part of the reason is the handoff after deployment. The control goes live, but ownership of its ongoing security effectiveness is not always clear.

Adam: Exactly. Sometimes the team doing the installation is not the security team at all. It could be an internal networking team that has simply been told, “You need to put this in.”

They get it deployed and working from a network perspective, but the deeper security configuration can easily get lost between teams.

The Incident Becomes the Tuning Exercise

Drawing on years of incident response experience, Adam described another pattern he has seen repeatedly: controls are often improved only after an incident reveals what they failed to detect.

A phishing attempt, account compromise, or fraudulent request gives investigators something concrete to work backward from.

Teams can then update policies, block indicators, close technical gaps, or change internal processes based on what happened.

Adam: A lot of blocking decisions come from the output of an incident.

Something happens, the team investigates the issue and then works out what they can change or block to prevent the same thing from happening again.

Zach: The uncomfortable reality is that the incident becomes the validation exercise.

The organization discovers what the control was not detecting, which information it was not collecting, or where the process broke down only after someone has exposed the gap.

Those changes may reduce the likelihood of the same attack succeeding again. But the next attempt may use a different domain, identity, message, or technique.

Adam: That is why context matters. Teams need to understand the behavior around it, what was unusual, and which earlier signals could have helped them identify it sooner.

Without deliberate testing, regular policy reviews, and a clear understanding of normal activity, protection remains largely retrospective.

“We Have It” and “It Works” Are Different Claims

Zach: One thing I think leaders sometimes forget is that these projects are not something most organizations do every day. You are not supposed to know everything.

A team may refresh individual technologies over time, but a major firewall migration, SSE rollout, or broader security transformation is still a significant and relatively infrequent undertaking.

For some of the people leading it, this may be the first time they have owned a project of this scale and complexity. It is difficult to build deep expertise through repetition when every decision feels high-stakes and there is often no opportunity for a second attempt.

Adam: That is true. A lot of experience comes from seeing where things did not work as expected, not from reading best practices on paper.

Zach: That is why it helps to learn from people who have been through those situations before. Whether that experience comes from a partner, vendor, consultant, or someone in your network, the value is in understanding how these capabilities perform across different environments, which challenges tend to emerge, and which decisions can create problems six months or a year later.

Security effectiveness does not come from buying a tool, and it does not come from deploying one. It comes from understanding how the technology applies to your environment, validating the assumptions you have made, and adjusting as the organization changes.

Because owning the capability and being protected by it are two different things.

AuthorS

Zach Frankhouser - Global NetSec Practice Lead

Zach Frankhouser is a network and security sales leader with over 15 years of experience across enterprise connectivity, managed infrastructure, WAN modernization, and cloud-delivered security. Combining a background in technical solution development with enterprise sales leadership, he works with organizations navigating network modernization, cloud-driven traffic changes, and evolving security architectures.

Prior to Globalgig, Zach held leadership roles across enterprise networking and managed services. At Globalgig, he leads strategic SASE and security initiatives focused on secure enterprise connectivity, operational scalability, and long-term infrastructure modernization.