---
# In BSI Basic Protection are multiple Requirements in one control.
# i.e. there are multiple sentences, some including a RFC2119 keyword
# Since we must increase granularity to create a precise control,
# we number each sentence with a RFC2119 keyword as a section, grouping sentences, which are logically connected.
# we number inline in brackets, so the lookup is easy
# we reference these numbers in comments over each rule or group of rules
policy: 'BSI-SYS-1-1-RHEL9'
title: 'SYS.1.1 General Server (RHEL9)'
id: bsi_sys_1_1_rhel9
version: '1.0'
source: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Grundschutz/International/bsi_it_gs_comp_2022.pdf

levels:
    - id: basic
    - id: standard
      inherits_from:
          - basic
    - id: elevated
      inherits_from:
          - standard

reference_type: bsi
product: rhel9

controls:
    - id: SYS.1.1.A1
      title: Appropriate Installation
      levels:
          - basic
      description: |-
          (1) Servers MUST be operated in locations that may only be accessed by authorised persons.
          (2) Servers MUST therefore be set up and installed in data centres, computer rooms, or lockable server rooms (see the corresponding modules in the INF Infrastructure layer). (3) Servers MUST NOT be used as personal computers (4) IT systems used as workstations MUST NOT be used as servers.
      notes: |-
          This requirement must be implemented organizationally and cannot be checked technically
      status: manual

    - id: SYS.1.1.A2
      title: User Authentication on Servers
      levels:
          - basic
      description: |-
          (1) Authentication methods adequate for the protection needs at hand MUST be used when users and services log into servers. (2) This SHOULD be taken into account for administrative access in particular. (3) Central, network-based authentication services SHOULD be used whenever possible.
      notes: |-
          Section 1,2: sshd configuration, NoPermitRootLogin,PAM
          Section 3: AD Integration, IdM?
      status: pending

    - id: SYS.1.1.A3
      title: ELIMINATED
      levels:
          - basic
      description: |-
          This requirement has been eliminated.
      notes: |-
          This requirement has been eliminated.
      status: not applicable

    - id: SYS.1.1.A4
      title: ELIMINATED
      levels:
          - basic
      description: |-
          This requirement has been eliminated.
      notes: |-
          This requirement has been eliminated.
      status: not applicable

    - id: SYS.1.1.A5
      title: Protection of Interfaces
      levels:
          - basic
      description: |-
          (1) It MUST be ensured that only specified removable storage media and other devices can be
          connected to servers. All interfaces that are no longer needed must be disabled.
      notes: |-
          Section 1: If you dont utilize specific software to control the allowed devices for usb ports,
          you can ensure compliance by disabling the usb port completely.
          Interfaces is ambigious, it is focussed on usb etc. not on network.
      status: automated
      rules:
      # Section 1
      # USB
          - grub2_nousb_argument
          - bios_disable_usb_boot
          - kernel_module_usb-storage_disabled
      # Automount
          - service_autofs_disabled
      # Firewire
          - kernel_module_firewire-core_disabled

    - id: SYS.1.1.A6
      title: Disabling Unnecessary Services
      levels:
          - basic
      description: |-
          (1) All unnecessary services and applications — particularly network services — MUST be
          disabled or uninstalled. (2) All unused functions in firmware MUST also be disabled.
          (3) On servers, the disk space allotted to both individual users and applications SHOULD be
          restricted appropriately.
          (4) The decisions taken in this regard SHOULD be documented in a way that makes it clear which
          configuration and software equipment was chosen for servers.
      notes: |-
          Section 1: We can conclude for servers, that wireless protocols are unnecessary
          Section 4: Documentation and organizational tasks.
      status: partial
      rules:
      # Section 1, 2
          - mask_nonessential_services
          - configure_firewalld_ports
          - kernel_module_bluetooth_disabled
          - kernel_module_cfg80211_disabled
          - kernel_module_iwlmvm_disabled
          - kernel_module_iwlwifi_disabled
          - kernel_module_mac80211_disabled
          - service_bluetooth_disabled
          - wireless_disable_in_bios
          - wireless_disable_interfaces
      # Section 3
          - partition_for_home
          - partition_for_opt
          - partition_for_var
          - partition_for_var_log
          - partition_for_usr
          - partition_for_tmp
          - partition_for_var_tmp

    - id: SYS.1.1.A7
      title: ELIMINATED
      levels:
          - basic
      description: |-
          This requirement has been eliminated.
      notes: |-
          This requirement has been eliminated.
      status: not applicable

    - id: SYS.1.1.A8
      title: ELIMINATED
      levels:
          - basic
      description: |-
          This requirement has been eliminated.
      notes: |-
          This requirement has been eliminated.
      status: not applicable

    - id: SYS.1.1.A9
      title: Using Anti-Virus Programs on Servers
      levels:
          - basic
      description: |-
          (1) Whether virus protection programs can and should be used MUST be checked depending on the
          operating system installed, the services provided, and other existing protection mechanisms of
          the server in question. (2) Where available, concrete statements from the relevant operating
          system modules of the IT-Grundschutz Compendium on whether virus protection is necessary MUST
          be considered.
      notes: |-
          Section 1,2: Antivirus software on linux systems is more useful, if the servers provide any
          file or mailservices to endpoints.
      status: automated
      rules:
          - install_antivirus
          - install_endpoint_security_software

    - id: SYS.1.1.A10
      title: Logging
      levels:
          - basic
      description: |-
          (1) In general, all security-relevant system events MUST be logged, including the following at
          minimum:
          • (2) System starts and reboots
          • (3) Successful and failed login attempts (operating system and application software)
          • (4) Failed authorisation checks
          • (5) Blocked data flows (violations of ACLs or firewall rules)
          • (6) Creation of or changes to users, groups, and authorisations
          • (7) Security-relevant error messages (e.g. hardware defects, exceeded capacity limits)
          • (8) Warnings from security systems (e.g. virus protection)
      notes: |-
          This whole requirement is more specifically implemented in the CIS hardening guide, which also
          defines permissions to protect against manipulations.
          Section 7 and 8 are not addressed explicitly with rules, as 8 is specific for the AV software
          and 7 is quite broad.
          # OPS.1.1.5: Logging Anforderung anschauen
          # AIDE
          Section 2: Only in system logs, not in specialized audit logs
          Section 5: Identify how firewalld logs and if we could use that
      status: automated
      rules:
      # ensure auditd is installed
          - package_audit_installed
          - package_audit-libs_installed
      # ensure auditd is enabled
          - service_auditd_enabled
      # Section 2 (start / reboot)
          - grub2_audit_argument
          - grub2_audit_backlog_limit_argument
          - var_audit_backlog_limit=8192
      # Section 3 (login)
          - audit_rules_session_events
          - audit_rules_login_events_faillock
          - audit_rules_login_events_lastlog
          - var_accounts_passwords_pam_faillock_dir=run
      # Section 4 (authorization)
          - audit_rules_sysadmin_actions
          - audit_rules_suid_auid_privilege_function
          - audit_sudo_log_events
          - audit_rules_privileged_commands
          - audit_rules_execution_chcon
          - audit_rules_execution_setfacl
      # Section 5 (dataflows / firewall)
          - audit_rules_dac_modification_chmod
          - audit_rules_dac_modification_chown
          - audit_rules_dac_modification_fchmod
          - audit_rules_dac_modification_fchmodat
          - audit_rules_dac_modification_fchown
          - audit_rules_dac_modification_fchownat
          - audit_rules_dac_modification_fremovexattr
          - audit_rules_dac_modification_fsetxattr
          - audit_rules_dac_modification_lchown
          - audit_rules_dac_modification_lremovexattr
          - audit_rules_dac_modification_lsetxattr
          - audit_rules_dac_modification_removexattr
          - audit_rules_dac_modification_setxattr
      # Section 6 (users and groups)
          - audit_rules_usergroup_modification_group
          - audit_rules_usergroup_modification_gshadow
          - audit_rules_usergroup_modification_opasswd
          - audit_rules_usergroup_modification_passwd
          - audit_rules_usergroup_modification_shadow
          - audit_rules_privileged_commands_usermod

    - id: SYS.1.1.A11
      title: Defining a Security Policy for Servers
      levels:
          - standard
      description: |-
          (1) Based on the general security policy of the organisation in question, the requirements for
          servers SHOULD be specified in a separate security policy. (2) This policy SHOULD be known to
          all administrators and other persons involved in the procurement and operation of servers and
          be integral to their work. (3) The implementation of the policy's requirements SHOULD be
          checked at regular intervals. (4) The results SHOULD be appropriately documented.
      notes: |-
          This requirement must be implemented organizationally.
          If we interprete this towards hardening, the CIS Profile could be used
      status: manual

    - id: SYS.1.1.A12
      title: Planning the Use of Servers
      levels:
          - standard
      description: |-
          Each server system SHOULD be suitably planned. In this process, the following points
          SHOULD be taken into account at minimum:
          • Selection of the hardware platform, operating system, and application software
          • Hardware capacity (performance, memory, bandwidth, etc)
          • Type and number of communication interfaces
          • Power consumption, thermal load, space requirements, and structural shape
          • Administrative access points (see SYS.1.1.A5 Protection of Administration Interfaces)
          • User access
          • Logging (see SYS.1.1.A10 Logging).
          • Updates for operating systems and applications
          • Integration into system and network management, backups, and protection systems
          (virus protection, IDS, etc)
          All decisions taken in the planning phase SHOULD be documented in such a way that they can
          be understood at any future point in time.
      notes: |-
          This requirement must be implemented organizationally.
          Some parts could be technically checked, i.e. if repositories are configureg, if AV is
          installed and therelike.
      status: manual

    - id: SYS.1.1.A13
      title: Procurement of Servers
      levels:
          - standard
      description: |-
          Prior to procuring one or more servers, a requirements list SHOULD be drawn up that can be
          used to evaluate the products available on the market.
      notes: |-
          This requirement must be implemented organizationally.
      status: manual

    - id: SYS.1.1.A14
      title: ELIMINATED
      levels:
          - standard
      description: |-
          This requirement has been eliminated.
      notes: |-
          This requirement has been eliminated.
      status: not applicable

    - id: SYS.1.1.A15
      title: Stable and Uninterruptible Power Supply [Building Services]
      levels:
          - standard
      description: |-
          (1) Every server SHOULD be connected to an uninterruptible power supply (UPS).
      notes: |-
          This requirement must be implemented organizationally.
      status: manual

    - id: SYS.1.1.A16
      title: Secure Basic Configuration of Servers
      levels:
          - standard
      description: |-
          (1) The basic settings of servers SHOULD be checked and, where necessary, adapted to the
          specifications of the security policy at hand. (2) Clients SHOULD only be connected to the
          Internet after the installation and configuration have been completed.
      notes: |-
          One could argue, that this is done with this profile. Or could utilize the CIS Benchmark again,
          if CIS is the security policy
      status: inherently met
    # rules:

    - id: SYS.1.1.A17
      title: ELIMINATED
      levels:
          - standard
      description: |-
          This requirement has been eliminated.
      notes: |-
          This requirement has been eliminated.
      status: not applicable

    - id: SYS.1.1.A18
      title: ELIMINATED
      levels:
          - standard
      description: |-
          This requirement has been eliminated.
      notes: |-
          This requirement has been eliminated.
      status: not applicable

    - id: SYS.1.1.A19
      title: Configuring Local Packet Filters
      levels:
          - standard
      description: |-
          (1) Based on a set of rules, existing local packet filters SHOULD be designed to limit
          incoming and outgoing communications to the necessary communication partners, communication
          protocols, ports, and interfaces. (2) The identity of remote systems and the integrity of
          corresponding connections SHOULD be protected cryptographically.
      notes: |-
          Section 1: This can be addressed by utilizing firewalld or therelike
          Section 2: this must be configured on the application layer
          # deactivate WebConsole to circumvent TLS
      status: partial
      rules:
      # Section 1
          - service_firewalld_enabled
          - package_firewalld_installed
          - unnecessary_firewalld_services_ports_disabled
          - set_firewalld_appropriate_zone

    - id: SYS.1.1.A20
      title: ELIMINATED
      levels:
          - standard
      description: |-
          This requirement has been eliminated.
      notes: |-
          This requirement has been eliminated.
      status: not applicable

    - id: SYS.1.1.A21
      title: Operational Documentation for Servers
      levels:
          - standard
      description: |-
          (1) Operational tasks that are carried out on a server SHOULD be clearly documented in terms
          of what has been done, when, and by whom. (2) In particular, the documentation SHOULD make
          configuration changes transparent. (3) Security-relevant responsibilities, such as who is
          authorised to install new hard disks, SHOULD be documented. (4) Everything that can be
          documented automatically SHOULD be documented automatically. (5) The documentation SHOULD be
          protected against unauthorised access and loss.
      notes: |-
          This requirement must be implemented organizationally.
      status: manual

    - id: SYS.1.1.A22
      title: Integration into Contingency Planning
      levels:
          - standard
      description: |-
          (1) Servers SHOULD be taken into account in business continuity management processes.
          (2) To this end, the contingency requirements for the system in question SHOULD be determined
          and appropriate contingency procedures implemented—for example, by drawing up recovery plans
          or securely storing passwords and cryptographic keys.
      notes: |-
          This requirement must be implemented organizationally.
      status: manual

    - id: SYS.1.1.A23
      title: Monitoring Systems and Servers
      levels:
          - standard
      description: |-
          (1) Server systems SHOULD be integrated into an appropriate system monitoring concept.
          (2) The status and functionality of these systems and the services operated on them SHOULD be
          continuously monitored. (3) Error conditions and defined thresholds that are exceeded SHOULD
          be reported to the operating personnel.
      notes: |-
          Monitoring is a very specific and organization dependend task. therefore we do not
          check this automatically
      status: manual
    # rules:
    # there does not seem to be a rule for that

    - id: SYS.1.1.A24
      title: Security Checks for Servers
      levels:
          - standard
      description: |-
          (1) Servers SHOULD be subjected to regular security tests to check their compliance with the
          applicable security requirements and identify possible vulnerabilities. (2) In particular,
          these security tests SHOULD be performed on servers with external interfaces. (3) To prevent
          indirect attacks via infected systems in an organisation’s own network, internal server
          systems SHOULD also be checked accordingly at defined intervals. (4) Whether the security
          checks can be realised automatically—by means of suitable scripts, for example—SHOULD be
          examined.
      notes: |-
          This is met due to the usage of this compliance profile.
      status: inherently met

    - id: SYS.1.1.A25
      title: Controlled Decommissioning of a Server
      levels:
          - standard
      description: |-
          (1) When decommissioning a server, it SHOULD be ensured that no important data that might
          still be present on the storage media is lost and no sensitive data remains.
          (2) There SHOULD be an overview of the data stored in each location on the server.
          (3) Furthermore, it SHOULD be ensured that services offered by the server will be taken over
          by another server when necessary.
          (4) A checklist SHOULD be created that is to be completed when decommissioning a server.
          (5) This checklist SHOULD at least include aspects related to backing up data, migrating
          services, and subsequently deleting all data in a secure manner.
      notes: |-
          This requirement must be implemented organizationally.
      status: manual

    - id: SYS.1.1.A35
      title: Drawing Up and Maintaining an Operating Manual
      levels:
          - standard
      description: |-
          (1) An operating manual SHOULD be drawn up. (2) It SHOULD document all the rules, requirements,
          and settings that are necessary in operating servers. (3) There SHOULD be a specific operating
          manual for every type of server. (4) Each operating manual SHOULD be updated at regular
          intervals. (5) Operating manuals SHOULD be protected against unauthorised access. (6) Operating
          manuals SHOULD be available in emergencies.
      notes: |-
          This requirement must be implemented organizationally.
      status: manual

    - id: SYS.1.1.A37
      title: Encapsulation of Security-Critical Applications and Operating System Components
      levels:
          - standard
      description: |-
          (1) In order to prevent an attacker from accessing the operating system or other applications and
          prevent access from the operating system to files that are particularly sensitive, applications
          and operating system components (such as authentication or certificate verification) SHOULD
          be specially encapsulated according to their protection needs or isolated from other
          applications and operating system components. (2) Particular attention SHOULD be paid to
          security-critical applications that work with data from insecure sources (e.g. web browsers and
          office communication applications)
      notes: |-
          Section 1-2: This can be done by utilizing SELinux for enhanced protection and/or container
          technology (Microsegmentation)
      status: automated
      rules:
          - package_libselinux_installed
          - grub2_enable_selinux
          - selinux_not_disabled
          - var_selinux_policy_name=targeted
          - selinux_policytype
          - var_selinux_state=enforcing
          - selinux_state
          - selinux_confinement_of_daemons

    - id: SYS.1.1.A26
      title: ELIMINATED
      levels:
          - elevated
      description: |-
          This requirement has been eliminated.
      notes: |-
          This requirement has been eliminated.
      status: not applicable

    - id: SYS.1.1.A27
      title: Host-Based Attack Detection
      levels:
          - elevated
      description: |-
          (1) Host-based attack detection systems (also referred to as host-based intrusion detection
          systems, IDS, or intrusion prevention systems, IPS) SHOULD be used to monitor system
          behaviour for abnormalities and misuse. (2) The IDS/IPS mechanisms used SHOULD be
          appropriately selected, configured, and thoroughly tested. (3) If an attack has been detected,
          the operating personnel SHOULD be alerted in an appropriate manner.
          (4) Using operating system mechanisms or suitable additional products, changes made to system
          files and configuration settings SHOULD be checked, restricted, and reported.
      notes: |-
          Section 1: Can only be checked manually.
          Section 2,3: this is an organizational requirement
          Section 4: AIDE could be leveraged as a system mechanism
      status: partial
      rules:
      # Section 1
          - install_hids
      # Section 4
          - package_aide_installed
          - aide_scan_notification
          - aide_periodic_cron_checking
      # currently not in rhel9, might cause errors
      # - aide_periodic_checking_systemd_timer
      # currently not in rhel9, causes massive error with filesystem walk
      # - aide_disable_silentreports
          - aide_build_database

          - rpm_verify_hashes
          - rpm_verify_ownership

      related_rules:
      # while rpm_verify_permissions is a part of how to detect changes, it conflicts
      # with permission hardening rules like the cron_permissions rules and therelike.
      # it is more important to harden the permissions to prevent change, than it is to
      # ensure that the permissions are the same as in the rpm database.
          - rpm_verify_permissions

    - id: SYS.1.1.A28
      title: Increasing Availability Through Redundancy
      levels:
          - elevated
      description: |-
          (1) Server systems with high availability requirements SHOULD be protected adequately against
          failures. (2) At minimum, suitable redundancies SHOULD be available and maintenance contracts
          concluded with the respective suppliers. (3) Whether high-availability architectures with
          automatic failover (across various sites, if necessary) are required in the case of very high
          requirements SHOULD be checked.
      notes: |-
          this is an organizational requirement
      status: manual

    - id: SYS.1.1.A29
      title: ELIMINATED
      levels:
          - elevated
      description: |-
          This requirement has been eliminated.
      notes: |-
          This requirement has been eliminated.
      status: not applicable

    - id: SYS.1.1.A30
      title: One Service per Server
      levels:
          - elevated
      description: |-
          (1) Depending on the threat landscape at hand and the protection needs of services, only one
          service SHOULD be operated on each server.
      notes: |-
          This requirement must be implemented organizationally.
      status: manual

    - id: SYS.1.1.A31
      title: Using Execution Control
      levels:
          - elevated
      description: |-
          (1) Execution control SHOULD be used to ensure that only explicitly authorised programs and
          scripts can be executed. (2) The rules SHOULD be set as restrictively as possible. (3) If explicit
          specification of paths and hashes is not possible, certificate-based or path rules SHOULD be
          used as an alternative.
      notes: |-
          While not directly leveraging a allowlist of executable programs, SELinux and fapolicyd help to
          address this issue. They deny execution or fileaccess based on a list of allowed permissions.
      status: automated
      rules:
      # selinux
          - package_libselinux_installed
          - grub2_enable_selinux
          - selinux_not_disabled
          - var_selinux_policy_name=targeted
          - selinux_policytype
          - var_selinux_state=enforcing
          - selinux_state
          - selinux_confinement_of_daemons
      # fapolicyd
          - fapolicy_default_deny
          - package_fapolicyd_installed
          - service_fapolicyd_enabled

    - id: SYS.1.1.A32
      title: ELIMINATED
      levels:
          - elevated
      description: |-
          This requirement has been eliminated.
      notes: |-
          This requirement has been eliminated.
      status: not applicable

    - id: SYS.1.1.A33
      title: Active Administration of Root Certificates
      levels:
          - elevated
      description: |-
          (1) As part of the procurement and installation of a server, the root certificates that are
          required to operate the server SHOULD be documented. (2) Only the previously documented root
          certificates required for operation SHOULD be present on the server. (3) Regular checks SHOULD
          be performed as to whether existing root certificates still comply with the respective
          organisation’s requirements. (4) All certificate stores on the IT system at hand SHOULD be
          included in these checks.
      notes: |-
          Section 1: organizational control
          Section 2-4: can be addressed by a manual rule in OpenSCAP
          This can be in conflict with rpm_checks as changing the ca-trust-store triggers these checks.
      status: manual
      rules:
      # Section 1-4
          - only_allow_specific_certs

    - id: SYS.1.1.A34
      title: Hard Disk Encryption
      levels:
          - elevated
      description: |-
          (1) In case of increased protection needs, a server's storage media should be encrypted using a
          product or procedure that is considered secure. (2) This SHOULD also apply to virtual machines
          containing production data. (3) Trusted Platform Module (TPM) SHOULD NOT be the only form
          of key protection used. (4) Recovery passwords SHOULD be stored in an appropriate and secure
          location. (5) In case of very high requirements (e.g. regarding confidentiality), full volume or full
          disk encryption SHOULD be used.
      notes: |-
          Section 1-3: Specification of what is needed
          Section 4: organizational control
          Section 5: can be addressed on a partition label with existing checks
          # Keylime?
          # nbde?
          # https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening
      status: partial
      rules:
      # Section 3
          - grub2_rng_core_default_quality_argument
      # Section 1,5
          - encrypt_partitions

    - id: SYS.1.1.A36
      title: Protecting the Boot Process
      levels:
          - elevated
      description: |-
          (1) A server's boot loader and operating system kernel SHOULD be checked by self-controlled key
          material that is signed upon system start in a trusted chain (secure boot). (2) Unnecessary key
          material SHOULD be removed.
      notes: |-
          At the moment there is no automatic check to check if secure boot is active.
          It can be done manually by using mokutil --sb-state
      status: manual
      rules: []

    - id: SYS.1.1.A38
      title: Hardening of the Host System by Means of a Read-Only File System
      levels:
          - elevated
      description: |-
          The integrity of the host system should be ensured by a read-only file system (an immutable OS).
      notes: |-
          RHEL does not meet this requirement. RHEL in ImageMode (bootc) might be the solution
          for that.
      status: does not meet
