Is your attack surface too big?

An attack surface is the entire area of a computing environment that is potentially susceptible to hacking. To that end, it comprises all potential entry points into an organization’s systems and data. The smaller the attack surface, the easier it will be to safeguard the organization.

The exponential proliferation of data over the past couple of decades has gone hand in hand with an exponential expansion of attack surfaces. Although computing environments are more interoperable than ever before, the underlying infrastructure often remains highly disparate. A disparate computing environment is inherently more difficult to protect, unless your security tooling can effectively monitor and secure everything. The bigger and more multifaceted the attack surface, the less likely that is to be possible.

Paradoxically, the same applies to consolidated computing environments over which you have complete control. When everything is connected and integrated, all the moving parts in your environment can end up acting as single points of failure that can potentially allow attackers to move laterally through your network once they have found an entry point. To address these challenges, business leaders must focus on reducing attack surfaces and decentralizing risk with zero trust security.

Attack surfaces span three main domains – digital, physical, and social engineering. Anything (or anyone) that stores or facilitates access to sensitive data must be carefully examined. This includes assets like web servers, communications platforms, network ports, and even people themselves.

There are many factors contributing to the expansion of attack surfaces. The overall challenge is the fact that most organizations now make extensive use of cloud-hosted assets, including software-as-a-service, web applications, and cloud-based storage.

Increasing complexity is the primary driver in the expansion of attack surfaces. For example, many organizations use dozens of cloud-hosted apps, many of which have been configured to achieve enhanced interoperability, typically through the use of application programming interfaces (APIs) or microservices architecture. Some of these are insecure to the point they can become glaring single points of failure in your broader computing environment – even if the rest is otherwise well-secured.

Attack surfaces are also expanding at the application level. Many applications and web servers are brimming with features that no one ever uses, all of which can in turn become a potential vulnerability that offers nothing of value to your business. So-called software bloat, also known as feature creep, often translates into reduced security performance. Obsolete features, such as outdated communications or security protocols, are often not properly retired, rendering an otherwise secure application insecure. Sometimes, typically obsolete features may need to be retained, due to the fact a small number of users still need them for compatibility reasons. This is a common problem with off-the-shelf software, which often caters to a large customer base.

The same applies at the hardware and firmware level. For example, most wireless networking routers support multiple security protocols, such as WEP, WPA, WPA2, and WPA3. However, WPA3, the third generation of the Wi-Fi Protected Access protocol, is the only one businesses should really be using, although WPA2 is supported by a far broader range of wireless devices, hence it often remains the only practical choice.

From an operational perspective, it clearly makes sense to consolidate all your business apps and data into a single environment that you can protect as one. That said, organizations also need to avoid having a single, or even multiple, layers of security protecting everything from a centralized perspective. You still need a single pain of glass for the sake of simplified security management, but if everything is infrastructurally protected as one operating unit, then that becomes a single point of failure.

This means that risk itself must be decentralized, with each communications channel or data asset being isolated and protected as one. In other words, no person, device, or application should have access to data not explicitly required to perform their function. This is, in essence, what zero trust security is all about.

When it comes to features, security leaders should favor applications that have fewer features, since fewer features means a smaller attack surface. This approach should also be applied to the entire software stack. For example, there is rarely any need for an organization to be using Zoom if they are already using Microsoft Teams. In this case, it is better to focus on safeguarding the Microsoft Teams deployment, instead of artificially expanding the attack surface by using several different platforms that do much the same thing.