Your network is always changing. Continuous monitoring provides real-time visibility into vulnerabilities so you can fix them faster.
SHARE
back to BLOG

Why you need continuous network monitoring

James Harrison

Changes in the way we work have had significant implications for cybersecurity, not least in network monitoring. Workers no longer sit safely side-by-side on a corporate network, dev teams constantly spin up and tear down systems, exposing services to the internet. Keeping track of these users, changes and services is difficult – internet-facing attack surfaces rarely stay the same for long.

But a secure working network is the backbone of every modern business, and with so many different attack vectors and entry points, relying on firewalls and point-in-time scanning is no longer enough. You need to understand how your firewalls are being changed in real time, with real-world validation of how they’re configured. You need continuous network monitoring.

What needs protecting in your network?

There is so much sprawl in today’s corporate networks with remote working, cloud computing and third-party integrations, that it’s no longer just the devices or systems that you have in your office and data center that need protecting.  

From the hardware and software of the network itself, to all the devices used to access it, from IoT endpoints to laptops and smartphones, network security now needs to look beyond the perimeter to your cloud resources, edge devices, third-party hosted content, integrations with other hardware or software, and assets hosted in dispersed offices.  

Just to complicate matters further, some of these services, especially those hosted in the cloud, may only be active for a short space of time for specific projects, events, deployments, or by design. With such a dispersed network, the castle-and-moat model of network security is no longer fit for purpose.

What can go wrong with your network?

Vulnerabilities can be introduced to your network in a number of ways, including misconfigurations, expiring certificates, new assets added to cloud environments, missing patches, or unnecessarily exposing services to the internet. In addition, there’s the ever-present risk of attack from phishing, supply chain compromises and exposed credentials.

For example, a Windows SMB service on your internal network is not a vulnerability, but exposing one to the internet is a different matter entirely – that’s what led to the WannaCry ransomware attack that spread across the world.

Similarly, Australian telco Optus suffered a devastating data breach in 2022 that exposed details of 11 million customers. The breach occurred through an unprotected and publicly-exposed API which didn’t require user authentication, so anyone that discovered the API on the internet could connect to it without a username or password.

How can you protect your network?

Continuous network monitoring supported by regular scanning could have picked up both of these vulnerabilities and prevented these breaches.

Monitoring uses automation to detect and identify flaws and weak spots in your devices, application software and operating systems. It does this by sending probes to look for open ports and services, and once the list of services is discovered, probing each for more information, configuration weaknesses or known vulnerabilities.  

It’s common to have a range of systems in your network, from laptops and workstations in the office or at home, to systems in cloud platforms like AWS, Azure, and Google Cloud. Your team may well use a range of operating systems too.

Deciding what to include in your network scan can be hard, but there are multiple ways to tackle it: exposure based, sensitivity based and coverage based. Check out our guide to find out the best approach for your business context.

Why do you need to monitor continuously?

Your network is always changing. New services are spun up, web apps updated, permissions changed, devices added and removed. All of these can introduce potential vulnerabilities. The goal of continuous monitoring is to provide near-immediate feedback and insight into these changes, assessing and prioritizing vulnerabilities, so you can understand the risk across your entire infrastructure.

With this clear picture of what attackers can see and what’s accessible in your internet-facing infrastructure, you can easily tackle any problems as soon as they arise.

Continuous monitoring not only provides visibility into the vulnerabilities in your IT environment and remote devices, but also clarity into how those vulnerabilities translate into business risk, and which are most likely to be targeted by attackers.

Ask the expert: 3 reasons why you need continuous scanning

By Andy Hornegold, Intruder Product VP

1.       "I don't need continuous monitoring because my assets/apps/systems don't change that frequently"

Just because your app doesn't change every day, or only changes once every six months, there are always new vulnerabilities being discovered in the technologies you use every day. If you haven't changed your assets/apps/systems in six months, then you haven't patched in six months, which means you're much more likely to be vulnerable to those new vulnerabilities.

2.       "You're checking for technologies that I don't use"

We don't make assumptions about the technologies you're using (you know what they say about assumptions) but we will scan for every medium, high or critical vulnerability that there’s a check for, because you may have deployed that technology since our last check. Someone else in your team might have deployed something, and you need to know about it. There's no downside because you don't have to lift a finger - our Emerging Threat Scans does it for you.

3.       "Why would I need daily network scanning?"

Vulnerability scanning engines take time to develop checks, and those checks can take days to be released after the vulnerability has been outed (usually it's 24 hours, but there are occasions where this is longer - like CitrixBleed). If a vulnerability blows up, then the next question should (at least) be "am I vulnerable?". If there's no check, how do you know what your exposure is? Network View will show if you have those technologies exposed and proactively increase monitoring or firewall the assets until a check or patch is available. You need to know that the information you have is up to date.

Continuous network monitoring with Intruder

Advanced network monitoring tools like Intruder run daily network scans so your network view is always accurate and up to date – showing active and unresponsive targets, any changes since your last scan, expiring certificates, and the ports and services you expect – and more importantly, don’t expect – to be exposed to the internet.

Any targets you add will kick off a scan. Once finished, we add the target to the queue for rescanning at regular intervals. Any changes will automatically kick off a vulnerability scan, with issues prioritized by context so you can fix what matters most.

If you’re lucky enough to have your own network range, you know how useful it can be but how hard to manage. You want to make sure your whole range is covered, but licensing vast numbers of inactive IPs can be expensive. Our Smart Recon feature monitors your external network ranges for active IPs – but you’ll only pay for the ones in use.

This continuous monitoring gives comprehensive and up-to-date visibility across your entire IT environment to take your network security to another level. Why not try Intruder with a free 14-day trial and experience continuous network monitoring for yourself? Or choose a time to chat with us for more information.

Release Date
Level of Ideal
Comments
Before CVE details are published
🥳
Limited public information is available about the vulnerability.

Red teamers, security researchers, detection engineers, threat actors have to actively research type of vulnerability, location in vulnerable software and build an associated exploit.

Tenable release checks for 47.43% of the CVEs they cover in this window, and Greenbone release 32.96%.
Day of CVE publish
😊
Vulnerability information is publicly accessible.

Red teamers, security researchers, detection engineers and threat actors now have access to some of the information they were previously having to hunt themselves, speeding up potential exploit creation.

Tenable release checks for 17.12% of the CVEs they cover in this window, and Greenbone release 17.69%.
First week since CVE publish
😐
Vulnerability information has been publicly available for up to 1 week.

The likelihood that exploitation in the wild is going to be happening is steadily increasing.

Tenable release checks for 10.9% of the CVEs they cover in this window, and Greenbone release 20.69%.
Between 1 week and 1 month since CVE publish
🥺
Vulnerability information has been publicly available for up to 1 month, and some very clever people have had time to craft an exploit.

We’re starting to lose some of the benefit of rapid, automated vulnerability detection.

Tenable release checks for 9.58% of the CVEs they cover in this window, and Greenbone release 12.43%.
After 1 month since CVE publish
😨
Information has been publicly available for more than 31 days.

Any detection released a month after the details are publicly available is decreasing in value for me.

Tenable release checks for 14.97% of the CVEs they cover over a month after the CVE details have been published, and Greenbone release 16.23%.

With this information in mind, I wanted to check what is the delay for both Tenable and Greenbone to release a detection for their scanners. The following section will focus on vulnerabilities which:

These are the ones where an attacker can point their exploit code at your vulnerable system and gain unauthorised access.

We’ve seen previously that Tenable have remote checks for 643 critical vulnerabilities, and OpenVAS have remote checks for 450 critical vulnerabilities. Tenable release remote checks for critical vulnerabilities within 1 month of the details being made public 58.4% of the time, but Greenbone release their checks within 1 month 76.8% of the time. So, even though OpenVAS has fewer checks for those critical vulnerabilities, you are more likely to get them within 1 month of the details being made public. Let’s break that down further.

In Figure 10 we can see the absolute number of remote checks released on a given day after a CVE for a critical vulnerability has been published. What you can immediately see is that both Tenable and OpenVAS release the majority of their checks on or before the CVE details are made public; Tenable have released checks for 247 CVEs, and OpenVAS have released checks for 144 CVEs. Then since 2010 Tenable have remote released checks for 147 critical CVEs and OpenVAS 79 critical CVEs on the same day as the vulnerability details were published. The number of vulnerabilities then drops off across the first week and drops further after 1 week, as we would hope for in an efficient time-to-release scenario.

Figure 10: Absolute numbers of critical CVEs with a remote check release date from the date a CVE is published

While raw numbers are good, Tenable have a larger number of checks available so it could be unfair to go on raw numbers alone. It’s potentially more important to understand the likelihood that OpenVAS or Tenable will release a check of a vulnerability on any given day after a CVE for a critical vulnerability is released. In Figure 11 we can see that Tenable release 61% their checks on or before the date that a CVE is published, and OpenVAS release a shade under 50% of their checks on or before the day that a CVE is published.

Figure 11: Percentage chance of delay for critical vulnerabilities

So, since 2010 Tenable has more frequently released their checks before or on the same day as the CVE details have been published for critical vulnerabilities. While Tenable is leading at this point, Greenbone’s community feed still gets a considerable percentage of their checks out on or before day 0.

I thought I’d go another step further and try and see if I could identify any trend in each organisations release delay, are they getting better year-on-year or are their releases getting later? In Figure 12 I’ve taken the mean delay for critical vulnerabilities per year and plotted them. The mean as a metric is particularly influenced by outliers in a data set, so I expected some wackiness and limited the mean to only checks released 180 days prior to a CVE being published and 31 days after a CVE being published. These seem to me like reasonable limits, as anything greater than 6 months prior to CVE details being released is potentially a quirk of the check details and anything after a 1-month delay is less important for us.

What can we take away from Figure 12?

Figure 12: Release delay year-on-year (lower is better)

With the larger number of checks, and still being able to release a greater percentage of their remote checks for critical vulnerabilities Tenable could win this category. However, the delay time from 2019 and 2020 going to OpenVAS, and the trend lines being so close, I am going to declare this one a tie. It’s a tie.

The takeaway from this is that both vendors are getting their checks out the majority of the time either before the CVE details are published or on the day the details are published. This is overwhelmingly positive for both scanning solutions. Over time both also appear to be releasing remote checks for critical vulnerabilities more quickly.

Written by

James Harrison

Recommended articles

Ready to get started with your 14-day trial?
try for free