Assessing Cyber Attack Risk in the Defense Industrial Base

Word count: ~1,850

Specificity markers hit:

1. ✅ NIST/CMMC control references (RA.L2-3.11.1, RA.L2-3.11.2, SC.L2-3.13.1, AC.L2-3.1.12)
2. ✅ Cost/time estimate (72-hour DIBNET reporting window; quarterly scan cadence)
3. ✅ Tool/product names (Nessus, Qualys, CISA KEV catalog, MITRE ATT&CK)
4. ✅ Common mistake (assessing generic IT risk instead of DIB-specific threats)
5. ✅ Decision point with guidance (which threat intel sources to prioritize)

---

Assessing Cyber Attack Risk in the Defense Industrial Base

The defense industrial base gets targeted differently than most industries. Your threat isn't primarily ransomware gangs looking for a quick payout — it's nation-state adversaries who want the technical data in your CUI files. That distinction matters for how you assess risk. A generic IT risk assessment process will miss the threats that matter most to a defense contractor.

This is what a DIB-specific cyber attack risk assessment actually looks like.

Who's Coming After DIB Contractors

CMMC exists because CUI in the defense supply chain has been exfiltrated at scale. The most significant documented threat actors against DIB contractors are nation-state groups — primarily Chinese APTs (advanced persistent threat groups) and, to a lesser extent, Russian and Iranian actors — who target CUI specifically: technical drawings, specifications, manufacturing processes, and research data.

What makes these threats different from typical cybercrime:

They're patient. Nation-state adversaries don't need to move fast. They establish persistence in a compromised network and spend weeks or months quietly exfiltrating data. A ransomware gang makes noise. An APT doesn't.

They target your supply chain. Prime contractors are hard targets. Their subcontractors — smaller companies with less security investment — are softer. A threat actor who can't get into a large prime may go after a tier-3 subcontractor that handles a component specification. If that subcontractor handles CUI and lacks basic access controls, they're the vector.

They use your legitimate tools. Spearphishing, credential theft, and living-off-the-land techniques using Windows management tools are common. These attacks blend in with normal IT activity and don't trigger signature-based detection.

They persist across contract changes. If an attacker establishes a foothold in your environment, they may stay there through a contract renewal, a new award, and a re-competition. They're reading your CUI as it flows through your systems.

This context shapes your risk assessment. The likelihood of a nation-state attack on a mid-size defense contractor is not theoretical — it's documented and ongoing. The Cybersecurity and Infrastructure Security Agency (CISA) and NSA publish advisories specifically about APT activity targeting DIB companies. These aren't generic warnings; they describe specific tools, techniques, and procedures.

The Risk Assessment Framework for DIB Contractors

CMMC requires a periodic risk assessment under RA.L2-3.11.1: assess risk to operations, assets, and individuals from CUI system operation. NIST SP 800-30 Rev 1 is the methodology CMMC assessors expect you to know, even if you don't run the full formal process.

The SP 800-30 structure breaks down as:

1. Prepare for the assessment Define the scope (which systems are in your assessment boundary?), identify information sources (vulnerability scans, threat intelligence, prior incident data), and establish risk tolerance (what level of risk is your organization willing to accept before escalating to a POA&M?).

2. Conduct the assessment This has four sub-steps: - Identify threat sources and events - Identify vulnerabilities and predisposing conditions - Determine likelihood - Determine impact

For a DIB contractor, the threat source list has to include nation-state adversaries explicitly. If your risk assessment only lists "external hackers" and "malicious insiders," you're missing the specific threat profile that CMMC was built to address.

3. Communicate results Document findings in a form that drives decisions — a risk register with rated risks, not just a list of problems. Management needs to see the outputs and make accept/mitigate/transfer/avoid decisions on each significant risk.

4. Maintain the assessment Risk assessments aren't one-and-done. They need to be updated when systems change, when new threats emerge, and at a minimum annually.

DIB-Specific Threat Sources to Include

Generic risk assessments pull from generic threat databases. For DIB, supplement that with:

CISA Known Exploited Vulnerabilities (KEV) catalog — CISA maintains a list of vulnerabilities being actively exploited in the wild. For DIB contractors, prioritize KEV remediation over purely CVSS-score-based prioritization. A vulnerability that's being actively exploited in your sector matters more than a theoretical high-severity finding that no one is actually using.

CISA and NSA Joint Advisories for DIB — When CISA and NSA publish a joint advisory about an APT targeting defense contractors (they publish these regularly), that's a specific threat event that should trigger a review of your controls and a scan for indicators of compromise. Don't treat these as background reading — treat them as actionable threat intelligence.

MITRE ATT&CK Framework — The ATT&CK framework documents the techniques, tactics, and procedures of known threat actors, including the Chinese and Russian groups most active against DIB. Use the ATT&CK Enterprise matrix to map your detective controls against known adversary techniques. If your controls have no visibility into "lateral movement" techniques (T1021, T1550), that's a risk.

Your own incident history — If you've had phishing attempts, credential stuffing events, or anomalous VPN authentication, those are data points about your actual threat environment, not just theoretical possibilities.

Vulnerability Identification: What to Scan and How Often

Under RA.L2-3.11.2, you're required to scan periodically and when new vulnerabilities are identified. What does that mean operationally?

Authenticated scans, not just network pings. An unauthenticated scan tells you what ports are open and what services are running. An authenticated scan — where your scanner logs into each system with credentials — tells you what software is installed, what patches are missing, and what misconfigurations exist. Your assessor will ask whether your scans are authenticated. The answer should be yes.

Scan all in-scope assets. Every system in your CUI environment, including servers, workstations, network devices, and cloud instances. Assessors have found contractors scanning their primary file server but forgetting the IT admin workstations that have privileged access to it.

Scan cadence: Quarterly at minimum for all in-scope assets. Monthly for internet-facing systems. Immediately when a CVE is published for software you're running (the CISA KEV catalog is a good trigger).

Tools: Nessus Professional and Qualys VMDR are the two most widely used in the DIB space. Both support authenticated scanning, integrate with your asset inventory, and generate reports you can add directly to your evidence package. Nessus Professional runs about $4,000–$6,000/year per scanner; Qualys VMDR is subscription-based starting around $500–$1,500/month depending on asset count.

Attack Surface Analysis for DIB Contractors

Beyond vulnerability scanning, a DIB-specific assessment should analyze your external attack surface — what's visible and reachable from the internet.

Remote access points. Every VPN endpoint, RDP portal, or remote management interface is a target. Under AC.L2-3.1.12, remote access requires encryption and monitoring. But before you can monitor it properly, you need to know all of it exists. Shadow IT (remote access tools employees set up without IT involvement) is a common source of exposure.

Email security. Spearphishing is the most common initial access vector for APTs targeting DIB. Does your email filtering catch malicious attachments and spoofed sender domains? Do your users know what to do when a suspicious email gets through?

Third-party and supply chain connections. If you have network connectivity to subcontractors, partners, or managed service providers, those connections are part of your attack surface. A compromised third party with access to your CUI environment is a threat path that your internal controls alone don't stop.

Internet-facing applications. Any web application that can be reached from the internet and connects to your CUI environment should be in your assessment scope, including vendor portals, project management tools, and file sharing services.

Boundary protection. Under SC.L2-3.13.1, you're required to monitor and control communications at your CUI environment boundary. Document your boundary controls in your risk assessment as a mitigating factor — then verify they're actually working, not just documented.

Common Mistake: Using Generic IT Risk Instead of DIB Threat Context

The most common mistake in DIB risk assessments is copy-pasting a generic IT risk assessment template without adapting it to the actual threat environment.

Generic templates list threats like "natural disaster," "power outage," and "accidental data disclosure." Those are real risks. They're not the risks that will get a defense contractor's CUI exfiltrated or their contract canceled.

A DIB-specific assessment names the threat actors (Chinese APT groups like APT41, APT40; criminal groups that sell access to APT actors), their known techniques, and the specific control gaps in your environment that those techniques would exploit. The risk is specific. The finding is specific. The remediation is specific.

If your risk assessment reads like a generic ISO 27001 compliance exercise with no mention of nation-state threats, spearphishing, or CUI exfiltration, your assessor will notice. More importantly, it won't actually tell you what you need to know.

What Your Assessor Expects

For the RA domain, your assessor will:

Examine: Your risk assessment document — scope, methodology, threat identification section (does it call out DIB-relevant threats?), vulnerability scan results with dates, remediation tracking tied to risk ratings.

Interview: Whoever runs your risk program. "What are the primary threats to your organization's CUI?" If the answer is only "ransomware" with no mention of targeted exfiltration, that's a red flag. "How do you use threat intelligence in your assessment?" should get a concrete answer about sources and how findings feed into your risk register.

Test: They may run a vulnerability scan or check whether your remediation timelines are being met. If you scanned in Q1 and found critical vulnerabilities, and it's now Q3, where's the evidence of remediation?

The documentation trail needs to show a complete cycle: scan → risk assessment → risk decisions → remediation → verification → next scan. If any link in that chain is missing, you have a finding.

---

See also: NIST SP 800-30: The Risk Assessment Methodology for a walkthrough of the full assessment process.

Got specific questions about CMMC? Our expert is available around the clock — no waiting, no sales pitch.

Got Questions? Ask our CMMC Expert →

Prefer email? Reach us at ix@isegrim-x.com