5
DEALING WITH VULNERABILITIES
All the data collection and analysis you do will be for nothing if you don’t have a clear goal in mind for how you’ll use the results. In this chapter, you’ll learn to use your vulnerability analysis to improve your organization’s baseline security level. We’ll look at three broad categories of security measures: patching, mitigation, and systemic measures. Patches and mitigations are direct responses and are almost always the most pressing. But the lasting value in any security program is systemic change brought about by improved intelligence. Although it might seem counterintuitive, another option is to accept the existing risk. I’ll discuss why that could be the correct decision in your environment.
Security Measures
All of the measures mentioned you can apply in combination as part of a defense-in-depth strategy. Using this approach, you put redundant controls in place to defend against a vulnerability or category of vulnerabilities. Additionally, you must test these controls to confirm their effectiveness in protecting against vulnerability exploitation.
Patching
Patching is applying updates to resolve bugs and address vulnerabilities. Your first step after learning about new vulnerabilities is to determine the availability of a patch and apply it as soon as possible. You want to close the hole before any adversaries take advantage of it. Of course, this is easier said than done. Patching might be as easy as running an “updater” program on the system. Or it could be as complicated as compiling new code from an unofficial resource, applying it, and crossing your fingers. Patch management products, such as Microsoft System Center Configuration Manager (SCCM), are very helpful. But centralized patch tools might not be available for all operating systems and devices in your organization. In addition, there may be other reasons that patching is not feasible: perhaps the vulnerability is too new for the developer to have addressed it, the software is no longer being updated, or business requirements prioritize uptime over updates. Whatever the case, your next step is to look at how to mitigate the vulnerability without directly modifying the vulnerable application or OS.
Mitigation
Mitigations are a broad category of actions that either make exploitation more difficult or make the exploitation consequences less severe. For example, if you had a vulnerability on a specific Linux server daemon, you could use a firewall to block the port the daemon is using, preventing anyone from accessing it and exploiting the vulnerability. Of course, this isn’t always a reasonable response. With the exception of network services that listen only on localhost (127.0.0.1) for local connections, most network services are running to communicate with outside systems. So if you’re going to close them, you might as well turn them off. Instead, you might limit or block the vulnerable system from initiating connections to other internal systems. That way, even if the server is compromised, it will be difficult for the attacker to move laterally within the organization and compromise more systems.
Mitigations fall into a number of overlapping categories:
Application-based These mitigations modify the vulnerable application to remove or limit the danger of exploitation. For example, if a vulnerability is in an Apache module that you’re unable to patch immediately, you might modify the Apache configuration to disable that module. Alternatively, you could filter requests to the module and exclude known attack patterns.
Host-based This mitigation is performed at the OS level, rather than on the application. A host-based firewall or a system tool like SELinux, which limits the effectiveness of exploitation by making it harder to modify the underlying system, are good examples of host-based mitigations.
Network-based This mitigation is performed at the network level to intercept or monitor traffic to/from the vulnerable host. An example is a physical firewall, or an IDS, which watches for traffic indicating an attack or a successful compromise.
Temporary Some mitigations are more like bandages and are designed to be temporary. For example, blocking all access to a vulnerable host is probably not a lasting solution. But until you find a patch or a more permanent mitigation, it’s invaluable.
Permanent If a mitigation doesn’t affect the normal functionality of a vulnerable product, it often makes sense to leave it in place, even after you address the underlying vulnerability. This provides additional security against future vulnerabilities and improves the system’s overall security posture.
Logical As distinguished from physical mitigations, logical mitigations occur at the software or network level (where most vulnerabilities exist).
Physical Sometimes you’ll need physical mitigations. For instance, some secure environments prohibit removable USB drives to stop data exfiltration or the introduction of malware. Instead of disabling the USB ports in software, these organizations epoxy the ports shut, physically preventing the insertion of USB devices.
Systemic Measures
You implement a mitigation to protect against a specific vulnerability (or class of vulnerabilities), but you take systemic measures to improve the organization’s overall security posture. Mitigations are reactive, whereas systemic measures are proactive. You might implement specific mitigations in response to a particular threat or vulnerability. But later, during a postmortem or a scheduled security review, the need for these mitigations might lead you to rethink your security posture to protect against future threats in that category.
Here’s an example: you have a MySQL vulnerability on a system that you can’t immediately patch. So you block access to the MySQL port (TCP 3306) using your internal firewall; modify the MySQL configuration to listen only on a local socket; and when you can, patch MySQL to a newer version. So far, you’ve done some mitigation (and a bit of patching). Now take a step back: why was that port open anyway? Maybe it should have been closed beforehand. What about other MySQL servers that weren’t vulnerable to this specific issue? Do they really need to be listening for remote connections? What if that first system had been successfully compromised? Could an attacker have used it as a launch point for further attacks? By thinking about these systemic questions, you can make broader changes that improve your overall security environment or at least start a conversation to influence organizational policies and configuration standards.
Accept the Risk
A fourth option is to do nothing at all. In risk management terms, this is called risk acceptance. Risk acceptance happens when you decide that the risk is so rare or so low impact that it’s not worth addressing. There are cases where this is the best option. But even when you accept the risk, you need to document this lack of action and ensure that stakeholders agree with the decision. If auditors come around, you’ll need to show them that you’ve considered and accepted the risk, not just neglected it. From the outside, an accepted but undocumented risk and an unnoticed risk look the same!
Defense in Depth
Most responses to a vulnerability will encompass patching, mitigation, and systemic change. Defense in depth is the practice of using multiple defensive measures in concert. Although you might not be able to apply a patch immediately on a critical system, you can quickly put some mitigations in place to block or at least limit the exploitation severity. Once you can patch the system, you can remove some of the more draconian mitigations (for instance, blocking all access to the affected service) while leaving some mitigations, such as improved configurations, in place. When certain mitigations are applied to multiple systems or across network environments, they might become systemic improvements.
This is the power of defense in depth: if you have multiple layers of protection, one layer can mitigate the failure of another layer. Even better, layered defenses can help protect against vulnerabilities that haven’t been discovered. If a new MySQL zero-day vulnerability comes out that requires direct access, your existing measures of permitting access from only trusted hosts might be the difference between a day one exploitation and having enough time to apply the patch.
Validating Controls
Once you’ve put a patch, mitigation, or systemic change into place, the last step is to validate the presence and effectiveness of your chosen controls. In other words, you have to test those controls. With a mitigation or a systemic change, you can sometimes do this using additional scans: if the scanner no longer reports a vulnerability, the change is successful. Sometimes manual testing is best, especially if the mitigation or other change has subtle effects. Although a vulnerability scanner might have a hard time determining whether, for instance, you’ve disabled specific login options in Secure Shell (SSH), a human can craft test cases to validate this change.
Patching might seem like a simple case to validate. If you can confirm the patch has been applied, the vulnerability has been removed, right? But in reality, applying a patch doesn’t always fully resolve the issue. Vendor-supplied patches (especially unofficial patches) might be incomplete, incorrectly applied, or missed on some systems, or they might cause other issues with the system and need to be rolled back. It’s best to treat patching like any other mitigation and determine its effectiveness through active testing.
You can validate controls with the tools you already have by doing a vulnerability scan of a system before and after you apply controls. When you do, you should see a difference in the results. Let’s say you have a remote code execution vulnerability on a MySQL deployment, and the system owner claims to have applied the patch to address this vulnerability. You would expect that a new scan of that system will show that the vulnerability no longer exists; if it does, you know the patch was incorrectly applied, not applied at all, or ineffective. If the mitigation was instead to restrict MySQL database connections to localhost, your scan should show that the port is no longer open on the system’s public network interfaces.
But if your mitigation was to restrict MySQL connections to the local network, your scan will show nothing different. In such situations, devise testing methods based on the purpose of the mitigations or systemic measures that have been put in place. In this example, you might run another scan from outside your local network segment.
Although a full discussion of control validation techniques is outside the scope of the present topic, the general principle is simple: don’t assume anything works! Always test to make sure that any measures you’ve taken to address the vulnerability are addressing it.
Summary
In this chapter, we took a high-level look at the actions you can take when you discover vulnerabilities in your environment. Whether immediate, systemic, or—in the case of risk acceptance—just in the form of documentation, the measures you take to protect against vulnerabilities will depend on the system you’re working within.
In the next chapter, you’ll learn how to work within your organization’s structures to put these measures into effect and bring about lasting improvements to your system’s security posture.