Forward Deployed Engineer 101: Security Review and ATO (Authority to Operate) Process

Security Review and ATO (Authority to Operate) Process

Security Review & ATO (Authority to Operate) Process – Field-Ready Study Guide

What This Is

The ATO (Authority to Operate) is the formal approval that your software meets security and compliance requirements to run in a customer’s environment—especially critical in defense, intelligence, and regulated industries. As an FDE, you’ll spend 30-50% of your time navigating security reviews, not just writing code. Example: You’re deploying a real-time satellite imagery analysis tool on a classified DoD network. The ATO process isn’t just paperwork—it’s a gatekeeper that can delay (or kill) your project if you don’t plan for it. Miss a single STIG (Security Technical Implementation Guide) requirement, and your model won’t deploy for months. Your job is to anticipate security needs early, work with ISSOs (Information System Security Officers), and build systems that pass review on the first try.

Key Terms & Concepts

• ATO (Authority to Operate): Formal approval from a Designated Approving Authority (DAA) that your system meets security requirements. Without it, your software cannot run in production.
• RMF (Risk Management Framework): NIST’s 6-step process (Categorize → Select → Implement → Assess → Authorize → Monitor) that structures security compliance. Most DoD/IC customers use RMF.
• STIG (Security Technical Implementation Guide): DISA’s checklist of security controls for OS, apps, and networks. Example: A STIG might require disabling SSH password authentication (use keys only).
• eMASS (Enterprise Mission Assurance Support Service): DoD’s web-based tool for tracking RMF compliance. You’ll upload artifacts (scan reports, POA&Ms) here.
• POA&M (Plan of Action & Milestones): A living document listing security vulnerabilities and remediation timelines. Your ATO is conditional until POA&Ms are closed.
• SCAP (Security Content Automation Protocol): Automated scanning tools (e.g., OpenSCAP, Nessus) that check STIG compliance. Run these before the customer does.
• FIPS 140-2/3: U.S. government standard for cryptographic modules. If your app uses encryption (e.g., TLS, disk encryption), it must use FIPS-validated libraries (e.g., OpenSSL FIPS, BoringSSL).
• Air-Gapped Deployment: No internet access. You’ll need offline dependency mirrors (e.g., apt-offline, pip download), physical media (USB drives), and manual patching.
• Zero Trust: Security model assuming no implicit trust. Even inside a network, every request must authenticate (e.g., mutual TLS, SPIFFE/SPIRE).
• ACO (Approved Configuration Owner): The customer’s team responsible for maintaining the system post-deployment. They own the ATO, not you.
• SOC (Security Operations Center): The team monitoring for threats. If your app triggers alerts (e.g., unusual port scans), they’ll shut it down without warning.
• IATO (Interim ATO): Temporary approval (30-180 days) to operate while POA&Ms are resolved. Never assume you’ll get one—plan for full ATO.

Step-by-Step / Field Process

1. Pre-Deployment: Align with Security Early

• Action: Before writing code, get the customer’s security team in the room (ISSO, ACO, SOC). Ask:
• What’s the RMF step they’re in? (If they’re in "Assess," you’re too late to influence controls.)
• What STIGs apply? (e.g., RHEL 8 STIG, Kubernetes STIG)
• What’s their eMASS workflow? (How do they track POA&Ms?)
• Field Move: Request their System Security Plan (SSP)—this is the bible for their security requirements. If they don’t have one, you’re building blind.
• Tool Example: Use oscap to scan a baseline system: bash oscap xccdf eval --profile stig-rhel8-disa --results /tmp/scan-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

2. Build for Compliance from Day 1

• Action: Design your system to fail fast in security reviews. Key moves:
• Containerization: Use distroless or UBI (Red Hat Universal Base Image) containers to minimize attack surface.
• FIPS Mode: Enable FIPS in your OS and apps (e.g., update-crypto-policies --set FIPS on RHEL).
• Logging: Ship logs to the customer’s SIEM (e.g., Splunk, Elastic) in their required format (CEF, JSON).
• Hardening: Apply STIGs before deployment. Example for Kubernetes:
  bash
kubectl apply -f https://raw.githubusercontent.com/ComplianceAsCode/kubernetes/master/dist/content/kubernetes-stig.yaml
• Field Trap: If you wait until the end to harden, you’ll rewrite 30% of your code.

3. Pre-Scan and Fix Before the Customer Does

• Action: Run SCAP scans and static analysis (e.g., SonarQube, Checkov) before submitting for review. Example: ```bash # Run OpenSCAP scan oscap xccdf eval --results /tmp/scan-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

# Generate a POA&M from results oscap xccdf generate fix --template urn:xccdf:fix:script:sh /tmp/scan-results.xml > /tmp/fixes.sh ``` - Field Move: Automate scans in CI/CD (e.g., GitLab CI, GitHub Actions) so you catch issues early.

4. Submit Artifacts and Navigate the Review

• Action: The customer’s ISSO will request:
• Scan reports (SCAP, Nessus, Twistlock)
• SSP updates (how your system meets controls)
• POA&Ms (your plan to fix gaps)
• Diagrams (network, data flow, trust boundaries)
• Field Move: Pre-write POA&Ms for common issues (e.g., "Disable SSH password auth" → "Will implement key-based auth by [date]"). This shows you’re proactive.
• Tool Example: Use eMASS API to upload artifacts programmatically: python import requests emass_api = "https://emass.customer.mil/api" headers = {"Authorization": "Bearer YOUR_TOKEN"} files = {"file": open("scan-results.xml", "rb")} requests.post(f"{emass_api}/artifacts", headers=headers, files=files)

5. Deploy and Monitor for Drift

• Action: After ATO approval:
• Deploy in phases (e.g., staging → pre-prod → prod) to catch issues early.
• Monitor for compliance drift (e.g., new STIGs, config changes). Example:
  bash
# Check for unauthorized changes to /etc/ssh/sshd_config
sudo rpm -V openssh-server
• Set up alerts for security events (e.g., failed logins, port scans).
• Field Trap: If you don’t monitor, the SOC will revoke your ATO for "non-compliance."

Common Mistakes

FDE Interview / War Story Insights

1. "You’re on site and the customer demands a feature that violates the original scope (e.g., real-time data sharing with an unapproved third party). How do you respond?"

• Answer: Say: "I understand the urgency, but this change would require a new security review and could delay our ATO. Let’s document the request, assess the risk, and escalate to the ISSO and ACO for approval."
• Why: Never bypass security for "just this once." The ISSO will find out, and your ATO is at risk.

2. "The customer’s ISSO says your app fails a STIG check, but you disagree. How do you handle it?"

• Answer: Ask for the exact STIG rule ID (e.g., "RHEL-08-010020") and the scan output. Reproduce the issue in your test environment, then:
• If it’s a false positive, provide evidence (e.g., config files, logs).
• If it’s a real issue, submit a POA&M with a fix timeline.
• Why: ISSOs don’t negotiate—they follow the STIG. Your job is to prove compliance or fix it.

3. "You’re deploying to an air-gapped environment, and the customer’s security team won’t let you bring in a USB drive. How do you get your software in?"

• Answer: Use approved transfer methods (e.g., hardened DVDs, secure file transfer appliances like DISA’s DoD SAFE). If those aren’t available:
• Pre-load dependencies on a customer-provided system (e.g., yum --downloadonly).
• Use a "sneakernet" process (e.g., burn to DVD, hand-carry with an escort).
• Why: Air-gapped environments ban USBs due to malware risks. Always ask: "What’s your approved transfer process?"

Quick Check Questions

1. You’re deploying to an environment where you can’t run standard Docker images due to security restrictions. What’s your first step?

• Answer: Ask the ISSO for their approved base images (e.g., UBI, distroless) and container hardening guidelines (e.g., no root, read-only filesystems).
• Why: Customers often ban public Docker Hub images due to supply chain risks.

2. The customer’s SOC detects your app making outbound HTTPS calls to an unknown domain. What do you do?

• Answer: Immediately block the traffic and investigate. If it’s legitimate (e.g., a license check), document it in the SSP and get approval from the ISSO.
• Why: Unapproved outbound traffic triggers SOC alerts and can get your app shut down.

3. You’re asked to deploy a Python app, but the customer’s environment only allows FIPS-validated crypto. What’s your first move?

• Answer: Replace hashlib.md5() with hashlib.sha256() and ensure you’re using a FIPS-validated OpenSSL (e.g., openssl version should show "FIPS").
• Why: MD5 and SHA-1 are banned in FIPS mode, and non-FIPS libraries will fail scans.

Last-Minute Cram Sheet

1. ATO = Permission to run. No ATO? No deployment.
2. RMF = 6 steps (Categorize → Select → Implement → Assess → Authorize → Monitor).
3. STIGs = Security checklists. Use oscap to scan: oscap xccdf eval --profile stig-rhel8-disa.
4. FIPS mode = Required for crypto. Enable with update-crypto-policies --set FIPS (RHEL).
5. POA&Ms = Your to-do list for ATO. Close them before the customer’s deadline.
6. eMASS = DoD’s ATO tracker. Upload artifacts here.
7. Air-gapped? Use offline mirrors: apt-offline, pip download --dest.
8. ⚠️ Always test in the customer’s environment. Your lab ≠ their network.
9. SOC = Your app’s babysitter. Trigger an alert? They’ll shut you down.
10. ACO = The customer’s team that owns the ATO. They’re your best friend or worst enemy.