Hardened Images/Compliance
Compliance: DISA STIG, FIPS and the Evidence Pack
What is applied to every image, what the evidence pack contains, and where Kapstone Systems' responsibility ends and the customer's begins.
DISA STIG
A government configuration standard for the operating system
A Security Technical Implementation Guide is published by the Defense Information Systems Agency for a specific product, in this case Red Hat Enterprise Linux 9 and compatible distributions. It consists of several hundred individual checks covering password policy, audit rules, permitted services, SSH configuration, file permissions and related settings.
Each check carries a severity: CAT I (high), CAT II (medium) or CAT III (low). An assessor expects CAT I items closed and every open item explained.
On Kapstone images the STIG profile is applied at build time. The base image passes 433 checks with zero CAT I findings. Items that remain open are recorded in the exceptions document with the reason (commonly that the control depends on the customer environment, such as a central log destination or site-specific banner text) and the mitigating control.
FIPS 140-3
Validated cryptographic modules only
FIPS 140-3 is the U.S. and Canadian standard for cryptographic modules. Enabling FIPS mode in AlmaLinux sets the operating system crypto policy so that only FIPS 140-3 validated modules and approved algorithms are used. Non-approved ciphers are refused at the system level.
Kapstone enables FIPS mode at installation, before any application component is configured, so every component on the image inherits the policy. The validation belongs to the operating system's cryptographic modules; Kapstone Systems does not claim a validation of its own.
One practical consequence: ed25519 SSH keys are rejected. An RSA key is required at launch.
Additional controls
Three further controls on every image
| Control | Function | Relevant control families |
|---|---|---|
| SELinux enforcing | Mandatory access control. Each process is confined to what its policy permits, including processes running as root. Enforcing mode blocks violations rather than only logging them. | NIST SP 800-53 AC-3, AC-6; SP 800-171 3.1 |
| fapolicyd | Application allow-listing. Only software from trusted sources (the package manager, or paths the customer approves) is permitted to execute. | NIST SP 800-53 CM-7(5), SI-7; SP 800-171 3.4.8, 3.14 |
| auditd | The Linux audit subsystem with the STIG rule set loaded. Logons, privilege changes, permission changes and administrative commands are recorded locally for forwarding to the customer's log collector. | NIST SP 800-53 AU-2, AU-3, AU-12; SP 800-171 3.3 |
Evidence pack
Contents of each release
- OpenSCAP scan results
- Automated STIG scan output from the exact build deployed.
- DISA-format .ckl checklist
- Opens in DISA STIG Viewer and can be provided directly to an assessor or ISSO.
- SBOM (CycloneDX)
- A software bill of materials listing every package and version on the image.
- Documented exceptions list
- Each open STIG item, the reason it remains open, and the mitigating control. Suitable as POA&M input.
Every image is rebuilt monthly with current security updates, rescanned and republished with a new pack. The pack describes the image as shipped; changes made after launch are the customer's to document.
Application
Where the evidence is used
- CMMC Level 2 / NIST SP 800-171: configuration baseline and FIPS evidence for families 3.4, 3.13 and 3.14; the .ckl for the assessor; the exceptions list as POA&M input.
- Federal ATO: the .ckl and SBOM join the artifacts the ISSO already collects for the NIST SP 800-53 package.
- HIPAA, SOC 2, PCI DSS: hardening and change management evidence for the configuration questions in each framework.
- State and local: documentation requested by the CISO or HIPAA security officer at renewal.
Shared responsibility model
Division of responsibility
| Layer | Responsible party | Scope |
|---|---|---|
| Physical, network, hypervisor | Microsoft Azure / AWS | Data centers, host fleet, FedRAMP and other platform authorizations. Government regions where selected by the customer. |
| Operating system image | Kapstone Systems | STIG applied, FIPS enabled, SELinux, fapolicyd, auditd, monthly rebuilds, evidence pack per release, documented exceptions. |
| Application on the image | Kapstone Systems | For OCR, SFTP, Bastion and FHIR: the application as configured at build, with the secure defaults (key-only authentication, MFA, mutual TLS, session recording) described on each product page. |
| Customer configuration | Customer | Users and keys, data, network rules, patches applied between rebuilds, timing of moves to new releases, and any changes to the image. |
| Security program | Customer | Policies, risk assessment, system security plan, authorization boundary, log destination, incident response, training. The elements an assessor evaluates about an organization rather than a host. |
Kapstone Systems states that these images provide hardened hosts with documented evidence toward the customer's compliance objectives. Kapstone Systems does not state that the images make a customer compliant, and the images are not FedRAMP-authorized products; FedRAMP authorization belongs to the cloud platforms on which they run.
Contact Kapstone Systems
Describe the workload and cloud environment in question. Kapstone Systems will respond with a direct assessment of whether one of these images is appropriate and, if not, what alternative is recommended.
Email: info@kapstone.systems