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

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

Threat Monitoring Process

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

Enterprise Security Team must gather information on current, new and emerging threats. Threat information must include vendors’ notifications for threats, patches and system updates and security information exchanges including US CERT.

The technologies tracked in the threat monitoring process must be determined from the types of technologies present in the inventory of Technology assets.

Threats identified must be resolved according to the Vulnerability Remediation Management.

Vulnerability Assessment

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

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

Development and management of Vulnerability Assessments processes and procedures

Architecture reviews

Security controls, limitations, network connections, and restrictions must be tested to assure conformance with applicable standards.

Internal and external vulnerability scans must be run at least quarterly

Internal scans must also be conducted after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades)

A vendor certified by the payment card industry must perform quarterly external vulnerability scans. Scans conducted after network changes may be performed by the company’s internal staff

Penetration testing must be conducted at least once a year and after any significant infrastructure or application upgrade or modification (e.g., major release, widespread upgrade of major router IOS version, change of border firewall vendor). Penetration testing must include:

Network-layer penetration tests

Application-layer penetration tests

These processes and procedures must include follow-up actions leveraging the IT Asset Management data (e.g., configuration information, OS versions, and patch levels) to validate and track findings in order to determine appropriate remediation efforts.

Vulnerabilities identified must be resolved according to the Remediation Management process.

Configuration Management

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

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

Be designed in compliance with applicable security requirements

Be kept up to date by the functional areas responsible for the technology asset and

Be integrated as part of the system build process and consistently enforced across all functional areas.

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

Vulnerability Remediation Management

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

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

Hardware details, software versions, and the configuration of the organization’s information systems as recorded in the asset inventory

The likelihood of occurrence

The impact of an occurrence and

Any applicable compensating controls.

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

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

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

Software Release. If a software release is available to fix the vulnerability, it should be tested and deployed following proper change management processes. Depending on the urgency of the deployment, the change request may be submitted as an emergency change request.

Compensating Control. If no software release is available to address the vulnerability, or if the deployment of the software release is determined to create an unacceptable risk, alternative controls may be deployed to prevent the exploitation of the vulnerability. As in the case of the software release approach, an emergency change request may be appropriate. Examples of compensating controls include:

Changes to technical configuration and standards

Changes to processes

Vulnerability and Patch – Detailed Process

The figure below shows the phases of vulnerability management (including components of patch management) and their requirements.

Identification

Processes must be in place to identify threats and vulnerabilities to an organization’s critical business information and associated hardware and

Internal security tools and services must be used to identify suspected or confirmed attacks against the organization’s business critical information and This must include the following:

Devices that detect and/or prevent known attacks

Devices that monitor critical files and

Devices that capture and analyze suspicious or unauthorized access

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

Testing of new hardware or software and after a significant change before going live or immediately after, e.g., major software release, new application, new product capability affecting confidential data access or management, to be carried out by independent and trained penetration

Re-tests must be performed to confirm exploitable or ‘high’ risk vulnerabilities were

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

Quarterly internal scanning of infrastructure and applications on business critical data environments

Scanning after a significant change to hardware or software before going live or immediately after, e.g., major software releases, new application or new product capability changing how confidential data is accessed or managed

Re-scanning infrastructure after ‘high’ vulnerabilities have been

Quarterly wireless scanning for WLAN cards and portable wireless devices (e.g. USB) connected to systems, and wireless devices connected to a network port or system

An incident response plan to deal with the discovery of unauthorized devices (on wired or wireless networks).

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

Registration to threat intelligence services to provide early knowledge of potential threats or risk to brand

Registration to vendor announcements and publications to provide details of known vulnerabilities and recommended patches or workarounds and

Regular monitoring of both points above for applicability as per the business.

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

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

Analysis

Roles and Frequency: Vulnerability management analysis meetings must take place at least monthly.

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

A monthly process must exist to list identified

The list of identified vulnerabilities must be mapped to specific business critical services that are

All vulnerabilities with a rating of ‘critical’, ‘high’ (as documented in Table 0) or with a CVSS number greater than 4.0 must have a mitigating action assigned; all other vulnerabilities must be assessed and action agreed on based on a risk-based decision.

Critical’ or ‘high’ vulnerabilities must be mitigated within 3 days of the vulnerability being

Vulnerabilities below ‘critical’ and ‘high’ but with a CVSS number greater than 0 must be mitigated within 90 days or justification documenting the risk-based decision not to.

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

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

Fix

Configuration and testing: All standard changes (non-emergency changes) must successfully go through testing in non-production environments before being deployed to

The testing must include a check to make sure other security tools or previous patches are not negatively affected when the new patch or workaround is

Any vulnerability mitigation (e.g., patch deployment or workaround) must be entered into the change control systems and follow the change control

Emergency mitigations must be authorized with the relevant team before being applied to the live

Deployment: The vulnerability mitigation must be completed by the date listed on the Risk Mitigation

On successful completion of the testing, the relevant team must be notified.

The change deployment process must have a roll-back option.

Monitoring

Re-scanning or re-testing must be conducted after fixes have been applied to devices to demonstrate that high-level vulnerabilities have been successfully

A report or log file must be produced after deploying patches or workarounds to confirm successful completion across all Vulnerability scanning or penetration testing incidents must be reported to the organization’s Security Team.

The vulnerability mitigation list must be monitored by the Security Team and any outstanding vulnerabilities not fixed by the completion date escalated to them.

In order to test access to confidential information, the following types of testing will be used.

External Security Vulnerability Testing

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

For internal Security Vulnerability Testing, assessors work from the internal network and assume the identity of a trusted insider.

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

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

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

Overt/Covert Security Vulnerability Testing

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

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

About InfoSec

InfoSec Institute is the best source for high quality information security training. We have been training Information Security and IT Professionals since 1998 with a diverse lineup of relevant training courses. In the past 16 years, over 50,000 individuals have trusted InfoSec Institute for their professional development needs!

Join our newsletter

File download

First Name

Last Name

Work Phone Number

Work Email Address

Job Title

Why Take This Training?

How will you fund your training?

What is your training budget?

InfoSec institute respects your privacy and will never use your personal information for anything other than to notify you of your requested course pricing. We will never sell your information to third parties. You will not be spammed.

Comments

What is Skillset?

Skillset

Practice tests & assessments.

Practice for certification success with the Skillset library of over 100,000 practice test questions. We analyze your responses and can determine when you are ready to sit for the test. Along your journey to exam readiness, we will:

1. Determine which required skills your knowledge is sufficient
2. Which required skills you need to work on
3. Recommend specific skills to practice on next
4. Track your progress towards a certification exam