Skip to main content

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:

CategorySeverityRisk Level
CAT ICRITICAL/HIGHDirectly enables unauthorized access or DoD data loss
CAT IIMEDIUMMarginally increases risk if violated
CAT IIILOWDegrades 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

STIGRulesCategory
AWS Foundations STIG48Cloud infrastructure
RHEL 9 STIG82Linux operating system
Ubuntu 22.04 STIG61Linux operating system
PostgreSQL 15 STIG34Database
Microsoft SQL Server 2019 STIG22Database
AWS RDS STIG12Managed database

AWS Foundations STIG (48 rules)

Covers AWS account and service configuration requirements for DoD cloud environments:

RuleCATDescription
STIG-AWS-CLOUDTRAIL-ALL-REGIONSICloudTrail must be enabled in all regions
STIG-AWS-CLOUDTRAIL-VALIDATIONIICloudTrail log file integrity validation
STIG-AWS-ROOT-MFAIRoot account must have MFA
STIG-AWS-IAM-KEY-ROTATIONIIIAM access keys rotated every 90 days
STIG-AWS-SG-NO-SSH-INTERNETINo security groups allow SSH from 0.0.0.0/0
STIG-AWS-S3-PUBLIC-BLOCKIS3 Block Public Access enabled at account level
STIG-AWS-EBS-ENCRYPTIONIEBS volumes encrypted at rest
STIG-AWS-VPC-FLOW-LOGSIIVPC flow logging enabled
STIG-AWS-GUARDDUTYIIGuardDuty enabled in all regions
STIG-AWS-SECURITYHUBIISecurity 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:

CategoryRulesExample Checks
Authentication18PAM configuration, password policy, MFA
Audit16auditd configuration, log retention, event rules
File System12noexec/nosuid mounts, world-writable files
Kernel8ASLR, kernel parameters, module restrictions
Network10Firewalld rules, IP forwarding, IPv6
Services8Unnecessary services disabled, FIPS mode
SSH10SSHd 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)

CategoryRulesFocus Areas
Authentication15pam_pwquality, failed login lockout, MFA
System Integrity12AIDE, file permissions, SUID binaries
Auditing10auditd rules for privileged commands
Network9UFW firewall, TCP/IP stack hardening
SSH8SSHd hardening, key algorithms
Services7Unnecessary 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 }
}
}
warning

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