A.12.6 Resolver Risk Assessment-Threat & Vulnerability Management standard

1. Introduction

The ISO/IEC 27002:2013 standard provides the following definition for a vulnerability: “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 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.

2. Purpose and Scope

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 have the potential to disrupt Resolver IT systems and business processes; and as a consequence, compromise the confidentiality, integrity, 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.

3. Audience

  • Information Technology (IT) Team.
  • DevOps Team (DevOps).
  • Informational Security (InfoSec) Team.
  • Development (R&D) Team.
  • Product Management (PM) Team.
  • Resolver’s 3rd parties, suppliers and vendors

4. Reference documents

  • ISO/IEC 27001:2013 standard, clauses 6.1.2, 6.1.3, 8.2, 8.3 and control 12.6
  • Information Security Policy
  • Statement of Acceptance of ISMS documents

5. Objectives

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 threat or the platform in which a vulnerability is located.

6. Roles and responsibilities

  • Chief Informational Security Officer (CISO): The CISO is the owner and the main person in charge of the overall of the Vulnerability and Threat Management process.
  • Informational Security Analyst: The person in the role is responsible for overall monitoring and investigation of detected vulnerabilities and providing the risk assessment (In collaboration with asset owner) and mitigation steps.
  • IT System Engineer: The IT system engineer role is typically responsible for implementing remediating actions defined as a result of detected vulnerabilities for Resolver’s Corporate network-attached assets.
  • DevOps Engineers: The DevOps engineers are responsible to implement remediating actions defined as a result of detected vulnerabilities for Resolver’s Hosted production environments.
  • Asset Owner: The asset owner is responsible for the IT asset that is scanned by the vulnerability management process. This role should decide whether identified vulnerabilities are mitigated or their associated risks are accepted.

7. Risk Assessment and Threats, and Vulnerability Management Components

  • Assets Management
  • Building assets inventory
  • Categorizing assets into groups
  • Vulnerability Scan (Initial)
  • Risk Assessment
  • Consequences and likelihood
  • Remediating actions
  • Rescan
  • External penetration test
  • Continuous monitoring
  • Regular reviews of risk assessment and risk treatment
  • Reports

8. Vulnerability Management Process Standards

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.

8.1. Assets Management

8.1.1. Build an asset inventory

  • Without an updated current asset inventory, it is difficult to properly address the inherent environmental risk.
  • Resolver’s networks should be scanned at least once in a quarter in order to discover new systems.
  • In this step, the vulnerability assessment tool scans specified network subnets for assets. Systems discovered during the scan are added to the asset inventory. This process helps to ensure that all systems are identified and patched accordingly.

8.1.2. Categorizing assets

Asset categories or groups are created from the asset inventory. Asset groups are used to scan specific assets, like: Web Servers, File Servers, DataBase Server (rather than subnets). These categories also allow for vulnerability scan customization, addressing asset or business requirements, and assists with assigning risk rankings.

8.2. Determining the risk owners

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.

8.3. Vulnerability Scanning (Initial)

  • There are two major aspects to vulnerability scanning – the scan and a report. The vulnerability scan is designed to test and analyze systems and services for known vulnerabilities. The scan comprises a list of scan options (ports, protocols, and network packet behavioral characteristics used for scanning) and assets. The report contains the prioritized list of vulnerabilities, vulnerability description, calculated risk, and remediation activities.

This standard provides requirements for the ongoing identification, prioritization, and remediation of vulnerabilities within the environment. All vulnerability management activities must align to the Common Vulnerability Scoring System version 3 (CVSS v3).

  • 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 not limited to;

  • Network devices and systems such as Firewalls, Network Switches, Servers, NAS or SAN storage solutions, Wi-Fi Access point, Wi-Fi Routers, desktop workstations, laptop computers, printers, and IP telephones.
  • Mobile devices such as tablets and smartphones
  • Servers and web applications, ERP & SCM applications and cloud-based applications
  • Client applications running on platforms such as desktop workstations, laptop computers, and mobile devices.
  • System and software vulnerabilities associated with business applications, information systems, and network devices must be managed through scanning each of these for system and software vulnerabilities.

Patches must then be applied as per defined patching processes described in Resolver Corporate Patch Management Policy.

8.3.1. Vulnerability scanning must be:

  • Restricted to a limited number of authorized individuals (e.g. using a dedicated account that is only used for vulnerability scanning)
  • Using approved and dedicated systems (e.g. using predetermined, static IP addresses)
  • Monitored (e.g. to identify misuse by authorized individuals or help detect unauthorized

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:

  • Identify system and software vulnerabilities that are present in business applications,
    information systems and network devices
  • Determine the extent to which business applications, information systems, and network
    devices are exposed to threats
  • Prioritize the remediation of vulnerabilities (e.g. using the vendor’s patch release schedule)
  • Provide a high-level view of vulnerabilities across the organization’s technical infrastructure (e.g. to make comparisons and identify trends).

8.3.2. Risk Assessment:

Risks are prioritized by the calculated business risk. Assets and asset groups are assigned a business criticality rating. When a vulnerability is discovered, the vulnerability assessment tool (CVSS V3.0) helps to calculate the business risk of an asset, together with the interviewing of asset owners and his 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 requiring a low severity security patch.

8.3.3. Consequences and likelihood

Once risk owners have been identified, it is necessary to assess consequences for each combination of threats and vulnerabilities for an individual asset if such a risk materializes:

Low consequence 0 Loss of confidentiality, availability, or integrity does not affect the organization’s cash flow, legal or contractual obligations, or its reputation.
Moderate consequence 1 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.
High consequence 2 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.


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:

Low likelihood 0 Existing security controls are strong and have so far provided an adequate level of protection. No new incidents are expected in the future.
Moderate likelihood 1 Existing security controls are moderate and have mostly provided an adequate level of protection. New incidents are possible, but not highly likely.
High likelihood 2 Existing security controls are low or ineffective. Such incidents have a high likelihood of occurring 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.

8.4. Risk acceptance criteria

Risk acceptance criteria are criteria used as a basis for decisions about acceptable risk.

  • All avoidable risks should be avoided.
  • Risks should be reduced wherever practicable.
  • Consequences and Likelihood risk with values 0 and CVSS V3.0 base scored severity level 3.9 and lower risks are acceptable risks.
  • Each risk with the Consequences and likelihood levels 1 and 2 should be assessed by the ISMS team (on a weekly Change Control Committee and/or Monthly Security Review with Development team’s leaders and/or Monthly DevOps Security Review meeting).
  • All risks with Attack Vector è External Network and Confidentiality and Integrity impact High should be equated as Unacceptable risks and must be treated.

8.5. Risk treatment / Remediating actions

8.5.1. Define responsibility

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 to DevOps (Jira ticket) teams in order to:

  • Monitor the vulnerability remediation flow.
  • Evaluate the mitigation steps
  • Compliance requirements

8.5.2. Vulnerability Remediation

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.0 and industry best practice (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 which, if compromised, would have a significant impact on 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.

8.5.3. Patch Management

Patches must then be applied as per 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.

  • Adhere to the least privilege or principle, depends on system predestination
  • “need to know”
  • Utilize/Implement Role-Based Access control (RBAC), whereby users are granted permissions based on defined roles for specific systems.
  • Utilizing provisioning and de-provisioning documentation for on-boarding and off-boarding all users, such as authorization forms and checklists, termination forms and checklist, etc.
  • Maintain password policy
  • Enforcing appropriate segregation of duties for users having access to company system resources.
  • Documented policy and procedure detailing the provisioning and de-provisioning for all users/roles accessing the company system resources.

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.

  • Configuration standards have been appropriately identified, reviewed, and approved by Information Security (InfoSec) team members.
  • Relevant and timely updated actual configuration standards documentation should be created – such as guides, checklists, scripts, policies, and other supporting hardening material should be provided.
  • All critical system resources within Resolver have been adequately provisioned, hardened, secured, and locked-down according to the stated configuration documentation.

Network Architecture and Topology

Insecure network topology and weak security architectures – even if the system themselves are 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:

  • Various industry best practices standards like; “AWS Security Best Practices”.
  • Should implement a “Defense in Depth” approach described in the “Resolver System description” document.

8.5.4. Removal of the affected software

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:

  • Uninstall all unnecessary packages
  • Uninstall all unnecessary OS Components.

E.g. FTP server running on your Web server. Uninstall the component and consider the installation of a separate server SFTP Virtual appliance.

8.5.5. Compensation control implementation

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 Web server we could configure a Web Application Firewall (WAF) to protect against the SQL injection until an application patch is available.

8.5.6. Malware Awareness

User awareness activities should include appropriate awareness relating to threats, viruses and
general malware. Through these training activities End Users must be informed about:

  • Prevalence of malware and associated risks (e.g. unauthorized access to critical business
    applications, corruption of critical business information or leakage of sensitive information)
  • Ways in which malware can install itself on computing devices
  • Common symptoms of malware infection (e.g. poor system performance, unexpected
    application behavior, sudden termination of an application).
  • Not installing software from untrusted sources, opening untrusted attachments, or clicking on suspicious or unknown hyperlinks within emails or documents.
    End users should be
  • Advised to manually scan files when attaching portable storage devices or when receiving unknown or questionable files
  • Notified quickly of significant new malware-related risks (e.g. by email, freeware or
    suspicious websites)

8.5.7. Malware Protection

A defense-in-depth approach is taken for malware protection covering network to all applications including email.
Malware protection software must be installed on systems that are exposed to malware including:

  • Servers (e.g. servers that are at risk from malware, such as file and print servers, application servers, web servers, and database servers).
  • computing devices (e.g. desktop computers and laptops).
  • Information systems that support or enable the organization’s critical infrastructure (e.g.
    embedded systems and industrial control systems where the malware protection software is available.
  • Malware protection software should protect against all forms of malware (e.g. computer viruses, worms, Trojan horses, spyware, rootkits, botnet software, keystroke loggers, and adware).
  • Malware protection software should be distributed automatically, and within defined timescales to reduce the likelihood of systems being exposed to the most recent malware (including those that are associated with ‘zero-day’ attacks).
  • A patch management process/procedure must exist for each asset being protected, including those managed by third parties.
  • Malware protection software should be configured to scan:
    • the master boot record (MBR) of hard disk drives (a popular target for boot sector-infecting viruses).
    • Targeted files (including executables, image files such as JPEG, document formats such as Adobe PDF and macro files in desktop software).
    • Protected files (e.g. compressed or password-protected files) where possible
    • portable storage media (e.g. CDs, DVDs, and USB storage devices) immediately upon loading or connection to computer equipment.
    • Network folders immediately upon being mounted/shared.
  • network traffic entering the corporate network (including email and downloads from the
  • Network traffic leaving the corporate network (including email attachments and shared
  • Malware protection software should be configured to be active at all times (e.g. by scanning files as they are accessed to provide real-time protection, or by being configured to be active at all times and to restart if stopped)
  • Perform scheduled scanning at predetermined times
  • provide a notification when suspected malware is identified (e.g. by producing an event log entry and providing an alert)
  • Disable and quarantine files suspected of containing malware (e.g. for further investigation)
  • Remove malware and any associated files immediately upon detection
  • ensure that important settings cannot be disabled or functionality minimized.

8.5.8. Methods of Malware Detection to be used

  • Signature-based anti-virus detection: This must be implemented by default.
  • Behavior-based malware detection: Where installed, behavior-based malware detection should be implemented.

8.5.9. Mobile devices

  • No BYOD connected to the Resolver’s networks (except Guest).
  • Encryption – devices must be encrypted.
  • Rooted/Jailbroken devices must be blocked.
  • Remote wipe – all devices must be able to be wiped remotely.
  • Password – suitable strength password policies must be enforced.

8.5.10. Security Event Logging

  • New systems deployed should be compatible with Logging Standard.

8.5.11. System and Network Monitoring

  • System and network activity should be monitored for potentially suspicious activity, based on their criticality.

System/network monitoring activities should be conducted to help identify:

  • unauthorized scanning of business applications, information systems, and networks.
  • successful and unsuccessful attempts to access protected resources (e.g. DNS servers, web portals, and file shares).
  • unauthorized changes to user accounts and access rights (to detect privilege escalation)
    The results of monitoring activities should be reviewed by the owners of business applications, information systems, and networks, and presented to the business owners to whom services are provided.

8.5.12. Intrusion Detection

  • Network ingress/egress points must be monitored for malicious activity.
  • Any intrusion monitoring system must be configured with updated detection mechanisms as they become available.
  • Network intrusion detection systems should be installed and configured such that they are difficult to detect or attack.
  • Intrusion detection alerts must be monitored and responded to as appropriate.
  • Intrusion detection software should be:
    • updated automatically and within defined timescales (e.g. delivery of distribution attack signature files to intrusion detection sensors via a central management console)
    • configured to provide an alert when suspicious activity is detected
  • Suspected intrusions should be analyzed and the potential business impact assessed. Initial analysis should include;
    • Confirming whether an attack is actually occurring (e.g. by eliminating false positives)
    • Determining the type of attack (e.g. worms, buffer overflows or denial of service)
    • Identifying the original point of attack
    • Quantifying the possible impact of an attack.
    • The status of an attack should be assessed in terms of both scale and time elapsed since the start of the attack & since the detection of the attack.
      All attacks should be reported to infosec@resolver.com.

8.5.13. Configuration standard

Provisioning, hardening security, and locking-down all critical system resources are crucial to ensure a baseline of information security.

All Information systems mentioned in the vulnerability scanning paragraph configuration:

  • Must follow vendor security configuration best practices if such exist.
  • If not exist, must be securely configured
  • And must NOT use system configuration defaults, like a:
    • Users name
    • Password
    • Ports (if applicable)

8.6. Rescan

Follow-up remediation scan – confirms vulnerability addressed.

8.7. External Penetration testing

At least an annual external penetration test must be done, as PCI DSS requirement and GDPR recommendation.

8.8. Continuous Monitoring

A Threat to Resolver’s company information systems landscape and all critical system resources is dynamic in nature and persistent – which is creating enormous challenges for Resolver and this standard identified the major purposes of vulnerability management, and one of the important components is, continues monitoring.

  • Users Access right: Periodic review of the entire user identity, provisioning, and access rights lifecycle, with findings, analysis, and recommendations reported to senior management within Resolver.
  • Configuration Standards: Periodic review of critical system resources for ensuring the applicable hardening reported to senior management within Resolver.
  • Network Architecture and Topology: Periodic review of the entire Resolver security architecture to ensure a layered, Defense in Depth approach is being utilized, with findings, analysis, and recommendations reported to senior management within Resolver.
  • Vulnerability scanning:  Continues vulnerability scanning as we already a few times mentioned in this document.

8.9. Report

Reports will be produced identifying compliance with the ongoing security activities defined in this standard and to outline detected security exceptions and incidents.

8.10. Regular reviews of risk assessment and risk treatment

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, change of business objectives, changes in the business environment, etc.

9. Exceptions

Exceptions to this document can only be granted in accordance with the Resolvers Information Security Department’s written approval.

10. Non-Conformance / Incident Reporting

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.

11. Validity and document management

This document is valid as of July 2020.

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:

  • The number of incidents arising from the unclear definition of the ISMS scope.
  • The number of corrective actions taken due to an inadequately defined ISMS scope.
  • The Time put in by employees implementing the ISMS to resolve dilemmas concerning the unclear scope.


September 2020


Annual at least and as needed


last time reviewed and approved in August 2020 by Resolver’s Information Technology Security team.