Compliance Standards Integration#

Overview#

opnDossier integrates industry-standard security compliance frameworks to provide comprehensive blue team audit reports. The system supports STIG (Security Technical Implementation Guide), SANS Firewall Checklist, and Firewall Security Controls (independently developed cybersecurity best practices) for firewall security assessment.

Status#

Audit mode is implemented but has known issues with finding aggregation and display. See #266 for details.

Three-State Check Pattern#

Firewall compliance checks use a three-state checkResult pattern:

The "Unknown" state prevents false positives. Some settings (e.g., SSH banners, MOTD) are OS-level configurations stored outside config.xml and cannot be assessed from the exported configuration alone. When a check returns Unknown, opnDossier does not report a finding rather than guessing.

Supported Standards#

STIG (Security Technical Implementation Guide)#

STIGs are cybersecurity methodologies for standardizing security configuration within networks, servers, computers, and logical designs to enhance overall security. opnDossier implements the DISA Firewall Security Requirements Guide controls listed below.

Implemented STIG Controls#

SANS Firewall Checklist#

The SANS SCORE Firewall Checklist (prepared by Krishni Naidu) is a practical security audit checklist containing 24 numbered security elements for firewall configuration and management. It covers ruleset management, application-layer controls, logging, patching, DMZ architecture, anti-spoofing, port security, remote access, traffic filtering, and availability.

The current SANS plugin defines 4 controls with placeholder check logic. The checklist has been fully analyzed and 16 additional controls are planned for implementation, covering the complete SANS checklist.

Implemented SANS Controls#

Planned SANS Controls#

The following controls map to specific SANS SCORE Firewall Checklist items and are planned for implementation. "Implementability" indicates whether the control can be evaluated from config.xml data alone.

Ruleset and Filtering (SANS Checklist #1, #2, #3)#

Maintenance and Compliance (SANS Checklist #5, #7, #8)#

Anti-Spoofing and Traffic Validation (SANS Checklist #9, #10, #18)#

Port and Service Filtering (SANS Checklist #11, #12, #14, #15, #17)#

Network Architecture (SANS Checklist #6, #13, #16)#

Server Protection and Availability (SANS Checklist #19, #22, #23, #24)#

SANS Checklist Items Not Applicable to Config Audit#

The following SANS checklist items are procedural or endpoint-focused and cannot be evaluated from a single device configuration export:

Firewall Security Controls#

Firewall security controls provide comprehensive security guidance designed for OPNsense and pfSense firewalls, based on general cybersecurity best practices for network firewall security. They are independently developed by EvilBit Labs and draw from industry frameworks including NIST SP 800-41, PCI DSS Requirement 1, CIS Benchmarks, and NSA/CISA network infrastructure guidance.

See the Firewall Security Controls Reference for detailed per-control documentation.

Implemented Firewall Security Controls#

Status key:

• Implemented - Check logic evaluates config.xml data and produces compliant/non-compliant results
• Unknown - Control is defined but the required data is not available in config.xml (OS-level or model gap); the check always returns Unknown and no finding is emitted
• Placeholder - Control is defined with placeholder check logic that always returns compliant; real analysis will be added in a future release

Planned Firewall Security Controls#

The following controls are organized by security domain and represent the full planned expansion of the firewall plugin. Controls are sourced from NIST SP 800-41, PCI DSS v4.0 Requirement 1, CIS Benchmarks, NSA/CISA guidance, and OPNsense/pfSense-specific best practices.

Management Plane Security#

Authentication and Access Control#

Firewall Rule Hygiene#

Network Segmentation#

Anti-Spoofing and Traffic Validation#

Encryption and TLS#

Logging and Monitoring#

Time Synchronization#

SNMP Security#

VPN Configuration#

NAT Security#

Service Hardening#

Change Management and Backup#

High Availability#

Implementation Details#

Plugin Architecture#

Compliance checking is implemented via the plugin system in internal/compliance/ and internal/plugins/:

• internal/compliance/interfaces.go - Defines the Plugin interface, Control, and Finding types
• internal/audit/plugin.go - Plugin registry for dynamic plugin loading
• internal/audit/plugin_manager.go - Plugin lifecycle management
• internal/plugins/stig/ - STIG compliance plugin
• internal/plugins/sans/ - SANS compliance plugin
• internal/plugins/firewall/ - Firewall security compliance plugin

Each plugin implements the compliance.Plugin interface:

type Plugin interface {
    Name() string
    Version() string
    Description() string
    RunChecks(device *common.CommonDevice) []Finding
    GetControls() []Control
    GetControlByID(id string) (*Control, error)
    ValidateConfiguration() error
}

Compliance Checks#

The audit engine performs the following checks per plugin:

STIG Compliance Checks#

1. Default Deny Policy (V-206694) - Looks for explicit block/reject rules in the rule set and checks that no any/any pass rules override them. If no rules exist, assumes default deny (conservative approach).

2. Packet Filtering (V-206674) - Scans pass rules for overly broad source/destination addresses (any, 0.0.0.0/0, ::/0, RFC 1918 ranges) and flags rules without specific port restrictions.

3. Service Hardening (V-206690) - Checks for SNMP with community strings, Unbound DNS with DNSSEC stripping, more than 2 DHCP interfaces, and configured load balancer services.

4. Logging Configuration (V-206682) - Analyzes syslog configuration for system and auth logging. Returns comprehensive, partial, not-configured, or unable-to-determine status. Finds non-compliant when syslog is disabled, logging is only partial, or logging status cannot be determined (e.g., rules exist but syslog is not configured).

SANS Compliance Checks#

All four SANS checks currently use placeholder logic:

1. Default Deny Policy (SANS-FW-001) - Placeholder: always returns compliant
2. Explicit Rule Configuration (SANS-FW-002) - Placeholder: always returns compliant
3. Network Zone Separation (SANS-FW-003) - Placeholder: always returns compliant
4. Comprehensive Logging (SANS-FW-004) - Placeholder: always returns compliant

Firewall Security Compliance Checks#

1. SSH Warning Banner (FIREWALL-001) - Always returns Unknown. SSH banners are OS-level configs (/etc/ssh/sshd_config) not present in config.xml.

2. Auto Configuration Backup (FIREWALL-002) - Checks the Packages list and Firmware.Plugins string for the os-acb package.

3. Message of the Day (FIREWALL-003) - Always returns Unknown. MOTD is an OS-level file (/etc/motd) not present in config.xml.

4. Hostname Configuration (FIREWALL-004) - Checks the device hostname against known defaults (opnsense, pfsense, firewall, localhost). Empty hostnames are also flagged.

5. DNS Server Configuration (FIREWALL-005) - Checks whether System.DNSServers is non-empty.

6. IPv6 Disablement (FIREWALL-006) - Checks System.IPv6Allow. Finding emitted when IPv6 is enabled.

7. DNS Rebind Check (FIREWALL-007) - Always returns Unknown. The CommonDevice model does not yet expose this setting (tracked in #296).

8. HTTPS Web Management (FIREWALL-008) - Checks System.WebGUI.Protocol for case-insensitive match against "https".

Blue Team Reports#

When audit mode is working correctly (#266), the blue team report provides:

• Executive Summary with compliance metrics
• Findings by Severity with control references
• STIG Compliance Details with status matrix
• SANS Compliance Details with status matrix
• Firewall Security Compliance Details with status matrix
• Security Recommendations mapped to controls
• Compliance Roadmap for remediation
• Risk Assessment based on findings

Report Sections#

Executive Summary#

• Total findings count
• Severity breakdown
• Compliance status summary across all standards

Critical/High Findings#

• Detailed findings with control references
• Specific remediation guidance
• STIG/SANS/Firewall control mappings

Compliance Details#

• Control-by-control status for each standard
• Compliance matrices
• Risk assessments

Recommendations#

• Prioritized action items
• Control-specific guidance
• Implementation roadmap

Compliance Mapping#

Finding to Control Mapping#

Each plugin maps its findings to the relevant compliance controls using the Finding type from internal/compliance/interfaces.go. Findings include description, recommendation, and component references. Each finding carries a Severity field copied from its originating control, enabling the audit engine to accurately tally findings by severity level (critical, high, medium, low).

Cross-Standard Coverage#

Many controls overlap across standards. The following matrix shows where SANS and Firewall controls address the same security concern:

Implementation Priority#

Phase 1 — High Impact, Directly Implementable#

Controls that can be fully evaluated from existing CommonDevice fields:

SANS: SANS-FW-012 (anti-spoofing/bogon), SANS-FW-014 (dangerous ports), SANS-FW-005 (ruleset ordering), SANS-FW-021 (egress filtering), SANS-FW-019 (NAT), SANS-FW-024 (TCP state), SANS-FW-015 (secure remote access)

Firewall: FIREWALL-022 (no any-any rules), FIREWALL-029 (private address filtering), FIREWALL-030 (bogon filtering), FIREWALL-025 (rule documentation), FIREWALL-039 (remote syslog), FIREWALL-043 (NTP), FIREWALL-046 (SNMP community strings), FIREWALL-047 through 053 (VPN controls)

Phase 2 — Cross-Reference Checks#

Controls requiring correlation between multiple config sections:

FIREWALL-018 (least privilege), FIREWALL-054-056 (NAT controls), FIREWALL-032 (VLAN segmentation), FIREWALL-036-038 (certificate controls), SANS-FW-017 (mail traffic), SANS-FW-020 (DNS zone transfers), SANS-FW-022 (critical server protection)

Phase 3 — Advanced Analysis#

Controls requiring deeper algorithmic analysis or external data:

SANS-FW-008 (firmware version comparison), FIREWALL-034-035 (DoS protection tunables), SANS-FW-006 (application layer filtering)

Benefits#

For Blue Teams#

1. Standardized Assessment: Use industry-recognized security controls
2. Compliance Reporting: Generate reports for regulatory requirements
3. Risk Prioritization: Focus on high-impact security issues
4. Remediation Guidance: Get specific action items for each finding
5. Framework Alignment: Align with STIG, SANS, and industry best practices

For Organizations#

1. Regulatory Compliance: Meet STIG, SANS, and industry security requirements
2. Security Posture: Understand current security state
3. Improvement Roadmap: Plan security enhancements
4. Audit Readiness: Prepare for security assessments
5. Industry Standards: Follow recognized best practices

Future Enhancements#

Additional STIG Controls#

Additional DISA Firewall SRG controls under consideration:

• V-206701: DoS attack prevention filters
• V-206680: Network location information logging
• V-206679: Event timestamp logging
• V-206678: Event type logging
• V-206681: Source information logging
• V-206711: DoS incident alerting

Additional Standards#

• NIST Cybersecurity Framework — Map existing controls to NIST CSF categories
• PCI DSS v4.0 — Requirement 1 (network security controls) alignment
• ISO 27001 — Annex A network security controls
• CIS Benchmarks — Community-derived firewall hardening controls
• Custom Controls — Organization-specific security requirements

Planned Features#

1. Real SANS Check Logic: Replace placeholder stubs with actual analysis
2. Automated Remediation: Generate configuration fixes
3. Compliance Monitoring: Track compliance over time
4. Integration: SIEM and ticketing system integration

References#

• DISA STIG Library
• DISA Firewall Security Requirements Guide
• SANS SCORE Firewall Checklist (PDF)
• NIST SP 800-41 Rev. 1 — Guidelines on Firewalls and Firewall Policy
• NIST SP 800-53 — Security and Privacy Controls
• PCI DSS v4.0 — Requirement 1
• NSA/CISA Network Infrastructure Security Guide
• NIST Cybersecurity Framework
• Firewall Security Controls Reference

Support#

For questions about compliance standards integration:

1. Documentation: Review this guide and API documentation
2. Issues: Report bugs or feature requests via GitHub
3. Contributions: Submit improvements to compliance mappings
4. Standards: Suggest additional security frameworks to support