ISO Vulnerability Operational Documentation
Operational Vulnerability Management Documenation
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.
- Scans can be broken up logically and initiated on a distributed schedule to control loads on the servers and the systems.
- Breaking up the scans allows for more granular control of the scanning for scheduling and reporting.
- Inventories of systems are now associated with support structures (departments, individuals, groups) that are the focus of the agent groups.
- 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.
- 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.
- Having an automated discovery and vulnerability capability satisfies the automated inventory requirements for all security frameworks.
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
- 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.
- 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.
- 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)
Scanners deployed but not in service: Agent-r, Scanner-i, Scanner-Adminsys
- 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