By: Chris Roth, Security Engineer, MAD Security | January 24, 2019
 
Software vulnerabilities provide one of the biggest attack vectors into an organization. New security flaws are constantly being discovered, making defending against them an ongoing struggle to keep our organizations safe. The good news is that there are best practices that help mitigate the risks associated with them. Two of the most significant practices include patch and vulnerability management. While these may seem simple on the surface, software vulnerabilities are frequently our main point of entry during security assessments. A well implemented patch and vulnerability management program can remediate and detect patch-related vulnerabilities before an attacker is given a chance to abuse them. Below we will step through the basic components of what a successful patch and vulnerability management program should encompass.
 

Patch Management

 
What is patch management?  It may seem like a silly question, but patch management encompasses much more than just “applying patches” and is a continuous set of tasks that have the overall goal of preventing the exploitation of vulnerabilities. At a high level, this is done by applying security related updates to remove attack vectors exposed by poor coding or through incorrect implementation of the software.  There are a number of steps that are needed to ensure that patching is successful across your infrastructure.  These steps can be broken down to the major categories of: hardware inventory, software inventory, patch testing, and patch deployment. Each of these has been broken out below and explained in more detail to help gain a better understanding of how it is accomplished, as well as why it is important.
 
Hardware Inventory
 
The first major step in addressing patch management is knowing what you have. Again, this may seem simple, but keeping track of everything from desktops, to servers, to printers and everything in between can be a daunting task. I can’t stress enough the number of times we’ve used a long-forgotten Windows XP box or development server to gain a foothold into an organization. Fortunately, there are a number of automated asset scanning solutions available today that can make this task much easier to take care of.
Your asset inventory should be documented, and continually updated. It should include details such as where the assets reside, who owns them, what their purposes are, what the criticality of the system is, and any pertinent hardware and operating system details. This inventory along with any other inventory list that is kept should exist as a “living document” that is always being updated. If a new asset is deployed or an old system is decommissioned, that should be reflected within the inventory list.
 
These same inventory techniques will be used in the software section below, as the tools used will not only report what assets are live but also cover some of the software installed on them.
 
Software Inventory
 
In addition to knowing what hardware is on your network, you also need to know what software is in use. Not only this but knowing what’s allowed to be on your network is a key component. Having an up to date approved software list containing all software needed to perform day to day business ensures that your company is able to both prevent and detect unapproved software from being installed on devices. This same list can also be used to inform you of what versions of software should be in use on your network, when the software’s end of life date is (when the software will no longer receive patches from the developer), and if there is a limit to the number of licenses for the software.
 
This list will be used in conjunction with the software information gathered during the asset and software inventory to ensure that only approved software is in use throughout the network.
 
Patch Testing
 
After you know what you have you can then start the process of making sure everything is up to date. Vendors typically release patches on a regular schedule such as weekly, bi-monthly, or quarterly. Once a patch is released, it will need to be tested to ensure that the change does not cause any problems with any other program the patched software communicates with (looking at you Java). This testing should occur in an environment setup specifically for testing purposes that mimics the same hardware and software in the same manner as your organization’s production environment but does not house any actual data and is not utilized for core business functions. While testing these new patches, ensure that there are no problems relating to the software that is patched, the server the software is on, or any business-critical function.
 
Deployment
 
The final action of this process is deploying the patches. From here onwards, schedule a weekly or bi-weekly recurring patching and maintenance window.  This will be used for system updates and applying software patches. There are many different automated patching systems that can be used to aid you in this patch deployment. These patches should be manually verified to ensure they were successfully applied.
 

Vulnerability Management

 
The second practice to defend against software vulnerabilities we will be discussing is vulnerability management. This is a cyclical operation based on asset and software inventory, scanning or identifying vulnerabilities, prioritization, and remediation. The goal here is reduce the risk of an attacker exploiting a software-related vulnerability by detecting and remediating vulnerabilities within the environment.
 
Asset and Software Inventory
 
Asset and software inventory are also important components in a successful vulnerability management program. An effective inventory not only allows you to see and track assets, it also gives you information on the versions and patch levels of existing systems and software.  Without an accurate inventory you are blind to what exists within your environment, leading to vulnerabilities being missed and introducing a potential foothold to an attacker.
 
Scanning
 
After completing the asset and software inventory it is imperative to implement reoccurring authenticated network vulnerability scanning. This can be used to ensure that your software is being updated correctly, as well as give you an accurate view of any vulnerabilities that are present across your network. The frequency of these scans will depend on your organization’s security needs, however many of our clients use a window of between once a week and once a month. These vulnerability scans should be reviewed to confirm that any findings seen are accurate. Then you’ll want to begin research into potential remediations or mitigations to reduce the likelihood of them being exploited.
 
Prioritization
 
Once vulnerabilities have been identified you are going to want to prioritize them based on the risk to your organization. The way this is done varies but a few questions you should consider when doing so might include:

  • What is the likelihood of each vulnerability to be used in an attack on the environment?
  • What is the cost of recovery versus mitigation?
  • What is the likelihood that this vulnerability will be successfully used against the environment?
  • Is the threat from this vulnerability coming from inside or outside the environment’s security perimeter?
  • What is the criticality of the asset affected?

The answers to these questions will allow you to create a priority list for what vulnerabilities need to be fixed immediately and what should be fixed subsequently.
 
Remediation
 
Once vulnerabilities have been identified and prioritized, a remediation plan should be created.  Different software vulnerabilities will have different remediations or fixes – some may require a patch from the vendor while others require a configuration change, and some may not have a fix yet and will need to be mitigated until a patch is released. Mitigation strategies vary, depending on what they are but can often be as simple as segmenting affected assets to ensure that even if they are exploited the impact is minimal.
 

Third Party Assessments

 
Finally, you’ve got your entire process down and you are confident that you know what you have and you are prioritizing and fixing vulnerabilities as they come in. Now it’s time to test it. It’s important that this be performed by a third-party, because like many things, we become “nose-blind” to tasks that we deal with every day. You’ll want to engage a partner such as a Managed Security Services Provider to come in and either validate your efforts or show you areas in which you can improve. Just from my experience, some of the most confident companies have had some of the most egregious holes in their security. Not only will it validate and help improve your processes, but it may also alert you to advanced threats that you may be unaware of. These point-in-time assessments are crucial to ensure that you maintain a secure environment.
 
Software vulnerabilities won’t go away on their own, and if left unaddressed, the problem only compounds over time. They have the potential, if left unchecked, to provide an attacker complete ownership of a network. There are multiple other methods outside of what we’ve discussed here to protect against software vulnerabilities such as firewall logging, intrusion prevention systems, and access control policies to name a few. Both practices work well hand in hand, as vulnerability management helps to validate your efforts in patch management while patch management helps to remediate findings from vulnerability management. The two methods are effective practices towards protecting your organization from these software vulnerabilities and in turn, reducing the risk of an attacker compromising your network.
 
 

Chris Roth
Chris Roth is a Security Engineer with MAD Security. Chris has multiple years of experience in information technology and cybersecurity domains. He has broadly performed technical assessments focusing on web applications, networks, as well as firewall evaluations. Chris is also a former Staff Sergeant in the United States Marine Corps serving as a Platoon Sergeant for both a HiMARS and Fire Direction Center platoons throughout his career.