Current revision updated by rgilbert39 on
Originally created by rgilbert39 on
  • OIT: Office of Information Technology 
  • USG: University System of Georgia 
  • TSO: Technology Services Organization 
  • Vulnerability: A weakness or exposure in IT systems including networks, applications, Operating Systems, Firmware, ETC. 
  • CISA:  Cybersecurity and Infrastructure Security Agency
  • Mitigate: reduce or eliminate vulnerability. This does not necessarily mean it is resolved with a patch but reduced with Compensating controls such as firewalls or other means. 
  • Patching: implementing software or configuration fixes to mitigate a vulnerability. 
  • Defense-in-Depth: The practice of protecting endpoints with many methods. Examples include behind a firewall and patching or adding tools such as Intrusion Detection, ETC. 
Vulnerability Detection 

Vulnerability detection is performed by Qualys with scheduled scanning and firewall API. The scanning is performed weekly and provided on 2 different reports: FIRE report and coc-FW_scan. 

The firewall API allows TSO users with access to fw.noc.gatech.edu to be able to scan endpoints one at a time for Vulnerabilities. The API shows level 4 and level 5 vulnerabilities on the interface as well as providing the ability to generate a Qualys report of all vulnerabilities for the endpoint. This is used to ensure high and critical vulnerabilities are addressed before opening ports, and as a tool for TSO users to check for the status of vulnerabilities they are working on.  

The FIRE report is produced for a GT initiative to control the lack of patching in the past. It started at external facing Critical and currently includes High. The intent is to work down in severity until eventually addressing all.  It is rated by the CVSS scoring system and not the Qualys level rating system. Although the intention is external, any device with a Qualys agent installed on an IP ever seen as public will also be reported.  

The coc-FW_scan report is generated over the weekend and shows any vulnerability at level 4 (high) and level 5 (critical) that can be seen from the network. These may be mitigated by a firewall rule but will still show to ensure it is reviewed and addressed.  If a compensating control is accepted, the vulnerability will be “ignored” with a reason in the firewall to show it had been accepted, which will remove it from future scans. The Ignored Vulnerabilities will return on scans periodically and be reviewed again.  

Differences in the two reports are due to the scanning source and the metrics. FIRE will scan from outside only and pull from certain QA agents, which makes it possible for a Vulnerability to show on coc-FW_scan as it scans the internal network to see if the host has vulnerabilities that are not local to it.  The metrics also can show an inconsistency in vulnerabilities as well as they are calculated by two different groups that may rate them differently. 

Weekly Ignored Report 

All Vulnerabilities marked as ignored from scanning are reported weekly on a report labeled COC-FW-Ignored. This report is generated over the weekend and is intended for weekly review to audit accepted vulnerabilities for validity and for any possible updated mitigations, such as patches. As COC practices defense in depth, any changes to mitigation capabilities will change the status of these vulnerabilities to allow the updated mitigation to be performed. If there is a large footprint, then rather than removing the ignore status, the update may occur as a project, and tracking could be done by watching the vulnerabilities fall off the COC-FW-Ignored report. 

Vulnerability Priority 

Vulnerability mitigation will follow CISA guidelines. This means COC’s goal is a Critical vulnerability will be addressed within 15 days of detection and a High within 30 days of detection. Mediums and lows can be addressed during patching cycles. In the event this cannot be done, these vulnerabilities must be tracked, and a business statement given on why they cannot be addressed with an estimated time of when the mitigation can occur. Note that compensating controls can be used as a form of mitigation until full remediation can occur so a compensating control set in those 15 or 30 days can fulfill the requirement.  

The coc-FW_scan report is the priority report as it focuses on Critical and High Vulnerabilities that are visible from the network. These vulnerabilities are the most likely to be exploited, so they will be the first to be reviewed and mitigated.  

When opening ports or adding/editing rules for an endpoint, the user must run an API scan for the endpoint to check its vulnerability status. If a Vulnerability shows, it is high or critical and must be addressed before any changes are made. If it is already open to the public internet, it must be addressed within a 15-day Window, meaning a ticket is opened as a Vulnerability and tracked with TSO Security.  

Critical and high for FIRE that can be seen from the public internet would be seen on the coc-FW_scan report and would be addressed there. The FIRE report is maintained by Patching cycles, OS Upgrades, and the decommissioning of equipment.  Mitigation is desired for defense-in-depth. However, Mitigation of the network-facing vulnerabilities will take precedence.  

As Vulnerability management matures, such as FIRE being completed, Vulnerability reports will move to a single approach and will be classified by priority only and addressed in that manner to allow for an easier-to-follow and centralized approach. 

Metrics and Measurement 

Scanning and tracking are centralized by The Trello boards for each report. These are updated on a weekly basis to report New and completed vulnerabilities as well as the team responsible. They are separated by boards per report for the purpose of priority. 

Monthly Security meetings are conducted and recorded as a method to track and speak to the security of COC including Vulnerability progress. These meetings are stored for 1 year for auditing purposes and trend analysis. Vulnerabilities are measured for the Month per Report to upgrade status as well as to any large changes in the statuses. 

FWOPSVulnerability.py

FWOPSVulnerability.py is the script designed to automate the Vulnerability process to about 98 percent. It requires manual intervention to retrieve and rename reports, create new coc-FW_scan tickets, maintain large coc-FW-scan projects, monitor progress for reporting, and close completed tickets. Tickets should always be closed manually to ensure the mitigation steps are documented. 

The automation expects the naming for the coc-FW_scan report to be fwscan<mmdd> and The FIRE report to be opsfire<mmdd> where m is for month and d is for day. This allows for the script to differentiate between which report it will be running.  

Running the automation requires one to open a terminal directory and change to the directory of the script and the saved reports filed in .csv format. Entering python3 FWOPSVulnerability.py firewall compare –date <MMDD of the report filename>> will begin the process. This will take time as the Script will query Inventory (SnipeIT) for needed information such as TSO Point of contact, asset name, and other information to simplify tracking, and it will Query Trello to see if the vulnerability is new or resolved and update accordingly. Entering python3 FWOPSVulnerability.py opsfire compare –date <MMDD of the report filename>> will do the same for the FIRE report but will also ask for RT credentials as it will create a new ticket in the “Operations: Vulnerability Project” queue if there is a new host. Any completed vulnerabilities will be checked off the Trello cards and when all are done, the card is moved to the “Complete” list with Trello automation. The coc-FW_scan report does not create RT tickets on purpose as there will be times a vulnerability of a large footprint may occur that is better tracked in processes and if this does not occur, the number of vulnerabilities is very small per week which makes it easy to create the Tickets as needed. 

Excluded from Scanning 

Some subnets and endpoints may be excluded from scanning for various reasons. Subnets will be built with the appropriate controls in place and will be restricted to the devices designated to be used in that subnet. The subnets are part of Risk analysis, documented, and tracked. They currently use the Policy exception process for GT awareness until they have a different policy to track. Endpoints will use the policy exception process until Research Category 3 for Minimum endpoint standards are in place and will also be tracked and inventoried. 

Vulnerability Management Flow Diagram 

Legend: 

  1. Green: Both reports share steps 
  2. Blue: Operations Fire flow 
  3. Pink- Firewall scan flow 

 

Links to More Information 
Filing Categories
Identifier Categories
Specific categories