Transcription
Old Dominion UniversityTechnology Policies, Standards, Procedures and GuidelinesOCCS ProcedureTitle:Reference Number:Last updated:Vulnerability Scanning and Management Procedure9.4.2September 6, 2011PurposeThe purpose of this procedure is to define the management and controls used to maintain thesecurity for systems and applications using network resources.IntroductionOCCS uses a comprehensive integrated program to detect and remediate vulnerabilities withinnetwork devices to assure that maximum security afforded by the network design is maintained.Scanning ToolsOCCS uses scanning application tools capable of reporting and grouping functions, persistentapplication update and upgrades and adequate systems/customer support accommodations.The primary tool is the Rapid7 Nexpose scanner. The tool scans the network infrastructuredevices every month and generates a report on the vulnerabilities identified. In addition, theNetwork Infrastructure Parser (Nipper) firewall audit tool probes network ports and services andprovides a network vulnerability analysis. This tool is will be used to conduct twice a year reviewof network code and firewall configurations.Upon receipt of the reports and analyses the Network Engineering Team is responsible forreviewing the results and correct or implement mitigating measures for any vulnerabilityidentified (non false positives). All corrections are to be completed as soon as possible but nolater than the next scheduled scan/reporting period unless approved by management. Thesereviews and any mitigating action taken are documented for review and approval by theNetwork Engineering Manager and Director, Network Technologies and Operations.Specialized scanners are also used to identify specific vulnerabilities or provide a deeper level ofanalysis, such as Nessus, Metasploit, OpenVAS, Paros and Single Vulnerability Assessment Tools.Scanned ResourcesAll devices connected to both public and private segments of the network are scanned. Devicescans are organized by the individually defined address spaces, referred to here as a site.1
Old Dominion UniversityTechnology Policies, Standards, Procedures and GuidelinesA scan site specifies a collation of hosts to be scanned and is named after the subnet that itholds. Scan sites also identify its classification or a general description of the hosts/devices onthe 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 throughthe Footprints issue management system and assigned to the Security Team.Scanning SchedulesAll 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 serversand 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 eachmonth.All scans should be allocated at most 36 hours to complete where no other scan isrunning.The scan cycle should be established when the site is defined and should be part of thesite request.Ad hoc / individual system scans may be requested via a work request throughFootprints and assigned to the Security TeamAll 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 andNovember 15 to determine if there are associated vulnerabilities in the operatingsystem.Scan ReportingA tailored reporting schedule that works in tandem with system administration patching cycles isutilized. 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 specificapplication, managed by a specific set of administrators, etc. A device may belong to one ormore groups. Reporting is done by group so that the devices and vulnerabilities can more easilybe distributed to staff. Groups may be added or changed via a work request submitted throughFootprints and assigned to the Security Team.Documentation is located in a shared drive folder with access by the Director, InformationSecurity and others as determined by the Director of Network Technologies and Operations.2
Old Dominion UniversityTechnology Policies, Standards, Procedures and GuidelinesOfficial ReportsTitleISO Monthly Comparison ReportFrequencyMonthlyPurposeThe ISO tracks changes in the vulnerability posture ofthe University.Systems Administrator ReportQuarterlyThe system administrators review these reports andaddress vulnerabilities that are identified in a timelymanner.System Owner ReportQuarterlySystem Owners review these reports to understand thevulnerabilities that their systems may be exposed toand to work with the system administrators to performcorrective actions.CIO ReportQuarterlyThe CIO reviews these reports to ensure properresources are allocated to address outstandingvulnerabilities.As needed for new orchanged systemsThese reports are generally focused toward anindividual system and are usually requested for newsystems or when changes are being made.Re-scan ReportsAs needed to confirmcorrections.Temporary reportsAs neededThese reports are generated to refresh the vulnerabilityview to see that identified vulnerabilities have beenproperly addressed.These reports are run on an ad hoc basis as needed toassess the vulnerabilities associated with a system,group or site.Actionable ReportsOne-time Scan ReportsThese reports are generated in sequence with an allowance for a one month window betweensystem administrator and system owner and CIO reports. However, actionable device reports arereadily available upon completion of a successive scan. Report information is also availablethrough the NexPose User Interface any time.Resolution ManagementReporting of vulnerabilities is done to provide system owners and administrators the opportunityto both understand the potential risk that their systems may be exposed to and to take proactivesteps 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 thedissemination of actionable system reports as generated by the monthly scan cycle or by customreporting. Unplanned reports and alerts are made for issues regarding industry wide or Zero-Dayexploits.3
Old Dominion UniversityTechnology Policies, Standards, Procedures and GuidelinesGeneral Responsibilities by RoleSecurity TeamThe Security Team maintains the vulnerability tools, reporting,etc. and monitors the vulnerability posture of the University.The team ensures that systems are scanned for vulnerabilitieson a regularly scheduled basis and that identified vulnerabilitiesare brought to the attention of the appropriate personnel. System OwnerSystem Owners work with the system administrators toauthorize, prioritize and schedule changes to their systems orimplement acceptable mitigating controls to reduce the risk toan acceptable level. Corrective actions such as patches areconsidered normal business maintenance, however, if othermitigating controls are used, the ISO should review andapprove the controls as appropriate to address thevulnerability. It is ultimately the System Owners responsibilityto accept any unmitigated risk that remains.System AdministratorSystem administrators are to implement the corrective actionsauthorized by the System Owners. They are a technicalresource that may research and propose various resolutionsand mitigating controls. Disseminating vulnerability reportsManagement reports and vulnerability databaseIssue resolution recommendations and guidanceTracking the vulnerability resolution progressReport to the CIO unmitigated vulnerabilities ofsignificanceRespond to requests for vulnerability reviewsReview vulnerability reportsAssess the degree of risk that the vulnerabilitiesrepresentReview and approve proposed corrective actions ormitigating controlsSchedule changes with the users and the systemadministratorsFormally accept unmitigated riskReview vulnerability reportsAssess the risk of vulnerabilities to the systemPropose corrective actions or mitigating controls tothe System Owner(s)Request Vulnerability Exceptions where appropriateImplement changes authorized by the SystemOwner(s)Exceptions ManagementVulnerabilities may exist in the operating system, applications or in the way differentcomponents work together. Every effort must be made to correct issues, but some vulnerabilitycannot be fixed. Vendors may have appliances that are not timely patched, services may beexposed 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 thesystem. Sometimes the vulnerability scanner may falsely identify vulnerability. These are failuresof the scanner and do not accurately reflect the risk of the system.Exception TypesFalse positives are vulnerabilities where the scanner has identified a host as being vulnerablewhen, in fact, it is not. This can occur because some vulnerability can only be identified bysoftware version numbers. Some software will “back patch” or patch the issue without updatingversion numbers.Acceptable risk vulnerabilities are those where the vulnerability is real, but compensatingcontrols are in place to mitigate the risk or the service has been deemed too critical.4
Old Dominion UniversityTechnology Policies, Standards, Procedures and GuidelinesException Request ProceduresAll exception requests must present justification for the request. Exception can be permanent ormay have an expiration date attached. The request should clearly state if it is a permanent ortemporary exception.False positives identification may be documented through mails or footprints tickets with thesecurity staff. These are usually worked out during the scan process and before Access ControlLists are opened. These do not require ISO approval as they are failures on the vulnerabilityscanning software to properly identify the vulnerability. Justification for such requests may comein the form of vendor documentation/correspondence, application/operating system patchnotes or any other supporting documentation showing the system is not vulnerable.Acceptable Risk Exceptions must be requested through footprints to the Information SecurityOfficer. 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 reflectthe exception and a brief summary for why it was approved and what controls are in place. Anew Nexpose scan will be done on the device impacted by the exception to show the impact ofthe exception being posted. Confirmation of the posting will be reported back to the requesterby the security staff posting the exception.Exception ReviewsThe Security Team reviews all posted exception at least annually to validate that the exceptionsare still appropriate. The staff will remove any exception that is no longer required and alertappropriate system administrators.OCCS PROCEDURELast approved by CIO/departmental supervisorName5Date
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
