STIGViewer Support

The IBM z/OS Syslog daemon must be properly defined and secured.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-223814RACF-SL-000030SV-223814r1196251_ruleCCI-000764medium
Description
The Syslog daemon, known as syslogd, is a z/OS Unix daemon that provides a central processing point for log messages issued by other z/OS Unix processes. It is also possible to receive log messages from other network-connected hosts. Some of the IBM Communications Server components that may send messages to syslog are the FTP, z/OS Unix Telnet, DNS, and DHCP servers. The messages may be of varying importance and may include general process information, diagnostic information, critical error notification, and audit-class information. There is a security interest in protecting the syslogd process and its associated data because of the potential to use this information in an audit process. The Syslog daemon requires special privileges and access to sensitive resources to provide its system services. Failure to properly define and control the syslog daemon could lead to unauthorized access. This exposure may result in the compromise of the integrity and availability of the operating system environment, ACP, and customer data.
STIGDate
IBM z/OS RACF Security Technical Implementation Guide2026-06-03

Related Frameworks

1 mapping across 5 frameworks
SCF0 mappings

No source states a mapping between these directly.

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

IAC-01.2Authenticate, Authorize and Audit (AAA)
1.00
IAC-02Identification & Authentication for Organizational Users
1.00
IAC-03Identification & Authentication for Non-Organizational Users
1.00
IAC-04Identification & Authentication for Devices
1.00
IAC-05Identification & Authentication for Third-Party Technology Assets, Applications and/or Services (TAAS)
1.00
NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (71) 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-11Device Lock
1.00
AC-11(1)Pattern-hiding Displays
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(11)Usage Conditions
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

+61 more (top 10 by confidence shown)

NIST 800-1710 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.

3.5.1
1.00
3.5.2
1.00
CCI1 mapping
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (3) 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 5 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-223814r1196251_chk)

From z/OS command screen enter: ListUser SYSLOGD OMVS (SYSLOGD is usual name of the SYSLOG daemon) If all of the following are true, this is not a finding. If either of the following is untrue, this is a finding. -The SYSLOGD userid is defined as a PROTECTED userid. -The SYSLOGD userid has the following z/OS Unix attributes: UID(0), HOME directory '/', shell program /bin/sh. From z/OS command screen enter: RList STARTED SYSLOGD If a matching entry in the STARTED resource class exists enabling the use of the standard userid and appropriate group, this is not a finding.

Fix Text (F-25475r868864_fix)

The Syslog daemon userid is SYSLOGD. Define the SYSLOGD userid as a PROTECTED userid. Define the SYSLOGD userid has UID(0), HOME('/'), and PROGRAM('/bin/sh') specified in the OMVS segment. To set up and use as an MVS Started Proc, the following sample commands are provided: AU SYSLOGD NAME('stc, tcpip') NOPASSWORD NOOIDCARD DFLTGRP(STC) - OWNER(STC) DATA('Reference ISLG0020 for proper setup ') ALU SYSLOGD DFLTGRP(stctcpx) ALU SYSLOGD OMVS(UID(0) HOME('/') PROGRAM('/bin/sh')) CO SYSLOGD GROUP(stctcpx) OWNER(stctcpx) A matching entry mapping the SYSLOGD started proc to the SYSLOGD userid is in the STARTED resource class. RDEF STARTED SYSLOGD.** UACC(NONE) OWNER(ADMIN) AUDIT(ALL(READ)) STDATA(USER(SYSLOGD) GROUP(STC)) If /etc/rc is used to start the Syslog daemon, ensure that the _BPX_JOBNAME and _BPX_ USERID environment variables are assigned a value of SYSLOGD.