Scanning Procedure

PREPARED BY PAUL KALININ 24 JUNE 2014 VERSION 1.0 FINAL

CONFIDENTIAL

PCI Vulnerability Scan Procedure

Queensland Airports

CONFIDENTIAL ii

Document Control Author Paul Kalinin Issue Date 24-Jun-2014 Review Date 24-Jun-2014 Version 1.0 Final Location Gold Coast Description PCI Vulnerability Scan Procedure Security Classification Confidential Date Version Description of Modification Modified By 24-Jul-2012 1.0 Document creation, PK 24-Jun-14 2.0 Updated to cater for current version of Nessus PNK

CONFIDENTIAL iii

Contents

1 Internal Vulnerability Scanning Procedure 1 1.1 Introduction 1 1.2 PCI-DSS Requirements 1

2 Scan Preparation 2 2.1 Prerequisites 2 2.2 Update Nessus Plugins 2 2.3 Discover Active Hosts 2

3 Vulnerability Scanning 3 3.1 Login to Nessus 3 3.2 Create New Scan 3

4 Validating Scan Results 5 4.1 Open Scan Report 5 4.2 Filter Scan Results 6 4.3 Validate Vulnerabilities 9

5 Remediation Requirements 11

6 Appendix A: Nessus Administration 12 6.1 Defining New Scan Policies 12

7 Appendix B Vulnerability Assessment Report Template 14

Queensland Airports PCI Vulnerability Scan Procedure

VERSION 1.0 FINAL CONFIDENTIAL PAGE 1

1 Internal Vulnerability Scanning Procedure

1.1 Introduction

The PCI-DSS standard states in requirement 11.2.1 that an internal vulnerability scan must be performed every ninety days. The tool that has been selected by Queensland Airports to conduct the vulnerability scans is Nessus. This document outlines the procedure for conducting the internal vulnerability scans using Nessus. Vulnerability scanning with Nessus will allow Queensland Airports to meet the PCI-DSS requirement for internal vulnerability scans.

1.2 PCI-DSS Requirements

The requirements stated within the PCI DSS in relation to internal vulnerability scanning are outlined below: | Internal vulnerability scans must be conducted every ninety days. A passing scan is required

within each quarter. | Internal vulnerability scan results must be documented. | If vulnerabilities are identified with a base CVSS score of 4.0 they must be rectified before a

passing scan can be obtained. | The internal vulnerability scan needs to be repeated until a passing scan is obtained. | The vulnerability scans can only be performed by a qualified internal resource.



2 Scan Preparation

2.1 Prerequisites

This procedure relies on the availability of the dedicated vulnerability scanning laptop. This is a Macbook Pro system that has both Nessus and Nmap installed.

2.2 Update Nessus Plugins

Prior to launching a vulnerability scan using Nessus, it is important to ensure that the latest plugins have been downloaded and installed. This can be done using the -update-plugins command located in the /Library/Nessus/run/sbin directory, as shown in the screenshot below: The vulnerability scanning laptop must be connected to a network that has Internet access so that the updates can be downloaded.

2.3 Discover Active Hosts

The next step in scan preparation is to obtain a current listing of active hosts within the network ranges that make up the cardholder data environment (CDE). The CDE is currently comprised of the network ranges listed below:

| Gold Coast corporate network (10.10.0.0/16) | Gold Coast carpark network (10.159.1.0/24) | Townsville corporate network (10.20.0.0/16) | Townsville carpark network (192.168.2.0/24)

The following procedure must be repeated for each of the CDE network ranges.

1. Connect the vulnerability scanning laptop to the network and ensure that it has obtained a valid IP address using DHCP. For accurate scan results the scanning system must be directly connected to the network segment.

2. Create a list of active hosts that can be loaded into Nessus, use with the following syntax:

sudo nmap –sP <network range> -oG <filename to save results>

An example is shown below:

sudo nmap –sP 10.10.0.0/16 –oG gccorpnet.txt

3. Process the contents of so that it only contains the information that is pertinent to Nessus we use the following command:

cat gccorpnet.txt | grep Up | awk ‘{ print $2 }’ > gccorpnet-nessus.txt

The above command will create a file - that is a listing of the active IP addresses within the scanned network.



3 Vulnerability Scanning

3.1 Login to Nessus

To conduct the vulnerability scan login to Nessus by entering the following URI into the address bar of an internet browser: https://127.0.0.1:8834 The Nessus logon screen will be displayed. Enter the username and password for the Nessus user. Following successful authentication the following screen will be presented:

3.2 Create New Scan

To configure a new scan click the New Scan button located in the top left hand corner of the screen. The following screen will be displayed:

The following steps are involved in configuring a scan:

1. Enter a name for the scan report in the text box denoted by

2. Using the drop down menu denoted by ,select the policy to be used for the scan. Currently two custom scan policy profiles have been created for internal vulnerability scans, these

https://127.0.0.1:8834/



betwe scan is not configured with domain credentials and scans are based purely on netw -faster scans of the environment to be conducted, it must be noted that it is likely that these scans will contain more false positives. To conduct an authenticated scan of a network range select the

3. , you can enter individual IP addresses or full network ranges eg. 10.10.0.0/16. Another option is to use a host file that can be created using the method outlined in section 2.3. A host file can be entered by selecting the denoted by display a pop up as shown in the screenshot below.

4. Select the file that contains the listing of the active hosts in the network range you wish to scan.

5. Once the relevant host listing file has been selected select the Open button.

6. Now all the variables that are required for the scan have been selected, select Launch button located in the bottom right corner of the screen. This will commence the scan and you will be presented with the screen shown below until the scan is complete.



4 Validating Scan Results

4.1 Open Scan Report

Following the successful completion of a scan, the next step is to review the scan results to eliminate false positives. When the scan is completed the results can be displayed simply by double clicking scan in the main menu. This will display the screen shown in the screen capture below:

The above report screen provides a visual listing of findings categorised by the severity of vulnerabilities identified. It is possible to change the view in which the findings are displayed. This can be achieved simply by selecting from the . This is shown in more detail in the screenshot below:



4.2 Filter Scan Results

As we are primarily concerned with vulnerabilities that have a CVSS score of over 4.0, it is a good idea to create a filter so that only the relevant vulnerabilities are displayed. To create a filter press the menu button on the Filter Hosts input box located in the top right hand corner of the screen ( this is highlighted in the screenshot below).

This will display the filter menu as shown in the screenshot below:

E vulnerabilities displayed to only those with a CVSS score of 4.0 or higher as shown in the screen capture below:

Each of the vulnerabilities displayed will need to be remediated, following remediation another scan will need to be conducted. If no vulnerabilities with a CVSS score of greater than 4.0 are present then the scan is regarded as passing.



To assist in the remediation it is recommended to export the results of the scan into either a html or pdf format. This will allow the issues to be easily distributed to relevant personnel that will be involved in the remediation process. To do this click the export button as indicated in the screenshot below:

Select HTML from the drop down list, this will display the following screen shown in the screenshot:

This screen allows the format of the report to be customised, the most useful formats for the purposes of

format, groups vulnerabilities found by host, this format is useful when systems are supported by different groups. The Vulnerability by Plugin groups vulnerable hosts under each of the identified vulnerabilities. This view is useful to get a picture of how the vulnerabilities are distributed within the network range. It also makes it easy to identify the hosts that have the most critical vulnerabilities that need to be dealt with first.



field in the left hand column and drag it to the report content section, as shown in the screenshot below:

Click on the Export button to save a copy of the report in HTML format.



4.3 Validate Vulnerabilities

To view details of a vulnerability, double click on one of the hosts and then select one of the vulnerabilities displayed. Clicking the vulnerability will produce a screen as shown in the screen capture below:

To assist in the verification of vulnerabilities, an explanation of relevant sections of the vulnerability details shown in the previous screen capture are listed below:

| Description: this provides a brief description of the vulnerability. | References: this provides a list of references that can be reviewed to obtain more details about

the vulnerability. It may also contain information that details how to exploit the vulnerability. This can be useful in assisting in the process of verification for vulnerabilities for which a clear explanation is not provided.

| Hosts: this section provides a listing of all of the hosts within the scan targets that are affected by this vulnerability.

| Nessus Test Procedure: this is the section of the vulnerability description below the host listing, This is important as it often provides the results of tests that were completed within the scan and gives the basis for which the host was determined to be vulnerable.



The procedure for vulnerability verification is outlined below:

| Review each vulnerability in the scan report. | For each vulnerability, review the vulnerability description and if necessary the references

provided. This should provide you with some background about the vulnerability and the possible steps necessary for verification.

| If details are provided about the Nessus test procedure within the vulnerability description, then these should be manually tested to provide verification. If no details are provided then follow any verification procedures detailed within the external references section.

| If a vulnerability is determined as being a false positive, it should be listed within a section of the vulnerability assessment report1 along with the logic and supporting evidence for the determination.

| Verified vulnerabilities should be documented within the vulnerability assessment report. The documentation of vulnerabilities within the report should include the following information:

o Vulnerability description; o Affected hosts; o Risk Rating i.e. High, Moderate and Low; o Individual responsible for remediation; o Remediation status.

1 A template that can be used for the documentation of vulnerabilities discovered can be found in Appendix B.



5 Remediation Requirements The PCI-DSS standard requires that all vulnerabilities that have a base CVSS score of greater than 4.0 be remediated before a passing scan can be obtained. Therefore, any vulnerabilities that have been verified in the previous step must be remediated. Following the remediation of the vulnerabilities, a new Nessus scan needs to be conducted on the relevant network ranges. If the scan produces a report with no vulnerabilities with a CVSS score of greater than 4.0, then the scan can be regarded as a passing scan. However, if vulnerabilities are still detected that prevent a passing scan the process of remediation and rescanning needs to be repeated until a passing scan can be obtained.



6 Appendix A: Nessus Administration

6.1 Defining New Scan Policies

Often specific policies are required to perform vulnerability scanning of certain types of hardware, or assess specific areas such web applications. To create a customised policy to following parameters need to be defined:

1. Log into the main Nessus view using a web browser and select the Policies view, from the menu at the top of the screen.

2. This will display the policies screen, as shown in the screenshot below:

3. To create a new policy press the New policy button this will display the policy wizard (shown below). It is possible to choose one of the pre-defined templates that can be used to cater for typical types of scans. Choose the Advanced policy option if none of the pre-defined templates match your requirements:



4. The first step in creating an advanced policy is to give the policy a name, which is entered into the name field on the screen. This shown in the screenshot below:

5. If authenticated scan is requiredof the screen and enter the relevan Credentialsprovide settings to allow Nessus to login to devices and servers and perform better audits. Credentials can include, domain credentials, SNMP community strings, SSH passwords and other types of credentials. Without defining any credentials it is assumed that scans will be performed simulating an anonymous user.

6. The majority of configuration settings that would typically be customized in a scan can be found by selectin

7. In the Preferences section, the policy can be customised to perform extended task, such as web application scanning, brute force password attacks, and numerous other scanning parameters. The required preference can be selected from the drop down menu. When defining a new policy each of the Plugin options should be reviewed to ensure that the default settings defined will not adversely impact the target environment.

Once finished configuring the policy select Save in the lower right corner of the screen to save the settings of the scan. The policy can now be selected when creating a new scan.



7 Appendix B Vulnerability Assessment Report Template The following table provides an example format that can be used within the vulnerability assessment report for documenting vulnerabilities. Host

Vulnerability Risk Rating Assigned To Current Status ETA

10.10.100.10 Missing MS08-067 security update from Microsoft. This can provide remote code execution from within the server service

Critical Peter Carter Patch has not been applied.

As server plays an important role within several business processes the first available change window to apply this patch was the 28/07/2012 at 11pm.

Scanning Procedure

Documents

Transcript of Scanning Procedure