The "deny all, permit by exception" requirement in NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 (Control SC.L2-3.13.6) mandates that network traffic be blocked by default and only allowed when explicitly required — in AWS this is implemented primarily through carefully-designed VPCs, security groups, subnet controls, and monitoring automation.
Why this control matters for Compliance Framework
This control enforces a least-privilege network posture for Controlled Unclassified Information (CUI) and related systems. For small businesses handling government contracts, failing to enforce deny-by-exception increases risk of data exposure, lateral movement after compromise, and non-compliance that can lead to contract loss or corrective action. Practically, it requires that your AWS environment be architected so that only required ports, protocols, and source/destination pairs are allowed, and all other traffic is implicitly or explicitly denied and logged.
Practical AWS implementation overview
In AWS the canonical building blocks are: Security Groups (SGs) as resource-level, stateful, allow-only firewalls; Network ACLs (NACLs) as optional subnet-level, stateless controls that can include denies; VPC segmentation (public, private, management subnets); VPC Endpoints for private service access; and monitoring (VPC Flow Logs, AWS Config, Security Hub). For compliance, treat security groups as your primary "deny all, permit by exception" mechanism because they default to deny for inbound traffic and are simple to audit and manage.
Security group baseline patterns (actionable rules)
Use a small set of curated SG templates and apply them by role. Example small-business templates: - ALB (internet-facing): Inbound TCP 443 from 0.0.0.0/0 (if public web) and TCP 80 only if you need HTTP; outbound only to the application SG. - App servers: Inbound TCP 443 (or app port) only from ALB security group (referenced by SG id), outbound only to the DB SG and required update domains. No SSH/RDP from internet. - Database: Inbound DB port (e.g., 5432 or 3306) only from application SG; no outbound except to backup endpoints or logging. - Management: SSH/RDP allowed only from a fixed corporate IP or via an SSM-managed bastion; prefer AWS Systems Manager Session Manager to eliminate SSH ports entirely. Implement these with named tags (e.g., Name=sg-app-tier) and version them in IaC (Terraform/CloudFormation). Example AWS CLI snippet to create a simple SG and allow only HTTPS inbound (replace VPC and SG ids accordingly): aws ec2 create-security-group --group-name sg-app --description "app tier" --vpc-id vpc-xxxx; aws ec2 authorize-security-group-ingress --group-id sg-xxxx --protocol tcp --port 443 --source-group sg-alb
Network ACL, subnets, and VPC design
Use private subnets for all workloads that store/process CUI—no direct internet access. Place NAT Gateways in a small number of public subnets for outbound patching/updates, or design a central egress proxy so you can restrict outbound destinations. Apply NACLs sparingly as a second layer to block known bad IP ranges or to implement subnet-level explicit denies for specific protocols; remember NACLs are stateless so you must configure both inbound and outbound rules. For high assurance, create a management subnet where only jump hosts or SSM endpoints are reachable from your management IPs.
Automation, auditing, and evidence collection
To meet Compliance Framework audit expectations: codify security-group rules in IaC, enforce rule templates with guardrails, and log everything. Enable VPC Flow Logs (send to CloudWatch Logs or S3) and retain logs per your policy. Use AWS Config managed rules (or custom rules) that detect public access to sensitive ports and SNS/S3 notifications to trigger tickets. Example automated checks: flag any SG with 0.0.0.0/0 on ports 22, 3389, 1433, 3306, 5432 or any SG that allows ingress from 0.0.0.0/0 to non-ALB ports. Implement Lambda auto-remediation (or Systems Manager Automation) to remove offending rules and create an evidence record for auditors.
Real-world small business scenario
Example: A 20-person subcontractor hosts an internal web app and RDS for CUI. They deploy: VPC with two public subnets (ALB and NATs) and two private subnets (app and db). The ALB SG allows 443 from the internet; app SG allows 443 only from ALB SG; db SG allows 5432 only from app SG; management access uses SSM Session Manager (no inbound 22/3389). S3 access for backups uses a VPC Gateway Endpoint and an endpoint policy limiting specific buckets. AWS Config, VPC Flow Logs, and CloudTrail are enabled; Terraform stores SG templates and any change to SGs triggers a CI pipeline that runs static checks and requires approval. This posture satisfies "deny all, permit by exception" because everything is blocked by default and only required paths are opened by explicit SG rules.
Compliance tips, best practices, and common pitfalls
Best practices: centralize rule templates, minimize the number of SGs and ports, use security group references (not IP ranges) where possible, tag and document the business justification for each rule, and require change approvals. Pitfalls to avoid: allowing SSH/RDP from the internet, using overly-broad outbound rules (e.g., 0.0.0.0/0 on all ports), and relying solely on NACLs without enforcing SG controls. For evidence, export SG inventories and change history (CloudTrail) and retain Flow Logs for the assessment window required by your contract.
Risks of not implementing deny-all permit-by-exception
If you do not implement this control correctly, you raise the likelihood of unauthorized access to CUI, increased blast radius from a compromised instance, easier lateral movement, undetected exfiltration, and ultimately failure of NIST/CMMC assessments. Non-compliance can lead to corrective action plans, suspension from contracting opportunities, and reputational damage — costs that far exceed the engineering effort required to harden networking controls.
In summary, implementing "deny all, permit by exception" in AWS for NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 is achievable with disciplined VPC architecture, restrictive security groups as the primary enforcement mechanism, selective use of NACLs, VPC endpoints for private service access, and automation for detection and remediation. Use IaC, logging, and change control to produce the evidence auditors want, and adopt SSM and endpoint policies to eliminate risky direct-internet management paths — small businesses can meet this control with a compact, repeatable pattern that scales as they grow.
