What Is DISA ACAS Certification and How Does It Work?

Here on the Ignyte blog, we talk a lot about the most important cybersecurity frameworks for the federal government, including FedRAMP and CMMC. There’s a lot that goes into these frameworks, with contributors all across the information security world, but one of the more important agencies is DISA.

The United States Defense Information Systems Agency, formerly known as the Defense Communications Agency, is the DoD sub-agency responsible for IT services and security for the Department of Defense.

DISA does a lot. You’ve certainly heard of STIGs, the Security Technical Implementation Guides that DISA creates as resources to guide the implementation of technical security (how’s that for some redundancy?). They also maintain the SPRS, or Supplier Performance Risk System, which is the register that the government uses to track security and compliance status for contractors with DFARS contract clauses or (as of last month) CMMC compliance.

Another of the many elements of information security DISA manages is ACAS. Unfortunately, because of changes over the years, a lot of brand names, and not a lot of clear resources, there’s plenty of confusion surrounding what ACAS is and who needs to care about it. Since there’s a lot to know about ACAS, we’ve decided to talk about it and help you understand what you need to know.

What is ACAS?

First up, what is ACAS?

ACAS stands for Assured Compliance Assessment Solution. It is a suite of COTS (Commercial Off The Shelf) software applications, and is comprised of tools like a security center, a vulnerability scanner, a passive vulnerability scanner, and more.

ACAS is not new, but neither is it truly old. It was first developed back in 2012 in response to the need for unified security across the DoD’s secure networks and those who access them. The DoD conducted an evaluation of prospective contractors to make a suite of security programs for use across the defense industrial base.

These programs would be mandated for any agency or contractor that needs to access networks like SIPRNet (a sort of secret government-only internet). The DoD picked two firms to do the development, and ACAS is the result.

There’s a lot of confusion surrounding ACAS because of the nouns thrown around to describe it, and the way they’re used. Names like Tenable, Perspecta, and Nessus are all used, often in contradictory ways, so we wanted to take the time to clarify what they all mean.

One important note is that ACAS is not a security framework along the lines of CMMC or FedRAMP. It is a set of tools that helps businesses and agencies comply with those frameworks through the use of vulnerability scanning, monitoring, and management of vulnerabilities.

Who is Tenable?

In 2012, when the DoD decided to formalize some kind of standardization for security, they did what the government so often does: looked for someone to do the work for them. That’s the whole point of being able to authorize third-party contractors to perform services for the government, after all.

After their search and evaluation of bids, the DoD picked two companies to perform the task of developing what we now know as the suite of ACAS tools.

Tenable Inc. is the modern-day name for the company that was then known as Tenable Network Security. They are the more well-known of the two companies that contributed to the ACAS suite.

When people refer to Tenable in the context of ACAS, they may be talking about ACAS itself, but it’s also likely that they’re talking about one of the Tenable offerings. Tenable.sc, Tenable.io, Tenable.ad, and so on, all get referred to as Tenable.

Tenable has four core modules, which are part of ACAS by default, and several more that are optional but recommended, or may be required for certain entities required to implement ACAS. We’ll go over the full set later.

Who is Perspecta?

Perspecta is the current name for the other of the two companies that were tapped to develop ACAS back in 2012. At the time, though, they had a different name: Hewlett Packard Enterprise Services, more commonly referred to as HPES, or even just HP, though Hewlett Packard itself is a different arm of the company.

This one is actually a lot muddier to track than Tenable. HPES won the contract to assist Tenable and contribute to ACAS in 2012. In 2016, HPES spun off the Enterprise Services part of its business and merged it with Computer Sciences Corporation, CSC, to create a new company, DXC Technology.

It doesn’t stop there. Just two years later, in 2018, DXC Technology merged with Vencore Holding Corporation and KeyPoint Government Solutions, in a merger that formed Perspecta.

None of the specific components of ACAS today are referred to as HP or Perspecta; the company contributed to the development of ACAS as a whole, but didn’t develop stand-alone components. Today, the company (now owned by Peraton) provides a variety of technology services to both the government and to other industries, primarily including healthcare.

What is Nessus?

In 1998, Renaud Deraison created a program called The Nessus Project, which used resources similar to STIGs to provide remote, automatic security and vulnerability scanning. The project was managed as an open-source program for a few years, until Renaud partnered up with Ron Gula and Jack Huffard to found Tenable.

In 2005, Tenable’s leadership, including Renaud, decided that keeping Nessus as an open-source project was losing them money and opportunities, so they shifted it to a closed-source proprietary licensed program. It was forked at the time; an open-source version still exists, called OpenVAS, though the two have diverged significantly over the intervening two decades.

Nessus, being a fully-featured and highly automated vulnerability scanner, was a big part of what the DoD was looking for when they sought firms to develop ACAS, and is a significant reason why Tenable won the contract.

Today, Nessus is one of the components offered by Tenable as part of ACAS.

A lot of the confusion in terminology surrounding ACAS comes from the fact that Nessus is one of the most prominent and important components of ACAS; people who aren’t clear on the components and design of the system refer to all of ACAS as Nessus, or think of ACAS as a set of Nessus components, neither of which is strictly accurate.

What Was Retina?

Sometimes, in the context of ACAS and DISA, you’ll see references to Retina. Retina was a vulnerability scanner developed by the security firm BeyondTrust, formerly eEye. Retina continued to exist as a competitor to Nessus for some time, was eventually rolled into the BeyondTrust Enterprise Vulnerability Management tool, and was discontinued as of December 31, 2020.

Despite that, occasionally, some legacy references and long-time employees habitually refer to various ACAS apps as parts of “Retina” the same way people now refer to ACAS as Nessus.

To Sum Up:

ACAS is the overall Assured Compliance Assessment Solution, which is comprised of several security services that are primarily owned, developed, and maintained by Tenable, including Tenable.sc, Tenable.io, and Nessus.

Retina is the name of the scanning system in use before ACAS was developed to replace it.

What Do the ACAS Applications Do?

ACAS is made up of several core modules and several more optional modules. All of them provide specific functionality for automatic evaluation, monitoring, and maintenance of security.

Different elements of the Tenable and Nessus suite fulfill security goals laid out in various relevant security clauses. Using the tools on an ongoing basis is critical to maintain compliance with security frameworks like CMMC and higher-tier SECRET and above security clearances.

Nessus Vulnerability Scanning

Nessus is a critical component of ACAS and is the tool used as an active vulnerability scanner. To use a metaphor, it’s similar to running an antivirus check on your personal computer, or having a security firm patrol and audit a facility.

Nessus works through the use of reference libraries full of technical data on technology systems and configurations. These come from many different sources, but two of the biggest are STIGs and CVEs.

STIGs: Security Technical Implementation Guides. These are individual guides that are specific to apps or pieces of hardware like phones, routers, or other devices. STIGs can be anywhere from a small handful of configuration options to dozens or hundreds, depending on the complexity of the app or device and the granularity of controls.

STIGs can apply to everything from server operating systems to apps like Microsoft Word to VPNs. Created and written in a machine-readable format, a STIG is easy for a program like Nessus to read, and then check the relevant app or device on your system to compare and identify differences from acceptable security.

CVEs: Common Vulnerabilities and Exposures. Whenever a security hole in an app or system is identified, it is analyzed. This analysis facilitates both the closure of the security hole and the recording of the existence of the security hole. In common parlance, you can think of it sort of like the virus definitions that allow your computer’s antivirus to identify malware.

CVEs are used throughout the government for security purposes, but also throughout the private sector, and are not limited to the United States. Vulnerability researchers around the world contribute knowledge and awareness to the library.

Nessus (and other competing active vulnerability scanners) use these reference libraries to scan systems and seek out any vulnerabilities. Active scans are generally performed on a weekly basis, as well as when major vulnerabilities are discovered, and when major changes are made to systems.

Passive Vulnerability Scanning

PVS, or passive vulnerability scanning, is the other side of the coin of Nessus. You can think of it sort of like a motion detector for your security status. This passive scanning monitors traffic at the packet level throughout your network, checking for signs of vulnerabilities, unknown or unwanted traffic, or other problems. It’s passive in that you don’t need to initiate scans; it’s just always there in the background, as opposed to Nessus, which needs to be activated to scan.

To add to the confusion, the most common PVS used as part of ACAS is also called Nessus, specifically the Nessus Network Monitor. There are also other PVS apps out there, and all of them work in effectively the same way, drawing on the same sorts of resources (like CVEs) to check for signs of vulnerabilities.

Security Center

Security Centers are the central control rooms of the overall ACAS security paradigm. Usually referred to as either Tenable or Nessus, the Security Center is where the scans are initiated and the results are reported.

Tenable.sc is the common on-premises scanning and control system based on Nessus and Nessus PVS. Meanwhile, Tenable.io is a cloud-based version of the same system. There’s also Tenable.ad, meant for environments relying on Active Directory.

Who Needs to Use ACAS?

Why is ACAS important, and to whom?

ACAS is not a framework; it’s a suite of tools. Those tools are used to comply with various security frameworks, at least in part, across technical and operational lines (but do not impact other elements of those frameworks, like personnel training).

The trick is that ACAS in the Tenable/Nessus sense is not required, but ACAS in the “using a technical solution to validate security” sense is. Frameworks like FedRAMP and CMMC, as well as requirements for higher-level security clearances, have technological requirements that can be satisfied using ACAS tools.

These work even at high levels. For example, Tenable Enclave Security is designed and built for very stringent requirements and will satisfy the requirements for FedRAMP High and CMMC Level 3.

So, while the specific tools developed by Tenable for the DoD for the purpose of ACAS are not necessarily required, they’re very commonly used because they’re purpose-built for the job of security according to the DoD rules.

If you’re complying with one of the security frameworks like CMMC, the Ignyte Assurance Platform can help. Using ACAS tools like Nessus will generate reports, and you can mirror those reports in the Ignyte Platform, so they’re available as artifacts of proof of your security implementation when it’s time to validate and audit your systems. To see how it works for you and discuss how it can function alongside your ACAS tools, just schedule a call to see it in action.