Vulnerability and patch management in the CISSP exam

This article is part of our CISSP certification prep series. For more CISSP-related resources, see our CISSP certification hub.

The purpose of the vulnerability assessment policy is to establish controls and processes to help identify vulnerabilities within the firm's technology infrastructure and information system components that could be exploited by attackers to gain unauthorized access, disrupt business operations and steal or leak sensitive data.

The purpose of the patch management policy is to identify controls and processes that will provide appropriate protection against threats that could adversely affect the security of the information system or data entrusted to the information system. Effective implementation of these controls will create a consistently configured environment that is secure against known vulnerabilities in the operating system and application software.

The CISSP certification covers the implementation and support of patch and vulnerability management in CISSP domain 7: Security operations.

Earn your CISSP, guaranteed!

Get live, expert CISSP training from anywhere. Enroll now to claim your Exam Pass Guarantee!

Get Pricing

Threat monitoring process

Threat monitoring is the ongoing process of gathering information about new and emerging threats to the IT assets.

• Enterprise security team must gather information on current, new and emerging threats. Threat information must include vendors’ notifications for threats, patches and system updates and security information exchanges including US CERT.
• The technologies tracked in the threat monitoring process must be determined from the types of technologies present in the inventory of Technology assets.
• Threats identified must be resolved according to the vulnerability remediation management.

Vulnerability assessment

Vulnerability assessments are point-in-time exercises intended to identify and analyze vulnerabilities associated with technology assets. Vulnerability assessments focus on current operations including process, procedure and state of technology assets.

Organizations must establish a formal program with defined roles and responsibilities for managing vulnerability scans and assessments, including:

• Development and management of vulnerability assessments processes and procedures
• Architecture reviews
• Security controls, limitations, network connections, and restrictions must be tested to assure conformance with applicable standards.
• Internal and external vulnerability scans must be run at least quarterly
  • Internal scans must also be conducted after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades)
  • A vendor certified by the payment card industry must perform quarterly external vulnerability scans. Scans conducted after network changes may be performed by the company’s internal staff
• Penetration testing must be conducted at least once a year and after any significant infrastructure or application upgrade or modification (e.g., major release, widespread upgrade of major router IOS version, change of border firewall vendor). Penetration testing must include:
  • Network-layer penetration tests
  • Application-layer penetration tests
• These processes and procedures must include follow-up actions leveraging the IT asset management data (e.g., configuration information, OS versions, and patch levels) to validate and track findings in order to determine appropriate remediation efforts.
• Vulnerabilities identified must be resolved according to the remediation management process.

Configuration management

Configuration Management is the practice of standardizing the configuration of similar technology assets based on documented configurations developed by subject matter experts in accordance with applicable policies and approved by functional leadership.

Organizations must document baseline configurations for all technology assets. These standards must:

• Be designed in compliance with applicable security requirements
• Be kept up to date by the functional areas responsible for the technology asset and
• Be integrated as part of the system build process and consistently enforced across all functional areas.

All technology assets must be configured consistent with the applicable baseline configuration.

Vulnerability remediation management

Vulnerability remediation Management is the practice of evaluating identified vulnerabilities, assigning risk based on likelihood and impact, planning an appropriate response, tracking the response through completion, and periodically verifying completion. Examples of processes that provide inputs to the Vulnerability Remediation Management process include Technology Risk Assessments, Threat Monitoring, and Vulnerability Assessments.

Organizations must evaluate the relevance of reported vulnerabilities and identify the associated risk to the organization's technology assets. The determination of risk must take into account:

• Hardware details, software versions, and the configuration of the organization's information systems as recorded in the asset inventory
• The likelihood of occurrence
• The impact of an occurrence and
• Any applicable compensating controls.

Respective stakeholders from an organization must be notified immediately when there is reason to believe there has been, or imminently will be, impact to the confidentiality, integrity, and/or availability of the production system.

All system components and software must have the latest vendor-supplied security patches installed within one month of approval by change management.

Organizations must identify an appropriate response to each technical vulnerability based on risk and the alternatives available. The response must consider the root cause(s) of the vulnerability. The technical vulnerability resolution may, among other things, include:

• Software release. If a software release is available to fix the vulnerability, it should be tested and deployed following proper change management processes. Depending on the urgency of the deployment, the change request may be submitted as an emergency change request.
• Compensating control. If no software release is available to address the vulnerability, or if the deployment of the software release is determined to create an unacceptable risk, alternative controls may be deployed to prevent the exploitation of the vulnerability. As in the case of the software release approach, an emergency change request may be appropriate. Examples of compensating controls include:
  • Changes to technical configuration and standards
  • Changes to processes

Earn your CISSP, guaranteed!

Get live, expert CISSP training from anywhere. Enroll now to claim your Exam Pass Guarantee!

Get Pricing

Vulnerability and patch: Detailed process

Identification

Processes must be in place to identify threats and vulnerabilities to an organization’s critical business information and associated hardware and internal security tools and services must be used to identify suspected or confirmed attacks against the organization’s business-critical information. This must include the following:

• Devices that detect and/or prevent known attacks
• Devices that monitor critical files and
• Devices that capture and analyze suspicious or unauthorized access

Penetration testing must be used to identify and confirm vulnerabilities on hardware and software that support the organization's business-critical information and systems (e.g., devices that require high availability). This must include the following:

• Annual external testing of network infrastructure and applications by independent penetration testers
• Annual internal testing of network infrastructure and applications by independent or trained penetration testers
• Testing of new hardware or software and after a significant change before going live or immediately after, e.g., major software release, new application, new product capability affecting confidential data access or management, to be carried out by independent and trained penetration
• Re-tests must be performed to confirm exploitable or ‘high’ risk vulnerabilities

Vulnerability scanning must be used regularly to identify vulnerabilities on hardware and software that support business-critical information and systems (e.g., devices that require high availability). This must include the following:

• Quarterly external scanning of internet-facing infrastructure and applications
• Quarterly internal scanning of infrastructure and applications on business-critical data environments
• Scanning after a significant change to hardware or software before going live or immediately after, e.g., major software releases, new application or new product capability changing how confidential data is accessed or managed
• Re-scanning infrastructure after ‘high’ vulnerabilities have been
• Quarterly wireless scanning for WLAN cards and portable wireless devices (e.g. USB) connected to systems, and wireless devices connected to a network port or system
• An incident response plan to deal with the discovery of unauthorized devices (on wired or wireless networks).

External sources must be used to identify threats and vulnerabilities that could impact the organization’s systems. This must include:

• Registration to threat intelligence services to provide early knowledge of potential threats or risk to brand
• Registration to vendor announcements and publications to provide details of known vulnerabilities and recommended patches or workarounds and
• Regular monitoring of both points above for applicability as per the business.

All vulnerability scans and penetration tests must have approval from system owners and any third parties that own devices being tested (e.g., ISPs or hosting providers).

IT operations must be made aware of vulnerability scans and penetration testing schedules and appropriate resources must be made available in the event of an issue with a test target.

Analysis

Roles and frequency:

Vulnerability management analysis meetings must take place at least monthly. Vulnerability management analysis meetings must include the appropriate individuals so that all device types with outstanding vulnerabilities with a CVSS number greater than 0 or rated as ‘high’ or ‘critical’ can be discussed.

A monthly process must exist to list identified vulnerabilities mapped to specific business-critical services.

Risk criteria

For devices storing, processing or transferring business-critical data:

• All vulnerabilities with a rating of ‘critical’, ‘high’ (as documented in Table 0) or with a CVSS number greater than 4.0 must have a mitigating action assigned; all other vulnerabilities must be assessed and action agreed on based on a risk-based decision.
• Critical’ or ‘high’ vulnerabilities must be mitigated within 3 days of the vulnerability being
• Vulnerabilities below ‘critical’ and ‘high’ but with a CVSS number greater than 0 must be mitigated within 90 days or justification documenting the risk-based decision not to.

For devices not storing, processing or transferring confidential data, a further risk-based decision must be used to agree on an appropriate mitigating

Risk mitigation list

An updated vulnerability list must be appended with a mitigating action, a date when the fix must be complete and an owner (e.g. Business, Application or Information owners) who will be responsible for the fix.

Fix

Configuration and testing

All standard changes (non-emergency changes) must successfully go through testing in non-production environments before being deployed. The testing must include a check to make sure other security tools or previous patches are not negatively affected when the new patch or workaround is deployed. Any vulnerability mitigation (e.g., patch deployment or workaround) must be entered into the change control systems and follow the change control protocol. Emergency mitigations must be authorized with the relevant team before being applied to the live environment.

Deployment

The vulnerability mitigation must be completed by the date listed. On successful completion of the testing, the relevant team must be notified. The change deployment process must have a roll-back option.

Monitoring

Re-scanning or re-testing must be conducted after fixes have been applied to devices to demonstrate that high-level vulnerabilities have been successfully addressed. A report or log file must be produced after deploying patches or workarounds to confirm successful completion. All vulnerability scanning or penetration testing incidents must be reported to the organization's security team.

The vulnerability mitigation list must be monitored by the security team and any outstanding vulnerabilities not fixed by the completion date escalated to them. In order to test access to confidential information, the following types of testing will be used.

External security vulnerability testing

External testing often begins with reconnaissance techniques that search public registration data, Domain Name System (DNS) server information, newsgroup postings, and other publicly available information to collect information (e.g., system names, Internet Protocol [IP] addresses, operating systems, technical points of contact) that may help the tester/assessor to identify vulnerabilities.

Depending on the protocols allowed through, initial attacks are generally focused on commonly used and allowed application protocols such as File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP) and Post Office Protocol (POP).

Servers that are externally accessible are tested for vulnerabilities that might allow access to internal servers and private information.

External security vulnerability testing also concentrates on discovering access method vulnerabilities, such as wireless access points, modems and portals to internal servers.

Internal security vulnerability testing

For internal security vulnerability testing, assessors work from the internal network and assume the identity of a trusted insider.

Internal security vulnerability testing is conducted by granting access to testers/assessors who will perform the testing on the application. These testers are often granted some level of access to the network, normally as general users, and are provided with information that users with similar privileges would have. This level of temporary access depends on the goals of the test and can be up to and including the privileges of a system or network administrator.

Working from whatever level of access they have been granted, testers/assessors attempt to gain additional access to the network and systems through privilege escalation — i.e., increasing user-level privileges to administrator-level privileges, or increasing system administrator privileges to domain administrator privileges.

Internal security vulnerability testing also focuses on system-level security and configuration—including application and service configuration, authentication, access control, and system hardening.

Earn your CISSP, guaranteed!

Get live, expert CISSP training from anywhere. Enroll now to claim your Exam Pass Guarantee!

Get Pricing

Overt/covert security vulnerability testing

Overt security vulnerability testing involves performing external and/or internal testing with the knowledge and consent of the organization’s IT staff, enabling comprehensive evaluation of the network or system security posture.

Covert security vulnerability testing, also known as black hat testing, takes an adversarial approach by performing testing without the knowledge of the organization’s IT staff but with the full knowledge and permission of upper management.