Pci dss doc 11 1 technical vulnerability management policy

Technical Vulnerability Management Policy

PCI DSS Toolkit Version 3 ŠCertiKit

Technical Vulnerability Management Policy [Insert Classification]

Implementation Guidance (The header page and this section must be removed from final version of the document)

Purpose of this document This document describes the organization’s policy regarding how technical vulnerabilities will be found and managed.

Areas of the standard addressed The following areas of the PCI DSS standard are addressed by this document: 6.1 Identify security vulnerabilities 6.2 Ensure patches and updates 6.5.6 High risk vulnerabilities 11.2 Internal/External vulnerability scans 11.3 Penetration Testing

General Guidance This document sets out how you will prevent and find technical vulnerabilities in your organization and manage them effectively to reduce your exposure. There are many ways to do this and a variety of common tools available to help you, some of which are very good and free. For external vulnerability scanning PCI DSS requires you to us an Approved Scanning Vendor (ASV). For more information on finding ASV companies please visit the official PCI DSS website.

Review Frequency Given the pace of change with technical vulnerabilities and associated malware we would recommend that this document is reviewed quarterly and upon significant change to the organization.

Toolkit Version Number PCI DSS Toolkit Version 3

Document Fields This document may contain fields which need to be updated with your own information, including a field for Organization Name that is linked to the custom document property “Organization Name”.

Version 1

Page 1 of 13

[Insert date]

Technical Vulnerability Management Policy [Insert Classification]

To update this field (and any others that may exist in this document): 1. Update the custom document property “Organization Name” by clicking File > Info > Properties > Advanced Properties > Custom > Organization Name 2. Press Ctrl a on the keyboard to select all text in the document (or use Select, Select All on the ribbon) 3. Press F9 on the keyboard to update all fields 4. When prompted, choose the option to just update TOC page numbers If you wish to permanently convert the fields in this document to text i.e. so that they are no longer updateable, then you will need to click into each occurrence of the field and press Ctrl Shift F9.

If you would like to make all fields in the document visible then go to File > Options > Advanced > Show document content > Field shading and set this to “Always”. This can be useful to check that you have updated all fields correctly.

Further detail on the above procedure can be found in the Toolkit Completion Instructions within the Project Resources folder.

Copyright notice Except for any third party works included in this document, as identified in this document, this document has been authored by CertiKit, and is © copyright CertiKit except as stated below.

CertiKit is a trading name of Public I.T. Limited, a company registered in England and Wales with company number 6432088 and registered office at 5 Falcons Rise, Belper, Derbyshire, DE56 0QN.

Licence terms This document is licensed on and subject to the standard licence terms of CertiKit, available on request, or by download from our website. All other rights are reserved. Unless you have purchased this product you only have an evaluation licence. If this product was purchased, a full licence is granted to the person identified as the licensee in the relevant purchase order. The standard licence terms include special terms relating to any third party copyright included in this document.

Disclaimer Please Note: Your use of and reliance on this document template is at your sole risk. Document templates are intended to be used as a starting point only from

Version 1

Page 2 of 13

[Insert date]

Technical Vulnerability Management Policy [Insert Classification]

which you will create your own document and to which you will apply all reasonable quality checks before use. Therefore please note that it is your responsibility to ensure that the content of any document you create that is based on our templates is correct and appropriate for your needs and complies with relevant laws in your country. You should take all reasonable and proper legal and other professional advice before using this document. CertiKit makes no claims, promises, or guarantees about the accuracy, completeness, or adequacy of our document templates, assumes no duty of care to any person with respect its document templates or their contents, and expressly excludes and disclaims liability for any cost, expense, loss or damage suffered or incurred in reliance on our document templates, or in expectation of our document templates meeting your needs, including (without limitation) as a result of misstatements, errors and omissions in their contents.

Version 1

Page 3 of 13

[Insert date]

Technical Vulnerability Management Policy [Insert Classification]

[Replace with your logo]

Technical Vulnerability Management Policy

Document Classification: Document Ref. Version: Dated: Document Author: Document Owner:

Version 1

Page 4 of 13

[Insert Classification] PCI-DSS-DOC-11-1 1 [Insert date]

[Insert date]

Technical Vulnerability Management Policy [Insert Classification]

Revision History Version Date

Revision Author

Summary of Changes

Distribution Name

Title

Approval Name

Version 1

Position

Signature

Page 5 of 13

Date

[Insert date]

Technical Vulnerability Management Policy [Insert Classification]

Contents 1

INTRODUCTION ....................................................................................................................................... 7

2

TECHNICAL VULNERABILITY MANAGEMENT POLICY............................................................. 9 2.1 2.2 2.3 2.4 2.5 2.6

3

WHAT IS A TECHNICAL VULNERABILITY? ................................................................................................. 9 SOURCES OF INFORMATION ....................................................................................................................... 9 ASSIGNING RISK RANKINGS .................................................................................................................... 10 PATCHES AND UPDATES .......................................................................................................................... 10 HARDENING ............................................................................................................................................ 11 AWARENESS TRAINING ........................................................................................................................... 11

NETWORK SECURITY AND VULNERABILITY TESTING ........................................................... 12 3.1 3.2 3.3

PENETRATION TESTING ........................................................................................................................... 12 VULNERABILITY SCANS .......................................................................................................................... 12 WIRELESS ............................................................................................................................................... 13

Version 1

Page 6 of 13

[Insert date]

Technical Vulnerability Management Policy [Insert Classification]

1 Introduction Malware is any code or software that may be harmful or destructive to the information processing capabilities of the organization and is one of the primary tools used by attackers to circumvent security in order to make some kind of gain or to disrupt the normal operation of the business.

It is essential that effective precautions are taken by [Organization Name] to protect itself against this threat which can come from a number of sources including organised gangs, competitor organizations, politically motivated groups, rogue employees, nation state sponsored “cyber-warfare” units or simply individuals exercising curiosity or testing their skills.

Whatever the source, the result of a successful security breach is that the organization and its stakeholders are affected, sometimes seriously, and harm is caused.

Malware comes in many forms and is constantly changing as previous attack routes are closed and new ones are found.

In order for malicious software to carry out its intended purpose it needs to be installed on the target device or computer. There are a number of key ways in which malware infects computers and networks, although new ways are being created all the time.

The most common infection routes are as follows.

• • • •

Phishing Websites and Mobile Code Removable Media Hacking

But in order for these techniques to be used by an attacker, they must take advantage of a Vulnerability in our defences (see section 2.1 for a definition).

This document sets out the organization’s policy on how it will assess and manage technical vulnerabilities within the IT environment, which includes the cloud services it uses. Its intended audience is IT and information security management and support staff who will implement and maintain the organization’s defences.

This control applies to all systems, people and processes that constitute the organization’s information systems, including board members, directors, employees, suppliers and other third parties who have access to [Organization Name] systems.

The following policies and procedures are relevant to this document: • •

Mobile Device Policy Remote Working Policy

Version 1

Page 7 of 13

[Insert date]

Technical Vulnerability Management Policy [Insert Classification]

• • • • • • •

Acceptable Use Policy Electronic Messaging Policy Internet Acceptable Use Policy Change Management Process Software Policy Anti-Malware Policy Network Security Policy

Version 1

Page 8 of 13

[Insert date]

Technical Vulnerability Management Policy [Insert Classification]

2 Technical Vulnerability Management Policy 2.1

What is a Technical Vulnerability?

A vulnerability is commonly defined as “an inherent weakness in an information system, security procedures, internal controls, or implementation that could be exploited by a threat source.”

The software development process is complicated and its output in the form of software programs is rarely bug free. Most of these bugs simply affect the functionality of the software so that it doesn’t work as intended. However, if manipulated in the correct way, some can allow an attacker to gain some form of advantage or access which was not intended by the developer. This type of bug is considered to be a software vulnerability.

These vulnerabilities are constantly being found and corrected via software updates or patches. Unfortunately, it is not always the developer or user who discovers these vulnerabilities. When discovered by a potential attacker the vulnerability becomes something to be exploited for gain and kept secret for as long as possible. A newlydiscovered vulnerability is often referred to as a “zero-day exploit” and is difficult to defend against.

[Organization Name]’s policy with respect to technical vulnerabilities is to be aware of them and to close them where possible, either directly or via other means.

2.2

Sources of Information

The first step in managing technical vulnerabilities is to become aware of them.

Since we are talking about technical vulnerabilities these will of course depend upon the technology employed within the organization. It is necessary then to gain a full appreciation of the technology components that make up the organization’s infrastructure and their versions (since most technical vulnerabilities are very version-specific).

This should include: • • • • • • •

Operating systems e.g. Windows, UNIX, Cisco Databases e.g. SQL Server, MySQL Web servers e.g. IIS, Apache Desktop software e.g. Office, Acrobat Web technologies e.g. Flash, Java Application software e.g. SAP, Agresso Hardware e.g. servers, routers

Version 1

Page 9 of 13

[Insert date]

Technical Vulnerability Management Policy [Insert Classification]

Information about vulnerabilities with any of the above components is generally available from the vendor who will issue updates and patches to fix those that it becomes aware of.

A process must therefore be put in place to ensure that all relevant information about updates is being received and reviewed by competent staff members. This will usually give guidance about the level of urgency associated with each update.

Where configuration changes are recommended to close off vulnerabilities, these must be actioned through the organization change management process so that appropriate controls are in place for testing, risks assessment and back-out.

For cloud services, the responsibilities of the cloud service provider (CSP) and [Organization Name] as the cloud service customer, must be defined and agreed.

This may involve the CSP being responsible for vulnerability assessment and patching for some or all aspects of the service, depending on the cloud service model adopted (e.g. IaaS, PaaS or SaaS or similar service definitions).

2.3

Assigning Risk Rankings

A process will be established to review new security vulnerabilities and assign a risk ranking. A simple scoring mechanism will be implemented to place the vulnerabilities into three categories of “High,” “Medium,” or “Low.” The risk score will depend on the following factors: • • • •

Based on industry best practices on classifying vulnerability risk scores Potential impact on the organization Classification by the vendor System affected and the data it may hold

A security vulnerability can also be identified as “critical” if one or more of the following criteria are met: • • • 2.4

Poses an imminent threat to the organization Impacts critical systems (e.g. public-facing devices or systems) Will result in potential compromise to systems Patches and Updates

Patches and updates will typically be issued by software vendors on a regular schedule as cumulative packages. These will be linked to the specific version of software that they relate to and may have dependencies stipulated with other software modules, products or operating systems.

Procedures must be put in place to obtain copies of the software updates electronically when they are issued by the vendor. If an update is identified as “critical,” the update will be installed within one month of release. All other updates

Version 1

Page 10 of 13

[Insert date]

Technical Vulnerability Management Policy [Insert Classification]

will be installed within three months of release. However, the scheduling of the installation of updates will depend upon a number of factors including: • • • • •

The criticality of the systems being updated The expected time taken to install the updates (and requirements for service outages to users) The degree of risk associated with any vulnerabilities that are closed by the updates Co-ordination of the updating of related components of the infrastructure Dependencies between updates

An update release plan will be created and maintained to keep track of when various system will be updated, taking into account the factors listed above. The plan must be managed through the change management process. For updates that are low risk and regular, a standard change may be defined within the change management process to allow this to happen without excess administrative overhead (see Change Management Process).

2.5

Hardening

A further action that must be taken to reduce the number and extent of vulnerabilities within [Organization Name] systems is the hardening of server and other device configurations. This involves the shutting down of services and protocols that are not needed so that the attack surface is reduced.

These hardening activities must be carried out according to vendors’ guidelines and under the control of the change management process.

2.6

Awareness Training

As a result of vulnerability assessment, it may be necessary to increase efforts in security awareness training for employees and contract staff. This training should explain the nature of vulnerabilities and what can be done to reduce them.

Version 1

Page 11 of 13

[Insert date]

Technical Vulnerability Management Policy [Insert Classification]

3 Network Security and Vulnerability Testing A fundamental part of network security and vulnerability management is the ability to test and verify the ‘strength’ of the organization’s security controls against everchanging cyber threats. To achieve this a variety of tests will be performed as described below.

Test results will be recorded, risk assessed, ranked (usually as high, medium and low) and applied to the treatment process to remediate any vulnerabilities found.

Refer to the Risk Assessment and Mitigation Process for more information.

Internal and external targets for testing include but are not limited to: • • • • • • 3.1

Perimeter network to the internet or public networks DMZ Internal network segmentation perimeters Cardholder Data Environment (CDE) perimeter Cloud providers Wireless Network Penetration Testing

A penetration test (also known as a pen test), is an authorized simulated attack on a computer or network that looks for security weaknesses, potentially gaining access to the system's features and data.

Internal and external penetration testing will be performed by a qualified internal resource or a qualified external third party at least annually (or every six months if the organization is a service provider of card payment services) and after any significant infrastructure or application change. Tests will be based on industryaccepted penetration testing approaches (for example, NIST SP800-115).

3.2

Vulnerability Scans

A vulnerability scanner is a computer program designed to assess computers, computer systems, networks or applications for weaknesses.

Internal and external vulnerability scans will be performed at least quarterly and after any significant change to the network. To fulfil the Organizations PCI DSS compliance requirements, external scans will be performed via an Approved Scanning Vendor (ASV) designated by the PCI DSS Council.

Version 1

Page 12 of 13

[Insert date]

Technical Vulnerability Management Policy [Insert Classification]

3.3

Wireless

A process must be put in place to test for the presence of rogue unauthorised wireless access points on a quarterly basis. IDS/IPS (Intrusion Detection System/Intrusion Prevention System) technologies may be used to perform this test if available. Any potential threats found must be risk assessed and the mitigation process applied to address any vulnerabilities found. Refer to the Risk Assessment and Mitigation Process for more information.

Version 1

Page 13 of 13

[Insert date]