| name | SI-20_tainting |
| description | Embed data or capabilities in the following systems or system components to determine if organizational data has been exfiltrated or improperly remove |
| category | input-validation |
| version | 5.2.0 |
| author | cyberstrike-official |
| tags | ["nist","sp800-53","rev5","si-20","si"] |
| tech_stack | ["aws","azure","gcp","linux","windows"] |
| cwe_ids | ["CWE-20"] |
| chains_with | ["AU-13"] |
| prerequisites | [] |
| severity_boost | {"AU-13":"Chain with AU-13 for comprehensive security coverage"} |
SI-20 Tainting
High-Level Description
Family: System and Information Integrity (SI)
Framework: NIST SP 800-53 Rev 5
Many cyber-attacks target organizational information, or information that the organization holds on behalf of other entities (e.g., personally identifiable information), and exfiltrate that data. In addition, insider attacks and erroneous user procedures can remove information from the system that is in violation of the organizational policies. Tainting approaches can range from passive to active. A passive tainting approach can be as simple as adding false email names and addresses to an internal database. If the organization receives email at one of the false email addresses, it knows that the database has been compromised. Moreover, the organization knows that the email was sent by an unauthorized entity, so any packets it includes potentially contain malicious code, and that the unauthorized entity may have potentially obtained a copy of the database. Another tainting approach can include embedding false data or steganographic data in files to enable the data to be found via open-source analysis. Finally, an active tainting approach can include embedding software in the data that is able to "call home," thereby alerting the organization to its "capture," and possibly its location, and the path by which it was exfiltrated or removed.
What to Check
How to Test
Step 1: Review Documentation
Examine the System Security Plan (SSP) and related artifacts for SI-20 implementation details. Verify the organization has documented how this control is satisfied.
Step 2: Validate Implementation
# For cloud environments, use cloud-audit-mcp tools
# For on-premises, review system configurations directly
# Example: Check if account management policies exist
grep -r "account.management\|access.control" /etc/security/ 2>/dev/null
Step 3: Test Operating Effectiveness
Verify the control is actively functioning, not just documented. Check logs, configurations, and operational evidence.
Tools
| Tool | Purpose | Usage |
|---|
| cloud-audit-mcp | Check integrity monitoring | cloud_audit_monitoring |
| AWS CLI |
