This post gives a practical, implementation-focused walkthrough for enforcing FAR 52.204-21 and CMMC 2.0 Level 1 control AC.L1-B.1.IV—limiting access to authorized users, processes, and devices—using three complementary technical controls: Web Application Firewalls (WAFs), Role-Based Access Control (RBAC), and filtering (network, DNS, and application-level). It is geared toward small businesses operating under a "Compliance Framework" requirement set and provides concrete steps, real-world examples, and evidence items you can collect to demonstrate compliance.
What AC.L1-B.1.IV Requires (Compliance Framework context)
At Level 1 the control intent is straightforward: ensure that only authorized users, devices, and processes can access covered contractor information and systems. For a Compliance Framework implementation this means documented policies + technical enforcement. Your practical deliverables will include access control configurations, WAF rule sets, firewall/filtering rules, logs showing enforcement, and periodic access reviews. Treat technical controls as evidence-producing mechanisms: configuration snapshots, rule change history, and logs are the artifacts auditors will want to see.
Deploying a Web Application Firewall (WAF)
WAFs protect web-facing applications by filtering malicious HTTP(S) traffic and enforcing application-layer policies—useful for protecting CUI that might be hosted via web portals or APIs. Implementation steps: 1) Inventory web apps and endpoints; 2) Place WAF in front of each app (cloud WAF in front of ALB/API Gateway or reverse-proxy like Cloudflare/Azure Front Door); 3) Apply managed rule groups (OWASP CRS, vendor-managed rules) then add custom rules for your app; 4) Start in detection/log-only mode for 1–2 weeks, tune false positives, then switch to block. Technical specifics: with AWS WAF create a WebACL, attach to Application Load Balancer or API Gateway, enable managed rule groups (AWSManagedRulesCommonRuleSet), add rate-based rules (e.g., RateLimit 2000/5m for suspicious endpoints), and use IPSet to block or allow management IP ranges. Ensure WAF logs stream to S3/CloudWatch for retention and to support audit requests.
Practical WAF examples for a small business
Example 1: A small subcontractor hosts a React SPA and backend API on AWS. Deploy AWS WAF on the ALB: enable OWASP rules, add a SQL injection/XSS rule group, create a rate-based rule for /api/login, and use an IPSet to restrict the admin portal to the company office IPs. Evidence: WebACL JSON, AWS WAF logs showing blocked SQLi attempts, change history in AWS CloudTrail. Example 2: A company running WordPress on a VM can use Cloudflare WAF with the WordPress rule set, add custom rules to block common plugin exploit patterns, and enable Bot Management to reduce credential stuffing—collect Cloudflare firewall events and configuration exports as evidence.
Implementing Role-Based Access Control (RBAC)
RBAC enforces who can do what. Start by defining roles that map to job functions (e.g., Admin, Developer, Operator, Helpdesk). Implement least privilege: only grant the minimum permissions needed. For cloud environments use Azure RBAC or AWS IAM: create groups, assign managed policies that are as granular as possible, and favor role assumption over permanent credentials. For on-prem and endpoint systems, use Active Directory groups to control local admin membership and use Group Policy to restrict who can log on to servers. For Linux systems, manage sudoers through configuration management tooling (e.g., Ansible) and avoid giving blanket sudo ALL privileges. Always require MFA for privileged roles and record role membership changes in a ticketing system.
RBAC example scenarios and technical notes
Example: In Azure, create custom roles scoped to a resource group that only allow read and deploy actions for CI/CD service accounts. Use Azure AD Conditional Access to require MFA for all role assignments. Example: A small team using GitHub Actions should create a short-lived service principal with scoped permissions and rotate keys via automation—don’t use shared accounts. Technical artifacts for audit: group membership lists, role definitions (JSON), recent access reviews, MFA enforcement logs, and IAM policy change history from AWS CloudTrail or Azure AD audit logs.
Filtering: Network, DNS, and Application-level
Filtering complements WAF and RBAC by blocking unauthorized network paths and reducing the attack surface. Implement network-level filtering with security groups (allow only required ports, e.g., 443 and 22 only from office IP ranges), network ACLs, and host-based firewalls (iptables, Windows Firewall). Enforce egress filtering to prevent data exfiltration—allow outbound traffic only to required destinations. DNS filtering (Cloudflare Gateway, Cisco Umbrella, or even Pi-hole for tiny shops) blocks phishing/malicious domains and prevents compromised endpoints from contacting C2 servers. Application-level filtering includes email attachment rules (block executable attachments), content inspection for large uploads, and URL allowlists for management interfaces. Log all filtering decisions to a central location for correlation.
Operational controls, evidence collection, and best practices
Operationalize controls: run periodic access reviews (quarterly), keep a change control log for WAF and ACL changes, and schedule WAF rule tuning after major releases. Best practices: test WAF rules in monitor mode first, use automation (IaC) to manage RBAC and firewall rules so configurations are reproducible, and store snapshots of configurations as evidence. Evidence package items for Compliance Framework audits: screenshots or exported JSON of WAF WebACLs, IAM/AD role definitions and group membership exports, firewall rule lists, recent logs showing denied access attempts, access review minutes, and change tickets showing who approved rule changes. Retain logs for the retention period required by contract (if unspecified, keep at least 90 days for initial programs and longer as required).
Risk of not implementing AC.L1-B.1.IV technical controls
Without proper WAF, RBAC, and filtering you leave CUI exposed to automated attacks (SQLi, XSS), credential stuffing, unauthorized privilege escalation, and lateral movement. Practical consequences include data breaches, contract termination, loss of future procurement opportunities, and regulatory penalties. For a small business a single exploited web app or misconfigured role can result in losing DoD contracts—so the risk is both technical and commercial. Additionally, lack of logs or documented controls will make it difficult to demonstrate compliance during an audit, even if no breach occurred.
Summary: To meet FAR 52.204-21 and CMMC 2.0 Level 1 AC.L1-B.1.IV in a practical, auditable way, combine a tuned WAF (cloud or edge) to protect HTTP/S surfaces, implement RBAC with least privilege and MFA across cloud and on-prem systems, and apply layered filtering for network, DNS, and application flows. Automate configurations where possible, collect configuration snapshots and logs as evidence, run regular access reviews, and document changes. These actions not only satisfy compliance requirements in the Compliance Framework context but materially reduce your risk exposure—critical for maintaining DoD-related contracts as a small business.
