Products on your perimeter considered harmful (until proven otherwise)

In the early days of the internet, a small group of cyber attackers successfully penetrated targets using basic perimeter attacks, like weak passwords on login services, and exploiting straightforward vulnerabilities in services. At that time, networks had limited telemetry and forensic capabilities, making it easier for attackers to gain access.

As more organizations established their online presence, defenders enhanced their security measures, focusing on tightening perimeters, performing vulnerability assessments, and applying patches. Meanwhile, attackers recognized that by targeting user devices directly, they could gain immediate access to essential files and resources.

This shift led many attackers to abandon perimeter defenses in favor of exploiting client software and phishing schemes. Browsers and other endpoint software were often insecure, while Office Macros, typically not secured, were frequently present across various targets.

The result was a significant increase in cyber compromises.

Nevertheless, advancements in recent years have made it more challenging to compromise endpoints via phishing. Major client applications, especially those that process internet files, have undergone extensive scrutiny, pushing software vendors to adopt more comprehensive security measures, such as removing risky features and implementing sandboxes and memory-safe programming languages. Microsoft’s recent adjustments regarding Macro defaults have largely curtailed this threat. As attackers search for obscure file formats that permit code execution, they are experiencing diminishing returns, as the rarer the format, the easier it is for defenders to detect.

Faced with these challenges, attackers have had to adapt. Some have turned back to seeking credentials or cloud data, while others are again targeting the organizational perimeter. Realizing that they cannot solely rely on weak passwords or misconfigurations, attackers are focusing on perimeter products like file transfer applications and firewalls, uncovering new zero-day vulnerabilities that allow them to infiltrate networks. Once one vulnerability is exploited, it often leads to widespread attacks.

While finding zero-day vulnerabilities might seem complex, many are well-recognized types of web vulnerabilities that can be easily exploited. During his OffensiveCon 23 keynote, expert Dave Aitel noted, “It’s only hard to find vulnerabilities if you look for hard vulnerabilities. You should instead seek out the easy ones.”

Attackers have come to understand that most perimeter-facing products are not designed with security in mind, making it significantly easier to locate vulnerabilities compared to popular client software. Furthermore, these products often lack sufficient logging capabilities or are not easily forensic-investigated, offering attackers ideal footholds in environments where client devices are equipped with advanced detection mechanisms.

Both the UK government and various partners are actively advocating for products to be ‘secure by design’, though achieving this goal will take time. In the meantime, attackers will likely continue to exploit vulnerabilities in internet-accessible products.

What Strategies Should Network Defenders Implement?

1. 1

   Urge vendors strongly to confirm whether their products are secure by design. It is crucial to demand that vendors provide evidence demonstrating that the software they sell adheres to security best practices. This requirement should be integrated into the procurement process and assessed when considering third-party products. Unfortunately, as NCSC CTO Ollie Whitehouse shared in his blog ‘Landing at the NCSC’, security is often an afterthought for many vendors. Hence, most vendors of perimeter products are unlikely to provide evidence, yet it is essential that we start demanding it.

2. 2

   When vendors fail to provide evidence of secure design, refrain from allowing their products on your perimeter. Consider shifting to cloud-hosted alternatives, utilizing ‘Software as a Service’ (SaaS) models that relieve you of maintaining underlying infrastructure. When migrating to the cloud, insist on the same level of evidence for secure design from vendors, especially for critical solutions like identity providers. The NCSC Cloud Security Principles can be a valuable resource in discussions with vendors, whose responses can be scrutinized (several vendors have public commitments). However, one may still face a challenging decision between ‘self-hosted solutions lacking evidence of secure design’, and ‘SaaS equivalents that also lack such evidence’. Your choice should depend on how easily you can transition to a secure alternative when it becomes available. Switching from a self-hosted service to a SaaS solution generally reduces risk for multiple reasons:

   • Exposure from an attack may compromise data, but should not enable an attacker to establish a foothold on your network.
   • The vendor’s security team is likely focused on monitoring their service, while your team must oversee all your organization’s services.
   • In the event of a compromise, it may be unlikely that your data is taken from the vendor unless your profile is particularly significant.

3. 3

   If reconfiguration of a self-hosted service is still necessary, take steps to mitigate risks. Many vulnerabilities, such as the widely exploited issues in Ivanti Connect, originate from additional services rather than core functionality (like management interfaces). Organizations should deactivate (or restrict through the firewall) any unnecessary internet-facing interfaces, portals, or services associated with such software.

4. 4

   Hold your own developers to equivalent standards. Organizations must ensure that the services and products they develop are designed with security in mind. Utilizing cloud hosting and serverless technologies can minimize potential damage in the event of a compromise.