Standards & Methodology

This document explains the security standards, authoritative sources, and methodology behind infraudit's 287 checks. Every check is traceable to at least one recognized security framework.

Why infraudit Is Valid

infraudit does not invent security rules. Every check is derived from one or more of the following authoritative sources, maintained by recognized security organizations:

CIS Benchmarks (Primary Source)

The CIS Benchmarks are consensus-based security configuration guides developed by a global community of security professionals. They are the most widely adopted hardening standards for Linux systems.

Benchmark Versions Used

CIS Coverage by Section

Total CIS coverage: ~150 Level 1 controls (~95%) and ~75 Level 2 controls (~90%) are mapped to infraudit checks. Run infraudit compliance <report.json> for a detailed per-section compliance report.

CIS Levels Explained

DISA STIG

The Security Technical Implementation Guides (STIGs) are published by the US Defense Information Systems Agency. They provide configuration standards for DoD systems and are widely adopted in government and defense.

STIG Coverage

NIST SP 800-53 Mapping

NIST SP 800-53 Rev. 5 defines security and privacy controls for federal information systems. Many compliance frameworks (FedRAMP, FISMA, CMMC) reference these controls. infraudit checks map to the following control families:

How Checks Are Derived

Each infraudit check follows a traceable process from standard to implementation:

1. Control identification — A security requirement is identified from CIS Benchmarks, DISA STIG, or NIST SP 800-53.
2. Technical mapping — The control is mapped to a specific Linux configuration: a file, a sysctl parameter, a service state, a permission, or a command output.
3. Pass/Fail criteria — Objective, binary criteria are defined. For example: PermitRootLogin must be no, not just "reviewed."
4. Severity assignment — Based on exploitability and impact:
   • CRITICAL — Directly exploitable without authentication (e.g., empty passwords, root SSH login)
   • HIGH — Enables privilege escalation or significant data exposure (e.g., missing firewall, weak ciphers)
   • MEDIUM — Security best practice not applied (e.g., log rotation, ASLR)
   • LOW — Defense-in-depth improvement (e.g., login banners, NTP security)
5. Remediation — Every check includes the exact command or configuration change to fix the finding.
6. CIS mapping — The check is mapped to the specific CIS section (e.g., "5.2.1 Ensure SSH root login is disabled") and level (L1/L2).

What infraudit Inspects

infraudit reads system state through these mechanisms — it never modifies your system:

Compliance Framework Applicability

Because infraudit's checks are derived from CIS and NIST, they are directly applicable to audits under the following frameworks:

Audit Methodology

Principles

• Read-only — infraudit never modifies system state. It only reads files, queries services, and inspects configurations.
• Deterministic — The same system state always produces the same results. No sampling, no heuristics.
• Objective — Pass/fail criteria are binary and documented. There is no subjective "risk assessment."
• Traceable — Every check maps to a specific CIS section, STIG rule, or NIST control.
• Actionable — Every finding includes a remediation command or configuration change.

Scoring Algorithm

The Hardening Index (0-100) weights each check by severity:

ERROR and SKIPPED checks are excluded from scoring. The score maps to a letter grade: A (≥90), B (≥80), C (≥70), D (≥60), F (<60).

Platform Awareness

infraudit detects the operating system, package manager, and init system at startup. Checks that are specific to a platform (e.g., update-crypto-policies on RHEL, apport on Ubuntu) are automatically SKIPPED on systems where they don't apply, eliminating false positives.

Limitations & Scope

infraudit is designed for Linux server hardening validation. It is not:

• A vulnerability scanner — It does not scan for CVEs or perform port scanning. Use tools like Trivy, Nessus, or OpenVAS for that.
• A penetration testing tool — It does not attempt exploitation. Use tools like Metasploit or Burp Suite.
• A cloud configuration auditor — It does not check AWS IAM, S3 buckets, or GCP firewall rules. Use tools like Prowler, ScoutSuite, or Steampipe.
• A compliance certification — infraudit provides evidence to support compliance audits, but it is not a certification body. Compliance determination is made by qualified auditors.

References

• CIS Benchmarks — Center for Internet Security
• DISA STIGs — Defense Information Systems Agency
• NIST SP 800-53 Rev. 5 — National Institute of Standards and Technology
• OWASP Docker Security Cheat Sheet
• Linux Kernel Documentation
• Linux man pages