Vulnerability Scanning and Management Procedure Reference ...

Old Dominion University
Technology Policies, Standards, Procedures and Guidelines

OCCS Procedure

Title: Vulnerability Scanning and Management Procedure
Reference Number: 9.4.2
Last updated: September 6, 2011

Purpose
The purpose of this procedure is to define the management and controls used to maintain the
security for systems and applications using network resources.

Introduction
OCCS uses a comprehensive integrated program to detect and remediate vulnerabilities within
network devices to assure that maximum security afforded by the network design is maintained.

Scanning Tools
OCCS uses scanning application tools capable of reporting and grouping functions, persistent
application update and upgrades and adequate systems/customer support accommodations.

The primary tool is the Rapid7 Nexpose scanner. The tool scans the network infrastructure
devices every month and generates a report on the vulnerabilities identified. In addition, the
Network Infrastructure Parser (Nipper) firewall audit tool probes network ports and services and
provides a network vulnerability analysis. This tool is will be used to conduct twice a year review
of network code and firewall configurations.

Upon receipt of the reports and analyses the Network Engineering Team is responsible for
reviewing the results and correct or implement mitigating measures for any vulnerability
identified (non false positives). All corrections are to be completed as soon as possible but no
later than the next scheduled scan/reporting period unless approved by management. These
reviews and any mitigating action taken are documented for review and approval by the
Network Engineering Manager and Director, Network Technologies and Operations.

Specialized scanners are also used to identify specific vulnerabilities or provide a deeper level of
analysis, such as Nessus, Metasploit, OpenVAS, Paros and Single Vulnerability Assessment Tools.

Scanned Resources
All devices connected to both public and private segments of the network are scanned. Device
scans are organized by the individually defined address spaces, referred to here as a site.

1

Old Dominion University
Technology Policies, Standards, Procedures and Guidelines

A scan site specifies a collation of hosts to be scanned and is named after the subnet that it
holds. Scan sites also identify its classification or a general description of the hosts/devices on
the network and an appropriate scan template is selected for the site.

A new scan site can be established, or an existing one changed, by submitting request through
the Footprints issue management system and assigned to the Security Team.

Scanning Schedules
All devices are scanned on a consistent scan schedule and also on a request or as needed basis.
The defined scan cycle makes provision for a scan frequency of at least once a month for servers
and sensitive hosts with a 3 month rolling scan for all other devices on the network.

 All server scans should be scheduled between the 16th and the 29th of each month.
 All desktop and other scans should be completed between the 1st and the 15th of each

month.
 All scans should be allocated at most 36 hours to complete where no other scan is

running.
 The scan cycle should be established when the site is defined and should be part of the

site request.
 Ad hoc / individual system scans may be requested via a work request through

Footprints and assigned to the Security Team
 All software images (operating systems) on the network devices (routers, switches, VPN,

Firewalls, Wireless and DNS/DHCP) are to be reviewed twice a year on May 15 and
November 15 to determine if there are associated vulnerabilities in the operating
system.

Scan Reporting
A tailored reporting schedule that works in tandem with system administration patching cycles is
utilized. A report may or may not follow a scan.

Systems are organized into a group consisting of a collection of systems that pertain to a specific
application, managed by a specific set of administrators, etc. A device may belong to one or
more groups. Reporting is done by group so that the devices and vulnerabilities can more easily
be distributed to staff. Groups may be added or changed via a work request submitted through
Footprints and assigned to the Security Team.

Documentation is located in a shared drive folder with access by the Director, Information
Security and others as determined by the Director of Network Technologies and Operations.

2

Old Dominion University
Technology Policies, Standards, Procedures and Guidelines

Official Reports Frequency Purpose
Title Monthly The ISO tracks changes in the vulnerability posture of
ISO Monthly Comparison Report Quarterly the University.
Systems Administrator Report
Quarterly The system administrators review these reports and
System Owner Report address vulnerabilities that are identified in a timely
Quarterly manner.
CIO Report
As needed for new or System Owners review these reports to understand the
Actionable Reports changed systems vulnerabilities that their systems may be exposed to
One-time Scan Reports As needed to confirm and to work with the system administrators to perform
corrections. corrective actions.
Re-scan Reports As needed
Temporary reports The CIO reviews these reports to ensure proper
resources are allocated to address outstanding
vulnerabilities.

These reports are generally focused toward an
individual system and are usually requested for new
systems or when changes are being made.

These reports are generated to refresh the vulnerability
view to see that identified vulnerabilities have been
properly addressed.
These reports are run on an ad hoc basis as needed to
assess the vulnerabilities associated with a system,
group or site.

These reports are generated in sequence with an allowance for a one month window between
system administrator and system owner and CIO reports. However, actionable device reports are
readily available upon completion of a successive scan. Report information is also available
through the NexPose User Interface any time.

Resolution Management
Reporting of vulnerabilities is done to provide system owners and administrators the opportunity
to both understand the potential risk that their systems may be exposed to and to take proactive
steps address the identified vulnerabilities.

Between each official reporting period, vulnerabilities may be identified by the Security Team,
system administrators, vendors, or other sources. The initiation of this process begins with the
dissemination of actionable system reports as generated by the monthly scan cycle or by custom
reporting. Unplanned reports and alerts are made for issues regarding industry wide or Zero-Day
exploits.

3

Old Dominion University
Technology Policies, Standards, Procedures and Guidelines

General Responsibilities by Role  Disseminating vulnerability reports
 Management reports and vulnerability database
Security Team  Issue resolution recommendations and guidance
The Security Team maintains the vulnerability tools, reporting,  Tracking the vulnerability resolution progress
etc. and monitors the vulnerability posture of the University.  Report to the CIO unmitigated vulnerabilities of
The team ensures that systems are scanned for vulnerabilities
on a regularly scheduled basis and that identified vulnerabilities significance
are brought to the attention of the appropriate personnel.  Respond to requests for vulnerability reviews

System Owner  Review vulnerability reports
System Owners work with the system administrators to  Assess the degree of risk that the vulnerabilities
authorize, prioritize and schedule changes to their systems or
implement acceptable mitigating controls to reduce the risk to represent
an acceptable level. Corrective actions such as patches are  Review and approve proposed corrective actions or
considered normal business maintenance, however, if other
mitigating controls are used, the ISO should review and mitigating controls
approve the controls as appropriate to address the  Schedule changes with the users and the system
vulnerability. It is ultimately the System Owners responsibility
to accept any unmitigated risk that remains. administrators
System Administrator  Formally accept unmitigated risk
System administrators are to implement the corrective actions
authorized by the System Owners. They are a technical  Review vulnerability reports
resource that may research and propose various resolutions  Assess the risk of vulnerabilities to the system
and mitigating controls.  Propose corrective actions or mitigating controls to

the System Owner(s)
 Request Vulnerability Exceptions where appropriate
 Implement changes authorized by the System

Owner(s)

Exceptions Management
Vulnerabilities may exist in the operating system, applications or in the way different
components work together. Every effort must be made to correct issues, but some vulnerability
cannot be fixed. Vendors may have appliances that are not timely patched, services may be
exposed to more hosts then required, and software may be abandoned and no longer supported.
In these cases, additional protections may exist to negate the vulnerability. In these cases,
exceptions may be made so that the vulnerabilities are not identified as items of risk to the
system. Sometimes the vulnerability scanner may falsely identify vulnerability. These are failures
of the scanner and do not accurately reflect the risk of the system.

Exception Types
False positives are vulnerabilities where the scanner has identified a host as being vulnerable
when, in fact, it is not. This can occur because some vulnerability can only be identified by
software version numbers. Some software will “back patch” or patch the issue without updating
version numbers.

Acceptable risk vulnerabilities are those where the vulnerability is real, but compensating
controls are in place to mitigate the risk or the service has been deemed too critical.

4

Old Dominion University
Technology Policies, Standards, Procedures and Guidelines

Exception Request Procedures
All exception requests must present justification for the request. Exception can be permanent or
may have an expiration date attached. The request should clearly state if it is a permanent or
temporary exception.

False positives identification may be documented through mails or footprints tickets with the
security staff. These are usually worked out during the scan process and before Access Control
Lists are opened. These do not require ISO approval as they are failures on the vulnerability
scanning software to properly identify the vulnerability. Justification for such requests may come
in the form of vendor documentation/correspondence, application/operating system patch
notes or any other supporting documentation showing the system is not vulnerable.

Acceptable Risk Exceptions must be requested through footprints to the Information Security
Officer. All supporting documentation must be attached to the request for the ISO to review.
The specific compensating controls that are in place must be clearly specified. System diagrams,
vendor documentation or Access Control Lists (ACLs) are some common examples. Additionally,
the vulnerability must also be addressed in the system risk assessment and reviewed accordingly.

Exception Posting Procedure:
Once an exception has been approved, Nexpose will be updated by Security personnel to reflect
the exception and a brief summary for why it was approved and what controls are in place. A
new Nexpose scan will be done on the device impacted by the exception to show the impact of
the exception being posted. Confirmation of the posting will be reported back to the requester
by the security staff posting the exception.

Exception Reviews
The Security Team reviews all posted exception at least annually to validate that the exceptions
are still appropriate. The staff will remove any exception that is no longer required and alert
appropriate system administrators.

OCCS PROCEDURE __________________
Last approved by CIO/departmental supervisor Date

__________________________________________________
Name

5