OpenControls Logo

STIG Viewer

STIGViewer Support

The WebSphere Liberty Server must be configured to offload logs to a centralized system.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-250327IBMW-LS-000230SV-250327r1043188_ruleCCI-000140medium
Description
Log processing failures include, but are not limited to, failures in the application server log capturing mechanisms or log storage capacity being reached or exceeded. In some instances, it is preferred to send alarms to individuals rather than to an entire group. Application servers must be able to trigger an alarm and send an alert to, at a minimum, the SA and ISSO in the event there is an application server log processing failure. Satisfies: SRG-APP-000109-AS-000070, SRG-APP-000358-AS-000064
STIGDate
IBM WebSphere Liberty Server Security Technical Implementation Guide2025-02-11

Related Frameworks

2 mappings across 4 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (2) 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.

MON-05Response To Event Log Processing Failures
1.00
MON-08.1Event Log Backup on Separate Physical Systems / Components
0.50
NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (37) 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-17(1)Monitoring and Control
1.00
AC-2(1)Automated System Account Management
1.00
AC-2(4)Automated Audit Actions
1.00
AC-3Access Enforcement
1.00
AC-6(9)Log Use of Privileged Functions
1.00
AU-10Non-repudiation
1.00
AU-12Audit Record Generation
1.00
AU-12(1)System-wide and Time-correlated Audit Trail
1.00
AU-12(3)Changes by Authorized Individuals
1.00
AU-14(1)System Start-up
1.00

+27 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.4
1.00
CCI2 mappings
CCI-000140
1.00
CCI-001851
1.00

Details

Check Text (C-250327r1043188_chk)

As a privileged user with local file access to ${server.config.dir}/server.xml, verify the logstashCollector-1.0 feature is enabled. grep -i -A5 logstashcollector server.xml EXAMPLE: <featureManager> <feature>logstashCollector-1.0</feature> </featureManager> <logstashCollector source="message,accessLog,audit" hostName="<ip address of logstash server>" port="<port of logstash server>" sslRef="DefaultTLSSettings" </logstashCollector> If "logstashCollector" is not a configured feature and the logstashCollector "source" setting does not contain "message,accessLog,audit", this is a finding.

Fix Text (F-53716r795033_fix)

To send Liberty logs to a centralized syslog system, the Elastic environment must be set up as per the ELK stack/Elasticsearch directions. Once that is completed, configure the server.xml. The following is a sample configuration. Individual keystore, truststore, and authentication settings will vary. The SME must substitute their own values as needed. The message, audit, and accessLog sources must be included at a minimum. For additional information refer to the IBM website: https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.WebSphere.wlp.doc/ae/twlp_analytics_logstash.html EXAMPLE: <featureManager> <feature>logstashCollector-1.0</feature> </featureManager> <keyStore id="defaultKeyStore" password="xxxxxxx" /> <keyStore id="defaultTrustStore" location="trust.jks" password="xxxxxxx" /> <ssl id="myTLSConfig" trustStoreRef="defaultTrustStore" keyStoreRef="defaultKeyStore" /> <logstashCollector source="message,accessLog,audit" hostName="your ELK stack server" port="Your ELK stack port" sslRef="myTLSConfig"> </logstashCollector>