Products on your perimeter considered harmful (until proven otherwise)
As attackers' tactics change, so must network defenders'.
In the earlier days of the internet, a small number of cyber attackers compromised targets through very simple perimeter attacks (such as poor passwords on login services), and relatively simple vulnerabilities in services. This gained them entry to networks that – back then – had poor telemetry and forensics capabilities.
As more organisations went online, defenders got better at locking down their perimeters, conducting vulnerability scans, and patching systems. Attackers also realised that targeting user devices directly meant getting immediate access to the files and resources that a user had access to.
Consequently, many attackers stopped bothering with the perimeter, and instead moved to the rich oceans of client software and phishing emails. Browsers were insecure, as was effectively all of the other software on an endpoint. Office Macros (probably not locked down) could be assumed to be present in most targets.
This all resulted in huge numbers of compromises.
However, developments in recent years have made it much harder to compromise an endpoint through phishing. Common client programs (particularly those opening files from the internet) have had a decade of being put through the fire, and so vendors of client software have had to move to defence-in-depth / secure by design approaches such as removing dangerous features, sandboxes, entire rewrites, memory safe languages etc. (no defender mourns the loss of ActiveX). Recently Microsoft's changes around Macro defaults have largely closed that route, and so as attackers attempt to find obscure file formats that allow code execution, they’re facing diminishing returns. The more obscure a format, the easier it is for defenders to spot.
Attackers have therefore been forced to ‘change up’. In some cases, by phishing for access to credentials / cloud data, or by targeting the perimeter again. Knowing that they are less likely to be able to rely on poor passwords or misconfigurations, they are increasingly looking at products on the network perimeter (such as file transfer applications, firewalls and VPNs), finding new zero-day vulnerabilities in these products, and waltzing right in. Once a vulnerability is known, other attackers join resulting in mass exploitation.
Finding zero-day / new vulnerabilities might sound highly advanced, but many of these are well-understood classes of web vulnerability and are trivial to find and exploit. At his OffensiveCon 23 keynote, Dave Aitel remarked "It's only hard to find vulnerabilities if you look for hard vulnerabilities. You should look for easy ones."
Attackers have realised that the majority of perimeter-exposed products aren't ‘secure by design’, and so vulnerabilities can be found far more easily than in popular client software. Furthermore, these products typically don’t have decent logging (or can be easily forensically investigated), making perfect footholds in a network where every client device is likely to be running high-end detective capabilities.
The UK government and partners are pushing hard to ensure products are ‘secure by design’, but this will take time. Meanwhile attackers will continue getting into networks through internet-reachable products.
What can network defenders do?
- 1
Push vendors hard on whether their products are secure by design. We all need to start demanding that vendors can produce evidence the software they’re selling is secure by design. This should be part of the procurement process, as well as assessing whether a third party product is allowed on your perimeter. The sad truth however (as NCSC CTO Ollie Whitehouse explained in his blog ‘Landing at the NCSC’), is that for many vendors, security remains an afterthought. As such, the vast majority of vendors of perimeter products will not be able to produce evidence, but we need to start demanding they do.
- 2
Where vendors can’t provide evidence their product is secure by design, don’t allow it on your perimeter. Instead, you should consider cloud-hosted versions of products, with ‘Software as a Service’ / SaaS freeing you from maintaining underlying infrastructure. When moving to the cloud, you should demand the same level of evidence of secure by design from vendors, particularly for critical solutions like identity providers. The NCSC Cloud Security Principles can be useful here and vendors can be pushed on their response to the principles (several vendors have public responses). Sadly, you may still end up in least-worse choice between ‘self-hosted solutions that can’t evidence secure by design’, and ‘SaaS equivalents that also cannot evidence secure by design’. Your decision should be based on how easily you can migrate from the service to a secure competitor when one can be identified. Replacing a self-hosted perimeter service with a ‘software as a service’ solution will still likely reduce risk for a number of reasons:
- an attack will still place the data at risk, but shouldn’t give the attacker a foothold on your network
- the vendor’s security team will likely be focussed on monitoring their service (whilst your teams need to monitor all of your organisation’s services)
- if it is compromised, there is a chance your data will not be the data taken from the vendor (unless you are particularly high profile)
- 3
Where you can’t yet migrate away from a self-hosted service, reduce the risk. Many vulnerabilities, such as the widely exploited issues in Ivanti Connect, haven’t been in the core service but in additional services (such as web portals and management interfaces). Organisations should turn off (or block at the firewall) any interfaces, portals, or services of internet-facing software that they don’t need.
- 4
Hold your own developers to the same standards. Organisations must ensure that the services and products they build themselves are secure by design. Cloud hosting and use of technologies like serverless can be a part of this, by limiting the possible damage that can occur if a service is compromised.
Sadly, the days where a fully patched perimeter meant you were safe from all but the most advanced attackers are long gone. Anything on your perimeter, even fully patched, is increasingly in the firing line, and unless you have evidence that it can withstand attacks, you should consider removing it. We are entering the days where organisations need to start aiming for a perimeter scan with no ports found accessible.
The NCSC has long recommended a cloud-first, ‘SaaS by preference’ approach to security, and the success of attacks on internet-accessible third-party products reinforces this approach. Of course, this needs to be done right; attackers are also trying to gain access to cloud services through phishing and abuse of trust relationships. But in this next round of the security game, accelerating migration to SaaS and demanding more from vendors is an important defensive move.
Dave C
Tech Director for Platforms Research
Share and print this article
Written by
CTO for Architecture
