OCCS Procedure. Vulnerability Scanning and Management Procedure Reference Number: Last updated: September 6, 2011

Transcription

1 OCCS Procedure Title: Vulnerability Scanning and Management Procedure Reference Number: 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

2 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 16 th and the 29 th of each month. All desktop and other scans should be completed between the 1 st and the 15 th 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

3 Official Reports Title Frequency Purpose ISO Monthly Comparison Report Monthly The ISO tracks changes in the vulnerability posture of the University. Systems Administrator Report Quarterly The system administrators review these reports and address vulnerabilities that are identified in a timely manner. System Owner Report Quarterly System Owners review these reports to understand the vulnerabilities that their systems may be exposed to and to work with the system administrators to perform corrective actions. CIO Report Quarterly The CIO reviews these reports to ensure proper resources are allocated to address outstanding vulnerabilities. Actionable Reports One-time Scan Reports As needed for new or changed systems These reports are generally focused toward an individual system and are usually requested for new systems or when changes are being made. Re-scan Reports As needed to confirm corrections. These reports are generated to refresh the vulnerability view to see that identified vulnerabilities have been properly addressed. Temporary reports As needed 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

4 General Responsibilities by Role Security Team The Security Team maintains the vulnerability tools, reporting, etc. and monitors the vulnerability posture of the University. The team ensures that systems are scanned for vulnerabilities on a regularly scheduled basis and that identified vulnerabilities are brought to the attention of the appropriate personnel. System Owner System Owners work with the system administrators to authorize, prioritize and schedule changes to their systems or implement acceptable mitigating controls to reduce the risk to an acceptable level. Corrective actions such as patches are considered normal business maintenance, however, if other mitigating controls are used, the ISO should review and approve the controls as appropriate to address the vulnerability. It is ultimately the System Owners responsibility to accept any unmitigated risk that remains. System Administrator System administrators are to implement the corrective actions authorized by the System Owners. They are a technical resource that may research and propose various resolutions and mitigating controls. Disseminating vulnerability reports Management reports and vulnerability database Issue resolution recommendations and guidance Tracking the vulnerability resolution progress Report to the CIO unmitigated vulnerabilities of significance Respond to requests for vulnerability reviews Review vulnerability reports Assess the degree of risk that the vulnerabilities represent Review and approve proposed corrective actions or mitigating controls Schedule changes with the users and the system administrators Formally accept unmitigated risk Review vulnerability reports Assess the risk of vulnerabilities to the system 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

5 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 Name Date 5