ISO Vulnerability Operational Documentation

Operational Vulnerability Management Documenation


Contents











Vulnerability Identification, Notification, and Management


The Rice ISO manages systems risk on Rice Networks using both active and passive tools.  The Vulnerability Management portion is passive in that no active corrections to systems are performed only identification and notification.  The primary tools for this work are currently provided by Tenable/Nessus scanners.  The tools consist of a number of servers that are linked to the single management service in Tenable.SC (Tenable Security Center aka https://prometheus.rice.edu).  From this system all vulnerability identification and notification take place.  There are additional servers  (Scanners and Agent managers) that are associated with Rice sub-networks by way of scan zones that perform the actual network or Active scans of those and other networks.  The scanners can also perform Agent Management or Network Monitoring.  Scanner service functions should be isolated from each other per the vendor's best practices.  So we do not use an Agent scanner to perform network scans or Network Monitoring an example.  See the architectural drawings for deployment details.  


Both network (Active) scans and Agent scans are performed on schedules defined in the Tenable.SC server.  These are documented in Box so that they can be more easily seen and manipulated.  Scan schedules are used to lower the impact on scanners and allow all Agent-based systems scans to be completed three times per week and Active scans to be completed within a 10-12 day time frame.  Link to schedules inbox


Systems with agents are NOT network host scanned as this is a vendor best practice.  That is to say that systems with agents are not network scanned for vulnerabilities, however, they are included in discovery scans.  Agent scan results,  when completed are stored in a database called a Repository by Tenable that is specifically for agent data.  Repositories hold the results of agent and network scans which are both different types of repositories.  


Two different types of Network (Active) scans are scheduled monthly.  A Discovery scan, which is a special Active scan, is configured to perform a sweep of a VRF network (syn scan or ping sweep) to identify any system on the network and only takes minutes to complete for a given VRF.   The discovery scan results dynamically provide a list of systems identified as connected to the network so that they can be scanned for vulnerabilities - again following vendor best practices.  A Host scan, which is an Active scan or network scan uses vulnerability plugins to identify any vulnerability that can be identified over a network connection.  The host scans utilize two different Tenable Assets to identify IP addresses on the network to be vulnerability scanned.  The first asset is the target or range of addresses defined in the discovery scan and is noted by the identifier "Discovery" in the title.  This is a static IP-based asset type.  This asset contains the ip range in CIDR notation of the VRF to be scanned in the discovery scan.  The discovery asset is simply the collection of all network-connected devices within a VRF found during the most recent discovery scan.  The second asset denoted by the name "No Agent Host Scan" is an asset that points to the same network range as the discovery but includes a filter to eliminate any system with an agent plugin.  The Discovery Asset is the target in the configuration of the discovery scans while the No Agent Host Scan is the target for the host scans.


Using this best practice method for scanning we are able to reduce the time required to scan the network, eliminate duplication in host scans by eliminating agent-managed systems from those scans, and identify systems without agents so that they can be targeted for remediation.


 Tools






Agent Manager




The agent's manager is a Tenable / Nessus product that is used to manage the deployed Nessus agents.  While currently, the manager can initiate agent scans directly, ISO initiates all agent scans from Tenable. SC.  When an agent is installed on a system, it is a two-part process.  The software is installed and then the agent is linked to a server.  The server it is linked to is the agent manager.  The system's agent can be joined with parameters that include a group designation.  Currently, OIT is deploying systems with various group designations via SCCM, Jamf, and Satellite/Ansible.  Agents can also be associated with a group manually in the Nessus Manager which provides tools for manipulating group membership.




Group Designations are important in that they identify collections of systems to be targeted for agent scans similar to assets for host scans.  The results of those scans are stored in repositories managed by Tenable. SC.  Reports that are distributed to various groups are associated with those repositories or groups of repositories.  This provides a number of benefits.


    

  1. Scans can be broken up logically and initiated on a distributed schedule to control loads on the servers and the systems.
    2. 

  2. Breaking up the scans allows for more granular control of the scanning for scheduling and reporting.
    3. 

  3. Inventories of systems are now associated with support structures (departments, individuals, groups) that are the focus of the agent groups.
    4. 

  4. There is an association with the groups and the management services SCCM, JAMF, and Satellite/Ansible when systems are deployed so that deployment is ensured for a new system.
    5. 

  5. Generally, there is a one-to-one correlation between a group and a repository for better data management as reports are repository-centric allowing ISO to follow the least access principles with vulnerability information. 
    6. 

  6. Having an automated discovery and vulnerability capability satisfies the automated inventory requirements for all security frameworks.
    7. 



Centralized deployment of agent advanced configuration is a primary feature.  Agents can provide granular control for the impact the scan may have on the systems where they are installed.  This allows different types of systems on different schedules to be scanned with little or no impact  The vendor has provided a number of tuning and control parameters that are available for making sure that vulnerability scanning has minimal impact on production systems and services.  These are available in the Advanced Settings.  When implemented, a setting is distributed to all agents when they check-in.  Some examples of these settings are  (See https://docs.tenable.com/nessus/Content/SettingsAdvanced.htm)


    

  • Stagger Scan - provides a random start for groups of agents being scanned.
    • 

  • Scan Performance - allows setting the level of performance for systems when scanning (nice mode)
    • 

  • Plugin Compilation Performance - allows setting the level of performance for systems when compiling plugins
    • 



While agent scans generally low impact on the systems, we want to be cognizant of scan impacts on sensitive systems. Agent scans and look for changes.  The more changes in a system from the last scan, the longer the next scan can impact the system.  In addition to agent controls, scheduling is used to reduce the impact on systems and services and to target use cases to ensure that we get the most systems scanned during a scan window.  Since agent-based systems are broken down into management groups we have been able to separate servers from desktops and identify systems with specific functions.  Server agent scans are scheduled for off hours and a shorter duration as they are always on the network.  Lab systems are similarly scheduled for the same reason.  Desktop systems are scheduled during the work day when we know they have the best chance of being turned on.


There are maintenance processes that need to occur by Agent Manager to ensure that things are working as expected.   There is also a scan schedule that needs to be adjusted from time to time.  When new scans are added or modified the schedule needs to be consulted to ensure that the scans are complete before the reports are issued.  This ensures that the most current data is in the report.  Those who are responsible for patching systems depend on this information to validate their remediation work.


The scan schedule is located in Box https://rice.box.com/s/9e6ji8pcvjc56oale3stlgi76f99dm4o


Agent Manager


Weekly -


    

  • Checking the agent manager to ensure that it is running correctly on.  There are automated processes for updating the version of Nessus Manager and downloading plugins. 
    • 

  • Checking the performance levels during scanning on MWF.
    • 



Tenable. SC


Weekly - 


    

  • MWF checks for agent scan to ensure that they complete successfully and if not restart them manually.  This ensures fresh data for the follow-up reports.
    • 

  • MF Reports are verified when they are distributed to ensure that the results are not empty, distributed to the appropriate individuals or groups, and to verify any changes to the filter that may impact results.
    • 

  • Verify scan jobs and reports are completed successfully.
    • 

  • (NEW) Weekly discovery scans.  These are ping sweeps for all of the network ranges and provide information for the follow on agent scans to identify any new systems on the network.  The frequency of discovery scans should increase as the vulnerability processes mature.
    • 

  • (NEW) Weekly network (Active) scans are used to look for vulnerabilities in IOT, Printers, OT, storage, cameras, and security systems that are not able to accommodate a Nessus Agent.  They also identify systems that can have agents but are not installed and need them.  The network scan can identify the absence of both Nessus and FireEye agents. 
    • 



Continuous -


    

  • Soon to be implemented with Tenable NNM, these are not active but passive scans of OT equipment, Power control systems, VOIP, and others that have fragile network stacks that can not survive a network scan or performance requirements that prevent network scans from interfering with their production service.
    • 







 Generalized Server Architecture


This diagram shows a redundant architecture that will allow scanners to scale in order to maintain scan schedules and provide redundancies in the architecture.  


CURRENT NEEDS  (Agent Scanner Master, Agent Scanner B,  Additional secondary scanner for all Rice VRFs to act as load sharing and redundancy device)


Architecture


Scan zones are an abstraction of the IP ranges associated with one or more active scanners.  This configuration is the requirement for network or (Active) scans and not Agent scans which have their own architecture as shown in the drawing with orange lines.  The best practice is to ensure that 2 or more scanners are able to scan the same IP ranges.  This allows for continuity of vulnerability scans when maintenance is required on a scanner and automatically distributes the load of the scan equally across all scanners defined in the zone allowing the scans to complete faster.  There are no hard and fast rules when trying to define the number of network scanners.  You deploy the quantity and distribution based on your requirements for completing the scans in a time schedule for the size of your network.  For the size, complexity, and dynamic of the Rice network, a weekly network scan should be an achievable goal that provides sufficient information about vulnerable systems on our networks.




Passive Scanners


The Nessus Network Monitor (NNM) passive scanner is a device used to identify vulnerabilities strictly by the use of behavior analysis and passive listening on a network.  This service is specifically targeted at devices that are sensitive to network port scanning or can have service disruptions during a network scan.  The passive scanner is being deployed to cover current blind spots in Rice networks such as Infrastructure, and VOIP, and sensitive equipment such as monitoring interfaces for DC power distribution, SCADA, and other control systems.  The passive (NNM) scanner is a separate installation of the Nessus scanner suite.




Current Architecture


Scanners deployed but not in service: Agent-r, Scanner-i, Scanner-Adminsys





Tenable -Nessus Architecture


Notes: 


    

  • Some wireless 168.5 are scanned but not actively.  The scan results show systems being scanned have agents that discover the wireless IP in the 168.5 range and are assumed to be laptops or desktops with wireless adapters.
    • 

  • The Network Management VRF is believed to be vlan 0 where network device management is configured.  This network is currently only open to OIT Network management and may be a good candidate for NNM.
    • 

  • The VOIP network may be another candidate for NNM
    • 

  • The Parking PCI network has a compliance obligation for scanning but is not currently scanned
    • 

  • Native is a network unknown to ISO but is in use and may be associated with VLAN 0
    • 

  • Science DMZ and DMZ VRFs are not monitored nor scanned.  Some systems may have FireEye
    • 





References:


https://docs.tenable.com/other/nessus/Tenable_ProServ_Scan_Strategy_Guide.pdf


https://docs.tenable.com/nessus/Content/DeploymentConsiderations.htm


https://docs.tenable.com/tenablesc/director/Content/ScanZones.htm


https://docs.tenable.com/tenablesc/Content/AgentScanSettings.htm


https://community.tenable.com/s/article/How-does-Tenable-sc-balance-jobs-between-scanners





Keywords:
ISO,Security,Vulnerability,Tenable,Nessus,Architecture  
Doc ID:
118370
Owned by:
Mustafa K. in Rice U
Created:
2022-05-06
Updated:
2023-03-29
Sites:
Rice University
Clean URL:
https://kb.rice.edu/iso-vulnerability-operational-documentation