Log4Shell and Zero Trust

This blog was originally published by Appgate here.

Written by Jason Garbis, Appgate.

We’re only a few weeks past the emergence of the Log4Shell vulnerability (with a few ongoing related issues still open) and security teams worldwide have been in a mad scramble to diagnose, validate, update and communicate. While it may be a little early to take a step back and reflect, I have some thoughts I want to share with our community.

Log4Shell is a particularly insidious vulnerability, not only because it is easy to exploit, but because typically the attack surface is available to all users, often pre-authentication. In some cases, a bad actor could launch a successful attack directly from a website login page. In addition, the exploit is executed by the logging server itself, which typically runs on the corporate network in a trusted zone. The logging server makes an outbound request to the malicious site on the internet, retrieves the malicious code and executes it locally.

This type of vulnerability illustrates why Zero Trust security—and its central tenet of enforcing the principle of least privilege—is so important. There are far too many applications that are needlessly exposed to the internet. When using Zero Trust Network Access (ZTNA) technology, an organization can reduce its attack surface by making all resources invisible unless a user is authorized and authenticated to access them.

Log4Shell is a great example of why authentication-only security is far too weak, as even presenting a login screen to a malicious actor permits them to exploit it. Zero Trust’s principle of least privilege ensures that private applications stay hidden on the network, minimizing the likelihood of exploitation.

Of course, some applications or websites—like company websites—must be public-facing. However, organizations should consider shifting their security stance, and making customer-specific web applications only accessible to actual customers.

For example, if you are a firm offering business shipping and logistics services, there is no reason to expose your customer login page to every attacker in the wild. With a Zero Trust approach, you can ensure that only legitimate customers can even attempt to log in, preventing attackers from attempting to exploit the login site. Onboarding customers and requiring them to use this more secure access method is not only reasonable, but it could be a selling point for your business.

For servers and sites that need to be publicly exposed, organizations must apply a Zero Trust principle of least privilege model. These servers must not have access to a broad area of the company network. All access must be denied by default, with only explicitly allowed access granted based on defined policies. This model should also apply to outbound access to the internet.

Enterprises need to have a clear picture of not only the resources running on their networks, but also what those resources are permitted to access—and granting that access by a clearly-defined Zero Trust policy. This is also a legitimate and reasonable requirement for internal server-to-server access. Security teams simply MUST hold IT and application teams accountable for documenting and configuring policies to allow required access, and they also MUST hold themselves accountable for restricting all other access.

For admin-to-server access (for example, to apply updates or configuration changes), organizations should use defined maintenance windows, with the Zero Trust system controlling access based on IT Service Management (ITSM) business processes. More advanced organizations should consider taking a DevOps approach in which they treat servers as cattle, not pets—meaning they should never upgrade or maintain a server but rather update the master image and deploy a new server.

For server-to-internet access, most servers have no legitimate need to access arbitrary internet sites, and in fact, allowing that access represents a security weakness. Organizations must block this access or restrict it to a strict set of allowed sites. Core networking and infrastructure services (like DNS and NTP) should be limited to internal, enterprise-controlled systems.

Log4Shell also raises legitimate questions about software supply chain security and integrity—but that’s a topic for another blog post. Regardless of the degree to which you trust your software, you should operate with the Zero Trust principle of “assume breach.” If you assume that your open source, vendor-supplied or custom-written software is compromised, then at the bare minimum, you must restrict its inbound and outbound access, ensure that all access is explicitly controlled by policy, and log and monitor its actual behavior.

Given the complex threat landscape, frequency of vulnerabilities, complexity of hybrid environments and proliferation of devices in today’s remote-work universe, many enterprises and government organizations are rapidly embarking on their Zero Trust journeys. ZTNA solutions can send them smoothly on their way by:

• Actively cloaking ports, for example by using single packet authorization (SPA), which makes internet-facing servers invisible to unauthorized users
• Handling devices and user risk: a fine-grained ZTNA policy can calibrate and grant appropriate entitlements to users and devices based on the limited risk
• Controlling traffic to and from servers and user devices. Many ZTNA solutions work well in use cases that require user/device policies for resource interactions, also known as “up rules” (i.e., when a user’s mobile device needs to access a database). But “down rules”—which deal with interactions between a server, service or resource “down” to the user device—should be supported as well (i.e., remote desktop support and centralized endpoint protection platforms). Look for a ZTNA platform that supports both
• Supporting broad IT and security ecosystem integration. ZTNA must integrate with threat intelligence tools, security incident and event management (SIEM) solutions, endpoint detection and response (EDR) platforms, ITSM solutions and more
• Operating at enterprise scale and speed. While many organizations start with a single use case, eventually their ZTNA solution must be able to handle the full access control load of the entire organization, as well as increased load levels within an expanding footprint, including all applications across the network and cloud ecosystem

The last few weeks have been difficult for many people in information security. If you’re a practitioner, thank you for your dedication. If you are on the business side in your organization, please extend some patience to your security and network teams who have been working nights and weekends to protect your enterprise.

Log4Shell is the worst vulnerability we’ve seen in a long time and it underscores the need for and the value of a Zero Trust approach to security. Use this incident as a catalyst for starting or accelerating your Zero Trust journey—there’s no time to waste—as we all know that 2022 promises to bring additional security vulnerabilities. The principles and approaches of Zero Trust are proven to provide demonstrably better security, and you have a responsibility to help lead your organization to a better place. Now’s the time to get started.