Vulnerability & Patch Management Process

1. Introduction

A vulnerability is defined in the ISO 27002 standard as “A weakness of an asset or group of assets that can be exploited by one or more threats” (International Organization for Standardization, 2005)[1]

It is essential, in today’s society, for businesses to have an online presence in order to be fully capable of engaging in e-commerce and stay competitive. As a result, it’s imperative that businesses protect their data and put IT security at the forefront of everything they do online and off. With the advancement of new technologies comes opportunities for businesses to fall victim to scams through various attack vectors some of the most popular being social engineering and online computer network infiltrations.

Risk is the primary driving force for vulnerability management and as such organizations need to begin the process by performing risk assessments. A good starting point is for organizations to perform a Business Impact Analysis (BIA) for critical business functions. Among the many considerations in helping prioritize core business functions include, impact to revenue streams, and legal/regulatory compliance. The successful exploitation of vulnerabilities pulled off by attackers are driven by external factors, which so happens to be unquantifiable by any means including, rate and time of occurrences, what specific systems will be affected, and as a result, the costs associated with unknown factors.

The difference between patch management and vulnerability management is that vulnerability management is a proactive approach to mitigating specific threats through software testing and patch management is the process of acquiring, testing, and installing patches based on decisions made through the use of network security bulletins.

Patch Management

Discovery of vulnerabilities through security advisories.

Vulnerability Management

Discovery of vulnerabilities through software testing.

For example, an organization would perform a vulnerability assessment, using tools such as Nessus, Nexpose, or OpenVAS, to discover software vulnerabilities that exist within a network, which would subsequently be patched based on pre-established prioritizations.

1.1. Why Vulnerability & Patch Management is required?

In today’s society, it’s essential for business to have an online presence and be fully capable of engaging in e-commerce in order to stay competitive. As a result, it’s imperative that businesses protect their data and put IT security at the forefront of everything they do online and off. With the advancement of new technologies comes opportunities for businesses to fall victim to scams through various attack vectors some of the most popular being social engineering and online computer network infiltrations.

In an effort to control security risks inherent within information security, organizations must include an adequately prepared vulnerability management process. This will allow organizations to have continuous overview of any vulnerabilities and associated risks that may exist within their IT infrastructure. The only way to help prevent attackers from stealing valuable information is to mitigate identified vulnerabilities within and IT infrastructure before they become exploited attacks.

1.2. Vulnerability Scanners

There are many tools available for performing vulnerability assessments. Due to the absence of any prior assessment data, I would suggest performing a full assessment that will include data for implementing a vulnerability management process in addition to the creation of an IT security policy. I would recommend prioritizing any identified vulnerabilities based on threat levels specific to mission critical business operations. This will be based on the severity level and impact of the vulnerability, more specifically, how it relates to the current business operations. The availability of the exploit will also be a determining factor.

Some systems of classes that exist for computer and network vulnerabilities include implementation vulnerabilities, design vulnerabilities, operational vulnerabilities, and grey areas.

²Implementation vulnerabilities
- Code that’s not performing as designed. There’s typically a security issue involved in the way operations are carried out.
²Design Vulnerabilities
- A fundamental mistake, flaw, or oversight in software’s design.
[2]Operation vulnerabilities
- Security problems that arise from flawed operational procedures and general use of software used in a specific environment.

Mitigating identified vulnerabilities is only a good first step. Good vulnerability assessments can spur sound IT security policy that aligns with organizational requirements as well as providing administrators a consistent baseline upon which to work from while conducting future assessments.

1.3. Associated risks

Attention to be drawn to the risks associated with the negative effects a network may endure during testing, in particular, scanning. Network scans are an essential component to vulnerability discovery and therefore are a necessary requirement. Network scanning can be a very intrusive process that introduces a large number of crafted data packets into a network that the network may react negatively to with the potential of triggering alerts, alarms, and possible denial of service conditions. With this in mind, the vulnerability scanning process is limited to scanning only; therefore, risks of actual exploitation are minimal at best. This is a good reason why it’s critical to inform all of the various stakeholders within your organization before and during the scanning phase of vulnerability testing.

1.4. Classifying Vulnerabilities

Some systems of classes that exist for computer and network vulnerabilities include Implementation vulnerabilities, design vulnerabilities, operational vulnerabilities, and grey areas. For the remainder of this discussion I chose to talk about implementation vulnerabilities because I think it’s most practical to confront the problem during the implementation process. It’s easier to pull a sapling out of the ground than removing a mature redwood. The same can be said about computer and network security, where the largest number of vulnerabilities is most prevalent in web-servers and online communications.

Insecure software code tends to traverse through the software development life-cycle unchecked in many cases leading to one of the number one known vulnerabilities today, SQL Injection. Insecure programming code is, in most cases, the result of “rush to market” product practices. The problem is systemic and there is a culture that exists where secure code takes a backseat to profit margins. As the old adage goes, “Security comes at the cost of convenience” and in many cases profit margins. The majority of problems could be fixed rather easily if solutions where to be implemented during the appropriate stages of the SDLC. Such remedies could include input sanitization and parameterized queries. One of the big ones is white listing input validation. Secure code has never been a consideration in coding schools and therefore hasn’t been at the forefront of software engineering. The majority of these problems exist principally within the C, C++, and Java languages.

One of the most prominent and influential means of classifying implementation vulnerabilities that would allow defenders to granulize and prioritize vulnerabilities with greater detail is the Common Vulnerabilities and Exposures (CVE) database. There are actually many benefits to using this system including vulnerability classification, severity score, detailed descriptions, and references to additional pertinent information. In contrast to that, there are criminal hackers who also utilize these same types of vulnerability databases in anticipation of exploiting unpatched systems. It’s unfortunate that there exist many organizations large and small that will inherently delay patch updates for precarious reasons but, for the most part, these vulnerability databases to tend to help curb the epidemic spread of well-documented vulnerabilities.

1.5. Vulnerability & Patch Management Prioritization

The interrelationships between patch management processes and risks are the tools designed to aid network defenders in making appropriate decisions in regards to risk mitigation. Risk is the combination of probability and consequence.

The resultant prioritizations are based decisions that affect the amount of risk your organization is ultimately exposed to. Vulnerabilities marked as high are susceptible to targeted distribution that could put all of your servers at risk of compromise with an extreme probability. Compromised systems will lead to subsequent violations in regards to any legal and regulatory requirements that would have a huge impact on the viability of the business.

(General risk equation) Risk = Likelihood x Impact

Factors for estimating likelihood include:

[3]Threat Agent Factors:

(Skill Level) Security penetration skills (9), network and programming skills (6), advanced computer user (5), some technical skills (3), no technical skills (1).
(Motive) Low or no reward (1), possible reward (4), high reward (9).
(Opportunity) Full access or expensive resources required (0), special access or resources required (4), some access or resources required (7), no access or resources required (9).
(Size) Developers (2), system administrators (2), intranet users (4), partners (5), authenticated users (6), anonymous Internet users (9).

³Vulnerability Factors

(Ease of Discovery) Practically impossible (1), difficult (3), easy (7), automated tools (9).
(Ease of Exploit) Theoretical (1), difficult (3), easy (5), automated tools available (9).
(Awareness) Unknown (1), hidden (4), obvious (6), public knowledge (9).
(Intrusion Detection) Active detection in application (1), logged and reviewed (3), logged without review (8), not logged (9).

[4]Figure 1: (OWASP) Determining the Likelihood and Impact levels of the Risk

Factors for estimating Impact include:

⁴Technical Impact Factors

(Loss of Confidentiality) Minimal non-sensitive data disclosed (2), minimal critical data disclosed (6), extensive non-sensitive data disclosed (6), extensive critical data disclosed (7), all data disclosed (9).
(Loss of integrity) Minimal slightly corrupt data (1), minimal seriously corrupt data (3), extensive slightly corrupt data (5), extensive seriously corrupt data (7), all data totally corrupt (9).
(Loss of availability) (1), minimal primary services interrupted (5), extensive secondary services interrupted (5), extensive primary services interrupted (7), all services completely lost (9).
(Loss of accountability) Are the threat agents’ actions traceable to an individual? Fully traceable (1), possibly traceable (7), completely anonymous (9).

⁴Business Impact Factors

(Financial damage) Less than the cost to fix the vulnerability (1), minor effect on annual profit (3), significant effect on annual profit (7), bankruptcy (9).
(Reputation damage) Minimal damage (1), Loss of major accounts (4), loss of goodwill (5), brand damage (9).
(Non-compliance) Minor violation (2), clear violation (5), high profile violation (7)
(Privacy violation) One individual (3), hundreds of people (5), thousands of people (7), millions of people (9).

[5]Figure 2: (OWASP) Determining the overall Severity of the Risk

Many regulatory agencies require organizations to meet, at a minimum, the requirements laid out by the CIA triad (confidentiality, integrity, and availability). In addition, Vulnerabilities with a rating of high also present a high probability of congruent systems being affected, which could include partner and customer networks. If your organization does not address these vulnerabilities first, the likelihood of attackers attempting these exploits are extremely high and therefore should be at the forefront of your organization’s patch management strategy.

2. Vulnerability & Patch Management Process

2.1. Objective

This document is intended to assist in executing a vulnerability and patch management program to help detect and remediate vulnerabilities that may exist within your organization. Not performing scans regularly introduces your network to many unforeseen threats and increases your network’s risk to an attack and subsequent loss of private and confidential data. It’s critical for your organization to establish scan schedules based on the prioritized level of risk. Performing quarterly or annual only scans presents a snapshot of an organization’s security posture over an extended period of time.

[6]Figure 3: Vulnerability Scanning Annual Life-cycle

Figure 3 above shows a potential vulnerability life-cycle performed on an annual basis. Vulnerabilities introduced into a network during an annual scan life-cycle could present an issue to the safety of a network like a ticking time bomb that leaves a system vulnerable until the next annual scan cycle rolls around. This unnecessarily increases exposure time of the network vulnerability to potential exploitation.

[7]Figure 4: Continuous Vulnerability Management

It is better to implement a short vulnerability scan lifecycle routine as seen below in figure 4. Shorter interval scans that are performed on a regular basis dramatically decrease the exposure time of network vulnerabilities in addition to allowing quicker remediation.

2.2. Roles and responsibilities

Part of the vulnerability and patch management process is to create a group of individuals who are tasked with the implementation and oversight of the vulnerability and patch management program. Listed below are some of the minimum roles and responsibilities that should assigned by an organization:

Security Officer: Owner and designer of the vulnerability management process who ensure that it’s properly implemented.
Vulnerability Engineer: Responsible for vulnerability scanning configurations and scheduling.
Asset Owner: Responsible for assets that are scanned and decide whether an identified vulnerability should be mitigated or if the associated risks should be accepted.
IT System Engineer: Usually responsible for executing remediation attempts as a result of identified vulnerabilities.

2.3. Vulnerability Management Process: Step-by-Step

The typical vulnerability management process constitutes five basic phases:

(Phase 1) Preparation
(Phase 2) Vulnerability scan
(Phase 3) Define remediating actions
(Phase 4) Implement remediating actions
(Phase 5) Rescan

2.3.1. Preparation

[8]Figure 5: Vulnerability Management – Preparation (Phase 1)

It is preferred to start with a small project scope in order to avoid potentially being bombarded with thousands of scans. A good start is to limit the number of systems to be scanned, which limits the number of vulnerabilities discovered by the vulnerability scanner. This can be accomplished by scanning only vulnerabilities for which there are known exploits, which will allow the security team to start mitigating the highest priority threats first.

The security officer within an organization is primarily responsible for the preparation phase. One of the first tasks to be performed is defining the scope of the overall process, which includes obtaining written agreements that define what systems are to be included or excluded from the overall process. The agreements should also spell out what particular types of scans are authorized, such as external or internal, and whether authentication is required or not.

External scanning reveals security vulnerabilities visible from outside of the network, which takes into account all defensive layers that, divide the target from the scanner’s point of origin. Various layers of defense that are tested by external vulnerability scanning include: (web) application firewalls, network firewalls, intrusion detection systems, and host based security controls present on target machines. External scan results provide an accurate picture of security controls currently in place on the network.

Internal network scans provide an overview of vulnerabilities that are visible from inside the network and takes into account host based security controls on target machines. The results of scans performed at each element, within a given network architecture, reveals the adequacy of the security controls currently in place in addition to the quality of defense-in-depth strategy used. A planning spreadsheet, as seen in figure 6 below, is a basic example of required information that should be collected prior to beginning the scanning process.

[9]Figure 6: Planning Spreadsheet

The viability of an organization’s interdepartmental communications, which is willing to accept certain risks, plays a critical role in the vulnerability management process. If an organization chooses to accept certain risks, due to limited resources for instance, then the scope of the vulnerability management process can be altered to exclusively consider high-risk vulnerabilities with known exploits only. This affords the opportunity to forgo expending efforts towards low-risk vulnerabilities to the detriment of high-risk vulnerabilities.

2.3.2. Initial Vulnerability Scan

[10]Figure 7: Vulnerability Management Process – Initial Scan Phase

Issues that may have been identified during the initial scans should be documented for reference during future scans. Issues that may arise during the scanning process include slow system response and/or, in more extreme cases, system crashes. All documented issues should be delineated in order to prevent the repeated negative impact of future scans against production systems in a live environment.

The bulk of vulnerability scanning tools offer various reporting formats and visual aids of scan results making it easier to create various types of reports for different business units within an organization. The security officer and management both have a vested interest in the overarching security risks the organization may be facing. These risks include any number of vulnerabilities and their associated severity/risk ratings. Additionally, asset owners will have to be provided with a summary of all vulnerabilities for systems that they are responsible for. Lastly, the IT department will require the production of a technical summary for all detected vulnerabilities in addition to suggestions for mitigation and improvements.

2.3.3. Remediation phase

[11]Figure 8: Vulnerability Management Process – Remediation Phase

During the remediation phase, the asset owners in collaboration with the security officer and IT department should outline remediating actions. The table in figure 9 below is an example of possible mitigation timeframes that may be used depending on the types of risks that have been identified.

[12]Figure 9: Overview of Possible Mitigation Timeframe

It is the responsibility of the security officer to track and ensure proper implementation of planned remediation activities, which can be managed through the use of a simple spreadsheet. Tracking relevant changes during the remediation process can be performed through the service desk system. Lastly, vulnerability scanners contain specific modules that can provide status in regards to remediation activities. As a good rule of thumb, risk waivers should have time restrictions placed upon them ensuring that frequent re-evaluations of risks are performed on a regular basis.

2.3.4. Implement remediating actions

[13]Figure 10: Vulnerability Management Process – Implement Remediating Actions

Remediation activities should be deployed inline with pre-established timeframes and if any issues arise during remediation activities they should be documented. The asset owner, based on recommendations provided by the security officer and IT department, should then define alternative actions and implement them. Lastly, the security officer must monitor the progress of all remediation events.

2.3.5. Rescan

[14]Figure 11: Vulnerability Management Process – Rescan Phase

In order to properly verify the implementation of remediation activities a rescan should be scheduled. All rescans should be performed utilizing the same tools and configuration settings that were used during the initial vulnerability scans. This process helps eliminate inaccurate data due to potential configuration errors. Rescans are typically scheduled after remediation efforts have been concluded. The same types of reports that were generated for the initial scans should also be generated for the rescans. The security department, management, and asset owners will all be interested in how well the remediation actions were implemented. Management and the asset owners will also be interested to know if there are any persistent residual risks still lingering.

An agreement between the security officer and asset owners should be established to define how often scans should be performed. Once a scan schedule has been agreed upon by both parties, the timeframe should take into account the amount of risk the organization is willing to accept, in addition to, the organization’s capacity to remediate vulnerabilities that have been identified. Practical vulnerability management processes should consist of frequent scans, which are typically performed on a weekly or monthly basis, that ensure rapid detection and adequate time to deploy mitigating controls.

Lastly, lessons learned during the execution of the overall process provide good insight into the ability of the IT organization’s ability to handle future requests. Lessons learned also provide direction upon which to improve the overall vulnerability management process as a whole.

3. Security Metrics for Patch and Vulnerability Management

3.1 Types of Patch and Vulnerability Metrics

This section outlines the process designed to develop and implement a patch and vulnerability metrics program. It is critical for organizations to have the capability to measure the effectiveness of its patch and vulnerability management program frequently and apply corrective actions when necessary. There are three main categories of patch and vulnerability management metrics:

Susceptibility to attack
Mitigation response time
Cost

3.1.1. Susceptibility to attack

There are several measurements that can be used to approximate an organization’s susceptibility to an attack. Organizations have the ability to measure the number of vulnerabilities, number of patches needed, and number of network services running on a per system basis. Each individual measurement taken from each computer within the system can then be combined to determine system wide results.

3.1.2. Mitigation Response Time

The time it takes for an organization to identify, classify, and respond to new vulnerabilities and mitigate them has a direct impact upon the organization’s incident recovery time. Since the average time between the announcement of a vulnerability and the release of an exploit has dramatically decreased in recent times, it is of the utmost importance for organizations to reduce response times. The three main time measurements that can be taken are: emergency security configuration changes, patch application, and patch identification.

3.1.3. Cost

Since costs are split between various personnel, groups, and departments, it is often difficult to measure the expenses involved in the patch and vulnerability management process. Although there will be a centralized group dedicated to deploying patches and security configurations it is possible to split those functions between multiple groups. The four main cost measurements are: enterprise patch and vulnerability management tools, patch and vulnerability management group, system administrator support, and incidents as a result of failed patch and vulnerability management processes.

4. Information Sharing Methodology

The Community Attack model is based on the principle of community policing where everyone gets involved in the sharing of information including the cooperation among various business units within an organization. This includes the assembling and distribution of actual attack events that have been put into an easily understandable defensive action plan with reliable mappings to remedial references.

A useful list of essential attributes for any security model will include:

Open and negotiable
Low cost (preferably community shared)
Continuous validated defense updates
Easily translatable attack-to-action controls

Keep in mind that this list is not comprehensive in any way but should be viewed as a guideline to aid organizations in formulating more specific goal based policies with prioritization in mind. Community policing demonstrates best practices in combating exterior and interior threats alike when interdepartmental communication channels are establish and unimpeded.

Device inventory is a good starting point before security measures are put in place with the appropriation of network defenses. Besides the technical aspects related to defense in depth strategies, the human factor plays the biggest role in attack mitigation. “You Are the Firewall” is a key concept that helps engage employees in becoming a part of the solution, instead of the problem. With these key concepts in mind, your organization will be on the path to a more secure and well-defended network.

5. Conclusion

The lack of a sound vulnerability management process renders an organization blind and defenseless against security related risks to their IT infrastructure and the negative consequences that will follow. The primary objective of any good vulnerability management process is the mitigation of risk. By having a well-defined vulnerability management procedure in place organizations will have an unobstructed view of risks associated with the presence of security vulnerabilities within its IT infrastructure. Management will have the ability to make prudent decisions before deciding to take action to remediate risks associated with specific vulnerabilities. In the end, a good vulnerability management program provides an organization with a good understanding of the potential security risks their IT infrastructure faces at any particular point in time allowing them to act before real harm can be done by real attackers.

“Prevention is ideal but detection is a must” Although there are some common characteristics, every attack is unique. With the advent of emerging technologies, Internet of Things for example, organizations cannot afford to become complacent with static security infrastructure methodologies. The need to adapt to new and emerging threats perpetuates change in IT security policy. It is a never-ending cycle that requires full cooperation between all interdepartmental entities. This means that business units and security teams have to join forces and be distinctly aligned in enforcing IT security policy.

“Offense Informs Defense” To defeat the enemy, one must think like the enemy. Through observation of actual attacks, network defenders can articulate better defenses comprised of practical systems design. Security controls should include current attack vectors to stop real-world attacks.

These philosophies are at the forefront of any good threat management program and vital to their success. The modern threat landscape is evolving and keeping up with rapid change in technology is difficult at best and gives the advantage to attackers. An attacker has to only commit one exploit to be successful but network defenders have to stop every attack. The odds are overwhelmingly stacked against network defenders, which is why it’s crucial for organizations to implement sound IT security policies.

Preparedness is key, in that; your organization must continuously analyze attack data from leading IT security vendor’s threat reports. This help ensures your organization’s security controls sufficiently align with the most prevalent threats of today and tomorrow, which ultimately helps increase your organization’s overall security posture.

6. References

Tenable Network Security. (2016, August 17). Nessus 6.8 User Guide. Retrieved December 20, 2016, from http://static.tenable.com/prod_docs/Nessus_6.8_User_Guide.pdf

Souppaya, M., & Scarfone, K. (2013, July). Guide to Enterprise Patch Management Technologies. Retrieved December 20, 2016, from http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r3.pdf

ISO/IEC, “Information technology — Security techniques – Code of practice for information security management ” ISO/IEC 27002 Palmaers, T., & Distler, D. (2013, March 23). Implementing a vulnerability management process. Retrieved December 20, 2016, from https://www.giac.org/paper/gsec/32851/implementing-vulnerability-management-process/112555

Meunier, P. (2016, November). Classes of Vulnerabilities and Attacks. Retrieved November, 2016, from http://homes.cerias.purdue.edu/~pmeunier/aboutme/classes_vulnerabilities.pdf

OWASP. (2016, March 26). OWASP Risk Rating Methodology. Retrieved December 22, 2016, from https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology

Mell, P., Bergeron, T., & Henning, D. (2005, November). Retrieved December 22, 2016, from http://csrc.nist.gov/publications/nistpubs/800-40-Ver2/SP800-40v2.pdf

Kelley, D. (2012, 10). Five tips to improve a threat and vulnerability management program. Retrieved from techtarget: http://searchsecurity.techtarget.com/tip/Five-tips-to-improve-a-threat-and-vulnerability-management-program

Milea, D. (2013, 11 29). Prevention is Ideal, but Detection is a Must. Retrieved from medium.com: https://medium.com/@demetriom/prevention-is-ideal-but-detection-is-a-must-13bcdc8e4ab9#.ab6xmh58m

[1] ISO/IEC, “Information technology — Security techniques – Code of practice for information security management ” ISO/IEC 27002

[2] Meunier, P. (2016, November). Classes of Vulnerabilities and Attacks. Retrieved November, 2016, from http://homes.cerias.purdue.edu/~pmeunier/aboutme/classes_vulnerabilities.pdf

[3] OWASP. (2016, March 26). OWASP Risk Rating Methodology. Retrieved December 22,

2016, from https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology

[4] OWASP. (2016, March 26). OWASP Risk Rating Methodology. Retrieved December 22,

2016, from https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology

[5] OWASP. (2016, March 26). OWASP Risk Rating Methodology. Retrieved December 22,

2016, from https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology

[6] Palmaers, T., & Distler, D. (2013, March 23). Implementing a vulnerability management process. Retrieved December 20, 2016, from https://www.giac.org/paper/gsec/32851/implementing-vulnerability-management-process/112555

[7] Palmaers, T., & Distler, D. (2013, March 23). Implementing a vulnerability management process. Retrieved December 20, 2016, from https://www.giac.org/paper/gsec/32851/implementing-vulnerability-management-process/112555

[8] Palmaers, T., & Distler, D. (2013, March 23). Implementing a vulnerability management process. Retrieved December 20, 2016, from https://www.giac.org/paper/gsec/32851/implementing-vulnerability-management-process/112555

[9] Palmaers, T., & Distler, D. (2013, March 23). Implementing a vulnerability management process. Retrieved December 20, 2016, from https://www.giac.org/paper/gsec/32851/implementing-vulnerability-management-process/112555

[10] Palmaers, T., & Distler, D. (2013, March 23). Implementing a vulnerability management process. Retrieved December 20, 2016, from https://www.giac.org/paper/gsec/32851/implementing-vulnerability-management-process/112555

[11] Palmaers, T., & Distler, D. (2013, March 23). Implementing a vulnerability management process. Retrieved December 20, 2016, from https://www.giac.org/paper/gsec/32851/implementing-vulnerability-management-process/112555