South Plains College
Information Services (SPC-IS)
Vulnerability Scanning Standard: I-E(d)
Purpose and Benefits
South Plains College utilizes automated tools to scan systems, computing and network devices, web applications, and code. The results of these scans help inform management and system administrators of known and potential vulnerabilities.
Vulnerability management is a process by which the vulnerabilities identified through scanning are tracked, evaluated, prioritized, and managed until the vulnerabilities are remediated or otherwise appropriately resolved. Managing the vulnerabilities identified during scans ensures that appropriate actions are taken to reduce the potential that these vulnerabilities are exploited and thereby reduce the risk of compromise to the confidentiality, integrity, and availability of information assets.
Information Statement
The Information Security Policy: I-A states that all systems must be scanned for vulnerabilities. Each system must also be inventoried, and an individual or group must be responsible for maintenance and administration.
Types of Scans
The type of vulnerability scans appropriate for a given target depends on the target type (e.g., hardware, software, or source code) and the target’s location (e.g., internal or external to the network). The table below lists the types of vulnerability scans required by this standard.
Type |
Description |
External Infrastructure Scan |
Scans of the perimeter of networks or any externally available hosted infrastructure to identify potential vulnerabilities in Internet-accessible IT infrastructure. |
Internal Infrastructure Scan |
Scans of IT infrastructure on protected networks or any hosted infrastructure to identify potential vulnerabilities. |
“Lite” Web Application Scan |
Cursory unauthenticated scans of externally facing production web applications to identify security vulnerabilities. |
In-depth Web Application Scan |
When implemented, authenticated in-depth scans of web applications to identify security vulnerabilities. |
Application Source Code Analysis |
Scans of application source code run during development to identify problems in the code that could cause potential vulnerabilities. |
Scanning
The ISO is responsible for confirming that vulnerability scans are conducted. SPC must use a scanning tool approved by the ISO or designated security representative. Any approved scanning tool must be able to provide remediation suggestions and associate a severity value to each vulnerability discovered based on its relative impact on the affected system.
As per the Information Classification Standard: I-F, scan reports are classified with moderate confidentiality and integrity and should be protected.
SPC-IS must provide the ISO or designated security representatives with all external IP addresses and Uniform Resource Locators (URLs) for all externally facing web applications.
Network and system administrators must provide sufficient access for the vulnerability scan engine to scan all system services. No devices connected to the network shall be specifically configured to block vulnerability scans from authorized scanning engines.
Scans must be performed within the system development life cycle (see SSDLC Standard: I-E) while in pre-deployment environments when deployed into the target implementation environment and periodically after that as specified below:
- Pre-deployment scans occur before the move of the system or web application to the target implementation environment:
- All systems must undergo an authenticated internal infrastructure scan, where technically feasible or required, before being deployed to the target implementation environment. Any infrastructure vulnerability discovered must be remediated or determined to be a false positive or insignificant risk by the Information Security Officer (ISO) or designated security representative before the system is deployed for the intended use.
- When source code is available, applications must undergo source code scanning before the updated code moves into the target implementation environment if the application code has changed.
- Scans must be authenticated when the application requires authentication before being deployed into the target implementation environment or into an environment that is externally accessible. When authentication is required to access the application, scans must be run with authenticated access at each access level (e.g., user, admin) supported by the application, except where limitations in the tool prevent authenticated scanning. Any web application vulnerability discovered must be remediated or determined to be a false positive or insignificant risk by the ISO or designated security representative before the system is placed into the target implementation environment.
- Any system or application deployed to its target implementation environment with un-remediated
vulnerabilities must have a formal remediation plan and the documented approval of
the executive responsible for risk management or their designee.
- Implementation scans occur the first time a system or web application is moved to its target implementation environment:
- Systems must be scanned immediately upon being placed into the target implementation environment with an authenticated internal infrastructure scan, where technically feasible or required. If the system is accessible from the Internet or an external network, it must be scanned with an external infrastructure scan.
- Web applications must be scanned within the first month of being placed into the target
implementation environment. If feasible, an authenticated in-depth web application
scan is required, but at minimum, a “lite” scan is needed. The application's sensitivity
and criticality must be considered when determining the schedule for the initial implementation
scan.
- Recurring Scans: After the initial scan in the target implementation environment, the frequency of scans is to be determined according to the system or application’s risk rating (see Table 2).
- When performing internal infrastructure scans on systems built using a shared image, such as workstations, scans may be run on a sampling of systems, but the sample set must vary from scan to scan.
- Production web applications must undergo recurring scans, at minimum recurring “lite” application scans.
- All vulnerabilities found during scans must be addressed per the remediation section
Determine Risk Rating and Frequency of Scans
The risk that vulnerabilities pose to systems and applications is based on the likelihood of a vulnerability being exploited and the impact of the information assets' confidentiality, integrity, or availability being compromised. The possibility of a vulnerability being exploited is increased in direct relation to the system’s or application’s accessibility from other systems.
The impact on information assets is based on their information classification (see Information Classification Standard: I-F). Suppose confidentiality, integrity, or availability is compromised. In that case, the impact (i.e., high, moderate, or low) must be considered, and the highest individual impact rating for confidentiality, integrity, or availability is utilized within the table below.
Table 2: RISK RATING |
|||
Impact (Confidentiality, Integrity, Availability) |
Exposure |
||
Systems with no network connectivity to production data
|
Systems with network connectivity to production data (not internet-facing) |
A system that is publicly available on the internet |
|
High |
Medium |
High |
High |
Medium |
Low |
Medium |
High |
Low |
Low |
Low |
Medium |
The minimum frequency of scans is dependent on the risk rating. Systems without a risk rating must be scanned as if they had a " High " risk rating until they are rated.
TABLE 3: FREQUENCY OF SCANS |
|
Risk Rating |
Frequency |
Infrastructure scans |
|
High |
Monthly |
Medium |
Quarterly |
Low |
Semi-annually |
Web Application Scans |
|
High |
Quarterly or after a significant change |
Medium |
Semi-annually |
Low |
Annually |
Remediation
Vulnerabilities discovered during scans must be remediated based on risk rating (see Table 2) and vulnerability severity identified by the scanning tool as per the table below.
TABLE 4: REMEDIATION TIMEFRAMES |
|||
Risk Rating (from Table 2) |
Vulnerability Severity |
||
Low or Below |
Above Low to Below High |
High or Above |
|
High |
At the discretion of the ISO/designated security representative |
Action Plan in 2 Weeks, Resolved in 6 Months |
Action Plan in 1 Week, Resolved in 1 Month |
Medium |
At the discretion of the ISO/designated security representative |
Action Plan in 3 Weeks, Resolved in 1 year |
Action Plan in 2 Weeks, Resolved in 6 Months |
Low |
At the discretion of the ISO/designated security representative |
At the discretion of the ISO/designated security representative |
Action Plan in 3 Weeks, Resolved one year |
The ISO or designated security representative may review vulnerabilities to adjust the severity rating. Testing must be done to verify that remediation has been completed.
Individuals managing vulnerability scans must notify the ISO or designated security representative within one business day of scan completion for new vulnerabilities and at least monthly for vulnerabilities not remediated on systems or applications running in production.
The ISOs or designated security representatives must notify management of vulnerabilities not addressed in the timeframes prescribed in this standard so that the appropriate party can accept the risk.
Compliance
This standard shall take effect upon publication. Compliance is expected with all enterprise policies and standards. Policies and standards may be amended at any time; compliance with amended policies and standards is expected.
If compliance with this standard is not feasible or technically possible, or if deviation from this standard is necessary to support a business function, Entities shall request an exception through the Chief Information Security Officer’s exception process.
Related Documents
1 TAC § 202.74 (a)(2)
Patch Management Standard: I-E(b)
An index of approved SPC-IS policies can be found on the SPC Policies website at http://www.southplainscollege.edu/human_resources/policy_procedure/?%20. The SPC Information Security Program and SPC Information Security User Guide are also available on the Information Technology Services Policies website.
Texas Security Controls Standards Catalog Control Group: CA-8, RA-5
NIST Function Groups: DE.AE-3, DE.CM-1, DE.CM-4, DE.CM-7