Cybersecurity Practice #7: Vulnerability Management (medium/large)

Modified on Wed, 14 Jun, 2023 at 2:32 PM

Organizations use vulnerability management to proactively discover vulnerabilities. These processes enable the organization to classify, evaluate, prioritize, remediate, and mitigate the technical vulnerability footprint from the perspective of an attacker. The ability to mitigate vulnerabilities before a hacker discovers them gives the organization a competitive edge and time to address these vulnerabilities in a prioritized fashion.26 


There are multiple types of vulnerability scanning. The most well-known methods are scans against servers (or hosts) and against web applications. These two scan types focus on different considerations.


 

Cybersecurity Practice 7: Vulnerability Management

  
 

Data that may

be affected

PHI

 

Medium Sub- Practices

    7.M.A   Host/Server Based Scanning

    7.M.B.  Web Application Scanning

    7.M.C.  System Placement and Data Classification

    7.M.D.  Patch Management, Configuration Management & Change Management

Large Sub- Practices

    7.L.A    Penetration Testing

    7.L.B.   Remediation Planning

 

Key Mitigated Risks

  • Ransomware Attacks
  • Insider, Accidental or Intentional Data Loss
  • Attacks Against Connected Medical Devices that May Affect Patient Safety

 

  


Sub-Practices for Medium-Sized Organizations

 

7.M.A

Host/Server-Based Scanning

NIST FRAMEWKORK REF:

DE.CM-8

In this model, vulnerability scanners are leveraged to identify weaknesses in OS or third-party applications that reside on a server. There are two scan options: unauthenticated and authenticated.


In the unauthenticated model, the scanner has no extra sets of server privileges and queries the server based on ports that are active and present for network connectivity. Depending on the level of sophistication of the software scanner, each server is queried and checked for vulnerabilities. Scan results provide the perspective of an attacker who lacks server access. Vulnerabilities that rate high in this space should be mitigated first, as they are the most likely points at which a hacker could enter the server.


Authenticated scans are conducted by letting the vulnerability scanner log in to the server and query all running software with all running versions. The resulting vulnerability lists are usually compared against a database (maintained by the scanner’s vendor), and vulnerabilities are enumerated based on the known software version’s disclosed issues. While this type of scanning provides a much higher degree of accuracy in enumerating vulnerabilities, it does not necessarily provide context that describes how the vulnerabilities might be exploited. An advantage of this type of scan is that it will identify client-side vulnerabilities that exist on the server and that may otherwise be difficult to discover, such as vulnerable versions of Java.

Most scanning systems can categorize vulnerabilities against the MITRE Common Vulnerability Scoring System (CVSS). The CVSS system helps organizations prioritize identified vulnerabilities, which enables development of a prioritized response. Version 3 of the system considers the following three factors: base score, temporal score, and environmental score. These factors, along with their sub-factors, are used to calculate vulnerabilities on a scale ranging from 1 to 10. For more information, refer to the CVSS Specification Document, available online.27

 

7.M.B

Web Application Scanning

NIST FRAMEWKORK REF:

DE.CM-8


In this model, specialized vulnerability scanners interrogate a running web application to check for vulnerabilities in the application design. Most web applications run dynamic code, run atop a web server, interact with middleware, and connect to databases. If the web application is not coded securely, this architecture may enable unanticipated access to data or systems.


Common web application attack types include Structured Query Language injection, cross-site scripting, and security misconfigurations. In these cases, attackers can

  • bypass web application security controls and pull data directly from the database;
  • steal an already authenticated cookie on a vulnerable website to get access; or
  • exploit misconfigurations that can permit properly formatted commands or scripts to execute privileged content on the webserver itself.


More information can be found on the Open Web Application Security Project’s Top 10 website.28

In all cases, vulnerabilities to web applications with sensitive information represent a high risk to the organization. It is important to understand these vulnerabilities to conduct appropriate and prioritized remediation.

 

7.M.C

System Placement and Data Classification

NIST FRAMEWKORK REF:

ID.RA-5


Organizations should apply Cybersecurity Practice #4: Data Protection and Loss Prevention and Cybersecurity Practice #5: IT Asset Management to understand IT assets and asset classifications. These cybersecurity practices answer the question, “How bad would it be if this asset were breached?”


It is important to understand the exposure of each system in your environment. Organizations should apply Cybersecurity Practice #6: Network Management to determine the likelihood that each this system can be compromised.

The level of risk related to vulnerabilities in your systems is directly related to the exposure of these systems and the types of data they contain.

 

7.M.D

Patch Management, Configuration Management, & Change Management

NIST FRAMEWKORK REF:

PR.IP-1, PR.IP-3, PR.IP-12


All organizations should have a routine to patch security flaws in their servers, applications (including web applications), and third-party software. Although the patching process may vary, large organizations should use centralized systems to interrogate servers and determine which software updates should be implemented.


At least monthly, organizations should implement patches that are produced by the vendor community. IT operations should collect these patches, conduct appropriate regression tests to ensure that patches do not negatively impact the business, and schedule patch implementation during routine change windows. This process should be executed and measured using standard IT operations activities.


Not all vulnerabilities are created equal. Some are easier to exploit than others. The National Vulnerability Database (NVD) has produced the CVSS, a standard measurement across all industries that normalizes and ranks the severity of a vulnerability.29


The more a vulnerability is exposed, the higher priority an organization will generally assign to mitigate it. Exposure may be a more critical variable than the potential impact to an asset, considering that hackers attempt to gain a foothold on organizational assets before conducting additional internal attacks. Another factor to consider is the level of active exploitability in the wild. A less-critical vulnerability may have an active threat against it. In such a case, an organization might want to consider proactively executing IR processes, organizing the response team, and quickly patching systems. The WannaCry exploit of 2017 was a classic example of organizations identifying an active threat and quickly implementing patches that were previously neglected30.


If your systems are running end-of-life OS or software, associated vulnerabilities should be identified and steps taken to bring these systems back to a supported state. This may include decommissioning systems that run on unsupported OS, which may require additional investments. Once systems are unsupported, it is usually impossible to apply security patches, potentially increasing the organization’s risk posture.


Table 8 provides general guidelines for planning remediation efforts based on criticalities.

Table 8. Recommended Timeframes for Mitigating IT Vulnerabilities

 

Vulnerability Criticality

Days to Mitigate in DMZ

Days to Mitigate in Data Center

Critical

< 14 days

< 30 days

High

< 30 days

< 90 days

Medium

< 90 day

< 180 days

Low

< 180 days

At your discretion


The vulnerability scanning process is a quality check on the effectiveness of an organization’s patch management practice, otherwise referred to as a lagging metric. Organizations with a robust patch management practice are better positioned to mitigate residual vulnerabilities.


In addition to conducting routine patch management activities, organizations should ensure that proper security configuration management activities are in place. Common vulnerabilities can be introduced in systems with insecure configurations. Examples of insecure configurations include permitting a file transfer protocol (FTP) server to allow anonymous login, making that login credential accessible to the internet, or failing to change default account passwords on applications. Organizations that follow Cybersecurity Practice #2: Endpoint Protection Systems and expand those practices to their servers will be positioned to minimize these issues. 

Lastly, consideration needs to be given to changes made to systems, servers, and networks, along with the vulnerabilities that may be exposed as a result. A testing plan should be part of the change management process. It should include a vulnerability scan of new network connectivity (such as a firewall change) or a new system function or service. This scan should be conducted during the test phase of the change process, before the change is implemented into the production environment. Such a process enables the identification and mitigation of security exposures.


Sub-Practices for Large Organizations

 

7.L.A

Penetration Testing

NIST FRAMEWKORK REF:

ID.RA-1, PR.IP-12,

DE.CM-8, RS.AN-5

In addition to vulnerability scanning, it is also important to consider conducting penetration tests. These types of tests are sometimes called red teaming; the goal is to actively exploit your own environment before malicious actors do. 


Penetration tests involve more than simply conducting vulnerability scans and attempting to exploit the findings. A proper penetration test should mimic the same attack methodologies that are deployed by the adversaries. Per SANS Critical Control #20, penetration testing involves mimicking the actions of computer attackers to identify vulnerabilities in a target organization, and exploiting them to determine what kind of access an attacker can gain. Penetration tests typically provide a deeper analysis of security flaws than a vulnerability assessment.31


Penetration tests should blend client-based, internet-based, web application–based, and wireless-based attacks. When selecting a testing method, consider the types of attacks that might occur most frequently against your organization. With these scenarios, you can test the resiliency of your cybersecurity program.


Penetration tests can be run internally by qualified individuals, or they can be run by external partners. No matter who will conduct the test, proper authority to perform the test must be documented, clearly defining the scope of the assets that may be tested, the methods that may be deployed, and the timing for conducting the tests. Assets and methods not permitted should be clearly articulated. This documentation is especially important if internal staff will conduct the test, and documentation may be necessary to comply with legal and HR obligations.

Multiple variations of penetration tests that can be conducted. Outlined in Table 9 are a few options for consideration. Review each of the factors in the table below and select what works best for your organization.

 

Table 9. Factors for Consideration in Penetration Test Planning

 

Factor

Options

Description

 

 

 

 

Type

 

  1. White box: Tester is permitted to know all aspects of the target
  2. Grey box: Tester is permitted to know some aspects of the target
  3. Black box: Tester is not permitted to know any details of the target

Depending on the type of test you want to conduct, it might be useful for the tester to already know some details of the target or organization. Such knowledge might reduce the effort of common reconnaissance activities, such as finding e-mail addresses for phishing targets or discovering all vulnerabilities on externally facing servers.


 

 

 

 

Resources

 

  1. External expert: A subject matter expert (SME) who specializes in the specific methodologies you wish to deploy
  2. Internal expert: A SME on an internal team who has context to the environment

Either type of resource can be useful. The benefit of using internal staff is that they understand the technical nuances of your environment. However, in some cases, targeted tests requiring specialized skillsets might be desired. External experts are useful in these cases, or when internal resources are committed to other activities.

 

 

 

 

 

 

 

 

 

 

 

 

Methods

  1. Social engineering: Attacks geared towards “tricking the human”
  2. Web application: Attacks centered on attacking web application infrastructure
  3. Host based: Attacks centered on attacking host infrastructure, inclusive of servers, or endpoints
  4. Client based: Attacks centered on attacking the client, such as laptops or desktops (usually bypassing perimeter protections)
  5. Network based: Attacks against the network infrastructure itself, such as physical connections or wireless attacks
  6. Privileged escalation: Once a foothold has been made, conducting secondary attacks to further escalate privileges for more lateral movement

Many methods exist; those listed here are common. These methods can be combined, based on the type of attack you are looking to carry out.

For example, if you want to see whether it is possible for an external attacker to gain access to your EMR, you might use social engineering, client-based, and privileged- escalation attacks. The goal of each of these attacks is to discover a user with sensitive EMR access, compromise the user’s credentials, and get remote access to the environment to be able to log in to the EMR with those credentials.

 

 

 

 

 

 

 

 

 

 

Targets

  1. Data: Discover and exfiltrate sensitive data to test data security controls
  2. IT assets: Compromise IT assets, such as servers or endpoints, to test system security controls
  3. People: Compromise individuals to test educational controls
  4. Medical technologies: Determine how vulnerable the organization is to attacks against medical devices
  5. Infrastructure: Determine how vulnerable the organization is to digital extortion attacks, such as ransomware outbreaks

Each test conducted should have different targets and goals in mind. In some cases, you might want to test how susceptible your user population is to phishing attacks- in that case, you will set “People” as the target. In other cases, you might want to understand how vulnerable your

organization is to a ransomware attacks; in that case, you might select “IT Assets” and “Infrastructure” as your targets/

 

 

 

7.L.B

Remediation Planning

NIST FRAMEWKORK REF:

PR.IP-12

It is important to classify and prioritize vulnerabilities that remain after completion of standard patch management practices. Typically, these remaining vulnerabilities are issues that cannot be mitigated with a patch. They may require system configuration changes, code updates, or perhaps even a full- blown version upgrade. The process of resolving these vulnerabilities tends to be more time-consuming and complex.


Like risk management activities, remediation efforts should be prioritized to resolve identified vulnerabilities. The most common practice is to first patch identified vulnerabilities and then rescan the system to validate that those vulnerabilities are closed. Most vulnerability scanning systems can track the opening, closure, and reopening of vulnerabilities over time. It is highly encouraged to track these metrics.


Mitigation of some vulnerabilities requires far more effort than a simple patch. In these cases, it is best to develop structured remediation plans that include the following elements:

  • Remediation owner: The single individual accountable for ensuring that the vulnerabilities are addressed. It is important to assign remediation plans to a single owner, otherwise they are likely to stall due to lack of leadership.
  • Plan: A full description of the remediation plan to be completed. The remediation plan owner and the information security office should develop this plan. Once the plan is approved, execution tasks can be started.
  • Stakeholders: The individuals responsible for completing tasks in the remediation plan, or organizing other individuals who will complete tasks. Stakeholders may include individuals who need to be informed of remediation activities as well as those who complete the work.
  • Dates: Major milestone dates and remediation plan due dates must be captured on the remediation plan. The remediation plan owner must commit to these dates.
  • Status: Periodically, the plan should be updated to remain current. Updating generally occurs between once per week and once per month. The remediation plan owner may be accountable for providing status updates.


After a remediation plan is completed, the organization’s information security office should implement a monitoring process. This monitoring process may include all remediation plans in progress and current activities. The security office may provide support to activities that are behind schedule. Consider engaging in such a monitoring process once per week to maintain momentum.

Threats Mitigated

  1. Ransomware attacks
  2. Insider, accidental or intentional data loss
  3. Attacks against connected medical devices that may affect patient safety

Suggested Metrics

  • Stacked aggregate of vulnerabilities in DMZ trended by month, with vulnerabilities categorized using CVSS categories (Critical, High, Medium, Low, None) and plotted as a simple stacked bar. The goal is to mitigate the most severe vulnerabilities first, through patching and configuration management. Of the remaining vulnerabilities, the most critical should be mitigated within 30 days. The total number of vulnerabilities should be reduced over time.
  • Stacked aggregate of vulnerabilities in data center trended by month, with vulnerabilities categorized using CVSS scores and plotted as a simple stacked bar. The goal is to mitigate the most severe vulnerabilities first, through patching and configuration management. The total number of vulnerabilities should be reduced over time.
  • Number of unmitigated new vulnerabilities introduced into the environment trended by week. The goal is to keep the number of new vulnerabilities as low as possible, defined by your organization’s level of risk tolerance.

 

26. “CIS Control 3: Continous Vulnerability Management,” Center for Information Security Controls, accessed September 24, 2018, https://www.cisecurity.org/controls/continuous-vulnerability- management/.

27. “Common Vulnerability Scoring System v3.0: Specification Document,” FIRST, accessed September 24, 2018, https://www.first.org/cvss/specification-document.

28. OWASP Top 10 - 2017: Ten Most Critical Web Application Security Risks, OWASP, 2017, https://www.owasp.org/images/7/72/OWASP_Top_10_2017_%28en%29.pdf.pdf.

29. “CVSS,” NIST National Vulnerability Database, accessed September 24, 2018, https://nvd.nist.gov/vuln-metrics/cvss.

30. “Report. The IT Response to WannaCry,” accessed September 30, 2018, https://www.techrepublic.com/article/report-the-it-response-to-wannacry/.

31. “CIS Control 20. Penetration Tests and Red Team Exercises,” Center for Internet Security, accessed September 24, 2018, https://www.cisecurity.org/controls/penetration-tests-and-red-team-exercises/.




Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article