Generic version - not vendor specific, will be collaborating on this with SUSE and Canonical. This version will become the basis for a RHEL-specific version developed by Red Hatters. This will also be used as the basis for the RHEL Hardening Guide and the current version of the Guide can be used to help with this document.
What is ok to talk about in the generic version?
What is not ok to talk about in the generic version and should be reserved for the RHEL-specific version once we get there?
RHEL 8 Hardening Guide: Red Hat Enterprise Linux 8 Security hardening
Common Criteria: Red Hat Adds Common Criteria Certification for Red Hat Enterprise Linux 8
The Compliance Collaborative for Enterprise Linux(s) wants to define a paradigm for “what constitutes a hardened Linux system.” In order to be able to define how to harden and secure these systems, consensus is needed to define deployment methods and security concerns pertaining to those environments. This outline will seek to define, with alignment to NIST SP 800-53 Control Families:
Where Linux OS are deployed (on prem, disconnected, cloud, etc)
Specific challenges unique to those deployments (HSM, air-gap, virtualizations, etc)
With a goal of determining how those challenges impact or determine how the OS will mitigate risk in those environments.
From this outline, The Enterprise Linux providers will take the information gathered and use it to apply it to current in-house security technologies, features and products to achieve a hardened Linux system (OS or platform)
Bare-Metal
Virtualized
Infrastructure Platform (Hypervisor)
On-Prem
Disconnected (air-gapped)
DMZ
Intranet
Cloud
Hyperscalers
Workload
Topology (past OS only concerns) - how they interact with Hybrid Solutions
What is a hardened linux?
Defaults to Secure Posture
Provide guidance on resiliency
Easily capable of managing certificates and implemented by default
Validate signatures of kernel modules prior to boot
Use strong, trusted cryptography starting at install time
Strong non-repudiation
Confirmed source of packages (like RH produced manifests)
Minimal application and package set for operation
Ensures trusted/secure boot
Allow list, applications, library, compilers, intrusion detection
Unaltered universal image
Systems not reviewed or scanned for vulnerabilities
Unable to prove integrity
Out of date/unpatched system (unsupported; EOL)
No enterprise security integration
Logging disabled
No firewall enabled
Weak access controls
Do not uniquely identify users
Lack of good time source
Supported known compromised encryption protocols
Manual efforts; not automated
Describe process for vendors to create and sign their content (ex, packages, base images, etc) for Consumers to use to build their Organization base images
Package manifests
-Checksums
-GPG signatures
-Vendor support contract to provide package updates and ongoing maintenance
This process should be automated and continually run on a recurring time basis as well as ad hoc as needed.
This process is the same whether building an organization’s base image, ex just Linux with minimum packages, or a layered image such as a container, a specific piece of middleware, or a mission application layered on top of the base image or a layered image.
pull install content or pre-made image from Trusted source
pull additional content required to be installed on top of base install or base pre-made image to meet mission or hardening requirements
verify pulled content or pre-made image signatures are signed with trusted keys
if doing fresh install, install from content pulled from Trusted source signed with trusted keys
install any additional required content from Trusted source signed with Trusted keys
configure system has per hardening guidelines/requirements
scan system for vulnerabilities, EX CVEs
scan system for compliance checks
prepare installed system for templatization, ex
wipe hostname, network configuration, any other machine identifying info
turn system into templatized image
create test system from new image
scan test system for vulnerabilities, EX CVEs
scan test system for compliance checks
run any mission specific functionality tests against test system
delete test system
publish template
sign template
notify dependent layered template jobs and runtime systems of new base image to kick off their release engineering process
Verify Logging in enabled and creating logs
Regularly confirmed backed up
Data at rest enabled
Data in motion - validated encryption
Data Loss prevention
Access control validation and maintenance (RBAC and ABAC)
Enterprise defined User accounts (Central and standalone)
##Consumer Organization Runtime System(s) Integration and Deployment
DOING - describe process for Consumer Organization to continually integrate runtime systems on top of base images and deploy them
-See To Do section above
Kickstarted from immutable media (RHEL DVD downloaded, checksum validated, scanned)
SELinux enforcing
Firewall enforcing, add 22 (and 4750 for us)
FIPS=1
Partitions per stig and sanity (/tmp, /var, /opt, /var/log , /var/log/audit, /home…)
Software added/removed for STIG from ideally minimal install.
Kdump killed
Postinstall script run for enterprise agent install (bladelogic)
At this point, as a vm template, the template would be cut here and phase 2 would start on vmware deploy triggers. For a physical blade, phase 2 just continues the process
Automation properties populated and pushed for network zone, tenant/business system, etc including metadata on ownership, function, known accepted security exceptions
Compliance as Code current “accepted” release (we made minor changes) pushed out to server (content, custom toolset) with other defined required files including enterprise-wide tailoring files.
Patch Server from current repo, reboot
Enterprise-mandated software suites deployed to server (McAfee HBSS, Netbackup)
Deployments tailored based on network zone properties
Customized SELinux packages pushed for enterprise and/or business software
Enterprise and business-system firewall rules
Standard network customizations for DNS, Time, mail gateway, etc
FAPolicyD enterprise base configuration
AIDE entreprise base configuration
A few other random bits
Hardening pass 1:
Execute oscap run against compliance as code content with os-specific tailoring file. Custom python integrated zone, system, etc exceptions into master tailoring file for server and validates during runtime. Run applies all STIG’s present in content_profile_stig with changes noted in tailoring.
Hardening pass 2:
Anything not found in the CAC content got written and dumped into a master ansible yaml and included in pass 2… last check, i think there 138. Ansible was configured to use exception logic fed into hardening pass 1 as well for a unified approach.
Patch server, reboot
Install phase automation steps complete. VM or server shut down, and moved to either destination service zone (non-dmz) or dmz install zone (dmz with explicit reachback to software repos)
More automation logic, then…
Add centrally managed user accounts and ssh-rsa public keys
Install and configure zone-dependent software (Solarwinds, others)
Patch and reboot (in case physical delay in hardware moves)
Kick off SCC, OSCAP, and ACAS scans.
Publish scan results to file share
Build complete.
So going through this in my mind, i see some things the jump right out at me as adding value to “hardenned”
Validated immutable media at the source
Cryptographically validated patch sources
FIPS encryption validation and enforcement from the initial boot
Automated scan and remediation content
Openly published compliance available to system owners
Deliberate, well conceived security plan
Compliant by Delivery, noncompliant by explicit administrative action
Full nonrepudiation (All those lovely audit STIGs automatically applied…)
Organization describes processes for:
Consumer Organization to continually scan runtime systems
for new static vulnerabilities (CVEs),
static compliance drift (ex, comparisons against STIG)
life intrusion events.
Additionally scanning Consumer Organization Base IMages at rest for static vulnerabilities and static compliance drift to mark as stale as new vulnerabilities and compliance criteria are released and old images become vulnerabile.
Continuous observability and monitoring *