Datastream XCCDF Checklist GPOS v3r2p2
with profile xccdf_basic_profile_.check
This XCCDF document provides a basic security check for a Linux system.
Evaluation Characteristics
| Evaluation target | unknown |
|---|---|
| Target ID | reg.mini.dev/openjdk-fips:26.0.1 |
| Benchmark URL | #scap_org.open-scap_comp_all-resolved-xccdf-v3r2.xml |
| Benchmark ID | xccdf_org.open-scap.sce-community-content_benchmark_all |
| Benchmark version | 3.2.2 |
| Profile ID | xccdf_basic_profile_.check |
| Started at | 2026-06-21T02:00:05+00:00 |
| Finished at | 2026-06-21T02:00:07+00:00 |
| Performed by | unknown user |
| Test system | cpe:/a:redhat:openscap:1.4.4 |
CPE Platforms
Addresses
Compliance and Scoring
There were no failed or uncertain rules. It seems that no action is necessary.
Rule results
Score
| Scoring system | Score | Maximum | Percent |
|---|---|---|---|
| urn:xccdf:scoring:default | 100.000000 | 100.000000 | |
| urn:xccdf:scoring:flat | 91.000000 | 91.000000 |
Rule Overview
Result Details
The operating system must use cryptographic mechanisms
to protect the integrity of audit tools.xccdf_mil.disa.stig_rule_SV-203682r991567_rule highCCI-001496
The operating system must use cryptographic mechanisms to protect the integrity of audit tools.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203682r991567_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-001496 |
| Description | Protecting the integrity of the tools used for
auditing purposes is a critical step toward ensuring the integrity of audit
information. Audit information includes all information (e.g., audit
records, audit settings, and audit reports) needed to successfully audit
information system activity.
Audit tools include, but are not limited to, vendor-provided and open source
audit tools needed to successfully view and manipulate audit information
system activity and records. Audit tools include custom queries and report
generators.
It is not uncommon for attackers to replace the audit tools or inject code
into the existing tools with the purpose of providing the capability to hide
or erase system activity from the audit logs.
To address this risk, audit tools must be cryptographically signed in order
to provide the capability to identify when the audit tools have been
modified, manipulated, or replaced. An example is a checksum hash of the
file or files. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must implement cryptographic
mechanisms to prevent unauthorized disclosure of all information at rest on
all operating system components.xccdf_mil.disa.stig_rule_SV-203746r958872_rule highCCI-002476
The operating system must implement cryptographic mechanisms to prevent unauthorized disclosure of all information at rest on all operating system components.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203746r958872_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-002476 |
| Description | Operating systems handling data requiring "data
at rest" protections must employ cryptographic mechanisms to prevent
unauthorized disclosure and modification of the information at rest.
Selection of a cryptographic mechanism is based on the need to protect the
integrity of organizational information. The strength of the mechanism is
commensurate with the security category and/or classification of the
information. Organizations have the flexibility to either encrypt all
information on storage devices (i.e., full disk encryption) or encrypt
specific data structures (e.g., files, records, or fields). |
| Rationale | Linux containers store configuration and data files on the host
filesystem. As such, the host filesystem is responsible for the size, capacity,
and utilization of the physical disks used by the containers running on that host.
To protect data at rest inside containers from unauthorized access or modification,
security measures must be implemented at the host operating system level, such as
using encrypted virtual filesystems.
For more information on inherited controls for containers see the DISA Container
Hardening Process Guide. |
The operating system must implement cryptographic
mechanisms to prevent unauthorized modification of all information at rest
on all operating system components.xccdf_mil.disa.stig_rule_SV-203745r958870_rule highCCI-002475
The operating system must implement cryptographic mechanisms to prevent unauthorized modification of all information at rest on all operating system components.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203745r958870_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-002475 |
| Description | Operating systems handling data requiring "data
at rest" protections must employ cryptographic mechanisms to prevent
unauthorized disclosure and modification of the information at rest.
Selection of a cryptographic mechanism is based on the need to protect the
integrity of organizational information. The strength of the mechanism is
commensurate with the security category and/or classification of the
information. Organizations have the flexibility to either encrypt all
information on storage devices (i.e., full disk encryption) or encrypt
specific data structures (e.g., files, records, or fields). |
| Rationale | Linux containers store configuration and data files on the host
filesystem. As such, the host filesystem is responsible for the size, capacity,
and utilization of the physical disks used by the containers running on that host.
To protect data at rest inside containers from unauthorized access or modification,
security measures must be implemented at the host operating system level, such as
using encrypted virtual filesystems.
For more information on inherited controls for containers see the DISA Container
Hardening Process Guide. |
The operating system must implement cryptographic
mechanisms to prevent unauthorized disclosure of information and/or detect
changes to information during transmission unless otherwise protected by
alternative physical safeguards, such as, at a minimum, a Protected
Distribution System (PDS).xccdf_mil.disa.stig_rule_SV-203749r971547_rule highCCI-002421
The operating system must implement cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission unless otherwise protected by alternative physical safeguards, such as, at a minimum, a Protected Distribution System (PDS).
| Rule ID | xccdf_mil.disa.stig_rule_SV-203749r971547_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-002421 |
| Description | Encrypting information for transmission protects
information from unauthorized disclosure and modification. Cryptographic
mechanisms implemented to protect information integrity include, for
example, cryptographic hash functions which have common application in
digital signatures, checksums, and message authentication codes.
Use of this requirement will be limited to situations where the data owner
has a strict requirement for ensuring data integrity and confidentiality is
maintained at every step of the data transfer and handling process. When
transmitting data, operating systems need to leverage transmission
protection mechanisms such as TLS, SSL VPNs, or IPSec.
Alternative physical protection measures include PDS. PDSs are used to
transmit unencrypted classified National Security Information (NSI) through
an area of lesser classification or control. Since the classified NSI is
unencrypted, the PDS must provide adequate electrical, electromagnetic, and
physical safeguards to deter exploitation. |
| Rationale | Linux containers do not automatically expose open ports to the host
or network where the containers are running. If ports need to be opened, they must
be explicitly configured during container startup to allow the application to be
accessible on the network. A host configured to comply with STIG requirements will
only enable the ports essential for the container’s operation. Once exposed, these
open ports must be filtered and monitored by the host’s firewall and protected by
the host’s auditing and security features.
For more information on inherited controls for containers see the DISA Container
Hardening Process Guide. |
The operating system must protect the confidentiality
and integrity of transmitted information.xccdf_mil.disa.stig_rule_SV-203748r958908_rule highCCI-002418
The operating system must protect the confidentiality and integrity of transmitted information.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203748r958908_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-002418 |
| Description | Without protection of the transmitted
information, confidentiality and integrity may be compromised because
unprotected communications can be intercepted and either read or altered.
This requirement applies to both internal and external networks and all
types of information system components from which information can be
transmitted (e.g., servers, mobile devices, notebook computers, printers,
copiers, scanners, and facsimile machines). Communication paths outside the
physical protection of a controlled boundary are exposed to the possibility
of interception and modification.
Protecting the confidentiality and integrity of organizational information
can be accomplished by physical means (e.g., employing physical distribution
systems) or by logical means (e.g., employing cryptographic techniques). If
physical means of protection are employed, then logical means (cryptography)
do not have to be employed, and vice versa. |
| Rationale | Linux containers do not automatically expose open ports to the host
or network where the containers are running. If ports need to be opened, they must
be explicitly configured during container startup to allow the application to be
accessible on the network. A host configured to comply with STIG requirements will
only enable the ports essential for the container’s operation. Once exposed, these
open ports must be filtered and monitored by the host’s firewall and protected by
the host’s auditing and security features.
For more information on inherited controls for containers see the DISA Container
Hardening Process Guide. |
The operating system must protect the confidentiality
and integrity of communications with wireless peripherals.xccdf_mil.disa.stig_rule_SV-252688r958358_rule highCCI-002418
The operating system must protect the confidentiality and integrity of communications with wireless peripherals.
| Rule ID | xccdf_mil.disa.stig_rule_SV-252688r958358_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-002418 |
| Description | Without protection of communications with
wireless peripherals, confidentiality and integrity may be compromised
because unprotected communications can be intercepted and either read,
altered, or used to compromise the operating system.
This requirement applies to wireless peripheral technologies (e.g., wireless
mice, keyboards, displays, etc.) used with an operating system. Wireless
peripherals (e.g., Wi-Fi/Bluetooth/IR Keyboards, Mice, and Pointing Devices
and Near Field Communications [NFC]) present a unique challenge by creating
an open, unsecured port on a computer. Wireless peripherals must meet DoD
requirements for wireless data transmission and be approved for use by the
AO. Even though some wireless peripherals, such as mice and pointing
devices, do not ordinarily carry information that need to be protected,
modification of communications with these wireless peripherals may be used
to compromise the operating system. Communication paths outside the physical
protection of a controlled boundary are exposed to the possibility of
interception and modification.
Protecting the confidentiality and integrity of communications with wireless
peripherals can be accomplished by physical means (e.g., employing physical
barriers to wireless radio frequencies) or by logical means (e.g., employing
cryptographic techniques). If physical means of protection are employed,
then logical means (cryptography) do not have to be employed, and vice
versa. If the wireless peripheral is only passing telemetry data, encryption
of the data may not be required. |
| Rationale | Linux containers do not automatically inherit access to
underlying hardware such as USB and WiFi adapters on the hosts where they run.
If such connections are required, they must be explicitly configured during
container runtime. A host configured to meet STIG requirements will disable
unused USB connections and ensure WiFi interfaces are properly configured,
only enabling them when necessary for the service to operate.
For more information on inherited controls for containers see the DISA
Container Hardening Process Guide. |
The operating system must record time stamps for audit
records that can be mapped to Coordinated Universal Time (UTC) or Greenwich
Mean Time (GMT).xccdf_mil.disa.stig_rule_SV-203714r958788_rule lowCCI-001890
The operating system must record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT).
| Rule ID | xccdf_mil.disa.stig_rule_SV-203714r958788_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | low |
| Identifiers: | CCI-001890 |
| Description | If time stamps are not consistently applied and
there is no common time reference, it is difficult to perform forensic
analysis.
Time stamps generated by the operating system include date and time. Time is
commonly expressed in Coordinated Universal Time (UTC), a modern
continuation of Greenwich Mean Time (GMT), or local time with an offset from
UTC. |
| Rationale | Linux containers inherit the system time from the underlying host,
and do not operate a separate time service. Configuration of the host's time
service is responsible for generating the timestamp used by the host’s auditing
system, performing periodic synchronization, and ensuring that only authorized
time servers are used as the authoritative source. Time synchronization of the
host clock is automatically reflected in the time used by the container.
For more information on inherited controls for containers see the DISA
Container Hardening Process Guide. |
The operating system must provide a report generation
capability that supports after-the-fact investigations of security
incidents.xccdf_mil.disa.stig_rule_SV-203708r958774_rule lowCCI-001880
The operating system must provide a report generation capability that supports after-the-fact investigations of security incidents.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203708r958774_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | low |
| Identifiers: | CCI-001880 |
| Description | If the report generation capability does not
support after-the-fact investigations, it is difficult to establish,
correlate, and investigate the events leading up to an outage or attack or
identify those responses for one. This capability is also required to comply
with applicable Federal laws and DoD policies.
The report generation capability must support after-the-fact investigations
of security incidents either natively or through the use of third-party
tools. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must immediately notify the SA and
ISSO (at a minimum) when allocated audit record storage volume reaches 75
percent of the repository maximum audit record storage capacity.xccdf_mil.disa.stig_rule_SV-203702r971542_rule lowCCI-001855
The operating system must immediately notify the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of the repository maximum audit record storage capacity.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203702r971542_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | low |
| Identifiers: | CCI-001855 |
| Description | If security personnel are not notified
immediately when storage volume reaches 75% utilization, they are unable to
plan for audit record storage capacity expansion. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must offload audit records onto a
different system or media from the system being audited.xccdf_mil.disa.stig_rule_SV-203701r958754_rule lowCCI-001851
The operating system must offload audit records onto a different system or media from the system being audited.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203701r958754_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | low |
| Identifiers: | CCI-001851 |
| Description | Information stored in one location is vulnerable
to accidental or incidental deletion or alteration.
Off-loading is a common process in information systems with limited audit
storage capacity. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must allocate audit record storage
capacity to store at least one week's worth of audit records, when audit
records are not immediately sent to a central audit record storage facility.xccdf_mil.disa.stig_rule_SV-203700r958752_rule lowCCI-001849
The operating system must allocate audit record storage capacity to store at least one week's worth of audit records, when audit records are not immediately sent to a central audit record storage facility.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203700r958752_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | low |
| Identifiers: | CCI-001849 |
| Description | In order to ensure operating systems have a
sufficient storage capacity in which to write the audit logs, operating
systems need to be able to allocate audit record storage capacity.
The task of allocating audit record storage capacity is usually performed
during initial installation of the operating system. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must provide a report generation
capability that supports on-demand reporting requirements.xccdf_mil.disa.stig_rule_SV-203707r958772_rule lowCCI-001879
The operating system must provide a report generation capability that supports on-demand reporting requirements.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203707r958772_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | low |
| Identifiers: | CCI-001879 |
| Description | The report generation capability must support
on-demand reporting in order to facilitate the organization's ability to
generate incident reports, as needed, to better handle larger-scale or more
complex security incidents.
Report generation must be capable of generating on-demand (i.e.,
customizable, ad hoc, and as-needed) reports. On-demand reporting allows
personnel to report issues more rapidly to more effectively meet reporting
requirements. Collecting log data and aggregating it to present the data in
a single, consolidated report achieves this objective. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must provide a report generation
capability that supports on-demand audit review and analysis.xccdf_mil.disa.stig_rule_SV-203706r958770_rule lowCCI-001878
The operating system must provide a report generation capability that supports on-demand audit review and analysis.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203706r958770_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | low |
| Identifiers: | CCI-001878 |
| Description | The report generation capability must support
on-demand review and analysis in order to facilitate the organization's
ability to generate incident reports, as needed, to better handle
larger-scale or more complex security incidents.
Report generation must be capable of generating on-demand (i.e.,
customizable, ad hoc, and as-needed) reports. On-demand reporting allows
personnel to report issues more rapidly to more effectively meet reporting
requirements. Collecting log data and aggregating it to present the data in
a single, consolidated report achieves this objective. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must provide an audit reduction
capability that supports after-the-fact investigations of security
incidents.xccdf_mil.disa.stig_rule_SV-203705r958768_rule lowCCI-001877
The operating system must provide an audit reduction capability that supports after-the-fact investigations of security incidents.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203705r958768_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | low |
| Identifiers: | CCI-001877 |
| Description | If the audit reduction capability does not
support after-the-fact investigations, it is difficult to establish,
correlate, and investigate the events leading up to an outage or attack or
identify those responses for one. This capability is also required to comply
with applicable Federal laws and DoD policies.
Audit reduction capability must support after-the-fact investigations of
security incidents either natively or through the use of third-party tools.
This requirement is specific to operating systems with audit reduction
capabilities. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must provide an audit reduction
capability that supports on-demand audit review and analysis.xccdf_mil.disa.stig_rule_SV-203704r958766_rule lowCCI-001875
The operating system must provide an audit reduction capability that supports on-demand audit review and analysis.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203704r958766_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | low |
| Identifiers: | CCI-001875 |
| Description | The ability to perform on-demand audit review and
analysis, including after the audit data has been subjected to audit
reduction, greatly facilitates the organization's ability to generate
incident reports, as needed, to better handle larger-scale or more complex
security incidents.
Audit reduction is a technique used to reduce the volume of audit records in
order to facilitate a manual review. Audit reduction does not alter original
audit records. The report generation capability provided by the application
must support on-demand (i.e., customizable, ad hoc, and as-needed) reports. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must authenticate peripherals
before establishing a connection.xccdf_mil.disa.stig_rule_SV-203730r958820_rule mediumCCI-001958
The operating system must authenticate peripherals before establishing a connection.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203730r958820_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001958 |
| Description | Without authenticating devices, unidentified or
unknown devices may be introduced, thereby facilitating malicious activity.
Peripherals include, but are not limited to, such devices as flash drives,
external storage, and printers. |
| Rationale | Linux containers do not automatically inherit access to
underlying hardware such as USB and WiFi adapters on the hosts where they run.
If such connections are required, they must be explicitly configured during
container runtime. A host configured to meet STIG requirements will disable
unused USB connections and ensure WiFi interfaces are properly configured,
only enabling them when necessary for the service to operate.
For more information on inherited controls for containers see the DISA
Container Hardening Process Guide. |
The operating system must authenticate all endpoint
devices before establishing a local, remote, and/or network connection using
bidirectional authentication that is cryptographically based.xccdf_mil.disa.stig_rule_SV-203731r971545_rule mediumCCI-001967
The operating system must authenticate all endpoint devices before establishing a local, remote, and/or network connection using bidirectional authentication that is cryptographically based.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203731r971545_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001967 |
| Description | Without authenticating devices, unidentified or
unknown devices may be introduced, thereby facilitating malicious activity.
Bidirectional authentication provides stronger safeguards to validate the
identity of other devices for connections that are of greater risk.
Bidirectional authentication solutions include, but are not limited to, IEEE
802.1x and Extensible Authentication Protocol [EAP], RADIUS server with
EAP-Transport Layer Security [TLS] authentication, Kerberos, and SSL mutual
authentication.
A local connection is any connection with a device communicating without the
use of a network. A network connection is any connection with a device that
communicates through a network (e.g., local area network, wide area network,
or the Internet). A remote connection is any connection with a device
communicating through an external network (e.g., the Internet).
Because of the challenges of applying this requirement on a large scale,
organizations are encouraged to only apply this requirement to those limited
number (and type) of devices that truly need to support this capability. |
| Rationale | Minimus images are extremely minimal, equipped with only the essential software
required for a container to perform its intended purpose. All components deemed to be non-essential
have been removed, including shell environments, executables, package managers, software installers,
and process-launching tools. Furthermore, Minimus containers restrict the installation of additional
packages on the image before or during runtime, to help protect against unauthorized modification.
The host operating system environment is further protected against unauthorized modification by
standard Linux container isolation mechanisms including the Linux Namespace and cgroup subsystems.
Together, these help to protect the host system against potential malicious activity from the
containers running on it.
For more information on inherited controls for containers see the DISA ContainerHardening Process
Guide. |
The operating system must manage excess capacity,
bandwidth, or other redundancy to limit the effects of information flooding
types of Denial of Service (DoS) attacks.xccdf_mil.disa.stig_rule_SV-203658r958528_rule mediumCCI-001095
The operating system must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of Denial of Service (DoS) attacks.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203658r958528_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001095 |
| Description | DoS is a condition when a resource is not
available for legitimate users. When this occurs, the organization either
cannot accomplish its mission or must operate at degraded capacity.
Managing excess capacity ensures that sufficient capacity is available to
counter flooding attacks. Employing increased capacity and service
redundancy may reduce the susceptibility to some DoS attacks. Managing
excess capacity may include, for example, establishing selected usage
priorities, quotas, or partitioning. |
| Rationale | Containers achieve process isolation by executing applications in a
constrained environment. Linux namespace and cgroup subsystems are used to provide
process isolation, where container processes can only access a limited set of system
resources, defined when the container is launched.
Processes are further restricted by cgroup-imposed limits on system resources such as
system memory and CPU usage. Cgroups help protect host resources and other containers
by preventing a single container from consuming excessive resources, reducing the risk
of Denial of Service (DoS) attacks. Namespaces and cgroups help to isolate the security
functions of the host operating system from the non-security functions of applications
running within containers. This separation ensures that container failures do not
directly impact the host’s operation or its security mechanisms. In the event of a
container failure during initialization, shutdown, or an unexpected abort, the host
operating system's security capabilities will continue to function as expected.
For more information on inherited controls for containers see the DISA Container
Hardening Process Guide. |
The operating system must be configured in accordance
with the security configuration settings based on DoD security configuration
or implementation guidance, including STIGs, NSA configuration guides, CTOs,
and DTMs.xccdf_mil.disa.stig_rule_SV-203780r991589_rule mediumCCI-000366
The operating system must be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203780r991589_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000366 |
| Description | Configuring the operating system to implement
organization-wide security implementation guides and security checklists
ensures compliance with federal standards and establishes a common security
baseline across DoD that reflects the most restrictive security posture
consistent with operational requirements.
Configuration settings are the set of parameters that can be changed in
hardware, software, or firmware components of the system that affect the
security posture and/or functionality of the system. Security-related
parameters are those parameters impacting the security state of the system,
including the parameters required to satisfy other security control
requirements. Security-related parameters include, for example: registry
settings; account, file, directory permission settings; and settings for
functions, ports, protocols, services, and remote connections. |
| Rationale | The OpenSCAP tool can be used to validate containers against the
General Purpose Operating STIG and other applicable STIGs. OpenSCAP is used to
review and validate the configuration of the image filesystem and to perform
interactive testing by executing commands against running containers.
For more information on inherited controls for containers see the DISA
Container Hardening Process Guide. |
The operating system must enable an application
firewall, if available.xccdf_mil.disa.stig_rule_SV-203784r991593_rule mediumCCI-000366
The operating system must enable an application firewall, if available.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203784r991593_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000366 |
| Description | Firewalls protect computers from network attacks
by blocking or limiting access to open network ports. Application firewalls
limit which applications are allowed to communicate over the network. |
| Rationale | Linux containers inherit the firewall configuration of their host
operating system. That is, the host firewall configuration determines which
container ports can be accessed from the network. The host firewall also
controls which ports are accessible on the applications running on the container.
Therefore, an additional application-level firewall inside the container is not
necessary.
For more information on inherited controls for containers see the DISA Container
Hardening Process Guide. |
The operating system must provide an audit reduction
capability that supports on-demand reporting requirements.xccdf_mil.disa.stig_rule_SV-203651r958506_rule mediumCCI-001876
The operating system must provide an audit reduction capability that supports on-demand reporting requirements.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203651r958506_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001876 |
| Description | The ability to generate on-demand reports,
including after the audit data has been subjected to audit reduction,
greatly facilitates the organization's ability to generate incident reports
as needed to better handle larger-scale or more complex security incidents.
Audit reduction is a process that manipulates collected audit information
and organizes such information in a summary format that is more meaningful
to analysts. The report generation capability provided by the application
must support on-demand (i.e., customizable, ad hoc, and as-needed) reports. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
Operating systems must prevent unauthorized and
unintended information transfer via shared system resources.xccdf_mil.disa.stig_rule_SV-203657r958524_rule mediumCCI-001090
Operating systems must prevent unauthorized and unintended information transfer via shared system resources.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203657r958524_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001090 |
| Description | Preventing unauthorized information transfers
mitigates the risk of information, including encrypted representations of
information, produced by the actions of prior users/roles (or the actions of
processes acting on behalf of prior users/roles) from being available to any
current users/roles (or current processes) that obtain access to shared
system resources (e.g., registers, main memory, hard disks) after those
resources have been released back to information systems. The control of
information in shared resources is also commonly referred to as object reuse
and residual information protection.
This requirement generally applies to the design of an information
technology product, but it can also apply to the configuration of particular
information system components that are, or use, such products. This can be
verified by acceptance/validation processes in DoD or other government
agencies.
There may be shared resources with configurable protections (e.g., files in
storage) that may be assessed on specific information system components. |
| Rationale | Containers achieve process isolation by executing applications in a
constrained environment. Linux namespace and cgroup subsystems are used to provide
process isolation, where container processes can only access a limited set of system
resources, defined when the container is launched.
Processes are further restricted by cgroup-imposed limits on system resources such as
system memory and CPU usage. Cgroups help protect host resources and other containers
by preventing a single container from consuming excessive resources, reducing the risk
of Denial of Service (DoS) attacks. Namespaces and cgroups help to isolate the security
functions of the host operating system from the non-security functions of applications
running within containers. This separation ensures that container failures do not
directly impact the host’s operation or its security mechanisms. In the event of a
container failure during initialization, shutdown, or an unexpected abort, the host
operating system's security capabilities will continue to function as expected.
For more information on inherited controls for containers see the DISA Container
Hardening Process Guide. |
The operating system must isolate security functions
from nonsecurity functions.xccdf_mil.disa.stig_rule_SV-203656r958518_rule mediumCCI-001084
The operating system must isolate security functions from nonsecurity functions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203656r958518_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001084 |
| Description | An isolation boundary provides access control and
protects the integrity of the hardware, software, and firmware that perform
security functions.
Security functions are the hardware, software, and/or firmware of the
information system responsible for enforcing the system security policy and
supporting the isolation of code and data on which the protection is based.
Operating systems implement code separation (i.e., separation of security
functions from nonsecurity functions) in a number of ways, including through
the provision of security kernels via processor rings or processor modes.
For non-kernel code, security function isolation is often achieved through
file system protections that serve to protect the code on disk and address
space protections that protect executing code.
Developers and implementers can increase the assurance in security functions
by employing well-defined security policy models; structured, disciplined,
and rigorous hardware and software development techniques; and sound
system/security engineering principles. Implementation may include isolation
of memory space and libraries. Operating systems restrict access to security
functions through the use of access control mechanisms and by implementing
least privilege capabilities. |
| Rationale | Containers achieve process isolation by executing applications in a
constrained environment. Linux namespace and cgroup subsystems are used to provide
process isolation, where container processes can only access a limited set of system
resources, defined when the container is launched.
Processes are further restricted by cgroup-imposed limits on system resources such as
system memory and CPU usage. Cgroups help protect host resources and other containers
by preventing a single container from consuming excessive resources, reducing the risk
of Denial of Service (DoS) attacks. Namespaces and cgroups help to isolate the security
functions of the host operating system from the non-security functions of applications
running within containers. This separation ensures that container failures do not
directly impact the host’s operation or its security mechanisms. In the event of a
container failure during initialization, shutdown, or an unexpected abort, the host
operating system's security capabilities will continue to function as expected.
For more information on inherited controls for containers see the DISA Container
Hardening Process Guide. |
The operating system must prevent program execution in
accordance with local policies regarding software program usage and
restrictions and/or rules authorizing the terms and conditions of software
program usage.xccdf_mil.disa.stig_rule_SV-203721r958804_rule mediumCCI-001764
The operating system must prevent program execution in accordance with local policies regarding software program usage and restrictions and/or rules authorizing the terms and conditions of software program usage.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203721r958804_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001764 |
| Description | Control of program execution is a mechanism used
to prevent execution of unauthorized programs. Some operating systems may
provide a capability that runs counter to the mission or provides users with
functionality that exceeds mission requirements. This includes functions and
services installed at the operating system-level.
Some of the programs, installed by default, may be harmful or may not be
necessary to support essential organizational operations (e.g., key
missions, functions). Removal of executable programs is not always possible;
therefore, establishing a method of preventing program execution is critical
to maintaining a secure system baseline.
Methods for complying with this requirement include restricting execution of
programs in certain environments, while preventing execution in other
environments; or limiting execution of certain program functionality based
on organization-defined criteria (e.g., privileges, subnets, sandboxed
environments, or roles). |
| Rationale | Minimus images are extremely minimal, equipped with only the essential software
required for a container to perform its intended purpose. All components deemed to be non-essential
have been removed, including shell environments, executables, package managers, software installers,
and process-launching tools. Furthermore, Minimus containers restrict the installation of additional
packages on the image before or during runtime, to help protect against unauthorized modification.
The host operating system environment is further protected against unauthorized modification by
standard Linux container isolation mechanisms including the Linux Namespace and cgroup subsystems.
Together, these help to protect the host system against potential malicious activity from the
containers running on it.
For more information on inherited controls for containers see the DISA ContainerHardening Process
Guide. |
The operating system must employ a deny-all,
permit-by-exception policy to allow the execution of authorized software
programs.xccdf_mil.disa.stig_rule_SV-203722r958808_rule mediumCCI-001774
The operating system must employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203722r958808_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001774 |
| Description | Utilizing a whitelist provides a configuration
management method for allowing the execution of only authorized software.
Using only authorized software decreases risk by limiting the number of
potential vulnerabilities.
The organization must identify authorized software programs and permit
execution of authorized software. The process used to identify software
programs that are authorized to execute on organizational information
systems is commonly referred to as whitelisting.
Verification of white-listed software occurs prior to execution or at system
startup.
This requirement applies to operating system programs, functions, and
services designed to manage system processes and configurations (e.g., group
policies). |
| Rationale | Minimus images are extremely minimal, equipped with only the essential software
required for a container to perform its intended purpose. All components deemed to be non-essential
have been removed, including shell environments, executables, package managers, software installers,
and process-launching tools. Furthermore, Minimus containers restrict the installation of additional
packages on the image before or during runtime, to help protect against unauthorized modification.
The host operating system environment is further protected against unauthorized modification by
standard Linux container isolation mechanisms including the Linux Namespace and cgroup subsystems.
Together, these help to protect the host system against potential malicious activity from the
containers running on it.
For more information on inherited controls for containers see the DISA ContainerHardening Process
Guide. |
The operating system must allow only the ISSM (or
individuals or roles appointed by the ISSM) to select which auditable events
are to be audited.xccdf_mil.disa.stig_rule_SV-203620r958444_rule mediumCCI-000171
The operating system must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203620r958444_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000171 |
| Description | Without the capability to restrict which roles
and individuals can select which events are audited, unauthorized personnel
may be able to prevent the auditing of critical events. Misconfigured audits
may degrade the system's performance by overwhelming the audit log.
Misconfigured audits may also make it more difficult to establish,
correlate, and investigate the events relating to an incident or identify
those responsible for one. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records when
successful/unsuccessful attempts to access privileges occur.xccdf_mil.disa.stig_rule_SV-203621r958446_rule mediumCCI-000172
The operating system must generate audit records when successful/unsuccessful attempts to access privileges occur.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203621r958446_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must remove all software
components after updated versions have been installed.xccdf_mil.disa.stig_rule_SV-203755r958936_rule mediumCCI-002617
The operating system must remove all software components after updated versions have been installed.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203755r958936_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002617 |
| Description | Previous versions of software components that are
not removed from the information system after updates have been installed
may be exploited by adversaries. Some information technology products may
remove older versions of software automatically from the information system. |
| Rationale | Minimus images are extremely minimal, equipped with only the essential software
required for a container to perform its intended purpose. All components deemed to be non-essential
have been removed, including shell environments, executables, package managers, software installers,
and process-launching tools. Furthermore, Minimus containers restrict the installation of additional
packages on the image before or during runtime, to help protect against unauthorized modification.
The host operating system environment is further protected against unauthorized modification by
standard Linux container isolation mechanisms including the Linux Namespace and cgroup subsystems.
Together, these help to protect the host system against potential malicious activity from the
containers running on it.
For more information on inherited controls for containers see the DISA ContainerHardening Process
Guide. |
The operating system must protect wireless access to
and from the system using encryption.xccdf_mil.disa.stig_rule_SV-203688r991568_rule mediumCCI-001444
The operating system must protect wireless access to and from the system using encryption.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203688r991568_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001444 |
| Description | Allowing devices and users to connect to or from
the system without first authenticating them allows untrusted access and can
lead to a compromise or attack. Since wireless communications can be
intercepted, it is necessary to use encryption to protect the
confidentiality of information in transit.
Wireless technologies include, for example, microwave, packet radio
(UHF/VHF), 802.11x, and Bluetooth. Wireless networks use authentication
protocols (e.g., EAP/TLS, PEAP), which provide credential protection and
mutual authentication.
This requirement applies to those operating systems that control wireless
devices. |
| Rationale | Linux containers do not automatically inherit access to
underlying hardware such as USB and WiFi adapters on the hosts where they run.
If such connections are required, they must be explicitly configured during
container runtime. A host configured to meet STIG requirements will disable
unused USB connections and ensure WiFi interfaces are properly configured,
only enabling them when necessary for the service to operate.
For more information on inherited controls for containers see the DISA
Container Hardening Process Guide. |
The operating system must protect wireless access to
the system using authentication of users and/or devices.xccdf_mil.disa.stig_rule_SV-203689r991569_rule mediumCCI-001443
The operating system must protect wireless access to the system using authentication of users and/or devices.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203689r991569_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001443 |
| Description | Allowing devices and users to connect to the
system without first authenticating them allows untrusted access and can
lead to a compromise or attack.
Wireless technologies include, for example, microwave, packet radio
(UHF/VHF), 802.11x, and Bluetooth. Wireless networks use authentication
protocols (e.g., EAP/TLS, PEAP), which provide credential protection and
mutual authentication.
This requirement applies to those operating systems that control wireless
devices. |
| Rationale | Linux containers do not automatically inherit access to
underlying hardware such as USB and WiFi adapters on the hosts where they run.
If such connections are required, they must be explicitly configured during
container runtime. A host configured to meet STIG requirements will disable
unused USB connections and ensure WiFi interfaces are properly configured,
only enabling them when necessary for the service to operate.
For more information on inherited controls for containers see the DISA
Container Hardening Process Guide. |
The operating system must behave in a predictable and
documented manner that reflects organizational and system objectives when
invalid inputs are received.xccdf_mil.disa.stig_rule_SV-203752r958926_rule mediumCCI-002754
The operating system must behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203752r958926_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002754 |
| Description | A common vulnerability of operating system is
unpredictable behavior when invalid inputs are received. This requirement
guards against adverse or unintended system behavior caused by invalid
inputs, where information system responses to the invalid input may be
disruptive or cause the system to fail into an unsafe state.
The behavior will be derived from the organizational and system requirements
and includes, but is not limited to, notification of the appropriate
personnel, creating an audit record, and rejecting invalid input. |
| Rationale | Containers achieve process isolation by executing applications in a
constrained environment. Linux namespace and cgroup subsystems are used to provide
process isolation, where container processes can only access a limited set of system
resources, defined when the container is launched.
Processes are further restricted by cgroup-imposed limits on system resources such as
system memory and CPU usage. Cgroups help protect host resources and other containers
by preventing a single container from consuming excessive resources, reducing the risk
of Denial of Service (DoS) attacks. Namespaces and cgroups help to isolate the security
functions of the host operating system from the non-security functions of applications
running within containers. This separation ensures that container failures do not
directly impact the host’s operation or its security mechanisms. In the event of a
container failure during initialization, shutdown, or an unexpected abort, the host
operating system's security capabilities will continue to function as expected.
For more information on inherited controls for containers see the DISA Container
Hardening Process Guide. |
The operating system must be configured to prohibit or
restrict the use of functions, ports, protocols, and/or services, as defined
in the PPSM CAL and vulnerability assessments.xccdf_mil.disa.stig_rule_SV-203638r958480_rule mediumCCI-000382
The operating system must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203638r958480_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000382 |
| Description | In order to prevent unauthorized connection of
devices, unauthorized transfer of information, or unauthorized tunneling
(i.e., embedding of data types within data types), organizations must
disable or restrict unused or unnecessary physical and logical
ports/protocols on information systems.
Operating systems are capable of providing a wide variety of functions and
services. Some of the functions and services provided by default may not be
necessary to support essential organizational operations. Additionally, it
is sometimes convenient to provide multiple services from a single component
(e.g., VPN and IPS); however, doing so increases risk over limiting the
services provided by any one component.
To support the requirements and principles of least functionality, the
operating system must support the organizational requirements, providing
only essential capabilities and limiting the use of ports, protocols, and/or
services to only those required, authorized, and approved to conduct
official business or to address authorized quality of life issues. |
| Rationale | Linux containers inherit the firewall configuration of their host
operating system which dictates which ports on the container can be accessed
from the network. Selection of which ports to make accessible on the
applications running on the container is the responsibility of the host
firewall configuration - an additional application-level firewall inside the
container is not necessary.
For more information on inherited controls for containers see the DISA
Container Hardening Process Guide. |
The operating system must be configured to disable
non-essential capabilities.xccdf_mil.disa.stig_rule_SV-203637r958478_rule mediumCCI-000381
The operating system must be configured to disable non-essential capabilities.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203637r958478_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000381 |
| Description | It is detrimental for operating systems to
provide, or install by default, functionality exceeding requirements or
mission objectives. These unnecessary capabilities or services are often
overlooked and therefore may remain unsecured. They increase the risk to the
platform by providing additional attack vectors.
Operating systems are capable of providing a wide variety of functions and
services. Some of the functions and services, provided by default, may not
be necessary to support essential organizational operations (e.g., key
missions, functions).
Examples of non-essential capabilities include, but are not limited to,
games, software packages, tools, and demonstration software, not related to
requirements or providing a wide array of functionality not required for
every mission, but which cannot be disabled. |
| Rationale | Minimus images are extremely minimal, equipped with only the essential software
required for a container to perform its intended purpose. All components deemed to be non-essential
have been removed, including shell environments, executables, package managers, software installers,
and process-launching tools. Furthermore, Minimus containers restrict the installation of additional
packages on the image before or during runtime, to help protect against unauthorized modification.
The host operating system environment is further protected against unauthorized modification by
standard Linux container isolation mechanisms including the Linux Namespace and cgroup subsystems.
Together, these help to protect the host system against potential malicious activity from the
containers running on it.
For more information on inherited controls for containers see the DISA ContainerHardening Process
Guide. |
The operating system must protect against or limit the
effects of Denial of Service (DoS) attacks by ensuring the operating system
is implementing rate-limiting measures on impacted network interfaces.xccdf_mil.disa.stig_rule_SV-203747r958902_rule mediumCCI-002385
The operating system must protect against or limit the effects of Denial of Service (DoS) attacks by ensuring the operating system is implementing rate-limiting measures on impacted network interfaces.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203747r958902_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002385 |
| Description | DoS is a condition when a resource is not
available for legitimate users. When this occurs, the organization either
cannot accomplish its mission or must operate at degraded capacity.
This requirement addresses the configuration of the operating system to
mitigate the impact of DoS attacks that have occurred or are ongoing on
system availability. For each system, known and potential DoS attacks must
be identified and solutions for each type implemented. A variety of
technologies exist to limit or, in some cases, eliminate the effects of DoS
attacks (e.g., limiting processes or establishing memory partitions).
Employing increased capacity and bandwidth, combined with service
redundancy, may reduce the susceptibility to some DoS attacks. |
| Rationale | Containers achieve process isolation by executing applications in a
constrained environment. Linux namespace and cgroup subsystems are used to provide
process isolation, where container processes can only access a limited set of system
resources, defined when the container is launched.
Processes are further restricted by cgroup-imposed limits on system resources such as
system memory and CPU usage. Cgroups help protect host resources and other containers
by preventing a single container from consuming excessive resources, reducing the risk
of Denial of Service (DoS) attacks. Namespaces and cgroups help to isolate the security
functions of the host operating system from the non-security functions of applications
running within containers. This separation ensures that container failures do not
directly impact the host’s operation or its security mechanisms. In the event of a
container failure during initialization, shutdown, or an unexpected abort, the host
operating system's security capabilities will continue to function as expected.
For more information on inherited controls for containers see the DISA Container
Hardening Process Guide. |
The operating system must provide the capability for
assigned IMOs/ISSOs or designated SAs to change the auditing to be performed
on all operating system components, based on all selectable event criteria
in near real time.xccdf_mil.disa.stig_rule_SV-203699r971541_rule mediumCCI-001914
The operating system must provide the capability for assigned IMOs/ISSOs or designated SAs to change the auditing to be performed on all operating system components, based on all selectable event criteria in near real time.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203699r971541_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001914 |
| Description | If authorized individuals do not have the ability
to modify auditing parameters in response to a changing threat environment,
the organization may not be able to effectively respond, and important
forensic information may be lost.
This requirement enables organizations to extend or limit auditing as
necessary to meet organizational requirements. Auditing that is limited to
conserve information system resources may be extended to address certain
threat situations. In addition, auditing may be limited to a specific set of
events to facilitate audit reduction, analysis, and reporting. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must allow operating system admins
to change security attributes on users, the operating system, or the
operating systems components.xccdf_mil.disa.stig_rule_SV-203694r958702_rule mediumCCI-002165
The operating system must allow operating system admins to change security attributes on users, the operating system, or the operating systems components.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203694r958702_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002165 |
| Description | Discretionary Access Control (DAC) is based on
the notion that individual users are "owners" of objects and therefore have
discretion over who should be authorized to access the object and in which
mode (e.g., read or write). Ownership is usually acquired as a consequence
of creating the object or via specified ownership assignment. DAC allows the
owner to determine who will have access to objects they control. An example
of DAC includes user-controlled file permissions.
When discretionary access control policies are implemented, subjects are not
constrained with regard to what actions they can take with information for
which they have already been granted access. Thus, subjects that have been
granted access to information are not prevented from passing (i.e., the
subjects have the discretion to pass) the information to other subjects or
objects. A subject that is constrained in its operation by Mandatory Access
Control policies is still able to operate under the less rigorous
constraints of this requirement. Thus, while Mandatory Access Control
imposes constraints preventing a subject from passing information to another
subject operating at a different sensitivity level, this requirement permits
the subject to pass the information to any subject at the same sensitivity
level. The policy is bounded by the information system boundary. Once the
information is passed outside the control of the information system,
additional means may be required to ensure the constraints remain in effect.
While the older, more traditional definitions of discretionary access
control require identity-based access control, that limitation is not
required for this use of discretionary access control. |
| Rationale | Linux containers store configuration and data files on the host
filesystem. As such, the host filesystem is responsible for the size, capacity,
and utilization of the physical disks used by the containers running on that host.
To protect data at rest inside containers from unauthorized access or modification,
security measures must be implemented at the host operating system level, such as
using encrypted virtual filesystems.
For more information on inherited controls for containers see the DISA Container
Hardening Process Guide. |
The operating system must audit the execution of
privileged functions.xccdf_mil.disa.stig_rule_SV-203697r958732_rule mediumCCI-002234
The operating system must audit the execution of privileged functions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203697r958732_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002234 |
| Description | Misuse of privileged functions, either
intentionally or unintentionally by authorized users, or by unauthorized
external entities that have compromised information system accounts, is a
serious and ongoing concern and can have significant adverse impacts on
organizations. Auditing the use of privileged functions is one way to detect
such misuse and identify the risk from insider threats and the advanced
persistent threat. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must notify system administrators
and ISSOs of account enabling actions.xccdf_mil.disa.stig_rule_SV-203691r982207_rule mediumCCI-000015
The operating system must notify system administrators and ISSOs of account enabling actions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203691r982207_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000015 |
| Description | Once an attacker establishes access to a system,
the attacker often attempts to create a persistent method of reestablishing
access. One way to accomplish this is for the attacker to enable an existing
disabled account. Sending notification of account enabling actions to the
system administrator and ISSO is one method for mitigating this risk. Such a
capability greatly reduces the risk that operating system accessibility will
be negatively affected for extended periods of time and also provides
logging that can be used for forensic purposes.
In order to detect and respond to events that affect user accessibility and
application processing, operating systems must audit account enabling
actions and, as required, notify the appropriate individuals so they can
investigate the event.
To address access requirements, many operating systems can be integrated
with enterprise-level authentication/access/auditing mechanisms that meet or
exceed access control policy requirements. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must audit all account enabling
actions.xccdf_mil.disa.stig_rule_SV-203690r958684_rule mediumCCI-002130
The operating system must audit all account enabling actions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203690r958684_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002130 |
| Description | Once an attacker establishes access to a system,
the attacker often attempts to create a persistent method of reestablishing
access. One way to accomplish this is for the attacker to enable a new or
disabled account. Auditing account modification actions provides logging
that can be used for forensic purposes.
To address access requirements, many operating systems can be integrated
with enterprise-level authentication/access/auditing mechanisms that meet or
exceed access control policy requirements. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must allow operating system admins
to grant their privileges to other operating system admins.xccdf_mil.disa.stig_rule_SV-203693r958702_rule mediumCCI-002165
The operating system must allow operating system admins to grant their privileges to other operating system admins.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203693r958702_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002165 |
| Description | Discretionary Access Control (DAC) is based on
the notion that individual users are "owners" of objects and therefore have
discretion over who should be authorized to access the object and in which
mode (e.g., read or write). Ownership is usually acquired as a consequence
of creating the object or via specified ownership assignment. DAC allows the
owner to determine who will have access to objects they control. An example
of DAC includes user-controlled file permissions.
When discretionary access control policies are implemented, subjects are not
constrained with regard to what actions they can take with information for
which they have already been granted access. Thus, subjects that have been
granted access to information are not prevented from passing (i.e., the
subjects have the discretion to pass) the information to other subjects or
objects. A subject that is constrained in its operation by Mandatory Access
Control policies is still able to operate under the less rigorous
constraints of this requirement. Thus, while Mandatory Access Control
imposes constraints preventing a subject from passing information to another
subject operating at a different sensitivity level, this requirement permits
the subject to pass the information to any subject at the same sensitivity
level. The policy is bounded by the information system boundary. Once the
information is passed outside the control of the information system,
additional means may be required to ensure the constraints remain in effect.
While the older, more traditional definitions of discretionary access
control require identity-based access control, that limitation is not
required for this use of discretionary access control. |
| Rationale | Linux containers store configuration and data files on the host
filesystem. As such, the host filesystem is responsible for the size, capacity,
and utilization of the physical disks used by the containers running on that host.
To protect data at rest inside containers from unauthorized access or modification,
security measures must be implemented at the host operating system level, such as
using encrypted virtual filesystems.
For more information on inherited controls for containers see the DISA Container
Hardening Process Guide. |
The operating system must audit all account creations.xccdf_mil.disa.stig_rule_SV-203593r958368_rule mediumCCI-000018
The operating system must audit all account creations.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203593r958368_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000018 |
| Description | Once an attacker establishes access to a system,
the attacker often attempts to create a persistent method of reestablishing
access. One way to accomplish this is for the attacker to create an account.
Auditing account creation actions provides logging that can be used for
forensic purposes.
To address access requirements, many operating systems may be integrated
with enterprise level authentication/access/auditing mechanisms that meet or
exceed access control policy requirements. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must produce audit records
containing information to establish where the events occurred.xccdf_mil.disa.stig_rule_SV-203606r958416_rule mediumCCI-000132
The operating system must produce audit records containing information to establish where the events occurred.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203606r958416_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000132 |
| Description | Without establishing where events occurred, it is
impossible to establish, correlate, and investigate the events leading up to
an outage or attack.
In order to compile an accurate risk assessment and provide forensic
analysis, it is essential for security personnel to know where events
occurred, such as operating system components, modules, device identifiers,
node names, file names, and functionality.
Associating information about where the event occurred within the operating
system provides a means of investigating an attack; recognizing resource
utilization or capacity thresholds; or identifying an improperly configured
operating system. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must produce audit records
containing information to establish the source of the events.xccdf_mil.disa.stig_rule_SV-203607r958418_rule mediumCCI-000133
The operating system must produce audit records containing information to establish the source of the events.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203607r958418_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000133 |
| Description | Without establishing the source of the event, it
is impossible to establish, correlate, and investigate the events leading up
to an outage or attack.
In addition to logging where events occur within the operating system, the
operating system must also generate audit records that identify sources of
events. Sources of operating system events include, but are not limited to,
processes and services.
In order to compile an accurate risk assessment and provide forensic
analysis, it is essential for security personnel to know the source of the
event. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must produce audit records
containing information to establish what type of events occurred.xccdf_mil.disa.stig_rule_SV-203604r958412_rule mediumCCI-000130
The operating system must produce audit records containing information to establish what type of events occurred.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203604r958412_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000130 |
| Description | Without establishing what type of events
occurred, it would be difficult to establish, correlate, and investigate the
events leading up to an outage or attack.
Audit record content that may be necessary to satisfy this requirement
includes, for example, time stamps, source and destination addresses,
user/process identifiers, event descriptions, success/fail indications,
filenames involved, and access control or flow control rules invoked.
Associating event types with detected events in the operating system audit
logs provides a means of investigating an attack; recognizing resource
utilization or capacity thresholds; or identifying an improperly configured
operating system. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must produce audit records
containing information to establish when (date and time) the events
occurred.xccdf_mil.disa.stig_rule_SV-203605r958414_rule mediumCCI-000131
The operating system must produce audit records containing information to establish when (date and time) the events occurred.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203605r958414_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000131 |
| Description | Without establishing when events occurred, it is
impossible to establish, correlate, and investigate the events leading up to
an outage or attack.
In order to compile an accurate risk assessment and provide forensic
analysis, it is essential for security personnel to know when events
occurred (date and time).
Associating event types with detected events in the operating system audit
logs provides a means of investigating an attack; recognizing resource
utilization or capacity thresholds; or identifying an improperly configured
operating system. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must produce audit records
containing information to establish the outcome of the events.xccdf_mil.disa.stig_rule_SV-203608r958420_rule mediumCCI-000134
The operating system must produce audit records containing information to establish the outcome of the events.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203608r958420_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000134 |
| Description | Without information about the outcome of events,
security personnel cannot make an accurate assessment as to whether an
attack was successful or if changes were made to the security state of the
system.
Event outcomes can include indicators of event success or failure and
event-specific results (e.g., the security state of the information system
after the event occurred). As such, they also provide a means to measure the
impact of an event and help authorized personnel to determine the
appropriate response. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records
containing the full-text recording of privileged commands.xccdf_mil.disa.stig_rule_SV-203609r958422_rule mediumCCI-000135
The operating system must generate audit records containing the full-text recording of privileged commands.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203609r958422_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000135 |
| Description | Reconstruction of harmful events or forensic
analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of
privileged commands. The organization must maintain audit trails in
sufficient detail to reconstruct events to determine the cause and impact of
compromise. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must fail to a secure state if
system initialization fails, shutdown fails, or aborts fail.xccdf_mil.disa.stig_rule_SV-203660r958550_rule mediumCCI-001190
The operating system must fail to a secure state if system initialization fails, shutdown fails, or aborts fail.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203660r958550_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001190 |
| Description | Failure to a known safe state helps prevent
systems from failing to a state that may cause loss of data or unauthorized
access to system resources. Operating systems that fail suddenly and with no
incorporated failure state planning may leave the system available but with
a reduced security protection capability. Preserving operating system state
information also facilitates system restart and return to the operational
mode of the organization with less disruption to mission-essential
processes.
Abort refers to stopping a program or function before it has finished
naturally. The term abort refers to both requested and unexpected
terminations. |
| Rationale | Containers achieve process isolation by executing applications in a
constrained environment. Linux namespace and cgroup subsystems are used to provide
process isolation, where container processes can only access a limited set of system
resources, defined when the container is launched.
Processes are further restricted by cgroup-imposed limits on system resources such as
system memory and CPU usage. Cgroups help protect host resources and other containers
by preventing a single container from consuming excessive resources, reducing the risk
of Denial of Service (DoS) attacks. Namespaces and cgroups help to isolate the security
functions of the host operating system from the non-security functions of applications
running within containers. This separation ensures that container failures do not
directly impact the host’s operation or its security mechanisms. In the event of a
container failure during initialization, shutdown, or an unexpected abort, the host
operating system's security capabilities will continue to function as expected.
For more information on inherited controls for containers see the DISA Container
Hardening Process Guide. |
The operating system must protect the confidentiality
and integrity of all information at rest.xccdf_mil.disa.stig_rule_SV-203661r958552_rule mediumCCI-001199
The operating system must protect the confidentiality and integrity of all information at rest.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203661r958552_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001199 |
| Description | Information at rest refers to the state of
information when it is located on a secondary storage device (e.g., disk
drive and tape drive, when used for backups) within an operating system.
This requirement addresses protection of user-generated data, as well as
operating system-specific configuration data. Organizations may choose to
employ different mechanisms to achieve confidentiality and integrity
protections, as appropriate, in accordance with the security category and/or
classification of the information. |
| Rationale | Linux containers store configuration and data files on the host
filesystem. As such, the host filesystem is responsible for the size, capacity,
and utilization of the physical disks used by the containers running on that host.
To protect data at rest inside containers from unauthorized access or modification,
security measures must be implemented at the host operating system level, such as
using encrypted virtual filesystems.
For more information on inherited controls for containers see the DISA Container
Hardening Process Guide. |
The operating system must generate error messages that
provide information necessary for corrective actions without revealing
information that could be exploited by adversaries.xccdf_mil.disa.stig_rule_SV-203663r958564_rule mediumCCI-001312
The operating system must generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203663r958564_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001312 |
| Description | Any operating system providing too much
information in error messages risks compromising the data and security of
the structure, and content of error messages needs to be carefully
considered by the organization.
Organizations carefully consider the structure/content of error messages.
The extent to which information systems are able to identify and handle
error conditions is guided by organizational policy and operational
requirements. Information that could be exploited by adversaries includes,
for example, erroneous logon attempts with passwords entered by mistake as
the username, mission/business information that can be derived from (if not
stated explicitly by) information recorded, and personal information, such
as account numbers, social security numbers, and credit card numbers. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must audit all account
modifications.xccdf_mil.disa.stig_rule_SV-203666r991551_rule mediumCCI-001403
The operating system must audit all account modifications.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203666r991551_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001403 |
| Description | Once an attacker establishes access to a system,
the attacker often attempts to create a persistent method of reestablishing
access. One way to accomplish this is for the attacker to modify an existing
account. Auditing account modification actions provides logging that can be
used for forensic purposes.
To address access requirements, many operating systems can be integrated
with enterprise-level authentication/access/auditing mechanisms that meet or
exceed access control policy requirements. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must audit all account disabling
actions.xccdf_mil.disa.stig_rule_SV-203667r991552_rule mediumCCI-001404
The operating system must audit all account disabling actions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203667r991552_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001404 |
| Description | When operating system accounts are disabled, user
accessibility is affected. Accounts are utilized for identifying individual
users or for identifying the operating system processes themselves. In order
to detect and respond to events affecting user accessibility and system
processing, operating systems must audit account disabling actions and, as
required, notify the appropriate individuals so they can investigate the
event. Such a capability greatly reduces the risk that operating system
accessibility will be negatively affected for extended periods of time and
provides logging that can be used for forensic purposes.
To address access requirements, many operating systems can be integrated
with enterprise-level authentication/access/auditing mechanisms that meet or
exceed access control policy requirements. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must audit all account removal
actions.xccdf_mil.disa.stig_rule_SV-203668r991553_rule mediumCCI-001405
The operating system must audit all account removal actions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203668r991553_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001405 |
| Description | When operating system accounts are removed, user
accessibility is affected. Accounts are utilized for identifying individual
users or for identifying the operating system processes themselves. In order
to detect and respond to events affecting user accessibility and system
processing, operating systems must audit account removal actions and, as
required, notify the appropriate individuals so they can investigate the
event. Such a capability greatly reduces the risk that operating system
accessibility will be negatively affected for extended periods of time and
provides logging that can be used for forensic purposes.
To address access requirements, many operating systems can be integrated
with enterprise-level authentication/access/auditing mechanisms that meet or
exceed access control policy requirements. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must verify correct operation of
all security functions.xccdf_mil.disa.stig_rule_SV-203756r958944_rule mediumCCI-002696
The operating system must verify correct operation of all security functions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203756r958944_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002696 |
| Description | Without verification of the security functions,
security functions may not operate correctly and the failure may go
unnoticed. Security function is defined as the hardware, software, and/or
firmware of the information system responsible for enforcing the system
security policy and supporting the isolation of code and data on which the
protection is based. Security functionality includes, but is not limited to,
establishing system accounts, configuring access authorizations (i.e.,
permissions, privileges), setting events to be audited, and setting
intrusion detection parameters.
This requirement applies to operating systems performing security function
verification/testing and/or systems and environments that require this
functionality. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must perform verification of the
correct operation of security functions: upon system start-up and/or
restart; upon command by a user with privileged access; and/or every 30
days.xccdf_mil.disa.stig_rule_SV-203757r958946_rule mediumCCI-002699
The operating system must perform verification of the correct operation of security functions: upon system start-up and/or restart; upon command by a user with privileged access; and/or every 30 days.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203757r958946_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002699 |
| Description | Without verification of the security functions,
security functions may not operate correctly and the failure may go
unnoticed. Security function is defined as the hardware, software, and/or
firmware of the information system responsible for enforcing the system
security policy and supporting the isolation of code and data on which the
protection is based. Security functionality includes, but is not limited to,
establishing system accounts, configuring access authorizations (i.e.,
permissions, privileges), setting events to be audited, and setting
intrusion detection parameters.
Notifications provided by information systems include, for example,
electronic alerts to system administrators, messages to local computer
consoles, and/or hardware indications, such as lights.
This requirement applies to operating systems performing security function
verification/testing and/or systems and environments that require this
functionality. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must use internal system clocks to
generate time stamps for audit records.xccdf_mil.disa.stig_rule_SV-203615r958432_rule mediumCCI-000159
The operating system must use internal system clocks to generate time stamps for audit records.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203615r958432_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000159 |
| Description | Without an internal clock used as the reference
for the time stored on each event to provide a trusted common reference for
the time, forensic analysis would be impeded. Determining the correct time a
particular event occurred on a system is critical when conducting forensic
analysis and investigating system events.
If the internal clock is not used, the system may not be able to provide
time stamps for log messages. Additionally, externally generated time stamps
may not be accurate. |
| Rationale | Linux containers inherit the system time from the underlying host,
and do not operate a separate time service. Configuration of the host's time
service is responsible for generating the timestamp used by the host’s auditing
system, performing periodic synchronization, and ensuring that only authorized
time servers are used as the authoritative source. Time synchronization of the
host clock is automatically reflected in the time used by the container.
For more information on inherited controls for containers see the DISA
Container Hardening Process Guide. |
The operating system must provide the capability to
filter audit records for events of interest based upon all audit fields
within audit records.xccdf_mil.disa.stig_rule_SV-203614r958430_rule mediumCCI-000158
The operating system must provide the capability to filter audit records for events of interest based upon all audit fields within audit records.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203614r958430_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000158 |
| Description | The ability to specify the event criteria that
are of interest provides the individuals reviewing the logs with the ability
to quickly isolate and identify these events without having to review
entries that are of little or no consequence to the investigation. Without
this capability, forensic investigations are impeded.
Events of interest can be identified by the content of specific audit record
fields, including, for example, identities of individuals, event types,
event locations, event times, event dates, system resources involved, IP
addresses involved, or information objects accessed. Organizations may
define audit event criteria to any degree of granularity required, for
example, locations selectable by general networking location (e.g., by
network or subnetwork) or selectable by specific information system
component.
This requires operating systems to provide the capability to customize audit
record reports based on all available criteria. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must alert the ISSO and SA (at a
minimum) in the event of an audit processing failure.xccdf_mil.disa.stig_rule_SV-203611r958424_rule mediumCCI-000139
The operating system must alert the ISSO and SA (at a minimum) in the event of an audit processing failure.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203611r958424_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000139 |
| Description | It is critical for the appropriate personnel to
be aware if a system is at risk of failing to process audit logs as
required. Without this notification, the security personnel may be unaware
of an impending failure of the audit capability, and system operation may be
adversely affected.
Audit processing failures include software/hardware errors, failures in the
audit capturing mechanisms, and audit storage capacity being reached or
exceeded.
This requirement applies to each audit data storage repository (i.e.,
distinct information system component where audit records are stored), the
centralized audit storage capacity of organizations (i.e., all audit data
storage repositories combined), or both. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must provide the capability to
centrally review and analyze audit records from multiple components within
the system.xccdf_mil.disa.stig_rule_SV-203613r958428_rule mediumCCI-000154
The operating system must provide the capability to centrally review and analyze audit records from multiple components within the system.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203613r958428_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000154 |
| Description | Successful incident response and auditing relies
on timely, accurate system information and analysis in order to allow the
organization to identify and respond to potential incidents in a proficient
manner. If the operating system does not provide the ability to centrally
review the operating system logs, forensic analysis is negatively impacted.
Segregation of logging data to multiple disparate computer systems is
counterproductive and makes log analysis and log event alarming difficult to
implement and manage, particularly when the system has multiple logging
components writing to different locations or systems.
To support the centralized capability, the operating system must be able to
provide the information in a format that can be extracted and used, allowing
the application performing the centralization of the log records to meet
this requirement. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must provide audit record
generation capability for DoD-defined auditable events for all operating
system components.xccdf_mil.disa.stig_rule_SV-203619r958442_rule mediumCCI-000169
The operating system must provide audit record generation capability for DoD-defined auditable events for all operating system components.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203619r958442_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000169 |
| Description | Without the capability to generate audit records,
it would be difficult to establish, correlate, and investigate the events
relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter).
The list of audited events is the set of events for which audits are to be
generated. This set of events is typically a subset of the list of all
events for which the system is capable of generating audit records.
DoD has defined the list of events for which the operating system will
provide an audit record generation capability as the following:
1) Successful and unsuccessful attempts to access, modify, or delete
privileges, security objects, security levels, or categories of information
(e.g., classification levels);
2) Access actions, such as successful and unsuccessful logon attempts,
privileged activities or other system-level access, starting and ending time
for user access to the system, concurrent logons from different
workstations, successful and unsuccessful accesses to objects, all program
initiations, and all direct access to the information system;
3) All account creations, modifications, disabling, and terminations; and
4) All kernel module load, unload, and restart actions. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must protect audit information
from unauthorized deletion.xccdf_mil.disa.stig_rule_SV-203618r958438_rule mediumCCI-000164
The operating system must protect audit information from unauthorized deletion.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203618r958438_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000164 |
| Description | If audit information were to become compromised,
then forensic analysis and discovery of the true source of potentially
malicious system activity is impossible to achieve.
To ensure the veracity of audit information, the operating system must
protect audit information from unauthorized deletion. This requirement can
be achieved through multiple methods, which will depend upon system
architecture and design.
Audit information includes all information (e.g., audit records, audit
settings, audit reports) needed to successfully audit information system
activity. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must protect audit tools from
unauthorized modification.xccdf_mil.disa.stig_rule_SV-203673r991558_rule mediumCCI-001494
The operating system must protect audit tools from unauthorized modification.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203673r991558_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001494 |
| Description | Protecting audit information also includes
identifying and protecting the tools used to view and manipulate log data.
Therefore, protecting audit tools is necessary to prevent unauthorized
operation on audit information.
Operating systems providing tools to interface with audit information will
leverage user permissions and roles identifying the user accessing the tools
and the corresponding rights the user has in order to make access decisions
regarding the modification of audit tools.
Audit tools include, but are not limited to, vendor-provided and open source
audit tools needed to successfully view and manipulate audit information
system activity and records. Audit tools include custom queries and report
generators. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must protect audit tools from
unauthorized access.xccdf_mil.disa.stig_rule_SV-203672r991557_rule mediumCCI-001493
The operating system must protect audit tools from unauthorized access.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203672r991557_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001493 |
| Description | Protecting audit information also includes
identifying and protecting the tools used to view and manipulate log data.
Therefore, protecting audit tools is necessary to prevent unauthorized
operation on audit information.
Operating systems providing tools to interface with audit information will
leverage user permissions and roles identifying the user accessing the tools
and the corresponding rights the user enjoys in order to make access
decisions regarding the access to audit tools.
Audit tools include, but are not limited to, vendor-provided and open source
audit tools needed to successfully view and manipulate audit information
system activity and records. Audit tools include custom queries and report
generators. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must produce audit records
containing information to establish the identity of any individual or
process associated with the event.xccdf_mil.disa.stig_rule_SV-203671r991556_rule mediumCCI-001487
The operating system must produce audit records containing information to establish the identity of any individual or process associated with the event.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203671r991556_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001487 |
| Description | Without information that establishes the identity
of the subjects (i.e., users or processes acting on behalf of users)
associated with the events, security personnel cannot determine
responsibility for the potentially harmful event. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must initiate session audits at
system start-up.xccdf_mil.disa.stig_rule_SV-203670r991555_rule mediumCCI-001464
The operating system must initiate session audits at system start-up.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203670r991555_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001464 |
| Description | If auditing is enabled late in the start-up
process, the actions of some start-up processes may not be audited. Some
audit systems also maintain state information only available if auditing is
enabled before a given process is created. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
In the event of a system failure, the operating system
must preserve any information necessary to determine cause of failure and
any information necessary to return to operations with least disruption to
mission processes.xccdf_mil.disa.stig_rule_SV-203677r991562_rule mediumCCI-001665
In the event of a system failure, the operating system must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to mission processes.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203677r991562_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001665 |
| Description | Failure to a known state can address safety or
security in accordance with the mission/business needs of the organization.
Failure to a known secure state helps prevent a loss of confidentiality,
integrity, or availability in the event of a failure of the information
system or a component of the system.
Preserving operating system state information helps to facilitate operating
system restart and return to the operational mode of the organization with
least disruption to mission/business processes. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must protect audit tools from
unauthorized deletion.xccdf_mil.disa.stig_rule_SV-203674r991559_rule mediumCCI-001495
The operating system must protect audit tools from unauthorized deletion.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203674r991559_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001495 |
| Description | Protecting audit information also includes
identifying and protecting the tools used to view and manipulate log data.
Therefore, protecting audit tools is necessary to prevent unauthorized
operation on audit information.
Operating systems providing tools to interface with audit information will
leverage user permissions and roles identifying the user accessing the tools
and the corresponding rights the user has in order to make access decisions
regarding the deletion of audit tools.
Audit tools include, but are not limited to, vendor-provided and open source
audit tools needed to successfully view and manipulate audit information
system activity and records. Audit tools include custom queries and report
generators. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must shut down the information
system, restart the information system, and/or notify the system
administrator when anomalies in the operation of any security functions are
discovered.xccdf_mil.disa.stig_rule_SV-203758r958948_rule mediumCCI-002702
The operating system must shut down the information system, restart the information system, and/or notify the system administrator when anomalies in the operation of any security functions are discovered.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203758r958948_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002702 |
| Description | If anomalies are not acted upon, security
functions may fail to secure the system.
Security function is defined as the hardware, software, and/or firmware of
the information system responsible for enforcing the system security policy
and supporting the isolation of code and data on which the protection is
based. Security functionality includes, but is not limited to, establishing
system accounts, configuring access authorizations (i.e., permissions,
privileges), setting events to be audited, and setting intrusion detection
parameters.
Notifications provided by information systems include messages to local
computer consoles, and/or hardware indications, such as lights.
This capability must take into account operational requirements for
availability for selecting an appropriate response. The organization may
choose to shut down or restart the information system upon security function
anomaly detection. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must notify system administrators
and ISSOs when accounts are modified.xccdf_mil.disa.stig_rule_SV-203679r991564_rule mediumCCI-000015
The operating system must notify system administrators and ISSOs when accounts are modified.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203679r991564_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000015 |
| Description | Once an attacker establishes access to a system,
the attacker often attempts to create a persistent method of reestablishing
access. One way to accomplish this is for the attacker to modify an existing
account. Notification of account modification is one method for mitigating
this risk. A comprehensive account management process will ensure an audit
trail which documents the modification of operating system user accounts and
notifies the system administrator and ISSO of changes. Such a process
greatly reduces the risk that accounts will be surreptitiously created and
provides logging that can be used for forensic purposes.
To address access requirements, many operating systems can be integrated
with enterprise-level authentication/access/auditing mechanisms that meet or
exceed access control policy requirements. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must notify system administrators
and ISSOs when accounts are created.xccdf_mil.disa.stig_rule_SV-203678r991563_rule mediumCCI-000015
The operating system must notify system administrators and ISSOs when accounts are created.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203678r991563_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000015 |
| Description | Once an attacker establishes access to a system,
the attacker often attempts to create a persistent method of reestablishing
access. One way to accomplish this is for the attacker to create a new
account. Notification of account creation is one method for mitigating this
risk. A comprehensive account management process will ensure an audit trail
which documents the creation of operating system user accounts and notifies
administrators and ISSOs that it exists. Such a process greatly reduces the
risk that accounts will be surreptitiously created and provides logging that
can be used for forensic purposes.
To address access requirements, many operating systems can be integrated
with enterprise-level authentication/access/auditing mechanisms that meet or
exceed access control policy requirements. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records when
successful/unsuccessful attempts to access security objects occur.xccdf_mil.disa.stig_rule_SV-203759r991570_rule mediumCCI-000172
The operating system must generate audit records when successful/unsuccessful attempts to access security objects occur.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203759r991570_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records when
successful/unsuccessful accesses to objects occur.xccdf_mil.disa.stig_rule_SV-203772r991583_rule mediumCCI-000172
The operating system must generate audit records when successful/unsuccessful accesses to objects occur.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203772r991583_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records for
all direct access to the information system.xccdf_mil.disa.stig_rule_SV-203773r991584_rule mediumCCI-000172
The operating system must generate audit records for all direct access to the information system.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203773r991584_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records
showing starting and ending time for user access to the system.xccdf_mil.disa.stig_rule_SV-203770r991581_rule mediumCCI-000172
The operating system must generate audit records showing starting and ending time for user access to the system.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203770r991581_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must, at a minimum, off-load audit
data from interconnected systems in real time and off-load audit data from
standalone systems weekly.xccdf_mil.disa.stig_rule_SV-203777r959008_rule mediumCCI-001851
The operating system must, at a minimum, off-load audit data from interconnected systems in real time and off-load audit data from standalone systems weekly.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203777r959008_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001851 |
| Description | Information stored in one location is vulnerable
to accidental or incidental deletion or alteration.
Off-loading is a common process in information systems with limited audit
storage capacity. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records for
all account creations, modifications, disabling, and termination events.xccdf_mil.disa.stig_rule_SV-203774r991585_rule mediumCCI-000172
The operating system must generate audit records for all account creations, modifications, disabling, and termination events.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203774r991585_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records for
all kernel module load, unload, and restart actions, and also for all
program initiations.xccdf_mil.disa.stig_rule_SV-203775r991586_rule mediumCCI-000172
The operating system must generate audit records for all kernel module load, unload, and restart actions, and also for all program initiations.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203775r991586_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must uniquely identify peripherals
before establishing a connection.xccdf_mil.disa.stig_rule_SV-203647r958498_rule mediumCCI-000778
The operating system must uniquely identify peripherals before establishing a connection.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203647r958498_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000778 |
| Description | Without identifying devices, unidentified or
unknown devices may be introduced, thereby facilitating malicious activity.
Peripherals include, but are not limited to, such devices as flash drives,
external storage, and printers. |
| Rationale | Linux containers do not automatically inherit access to
underlying hardware such as USB and WiFi adapters on the hosts where they run.
If such connections are required, they must be explicitly configured during
container runtime. A host configured to meet STIG requirements will disable
unused USB connections and ensure WiFi interfaces are properly configured,
only enabling them when necessary for the service to operate.
For more information on inherited controls for containers see the DISA
Container Hardening Process Guide. |
The operating system must not alter original content or
time ordering of audit records when it provides a report generation
capability.xccdf_mil.disa.stig_rule_SV-203710r987795_rule mediumCCI-001882
The operating system must not alter original content or time ordering of audit records when it provides a report generation capability.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203710r987795_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001882 |
| Description | If the report generation capability alters the
content or time ordering of audit records, the integrity of the audit
records is compromised, and the records are no longer usable for forensic
analysis.
Time ordering refers to the chronological organization of records based on
time stamps. The degree of time stamp precision can affect this.
This requirement is specific to operating systems providing report
generation capabilities. The report generation capability can be met either
natively or through the use of third-party tools. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must, for networked systems,
compare internal information system clocks at least every 24 hours with a
server which is synchronized to one of the redundant United States Naval
Observatory (USNO) time servers, or a time server designated for the
appropriate DoD network (NIPRNet/SIPRNet), and/or the Global Positioning
System (GPS).xccdf_mil.disa.stig_rule_SV-203711r1038944_rule mediumCCI-004923
The operating system must, for networked systems, compare internal information system clocks at least every 24 hours with a server which is synchronized to one of the redundant United States Naval Observatory (USNO) time servers, or a time server designated for the appropriate DoD network (NIPRNet/SIPRNet), and/or the Global Positioning System (GPS).
| Rule ID | xccdf_mil.disa.stig_rule_SV-203711r1038944_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004923 |
| Description | Inaccurate time stamps make it more difficult to
correlate events and can lead to an inaccurate analysis. Determining the
correct time a particular event occurred on a system is critical when
conducting forensic analysis and investigating system events. Sources
outside the configured acceptable allowance (drift) may be inaccurate.
Synchronizing internal information system clocks provides uniformity of time
stamps for information systems with multiple system clocks and systems
connected over a network.
Organizations should consider endpoints that may not have regular access to
the authoritative time server (e.g., mobile, teleworking, and tactical
endpoints). |
| Rationale | Linux containers inherit the system time from the underlying host,
and do not operate a separate time service. Configuration of the host's time
service is responsible for generating the timestamp used by the host’s auditing
system, performing periodic synchronization, and ensuring that only authorized
time servers are used as the authoritative source. Time synchronization of the
host clock is automatically reflected in the time used by the container.
For more information on inherited controls for containers see the DISA
Container Hardening Process Guide. |
The operating system must synchronize internal
information system clocks to the authoritative time source when the time
difference is greater than one second.xccdf_mil.disa.stig_rule_SV-203712r982209_rule mediumCCI-004926
The operating system must synchronize internal information system clocks to the authoritative time source when the time difference is greater than one second.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203712r982209_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004926 |
| Description | Inaccurate time stamps make it more difficult to
correlate events and can lead to an inaccurate analysis. Determining the
correct time a particular event occurred on a system is critical when
conducting forensic analysis and investigating system events.
Synchronizing internal information system clocks provides uniformity of time
stamps for information systems with multiple system clocks and systems
connected over a network. Organizations should consider setting time periods
for different types of systems (e.g., financial, legal, or mission-critical
systems).
Organizations should also consider endpoints that may not have regular
access to the authoritative time server (e.g., mobile, teleworking, and
tactical endpoints). This requirement is related to the comparison done
every 24 hours in SRG-OS-000355 because a comparison must be done in order
to determine the time difference. |
| Rationale | Linux containers inherit the system time from the underlying host,
and do not operate a separate time service. Configuration of the host's time
service is responsible for generating the timestamp used by the host’s auditing
system, performing periodic synchronization, and ensuring that only authorized
time servers are used as the authoritative source. Time synchronization of the
host clock is automatically reflected in the time used by the container.
For more information on inherited controls for containers see the DISA
Container Hardening Process Guide. |
The operating system must record time stamps for audit
records that meet a minimum granularity of one second for a minimum degree
of precision.xccdf_mil.disa.stig_rule_SV-203713r958786_rule mediumCCI-001889
The operating system must record time stamps for audit records that meet a minimum granularity of one second for a minimum degree of precision.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203713r958786_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001889 |
| Description | Without sufficient granularity of time stamps, it
is not possible to adequately determine the chronological order of records.
Time stamps generated by the operating system include date and time.
Granularity of time measurements refers to the degree of synchronization
between information system clocks and reference clocks. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must enforce dual authorization
for movement and/or deletion of all audit information, when such movement or
deletion is not part of an authorized automatic process.xccdf_mil.disa.stig_rule_SV-203715r958790_rule mediumCCI-000366
The operating system must enforce dual authorization for movement and/or deletion of all audit information, when such movement or deletion is not part of an authorized automatic process.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203715r958790_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000366 |
| Description | An authorized user may intentionally or
accidentally move or delete audit records without those specific actions
being authorized.
All bulk manipulation of audit information must be authorized via automatic
processes. Any manual manipulation of audit information must require dual
authorization. Dual authorization mechanisms require the approval of two
authorized individuals to execute. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must notify designated personnel
if baseline configurations are changed in an unauthorized manner.xccdf_mil.disa.stig_rule_SV-203717r958794_rule mediumCCI-001744
The operating system must notify designated personnel if baseline configurations are changed in an unauthorized manner.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203717r958794_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001744 |
| Description | Unauthorized changes to the baseline
configuration could make the system vulnerable to various attacks or allow
unauthorized access to the operating system. Changes to operating system
configurations can have unintended side effects, some of which may be
relevant to security.
Detecting such changes and providing an automated response can help avoid
unintended, negative consequences that could ultimately affect the security
state of the operating system. The operating system's IMO/ISSO and SAs must
be notified via email and/or monitoring system trap when there is an
unauthorized modification of a configuration item. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must audit the enforcement actions
used to restrict access associated with changes to the system.xccdf_mil.disa.stig_rule_SV-203719r982211_rule mediumCCI-003938
The operating system must audit the enforcement actions used to restrict access associated with changes to the system.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203719r982211_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-003938 |
| Description | Without auditing the enforcement of access
restrictions against changes to the application configuration, it will be
difficult to identify attempted attacks and an audit trail will not be
available for forensic investigation for after-the-fact actions.
Enforcement actions are the methods or mechanisms used to prevent
unauthorized changes to configuration settings. Enforcement action methods
may be as simple as denying access to a file based on the application of
file permissions (access restriction). Audit items may consist of lists of
actions blocked by access restrictions or changes identified after the fact. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The audit system must be configured to audit the
loading and unloading of dynamic kernel modules.xccdf_mil.disa.stig_rule_SV-203769r991580_rule mediumCCI-000172
The audit system must be configured to audit the loading and unloading of dynamic kernel modules.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203769r991580_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records for
privileged activities or other system-level access.xccdf_mil.disa.stig_rule_SV-203768r991579_rule mediumCCI-000172
The operating system must generate audit records for privileged activities or other system-level access.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203768r991579_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records when
successful/unsuccessful attempts to delete security levels occur.xccdf_mil.disa.stig_rule_SV-203765r991576_rule mediumCCI-000172
The operating system must generate audit records when successful/unsuccessful attempts to delete security levels occur.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203765r991576_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records when
successful/unsuccessful attempts to delete privileges occur.xccdf_mil.disa.stig_rule_SV-203764r991575_rule mediumCCI-000172
The operating system must generate audit records when successful/unsuccessful attempts to delete privileges occur.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203764r991575_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records when
successful/unsuccessful logon attempts occur.xccdf_mil.disa.stig_rule_SV-203767r991578_rule mediumCCI-000172
The operating system must generate audit records when successful/unsuccessful logon attempts occur.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203767r991578_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records when
successful/unsuccessful attempts to delete security objects occur.xccdf_mil.disa.stig_rule_SV-203766r991577_rule mediumCCI-000172
The operating system must generate audit records when successful/unsuccessful attempts to delete security objects occur.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203766r991577_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records when
successful/unsuccessful attempts to modify privileges occur.xccdf_mil.disa.stig_rule_SV-203761r991572_rule mediumCCI-000172
The operating system must generate audit records when successful/unsuccessful attempts to modify privileges occur.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203761r991572_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records when
successful/unsuccessful attempts to access categories of information (e.g.,
classification levels) occur.xccdf_mil.disa.stig_rule_SV-203760r991571_rule mediumCCI-000172
The operating system must generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203760r991571_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records when
successful/unsuccessful attempts to modify categories of information (e.g.,
classification levels) occur.xccdf_mil.disa.stig_rule_SV-203763r991574_rule mediumCCI-000172
The operating system must generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203763r991574_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must generate audit records when
successful/unsuccessful attempts to modify security objects occur.xccdf_mil.disa.stig_rule_SV-203762r991573_rule mediumCCI-000172
The operating system must generate audit records when successful/unsuccessful attempts to modify security objects occur.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203762r991573_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must not alter original content or
time ordering of audit records when it provides an audit reduction
capability.xccdf_mil.disa.stig_rule_SV-203709r958776_rule mediumCCI-001881
The operating system must not alter original content or time ordering of audit records when it provides an audit reduction capability.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203709r958776_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001881 |
| Description | If the audit reduction capability alters the
content or time ordering of audit records, the integrity of the audit
records is compromised, and the records are no longer usable for forensic
analysis.
Audit reduction is a process that manipulates collected audit information
and organizes such information in a summary format that is more meaningful
to analysts. Time ordering refers to the chronological organization of
records based on time stamps. The degree of time stamp precision can affect
this.
This requirement is specific to operating systems providing audit reduction
capabilities. The audit reduction capability can be met either natively or
through the use of third-party tools. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must provide an immediate
real-time alert to the SA and ISSO, at a minimum, of all audit failure
events requiring real-time alerts.xccdf_mil.disa.stig_rule_SV-203703r958758_rule mediumCCI-001858
The operating system must provide an immediate real-time alert to the SA and ISSO, at a minimum, of all audit failure events requiring real-time alerts.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203703r958758_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001858 |
| Description | It is critical for the appropriate personnel to
be aware if a system is at risk of failing to process audit logs as
required. Without a real-time alert, security personnel may be unaware of an
impending failure of the audit capability and system operation may be
adversely affected.
Alerts provide organizations with urgent messages. Real-time alerts provide
these messages immediately (i.e., the time from event detection to alert
occurs in seconds or less). |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must prohibit the use or
connection of
unauthorized hardware
components.xccdf_mil.disa.stig_rule_SV-263651r982555_rule mediumCCI-003959
The operating system must prohibit the use or connection of unauthorized hardware components.
| Rule ID | xccdf_mil.disa.stig_rule_SV-263651r982555_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-003959 |
| Description | Hardware components provide the foundation for
organizational systems and the platform for the execution of authorized
software programs. Managing the inventory of hardware components and
controlling which hardware components are permitted to be installed or
connected to organizational systems is essential to provide adequate
security. |
| Rationale | Linux containers do not automatically inherit access to
underlying hardware such as USB and WiFi adapters on the hosts where they run.
If such connections are required, they must be explicitly configured during
container runtime. A host configured to meet STIG requirements will disable
unused USB connections and ensure WiFi interfaces are properly configured,
only enabling them when necessary for the service to operate.
For more information on inherited controls for containers see the DISA
Container Hardening Process Guide. |
The operating system must, for password-based
authentication, verify when users create or update passwords the
passwords are not found on the list of commonly-used, expected, or
compromised passwords in IA-5 (1) (a).xccdf_mil.disa.stig_rule_SV-263653r982229_rule mediumCCI-004061
The operating system must, for password-based authentication, verify when users create or update passwords the passwords are not found on the list of commonly-used, expected, or compromised passwords in IA-5 (1) (a).
| Rule ID | xccdf_mil.disa.stig_rule_SV-263653r982229_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004061 |
| Description | Password-based authentication applies
to passwords regardless of whether they are used in single-factor or
multifactor authentication. Long passwords or passphrases are preferable
over shorter passwords. Enforced composition rules provide marginal
security benefits while decreasing usability. However, organizations may
choose to establish certain rules for password generation (e.g., minimum
character length for long passwords) under certain circumstances and can
enforce this requirement in IA-5(1)(h). Account recovery can occur, for
example, in situations when a password is forgotten. Cryptographically
protected passwords include salted one-way cryptographic hashes
of passwords. The list of commonly used, compromised, or expected
passwords includes passwords obtained from previous breach corpuses,
dictionary words, and repetitive or sequential characters. The list
includes context-specific words, such as the name of the service,
username, and derivatives thereof. |
| Rationale | These container images ship with no local user accounts apart from a locked
root account. Any access to the workload, interactive or programmatic, is
mediated by the container-orchestration platform, which applies its own
credential-hygiene and MFA policies. The operating system inside the
container never receives, retains, or checks passwords, and no password
store exists on which to enforce compromised-password screening, mandatory
changes after recovery, passphrase-length requirements, or
password-generation helpers. For more information on inherited controls for
containers see the DISA Container Hardening Process Guide. |
The operating system must for password-based
authentication, require immediate selection of a new password upon
account recovery.xccdf_mil.disa.stig_rule_SV-263654r982232_rule mediumCCI-004063
The operating system must for password-based authentication, require immediate selection of a new password upon account recovery.
| Rule ID | xccdf_mil.disa.stig_rule_SV-263654r982232_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004063 |
| Description | Password-based authentication applies
to passwords regardless of whether they are used in single-factor or
multifactor authentication. Long passwords or passphrases are preferable
over shorter passwords. Enforced composition rules provide marginal
security benefits while decreasing usability. However, organizations may
choose to establish certain rules for password generation (e.g., minimum
character length for long passwords) under certain circumstances and can
enforce this requirement in IA-5(1)(h). Account recovery can occur, for
example, in situations when a password is forgotten. Cryptographically
protected passwords include salted one-way cryptographic hashes
of passwords. The list of commonly used, compromised, or expected
passwords includes passwords obtained from previous breach corpuses,
dictionary words, and repetitive or sequential characters. The list
includes context-specific words, such as the name of the service,
username, and derivatives thereof. |
| Rationale | These container images ship with no local user accounts apart from a locked
root account. Any access to the workload, interactive or programmatic, is
mediated by the container-orchestration platform, which applies its own
credential-hygiene and MFA policies. The operating system inside the
container never receives, retains, or checks passwords, and no password
store exists on which to enforce compromised-password screening, mandatory
changes after recovery, passphrase-length requirements, or
password-generation helpers. For more information on inherited controls for
containers see the DISA Container Hardening Process Guide. |
The operating system must for password-based
authentication, allow user selection of long passwords and passphrases,
including spaces and all printable characters.xccdf_mil.disa.stig_rule_SV-263655r982235_rule mediumCCI-004064
The operating system must for password-based authentication, allow user selection of long passwords and passphrases, including spaces and all printable characters.
| Rule ID | xccdf_mil.disa.stig_rule_SV-263655r982235_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004064 |
| Description | Password-based authentication applies
to passwords regardless of whether they are used in single-factor or
multifactor authentication. Long passwords or passphrases are preferable
over shorter passwords. Enforced composition rules provide marginal
security benefits while decreasing usability. However, organizations may
choose to establish certain rules for password generation (e.g., minimum
character length for long passwords) under certain circumstances and can
enforce this requirement in IA-5(1)(h). Account recovery can occur, for
example, in situations when a password is forgotten. Cryptographically
protected passwords include salted one-way cryptographic hashes
of passwords. The list of commonly used, compromised, or expected
passwords includes passwords obtained from previous breach corpuses,
dictionary words, and repetitive or sequential characters. The list
includes context-specific words, such as the name of the service,
username, and derivatives thereof. |
| Rationale | These container images ship with no local user accounts apart from a locked
root account. Any access to the workload, interactive or programmatic, is
mediated by the container-orchestration platform, which applies its own
credential-hygiene and MFA policies. The operating system inside the
container never receives, retains, or checks passwords, and no password
store exists on which to enforce compromised-password screening, mandatory
changes after recovery, passphrase-length requirements, or
password-generation helpers. For more information on inherited controls for
containers see the DISA Container Hardening Process Guide. |
The operating system must, for password-based
authentication, employ automated tools to assist the user in selecting
strong password authenticators.xccdf_mil.disa.stig_rule_SV-263656r982238_rule mediumCCI-004065
The operating system must, for password-based authentication, employ automated tools to assist the user in selecting strong password authenticators.
| Rule ID | xccdf_mil.disa.stig_rule_SV-263656r982238_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004065 |
| Description | Password-based authentication applies
to passwords regardless of whether they are used in single-factor or
multifactor authentication. Long passwords or passphrases are preferable
over shorter passwords. Enforced composition rules provide marginal
security benefits while decreasing usability. However, organizations may
choose to establish certain rules for password generation (e.g., minimum
character length for long passwords) under certain circumstances and can
enforce this requirement in IA-5(1)(h). Account recovery can occur, for
example, in situations when a password is forgotten. Cryptographically
protected passwords include salted one-way cryptographic hashes
of passwords. The list of commonly used, compromised, or expected
passwords includes passwords obtained from previous breach corpuses,
dictionary words, and repetitive or sequential characters. The list
includes context-specific words, such as the name of the service,
username, and derivatives thereof. |
| Rationale | These container images ship with no local user accounts apart from a locked
root account. Any access to the workload, interactive or programmatic, is
mediated by the container-orchestration platform, which applies its own
credential-hygiene and MFA policies. The operating system inside the
container never receives, retains, or checks passwords, and no password
store exists on which to enforce compromised-password screening, mandatory
changes after recovery, passphrase-length requirements, or
password-generation helpers. For more information on inherited controls for
containers see the DISA Container Hardening Process Guide. |
The operating system must accept only external
credentials that are NIST-compliantxccdf_mil.disa.stig_rule_SV-263657r982559_rule mediumCCI-004083
The operating system must accept only external credentials that are NIST-compliant
| Rule ID | xccdf_mil.disa.stig_rule_SV-263657r982559_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004083 |
| Description | Acceptance of only NIST-compliant external
authenticators applies to organizational systems that are accessible
to the public (e.g., public-facing websites). External authenticators
are issued by nonfederal government entities and are compliant with [SP
800-63B]. Approved external authenticators meet or exceed the minimum
federal government-wide technical, security, privacy, and organizational
maturity requirements. Meeting or exceeding federal requirements allows
federal government relying parties to trust external authenticators in
connection with an authentication transaction at a specified authenticator
assurance level. |
| Rationale | Linux containers depend on the host operating system to provide and enforce
authentication, including the validation of external credentials. Because
user authentication and identity management are delegated to the host, it is
the host operating system that bears ultimate responsibility for accepting
only NIST-compliant external authenticators. For more information on
inherited controls for containers see the DISA Container Hardening Process
Guide. |
The operating system must monitor the use of
maintenance tools that execute with increased privilegexccdf_mil.disa.stig_rule_SV-263658r982561_rule mediumCCI-004188
The operating system must monitor the use of maintenance tools that execute with increased privilege
| Rule ID | xccdf_mil.disa.stig_rule_SV-263658r982561_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004188 |
| Description | Maintenance tools that execute with
increased system privilege can result in unauthorized access to
organizational information and assets that would otherwise be
inaccessible. |
| Rationale | Auditing in Linux containers is essential for monitoring
security events, tracking user activities, and ensuring regulatory
compliance. Since containers share the host’s kernel, traditional
auditing mechanisms, such as the Linux Auditing System (auditd),
operate at the host level rather than within individual containers.
An auditing program captures events and runtime information such as
process execution, system calls, file access, user authentication
events, network activity, and other security-related events.
Container activity logs are written to the host's audit log files
and are restricted access. Log collection and forwarding must be
configured for incident response, reporting, and compliance purposes.
Properly configured, the logs must be collected from the host to
ensure storage capacity is sufficient, and they must be actively
monitored and managed with associated alerts. Configuration of the
audit log process is managed on the host where the containers are
running.
For more information on inherited controls for containers see the
DISA Container Hardening Process Guide. |
The operating system must provide protected
storage for cryptographic keys with organization-defined safeguards
and/or hardware protected key store.xccdf_mil.disa.stig_rule_SV-263660r982565_rule mediumCCI-004910
The operating system must provide protected storage for cryptographic keys with organization-defined safeguards and/or hardware protected key store.
| Rule ID | xccdf_mil.disa.stig_rule_SV-263660r982565_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004910 |
| Description | A Trusted Platform Module (TPM) is an
example of a hardware-protected data store that can be used to protect
cryptographic keys. |
| Rationale | Linux containers store configuration and data files on the host
filesystem. As such, the host filesystem is responsible for the size, capacity,
and utilization of the physical disks used by the containers running on that host.
To protect data at rest inside containers from unauthorized access or modification,
security measures must be implemented at the host operating system level, such as
using encrypted virtual filesystems.
For more information on inherited controls for containers see the DISA Container
Hardening Process Guide. |
The operating system must synchronize system clocks
within and between systems or system components.xccdf_mil.disa.stig_rule_SV-263661r982567_rule mediumCCI-004922
The operating system must synchronize system clocks within and between systems or system components.
| Rule ID | xccdf_mil.disa.stig_rule_SV-263661r982567_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004922 |
| Description | Time synchronization of system clocks is
essential for the correct execution of many system services, including
identification and authentication processes that involve certificates
and time-of-day restrictions as part of access control. Denial of
service or failure to deny expired credentials may result without
properly synchronized clocks within and between systems and system
components. Time is commonly expressed in Coordinated Universal Time
(UTC), a modern continuation of Greenwich Mean Time (GMT), or local time
with an offset from UTC. The granularity of time measurements refers
to the degree of synchronization between system clocks and reference
clocks, such as clocks synchronizing within hundreds of milliseconds
or tens of milliseconds. Organizations may define different time
granularities for system components. Time service can be critical to
other security capabilities—such as access control and identification
and authentication—depending on the nature of the mechanisms used to
support the capabilities. |
| Rationale | Linux containers inherit the system time from the underlying host,
and do not operate a separate time service. Configuration of the host's time
service is responsible for generating the timestamp used by the host’s auditing
system, performing periodic synchronization, and ensuring that only authorized
time servers are used as the authoritative source. Time synchronization of the
host clock is automatically reflected in the time used by the container.
For more information on inherited controls for containers see the DISA
Container Hardening Process Guide. |
The operating system must install security-relevant
software updates within the time period directed by an authoritative
source (e.g., IAVM, CTOs, DTMs, and STIGs).xccdf_mil.disa.stig_rule_SV-259333r958940_rule mediumCCI-002605
The operating system must install security-relevant software updates within the time period directed by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).
| Rule ID | xccdf_mil.disa.stig_rule_SV-259333r958940_rule |
| Result | notapplicable |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002605 |
| Description | Security flaws with operating
systems are discovered daily. Vendors are constantly updating
and patching their products to address newly discovered security
vulnerabilities. Organizations (including any contractor to the
organization) are required to promptly install security-relevant software
updates (e.g., patches, service packs, and hot fixes). Flaws discovered
during security assessments, continuous monitoring, incident response
activities, or information system error handling must also be addressed
expeditiously. |
| Rationale | Minimus images are extremely minimal, equipped with only the essential software
required for a container to perform its intended purpose. All components deemed to be non-essential
have been removed, including shell environments, executables, package managers, software installers,
and process-launching tools. Furthermore, Minimus containers restrict the installation of additional
packages on the image before or during runtime, to help protect against unauthorized modification.
The host operating system environment is further protected against unauthorized modification by
standard Linux container isolation mechanisms including the Linux Namespace and cgroup subsystems.
Together, these help to protect the host system against potential malicious activity from the
containers running on it.
For more information on inherited controls for containers see the DISA ContainerHardening Process
Guide. |
The operating system must implement NSA-approved
cryptography to protect classified information in accordance with applicable
federal laws, Executive Orders, directives, policies, regulations, and
standards.xccdf_mil.disa.stig_rule_SV-203739r987791_rule highCCI-002450
The operating system must implement NSA-approved cryptography to protect classified information in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203739r987791_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.OpenSsl:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-002450 |
| Description | Use of weak or untested encryption algorithms
undermines the purposes of utilizing encryption to protect data. The
operating system must implement cryptographic modules adhering to the higher
standards approved by the federal government since this provides assurance
they have been tested and validated.
Script Verification:
To manually verify, ensure that fipsmodule.cnf and openssl.cnf exist in
the /etc/ssl folder. Also verify that openssl-fips-config and
minimus-cryptographic-module exist in the file /lib/apk/db/installed.
|
OVAL test results details
OpenSSL FIPS module configuration file exists oval:org.OpenSsl:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| not evaluated | /etc/ssl/fipsmodule.cnf | regular | 0 | 0 | 214 | rw-r--r-- |
OpenSSL configuration file exists oval:org.OpenSsl:tst:2 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| not evaluated | /etc/ssl/openssl.cnf | regular | 0 | 0 | 1001 | rw-r--r-- |
openssl-fips-config package is installed oval:org.OpenSsl:tst:3 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /lib/apk/db/installed | P:openssl-fips-config |
minimus-cryptographic-module package is installed oval:org.OpenSsl:tst:4 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /lib/apk/db/installed | P:minimus-cryptographic-module |
The operating system must implement NIST FIPS-validated
cryptography for the following: to provision digital signatures, to generate
cryptographic hashes, and to protect unclassified information requiring
confidentiality and cryptographic protection in accordance with applicable
federal laws, Executive Orders, directives, policies, regulations, and
standards.xccdf_mil.disa.stig_rule_SV-203776r959006_rule highCCI-002450
The operating system must implement NIST FIPS-validated cryptography for the following: to provision digital signatures, to generate cryptographic hashes, and to protect unclassified information requiring confidentiality and cryptographic protection in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203776r959006_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.OpenSsl:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-002450 |
| Description | Use of weak or untested encryption algorithms
undermines the purposes of utilizing encryption to protect data. The
operating system must implement cryptographic modules adhering to the higher
standards approved by the federal government since this provides assurance
they have been tested and validated.
Script Verification:
To manually verify, ensure that fipsmodule.cnf and openssl.cnf exist in
the /etc/ssl folder. Also verify that openssl-fips-config and
minimus-cryptographic-module exist in the file /lib/apk/db/installed.
|
OVAL test results details
OpenSSL FIPS module configuration file exists oval:org.OpenSsl:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| not evaluated | /etc/ssl/fipsmodule.cnf | regular | 0 | 0 | 214 | rw-r--r-- |
OpenSSL configuration file exists oval:org.OpenSsl:tst:2 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| not evaluated | /etc/ssl/openssl.cnf | regular | 0 | 0 | 1001 | rw-r--r-- |
openssl-fips-config package is installed oval:org.OpenSsl:tst:3 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /lib/apk/db/installed | P:openssl-fips-config |
minimus-cryptographic-module package is installed oval:org.OpenSsl:tst:4 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /lib/apk/db/installed | P:minimus-cryptographic-module |
The operating system must maintain the confidentiality
and integrity of information during preparation for transmission.xccdf_mil.disa.stig_rule_SV-203750r958912_rule mediumCCI-002420
The operating system must maintain the confidentiality and integrity of information during preparation for transmission.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203750r958912_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.OpenSsl:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002420 |
| Description | Information can be either unintentionally or
maliciously disclosed or modified during preparation for transmission, for
example, during aggregation, at protocol transformation points, and during
packing/unpacking. These unauthorized disclosures or modifications
compromise the confidentiality or integrity of the information.
Ensuring the confidentiality of transmitted information requires the
operating system to take measures in preparing information for transmission.
This can be accomplished via access control and encryption.
Use of this requirement will be limited to situations where the data owner
has a strict requirement for ensuring data integrity and confidentiality is
maintained at every step of the data transfer and handling process. When
transmitting data, operating systems need to support transmission protection
mechanisms such as TLS, SSL VPNs, or IPSec.
Script Verification:
To manually verify, ensure that fipsmodule.cnf and openssl.cnf exist in
the /etc/ssl folder. Also verify that openssl-fips-config and
minimus-cryptographic-module exist in the file /lib/apk/db/installed.
|
OVAL test results details
OpenSSL FIPS module configuration file exists oval:org.OpenSsl:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| not evaluated | /etc/ssl/fipsmodule.cnf | regular | 0 | 0 | 214 | rw-r--r-- |
OpenSSL configuration file exists oval:org.OpenSsl:tst:2 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| not evaluated | /etc/ssl/openssl.cnf | regular | 0 | 0 | 1001 | rw-r--r-- |
openssl-fips-config package is installed oval:org.OpenSsl:tst:3 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /lib/apk/db/installed | P:openssl-fips-config |
minimus-cryptographic-module package is installed oval:org.OpenSsl:tst:4 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /lib/apk/db/installed | P:minimus-cryptographic-module |
The operating system must maintain the confidentiality
and integrity of information during reception.xccdf_mil.disa.stig_rule_SV-203751r958914_rule mediumCCI-002422
The operating system must maintain the confidentiality and integrity of information during reception.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203751r958914_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.OpenSsl:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002422 |
| Description | Information can be either unintentionally or
maliciously disclosed or modified during reception, including, for example,
during aggregation, at protocol transformation points, and during
packing/unpacking. These unauthorized disclosures or modifications
compromise the confidentiality or integrity of the information.
Ensuring the confidentiality of transmitted information requires the
operating system to take measures in preparing information for transmission.
This can be accomplished via access control and encryption.
Use of this requirement will be limited to situations where the data owner
has a strict requirement for ensuring data integrity and confidentiality is
maintained at every step of the data transfer and handling process. When
receiving data, operating systems need to leverage protection mechanisms
such as TLS, SSL VPNs, or IPSec.
Script Verification:
To manually verify, ensure that fipsmodule.cnf and openssl.cnf exist in
the /etc/ssl folder. Also verify that openssl-fips-config and
minimus-cryptographic-module exist in the file /lib/apk/db/installed.
|
OVAL test results details
OpenSSL FIPS module configuration file exists oval:org.OpenSsl:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| not evaluated | /etc/ssl/fipsmodule.cnf | regular | 0 | 0 | 214 | rw-r--r-- |
OpenSSL configuration file exists oval:org.OpenSsl:tst:2 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| not evaluated | /etc/ssl/openssl.cnf | regular | 0 | 0 | 1001 | rw-r--r-- |
openssl-fips-config package is installed oval:org.OpenSsl:tst:3 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /lib/apk/db/installed | P:openssl-fips-config |
minimus-cryptographic-module package is installed oval:org.OpenSsl:tst:4 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /lib/apk/db/installed | P:minimus-cryptographic-module |
The operating system must use mechanisms meeting the
requirements of applicable federal laws, Executive orders, directives,
policies, regulations, standards, and guidance for authentication to a
cryptographic module.xccdf_mil.disa.stig_rule_SV-203649r971535_rule mediumCCI-000803
The operating system must use mechanisms meeting the requirements of applicable federal laws, Executive orders, directives, policies, regulations, standards, and guidance for authentication to a cryptographic module.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203649r971535_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.OpenSsl:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000803 |
| Description | Unapproved mechanisms that are used for
authentication to the cryptographic module are not verified and therefore
cannot be relied upon to provide confidentiality or integrity, and DoD data
may be compromised.
Operating systems utilizing encryption are required to use FIPS-compliant
mechanisms for authenticating to cryptographic modules.
FIPS 140-2/140-3 is the current standard for validating that mechanisms used
to access cryptographic modules utilize authentication that meets DoD
requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a
general purpose computing system.
Script Verification:
To manually verify, ensure that fipsmodule.cnf and openssl.cnf exist in
the /etc/ssl folder. Also verify that openssl-fips-config and
minimus-cryptographic-module exist in the file /lib/apk/db/installed.
|
OVAL test results details
OpenSSL FIPS module configuration file exists oval:org.OpenSsl:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| not evaluated | /etc/ssl/fipsmodule.cnf | regular | 0 | 0 | 214 | rw-r--r-- |
OpenSSL configuration file exists oval:org.OpenSsl:tst:2 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| not evaluated | /etc/ssl/openssl.cnf | regular | 0 | 0 | 1001 | rw-r--r-- |
openssl-fips-config package is installed oval:org.OpenSsl:tst:3 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /lib/apk/db/installed | P:openssl-fips-config |
minimus-cryptographic-module package is installed oval:org.OpenSsl:tst:4 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /lib/apk/db/installed | P:minimus-cryptographic-module |
The operating system must implement cryptographic
mechanisms to protect the integrity of nonlocal maintenance and diagnostic
communications, when used for nonlocal maintenance sessions.xccdf_mil.disa.stig_rule_SV-203736r958848_rule highCCI-002890
The operating system must implement cryptographic mechanisms to protect the integrity of nonlocal maintenance and diagnostic communications, when used for nonlocal maintenance sessions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203736r958848_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-002890 |
| Description | Privileged access contains control and
configuration information and is particularly sensitive, so additional
protections are necessary. This is maintained by using cryptographic
mechanisms, such as a hash function or digital signature, to protect
integrity.
Nonlocal maintenance and diagnostic activities are those activities
conducted by individuals communicating through a network, either an external
network (e.g., the Internet) or an internal network. Local maintenance and
diagnostic activities are those activities carried out by individuals
physically present at the information system or information system component
and not communicating across a network connection.
The operating system can meet this requirement through leveraging a
cryptographic module. This requirement does not cover hardware/software
components that may support information system maintenance, yet are a part
of the system (e.g., the software implementing "ping," "ls," "ipconfig," or
the hardware and software implementing the monitoring port of an Ethernet
switch).
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must implement cryptographic
mechanisms to protect the confidentiality of nonlocal maintenance and
diagnostic communications, when used for nonlocal maintenance sessions.xccdf_mil.disa.stig_rule_SV-203737r958850_rule highCCI-003123
The operating system must implement cryptographic mechanisms to protect the confidentiality of nonlocal maintenance and diagnostic communications, when used for nonlocal maintenance sessions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203737r958850_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-003123 |
| Description | Privileged access contains control and
configuration information and is particularly sensitive, so additional
protections are necessary. This is maintained by using cryptographic
mechanisms such as encryption to protect confidentiality.
Nonlocal maintenance and diagnostic activities are those activities
conducted by individuals communicating through a network, either an external
network (e.g., the Internet) or an internal network. Local maintenance and
diagnostic activities are those activities carried out by individuals
physically present at the information system or information system component
and not communicating across a network connection.
This requirement applies to hardware/software diagnostic test equipment or
tools. This requirement does not cover hardware/software components that may
support information system maintenance, yet are a part of the system (e.g.,
the software implementing "ping," "ls," "ipconfig," or the hardware and
software implementing the monitoring port of an Ethernet switch).
The operating system can meet this requirement through leveraging a
cryptographic module.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must employ strong authenticators
in the establishment of nonlocal maintenance and diagnostic sessions.xccdf_mil.disa.stig_rule_SV-203653r958510_rule highCCI-000877
The operating system must employ strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203653r958510_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-000877 |
| Description | If maintenance tools are used by unauthorized
personnel, they may accidentally or intentionally damage or compromise the
system. The act of managing systems and applications includes the ability to
access sensitive application information, such as system configuration
details, diagnostic information, user information, and potentially sensitive
application data.
Some maintenance and test tools are either standalone devices with their own
operating systems or are applications bundled with an operating system.
Nonlocal maintenance and diagnostic activities are those activities
conducted by individuals communicating through a network, either an external
network (e.g., the Internet) or an internal network. Local maintenance and
diagnostic activities are those activities carried out by individuals
physically present at the information system or information system component
and not communicating across a network connection. Typically, strong
authentication requires authenticators that are resistant to replay attacks
and employ multifactor authentication. Strong authenticators include, for
example, PKI where certificates are stored on a token protected by a
password, passphrase, or biometric.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must implement DoD-approved
encryption to protect the confidentiality of remote access sessions.xccdf_mil.disa.stig_rule_SV-203603r958408_rule highCCI-000068
The operating system must implement DoD-approved encryption to protect the confidentiality of remote access sessions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203603r958408_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-000068 |
| Description | Without confidentiality protection mechanisms,
unauthorized individuals may gain access to sensitive information via a
remote access session.
Remote access is access to DoD nonpublic information systems by an
authorized user (or an information system) communicating through an
external, non-organization-controlled network. Remote access methods
include, for example, dial-up, broadband, and wireless.
Encryption provides a means to secure the remote connection to prevent
unauthorized access to the data traversing the remote access connection
(e.g., RDP), thereby providing a degree of confidentiality. The encryption
strength of a mechanism is selected based on the security categorization of
the information.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must implement cryptography to
protect the integrity of remote access sessions.xccdf_mil.disa.stig_rule_SV-203669r991554_rule highCCI-001453
The operating system must implement cryptography to protect the integrity of remote access sessions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203669r991554_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-001453 |
| Description | Without cryptographic integrity protections,
information can be altered by unauthorized users without detection.
Remote access (e.g., RDP) is access to DoD nonpublic information systems by
an authorized user (or an information system) communicating through an
external, non-organization-controlled network. Remote access methods
include, for example, dial-up, broadband, and wireless.
Cryptographic mechanisms used for protecting the integrity of information
include, for example, signed hash functions using asymmetric cryptography
enabling distribution of the public key to verify the hash information while
maintaining the confidentiality of the secret key used to generate the hash.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must not allow an unattended or
automatic logon to the system.xccdf_mil.disa.stig_rule_SV-203782r991591_rule highCCI-000366
The operating system must not allow an unattended or automatic logon to the system.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203782r991591_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-000366 |
| Description | Failure to restrict system access to
authenticated users negatively impacts operating system security.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must limit the number of
concurrent sessions to ten for all accounts and/or account types.xccdf_mil.disa.stig_rule_SV-203597r958398_rule lowCCI-000054
The operating system must limit the number of concurrent sessions to ten for all accounts and/or account types.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203597r958398_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | low |
| Identifiers: | CCI-000054 |
| Description | Operating system management includes the ability
to control the number of users and user sessions that utilize an operating
system. Limiting the number of allowed users and sessions per user is
helpful in reducing the risks related to DoS attacks.
This requirement addresses concurrent sessions for information system
accounts and does not address concurrent sessions by single users via
multiple system accounts. The maximum number of concurrent sessions should
be defined based upon mission needs and the operational environment for each
system.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must enforce access restrictions.xccdf_mil.disa.stig_rule_SV-203718r958796_rule mediumCCI-001813
The operating system must enforce access restrictions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203718r958796_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001813 |
| Description | Failure to provide logical access restrictions
associated with changes to system configuration may have significant effects
on the overall security of the system.
When dealing with access restrictions pertaining to change control, it
should be noted that any changes to the hardware, software, and/or firmware
components of the operating system can have significant effects on the
overall security of the system.
Accordingly, only qualified and authorized individuals should be allowed to
obtain access to operating system components for the purposes of initiating
changes, including upgrades and modifications.
Logical access restrictions include, for example, controls that restrict
access to workflow automation, media libraries, abstract layers (e.g.,
changes implemented into third-party interfaces rather than directly into
information systems), and change windows (e.g., changes occur only during
specified times, making unauthorized changes easy to discover).
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must verify remote disconnection
at the termination of nonlocal maintenance and diagnostic sessions, when
used for nonlocal maintenance sessions.xccdf_mil.disa.stig_rule_SV-203738r958852_rule mediumCCI-002891
The operating system must verify remote disconnection at the termination of nonlocal maintenance and diagnostic sessions, when used for nonlocal maintenance sessions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203738r958852_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002891 |
| Description | If the remote connection is not closed and
verified as closed, the session may remain open and be exploited by an
attacker; this is referred to as a zombie session. Remote connections must
be disconnected and verified as disconnected when nonlocal maintenance
sessions have been terminated and are no longer available for use.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system, for PKI-based authentication,
must implement a local cache of revocation data to support path discovery
and validation in case of the inability to access revocation information via
the network.xccdf_mil.disa.stig_rule_SV-203734r982217_rule mediumCCI-004068
The operating system, for PKI-based authentication, must implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203734r982217_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004068 |
| Description | Without configuring a local cache of revocation
data, there is the potential to allow access to users who are no longer
authorized (users with revoked certificates).
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must audit all activities
performed during nonlocal maintenance and diagnostic sessions.xccdf_mil.disa.stig_rule_SV-203735r958846_rule mediumCCI-002884
The operating system must audit all activities performed during nonlocal maintenance and diagnostic sessions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203735r958846_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002884 |
| Description | If events associated with nonlocal administrative
access or diagnostic sessions are not logged, a major tool for assessing and
investigating attacks would not be available.
This requirement addresses auditing-related issues associated with
maintenance tools used specifically for diagnostic and repair actions on
organizational information systems.
Nonlocal maintenance and diagnostic activities are those activities
conducted by individuals communicating through a network, either an external
network (e.g., the Internet) or an internal network. Local maintenance and
diagnostic activities are those activities carried out by individuals
physically present at the information system or information system component
and not communicating across a network connection.
This requirement applies to hardware/software diagnostic test equipment or
tools. This requirement does not cover hardware/software components that may
support information system maintenance, yet are a part of the system, for
example, the software implementing "ping," "ls," "ipconfig," or the hardware
and software implementing the monitoring port of an Ethernet switch.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must terminate all network
connections associated with a communications session at the end of the
session, or as follows: for in-band management sessions (privileged
sessions), the session must be terminated after 10 minutes of inactivity;
and for user sessions (non-privileged session), the session must be
terminated after 15 minutes of inactivity, except to fulfill documented and
validated mission requirements.xccdf_mil.disa.stig_rule_SV-203659r970703_rule mediumCCI-001133
The operating system must terminate all network connections associated with a communications session at the end of the session, or as follows: for in-band management sessions (privileged sessions), the session must be terminated after 10 minutes of inactivity; and for user sessions (non-privileged session), the session must be terminated after 15 minutes of inactivity, except to fulfill documented and validated mission requirements.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203659r970703_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001133 |
| Description | Terminating an idle session within a short time
period reduces the window of opportunity for unauthorized personnel to take
control of a management session enabled on the console or console port that
has been left unattended. In addition, quickly terminating an idle session
will also free up resources committed by the managed network element.
Terminating network connections associated with communications sessions
includes, for example, de-allocating associated TCP/IP address/port pairs at
the operating system level, and de-allocating networking assignments at the
application level if multiple application sessions are using a single
operating system-level network connection. This does not mean that the
operating system terminates all sessions or network access; it only ends the
inactive session and releases the resources associated with that session.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must require users to
re-authenticate for privilege escalation.xccdf_mil.disa.stig_rule_SV-203723r1050789_rule mediumCCI-002038
The operating system must require users to re-authenticate for privilege escalation.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203723r1050789_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002038 |
| Description | Without re-authentication, users may access
resources or perform tasks for which they do not have authorization.
When operating systems provide the capability to escalate a functional
capability, it is critical the user re-authenticate.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must implement multifactor
authentication for remote access to privileged accounts in such a way that
one of the factors is provided by a device separate from the system gaining
access.xccdf_mil.disa.stig_rule_SV-203727r982216_rule mediumCCI-004046
The operating system must implement multifactor authentication for remote access to privileged accounts in such a way that one of the factors is provided by a device separate from the system gaining access.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203727r982216_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004046 |
| Description | Using an authentication device, such as a CAC or
token that is separate from the information system, ensures that even if the
information system is compromised, that compromise will not affect
credentials stored on the authentication device.
Multifactor solutions that require devices separate from information systems
gaining access include, for example, hardware tokens providing time-based or
challenge-response authenticators and smart cards such as the U.S.
Government Personal Identity Verification card and the DoD Common Access
Card.
A privileged account is defined as an information system account with
authorizations of a privileged user.
Remote access is access to DoD nonpublic information systems by an
authorized user (or an information system) communicating through an
external, non-organization-controlled network. Remote access methods
include, for example, dial-up, broadband, and wireless.
This requirement only applies to components where this is specific to the
function of the device or has the concept of an organizational user (e.g.,
VPN, proxy capability). This does not apply to authentication for the
purpose of configuring the device itself (management).
Requires further clarification from NIST.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must electronically verify
Personal Identity Verification (PIV) credentials.xccdf_mil.disa.stig_rule_SV-203729r958818_rule mediumCCI-001954
The operating system must electronically verify Personal Identity Verification (PIV) credentials.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203729r958818_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001954 |
| Description | The use of PIV credentials facilitates
standardization and reduces the risk of unauthorized access.
DoD has mandated the use of the CAC to support identity management and
personal authentication for systems covered under Homeland Security
Presidential Directive (HSPD) 12, as well as making the CAC a primary
component of layered protection for national security systems.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must accept Personal Identity
Verification (PIV) credentials.xccdf_mil.disa.stig_rule_SV-203728r958816_rule mediumCCI-001953
The operating system must accept Personal Identity Verification (PIV) credentials.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203728r958816_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001953 |
| Description | The use of PIV credentials facilitates
standardization and reduces the risk of unauthorized access.
DoD has mandated the use of the CAC to support identity management and
personal authentication for systems covered under Homeland Security
Presidential Directive (HSPD) 12, as well as making the CAC a primary
component of layered protection for national security systems.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must map the authenticated
identity to the user or group account for PKI-based authentication.xccdf_mil.disa.stig_rule_SV-203624r958452_rule mediumCCI-000187
The operating system must map the authenticated identity to the user or group account for PKI-based authentication.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203624r958452_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000187 |
| Description | Without mapping the certificate used to
authenticate to the user account, the ability to determine the identity of
the individual user or group will not be available for forensic analysis.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system, for PKI-based authentication,
must validate certificates by constructing a certification path (which
includes status information) to an accepted trust anchor.xccdf_mil.disa.stig_rule_SV-203622r958448_rule mediumCCI-000185
The operating system, for PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203622r958448_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000185 |
| Description | Without path validation, an informed trust
decision by the relying party cannot be made when presented with any
certificate not already explicitly trusted.
A trust anchor is an authoritative entity represented via a public key and
associated data. It is used in the context of public key infrastructures,
X.509 digital certificates, and DNSSEC.
When there is a chain of trust, usually the top entity to be trusted becomes
the trust anchor; it can be, for example, a Certification Authority (CA). A
certification path starts with the subject certificate and proceeds through
a number of intermediate certificates up to a trusted root certificate,
typically issued by a trusted CA.
This requirement verifies that a certification path to an accepted trust
anchor is used for certificate validation and that the path includes status
information. Path validation is necessary for a relying party to make an
informed trust decision when presented with any certificate not already
explicitly trusted. Status information for certification paths includes
certificate revocation lists or online certificate status protocol
responses. Validation of the certificate status information is out of scope
for this requirement.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system, for PKI-based authentication,
must enforce authorized access to the corresponding private key.xccdf_mil.disa.stig_rule_SV-203623r958450_rule mediumCCI-000186
The operating system, for PKI-based authentication, must enforce authorized access to the corresponding private key.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203623r958450_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000186 |
| Description | If the private key is discovered, an attacker
can use the key to authenticate as an authorized user and gain access to the
network infrastructure.
The cornerstone of the PKI is the private key used to encrypt or digitally
sign information.
If the private key is stolen, this will lead to the compromise of the
authentication and non-repudiation gained through PKI because the attacker
can use the private key to digitally sign documents and pretend to be the
authorized user.
Both the holders of a digital certificate and the issuing authority must
protect the computers, storage devices, or whatever they use to keep the
private keys.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must automatically terminate a
user session after inactivity time-outs have expired or at shutdown.xccdf_mil.disa.stig_rule_SV-203683r958636_rule mediumCCI-002361
The operating system must automatically terminate a user session after inactivity time-outs have expired or at shutdown.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203683r958636_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002361 |
| Description | Automatic session termination addresses the
termination of user-initiated logical sessions in contrast to the
termination of network connections that are associated with communications
sessions (i.e., network disconnect). A logical session (for local, network,
and remote access) is initiated whenever a user (or process acting on behalf
of a user) accesses an organizational information system. Such user sessions
can be terminated (and thus terminate user access) without terminating
network sessions.
Session termination terminates all processes associated with a user's
logical session except those processes that are specifically created by the
user (i.e., session owner) to continue after the session is terminated.
Conditions or trigger events requiring automatic session termination can
include, for example, organization-defined periods of user inactivity,
targeted responses to certain types of incidents, and time-of-day
restrictions on information system use.
This capability is typically reserved for specific operating system
functionality where the system owner, data owner, or organization requires
additional assurance.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must control remote access
methods.xccdf_mil.disa.stig_rule_SV-203686r958672_rule mediumCCI-002314
The operating system must control remote access methods.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203686r958672_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002314 |
| Description | Remote access services, such as those providing
remote access to network devices and information systems, which lack
automated control capabilities, increase risk and make remote user access
management difficult at best.
Remote access is access to DoD nonpublic information systems by an
authorized user (or an information system) communicating through an
external, non-organization-controlled network. Remote access methods
include, for example, dial-up, broadband, and wireless.
Operating system functionality (e.g., RDP) must be capable of taking
enforcement action if the audit reveals unauthorized activity. Automated
control of remote access sessions allows organizations to ensure ongoing
compliance with remote access policies by enforcing connection rules of
remote access applications on a variety of information system components
(e.g., servers, workstations, notebook computers, smartphones, and tablets).
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must provide the capability to
immediately disconnect or disable remote access to the operating system.xccdf_mil.disa.stig_rule_SV-203687r958674_rule mediumCCI-002322
The operating system must provide the capability to immediately disconnect or disable remote access to the operating system.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203687r958674_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002322 |
| Description | Without the ability to immediately disconnect or
disable remote access, an attack or other compromise taking place would not
be immediately stopped.
Operating system remote access functionality must have the capability to
immediately disconnect current users remotely accessing the information
system and/or disable further remote access. The speed of disconnect or
disablement varies based on the criticality of missions functions and the
need to eliminate immediate or future remote access to organizational
information systems.
The remote access functionality (e.g., RDP) may implement features such as
automatic disconnect (or user-initiated disconnect) in case of adverse
information based on an indicator of compromise or attack.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must provide a logoff capability
for user-initiated communications sessions when requiring user access
authentication.xccdf_mil.disa.stig_rule_SV-203684r958638_rule mediumCCI-002363
The operating system must provide a logoff capability for user-initiated communications sessions when requiring user access authentication.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203684r958638_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002363 |
| Description | If a user cannot explicitly end an operating
system session, the session may remain open and be exploited by an attacker;
this is referred to as a zombie session.
Information resources to which users gain access via authentication include,
for example, local workstations and remote services. For some types of
interactive sessions, including, for example, remote logon, information
systems typically send logoff messages as final messages prior to
terminating sessions.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must display an explicit logoff
message to users indicating the reliable termination of authenticated
communications sessions.xccdf_mil.disa.stig_rule_SV-203685r958640_rule mediumCCI-002364
The operating system must display an explicit logoff message to users indicating the reliable termination of authenticated communications sessions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203685r958640_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002364 |
| Description | If a user cannot explicitly end an operating
system session, the session may remain open and be exploited by an attacker;
this is referred to as a zombie session. Users need to be aware of whether
or not the session has been terminated.
Information resources to which users gain access via authentication include,
for example, local workstations and remote services. Logoff messages can be
displayed after authenticated sessions have been terminated. However, for
some types of interactive sessions, including, for example, remote logon,
information systems typically send logoff messages as final messages prior
to terminating sessions.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must enforce approved
authorizations for logical access to information and system resources in
accordance with applicable access control policies.xccdf_mil.disa.stig_rule_SV-203636r958472_rule mediumCCI-000213
The operating system must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203636r958472_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000213 |
| Description | To mitigate the risk of unauthorized access to
sensitive information by entities that have been issued certificates by
DoD-approved PKIs, all DoD systems (e.g., web servers and web portals) must
be properly configured to incorporate access control methods that do not
rely solely on the possession of a certificate for access. Successful
authentication must not automatically give an entity access to an asset or
security boundary. Authorization procedures and controls must be implemented
to ensure each authenticated entity also has a validated and current
authorization. Authorization is the process of determining whether an
entity, once authenticated, is permitted to access a specific asset.
Information systems use access control policies and enforcement mechanisms
to implement this requirement.
Access control policies include: identity-based policies, role-based
policies, and attribute-based policies. Access enforcement mechanisms
include: access control lists, access control matrices, and cryptography.
These policies and mechanisms must be employed by the application to control
access between users (or processes acting on behalf of users) and objects
(e.g., devices, files, records, processes, programs, and domains) in the
information system.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must only allow the use of DoD
PKI-established certificate authorities for authentication in the
establishment of protected sessions to the operating system.xccdf_mil.disa.stig_rule_SV-203744r958868_rule mediumCCI-002470
The operating system must only allow the use of DoD PKI-established certificate authorities for authentication in the establishment of protected sessions to the operating system.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203744r958868_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002470 |
| Description | Untrusted Certificate Authorities (CA) can issue
certificates, but they may be issued by organizations or individuals that
seek to compromise DoD systems or by organizations with insufficient
security controls. If the CA used for verifying the certificate is not a
DoD-approved CA, trust of this CA has not been established.
The DoD will only accept PKI-certificates obtained from a DoD-approved
internal or external certificate authority. Reliance on CAs for the
establishment of secure sessions includes, for example, the use of SSL/TLS
certificates.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must automatically lock an account
until the locked account is released by an administrator when three
unsuccessful logon attempts in 15 minutes occur.xccdf_mil.disa.stig_rule_SV-203698r958736_rule mediumCCI-002238
The operating system must automatically lock an account until the locked account is released by an administrator when three unsuccessful logon attempts in 15 minutes occur.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203698r958736_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002238 |
| Description | By limiting the number of failed logon attempts,
the risk of unauthorized system access via user password guessing, otherwise
known as brute-forcing, is reduced. Limits are imposed by locking the
account.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must retain a users session lock
until that user reestablishes access using established identification and
authentication procedures.xccdf_mil.disa.stig_rule_SV-203598r958400_rule mediumCCI-000056
The operating system must retain a users session lock until that user reestablishes access using established identification and authentication procedures.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203598r958400_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000056 |
| Description | A session lock is a temporary action taken when a
user stops work and moves away from the immediate physical vicinity of the
information system but does not want to log out because of the temporary
nature of the absence.
The session lock is implemented at the point where session activity can be
determined.
Regardless of where the session lock is determined and implemented, once
invoked, the session lock shall remain in place until the user
re-authenticates. No other activity aside from re-authentication shall
unlock the system.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must initiate a session lock after
a 15-minute period of inactivity for all connection types.xccdf_mil.disa.stig_rule_SV-203599r958402_rule mediumCCI-000057
The operating system must initiate a session lock after a 15-minute period of inactivity for all connection types.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203599r958402_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000057 |
| Description | A session time-out lock is a temporary action
taken when a user stops work and moves away from the immediate physical
vicinity of the information system but does not log out because of the
temporary nature of the absence. Rather than relying on the user to manually
lock their operating system session prior to vacating the vicinity,
operating systems need to be able to identify when a user's session has
idled and take action to initiate the session lock.
The session lock is implemented at the point where session activity can be
determined and/or controlled.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must display the Standard
Mandatory DoD Notice and Consent Banner until users acknowledge the usage
conditions and take explicit actions to log on for further access.xccdf_mil.disa.stig_rule_SV-203596r958392_rule mediumCCI-000050
The operating system must display the Standard Mandatory DoD Notice and Consent Banner until users acknowledge the usage conditions and take explicit actions to log on for further access.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203596r958392_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000050 |
| Description | The banner must be acknowledged by the user prior
to allowing the user access to the operating system. This provides assurance
that the user has seen the message and accepted the conditions for access.
If the consent banner is not acknowledged by the user, DoD will not be in
compliance with system use notifications required by law.
To establish acceptance of the application usage policy, a click-through
banner at system logon is required. The system must prevent further activity
until the user executes a positive action to manifest agreement by clicking
on a box indicating "OK".
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must enforce the limit of three
consecutive invalid logon attempts by a user during a 15-minute time period.xccdf_mil.disa.stig_rule_SV-203594r958388_rule mediumCCI-000044
The operating system must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203594r958388_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000044 |
| Description | By limiting the number of failed logon attempts,
the risk of unauthorized system access via user password guessing, otherwise
known as brute-force attacks, is reduced. Limits are imposed by locking the
account.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must display the Standard
Mandatory DoD Notice and Consent Banner before granting local or remote
access to the system.xccdf_mil.disa.stig_rule_SV-203595r958390_rule mediumCCI-000048
The operating system must display the Standard Mandatory DoD Notice and Consent Banner before granting local or remote access to the system.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203595r958390_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000048 |
| Description | Display of a standardized and approved use
notification before granting access to the operating system ensures privacy
and security notification verbiage used is consistent with applicable
federal laws, Executive Orders, directives, policies, regulations,
standards, and guidance.
System use notifications are required only for access via logon interfaces
with human users and are not required when such human interfaces do not
exist.
The banner must be formatted in accordance with applicable DoD policy. Use
the following verbiage for operating systems that can accommodate banners of
1300 characters:
"You are accessing a U.S. Government (USG) Information System (IS) that is
provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you
consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for
purposes including, but not limited to, penetration testing, COMSEC
monitoring, network operations and defense, personnel misconduct (PM), law
enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are
subject to routine monitoring, interception, and search, and may be
disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access
controls) to protect USG interests--not for your personal benefit or
privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM,
LE or CI investigative searching or monitoring of the content of privileged
communications, or work product, related to personal representation or
services by attorneys, psychotherapists, or clergy, and their assistants.
Such communications and work product are private and confidential. See User
Agreement for details."
Use the following verbiage for operating systems that have severe
limitations on the number of characters that can be displayed in the banner:
"I've read & consent to terms in IS user agreem't."
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must monitor remote access
methods.xccdf_mil.disa.stig_rule_SV-203602r958406_rule mediumCCI-000067
The operating system must monitor remote access methods.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203602r958406_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000067 |
| Description | Remote access services, such as those providing
remote access to network devices and information systems, which lack
automated monitoring capabilities, increase risk and make remote user access
management difficult at best.
Remote access is access to DoD nonpublic information systems by an
authorized user (or an information system) communicating through an
external, non-organization-controlled network. Remote access methods
include, for example, dial-up, broadband, and wireless.
Automated monitoring of remote access sessions allows organizations to
detect cyber attacks and also ensure ongoing compliance with remote access
policies by auditing connection activities of remote access capabilities,
such as Remote Desktop Protocol (RDP), on a variety of information system
components (e.g., servers, workstations, notebook computers, smartphones,
and tablets).
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must provide the capability for
users to directly initiate a session lock for all connection types.xccdf_mil.disa.stig_rule_SV-203600r982194_rule mediumCCI-000057
The operating system must provide the capability for users to directly initiate a session lock for all connection types.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203600r982194_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000057 |
| Description | A session lock is a temporary action taken when a
user stops work and moves away from the immediate physical vicinity of the
information system but does not want to log out because of the temporary
nature of the absence.
The session lock is implemented at the point where session activity can be
determined. Rather than be forced to wait for a period of time to expire
before the user session can be locked, operating systems need to provide
users with the ability to manually invoke a session lock so users may secure
their session should the need arise for them to temporarily vacate the
immediate physical vicinity.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must conceal, via the session
lock, information previously visible on the display with a publicly viewable
image.xccdf_mil.disa.stig_rule_SV-203601r958404_rule mediumCCI-000060
The operating system must conceal, via the session lock, information previously visible on the display with a publicly viewable image.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203601r958404_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000060 |
| Description | A session lock is a temporary action taken when a
user stops work and moves away from the immediate physical vicinity of the
information system but does not log out because of the temporary nature of
the absence.
The session lock is implemented at the point where session activity can be
determined. The operating system session lock event must include an
obfuscation of the display screen so as to prevent other users from reading
what was previously displayed.
Publicly viewable images can include static or dynamic images, for example,
patterns used with screen savers, photographic images, solid colors, a
clock, a battery life indicator, or a blank screen, with the additional
caveat that none of the images convey sensitive information.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
Any publicly accessible connection to the operating
system must display the Standard Mandatory DoD Notice and Consent Banner
before granting access to the system.xccdf_mil.disa.stig_rule_SV-203665r958586_rule mediumCCI-001384
Any publicly accessible connection to the operating system must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203665r958586_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001384 |
| Description | Display of a standardized and approved use
notification before granting access to the publicly accessible operating
system ensures privacy and security notification verbiage used is consistent
with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance.
System use notifications are required only for access via logon interfaces
with human users and are not required when such human interfaces do not
exist.
The banner must be formatted in accordance with applicable DoD policy. Use
the following verbiage for operating systems that can accommodate banners of
1300 characters:
"You are accessing a U.S. Government (USG) Information System (IS) that is
provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you
consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for
purposes including, but not limited to, penetration testing, COMSEC
monitoring, network operations and defense, personnel misconduct (PM), law
enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are
subject to routine monitoring, interception, and search, and may be
disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access
controls) to protect USG interests--not for your personal benefit or
privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM,
LE or CI investigative searching or monitoring of the content of privileged
communications, or work product, related to personal representation or
services by attorneys, psychotherapists, or clergy, and their assistants.
Such communications and work product are private and confidential. See User
Agreement for details."
Use the following verbiage for operating systems that have severe
limitations on the number of characters that can be displayed in the banner:
"I've read & consent to terms in IS user agreem't."
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must enforce a delay of at least 4
seconds between logon prompts following a failed logon attempt.xccdf_mil.disa.stig_rule_SV-203779r991588_rule mediumCCI-000366
The operating system must enforce a delay of at least 4 seconds between logon prompts following a failed logon attempt.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203779r991588_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000366 |
| Description | Limiting the number of logon attempts over a
certain time interval reduces the chances that an unauthorized user may gain
access to an account.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must generate audit records when
concurrent logons to the same account occur from different sources.xccdf_mil.disa.stig_rule_SV-203771r991582_rule mediumCCI-000172
The operating system must generate audit records when concurrent logons to the same account occur from different sources.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203771r991582_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000172 |
| Description | Without generating audit records that are
specific to the security and mission needs of the organization, it would be
difficult to establish, correlate, and investigate the events relating to an
incident or identify those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter).
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must implement replay-resistant
authentication mechanisms for network access to non-privileged accounts.xccdf_mil.disa.stig_rule_SV-203646r982206_rule mediumCCI-001941
The operating system must implement replay-resistant authentication mechanisms for network access to non-privileged accounts.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203646r982206_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001941 |
| Description | A replay attack may enable an unauthorized user
to gain access to the operating system. Authentication sessions between the
authenticator and the operating system validating the user credentials must
not be vulnerable to a replay attack.
An authentication process resists replay attacks if it is impractical to
achieve a successful authentication by recording and replaying a previous
authentication message.
A non-privileged account is any operating system account with authorizations
of a non-privileged user.
Techniques used to address this include protocols using nonces (e.g.,
numbers generated for a specific one-time use) or challenges (e.g., TLS,
WS_Security). Additional techniques include time-synchronous or
challenge-response one-time authenticators.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must require individuals to be
authenticated with an individual authenticator prior to using a group
authenticator.xccdf_mil.disa.stig_rule_SV-203644r982205_rule mediumCCI-004045
The operating system must require individuals to be authenticated with an individual authenticator prior to using a group authenticator.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203644r982205_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004045 |
| Description | To assure individual accountability and prevent
unauthorized access, organizational users must be individually identified
and authenticated.
A group authenticator is a generic account used by multiple individuals. Use
of a group authenticator alone does not uniquely identify individual users.
Examples of the group authenticator is the UNIX OS "root" user account, the
Windows "Administrator" account, the "sa" account, or a "helpdesk" account.
For example, the UNIX and Windows operating systems offer a 'switch user'
capability allowing users to authenticate with their individual credentials
and, when needed, 'switch' to the administrator role. This method provides
for unique individual authentication prior to using a group authenticator.
Users (and any processes acting on behalf of users) need to be uniquely
identified and authenticated for all accesses other than those accesses
explicitly identified and documented by the organization, which outlines
specific user actions that can be performed on the operating system without
identification or authentication.
Requiring individuals to be authenticated with an individual authenticator
prior to using a group authenticator allows for traceability of actions, as
well as adding an additional level of protection of the actions that can be
taken with group account knowledge.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must implement replay-resistant
authentication mechanisms for network access to privileged accounts.xccdf_mil.disa.stig_rule_SV-203645r958494_rule mediumCCI-001941
The operating system must implement replay-resistant authentication mechanisms for network access to privileged accounts.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203645r958494_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001941 |
| Description | A replay attack may enable an unauthorized user
to gain access to the operating system. Authentication sessions between the
authenticator and the operating system validating the user credentials must
not be vulnerable to a replay attack.
An authentication process resists replay attacks if it is impractical to
achieve a successful authentication by recording and replaying a previous
authentication message.
A privileged account is any information system account with authorizations
of a privileged user.
Techniques used to address this include protocols using nonces (e.g.,
numbers generated for a specific one-time use) or challenges (e.g., TLS,
WS_Security). Additional techniques include time-synchronous or
challenge-response one-time authenticators.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must use multifactor
authentication for local access to privileged accounts.xccdf_mil.disa.stig_rule_SV-203642r982203_rule mediumCCI-000765
The operating system must use multifactor authentication for local access to privileged accounts.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203642r982203_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000765 |
| Description | To assure accountability and prevent
unauthenticated access, privileged users must utilize multifactor
authentication to prevent potential misuse and compromise of the system.
Multifactor authentication is defined as using two or more factors to
achieve authentication.
Factors include:
1) Something you know (e.g., password/PIN);
2) Something you have (e.g., cryptographic identification device, token);
and
3) Something you are (e.g., biometric).
A privileged account is defined as an operating system account with
authorizations of a privileged user.
Local access is defined as access to an organizational information system by
a user (or process acting on behalf of a user) communicating through a
direct connection without the use of a network.
The DoD CAC with DoD-approved PKI is an example of multifactor
authentication.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must use multifactor
authentication for local access to non-privileged accounts.xccdf_mil.disa.stig_rule_SV-203643r982204_rule mediumCCI-000766
The operating system must use multifactor authentication for local access to non-privileged accounts.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203643r982204_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000766 |
| Description | To assure accountability, prevent unauthenticated
access, and prevent misuse of the system, non-privileged users must utilize
multifactor authentication for local access.
Multifactor authentication is defined as using two or more factors to
achieve authentication.
Factors include:
1) Something you know (e.g., password/PIN);
2) Something you have (e.g., cryptographic identification device or token);
and
3) Something you are (e.g., biometric).
A non-privileged account is defined as an operating system account with
authorizations of a regular or non-privileged user.
Local access is defined as access to an organizational information system by
a user (or process acting on behalf of a user) communicating through a
direct connection without the use of a network.
The DoD CAC with DoD-approved PKI is an example of multifactor
authentication.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must use multifactor
authentication for network access to privileged accounts.xccdf_mil.disa.stig_rule_SV-203640r958484_rule mediumCCI-000765
The operating system must use multifactor authentication for network access to privileged accounts.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203640r958484_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000765 |
| Description | Without the use of multifactor authentication,
the ease of access to privileged functions is greatly increased.
Multifactor authentication requires using two or more factors to achieve
authentication.
Factors include:
1) something a user knows (e.g., password/PIN);
2) something a user has (e.g., cryptographic identification device, token);
and
3) something a user is (e.g., biometric).
A privileged account is defined as an information system account with
authorizations of a privileged user.
Network access is defined as access to an information system by a user (or a
process acting on behalf of a user) communicating through a network (e.g.,
local area network, wide area network, or the Internet).
The DoD CAC with DoD-approved PKI is an example of multifactor
authentication.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must use multifactor
authentication for network access to non-privileged accounts.xccdf_mil.disa.stig_rule_SV-203641r958486_rule mediumCCI-000766
The operating system must use multifactor authentication for network access to non-privileged accounts.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203641r958486_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000766 |
| Description | To assure accountability and prevent
unauthenticated access, non-privileged users must utilize multifactor
authentication to prevent potential misuse and compromise of the system.
Multifactor authentication uses two or more factors to achieve
authentication.
Factors include:
1) Something you know (e.g., password/PIN);
2) Something you have (e.g., cryptographic identification device, token);
and
3) Something you are (e.g., biometric).
A non-privileged account is any information system account with
authorizations of a non-privileged user.
Network access is any access to an application by a user (or process acting
on behalf of a user) where said access is obtained through a network
connection.
The DoD CAC with DoD-approved PKI is an example of multifactor
authentication.
Script Verification:
To manually verify, ensure none of the following remote access packages
exist in the folder /lib/apk/db/ Packages: openssh, openssh-server,
openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must implement multifactor
authentication for
local,
network, and/or remote access to privileged accounts and/or nonprivileged
accounts
such that the device meets organization-defined strength of mechanism
requirements.xccdf_mil.disa.stig_rule_SV-263652r982557_rule mediumCCI-004047
The operating system must implement multifactor authentication for local, network, and/or remote access to privileged accounts and/or nonprivileged accounts such that the device meets organization-defined strength of mechanism requirements.
| Rule ID | xccdf_mil.disa.stig_rule_SV-263652r982557_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.RemoteAccessServices:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004047 |
| Description | The purpose of requiring a device separate from
the system to which the user is attempting to gain access for one of the
factors during multifactor authentication is to reduce the likelihood of
compromising authenticators or credentials stored on the system. Adversaries
may be able to compromise such authenticators or credentials and
subsequently impersonate authorized users. Implementing one of the factors
on a separate device (e.g., a hardware token), provides a greater strength
of mechanism and an increased level of assurance in the authentication
process.
Script Verification:
To check manually, confirm that none of the following remote-access
packages are present in the folder /usr/lib/apk/db/ Packages: openssh,
openssh-server, openssh-client, openssh-sftp-server, dropbear, tigervnc,
tigervnc-server, tigervnc-viewer, xrdp, xorgxrdp, vsftpd, proftpd,
webmin, cockpit, cockpit-ws, cockpit-bridge, nfs-utils, samba,
samba-server, samba-client, samba-common, rsh, telnet
|
OVAL test results details
Check for installed packages starting with 'mypkg-' in /lib/apk/db/installed oval:org.RemoteAccessServices:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.RemoteAccessServices:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /lib/apk/db | installed | (openssh|openssh-server|openssh-client|openssh-sftp-server|dropbear|tigervnc|tigervnc-server|tigervnc-viewer|xrdp|xorgxrdp|vsftpd|proftpd|webmin|cockpit|cockpit-ws|cockpit-bridge|nfs-utils|samba|samba-server|samba-client|samba-common|rsh|telnet)-* | 1 |
The operating system must prevent the installation of
patches, service packs, device drivers, or operating system components
without verification they have been digitally signed using a certificate
that is recognized and approved by the organization.xccdf_mil.disa.stig_rule_SV-203720r982212_rule highCCI-003992
The operating system must prevent the installation of patches, service packs, device drivers, or operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203720r982212_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.PackageSignature:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-003992 |
| Description | Changes to any software components can have
significant effects on the overall security of the operating system. This
requirement ensures the software has not been tampered with and that it has
been provided by a trusted vendor.
Accordingly, patches, service packs, device drivers, or operating system
components must be signed with a certificate recognized and approved by the
organization.
Verifying the authenticity of the software prior to installation validates
the integrity of the patch or upgrade received from a vendor. This ensures
the software has not been tampered with and that it has been provided by a
trusted vendor. Self-signed certificates are disallowed by this requirement.
The operating system should not have to verify the software again. This
requirement does not mandate DoD certificates for this purpose; however, the
certificate used to verify the software must be from an approved CA.
Script Verification:
To manually verify, ensure all repositories in /etc/apk/repositories/
begin with 'https://'
|
OVAL test results details
Check existence of /usr/lib directory oval:org.PackageSignature:tst:1 true
No items have been found conforming to the following objects:
Object oval:org.PackageSignature:obj:1 of type file_object
| Path | Filename |
|---|---|
| etc/apk/repositories | ^(?!.*https://).* |
The operating system must store only encrypted
representations of passwords.xccdf_mil.disa.stig_rule_SV-203629r982199_rule highCCI-004062
The operating system must store only encrypted representations of passwords.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203629r982199_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.example:def:3 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-004062 |
| Description | Passwords need to be protected at all times, and
encryption is the standard method for protecting passwords. If passwords are
not encrypted, they can be plainly read (i.e., clear text) and easily
compromised.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify no password
fields start with a '$' indicating a hashed password
|
OVAL test results details
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.example:tst:6 true
No items have been found conforming to the following objects:
Object oval:org.example:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^[^:]+:\$[^\n]*: | 1 |
The operating system must transmit only encrypted
representations of passwords.xccdf_mil.disa.stig_rule_SV-203630r987796_rule highCCI-000197
The operating system must transmit only encrypted representations of passwords.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203630r987796_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.example:def:3 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-000197 |
| Description | Passwords need to be protected at all times, and
encryption is the standard method for protecting passwords. If passwords are
not encrypted, they can be plainly read (i.e., clear text) and easily
compromised.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify no password
fields start with a '$' indicating a hashed password
|
OVAL test results details
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.example:tst:6 true
No items have been found conforming to the following objects:
Object oval:org.example:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^[^:]+:\$[^\n]*: | 1 |
The operating system must prohibit the use of cached
authenticators after one day.xccdf_mil.disa.stig_rule_SV-203733r958828_rule mediumCCI-002007
The operating system must prohibit the use of cached authenticators after one day.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203733r958828_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.example:def:3 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002007 |
| Description | If cached authentication information is
out-of-date, the validity of the authentication information may be
questionable.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify no password
fields start with a '$' indicating a hashed password
|
OVAL test results details
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.example:tst:6 true
No items have been found conforming to the following objects:
Object oval:org.example:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^[^:]+:\$[^\n]*: | 1 |
The operating system must require the change of at
least 50% of the total number of characters when passwords are changed.xccdf_mil.disa.stig_rule_SV-203628r982198_rule mediumCCI-004066
The operating system must require the change of at least 50% of the total number of characters when passwords are changed.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203628r982198_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.example:def:3 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004066 |
| Description | If the operating system allows the user to
consecutively reuse extensive portions of passwords, this increases the
chances of password compromise by increasing the window of opportunity for
attempts at guessing and brute-force attacks.
The number of changed characters refers to the number of changes required
with respect to the total number of positions in the current password. In
other words, characters may be the same within the two passwords; however,
the positions of the like characters must be different.
If the password length is an odd number then number of changed characters
must be rounded up. For example, a password length of 15 characters must
require the change of at least 8 characters.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify no password
fields start with a '$' indicating a hashed password
|
OVAL test results details
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.example:tst:6 true
No items have been found conforming to the following objects:
Object oval:org.example:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^[^:]+:\$[^\n]*: | 1 |
The operating system must enforce password complexity
by requiring that at least one upper-case character be used.xccdf_mil.disa.stig_rule_SV-203625r982195_rule mediumCCI-004066
The operating system must enforce password complexity by requiring that at least one upper-case character be used.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203625r982195_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.example:def:3 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004066 |
| Description | Use of a complex password helps to increase the
time and resources required to compromise the password. Password complexity,
or strength, is a measure of the effectiveness of a password in resisting
attempts at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it
takes to crack a password. The more complex the password, the greater the
number of possible combinations that need to be tested before the password
is compromised.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify no password
fields start with a '$' indicating a hashed password
|
OVAL test results details
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.example:tst:6 true
No items have been found conforming to the following objects:
Object oval:org.example:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^[^:]+:\$[^\n]*: | 1 |
The operating system must enforce password complexity
by requiring that at least one lower-case character be used.xccdf_mil.disa.stig_rule_SV-203626r982196_rule mediumCCI-004066
The operating system must enforce password complexity by requiring that at least one lower-case character be used.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203626r982196_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.example:def:3 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004066 |
| Description | Use of a complex password helps to increase the
time and resources required to compromise the password. Password complexity,
or strength, is a measure of the effectiveness of a password in resisting
attempts at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it
takes to crack a password. The more complex the password, the greater the
number of possible combinations that need to be tested before the password
is compromised.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify no password
fields start with a '$' indicating a hashed password
|
OVAL test results details
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.example:tst:6 true
No items have been found conforming to the following objects:
Object oval:org.example:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^[^:]+:\$[^\n]*: | 1 |
The operating system must enforce password complexity
by requiring that at least one numeric character be used.xccdf_mil.disa.stig_rule_SV-203627r982197_rule mediumCCI-004066
The operating system must enforce password complexity by requiring that at least one numeric character be used.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203627r982197_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.example:def:3 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004066 |
| Description | Use of a complex password helps to increase the
time and resources required to compromise the password. Password complexity,
or strength, is a measure of the effectiveness of a password in resisting
attempts at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it
takes to crack a password. The more complex the password, the greater the
number of possible combinations that need to be tested before the password
is compromised.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify no password
fields start with a '$' indicating a hashed password
|
OVAL test results details
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.example:tst:6 true
No items have been found conforming to the following objects:
Object oval:org.example:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^[^:]+:\$[^\n]*: | 1 |
The operating system must obscure feedback of
authentication information during the authentication process to protect the
information from possible exploitation/use by unauthorized individuals.xccdf_mil.disa.stig_rule_SV-203635r958470_rule mediumCCI-000206
The operating system must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203635r958470_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.example:def:3 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000206 |
| Description | To prevent the compromise of authentication
information, such as passwords during the authentication process, the
feedback from the operating system shall not provide any information
allowing an unauthorized user to compromise the authentication mechanism.
Obfuscation of user-provided information that is typed into the system is a
method used when addressing this risk.
For example, displaying asterisks when a user types in a password is an
example of obscuring feedback of authentication information.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify no password
fields start with a '$' indicating a hashed password
|
OVAL test results details
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.example:tst:6 true
No items have been found conforming to the following objects:
Object oval:org.example:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^[^:]+:\$[^\n]*: | 1 |
The operating system must enforce a minimum
15-character password length.xccdf_mil.disa.stig_rule_SV-203634r982202_rule mediumCCI-004066
The operating system must enforce a minimum 15-character password length.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203634r982202_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.example:def:3 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004066 |
| Description | The shorter the password, the lower the number of
possible combinations that need to be tested before the password is
compromised.
Password complexity, or strength, is a measure of the effectiveness of a
password in resisting attempts at guessing and brute-force attacks. Password
length is one factor of several that helps to determine strength and how
long it takes to crack a password. Use of more characters in a password
helps to exponentially increase the time and/or resources required to
compromise the password.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify no password
fields start with a '$' indicating a hashed password
|
OVAL test results details
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.example:tst:6 true
No items have been found conforming to the following objects:
Object oval:org.example:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^[^:]+:\$[^\n]*: | 1 |
Operating systems must enforce a 60-day maximum
password lifetime restriction.xccdf_mil.disa.stig_rule_SV-203632r1038967_rule mediumCCI-004066
Operating systems must enforce a 60-day maximum password lifetime restriction.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203632r1038967_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.example:def:3 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004066 |
| Description | Any password, no matter how complex, can
eventually be cracked. Therefore, passwords need to be changed periodically.
If the operating system does not limit the lifetime of passwords and force
users to change their passwords, there is the risk that the operating system
passwords could be compromised.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify no password
fields start with a '$' indicating a hashed password
|
OVAL test results details
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.example:tst:6 true
No items have been found conforming to the following objects:
Object oval:org.example:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^[^:]+:\$[^\n]*: | 1 |
Operating systems must enforce 24 hours/1 day as the
minimum password lifetime.xccdf_mil.disa.stig_rule_SV-203631r982188_rule mediumCCI-004066
Operating systems must enforce 24 hours/1 day as the minimum password lifetime.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203631r982188_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.example:def:3 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004066 |
| Description | Enforcing a minimum password lifetime helps to
prevent repeated password changes to defeat the password reuse or history
enforcement requirement. If users are allowed to immediately and continually
change their password, then the password could be repeatedly changed in a
short period of time to defeat the organization's policy regarding password
reuse.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify no password
fields start with a '$' indicating a hashed password
|
OVAL test results details
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.example:tst:6 true
No items have been found conforming to the following objects:
Object oval:org.example:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^[^:]+:\$[^\n]*: | 1 |
The operating system must enforce password complexity
by requiring that at least one special character be used.xccdf_mil.disa.stig_rule_SV-203676r991561_rule mediumCCI-004066
The operating system must enforce password complexity by requiring that at least one special character be used.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203676r991561_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.example:def:3 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-004066 |
| Description | Use of a complex password helps to increase the
time and resources required to compromise the password. Password complexity
or strength is a measure of the effectiveness of a password in resisting
attempts at guessing and brute-force attacks.
Password complexity is one factor in determining how long it takes to crack
a password. The more complex the password, the greater the number of
possible combinations that need to be tested before the password is
compromised.
Special characters are those characters that are not alphanumeric. Examples
include: ~ ! @ # $ % ^ *.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify no password
fields start with a '$' indicating a hashed password
|
OVAL test results details
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.example:tst:6 true
No items have been found conforming to the following objects:
Object oval:org.example:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^[^:]+:\$[^\n]*: | 1 |
The operating system must prevent the use of dictionary
words for passwords.xccdf_mil.disa.stig_rule_SV-203778r991587_rule mediumCCI-000366
The operating system must prevent the use of dictionary words for passwords.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203778r991587_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.example:def:3 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000366 |
| Description | If the operating system allows the user to select
passwords based on dictionary words, then this increases the chances of
password compromise by increasing the opportunity for successful guesses and
brute-force attacks.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify no password
fields start with a '$' indicating a hashed password
|
OVAL test results details
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.example:tst:6 true
No items have been found conforming to the following objects:
Object oval:org.example:obj:6 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^[^:]+:\$[^\n]*: | 1 |
The operating system must prevent nonprivileged users
from executing privileged functions to include disabling, circumventing, or
altering implemented security safeguards/countermeasures.xccdf_mil.disa.stig_rule_SV-203695r958726_rule highCCI-002235
The operating system must prevent nonprivileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203695r958726_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | high |
| Identifiers: | CCI-002235 |
| Description | Preventing non-privileged users from executing
privileged functions mitigates the risk that unauthorized individuals or
processes may gain unnecessary access to information or privileges.
Privileged functions include, for example, establishing accounts, performing
system integrity checks, or administering cryptographic key management
activities. Non-privileged users are individuals that do not possess
appropriate authorizations. Circumventing intrusion detection and prevention
mechanisms or malicious code protection mechanisms are examples of
privileged functions that require protection from non-privileged users.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must define default permissions
for all authenticated users in such a way that the user can only read and
modify their own files.xccdf_mil.disa.stig_rule_SV-203781r991590_rule mediumCCI-000366
The operating system must define default permissions for all authenticated users in such a way that the user can only read and modify their own files.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203781r991590_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000366 |
| Description | Setting the most restrictive default permissions
ensures that when new accounts are created they do not have unnecessary
access.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must uniquely identify and must
authenticate non-organizational users (or processes acting on behalf of
non-organizational users).xccdf_mil.disa.stig_rule_SV-203650r958504_rule mediumCCI-000804
The operating system must uniquely identify and must authenticate non-organizational users (or processes acting on behalf of non-organizational users).
| Rule ID | xccdf_mil.disa.stig_rule_SV-203650r958504_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000804 |
| Description | Lack of authentication and identification enables
non-organizational users to gain access to the application or possibly other
information systems and provides an opportunity for intruders to compromise
resources within the application or information system.
Non-organizational users include all information system users other than
organizational users, which include organizational employees or individuals
the organization deems to have equivalent status of an employee (e.g.,
contractors and guest researchers).
Non-organizational users shall be uniquely identified and authenticated for
all accesses other than those accesses explicitly identified and documented
by the organization when related to the use of anonymous access.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The information system must automatically remove or
disable emergency accounts after the crisis is resolved or 72 hours.xccdf_mil.disa.stig_rule_SV-203652r958508_rule mediumCCI-001682
The information system must automatically remove or disable emergency accounts after the crisis is resolved or 72 hours.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203652r958508_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001682 |
| Description | Emergency accounts are privileged accounts that
are established in response to crisis situations where the need for rapid
account activation is required. Therefore, emergency account activation may
bypass normal account authorization processes. If these accounts are
automatically disabled, system maintenance during emergencies may not be
possible, thus adversely affecting system availability.
Emergency accounts are different from infrequently used accounts (i.e.,
local logon accounts used by the organization's system administrators when
network or normal logon/access is not available). Infrequently used accounts
are not subject to automatic termination dates. Emergency accounts are
accounts created in response to crisis situations, usually for use by
maintenance personnel. The automatic expiration or disabling time period may
be extended as needed until the crisis is resolved; however, it must not be
extended indefinitely. A permanent account should be established for
privileged users who need long-term maintenance accounts.
To address access requirements, many operating systems can be integrated
with enterprise-level authentication/access mechanisms that meet or exceed
access control policy requirements.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must separate user functionality
(including user interface services) from operating system management
functionality.xccdf_mil.disa.stig_rule_SV-203655r958514_rule mediumCCI-001082
The operating system must separate user functionality (including user interface services) from operating system management functionality.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203655r958514_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001082 |
| Description | Operating system management functionality
includes functions necessary for administration and requires privileged user
access. Allowing non-privileged users to access operating system management
functionality capabilities increases the risk that non-privileged users may
obtain elevated privileges.
Operating system management functionality includes functions necessary to
administer console, network components, workstations, or servers and
typically requires privileged user access.
The separation of user functionality from information system management
functionality is either physical or logical and is accomplished by using
different computers, different central processing units, different instances
of the operating system, different network addresses, different TCP/UDP
ports, virtualization techniques, combinations of these methods, or other
methods, as appropriate.
An example of this type of separation is observed in web administrative
interfaces that use separate authentication methods for users of any other
information system resources. This may include isolating the administrative
interface on a different security domain and with additional access
controls.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must require users to
re-authenticate when changing authenticators.xccdf_mil.disa.stig_rule_SV-203725r1050791_rule mediumCCI-002038
The operating system must require users to re-authenticate when changing authenticators.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203725r1050791_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002038 |
| Description | Without re-authentication, users may access
resources or perform tasks for which they do not have authorization.
When operating systems provide the capability to change user authenticators,
it is critical the user re-authenticate.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must require users to
re-authenticate when changing roles.xccdf_mil.disa.stig_rule_SV-203724r1050790_rule mediumCCI-002038
The operating system must require users to re-authenticate when changing roles.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203724r1050790_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002038 |
| Description | Without re-authentication, users may access
resources or perform tasks for which they do not have authorization.
When operating systems provide the capability to change security roles, it
is critical the user re-authenticate.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must notify system administrators
and ISSOs when accounts are disabled. xccdf_mil.disa.stig_rule_SV-203680r991565_rule mediumCCI-000015
The operating system must notify system administrators and ISSOs when accounts are disabled.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203680r991565_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000015 |
| Description | When operating system accounts are disabled, user
accessibility is affected. Accounts are utilized for identifying individual
operating system users or for identifying the operating system processes
themselves. Sending notification of account disabling events to the system
administrator and ISSO is one method for mitigating this risk. Such a
capability greatly reduces the risk that operating system accessibility will
be negatively affected for extended periods of time and also provides
logging that can be used for forensic purposes.
To address access requirements, many operating systems can be integrated
with enterprise-level authentication/access/auditing mechanisms that meet or
exceed access control policy requirements.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must notify system administrators
and ISSOs when accounts are removed.xccdf_mil.disa.stig_rule_SV-203681r991566_rule mediumCCI-000015
The operating system must notify system administrators and ISSOs when accounts are removed.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203681r991566_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000015 |
| Description | When operating system accounts are removed, user
accessibility is affected. Accounts are utilized for identifying individual
operating system users or for identifying the operating system processes
themselves. Sending notification of account removal events to the system
administrator and ISSO is one method for mitigating this risk. Such a
capability greatly reduces the risk that operating system accessibility will
be negatively affected for extended periods of time and also provides
logging that can be used for forensic purposes.
To address access requirements, many operating systems can be integrated
with enterprise-level authentication/access/auditing mechanisms that meet or
exceed access control policy requirements.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must uniquely identify and must
authenticate organizational users (or processes acting on behalf of
organizational users).xccdf_mil.disa.stig_rule_SV-203639r958482_rule mediumCCI-000764
The operating system must uniquely identify and must authenticate organizational users (or processes acting on behalf of organizational users).
| Rule ID | xccdf_mil.disa.stig_rule_SV-203639r958482_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000764 |
| Description | To assure accountability and prevent
unauthenticated access, organizational users must be identified and
authenticated to prevent potential misuse and compromise of the system.
Organizational users include organizational employees or individuals the
organization deems to have equivalent status of employees (e.g.,
contractors). Organizational users (and processes acting on behalf of users)
must be uniquely identified and authenticated to all accesses, except for
the following:
1) Accesses explicitly identified and documented by the organization.
Organizations document specific user actions that can be performed on the
information system without identification or authentication; and
2) Accesses that occur through authorized use of group authenticators
without individual authentication. Organizations may require unique
identification of individuals in group accounts (e.g., shared privilege
accounts) or for detailed accountability of individual activity.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must prevent all software from
executing at higher privilege levels than users executing the software.xccdf_mil.disa.stig_rule_SV-203696r958730_rule mediumCCI-002233
The operating system must prevent all software from executing at higher privilege levels than users executing the software.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203696r958730_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002233 |
| Description | In certain situations, software
applications/programs need to execute with elevated privileges to perform
required functions. However, if the privileges required for execution are at
a higher level than the privileges assigned to organizational users invoking
such applications/programs, those users are indirectly provided with greater
privileges than assigned by the organizations.
Some programs and processes are required to operate at a higher privilege
level and therefore should be excluded from the organization-defined
software list after review.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must allow operating system admins
to pass information to any other operating system admin or user.xccdf_mil.disa.stig_rule_SV-203692r958702_rule mediumCCI-002165
The operating system must allow operating system admins to pass information to any other operating system admin or user.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203692r958702_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002165 |
| Description | Discretionary Access Control (DAC) is based on
the notion that individual users are "owners" of objects and therefore have
discretion over who should be authorized to access the object and in which
mode (e.g., read or write). Ownership is usually acquired as a consequence
of creating the object or via specified ownership assignment. DAC allows the
owner to determine who will have access to objects they control. An example
of DAC includes user-controlled file permissions.
When discretionary access control policies are implemented, subjects are not
constrained with regard to what actions they can take with information for
which they have already been granted access. Thus, subjects that have been
granted access to information are not prevented from passing (i.e., the
subjects have the discretion to pass) the information to other subjects or
objects. A subject that is constrained in its operation by Mandatory Access
Control policies is still able to operate under the less rigorous
constraints of this requirement. Thus, while Mandatory Access Control
imposes constraints preventing a subject from passing information to another
subject operating at a different sensitivity level, this requirement permits
the subject to pass the information to any subject at the same sensitivity
level. The policy is bounded by the information system boundary. Once the
information is passed outside the control of the information system,
additional means may be required to ensure the constraints remain in effect.
While the older, more traditional definitions of discretionary access
control require identity-based access control, that limitation is not
required for this use of discretionary access control.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must automatically remove or
disable temporary user accounts after 72 hours.xccdf_mil.disa.stig_rule_SV-203592r958364_rule mediumCCI-000016
The operating system must automatically remove or disable temporary user accounts after 72 hours.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203592r958364_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000016 |
| Description | If temporary user accounts remain active when no
longer needed or for an excessive period, these accounts may be used to gain
unauthorized access. To mitigate this risk, automated termination of all
temporary accounts must be set upon account creation.
Temporary accounts are established as part of normal account activation
procedures when there is a need for short-term accounts without the demand
for immediacy in account activation.
If temporary accounts are used, the operating system must be configured to
automatically terminate these types of accounts after a DoD-defined time
period of 72 hours.
To address access requirements, many operating systems may be integrated
with enterprise-level authentication/access mechanisms that meet or exceed
access control policy requirements.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must provide automated mechanisms
for supporting account management functions.xccdf_mil.disa.stig_rule_SV-203591r958362_rule mediumCCI-000015
The operating system must provide automated mechanisms for supporting account management functions.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203591r958362_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000015 |
| Description | Enterprise environments make account management
challenging and complex. A manual process for account management functions
adds the risk of a potential oversight or other errors.
A comprehensive account management process that includes automation helps to
ensure accounts designated as requiring attention are consistently and
promptly addressed. Examples include, but are not limited to, using
automation to take action on multiple accounts designated as inactive,
suspended or terminated, or by disabling accounts located in non-centralized
account stores such as multiple servers. This requirement applies to all
account types, including individual/user, shared, group, system,
guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and
service.
The automated mechanisms may reside within the operating system itself or
may be offered by other infrastructure providing automated account
management capabilities. Automated mechanisms may be composed of differing
technologies that, when placed together, contain an overall automated
mechanism supporting an organization's automated account management
requirements.
Account management functions include: assigning group or role membership;
identifying account type; specifying user access authorizations (i.e.,
privileges); account removal, update, or termination; and administrative
alerts. The use of automated mechanisms can include, for example: using
email or text messaging to automatically notify account managers when users
are terminated or transferred; using the information system to monitor
account usage; and using automated telephonic notification to report
atypical system account usage.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must limit the ability of
non-privileged users to grant other users direct access to the contents of
their home directories/folders.xccdf_mil.disa.stig_rule_SV-203783r991592_rule mediumCCI-000366
The operating system must limit the ability of non-privileged users to grant other users direct access to the contents of their home directories/folders.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203783r991592_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000366 |
| Description | Users' home directories/folders may contain
information of a sensitive nature. Non-privileged users should coordinate
any sharing of information with an SA through shared resources.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must produce audit records
containing the individual identities of group account users.xccdf_mil.disa.stig_rule_SV-203610r958422_rule mediumCCI-000135
The operating system must produce audit records containing the individual identities of group account users.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203610r958422_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000135 |
| Description | Reconstruction of harmful events or forensic
analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the individual identities of group
users. The organization must maintain audit trails in sufficient detail to
reconstruct events to determine the actual account involved in the activity.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must disable account identifiers
(individuals, groups, roles, and devices) after 35 days of inactivity.xccdf_mil.disa.stig_rule_SV-203648r982189_rule mediumCCI-003627
The operating system must disable account identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203648r982189_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-003627 |
| Description | Inactive identifiers pose a risk to systems and
applications because attackers may exploit an inactive identifier and
potentially obtain undetected access to the system. Owners of inactive
accounts will not notice if unauthorized access to their user account has
been obtained.
Operating systems need to track periods of inactivity and disable
application identifiers after 35 days of inactivity.
Script Verification:
To manually verify, run command 'cat /etc/shadow and verify that no
additional users exist
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must disable accounts when
the accounts are no longer associated to a user.xccdf_mil.disa.stig_rule_SV-263650r982553_rule mediumCCI-003628
The operating system must disable accounts when the accounts are no longer associated to a user.
| Rule ID | xccdf_mil.disa.stig_rule_SV-263650r982553_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.NoUsers:def:1 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-003628 |
| Description | Disabling expired, inactive, or otherwise
anomalous accounts supports the concepts of least privilege and least
functionality which reduce the attack surface of the system.
Script Verification:
To check manually, run the command 'cat /etc/shadow' and confirm that no
additional users are present
|
OVAL test results details
Check presence of 'nobody' line in /etc/shadow oval:org.NoUsers:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/shadow | nobody:!::0::::: |
Check for unauthorized users after the 'nobody' line in /etc/shadow oval:org.NoUsers:tst:2 true
No items have been found conforming to the following objects:
Object oval:org.NoUsers:obj:2 of type textfilecontent54_object
| Path | Filename | Pattern | Instance |
|---|---|---|---|
| /etc | shadow | ^nobody:.*\n(.+) | 1 |
The operating system must implement address space
layout randomization to protect its memory from unauthorized code execution.xccdf_mil.disa.stig_rule_SV-203754r958928_rule mediumCCI-002824
The operating system must implement address space layout randomization to protect its memory from unauthorized code execution.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203754r958928_rule |
| Result | pass |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002824 |
| Description | Some adversaries launch attacks with the intent
of executing code in non-executable regions of memory or in memory locations
that are prohibited. Security safeguards employed to protect memory include,
for example, data execution prevention and address space layout
randomization. Data execution prevention safeguards can either be
hardware-enforced or software-enforced with hardware providing the greater
strength of mechanism.
Examples of attacks are buffer overflow attacks. |
The operating system must implement non-executable data
to protect its memory from unauthorized code execution.xccdf_mil.disa.stig_rule_SV-203753r958928_rule mediumCCI-002824
The operating system must implement non-executable data to protect its memory from unauthorized code execution.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203753r958928_rule |
| Result | pass |
| Multi-check rule | no |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-002824 |
| Description | Some adversaries launch attacks with the intent
of executing code in non-executable regions of memory or in memory locations
that are prohibited. Security safeguards employed to protect memory include,
for example, data execution prevention and address space layout
randomization. Data execution prevention safeguards can either be
hardware-enforced or software-enforced with hardware providing the greater
strength of mechanism.
Examples of attacks are buffer overflow attacks. |
The operating system must reveal error messages only to
authorized users.xccdf_mil.disa.stig_rule_SV-203664r958566_rule mediumCCI-001314
The operating system must reveal error messages only to authorized users.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203664r958566_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.varlog:def:2 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-001314 |
| Description | Only authorized personnel should be aware of
errors and the details of the errors. Error messages are an indicator of an
organization's operational state or can identify the operating system or
platform. Additionally, Personally Identifiable Information (PII) and
operational information must not be revealed through error messages to
unauthorized personnel or their designated representatives.
The structure and content of error messages must be carefully considered by
the organization and development team. The extent to which the information
system is able to identify and handle error conditions is guided by
organizational policy and operational requirements. |
OVAL test results details
Check existence of /var/log directory oval:org.varlog:tst:5 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| true | /var/log/ | directory | 0 | 0 | 4096 | rwxr-xr-x |
The operating system must protect audit information
from unauthorized modification.xccdf_mil.disa.stig_rule_SV-203617r958436_rule mediumCCI-000163
The operating system must protect audit information from unauthorized modification.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203617r958436_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.varlog:def:2 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000163 |
| Description | If audit information were to become compromised,
then forensic analysis and discovery of the true source of potentially
malicious system activity is impossible to achieve.
To ensure the veracity of audit information, the operating system must
protect audit information from unauthorized modification.
Audit information includes all information (e.g., audit records, audit
settings, audit reports) needed to successfully audit information system
activity. |
OVAL test results details
Check existence of /var/log directory oval:org.varlog:tst:5 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| true | /var/log/ | directory | 0 | 0 | 4096 | rwxr-xr-x |
The operating system must protect audit information
from unauthorized read access.xccdf_mil.disa.stig_rule_SV-203616r958434_rule mediumCCI-000162
The operating system must protect audit information from unauthorized read access.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203616r958434_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.varlog:def:2 |
| Time | 2026-06-21T02:00:05+00:00 |
| Severity | medium |
| Identifiers: | CCI-000162 |
| Description | Unauthorized disclosure of audit records can
reveal system and configuration data to attackers, thus compromising its
confidentiality.
Audit information includes all information (e.g., audit records, audit
settings, audit reports) needed to successfully audit operating system
activity. |
OVAL test results details
Check existence of /var/log directory oval:org.varlog:tst:5 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| true | /var/log/ | directory | 0 | 0 | 4096 | rwxr-xr-x |
The operating system must limit privileges to change
software resident within software libraries.xccdf_mil.disa.stig_rule_SV-203675r991560_rule mediumCCI-001499
The operating system must limit privileges to change software resident within software libraries.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203675r991560_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.LibraryPermissions:def:2 |
| Time | 2026-06-21T02:00:07+00:00 |
| Severity | medium |
| Identifiers: | CCI-001499 |
| Description | If the operating system were to allow any user
to make changes to software libraries, then those changes might be
implemented without undergoing the appropriate testing and approvals that
are part of a robust change management process.
This requirement applies to operating systems with software libraries that
are accessible and configurable, as in the case of interpreted languages.
Software libraries also include privileged programs which execute with
escalated privileges. Only qualified and authorized individuals shall be
allowed to obtain access to information system components for purposes of
initiating changes, including upgrades and modifications.
Script Verification:
To manually verify, ensure all directories and files in the /usr/lib
folder have both owner and group values of 'root' via 'ls -ld /usr/lib'
|
OVAL test results details
... and 36 more items.
... and 827 more items.
Check existence of /usr/lib directory oval:org.LibraryPermissions:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| true | /usr/lib/libxcb-dpms.so.0 | symbolic link | 0 | 0 | 20 | rwxrwxrwx |
| true | /usr/lib/libexpat.so.1.12.1 | regular | 0 | 0 | 201336 | rwxr-xr-x |
| true | /usr/lib/libxcb-randr.so.0 | symbolic link | 0 | 0 | 21 | rwxrwxrwx |
| true | /usr/lib/libxcb-dbe.so.0 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libXtst.so.6.1.0 | regular | 0 | 0 | 30840 | rwxr-xr-x |
| true | /usr/lib/libXdmcp.so.6.0.0 | regular | 0 | 0 | 29736 | rwxr-xr-x |
| true | /usr/lib/libjpeg.so.8 | symbolic link | 0 | 0 | 16 | rwxrwxrwx |
| true | /usr/lib/libBrokenLocale.so.1 | regular | 0 | 0 | 15616 | rwxr-xr-x |
| true | /usr/lib/libxcb-screensaver.so.0.0.0 | regular | 0 | 0 | 21440 | rwxr-xr-x |
| true | /usr/lib/libffi.so | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/libXi.so.6 | symbolic link | 0 | 0 | 14 | rwxrwxrwx |
| true | /usr/lib/libpng16.so.16 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libX11.so.6 | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/lib | symbolic link | 0 | 0 | 3 | rwxrwxrwx |
| true | /usr/lib/libbz2.so.1.0.8 | regular | 0 | 0 | 82944 | rwxr-xr-x |
| true | /usr/lib/libfontconfig.so.1.16.1 | regular | 0 | 0 | 421440 | rwxr-xr-x |
| true | /usr/lib/libthread_db.so.1 | regular | 0 | 0 | 54464 | rwxr-xr-x |
| true | /usr/lib/libzstd.so.1.5.7 | regular | 0 | 0 | 1222576 | rwxr-xr-x |
| true | /usr/lib/libjpeg.so.8.3.2 | regular | 0 | 0 | 486136 | rwxr-xr-x |
| true | /usr/lib/libxcb-randr.so.0.1.0 | regular | 0 | 0 | 99376 | rwxr-xr-x |
| true | /usr/lib/libresolv.so.2 | regular | 0 | 0 | 77256 | rwxr-xr-x |
| true | /usr/lib/libX11-xcb.so.1 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libmvec.so.1 | regular | 0 | 0 | 1062672 | rwxr-xr-x |
| true | /usr/lib/libbrotlidec.so.1.2.0 | regular | 0 | 0 | 63752 | rwxr-xr-x |
| true | /usr/lib/libXi.so.6.1.0 | regular | 0 | 0 | 87776 | rwxr-xr-x |
| true | /usr/lib/libpthread.so.0 | regular | 0 | 0 | 16400 | rwxr-xr-x |
| true | /usr/lib/libtasn1.so.6.6.5 | regular | 0 | 0 | 95984 | rwxr-xr-x |
| true | /usr/lib/libxcb-xvmc.so.0 | symbolic link | 0 | 0 | 20 | rwxrwxrwx |
| true | /usr/lib/libffi.so.8 | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/libxcb-screensaver.so.0 | symbolic link | 0 | 0 | 27 | rwxrwxrwx |
| true | /usr/lib/libmemusage.so | regular | 0 | 0 | 22176 | rwxr-xr-x |
| true | /usr/lib/libxcb-xkb.so.1.0.0 | regular | 0 | 0 | 162480 | rwxr-xr-x |
| true | /usr/lib/libxcb-present.so.0.0.0 | regular | 0 | 0 | 17536 | rwxr-xr-x |
| true | /usr/lib/libxcb-render.so.0.0.0 | regular | 0 | 0 | 80856 | rwxr-xr-x |
| true | /usr/lib/libm.so.6 | regular | 0 | 0 | 1230992 | rwxr-xr-x |
| true | /usr/lib/libc_malloc_debug.so.0 | regular | 0 | 0 | 63240 | rwxr-xr-x |
| true | /usr/lib/libstdc++.so.6.0.35-gdb.py | regular | 0 | 0 | 2927 | rw-r--r-- |
| true | /usr/lib/libXext.so.6 | symbolic link | 0 | 0 | 16 | rwxrwxrwx |
| true | /usr/lib/libstdc++.so.6 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libxcb-xinput.so.0.1.0 | regular | 0 | 0 | 209912 | rwxr-xr-x |
| true | /usr/lib/libcrypto.so | symbolic link | 0 | 0 | 14 | rwxrwxrwx |
| true | /usr/lib/libxcb-res.so.0 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/ld-linux-x86-64.so.2 | regular | 0 | 0 | 250792 | rwxr-xr-x |
| true | /usr/lib/libasound.so.2 | symbolic link | 0 | 0 | 18 | rwxrwxrwx |
| true | /usr/lib/libxcb-xv.so.0.0.0 | regular | 0 | 0 | 43392 | rwxr-xr-x |
| true | /usr/lib/libz.so.1 | symbolic link | 0 | 0 | 13 | rwxrwxrwx |
| true | /usr/lib/libgif.so.7 | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/libxcb-glx.so.0.0.0 | regular | 0 | 0 | 165368 | rwxr-xr-x |
| true | /usr/lib/libssl.so | symbolic link | 0 | 0 | 11 | rwxrwxrwx |
| true | /usr/lib/libxcb-damage.so.0 | symbolic link | 0 | 0 | 22 | rwxrwxrwx |
| true | /usr/lib/libzstd.so.1 | symbolic link | 0 | 0 | 16 | rwxrwxrwx |
| true | /usr/lib/librt.so.1 | regular | 0 | 0 | 16216 | rwxr-xr-x |
| true | /usr/lib/libxcb.so.1.1.0 | regular | 0 | 0 | 230928 | rwxr-xr-x |
| true | /usr/lib/libgif.so.7.2.0 | regular | 0 | 0 | 47712 | rwxr-xr-x |
| true | /usr/lib/libxcb-dbe.so.0.0.0 | regular | 0 | 0 | 22264 | rwxr-xr-x |
| true | /usr/lib/libdl.so.2 | regular | 0 | 0 | 15552 | rwxr-xr-x |
| true | /usr/lib/libasound.so.2.0.0 | regular | 0 | 0 | 1552216 | rwxr-xr-x |
| true | /usr/lib/libX11-xcb.so.1.0.0 | regular | 0 | 0 | 14880 | rwxr-xr-x |
| true | /usr/lib/libxcb-sync.so.1 | symbolic link | 0 | 0 | 20 | rwxrwxrwx |
| true | /usr/lib/libexpat.so.1 | symbolic link | 0 | 0 | 18 | rwxrwxrwx |
| true | /usr/lib/libbrotlidec.so.1 | symbolic link | 0 | 0 | 21 | rwxrwxrwx |
| true | /usr/lib/libxcb-damage.so.0.0.0 | regular | 0 | 0 | 16416 | rwxr-xr-x |
| true | /usr/lib/libcrypt.so.1 | symbolic link | 0 | 0 | 17 | rwxrwxrwx |
| true | /usr/lib/libstdc++.so.6.0.35 | regular | 0 | 0 | 3544448 | rwxr-xr-x |
| true | /usr/lib/libxcb-glx.so.0 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/liblcms2.so.2.0.19 | regular | 0 | 0 | 502408 | rwxr-xr-x |
| true | /usr/lib/libXtst.so.6 | symbolic link | 0 | 0 | 16 | rwxrwxrwx |
| true | /usr/lib/libxcb-res.so.0.0.0 | regular | 0 | 0 | 23056 | rwxr-xr-x |
| true | /usr/lib/libxcb-xtest.so.0.0.0 | regular | 0 | 0 | 16232 | rwxr-xr-x |
| true | /usr/lib/libxcb-record.so.0.0.0 | regular | 0 | 0 | 27864 | rwxr-xr-x |
| true | /usr/lib/libfreetype.so.6 | symbolic link | 0 | 0 | 21 | rwxrwxrwx |
| true | /usr/lib/libatopology.so.2 | symbolic link | 0 | 0 | 21 | rwxrwxrwx |
| true | /usr/lib/libxcb-composite.so.0 | symbolic link | 0 | 0 | 25 | rwxrwxrwx |
| true | /usr/lib/libnsl.so.1 | regular | 0 | 0 | 123216 | rwxr-xr-x |
| true | /usr/lib/libX11.so.6.4.0 | regular | 0 | 0 | 1473336 | rwxr-xr-x |
| true | /usr/lib/libXau.so.6.0.0 | regular | 0 | 0 | 21000 | rwxr-xr-x |
| true | /usr/lib/libgcc_s_asneeded.so | regular | 0 | 0 | 108 | rwxr-xr-x |
| true | /usr/lib/libxcb-xtest.so.0 | symbolic link | 0 | 0 | 21 | rwxrwxrwx |
| true | /usr/lib/libcrypto.a | regular | 0 | 0 | 29895920 | rw-r--r-- |
| true | /usr/lib/libp11-kit.so.0 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libxcb-record.so.0 | symbolic link | 0 | 0 | 22 | rwxrwxrwx |
| true | /usr/lib/libxcb-composite.so.0.0.0 | regular | 0 | 0 | 17320 | rwxr-xr-x |
| true | /usr/lib/libxcb-sync.so.1.0.0 | regular | 0 | 0 | 42344 | rwxr-xr-x |
| true | /usr/lib/libnss_files.so.2 | regular | 0 | 0 | 15144 | rwxr-xr-x |
| true | /usr/lib/libxcb-xinerama.so.0 | symbolic link | 0 | 0 | 24 | rwxrwxrwx |
| true | /usr/lib/libxcb.so.1 | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/libp11-kit.so.0.4.8 | regular | 0 | 0 | 3214800 | rwxr-xr-x |
| true | /usr/lib/libbrotlicommon.so.1 | symbolic link | 0 | 0 | 24 | rwxrwxrwx |
| true | /usr/lib/libssl.so.3 | regular | 0 | 0 | 1114096 | rwxr-xr-x |
| true | /usr/lib/libXext.so.6.4.0 | regular | 0 | 0 | 93872 | rwxr-xr-x |
| true | /usr/lib/libxcb-xf86dri.so.0.0.0 | regular | 0 | 0 | 27864 | rwxr-xr-x |
| true | /usr/lib/libturbojpeg.so.0.4.0 | regular | 0 | 0 | 613728 | rwxr-xr-x |
| true | /usr/lib/libxcb-xv.so.0 | symbolic link | 0 | 0 | 18 | rwxrwxrwx |
| true | /usr/lib/libxcb-shm.so.0 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libnss_dns.so.2 | regular | 0 | 0 | 15144 | rwxr-xr-x |
| true | /usr/lib/libnss_compat.so.2 | regular | 0 | 0 | 49408 | rwxr-xr-x |
| true | /usr/lib/libxcb-xf86dri.so.0 | symbolic link | 0 | 0 | 23 | rwxrwxrwx |
| true | /usr/lib/libffi.so.8.3.1 | regular | 0 | 0 | 67616 | rwxr-xr-x |
| true | /usr/lib/libssl.a | regular | 0 | 0 | 7832820 | rw-r--r-- |
| true | /usr/lib/libxcb-dpms.so.0.0.0 | regular | 0 | 0 | 17120 | rwxr-xr-x |
Check existence of /usr/lib directory oval:org.LibraryPermissions:tst:2 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| true | /usr/lib/libexpat.so.1.12.1 | regular | 0 | 0 | 201336 | rwxr-xr-x |
| true | /usr/lib/libXtst.so.6.1.0 | regular | 0 | 0 | 30840 | rwxr-xr-x |
| true | /usr/lib/libXdmcp.so.6.0.0 | regular | 0 | 0 | 29736 | rwxr-xr-x |
| true | /usr/lib/libBrokenLocale.so.1 | regular | 0 | 0 | 15616 | rwxr-xr-x |
| true | /usr/lib/libxcb-screensaver.so.0.0.0 | regular | 0 | 0 | 21440 | rwxr-xr-x |
| true | /usr/lib/libbz2.so.1.0.8 | regular | 0 | 0 | 82944 | rwxr-xr-x |
| true | /usr/lib/libfontconfig.so.1.16.1 | regular | 0 | 0 | 421440 | rwxr-xr-x |
| true | /usr/lib/libthread_db.so.1 | regular | 0 | 0 | 54464 | rwxr-xr-x |
| true | /usr/lib/libzstd.so.1.5.7 | regular | 0 | 0 | 1222576 | rwxr-xr-x |
| true | /usr/lib/libjpeg.so.8.3.2 | regular | 0 | 0 | 486136 | rwxr-xr-x |
| true | /usr/lib/libxcb-randr.so.0.1.0 | regular | 0 | 0 | 99376 | rwxr-xr-x |
| true | /usr/lib/libresolv.so.2 | regular | 0 | 0 | 77256 | rwxr-xr-x |
| true | /usr/lib/libmvec.so.1 | regular | 0 | 0 | 1062672 | rwxr-xr-x |
| true | /usr/lib/libbrotlidec.so.1.2.0 | regular | 0 | 0 | 63752 | rwxr-xr-x |
| true | /usr/lib/libXi.so.6.1.0 | regular | 0 | 0 | 87776 | rwxr-xr-x |
| true | /usr/lib/libpthread.so.0 | regular | 0 | 0 | 16400 | rwxr-xr-x |
| true | /usr/lib/libtasn1.so.6.6.5 | regular | 0 | 0 | 95984 | rwxr-xr-x |
| true | /usr/lib/libmemusage.so | regular | 0 | 0 | 22176 | rwxr-xr-x |
| true | /usr/lib/libxcb-xkb.so.1.0.0 | regular | 0 | 0 | 162480 | rwxr-xr-x |
| true | /usr/lib/libxcb-present.so.0.0.0 | regular | 0 | 0 | 17536 | rwxr-xr-x |
| true | /usr/lib/libxcb-render.so.0.0.0 | regular | 0 | 0 | 80856 | rwxr-xr-x |
| true | /usr/lib/libm.so.6 | regular | 0 | 0 | 1230992 | rwxr-xr-x |
| true | /usr/lib/libc_malloc_debug.so.0 | regular | 0 | 0 | 63240 | rwxr-xr-x |
| true | /usr/lib/libstdc++.so.6.0.35-gdb.py | regular | 0 | 0 | 2927 | rw-r--r-- |
| true | /usr/lib/libxcb-xinput.so.0.1.0 | regular | 0 | 0 | 209912 | rwxr-xr-x |
| true | /usr/lib/ld-linux-x86-64.so.2 | regular | 0 | 0 | 250792 | rwxr-xr-x |
| true | /usr/lib/libxcb-xv.so.0.0.0 | regular | 0 | 0 | 43392 | rwxr-xr-x |
| true | /usr/lib/libxcb-glx.so.0.0.0 | regular | 0 | 0 | 165368 | rwxr-xr-x |
| true | /usr/lib/librt.so.1 | regular | 0 | 0 | 16216 | rwxr-xr-x |
| true | /usr/lib/libxcb.so.1.1.0 | regular | 0 | 0 | 230928 | rwxr-xr-x |
| true | /usr/lib/libgif.so.7.2.0 | regular | 0 | 0 | 47712 | rwxr-xr-x |
| true | /usr/lib/libxcb-dbe.so.0.0.0 | regular | 0 | 0 | 22264 | rwxr-xr-x |
| true | /usr/lib/libdl.so.2 | regular | 0 | 0 | 15552 | rwxr-xr-x |
| true | /usr/lib/libasound.so.2.0.0 | regular | 0 | 0 | 1552216 | rwxr-xr-x |
| true | /usr/lib/libX11-xcb.so.1.0.0 | regular | 0 | 0 | 14880 | rwxr-xr-x |
| true | /usr/lib/libxcb-damage.so.0.0.0 | regular | 0 | 0 | 16416 | rwxr-xr-x |
| true | /usr/lib/libstdc++.so.6.0.35 | regular | 0 | 0 | 3544448 | rwxr-xr-x |
| true | /usr/lib/liblcms2.so.2.0.19 | regular | 0 | 0 | 502408 | rwxr-xr-x |
| true | /usr/lib/libxcb-res.so.0.0.0 | regular | 0 | 0 | 23056 | rwxr-xr-x |
| true | /usr/lib/libxcb-xtest.so.0.0.0 | regular | 0 | 0 | 16232 | rwxr-xr-x |
| true | /usr/lib/libxcb-record.so.0.0.0 | regular | 0 | 0 | 27864 | rwxr-xr-x |
| true | /usr/lib/libnsl.so.1 | regular | 0 | 0 | 123216 | rwxr-xr-x |
| true | /usr/lib/libX11.so.6.4.0 | regular | 0 | 0 | 1473336 | rwxr-xr-x |
| true | /usr/lib/libXau.so.6.0.0 | regular | 0 | 0 | 21000 | rwxr-xr-x |
| true | /usr/lib/libgcc_s_asneeded.so | regular | 0 | 0 | 108 | rwxr-xr-x |
| true | /usr/lib/libcrypto.a | regular | 0 | 0 | 29895920 | rw-r--r-- |
| true | /usr/lib/libxcb-composite.so.0.0.0 | regular | 0 | 0 | 17320 | rwxr-xr-x |
| true | /usr/lib/libxcb-sync.so.1.0.0 | regular | 0 | 0 | 42344 | rwxr-xr-x |
| true | /usr/lib/libnss_files.so.2 | regular | 0 | 0 | 15144 | rwxr-xr-x |
| true | /usr/lib/libp11-kit.so.0.4.8 | regular | 0 | 0 | 3214800 | rwxr-xr-x |
| true | /usr/lib/libssl.so.3 | regular | 0 | 0 | 1114096 | rwxr-xr-x |
| true | /usr/lib/libXext.so.6.4.0 | regular | 0 | 0 | 93872 | rwxr-xr-x |
| true | /usr/lib/libxcb-xf86dri.so.0.0.0 | regular | 0 | 0 | 27864 | rwxr-xr-x |
| true | /usr/lib/libturbojpeg.so.0.4.0 | regular | 0 | 0 | 613728 | rwxr-xr-x |
| true | /usr/lib/libnss_dns.so.2 | regular | 0 | 0 | 15144 | rwxr-xr-x |
| true | /usr/lib/libnss_compat.so.2 | regular | 0 | 0 | 49408 | rwxr-xr-x |
| true | /usr/lib/libffi.so.8.3.1 | regular | 0 | 0 | 67616 | rwxr-xr-x |
| true | /usr/lib/libssl.a | regular | 0 | 0 | 7832820 | rw-r--r-- |
| true | /usr/lib/libxcb-dpms.so.0.0.0 | regular | 0 | 0 | 17120 | rwxr-xr-x |
| true | /usr/lib/libz.so.1.3.2 | regular | 0 | 0 | 112752 | rwxr-xr-x |
| true | /usr/lib/libxcb-dri3.so.0.1.0 | regular | 0 | 0 | 27728 | rwxr-xr-x |
| true | /usr/lib/libanl.so.1 | regular | 0 | 0 | 15376 | rwxr-xr-x |
| true | /usr/lib/libbrotlicommon.so.1.2.0 | regular | 0 | 0 | 143240 | rwxr-xr-x |
| true | /usr/lib/libcrypto.so.3 | regular | 0 | 0 | 6115664 | rwxr-xr-x |
| true | /usr/lib/libfreetype.so.6.20.6 | regular | 0 | 0 | 896768 | rwxr-xr-x |
| true | /usr/lib/libxcb-xfixes.so.0.0.0 | regular | 0 | 0 | 45480 | rwxr-xr-x |
| true | /usr/lib/libxcb-shm.so.0.0.0 | regular | 0 | 0 | 17136 | rwxr-xr-x |
| true | /usr/lib/libc.so.6 | regular | 0 | 0 | 2365672 | rwxr-xr-x |
| true | /usr/lib/libxcb-xinerama.so.0.0.0 | regular | 0 | 0 | 17240 | rwxr-xr-x |
| true | /usr/lib/libbz2.so.1 | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/libXrender.so.1.3.0 | regular | 0 | 0 | 52384 | rwxr-xr-x |
| true | /usr/lib/libutil.so.1 | regular | 0 | 0 | 15376 | rwxr-xr-x |
| true | /usr/lib/libxcb-xvmc.so.0.0.0 | regular | 0 | 0 | 23120 | rwxr-xr-x |
| true | /usr/lib/libgcc_s.so.1 | regular | 0 | 0 | 197928 | rwxr-xr-x |
| true | /usr/lib/libpng16.so.16.58.0 | regular | 0 | 0 | 255280 | rwxr-xr-x |
| true | /usr/lib/libcrypt.so.1.1.0 | regular | 0 | 0 | 213256 | rwxr-xr-x |
| true | /usr/lib/libatopology.so.2.0.0 | regular | 0 | 0 | 144056 | rwxr-xr-x |
| true | /usr/lib/libxcb-shape.so.0.0.0 | regular | 0 | 0 | 17848 | rwxr-xr-x |
| true | /usr/lib/libxcb-dri2.so.0.0.0 | regular | 0 | 0 | 27856 | rwxr-xr-x |
| true | /usr/lib/libxcb-dpms.so.0 | symbolic link | 0 | 0 | 20 | rwxrwxrwx |
| true | /usr/lib/libxcb-dbe.so.0 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libxcb-randr.so.0 | symbolic link | 0 | 0 | 21 | rwxrwxrwx |
| true | /usr/lib/ossl-modules/fips.so | regular | 0 | 0 | 2601976 | rwxr-xr-x |
| true | /usr/lib/ossl-modules/cryptocomply-entropy.so | regular | 0 | 0 | 64272 | rwxr-xr-x |
| true | /usr/lib/locale/en_CA.utf8/LC_MEASUREMENT | regular | 0 | 0 | 23 | rw-r--r-- |
| true | /usr/lib/locale/en_BW.utf8/LC_MEASUREMENT | regular | 0 | 0 | 23 | rw-r--r-- |
| true | /usr/lib/locale/en_CA.utf8/LC_COLLATE | regular | 0 | 0 | 2586930 | rw-r--r-- |
| true | /usr/lib/libffi.so | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/libXi.so.6 | symbolic link | 0 | 0 | 14 | rwxrwxrwx |
| true | /usr/lib/libpng16.so.16 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libX11.so.6 | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/lib | symbolic link | 0 | 0 | 3 | rwxrwxrwx |
| true | /usr/lib/libX11-xcb.so.1 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libXtst.so.6 | symbolic link | 0 | 0 | 16 | rwxrwxrwx |
| true | /usr/lib/libxcb-res.so.0 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libxcb-screensaver.so.0 | symbolic link | 0 | 0 | 27 | rwxrwxrwx |
| true | /usr/lib/locale/en_IL/LC_TIME | regular | 0 | 0 | 3196 | rw-r--r-- |
| true | /usr/lib/libxcb-xvmc.so.0 | symbolic link | 0 | 0 | 20 | rwxrwxrwx |
| true | /usr/lib/libgif.so.7 | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/libssl.so | symbolic link | 0 | 0 | 11 | rwxrwxrwx |
The operating system must prohibit user installation of
system software without explicit privileged status.xccdf_mil.disa.stig_rule_SV-203716r982210_rule mediumCCI-003980
The operating system must prohibit user installation of system software without explicit privileged status.
| Rule ID | xccdf_mil.disa.stig_rule_SV-203716r982210_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.LibraryPermissions:def:2 |
| Time | 2026-06-21T02:00:07+00:00 |
| Severity | medium |
| Identifiers: | CCI-003980 |
| Description | Allowing regular users to install software,
without explicit privileges, creates the risk that untested or potentially
malicious software will be installed on the system. Explicit privileges
(escalated or administrative privileges) provide the regular user with
explicit capabilities and control that exceeds the rights of a regular user.
Operating system functionality will vary, and while users are not permitted
to install unapproved software, there may be instances where the
organization allows the user to install approved software packages, such as
from an approved software repository.
The operating system or software configuration management utility must
enforce control of software installation by users based upon what types of
software installations are permitted (e.g., updates and security patches to
existing software) and what types of installations are prohibited (e.g.,
software whose pedigree with regard to being potentially malicious is
unknown or suspect) by the organization.
Script Verification:
To manually verify, ensure all directories and files in the /usr/lib
folder have both owner and group values of 'root' via 'ls -ld /usr/lib'
|
OVAL test results details
... and 36 more items.
... and 827 more items.
Check existence of /usr/lib directory oval:org.LibraryPermissions:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| true | /usr/lib/libxcb-dpms.so.0 | symbolic link | 0 | 0 | 20 | rwxrwxrwx |
| true | /usr/lib/libexpat.so.1.12.1 | regular | 0 | 0 | 201336 | rwxr-xr-x |
| true | /usr/lib/libxcb-randr.so.0 | symbolic link | 0 | 0 | 21 | rwxrwxrwx |
| true | /usr/lib/libxcb-dbe.so.0 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libXtst.so.6.1.0 | regular | 0 | 0 | 30840 | rwxr-xr-x |
| true | /usr/lib/libXdmcp.so.6.0.0 | regular | 0 | 0 | 29736 | rwxr-xr-x |
| true | /usr/lib/libjpeg.so.8 | symbolic link | 0 | 0 | 16 | rwxrwxrwx |
| true | /usr/lib/libBrokenLocale.so.1 | regular | 0 | 0 | 15616 | rwxr-xr-x |
| true | /usr/lib/libxcb-screensaver.so.0.0.0 | regular | 0 | 0 | 21440 | rwxr-xr-x |
| true | /usr/lib/libffi.so | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/libXi.so.6 | symbolic link | 0 | 0 | 14 | rwxrwxrwx |
| true | /usr/lib/libpng16.so.16 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libX11.so.6 | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/lib | symbolic link | 0 | 0 | 3 | rwxrwxrwx |
| true | /usr/lib/libbz2.so.1.0.8 | regular | 0 | 0 | 82944 | rwxr-xr-x |
| true | /usr/lib/libfontconfig.so.1.16.1 | regular | 0 | 0 | 421440 | rwxr-xr-x |
| true | /usr/lib/libthread_db.so.1 | regular | 0 | 0 | 54464 | rwxr-xr-x |
| true | /usr/lib/libzstd.so.1.5.7 | regular | 0 | 0 | 1222576 | rwxr-xr-x |
| true | /usr/lib/libjpeg.so.8.3.2 | regular | 0 | 0 | 486136 | rwxr-xr-x |
| true | /usr/lib/libxcb-randr.so.0.1.0 | regular | 0 | 0 | 99376 | rwxr-xr-x |
| true | /usr/lib/libresolv.so.2 | regular | 0 | 0 | 77256 | rwxr-xr-x |
| true | /usr/lib/libX11-xcb.so.1 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libmvec.so.1 | regular | 0 | 0 | 1062672 | rwxr-xr-x |
| true | /usr/lib/libbrotlidec.so.1.2.0 | regular | 0 | 0 | 63752 | rwxr-xr-x |
| true | /usr/lib/libXi.so.6.1.0 | regular | 0 | 0 | 87776 | rwxr-xr-x |
| true | /usr/lib/libpthread.so.0 | regular | 0 | 0 | 16400 | rwxr-xr-x |
| true | /usr/lib/libtasn1.so.6.6.5 | regular | 0 | 0 | 95984 | rwxr-xr-x |
| true | /usr/lib/libxcb-xvmc.so.0 | symbolic link | 0 | 0 | 20 | rwxrwxrwx |
| true | /usr/lib/libffi.so.8 | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/libxcb-screensaver.so.0 | symbolic link | 0 | 0 | 27 | rwxrwxrwx |
| true | /usr/lib/libmemusage.so | regular | 0 | 0 | 22176 | rwxr-xr-x |
| true | /usr/lib/libxcb-xkb.so.1.0.0 | regular | 0 | 0 | 162480 | rwxr-xr-x |
| true | /usr/lib/libxcb-present.so.0.0.0 | regular | 0 | 0 | 17536 | rwxr-xr-x |
| true | /usr/lib/libxcb-render.so.0.0.0 | regular | 0 | 0 | 80856 | rwxr-xr-x |
| true | /usr/lib/libm.so.6 | regular | 0 | 0 | 1230992 | rwxr-xr-x |
| true | /usr/lib/libc_malloc_debug.so.0 | regular | 0 | 0 | 63240 | rwxr-xr-x |
| true | /usr/lib/libstdc++.so.6.0.35-gdb.py | regular | 0 | 0 | 2927 | rw-r--r-- |
| true | /usr/lib/libXext.so.6 | symbolic link | 0 | 0 | 16 | rwxrwxrwx |
| true | /usr/lib/libstdc++.so.6 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libxcb-xinput.so.0.1.0 | regular | 0 | 0 | 209912 | rwxr-xr-x |
| true | /usr/lib/libcrypto.so | symbolic link | 0 | 0 | 14 | rwxrwxrwx |
| true | /usr/lib/libxcb-res.so.0 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/ld-linux-x86-64.so.2 | regular | 0 | 0 | 250792 | rwxr-xr-x |
| true | /usr/lib/libasound.so.2 | symbolic link | 0 | 0 | 18 | rwxrwxrwx |
| true | /usr/lib/libxcb-xv.so.0.0.0 | regular | 0 | 0 | 43392 | rwxr-xr-x |
| true | /usr/lib/libz.so.1 | symbolic link | 0 | 0 | 13 | rwxrwxrwx |
| true | /usr/lib/libgif.so.7 | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/libxcb-glx.so.0.0.0 | regular | 0 | 0 | 165368 | rwxr-xr-x |
| true | /usr/lib/libssl.so | symbolic link | 0 | 0 | 11 | rwxrwxrwx |
| true | /usr/lib/libxcb-damage.so.0 | symbolic link | 0 | 0 | 22 | rwxrwxrwx |
| true | /usr/lib/libzstd.so.1 | symbolic link | 0 | 0 | 16 | rwxrwxrwx |
| true | /usr/lib/librt.so.1 | regular | 0 | 0 | 16216 | rwxr-xr-x |
| true | /usr/lib/libxcb.so.1.1.0 | regular | 0 | 0 | 230928 | rwxr-xr-x |
| true | /usr/lib/libgif.so.7.2.0 | regular | 0 | 0 | 47712 | rwxr-xr-x |
| true | /usr/lib/libxcb-dbe.so.0.0.0 | regular | 0 | 0 | 22264 | rwxr-xr-x |
| true | /usr/lib/libdl.so.2 | regular | 0 | 0 | 15552 | rwxr-xr-x |
| true | /usr/lib/libasound.so.2.0.0 | regular | 0 | 0 | 1552216 | rwxr-xr-x |
| true | /usr/lib/libX11-xcb.so.1.0.0 | regular | 0 | 0 | 14880 | rwxr-xr-x |
| true | /usr/lib/libxcb-sync.so.1 | symbolic link | 0 | 0 | 20 | rwxrwxrwx |
| true | /usr/lib/libexpat.so.1 | symbolic link | 0 | 0 | 18 | rwxrwxrwx |
| true | /usr/lib/libbrotlidec.so.1 | symbolic link | 0 | 0 | 21 | rwxrwxrwx |
| true | /usr/lib/libxcb-damage.so.0.0.0 | regular | 0 | 0 | 16416 | rwxr-xr-x |
| true | /usr/lib/libcrypt.so.1 | symbolic link | 0 | 0 | 17 | rwxrwxrwx |
| true | /usr/lib/libstdc++.so.6.0.35 | regular | 0 | 0 | 3544448 | rwxr-xr-x |
| true | /usr/lib/libxcb-glx.so.0 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/liblcms2.so.2.0.19 | regular | 0 | 0 | 502408 | rwxr-xr-x |
| true | /usr/lib/libXtst.so.6 | symbolic link | 0 | 0 | 16 | rwxrwxrwx |
| true | /usr/lib/libxcb-res.so.0.0.0 | regular | 0 | 0 | 23056 | rwxr-xr-x |
| true | /usr/lib/libxcb-xtest.so.0.0.0 | regular | 0 | 0 | 16232 | rwxr-xr-x |
| true | /usr/lib/libxcb-record.so.0.0.0 | regular | 0 | 0 | 27864 | rwxr-xr-x |
| true | /usr/lib/libfreetype.so.6 | symbolic link | 0 | 0 | 21 | rwxrwxrwx |
| true | /usr/lib/libatopology.so.2 | symbolic link | 0 | 0 | 21 | rwxrwxrwx |
| true | /usr/lib/libxcb-composite.so.0 | symbolic link | 0 | 0 | 25 | rwxrwxrwx |
| true | /usr/lib/libnsl.so.1 | regular | 0 | 0 | 123216 | rwxr-xr-x |
| true | /usr/lib/libX11.so.6.4.0 | regular | 0 | 0 | 1473336 | rwxr-xr-x |
| true | /usr/lib/libXau.so.6.0.0 | regular | 0 | 0 | 21000 | rwxr-xr-x |
| true | /usr/lib/libgcc_s_asneeded.so | regular | 0 | 0 | 108 | rwxr-xr-x |
| true | /usr/lib/libxcb-xtest.so.0 | symbolic link | 0 | 0 | 21 | rwxrwxrwx |
| true | /usr/lib/libcrypto.a | regular | 0 | 0 | 29895920 | rw-r--r-- |
| true | /usr/lib/libp11-kit.so.0 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libxcb-record.so.0 | symbolic link | 0 | 0 | 22 | rwxrwxrwx |
| true | /usr/lib/libxcb-composite.so.0.0.0 | regular | 0 | 0 | 17320 | rwxr-xr-x |
| true | /usr/lib/libxcb-sync.so.1.0.0 | regular | 0 | 0 | 42344 | rwxr-xr-x |
| true | /usr/lib/libnss_files.so.2 | regular | 0 | 0 | 15144 | rwxr-xr-x |
| true | /usr/lib/libxcb-xinerama.so.0 | symbolic link | 0 | 0 | 24 | rwxrwxrwx |
| true | /usr/lib/libxcb.so.1 | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/libp11-kit.so.0.4.8 | regular | 0 | 0 | 3214800 | rwxr-xr-x |
| true | /usr/lib/libbrotlicommon.so.1 | symbolic link | 0 | 0 | 24 | rwxrwxrwx |
| true | /usr/lib/libssl.so.3 | regular | 0 | 0 | 1114096 | rwxr-xr-x |
| true | /usr/lib/libXext.so.6.4.0 | regular | 0 | 0 | 93872 | rwxr-xr-x |
| true | /usr/lib/libxcb-xf86dri.so.0.0.0 | regular | 0 | 0 | 27864 | rwxr-xr-x |
| true | /usr/lib/libturbojpeg.so.0.4.0 | regular | 0 | 0 | 613728 | rwxr-xr-x |
| true | /usr/lib/libxcb-xv.so.0 | symbolic link | 0 | 0 | 18 | rwxrwxrwx |
| true | /usr/lib/libxcb-shm.so.0 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libnss_dns.so.2 | regular | 0 | 0 | 15144 | rwxr-xr-x |
| true | /usr/lib/libnss_compat.so.2 | regular | 0 | 0 | 49408 | rwxr-xr-x |
| true | /usr/lib/libxcb-xf86dri.so.0 | symbolic link | 0 | 0 | 23 | rwxrwxrwx |
| true | /usr/lib/libffi.so.8.3.1 | regular | 0 | 0 | 67616 | rwxr-xr-x |
| true | /usr/lib/libssl.a | regular | 0 | 0 | 7832820 | rw-r--r-- |
| true | /usr/lib/libxcb-dpms.so.0.0.0 | regular | 0 | 0 | 17120 | rwxr-xr-x |
Check existence of /usr/lib directory oval:org.LibraryPermissions:tst:2 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| true | /usr/lib/libexpat.so.1.12.1 | regular | 0 | 0 | 201336 | rwxr-xr-x |
| true | /usr/lib/libXtst.so.6.1.0 | regular | 0 | 0 | 30840 | rwxr-xr-x |
| true | /usr/lib/libXdmcp.so.6.0.0 | regular | 0 | 0 | 29736 | rwxr-xr-x |
| true | /usr/lib/libBrokenLocale.so.1 | regular | 0 | 0 | 15616 | rwxr-xr-x |
| true | /usr/lib/libxcb-screensaver.so.0.0.0 | regular | 0 | 0 | 21440 | rwxr-xr-x |
| true | /usr/lib/libbz2.so.1.0.8 | regular | 0 | 0 | 82944 | rwxr-xr-x |
| true | /usr/lib/libfontconfig.so.1.16.1 | regular | 0 | 0 | 421440 | rwxr-xr-x |
| true | /usr/lib/libthread_db.so.1 | regular | 0 | 0 | 54464 | rwxr-xr-x |
| true | /usr/lib/libzstd.so.1.5.7 | regular | 0 | 0 | 1222576 | rwxr-xr-x |
| true | /usr/lib/libjpeg.so.8.3.2 | regular | 0 | 0 | 486136 | rwxr-xr-x |
| true | /usr/lib/libxcb-randr.so.0.1.0 | regular | 0 | 0 | 99376 | rwxr-xr-x |
| true | /usr/lib/libresolv.so.2 | regular | 0 | 0 | 77256 | rwxr-xr-x |
| true | /usr/lib/libmvec.so.1 | regular | 0 | 0 | 1062672 | rwxr-xr-x |
| true | /usr/lib/libbrotlidec.so.1.2.0 | regular | 0 | 0 | 63752 | rwxr-xr-x |
| true | /usr/lib/libXi.so.6.1.0 | regular | 0 | 0 | 87776 | rwxr-xr-x |
| true | /usr/lib/libpthread.so.0 | regular | 0 | 0 | 16400 | rwxr-xr-x |
| true | /usr/lib/libtasn1.so.6.6.5 | regular | 0 | 0 | 95984 | rwxr-xr-x |
| true | /usr/lib/libmemusage.so | regular | 0 | 0 | 22176 | rwxr-xr-x |
| true | /usr/lib/libxcb-xkb.so.1.0.0 | regular | 0 | 0 | 162480 | rwxr-xr-x |
| true | /usr/lib/libxcb-present.so.0.0.0 | regular | 0 | 0 | 17536 | rwxr-xr-x |
| true | /usr/lib/libxcb-render.so.0.0.0 | regular | 0 | 0 | 80856 | rwxr-xr-x |
| true | /usr/lib/libm.so.6 | regular | 0 | 0 | 1230992 | rwxr-xr-x |
| true | /usr/lib/libc_malloc_debug.so.0 | regular | 0 | 0 | 63240 | rwxr-xr-x |
| true | /usr/lib/libstdc++.so.6.0.35-gdb.py | regular | 0 | 0 | 2927 | rw-r--r-- |
| true | /usr/lib/libxcb-xinput.so.0.1.0 | regular | 0 | 0 | 209912 | rwxr-xr-x |
| true | /usr/lib/ld-linux-x86-64.so.2 | regular | 0 | 0 | 250792 | rwxr-xr-x |
| true | /usr/lib/libxcb-xv.so.0.0.0 | regular | 0 | 0 | 43392 | rwxr-xr-x |
| true | /usr/lib/libxcb-glx.so.0.0.0 | regular | 0 | 0 | 165368 | rwxr-xr-x |
| true | /usr/lib/librt.so.1 | regular | 0 | 0 | 16216 | rwxr-xr-x |
| true | /usr/lib/libxcb.so.1.1.0 | regular | 0 | 0 | 230928 | rwxr-xr-x |
| true | /usr/lib/libgif.so.7.2.0 | regular | 0 | 0 | 47712 | rwxr-xr-x |
| true | /usr/lib/libxcb-dbe.so.0.0.0 | regular | 0 | 0 | 22264 | rwxr-xr-x |
| true | /usr/lib/libdl.so.2 | regular | 0 | 0 | 15552 | rwxr-xr-x |
| true | /usr/lib/libasound.so.2.0.0 | regular | 0 | 0 | 1552216 | rwxr-xr-x |
| true | /usr/lib/libX11-xcb.so.1.0.0 | regular | 0 | 0 | 14880 | rwxr-xr-x |
| true | /usr/lib/libxcb-damage.so.0.0.0 | regular | 0 | 0 | 16416 | rwxr-xr-x |
| true | /usr/lib/libstdc++.so.6.0.35 | regular | 0 | 0 | 3544448 | rwxr-xr-x |
| true | /usr/lib/liblcms2.so.2.0.19 | regular | 0 | 0 | 502408 | rwxr-xr-x |
| true | /usr/lib/libxcb-res.so.0.0.0 | regular | 0 | 0 | 23056 | rwxr-xr-x |
| true | /usr/lib/libxcb-xtest.so.0.0.0 | regular | 0 | 0 | 16232 | rwxr-xr-x |
| true | /usr/lib/libxcb-record.so.0.0.0 | regular | 0 | 0 | 27864 | rwxr-xr-x |
| true | /usr/lib/libnsl.so.1 | regular | 0 | 0 | 123216 | rwxr-xr-x |
| true | /usr/lib/libX11.so.6.4.0 | regular | 0 | 0 | 1473336 | rwxr-xr-x |
| true | /usr/lib/libXau.so.6.0.0 | regular | 0 | 0 | 21000 | rwxr-xr-x |
| true | /usr/lib/libgcc_s_asneeded.so | regular | 0 | 0 | 108 | rwxr-xr-x |
| true | /usr/lib/libcrypto.a | regular | 0 | 0 | 29895920 | rw-r--r-- |
| true | /usr/lib/libxcb-composite.so.0.0.0 | regular | 0 | 0 | 17320 | rwxr-xr-x |
| true | /usr/lib/libxcb-sync.so.1.0.0 | regular | 0 | 0 | 42344 | rwxr-xr-x |
| true | /usr/lib/libnss_files.so.2 | regular | 0 | 0 | 15144 | rwxr-xr-x |
| true | /usr/lib/libp11-kit.so.0.4.8 | regular | 0 | 0 | 3214800 | rwxr-xr-x |
| true | /usr/lib/libssl.so.3 | regular | 0 | 0 | 1114096 | rwxr-xr-x |
| true | /usr/lib/libXext.so.6.4.0 | regular | 0 | 0 | 93872 | rwxr-xr-x |
| true | /usr/lib/libxcb-xf86dri.so.0.0.0 | regular | 0 | 0 | 27864 | rwxr-xr-x |
| true | /usr/lib/libturbojpeg.so.0.4.0 | regular | 0 | 0 | 613728 | rwxr-xr-x |
| true | /usr/lib/libnss_dns.so.2 | regular | 0 | 0 | 15144 | rwxr-xr-x |
| true | /usr/lib/libnss_compat.so.2 | regular | 0 | 0 | 49408 | rwxr-xr-x |
| true | /usr/lib/libffi.so.8.3.1 | regular | 0 | 0 | 67616 | rwxr-xr-x |
| true | /usr/lib/libssl.a | regular | 0 | 0 | 7832820 | rw-r--r-- |
| true | /usr/lib/libxcb-dpms.so.0.0.0 | regular | 0 | 0 | 17120 | rwxr-xr-x |
| true | /usr/lib/libz.so.1.3.2 | regular | 0 | 0 | 112752 | rwxr-xr-x |
| true | /usr/lib/libxcb-dri3.so.0.1.0 | regular | 0 | 0 | 27728 | rwxr-xr-x |
| true | /usr/lib/libanl.so.1 | regular | 0 | 0 | 15376 | rwxr-xr-x |
| true | /usr/lib/libbrotlicommon.so.1.2.0 | regular | 0 | 0 | 143240 | rwxr-xr-x |
| true | /usr/lib/libcrypto.so.3 | regular | 0 | 0 | 6115664 | rwxr-xr-x |
| true | /usr/lib/libfreetype.so.6.20.6 | regular | 0 | 0 | 896768 | rwxr-xr-x |
| true | /usr/lib/libxcb-xfixes.so.0.0.0 | regular | 0 | 0 | 45480 | rwxr-xr-x |
| true | /usr/lib/libxcb-shm.so.0.0.0 | regular | 0 | 0 | 17136 | rwxr-xr-x |
| true | /usr/lib/libc.so.6 | regular | 0 | 0 | 2365672 | rwxr-xr-x |
| true | /usr/lib/libxcb-xinerama.so.0.0.0 | regular | 0 | 0 | 17240 | rwxr-xr-x |
| true | /usr/lib/libbz2.so.1 | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/libXrender.so.1.3.0 | regular | 0 | 0 | 52384 | rwxr-xr-x |
| true | /usr/lib/libutil.so.1 | regular | 0 | 0 | 15376 | rwxr-xr-x |
| true | /usr/lib/libxcb-xvmc.so.0.0.0 | regular | 0 | 0 | 23120 | rwxr-xr-x |
| true | /usr/lib/libgcc_s.so.1 | regular | 0 | 0 | 197928 | rwxr-xr-x |
| true | /usr/lib/libpng16.so.16.58.0 | regular | 0 | 0 | 255280 | rwxr-xr-x |
| true | /usr/lib/libcrypt.so.1.1.0 | regular | 0 | 0 | 213256 | rwxr-xr-x |
| true | /usr/lib/libatopology.so.2.0.0 | regular | 0 | 0 | 144056 | rwxr-xr-x |
| true | /usr/lib/libxcb-shape.so.0.0.0 | regular | 0 | 0 | 17848 | rwxr-xr-x |
| true | /usr/lib/libxcb-dri2.so.0.0.0 | regular | 0 | 0 | 27856 | rwxr-xr-x |
| true | /usr/lib/libxcb-dpms.so.0 | symbolic link | 0 | 0 | 20 | rwxrwxrwx |
| true | /usr/lib/libxcb-dbe.so.0 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libxcb-randr.so.0 | symbolic link | 0 | 0 | 21 | rwxrwxrwx |
| true | /usr/lib/ossl-modules/fips.so | regular | 0 | 0 | 2601976 | rwxr-xr-x |
| true | /usr/lib/ossl-modules/cryptocomply-entropy.so | regular | 0 | 0 | 64272 | rwxr-xr-x |
| true | /usr/lib/locale/en_CA.utf8/LC_MEASUREMENT | regular | 0 | 0 | 23 | rw-r--r-- |
| true | /usr/lib/locale/en_BW.utf8/LC_MEASUREMENT | regular | 0 | 0 | 23 | rw-r--r-- |
| true | /usr/lib/locale/en_CA.utf8/LC_COLLATE | regular | 0 | 0 | 2586930 | rw-r--r-- |
| true | /usr/lib/libffi.so | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/libXi.so.6 | symbolic link | 0 | 0 | 14 | rwxrwxrwx |
| true | /usr/lib/libpng16.so.16 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libX11.so.6 | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/lib | symbolic link | 0 | 0 | 3 | rwxrwxrwx |
| true | /usr/lib/libX11-xcb.so.1 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libXtst.so.6 | symbolic link | 0 | 0 | 16 | rwxrwxrwx |
| true | /usr/lib/libxcb-res.so.0 | symbolic link | 0 | 0 | 19 | rwxrwxrwx |
| true | /usr/lib/libxcb-screensaver.so.0 | symbolic link | 0 | 0 | 27 | rwxrwxrwx |
| true | /usr/lib/locale/en_IL/LC_TIME | regular | 0 | 0 | 3196 | rw-r--r-- |
| true | /usr/lib/libxcb-xvmc.so.0 | symbolic link | 0 | 0 | 20 | rwxrwxrwx |
| true | /usr/lib/libgif.so.7 | symbolic link | 0 | 0 | 15 | rwxrwxrwx |
| true | /usr/lib/libssl.so | symbolic link | 0 | 0 | 11 | rwxrwxrwx |
The operating system must include only approved
trust anchors in trust stores or certificate stores managed by the
organization.xccdf_mil.disa.stig_rule_SV-263659r982563_rule mediumCCI-004909
The operating system must include only approved trust anchors in trust stores or certificate stores managed by the organization.
| Rule ID | xccdf_mil.disa.stig_rule_SV-263659r982563_rule |
| Result | pass |
| Multi-check rule | no |
| OVAL Definition ID | oval:org.CABundleHash:def:1 |
| Time | 2026-06-21T02:00:07+00:00 |
| Severity | medium |
| Identifiers: | CCI-004909 |
| Description | Public key infrastructure (PKI) certificates are
certificates with visibility external to organizational systems and
certificates related to the internal operations of systems, such as
application-specific time services. In cryptographic systems with a
hierarchical structure, a trust anchor is an authoritative source (i.e., a
certificate authority) for which trust is assumed and not derived. A root
certificate for a PKI system is an example of a trust anchor. A trust store
or certificate store maintains a list of trusted root certificates.
Script Verification:
To check manually, confirm that the ca-certificates package has not been
altered, either by running apk audit or by checking that its sha256
value matches the trusted value.
|
OVAL test results details
Ensure CA bundle file exists oval:org.CABundleHash:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| not evaluated | /etc/ssl/certs/ca-certificates.crt | regular | 0 | 0 | 179359 | rw-r--r-- |
Check that CA bundle file matches expected SHA-256 hash oval:org.CABundleHash:tst:2 true
Following items have been found on the system:
| Result of item-state comparison | Filepath | Path | Filename | Hash type | Hash |
|---|---|---|---|---|---|
| true | /etc/ssl/certs/ca-certificates.crt | /etc/ssl/certs | ca-certificates.crt | SHA-256 | b8d837841b88bfaa1a0fa827cbca8e2576418dd47c9fc4bb7f1f9d89c83111b9 |