How a global investment firm reduced security surprises

Most security teams don’t suffer from a lack of data. They suffer from a lack of certainty.

Vulnerability scanners, annual penetration tests, and compliance assessments can generate thousands of findings. Yet they often fail to answer a simple question: Which risks actually matter?

For a global investment firm operating across 18 locations, that question became increasingly important. A small security engineering team was responsible for securing a growing environment while balancing infrastructure projects, identity management, user support, and the countless responsibilities that come with protecting a modern enterprise.

The team wasn’t struggling to generate findings. They were struggling to understand which findings represented real risk, whether remediation efforts were working, and how to ensure leadership would never be surprised by an exposure that should have been discovered earlier.

That journey led them from point-in-time testing to continuous validation.

Outcomes at a glance

• Reduced impacts from 251 to 0 in a same-scope internal penetration test (pentest)





• Reduced compromised credentials from 52 to 0





• Reduced compromised hosts from 67 to 0





• Reduced cracked Active Directory passwords from 40 to 0





• Expanded continuous validation across 18 locations using a phased rollout strategy





• Enabled a lean security team to continuously validate risk without significant operational overhead

Impact

The team wasn’t expecting perfection. Every environment contains weaknesses, and no experienced security practitioner assumes an internal pentest will come back clean.

What surprised them was how effectively those weaknesses could be chained together once an attacker gained a foothold.

One of the firm’s early internal pentests identified 85 weaknesses. By itself, the number wouldn’t have stood out to most security teams. The real concern wasn’t the weaknesses themselves. It was what those weaknesses enabled.

NodeZero^® showed that those weaknesses could produce 251 impacts, including domain compromise, sensitive data exposure, ransomware exposure, host compromise, domain user compromise, and compromised credentials. 

That distinction matters because attackers don’t exploit weaknesses in isolation. They chain weaknesses, misconfigurations, and credentials together to achieve an objective. A low-priority finding on its own may appear manageable, but when combined with other weaknesses, it can become part of a pathway to something much more serious.

Figure 1. An early internal pentest identified 85 weaknesses that led to 251 impacts, including domain compromise, ransomware exposure, sensitive data exposure, and host compromise.

As the organization’s senior security engineer explained: “That impact section in NodeZero is just pure evidence of what can happen in a real life scenario.”

The shift from theoretical risk to demonstrated impact changed how the team approached remediation, shifting the conversation from identifying weaknesses to understanding their potential business impact.

Background

Like many organizations, this organization was already investing in security testing. The challenge wasn’t finding another tool. It was finding an approach that could scale across the business without creating additional work for a small security team already balancing infrastructure projects, identity management, user support, and countless other responsibilities.

As the senior security engineer described: “NodeZero is, let’s say, 5% of my work. I’m dealing with a million different things, a million different projects, a million different responsibilities.”

That reality made operational simplicity more than a convenience. It became a requirement.

The team had experience with security testing platforms that required significant infrastructure and ongoing maintenance to keep running effectively. For a small team juggling competing priorities, that overhead mattered. NodeZero offered a different model. The platform was simple to deploy, easy to operate, and allowed the team to begin testing immediately without dedicating resources to managing complex hardware infrastructure.

That ease of deployment became particularly important because the team wasn’t interested in running a proof of concept. They wanted to build a sustainable program that could scale with the business.

Click