AC-4(28): Linear Filter Pipelines

AC-4(28) sits in the Access Control family but becomes operationally real when you move data between security domains (for example: classified vs. unclassified enclaves, regulated vs. non-regulated segments, production vs. development, or separate tenants with different authorization boundaries). The requirement is narrow and concrete: create a linear content filter pipeline for cross-domain transfers and ensure the pipeline is enforced by both discretionary and mandatory access controls. ¹

For a CCO or GRC lead, the fastest path to “done” is to treat AC-4(28) as an architecture and governance control with three deliverables: (1) a documented cross-domain data flow inventory, (2) a reference design showing a single enforced path with ordered filtering stages, and (3) recurring evidence that rules are enforced, tested, and controlled through change management. This page is written to help you operationalize the requirement quickly: what systems it applies to, what to build, what evidence to retain, and where audits typically stall.

Regulatory text

Requirement (excerpt): “When transferring information between different security domains, implement a linear content filter pipeline that is enforced with discretionary and mandatory access controls.” ¹

Operator meaning: if any workflow moves information from Domain A to Domain B, you need:

1. A linear pipeline: a single ordered sequence of filter stages (Filter 1 → Filter 2 → Filter 3 …) that content must traverse.
2. Content filtering: each stage evaluates content and can allow, transform, quarantine, redact, or block based on policy.
3. Enforcement with DAC and MAC: access decisions must include both discretionary rules (ownership/role-based permissions) and mandatory rules (label-based or policy-based constraints that users can’t override). ¹

Plain-English interpretation

AC-4(28) is a “no bypass” rule for cross-domain transfers. If you allow data to cross from one security domain to another, the transfer path cannot be a patchwork of optional scanners, ad hoc scripts, or alternative routes that some teams can use to avoid inspection. You define one sanctioned pipeline and you force all transfers through it. Then you prove, with logs and configuration, that the pipeline enforces policy using both DAC (who is allowed to request or approve transfer) and MAC (what data classifications/labels are allowed to move, regardless of who asks). ¹

What “linear” means in an audit

Assessors typically interpret “linear” as:

• A deterministic order of filter steps (e.g., validate request → check labels → malware scan → DLP/content rules → sanitize/transform → release).
• No parallel alternate path that can reach the destination without passing through the same controls.
• A control plane that prevents exception handling from becoming a bypass.

Who it applies to

Entity types (typical):

• Federal information systems and programs adopting NIST SP 800-53 Rev. 5 controls.
• Contractors handling federal data where NIST SP 800-53 controls are contractually required or inherited through an authorization boundary. ¹

Operational contexts where AC-4(28) becomes relevant:

• Cross-domain solutions (CDS), data diodes, guard systems, or any “gateway” pattern between enclaves.
• Segmented networks where domains have different authorization boundaries (e.g., mission network to corporate network).
• Multi-tenant environments with strong separation requirements.
• Any environment where data labels/classifications or policy tags must constrain movement.

Quick scoping test (use this): If you can answer “yes” to both questions, scope AC-4(28) in:

1. Do we move files, messages, records, or API payloads between two environments with different security policies?
2. Can a user, service, admin, or third party trigger that movement?

What you actually need to do (step-by-step)

Step 1: Identify and classify “security domains”

• Define the domains in plain operational terms: enclaves, tenants, segments, environments, or authorization boundaries.
• For each domain, document the policy basis: what makes it different (data types, classification labels, compliance boundary, trust level). Artifact: “Security Domain Register” with owners, purpose, and allowed inbound/outbound transfer types.

Step 2: Inventory every cross-domain transfer path

Build a transfer inventory that includes:

• Source domain, destination domain
• Transfer mechanism (file transfer, message bus, API gateway, ETL job, admin copy, backup restore, ticket attachment, collaboration tool)
• Initiator (human, service account, scheduled job, third party integration)
• Data types and sensitivity Artifact: “Cross-Domain Data Flow Map” with a unique ID for each path.

Practical note: audits often fail here because teams document the “official” gateway but forget engineer-driven paths (admin jump boxes, direct database reads, shared object storage, or break-glass accounts).

Step 3: Design a single linear filter pipeline per transfer class

For each transfer class (file, message, API payload), define the ordered stages. A workable starting sequence:

1. Request and identity gate (DAC): authenticate initiator; require authorization to request transfer.
2. Policy/label gate (MAC): evaluate mandatory rules (labels/tags/classification; allowed directionality).
3. Content inspection stage(s): malware scanning; file type validation; decompression controls.
4. Content policy stage(s): DLP patterns; secret detection; structured validation; schema checks.
5. Sanitization/transformation stage: strip active content; convert formats; redact fields.
6. Release/quarantine decision: allow to destination, block, or hold for review with documented approval.

Artifact: “Linear Filter Pipeline Design” diagram plus written control logic.

Step 4: Implement technical enforcement to prevent bypass

You need enforcement that makes “the pipeline” the only path:

• Network controls: routing, firewall rules, proxy enforcement, segmentation.
• Application controls: API gateway policies, service mesh policies, broker ACLs.
• Storage controls: prevent cross-domain shared storage unless it is fronted by the pipeline.
• Admin controls: restrict direct copy tools; constrain privileged pathways; monitor break-glass use.

Artifact: configuration snapshots and a narrative showing how alternate routes are blocked.

Step 5: Implement DAC and MAC explicitly, not implicitly

Audits stall when teams claim “we have RBAC” but cannot show MAC enforcement.

• DAC evidence: permissions for who can request, approve, or administer transfers; role definitions; access reviews tied to the pipeline.
• MAC evidence: a mandatory policy model (labels/tags/classification) and enforcement point(s) that deny transfers even if the user is privileged.

Artifact: access control policy + policy engine rules + screenshots/exports of enforcement configuration.

Step 6: Add monitoring, logging, and repeatable testing

Minimum operational checks:

• Log every transfer attempt, decision, filter stage result, and final disposition.
• Alert on bypass indicators: direct connections between domains, denied attempts spikes, disabled filters, policy changes, and quarantines.
• Test: attempt known-bad transfers (malware-like test file, forbidden label combination, disallowed file type) and retain results.

Artifact: test plan, test results, log samples, and alert rules.

Step 7: Operational governance (change control + exceptions)

Treat pipeline rules like security policy:

• Changes require review/approval, tracked in tickets, with risk acceptance where needed.
• Exceptions cannot be “temporary forever.” Set an expiration and compensating controls.
• Third parties: if a third party integration moves data cross-domain, contractually require it to use the sanctioned path and provide logs.

Artifact: change records, exception register, and third party integration requirements.

Required evidence and artifacts to retain (assessor-ready)

Use this checklist to stay audit-ready:

• Security Domain Register (owners, boundaries, rationale)
• Cross-Domain Data Flow Map (all pathways)
• Linear Filter Pipeline Design (diagram + stage descriptions)
• DAC configuration exports (roles, groups, approvals, access review outputs)
• MAC policy documentation and enforcement rules (labels/tags and deny rules)
• Network/application enforcement configs proving “no bypass”
• Logging and monitoring evidence (sample logs, alert rules, SIEM queries)
• Test plan and results for allow/deny cases
• Change control history for pipeline rules
• Exception register with approvals and expirations

If you need a clean way to keep this packaged by control and system boundary, Daydream is typically used to map AC-4(28) to an owner, an implementation procedure, and recurring evidence artifacts so audits don’t devolve into one-off evidence hunts. ¹

Common exam/audit questions and hangups

Expect these questions and prep answers with artifacts:

• “Show me all cross-domain transfer mechanisms. How do you know this list is complete?”
• “Where is the enforcement point that prevents a user or admin from bypassing filtering?”
• “Walk me through the exact filter order. What happens if one stage fails?”
• “Where do DAC and MAC decisions occur, and how are they logged?”
• “How do you control changes to filter rules and label policies?”
• “How do third party integrations transfer data across domains, and what prevents direct access?”

Frequent implementation mistakes (and how to avoid them)

1. Documenting a pipeline but allowing alternate paths

• Fix: implement explicit network/app controls that block direct routes; verify with a connectivity test from source to destination that fails unless through the gateway.

2. Treating malware scanning as the whole pipeline

• Fix: add DLP/content policy checks and mandatory label policy enforcement. AC-4(28) calls out content filtering plus DAC/MAC enforcement. ¹

3. No proof of MAC

• Fix: define labels/tags and a mandatory policy engine; show deny rules that apply even to powerful roles.

4. Exceptions handled in email or chat

• Fix: create an exception register with approvals, scope, compensating controls, and expiry.

5. Logs exist but can’t reconstruct decisions

• Fix: log per-stage outcomes and final disposition with a correlation ID. Store logs in a tamper-resistant system aligned to your broader logging controls.

Enforcement context and risk implications

No public enforcement case sources were provided for AC-4(28) in the supplied catalog, so you should frame risk in operational terms rather than case law. The practical risk is straightforward: cross-domain transfer is a common path for data leakage, policy violations, and introduction of malicious content. If you cannot prove a single enforced pipeline with DAC/MAC, assessors tend to treat the exposure as systemic because it undermines boundary protections and makes incident scoping difficult. ¹

Practical execution plan (30/60/90-day)

Use this as an execution structure. Adjust sequencing to match engineering constraints.

First 30 days: Scope and design freeze

• Appoint a control owner and technical owners for each domain boundary.
• Build the Security Domain Register and Cross-Domain Data Flow Map.
• Select the reference pipeline pattern(s) per transfer type.
• Identify current bypass paths and document a remediation backlog.
• Define DAC roles (requester/approver/operator) and MAC labeling approach.

By 60 days: Implement enforcement and logging

• Implement the linear pipeline for highest-risk transfer paths first.
• Enforce “no bypass” with network/app policy; verify with negative tests.
• Turn on per-stage logging and centralize it (SIEM or equivalent).
• Stand up change control workflow for rules and label policy.

By 90 days: Prove operation and harden governance

• Execute a repeatable test plan and retain results.
• Run an access review for DAC roles tied to transfer requests and administration.
• Review exceptions, expire any that are no longer needed, and add compensating controls where required.
• Package evidence by system boundary so an assessor can trace: flow → pipeline → enforcement → logs → tests.

Frequently Asked Questions

Does AC-4(28) require a specific cross-domain solution product?

No product is named in the requirement. You must implement a linear filter pipeline and enforce it with DAC and MAC in whatever architecture you run. ¹

What counts as a “security domain” for scoping?

Treat a security domain as any environment with a distinct security policy or authorization boundary. If data movement between two environments changes what controls apply, you should assume AC-4(28) is in scope. ¹

We already have RBAC approvals for transfers. Is that enough?

RBAC maps to discretionary controls, but AC-4(28) also requires mandatory access controls. You need a mandatory policy layer (for example, label-based restrictions) that can deny transfers regardless of requester permissions. ¹

Can the pipeline have multiple scanners in parallel for performance?

“Linear” is easiest to defend when the decision path is ordered and cannot be bypassed. If you run parallel processing internally, keep a single enforced ingress/egress path and a deterministic decision sequence with unified logging.

How do we handle emergency transfers without violating “no bypass”?

Create a break-glass process that still routes through the pipeline but changes who can approve or what review is required. If you must allow an exception, record it in an exception register with an expiration and compensating monitoring.

What evidence do assessors usually ask for first?

They usually start with a cross-domain flow inventory and an architecture diagram, then ask you to prove enforcement with configs and logs. Have the flow map, pipeline design, and sample logs ready before the assessment starts.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON