System and Information Integrity (SI)¶

Domain: System and Information Integrity (SI)
Requirements in this domain: 7
Assessment Objectives in this domain: 20

SI.L2-3.14.1¶

SI.L2-3.14.1[a]¶

Assessment Objective

the time within which to identify system flaws is specified.

Collection Approach: Document

Potential Evidence Examples

SSP or Patch Management Policy specifying the required timeframe for identifying system flaws (e.g., critical vulnerabilities identified within X days of scan/disclosure).

Assessment Guide – Further Discussion

Is the time frame (e.g., a set number of days) within which system flaw identification activities (e.g., vulnerability scans, configuration scans, manual review) must be performed defined and documented [a]?

SI.L2-3.14.1[b]¶

Assessment Objective

system flaws are identified within the specified time frame.

Collection Approach: Screen Share

Potential Evidence Examples

Vulnerability scan output (scanner console/report) and scan-schedule configuration showing flaws are actually identified within the specified timeframe.

Assessment Guide – Further Discussion

Are system flaws (e.g., vulnerabilities, misconfigurations) identified in accordance with the specified time frame [b]?

SI.L2-3.14.1[c]¶

Assessment Objective

the time within which to report system flaws is specified.

Collection Approach: Document

Potential Evidence Examples

SSP or Patch Management Policy specifying the required timeframe for reporting identified system flaws to responsible personnel.

SI.L2-3.14.1[d]¶

Assessment Objective

system flaws are reported within the specified time frame.

Collection Approach: Screen Share

Potential Evidence Examples

ITSM ticket/trouble-ticket records paired with scanner output showing identified flaws are reported to responsible personnel within the specified timeframe.

SI.L2-3.14.1[e]¶

Assessment Objective

the time within which to correct system flaws is specified.

Collection Approach: Document

Potential Evidence Examples

SSP or Patch Management Policy specifying the required timeframe for correcting (patching/remediating) identified system flaws, typically risk-tiered by severity.

Assessment Guide – Further Discussion

Is the time frame (e.g., a set number of days dependent on the assessed severity of a flaw) within which system flaws must be corrected defined and documented [e]?

SI.L2-3.14.1[f]¶

Assessment Objective

system flaws are corrected within the specified time frame.

Collection Approach: Screen Share

Potential Evidence Examples

Follow-up/rescan output from the vulnerability scanner showing flaws were corrected within the specified timeframe (e.g., a previously flagged vulnerability no longer appears, or a patch-deployment record with a closure date).

Assessment Guide – Further Discussion

Are system flaws (e.g., applied security patches, made configuration changes, or implemented workarounds or mitigations) corrected in accordance with the specified time frame [f]?

SI.L2-3.14.2¶

SI.L2-3.14.2[a]¶

Assessment Objective

designated locations for malicious code protection are identified.

Collection Approach: Document

Potential Evidence Examples

SSP or System Protection Policy identifying the designated locations (e.g., endpoints, email gateway, web proxy, file servers) where malicious code protection is deployed.

Assessment Guide – Further Discussion

Are system components (e.g., workstations, servers, email gateways, mobile devices) for which malicious code protection must be provided identified and documented [a]?

SI.L2-3.14.2[b]¶

Assessment Objective

protection from malicious code at designated locations is provided.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the anti-malware/endpoint-protection console showing protection is active and reporting-in at each designated location identified in [a].

SI.L2-3.14.3¶

SI.L2-3.14.3[a]¶

Assessment Objective

response actions to system security alerts and advisories are identified.

Collection Approach: Document

Potential Evidence Examples

SSP, Vulnerability Management Policy, or Incident Response Plan defining what response actions are taken upon receipt of a system security alert or advisory (e.g., US-CERT/CISA advisory, vendor security bulletin).

Assessment Guide – Further Discussion

• Are the responses to system security alerts and advisories identified in relation to the assessed severity of potential flaws (e.g., communicating with responsible personnel, initiating vulnerability scans, initiating system flaw remediation activities) [a]?
• Are system security alerts and advisories addressed (e.g., assessing potential severity or likelihood, communicating with responsible personnel, initiating vulnerability scans, initiating system flaw remediation activities) [a,c]?

SI.L2-3.14.3[b]¶

Assessment Objective

system security alerts and advisories are monitored.

Collection Approach: Artifact

Potential Evidence Examples

Evidence of active monitoring for security alerts/advisories — e.g., a threat-intelligence subscription, CISA/US-CERT mailing-list subscription confirmation, or vendor advisory email records.

SI.L2-3.14.3[c]¶

Assessment Objective

actions in response to system security alerts and advisories are taken.

Collection Approach: Artifact

Potential Evidence Examples

Sampled ITSM ticket, change record, or configuration update (e.g., firewall/IPS signature update) showing a specific action was taken in response to a received security alert or advisory.

Assessment Guide – Further Discussion

Are system security alerts and advisories addressed (e.g., assessing potential severity or likelihood, communicating with responsible personnel, initiating vulnerability scans, initiating system flaw remediation activities) [a,c]?

SI.L2-3.14.4¶

SI.L2-3.14.4[a]¶

Assessment Objective

malicious code protection mechanisms are updated when new releases are available.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the anti-malware management console showing signature/definition update status and history, confirming malicious-code protection mechanisms are updated automatically or promptly when new releases are available.

Assessment Guide – Further Discussion

Is there a defined frequency by which malicious code protection mechanisms must be updated (e.g., frequency of automatic updates or manual processes) [a]?

SI.L2-3.14.5¶

SI.L2-3.14.5[a]¶

Assessment Objective

the frequency for malicious code scans is defined.

Collection Approach: Document

Potential Evidence Examples

SSP or Vulnerability Management Policy defining the required frequency for malicious-code (anti-malware) scans.

SI.L2-3.14.5[b]¶

Assessment Objective

malicious code scans are performed with the defined frequency.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the anti-malware console's scan schedule and scan-history log showing scans run at least as often as the defined frequency across endpoints, servers, and file shares.

SI.L2-3.14.5[c]¶

Assessment Objective

real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the anti-malware/endpoint-protection real-time (on-access) scanning setting showing files are scanned automatically as they are downloaded, opened, or executed.

Assessment Guide – Further Discussion

Are files from media (e.g., USB drives, CD-ROM) included in the definition of external sources and are they being scanned [c]?

SI.L2-3.14.6¶

SI.L2-3.14.6[a]¶

Assessment Objective

the system is monitored to detect attacks and indicators of potential attacks.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the SIEM, IPS, or endpoint-protection dashboard showing the system is actively monitored for attack indicators, including recent alerts/detections.

Assessment Guide – Further Discussion

• Are details provided for the methodology of determining attacks and indicators of attack [a]?
• Are monitoring devices deployed within the information system to collect information that may indicate an attack [a]?

SI.L2-3.14.6[b]¶

Assessment Objective

inbound communications traffic is monitored to detect attacks and indicators of potential attacks.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the firewall/IPS/SIEM configuration and sample alerts specifically showing inbound traffic is monitored for attack indicators.

Assessment Guide – Further Discussion

Are communications traffic flows understood and is there a deployed capability to review that traffic [b,c]?

SI.L2-3.14.6[c]¶

Assessment Objective

outbound communications traffic is monitored to detect attacks and indicators of potential attacks.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the firewall/IPS/SIEM configuration and sample alerts specifically showing outbound traffic is monitored for attack indicators (e.g., potential data exfiltration or command-and-control activity).

Assessment Guide – Further Discussion

Are communications traffic flows understood and is there a deployed capability to review that traffic [b,c]?

SI.L2-3.14.7¶

SI.L2-3.14.7[a]¶

Assessment Objective

authorized use of the system is defined.

Collection Approach: Document

Potential Evidence Examples

Acceptable Use Policy or SSP defining what constitutes authorized use of the system (e.g., permitted applications, activities, and data handling).

Assessment Guide – Further Discussion

Is authorized use of systems defined (e.g., data types permitted for storage or processing, personnel authorized to access, times or days of permitted use, permitted software) [a]?

SI.L2-3.14.7[b]¶

Assessment Objective

unauthorized use of the system is identified.

Collection Approach: Artifact

Potential Evidence Examples

Screen share of SIEM/endpoint-protection alerts or reports showing a mechanism exists to identify unauthorized system use (e.g., an alert triggered by activity outside the defined authorized-use baseline).

Assessment Guide – Further Discussion

Is unauthorized use of systems defined (e.g., not authorized to use systems for bitcoin mining, not authorized for pornographic content, not authorized to access gambling games/content) [b]?