ACAS

What ACAS Actually Is

The Assured Compliance Assessment Solution is the DoD’s enterprise vulnerability management program of record, awarded to Tenable through DISA. The contract has been renewed multiple times since the original 2012 award (HP/Tenable partnership), and Tenable continues to ship the toolset under the ACAS brand.

What’s actually in the box:

• Tenable.sc (formerly SecurityCenter) — the central console, dashboarding, and reporting layer
• Nessus scanners — the active scanning engines
• Nessus Network Monitor (NNM) — passive discovery and traffic analysis
• Tenable.sc Director — multi-console rollup for larger enclaves
• Log Correlation Engine (LCE) — historically bundled, less common in current deployments

Versioning lags commercial Tenable releases. DISA validates and posts approved builds to PMO patch repositories, and you run what’s approved — not what’s latest on tenable.com. Check the ACAS PMO portal on milSuite for the current authorized version baseline before you upgrade anything.

Where It Sits in the Compliance Flow

ACAS is mandated by USCYBERCOM CTO 08-005 and reinforced through DoDI 8510.01 (RMF), the DISA STIGs, and CCRI inspection criteria. If a system touches DoDIN, it gets ACAS-scanned. Period. There is no waiver path that ends with “we don’t scan.”

Cadence in practice:

• Credentialed vulnerability scans: weekly minimum, often pushed to daily delta scans on high-value assets
• Discovery scans: continuous via NNM plus scheduled active sweeps
• Compliance/STIG audits: monthly is typical; CCRI prep cycles tighten this considerably
• Plugin feed updates: offline differential pulls for air-gapped enclaves, usually weekly

Output flows into eMASS for POA&M generation, into command-level CCRI scorecards, and into whatever local risk dashboard the AO actually reads. ISSMs sign off; ISSOs do the actual chasing.

What It Does Well

The plugin coverage is genuinely good — Tenable’s research team is one of the better ones, and the audit files for STIG/CIS/USGCB content are maintained against current benchmarks. Credentialed Windows and Linux scans produce findings that map cleanly to CVE, IAVM, and STIG IDs in a single pass. Tenable.sc’s asset and repository model handles segmented networks reasonably well once you’ve laid it out properly.

Dashboards and Assurance Report Cards are flexible enough that a competent analyst can produce something an O-6 will actually look at without exporting to Excel.

What People Complain About

• The UI feels its age. Tenable.sc’s interface has improved but still hides useful filters three menus deep. Analysts who’ve used Tenable.io find the on-prem console clunky.
• Plugin update logistics on air-gapped networks are a recurring pain point. Differential feeds, signature validation, and the offline activation dance eat hours.
• Scan windows on operational systems — credentialed scans against domain controllers, ICS gear, or older RHEL boxes still cause occasional outages despite years of tuning guidance.
• False positives on STIG audits, particularly when registry checks don’t account for legitimate organizational settings or third-party hardening tools.
• Licensing and asset count drift during enclave growth — agencies regularly discover they’ve blown past their licensed asset ceiling.
• Reporting against eMASS requires either the official Tenable connector (limited) or homegrown export pipelines. Most shops still hand-massage CSVs.

Operational Notes

Deployment shape that survives contact with reality: one Tenable.sc per enclave or security boundary, scanners distributed by network segment with dedicated scan service accounts (least-privileged but with audit rights), NNM placed on SPAN ports at choke points. Don’t run a single scanner against everything — you’ll either time out or get throttled by network gear.

Common stumbles:

• Service accounts losing rights after a GPO change, silently degrading scans to uncredentialed
• Repository sprawl — every team makes their own, asset counts double-count, dashboards lie
• Not tuning scan policies; running a default policy against a database tier and wondering why the DBA is angry
• Forgetting that NNM findings need to be correlated, not just reported
• Treating the IAVM-to-CVE mapping as authoritative when it isn’t always current

Integration points worth setting up early: syslog out to your SIEM (Splunk, Elastic, whatever the SOC runs), the eMASS API path for POA&M ingest if your instance supports it, and a ticketing hook (ServiceNow, JIRA) so findings actually get assigned rather than dying in a dashboard.

NIST 800-53 Control Mapping

Control Family	How ACAS Contributes
RA	Vulnerability identification, severity scoring, risk reporting feeding RA-5 directly
CA	Continuous monitoring evidence (CA-7), assessment artifacts (CA-2)
CM	Configuration compliance via STIG/SCAP audits (CM-6, CM-8 asset inventory)
SI	Flaw remediation tracking (SI-2), system monitoring inputs (SI-4)
AU	Scan logs and audit trails on the Tenable.sc side (AU-2, AU-12)
AC	Account auditing during credentialed scans, privileged scan account governance (AC-2, AC-6)
IR	Vulnerability data feeding incident triage and impact analysis (IR-4)
SC	Detection of unauthorized services and protocol exposure (SC-7 boundary findings)

RA-5 is the headline. Everything else is supporting evidence you’ll cite during ATO packages and CCRI.

Bottom Line

ACAS is not optional and it is not glamorous. Run it correctly, keep the plugin feed current, tune your scan policies per asset class, and wire the output into the systems your team actually uses. Done right, it’s the single most useful piece of evidence in your RMF package. Done wrong, it’s a generator of dashboards no one trusts.