Building a Vulnerability Management Program with the End in Mind

Thinking about building a vulnerability management program? Unsure where to start? Unclear as to why your program might not be working? For some organizations, thinking about the end goal of the vulnerability management process can help provide clarity on how to improve your vulnerability management program. The purpose and the goal of the vulnerability management program is not to collect more vulnerabilities rather it’s to eliminate them from your organization. To do that requires patching and systems hardening.

Patch management is an incredibly complex discipline within enterprise IT. Some patching challenges include:

1. Timing of Patches

In a perfect world, patches are applied immediately. However, for most organizations this is not possible because of limited human capital to dedicate to the task. Additionally, many organizations struggle with their ability to test patches before applying them to production systems. While many organizations want to test all patches before applying them to their systems, realistically most organizations don’t have the time. Lastly, many organizations are drowning in their known vulnerabilities that they have to patch and manage. In this situation, many organizations are unable to appropriately prioritize and remediate their vulnerabilities.

2. Patch Bundling

Many software and system vendors have a responded to vulnerability management challenges by bundling many patches together. Some of these patch bundles are released monthly, some quarterly, some add another frequency. All of this is to reduce the overhead that comes with testing many different patches throughout the year. The concept of patch bundling is not without risk. Assembling an appropriate patch bundle can sometimes lengthen the time required to patch a known exploit. This gives potential attackers a longer attack window.

3. Vulnerability Exploit Blueprints

The release of any security patch is ostensibly admission to the fact that the vulnerability ability exists. The release of the systems patch may provide attackers the information that they need to exploit the corresponding vulnerability, one example is attackers who are able to reverse engineer the patch and learn how the vulnerability works and how to perform necessary exports. If the vulnerability is not being exploited then the organization should consider timing of the patch since the blueprint for the exploit now exists in the open. For some environments, we’re virtual hosts with snapshot capabilities are enabled, it may be preferable to patch without testing knowing the organization can roll back the patches if they cause usability or functionality problems.

4. Complete Installation

Many organizations struggle with timing of needing to reboot systems after applying a patch. In some cases to fully apply a patch to remediate a vulnerability the system sometimes needs to be rebooted. For systems that may not have been patched in a while, the patch you need may require applying other patches first.

Patch Management Tools

You should also consider is how patches are applied within your environment. Some examples are:

• A piece of software that may be able to automatically update itself.
• A centralized OS management tool that can either manually or automatically apply patches.
• Third-party patch management applications may be able to initiate patching.
• Or even manually applying software updates themselves.

Having multiple ways of applying patches can cause conflicts. When you have multiple systems, each system may try to patch the same software which can be problematic when an organization doesn’t want certain patches applied due to known issues with patches or inability to perform timely testing. Ideally, organizations should identify a single, established method for applying patches and configurations to the organizational systems.

The bigger issue, lies with the end-user and the users access to be able to control patch management configurations. Users that can override or circumvent patch management technologies can directly impact timely patching of systems. To prevent this from happening, organizations should control access and technical policies to appropriately control the users ability to manipulate patching.

System Architecture

When deciding on the correct architecture for your vulnerability management and patching program, it is important to consider the hosts that need protection with in your environment. Based on one host configuration over another, the architecture could introduce some significant challenges into managing your environment. Consider how the following environment scenarios might affect your vulnerability management patching program:

• Whether hosts are centrally managed or not
• Whether your host systems are within your enterprise network or off premise such as teleworkers or laptops
• Non-standard IT components such as appliances or applications
• Mobile devices, virtualized operating systems which are known in common to have different versions of operating systems
• Firmware updates such as system bios, which generally require a separate patching cadence in different procedures
  
  

Vulnerability Management Success Considerations:

A Complete Inventory of Software and Hardware

To be successful at vulnerability management and enterprise patch management, you need a current and complete inventory of systems. This will include hardware and a list of all the software on that hardware. Without this information, the correct patches cannot be identified, acquired, or installed. This inventory information is also necessary for identifying older versions of installed software. You will need to bring all older versions up to date. Updating older versions reduces the number of software versions that you must patch and test.

Resources

While patches have gotten better over the years, enterprise patch management activities can cause enterprise systems to become overloaded. If too many hosts start downloading the same patch bundle at the same time, you can saturate your network's bandwidth. For some organizations, staggering the delivery of patches is crucial to ensure availability of systems and network bandwidth.

Patch Feature Hygiene

More commonly, patches also include security feature enhancements. These feature enhancements must be generally understood so that you can appropriately configure the new system after the patch has been applied. Your organization should also be able to detect when security feature patch enhancements are being applied within the environment.

Purposeful Application of Patches

When an organization is applying and installing patches, those patches might not take affect until the affected software is restarted. Nowadays, it can be increasingly difficult to determine whether a patch requires a system reboot. One potential technique to validate whether a patch has been successfully applied or not is to perform a vulnerability scan or penetration testing after the patch has been applied to determine whether the vulnerability still exist with in your environment.

Whitelisting

Application whitelisting technologies have gotten better over the years. However, these technologies can also provide problems with either applying a patch or allowing the system to operate as intended afterwards. If you do not appropriately whitelist within your environment, many technologies allow the administrator to select certain services to be trusted updaters. This means that any files that are added or modified on a host are automatically added to the whitelist.

Vulnerability Scanning Considerations

When conducting a vulnerability scan within your environment to determine available patches or security misconfigurations, there are three common techniques to consider based on your host architecture configurations:

1. Agent Based Vulnerability Scanning

The first technique is using agent-based scanning technologies. Typically, each endpoint has an agent installed. That agent usually has administrative level credentials and is responsible for determining what vulnerable software is installed on the host. The agent then communicates back to the central vulnerability management program to give a consolidated view of the environment. Compared to agentless scanning and passive network monitoring, agent-based scanning technology is strongly preferred for hosts that are not on the local network at all time such as laptops and smart phones.

While agent-based vulnerabilities scanners have some positive features, there are also a few limitations that should be considered. Agent-based scanning technologies do not work well on hosts that do not permit direct administrator access to the operating system such as appliances. Also agents may not be available for all organizations platforms either for technical reasons or operating reasons such as medical devices or operational technology environments.

2. Agentless Vulnerability Scanning

The second technique is agentless scanning technologies. Agentless scanners usually have one or more servers or virtual servers that perform network scanning of each host and determine the vulnerabilities on those hosts. Generally speaking, agentless scanning requires an administrative credential to fully measure the security posture of that host. Many organizations, though, prohibit this type of credentialed scan. Without administrative credentials, many agentless scanners cannot adequately measure and capture the vulnerabilities on any one single host. The main preference for the scanning technology is that it does not require the installation and execution of an agent on each host.

One major limitation of agentless vulnerability scanners is they omit hosts not on the local network. This could include telecommuter laptops and mobile devices. Also, network security devices such as firewalls may inadvertently block scanning or negatively affect scan results. Agentless scanning may also negatively impact operations by consuming excessive amounts of bandwidth.

3. Passive Vulnerability Network Monitor

The third type of common scanning technologies is the passive network monitor. Passive network vulnerability technologies monitor local network traffic to identify applications that may contain vulnerabilities based on certain traffic characteristics. These technologies can effectively identify hosts that are not being maintained or scanned by agent based or agentless scanning devices. Passive network vulnerability monitors do not require any privileges on the host to be monitored, so they can be used to monitor the patch status of hosts that the organization does not control. The primary disadvantage of a passive network vulnerability monitor is that it only works with software where you can identify the version based on this network traffic, which assumes that the traffic is also on encrypted.

Security Risks in Maintaining a Vulnerability Management Program

It is occasionally heard that vulnerability management tools within an organization can create additional security risk. While some of this risk might be true the much greater risk is faced by an organization that does not run an effective vulnerability management and patching program. These tools and platforms usually increase security far more than they decrease security especially when vulnerability management tools contain built-in security measures to protect against security risks and threats. Some examples include:

• Credentials used for scanning might be misused. While this is a risk, Privilege Account Management tools such as CyberArk are designed to reduce this risk.
• Patching systems could introduce risk in that patches are altered or manipulated. This is a valid risk and has happened before so verify checksums before applying patches.
• Vulnerabilities in the patching solution may be exploited.

Patch deployment

Organizations should deploy enterprise patch management tools using a page to approach. The civil lowers process and user communication issues to be addressed to the small group before deploying the patch application university. Most organizations deployed patch management tools first to standardize desktop systems in single platform server farms of simile similarly configured servers. Once this has been accomplished, organization should address the more difficult issues of integrating multi platforms environments non-standard desktop systems, legacy computers, and computers with unusual configurations.

Justin founded NuHarbor Security in 2014 with the goal to provide end-to-end security services to clients. NuHarbor helps its clients design, implement, and sustain information security, compliance, and risk management programs. Justin’s innovation and thought leadership challenges traditional security methodologies to promote a new understanding of sustainable information security.