Only allow incoming communications from [organization-defined] to be routed to [organization-defined].
Scanned 9/3/2026
Install to Claude Code
npx -y skills add CyberStrikeus/CyberStrike --skill sc-7-11-restrict-incoming --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Sc 7 11 Restrict Incoming?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/cyberstrikeus-sc-7-11-restrict-incoming)More formats (shields.io, HTML) on the badges page.
---
name: "SC-7(11)_restrict-incoming-communications-traffic"
description: "Only allow incoming communications from [organization-defined] to be routed to [organization-defined]."
category: "configuration"
version: "5.2.0"
author: "cyberstrike-official"
tags:
- nist
- sp800-53
- rev5
- sc-7-11
- sc
- enhancement
tech_stack:
- aws
- azure
- gcp
- linux
- windows
- network
cwe_ids:
- CWE-311
chains_with:
- AC-3
prerequisites:
- SC-7
severity_boost:
AC-3: "Chain with AC-3 for comprehensive security coverage"
---
# SC-7(11) Restrict Incoming Communications Traffic
> **Enhancement of:** SC-7
## High-Level Description
**Family:** System and Communications Protection (SC)
**Framework:** NIST SP 800-53 Rev 5
General source address validation techniques are applied to restrict the use of illegal and unallocated source addresses as well as source addresses that should only be used within the system. The restriction of incoming communications traffic provides determinations that source and destination address pairs represent authorized or allowed communications. Determinations can be based on several factors, including the presence of such address pairs in the lists of authorized or allowed communications, the absence of such address pairs in lists of unauthorized or disallowed pairs, or meeting more general rules for authorized or allowed source and destination pairs. Strong authentication of network addresses is not possible without the use of explicit security protocols, and thus, addresses can often be spoofed. Further, identity-based incoming traffic restriction methods can be employed, including router access control lists and firewall rules.
## What to Check
- [ ] Verify SC-7(11) Restrict Incoming Communications Traffic is documented in SSP
- [ ] Confirm control is operating effectively
- [ ] Review evidence of continuous monitoring for SC-7(11)
- [ ] Verify enhancement builds upon base control SC-7
## How to Test
### Step 1: Review Documentation
Examine the System Security Plan (SSP) and related artifacts for SC-7(11) 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 encryption and network controls | `cloud_audit_encryption` |
| nmap | Network scanning | `nmap -sV --script ssl-enum-ciphers` |
## Remediation Guide
### Control Statement
Only allow incoming communications from [organization-defined] to be routed to [organization-defined].
### Implementation Guidance
General source address validation techniques are applied to restrict the use of illegal and unallocated source addresses as well as source addresses that should only be used within the system. The restriction of incoming communications traffic provides determinations that source and destination address pairs represent authorized or allowed communications. Determinations can be based on several factors, including the presence of such address pairs in the lists of authorized or allowed communications, the absence of such address pairs in lists of unauthorized or disallowed pairs, or meeting more general rules for authorized or allowed source and destination pairs. Strong authentication of network addresses is not possible without the use of explicit security protocols, and thus, addresses can often be spoofed. Further, identity-based incoming traffic restriction methods can be employed, including router access control lists and firewall rules.
## Risk Assessment
| Finding | Severity | Impact |
| ----------------------------------------------------------------- | -------- | ----------------------------------------------- |
| SC-7(11) Restrict Incoming Communications Traffic not implemented | High | System and Communications Protection |
| SC-7(11) partially implemented | Medium | Incomplete System and Communications Protection |
## CWE Categories
| CWE ID | Title |
| ------- | ------------------------------------ |
| CWE-311 | Missing Encryption of Sensitive Data |
## References
- [NIST SP 800-53 Rev 5 - SC-7(11)](https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home?element=sc-7.11)
- [NIST SP 800-53A Rev 5 (Assessment Procedures)](https://csrc.nist.gov/pubs/sp/800/53/a/r5/final)
- [NIST SP 800-53 Rev 5 Full Catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)
## Checklist
- [ ] Control documented in SSP
- [ ] Implementation evidence collected
- [ ] Operating effectiveness validated
- [ ] Continuous monitoring in place
- [ ] Related controls (AC-3) reviewed
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!