The ISO/IEC 27002:2013 standard defines a vulnerability: as “A weakness of an asset or group of assets that can be exploited by one or more threats” (International Organization for Standardization, 2005).
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 involves using a computer program to identify the network, computer infrastructure, or application vulnerabilities. Vulnerability management is the process surrounding vulnerability scanning, also taking into account other aspects such as risk acceptance, remediation, etc.
This document is a security standard and, as such, describes security control requirements.
Detailed configuration and implementation requirements must be contained within
operational procedure and guidelines documentation.
This standard defines the controls relating to the management of threats & vulnerabilities.
That can potentially disrupt Resolver’s IT systems and business processes and compromise the confidentiality, integrity, and availability (CIA) of Resolver’s data and company reputation.
This standard also defines Resolver’s strategy and approach to routine vulnerability scanning
and penetration testing, plus a mandated remediation schedule.
This standard applies to all servers and infrastructure components that provide or support
Resolver IT services hosted inside the corporate network, third-party data center(s), or cloud
service provider(s); and extends to apps available via public app stores.
The objective is to ensure a consistent, repeatable, and auditable approach for conducting threat and vulnerability management within the Resolver environments. This should be achieved regardless of the source of the threat or the platform in which a vulnerability is located.
The first step in risk assessment is the identification of all assets in the ISMS scope – i.e., of all assets which may affect confidentiality, integrity, and availability of information at Resolver. Assets may include documents in paper or electronic form, applications and databases, people, IT equipment, infrastructure, and external services/outsourced processes. When identifying assets, it is also necessary to identify their owners – the person or organizational unit responsible for each asset.
The next step is to identify all threats and vulnerabilities associated with each asset. Threats and vulnerabilities are identified using the catalogs included in the Risk Assessment Table. Every asset may be associated with several threats, and every threat may be associated with several vulnerabilities.
Asset categories or groups are created from the asset inventory. Asset groups are used to scan specific assets, like Web Servers, File Servers, and Database Servers (rather than subnets). These categories also allow for vulnerability scan customization, addressing asset or business requirements, and assisting with assigning risk rankings.
For each risk, a risk owner has to be identified – the person or organizational unit responsible for each risk. This person may or may not be the same as the asset owner.
This standard provides requirements for the ongoing identification, prioritization, and remediation of vulnerabilities within the environment. All vulnerability management activities must align with the Common Vulnerability Scoring System Version 3.1 (CVSS v3.1).
| · All information system must be scanned regularly for known vulnerabilities · The maximum time period allowed between scans is one quarter. · Data sensitive systems containing highly confidential information (as per Information Asset Inventory) and systems hosting critical applications (according to data owner) must be scanned monthly. · All hosted production environments must be scanned monthly. |
Information systems could be Hardware, Software, Appliances, IoT, Mobile, recording media (e.g., external storage) and include but are not limited to;
Patches must then be applied as per the defined patching processes described in Resolver Corporate Patch Management Policy.
The system and software vulnerability management process should be supported by performing vulnerability scans of critical and sensitive business applications, information systems, and network devices to help:
The calculated business risk prioritizes risks. Assets and asset groups are assigned a business criticality rating. When a vulnerability is discovered, the vulnerability assessment tool (CVSS v3.1) helps to calculate the business risk of an asset, together with the interviewing of asset owners and their evaluation of asset criticality.
The Remediation effort is subsequently prioritized on a risk basis.
For example, an Internet web server susceptible to a vulnerability granting administrative-level access should be remediated before an internal system requires a low-severity security patch.
Once risk owners have been identified, it is necessary to assess the consequences for each combination of threats and vulnerabilities for an individual asset if such a risk materializes:
Table: Impact
| Digital equivalent of the Impact raiting | Descriptor of Impact | Definition |
| 5 | Very High | Customer data is very high-impact information and must be considered as an immediate high-risk impact. Loss of confidentiality, availability, or integrity has considerable and/or immediate impact on the organization’s cash flow, operations, legal or contractual obligations, or its reputation. · No scenario planning performed · Lack of enterprise level/process level capabilities to address risks · Responses not implemented · No contingency or crisis management plans in place |
| 4 | High | Loss of confidentiality, availability, or integrity has considerable and/or immediate impact on the organization’s cash flow, operations, legal or contractual obligations, or its reputation. · Scenario planning for key strategic risks performed · Low enterprise level/process level capabilities to address risks · Responses partially implemented or not achieving control objectives · Some contingency or crisis management plans in place |
| 3 | Medium | Loss of confidentiality, availability or integrity incurs costs and has a low or moderate impact on legal or contractual obligations, or the organization’s reputation. · Stress testing and sensitivity analysis of scenarios performed · Medium enterprise level/process level capabilities to address risks · Responses implemented and achieving objectives most of the time · Most contingency and crisis management plans in place, limited rehearsals |
| 2 | Low | Loss of confidentiality, availability, or integrity does not affect the organization’s cash flow, legal or contractual obligations, or its reputation. · Strategic options defined · Medium to high enterprise level/process level capabilities to address risks · Responses implemented and achieving objectives except under extreme conditions · Contingency and crisis management plans in place, some rehearsals |
| 1 | Very Low | Loss of confidentiality, availability, or integrity does not affect the organization’s cash flow, legal or contractual obligations, or its reputation. · Real options deployed to maximize strategic flexibility · High enterprise level/process level capabilities to address risks · Redundant response mechanisms in place and regularly tested for critical risks · Contingency and crisis management plans in place and rehearsed regularly |
After the assessment of consequences, it is necessary to assess the likelihood of occurrence of such a risk, i.e. the probability that a threat will exploit the vulnerability of the respective asset:
Table: Likelihood
| Digital equivalent of the Likelihhod | Probability (Likelihood) Scale | Annual Frequency or Expected Event Frequency in years. | Probability in Next 5 years | Verbal description of the applicable implemented controls. |
| 5 | Very Likely | Up to once in 2 years or more (> 1 in 2) | > 95% | Existing security controls are low or ineffective. Such incidents have a high likelihood of occurring in the future. |
| 4 | Likely | Once in 2 years up to once in 5 years (1 in 2 to 1 in 5) | 65%-96% | Existing security controls are low or ineffective. Such incidents have a high likelihood of occurring in the future. |
| 3 | Medium | Once in 5 years up to once in 20 years (1 in 5 to 1 in 20) | 25%-65% | Existing security controls are moderate and have mostly provided an adequate level of protection. New incidents are possible, but not highly likely. |
| 2 | Unlikely | Once in 20 years up to once in 100 years (1 in 20 to 1 in 100) | 5%-25% | Existing security controls are strong and have so far provided an adequate level of protection. No new incidents are expected in the future. |
| 1 | Remote | Once in 100 years or less (1 in 100) | <5% | Existing security controls are strong and have so far provided an adequate level of protection. No new incidents are expected in the future. |
By entering the values of consequence and likelihood into the Risk Assessment Table, the level of risk is calculated automatically by adding up the two values. Existing security controls are to be entered in the last column of the Risk Assessment Table.
Risk acceptance criteria are criteria used as a basis for decisions about acceptable risk.
This section describes Product Level Cyber Risk acceptance criteria for in-house developed solutions and their hosting environments.
Once an asset is discovered, the vulnerability scan is done, and the risk assessment phase provides the criticality for business and priority, an appropriate task should be created for DevOps (Jira ticket) teams in order to:
| In general, remediation could be done by the following four methods: · Installation of a software patch. · Adjustment of a configuration setting. · Removal of the affected software. · Implementation of compensation control. |
These remediation targets are based on CVSS V3.1 and industry best practices (e.g., SANS, NIST).
| Vulnerability Severity Rating | Cloud Hosted systems | Corporate externally exposed systems | Corporate internal system |
| Critical | 8 days | 8 days | 14 days |
| High | 8 days | 8 days | 30 days |
| Medium | 30 days | 30 days | 30 days |
| Low | Risk assessment-based decision, but not later than 60 days | Risk assessment-based decision, but not later than 60 days | Risk assessment-based decision, but not later than 90 days |
Critical Applications
Critical applications must be regularly scanned for application logic vulnerabilities.
Note: A critical application is any system that, if compromised, would significantly impact business operations.
Zero-Day Vulnerabilities
Once a zero-day vulnerability becomes known, the relevant software must be updated according to the threat level and its relevance to Resolver (priority must be given in the next available window) when the relevant patch becomes available.
Anti-virus software definitions must be up-to-date on all relevant systems.
Patches must then be applied as per the defined patching processes described in Resolver Corporate Patch Management.
User Access Rights:
Ensuring users have access rights commensurate to one’s roles and responsibilities within the organization is a constant challenge, given the continuous user provisioning and the de-provisioning process undertaken, the numerous systems requiring access for such users, along with requests for changes and modifications in access rights.
Configuration Standards
Provisioning, hardening, securing, and locking down all critical system resources within Resolver’s environment is crucial for ensuring a baseline of information systems security, one that can be built upon over time by continuous monitoring and updating of such systems with security patches.
Network Architecture and Topology
Insecure network topology and weak security architectures – even if the system is properly secured and hardened – could cause a significant vulnerability for organizations.
Resolver’s network security architecture and supporting documentation should be created and follow the:
Once an asset is discovered, the vulnerability scan is done, the risk assessment phase provides the criticality for business and priority, and you have all information from the asset owner, you may conclude it will be much simpler to avoid usage of the asset:
E.g., FTP server running on your Web server. Uninstall the component and consider the installation of a separate server SFTP Virtual appliance.
Since not all vulnerabilities could be patched, fixed or may require a disproportionate amount of time or resources and as a consequence, could not be implemented in the required time frame, we should be able to implement compensating controls, e.g.:
If some vulnerability scan discovers SQL injection on a Web server, we could configure a Web Application Firewall (WAF) to protect against the SQL injection until an application patch is available.
User awareness activities should include appropriate awareness relating to threats, viruses and
general malware. Through these training activities, End Users must be informed about the following:
A defense-in-depth approach is taken for malware protection covering networks to all applications, including email.
Malware protection software must be installed on systems that are exposed to malware, including:
System/network monitoring activities should be conducted to help identify the following:
Provisioning, hardening security, and locking down all critical system resources are crucial to ensure a baseline of information security and privacy.
All Information systems mentioned in the vulnerability scanning paragraph configuration:
Follow-up remediation scan – confirms vulnerability addressed.
At least an annual external penetration test must be done, as per PCI DSS requirements and GDPR recommendations.
A Threat to Resolver’s company information systems landscape and all critical system resources is dynamic and persistent– creating enormous challenges for Resolver; this standard identified the significant purposes of vulnerability management and one of the critical components of the process; continuous monitoring.
Reports will be produced identifying compliance with the ongoing security activities defined in this standard and outlining detected security exceptions and incidents.
Risk owners must review existing risks and update the Risk Assessment Table in line with newly identified risks. The review is conducted at least once a year (annually), or more frequently in the case of significant organizational changes, a significant change in technology, a change of business objectives, changes in the business environment, etc.
Exceptions to this document can only be granted in accordance with the Resolvers Information Security Department’s written approval.
Any failure to comply with this document or security incident that materializes relating to the
requirements within this document must be reported to the Resolver Information Technology Security Incident team by email at infosec@resolver.com.
This document is valid as of August 2023.
The owner of this document is an Information Security Analyst who must check and, if necessary, update the document at least once a year.
When evaluating the effectiveness and adequacy of this document, the following criteria need to be considered:
EFFECTIVE ON: August 2023
REVIEW CYCLE: Annual at least and as needed