CIS Benchmarks as a Platform Baseline
An auditor asks: "What hardening standard applies to your JBoss server?" Answer A: "We have hardened everything." Answer B: "CIS Level 1, Policy ID 24.2, Q3-2025, three documented exceptions." Both teams have hardened their systems. Only one answer passes the audit.
CIS Benchmarks are not a certificate or an award. They are the shared reference language in which your team and an auditor can discuss system hardening: concrete, platform-specific, versioned, and built from controls that can actually be verified. lennlay implements CIS Benchmarks as an operational baseline, not a paper document.
The most important distinction first
- A consensus-based, publicly available hardening reference maintained by the Center for Internet Security
- Concrete configuration controls per platform: RHEL, Windows Server, JBoss EAP, Apache Tomcat, Apache HTTP Server, IIS
- Level 1: controls with low operational risk, suitable for most production environments
- Level 2: extended security depth that may restrict operational flexibility
- Updated for each major version of a platform
- Used by auditors worldwide to evaluate hardening: not as a certification authority, but as an objective reference
- Not a certification program, and not an official audit standard that issues a label
- Not a substitute for internal risk assessment: which controls apply at which level remains a judgment call
- Not a one-size-fits-all solution: the appropriate level depends on the risk profile of the platform
- Not a one-time project: a CIS baseline that is not maintained will drift and lose its audit value
When CIS Benchmarks are implemented as an operational baseline, you can tell an auditor: "We follow CIS Level 1 for JBoss EAP, here are the controls applied, here are the documented exceptions." That is audit language.
Level 1, Level 2, and the lennlay Best Practice
CIS Level 1
Foundational security with low operational risk.
Controls that significantly increase security without disrupting normal operations. Fast to apply, low implementation risk. Suitable as a minimum standard for all production environments.
CIS Level 2
Extended hardening for elevated protection requirements.
Additional controls with greater hardening depth that go beyond Level 1. Individual measures may restrict operational flexibility. Applying all Level 2 controls to every system is not always appropriate and requires a per-environment risk assessment.
lennlay Best Practice
CIS L1 plus selected L2 controls, pragmatic.
lennlay's pre-selected combination of L1 controls and specific L2 controls that deliver high security value with low operational disruption. The starting point for most lennlay customers before customer-specific policy refinement takes place.
CIS Benchmarks by lennlay product
lennlay maps each product to the corresponding CIS Benchmark. Implementation depth grows with product maturity.
Secure Linux Platform Automation
Secure Tomcat Platform Automation
Secure JBoss EAP Platform Automation
Secure Apache HTTP Platform Automation
Secure Windows Platform Automation
Secure IIS Platform Automation
Not a checklist, a policy artifact
lennlay translates CIS Benchmarks into machine-readable policy artifacts that are applied automatically and continuously verified.
Policy artifact
Every CIS baseline is captured as a structured policy artifact with a Rule ID, target platform, policy version, and complete rule set. Each rule contains: ID, name, significance and risk, level (L1/L2/BP), description, implementation steps, and audit check.
Policy lifecycle
Definition, versioning, approval, application, review, and audit evidence form a complete lifecycle. Minor rule adjustments are included in the subscription; new platform versions or new baselines are handled as major changes.
Automated enforcement
Ansible Collections apply the policy to all instances. New servers start at baseline level without manual configuration. Deviations are detected immediately, not at the next audit.
Automated compliance scan
A scanner continuously checks live instances against the policy and produces a structured report: which controls are met, which are not, which exceptions are active. Auditable, exportable, traceable.
Manage exceptions, do not hide them
CIS Benchmarks are not applied blindly at 100 percent. Some controls do not fit a specific environment. The difference is whether exceptions are documented or ignored.
Every exception has an ID
The exception is linked to the Rule ID of the relevant policy control. No anonymous "we skipped that" situations.
Justification and approval
Business reason, risk assessment, and the name of the approving person are recorded. Exceptions are not silence, they are decisions.
Expiry date
Exceptions do not accumulate indefinitely. Every exception has a validity date, after which it must be reassessed or closed.
In the audit: full transparency
"We have three documented exceptions, here they are with justifications and approval dates" is the stronger position than "we are not sure which controls we skipped."
Three situations where CIS Benchmarks make the difference
First external audit
The auditor asks for evidence of a hardening standard. Without CIS Benchmarks, the answer is "internal standard," which is vague and hard to verify. With a CIS-referenced baseline there is a concrete, verifiable foundation that the auditor already knows how to evaluate.
ISO 27001 and NIS2 compliance
ISO 27001 Annex A and NIS2 Article 21(e) require technical security measures. CIS Benchmarks are the most widely used implementation framework for these requirements. They translate regulatory obligations into concrete system configurations.
New platform or migration
A new platform is being introduced, or an environment is being migrated to a new OS or middleware version. The CIS Benchmark for the new platform defines the security target from day one, not as a post-launch cleanup.
CIS Benchmarks are not a one-time project. lennlay builds baselines that hold up in audits and are maintained over time.
