Security, Vulnerability Scanning Program, General Information
Overview of Vulnerability Scanning Program including information on tools used and reports generated.
This document details the security vulnerability program, common sources, tools, and policies used by Security for vulnerability management at the University of Illinois. Please note that while the Cyber Security Operations Center (CSOC) performs security vulnerability scans in many instances, individual system, infrastructure, and service stewards are responsible for discovering and managing their exposures, vulnerabilities, and associated risks.
- System Vulnerability Scanning
- Goal: Continuously probe university systems and networks for vulnerabilities and exposures such that the university has the most accurate & timely information.
- Goal: Provide service owners with access to accurate and timely vulnerability information.
- Goal: Perform timely scans of critical infrastructure including data centers.
- Service: Consult with stakeholders, service managers, and interested parties regarding: understanding results, understanding tools available, security scanning practices, planning/prioritizing remediation, validating results.
- Limitation: Vulnerability remediation of system and services must be done by service managers.
- Limitation: Scans upon request, new system/service scans, and review of reports must be done by service managers.
- Limitation: Campus IP space exceeds current scanning tools licenses, therefore ability to scan certain subnets may be limited.
- Application / Web application Vulnerability Scanning
- Goal: Provide recommendations and resources for application owners to perform application scans.
- Service: Provide web resources and consulting on tools available.
- Limitation: No purchased campus application scanner is currently available.
- Limitation: Application owners must know secure coding practices and steps for remediating applications.
- Limitation: Vulnerability remediation of applications must be done by application owners.
- Internal / External Vulnerability Reports
- Goal: Provide a single source for Internal / External agencies to report vulnerabilities.
- Goal: Review, approve, and implement appropriate external reporting and scanning services.
- Service: Validate reports and forward appropriate information to service owners and stewards.
- Service: Respond to critical vulnerabilities with appropriate action sanctioned by University leadership.
- Service: Report overall state of vulnerability detection capabilities and known campus vulnerabilities to campus leadership.
- Limitation: Internal scanning may only be conducted on services / systems owned by the unit and must use approved security tools.
- Limitation: External reports vary in quality and validation requirements may exceed staffing resources.
- Risk: Network, system, and application scanning all have inherent risk. This practice is approved by both campus and Technology Services Leadership to understand campus vulnerability and risk. Where possible, internal and external scans are limited to avoid systems and service interruptions. Scanning tools and services are continuously reviewed.
Vulnerability Scanning Practice and Tools
HOW TO GET/USE
|QualysGuard||Cloud SaaS tool used to detect and track host and network level vulnerabilities. Scanning engines are hosted on prem and the Qualys Cloud||IT pros can register and use QG by emailing firstname.lastname@example.org|
|Nmap||Scriptable port scanner||Free tool; Can be downloaded, installed and used by responsible IT pros on any Linux or Windows computer|
|Burp Pro||Manual/automated web application vulnerability testing tool||Security/SDG QA use only. Free version available but has limited but useful functionality.|
- Standard scanning profiles have been developed for the QualysGuard tool.
- Access to Privacy and Security managed tools may be provided by a member of the Vulnerability Assessment Team.
- Scan reports are considered confidential and should not be shared with non-stakeholders unless authorized by the campus Chief Privacy and Security Officer.
- Reports will be made available to system and service managers, their managers and directors (on request) and the Vulnerability Assessment Team.
- QualysGuard scans will be stored in the Security Office's logging environment for correlation with network based attacks.
Scanning Engine Source List
Technology Services maintains multiple vulnerability assessment technologies each targeting specific layer in the service delivery stack, though some degree of overlap exists in each.
Authorized scanning resources are listed below for general reference. This is a non-inclusive list as the vulnerability program needs it may use additional resources not listed here. External agencies both approved and not approved continuously scan our network for vulnerabilities. If you have questions about scanning activity from the any source, feel free to contact email@example.com
|nmap, Nessus, custom, others*||scanner.opia.illinois.edu||22.214.171.124||*Multipurpose security scanner, other tools used as needed|
|nmap, Nessus, custom, others*||scanner2.opia.illinois.edu||126.96.36.199||*Multipurpose security scanner, other tools used as needed|
|QualysGuard local network scan engine||qg00.cites.illinois.edu||188.8.131.52||Scanning appliance|
|QualysGuard local network scan engine||qg01.cites.illinois.edu||184.108.40.206||Scanning appliance|
|QualysGuard cloud scanning engines||---||220.127.116.11/20|
|Multipurpose and application scanner||opia-loic.ad.uillinois.edu||18.104.22.168|
External web application scanner run by UT Austin which continually scans all Illinois assets https://security.utexas.edu/dorkbot
|Shodan||census[1-12].shodan.io||†||†There are many shodan scanners, but they all should resolve to shodan.io addresses. Use the shodan web console to enumerate info found by Shodan|
Standards in play
Tech Services scanning standard (older)
- All systems and services owned/operated by Technology Services must undergo a vulnerability scan before being placed into production.
- Service and system managers are obligated to remedy, mitigate, or gain executive risk acceptance for any high, or critical vulnerabilities uncovered by the scans before the system is placed into production.
- Security will arrange for a recurring schedule of automated scans of hosts in the data center. Scan results revealing vulnerabilities will be made available to the appropriate system or service stakeholders.
- The scanning and remediation requirements outlined in this document are suitable to be used to fulfill security requirements in the Change Control Board process.
- Systems at higher than normal risk or criticality may be assessed or scanned at any time due to their heightened exposure to external threats.
- Critical threat intel with regard to UIUC resources may trigger a campus-wide vulnerability scan.
Recurring Scan Practice Description
- Every active development or test machine in a campus datacenter will be scanned on the third Thursday of the month,. The scans will start at 10:30 AM.
Every active production machine in a campus datacenter will be scanned 4 times a year on
Tuesday of Spring Break
Tuesday following June 15th
Tuesday of Fall Break
Tuesday following January 4th
Scans start at 10:30 (AM). 1
- Note that there may be some variation in the above schedule due to unexpected operational needs, however a notice will always be delivered to stakeholders containing a scan notice with the intended window prior to any scan event.
- Network scans will use all available plugins, except those deemed too impactful or inappropriate by the service manager of the scanning service.
- If a certain plugin is causing problems, system administrators should contact the service manager of the scanning service.
- Administrators and stewards are responsible for reviewing critical scan results and are expected to remedy or mitigate exposures in a timely fashion.
- Systems may be rescanned after vulnerabilities are addressed.
- Systems that display an unusually large number of vulnerabilities, or are subject to an unusually large number of security incidents may be scanned at a higher frequency, (possibly daily or weekly) until these systems fall into the range of acceptable risk, as determined by campus.
Network Port: A numeric identifier assigned to different TCP or UDP channels on a network interface. Although port numbers range from 0 to 65535, many well-known services have reserved port numbers between 0 and 1024 (e.g., HTTP uses port 80, Telnet uses port 23, and FTP uses ports 20 and 21.) To establish a session with a host, a network request must be sent to the appropriate port number on the host (i.e. to establish an HTTP session with a web server, your workstation software will send a request to port 80 of the web server).
Port Mapping: The process of sending packets to selected service port numbers (HTTP-80, Telnet-23, etc.) of a computing system with the purpose of collecting information such as available network services from that system. This non-invasive process is helpful for troubleshooting system problems or tightening system security. Network port scanning is an information gathering process, and when performed by unknown individuals it can be a prelude to attack.
Scanning: The process of gathering information on computing systems, which may be used for system maintenance, security assessment and investigation, and for attack. This process includes port mapping, vulnerability scanning; and at times (with the cooperation from system owners), authentication and internal information gathering. If used properly, scanning of this type is an excellent tool for protecting University information resources. Malicious scans can be a prelude to the disclosure of sensitive data, loss of service, and damage to the University's reputation in the global community.
Vulnerability Scanning: The process of identifying known vulnerabilities of computing systems on the network. This process goes a step beyond identifying the available network services of a system as performed by a network port scan. The vulnerability scan attempts to identify specific weaknesses in the operating system or application software, which can be used to compromise or crash the system. The vulnerability scan is also an information gathering process, and when performed by unknown individuals it is considered a prelude to attack.
Application Scanning: The process of identifying known vulnerabilities in software applications using automated scanning tools. These tools use methods such as querying and spidering to identify all pages and functions in a web site or application. It then tests the limits of each function or input identified with tests developed against common vulnerabilities and common OWASP top 20 flaws such as cross-site scripting, sequel injection, injection through i-frames, cross-site request forgery, authentication bypass, and other commonly occurring issues.
For any questions please email firstname.lastname@example.org.