Introduction

The ISO 27002 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.

Goal

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 a company’s IT systems and business processes; and as a consequence, compromise the confidentiality, integrity, availability (CIA) of A company’s data and reputation. This standard also defines A company’s strategy and approach to routine vulnerability scanning and penetration testing, plus mandated remediation schedule

Audience

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

Scope

This standard applies to all servers and infrastructure components that provide or support a company’s 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.

Objectives

The objective is to ensure a consistent, repeatable and auditable approach for conducting threat and vulnerability management within the A company’s environments. This should be achieved regardless of the source of threat or the platform in which a vulnerability is located.

Exceptions

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

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 A company’s Information Technology Security Incident team by email at INTENTIONALLY DELETED.

Roles and Responsibilities

  • Chief Informational Security Officer (CISO): The owner and the main person in charge of the overall of the Vulnerability and Threat Management process.
  • Informational Security Analyst: 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: Responsible for implementing remediating actions as a result of detected vulnerabilities for corporate networks and attached assets.
  • DevOps Engineers: Responsible to implement remediating actions as a result of detected vulnerabilities for hosted production environments.
  • Asset Owner: 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.

Vulnerability Management Components

  • Assets Management
    • Building asset inventory
    • Categorizing assets into groups
  • Vulnerability Scan (Initial)
    • Risk Assessment
  • Remediating actions
  • Rescan
  • External penetration test
  • Continues monitoring
  • Reports

Vulnerability Management Process Standards

Assets Management

Build an asset inventory

  • Without an updated current asset inventory, it is difficult to properly address the inherent environmental risk.
  • A company’s networks should be scanned at least once a month 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.

Categorizing assets

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

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 with the Common Vulnerability Scoring System version 2 (CVSS v3).

  • All information system must be scanned regularly for known vulnerabilities
  • The minimum 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 A company’s Hosted production environment must be scanned monthly

Information systems could be Hardware, Software, Appliances, IoT, Mobile, recording media (e.g. external storage) and include but not limited;

  • 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 “Patch Management Policy”

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 scanning).

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 across the organization’s technical infrastructure (e.g. to make comparisons and identify trends).

Risk Assessment:

Risks are prioritized by the calculated business risk. Assets and assets 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 interviewing of asset owner and his evaluation of asset criticality.

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.

Remediating actions

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

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 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 A company’s (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.

Patch Management

Patches must then be applied as per defined patching processes described in “Patch Management Policy”

Adjustment of a configuration setting

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 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 A company’s environment is crucial for ensuring a baseline of information systems security, one the 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 member.
  • 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 A company’s have been adequately provisioned, hardened, secured and locked-down in according 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 to the organization.

A company’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 “Defense in Depth” approach described in “A company’s System description” document

Removal of 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 should 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.

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 Web Application Firewall (WAF) (usually it’s implemented in A company’s environments) to protect our server against the SQL ejection immediately until application patch should be available.

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)

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
      Internet)
    • network traffic leaving the corporate network (including email attachments and shared
      documents).
  • 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.

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.

Mobile devices

  • No BYOD connected to the A company’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.

Security Event Logging

  • New systems deployed should be compatible with Logging Standard

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.

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 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 detection of the attack.
  • All attacks should be reported to INTENTIONALLY DELETED.

Configuration standard

Provisioning, hardening security and locking-down all critical system resources is crucial for ensure a baseline of informational security.

All Information systems mentioned in 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)

Rescan

Follow-up remediation scan – confirms vulnerability addressed.

10.5 External Penetration testing

At least annual external penetration test must be done, as PCI DSS required and GDRP recommends.

Continuous Monitoring

Threat to a A company’s company information systems landscape and all critical system resources is dynamic on nature and persistent – which is creating enormous challenges for A company’s and this standard identified the major purposes of vulnerability managements, 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 A company’s.
  • Configuration Standards: Periodic review of critical system resources for ensuring the applicable hardening reported to senior management within A company’s.
  • Network Architecture and Topology: Periodic review of the entire A company’s security architecture for ensure a layered, Defense in Depth approach is being utilized, with findings, analysis, and recommendations reported to senior management within A company’s.
  • Vulnerability scanning:  Continues vulnerability scanning as we already few times mentioned in this document.

Report

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