STIGViewer Support

The WebSphere Liberty Server must be configured to encrypt log information.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-250330IBMW-LS-000320SV-250330r960951_ruleCCI-000162medium
Description
Protection of log records is of critical importance. Encrypting log records provides a level of protection that does not rely on host-based protections that can be accidentally misconfigured, such as file system permissions. Cryptographic mechanisms are the industry-established standard used to protect the integrity of log data. An example of a cryptographic mechanism is the computation and application of a cryptographic-signed hash using asymmetric cryptography. - The security feature (appSecurity-2.0) must be defined in order to configure a user registry for the servlet to authenticate against. - The audit feature (audit-1.0) must be defined in order to generate audit records. - The servlet feature (servlet-3.1) must be defined to be able to deploy a web application. - The ejb feature (ejbLite-3.1) must be defined to be able to deploy an ejb application. - The ssl feature (ssl-1.0) must be defined to be able to generate and use certificates to sign and encrypt logs. - The ldap feature (ldapRegistry-3.0) must be defined in order to configure an enterprise-level user registry to authenticate users against. When the audit-1.0 feature is defined, all supported audit events will be captured and logged to an audit.log located under ${server.config.dir}/logs. The audit log that is currently being logged to is called audit.log. When an audit log fills to a configured maximum capacity, it is archived with a timestamp with the naming convention audit_<timestamp>.log and new records are written to audit.log. The audit logs are found under the ${server.config.dir}/logs directory and are named audit.log for the most recent, and audit_<timestamp>.log for any archived logs. One keystore needs to be created (ikeyman as part of the JDK may be used) and a personal certificate created. This certificate is used to encrypt the logs. The audit configuration needs to define the location of this keystore, its password, and the alias of the certificate used to encrypt the logs. As an example: <keyStore id="auditEncKeyStore" password="Liberty" location="${server.config.dir}/resources/security/AuditEncryptionKeyStore.jks" type="JKS" /> <keyStore id="auditSignKeyStore" password="{xor}EzY9Oi0rJg==" location="${server.config.dir}/resources/security/AuditSigningKeyStore2.jks" type="JKS" /> <auditFileHandler encrypt="true" encryptAlias="auditencryption" encryptKeyStoreRef="auditEncKeyStore" </auditFileHandler> Satisfies: SRG-APP-000126-AS-000085, SRG-APP-000118-AS-000078, SRG-APP-000267-AS-000170
STIGDate
IBM WebSphere Liberty Server Security Technical Implementation Guide2025-02-11

Related Frameworks

3 mappings across 5 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (7) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

CFG-02Secure Baseline Configurations
1.00
CRY-01Use of Cryptographic Controls
1.00
DCH-01Data Protection
1.00
IAC-21Least Privilege
1.00
MON-08Protection of Event Logs
1.00
MON-08.3Cryptographic Protection of Event Log Information
1.00
TDA-19Error Handling
1.00
NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (64) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

AC-10Concurrent Session Control
1.00
AC-17(1)Monitoring and Control
1.00
AC-17(10)Authenticate Remote Commands
1.00
AC-2(1)Automated System Account Management
1.00
AC-2(10)Shared and Group Account Credential Change
1.00
AC-2(2)Automated Temporary and Emergency Account Management
1.00
AC-2(3)Disable Accounts
1.00
AC-2(4)Automated Audit Actions
1.00
AC-3Access Enforcement
1.00
AC-3(4)Discretionary Access Control
1.00

+54 more (top 10 by confidence shown)

NIST 800-1710 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (1) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

3.3.8
1.00
CCI3 mappings
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (1) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

Who does this work

7 NICE work roles and 7 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-250330r960951_chk)

If the system is configured to send logs to a remote ELK stack log server, as per requirement IBMW-LS-000230, (or other remote logging solution) this requirement is Not Applicable. As a user with local file access to ${server.config.dir}/server.xml: 1. Verify the following features are configured. <featureManager> <feature>appSecurity-2.0</feature> <feature>audit-1.0</feature> <feature>ssl-1.0</feature> </featureManager> 2. Verify a keystore is configured. The following is an example: <keyStore id="auditEncKeyStore" password="ENTER THE ENCRYPTION KEYSTORE PASSWORD" location="${server.config.dir}/resources/security/AuditEncryptionKeyStore.jks" type="JKS" /> <keyStore id="auditSignKeyStore" password="ENTER THE SIGNING KEYSTORE PASSWORD" location="${server.config.dir}/resources/security/AuditSigningKeyStore2.jks" type="JKS" /> 3. Verify auditFileHandler encryption is enabled. Signing is optional. <auditFileHandler encrypt="true" encryptAlias="auditencryption" encryptKeyStoreRef="auditEncKeyStore" sign="true" signingAlias="auditsigning2" signingKeyStoreRef="auditSignKeyStore"> </auditFileHandler> If the features and keystore are not configured, and encryption is not enabled, this is a finding.

Fix Text (F-53719r862974_fix)

If the system is configured to send logs to a remote ELK stack log server, (or other remote logging solution) as per requirement IBMW-LS-000230, this requirement is Not Applicable. Signing is optional. The encrypted and/or signed audit logs are found under the ${server.config.dir}/logs directory and are named audit.log for the most recent, and audit_<timestamp>.log for any archived logs. Two keystores are recommended but not required when doing both encryption and signing (ikeyman as part of the JDK may be used) and a certificate imported into each. One keystore will contain the certificate used to encrypt the logs; the other keystore will contain the certificate used to sign the logs. The audit configuration must define the location of every keystore, their passwords, and the alias of each certificate used to encrypt and sign the logs. 1. Enable the following features: <featureManager> <feature>appSecurity-2.0</feature> <feature>audit-1.0</feature> <feature>ssl-1.0</feature> <feature> </featureManager> 2. Verify a keystore is configured. The following is a JKS keystore example. PKCS12 is also a viable keystore: <keyStore id="auditEncKeyStore" password="ENTER THE ENCRYPTION KEYSTORE PASSWORD" location="${server.config.dir}/resources/security/AuditEncryptionKeyStore.jks" type="JKS" /> <keyStore id="auditSignKeyStore" password="ENTER THE SIGNING KEYSTORE PASSWORD" location="${server.config.dir}/resources/security/AuditSigningKeyStore2.jks" type="JKS" /> 3. Enable auditFileHandler encryption. Signing the logs is optional. <auditFileHandler encrypt="true" encryptAlias="auditencryption" encryptKeyStoreRef="auditEncKeyStore" sign="true" signingAlias="auditsigning2" signingKeyStoreRef="auditSignKeyStore"> </auditFileHandler>