“An ounce of prevention is worth a pound of cure.”
- Benjamin Franklin
Benjamin Franklin wrote those words in 1735 while discussing fire prevention in Philadelphia. His argument was straightforward. It was better to prevent a fire than to build an increasingly sophisticated system for dealing with one after it started.
Nearly 300 years later, cybersecurity might benefit from the same philosophy.
Over roughly the last decade, it seems that we have increasingly accepted the idea that security incidents are inevitable. As a result, enormous investment has gone into technologies designed to detect attacks, investigate suspicious behavior, contain incidents, and respond after something has happened. That shift helps explain the growth of technologies such as EDR, MDR, and XDR.
These technologies are extremely valuable. We use them ourselves. But detection and prevention are not the same security function. And perhaps, somewhere along the way, cyber teams became so focused on building better alarms that we started paying less attention to the locks.
What Happened to Prevention?
There was a time when much of cybersecurity centered around preventing unwanted traffic from entering the corporate network. Organizations invested in firewalls, intrusion prevention systems, web filtering, antivirus, VPNs, and other controls intended to stop threats before they reached critical systems. Those technologies still exist. The problem is that in many environments, perimeter security became something of a commodity.
A firewall gets purchased. It gets installed. A set of rules gets created. Then, too often, everyone moves on. Rules may remain in place for years without meaningful review. Policies accumulate. Updates may not receive enough attention. Logs exist, but nobody actively monitors them. Configurations that made sense five years ago remain in production even though the organization around them has completely changed. In the worst cases, what should be an active security enforcement point becomes little more than a fancy router.
This is a point worth repeating:
If we don't go back to locking the door, there is no amount of detection that will save us from disaster.
Of course, solving that problem is no longer as simple as buying a better firewall. The world around the firewall changed.
The Perimeter Did Not Simply Disappear
Fifteen or twenty years ago, the corporate network was relatively easy to visualize: employees worked in offices, servers lived in company data centers, internet traffic entered and exited through a relatively small number of gateways. There was a clear distinction between inside and outside. But today, that model is increasingly difficult to apply.
Now, employees often work from home, applications are delivered through SaaS, and infrastructure runs in public clouds, private clouds, colocation facilities, and traditional data centers. Organizations operate multiple branches, and employees travel. Mobile devices connect from networks the company does not control. Business applications may communicate with services belonging to dozens of other organizations.
NIST identifies exactly these trends in its Zero Trust Architecture guidance. NIST describes Zero Trust as a response to remote users, BYOD, and cloud-based resources that may exist outside a traditional enterprise-owned network boundary. It also emphasizes protecting users, assets, and resources rather than granting trust simply because something happens to be located inside a particular network.
So perhaps saying that the perimeter disappeared is not quite right. But the perimeter did become distributed, and that changes where prevention has to happen.
The Modern Edge Still Matters
Today we increasingly talk about the edge. At Network Box USA, we use that term for the boundaries where users, offices, branches, cloud services, applications, and the public internet connect. Those boundaries still matter enormously.
Network security controls can inspect traffic, enforce policy, block unwanted connections, identify malicious content, and stop attacks before they reach the systems being protected. That is the role of Managed Edge Security Services.
Different technologies address different parts of that edge:
A Secure Web Gateway can inspect and govern users' web traffic, filter risky destinations, scan downloads, apply content policy, and extend web protection to remote and roaming users.
Secure SD-WAN can securely connect headquarters, branches, cloud services, and distributed teams while applying centralized policy and encrypted connectivity.
A Web Application Firewall applies application-aware controls to HTTP and HTTPS traffic reaching public applications and APIs.
UTM, firewalling, intrusion prevention, VPN, Secure Web Gateway, SD-WAN, WAF, and related technologies all provide opportunities to stop malicious activity before it reaches its intended target. Network Box USA's Edge Defense services explicitly bring these controls together at the points where users, sites, cloud services, applications, and the public internet connect.
That is prevention. But the distributed perimeter introduces another problem.
What Happens When the Employee Goes Home?
Imagine an employee working at headquarters. Their laptop connects to the corporate network. Internet traffic may pass through a managed firewall, intrusion prevention system, Secure Web Gateway, and other security controls. Those systems have an opportunity to inspect the traffic.
Now the employee takes the same laptop home.
The physical network boundary has changed. The organization can still extend security to that user. Traffic can be routed through a VPN, Secure Web Gateway, Zero Trust access service, or another protected path. Cloud-delivered web security can apply policy to roaming users. Network Box USA's SWG, for example, is designed to apply web controls across offices, homes, and mobile locations. But there is an important architectural reality here: a network security system can only inspect traffic that actually passes through it.
If a protected path is unavailable, bypassed, disconnected, or incorrectly configured, that particular control cannot inspect traffic it never receives. That is why modern architectures increasingly use technologies such as Zero Trust Network Access, Secure Service Edge, and SASE to make security enforcement less dependent on a single physical office perimeter.
But even those architectures do not eliminate the need to secure the device itself. The employee's laptop still needs its own protection.
Edge Security and Endpoint Security Are Not the Same Thing
This distinction matters. An endpoint is not suddenly part of the network edge simply because the employee took it home. EDR is endpoint technology. Application control is endpoint technology. A firewall, Secure Web Gateway, WAF, or SD-WAN service operates in a different part of the architecture.
But modern cybersecurity increasingly requires these layers to work together. The reason endpoint protection belongs in a conversation about the changing perimeter is not because the endpoint and the edge are the same thing.
They are not.
It belongs because security can no longer depend on one enforcement point sitting at the entrance to one corporate network. Prevention still has to continue while the user moves between environments. That means applying preventive controls at the edge and applying additional controls directly to endpoints.
EDR Solves an Important Problem
This brings us back to EDR. Endpoint Detection and Response has become one of the most important security technologies of the modern era, and for good reason: endpoints generate enormous amounts of useful security information. Monitoring endpoints allows us to answer questions like, What processes are running? What files are being accessed? What network connections are being created? Is an endpoint suddenly behaving differently? Is a user accessing resources they normally never touch? Is a process performing actions associated with known attacker behavior? And more.
Modern EDR products can detect suspicious behavior, block certain activity, terminate processes, isolate compromised devices, and provide investigators with detailed telemetry. That is extremely valuable. Network Box USA’s own NBX Managed Detection and Response service combines EDR, XDR, SIEM, automation, threat hunting, and human SOC monitoring to investigate suspicious behavior and respond when preventive controls do not stop something.
Our NBX system allows us to notice and respond to things like when a user suddenly accesses files they never normally touch, or when an endpoint starts communicating in an unusual way. It can even tell when an account begins generating suspicious authentication activity, and it auto-correlates those signals. As a managed service, we then alert the SOC and investigate these signals so that we may respond and mitigate.
Those are exactly the capabilities organizations need. But there is another question we can ask before any of that becomes necessary:
Why Should Untrusted Software Be Allowed to Run?
Traditional signature-based antivirus was built around a relatively straightforward idea: we have seen this malicious software before, we know what it looks like, we create a signature for it. If we see it again, we recognize it and block it. But security technology has progressed dramatically since those days.
Modern endpoint products use reputation systems, behavioral analysis, machine learning, exploit protection, threat intelligence, and other techniques that go far beyond simple signature matching. But there is another security philosophy that asks the question from the opposite direction. Instead of beginning with: “Do we know that this software is malicious?” it begins with: “Why should this software be allowed to execute?”
That concept is not new. For years it was commonly called application whitelisting. Today, application allowlisting and Zero Trust application control provide more sophisticated implementations of the same basic philosophy, and that philosophy lines up remarkably well with Zero Trust.
Do not automatically trust something simply because it exists inside your environment. First, establish why it should be trusted.
Application Allowlisting Is an Established Security Practice
This is not simply a vendor marketing concept. The Center for Internet Security includes application allowlisting directly in CIS Controls v8.1. CIS Safeguard 2.5 recommends using technical controls so that only authorized software can execute. CIS goes further by separately recommending controls for authorized software libraries and authorized scripts.
MITRE ATT&CK also identifies Execution Prevention as a security mitigation. MITRE describes application control, script blocking, and other execution-prevention mechanisms as ways to ensure that only trusted and authorized code executes.
The principle is simple: instead of trying to maintain an exhaustive understanding of every malicious application in existence, organizations can also define what is authorized to run in their environments. These approaches are not mutually exclusive, however. Instead, they complement each other.
Where WhiteCloud Fits
This is one of the reasons Network Box USA partnered with WhiteCloud Security. WhiteCloud is not an edge-security technology in the same sense as UTM, Secure Web Gateway, Secure SD-WAN, or WAF. It operates on the endpoint.
Our Zero Trust Application Control and Malware Prevention service powered by WhiteCloud applies a default-deny trust model to applications, software libraries, and scripts. The distinction from EDR is useful. WhiteCloud asks whether software should be permitted to execute, while NBX MDR and EDR analyze behavior, correlate signals, investigate suspicious activity, and help respond when something happens. Before all that, network edge controls inspect and restrict traffic.
These technologies are performing different jobs at different layers, and that is exactly the point. Security works better when those layers support one another.
Consider Ransomware
Ransomware makes this distinction easier to visualize. Imagine that malicious software reaches an employee's laptop. There may have already been several opportunities to stop it: a Secure Web Gateway may block the website delivering it, network threat intelligence may identify a malicious destination, an intrusion prevention system may detect an exploit attempt, or email security may stop the original attachment or link.
Those are opportunities for prevention. But suppose the file reaches the endpoint anyway. A behavioral endpoint system can watch what happens next. If the program begins modifying large numbers of files, launching suspicious processes, attempting lateral movement, or behaving like known ransomware, an EDR system may detect and stop that activity.
That is a critical layer. But, application control introduces an additional question even earlier: was the program authorized to execute at all? If it was not, the objective is to prevent execution before the malicious behavior begins.
CISA's ransomware guidance explicitly recommends using application allowlisting and/or EDR solutions so that authorized software can execute while unauthorized software is blocked. That wording is important. CISA is not presenting application allowlisting and EDR as opposing philosophies.
EDR Does Not Become Unnecessary
This begs an obvious question: if unauthorized software can be blocked before execution, why do we still need EDR? The answer is because attackers do not always need to introduce a brand-new malicious executable. Legitimate applications can be abused. Credentials can be stolen. Authorized administrative tools can be misused. Users can behave maliciously. Scripts and interpreters can become attack paths. Vulnerabilities can be exploited. Misconfigurations can expose resources. In short, preventive technologies can fail.
Sometimes activity is suspicious because of how an authorized tool is being used rather than because the tool itself should never have been permitted to run. This is where behavioral visibility becomes essential. Application control can answer: “Should this software execute? While EDR can help answer: “What is this endpoint actually doing?”
MDR can add another question: “What does this activity mean, and what should we do about it?” These are all different security functions. Organizations benefit from having all of them.
Prevention Is Often Boring
There is another lesson here that does not get nearly enough attention. Many of the most effective cybersecurity practices are not new: Patch your systems. Remove software you do not need. Do not leave unsupported applications running indefinitely. Use strong authentication. Apply least privilege. Segment networks where appropriate. Secure remote access. Control what software can run. Review firewall policies. Monitor logs. Keep security products updated. Actually investigate alerts.
CIS, for example, recommends maintaining an inventory of software, addressing unauthorized software, and using application allowlisting controls. None of this sounds revolutionary, and that is precisely the point. Many of these techniques have been considered best practices for decades. Security does not always fail because nobody has invented the right technology yet. Sometimes it fails because technologies and practices we already understand were not implemented, maintained, monitored, or enforced consistently.
We already know the rules. The challenge for companies today is actually following those rules.
AI Makes the Basics More Important, Not Less
This becomes particularly important as attackers gain access to better automation and increasingly capable AI tools. AI makes phishing easier to personalize. Automation can increase the speed at which attackers probe exposed systems. Attackers can now search for vulnerabilities, weak configurations, exposed credentials, and other opportunities at greater scale and with greater speed.
But faster attackers do not make established security practices obsolete. They make them more important. If an exposed service should not be reachable, restrict it. If an account does not require administrator privileges, remove them. If software should not be running, do not allow it to run. If traffic should pass through a protected security control, enforce that architecture. If a vulnerability has a patch available, patch it.
Cybersecurity will continue evolving, but many successful attacks still depend on organizations leaving doors open that they already knew how to close.
Prevention and Detection Should Be Layers
Perhaps the mistake of the last decade was companies allowing themselves to believe that increasingly sophisticated detection could somehow replace prevention. But in reality, it cannot. A modern cybersecurity architecture should create multiple opportunities to stop an attack.
At the network and access edge: inspect traffic, restrict exposure, secure connectivity, and enforce policy. At the endpoint: control what software is authorized to execute and reduce opportunities for malicious code to run. Across the environment: detect abnormal behavior and correlate signals from endpoints, servers, networks, and cloud systems. At the SOC: investigate suspicious activity, determine what it means, and respond before an incident becomes a disaster.
Network Box USA's own service architecture reflects that philosophy. Our cybersecurity services portfolio begins with prevention through our proprietary technologies such as Edge Defense, UTM+, Secure SD-WAN, Secure Web Gateway, and WAF. Detection and response services such as NBX then address the suspicious activity that preventive layers do not stop. Additional controls such as Zero Trust application control reduce risk at the endpoint.
The objective is not to find one security product that does everything, but to build layers of protection.
Lock the Door, Then Install the Alarm
We have better detection technology today than at any point in cybersecurity's history. That is a good thing. We should know when endpoints behave suspiciously. We should identify unusual network activity. We should correlate events across systems. We should investigate threats quickly. We should have analysts ready to respond when something happens.
But none of those capabilities are reasons to stop trying to prevent incidents in the first place. Protect the edge. Protect remote access. Protect web traffic. Protect public applications. Control what is allowed to execute on endpoints. Detect what prevention misses. Respond when something still gets through.
A better alarm is valuable. But a better alarm is not a reason to stop locking the door. Benjamin Franklin had it right almost 300 years ago.
An ounce of prevention is still worth a pound of cure.