Once a vulnerability is identified, a security professional is required to mitigate the issue. In this video, you’ll learn about patching, insurance, segmentation, compensating controls, and more.
In the vast majority of cases where a vulnerability has been identified, it can easily be mitigated by installing a security patch. Many times these security patches are provided on a standard schedule, so you might receive an update every week or every month, and that contains all of the patches for that particular time frame.
But if the vulnerability is particularly bad or it’s a zero day where there are active exploits occurring in the wild, you may get an unscheduled patch. This release will provide a method of removing that vulnerability from the system or provide some other method of mitigation. And if you work in IT, you know this process is one that continues. These patches are constantly provided by the manufacturers or the software developers, and you’re constantly testing and then deploying those to production.
Another way to mitigate these vulnerabilities is to move the risk from your environment to a cybersecurity insurance policy. These policies are often executed after an event occurs. So they’ll be able to cover any revenue losses or any losses due to the data recovery process. The organization might also lose money due to phishing attempts or if someone brings a lawsuit based on the results of these attacks.
But, like most policies, a cybersecurity insurance policy doesn’t cover everything. Some things that might not be covered in these policies are acts that are intentional or someone who may be transferring funds. Now that ransomware has become so prevalent in our industry, we’re seeing more and more organizations take advantage of cybersecurity insurance coverage.
Another way to mitigate any type of attack would be to limit the scope of what that attack might bring, and one way to do that is to provide segmentation. Separating devices onto their own networks or their own VLANs is a common way to provide this segmentation. This may not prevent an attacker from gaining access to a system, but it may prevent them from gaining access to the rest of the network that is outside of that segmentation.
And in some cases, you may not be able to patch. It may be that the patch causes problems with other software or the patch itself is not installing properly onto a service. In those cases, you may need to take that segment and move it completely off of your network onto its own air gapped segment.
Next-generation firewalls are great for monitoring the traffic flows between these different segments, especially since you can identify the exact application that’s being used to communicate between those segments. For example, it would be easy to see that the normal web server and SQL Server traffic may be transferred. But if someone is attempting to perform an SSH outside of that device, you can easily see that in the logs of the next-generation firewall.
If you wanted to create a segmentation with an air gap, you would use separate devices– for example, two switches. On one switch is Customer A, and on the other switch is Customer B. You’ll notice there’s no connectivity between these two networks, which means that none of the devices on the customer A network would be able to communicate with the devices on the customer B network and vice versa.
You can perform the same segmentation on the same device by using virtual LANs, or VLANs. VLANs allow you to logically assign interfaces on the switch to one particular network or another. And once those are assigned, only devices on the same VLAN can communicate with each other. So only Customer B would be able to communicate through the blue interfaces, and Customer A would only be able to communicate through the red interfaces.
On this single switch, you would not be able to communicate from the red VLAN to the blue VLAN and vice versa. Although these devices are all on the same physical device, we have logically segmented them. So the only way you can communicate between Customer A and Customer B is with a router that connects to both of those VLANs.
There may be times when you’re not able to patch a system. Perhaps the patch is causing problems with other software that you use or the patch itself is one that you’re not able to deploy at this time. And if you don’t have any type of firewalls internally, then you’ll need some other way to prevent this device from being attacked.
Some of those ways might be to disable the service that has the vulnerability. This would certainly prevent anyone from exploiting the vulnerability, but it also causes that service to be unavailable. Similarly, we could revoke access for everybody to use that application. This would certainly stop an attacker from gaining access to the app, but it also prevents all of our users from gaining access to the app.
Most organizations will have a firewall on the edge, and they may be able to set policies on that firewall that would prevent anyone from the outside from gaining access to that application or service on the inside. And there might be ways, even without internal firewalls, to provide additional types of security controls. For example, you may be able to set access control lists in a router or there may be software-based firewalls that you can install on the application server itself. Obviously, patching the application itself would be the best possible resolution. But if you’re not able to do that, some of these compensating controls might be a good second choice.
And there may be times when you can’t patch the application due to a conflict, and you may decide that you’re not going to provide any type of mitigation beyond what’s already available. Many organizations will have a security committee or change control committee that makes decisions on what devices may not receive a patch, and they can decide whether a service would have an exemption or an exemption.
This is a difficult decision to make. You don’t want to have systems that have a vulnerability that could be exploited, but you also want to maintain the uptime and availability of those services. We’re able to make these decisions regarding an exemption or an exemption because not all vulnerabilities are the same. For example, there are some vulnerabilities that can only be exploited if you are local on that device. And since many of our servers are inside data centers, it would be very unlikely for an attacker to get access to the data center, find that server within the data center facility, and then perform that particular exploit.
In those cases, the committee might decide that not patching that system is a perfectly reasonable security risk, and we can continue to follow that path until the vulnerability or the patch conflict is resolved. This is obviously a decision that is not commonly made by one individual. This would take a large number of people to look at the vulnerability, understand the risks associated with it, and then, as a group, decide to create an exemption.
Let’s say that your organization has identified a significant vulnerability. It’s one that has to be patched very quickly, and you’ve rolled that patch out to all of your systems. But did that patch actually remove the vulnerability from these systems, and were you able to patch all of the systems where this vulnerability would apply?
A good best practice after rolling out one of these patches is to perform a vulnerability scan. This scan might be able to confirm that the patch is indeed deployed properly, and it might find systems that need the patch that perhaps you weren’t already aware of.
It’s also good to get some type of feedback from these patch systems that the patch was actually deployed properly. There are usually checks and balances within the patching process that can tell you whether a patch was successful when it was completed. But it might be a good idea to perform an audit to a number of systems just to confirm that the patch is installed properly and it’s protecting that system. Usually this type of verification can be done through the patching system that you’re using, but it may also require someone to manually log into the system and confirm that that patch is installed and working as expected.
In large organizations, you may need some type of reporting system that can inform you of what patches have been pushed out and what the results of those deployments are. This is almost required once you get to a particular size. So if you have hundreds or even thousands of systems, you’re almost required to have some type of reporting system to monitor this process.
And since there are many different types of applications, vulnerabilities, and patches that are constantly deployed, you may want to report on the total number of vulnerabilities that have been identified in your organization. You might want to check to see what systems have been patched versus those that are unpatched. You could create a report that shows any new threat notifications, especially over a certain amount of time. And then you’d be able to tell what patches had an error, which ones have exceptions and exemptions, and get an idea of just how many systems are left to patch to be able to close these vulnerabilities.