Skip to content

In a recent webinar, Best Practices for Security Resilience, Jon Oltsik (an analyst from ESG Research Group) and I discussed the topic of network security resilience. The basic concept is that it is not a question of “IF” your company network will be breached, but “WHEN”. The real question for you to answer is, “How painful do you want that breach to be?”

You obviously want to do everything you can to prevent a breach, but the odds are that you will be attacked (probably multiple times) and one of those attacks will be successful. So now what? You really do not want to put all of your eggs into a defensive approach and neglect what happens after the bad actor gets through the door. You need to have a plan to stop, or at least limit, the exfiltration of data.

​The Network Security Resilience concept is focused on this question – once an attack has been successful, how can you limit the damage that a bad actor or malware can do? The first thing is to keep in mind that the average time from intrusion to detection of a security breach takes 191 days, according to a Ponemon Institute study. A second item is that over half of victimized companies never discover the breach themselves—they are informed by law enforcement, business partners, customers, or someone else about the breach (according to a 2017 Trustwave report). A third item is that a majority (68% according to the 2016 Verizon DBIR) of breaches happen over the course of days. So, a rapid response can have an effect and limit the exfiltration of some, or maybe even all, personally identifiable data. Limiting this data exfiltration is what will limit the cost of a breach because it limits the company’s liability – no data loss means no fines and no public reporting of the incident.

​When you put these facts together, you have a solid approach. Invest in the right set of capabilities that let you know that you have, in fact, been breached and implement those capabilities so that you know in a reasonable amount, i.e. six months is not reasonable and even one month is probably not reasonable. At the same time, you do not have to know within seconds or minutes (although that would be very nice) but you do need to know in a reasonable amount of time. You pick that interval.

​Network security resilience is a concept focused solely on this endeavor. It is all about trying to minimize corporate risk and the cost of a breach. The intent is to create a solution that identifies indicators of compromise and gives you actionable information to get the network back up and running (after a breach has occurred) as fast as possible.

​Watch this webinar below to get an overview of network security resilience and several tactics that you can implement to see indicators of compromise and limit data exfiltration.

Thank you to Keith Bromley, from Ixia for the article.

Related Posts

Cubro Webinar Replay: Network Packet Broker Technologies Uncovered

Cubro Webinar Replay: Network Packet Broker Technologies Uncovered

In this webinar, Cubro takes a technology-first look at how modern network packet brokers are designed to support increasingly complex,…
What Is a Master Clock and Why Does It Matter?

What Is a Master Clock and Why Does It Matter?

Modern organizations rely on precise time synchronization to keep operations running smoothly and consistently. Critical systems across industries such as…
Understanding Keysight Threat Simulator & Adding Value in the First 24 Hours

Understanding Keysight Threat Simulator & Adding Value in the First 24 Hours

In 2026, assuming your network is secure because you bought the “best” tools is no longer a viable strategy. The…
Everything Network Engineers Need to Know about PTP

Everything Network Engineers Need to Know about PTP

Everything Network Engineers Need to Know about PTP Precision Time Protocol (PTP), standardized as IEEE 1588 in 2002, is a…
Beyond the "Perfect" Lab: Simulating Real-World Network Chaos Before Deployment

Beyond the "Perfect" Lab: Simulating Real-World Network Chaos Before Deployment

It is the classic IT paradox: your application performed flawlessly in the staging lab, but the moment it was deployed…