complianceascode / content Goto Github PK

rhel 6 -> 7 porting

rhel6->rhel7 porting needed

AU-5 b CCI-000140 SRG-OS-000047 The operating system must shut down by default upon audit failure (unless availability is an overriding concern). "It is critical that when the operating system is at risk of failing to process audit logs as required, it take action to mitigate the failure. Audit processing failures include: software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode.

When availability is an overriding concern, other approved actions in response to an audit failure are as follows:

(i) If the failure was caused by the lack of audit record storage capacity, the operating system must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner.

(ii) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the operating system must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server. "

permissions_grub_conf needs porting rhel6->rhel7

bootloader_password needs porting rhel6->rhel7

$ ./testcheck.py sshd_use_approved_ciphers.xml
Evaluating with OVAL tempfile : /tmp/sshd_use_approved_ciphersR7sWpB.xml
Writing results to : /tmp/sshd_use_approved_ciphersR7sWpB.xml-results
Definition oval:scap-security-guide.testing:def:281: false
Definition oval:scap-security-guide.testing:def:279: false
Definition oval:scap-security-guide.testing:def:278: error
Evaluation done.

group_owner_grub_conf needs porting rhel6->rhel7

It seems that current policy definitions do not allow sysctl configurations other than /etc/sysctl.conf
and it may be wrong, and /usr/lib/sysctl.d/.conf, /run/sysctl.d/.conf and /etc/sysctl.d/*.conf
along with live sysctl configurations (ex. net.ipv4.ip_forward by libvirtd) should also be checked, IMHO.

• Even in RHEL 6, /etc/sysctl.d/*.conf is supported. see also: apply_sysctl() in /etc/rc.d/init.d/functions
• systemd-sysctl.service (systemd) in Fedora and RHEl 7 looks /usr/lib/sysctl.d/.conf, /run/sysctl.d/.conf and /etc/sysctl.d/*.conf; see also: sysctl.d(5) and systemd-sysctl.service(8)

I don't know it's possible to write a rule (?) to check for multiple files in oval but 'sysctl_test' [1]
might be an alternative, perhaps.

[1] https://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/unix-definitions-schema.html

Test

Check returns a fail when it should pass showing an unlock time of 604800
Check looks for “auth sufficient” rather than the “auth [default=die]” listed in the STIG.
It does detect “auth sufficient” properly it just is the wrong system variable to be checking.

IA-5 (2) (a) CCI-000185 SRG-OS-000066 The operating system, for PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor. "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."

rhel 6 --> rhel7

AC-11 a CCI-000058 SRG-OS-000030 The operating system must provide the capability for users to directly initiate a session lock. "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."

AC-7 a CCI-000044 SRG-OS-000021 The operating system must enforce the limit of three consecutive invalid logon attempts by a user during a 15 minute time period. By limiting the number of failed login 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.

XCCDF groupowner_rsyslog_files needs OVAL (existing is blank template)

user_owner_grub_conf needs to be ported from rhel6 to rhel7

AC-11 (1) CCI-000060 SRG-OS-000031 The operating system must conceal, via the session lock, information previously visible on the display with a publicly viewable image. "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.

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."

AC-17 (2) CCI-000068 SRG-OS-000033 The operating system must implement DoD-approved encryption to protect the confidentiality of remote access sessions. "Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session.

Remote access is access to DoD non-public 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 mechanism is selected based on the security categorization of the information."

CCI-000016 SRG-OS-000002 The operating system must automatically remove or disable temporary user accounts after 72 hours. "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. "

rhel6 -> rhel7 porting

AU-5 a CCI-000139 SRG-OS-000046 The operating system must alert the IAO and SA (at a minimum) in the event of an audit processing failure. "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."

Returns a pass when according to part of the SCC check and the manual check it should fail.

AC-10 CCI-000054 SRG-OS-000027 The operating system must limit the number of concurrent sessions to an organization-defined number for all accounts and/or account types. "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 limiting 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."

AC-8 b CCI-000050 SRG-OS-000024 The operating system must retain the Standard Mandatory DoD Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access. "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"". "

IA-5 (1) (a) CCI-000192 SRG-OS-000069 The operating system must enforce password complexity by requiring that at least one uppercase character be used. "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 determine 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."

Returns a pass when manual check and part of automated check return as failing.

AU-3 (1) CCI-000135 SRG-OS-000042 The operating system must generate audit records containing the full-text recording of privileged commands or the individual identities of group account users. "Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

Organizations consider limiting the additional audit information to only that information explicitly needed for specific audit requirements. The additional information required is dependent on the type of information (i.e., sensitivity of the data and the environment within which it resides). At a minimum, the organization must audit either full-text recording of privileged commands or the individual identities of group users, or both. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

In addition, the operating system must have the capability to include organization-defined additional (more detailed) information in the audit records for audit events. "

AC-11 b CCI-000056 SRG-OS-000028 The operating system must retain the session lock until the user reestablishes access using established identification and authentication procedures. "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. "

IA-5 (1) (a) CCI-000194 SRG-OS-000071 Operating systems must enforce password complexity by requiring that at least one numeric character be used. "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 determine 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."

SRG-OS-000118 CCI-000795 The operating system must manage information
system identifiers for users and devices by disabling the user
identifier after an organization-defined time period of inactivity.

Basically, it uses the following format:

auth required pam_lastlog.so inactive=35

It's a much cleaner way to do this rather than modifying the useradd
command. I plan to use that since RHEL is really starting to take off
here and RHEL 6.4 is going to be my standard if possible.

rhel6->rhel7 porting

AC-2 (3) CCI-000017 SRG-OS-000003 The operating system must automatically disable accounts after a 35 day period of account inactivity. "Attackers that are able to exploit an inactive account can potentially obtain and maintain undetected access to an application. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Operating systems need to track periods of user inactivity and disable accounts after 35 days of inactivity. Such a process greatly reduces the risk that accounts will be hijacked, leading to a data compromise.

This policy does not apply to either emergency accounts or infrequently used accounts. Infrequently used accounts are local login administrator accounts used by system administrators when network or normal logon/access is not available. Emergency accounts are administrator accounts created in response to crisis situations. "

OVAL verifies ip[6]tables is enabled, while XCCDF verifies that it is running. Need to sync.

IA-5 (1) (a) CCI-000193 SRG-OS-000070 The operating system must enforce password complexity by requiring that at least one lowercase character be used. "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 determine 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."

Output of duplicate ID usage notification below when running make for Fedora and RHEL 6 & 7. Should be investigated, and if necessary, patch created.

Notification: this ID is used more than once and should represent equivalent elements: login_banner_text
Notification: this ID is used more than once and should represent equivalent elements: test_unix_family
Notification: this ID is used more than once and should represent equivalent elements: state_unix_family
Notification: this ID is used more than once and should represent equivalent elements: obj_unix_family
Notification: this ID is used more than once and should represent equivalent elements: test_rhel_workstation
Notification: this ID is used more than once and should represent equivalent elements: state_rhel_workstation
Notification: this ID is used more than once and should represent equivalent elements: obj_rhel_workstation
Notification: this ID is used more than once and should represent equivalent elements: test_rhel_server
Notification: this ID is used more than once and should represent equivalent elements: state_rhel_server
Notification: this ID is used more than once and should represent equivalent elements: obj_rhel_server
Notification: this ID is used more than once and should represent equivalent elements: var_accounts_user_umask
Notification: this ID is used more than once and should represent equivalent elements: var_accounts_user_umask
Notification: this ID is used more than once and should represent equivalent elements: var_accounts_user_umask

AC-11 a CCI-000057 SRG-OS-000029 The operating system must initiate a session lock after a 15-minute period of inactivity. "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. "

AU-12 a CCI-000169 SRG-OS-000062 The operating system must provide audit record generation capability for DoD-defined auditable events for all operating system components. "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:

(i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);

(ii) 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;

(iii) All account creations, modifications, disabling, and terminations; and

(iv) All kernel module load, unload, and restart actions."

AC-8 a CCI-000048 SRG-OS-000023 The operating system must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. "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 DTM-08-060. Use the following verbiage for operating system 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."""

Both the latest Fedora and RHEL 7 use dconf instead of gconf. The XCCDF and OVAL content need to be migrated from gconf to dconf settings.

List of OVAL content:
gconf_gnome_disable_automount.xml
gconf_gnome_disable_thumbnailers.xml
gconf_gnome_screensaver_idle_activation_enabled.xml
gconf_gnome_screensaver_idle_delay.xml
gconf_gnome_screensaver_lock_enabled.xml
gconf_gnome_screensaver_mode_blank.xml
banner_gui_enabled.xml
set_gdm_login_banner_text.xml

AU-3 CCI-000134 SRG-OS-000041 The operating system must produce audit records containing information to establish the outcome of the events. "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."

AU-12 c CCI-000172 SRG-OS-000064 The operating system must generate audit records when successful/unsuccessful attempts to access privileges occur. "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). "