In this article we will examine specifically why it is important to leverage one of the most powerful advantages that dynamic application security testing (DAST) or vulnerability scanning has over manual penetration testing: its ability to be scheduled for frequent or continuous assessment.

Why you need vulnerability scanning

Each year, leading multinational telecommunications company Verizon Communications Inc publishes a data breach investigations report that compiles data from over 40,000 security incidents that have taken place of the past 12 months. This report can be analysed to provide insight into the most common cyber security threats across the current landscape. 

The most recent (2019) report suggests that more than 75% of attacks continue to originate with external sources rather than internal disenfranchised employees. Additionally, 40% of data breaches targeted vulnerabilities in web applications, with 908 of a total 5,334 incidents resulting in confirmed data disclosure. The statistics are clear – despite increasing maturity of security controls, external web applications continue to be a lucrative route of exploit for attackers.

New vulnerabilities are discovered constantly by cybercriminals and can be introduced to your network and infrastructure as a result of system changes, misconfigurations and newly discovered third party exploits (like the Log4J vulnerability).

‍
Organisations who may have experience with penetration testing only in the security testing space can sometimes implement vulnerability scanning on a semi-regular basis, or even just as an annual test. There are very compelling reasons why in doing so, they are missing out on some of the strongest benefits that DAST scanning can deliver, as well as exposing their organisation to unnecessary risk.

DAST tools, such as V-Scan, can prove so cost effective that they can be coupled with an annual manual scan, giving that year-round coverage and total peace of mind.

In this article, we’ll run through a number of compelling reasons why regular scanning is not just beneficial but essential to delivery on the full potential of DAST scanning, and how regular scanning elevates vulnerability scanning to its full potential, delivering benefits that simply cannot be delivered by penetration testing alone.

How often should I run vulnerability scans?

Traditionally, Vulnerability Scanning would be carried out as a one-off event, usually on an annual basis. The main issue here is that a one-off scan does not accommodate for any new vulnerabilities, which can arise at any moment.

We’d argue – “As often as you can, perhaps weekly, and running partial scans every day”. If you’re approaching this article from a background of having performed vulnerability scans or penetration testing perhaps every few quarters, or even just annually, this will seem patently absurd, unmanageable, and unnecessary.

But it is an approach based on sound technical underpinnings related to today’s modern web applications, threat landscapes, and development practices. Let’s run through the various reasons why running your vulnerability scans as often as possible maximises the benefits to you, your organisation, and your customers.

Why monthly vulnerability scanning

The simplest analogy for why vulnerability scans should be run regularly is to consider the parallels to physical security of your premises – the process is the same, testing and assurance that preventative measures are continuous and secure and that no breach is in progress or opportunity exists for an attacker. In a physical security environment, you might advise staff to lock doors and close windows out of hours, as a policy directive, but you would then employ a security guard to walk the perimeter – to check visually that windows are shut and to rattle door handles to ensure doors are locked.

Now the important question – how often would you expect the security guard to do this? Annually? It starts to seem a little ridiculous to suggest that you only test and verify your operated controls for weaknesses on such a long cycle, doesn’t it. Your premises is in use every day and an attack could happen at any time.

The same is true for your web applications, in which attackers have access 24 hours a day, and which presents a constantly changing attack surface. The online security threat landscape develops much faster than the physical, so it makes complete sense to ensure that your security assurance controls such as vulnerability scanners align with this pace of change.

Let’s take a look at some of the common drivers for performing vulnerability scans more frequently to fully leverage their benefits, as well as why this provides less burden on your organisations’ technical teams. 

Workload management and organisational buy-in

You may be responsible for purchasing, managing or operating the vulnerability scanning solution, but you (or your team) are not an island. Vulnerability detection is only part of a cohesive vulnerability management life-cycle and buy-in from other technical teams is absolutely essential if vulnerabilities detected are to be remediated in a timely fashion. The results of a vulnerability scan are only as valuable as the willingness of the IT admin to accept the results and act on them – so make it manageable.

Place yourself in the position of a development or operations team managing a service and ask yourself whether you would prefer to receive:

1. One vulnerability finding each week of the year, with a week to fix each; or
2. Fifty-two vulnerability findings on March 2^nd, with one week total to fix all of them.

“Little and often” makes the vulnerability management process Business As Usual, rather than an extraordinary demand for resources on an irregular basis. Managers can factor in 5% “fix time” per week which makes vulnerability management part of the status quo. Providing regular vulnerability reports from frequent scans, each with a small delta to the last, helps everyone.

Closing the attack window

New vulnerabilities in software are published regularly as CVEs. When a new vulnerability is reported, it triggers a race against the clock between the various people involved. From an organisation’s point of view, teams need to roll-out the necessary security patches to rectify the flaw, as soon as the vendor supplies them.

However, at the same time, attackers will start developing exploits with malicious code that can take advantage of the identified weaknesses. The race is on, and the period until you patch is known as the “attack window” during which an attacker can take advantage of the vulnerability on your systems.

If you are only performing vulnerability scanning on a long interval or cycle between scans, it may be months before you are even aware that one of your systems is un-patched and vulnerable. Scanning on a more regular basis doesn’t necessarily find more vulnerabilities or present a greater burden, but it reduces the timescales between a vulnerability being exposed on your system and you becoming aware of it and patching it, tipping the scales in your favour and against the attacker.

Accounting for application behaviour variance 

Modern web applications are complicated beasts. The use of Content Delivery Networks, proxies, round-robin DNS, load balancers, application routing, Web Application Firewalls and other technologies means that your web application may not always respond in exactly the same manner. Differing responses, timeouts, website bannering and outages, and intermittent behaviours may mean that making only a single scan per year fails to represent typical application behaviour. The more frequently that you scan, the greater assurance you have that you capture applications in a range of typical states, and hence are more likely to spot, and remediate, vulnerabilities.

Expiring resources

Sometimes things can change even when they haven’t been changed. What do we mean by that? Well, an organisation may believe that no vulnerability can possibly have been introduced because they haven’t made any change to their service, whether that is their infrastructure (systems) or web application code. However, some resource behaviour can change even where no explicit change action has been performed, allowing vulnerabilities to be introduced: SSL certificates can expire or be revoked, domain registrations can expire, permitting domain takeover, and products can go End of Life (EOL) and cease to receive ongoing critical security updates or advisories. In combination with appropriate asset management techniques, performing scanning regularly ensures a greater chance that these issues are detected early.

Included Dynamic Third Party Code

It has become very common for websites to include third-party client-side JavaScript libraries into their applications. Third-party JavaScript is incredibly time-saving for developers and allows them to leverage common functionality in an easy and standardised manner. Notable examples include the near-ubiquitous jQuery UI and React.js but there are thousands of others providing functionality including visitor tracking.

Many libraries are called by websites from remote servers and contain code that may be managed by an unknown party. Where this is done, the over-burden of trust in these third-party libraries can prove costly where there are code errors such as XSS or sandbox implementation errors, or  malicious malware introduction by developers. Because the JavaScript is typically called directly from a CDN server, it has received no review by the organisation but critically the organisation controls only the call, not the content returned, which can change immediately without the organisation having visibility. Frequent vulnerability scanning reduces the risk of third-party code becoming dangerous and is flagged as early as possible.

Retests

It is important that vulnerability scanning is performed not only to detect vulnerabilities, but critically that follow-up scanning is also performed to verify and provide assurance on claimed fixes. Investigations following Equifax’s well-publicised data breach of 2017 appears to suggest that Equifax were aware of the requirement to patch their systems against a known and published vulnerability, but that they failed to retest systems in order to ensure that they had been patched correctly –  failure that led directly to the theft of sensitive data relating to 145 million people.

If you only perform a scan annually, or quarterly, you are failing to follow up on verification that vulnerabilities discovered in previous scans are being remediated in timescales mandated by organisational policy or in line with risk.

Vulnerability Scanning with V-Scan

The bottom line is that without performing regular vulnerability scans, you do not have consistent visibility on your vulnerability landscape and are often one step behind the attackers. If you would like more information on how Infosec Cloud are helping organisations across the UK run monthly vulnerability assessments, please get in touch.