DISA STIGs
Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs) are mandatory hardening standards for DoD information systems. Any system deployed in or connected to a DoD network must be STIG-compliant. Infracast implements 259 STIG rules covering AWS infrastructure, RHEL 9, Ubuntu 22.04, PostgreSQL, Microsoft SQL Server, and more.
Overview
STIGs define specific configuration requirements for every category of technology, with each check assigned a severity category:
| Category | Severity | Risk Level |
|---|---|---|
| CAT I | CRITICAL/HIGH | Directly enables unauthorized access or DoD data loss |
| CAT II | MEDIUM | Marginally increases risk if violated |
| CAT III | LOW | Degrades security measures but has minimal risk if violated |
DISA publishes STIGs via IASE (Information Assurance Support Environment) and updates them quarterly. Infracast keeps its STIG rule content current via the content pack update mechanism.
Infracast STIG Coverage
259 Rules Across 6 STIG Profiles
| STIG | Rules | Category |
|---|---|---|
| AWS Foundations STIG | 48 | Cloud infrastructure |
| RHEL 9 STIG | 82 | Linux operating system |
| Ubuntu 22.04 STIG | 61 | Linux operating system |
| PostgreSQL 15 STIG | 34 | Database |
| Microsoft SQL Server 2019 STIG | 22 | Database |
| AWS RDS STIG | 12 | Managed database |
AWS Foundations STIG (48 rules)
Covers AWS account and service configuration requirements for DoD cloud environments:
| Rule | CAT | Description |
|---|---|---|
STIG-AWS-CLOUDTRAIL-ALL-REGIONS | I | CloudTrail must be enabled in all regions |
STIG-AWS-CLOUDTRAIL-VALIDATION | II | CloudTrail log file integrity validation |
STIG-AWS-ROOT-MFA | I | Root account must have MFA |
STIG-AWS-IAM-KEY-ROTATION | II | IAM access keys rotated every 90 days |
STIG-AWS-SG-NO-SSH-INTERNET | I | No security groups allow SSH from 0.0.0.0/0 |
STIG-AWS-S3-PUBLIC-BLOCK | I | S3 Block Public Access enabled at account level |
STIG-AWS-EBS-ENCRYPTION | I | EBS volumes encrypted at rest |
STIG-AWS-VPC-FLOW-LOGS | II | VPC flow logging enabled |
STIG-AWS-GUARDDUTY | II | GuardDuty enabled in all regions |
STIG-AWS-SECURITYHUB | II | Security Hub enabled |
Sample AWS STIG Finding
{
"rule_id": "STIG-AWS-CLOUDTRAIL-ALL-REGIONS",
"framework": "disa-stig",
"control_id": "ARST-00-000060",
"severity": "HIGH",
"category": "CAT I",
"title": "AWS CloudTrail must be enabled in all regions",
"description": "CloudTrail is not enabled in region 'ap-southeast-1'. DoD systems must log all API activity.",
"remediation": "Enable CloudTrail with multi-region logging and direct logs to a centralized S3 bucket with server-side encryption."
}
RHEL 9 STIG (82 rules)
The RHEL 9 STIG is one of the most comprehensive, covering kernel hardening, authentication, auditing, and service configuration:
| Category | Rules | Example Checks |
|---|---|---|
| Authentication | 18 | PAM configuration, password policy, MFA |
| Audit | 16 | auditd configuration, log retention, event rules |
| File System | 12 | noexec/nosuid mounts, world-writable files |
| Kernel | 8 | ASLR, kernel parameters, module restrictions |
| Network | 10 | Firewalld rules, IP forwarding, IPv6 |
| Services | 8 | Unnecessary services disabled, FIPS mode |
| SSH | 10 | SSHd hardening, ciphers, MACs, key types |
Sample RHEL 9 STIG rules:
RHEL-09-211010 — RHEL 9 must operate in FIPS 140-3 approved mode
RHEL-09-255015 — SSH daemon must use approved ciphers
RHEL-09-412040 — Password must contain at least one numeric character
RHEL-09-651010 — AIDE must verify integrity of all files
RHEL-09-432010 — RHEL 9 must disable the autofs service
Ubuntu 22.04 STIG (61 rules)
| Category | Rules | Focus Areas |
|---|---|---|
| Authentication | 15 | pam_pwquality, failed login lockout, MFA |
| System Integrity | 12 | AIDE, file permissions, SUID binaries |
| Auditing | 10 | auditd rules for privileged commands |
| Network | 9 | UFW firewall, TCP/IP stack hardening |
| SSH | 8 | SSHd hardening, key algorithms |
| Services | 7 | Unnecessary services, cron access |
Configuration Drift Detection (Build 17f)
STIG compliance isn't a one-time check — configurations drift over time as packages are updated, settings are changed, and engineers make manual modifications. Infracast's Configuration Drift feature (Build 17f) detects when STIG-compliant configurations change:
Import a Configuration Baseline
# Import an OSCAP scan result or CKL file
POST /api/v1/tenants/{tenantID}/configdrift/import
Content-Type: multipart/form-data
file=@rhel9-stig-scan-2024-03-01.xml
metadata={"source": "oscap", "host": "prod-web-01", "stig": "rhel9"}
Supported import formats:
- XCCDF XML (OpenSCAP output)
- CKL (STIG Viewer Checklist)
- JSON (Infracast native format)
Analyze Drift
# Compare current state against a baseline
POST /api/v1/tenants/{tenantID}/configdrift/analyze
{
"import_id": "import-abc123",
"compare_to": "latest",
"stig_profile": "rhel9"
}
# Get drift analysis results
GET /api/v1/tenants/{tenantID}/configdrift/analyses/{analysisID}
Response shows which STIG checks changed since the baseline:
{
"analysis_id": "analysis-xyz789",
"drifted_controls": 3,
"drifted": [
{
"check_id": "RHEL-09-255015",
"title": "SSH daemon must use approved ciphers",
"previous_status": "pass",
"current_status": "fail",
"changed_at": "2024-03-15T14:23:00Z",
"change_detail": "Ciphers line changed from 'aes256-gcm@openssh.com' to 'aes128-cbc'"
}
]
}
Ansible STIG Role Import
Infracast can import results from Ansible DISA STIG roles (from the ansible-lockdown project) to populate your compliance posture:
# After running the Ansible STIG role, export results
ansible-playbook rhel9-STIG.yml --tags check -e "output_results=true" \
| tee ansible-stig-results.json
# Import into Infracast
POST /api/v1/tenants/{tenantID}/configdrift/import
{
"source": "ansible",
"results_file": "<base64-encoded ansible output>",
"host_id": "aws:us-east-1:aws.ec2.instance:prod-web-01",
"stig_profile": "rhel9"
}
This allows organizations using Ansible for STIG remediation to track their compliance posture in Infracast alongside cloud infrastructure findings.
STIG Checklist Generation
Generate STIG Viewer-compatible checklists for review and reporting:
# Get available STIG profiles
GET /api/v1/stig/profiles
# Generate a STIG checklist for a specific host
POST /api/v1/tenants/{tenantID}/stig/checklist
{
"profile": "rhel9",
"node_id": "aws:us-east-1:aws.ec2.instance:prod-web-01"
}
# Export as CKL (STIG Viewer format)
POST /api/v1/tenants/{tenantID}/stig/export-ckl
{
"profile": "rhel9",
"node_id": "aws:us-east-1:aws.ec2.instance:prod-web-01",
"include_open_findings": true
}
CKL files can be loaded directly into DISA's STIG Viewer tool or submitted to your eMASS package.
STIG Compliance Score
GET /api/v1/tenants/{tenantID}/compliance/summary?framework=disa-stig
{
"framework": "disa-stig",
"rules_total": 259,
"rules_passing": 231,
"rules_failing": 28,
"by_category": {
"CAT_I": { "rules": 48, "passing": 45, "failing": 3 },
"CAT_II": { "rules": 142, "passing": 126, "failing": 16 },
"CAT_III": { "rules": 69, "passing": 60, "failing": 9 }
},
"by_stig": {
"aws": { "score": 92, "rules": 48 },
"rhel9": { "score": 87, "rules": 82 },
"ubuntu2204": { "score": 89, "rules": 61 }
}
}
CAT I findings represent the highest risk. These should be remediated immediately — open CAT I findings may block an ATO or Authorization to Connect (ATC) on DoD networks.
STIG Reports for eMASS
Generate STIG findings reports formatted for eMASS submission:
POST /api/v1/tenants/{tenantID}/reports/generate
{
"type": "framework",
"framework": "disa-stig",
"format": "pdf",
"options": {
"include_cat_i_only": false,
"group_by": "stig_profile",
"emass_format": true
}
}
Combine with the eMASS GRC integration to push STIG findings directly:
POST /api/v1/tenants/{tenantID}/grc-integrations/emass/sync
{
"sync_types": ["findings"],
"framework_filter": "disa-stig"
}
Next Steps
- CIS Benchmarks — Related hardening standard (civilian)
- FedRAMP Guide — STIG compliance often required for FedRAMP High
- API: Discovery Jobs — Schedule STIG scans
- API: Reports — Generate CKL and eMASS-formatted reports