ISO 27001:2022 A 8.8 Management of technical vulnerabilities

Audio version of the article

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”. Vulnerability management is the process in which vulnerabilities in IT are identified and the risks of these vulnerabilities are evaluated. This evaluation leads to correcting the vulnerabilities and removing the risk or a formal risk acceptance by the management of an organization (e.g. in case the impact of an attack would be low or the cost of correction does not outweigh possible damages to the organization). The term vulnerability management is often confused with vulnerability scanning. Despite the fact both are related, there is an important difference between the two. Vulnerability scanning consists of using a computer program to identify vulnerabilities in networks, computer infrastructure or applications. Vulnerability management is the process surrounding vulnerability scanning, also taking into account other aspects such as risk acceptance, remediation, etc. Depending on the size and structure of the organization, the approach to vulnerability scanning might differ. Small organizations that have a good understanding of IT resources throughout the enterprise might centralize vulnerability scanning. Larger organizations are more likely to have some degree of decentralization, so vulnerability scanning might be the responsibility of individual units. Some organizations might have a blend of both centralized and decentralized vulnerability assessment. Regardless, before starting a vulnerability scanning program, it is important to have the authority to conduct the scans and to understand the targets that will be scanned. Vulnerability scanning tools and methods are often somewhat tailored to varied types of information resources and vulnerability classes. The table below shows several important vulnerability classes and some relevant tools.

Common Types of Technical Vulnerabilities	Relevant Assessment Tools
Application Vulnerabilities	Web Application Scanners (static and dynamic), Web Application Firewalls
Network Layer Vulnerabilities	Network Vulnerability Scanners, Port Scanners, Traffic Profilers
Host/System Layer Vulnerabilities	Authenticated Vulnerability Scans, Asset and Patch Management Tools, Host Assessment and Scoring Tools

Information systems should be regularly reviewed for compliance with the organisation’s information security policies and standards. Automated tools are normally used to check systems and networks for technical compliance and these should be identified and implemented as appropriate. Where tools such as these are used, it is necessary to restrict their use to a few authorized personnel as possible and to carefully control and coordinate when they are used to prevent compromise of system availability and integrity. Adequate

Control

Information about technical vulnerabilities of information systems in use should be obtained, the organization’s exposure to such vulnerabilities should be evaluated and appropriate measures should be taken.

Purpose

To prevent exploitation of technical vulnerabilities.

ISO 27002 Implementation Guidance

Identifying technical vulnerabilities
The organization should have an accurate inventory of assets as a prerequisite for effective technical vulnerability management; the inventory should include the software vendor, software name, version numbers, current state of deployment (e.g. what software is installed on what systems) and the person within the organization responsible for the software. To identify technical vulnerabilities, the organization should consider:

1. defining and establishing the roles and responsibilities associated with technical vulnerability management, including vulnerability monitoring, vulnerability risk assessment, updating, asset tracking and any coordination responsibilities required;
2. for software and other technologies (based on the asset inventory list,), identifying information resources that will be used for identifying relevant technical vulnerabilities and maintaining awareness about them. Updating the list of information resources based on changes in the inventory or when other new or useful resources are found;
3. requiring suppliers of information system (including their components) to ensure vulnerability reporting, handling and disclosure, including the requirements in applicable contracts ;
4. using vulnerability scanning tools suitable for the technologies in use to identify vulnerabilities and to verify whether the patching of vulnerabilities was successful;
5. conducting planned, documented and repeatable penetration tests or vulnerability assessments by competent and authorized persons to support the identification of vulnerabilities. Exercising caution as such activities can lead to a compromise of the security of the system;
6. tracking the usage of third-party libraries and source code for vulnerabilities. This should be included in secure coding .

The organization should develop procedures and capabilities to:

1. detect the existence of vulnerabilities in its products and services including any external component used in these;
2. receive vulnerability reports from internal or external sources.

The organization should provide a public point of contact as part of a topic-specific policy on vulnerability disclosure so that researchers and others are able to report issues. The organization should establish vulnerability reporting procedures, online reporting forms and making use of appropriate threat intelligence or information sharing forums. The organization should also consider bug bounty programs where rewards are offered as an incentive to assist organizations in identifying vulnerabilities in order to appropriately remediate them. The organization should also share information with competent industry bodies or other interested parties.

Evaluating technical vulnerabilities
To evaluate identified technical vulnerabilities, the following guidance should be considered:

1. analyse and verify reports to determine what response and remediation activity is needed;
2. once a potential technical vulnerability has been identified, identifying the associated risks and the actions to be taken. Such actions can involve updating vulnerable systems or applying other controls.

Taking appropriate measures to address technical vulnerabilities
A software update management process should be implemented to ensure the most up-to-date approved patches and application updates are installed for all authorized software. If changes are necessary, the original software should be retained and the changes applied to a designated copy. All changes should be fully tested and documented, so that they can be reapplied, if necessary, to future software upgrades. If required, the modifications should be tested and validated by an independent evaluation body.
The following guidance should be considered to address technical vulnerabilities:

1. taking appropriate and timely action in response to the identification of potential technical vulnerabilities; defining a timeline to react to notifications of potentially relevant technical vulnerabilities;
2. depending on how urgently a technical vulnerability needs to be addressed, carrying out the action according to the controls related to change management or by following information security incident response procedures ;
3. only using updates from legitimate sources (which can be internal or external to the organization);
4. testing and evaluating updates before they are installed to ensure they are effective and do not result in side effects that cannot be tolerated [i.e. if an update is available, assessing the risks associated with installing the update (the risks posed by the vulnerability should be compared with the risk of installing the update)];
5. addressing systems at high risk first;
6. develop remediation (typically software updates or patches);
7. test to confirm if the remediation or mitigation is effective;
8. provide mechanisms to verify the authenticity of remediation;
9. if no update is available or the update cannot be installed, considering other controls, such as:
   • applying any workaround suggested by the software vendor or other relevant sources;
   • turning off services or capabilities related to the vulnerability;
   • adapting or adding access controls (e.g. firewalls) at network borders ;
   • shielding vulnerable systems, devices or applications from attack through deployment of suitable traffic filters (sometimes called virtual patching);
   • increasing monitoring to detect actual attacks;
   • raising awareness of the vulnerability.

For acquired software, if the vendors regularly release information about security updates for their software and provide a facility to install such updates automatically, the organization should decide whether to use the automatic update or not.

Other considerations
An audit log should be kept for all steps undertaken in technical vulnerability management. The technical vulnerability management process should be regularly monitored and evaluated in order to ensure its effectiveness and efficiency. An effective technical vulnerability management process should be aligned with incident management activities, to communicate data on vulnerabilities to the incident response function and provide technical procedures to be carried out in case an incident occurs. Where the organization uses a cloud service supplied by a third-party cloud service provider, technical vulnerability management of cloud service provider resources should be ensured by the cloud service provider. The cloud service provider’s responsibilities for technical vulnerability management should be part of the cloud service agreement and this should include processes for reporting the cloud service provider’s actions relating to technical vulnerabilities (see 5.23). For some cloud services, there are respective responsibilities for the cloud service provider and the cloud service customer. For example, the cloud service customer is responsible for vulnerability management of its own assets used for the cloud services.

Other information

Technical vulnerability management can be viewed as a sub-function of change management and as such can take advantage of the change management processes and procedures . There is a possibility that an update does not address the problem adequately and has negative side effects. Also, in some cases, uninstalling an update cannot be easily achieved once the update has been applied. If adequate testing of the updates is not possible (e.g. because of costs or lack of resources) a delay in updating can be considered to evaluate the associated risks, based on the experience reported by other users. Where software patches or updates are produced, the organization can consider providing an automated update process where these updates are installed on affected systems or products without the need for intervention by the customer or the user. If an automated update process is offered, it can allow the customer or user to choose an option to turn off the automatic update or control the timing of the installation of the update. Where the vendor provides an automated update process and the updates can be installed on affected systems or products without the need for intervention, the organization determines if it applies the automated process or not. One reason for not electing for automated update is to retain control over when the update is performed. For example, a software used for a business operation cannot be updated until the operation has completed. A weakness with vulnerability scanning is that it is possible it does not fully account for defence in depth: two countermeasures that are always invoked in sequence can have vulnerabilities that are masked by strengths in the other. The composite countermeasure is not vulnerable, whereas a vulnerability scanner can report that both components are vulnerable. The organization should therefore take care in reviewing and acting on vulnerability reports. Many organizations supply software, systems, products and services not only within the organization but also to interested parties such as customers, partners or other users. These software, systems, products and services can have information security vulnerabilities that affect the security of users. Organizations can release remediation and disclose information about vulnerabilities to users (typically through a public advisory) and provide appropriate information for software vulnerability database services.

Prior to implementing and vulnerability controls, it’s essential to obtain a complete and up-to-date list of physical and digital assets that are owned and operated by the organisation.Software asset information should include:

• Vendor name
• Application name
• Version numbers currently in operation
• Where the software is deployed

When attempting to pinpoint technical vulnerabilities, organisations should:

• Clearly outline who (within the organisation) is responsible for vulnerability management from a technical perspective, in accordance with its various functions, including (but not limited to):
  • Asset management
  • Risk assessment
  • Monitoring
  • Updating
• Who is responsible for the software within the organisation
• Maintain an inventory of applications and resources that will be used to identify technical vulnerabilities.
• Ask suppliers and vendors to disclose vulnerabilities upon the supply of new systems and hardware, and specify as such in all relevant contracts and service agreements.
• Make use of vulnerability scanning tools, including patching facilities.
• Carry out regular, documented penetration tests – either internally or via a certified third-party.
• Be mindful of the use of third-party code libraries and/or source code for underlying programmatic vulnerabilities.

In addition to internal systems, organisations should develop policies and procedures that detect vulnerabilities across all its products and services, and receive vulnerability assessments relating to the supply of said products and services.Organisations are to make a public effort to track down any vulnerabilities, and encourage third-parties to engage in vulnerability management efforts through the use of bounty programs (where exploits are looked for and reported to the organisation for a reward). Organisations should make themselves available to the general public through forums, public email addresses and research activity so that the collective knowledge of the wider public can be used to safeguard products and services at source. Where remedial action has been taken that affects users or customers, organisations should consider releasing relevant information to the affected individuals or organisations, and engage with specialist security organisations to disseminate information about vulnerabilities and attack vectors. In addition, organisations should consider offering an automatic update procedure that customers are able to opt in or out of, based on their business needs. Adequate reporting is key to ensuring swift and effective remedial action when vulnerabilities are discovered. When evaluating vulnerabilities, organisations should:

• Carefully analyse any reports and decide what action needs to be taken, including (but not limited to) the amendment, updating or removal of affected systems and/or hardware.
• Agree upon a resolution that takes into account other ISO controls (particularly those related to ISO 27002:2022) and acknowledges the level of risks involved.

Software vulnerabilities are best combated with a proactive approach to software updates and patch management. Prior to any amendments being implemented, organisations should ensure that incumbent software versions are retained, all changes are fully tested and applied to a designated copy of the software. When directly addressing vulnerabilities after they have been identified, organisations should:

1. Seek to resolve all vulnerabilities in a timely and efficient manner.
2. Where possible, follow the organisational procedures on change management and incident response .
3. Only apply updates and patches that emanate from trusted and/or certified sources, particularly in the vase of third-party vendor software and equipment.
4. Where vendor software is concerned, organisations should make a judgement call based on the information available as to whether it is necessary to apply automatic updates (or parts thereof) to acquired software and hardware.
5. Test any updates that are required prior to installation, to avoid any unforeseen incidents in an operational environment.
6. Seek to address high risk and business-critical systems as a priority.
7. Ensure that any remedial actions are effective and authentic.

In the event of an update not being available, or any issues that prevent an update being installed (such as cost issues), organisations should consider other measures, such as:

• Asking the vendor for advice on a workaround or “sticking plaster” solution whilst remedial efforts are ramped up.
• Disabling or stopping any network services that are affected by the vulnerability.
• Implementing network security controls at critical gateway points, including traffic rules and filters.
• Increasing the overall level of monitoring in line with the associated risk.
• Ensure that all affected parties are aware of the vulnerability, including suppliers and customers.
• Delaying the update to better evaluate the associated risks, especially where operational cost may be an issue.

Organisations should keep an audit log of all relevant vulnerability management activities, in order to aid remedial efforts and improve procedures in the event of a security incident. The entire vulnerability management process should be periodically reviewed and evaluated, in order to improve performance and identify more vulnerabilities at source. If the organisation used software hosted by a cloud service provider, the organisation should ensure that the service provider’s stance towards vulnerability management is aligned with its own, and should form a key part of any binding service agreement between the two parties, including any reporting procedures

Steps in the Vulnerability Management Life cycle

1. Asset Discovery
   First, you must create (or maintain) your asset directory. In this step, you take inventory of your organization’s assets, including software, hardware, operating systems, and services, taking note of the current versions and applied patches. Establish a baseline of identified vulnerabilities to serve as a reference when detecting new vulnerabilities. Periodically revisit the inventory and update it when you add new assets (software or devices).
2. Prioritization
   Classify your assets based on their risk level and importance to business operations. Assign business values to every asset class to determine which assets should be first for vulnerability assessment. Core business software and hardware should be the priority.
3. Vulnerability Assessment
   Once you’ve established baseline risk profiles and determined the priority level of your assets, arrange them according to the degree of exposure to specific vulnerabilities. The vulnerability assessment should consider each asset’s classification, criticality, and vulnerabilities. Research publicly available vulnerability lists and risk rankings to identify the exposure level of each asset to specific vulnerabilities.
4. Reporting
   Build an asset security strategy based on your identified risks and priority levels. Document the required remediation steps for each known vulnerability and continuously monitor suspicious behavior to lower the system’s overall risk.
5. Remediation
   Implement the security strategy to remediate your prioritized vulnerabilities, addressing high-risk and critical assets first. This step typically involves updating software and hardware, applying vulnerability patches, modifying security configurations, and identifying vulnerable areas to protect critical assets and infrastructure. You might have to deactivate specific user accounts, provide additional security awareness training, or introduce new technologies to handle certain tasks that the IT team used to perform manually.
6. Evaluation and Verification
   The final step in the vulnerability management life cycle involves evaluating your security strategy and verifying that your security measures have successfully reduced or eliminated your prioritized threats. This process will likely include several steps and should be a continuous effort with regular scans and assessments to ensure your vulnerability management policies are effective.

Vulnerability Assessment:

Vulnerability management and vulnerability assessment help address and resolve security vulnerabilities Vulnerability assessment offers visibility into the current state of the situation, while vulnerability management provides continuous, real-time intelligence, reporting, and remediation guidance. A vulnerability assessment is typically the first step in a vulnerability management process. It involves using scanners to gather information from devices and systems on the corporate network and comparing the information to known vulnerabilities disclosed by software vendors. The organization’s IT staff runs scans at regular intervals and schedules upgrades and patching. Vulnerability management is a continuous process rather than a scheduled process performed ad-hoc. It involves running an ongoing program that cycles through vulnerability assessments, prioritization, and remediation. The process employs multiple data sources to continually assess the situation and reassess the existing state of services and software.vulnerability assessments aim to discover vulnerabilities as quickly as possible and are more effective for detecting known vulnerabilities, penetration tests provide an in-depth assessment to identify unknown vulnerabilities.Vulnerability assessment typically involves automated, repeatable scans, which are useful for evaluating remediation attempts.Vulnerability assessments identify outdated applications or operating systems and device configuration issues like insecure ports and weak passwords. They are best suited to detecting common vulnerabilities and exposures, or CVEs, listed on public databases.Vulnerability assessments involve automated tools that scan the network for known CVEs. There are many vulnerability scanning tools ranging from open source to commercial solutions. When choosing a tool, organizations should consider various factors, including the infrastructure to be tested and configuration and support options.Vulnerability management tools scan corporate networks for vulnerabilities that potential intruders could exploit. If the scan finds weaknesses, the software suggests or initiates corrective action. In this way, vulnerability management software reduces the likelihood of a cyber attack. The most important features an organization should expect from a vulnerability assessment tool are:

• Quality and speed—vulnerability scanning can take a long time in large networks, and can result in false positives. Test a prospective tool on your network, see how long it takes to run, and compare selected findings with a manual assessment of vulnerabilities.
• User experience—the product should be easy to navigate and use, and vulnerability reports should be easy to understand by all relevant stakeholders.
• Compatibility—the product’s signature database should support all major operating systems, applications, and infrastructure components used by the organization.
• Cloud support—most organizations are running workloads in the cloud, and the tool should be able to detect vulnerabilities in IaaS, PaaS and SaaS environments.
• Compliance—the product must support all relevant compliance standards applicable to the organization, and should provide reports in the format required by auditors.
• Prioritization—the product should offer both manual review of vulnerabilities and automated prioritization.
• Remediation instructions—the tool must provide actionable remediation instructions that can be easily followed by IT staff and developers.

Best Practices for an Effective Vulnerability Management Program

1. Account for all IT Assets and Networks: All organizations have hardware or software that are not in common use, or were deployed without the knowledge of IT staff. They may seem harmless, but these outdated programs and systems are often the most vulnerable parts of the security infrastructure, just waiting to be exploited by potential attackers. This makes it critical to perform a comprehensive inventory of all hardware and software in the organization, and scanning all assets for vulnerabilities.
2. Establish a Vulnerability Management Policy: The purpose of a vulnerability management policy is to define rules for reviewing and evaluating vulnerabilities, applying system updates to mitigate them, and validating that the risk is no longer present. Vulnerability management policies typically cover network infrastructure, but policy scope can vary by organization size, type, and industry. They can extend to vulnerabilities affecting servers, operating systems, cloud environments, database servers, and more.
3. Use High Quality Threat Intelligence Feeds: High quality data about threats can be a game changer in keeping your network secure. It allows IT and security teams to stay one step ahead of attackers, by being aware of the latest attack patterns and known vulnerabilities. Threat intelligence feeds can uncover newly discovered vulnerabilities and exploits. These feeds are maintained by experts who track potential threats. Continuous access to updated information is critical for augmenting automated vulnerability scanners.
4. Perform Regular Penetration Testing: Penetration testing is conducted by ethical hackers working on behalf of an organization, and aims to identify exploitable vulnerabilities in networks or computing systems. It helps businesses find and fix high priority vulnerabilities that attackers can actually exploit.
5. Penetration testing can help protect your network from external attacks, and also provides unbiased and expert insight into weaknesses in security infrastructure. When combined with other threat management processes, such as vulnerability assessments, regular penetration testing is a highly effective way to identify and remediate vulnerabilities.

Common Challenges

• “Scanning Can Cause Disruptions.” IT operations teams are quite reasonably very sensitive about how vulnerability scans are conducted and keen to understand any potential for operational disruptions. Often legacy systems and older equipment can have issues even with simple network port scans; To help with this issue, it can often be useful to build confidence in the scanning process by partnering with these teams to conduct risk evaluations before initiating or expanding a scanning program. It is also often important to discuss the “scan windows” when these vulnerability assessments will occur to ensure that they do not conflict with regular maintenance schedules.
• “Drowning In Vulnerability Data and False Positives.” Technical vulnerability management practices can produce very large data-sets. It is important to realize that just because a tool indicates that a vulnerability is present that there are frequently follow-up evaluations needed to validate these findings. Reviewing all of these vulnerabilities is usually infeasible for many teams; For this reason, it is very important to develop a vulnerability prioritization plan before initiating a large number of scans. These priority plans should be risk-driven to ensure that teams are spending their time dealing with the most important vulnerabilities in terms of both likelihoods of exploitation and impact.