From c69a5f3925d992d34013e1d569ce357f29c451bf Mon Sep 17 00:00:00 2001 From: teacup-on-rockingchair <315160+teacup-on-rockingchair@users.noreply.github.com> Date: Wed, 1 Oct 2025 16:47:12 +0300 Subject: [PATCH 1/9] Add SUSE SLE 16 platform to build procedure --- CMakeLists.txt | 5 ++ build_product | 1 + products/sle16/CMakeLists.txt | 10 ++++ products/sle16/product.yml | 47 +++++++++++++++++++ products/sle16/transforms/constants.xslt | 9 ++++ products/sle16/transforms/table-style.xslt | 5 ++ .../transforms/xccdf-apply-overlay-stig.xslt | 8 ++++ .../sle16/transforms/xccdf2table-cce.xslt | 9 ++++ .../xccdf2table-profileccirefs.xslt | 9 ++++ ssg/constants.py | 5 +- 10 files changed, 106 insertions(+), 2 deletions(-) create mode 100644 products/sle16/CMakeLists.txt create mode 100644 products/sle16/product.yml create mode 100644 products/sle16/transforms/constants.xslt create mode 100644 products/sle16/transforms/table-style.xslt create mode 100644 products/sle16/transforms/xccdf-apply-overlay-stig.xslt create mode 100644 products/sle16/transforms/xccdf2table-cce.xslt create mode 100644 products/sle16/transforms/xccdf2table-profileccirefs.xslt diff --git a/CMakeLists.txt b/CMakeLists.txt index 774519b55e5..1bcf28ed86f 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -117,6 +117,7 @@ option(SSG_PRODUCT_RHEL10 "If enabled, the RHEL10 SCAP content will be built" ${ option(SSG_PRODUCT_RHV4 "If enabled, the RHV4 SCAP content will be built" ${SSG_PRODUCT_DEFAULT}) option(SSG_PRODUCT_SLE12 "If enabled, the SLE12 SCAP content will be built" ${SSG_PRODUCT_DEFAULT}) option(SSG_PRODUCT_SLE15 "If enabled, the SLE15 SCAP content will be built" ${SSG_PRODUCT_DEFAULT}) +option(SSG_PRODUCT_SLE16 "If enabled, the SLE16 SCAP content will be built" ${SSG_PRODUCT_DEFAULT}) option(SSG_PRODUCT_SLMICRO5 "If enabled, the SLE Micro 5 SCAP content will be built" ${SSG_PRODUCT_DEFAULT}) option(SSG_PRODUCT_SLMICRO6 "If enabled, the SLE Micro 6 SCAP content will be built" ${SSG_PRODUCT_DEFAULT}) option(SSG_PRODUCT_TENCENTOS4 "If enabled, the TencentOS Server 4 SCAP content will be built" ${SSG_PRODUCT_DEFAULT}) @@ -358,6 +359,7 @@ message(STATUS "RHEL 10: ${SSG_PRODUCT_RHEL10}") message(STATUS "RHV 4: ${SSG_PRODUCT_RHV4}") message(STATUS "SUSE 12: ${SSG_PRODUCT_SLE12}") message(STATUS "SUSE 15: ${SSG_PRODUCT_SLE15}") +message(STATUS "SUSE 16: ${SSG_PRODUCT_SLE16}") message(STATUS "SLE Micro 5: ${SSG_PRODUCT_SLMICRO5}") message(STATUS "SLE Micro 6: ${SSG_PRODUCT_SLMICRO6}") message(STATUS "TencentOS Server 4: ${SSG_PRODUCT_TENCENTOS4}") @@ -478,6 +480,9 @@ endif() if(SSG_PRODUCT_SLE15) add_subdirectory("products/sle15" "sle15") endif() +if(SSG_PRODUCT_SLE16) + add_subdirectory("products/sle16" "sle16") +endif() if(SSG_PRODUCT_SLMICRO5) add_subdirectory("products/slmicro5" "slmicro5") endif() diff --git a/build_product b/build_product index 567375462b9..bb288933456 100755 --- a/build_product +++ b/build_product @@ -383,6 +383,7 @@ all_cmake_products=( RHV4 SLE12 SLE15 + SLE16 SLMICRO5 SLMICRO6 TENCENTOS4 diff --git a/products/sle16/CMakeLists.txt b/products/sle16/CMakeLists.txt new file mode 100644 index 00000000000..c105c69cd8a --- /dev/null +++ b/products/sle16/CMakeLists.txt @@ -0,0 +1,10 @@ +# Sometimes our users will try to do: "cd sle16; cmake ." That needs to error in a nice way. +if("${CMAKE_SOURCE_DIR}" STREQUAL "${CMAKE_CURRENT_SOURCE_DIR}") + message(FATAL_ERROR "cmake has to be used on the root CMakeLists.txt, see the Building ComplianceAsCode section in the Developer Guide!") +endif() + +set(PRODUCT "sle16") +ssg_build_product("sle16") + + +ssg_build_html_cce_table(${PRODUCT}) diff --git a/products/sle16/product.yml b/products/sle16/product.yml new file mode 100644 index 00000000000..c6550fdbd65 --- /dev/null +++ b/products/sle16/product.yml @@ -0,0 +1,47 @@ +product: sle16 +full_name: SUSE Linux Enterprise Server 16 +type: platform + +families: + - suse + +major_version_ordinal: 16 + +benchmark_id: SLE-16 +benchmark_root: "../../linux_os/guide" + +profiles_root: "./profiles" + +init_system: "systemd" + +pkg_manager: "zypper" +pkg_manager_config_file: "/etc/zypp/zypp.conf" + +aide_bin_path: "/usr/bin/aide" + +cpes_root: "../../shared/applicability" +cpes: + - sle16: + name: "cpe:/o:suse:sles:16.0" + title: "SUSE Linux Enterprise Server 16.0" + check_id: installed_OS_is_sle16 + +platform_package_overrides: + login_defs: "shadow" + grub2: "grub2" + sssd: "sssd" + crontabs: "cronie" + passwd: "shadow" + +reference_uris: + suse-base-sle16: 'not_publicly_available' + +dconf_gdm_dir: "gdm.d" + +sysctl_remediate_drop_in_file: "true" +journald_conf_dir_path: /etc/systemd/journal.d +xwindows_packages: + - xorg-x11-server + - xorg-x11-server-extra + - xorg-x11-server-Xvfb + - xwayland diff --git a/products/sle16/transforms/constants.xslt b/products/sle16/transforms/constants.xslt new file mode 100644 index 00000000000..830c77a787d --- /dev/null +++ b/products/sle16/transforms/constants.xslt @@ -0,0 +1,9 @@ + + + + +SUSE Linux Enterprise Server 16.0 +SLES 16 +sle16 + + diff --git a/products/sle16/transforms/table-style.xslt b/products/sle16/transforms/table-style.xslt new file mode 100644 index 00000000000..8b6caeab8cd --- /dev/null +++ b/products/sle16/transforms/table-style.xslt @@ -0,0 +1,5 @@ + + + + + diff --git a/products/sle16/transforms/xccdf-apply-overlay-stig.xslt b/products/sle16/transforms/xccdf-apply-overlay-stig.xslt new file mode 100644 index 00000000000..4789419b80a --- /dev/null +++ b/products/sle16/transforms/xccdf-apply-overlay-stig.xslt @@ -0,0 +1,8 @@ + + + + + + + + diff --git a/products/sle16/transforms/xccdf2table-cce.xslt b/products/sle16/transforms/xccdf2table-cce.xslt new file mode 100644 index 00000000000..f156a669566 --- /dev/null +++ b/products/sle16/transforms/xccdf2table-cce.xslt @@ -0,0 +1,9 @@ + + + + + + + + + diff --git a/products/sle16/transforms/xccdf2table-profileccirefs.xslt b/products/sle16/transforms/xccdf2table-profileccirefs.xslt new file mode 100644 index 00000000000..9d8d3e5faf1 --- /dev/null +++ b/products/sle16/transforms/xccdf2table-profileccirefs.xslt @@ -0,0 +1,9 @@ + + + + + + + + + diff --git a/ssg/constants.py b/ssg/constants.py index 0dd3752b308..de789d849aa 100644 --- a/ssg/constants.py +++ b/ssg/constants.py @@ -59,7 +59,7 @@ 'openembedded', 'rhel8', 'rhel9', 'rhel10', 'rhv4', - 'sle12', 'sle15', 'slmicro5', 'slmicro6', + 'sle12', 'sle15', 'sle16', 'slmicro5', 'slmicro6', 'tencentos4', 'ubuntu2204', 'ubuntu2404' ] @@ -238,6 +238,7 @@ "Red Hat Virtualization 4": "rhv4", "SUSE Linux Enterprise 12": "sle12", "SUSE Linux Enterprise 15": "sle15", + "SUSE Linux Enterprise 16": "sle16", "SUSE Linux Enterprise Micro 5": "slmicro5", "SUSE Linux Enterprise Micro 6": "slmicro6", "TencentOS Server 4": "tencentos4", @@ -315,7 +316,7 @@ "multi_platform_rhcos": ["rhcos4"], "multi_platform_rhel": ["rhel8", "rhel9", "rhel10"], "multi_platform_rhv": ["rhv4"], - "multi_platform_sle": ["sle12", "sle15"], + "multi_platform_sle": ["sle12", "sle15", "sle16"], "multi_platform_slmicro": ["slmicro5", "slmicro6"], "multi_platform_tencentos": ["tencentos4"], "multi_platform_ubuntu": ["ubuntu2204", "ubuntu2404"], From 28011f2abb4a4201acf9f542facb7a0c8621aa97 Mon Sep 17 00:00:00 2001 From: teacup-on-rockingchair <315160+teacup-on-rockingchair@users.noreply.github.com> Date: Wed, 1 Oct 2025 17:46:14 +0300 Subject: [PATCH 2/9] Add initial profile for SLE16 platform --- controls/base_sle16.yml | 23 +++++++ products/sle16/profiles/base.profile | 19 ++++++ shared/checks/oval/installed_OS_is_sle16.xml | 69 ++++++++++++++++++++ 3 files changed, 111 insertions(+) create mode 100644 controls/base_sle16.yml create mode 100644 products/sle16/profiles/base.profile create mode 100644 shared/checks/oval/installed_OS_is_sle16.xml diff --git a/controls/base_sle16.yml b/controls/base_sle16.yml new file mode 100644 index 00000000000..da44120a375 --- /dev/null +++ b/controls/base_sle16.yml @@ -0,0 +1,23 @@ +--- +policy: Basis System Security Profile for SUSE Linux Enterprise 16 +title: asis System Security Profile SUSE Linux Enterprise 16 +id: base_sle16 +version: '1.0' +source: not_publicly_available +reference_type: suse-base-sle16 + +levels: + - id: high + - id: medium + - id: low + +product: sle16 + +controls: + - id: SLES-16-16016015 + levels: + - high + title: SLES 16 must be a vendor-supported release. + rules: + - installed_OS_is_vendor_supported + status: automated diff --git a/products/sle16/profiles/base.profile b/products/sle16/profiles/base.profile new file mode 100644 index 00000000000..b1b0d2f46d3 --- /dev/null +++ b/products/sle16/profiles/base.profile @@ -0,0 +1,19 @@ +documentation_complete: true + +metadata: + version: 1.0 + SMEs: + - svet-se + - rumch-se + - teacup-on-rockingchair + +reference: not_publicly_available + +title: 'General System Security Profile for SUSE Linux Enterprise (SLES) 16' + +description: |- + This profile contains configuration checks that align to the + General System Security Profile for SUSE Linux Enterprise (SLES) 16. + +selections: + - base_sle16:all diff --git a/shared/checks/oval/installed_OS_is_sle16.xml b/shared/checks/oval/installed_OS_is_sle16.xml new file mode 100644 index 00000000000..282e64eb0c8 --- /dev/null +++ b/shared/checks/oval/installed_OS_is_sle16.xml @@ -0,0 +1,69 @@ + + + + SUSE Linux Enterprise 16 + + multi_platform_all + + + + The operating system installed on the system is + SUSE Linux Enterprise 15. + + + + + + + + + + + + + + + + + unix + + + + + + + + + ^16.*$ + + + sled-release + + + + + + + + ^16.*$ + + + sles-release + + + + + + + + ^16.*$ + + + SLES_SAP-release + + + From dbd33b840cdaf53ffa8ade0cddd029458b4fbaa9 Mon Sep 17 00:00:00 2001 From: teacup-on-rockingchair <315160+teacup-on-rockingchair@users.noreply.github.com> Date: Sun, 5 Oct 2025 15:07:40 +0300 Subject: [PATCH 3/9] Add skeleton implementation for PCI-DSS and ANSSI minimal profiles for SLES16 --- controls/anssi_sle16.yml | 863 ++++ controls/base_sle16.yml | 25 + controls/pcidss_4_sle16.yml | 3540 +++++++++++++++++ products/sle16/product.yml | 2 + .../sle16/profiles/anssi_bp28_minimal.profile | 28 + products/sle16/profiles/pci-dss-4.profile | 17 + 6 files changed, 4475 insertions(+) create mode 100644 controls/anssi_sle16.yml create mode 100644 controls/pcidss_4_sle16.yml create mode 100644 products/sle16/profiles/anssi_bp28_minimal.profile create mode 100644 products/sle16/profiles/pci-dss-4.profile diff --git a/controls/anssi_sle16.yml b/controls/anssi_sle16.yml new file mode 100644 index 00000000000..c0e622eefa7 --- /dev/null +++ b/controls/anssi_sle16.yml @@ -0,0 +1,863 @@ +--- +policy: 'ANSSI-BP-028' +title: 'Configuration Recommendations of a GNU/Linux System' +id: anssi_sle16 +version: '2.0' +source: https://cyber.gouv.fr/sites/default/files/document/linux_configuration-en-v2.pdf +product: sle16 + +levels: + - id: minimal + - id: intermediary + inherits_from: + - minimal + - id: enhanced + inherits_from: + - intermediary + - id: high + inherits_from: + - enhanced + +reference_type: anssi_sle16 + +controls: + - id: R1 + title: Hardware Support + levels: + - enhanced + description: >- + It is recommended to apply the configuration recommendations for Hardware support + mentioned in ANSSI DAT-24. + notes: >- + This requirement can be checked, but remediation requires manual reinstall of the OS. + The content automation cannot really configure the BIOS, but can in some cases, + check settings that are visible to the OS. Like for example the NX/DX setting. + status: partial + + # R8 It is recommended to use hardware with support for hardware random number generator + # R9 Disable VT-x AMD-V technologies + # TODO: can we reliably check cpuinfo flags? + # R10 IOMMU must enabled if the hardware supports it + - id: R2 + title: Hardware configuration + levels: + - intermediary + description: >- + It is recommended to apply the configuration recommendations for BIOS/UEFI mentioned in + ANSSI DAT-24. + notes: >- + Configurations recommended for this requirement are to be performed at the BIOS level. + status: manual + + # From ANSSI DAT-24 + # R11 Password protect the BIOS + # R12 Deactivate peripherals not needed + # R13 The boot order list should give highest preference to component on which final OS is installed + # R14 Enable NX/XD bit + # - bios_enable_execution_restrictions # Doesn't have check + # R15 Disable VT-x/AMD-V functionality + # R16 Enable IOMMU + - id: R3 + title: UEFI Secure boot activation + levels: + - intermediary + description: >- + It is recommended to apply UEFI Secure Boot configuration of the distribution. + notes: >- + Secure Boot needs to be enabled in the UEFI Setup program. + Enabling Secure Boot can't be accomplished from the operating system. + Also, OVAL doesn't provide any reliable ways to detect the Secure Boot status. + Therefore, we will not provide any rules to automate this requirement. + We recommend checking the Secure Boot status using the `mokutil --sb-state` or `bootctl status` + commands. + status: manual + + - id: R4 + title: Replacing of preloaded keys + levels: + - high + description: >- + It is recommended to replace the UEFI preloaded keys with new keys used to sign; + the bootloader and Linux kernel, or; the image of the Linux kernel in EFI format. + notes: >- + This requirement is not generally automatable. The Machine Owner Key (MOK) could + be used to add keys to the Secure Boot db key database but manual interaction is + required to navigate the UEFI console and input the key password. + On systems where MOK utility is not supported, one will need to access the UEFI + firmware interface to add new keys. + We have no automation support for UEFI interfaces and the steps for each hardware + manufacturer can vary. + status: manual + + - id: R5 + title: Boot loader password + levels: + - intermediary + description: >- + A password protecting the boot loader must exist. + This password must prevent any user from changing their configuration options. + status: pending + + - id: R6 + title: Protecting kernel command line parameters + levels: + - high + description: >- + It is recommended that UEFI Secure Boot is used to protect the Linux Kernel + command line parameters during boot. + notes: >- + To protect the Linux Kernel command line one needs to create an Unified Kernel Image and use + it with the UEFI Secure Boot mechanism. + To check if the Kernel image contains the kernel command one needs to inspect the binary, on + the command line one can use the objdump command. But unfortunately OVAL is not able to + inspect kernel images. + Also, it is not trivial to automate creation of such image or configuration of the + Secure Boot mechanism. + status: manual + + - id: R7 + title: IOMMU Configuration Guidelines + levels: + - enhanced + description: >- + The iommu = force directive must be added to the list of kernel parameters + during startup in addition to those already present in the configuration + files of the bootloader (/boot/grub/menu.lst or /etc/default/grub). + status: pending + + - id: R8 + title: Memory configuration options + levels: + - intermediary + status: pending + + - id: R9 + title: Kernel configuration options + levels: + - intermediary + status: pending + + - id: R10 + title: Disabling the loading of kernel modules + levels: + - enhanced + description: >- + The loading of the kernel modules can be blocked by the activation of the + sysctl kernel.modules_disabled: + Prohibition of loading modules (except those already loaded to this point) + kernel.modules_disabled = 1 + status: pending + + - id: R11 + title: Yama module sysctl configuration + levels: + - intermediary + description: >- + It is recommended to load the Yama security module at startup (by example + passing the security = yama argument to the kernel) and configure the + sysctl kernel.yama.ptrace_scope to a value of at least 1. + status: pending + + - id: R12 + title: IPv4 configuration options + levels: + - intermediary + status: pending + + - id: R13 + title: Disabling IPv6 + levels: + - intermediary + notes: >- + When IPv6 is not in use, disable it, otherwise secure the IPv6 stack. + This control hardens the IPv6 stack, to disable it use the related rules instead. + status: pending + + - id: R14 + title: File system configuration options + levels: + - intermediary + notes: >- + The rule for the /proc file system is not implemented + status: pending + + - id: R15 + title: Compile options for memory management + levels: + - high + status: pending + notes: >- + The special case of direct access to physical memory is not handled. + + - id: R16 + title: Compile options for kernel data structures + levels: + - high + status: pending + + - id: R17 + title: Compile options for the memory allocator + levels: + - high + status: pending + + - id: R18 + title: Compile options for the management of kernel module + levels: + - high + status: pending + + - id: R19 + title: Compile options for abnormal situations + levels: + - high + status: pending + + - id: R20 + title: Compile options for kernel security functions + levels: + - high + status: pending + + - id: R21 + title: Compile options for the compiler plugins + levels: + - high + status: pending + + - id: R22 + title: Compile options for the IP stack + levels: + - high + notes: >- + This control doesn't disable the IPv6 stack, to disable it select the related rule. + status: pending + + - id: R23 + title: Compile options for various kernel behaviors + levels: + - high + notes: >- + If the system can function without support for kernel modules, module support should be disabled + by setting CONFIG_MODULES=n. + status: pending + + - id: R24 + title: Compile options for 32-bit architectures + levels: + - high + notes: >- + Unless a X86 32bit kernel is explicitly supported by one of products in the project, this + requirement is set to not applicable. + status: not applicable + + - id: R25 + title: Compile options for x86_64 architectures + levels: + - high + status: pending + + - id: R26 + title: Compile options for ARM architectures + levels: + - high + notes: >- + Unless a ARM 32bit kernel is explicitly supported by one of products in the project, this + requirement is set to not applicable. + status: not applicable + + - id: R27 + title: Compile options for ARM 64 architectures + levels: + - high + status: pending + + - id: R28 + title: Partitioning type + levels: + - intermediary + status: pending + + - id: R29 + title: Access Restrictions on /boot + levels: + - enhanced + description: >- + When possible, it is recommended not to automatically mount the /boot partition. + In any case, access to the /boot folder should only be allowed for the root user. + notes: >- + The /boot partition mounted is essential to perform certain administrative actions, for + example updating the kernel. Therefore, for better stability, in this requirement only rules + to restrict the access to /boot are selected. It is not changed how the /boot is mounted. + status: pending + + - id: R30 + title: Removal of unused user accounts + levels: + - minimal + description: >- + Unused user accounts must be deleted from the system. + notes: >- + The definition of unused user accounts is broad. It can include accounts + whose owners don't use the system anymore, or users created by services + or applications that should not be used. + Automation by itself cannot discern which accounts are used or not. + status: manual + + - id: R31 + title: User password strength + levels: + - minimal + notes: >- + The rules selected below establish a general password strength baseline + of 100 bits, based on the recommendations of the technical note + "Recommandations relatives à l'authentification multifacteur et aux mots de passe" + (https://cyber.gouv.fr/publications/recommandations-relatives-lauthentification-multifacteur-et-aux-mots-de-passe) + + The baseline should be reviewed and tailored to the system's use case and needs. + status: pending + + - id: R32 + title: Configuring a timeout on local user sessions + levels: + - intermediary + description: >- + Local user sessions (console TTY, graphical session) must be locked after a certain period + of inactivity. + notes: >- + ANSSI doesn't specify the length of the inactivity period, we are choosing 10 minutes as reasonable + number. + status: pending + + - id: R33 + title: Use of dedicated administration accounts + levels: + - intermediary + notes: >- + By disabling direct root logins proper accountability is ensured. + Users will login first, then escalate to privileged (root) access. + Change of privilege operations must be based on executables to monitor the activities + performed (for example sudo). + Nonetheless, the content automation cannot ensure that each administrator was given a + nominative administration account separate from his normal user account. + status: pending + + - id: R34 + title: Deactivation of service accounts + levels: + - intermediary + notes: >- + It is difficult to generally identify the system's service accounts. + UIDs of such accounts are generally between SYS_UID_MIN and SYS_UID_MAX, but their values + are not enforced by the OS and can be changed over time. + Assisting rules could list users which are not disabled for manual review. + status: manual + + - id: R35 + title: Uniqueness and exclusivity of system service accounts + levels: + - intermediary + description: >- + Each service must have its own system account and be dedicated to it exclusively. + notes: >- + It is not trivial to identify whether a user account is a service account. + UIDs of such accounts are generally between SYS_UID_MIN and SYS_UID_MAX, but their values + are not enforced by the OS and can be changed over time. + status: manual + + - id: R36 + title: Changing the default value of UMASK + levels: + - enhanced + description: >- + The default value of UMASK for the shells must be set to 0077 in order to allow read and + write access to its owner only. This value can be defined in the configuration file + /etc/profile that most shells (bash, dash, ksh…) will use. + The default value of UMASK for services must be determined for each service, but in most + cases, it should be set to 0027 (or more restrictive). This allows read access to its owner + and its group, and a full access to its owner. For services such as systemd, this value can + be defined directly in the configuration file of the service with the directive UMask=0027. + notes: >- + There are cases of Systemd services which would stop working in case umask + would be configured to 0027 for all services. One such example is the + Cups service which needs to create sockets which need to be available for + all users. Therefore, this part of the requirement can't be automated. + status: pending + + - id: R37 + title: Using access control features + levels: + - enhanced + description: >- + It is recommended to use the mandatory access control (MAC) features in + addition to the traditional Unix user model (DAC), or possibly combine + them with partitioning mechanisms. + notes: >- + Other partitioning mechanisms can include chroot and containers and are not contemplated + in this requirement. + status: pending + + - id: R38 + title: Group dedicated to the use of sudo + levels: + - enhanced + description: >- + A group dedicated to the use of sudo must be created, and only members of this + group are allowed to execute sudo. + status: pending + + - id: R39 + title: Sudo configuration guidelines + levels: + - intermediary + status: pending + + - id: R40 + title: Privileges of target sudo users + description: The targeted users of a rule should be, as much as possible, non privileged users. + levels: + - intermediary + status: pending + + - id: R41 + title: Limiting the number of commands requiring the use of the EXEC option + levels: + - enhanced + description: >- + The commands requiring the execution of sub-processes (EXEC tag) must be + explicitly listed and their use should be reduced to a strict minimum. + notes: >- + Human review is required to assess if the set of commands requiring EXEC is minimal. + An auxiliary rule could list rules containing EXEC tag, for analysis. + status: manual + + - id: R42 + title: Good use of negation in a sudoers file + levels: + - intermediary + description: The sudoers configuration rules should not involve negation. + status: pending + + - id: R43 + title: Explicit arguments in sudo specifications + levels: + - intermediary + status: pending + + - id: R44 + title: Editing files with sudo + levels: + - intermediary + description: A file requiring sudo to be edited, must be edited through the sudoedit command. + notes: >- + In R62 we established that the sudoers files should not use negations, thus the approach + for this requirement is to ensure that sudoedit is the only text editor allowed. + But it is difficult to ensure that allowed binaries aren't text editors without human + review. + status: manual + + - id: R45 + title: Enable AppArmor security profiles + levels: + - enhanced + description: >- + All AppArmor security profiles on the system must be enabled by default. + status: pending + + - id: R46 + title: Activate SELinux with the Targeted Policy + levels: + - high + description: >- + It is recommended to enable the targeted policy when the distribution + supports it and that it does not operate another security module than SELinux. + status: pending + + - id: R47 + title: Containment of unprivileged interactive users + levels: + - high + description: >- + Interactive non-privileged users of a system must be confined by associating them with a SELinux + confined user. + notes: Interactive users who still need to perform administrative tasks should not be confined + with user_u. + status: manual + + - id: R48 + title: Setting SELinux booleans + levels: + - high + description: >- + It is recommended to set the following Booleans: + allow_execheap to off, forbids processes to make their heap executable; + allow_execmem to off, forbids processes to have both write and execute rights on memory pages; + allow_execstack to off, forbids processes to make their stack executable; + secure_mode_insmod to on, prohibits dynamic loading of modules by any process; + ssh_sysadm_login to off, forbids SSH logins to connect directly in sysadmin role. + notes: In RHEL, the SELinux boolean allow_execheap is renamed to selinuxuser_execheap, and the + boolean allow_execstack is renamed to selinuxuser_execstack. And allow_execmem is not available, + deny_execmem provides the same functionality. + status: pending + + - id: R49 + title: Uninstalling SELinux Policy Debugging Tools + levels: + - high + description: >- + SELinux policy manipulation and debugging tools should not be installed + on a machine in production. + status: pending + + - id: R50 + title: Rights to access sensitive files and directories + levels: + - intermediary + status: pending + + - id: R51 + title: Sensitive and trusted files + levels: + - enhanced + description: >- + All sensitive files and those contributing to the authentication mechanisms + must be set up as soon as the system is installed. If default secrets are + preconfigured, they must be replaced during, or immediately after, the + installation phase of the system. + notes: >- + This concerns two aspects, the first is administrative, and involves prompt + installation of secrets or trusted elements by the sysadmin. + The second involves removal of any default secret or trusted element + configured by the operating system during install process, e.g. default + known passwords. + status: documentation + + - id: R52 + title: Securing access for named sockets and pipes + levels: + - intermediary + notes: |- + The requirement states that all sockets and named pipes within all mounted + file systems should be checked. The check should look at the permissions + of the socket / pipe and compare them with permissions of the directory + which contains the particular socket. In case permissions of the directory + are less stricter than permissions of the socket, this should be + considered a finding. Since different use cases can require different + permissions for named pipes / sockets, it is not possible to perform this + check automatically. + status: manual + + - id: R53 + title: Files or directories without a known user or group + levels: + - minimal + status: automated + controls: + - base_sle16:SLES-16-16016025 + - base_sle16:SLES-16-16016030 + + - id: R54 + title: Sticky bit and write access rights + levels: + - minimal + status: pending + + - id: R55 + title: Temporary directories dedicated to accounts + levels: + - intermediary + description: >- + Each user or service account must have its own temporary directory + and dispose of it exclusively. + notes: The approach of the selected rules is to use and configure pam_namespace module. + status: pending + + - id: R56 + title: Executables with setuid and setgid bits + levels: + - minimal + notes: >- + Only programs specifically designed to be used with setuid or setgid bits can have these privilege + bits set. + This requirement considers apropriate for setuid and setgid bits the binaries that are installed + from + recognized and authorized repositories (covered in R15). + The remediation resets the sticky bit to intended value by vendor/developer, any finding after + remediation + should be reviewed. + status: pending + + - id: R57 + title: Executable with special rights setuid root and setgid root + levels: + - enhanced + description: >- + The executables with setuid executables root and setgid root special rights should be as few + as possible. + When only administrators are expected to execute them, these special rights should + be removed and prefer them commands like su or sudo, which can be monitored + notes: There could be rules to list all executables with setuid root or setgid root rights. + status: manual + + - id: R58 + title: Installation of packages reduced to the bare necessities + levels: + - minimal + description: >- + The selection of packages installed should be as small as possible, + limiting itself to select only what is required. + notes: >- + It is not possible to automatically decide in general way if a package is required or not for + given system. + As a future improvement, there could be rules assisting assessment by listing the installed + packages. + status: manual + + - id: R59 + title: Official package repositories + levels: + - minimal + description: Only up-to-date official repositories of the distribution must be used. + notes: >- + It is not trivial to distinguish an official repository from an unofficial one. + We cannot draw conclusions from the repo name or URL of the repo (as they can be arbitrary + or behind a proxy). + One approach to check the origin of installed packages is to check the signature of the packages. + If the public key of a repository is not installed, the repo is not trusted. + status: pending + + - id: R60 + title: Hardened package repositories + levels: + - enhanced + description: >- + When the distribution provides several types of repositories, preference + should be given to those containing packages subject to additional + hardening measures. + Between two packages providing the same service, those subject to hardening + (at compilation, installation, or default configuration) must be preferred. + status: not applicable + + - id: R61 + title: Regular updates + levels: + - minimal + notes: Check the vendor CVE feed and configure automatic install of security related updates. + status: pending + + - id: R62 + title: Minimization of installed services + levels: + - minimal + description: >- + Only the components strictly necessary to the service provided by the system should + be installed. + Those whose presence can not be justified should be disabled, removed or deleted. + status: manual # The list of essential services is not objective. + notes: >- + Performing a minimal install is a good starting point, but doesn't provide any assurance + over any package installed later. + Manual review is required to assess if the installed services are minimal. + In general, use of obsolete or insecure services is not recommended and we remove some + of these in this recommendation. + + - id: R63 + title: Minimization of services configuration + levels: + - intermediary + description: >- + Services are often installed with default configurations that enable features potentially + problematic from a security point of view. + The features configured at the level of launched services should be limited to the strict + minimum. + notes: >- + Define a list of most problematic components or features to be hardened or restricted. + status: manual + + - id: R64 + title: Least privilege for the services + levels: + - enhanced + description: >- + The deployed services must have their access restricted to the system + strict minimum, especially when it comes to files, processes or network. + notes: >- + SELinux policies limit the privileges of services and daemons just to those which are required. + The policies should be enough to restrict the services' privileges to its essentials, but the + automated content cannot assess whether they are the minimum required for the deployment. + status: pending + + - id: R65 + title: Services partitioning + levels: + - enhanced + notes: >- + Using automation to restrict access and chroot services is not generally reliable. + status: manual + + - id: R66 + title: Virtualization components hardening + levels: + - high + description: >- + Each component supporting the virtualization must be hardened, especially + by applying technical measures to counter the exploit attempts. + notes: >- + We cannot easily automate securing of virtualization technologies in a general way. + It may be interesting to point out virtualization components that are installed and + should be hardened. + status: manual + + - id: R67 + title: Secure remote authentication with PAM + levels: + - intermediary + description: |- + When authentication takes place through a remote application (network), + the authentication protocol used by PAM must be secure (flow encryption, + remote server authentication, anti-replay mechanisms, ...). + notes: |- + In systems where remote authentication is handled through sssd service, PAM delegates + requests for remote authentication to sssd service through a local Unix socket. The sssd + service can use IPA, AD or LDAP as a remote database containing information required for authentication. + In case LDAP is configured manually, there are several configuration options which should be chedked. + status: pending + + - id: R68 + title: Protecting stored passwords + levels: + - minimal + description: Any password must be protected by cryptographic mechanisms. + notes: >- + The selection of rules doesn't cover the use of hardware devices to protect the passwords. + status: supported + + - id: R69 + title: Securing access to remote user databases + levels: + - intermediary + description: |- + When the user databases are stored on a remote network service, NSS must + be configured to establish a secure link that allows, at minimum, to + authenticate the server and protect the communication channel. + notes: |- + A nsswitch service connecting to remote database is provided by sssd. This is checked in requirement R67. + Another such service is winbind which is by default configured to connect securely to Samba domains. + Other relevant services are NIS and Hesiod. These should not be used. + status: pending + + - id: R70 + title: Separation of System Accounts and Directory Administrator + levels: + - intermediary + status: manual + + - id: R71 + title: Implement a logging system + levels: + - enhanced + description: >- + The configuration of the service must be performed according to the + 'Security Recommendations for the architecture of a logging system' + (DAT-PA-012 v2.0) accessible on the ANSSI website + (https://www.ssi.gouv.fr/journalisation). + notes: >- + A lot of recommendations and requirements from the DAT-PA-012 document are administrative and + hard to automate. + The rules selected below address a few of the aspects that can be covered, keep in mind that + these configurations should + be customized for the systems deployment requirements. + status: pending + + - id: R72 + title: Service Activity Logs + levels: + - enhanced + description: >- + Each service must have a dedicated event logging journal on the system. + This log must only be accessible by the syslog server, and must not be readable, + editable or deletable by the service directly. + status: documentation # How to enable syslog for each service installed in the system + + - id: R73 + title: Logging activity by auditd + levels: + - enhanced + description: >- + The logging of the system activity must be done through the auditd service. + status: pending + + - id: R74 + title: Configuring the local messaging service + levels: + - intermediary + status: pending + + - id: R75 + title: Messaging Aliases for Service Accounts + levels: + - intermediary + status: pending # semi-automated + notes: >- + Only the alias for root user is covered by the rule. + The other services cannot be reliably covered, as there is no simple way + of determining what is a service account. + + - id: R76 + title: Sealing and integrity of files + levels: + - high + description: >- + Any file that is not transient (such as temporary files, databases, etc.) + must be monitored by a sealing program. + This includes: directories containing executables, libraries, + configuration files, as well as any files that may contain sensitive + elements (cryptographic keys, passwords, confidential data). + status: pending + + - id: R77 + title: Protection of the seals database + levels: + - high + description: >- + The sealing database must be protected from malicious access by + cryptographic signature mechanisms (with the key used for the signature + not locally stored in clear), or possibly stored on a separate machine + of the one on which the sealing is done. + Check section "Database and config signing in AIDE manual" + https://aide.github.io/doc/#signing + status: does not meet + + - id: R78 + title: Network services partitioning + levels: + - enhanced + description: >- + Network services should as much as possible be hosted on isolated environments. + This avoids having other potentially affected services if one of them gets + compromised under the same environment. + notes: >- + Manual analysis is required to determine if services are hosted appropriately in + separate or isolated system while maintaining functionality. + status: manual + + - id: R79 + title: Hardening and monitoring of exposed services + levels: + - intermediary + notes: >- + SELinux can provide confinement and monitoring of services, and AIDE provides + basic integrity checking. System logs are configured as part of R43. + Hardening of particular services should be done on a case by case basis and is + not automated by this content. + status: pending + + - id: R80 + title: Minimization of network services + levels: + - minimal + description: All network services must be listening on the correct network intefaces. + notes: >- + Manual review is necessary to decide if the list of resident daemons is minimal. + Assisting rules could be created to list sevices listening on the network for manual review. + status: manual diff --git a/controls/base_sle16.yml b/controls/base_sle16.yml index da44120a375..df7829df7a8 100644 --- a/controls/base_sle16.yml +++ b/controls/base_sle16.yml @@ -21,3 +21,28 @@ controls: rules: - installed_OS_is_vendor_supported status: automated + + - id: SLES-16-16016020 + title: Enable NX/XD Support + levels: + - medium + automated: partially + rules: + - bios_enable_execution_restrictions + - install_PAE_kernel_on_x86-32 + + - id: SLES-16-16016025 + title: Ensure All Files Are Owned by a Group + levels: + - medium + rules: + - file_permissions_ungroupowned + status: automated + + - id: SLES-16-16016030 + title: Ensure All Files Are Owned by a Use + levels: + - medium + rules: + - no_files_unowned_by_user + status: automated diff --git a/controls/pcidss_4_sle16.yml b/controls/pcidss_4_sle16.yml new file mode 100644 index 00000000000..de1e0a939ab --- /dev/null +++ b/controls/pcidss_4_sle16.yml @@ -0,0 +1,3540 @@ +--- +policy: PCI-DSS +title: Payment Card Industry - Data Security Standard (PCI-DSS) +id: pcidss_4_sle16 +version: '4.0.1' +source: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf +product: sle16 + +levels: + - id: base + +reference_type: pcidss4_sle16 + +controls: + - id: '1.1' + title: 'Processes and mechanisms for installing and maintaining network security controls are defined + and understood.' + levels: + - base + status: manual + controls: + - id: 1.1.1 + title: 'All security policies and operational procedures that are identified in Requirement + 1 are Documented, Kept up to date, In use and Known to all affected parties.' + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that security policies and + operational procedures identified in Requirement 1 are managed in accordance with all + elements specified in this requirement. + + - id: 1.1.2 + title: 'Roles and responsibilities for performing activities in Requirement 1 are documented, + assigned, and understood.' + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that day-to-day responsibilities + for performing all the activities in Requirement 1 are documented, assigned and understood + by the assigned personnel. + + - id: '1.2' + title: 'Network Security Controls (NSCs) are configured and maintained.' + levels: + - base + status: pending + controls: + - id: 1.2.1 + title: 'Configuration standards for NSC rulesets are Defined, Implemented and Maintained.' + levels: + - base + status: pending + notes: |- + Examples of NSCs covered by these configuration standards include, but are not limited to, + firewalls, routers configured with access control lists, and cloud virtual networks. The + objective of this requirement is to ensure the way that NSCs are configured and operate + are defined and consistently applied. While the tooling and standards can be automated, + the review of allowed accesses should be manual as different sites may have different + policies. + + - id: 1.2.2 + title: 'All changes to network connections and to configurations of NSCs are approved and + managed in accordance with the change control process defined at Requirement 6.5.1.' + levels: + - base + status: manual + notes: |- + Changes to network connections and NSCs cannot result in misconfiguration, implementation + of insecure services, or unauthorized network connections. Changes to network connections + include the addition, removal, or modification of a connection. Changes to NSC + configurations include those related to the component itself as well as those affecting + how it performs its security function. A formal change control process should be in place. + + - id: 1.2.3 + title: 'An accurate network diagram(s) is maintained that shows all connections between the + CDE and other networks, including any wireless networks.' + levels: + - base + status: manual + notes: |- + A representation of the boundaries between the CDE, all trusted networks, and all + untrusted networks, is maintained and available. A current network diagram(s) or other + technical or topological solution that identifies network connections and devices can be + used to meet this requirement. + + - id: 1.2.4 + title: 'An accurate data-flow diagram(s) is maintained' + description: |- + An accurate data-flow diagram(s) is maintained that meets the following: + - Shows all account data flows across systems and networks + - Updated as needed upon changes to the environment + levels: + - base + status: manual + + - id: 1.2.5 + title: 'All services, protocols, and ports allowed are identified, approved, and have a defined + business need.' + levels: + - base + status: manual + + - id: 1.2.6 + title: Security features are defined and implemented for all services, protocols, and ports + that are in use and considered to be insecure, such that the risk is mitigated. + levels: + - base + status: pending + notes: |- + The specific risks associated with the use of insecure services, protocols, and ports are + understood, assessed, and appropriately mitigated. The selected rules here basically + remove services without encryption and restricted some common services. + + - id: 1.2.7 + title: Configurations of NSCs are reviewed at least once every six months to confirm they + are relevant and effective. + description: |- + NSC configurations that allow or restrict access to trusted networks are verified + periodically to ensure that only authorized connections with a current business + justification are permitted. + levels: + - base + status: manual + notes: |- + Some configuration automation solution, such as Ansible could be helpful here. + + - id: 1.2.8 + title: Configuration files for NSCs are secured from unauthorized access and kept consistent + with active network configurations. + levels: + - base + status: pending + + - id: '1.3' + title: Network access to and from the cardholder data environment is restricted. + levels: + - base + status: pending + controls: + - id: 1.3.1 + title: Inbound traffic to the CDE is restricted to only traffic that is necessary + description: |- + Inbound traffic to the CDE is restricted as follows: + - To only traffic that is necessary. + - All other traffic is specifically denied. + levels: + - base + status: pending + + - id: 1.3.2 + title: Outbound traffic from the CDE is restricted to only traffic that is necessary + description: |- + Outbound traffic from the CDE is restricted as follows: + - To only traffic that is necessary. + - All other traffic is specifically denied. + levels: + - base + status: pending + notes: |- + It appears there is no rule in the project to restrict outbound traffic on the firewall. + Perhaps a rule to automates this would do more harm than good. Probably a manual + assessment is more reasonable here. + + - id: 1.3.3 + title: NSCs are installed between all wireless networks and the CDE, regardless of whether + the wireless network is a CDE. + description: |- + NSCs are installed between all wireless networks and the CDE, regardless of whether the + wireless network is a CDE, such that: + - All wireless traffic from wireless networks into the CDE is denied by default. + - Only wireless traffic with an authorized business purpose is allowed into the CDE. + levels: + - base + status: pending + notes: |- + Wireless interfaces are not expected in servers so they are disabled by default in this + policy. + + - id: '1.4' + title: Network connections between trusted and untrusted networks are controlled. + levels: + - base + status: pending + controls: + - id: 1.4.1 + title: NSCs are implemented between trusted and untrusted networks. + description: |- + Unauthorized traffic cannot traverse network boundaries between trusted and untrusted + networks. + levels: + - base + status: pending + notes: |- + Trusted and untrusted networks are expected to be different for each environment. + But loopback traffic is assumed to be trusted and even necessary for some services. + This requirement is complements 1.2.1 and 1.3.1 requirements. + + - id: 1.4.2 + title: Inbound traffic from untrusted networks to trusted networks is restricted. + description: |- + Inbound traffic from untrusted networks to trusted networks is restricted to: + - Communications with system components that are authorized to provide publicly accessible + services, protocols, and ports. + - Stateful responses to communications initiated by system components in a trusted network. + - All other traffic is denied. + levels: + - base + status: pending + notes: |- + Probably missing some relevant IPv6 related rules. Needs to be investigated. + + - id: 1.4.3 + title: Anti-spoofing measures are implemented to detect and block forged source IP addresses + from entering the trusted network. + levels: + - base + status: pending + notes: |- + Probably missing some relevant IPv6 related rules. Needs to be investigated. + + - id: 1.4.4 + title: System components that store cardholder data are not directly accessible from untrusted + networks. + levels: + - base + status: pending + notes: |- + This requirement is not intended to apply to storage of account data in volatile memory + but does apply where memory is being treated as persistent storage (for example, RAM + disk). Account data can only be stored in volatile memory during the time necessary to + support the associated business process (for example, until completion of the related + payment card transaction). + + - id: 1.4.5 + title: The disclosure of internal IP addresses and routing information is limited to only + authorized parties. + description: |- + Internal network information is protected from unauthorized disclosure. + levels: + - base + status: pending + + - id: '1.5' + title: Risks to the CDE from computing devices that are able to connect to both untrusted networks + and the CDE are mitigated. + levels: + - base + status: pending + controls: + - id: 1.5.1 + title: Security controls are implemented on any computing devices, including company- and + employee-owned devices, that connect to both untrusted networks (including the Internet) + and the CDE + description: |- + Security controls are implemented on any computing devices, including company- and + employee-owned devices, that connect to both untrusted networks (including the Internet) + and the CDE as follows: + - Specific configuration settings are defined to prevent threats being introduced into the + entity's network. + - Security controls are actively running. + - Security controls are not alterable by users of the computing devices unless + specifically documented and authorized by management on a case-by-case basis for a limited + period. + levels: + - base + status: pending + notes: |- + To ensure this requirement, a manual analysis of site policy and topology is inevitable. + From the technical perspective, previous requirements should already cover this + requirement at some level. + + - id: '2.1' + title: Processes and mechanisms for applying secure configurations to all system components are + defined and understood. + levels: + - base + status: manual + controls: + - id: 2.1.1 + title: All security policies and operational procedures that are identified in Requirement + 2 are Documented, Kept up to date, In use and Known to all affected parties. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that security policies and + operational procedures identified in Requirement 2 are managed in accordance with all + elements specified in this requirement. + + - id: 2.1.2 + title: Roles and responsibilities for performing activities in Requirement 2 are documented, + assigned, and understood. + description: |- + Day-to-day responsibilities for performing all the activities in Requirement 2 are + allocated. Personnel are accountable for successful, continuous operation of these + requirements. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that day-to-day responsibilities + for performing all the activities in Requirement 2 are documented, assigned and understood + by the assigned personnel. + + - id: '2.2' + title: 'System components are configured and managed securely.' + levels: + - base + status: pending + controls: + - id: 2.2.1 + title: Configuration standards are developed, implemented, and maintained + description: |- + Configuration standards are developed, implemented, and maintained to: + - Cover all system components. + - Address all known security vulnerabilities. + - Be consistent with industry-accepted system hardening standards or vendor hardening + recommendations. + - Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1. + - Be applied when new systems are configured and verified as in place before or + immediately after a system component is connected to a production environment. + levels: + - base + status: partial + notes: |- + Interestingly this requirement recommends other standards, such as Center for Internet + Security (CIS), International Organization for Standardization (ISO), National Institute + of Standards and Technology (NIST), Cloud Security Alliance, and product vendors. So, the + rules included here are very generic in terms of hardening. + controls: + - base_sle16:SLES-16-16016020 + + - id: 2.2.2 + title: Vendor default accounts are managed. + description: |- + Vendor default accounts are managed as follows: + - If the vendor default account(s) will be used, the default password is changed per + Requirement 8.3.6. + - If the vendor default account(s) will not be used, the account is removed or disabled. + levels: + - base + status: pending + notes: |- + Also related to requirement 8.2.6 and 8.3.5. + + - id: 2.2.3 + title: 'Primary functions requiring different security levels are managed' + levels: + - base + status: manual + + - id: 2.2.4 + title: Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary + functionality is removed or disabled + description: |- + System components cannot be compromised by exploiting unnecessary functionality present in + the system component. + levels: + - base + status: pending + + - id: 2.2.5 + title: If any insecure services, protocols, or daemons are present, business justification + is documented and the risk is reduced. + description: |- + If any insecure services, protocols, or daemons are present: + - Business justification is documented. + - Additional security features are documented and implemented that reduce the risk of + using insecure services, protocols, or daemons. + levels: + - base + status: manual + notes: |- + Known insecure services are removed or disabled by 2.2.4 + General security measures are covered by 1.2.6 + This requirement is more about checking exceptions and their respective documentation. + + - id: 2.2.6 + title: System security parameters are configured to prevent misuse. + description: |- + System components cannot be compromised because of incorrect security parameter + configuration. + levels: + - base + status: pending + notes: |- + This requirement is not specific but also points to 2.2.1, where other policies are + referenced. Therefore, the most common rules related to system configuration in order to + prevent misuse and selected in main profiles are also selected here. + + - id: 2.2.7 + title: All non-console administrative access is encrypted using strong cryptography. + description: |- + Cleartext administrative authorization factors cannot be read or intercepted from any + network transmissions. This includes administrative access via browser-based interfaces + and application programming interfaces (APIs). + levels: + - base + status: pending + notes: |- + Related to requirement 12.3.3. + + - id: '2.3' + title: Wireless environments are configured and managed securely. + levels: + - base + status: supported + controls: + - id: 2.3.1 + title: For wireless environments connected to the CDE or transmitting account data, all wireless + vendor defaults are changed at installation or are confirmed to be secure. + description: |- + For wireless environments connected to the CDE or transmitting account data, all wireless + vendor defaults are changed at installation or are confirmed to be secure, including but + not limited to: + - Default wireless encryption keys. + - Passwords on wireless access points. + - SNMP defaults. + - Any other security-related wireless vendor defaults. + levels: + - base + status: supported + notes: |- + Wireless interfaces are disabled by 1.3.3. + + - id: 2.3.2 + title: For wireless environments connected to the CDE or transmitting account data, wireless + encryption keys are changed + description: |- + For wireless environments connected to the CDE or transmitting account + data, wireless encryption keys are changed + levels: + - base + status: supported + notes: |- + Wireless interfaces are disabled by 1.3.3. + + - id: '3.1' + title: Processes and mechanisms for protecting stored account data are defined and understood. + levels: + - base + status: manual + controls: + - id: 3.1.1 + title: All security policies and operational procedures that are identified in Requirement + 3 are Documented, Kept up to date, In use and Known to all affected parties. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that security policies and + operational procedures identified in Requirement 3 are managed in accordance with all + elements specified in this requirement. + + - id: 3.1.2 + title: Roles and responsibilities for performing activities in Requirement 3 are documented, + assigned, and understood. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that day-to-day responsibilities + for performing all the activities in Requirement 3 are documented, assigned and understood + by the assigned personnel. + + - id: '3.2' + title: Storage of account data is kept to a minimum. + levels: + - base + status: manual + controls: + - id: 3.2.1 + title: Account data storage is kept to a minimum through implementation of data retention + and disposal policies, procedures, and processes. + description: |- + Account data storage is kept to a minimum through implementation of data retention and + disposal policies, procedures, and processes that include at least the following: + - Coverage for all locations of stored account data. + - Coverage for any sensitive authentication data (SAD) stored prior to completion of + authorization. + - Limiting data storage amount and retention time to that which is required for legal or + regulatory, and/or business requirements. + - Specific retention requirements for stored account data that defines length of retention + period and includes a documented business justification. + - Processes for secure deletion or rendering account data unrecoverable when no longer + needed per the retention policy. + - A process for verifying, at least once every three months, that stored account data + exceeding the defined retention period has been securely deleted or rendered unrecoverable. + levels: + - base + status: manual + notes: |- + This requirement is very dependent on each site policies and business model. + Local policies should be consulted and audited. Manual checking is reasonable. + + - id: '3.3' + title: Sensitive authentication data (SAD) is not stored after authorization. + levels: + - base + status: pending + controls: + - id: 3.3.1 + title: SAD is not stored after authorization, even if encrypted. All sensitive authentication + data received is rendered unrecoverable upon completion of the authorization process. + description: |- + This requirement is not eligible for the customized approach. This requirement does not + apply to issuers and companies that support issuing services (where SAD is needed for a + legitimate issuing business need) and have a business justification to store the sensitive + authentication data. Refer to Requirement 3.3.3 for additional requirements specifically + for issuers. Sensitive authentication data includes the data cited in Requirements 3.3.1.1 + through 3.3.1.3. + levels: + - base + status: pending + controls: + - id: 3.3.1.1 + title: The full contents of any track are not stored upon completion of the authorization + process. + description: |- + This requirement is not eligible for the customized approach. In the normal course of + business, the following data elements from the track may need to be retained: + - Cardholder name. + - Primary account number (PAN). + - Expiration date. + - Service code. + To minimize risk, store securely only these data elements as needed for business. + levels: + - base + status: pending + notes: |- + This requirement consists in auditing files, databases and memory to make sure the full + content of any track is not unnecessarily stored. It involves manual auditing but some + automated rules fit this requirement in order to reduce the chances if this data be + unintentionally stored in memory. + + - id: 3.3.1.2 + title: The card verification code is not stored upon completion of the authorization + process. + description: |- + This requirement is not eligible for the customized approach. The card verification code + is the three- or four-digit number printed on the front or back of a payment card used + to verify card-not-present transactions. + levels: + - base + status: pending + notes: |- + Same rules already selected in 3.3.1.1 are valid here, but they are not repeated. + + - id: 3.3.1.3 + title: The personal identification number (PIN) and the PIN block are not stored upon + completion of the authorization process. + description: |- + This requirement is not eligible for the customized approach. PIN blocks are encrypted + during the natural course of transaction processes, but even if an entity encrypts the + PIN block again, it is still not allowed to be stored after the completion of the + authorization process. + levels: + - base + status: pending + notes: |- + Same rules already selected in 3.3.1.1 are valid here, but they are not repeated. + + - id: 3.3.2 + title: SAD that is stored electronically prior to completion of authorization is encrypted + using strong cryptography. + description: |- + This requirement is not eligible for the customized approach. Whether SAD is permitted to + be stored prior to authorization is determined by the organizations that manage compliance + programs (for example, payment brands and acquirers). Contact the organizations of + interest for any additional criteria. This requirement applies to all storage of SAD, even + if no PAN is present in the environment. Refer to Requirement 3.2.1 for an additional + requirement that applies if SAD is stored prior to completion of authorization. Issuers + and companies that support issuing services, where there is a legitimate and documented + business need to store SAD, are not required to meet this requirement. A legitimate + business need is one that is necessary for the performance of the function being provided + by or for the issuer. Refer to Requirement 3.3.3 for requirements specifically for issuers. + This requirement does not replace how PIN blocks are required to be managed, nor does it + mean that a properly encrypted PIN block needs to be encrypted again. + levels: + - base + status: manual + notes: |- + This requirement is a best practice until 31 March 2025, after which it will be required + and must be fully considered during a PCI DSS assessment. + This requirement consists of auditing information stored during a relatively short period + of time. Where and how the information is possibly stored depends in each Business and + local policies so the check is not actually automatable. + + - id: 3.3.3 + title: Additional requirement for issuers and companies that support issuing services and + store sensitive authentication data. + description: |- + Additional requirement for issuers and companies that support issuing services and store + sensitive authentication data: Any storage of sensitive authentication data is: + - Limited to that which is needed for a legitimate issuing business need and is secured. + - Encrypted using strong cryptography. This bullet is a best practice until until + 31 March 2025, after which it will be required as part of Requirement 3.3.3 and must be + fully considered during a PCI DSS assessment. + levels: + - base + status: manual + + - id: '3.4' + title: Access to displays of full PAN and ability to copy PAN is restricted. + levels: + - base + status: pending + controls: + - id: 3.4.1 + title: PAN is masked when displayed (the BIN and last four digits are the maximum number + of digits to be displayed), such that only personnel with a legitimate business need + can see more than the BIN and last four digits of the PAN. + description: |- + PAN displays are restricted to the minimum number of digits necessary to meet a defined + business need. This requirement does not supersede stricter requirements in place for + displays of cardholder data — for example, legal or payment brand requirements for + point-of-sale (POS) receipts. This requirement relates to protection of PAN where it is + displayed on screens, paper receipts, printouts, etc., and is not to be confused with + Requirement 3.5.1 for protection of PAN when stored, processed, or transmitted. + levels: + - base + status: manual + notes: |- + Consists on examining documented policies and procedures, checking system configurations + and observing relevant applications. + + - id: 3.4.2 + title: When using remote-access technologies, technical controls prevent copy and/or relocation + of PAN for all personnel, except for those with documented, explicit authorization and + a legitimate, defined business need. + description: |- + PAN cannot be copied or relocated by unauthorized personnel using remote-access + technologies. Storing or relocating PAN onto local hard drives, removable electronic + media, and other storage devices brings these devices into scope for PCI DSS. + This requirement is a best practice until 31 March 2025, after which it will be required + and must be fully considered during a PCI DSS assessment. + levels: + - base + status: pending + notes: |- + There are technical rules to disable removable storage devices. However, this requirement + still demand some manual auditing in documentation and eventual exceptions. + + - id: '3.5' + title: Primary account number (PAN) is secured wherever it is stored. + levels: + - base + status: pending + controls: + - id: 3.5.1 + title: PAN is rendered unreadable anywhere it is stored + description: |- + PAN is rendered unreadable anywhere it is stored by using any of the following approaches: + - One-way hashes based on strong cryptography of the entire PAN. + - Truncation (hashing cannot be used to replace the truncated segment of PAN). + - If hashed and truncated versions of the same PAN, or different truncation formats of + the same PAN, are present in an environment, additional controls are in place such that + the different versions cannot be correlated to reconstruct the original PAN. + - Indexes tokens. + - Strong cryptography with associated key-management processes and procedures. + levels: + - base + status: pending + controls: + - id: 3.5.1.1 + title: Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) + are keyed cryptographic hashes of the entire PAN, with associated key-management + processes and procedures in accordance with Requirements 3.6 and 3.7. + description: |- + All Applicability Notes for Requirement 3.5.1 also apply to this requirement. + Key-management processes and procedures (Requirements 3.6 and 3.7) do not apply to + system components used to generate individual keyed hashes of a PAN for comparison to + another system if: + - The system components only have access to one hash value at a time (hash values are + not stored on the system) + AND + - There is no other account data stored on the same system as the hashes. + This requirement is considered a best practice until 31 March 2025, after which it will + be required and must be fully considered during a PCI DSS assessment. This requirement + will replace the bullet in Requirement 3.5.1 for one-way hashes once its effective date + is reached. + levels: + - base + status: planned + notes: |- + This requirement likely demand assessment in application level for some environments and + this would be too specific to be automated. However, on system level we can ensure some + strong cryptographic algorithms. This is also generally covered by 2.2.7 but here would + be possible to include more specific rules, for openssl and libreswan for example. + However it would be first necessary to include a platform conditional in these rules + before selecting them so they are applicable only if the respective packages are + installed. + + - id: 3.5.1.2 + title: If disk-level or partition-level encryption (rather than file-, column-, or + field-level database encryption) is used to render PAN unreadable, it is implemented + only on removable electronic media or complemented by another mechanism that meets + Requirement 3.5.1 + levels: + - base + status: pending + + - id: 3.5.1.3 + title: If disk-level or partition-level encryption is used (rather than file-, column-, + or field--level database encryption) to render PAN unreadable, it is managed. + description: |- + If disk-level or partition-level encryption is used (rather than file-, column-, or + field--level database encryption) to render PAN unreadable, it is managed as follows: + - Logical access is managed separately and independently of native operating system + authentication and access control mechanisms. + - Decryption keys are not associated with user accounts. + - Authentication factors (passwords, passphrases, or cryptographic keys) that allow + access to unencrypted data are stored securely. + levels: + - base + status: manual + notes: |- + To properly check this requirement, site policies and documentation should be consulted. + + - id: '3.6' + title: Cryptographic keys used to protect stored account data are secured. + levels: + - base + status: manual + controls: + - id: 3.6.1 + title: Procedures are defined and implemented to protect cryptographic keys used to protect + stored account data against disclosure and misuse. + description: |- + Procedures are defined and implemented to protect cryptographic keys used to protect + stored account data against disclosure and misuse that include: + - Access to keys is restricted to the fewest number of custodians necessary. + - Key-encrypting keys are at least as strong as the data-encrypting keys they protect. + - Key-encrypting keys are stored separately from data-encrypting keys. + - Keys are stored securely in the fewest possible locations and forms. + levels: + - base + status: manual + controls: + - id: 3.6.1.1 + title: 'Additional requirement for service providers only: A documented description + of the cryptographic architecture is maintained' + description: |- + Additional requirement for service providers only: A documented description of the + cryptographic architecture is maintained that includes: + - Details of all algorithms, protocols, and keys used for the protection of stored + account data, including key strength and expiry date. + - Preventing the use of the same cryptographic keys in production and test environments. + This bullet is a best practice until 31 March 2025, after which it will be required as + part of Requirement 3.6.1.1 and must be fully considered during a PCI DSS assessment. + - Description of the key usage for each key. + - Inventory of any hardware security modules (HSMs), key management systems (KMS), and + other secure cryptographic devices (SCDs) used for key management, including type and + location of devices, as outlined in Requirement 12.3.4. + levels: + - base + status: manual + + - id: 3.6.1.2 + title: Secret and private keys used to encrypt/decrypt stored account data are stored + in secure forms. + description: |- + Secret and private keys used to encrypt/decrypt stored account data are stored in one + (or more) of the following forms at all times: + - Encrypted with a key-encrypting key that is at least as strong as the data-encrypting + key, and that is stored separately from the data-encrypting key. + - Within a secure cryptographic device (SCD), such as a hardware security module (HSM) + or PTS-approved point-of-interaction device. + - As at least two full-length key components or key shares, in accordance with an + industry-accepted method. + Secret and private keys are stored in a secure form that prevents unauthorized retrieval + or access. It is not required that public keys be stored in one of these forms. + Cryptographic keys stored as part of a key management system (KMS) that employs SCDs are + acceptable. A cryptographic key that is split into two parts does not meet this + requirement. Secret or private keys stored as key components or key shares must be + generated via one of the following + levels: + - base + status: manual + + - id: 3.6.1.3 + title: Access to cleartext cryptographic key components is restricted to the fewest + number of custodians necessary. + description: |- + Access to cleartext cryptographic key components is restricted to necessary personnel. + levels: + - base + status: manual + + - id: 3.6.1.4 + title: Cryptographic keys are stored in the fewest possible locations. + description: |- + Cryptographic keys are retained only where necessary. + levels: + - base + status: manual + + - id: '3.7' + title: Where cryptography is used to protect stored account data, key management processes and + procedures covering all aspects of the key lifecycle are defined and implemented. + levels: + - base + status: manual + controls: + - id: 3.7.1 + title: Key-management policies and procedures are implemented to include generation of strong + cryptographic keys used to protect stored account data. + description: |- + Strong cryptographic keys are generated. + levels: + - base + status: manual + + - id: 3.7.2 + title: Key-management policies and procedures are implemented to include secure distribution + of cryptographic keys used to protect stored account data. + description: |- + Cryptographic keys are secured during distribution. + levels: + - base + status: manual + + - id: 3.7.3 + title: Key-management policies and procedures are implemented to include secure storage of + cryptographic keys used to protect stored account data. + description: |- + Cryptographic keys are secured when stored. + levels: + - base + status: manual + notes: |- + The scope of this requirement seems much wider going even to application level, which + might be different for each site. Regarding local system there are some technical measures + ensured by 2.2.6. + + - id: 3.7.4 + title: Key management policies and procedures are implemented for cryptographic key changes + for keys that have reached the end of their cryptoperiod, as defined by the associated + application vendor or key owner, and based on industry best practices and guidelines. + description: |- + Key management policies and procedures are implemented for cryptographic key changes for + keys that have reached the end of their cryptoperiod, as defined by the associated + application vendor or key owner, and based on industry best practices and guidelines, + including the following: + - A defined cryptoperiod for each key type in use. + - A process for key changes at the end of the defined cryptoperiod. + levels: + - base + status: manual + + - id: 3.7.5 + title: Key management policies procedures are implemented to include the retirement, replacement, + or destruction of keys used to protect stored account data, as deemed necessary. + description: |- + Key management policies procedures are implemented to include the retirement, replacement, + or destruction of keys used to protect stored account data, as deemed necessary when: + - The key has reached the end of its defined cryptoperiod. + - The integrity of the key has been weakened, including when personnel with knowledge of a + cleartext key component leaves the company, or the role for which the key component was + known. + - The key is suspected of or known to be compromised. + - Retired or replaced keys are not used for encryption operations. + levels: + - base + status: manual + + - id: 3.7.6 + title: Where manual cleartext cryptographic key-management operations are performed by personnel, + key-management policies and procedures are implemented include managing these operations + using split knowledge and dual control. + description: |- + Cleartext secret or private keys cannot be known by anyone. Operations involving cleartext + keys cannot be carried out by a single person. This control is applicable for manual + key-management operations or where key management is not controlled by the encryption + product. A cryptographic key that is simply split into two parts does not meet this + requirement. Secret or private keys stored as key components or key shares must be + generated via one of the following + levels: + - base + status: manual + + - id: 3.7.7 + title: Key management policies and procedures are implemented to include the prevention of + unauthorized substitution of cryptographic keys. + description: |- + Cryptographic keys cannot be substituted by unauthorized personnel. + levels: + - base + status: manual + + - id: 3.7.8 + title: Key management policies and procedures are implemented to include that cryptographic + key custodians formally acknowledge (in writing or electronically) that they understand + and accept their key-custodian responsibilities. + description: |- + Key custodians are knowledgeable about their responsibilities in relation to cryptographic + operations and can access assistance and guidance when required. + levels: + - base + status: manual + + - id: 3.7.9 + title: 'Additional requirement for service providers only: Where a service provider shares + cryptographic keys with its customers for transmission or storage of account data, guidance + on secure transmission, storage and updating of such keys is documented and distributed + to the service provider’s customers.' + description: |- + Customers are provided with appropriate key management guidance whenever they receive + shared cryptographic keys. This requirement applies only when the entity being assessed is + a service provider. + levels: + - base + status: manual + + - id: '4.1' + title: Processes and mechanisms for protecting cardholder data with strong cryptography during + transmission over open, public networks are defined and documented. + levels: + - base + status: manual + controls: + - id: 4.1.1 + title: All security policies and operational procedures that are identified in Requirement + 4 are Documented, Kept up to date, In use and Known to all affected parties. + levels: + - base + status: manual + + - id: 4.1.2 + title: Roles and responsibilities for performing activities in Requirement 4 are documented, + assigned, and understood. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that day-to-day responsibilities + for performing all the activities in Requirement 4 are documented, assigned and understood + by the assigned personnel. + + - id: '4.2' + title: PAN is protected with strong cryptography during transmission. + levels: + - base + status: manual + controls: + - id: 4.2.1 + title: Strong cryptography and security protocols are implemented as follows to safeguard + PAN during transmission over open, public networks. + description: |- + Strong cryptography and security protocols are implemented as follows to safeguard PAN + during transmission over open, public networks: + - Only trusted keys and certificates are accepted. + - Certificates used to safeguard PAN during transmission over open, public networks are + confirmed as valid and are not expired or revoked. This bullet is a best practice until + 31 March 2025, after which it will be required as part of Requirement 4.2.1 and must be + fully considered during a PCI DSS assessment. + - The protocol in use supports only secure versions or configurations and does not support + fallback to, or use of insecure versions, algorithms, key sizes, or implementations. + - The encryption strength is appropriate for the encryption methodology in use. + levels: + - base + status: supported + controls: + - id: 4.2.1.1 + title: An inventory of the entity's trusted keys and certificates used to protect PAN + during transmission is maintained. + description: |- + All keys and certificates used to protect PAN during transmission are identified and + confirmed as trusted. This requirement is a best practice until 31 March 2025, after + which it will be required and must be fully considered during a PCI DSS assessment. + levels: + - base + status: manual + + - id: 4.2.1.2 + title: Wireless networks transmitting PAN or connected to the CDE use industry best + practices to implement strong cryptography for authentication and transmission. + description: |- + Cleartext PAN cannot be read or intercepted from wireless network transmissions. + levels: + - base + status: manual + notes: |- + Wireless interfaces are disabled by 1.3.3. + + - id: 4.2.2 + title: PAN is secured with strong cryptography whenever it is sent via end-user messaging + technologies. + description: |- + Cleartext PAN cannot be read or intercepted from transmissions using end-user messaging + technologies. This requirement also applies if a customer, or other third-party, requests + that PAN is sent to them via end-user messaging technologies. There could be occurrences + where an entity receives unsolicited cardholder data via an insecure communication channel + that was not intended for transmissions of sensitive data. In this situation, the entity + can choose to either include the channel in the scope of their CDE and secure it according + to PCI DSS or delete the cardholder data and implement measures to prevent the channel + from being used for cardholder data. + levels: + - base + status: manual + notes: |- + Some known insecure services and protocols are disabled by 2.2.4. + If any specific end-user messaging technology is used, it should be manually checked in + alignment to site policies. + + - id: '5.1' + title: Processes and mechanisms for protecting all systems and networks from malicious software + are defined and understood. + levels: + - base + status: manual + controls: + - id: 5.1.1 + title: All security policies and operational procedures that are identified in Requirement + 5 are Documented, Kept up to date, In use and Known to all affected parties. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that security policies and + operational procedures identified in Requirement 5 are managed in accordance with all + elements specified in this requirement. + + - id: 5.1.2 + title: Roles and responsibilities for performing activities in Requirement 5 are documented, + assigned, and understood. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that day-to-day responsibilities + for performing all the activities in Requirement 5 are documented, assigned and understood + by the assigned personnel. + + - id: '5.2' + title: Malicious software (malware) is prevented, or detected and addressed. + levels: + - base + status: pending + notes: |- + Related measures are covered by 1.2.6, 1.4.5 and 3.4.2. + controls: + - id: 5.2.1 + title: An anti-malware solution(s) is deployed on all system components, except for those + system components identified in periodic evaluations per Requirement 5.2.3 that concludes + the system components are not at risk from malware. + description: |- + Automated mechanisms are implemented to prevent systems from becoming an attack vector for + malware. + levels: + - base + status: supported + notes: |- + There are many options of anti-malware and the criteria for any adopted solution or + approach relies on each site policy. Technologies are supported but manual assessment is + required. + + - id: 5.2.2 + title: The deployed anti-malware solution(s) detects all known types of malware and removes, + blocks, or contains all known types of malware. + levels: + - base + status: manual + + - id: 5.2.3 + title: Any system components that are not at risk for malware are evaluated periodically. + description: |- + Any system components that are not at risk for malware are evaluated periodically to + include the following: + - A documented list of all system components not at risk for malware. + - Identification and evaluation of evolving malware threats for those system components. + - Confirmation whether such system components continue to not require anti-malware + protection. + levels: + - base + status: manual + controls: + - id: 5.2.3.1 + title: The frequency of periodic evaluations of system components identified as not + at risk for malware is defined in the entity's targeted risk analysis, which is + performed according to all elements specified in Requirement 12.3.1. + description: |- + Systems not known to be at risk from malware are re-evaluated at a frequency that + addresses the entity's risk. This requirement is a best practice until 31 March 2025, + after which it will be required and must be fully considered during a PCI DSS + assessment. + levels: + - base + status: manual + + - id: '5.3' + title: Anti-malware mechanisms and processes are active, maintained, and monitored. + levels: + - base + status: manual + controls: + - id: 5.3.1 + title: The anti-malware solution(s) is kept current via automatic updates. + description: |- + Anti-malware mechanisms can detect and address the latest malware threats. + levels: + - base + status: manual + + - id: 5.3.2 + title: The anti-malware solution(s) performs periodic scans and active or real-time scans + or performs continuous behavioral analysis of systems or processes. + levels: + - base + status: manual + controls: + - id: 5.3.2.1 + title: If periodic malware scans are performed to meet Requirement 5.3.2, the frequency + of scans is defined in the entity's targeted risk analysis, which is performed + according to all elements specified in Requirement 12.3.1. + description: |- + Scans by the malware solution are performed at a frequency that addresses the entity's + risk. This requirement applies to entities conducting periodic malware scans to meet + Requirement 5.3.2. This requirement is a best practice until 31 March 2025, after which + it will be required and must be fully considered during a PCI DSS assessment. + levels: + - base + status: manual + + - id: 5.3.3 + title: For removable electronic media, the anti-malware solution(s) performs automatic scans + of when the media is inserted, connected, or logically mounted, or Performs continuous + behavioral analysis of systems or processes when the media is inserted, connected, or + logically mounted. + levels: + - base + status: manual + notes: |- + Related measures are covered by 3.4.2. + + - id: 5.3.4 + title: Audit logs for the anti-malware solution(s) are enabled and retained in accordance + with Requirement 10.5.1. + description: |- + Historical records of anti-malware actions are immediately available and retained for at + least 12 months. + levels: + - base + status: manual + + - id: 5.3.5 + title: Anti-malware mechanisms cannot be disabled or altered by users, unless specifically + documented, and authorized by management on a case-by-case basis for a limited time period. + description: |- + Anti-malware mechanisms cannot be modified by unauthorized personnel.Anti-malware + solutions may be temporarily disabled only if there is a legitimate technical need, as + authorized by management on a case-by-case basis. If anti-malware protection needs to be + disabled for a specific purpose, it must be formally authorized. Additional security + measures may also need to be implemented for the period during which anti-malware + protection is not active. + levels: + - base + status: manual + notes: |- + Related measures are covered by 2.2.6 requirement and 8.2 section. + + - id: '5.4' + title: Anti-phishing mechanisms protect users against phishing attacks. + levels: + - base + status: manual + controls: + - id: 5.4.1 + title: Processes and automated mechanisms are in place to detect and protect personnel against + phishing attacks. + description: |- + Mechanisms are in place to protect against and mitigate risk posed by phishing attacks. + The focus of this requirement is on protecting personnel with access to system components + in-scope for PCI DSS. Meeting this requirement for technical and automated controls to + detect and protect personnel against phishing is not the same as Requirement 12.6.3.1 for + security awareness training. Meeting this requirement does not also meet the requirement + for providing personnel with security awareness training, and vice versa. This requirement + is a best practice until 31 March 2025, after which it will be required and must be fully + considered during a PCI DSS assessment. + levels: + - base + status: manual + + - id: '6.1' + title: Processes and mechanisms for developing and maintaining secure systems and software are + defined and understood. + levels: + - base + status: manual + controls: + - id: 6.1.1 + title: All security policies and operational procedures that are identified in Requirement + 6 are Documented, Kept up to date, In use and Known to all affected parties. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that security policies and + operational procedures identified in Requirement 6 are managed in accordance with all + elements specified in this requirement. + + - id: 6.1.2 + title: Roles and responsibilities for performing activities in Requirement 6 are documented, + assigned, and understood. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that day-to-day responsibilities + for performing all the activities in Requirement 6 are documented, assigned and understood + by the assigned personnel. + + - id: '6.2' + title: Bespoke and custom software are developed securely. + levels: + - base + status: manual + controls: + - id: 6.2.1 + title: Bespoke and custom software are developed securely. + description: |- + Bespoke and custom software are developed securely, as follows: + - Based on industry standards and/or best practices for secure development. + - In accordance with PCI DSS (for example, secure authentication and logging). + - Incorporating consideration of information security issues during each stage of the + software development lifecycle. + levels: + - base + status: manual + + - id: 6.2.2 + title: Software development personnel working on bespoke and custom software are trained + at least once every 12 months + description: |- + Software development personnel working on bespoke and custom software are trained at least + once every 12 months as follows: + - On software security relevant to their job function and development languages. + - Including secure software design and secure coding techniques. + - Including, if security testing tools are used, how to use the tools for detecting + vulnerabilities in software. + levels: + - base + status: manual + + - id: 6.2.3 + title: Bespoke and custom software is reviewed prior to being released into production or + to customers, to identify and correct potential coding vulnerabilities. + description: |- + Bespoke and custom software is reviewed prior to being released into production or to + customers, to identify and correct potential coding vulnerabilities, as follows: + - Code reviews ensure code is developed according to secure coding guidelines. + - Code reviews look for both existing and emerging software vulnerabilities. + - Appropriate corrections are implemented prior to release. + levels: + - base + status: manual + controls: + - id: 6.2.3.1 + title: If manual code reviews are performed for bespoke and custom software prior to + release to production code changes co-reviewed and approved. + description: |- + If manual code reviews are performed for bespoke and custom software prior to release + to production code changes are: + - Reviewed by individuals other than the originating code author, and who are + knowledgeable about code-review techniques and secure coding practices. + - Reviewed and approved by management prior to release. + levels: + - base + status: manual + + - id: 6.2.4 + title: Software engineering techniques or other methods are defined and in use by software + development personnel to prevent or mitigate common software attacks and related vulnerabilities + in bespoke and custom software. + levels: + - base + status: manual + + - id: '6.3' + title: Security vulnerabilities are identified and addressed. + levels: + - base + status: pending + controls: + - id: 6.3.1 + title: Security vulnerabilities are identified and managed + levels: + - base + status: manual + + - id: 6.3.2 + title: An inventory of bespoke and custom software, and third-party software components incorporated + into bespoke and custom software is maintained to facilitate vulnerability and patch + management. + description: |- + Known vulnerabilities in third-party software components cannot be exploited in bespoke + and custom software.This requirement is a best practice until 31 March 2025, after which + it will be required and must be fully considered during a PCI DSS assessment. + levels: + - base + status: manual + notes: |- + This requirement is a best practice until 31 March 2025, after which it will be required + and must be fully considered during a PCI DSS assessment. + + - id: 6.3.3 + title: All system components are protected from known vulnerabilities by installing applicable + security patches/updates. + description: |- + All system components are protected from known vulnerabilities by installing + applicable security patches/updates as follows: + - Patches/updates for critical vulnerabilities (identified according to the risk ranking + process at Requirement 6.3.1) are installed within one month of release. + - All other applicable security patches/updates are installed within an appropriate time + frame as determined by the entity's assessment of the criticality of the risk to the + environment as identified according to the risk ranking process at Requirement 6.3.1. + levels: + - base + status: pending + + - id: '6.4' + title: Public-facing web applications are protected against attacks. + levels: + - base + status: manual + controls: + - id: 6.4.1 + title: For public-facing web applications, new threats and vulnerabilities are addressed + on an ongoing basis and these applications are protected against known attacks. + description: |- + For public-facing web applications, new threats and vulnerabilities are addressed on an + ongoing basis and these applications are protected against known attacks as follows: + - Reviewing public-facing web applications via manual or automated application + vulnerability security assessment tools or methods as follows: + - At least once every 12 months and after significant changes. + - By an entity that specializes in application security. + - Including, at a minimum, all common software attacks in Requirement 6.2.4. + - All vulnerabilities are ranked in accordance with requirement 6.3.1. + - All vulnerabilities are corrected. + - The application is re-evaluated after the corrections + OR + - Installing an automated technical solution(s) that continually detects and prevents + web-based attacks as follows: + - Installed in front of public-facing web applications to detect and prevent web-based + attacks. + - Actively running and up to date as applicable. + - Generating audit logs. + - Configured to either block web-based attacks or generate an alert that is immediately + investigated. + levels: + - base + status: manual + + - id: 6.4.2 + title: For public-facing web applications, an automated technical solution is deployed that + continually detects and prevents web-based attacks. + levels: + - base + status: manual + + - id: 6.4.3 + title: All payment page scripts that are loaded and executed in the consumer's browser are + managed + description: |- + All payment page scripts that are loaded and executed in the consumer's browser are + managed as follows: + - A method is implemented to confirm that each script is authorized. + - A method is implemented to assure the integrity of each script. + - An inventory of all scripts is maintained with written business or technical + justification as to why each is necessary. + levels: + - base + status: manual + + - id: '6.5' + title: Changes to all system components are managed securely. + levels: + - base + status: manual + controls: + - id: 6.5.1 + title: Changes to all system components in the production environment are made according + to established procedures. + levels: + - base + status: manual + + - id: 6.5.2 + title: Upon completion of a significant change, all applicable PCI DSS requirements are confirmed + to be in place on all new or changed systems and networks, and documentation is updated + as applicable. + description: |- + All system components are verified after a significant change to be compliant with the + applicable PCI DSS requirements.These significant changes should also be captured and + reflected in the entity's annual PCI DSS scope confirmation activity per Requirement + 12.5.2. + levels: + - base + status: manual + + - id: 6.5.3 + title: Pre-production environments are separated from production environments and the separation + is enforced with access controls. + description: |- + Pre-production environments cannot introduce risks and vulnerabilities into production + environments. + levels: + - base + status: manual + + - id: 6.5.4 + title: Roles and functions are separated between production and pre-production environments + to provide accountability such that only reviewed and approved changes are deployed. + description: |- + Job roles and accountability that differentiate between pre-production and production + activities are defined and managed to minimize the risk of unauthorized, unintentional, + or inappropriate actions. In environments with limited personnel where individuals perform + multiple roles or functions, this same goal can be achieved with additional procedural + controls that provide accountability. For example, a developer may also be an administrator + that uses an administrator-level account with elevated privileges in the development + environment and, for their developer role, they use a separate account with user-level + access to the production environment. + levels: + - base + status: manual + + - id: 6.5.5 + title: Live PANs are not used in pre-production environments, except where those environments + are included in the CDE and protected in accordance with all applicable PCI DSS requirements. + description: |- + Live PANs cannot be present in pre-production environments outside the CDE.s + levels: + - base + status: manual + + - id: 6.5.6 + title: Test data and test accounts are removed from system components before the system goes + into production. + description: |- + Test data and test accounts cannot exist in production environments. + levels: + - base + status: manual + + - id: '7.1' + title: Processes and mechanisms for restricting access to system components and cardholder data + by business need to know are defined and understood. + levels: + - base + status: manual + controls: + - id: 7.1.1 + title: All security policies and operational procedures that are identified in Requirement + 7 are Documented, Kept up to date, In use and Known to all affected parties. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that security policies and + operational procedures identified in Requirement 7 are managed in accordance with all + elements specified in this requirement. + + - id: 7.1.2 + title: Roles and responsibilities for performing activities in Requirement 7 are documented, + assigned, and understood. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that day-to-day responsibilities + for performing all the activities in Requirement 7 are documented, assigned and understood + by the assigned personnel. + + - id: '7.2' + title: Access to system components and data is appropriately defined and assigned. + levels: + - base + status: manual + controls: + - id: 7.2.1 + title: An access control model is defined and includes granting access + description: |- + An access control model is defined and includes granting access as follows: + - Appropriate access depending on the entity's business and access needs. + - Access to system components and data resources that is based on users' job + classification and functions. + - The least privileges required (for example, user, administrator) to perform a job + function. + levels: + - base + status: manual + notes: |- + General access are restricted by 2.2.6 and 8.2 section. This requirement is more about + checking granting access process. + + - id: 7.2.2 + title: Access is assigned to users, including privileged users, based on job classification + and function, and least privileges necessary to perform job responsibilities. + levels: + - base + status: manual + + - id: 7.2.3 + title: Required privileges are approved by authorized personnel. + description: |- + Access privileges cannot be granted to users without appropriate, documented + authorization. + levels: + - base + status: manual + + - id: 7.2.4 + title: All user accounts and related access privileges, including third-party/vendor accounts, + are reviewed + description: |- + All user accounts and related access privileges, including third-party/vendor accounts, + are reviewed as follows: + - At least once every six months. + - To ensure user accounts and access remain appropriate based on job function. + - Any inappropriate access is addressed. + - Management acknowledges that access remains appropriate. + levels: + - base + status: manual + + - id: 7.2.5 + title: All application and system accounts and related access privileges are assigned and + managed. + description: |- + All application and system accounts and related access privileges are assigned and managed + as follows: + - Based on the least privileges necessary for the operability of the system or application. + - Access is limited to the systems, applications, or processes that specifically require + their use. + levels: + - base + status: manual + notes: |- + General access are restricted by 2.2.6 and 8.2 section. + controls: + - id: 7.2.5.1 + title: All access by application and system accounts and related access privileges + are reviewed. + levels: + - base + status: manual + + - id: 7.2.6 + title: All user access to query repositories of stored cardholder data is restricted + levels: + - base + status: manual + notes: |- + This requirement is specific about cardholder data, which can be available in different + formats, such as clear and binary files, and databases depending on site policies. + General system restrictions are covered in 2.2.6. + + - id: '7.3' + title: 'Access to system components and data is managed via an access control system(s).' + levels: + - base + status: planned + controls: + - id: 7.3.1 + title: An access control system(s) is in place that restricts access based on a user's need + to know and covers all system components. + description: |- + Access rights and privileges are managed via mechanisms intended for that purpose. + levels: + - base + status: manual + + - id: 7.3.2 + title: The access control system(s) is configured to enforce permissions assigned to individuals, + applications, and systems based on job classification and function. + description: |- + Individual account access rights and privileges to systems, applications, and data are + only inherited from group membership. + levels: + - base + status: manual + + - id: 7.3.3 + title: The access control system(s) is set to "deny all" by default. + description: |- + Access rights and privileges are prohibited unless expressly permitted. + levels: + - base + status: planned + notes: |- + It is possible we can select some rules for this requirement but more investigation is + needed to confirm. + + - id: '8.1' + title: Processes and mechanisms for identifying users and authenticating access to system components + are defined and understood. + levels: + - base + status: manual + controls: + - id: 8.1.1 + title: All security policies and operational procedures that are identified in Requirement + 8 are Documented, Kept up to date, In use and Known to all affected parties. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that security policies and + operational procedures identified in Requirement 8 are managed in accordance with all + elements specified in this requirement. + + - id: 8.1.2 + title: Roles and responsibilities for performing activities in Requirement 8 are documented, + assigned, and understood. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that day-to-day responsibilities + for performing all the activities in Requirement 8 are documented, assigned and understood + by the assigned personnel. + + - id: '8.2' + title: User identification and related accounts for users and administrators are strictly managed + throughout an account's lifecycle. + levels: + - base + status: pending + controls: + - id: 8.2.1 + title: All users are assigned a unique ID before access to system components or cardholder + data is allowed. + description: |- + All actions by all users are attributable to an individual. This requirement is not + intended to apply to user accounts within point-of-sale terminals that have access to only + one card number at a time to facilitate a single transaction (such as IDs used by cashiers + on point-of-sale terminals). + levels: + - base + status: planned + notes: |- + The rules selected in this requirement are incomplete. Missing remediation and test + scenarios. They should include test scenarios and likely remediation or a warning + informing why a remediation is not present. + + - id: 8.2.2 + title: Group, shared, or generic IDs, or other shared authentication credentials are only + used when necessary on an exception basis, and are managed. + description: |- + - ID use is prevented unless needed for an exceptional circumstance. + - Use is limited to the time needed for the exceptional circumstance. + - Business justification for use is documented. + - Use is explicitly approved by management. + - Individual user identity is confirmed before access to an account is granted. + - Every action taken is attributable to an individual user. + levels: + - base + status: pending + notes: |- + This requirement is complemented by 8.2.1 and related to 8.3.5. + + - id: 8.2.3 + title: 'Additional requirement for service providers only: Service providers with remote + access to customer premises use unique authentication factors for each customer premises.' + levels: + - base + status: manual + + - id: 8.2.4 + title: Addition, deletion, and modification of user IDs, authentication factors, and other + identifier objects are managed + levels: + - base + status: manual + + - id: 8.2.5 + title: Access for terminated users is immediately revoked. + description: |- + The accounts of terminated users cannot be used. + levels: + - base + status: manual + notes: |- + This requirement depends on site policies for user termination. + + - id: 8.2.6 + title: Inactive user accounts are removed or disabled within 90 days of inactivity. + description: |- + Inactive user accounts cannot be used. + levels: + - base + status: pending + notes: |- + Also related to requirements 2.2.2 and 8.3.5. + + - id: 8.2.7 + title: Accounts used by third parties to access, support, or maintain system components via + remote access are managed. + levels: + - base + status: manual + + - id: 8.2.8 + title: If a user session has been idle for more than 15 minutes, the user is required to + re-authenticate to re-activate the terminal or session. + description: |- + A user session cannot be used except by the authorized user. This requirement is not + intended to apply to user accounts on point-of-sale terminals that have access to only one + card number at a time to facilitate a single transaction (such as IDs used by cashiers on + point-of-sale terminals). This requirement is not meant to prevent legitimate activities + from being performed while the console/PC is unattended. + levels: + - base + status: pending + + - id: '8.3' + title: Strong authentication for users and administrators is established and managed. + levels: + - base + status: pending + controls: + - id: 8.3.1 + title: All user access to system components for users and administrators is authenticated. + levels: + - base + status: pending + + - id: 8.3.2 + title: Strong cryptography is used to render all authentication factors unreadable during + transmission and storage on all system components. + description: |- + Cleartext authentication factors cannot be obtained, derived, or reused from the + interception of communications or from stored data. + levels: + - base + status: pending + notes: |- + There are similar rules that might be redundant for some distros. + + - id: 8.3.3 + title: User identity is verified before modifying any authentication factor. + description: |- + Unauthorized individuals cannot gain system access by impersonating the identity of an + authorized user. + levels: + - base + status: manual + notes: |- + This requirement is about processes, such as password resets, provisioning new hardware or + software tokens, and generating new keys. It is common that these activities involve help + desk teams and administrators and the involved people should ensure identities are properly + verified. + + - id: 8.3.4 + title: Invalid authentication attempts are limited. + description: |- + - Locking out the user ID after not more than 10 attempts. + - Setting the lockout duration to a minimum of 30 minutes or until the user's identity is + confirmed. + levels: + - base + status: pending + + - id: 8.3.5 + title: If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, + they are set and reset for each user. + description: |- + - Set to a unique value for first-time use and upon reset. + - Forced to be changed immediately after the first use. + levels: + - base + status: pending + notes: |- + Also related to requirement 2.2.2, 8.2.2 and 8.2.6. + + - id: 8.3.6 + title: If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, + they meet the minimum level of complexity. + description: |- + - A minimum length of 12 characters (or IF the system does not support 12 characters, a + minimum length of eight characters). + - Contain both numeric and alphabetic characters. + A guessed password/passphrase cannot be verified by either an online or offline brute + force attack. + levels: + - base + status: pending + notes: |- + This requirement is not intended to apply to: + - User accounts on point-of-sale terminals that have access to only one card number at a + time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale + terminals). + - Application or system accounts, which are governed by requirements in section 8.6. + + - id: 8.3.7 + title: Individuals are not allowed to submit a new password/passphrase that is the same as + any of the last four passwords/passphrases used. + description: |- + A previously used password cannot be used to gain access to an account for at least 12 + months. + levels: + - base + status: pending + notes: |- + This requirement is not intended to apply to user accounts on point-of-sale terminals that + have access to only one card number at a time to facilitate a single transaction (such as + IDs used by cashiers on point-of-sale terminals). + For RHEL 8 and RHEL 9 systems, the accounts_password_pam_pwhistory_... rules should be + prefered in detriment of accounts_password_pam_unix_remember. Using both should not create + conflict but is unnecessary and the last should be filtered out from the profile. + + - id: 8.3.8 + title: Authentication policies and procedures are documented and communicated to all users. + levels: + - base + status: manual + + - id: 8.3.9 + title: If passwords/passphrases are used as the only authentication factor for user access + (i.e., in any single-factor authentication implementation) they should have a limited + lifetime. + description: |- + If passwords/passphrases are used as the only authentication factor for user access (i.e., + in any single-factor authentication implementation) then either: + - Passwords/passphrases are changed at least once every 90 days, + OR + - The security posture of accounts is dynamically analyzed, and real-time access to + resources is automatically determined accordingly. + levels: + - base + status: pending + notes: |- + The requirement does not explicitily define the number of days before the password + expiration to warn the users, but the relevant rules were selected here as they do not + cause any problems in combination with password lifetime rules. + + - id: 8.3.10 + title: 'Additional requirement for service providers only: If passwords/passphrases are used + as the only authentication factor for customer user access to cardholder data (i.e., + in any single-factor authentication implementation) then guidance is provided to customer + users.' + levels: + - base + status: manual + controls: + - id: 8.3.10.1 + title: 'Additional requirement for service providers only: If passwords/passphrases + are used as the only authentication factor for customer user access (i.e., in any + single-factor authentication implementation) they should have a limited lifetime.' + levels: + - base + status: pending + notes: |- + This requirement is already covered by 8.3.9. + + - id: 8.3.11 + title: Where authentication factors such as physical or logical security tokens, smart cards, + or certificates are used, factors are not shared among multiple users and the usage is + controlled.' + levels: + - base + status: manual + + - id: '8.4' + title: Multi-factor authentication (MFA) is implemented to secure access into the CDE. + levels: + - base + status: supported + notes: |- + This parent requirement does not set one specific combination of Multi-factor authentication + (MFA), so we can't enforce the use of smartcards or any specific solution. The systems + usually support MFA but the chosen solution depends on site policies. + controls: + - id: 8.4.1 + title: MFA is implemented for all non-console access into the CDE for personnel with administrative + access. + levels: + - base + status: supported + + - id: 8.4.2 + title: MFA is implemented for all non-console access into the CDE. + description: |- + Access into the CDE cannot be obtained by the use of a single authentication factor. + levels: + - base + status: manual + + - id: 8.4.3 + title: MFA is implemented for all remote access originating from outside the entity's network + that could access or impact the CDE. + levels: + - base + status: manual + + - id: '8.5' + title: Multi-factor authentication (MFA) systems are configured to prevent misuse. + levels: + - base + status: manual + controls: + - id: 8.5.1 + title: MFA systems are properly implemented. + description: |- + - The MFA system is not susceptible to replay attacks. + - MFA systems cannot be bypassed by any users, including administrative users unless + specifically documented, and authorized by management on an exception basis, for a limited + time period. + - At least two different types of authentication factors are used. + - Success of all authentication factors is required before access is granted. + levels: + - base + status: manual + notes: |- + Each site might have a different MFA solution and each solution has its own capabilities. + This requirement demands manual assessment based on site policies. + + - id: '8.6' + title: Use of application and system accounts and associated authentication factors is strictly + managed. + levels: + - base + status: pending + controls: + - id: 8.6.1 + title: If accounts used by systems or applications can be used for interactive login, they + are managed. + description: |- + - Interactive use is prevented unless needed for an exceptional circumstance. + - Interactive use is limited to the time needed for the exceptional circumstance. + - Business justification for interactive use is documented. + - Interactive use is explicitly approved by management. + - Individual user identity is confirmed before access to account is granted. + - Every action taken is attributable to an individual user. + levels: + - base + status: pending + notes: |- + This requirement is related to 2.2.2, 2.2.6, 8.2.1 and 8.2.2. Specifically on 8.2.2 system + accounts usage is restricted. Exceptions to system accounts should be manually checked to + ensure the requirements in description. This requirement although implements some extra + controls regarding root account. + + - id: 8.6.2 + title: Passwords/passphrases for any application and system accounts that can be used for + interactive login are not hard coded in scripts, configuration/property files, or bespoke + and custom source code. + description: |- + Passwords/passphrases used by application and system accounts cannot be used by + unauthorized personnel. + levels: + - base + status: manual + + - id: 8.6.3 + title: Passwords/passphrases for any application and system accounts are protected against + misuse. + description: |- + - Passwords/passphrases are changed periodically (at the frequency defined in the entity's + targeted risk analysis, which is performed according to all elements specified in + Requirement 12.3.1) and upon suspicion or confirmation of compromise. + - Passwords/passphrases are constructed with sufficient complexity appropriate for how + frequently the entity changes the passwords/passphrases. + levels: + - base + status: pending + notes: |- + Related to requirements 8.3.6 and 8.3.9. + + - id: '9.1' + title: Processes and mechanisms for restricting physical access to cardholder data are defined + and understood. + levels: + - base + status: manual + controls: + - id: 9.1.1 + title: All security policies and operational procedures that are identified in Requirement + 9 are Documented, Kept up to date, In use and Known to all affected parties. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that security policies and + operational procedures identified in Requirement 9 are managed in accordance with all + elements specified in this requirement. + + - id: 9.1.2 + title: Roles and responsibilities for performing activities in Requirement 9 are documented, + assigned, and understood. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that day-to-day responsibilities + for performing all the activities in Requirement 9 are documented, assigned and understood + by the assigned personnel. + + - id: '9.2' + title: Physical access controls manage entry into facilities and systems containing cardholder + data. + levels: + - base + status: manual + controls: + - id: 9.2.1 + title: Appropriate facility entry controls are in place to restrict physical access to systems + in the CDE. + description: |- + System components in the CDE cannot be physically accessed by unauthorized personnel. + levels: + - base + status: manual + controls: + - id: 9.2.1.1 + title: Individual physical access to sensitive areas within the CDE is monitored with + either video cameras or physical access control mechanisms (or both). + levels: + - base + status: manual + + - id: 9.2.2 + title: Physical and/or logical controls are implemented to restrict use of publicly accessible + network jacks within the facility. + description: |- + Unauthorized devices cannot connect to the entity's network from public areas within the + facility. + levels: + - base + status: not applicable + + - id: 9.2.3 + title: Physical access to wireless access points, gateways, networking/communications hardware, + and telecommunication lines within the facility is restricted + description: |- + Physical networking equipment cannot be accessed by unauthorized personnel. + levels: + - base + status: not applicable + + - id: 9.2.4 + title: Access to consoles in sensitive areas is restricted via locking when not in use. + description: |- + Physical consoles within sensitive areas cannot be used by unauthorized personnel. + levels: + - base + status: manual + notes: |- + Related to requirement 8.2.8. + This requirement asks to observe a system administrator's attempt to log into consoles in + sensitive areas and verify that they are "locked" to prevent unauthorized use. Therefore + it is a manual requirement applicable only very specific circumstances. + + - id: '9.3' + title: Physical access for personnel and visitors is authorized and managed. + levels: + - base + status: manual + controls: + - id: 9.3.1 + title: Procedures are implemented for authorizing and managing physical access of personnel + to the CDE. + levels: + - base + status: manual + controls: + - id: 9.3.1.1 + title: Physical access to sensitive areas within the CDE for personnel is controlled + levels: + - base + status: manual + + - id: 9.3.2 + title: Procedures are implemented for authorizing and managing visitor access to the CDE. + levels: + - base + status: manual + + - id: 9.3.3 + title: Visitor badges or identification are surrendered or deactivated before visitors leave + the facility or at the date of expiration. + description: |- + Visitor identification or badges cannot be reused after expiration. + levels: + - base + status: manual + + - id: 9.3.4 + title: Visitor logs are used to maintain a physical record of visitor activity both within + the facility and within sensitive areas. + levels: + - base + status: manual + + - id: '9.4' + title: Media with cardholder data is securely stored, accessed, distributed, and destroyed. + levels: + - base + status: manual + controls: + - id: 9.4.1 + title: All media with cardholder data is physically secured. + description: |- + Media with cardholder data cannot be accessed by unauthorized personnel. + levels: + - base + status: manual + controls: + - id: 9.4.1.1 + title: Offline media backups with cardholder data are stored in a secure location. + description: |- + Offline backups cannot be accessed by unauthorized personnel. + levels: + - base + status: manual + + - id: 9.4.1.2 + title: The security of the offline media backup location(s) with cardholder data is + reviewed at least once every 12 months. + description: |- + The security controls protecting offline backups are verified periodically by + inspection. + levels: + - base + status: manual + + - id: 9.4.2 + title: All media with cardholder data is classified in accordance with the sensitivity of + the data. + description: |- + Media are classified and protected appropriately. + levels: + - base + status: manual + + - id: 9.4.3 + title: Media with cardholder data sent outside the facility is secured. + description: |- + Media is secured and tracked when transported outside the facility. + - Media sent outside the facility is logged. + - Media is sent by secured courier or other delivery method that can be accurately + tracked. + - Offsite tracking logs include details about media location. + levels: + - base + status: manual + + - id: 9.4.4 + title: Management approves all media with cardholder data that is moved outside the facility + (including when media is distributed to individuals). + description: |- + Media cannot leave a facility without the approval of accountable personnel. Individuals + approving media movements should have the appropriate level of management authority to + grant this approval. However, it is not specifically required that such individuals have + "manager" as part of their title. + levels: + - base + status: manual + + - id: 9.4.5 + title: Inventory logs of all electronic media with cardholder data are maintained. + description: |- + Accurate inventories of stored electronic media are maintained. + levels: + - base + status: manual + controls: + - id: 9.4.5.1 + title: Inventories of electronic media with cardholder data are conducted at least + once every 12 months. + description: |- + Media inventories are verified periodically. + levels: + - base + status: manual + + - id: 9.4.6 + title: Hard-copy materials with cardholder data are destroyed when no longer needed for business + or legal reasons. + levels: + - base + status: manual + + - id: 9.4.7 + title: Electronic media with cardholder data is destroyed when no longer needed for business + or legal reasons. + description: |- + - The electronic media is destroyed. + - The cardholder data is rendered unrecoverable so that it cannot be reconstructed. + levels: + - base + status: manual + + - id: '9.5' + title: Point-of-interaction (POI) devices are protected from tampering and unauthorized substitution. + levels: + - base + status: manual + controls: + - id: 9.5.1 + title: POI devices that capture payment card data via direct physical interaction with the + payment card form factor are protected from tampering and unauthorized substitution. + levels: + - base + status: manual + controls: + - id: 9.5.1.1 + title: An up-to-date list of POI devices is maintained. + levels: + - base + status: manual + + - id: 9.5.1.2 + title: POI device surfaces are periodically inspected to detect tampering and unauthorized + substitution. + description: |- + Point of Interaction Devices cannot be tampered with, substituted without authorization, + or have skimming attachments installed without timely detection. + levels: + - base + status: manual + controls: + - id: 9.5.1.2.1 + title: The frequency of periodic POI device inspections and the type of inspections + performed is defined in the entity's targeted risk analysis, which is performed + according to all elements specified in Requirement 12.3.1. + description: |- + POI devices are inspected at a frequency that addresses the entity's risk. + This requirement is a best practice until 31 March 2025, after which it will be + required and must be fully considered during a PCI DSS assessment. + levels: + - base + status: manual + + - id: 9.5.1.3 + title: Training is provided for personnel in POI environments to be aware of attempted + tampering or replacement of POI devices. + levels: + - base + status: manual + + - id: '10.1' + title: Processes and mechanisms for logging and monitoring all access to system components and + cardholder data are defined and documented. + levels: + - base + status: manual + controls: + - id: 10.1.1 + title: All security policies and operational procedures that are identified in Requirement + 10 are Documented, Kept up to date, In use and Known to all affected parties. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that security policies and + operational procedures identified in Requirement 10 are managed in accordance with all + elements specified in this requirement. + + - id: 10.1.2 + title: Roles and responsibilities for performing activities in Requirement 10 are documented, + assigned, and understood. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that day-to-day responsibilities + for performing all the activities in Requirement 10 are documented, assigned and + understood by the assigned personnel. + + - id: '10.2' + title: Audit logs are implemented to support the detection of anomalies and suspicious activity, + and the forensic analysis of events. + levels: + - base + status: pending + controls: + - id: 10.2.1 + title: Audit logs are enabled and active for all system components and cardholder data. + description: |- + Records of all activities affecting system components and cardholder data are captured. + levels: + - base + status: pending + controls: + - id: 10.2.1.1 + title: Audit logs capture all individual user access to cardholder data. + description: |- + Records of all individual user access to cardholder data are captured. + levels: + - base + status: planned + notes: |- + Differently than 10.2.1.4, this requirement is about logginh successful access to + cardholder data. This kind of events can easily hit performance issues and are usually + not necessary if a good access policy is in place. More clarification is needed about + this requirement. + + - id: 10.2.1.2 + title: Audit logs capture all actions taken by any individual with administrative access, + including any interactive use of application or system accounts. + description: |- + Records of all actions performed by individuals with elevated privileges are captured. + levels: + - base + status: pending + notes: |- + Not all privileged commands have suid or sgid enabled. We probably want to include more + rules for this requirement. + + - id: 10.2.1.3 + title: Audit logs capture all access to audit logs. + description: |- + Records of all access to audit logs are captured. + levels: + - base + status: pending + + - id: 10.2.1.4 + title: Audit logs capture all invalid logical access attempts. + description: |- + Records of all invalid access attempts are captured. + levels: + - base + status: pending + + - id: 10.2.1.5 + title: Audit logs capture all changes to identification and authentication credentials. + levels: + - base + status: pending + + - id: 10.2.1.6 + title: Audit logs capture the initialization of new audit logs, and starting, stopping, + or pausing of the existing audit logs. + levels: + - base + status: planned + notes: |- + Ideally should exist rules specifically logging when audit configuration files are + modified and audit service state is changed. + + - id: 10.2.1.7 + title: Audit logs capture all creation and deletion of system-level objects. + description: |- + Records of alterations that indicate a system has been modified from its intended + functionality are captured. + levels: + - base + status: pending + notes: |- + There are enough rules to capture deletion events but not for creation events. + This requirement needs to be better investigated to confirm which additional rules would + satistfy the requirement. + + - id: 10.2.2 + title: Audit logs record sufficient details for each auditable event. + description: |- + - User identification. + - Type of event. + - Date and time. + - Success and failure indication. + - Origination of event. + - Identity or name of affected data, system component, resource, or service (for example, + name and protocol). + levels: + - base + status: pending + notes: |- + Standard settings for audit should be enough. + + - id: '10.3' + title: Audit logs are protected from destruction and unauthorized modifications. + levels: + - base + status: pending + controls: + - id: 10.3.1 + title: Read access to audit logs files is limited to those with a job-related need. + description: |- + Stored activity records cannot be accessed by unauthorized personnel. + levels: + - base + status: pending + + - id: 10.3.2 + title: Audit log files are protected to prevent modifications by individuals. + description: |- + Stored activity records cannot be modified by personnel. + levels: + - base + status: pending + + - id: 10.3.3 + title: Audit log files, including those for external-facing technologies, are promptly backed + up to a secure, central, internal log server(s) or other media that is difficult to modify. + description: |- + Stored activity records are secured and preserved in a central location to prevent + unauthorized modification. + levels: + - base + status: pending + notes: |- + Although the technologies in general allow to send logs to a centralized server, some + parameters for this configuration are specific to each site policy and therefore the + requirement demands manual assessment. + + - id: 10.3.4 + title: File integrity monitoring or change-detection mechanisms is used on audit logs to + ensure that existing log data cannot be changed without generating alerts. + description: |- + Stored activity records cannot be modified without an alert being generated. + levels: + - base + status: pending + + - id: '10.4' + title: Audit logs are reviewed to identify anomalies or suspicious activity. + levels: + - base + status: manual + controls: + - id: 10.4.1 + title: The audit logs are reviewed at least once daily. + description: |- + - All security events. + - Logs of all system components that store, process, or transmit CHD and/or SAD. + - Logs of all critical system components. + - Logs of all servers and system components that perform security functions (for example, + network security controls, intrusion-detection systems/intrusion-prevention systems + (IDS/IPS), authentication servers). + levels: + - base + status: manual + controls: + - id: 10.4.1.1 + title: Automated mechanisms are used to perform audit log reviews. + description: |- + Potentially suspicious or anomalous activities are identified via a repeatable and + consistent mechanism. This requirement is a best practice until 31 March 2025, after + which it will be required and must be fully considered during a PCI DSS assessment. + levels: + - base + status: manual + notes: |- + Automation mechanisms, solutions and approaches vary for each organizarion. + + - id: 10.4.2 + title: Logs of all other system components (those not specified in Requirement 10.4.1) are + reviewed periodically. + description: |- + Potentially suspicious or anomalous activities for other system components (not included + in 10.4.1) are reviewed in accordance with the entity's identified risk. This requirement + is applicable to all other in-scope system components not included in Requirement 10.4.1. + levels: + - base + status: manual + controls: + - id: 10.4.2.1 + title: The frequency of periodic log reviews for all other system components (not defined + in Requirement 10.4.1) is defined in the entity's targeted risk analysis, which + is performed according to all elements specified in Requirement 12.3.1 + description: |- + Log reviews for lower-risk system components are performed at a frequency that addresses + the entity's risk. This requirement is a best practice until 31 March 2025, after which + it will be required and must be fully considered during a PCI DSS assessment. + levels: + - base + status: manual + + - id: 10.4.3 + title: Exceptions and anomalies identified during the review process are addressed. + description: |- + Suspicious or anomalous activities are addressed. + levels: + - base + status: manual + + - id: '10.5' + title: Audit log history is retained and available for analysis. + levels: + - base + status: pending + controls: + - id: 10.5.1 + title: Retain audit log history for at least 12 months, with at least the most recent three + months immediately available for analysis. + description: |- + Historical records of activity are available immediately to support incident response and + are retained for at least 12 months. + levels: + - base + status: pending + notes: |- + It is not simple to ensure 12 months history is present in each system but the rules in + this requirement ensures the logs are not lost without administrators awareness. + + - id: '10.6' + title: Time-synchronization mechanisms support consistent time settings across all systems. + levels: + - base + status: pending + controls: + - id: 10.6.1 + title: System clocks and time are synchronized using time-synchronization technology. + description: |- + Common time is established across all systems. Keeping time-synchronization technology + current includes managing vulnerabilities and patching the technology according to PCI DSS + Requirements 6.3.1 and 6.3.3. + levels: + - base + status: pending + notes: |- + Maybe it is possible to optmize some similar rules related to ntp. + + - id: 10.6.2 + title: Systems are configured to the correct and consistent time. + description: |- + - One or more designated time servers are in use. + - Only the designated central time server(s) receives time from external sources. + - Time received from external sources is based on International Atomic Time or Coordinated + Universal Time (UTC). + - The designated time server(s) accept time updates only from specific industry-accepted + external sources. + - Where there is more than one designated time server, the time servers peer with one + another to keep accurate time. + - Internal systems receive time information only from designated central time server(s). + levels: + - base + status: pending + notes: |- + The selected rules might need updates in order to restrict their platform applicability + to avoid conflicts. + + - id: 10.6.3 + title: Time synchronization settings and data are protected. + description: |- + - Access to time data is restricted to only personnel with a business need. + - Any changes to time settings on critical systems are logged, monitored, and reviewed. + levels: + - base + status: pending + + - id: '10.7' + title: Failures of critical security control systems are detected, reported, and responded to promptly. + levels: + - base + status: pending + controls: + - id: 10.7.1 + title: 'Additional requirement for service providers only: Failures of critical security + control systems are detected, alerted, and addressed promptly.' + description: |- + It includes but is not limited to failure of the following critical security control + systems: + - Network security controls. + - IDS/IPS. + - FIM. + - Anti-malware solutions. + - Physical access controls. + - Logical access controls. + - Audit logging mechanisms. + - Segmentation controls (if used). + levels: + - base + status: manual + + - id: 10.7.2 + title: Failures of critical security control systems are detected, alerted, and addressed + promptly. + description: |- + It includes but is not limited to failure of the following critical security control + systems: + - Network security controls. + - IDS/IPS. + - Change-detection mechanisms. + - Anti-malware solutions. + - Physical access controls. + - Logical access controls. + - Audit logging mechanisms. + - Segmentation controls (if used). + - Audit log review mechanisms. + - Automated security testing tools (if used). + levels: + - base + status: pending + + - id: 10.7.3 + title: Failures of any critical security controls systems are responded to restore security + functions, ensure documentation, address security issues and prevent other failures. + description: |- + It includes but is not limited to: + - Restoring security functions. + - Identifying and documenting the duration (date and time from start to end) of the + security failure. + - Identifying and documenting the cause(s) of failure and documenting required + remediation. + - Identifying and addressing any security issues that arose during the failure. + - Determining whether further actions are required as a result of the security failure. + - Implementing controls to prevent the cause of failure from reoccurring. + - Resuming monitoring of security controls. + levels: + - base + status: manual + + - id: '11.1' + title: Processes and mechanisms for regularly testing security of systems and networks are defined + and understood. + levels: + - base + status: manual + controls: + - id: 11.1.1 + title: All security policies and operational procedures that are identified in Requirement + 11 are Documented, Kept up to date, In use and Known to all affected parties. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that security policies and + operational procedures identified in Requirement 11 are managed in accordance with all + elements specified in this requirement. + + - id: 11.1.2 + title: Roles and responsibilities for performing activities in Requirement 11 are documented, + assigned, and understood. + levels: + - base + status: manual + notes: |- + Examine documentation and interview personnel to verify that day-to-day responsibilities + for performing all the activities in Requirement 11 are documented, assigned and + understood by the assigned personnel. + + - id: '11.2' + title: Wireless access points are identified and monitored, and unauthorized wireless access points + are addressed. + levels: + - base + status: manual + controls: + - id: 11.2.1 + title: Authorized and unauthorized wireless access points are managed. + levels: + - base + status: manual + + - id: 11.2.2 + title: An inventory of authorized wireless access points is maintained, including a documented + business justification. + description: |- + Unauthorized wireless access points are not mistaken for authorized wireless access + points. + levels: + - base + status: manual + + - id: '11.3' + title: External and internal vulnerabilities are regularly identified, prioritized, and addressed. + levels: + - base + status: manual + controls: + - id: 11.3.1 + title: Internal vulnerability scans are performed. + levels: + - base + status: manual + controls: + - id: 11.3.1.1 + title: All other applicable vulnerabilities (those not ranked as high-risk vulnerabilities + or critical vulnerabilities according to the entity's vulnerability risk rankings + defined at Requirement 6.3.1) are managed. + levels: + - base + status: manual + + - id: 11.3.1.2 + title: Internal vulnerability scans are performed via authenticated scanning. + levels: + - base + status: manual + + - id: 11.3.1.3 + title: Internal vulnerability scans are performed after any significant change. + levels: + - base + status: manual + + - id: 11.3.2 + title: External vulnerability scans are performed. + levels: + - base + status: manual + controls: + - id: 11.3.2.1 + title: External vulnerability scans are performed after any significant change. + levels: + - base + status: manual + + - id: '11.4' + title: External and internal penetration testing is regularly performed, and exploitable vulnerabilities + and security weaknesses are corrected. + levels: + - base + status: manual + controls: + - id: 11.4.1 + title: A penetration testing methodology is defined, documented, and implemented by the entity. + levels: + - base + status: manual + + - id: 11.4.2 + title: Internal penetration testing is performed. + levels: + - base + status: manual + + - id: 11.4.3 + title: External penetration testing is performed. + levels: + - base + status: manual + + - id: 11.4.4 + title: Exploitable vulnerabilities and security weaknesses found during penetration testing + are corrected + levels: + - base + status: manual + + - id: 11.4.5 + title: If segmentation is used to isolate the CDE from other networks, penetration tests + are performed on segmentation controls. + levels: + - base + status: manual + + - id: 11.4.6 + title: 'Additional requirement for service providers only: If segmentation is used to isolate + the CDE from other networks, penetration tests are performed on segmentation controls.' + levels: + - base + status: manual + + - id: 11.4.7 + title: 'Additional requirement for multi-tenant service providers only: Multi-tenant service + providers support their customers for external penetration testing per Requirement 11.4.3 + and 11.4.4.' + description: |- + Multi-tenant service providers support their customers' need for technical testing either + by providing access or evidence that comparable technical testing has been undertaken. + levels: + - base + status: manual + + - id: '11.5' + title: Network intrusions and unexpected file changes are detected and responded to. + levels: + - base + status: pending + controls: + - id: 11.5.1 + title: Intrusion-detection and/or intrusion-prevention techniques are used to detect and/or + prevent intrusions into the network. + levels: + - base + status: manual + controls: + - id: 11.5.1.1 + title: 'Additional requirement for service providers only: Intrusion-detection and/or + intrusion-prevention techniques detect, alert on/prevent, and address covert malware + communication channels.' + description: |- + Mechanisms are in place to detect and alert/prevent covert communications with + command-and-control systems. Alerts generated by these mechanisms are responded to by + personnel, or by automated means that ensure that such communications are blocked. This + requirement applies only when the entity being assessed is a service provider. This + requirement is a best practice until 31 March 2025, after which it will be required and + must be fully considered during a PCI DSS assessment. + levels: + - base + status: manual + notes: |- + The policy is not explicit about any specific solution. The solution might vary + depending on site policies. + + - id: 11.5.2 + title: A change-detection mechanism (for example, file integrity monitoring tools) is deployed. + levels: + - base + status: pending + + - id: '11.6' + title: Unauthorized changes on payment pages are detected and responded to. + levels: + - base + status: manual + controls: + - id: 11.6.1 + title: A change- and tamper-detection mechanism is deployed. + levels: + - base + status: manual + notes: |- + It depends on controls in application level, which varies based on site policies. + + - id: '12.1' + title: A comprehensive information security policy that governs and provides direction for protection + of the entity's information assets is known and current. + levels: + - base + status: pending + controls: + - id: 12.1.1 + title: An overall information security policy is established, published, maintained and disseminated + to all relevant personnel, as well as to relevant vendors and business partners. + levels: + - base + status: manual + + - id: 12.1.2 + title: The information security policy is updated and reviewed at least once every 12 months. + levels: + - base + status: manual + + - id: 12.1.3 + title: The security policy clearly defines information security roles and responsibilities + for all personnel, and all personnel are aware of and acknowledge their information security + responsibilities. + description: |- + Personnel understand their role in protecting the entity's cardholder data. + levels: + - base + status: manual + + - id: 12.1.4 + title: Responsibility for information security is formally assigned to a Chief Information + Security Officer or other information security knowledgeable member of executive management. + description: |- + A designated member of executive management is responsible for information security. + levels: + - base + status: manual + + - id: '12.2' + title: Acceptable use policies for end-user technologies are defined and implemented. + levels: + - base + status: manual + controls: + - id: 12.2.1 + title: Acceptable use policies for end-user technologies are documented and implemented. + levels: + - base + status: manual + + - id: '12.3' + title: Risks to the cardholder data environment are formally identified, evaluated, and managed. + levels: + - base + status: manual + controls: + - id: 12.3.1 + title: For each PCI DSS requirement that specifies completion of a targeted risk analysis, + the analysis is documented. + levels: + - base + status: manual + + - id: 12.3.2 + title: A targeted risk analysis is performed for each PCI DSS requirement that the entity + meets with the customized approach + levels: + - base + status: manual + + - id: 12.3.3 + title: Cryptographic cipher suites and protocols in use are documented and reviewed at least + once every 12 months. + levels: + - base + status: manual + notes: |- + Related to requirement 2.2.7. + + - id: 12.3.4 + title: Hardware and software technologies in use are reviewed at least once every 12 months. + levels: + - base + status: manual + notes: |- + The technical requirement related to this is 6.3.3. + + - id: '12.4' + title: PCI DSS compliance is managed. + levels: + - base + status: manual + controls: + - id: 12.4.1 + title: 'Additional requirement for service providers only: Responsibility is established + by executive management for the protection of cardholder data and a PCI DSS compliance + program.' + levels: + - base + status: manual + + - id: 12.4.2 + title: 'Additional requirement for service providers only: Reviews are performed at least + once every three months to confirm that personnel are performing their tasks in accordance + with all security policies and operational procedures.' + description: |- + Reviews are performed by personnel other than those responsible for performing the given + task. + levels: + - base + status: manual + controls: + - id: 12.4.2.1 + title: 'Additional requirement for service providers only: Reviews conducted in accordance + with Requirement 12.4.2 are documented.' + levels: + - base + status: manual + + - id: '12.5' + title: PCI DSS scope is documented and validated. + levels: + - base + status: manual + controls: + - id: 12.5.1 + title: An inventory of system components that are in scope for PCI DSS, including a description + of function/use, is maintained and kept current. + description: |- + All system components in scope for PCI DSS are identified and known. + levels: + - base + status: manual + + - id: 12.5.2 + title: PCI DSS scope is documented and confirmed by the entity at least once every 12 months + and upon significant change to the in-scope environment. + levels: + - base + status: manual + controls: + - id: 12.5.2.1 + title: 'Additional requirement for service providers only: PCI DSS scope is documented + and confirmed by the entity at least once every six months and upon significant + change to the in-scope environment. At a minimum, the scoping validation includes + all the elements specified in Requirement 12.5.2.' + description: |- + The accuracy of PCI DSS scope is verified to be continuously accurate by comprehensive + analysis and appropriate technical measures. This requirement applies only when the + entity being assessed is a service provider. This requirement is a best practice until + 31 March 2025, after which it will be required and must be fully considered during a + PCI DSS assessment. + levels: + - base + status: manual + + - id: 12.5.3 + title: 'Additional requirement for service providers only: Significant changes to organizational + structure result in a documented (internal) review of the impact to PCI DSS scope and + applicability of controls, with results communicated to executive management.' + description: |- + PCI DSS scope is confirmed after significant organizational change. This requirement + applies only when the entity being assessed is a service provider. This requirement is a + best practice until 31 March 2025, after which it will be required and must be fully + considered during a PCI DSS assessment. + levels: + - base + status: manual + + - id: '12.6' + title: Security awareness education is an ongoing activity. + levels: + - base + status: manual + controls: + - id: 12.6.1 + title: A formal security awareness program is implemented to make all personnel aware of + the entity's information security policy and procedures, and their role in protecting + the cardholder data. + description: |- + Personnel are knowledgeable about the threat landscape, their responsibility for the + operation of relevant security controls, and are able to access assistance and guidance + when required. + levels: + - base + status: manual + + - id: 12.6.2 + title: The security awareness program is updated and reviewed at least once every 12 months. + levels: + - base + status: manual + + - id: 12.6.3 + title: Personnel receive security awareness training upon hire and at least once every 12 + months via multiple methods of communication. + levels: + - base + status: manual + controls: + - id: 12.6.3.1 + title: Security awareness training includes awareness of threats and vulnerabilities + that could impact the security of the CDE. + levels: + - base + status: manual + + - id: 12.6.3.2 + title: Security awareness training includes awareness about the acceptable use of end-user + technologies in accordance with Requirement 12.2.1. + description: |- + Personnel are knowledgeable about their responsibility for the security and operation of + end-user technologies and are able to access assistance and guidance when required. This + requirement is a best practice until 31 March 2025, after which it will be required and + must be fully considered during a PCI DSS assessment. + levels: + - base + status: manual + + - id: '12.7' + title: Personnel are screened to reduce risks from insider threats. + levels: + - base + status: manual + controls: + - id: 12.7.1 + title: Potential personnel who will have access to the CDE are screened, within the constraints + of local laws, prior to hire to minimize the risk of attacks from internal sources. + description: |- + The risk related to allowing new members of staff access to the CDE is understood and + managed. For those potential personnel to be hired for positions such as store cashiers, + who only have access to one card number at a time when facilitating a transaction, this + requirement is a recommendation only. + levels: + - base + status: manual + + - id: '12.8' + title: Risk to information assets associated with third-party service provider (TPSP) relationships + is managed. + levels: + - base + status: manual + controls: + - id: 12.8.1 + title: A list of all third-party service providers (TPSPs) with which account data is shared + or that could affect the security of account data is maintained, including a description + for each of the services provided. + description: |- + Records are maintained of TPSPs and the services provided. The use of a PCI DSS compliant + TPSP does not make an entity PCI DSS compliant, nor does it remove the entit's + responsibility for its own PCI DSS compliance. + levels: + - base + status: manual + + - id: 12.8.2 + title: Written agreements with TPSPs are maintained + levels: + - base + status: manual + + - id: 12.8.3 + title: An established process is implemented for engaging TPSPs, including proper due diligence + prior to engagement. + description: |- + The capability, intent, and resources of a prospective TPSP to adequately protect account + data are assessed before the TPSP is engaged. + levels: + - base + status: manual + + - id: 12.8.4 + title: A program is implemented to monitor TPSPs' PCI DSS compliance status at least once + every 12 months. + description: |- + The PCI DSS compliance status of TPSPs is verified periodically. Where an entity has an + agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity (for + example, via a firewall service), the entity must work with the TPSP to make sure the + applicable PCI DSS requirements are met. If the TPSP does not meet those applicable + PCI DSS requirements, then those requirements are also "not in place" for the entity. + levels: + - base + status: manual + + - id: 12.8.5 + title: Information is maintained about which PCI DSS requirements are managed by each TPSP, + which are managed by the entity, and any that are shared between the TPSP and the entity. + description: |- + Records detailing the PCI DSS requirements and related system components for which each + TPSP is solely or jointly responsible, are maintained and reviewed periodically. + levels: + - base + status: manual + + - id: '12.9' + title: Third-party service providers (TPSPs) support their customers' PCI DSS compliance. + levels: + - base + status: manual + controls: + - id: 12.9.1 + title: |- + Additional requirement for service providers only: TPSPs provide written agreements to + customers that include acknowledgments that TPSPs are responsible for the security of + account data the TPSP possesses or otherwise stores, processes, or transmits on behalf of + the customer, or to the extent that the TPSP could impact the security of the customer's + cardholder data and/or sensitive authentication data. + description: |- + TPSPs formally acknowledge their security responsibilities to their customers. This + requirement applies only when the entity being assessed is a service provider. The exact + wording of an agreement will depend on the details of the service being provided, and the + responsibilities assigned to each party. The agreement does not have to include the exact + wording provided in this requirement. + levels: + - base + status: manual + + - id: 12.9.2 + title: |- + Additional requirement for service providers only: TPSPs support their customers' requests + for information to meet Requirements 12.8.4 and 12.8.5. + levels: + - base + status: manual + + - id: '12.10' + title: Suspected and confirmed security incidents that could impact the CDE are responded to immediately. + levels: + - base + status: manual + controls: + - id: 12.10.1 + title: An incident response plan exists and is ready to be activated in the event of a suspected + or confirmed security incident. + levels: + - base + status: manual + + - id: 12.10.2 + title: At least once every 12 months, the security incident response plan is reviewed, updated, + and tested. + levels: + - base + status: manual + + - id: 12.10.3 + title: Specific personnel are designated to be available on a 24/7 basis to respond to suspected + or confirmed security incidents. + description: |- + Incidents are responded to immediately where appropriate. + levels: + - base + status: manual + + - id: 12.10.4 + title: Personnel responsible for responding to suspected and confirmed security incidents + are appropriately and periodically trained on their incident response responsibilities. + description: |- + Personnel are knowledgeable about their role and responsibilities in incident response and + are able to access assistance and guidance when required. + levels: + - base + status: manual + controls: + - id: 12.10.4.1 + title: The frequency of periodic training for incident response personnel is defined + in the entity's targeted risk analysis, which is performed according to all elements + specified in Requirement 12.3.1. + description: |- + Incident response personnel are trained at a frequency that addresses the entity's risk. + This requirement is a best practice until 31 March 2025, after which it will be required + and must be fully considered during a PCI DSS assessment. + levels: + - base + status: manual + + - id: 12.10.5 + title: The security incident response plan includes monitoring and responding to alerts from + security monitoring systems. + levels: + - base + status: manual + + - id: 12.10.6 + title: The security incident response plan is modified and evolved according to lessons learned + and to incorporate industry developments. + description: |- + The effectiveness and accuracy of the incident response plan is reviewed and updated after + each invocation. + levels: + - base + status: manual + + - id: 12.10.7 + title: Incident response procedures are in place, to be initiated upon the detection of stored + PAN anywhere it is not expected. + levels: + - base + status: manual + + - id: A1.1 + title: Multi-tenant service providers protect and separate all customer environments and data. + levels: + - base + status: manual + controls: + - id: A1.1.1 + title: Logical separation is implemented. + description: |- + - The provider cannot access its customers' environments without authorization. + - Customers cannot access the provider's environment without authorization. + levels: + - base + status: manual + + - id: A1.1.2 + title: Controls are implemented such that each customer only has permission to access its + own cardholder data and CDE. + description: |- + Customers cannot access other customers' environments. + levels: + - base + status: manual + + - id: A1.1.3 + title: Controls are implemented such that each customer can only access resources allocated + to them. + description: |- + Customers cannot impact resources allocated to other customers. + levels: + - base + status: manual + + - id: A1.1.4 + title: The effectiveness of logical separation controls used to separate customer environments + is confirmed at least once every six months via penetration testing. + description: |- + Segmentation of customer environments from other environments is periodically validated to + be effective. The testing of adequate separation between customers in a multi-tenant + service provider environment is in addition to the penetration tests specified in + Requirement 11.4.6. This requirement is a best practice until 31 March 2025, after which + it will be required and must be fully considered during a PCI DSS assessment. + levels: + - base + status: manual + + - id: A1.2 + title: Multi-tenant service providers facilitate logging and incident response for all customers. + levels: + - base + status: manual + controls: + - id: A1.2.1 + title: Audit log capability is enabled for each customer's environment that is consistent + with PCI DSS Requirement 10. + levels: + - base + status: manual + + - id: A1.2.2 + title: Processes or mechanisms are implemented to support and/or facilitate prompt forensic + investigations in the event of a suspected or confirmed security incident for any customer. + description: |- + Forensic investigation is readily available to all customers in the event of a suspected + or confirmed security incident. + levels: + - base + status: manual + + - id: A1.2.3 + title: Processes or mechanisms are implemented for reporting and addressing suspected or + confirmed security incidents and vulnerabilities. + levels: + - base + status: manual + + - id: A2.1 + title: POI terminals using SSL and/or early TLS are confirmed as not susceptible to known SSL/TLS + exploits. + description: |- + Appendix A2: Additional PCI DSS Requirements for Entities Using SSL/Early TLS for + Card-Present POS POI Terminal Connections. + levels: + - base + status: manual + controls: + - id: A2.1.1 + title: Where POS POI terminals at the merchant or payment acceptance location use SSL and/or + early TLS, the entity confirms the devices are not susceptible to any known exploits + for those protocols. + levels: + - base + status: manual + notes: |- + Related to requirements 2.2.7 and 3.5.1.1. + Service level settings for web servers such as Apache and NGINX should also be checked. + + - id: A2.1.2 + title: 'Additional requirement for service providers only: All service providers with existing + connection points to POS POI terminals that use SSL and/or early TLS as defined in A2.1 + have a formal Risk Mitigation and Migration Plan in place.' + levels: + - base + status: manual + + - id: A2.1.3 + title: 'Additional requirement for service providers only: All service providers provide + a secure service offering.' + description: |- + This requirement is not eligible for the customized approach. This requirement applies + only when the entity being assessed is a service provider. + levels: + - base + status: manual + + - id: A3.1 + title: A PCI DSS compliance program is implemented. + description: |- + Appendix A3: Designated Entities Supplemental Validation (DESV) + levels: + - base + status: manual + controls: + - id: A3.1.1 + title: Responsibility is established by executive management for the protection of account + data and a PCI DSS compliance program. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Requirement 12 + + - id: A3.1.2 + title: A formal PCI DSS compliance program is in place. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Requirements 1-12 + + - id: A3.1.3 + title: PCI DSS compliance roles and responsibilities are specifically defined and formally + assigned to one or more personnel. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Requirement 12 + + - id: A3.1.4 + title: Up-to-date PCI DSS and/or information security training is provided at least once + every 12 months to personnel with PCI DSS compliance responsibilities (as identified + in A3.1.3). + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Requirement 12 + + - id: A3.2 + title: PCI DSS scope is documented and validated. + levels: + - base + status: manual + controls: + - id: A3.2.1 + title: PCI DSS scope is documented and confirmed for accuracy at least once every three months + and upon significant changes to the in-scope environment. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Scope of PCI DSS Requirements, Requirement 12. + + - id: A3.2.2 + title: PCI DSS scope impact for all changes to systems or networks is determined, including + additions of new systems and new network connections. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Scope of PCI DSS Requirements; Requirements 1-12 + controls: + - id: A3.2.2.1 + title: Upon completion of a change, all relevant PCI DSS requirements are confirmed + to be implemented on all new or changed systems and networks, and documentation + is updated as applicable. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Scope of PCI DSS Requirements; Requirements 1-12 + + - id: A3.2.3 + title: Changes to organizational structure result in a formal (internal) review of the impact + to PCI DSS scope and applicability of controls. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Requirement 12 + + - id: A3.2.4 + title: If segmentation is used, PCI DSS scope is confirmed. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Requirement 11 + + - id: A3.2.5 + title: A data-discovery methodology is implemented. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Scope of PCI DSS Requirements. + controls: + - id: A3.2.5.1 + title: Data discovery methods are confirmed. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Scope of PCI DSS Requirements. + + - id: A3.2.5.2 + title: Response procedures are implemented to be initiated upon the detection of cleartext + PAN outside the CDE. + levels: + - base + status: manual + + - id: A3.2.6 + title: Mechanisms are implemented for detecting and preventing cleartext PAN from leaving + the CDE via an unauthorized channel, method, or process. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Scope of PCI DSS Requirements, Requirement 12 + controls: + - id: A3.2.6.1 + title: Response procedures are implemented to be initiated upon the detection of attempts + to remove cleartext PAN from the CDE via an unauthorized channel, method, or process. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Requirement 12 + + - id: A3.3 + title: PCI DSS is incorporated into business-as-usual (BAU) activities. + levels: + - base + status: manual + controls: + - id: A3.3.1 + title: Failures of critical security control systems are detected, alerted, and addressed + promptly. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Requirement 12 + controls: + - id: A3.3.1.2 + title: Failures of any critical security control systems are responded to promptly. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Requirements 1-12 + If you noticed, this requirement should be A3.3.1.1 instead of A3.3.1.2 but it was kept + this way to be aligned to the policy. + + - id: A3.3.2 + title: Hardware and software technologies are reviewed at least once every 12 months to confirm + whether they continue to meet the organization's PCI DSS requirements. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Requirements 2, 6, 12. + + - id: A3.3.3 + title: Reviews are performed at least once every three months to verify BAU activities are + being followed. + description: |- + Reviews are performed by personnel assigned to the PCI DSS compliance program (as + identified in A3.1.3). + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Requirements 1-12. + + - id: A3.4 + title: Logical access to the cardholder data environment is controlled and managed. + levels: + - base + status: manual + controls: + - id: A3.4.1 + title: User accounts and access privileges to in-scope system components are reviewed at + least once every six months to ensure user accounts and access privileges remain appropriate + based on job function, and that all access is authorized. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Requirement 7. + + - id: A3.5 + title: Suspicious events are identified and responded to. + levels: + - base + status: manual + controls: + - id: A3.5.1 + title: A methodology is implemented for the prompt identification of attack patterns and + undesirable behavior across systems. + levels: + - base + status: manual + notes: |- + PCI DSS Reference: Requirement 10, 12. diff --git a/products/sle16/product.yml b/products/sle16/product.yml index c6550fdbd65..e1bcd9d0328 100644 --- a/products/sle16/product.yml +++ b/products/sle16/product.yml @@ -35,6 +35,8 @@ platform_package_overrides: reference_uris: suse-base-sle16: 'not_publicly_available' + pcidss4_sle16: 'https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf' + anssi_sle16: 'https://cyber.gouv.fr/sites/default/files/document/linux_configuration-en-v2.pdf' dconf_gdm_dir: "gdm.d" diff --git a/products/sle16/profiles/anssi_bp28_minimal.profile b/products/sle16/profiles/anssi_bp28_minimal.profile new file mode 100644 index 00000000000..03ed2faea65 --- /dev/null +++ b/products/sle16/profiles/anssi_bp28_minimal.profile @@ -0,0 +1,28 @@ +--- +documentation_complete: true + +metadata: + SMEs: + - svet-se + - rumch-se + - teacup-on-rockingchair + +title: 'ANSSI-BP-028 (minimal)' + +description: |- + This profile contains configurations that align to ANSSI-BP-028 v2.0 at the minimal hardening level. + + ANSSI is the French National Information Security Agency, and stands for Agence nationale de la sécurité des systèmes d'information. + ANSSI-BP-028 is a configuration recommendation for GNU/Linux systems. + + A copy of the ANSSI-BP-028 can be found at the ANSSI website: + https://www.ssi.gouv.fr/administration/guide/recommandations-de-securite-relatives-a-un-systeme-gnulinux/ + + Only the components strictly necessary to the service provided by the system should be installed. + Those whose presence can not be justified should be disabled, removed or deleted. + Performing a minimal install is a good starting point, but doesn't provide any assurance + over any package installed later. + Manual review is required to assess if the installed services are minimal. + +selections: + - anssi_sle16:all:minimal diff --git a/products/sle16/profiles/pci-dss-4.profile b/products/sle16/profiles/pci-dss-4.profile new file mode 100644 index 00000000000..3b1a418c6b2 --- /dev/null +++ b/products/sle16/profiles/pci-dss-4.profile @@ -0,0 +1,17 @@ +documentation_complete: true + +metadata: + SMEs: + - svet-se + - rumch-se + - teacup-on-rockingchair + +reference: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf + +title: 'PCI-DSS v4 Control Baseline for SUSE Linux Enterprise 16' + +description: |- + Ensures PCI-DSS v4 security configuration settings are applied. + +selections: + - pcidss_4_sle16:all:base From 7c0fd8f0d964311ef90d21d421d309bea05af4c9 Mon Sep 17 00:00:00 2001 From: teacup-on-rockingchair <315160+teacup-on-rockingchair@users.noreply.github.com> Date: Tue, 7 Oct 2025 07:45:43 +0300 Subject: [PATCH 4/9] Drop middle layer when defining anssi and pcidss profiles for sle16 --- controls/anssi_sle16.yml | 863 ---- controls/base_sle16.yml | 14 +- controls/pcidss_4_sle16.yml | 3540 ----------------- products/sle16/product.yml | 2 - .../sle16/profiles/anssi_bp28_minimal.profile | 2 +- products/sle16/profiles/pci-dss-4.profile | 2 +- 6 files changed, 9 insertions(+), 4414 deletions(-) delete mode 100644 controls/anssi_sle16.yml delete mode 100644 controls/pcidss_4_sle16.yml diff --git a/controls/anssi_sle16.yml b/controls/anssi_sle16.yml deleted file mode 100644 index c0e622eefa7..00000000000 --- a/controls/anssi_sle16.yml +++ /dev/null @@ -1,863 +0,0 @@ ---- -policy: 'ANSSI-BP-028' -title: 'Configuration Recommendations of a GNU/Linux System' -id: anssi_sle16 -version: '2.0' -source: https://cyber.gouv.fr/sites/default/files/document/linux_configuration-en-v2.pdf -product: sle16 - -levels: - - id: minimal - - id: intermediary - inherits_from: - - minimal - - id: enhanced - inherits_from: - - intermediary - - id: high - inherits_from: - - enhanced - -reference_type: anssi_sle16 - -controls: - - id: R1 - title: Hardware Support - levels: - - enhanced - description: >- - It is recommended to apply the configuration recommendations for Hardware support - mentioned in ANSSI DAT-24. - notes: >- - This requirement can be checked, but remediation requires manual reinstall of the OS. - The content automation cannot really configure the BIOS, but can in some cases, - check settings that are visible to the OS. Like for example the NX/DX setting. - status: partial - - # R8 It is recommended to use hardware with support for hardware random number generator - # R9 Disable VT-x AMD-V technologies - # TODO: can we reliably check cpuinfo flags? - # R10 IOMMU must enabled if the hardware supports it - - id: R2 - title: Hardware configuration - levels: - - intermediary - description: >- - It is recommended to apply the configuration recommendations for BIOS/UEFI mentioned in - ANSSI DAT-24. - notes: >- - Configurations recommended for this requirement are to be performed at the BIOS level. - status: manual - - # From ANSSI DAT-24 - # R11 Password protect the BIOS - # R12 Deactivate peripherals not needed - # R13 The boot order list should give highest preference to component on which final OS is installed - # R14 Enable NX/XD bit - # - bios_enable_execution_restrictions # Doesn't have check - # R15 Disable VT-x/AMD-V functionality - # R16 Enable IOMMU - - id: R3 - title: UEFI Secure boot activation - levels: - - intermediary - description: >- - It is recommended to apply UEFI Secure Boot configuration of the distribution. - notes: >- - Secure Boot needs to be enabled in the UEFI Setup program. - Enabling Secure Boot can't be accomplished from the operating system. - Also, OVAL doesn't provide any reliable ways to detect the Secure Boot status. - Therefore, we will not provide any rules to automate this requirement. - We recommend checking the Secure Boot status using the `mokutil --sb-state` or `bootctl status` - commands. - status: manual - - - id: R4 - title: Replacing of preloaded keys - levels: - - high - description: >- - It is recommended to replace the UEFI preloaded keys with new keys used to sign; - the bootloader and Linux kernel, or; the image of the Linux kernel in EFI format. - notes: >- - This requirement is not generally automatable. The Machine Owner Key (MOK) could - be used to add keys to the Secure Boot db key database but manual interaction is - required to navigate the UEFI console and input the key password. - On systems where MOK utility is not supported, one will need to access the UEFI - firmware interface to add new keys. - We have no automation support for UEFI interfaces and the steps for each hardware - manufacturer can vary. - status: manual - - - id: R5 - title: Boot loader password - levels: - - intermediary - description: >- - A password protecting the boot loader must exist. - This password must prevent any user from changing their configuration options. - status: pending - - - id: R6 - title: Protecting kernel command line parameters - levels: - - high - description: >- - It is recommended that UEFI Secure Boot is used to protect the Linux Kernel - command line parameters during boot. - notes: >- - To protect the Linux Kernel command line one needs to create an Unified Kernel Image and use - it with the UEFI Secure Boot mechanism. - To check if the Kernel image contains the kernel command one needs to inspect the binary, on - the command line one can use the objdump command. But unfortunately OVAL is not able to - inspect kernel images. - Also, it is not trivial to automate creation of such image or configuration of the - Secure Boot mechanism. - status: manual - - - id: R7 - title: IOMMU Configuration Guidelines - levels: - - enhanced - description: >- - The iommu = force directive must be added to the list of kernel parameters - during startup in addition to those already present in the configuration - files of the bootloader (/boot/grub/menu.lst or /etc/default/grub). - status: pending - - - id: R8 - title: Memory configuration options - levels: - - intermediary - status: pending - - - id: R9 - title: Kernel configuration options - levels: - - intermediary - status: pending - - - id: R10 - title: Disabling the loading of kernel modules - levels: - - enhanced - description: >- - The loading of the kernel modules can be blocked by the activation of the - sysctl kernel.modules_disabled: - Prohibition of loading modules (except those already loaded to this point) - kernel.modules_disabled = 1 - status: pending - - - id: R11 - title: Yama module sysctl configuration - levels: - - intermediary - description: >- - It is recommended to load the Yama security module at startup (by example - passing the security = yama argument to the kernel) and configure the - sysctl kernel.yama.ptrace_scope to a value of at least 1. - status: pending - - - id: R12 - title: IPv4 configuration options - levels: - - intermediary - status: pending - - - id: R13 - title: Disabling IPv6 - levels: - - intermediary - notes: >- - When IPv6 is not in use, disable it, otherwise secure the IPv6 stack. - This control hardens the IPv6 stack, to disable it use the related rules instead. - status: pending - - - id: R14 - title: File system configuration options - levels: - - intermediary - notes: >- - The rule for the /proc file system is not implemented - status: pending - - - id: R15 - title: Compile options for memory management - levels: - - high - status: pending - notes: >- - The special case of direct access to physical memory is not handled. - - - id: R16 - title: Compile options for kernel data structures - levels: - - high - status: pending - - - id: R17 - title: Compile options for the memory allocator - levels: - - high - status: pending - - - id: R18 - title: Compile options for the management of kernel module - levels: - - high - status: pending - - - id: R19 - title: Compile options for abnormal situations - levels: - - high - status: pending - - - id: R20 - title: Compile options for kernel security functions - levels: - - high - status: pending - - - id: R21 - title: Compile options for the compiler plugins - levels: - - high - status: pending - - - id: R22 - title: Compile options for the IP stack - levels: - - high - notes: >- - This control doesn't disable the IPv6 stack, to disable it select the related rule. - status: pending - - - id: R23 - title: Compile options for various kernel behaviors - levels: - - high - notes: >- - If the system can function without support for kernel modules, module support should be disabled - by setting CONFIG_MODULES=n. - status: pending - - - id: R24 - title: Compile options for 32-bit architectures - levels: - - high - notes: >- - Unless a X86 32bit kernel is explicitly supported by one of products in the project, this - requirement is set to not applicable. - status: not applicable - - - id: R25 - title: Compile options for x86_64 architectures - levels: - - high - status: pending - - - id: R26 - title: Compile options for ARM architectures - levels: - - high - notes: >- - Unless a ARM 32bit kernel is explicitly supported by one of products in the project, this - requirement is set to not applicable. - status: not applicable - - - id: R27 - title: Compile options for ARM 64 architectures - levels: - - high - status: pending - - - id: R28 - title: Partitioning type - levels: - - intermediary - status: pending - - - id: R29 - title: Access Restrictions on /boot - levels: - - enhanced - description: >- - When possible, it is recommended not to automatically mount the /boot partition. - In any case, access to the /boot folder should only be allowed for the root user. - notes: >- - The /boot partition mounted is essential to perform certain administrative actions, for - example updating the kernel. Therefore, for better stability, in this requirement only rules - to restrict the access to /boot are selected. It is not changed how the /boot is mounted. - status: pending - - - id: R30 - title: Removal of unused user accounts - levels: - - minimal - description: >- - Unused user accounts must be deleted from the system. - notes: >- - The definition of unused user accounts is broad. It can include accounts - whose owners don't use the system anymore, or users created by services - or applications that should not be used. - Automation by itself cannot discern which accounts are used or not. - status: manual - - - id: R31 - title: User password strength - levels: - - minimal - notes: >- - The rules selected below establish a general password strength baseline - of 100 bits, based on the recommendations of the technical note - "Recommandations relatives à l'authentification multifacteur et aux mots de passe" - (https://cyber.gouv.fr/publications/recommandations-relatives-lauthentification-multifacteur-et-aux-mots-de-passe) - - The baseline should be reviewed and tailored to the system's use case and needs. - status: pending - - - id: R32 - title: Configuring a timeout on local user sessions - levels: - - intermediary - description: >- - Local user sessions (console TTY, graphical session) must be locked after a certain period - of inactivity. - notes: >- - ANSSI doesn't specify the length of the inactivity period, we are choosing 10 minutes as reasonable - number. - status: pending - - - id: R33 - title: Use of dedicated administration accounts - levels: - - intermediary - notes: >- - By disabling direct root logins proper accountability is ensured. - Users will login first, then escalate to privileged (root) access. - Change of privilege operations must be based on executables to monitor the activities - performed (for example sudo). - Nonetheless, the content automation cannot ensure that each administrator was given a - nominative administration account separate from his normal user account. - status: pending - - - id: R34 - title: Deactivation of service accounts - levels: - - intermediary - notes: >- - It is difficult to generally identify the system's service accounts. - UIDs of such accounts are generally between SYS_UID_MIN and SYS_UID_MAX, but their values - are not enforced by the OS and can be changed over time. - Assisting rules could list users which are not disabled for manual review. - status: manual - - - id: R35 - title: Uniqueness and exclusivity of system service accounts - levels: - - intermediary - description: >- - Each service must have its own system account and be dedicated to it exclusively. - notes: >- - It is not trivial to identify whether a user account is a service account. - UIDs of such accounts are generally between SYS_UID_MIN and SYS_UID_MAX, but their values - are not enforced by the OS and can be changed over time. - status: manual - - - id: R36 - title: Changing the default value of UMASK - levels: - - enhanced - description: >- - The default value of UMASK for the shells must be set to 0077 in order to allow read and - write access to its owner only. This value can be defined in the configuration file - /etc/profile that most shells (bash, dash, ksh…) will use. - The default value of UMASK for services must be determined for each service, but in most - cases, it should be set to 0027 (or more restrictive). This allows read access to its owner - and its group, and a full access to its owner. For services such as systemd, this value can - be defined directly in the configuration file of the service with the directive UMask=0027. - notes: >- - There are cases of Systemd services which would stop working in case umask - would be configured to 0027 for all services. One such example is the - Cups service which needs to create sockets which need to be available for - all users. Therefore, this part of the requirement can't be automated. - status: pending - - - id: R37 - title: Using access control features - levels: - - enhanced - description: >- - It is recommended to use the mandatory access control (MAC) features in - addition to the traditional Unix user model (DAC), or possibly combine - them with partitioning mechanisms. - notes: >- - Other partitioning mechanisms can include chroot and containers and are not contemplated - in this requirement. - status: pending - - - id: R38 - title: Group dedicated to the use of sudo - levels: - - enhanced - description: >- - A group dedicated to the use of sudo must be created, and only members of this - group are allowed to execute sudo. - status: pending - - - id: R39 - title: Sudo configuration guidelines - levels: - - intermediary - status: pending - - - id: R40 - title: Privileges of target sudo users - description: The targeted users of a rule should be, as much as possible, non privileged users. - levels: - - intermediary - status: pending - - - id: R41 - title: Limiting the number of commands requiring the use of the EXEC option - levels: - - enhanced - description: >- - The commands requiring the execution of sub-processes (EXEC tag) must be - explicitly listed and their use should be reduced to a strict minimum. - notes: >- - Human review is required to assess if the set of commands requiring EXEC is minimal. - An auxiliary rule could list rules containing EXEC tag, for analysis. - status: manual - - - id: R42 - title: Good use of negation in a sudoers file - levels: - - intermediary - description: The sudoers configuration rules should not involve negation. - status: pending - - - id: R43 - title: Explicit arguments in sudo specifications - levels: - - intermediary - status: pending - - - id: R44 - title: Editing files with sudo - levels: - - intermediary - description: A file requiring sudo to be edited, must be edited through the sudoedit command. - notes: >- - In R62 we established that the sudoers files should not use negations, thus the approach - for this requirement is to ensure that sudoedit is the only text editor allowed. - But it is difficult to ensure that allowed binaries aren't text editors without human - review. - status: manual - - - id: R45 - title: Enable AppArmor security profiles - levels: - - enhanced - description: >- - All AppArmor security profiles on the system must be enabled by default. - status: pending - - - id: R46 - title: Activate SELinux with the Targeted Policy - levels: - - high - description: >- - It is recommended to enable the targeted policy when the distribution - supports it and that it does not operate another security module than SELinux. - status: pending - - - id: R47 - title: Containment of unprivileged interactive users - levels: - - high - description: >- - Interactive non-privileged users of a system must be confined by associating them with a SELinux - confined user. - notes: Interactive users who still need to perform administrative tasks should not be confined - with user_u. - status: manual - - - id: R48 - title: Setting SELinux booleans - levels: - - high - description: >- - It is recommended to set the following Booleans: - allow_execheap to off, forbids processes to make their heap executable; - allow_execmem to off, forbids processes to have both write and execute rights on memory pages; - allow_execstack to off, forbids processes to make their stack executable; - secure_mode_insmod to on, prohibits dynamic loading of modules by any process; - ssh_sysadm_login to off, forbids SSH logins to connect directly in sysadmin role. - notes: In RHEL, the SELinux boolean allow_execheap is renamed to selinuxuser_execheap, and the - boolean allow_execstack is renamed to selinuxuser_execstack. And allow_execmem is not available, - deny_execmem provides the same functionality. - status: pending - - - id: R49 - title: Uninstalling SELinux Policy Debugging Tools - levels: - - high - description: >- - SELinux policy manipulation and debugging tools should not be installed - on a machine in production. - status: pending - - - id: R50 - title: Rights to access sensitive files and directories - levels: - - intermediary - status: pending - - - id: R51 - title: Sensitive and trusted files - levels: - - enhanced - description: >- - All sensitive files and those contributing to the authentication mechanisms - must be set up as soon as the system is installed. If default secrets are - preconfigured, they must be replaced during, or immediately after, the - installation phase of the system. - notes: >- - This concerns two aspects, the first is administrative, and involves prompt - installation of secrets or trusted elements by the sysadmin. - The second involves removal of any default secret or trusted element - configured by the operating system during install process, e.g. default - known passwords. - status: documentation - - - id: R52 - title: Securing access for named sockets and pipes - levels: - - intermediary - notes: |- - The requirement states that all sockets and named pipes within all mounted - file systems should be checked. The check should look at the permissions - of the socket / pipe and compare them with permissions of the directory - which contains the particular socket. In case permissions of the directory - are less stricter than permissions of the socket, this should be - considered a finding. Since different use cases can require different - permissions for named pipes / sockets, it is not possible to perform this - check automatically. - status: manual - - - id: R53 - title: Files or directories without a known user or group - levels: - - minimal - status: automated - controls: - - base_sle16:SLES-16-16016025 - - base_sle16:SLES-16-16016030 - - - id: R54 - title: Sticky bit and write access rights - levels: - - minimal - status: pending - - - id: R55 - title: Temporary directories dedicated to accounts - levels: - - intermediary - description: >- - Each user or service account must have its own temporary directory - and dispose of it exclusively. - notes: The approach of the selected rules is to use and configure pam_namespace module. - status: pending - - - id: R56 - title: Executables with setuid and setgid bits - levels: - - minimal - notes: >- - Only programs specifically designed to be used with setuid or setgid bits can have these privilege - bits set. - This requirement considers apropriate for setuid and setgid bits the binaries that are installed - from - recognized and authorized repositories (covered in R15). - The remediation resets the sticky bit to intended value by vendor/developer, any finding after - remediation - should be reviewed. - status: pending - - - id: R57 - title: Executable with special rights setuid root and setgid root - levels: - - enhanced - description: >- - The executables with setuid executables root and setgid root special rights should be as few - as possible. - When only administrators are expected to execute them, these special rights should - be removed and prefer them commands like su or sudo, which can be monitored - notes: There could be rules to list all executables with setuid root or setgid root rights. - status: manual - - - id: R58 - title: Installation of packages reduced to the bare necessities - levels: - - minimal - description: >- - The selection of packages installed should be as small as possible, - limiting itself to select only what is required. - notes: >- - It is not possible to automatically decide in general way if a package is required or not for - given system. - As a future improvement, there could be rules assisting assessment by listing the installed - packages. - status: manual - - - id: R59 - title: Official package repositories - levels: - - minimal - description: Only up-to-date official repositories of the distribution must be used. - notes: >- - It is not trivial to distinguish an official repository from an unofficial one. - We cannot draw conclusions from the repo name or URL of the repo (as they can be arbitrary - or behind a proxy). - One approach to check the origin of installed packages is to check the signature of the packages. - If the public key of a repository is not installed, the repo is not trusted. - status: pending - - - id: R60 - title: Hardened package repositories - levels: - - enhanced - description: >- - When the distribution provides several types of repositories, preference - should be given to those containing packages subject to additional - hardening measures. - Between two packages providing the same service, those subject to hardening - (at compilation, installation, or default configuration) must be preferred. - status: not applicable - - - id: R61 - title: Regular updates - levels: - - minimal - notes: Check the vendor CVE feed and configure automatic install of security related updates. - status: pending - - - id: R62 - title: Minimization of installed services - levels: - - minimal - description: >- - Only the components strictly necessary to the service provided by the system should - be installed. - Those whose presence can not be justified should be disabled, removed or deleted. - status: manual # The list of essential services is not objective. - notes: >- - Performing a minimal install is a good starting point, but doesn't provide any assurance - over any package installed later. - Manual review is required to assess if the installed services are minimal. - In general, use of obsolete or insecure services is not recommended and we remove some - of these in this recommendation. - - - id: R63 - title: Minimization of services configuration - levels: - - intermediary - description: >- - Services are often installed with default configurations that enable features potentially - problematic from a security point of view. - The features configured at the level of launched services should be limited to the strict - minimum. - notes: >- - Define a list of most problematic components or features to be hardened or restricted. - status: manual - - - id: R64 - title: Least privilege for the services - levels: - - enhanced - description: >- - The deployed services must have their access restricted to the system - strict minimum, especially when it comes to files, processes or network. - notes: >- - SELinux policies limit the privileges of services and daemons just to those which are required. - The policies should be enough to restrict the services' privileges to its essentials, but the - automated content cannot assess whether they are the minimum required for the deployment. - status: pending - - - id: R65 - title: Services partitioning - levels: - - enhanced - notes: >- - Using automation to restrict access and chroot services is not generally reliable. - status: manual - - - id: R66 - title: Virtualization components hardening - levels: - - high - description: >- - Each component supporting the virtualization must be hardened, especially - by applying technical measures to counter the exploit attempts. - notes: >- - We cannot easily automate securing of virtualization technologies in a general way. - It may be interesting to point out virtualization components that are installed and - should be hardened. - status: manual - - - id: R67 - title: Secure remote authentication with PAM - levels: - - intermediary - description: |- - When authentication takes place through a remote application (network), - the authentication protocol used by PAM must be secure (flow encryption, - remote server authentication, anti-replay mechanisms, ...). - notes: |- - In systems where remote authentication is handled through sssd service, PAM delegates - requests for remote authentication to sssd service through a local Unix socket. The sssd - service can use IPA, AD or LDAP as a remote database containing information required for authentication. - In case LDAP is configured manually, there are several configuration options which should be chedked. - status: pending - - - id: R68 - title: Protecting stored passwords - levels: - - minimal - description: Any password must be protected by cryptographic mechanisms. - notes: >- - The selection of rules doesn't cover the use of hardware devices to protect the passwords. - status: supported - - - id: R69 - title: Securing access to remote user databases - levels: - - intermediary - description: |- - When the user databases are stored on a remote network service, NSS must - be configured to establish a secure link that allows, at minimum, to - authenticate the server and protect the communication channel. - notes: |- - A nsswitch service connecting to remote database is provided by sssd. This is checked in requirement R67. - Another such service is winbind which is by default configured to connect securely to Samba domains. - Other relevant services are NIS and Hesiod. These should not be used. - status: pending - - - id: R70 - title: Separation of System Accounts and Directory Administrator - levels: - - intermediary - status: manual - - - id: R71 - title: Implement a logging system - levels: - - enhanced - description: >- - The configuration of the service must be performed according to the - 'Security Recommendations for the architecture of a logging system' - (DAT-PA-012 v2.0) accessible on the ANSSI website - (https://www.ssi.gouv.fr/journalisation). - notes: >- - A lot of recommendations and requirements from the DAT-PA-012 document are administrative and - hard to automate. - The rules selected below address a few of the aspects that can be covered, keep in mind that - these configurations should - be customized for the systems deployment requirements. - status: pending - - - id: R72 - title: Service Activity Logs - levels: - - enhanced - description: >- - Each service must have a dedicated event logging journal on the system. - This log must only be accessible by the syslog server, and must not be readable, - editable or deletable by the service directly. - status: documentation # How to enable syslog for each service installed in the system - - - id: R73 - title: Logging activity by auditd - levels: - - enhanced - description: >- - The logging of the system activity must be done through the auditd service. - status: pending - - - id: R74 - title: Configuring the local messaging service - levels: - - intermediary - status: pending - - - id: R75 - title: Messaging Aliases for Service Accounts - levels: - - intermediary - status: pending # semi-automated - notes: >- - Only the alias for root user is covered by the rule. - The other services cannot be reliably covered, as there is no simple way - of determining what is a service account. - - - id: R76 - title: Sealing and integrity of files - levels: - - high - description: >- - Any file that is not transient (such as temporary files, databases, etc.) - must be monitored by a sealing program. - This includes: directories containing executables, libraries, - configuration files, as well as any files that may contain sensitive - elements (cryptographic keys, passwords, confidential data). - status: pending - - - id: R77 - title: Protection of the seals database - levels: - - high - description: >- - The sealing database must be protected from malicious access by - cryptographic signature mechanisms (with the key used for the signature - not locally stored in clear), or possibly stored on a separate machine - of the one on which the sealing is done. - Check section "Database and config signing in AIDE manual" - https://aide.github.io/doc/#signing - status: does not meet - - - id: R78 - title: Network services partitioning - levels: - - enhanced - description: >- - Network services should as much as possible be hosted on isolated environments. - This avoids having other potentially affected services if one of them gets - compromised under the same environment. - notes: >- - Manual analysis is required to determine if services are hosted appropriately in - separate or isolated system while maintaining functionality. - status: manual - - - id: R79 - title: Hardening and monitoring of exposed services - levels: - - intermediary - notes: >- - SELinux can provide confinement and monitoring of services, and AIDE provides - basic integrity checking. System logs are configured as part of R43. - Hardening of particular services should be done on a case by case basis and is - not automated by this content. - status: pending - - - id: R80 - title: Minimization of network services - levels: - - minimal - description: All network services must be listening on the correct network intefaces. - notes: >- - Manual review is necessary to decide if the list of resident daemons is minimal. - Assisting rules could be created to list sevices listening on the network for manual review. - status: manual diff --git a/controls/base_sle16.yml b/controls/base_sle16.yml index df7829df7a8..32ee529b81d 100644 --- a/controls/base_sle16.yml +++ b/controls/base_sle16.yml @@ -7,16 +7,16 @@ source: not_publicly_available reference_type: suse-base-sle16 levels: - - id: high - - id: medium - - id: low + - id: pcidss4 + - id: anssi_minimal product: sle16 controls: - id: SLES-16-16016015 levels: - - high + - pcidss4 + - anssi_minimal title: SLES 16 must be a vendor-supported release. rules: - installed_OS_is_vendor_supported @@ -25,7 +25,7 @@ controls: - id: SLES-16-16016020 title: Enable NX/XD Support levels: - - medium + - pcidss4 automated: partially rules: - bios_enable_execution_restrictions @@ -34,7 +34,7 @@ controls: - id: SLES-16-16016025 title: Ensure All Files Are Owned by a Group levels: - - medium + - anssi_minimal rules: - file_permissions_ungroupowned status: automated @@ -42,7 +42,7 @@ controls: - id: SLES-16-16016030 title: Ensure All Files Are Owned by a Use levels: - - medium + - anssi_minimal rules: - no_files_unowned_by_user status: automated diff --git a/controls/pcidss_4_sle16.yml b/controls/pcidss_4_sle16.yml deleted file mode 100644 index de1e0a939ab..00000000000 --- a/controls/pcidss_4_sle16.yml +++ /dev/null @@ -1,3540 +0,0 @@ ---- -policy: PCI-DSS -title: Payment Card Industry - Data Security Standard (PCI-DSS) -id: pcidss_4_sle16 -version: '4.0.1' -source: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf -product: sle16 - -levels: - - id: base - -reference_type: pcidss4_sle16 - -controls: - - id: '1.1' - title: 'Processes and mechanisms for installing and maintaining network security controls are defined - and understood.' - levels: - - base - status: manual - controls: - - id: 1.1.1 - title: 'All security policies and operational procedures that are identified in Requirement - 1 are Documented, Kept up to date, In use and Known to all affected parties.' - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that security policies and - operational procedures identified in Requirement 1 are managed in accordance with all - elements specified in this requirement. - - - id: 1.1.2 - title: 'Roles and responsibilities for performing activities in Requirement 1 are documented, - assigned, and understood.' - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that day-to-day responsibilities - for performing all the activities in Requirement 1 are documented, assigned and understood - by the assigned personnel. - - - id: '1.2' - title: 'Network Security Controls (NSCs) are configured and maintained.' - levels: - - base - status: pending - controls: - - id: 1.2.1 - title: 'Configuration standards for NSC rulesets are Defined, Implemented and Maintained.' - levels: - - base - status: pending - notes: |- - Examples of NSCs covered by these configuration standards include, but are not limited to, - firewalls, routers configured with access control lists, and cloud virtual networks. The - objective of this requirement is to ensure the way that NSCs are configured and operate - are defined and consistently applied. While the tooling and standards can be automated, - the review of allowed accesses should be manual as different sites may have different - policies. - - - id: 1.2.2 - title: 'All changes to network connections and to configurations of NSCs are approved and - managed in accordance with the change control process defined at Requirement 6.5.1.' - levels: - - base - status: manual - notes: |- - Changes to network connections and NSCs cannot result in misconfiguration, implementation - of insecure services, or unauthorized network connections. Changes to network connections - include the addition, removal, or modification of a connection. Changes to NSC - configurations include those related to the component itself as well as those affecting - how it performs its security function. A formal change control process should be in place. - - - id: 1.2.3 - title: 'An accurate network diagram(s) is maintained that shows all connections between the - CDE and other networks, including any wireless networks.' - levels: - - base - status: manual - notes: |- - A representation of the boundaries between the CDE, all trusted networks, and all - untrusted networks, is maintained and available. A current network diagram(s) or other - technical or topological solution that identifies network connections and devices can be - used to meet this requirement. - - - id: 1.2.4 - title: 'An accurate data-flow diagram(s) is maintained' - description: |- - An accurate data-flow diagram(s) is maintained that meets the following: - - Shows all account data flows across systems and networks - - Updated as needed upon changes to the environment - levels: - - base - status: manual - - - id: 1.2.5 - title: 'All services, protocols, and ports allowed are identified, approved, and have a defined - business need.' - levels: - - base - status: manual - - - id: 1.2.6 - title: Security features are defined and implemented for all services, protocols, and ports - that are in use and considered to be insecure, such that the risk is mitigated. - levels: - - base - status: pending - notes: |- - The specific risks associated with the use of insecure services, protocols, and ports are - understood, assessed, and appropriately mitigated. The selected rules here basically - remove services without encryption and restricted some common services. - - - id: 1.2.7 - title: Configurations of NSCs are reviewed at least once every six months to confirm they - are relevant and effective. - description: |- - NSC configurations that allow or restrict access to trusted networks are verified - periodically to ensure that only authorized connections with a current business - justification are permitted. - levels: - - base - status: manual - notes: |- - Some configuration automation solution, such as Ansible could be helpful here. - - - id: 1.2.8 - title: Configuration files for NSCs are secured from unauthorized access and kept consistent - with active network configurations. - levels: - - base - status: pending - - - id: '1.3' - title: Network access to and from the cardholder data environment is restricted. - levels: - - base - status: pending - controls: - - id: 1.3.1 - title: Inbound traffic to the CDE is restricted to only traffic that is necessary - description: |- - Inbound traffic to the CDE is restricted as follows: - - To only traffic that is necessary. - - All other traffic is specifically denied. - levels: - - base - status: pending - - - id: 1.3.2 - title: Outbound traffic from the CDE is restricted to only traffic that is necessary - description: |- - Outbound traffic from the CDE is restricted as follows: - - To only traffic that is necessary. - - All other traffic is specifically denied. - levels: - - base - status: pending - notes: |- - It appears there is no rule in the project to restrict outbound traffic on the firewall. - Perhaps a rule to automates this would do more harm than good. Probably a manual - assessment is more reasonable here. - - - id: 1.3.3 - title: NSCs are installed between all wireless networks and the CDE, regardless of whether - the wireless network is a CDE. - description: |- - NSCs are installed between all wireless networks and the CDE, regardless of whether the - wireless network is a CDE, such that: - - All wireless traffic from wireless networks into the CDE is denied by default. - - Only wireless traffic with an authorized business purpose is allowed into the CDE. - levels: - - base - status: pending - notes: |- - Wireless interfaces are not expected in servers so they are disabled by default in this - policy. - - - id: '1.4' - title: Network connections between trusted and untrusted networks are controlled. - levels: - - base - status: pending - controls: - - id: 1.4.1 - title: NSCs are implemented between trusted and untrusted networks. - description: |- - Unauthorized traffic cannot traverse network boundaries between trusted and untrusted - networks. - levels: - - base - status: pending - notes: |- - Trusted and untrusted networks are expected to be different for each environment. - But loopback traffic is assumed to be trusted and even necessary for some services. - This requirement is complements 1.2.1 and 1.3.1 requirements. - - - id: 1.4.2 - title: Inbound traffic from untrusted networks to trusted networks is restricted. - description: |- - Inbound traffic from untrusted networks to trusted networks is restricted to: - - Communications with system components that are authorized to provide publicly accessible - services, protocols, and ports. - - Stateful responses to communications initiated by system components in a trusted network. - - All other traffic is denied. - levels: - - base - status: pending - notes: |- - Probably missing some relevant IPv6 related rules. Needs to be investigated. - - - id: 1.4.3 - title: Anti-spoofing measures are implemented to detect and block forged source IP addresses - from entering the trusted network. - levels: - - base - status: pending - notes: |- - Probably missing some relevant IPv6 related rules. Needs to be investigated. - - - id: 1.4.4 - title: System components that store cardholder data are not directly accessible from untrusted - networks. - levels: - - base - status: pending - notes: |- - This requirement is not intended to apply to storage of account data in volatile memory - but does apply where memory is being treated as persistent storage (for example, RAM - disk). Account data can only be stored in volatile memory during the time necessary to - support the associated business process (for example, until completion of the related - payment card transaction). - - - id: 1.4.5 - title: The disclosure of internal IP addresses and routing information is limited to only - authorized parties. - description: |- - Internal network information is protected from unauthorized disclosure. - levels: - - base - status: pending - - - id: '1.5' - title: Risks to the CDE from computing devices that are able to connect to both untrusted networks - and the CDE are mitigated. - levels: - - base - status: pending - controls: - - id: 1.5.1 - title: Security controls are implemented on any computing devices, including company- and - employee-owned devices, that connect to both untrusted networks (including the Internet) - and the CDE - description: |- - Security controls are implemented on any computing devices, including company- and - employee-owned devices, that connect to both untrusted networks (including the Internet) - and the CDE as follows: - - Specific configuration settings are defined to prevent threats being introduced into the - entity's network. - - Security controls are actively running. - - Security controls are not alterable by users of the computing devices unless - specifically documented and authorized by management on a case-by-case basis for a limited - period. - levels: - - base - status: pending - notes: |- - To ensure this requirement, a manual analysis of site policy and topology is inevitable. - From the technical perspective, previous requirements should already cover this - requirement at some level. - - - id: '2.1' - title: Processes and mechanisms for applying secure configurations to all system components are - defined and understood. - levels: - - base - status: manual - controls: - - id: 2.1.1 - title: All security policies and operational procedures that are identified in Requirement - 2 are Documented, Kept up to date, In use and Known to all affected parties. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that security policies and - operational procedures identified in Requirement 2 are managed in accordance with all - elements specified in this requirement. - - - id: 2.1.2 - title: Roles and responsibilities for performing activities in Requirement 2 are documented, - assigned, and understood. - description: |- - Day-to-day responsibilities for performing all the activities in Requirement 2 are - allocated. Personnel are accountable for successful, continuous operation of these - requirements. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that day-to-day responsibilities - for performing all the activities in Requirement 2 are documented, assigned and understood - by the assigned personnel. - - - id: '2.2' - title: 'System components are configured and managed securely.' - levels: - - base - status: pending - controls: - - id: 2.2.1 - title: Configuration standards are developed, implemented, and maintained - description: |- - Configuration standards are developed, implemented, and maintained to: - - Cover all system components. - - Address all known security vulnerabilities. - - Be consistent with industry-accepted system hardening standards or vendor hardening - recommendations. - - Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1. - - Be applied when new systems are configured and verified as in place before or - immediately after a system component is connected to a production environment. - levels: - - base - status: partial - notes: |- - Interestingly this requirement recommends other standards, such as Center for Internet - Security (CIS), International Organization for Standardization (ISO), National Institute - of Standards and Technology (NIST), Cloud Security Alliance, and product vendors. So, the - rules included here are very generic in terms of hardening. - controls: - - base_sle16:SLES-16-16016020 - - - id: 2.2.2 - title: Vendor default accounts are managed. - description: |- - Vendor default accounts are managed as follows: - - If the vendor default account(s) will be used, the default password is changed per - Requirement 8.3.6. - - If the vendor default account(s) will not be used, the account is removed or disabled. - levels: - - base - status: pending - notes: |- - Also related to requirement 8.2.6 and 8.3.5. - - - id: 2.2.3 - title: 'Primary functions requiring different security levels are managed' - levels: - - base - status: manual - - - id: 2.2.4 - title: Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary - functionality is removed or disabled - description: |- - System components cannot be compromised by exploiting unnecessary functionality present in - the system component. - levels: - - base - status: pending - - - id: 2.2.5 - title: If any insecure services, protocols, or daemons are present, business justification - is documented and the risk is reduced. - description: |- - If any insecure services, protocols, or daemons are present: - - Business justification is documented. - - Additional security features are documented and implemented that reduce the risk of - using insecure services, protocols, or daemons. - levels: - - base - status: manual - notes: |- - Known insecure services are removed or disabled by 2.2.4 - General security measures are covered by 1.2.6 - This requirement is more about checking exceptions and their respective documentation. - - - id: 2.2.6 - title: System security parameters are configured to prevent misuse. - description: |- - System components cannot be compromised because of incorrect security parameter - configuration. - levels: - - base - status: pending - notes: |- - This requirement is not specific but also points to 2.2.1, where other policies are - referenced. Therefore, the most common rules related to system configuration in order to - prevent misuse and selected in main profiles are also selected here. - - - id: 2.2.7 - title: All non-console administrative access is encrypted using strong cryptography. - description: |- - Cleartext administrative authorization factors cannot be read or intercepted from any - network transmissions. This includes administrative access via browser-based interfaces - and application programming interfaces (APIs). - levels: - - base - status: pending - notes: |- - Related to requirement 12.3.3. - - - id: '2.3' - title: Wireless environments are configured and managed securely. - levels: - - base - status: supported - controls: - - id: 2.3.1 - title: For wireless environments connected to the CDE or transmitting account data, all wireless - vendor defaults are changed at installation or are confirmed to be secure. - description: |- - For wireless environments connected to the CDE or transmitting account data, all wireless - vendor defaults are changed at installation or are confirmed to be secure, including but - not limited to: - - Default wireless encryption keys. - - Passwords on wireless access points. - - SNMP defaults. - - Any other security-related wireless vendor defaults. - levels: - - base - status: supported - notes: |- - Wireless interfaces are disabled by 1.3.3. - - - id: 2.3.2 - title: For wireless environments connected to the CDE or transmitting account data, wireless - encryption keys are changed - description: |- - For wireless environments connected to the CDE or transmitting account - data, wireless encryption keys are changed - levels: - - base - status: supported - notes: |- - Wireless interfaces are disabled by 1.3.3. - - - id: '3.1' - title: Processes and mechanisms for protecting stored account data are defined and understood. - levels: - - base - status: manual - controls: - - id: 3.1.1 - title: All security policies and operational procedures that are identified in Requirement - 3 are Documented, Kept up to date, In use and Known to all affected parties. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that security policies and - operational procedures identified in Requirement 3 are managed in accordance with all - elements specified in this requirement. - - - id: 3.1.2 - title: Roles and responsibilities for performing activities in Requirement 3 are documented, - assigned, and understood. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that day-to-day responsibilities - for performing all the activities in Requirement 3 are documented, assigned and understood - by the assigned personnel. - - - id: '3.2' - title: Storage of account data is kept to a minimum. - levels: - - base - status: manual - controls: - - id: 3.2.1 - title: Account data storage is kept to a minimum through implementation of data retention - and disposal policies, procedures, and processes. - description: |- - Account data storage is kept to a minimum through implementation of data retention and - disposal policies, procedures, and processes that include at least the following: - - Coverage for all locations of stored account data. - - Coverage for any sensitive authentication data (SAD) stored prior to completion of - authorization. - - Limiting data storage amount and retention time to that which is required for legal or - regulatory, and/or business requirements. - - Specific retention requirements for stored account data that defines length of retention - period and includes a documented business justification. - - Processes for secure deletion or rendering account data unrecoverable when no longer - needed per the retention policy. - - A process for verifying, at least once every three months, that stored account data - exceeding the defined retention period has been securely deleted or rendered unrecoverable. - levels: - - base - status: manual - notes: |- - This requirement is very dependent on each site policies and business model. - Local policies should be consulted and audited. Manual checking is reasonable. - - - id: '3.3' - title: Sensitive authentication data (SAD) is not stored after authorization. - levels: - - base - status: pending - controls: - - id: 3.3.1 - title: SAD is not stored after authorization, even if encrypted. All sensitive authentication - data received is rendered unrecoverable upon completion of the authorization process. - description: |- - This requirement is not eligible for the customized approach. This requirement does not - apply to issuers and companies that support issuing services (where SAD is needed for a - legitimate issuing business need) and have a business justification to store the sensitive - authentication data. Refer to Requirement 3.3.3 for additional requirements specifically - for issuers. Sensitive authentication data includes the data cited in Requirements 3.3.1.1 - through 3.3.1.3. - levels: - - base - status: pending - controls: - - id: 3.3.1.1 - title: The full contents of any track are not stored upon completion of the authorization - process. - description: |- - This requirement is not eligible for the customized approach. In the normal course of - business, the following data elements from the track may need to be retained: - - Cardholder name. - - Primary account number (PAN). - - Expiration date. - - Service code. - To minimize risk, store securely only these data elements as needed for business. - levels: - - base - status: pending - notes: |- - This requirement consists in auditing files, databases and memory to make sure the full - content of any track is not unnecessarily stored. It involves manual auditing but some - automated rules fit this requirement in order to reduce the chances if this data be - unintentionally stored in memory. - - - id: 3.3.1.2 - title: The card verification code is not stored upon completion of the authorization - process. - description: |- - This requirement is not eligible for the customized approach. The card verification code - is the three- or four-digit number printed on the front or back of a payment card used - to verify card-not-present transactions. - levels: - - base - status: pending - notes: |- - Same rules already selected in 3.3.1.1 are valid here, but they are not repeated. - - - id: 3.3.1.3 - title: The personal identification number (PIN) and the PIN block are not stored upon - completion of the authorization process. - description: |- - This requirement is not eligible for the customized approach. PIN blocks are encrypted - during the natural course of transaction processes, but even if an entity encrypts the - PIN block again, it is still not allowed to be stored after the completion of the - authorization process. - levels: - - base - status: pending - notes: |- - Same rules already selected in 3.3.1.1 are valid here, but they are not repeated. - - - id: 3.3.2 - title: SAD that is stored electronically prior to completion of authorization is encrypted - using strong cryptography. - description: |- - This requirement is not eligible for the customized approach. Whether SAD is permitted to - be stored prior to authorization is determined by the organizations that manage compliance - programs (for example, payment brands and acquirers). Contact the organizations of - interest for any additional criteria. This requirement applies to all storage of SAD, even - if no PAN is present in the environment. Refer to Requirement 3.2.1 for an additional - requirement that applies if SAD is stored prior to completion of authorization. Issuers - and companies that support issuing services, where there is a legitimate and documented - business need to store SAD, are not required to meet this requirement. A legitimate - business need is one that is necessary for the performance of the function being provided - by or for the issuer. Refer to Requirement 3.3.3 for requirements specifically for issuers. - This requirement does not replace how PIN blocks are required to be managed, nor does it - mean that a properly encrypted PIN block needs to be encrypted again. - levels: - - base - status: manual - notes: |- - This requirement is a best practice until 31 March 2025, after which it will be required - and must be fully considered during a PCI DSS assessment. - This requirement consists of auditing information stored during a relatively short period - of time. Where and how the information is possibly stored depends in each Business and - local policies so the check is not actually automatable. - - - id: 3.3.3 - title: Additional requirement for issuers and companies that support issuing services and - store sensitive authentication data. - description: |- - Additional requirement for issuers and companies that support issuing services and store - sensitive authentication data: Any storage of sensitive authentication data is: - - Limited to that which is needed for a legitimate issuing business need and is secured. - - Encrypted using strong cryptography. This bullet is a best practice until until - 31 March 2025, after which it will be required as part of Requirement 3.3.3 and must be - fully considered during a PCI DSS assessment. - levels: - - base - status: manual - - - id: '3.4' - title: Access to displays of full PAN and ability to copy PAN is restricted. - levels: - - base - status: pending - controls: - - id: 3.4.1 - title: PAN is masked when displayed (the BIN and last four digits are the maximum number - of digits to be displayed), such that only personnel with a legitimate business need - can see more than the BIN and last four digits of the PAN. - description: |- - PAN displays are restricted to the minimum number of digits necessary to meet a defined - business need. This requirement does not supersede stricter requirements in place for - displays of cardholder data — for example, legal or payment brand requirements for - point-of-sale (POS) receipts. This requirement relates to protection of PAN where it is - displayed on screens, paper receipts, printouts, etc., and is not to be confused with - Requirement 3.5.1 for protection of PAN when stored, processed, or transmitted. - levels: - - base - status: manual - notes: |- - Consists on examining documented policies and procedures, checking system configurations - and observing relevant applications. - - - id: 3.4.2 - title: When using remote-access technologies, technical controls prevent copy and/or relocation - of PAN for all personnel, except for those with documented, explicit authorization and - a legitimate, defined business need. - description: |- - PAN cannot be copied or relocated by unauthorized personnel using remote-access - technologies. Storing or relocating PAN onto local hard drives, removable electronic - media, and other storage devices brings these devices into scope for PCI DSS. - This requirement is a best practice until 31 March 2025, after which it will be required - and must be fully considered during a PCI DSS assessment. - levels: - - base - status: pending - notes: |- - There are technical rules to disable removable storage devices. However, this requirement - still demand some manual auditing in documentation and eventual exceptions. - - - id: '3.5' - title: Primary account number (PAN) is secured wherever it is stored. - levels: - - base - status: pending - controls: - - id: 3.5.1 - title: PAN is rendered unreadable anywhere it is stored - description: |- - PAN is rendered unreadable anywhere it is stored by using any of the following approaches: - - One-way hashes based on strong cryptography of the entire PAN. - - Truncation (hashing cannot be used to replace the truncated segment of PAN). - - If hashed and truncated versions of the same PAN, or different truncation formats of - the same PAN, are present in an environment, additional controls are in place such that - the different versions cannot be correlated to reconstruct the original PAN. - - Indexes tokens. - - Strong cryptography with associated key-management processes and procedures. - levels: - - base - status: pending - controls: - - id: 3.5.1.1 - title: Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) - are keyed cryptographic hashes of the entire PAN, with associated key-management - processes and procedures in accordance with Requirements 3.6 and 3.7. - description: |- - All Applicability Notes for Requirement 3.5.1 also apply to this requirement. - Key-management processes and procedures (Requirements 3.6 and 3.7) do not apply to - system components used to generate individual keyed hashes of a PAN for comparison to - another system if: - - The system components only have access to one hash value at a time (hash values are - not stored on the system) - AND - - There is no other account data stored on the same system as the hashes. - This requirement is considered a best practice until 31 March 2025, after which it will - be required and must be fully considered during a PCI DSS assessment. This requirement - will replace the bullet in Requirement 3.5.1 for one-way hashes once its effective date - is reached. - levels: - - base - status: planned - notes: |- - This requirement likely demand assessment in application level for some environments and - this would be too specific to be automated. However, on system level we can ensure some - strong cryptographic algorithms. This is also generally covered by 2.2.7 but here would - be possible to include more specific rules, for openssl and libreswan for example. - However it would be first necessary to include a platform conditional in these rules - before selecting them so they are applicable only if the respective packages are - installed. - - - id: 3.5.1.2 - title: If disk-level or partition-level encryption (rather than file-, column-, or - field-level database encryption) is used to render PAN unreadable, it is implemented - only on removable electronic media or complemented by another mechanism that meets - Requirement 3.5.1 - levels: - - base - status: pending - - - id: 3.5.1.3 - title: If disk-level or partition-level encryption is used (rather than file-, column-, - or field--level database encryption) to render PAN unreadable, it is managed. - description: |- - If disk-level or partition-level encryption is used (rather than file-, column-, or - field--level database encryption) to render PAN unreadable, it is managed as follows: - - Logical access is managed separately and independently of native operating system - authentication and access control mechanisms. - - Decryption keys are not associated with user accounts. - - Authentication factors (passwords, passphrases, or cryptographic keys) that allow - access to unencrypted data are stored securely. - levels: - - base - status: manual - notes: |- - To properly check this requirement, site policies and documentation should be consulted. - - - id: '3.6' - title: Cryptographic keys used to protect stored account data are secured. - levels: - - base - status: manual - controls: - - id: 3.6.1 - title: Procedures are defined and implemented to protect cryptographic keys used to protect - stored account data against disclosure and misuse. - description: |- - Procedures are defined and implemented to protect cryptographic keys used to protect - stored account data against disclosure and misuse that include: - - Access to keys is restricted to the fewest number of custodians necessary. - - Key-encrypting keys are at least as strong as the data-encrypting keys they protect. - - Key-encrypting keys are stored separately from data-encrypting keys. - - Keys are stored securely in the fewest possible locations and forms. - levels: - - base - status: manual - controls: - - id: 3.6.1.1 - title: 'Additional requirement for service providers only: A documented description - of the cryptographic architecture is maintained' - description: |- - Additional requirement for service providers only: A documented description of the - cryptographic architecture is maintained that includes: - - Details of all algorithms, protocols, and keys used for the protection of stored - account data, including key strength and expiry date. - - Preventing the use of the same cryptographic keys in production and test environments. - This bullet is a best practice until 31 March 2025, after which it will be required as - part of Requirement 3.6.1.1 and must be fully considered during a PCI DSS assessment. - - Description of the key usage for each key. - - Inventory of any hardware security modules (HSMs), key management systems (KMS), and - other secure cryptographic devices (SCDs) used for key management, including type and - location of devices, as outlined in Requirement 12.3.4. - levels: - - base - status: manual - - - id: 3.6.1.2 - title: Secret and private keys used to encrypt/decrypt stored account data are stored - in secure forms. - description: |- - Secret and private keys used to encrypt/decrypt stored account data are stored in one - (or more) of the following forms at all times: - - Encrypted with a key-encrypting key that is at least as strong as the data-encrypting - key, and that is stored separately from the data-encrypting key. - - Within a secure cryptographic device (SCD), such as a hardware security module (HSM) - or PTS-approved point-of-interaction device. - - As at least two full-length key components or key shares, in accordance with an - industry-accepted method. - Secret and private keys are stored in a secure form that prevents unauthorized retrieval - or access. It is not required that public keys be stored in one of these forms. - Cryptographic keys stored as part of a key management system (KMS) that employs SCDs are - acceptable. A cryptographic key that is split into two parts does not meet this - requirement. Secret or private keys stored as key components or key shares must be - generated via one of the following - levels: - - base - status: manual - - - id: 3.6.1.3 - title: Access to cleartext cryptographic key components is restricted to the fewest - number of custodians necessary. - description: |- - Access to cleartext cryptographic key components is restricted to necessary personnel. - levels: - - base - status: manual - - - id: 3.6.1.4 - title: Cryptographic keys are stored in the fewest possible locations. - description: |- - Cryptographic keys are retained only where necessary. - levels: - - base - status: manual - - - id: '3.7' - title: Where cryptography is used to protect stored account data, key management processes and - procedures covering all aspects of the key lifecycle are defined and implemented. - levels: - - base - status: manual - controls: - - id: 3.7.1 - title: Key-management policies and procedures are implemented to include generation of strong - cryptographic keys used to protect stored account data. - description: |- - Strong cryptographic keys are generated. - levels: - - base - status: manual - - - id: 3.7.2 - title: Key-management policies and procedures are implemented to include secure distribution - of cryptographic keys used to protect stored account data. - description: |- - Cryptographic keys are secured during distribution. - levels: - - base - status: manual - - - id: 3.7.3 - title: Key-management policies and procedures are implemented to include secure storage of - cryptographic keys used to protect stored account data. - description: |- - Cryptographic keys are secured when stored. - levels: - - base - status: manual - notes: |- - The scope of this requirement seems much wider going even to application level, which - might be different for each site. Regarding local system there are some technical measures - ensured by 2.2.6. - - - id: 3.7.4 - title: Key management policies and procedures are implemented for cryptographic key changes - for keys that have reached the end of their cryptoperiod, as defined by the associated - application vendor or key owner, and based on industry best practices and guidelines. - description: |- - Key management policies and procedures are implemented for cryptographic key changes for - keys that have reached the end of their cryptoperiod, as defined by the associated - application vendor or key owner, and based on industry best practices and guidelines, - including the following: - - A defined cryptoperiod for each key type in use. - - A process for key changes at the end of the defined cryptoperiod. - levels: - - base - status: manual - - - id: 3.7.5 - title: Key management policies procedures are implemented to include the retirement, replacement, - or destruction of keys used to protect stored account data, as deemed necessary. - description: |- - Key management policies procedures are implemented to include the retirement, replacement, - or destruction of keys used to protect stored account data, as deemed necessary when: - - The key has reached the end of its defined cryptoperiod. - - The integrity of the key has been weakened, including when personnel with knowledge of a - cleartext key component leaves the company, or the role for which the key component was - known. - - The key is suspected of or known to be compromised. - - Retired or replaced keys are not used for encryption operations. - levels: - - base - status: manual - - - id: 3.7.6 - title: Where manual cleartext cryptographic key-management operations are performed by personnel, - key-management policies and procedures are implemented include managing these operations - using split knowledge and dual control. - description: |- - Cleartext secret or private keys cannot be known by anyone. Operations involving cleartext - keys cannot be carried out by a single person. This control is applicable for manual - key-management operations or where key management is not controlled by the encryption - product. A cryptographic key that is simply split into two parts does not meet this - requirement. Secret or private keys stored as key components or key shares must be - generated via one of the following - levels: - - base - status: manual - - - id: 3.7.7 - title: Key management policies and procedures are implemented to include the prevention of - unauthorized substitution of cryptographic keys. - description: |- - Cryptographic keys cannot be substituted by unauthorized personnel. - levels: - - base - status: manual - - - id: 3.7.8 - title: Key management policies and procedures are implemented to include that cryptographic - key custodians formally acknowledge (in writing or electronically) that they understand - and accept their key-custodian responsibilities. - description: |- - Key custodians are knowledgeable about their responsibilities in relation to cryptographic - operations and can access assistance and guidance when required. - levels: - - base - status: manual - - - id: 3.7.9 - title: 'Additional requirement for service providers only: Where a service provider shares - cryptographic keys with its customers for transmission or storage of account data, guidance - on secure transmission, storage and updating of such keys is documented and distributed - to the service provider’s customers.' - description: |- - Customers are provided with appropriate key management guidance whenever they receive - shared cryptographic keys. This requirement applies only when the entity being assessed is - a service provider. - levels: - - base - status: manual - - - id: '4.1' - title: Processes and mechanisms for protecting cardholder data with strong cryptography during - transmission over open, public networks are defined and documented. - levels: - - base - status: manual - controls: - - id: 4.1.1 - title: All security policies and operational procedures that are identified in Requirement - 4 are Documented, Kept up to date, In use and Known to all affected parties. - levels: - - base - status: manual - - - id: 4.1.2 - title: Roles and responsibilities for performing activities in Requirement 4 are documented, - assigned, and understood. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that day-to-day responsibilities - for performing all the activities in Requirement 4 are documented, assigned and understood - by the assigned personnel. - - - id: '4.2' - title: PAN is protected with strong cryptography during transmission. - levels: - - base - status: manual - controls: - - id: 4.2.1 - title: Strong cryptography and security protocols are implemented as follows to safeguard - PAN during transmission over open, public networks. - description: |- - Strong cryptography and security protocols are implemented as follows to safeguard PAN - during transmission over open, public networks: - - Only trusted keys and certificates are accepted. - - Certificates used to safeguard PAN during transmission over open, public networks are - confirmed as valid and are not expired or revoked. This bullet is a best practice until - 31 March 2025, after which it will be required as part of Requirement 4.2.1 and must be - fully considered during a PCI DSS assessment. - - The protocol in use supports only secure versions or configurations and does not support - fallback to, or use of insecure versions, algorithms, key sizes, or implementations. - - The encryption strength is appropriate for the encryption methodology in use. - levels: - - base - status: supported - controls: - - id: 4.2.1.1 - title: An inventory of the entity's trusted keys and certificates used to protect PAN - during transmission is maintained. - description: |- - All keys and certificates used to protect PAN during transmission are identified and - confirmed as trusted. This requirement is a best practice until 31 March 2025, after - which it will be required and must be fully considered during a PCI DSS assessment. - levels: - - base - status: manual - - - id: 4.2.1.2 - title: Wireless networks transmitting PAN or connected to the CDE use industry best - practices to implement strong cryptography for authentication and transmission. - description: |- - Cleartext PAN cannot be read or intercepted from wireless network transmissions. - levels: - - base - status: manual - notes: |- - Wireless interfaces are disabled by 1.3.3. - - - id: 4.2.2 - title: PAN is secured with strong cryptography whenever it is sent via end-user messaging - technologies. - description: |- - Cleartext PAN cannot be read or intercepted from transmissions using end-user messaging - technologies. This requirement also applies if a customer, or other third-party, requests - that PAN is sent to them via end-user messaging technologies. There could be occurrences - where an entity receives unsolicited cardholder data via an insecure communication channel - that was not intended for transmissions of sensitive data. In this situation, the entity - can choose to either include the channel in the scope of their CDE and secure it according - to PCI DSS or delete the cardholder data and implement measures to prevent the channel - from being used for cardholder data. - levels: - - base - status: manual - notes: |- - Some known insecure services and protocols are disabled by 2.2.4. - If any specific end-user messaging technology is used, it should be manually checked in - alignment to site policies. - - - id: '5.1' - title: Processes and mechanisms for protecting all systems and networks from malicious software - are defined and understood. - levels: - - base - status: manual - controls: - - id: 5.1.1 - title: All security policies and operational procedures that are identified in Requirement - 5 are Documented, Kept up to date, In use and Known to all affected parties. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that security policies and - operational procedures identified in Requirement 5 are managed in accordance with all - elements specified in this requirement. - - - id: 5.1.2 - title: Roles and responsibilities for performing activities in Requirement 5 are documented, - assigned, and understood. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that day-to-day responsibilities - for performing all the activities in Requirement 5 are documented, assigned and understood - by the assigned personnel. - - - id: '5.2' - title: Malicious software (malware) is prevented, or detected and addressed. - levels: - - base - status: pending - notes: |- - Related measures are covered by 1.2.6, 1.4.5 and 3.4.2. - controls: - - id: 5.2.1 - title: An anti-malware solution(s) is deployed on all system components, except for those - system components identified in periodic evaluations per Requirement 5.2.3 that concludes - the system components are not at risk from malware. - description: |- - Automated mechanisms are implemented to prevent systems from becoming an attack vector for - malware. - levels: - - base - status: supported - notes: |- - There are many options of anti-malware and the criteria for any adopted solution or - approach relies on each site policy. Technologies are supported but manual assessment is - required. - - - id: 5.2.2 - title: The deployed anti-malware solution(s) detects all known types of malware and removes, - blocks, or contains all known types of malware. - levels: - - base - status: manual - - - id: 5.2.3 - title: Any system components that are not at risk for malware are evaluated periodically. - description: |- - Any system components that are not at risk for malware are evaluated periodically to - include the following: - - A documented list of all system components not at risk for malware. - - Identification and evaluation of evolving malware threats for those system components. - - Confirmation whether such system components continue to not require anti-malware - protection. - levels: - - base - status: manual - controls: - - id: 5.2.3.1 - title: The frequency of periodic evaluations of system components identified as not - at risk for malware is defined in the entity's targeted risk analysis, which is - performed according to all elements specified in Requirement 12.3.1. - description: |- - Systems not known to be at risk from malware are re-evaluated at a frequency that - addresses the entity's risk. This requirement is a best practice until 31 March 2025, - after which it will be required and must be fully considered during a PCI DSS - assessment. - levels: - - base - status: manual - - - id: '5.3' - title: Anti-malware mechanisms and processes are active, maintained, and monitored. - levels: - - base - status: manual - controls: - - id: 5.3.1 - title: The anti-malware solution(s) is kept current via automatic updates. - description: |- - Anti-malware mechanisms can detect and address the latest malware threats. - levels: - - base - status: manual - - - id: 5.3.2 - title: The anti-malware solution(s) performs periodic scans and active or real-time scans - or performs continuous behavioral analysis of systems or processes. - levels: - - base - status: manual - controls: - - id: 5.3.2.1 - title: If periodic malware scans are performed to meet Requirement 5.3.2, the frequency - of scans is defined in the entity's targeted risk analysis, which is performed - according to all elements specified in Requirement 12.3.1. - description: |- - Scans by the malware solution are performed at a frequency that addresses the entity's - risk. This requirement applies to entities conducting periodic malware scans to meet - Requirement 5.3.2. This requirement is a best practice until 31 March 2025, after which - it will be required and must be fully considered during a PCI DSS assessment. - levels: - - base - status: manual - - - id: 5.3.3 - title: For removable electronic media, the anti-malware solution(s) performs automatic scans - of when the media is inserted, connected, or logically mounted, or Performs continuous - behavioral analysis of systems or processes when the media is inserted, connected, or - logically mounted. - levels: - - base - status: manual - notes: |- - Related measures are covered by 3.4.2. - - - id: 5.3.4 - title: Audit logs for the anti-malware solution(s) are enabled and retained in accordance - with Requirement 10.5.1. - description: |- - Historical records of anti-malware actions are immediately available and retained for at - least 12 months. - levels: - - base - status: manual - - - id: 5.3.5 - title: Anti-malware mechanisms cannot be disabled or altered by users, unless specifically - documented, and authorized by management on a case-by-case basis for a limited time period. - description: |- - Anti-malware mechanisms cannot be modified by unauthorized personnel.Anti-malware - solutions may be temporarily disabled only if there is a legitimate technical need, as - authorized by management on a case-by-case basis. If anti-malware protection needs to be - disabled for a specific purpose, it must be formally authorized. Additional security - measures may also need to be implemented for the period during which anti-malware - protection is not active. - levels: - - base - status: manual - notes: |- - Related measures are covered by 2.2.6 requirement and 8.2 section. - - - id: '5.4' - title: Anti-phishing mechanisms protect users against phishing attacks. - levels: - - base - status: manual - controls: - - id: 5.4.1 - title: Processes and automated mechanisms are in place to detect and protect personnel against - phishing attacks. - description: |- - Mechanisms are in place to protect against and mitigate risk posed by phishing attacks. - The focus of this requirement is on protecting personnel with access to system components - in-scope for PCI DSS. Meeting this requirement for technical and automated controls to - detect and protect personnel against phishing is not the same as Requirement 12.6.3.1 for - security awareness training. Meeting this requirement does not also meet the requirement - for providing personnel with security awareness training, and vice versa. This requirement - is a best practice until 31 March 2025, after which it will be required and must be fully - considered during a PCI DSS assessment. - levels: - - base - status: manual - - - id: '6.1' - title: Processes and mechanisms for developing and maintaining secure systems and software are - defined and understood. - levels: - - base - status: manual - controls: - - id: 6.1.1 - title: All security policies and operational procedures that are identified in Requirement - 6 are Documented, Kept up to date, In use and Known to all affected parties. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that security policies and - operational procedures identified in Requirement 6 are managed in accordance with all - elements specified in this requirement. - - - id: 6.1.2 - title: Roles and responsibilities for performing activities in Requirement 6 are documented, - assigned, and understood. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that day-to-day responsibilities - for performing all the activities in Requirement 6 are documented, assigned and understood - by the assigned personnel. - - - id: '6.2' - title: Bespoke and custom software are developed securely. - levels: - - base - status: manual - controls: - - id: 6.2.1 - title: Bespoke and custom software are developed securely. - description: |- - Bespoke and custom software are developed securely, as follows: - - Based on industry standards and/or best practices for secure development. - - In accordance with PCI DSS (for example, secure authentication and logging). - - Incorporating consideration of information security issues during each stage of the - software development lifecycle. - levels: - - base - status: manual - - - id: 6.2.2 - title: Software development personnel working on bespoke and custom software are trained - at least once every 12 months - description: |- - Software development personnel working on bespoke and custom software are trained at least - once every 12 months as follows: - - On software security relevant to their job function and development languages. - - Including secure software design and secure coding techniques. - - Including, if security testing tools are used, how to use the tools for detecting - vulnerabilities in software. - levels: - - base - status: manual - - - id: 6.2.3 - title: Bespoke and custom software is reviewed prior to being released into production or - to customers, to identify and correct potential coding vulnerabilities. - description: |- - Bespoke and custom software is reviewed prior to being released into production or to - customers, to identify and correct potential coding vulnerabilities, as follows: - - Code reviews ensure code is developed according to secure coding guidelines. - - Code reviews look for both existing and emerging software vulnerabilities. - - Appropriate corrections are implemented prior to release. - levels: - - base - status: manual - controls: - - id: 6.2.3.1 - title: If manual code reviews are performed for bespoke and custom software prior to - release to production code changes co-reviewed and approved. - description: |- - If manual code reviews are performed for bespoke and custom software prior to release - to production code changes are: - - Reviewed by individuals other than the originating code author, and who are - knowledgeable about code-review techniques and secure coding practices. - - Reviewed and approved by management prior to release. - levels: - - base - status: manual - - - id: 6.2.4 - title: Software engineering techniques or other methods are defined and in use by software - development personnel to prevent or mitigate common software attacks and related vulnerabilities - in bespoke and custom software. - levels: - - base - status: manual - - - id: '6.3' - title: Security vulnerabilities are identified and addressed. - levels: - - base - status: pending - controls: - - id: 6.3.1 - title: Security vulnerabilities are identified and managed - levels: - - base - status: manual - - - id: 6.3.2 - title: An inventory of bespoke and custom software, and third-party software components incorporated - into bespoke and custom software is maintained to facilitate vulnerability and patch - management. - description: |- - Known vulnerabilities in third-party software components cannot be exploited in bespoke - and custom software.This requirement is a best practice until 31 March 2025, after which - it will be required and must be fully considered during a PCI DSS assessment. - levels: - - base - status: manual - notes: |- - This requirement is a best practice until 31 March 2025, after which it will be required - and must be fully considered during a PCI DSS assessment. - - - id: 6.3.3 - title: All system components are protected from known vulnerabilities by installing applicable - security patches/updates. - description: |- - All system components are protected from known vulnerabilities by installing - applicable security patches/updates as follows: - - Patches/updates for critical vulnerabilities (identified according to the risk ranking - process at Requirement 6.3.1) are installed within one month of release. - - All other applicable security patches/updates are installed within an appropriate time - frame as determined by the entity's assessment of the criticality of the risk to the - environment as identified according to the risk ranking process at Requirement 6.3.1. - levels: - - base - status: pending - - - id: '6.4' - title: Public-facing web applications are protected against attacks. - levels: - - base - status: manual - controls: - - id: 6.4.1 - title: For public-facing web applications, new threats and vulnerabilities are addressed - on an ongoing basis and these applications are protected against known attacks. - description: |- - For public-facing web applications, new threats and vulnerabilities are addressed on an - ongoing basis and these applications are protected against known attacks as follows: - - Reviewing public-facing web applications via manual or automated application - vulnerability security assessment tools or methods as follows: - - At least once every 12 months and after significant changes. - - By an entity that specializes in application security. - - Including, at a minimum, all common software attacks in Requirement 6.2.4. - - All vulnerabilities are ranked in accordance with requirement 6.3.1. - - All vulnerabilities are corrected. - - The application is re-evaluated after the corrections - OR - - Installing an automated technical solution(s) that continually detects and prevents - web-based attacks as follows: - - Installed in front of public-facing web applications to detect and prevent web-based - attacks. - - Actively running and up to date as applicable. - - Generating audit logs. - - Configured to either block web-based attacks or generate an alert that is immediately - investigated. - levels: - - base - status: manual - - - id: 6.4.2 - title: For public-facing web applications, an automated technical solution is deployed that - continually detects and prevents web-based attacks. - levels: - - base - status: manual - - - id: 6.4.3 - title: All payment page scripts that are loaded and executed in the consumer's browser are - managed - description: |- - All payment page scripts that are loaded and executed in the consumer's browser are - managed as follows: - - A method is implemented to confirm that each script is authorized. - - A method is implemented to assure the integrity of each script. - - An inventory of all scripts is maintained with written business or technical - justification as to why each is necessary. - levels: - - base - status: manual - - - id: '6.5' - title: Changes to all system components are managed securely. - levels: - - base - status: manual - controls: - - id: 6.5.1 - title: Changes to all system components in the production environment are made according - to established procedures. - levels: - - base - status: manual - - - id: 6.5.2 - title: Upon completion of a significant change, all applicable PCI DSS requirements are confirmed - to be in place on all new or changed systems and networks, and documentation is updated - as applicable. - description: |- - All system components are verified after a significant change to be compliant with the - applicable PCI DSS requirements.These significant changes should also be captured and - reflected in the entity's annual PCI DSS scope confirmation activity per Requirement - 12.5.2. - levels: - - base - status: manual - - - id: 6.5.3 - title: Pre-production environments are separated from production environments and the separation - is enforced with access controls. - description: |- - Pre-production environments cannot introduce risks and vulnerabilities into production - environments. - levels: - - base - status: manual - - - id: 6.5.4 - title: Roles and functions are separated between production and pre-production environments - to provide accountability such that only reviewed and approved changes are deployed. - description: |- - Job roles and accountability that differentiate between pre-production and production - activities are defined and managed to minimize the risk of unauthorized, unintentional, - or inappropriate actions. In environments with limited personnel where individuals perform - multiple roles or functions, this same goal can be achieved with additional procedural - controls that provide accountability. For example, a developer may also be an administrator - that uses an administrator-level account with elevated privileges in the development - environment and, for their developer role, they use a separate account with user-level - access to the production environment. - levels: - - base - status: manual - - - id: 6.5.5 - title: Live PANs are not used in pre-production environments, except where those environments - are included in the CDE and protected in accordance with all applicable PCI DSS requirements. - description: |- - Live PANs cannot be present in pre-production environments outside the CDE.s - levels: - - base - status: manual - - - id: 6.5.6 - title: Test data and test accounts are removed from system components before the system goes - into production. - description: |- - Test data and test accounts cannot exist in production environments. - levels: - - base - status: manual - - - id: '7.1' - title: Processes and mechanisms for restricting access to system components and cardholder data - by business need to know are defined and understood. - levels: - - base - status: manual - controls: - - id: 7.1.1 - title: All security policies and operational procedures that are identified in Requirement - 7 are Documented, Kept up to date, In use and Known to all affected parties. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that security policies and - operational procedures identified in Requirement 7 are managed in accordance with all - elements specified in this requirement. - - - id: 7.1.2 - title: Roles and responsibilities for performing activities in Requirement 7 are documented, - assigned, and understood. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that day-to-day responsibilities - for performing all the activities in Requirement 7 are documented, assigned and understood - by the assigned personnel. - - - id: '7.2' - title: Access to system components and data is appropriately defined and assigned. - levels: - - base - status: manual - controls: - - id: 7.2.1 - title: An access control model is defined and includes granting access - description: |- - An access control model is defined and includes granting access as follows: - - Appropriate access depending on the entity's business and access needs. - - Access to system components and data resources that is based on users' job - classification and functions. - - The least privileges required (for example, user, administrator) to perform a job - function. - levels: - - base - status: manual - notes: |- - General access are restricted by 2.2.6 and 8.2 section. This requirement is more about - checking granting access process. - - - id: 7.2.2 - title: Access is assigned to users, including privileged users, based on job classification - and function, and least privileges necessary to perform job responsibilities. - levels: - - base - status: manual - - - id: 7.2.3 - title: Required privileges are approved by authorized personnel. - description: |- - Access privileges cannot be granted to users without appropriate, documented - authorization. - levels: - - base - status: manual - - - id: 7.2.4 - title: All user accounts and related access privileges, including third-party/vendor accounts, - are reviewed - description: |- - All user accounts and related access privileges, including third-party/vendor accounts, - are reviewed as follows: - - At least once every six months. - - To ensure user accounts and access remain appropriate based on job function. - - Any inappropriate access is addressed. - - Management acknowledges that access remains appropriate. - levels: - - base - status: manual - - - id: 7.2.5 - title: All application and system accounts and related access privileges are assigned and - managed. - description: |- - All application and system accounts and related access privileges are assigned and managed - as follows: - - Based on the least privileges necessary for the operability of the system or application. - - Access is limited to the systems, applications, or processes that specifically require - their use. - levels: - - base - status: manual - notes: |- - General access are restricted by 2.2.6 and 8.2 section. - controls: - - id: 7.2.5.1 - title: All access by application and system accounts and related access privileges - are reviewed. - levels: - - base - status: manual - - - id: 7.2.6 - title: All user access to query repositories of stored cardholder data is restricted - levels: - - base - status: manual - notes: |- - This requirement is specific about cardholder data, which can be available in different - formats, such as clear and binary files, and databases depending on site policies. - General system restrictions are covered in 2.2.6. - - - id: '7.3' - title: 'Access to system components and data is managed via an access control system(s).' - levels: - - base - status: planned - controls: - - id: 7.3.1 - title: An access control system(s) is in place that restricts access based on a user's need - to know and covers all system components. - description: |- - Access rights and privileges are managed via mechanisms intended for that purpose. - levels: - - base - status: manual - - - id: 7.3.2 - title: The access control system(s) is configured to enforce permissions assigned to individuals, - applications, and systems based on job classification and function. - description: |- - Individual account access rights and privileges to systems, applications, and data are - only inherited from group membership. - levels: - - base - status: manual - - - id: 7.3.3 - title: The access control system(s) is set to "deny all" by default. - description: |- - Access rights and privileges are prohibited unless expressly permitted. - levels: - - base - status: planned - notes: |- - It is possible we can select some rules for this requirement but more investigation is - needed to confirm. - - - id: '8.1' - title: Processes and mechanisms for identifying users and authenticating access to system components - are defined and understood. - levels: - - base - status: manual - controls: - - id: 8.1.1 - title: All security policies and operational procedures that are identified in Requirement - 8 are Documented, Kept up to date, In use and Known to all affected parties. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that security policies and - operational procedures identified in Requirement 8 are managed in accordance with all - elements specified in this requirement. - - - id: 8.1.2 - title: Roles and responsibilities for performing activities in Requirement 8 are documented, - assigned, and understood. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that day-to-day responsibilities - for performing all the activities in Requirement 8 are documented, assigned and understood - by the assigned personnel. - - - id: '8.2' - title: User identification and related accounts for users and administrators are strictly managed - throughout an account's lifecycle. - levels: - - base - status: pending - controls: - - id: 8.2.1 - title: All users are assigned a unique ID before access to system components or cardholder - data is allowed. - description: |- - All actions by all users are attributable to an individual. This requirement is not - intended to apply to user accounts within point-of-sale terminals that have access to only - one card number at a time to facilitate a single transaction (such as IDs used by cashiers - on point-of-sale terminals). - levels: - - base - status: planned - notes: |- - The rules selected in this requirement are incomplete. Missing remediation and test - scenarios. They should include test scenarios and likely remediation or a warning - informing why a remediation is not present. - - - id: 8.2.2 - title: Group, shared, or generic IDs, or other shared authentication credentials are only - used when necessary on an exception basis, and are managed. - description: |- - - ID use is prevented unless needed for an exceptional circumstance. - - Use is limited to the time needed for the exceptional circumstance. - - Business justification for use is documented. - - Use is explicitly approved by management. - - Individual user identity is confirmed before access to an account is granted. - - Every action taken is attributable to an individual user. - levels: - - base - status: pending - notes: |- - This requirement is complemented by 8.2.1 and related to 8.3.5. - - - id: 8.2.3 - title: 'Additional requirement for service providers only: Service providers with remote - access to customer premises use unique authentication factors for each customer premises.' - levels: - - base - status: manual - - - id: 8.2.4 - title: Addition, deletion, and modification of user IDs, authentication factors, and other - identifier objects are managed - levels: - - base - status: manual - - - id: 8.2.5 - title: Access for terminated users is immediately revoked. - description: |- - The accounts of terminated users cannot be used. - levels: - - base - status: manual - notes: |- - This requirement depends on site policies for user termination. - - - id: 8.2.6 - title: Inactive user accounts are removed or disabled within 90 days of inactivity. - description: |- - Inactive user accounts cannot be used. - levels: - - base - status: pending - notes: |- - Also related to requirements 2.2.2 and 8.3.5. - - - id: 8.2.7 - title: Accounts used by third parties to access, support, or maintain system components via - remote access are managed. - levels: - - base - status: manual - - - id: 8.2.8 - title: If a user session has been idle for more than 15 minutes, the user is required to - re-authenticate to re-activate the terminal or session. - description: |- - A user session cannot be used except by the authorized user. This requirement is not - intended to apply to user accounts on point-of-sale terminals that have access to only one - card number at a time to facilitate a single transaction (such as IDs used by cashiers on - point-of-sale terminals). This requirement is not meant to prevent legitimate activities - from being performed while the console/PC is unattended. - levels: - - base - status: pending - - - id: '8.3' - title: Strong authentication for users and administrators is established and managed. - levels: - - base - status: pending - controls: - - id: 8.3.1 - title: All user access to system components for users and administrators is authenticated. - levels: - - base - status: pending - - - id: 8.3.2 - title: Strong cryptography is used to render all authentication factors unreadable during - transmission and storage on all system components. - description: |- - Cleartext authentication factors cannot be obtained, derived, or reused from the - interception of communications or from stored data. - levels: - - base - status: pending - notes: |- - There are similar rules that might be redundant for some distros. - - - id: 8.3.3 - title: User identity is verified before modifying any authentication factor. - description: |- - Unauthorized individuals cannot gain system access by impersonating the identity of an - authorized user. - levels: - - base - status: manual - notes: |- - This requirement is about processes, such as password resets, provisioning new hardware or - software tokens, and generating new keys. It is common that these activities involve help - desk teams and administrators and the involved people should ensure identities are properly - verified. - - - id: 8.3.4 - title: Invalid authentication attempts are limited. - description: |- - - Locking out the user ID after not more than 10 attempts. - - Setting the lockout duration to a minimum of 30 minutes or until the user's identity is - confirmed. - levels: - - base - status: pending - - - id: 8.3.5 - title: If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, - they are set and reset for each user. - description: |- - - Set to a unique value for first-time use and upon reset. - - Forced to be changed immediately after the first use. - levels: - - base - status: pending - notes: |- - Also related to requirement 2.2.2, 8.2.2 and 8.2.6. - - - id: 8.3.6 - title: If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, - they meet the minimum level of complexity. - description: |- - - A minimum length of 12 characters (or IF the system does not support 12 characters, a - minimum length of eight characters). - - Contain both numeric and alphabetic characters. - A guessed password/passphrase cannot be verified by either an online or offline brute - force attack. - levels: - - base - status: pending - notes: |- - This requirement is not intended to apply to: - - User accounts on point-of-sale terminals that have access to only one card number at a - time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale - terminals). - - Application or system accounts, which are governed by requirements in section 8.6. - - - id: 8.3.7 - title: Individuals are not allowed to submit a new password/passphrase that is the same as - any of the last four passwords/passphrases used. - description: |- - A previously used password cannot be used to gain access to an account for at least 12 - months. - levels: - - base - status: pending - notes: |- - This requirement is not intended to apply to user accounts on point-of-sale terminals that - have access to only one card number at a time to facilitate a single transaction (such as - IDs used by cashiers on point-of-sale terminals). - For RHEL 8 and RHEL 9 systems, the accounts_password_pam_pwhistory_... rules should be - prefered in detriment of accounts_password_pam_unix_remember. Using both should not create - conflict but is unnecessary and the last should be filtered out from the profile. - - - id: 8.3.8 - title: Authentication policies and procedures are documented and communicated to all users. - levels: - - base - status: manual - - - id: 8.3.9 - title: If passwords/passphrases are used as the only authentication factor for user access - (i.e., in any single-factor authentication implementation) they should have a limited - lifetime. - description: |- - If passwords/passphrases are used as the only authentication factor for user access (i.e., - in any single-factor authentication implementation) then either: - - Passwords/passphrases are changed at least once every 90 days, - OR - - The security posture of accounts is dynamically analyzed, and real-time access to - resources is automatically determined accordingly. - levels: - - base - status: pending - notes: |- - The requirement does not explicitily define the number of days before the password - expiration to warn the users, but the relevant rules were selected here as they do not - cause any problems in combination with password lifetime rules. - - - id: 8.3.10 - title: 'Additional requirement for service providers only: If passwords/passphrases are used - as the only authentication factor for customer user access to cardholder data (i.e., - in any single-factor authentication implementation) then guidance is provided to customer - users.' - levels: - - base - status: manual - controls: - - id: 8.3.10.1 - title: 'Additional requirement for service providers only: If passwords/passphrases - are used as the only authentication factor for customer user access (i.e., in any - single-factor authentication implementation) they should have a limited lifetime.' - levels: - - base - status: pending - notes: |- - This requirement is already covered by 8.3.9. - - - id: 8.3.11 - title: Where authentication factors such as physical or logical security tokens, smart cards, - or certificates are used, factors are not shared among multiple users and the usage is - controlled.' - levels: - - base - status: manual - - - id: '8.4' - title: Multi-factor authentication (MFA) is implemented to secure access into the CDE. - levels: - - base - status: supported - notes: |- - This parent requirement does not set one specific combination of Multi-factor authentication - (MFA), so we can't enforce the use of smartcards or any specific solution. The systems - usually support MFA but the chosen solution depends on site policies. - controls: - - id: 8.4.1 - title: MFA is implemented for all non-console access into the CDE for personnel with administrative - access. - levels: - - base - status: supported - - - id: 8.4.2 - title: MFA is implemented for all non-console access into the CDE. - description: |- - Access into the CDE cannot be obtained by the use of a single authentication factor. - levels: - - base - status: manual - - - id: 8.4.3 - title: MFA is implemented for all remote access originating from outside the entity's network - that could access or impact the CDE. - levels: - - base - status: manual - - - id: '8.5' - title: Multi-factor authentication (MFA) systems are configured to prevent misuse. - levels: - - base - status: manual - controls: - - id: 8.5.1 - title: MFA systems are properly implemented. - description: |- - - The MFA system is not susceptible to replay attacks. - - MFA systems cannot be bypassed by any users, including administrative users unless - specifically documented, and authorized by management on an exception basis, for a limited - time period. - - At least two different types of authentication factors are used. - - Success of all authentication factors is required before access is granted. - levels: - - base - status: manual - notes: |- - Each site might have a different MFA solution and each solution has its own capabilities. - This requirement demands manual assessment based on site policies. - - - id: '8.6' - title: Use of application and system accounts and associated authentication factors is strictly - managed. - levels: - - base - status: pending - controls: - - id: 8.6.1 - title: If accounts used by systems or applications can be used for interactive login, they - are managed. - description: |- - - Interactive use is prevented unless needed for an exceptional circumstance. - - Interactive use is limited to the time needed for the exceptional circumstance. - - Business justification for interactive use is documented. - - Interactive use is explicitly approved by management. - - Individual user identity is confirmed before access to account is granted. - - Every action taken is attributable to an individual user. - levels: - - base - status: pending - notes: |- - This requirement is related to 2.2.2, 2.2.6, 8.2.1 and 8.2.2. Specifically on 8.2.2 system - accounts usage is restricted. Exceptions to system accounts should be manually checked to - ensure the requirements in description. This requirement although implements some extra - controls regarding root account. - - - id: 8.6.2 - title: Passwords/passphrases for any application and system accounts that can be used for - interactive login are not hard coded in scripts, configuration/property files, or bespoke - and custom source code. - description: |- - Passwords/passphrases used by application and system accounts cannot be used by - unauthorized personnel. - levels: - - base - status: manual - - - id: 8.6.3 - title: Passwords/passphrases for any application and system accounts are protected against - misuse. - description: |- - - Passwords/passphrases are changed periodically (at the frequency defined in the entity's - targeted risk analysis, which is performed according to all elements specified in - Requirement 12.3.1) and upon suspicion or confirmation of compromise. - - Passwords/passphrases are constructed with sufficient complexity appropriate for how - frequently the entity changes the passwords/passphrases. - levels: - - base - status: pending - notes: |- - Related to requirements 8.3.6 and 8.3.9. - - - id: '9.1' - title: Processes and mechanisms for restricting physical access to cardholder data are defined - and understood. - levels: - - base - status: manual - controls: - - id: 9.1.1 - title: All security policies and operational procedures that are identified in Requirement - 9 are Documented, Kept up to date, In use and Known to all affected parties. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that security policies and - operational procedures identified in Requirement 9 are managed in accordance with all - elements specified in this requirement. - - - id: 9.1.2 - title: Roles and responsibilities for performing activities in Requirement 9 are documented, - assigned, and understood. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that day-to-day responsibilities - for performing all the activities in Requirement 9 are documented, assigned and understood - by the assigned personnel. - - - id: '9.2' - title: Physical access controls manage entry into facilities and systems containing cardholder - data. - levels: - - base - status: manual - controls: - - id: 9.2.1 - title: Appropriate facility entry controls are in place to restrict physical access to systems - in the CDE. - description: |- - System components in the CDE cannot be physically accessed by unauthorized personnel. - levels: - - base - status: manual - controls: - - id: 9.2.1.1 - title: Individual physical access to sensitive areas within the CDE is monitored with - either video cameras or physical access control mechanisms (or both). - levels: - - base - status: manual - - - id: 9.2.2 - title: Physical and/or logical controls are implemented to restrict use of publicly accessible - network jacks within the facility. - description: |- - Unauthorized devices cannot connect to the entity's network from public areas within the - facility. - levels: - - base - status: not applicable - - - id: 9.2.3 - title: Physical access to wireless access points, gateways, networking/communications hardware, - and telecommunication lines within the facility is restricted - description: |- - Physical networking equipment cannot be accessed by unauthorized personnel. - levels: - - base - status: not applicable - - - id: 9.2.4 - title: Access to consoles in sensitive areas is restricted via locking when not in use. - description: |- - Physical consoles within sensitive areas cannot be used by unauthorized personnel. - levels: - - base - status: manual - notes: |- - Related to requirement 8.2.8. - This requirement asks to observe a system administrator's attempt to log into consoles in - sensitive areas and verify that they are "locked" to prevent unauthorized use. Therefore - it is a manual requirement applicable only very specific circumstances. - - - id: '9.3' - title: Physical access for personnel and visitors is authorized and managed. - levels: - - base - status: manual - controls: - - id: 9.3.1 - title: Procedures are implemented for authorizing and managing physical access of personnel - to the CDE. - levels: - - base - status: manual - controls: - - id: 9.3.1.1 - title: Physical access to sensitive areas within the CDE for personnel is controlled - levels: - - base - status: manual - - - id: 9.3.2 - title: Procedures are implemented for authorizing and managing visitor access to the CDE. - levels: - - base - status: manual - - - id: 9.3.3 - title: Visitor badges or identification are surrendered or deactivated before visitors leave - the facility or at the date of expiration. - description: |- - Visitor identification or badges cannot be reused after expiration. - levels: - - base - status: manual - - - id: 9.3.4 - title: Visitor logs are used to maintain a physical record of visitor activity both within - the facility and within sensitive areas. - levels: - - base - status: manual - - - id: '9.4' - title: Media with cardholder data is securely stored, accessed, distributed, and destroyed. - levels: - - base - status: manual - controls: - - id: 9.4.1 - title: All media with cardholder data is physically secured. - description: |- - Media with cardholder data cannot be accessed by unauthorized personnel. - levels: - - base - status: manual - controls: - - id: 9.4.1.1 - title: Offline media backups with cardholder data are stored in a secure location. - description: |- - Offline backups cannot be accessed by unauthorized personnel. - levels: - - base - status: manual - - - id: 9.4.1.2 - title: The security of the offline media backup location(s) with cardholder data is - reviewed at least once every 12 months. - description: |- - The security controls protecting offline backups are verified periodically by - inspection. - levels: - - base - status: manual - - - id: 9.4.2 - title: All media with cardholder data is classified in accordance with the sensitivity of - the data. - description: |- - Media are classified and protected appropriately. - levels: - - base - status: manual - - - id: 9.4.3 - title: Media with cardholder data sent outside the facility is secured. - description: |- - Media is secured and tracked when transported outside the facility. - - Media sent outside the facility is logged. - - Media is sent by secured courier or other delivery method that can be accurately - tracked. - - Offsite tracking logs include details about media location. - levels: - - base - status: manual - - - id: 9.4.4 - title: Management approves all media with cardholder data that is moved outside the facility - (including when media is distributed to individuals). - description: |- - Media cannot leave a facility without the approval of accountable personnel. Individuals - approving media movements should have the appropriate level of management authority to - grant this approval. However, it is not specifically required that such individuals have - "manager" as part of their title. - levels: - - base - status: manual - - - id: 9.4.5 - title: Inventory logs of all electronic media with cardholder data are maintained. - description: |- - Accurate inventories of stored electronic media are maintained. - levels: - - base - status: manual - controls: - - id: 9.4.5.1 - title: Inventories of electronic media with cardholder data are conducted at least - once every 12 months. - description: |- - Media inventories are verified periodically. - levels: - - base - status: manual - - - id: 9.4.6 - title: Hard-copy materials with cardholder data are destroyed when no longer needed for business - or legal reasons. - levels: - - base - status: manual - - - id: 9.4.7 - title: Electronic media with cardholder data is destroyed when no longer needed for business - or legal reasons. - description: |- - - The electronic media is destroyed. - - The cardholder data is rendered unrecoverable so that it cannot be reconstructed. - levels: - - base - status: manual - - - id: '9.5' - title: Point-of-interaction (POI) devices are protected from tampering and unauthorized substitution. - levels: - - base - status: manual - controls: - - id: 9.5.1 - title: POI devices that capture payment card data via direct physical interaction with the - payment card form factor are protected from tampering and unauthorized substitution. - levels: - - base - status: manual - controls: - - id: 9.5.1.1 - title: An up-to-date list of POI devices is maintained. - levels: - - base - status: manual - - - id: 9.5.1.2 - title: POI device surfaces are periodically inspected to detect tampering and unauthorized - substitution. - description: |- - Point of Interaction Devices cannot be tampered with, substituted without authorization, - or have skimming attachments installed without timely detection. - levels: - - base - status: manual - controls: - - id: 9.5.1.2.1 - title: The frequency of periodic POI device inspections and the type of inspections - performed is defined in the entity's targeted risk analysis, which is performed - according to all elements specified in Requirement 12.3.1. - description: |- - POI devices are inspected at a frequency that addresses the entity's risk. - This requirement is a best practice until 31 March 2025, after which it will be - required and must be fully considered during a PCI DSS assessment. - levels: - - base - status: manual - - - id: 9.5.1.3 - title: Training is provided for personnel in POI environments to be aware of attempted - tampering or replacement of POI devices. - levels: - - base - status: manual - - - id: '10.1' - title: Processes and mechanisms for logging and monitoring all access to system components and - cardholder data are defined and documented. - levels: - - base - status: manual - controls: - - id: 10.1.1 - title: All security policies and operational procedures that are identified in Requirement - 10 are Documented, Kept up to date, In use and Known to all affected parties. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that security policies and - operational procedures identified in Requirement 10 are managed in accordance with all - elements specified in this requirement. - - - id: 10.1.2 - title: Roles and responsibilities for performing activities in Requirement 10 are documented, - assigned, and understood. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that day-to-day responsibilities - for performing all the activities in Requirement 10 are documented, assigned and - understood by the assigned personnel. - - - id: '10.2' - title: Audit logs are implemented to support the detection of anomalies and suspicious activity, - and the forensic analysis of events. - levels: - - base - status: pending - controls: - - id: 10.2.1 - title: Audit logs are enabled and active for all system components and cardholder data. - description: |- - Records of all activities affecting system components and cardholder data are captured. - levels: - - base - status: pending - controls: - - id: 10.2.1.1 - title: Audit logs capture all individual user access to cardholder data. - description: |- - Records of all individual user access to cardholder data are captured. - levels: - - base - status: planned - notes: |- - Differently than 10.2.1.4, this requirement is about logginh successful access to - cardholder data. This kind of events can easily hit performance issues and are usually - not necessary if a good access policy is in place. More clarification is needed about - this requirement. - - - id: 10.2.1.2 - title: Audit logs capture all actions taken by any individual with administrative access, - including any interactive use of application or system accounts. - description: |- - Records of all actions performed by individuals with elevated privileges are captured. - levels: - - base - status: pending - notes: |- - Not all privileged commands have suid or sgid enabled. We probably want to include more - rules for this requirement. - - - id: 10.2.1.3 - title: Audit logs capture all access to audit logs. - description: |- - Records of all access to audit logs are captured. - levels: - - base - status: pending - - - id: 10.2.1.4 - title: Audit logs capture all invalid logical access attempts. - description: |- - Records of all invalid access attempts are captured. - levels: - - base - status: pending - - - id: 10.2.1.5 - title: Audit logs capture all changes to identification and authentication credentials. - levels: - - base - status: pending - - - id: 10.2.1.6 - title: Audit logs capture the initialization of new audit logs, and starting, stopping, - or pausing of the existing audit logs. - levels: - - base - status: planned - notes: |- - Ideally should exist rules specifically logging when audit configuration files are - modified and audit service state is changed. - - - id: 10.2.1.7 - title: Audit logs capture all creation and deletion of system-level objects. - description: |- - Records of alterations that indicate a system has been modified from its intended - functionality are captured. - levels: - - base - status: pending - notes: |- - There are enough rules to capture deletion events but not for creation events. - This requirement needs to be better investigated to confirm which additional rules would - satistfy the requirement. - - - id: 10.2.2 - title: Audit logs record sufficient details for each auditable event. - description: |- - - User identification. - - Type of event. - - Date and time. - - Success and failure indication. - - Origination of event. - - Identity or name of affected data, system component, resource, or service (for example, - name and protocol). - levels: - - base - status: pending - notes: |- - Standard settings for audit should be enough. - - - id: '10.3' - title: Audit logs are protected from destruction and unauthorized modifications. - levels: - - base - status: pending - controls: - - id: 10.3.1 - title: Read access to audit logs files is limited to those with a job-related need. - description: |- - Stored activity records cannot be accessed by unauthorized personnel. - levels: - - base - status: pending - - - id: 10.3.2 - title: Audit log files are protected to prevent modifications by individuals. - description: |- - Stored activity records cannot be modified by personnel. - levels: - - base - status: pending - - - id: 10.3.3 - title: Audit log files, including those for external-facing technologies, are promptly backed - up to a secure, central, internal log server(s) or other media that is difficult to modify. - description: |- - Stored activity records are secured and preserved in a central location to prevent - unauthorized modification. - levels: - - base - status: pending - notes: |- - Although the technologies in general allow to send logs to a centralized server, some - parameters for this configuration are specific to each site policy and therefore the - requirement demands manual assessment. - - - id: 10.3.4 - title: File integrity monitoring or change-detection mechanisms is used on audit logs to - ensure that existing log data cannot be changed without generating alerts. - description: |- - Stored activity records cannot be modified without an alert being generated. - levels: - - base - status: pending - - - id: '10.4' - title: Audit logs are reviewed to identify anomalies or suspicious activity. - levels: - - base - status: manual - controls: - - id: 10.4.1 - title: The audit logs are reviewed at least once daily. - description: |- - - All security events. - - Logs of all system components that store, process, or transmit CHD and/or SAD. - - Logs of all critical system components. - - Logs of all servers and system components that perform security functions (for example, - network security controls, intrusion-detection systems/intrusion-prevention systems - (IDS/IPS), authentication servers). - levels: - - base - status: manual - controls: - - id: 10.4.1.1 - title: Automated mechanisms are used to perform audit log reviews. - description: |- - Potentially suspicious or anomalous activities are identified via a repeatable and - consistent mechanism. This requirement is a best practice until 31 March 2025, after - which it will be required and must be fully considered during a PCI DSS assessment. - levels: - - base - status: manual - notes: |- - Automation mechanisms, solutions and approaches vary for each organizarion. - - - id: 10.4.2 - title: Logs of all other system components (those not specified in Requirement 10.4.1) are - reviewed periodically. - description: |- - Potentially suspicious or anomalous activities for other system components (not included - in 10.4.1) are reviewed in accordance with the entity's identified risk. This requirement - is applicable to all other in-scope system components not included in Requirement 10.4.1. - levels: - - base - status: manual - controls: - - id: 10.4.2.1 - title: The frequency of periodic log reviews for all other system components (not defined - in Requirement 10.4.1) is defined in the entity's targeted risk analysis, which - is performed according to all elements specified in Requirement 12.3.1 - description: |- - Log reviews for lower-risk system components are performed at a frequency that addresses - the entity's risk. This requirement is a best practice until 31 March 2025, after which - it will be required and must be fully considered during a PCI DSS assessment. - levels: - - base - status: manual - - - id: 10.4.3 - title: Exceptions and anomalies identified during the review process are addressed. - description: |- - Suspicious or anomalous activities are addressed. - levels: - - base - status: manual - - - id: '10.5' - title: Audit log history is retained and available for analysis. - levels: - - base - status: pending - controls: - - id: 10.5.1 - title: Retain audit log history for at least 12 months, with at least the most recent three - months immediately available for analysis. - description: |- - Historical records of activity are available immediately to support incident response and - are retained for at least 12 months. - levels: - - base - status: pending - notes: |- - It is not simple to ensure 12 months history is present in each system but the rules in - this requirement ensures the logs are not lost without administrators awareness. - - - id: '10.6' - title: Time-synchronization mechanisms support consistent time settings across all systems. - levels: - - base - status: pending - controls: - - id: 10.6.1 - title: System clocks and time are synchronized using time-synchronization technology. - description: |- - Common time is established across all systems. Keeping time-synchronization technology - current includes managing vulnerabilities and patching the technology according to PCI DSS - Requirements 6.3.1 and 6.3.3. - levels: - - base - status: pending - notes: |- - Maybe it is possible to optmize some similar rules related to ntp. - - - id: 10.6.2 - title: Systems are configured to the correct and consistent time. - description: |- - - One or more designated time servers are in use. - - Only the designated central time server(s) receives time from external sources. - - Time received from external sources is based on International Atomic Time or Coordinated - Universal Time (UTC). - - The designated time server(s) accept time updates only from specific industry-accepted - external sources. - - Where there is more than one designated time server, the time servers peer with one - another to keep accurate time. - - Internal systems receive time information only from designated central time server(s). - levels: - - base - status: pending - notes: |- - The selected rules might need updates in order to restrict their platform applicability - to avoid conflicts. - - - id: 10.6.3 - title: Time synchronization settings and data are protected. - description: |- - - Access to time data is restricted to only personnel with a business need. - - Any changes to time settings on critical systems are logged, monitored, and reviewed. - levels: - - base - status: pending - - - id: '10.7' - title: Failures of critical security control systems are detected, reported, and responded to promptly. - levels: - - base - status: pending - controls: - - id: 10.7.1 - title: 'Additional requirement for service providers only: Failures of critical security - control systems are detected, alerted, and addressed promptly.' - description: |- - It includes but is not limited to failure of the following critical security control - systems: - - Network security controls. - - IDS/IPS. - - FIM. - - Anti-malware solutions. - - Physical access controls. - - Logical access controls. - - Audit logging mechanisms. - - Segmentation controls (if used). - levels: - - base - status: manual - - - id: 10.7.2 - title: Failures of critical security control systems are detected, alerted, and addressed - promptly. - description: |- - It includes but is not limited to failure of the following critical security control - systems: - - Network security controls. - - IDS/IPS. - - Change-detection mechanisms. - - Anti-malware solutions. - - Physical access controls. - - Logical access controls. - - Audit logging mechanisms. - - Segmentation controls (if used). - - Audit log review mechanisms. - - Automated security testing tools (if used). - levels: - - base - status: pending - - - id: 10.7.3 - title: Failures of any critical security controls systems are responded to restore security - functions, ensure documentation, address security issues and prevent other failures. - description: |- - It includes but is not limited to: - - Restoring security functions. - - Identifying and documenting the duration (date and time from start to end) of the - security failure. - - Identifying and documenting the cause(s) of failure and documenting required - remediation. - - Identifying and addressing any security issues that arose during the failure. - - Determining whether further actions are required as a result of the security failure. - - Implementing controls to prevent the cause of failure from reoccurring. - - Resuming monitoring of security controls. - levels: - - base - status: manual - - - id: '11.1' - title: Processes and mechanisms for regularly testing security of systems and networks are defined - and understood. - levels: - - base - status: manual - controls: - - id: 11.1.1 - title: All security policies and operational procedures that are identified in Requirement - 11 are Documented, Kept up to date, In use and Known to all affected parties. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that security policies and - operational procedures identified in Requirement 11 are managed in accordance with all - elements specified in this requirement. - - - id: 11.1.2 - title: Roles and responsibilities for performing activities in Requirement 11 are documented, - assigned, and understood. - levels: - - base - status: manual - notes: |- - Examine documentation and interview personnel to verify that day-to-day responsibilities - for performing all the activities in Requirement 11 are documented, assigned and - understood by the assigned personnel. - - - id: '11.2' - title: Wireless access points are identified and monitored, and unauthorized wireless access points - are addressed. - levels: - - base - status: manual - controls: - - id: 11.2.1 - title: Authorized and unauthorized wireless access points are managed. - levels: - - base - status: manual - - - id: 11.2.2 - title: An inventory of authorized wireless access points is maintained, including a documented - business justification. - description: |- - Unauthorized wireless access points are not mistaken for authorized wireless access - points. - levels: - - base - status: manual - - - id: '11.3' - title: External and internal vulnerabilities are regularly identified, prioritized, and addressed. - levels: - - base - status: manual - controls: - - id: 11.3.1 - title: Internal vulnerability scans are performed. - levels: - - base - status: manual - controls: - - id: 11.3.1.1 - title: All other applicable vulnerabilities (those not ranked as high-risk vulnerabilities - or critical vulnerabilities according to the entity's vulnerability risk rankings - defined at Requirement 6.3.1) are managed. - levels: - - base - status: manual - - - id: 11.3.1.2 - title: Internal vulnerability scans are performed via authenticated scanning. - levels: - - base - status: manual - - - id: 11.3.1.3 - title: Internal vulnerability scans are performed after any significant change. - levels: - - base - status: manual - - - id: 11.3.2 - title: External vulnerability scans are performed. - levels: - - base - status: manual - controls: - - id: 11.3.2.1 - title: External vulnerability scans are performed after any significant change. - levels: - - base - status: manual - - - id: '11.4' - title: External and internal penetration testing is regularly performed, and exploitable vulnerabilities - and security weaknesses are corrected. - levels: - - base - status: manual - controls: - - id: 11.4.1 - title: A penetration testing methodology is defined, documented, and implemented by the entity. - levels: - - base - status: manual - - - id: 11.4.2 - title: Internal penetration testing is performed. - levels: - - base - status: manual - - - id: 11.4.3 - title: External penetration testing is performed. - levels: - - base - status: manual - - - id: 11.4.4 - title: Exploitable vulnerabilities and security weaknesses found during penetration testing - are corrected - levels: - - base - status: manual - - - id: 11.4.5 - title: If segmentation is used to isolate the CDE from other networks, penetration tests - are performed on segmentation controls. - levels: - - base - status: manual - - - id: 11.4.6 - title: 'Additional requirement for service providers only: If segmentation is used to isolate - the CDE from other networks, penetration tests are performed on segmentation controls.' - levels: - - base - status: manual - - - id: 11.4.7 - title: 'Additional requirement for multi-tenant service providers only: Multi-tenant service - providers support their customers for external penetration testing per Requirement 11.4.3 - and 11.4.4.' - description: |- - Multi-tenant service providers support their customers' need for technical testing either - by providing access or evidence that comparable technical testing has been undertaken. - levels: - - base - status: manual - - - id: '11.5' - title: Network intrusions and unexpected file changes are detected and responded to. - levels: - - base - status: pending - controls: - - id: 11.5.1 - title: Intrusion-detection and/or intrusion-prevention techniques are used to detect and/or - prevent intrusions into the network. - levels: - - base - status: manual - controls: - - id: 11.5.1.1 - title: 'Additional requirement for service providers only: Intrusion-detection and/or - intrusion-prevention techniques detect, alert on/prevent, and address covert malware - communication channels.' - description: |- - Mechanisms are in place to detect and alert/prevent covert communications with - command-and-control systems. Alerts generated by these mechanisms are responded to by - personnel, or by automated means that ensure that such communications are blocked. This - requirement applies only when the entity being assessed is a service provider. This - requirement is a best practice until 31 March 2025, after which it will be required and - must be fully considered during a PCI DSS assessment. - levels: - - base - status: manual - notes: |- - The policy is not explicit about any specific solution. The solution might vary - depending on site policies. - - - id: 11.5.2 - title: A change-detection mechanism (for example, file integrity monitoring tools) is deployed. - levels: - - base - status: pending - - - id: '11.6' - title: Unauthorized changes on payment pages are detected and responded to. - levels: - - base - status: manual - controls: - - id: 11.6.1 - title: A change- and tamper-detection mechanism is deployed. - levels: - - base - status: manual - notes: |- - It depends on controls in application level, which varies based on site policies. - - - id: '12.1' - title: A comprehensive information security policy that governs and provides direction for protection - of the entity's information assets is known and current. - levels: - - base - status: pending - controls: - - id: 12.1.1 - title: An overall information security policy is established, published, maintained and disseminated - to all relevant personnel, as well as to relevant vendors and business partners. - levels: - - base - status: manual - - - id: 12.1.2 - title: The information security policy is updated and reviewed at least once every 12 months. - levels: - - base - status: manual - - - id: 12.1.3 - title: The security policy clearly defines information security roles and responsibilities - for all personnel, and all personnel are aware of and acknowledge their information security - responsibilities. - description: |- - Personnel understand their role in protecting the entity's cardholder data. - levels: - - base - status: manual - - - id: 12.1.4 - title: Responsibility for information security is formally assigned to a Chief Information - Security Officer or other information security knowledgeable member of executive management. - description: |- - A designated member of executive management is responsible for information security. - levels: - - base - status: manual - - - id: '12.2' - title: Acceptable use policies for end-user technologies are defined and implemented. - levels: - - base - status: manual - controls: - - id: 12.2.1 - title: Acceptable use policies for end-user technologies are documented and implemented. - levels: - - base - status: manual - - - id: '12.3' - title: Risks to the cardholder data environment are formally identified, evaluated, and managed. - levels: - - base - status: manual - controls: - - id: 12.3.1 - title: For each PCI DSS requirement that specifies completion of a targeted risk analysis, - the analysis is documented. - levels: - - base - status: manual - - - id: 12.3.2 - title: A targeted risk analysis is performed for each PCI DSS requirement that the entity - meets with the customized approach - levels: - - base - status: manual - - - id: 12.3.3 - title: Cryptographic cipher suites and protocols in use are documented and reviewed at least - once every 12 months. - levels: - - base - status: manual - notes: |- - Related to requirement 2.2.7. - - - id: 12.3.4 - title: Hardware and software technologies in use are reviewed at least once every 12 months. - levels: - - base - status: manual - notes: |- - The technical requirement related to this is 6.3.3. - - - id: '12.4' - title: PCI DSS compliance is managed. - levels: - - base - status: manual - controls: - - id: 12.4.1 - title: 'Additional requirement for service providers only: Responsibility is established - by executive management for the protection of cardholder data and a PCI DSS compliance - program.' - levels: - - base - status: manual - - - id: 12.4.2 - title: 'Additional requirement for service providers only: Reviews are performed at least - once every three months to confirm that personnel are performing their tasks in accordance - with all security policies and operational procedures.' - description: |- - Reviews are performed by personnel other than those responsible for performing the given - task. - levels: - - base - status: manual - controls: - - id: 12.4.2.1 - title: 'Additional requirement for service providers only: Reviews conducted in accordance - with Requirement 12.4.2 are documented.' - levels: - - base - status: manual - - - id: '12.5' - title: PCI DSS scope is documented and validated. - levels: - - base - status: manual - controls: - - id: 12.5.1 - title: An inventory of system components that are in scope for PCI DSS, including a description - of function/use, is maintained and kept current. - description: |- - All system components in scope for PCI DSS are identified and known. - levels: - - base - status: manual - - - id: 12.5.2 - title: PCI DSS scope is documented and confirmed by the entity at least once every 12 months - and upon significant change to the in-scope environment. - levels: - - base - status: manual - controls: - - id: 12.5.2.1 - title: 'Additional requirement for service providers only: PCI DSS scope is documented - and confirmed by the entity at least once every six months and upon significant - change to the in-scope environment. At a minimum, the scoping validation includes - all the elements specified in Requirement 12.5.2.' - description: |- - The accuracy of PCI DSS scope is verified to be continuously accurate by comprehensive - analysis and appropriate technical measures. This requirement applies only when the - entity being assessed is a service provider. This requirement is a best practice until - 31 March 2025, after which it will be required and must be fully considered during a - PCI DSS assessment. - levels: - - base - status: manual - - - id: 12.5.3 - title: 'Additional requirement for service providers only: Significant changes to organizational - structure result in a documented (internal) review of the impact to PCI DSS scope and - applicability of controls, with results communicated to executive management.' - description: |- - PCI DSS scope is confirmed after significant organizational change. This requirement - applies only when the entity being assessed is a service provider. This requirement is a - best practice until 31 March 2025, after which it will be required and must be fully - considered during a PCI DSS assessment. - levels: - - base - status: manual - - - id: '12.6' - title: Security awareness education is an ongoing activity. - levels: - - base - status: manual - controls: - - id: 12.6.1 - title: A formal security awareness program is implemented to make all personnel aware of - the entity's information security policy and procedures, and their role in protecting - the cardholder data. - description: |- - Personnel are knowledgeable about the threat landscape, their responsibility for the - operation of relevant security controls, and are able to access assistance and guidance - when required. - levels: - - base - status: manual - - - id: 12.6.2 - title: The security awareness program is updated and reviewed at least once every 12 months. - levels: - - base - status: manual - - - id: 12.6.3 - title: Personnel receive security awareness training upon hire and at least once every 12 - months via multiple methods of communication. - levels: - - base - status: manual - controls: - - id: 12.6.3.1 - title: Security awareness training includes awareness of threats and vulnerabilities - that could impact the security of the CDE. - levels: - - base - status: manual - - - id: 12.6.3.2 - title: Security awareness training includes awareness about the acceptable use of end-user - technologies in accordance with Requirement 12.2.1. - description: |- - Personnel are knowledgeable about their responsibility for the security and operation of - end-user technologies and are able to access assistance and guidance when required. This - requirement is a best practice until 31 March 2025, after which it will be required and - must be fully considered during a PCI DSS assessment. - levels: - - base - status: manual - - - id: '12.7' - title: Personnel are screened to reduce risks from insider threats. - levels: - - base - status: manual - controls: - - id: 12.7.1 - title: Potential personnel who will have access to the CDE are screened, within the constraints - of local laws, prior to hire to minimize the risk of attacks from internal sources. - description: |- - The risk related to allowing new members of staff access to the CDE is understood and - managed. For those potential personnel to be hired for positions such as store cashiers, - who only have access to one card number at a time when facilitating a transaction, this - requirement is a recommendation only. - levels: - - base - status: manual - - - id: '12.8' - title: Risk to information assets associated with third-party service provider (TPSP) relationships - is managed. - levels: - - base - status: manual - controls: - - id: 12.8.1 - title: A list of all third-party service providers (TPSPs) with which account data is shared - or that could affect the security of account data is maintained, including a description - for each of the services provided. - description: |- - Records are maintained of TPSPs and the services provided. The use of a PCI DSS compliant - TPSP does not make an entity PCI DSS compliant, nor does it remove the entit's - responsibility for its own PCI DSS compliance. - levels: - - base - status: manual - - - id: 12.8.2 - title: Written agreements with TPSPs are maintained - levels: - - base - status: manual - - - id: 12.8.3 - title: An established process is implemented for engaging TPSPs, including proper due diligence - prior to engagement. - description: |- - The capability, intent, and resources of a prospective TPSP to adequately protect account - data are assessed before the TPSP is engaged. - levels: - - base - status: manual - - - id: 12.8.4 - title: A program is implemented to monitor TPSPs' PCI DSS compliance status at least once - every 12 months. - description: |- - The PCI DSS compliance status of TPSPs is verified periodically. Where an entity has an - agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity (for - example, via a firewall service), the entity must work with the TPSP to make sure the - applicable PCI DSS requirements are met. If the TPSP does not meet those applicable - PCI DSS requirements, then those requirements are also "not in place" for the entity. - levels: - - base - status: manual - - - id: 12.8.5 - title: Information is maintained about which PCI DSS requirements are managed by each TPSP, - which are managed by the entity, and any that are shared between the TPSP and the entity. - description: |- - Records detailing the PCI DSS requirements and related system components for which each - TPSP is solely or jointly responsible, are maintained and reviewed periodically. - levels: - - base - status: manual - - - id: '12.9' - title: Third-party service providers (TPSPs) support their customers' PCI DSS compliance. - levels: - - base - status: manual - controls: - - id: 12.9.1 - title: |- - Additional requirement for service providers only: TPSPs provide written agreements to - customers that include acknowledgments that TPSPs are responsible for the security of - account data the TPSP possesses or otherwise stores, processes, or transmits on behalf of - the customer, or to the extent that the TPSP could impact the security of the customer's - cardholder data and/or sensitive authentication data. - description: |- - TPSPs formally acknowledge their security responsibilities to their customers. This - requirement applies only when the entity being assessed is a service provider. The exact - wording of an agreement will depend on the details of the service being provided, and the - responsibilities assigned to each party. The agreement does not have to include the exact - wording provided in this requirement. - levels: - - base - status: manual - - - id: 12.9.2 - title: |- - Additional requirement for service providers only: TPSPs support their customers' requests - for information to meet Requirements 12.8.4 and 12.8.5. - levels: - - base - status: manual - - - id: '12.10' - title: Suspected and confirmed security incidents that could impact the CDE are responded to immediately. - levels: - - base - status: manual - controls: - - id: 12.10.1 - title: An incident response plan exists and is ready to be activated in the event of a suspected - or confirmed security incident. - levels: - - base - status: manual - - - id: 12.10.2 - title: At least once every 12 months, the security incident response plan is reviewed, updated, - and tested. - levels: - - base - status: manual - - - id: 12.10.3 - title: Specific personnel are designated to be available on a 24/7 basis to respond to suspected - or confirmed security incidents. - description: |- - Incidents are responded to immediately where appropriate. - levels: - - base - status: manual - - - id: 12.10.4 - title: Personnel responsible for responding to suspected and confirmed security incidents - are appropriately and periodically trained on their incident response responsibilities. - description: |- - Personnel are knowledgeable about their role and responsibilities in incident response and - are able to access assistance and guidance when required. - levels: - - base - status: manual - controls: - - id: 12.10.4.1 - title: The frequency of periodic training for incident response personnel is defined - in the entity's targeted risk analysis, which is performed according to all elements - specified in Requirement 12.3.1. - description: |- - Incident response personnel are trained at a frequency that addresses the entity's risk. - This requirement is a best practice until 31 March 2025, after which it will be required - and must be fully considered during a PCI DSS assessment. - levels: - - base - status: manual - - - id: 12.10.5 - title: The security incident response plan includes monitoring and responding to alerts from - security monitoring systems. - levels: - - base - status: manual - - - id: 12.10.6 - title: The security incident response plan is modified and evolved according to lessons learned - and to incorporate industry developments. - description: |- - The effectiveness and accuracy of the incident response plan is reviewed and updated after - each invocation. - levels: - - base - status: manual - - - id: 12.10.7 - title: Incident response procedures are in place, to be initiated upon the detection of stored - PAN anywhere it is not expected. - levels: - - base - status: manual - - - id: A1.1 - title: Multi-tenant service providers protect and separate all customer environments and data. - levels: - - base - status: manual - controls: - - id: A1.1.1 - title: Logical separation is implemented. - description: |- - - The provider cannot access its customers' environments without authorization. - - Customers cannot access the provider's environment without authorization. - levels: - - base - status: manual - - - id: A1.1.2 - title: Controls are implemented such that each customer only has permission to access its - own cardholder data and CDE. - description: |- - Customers cannot access other customers' environments. - levels: - - base - status: manual - - - id: A1.1.3 - title: Controls are implemented such that each customer can only access resources allocated - to them. - description: |- - Customers cannot impact resources allocated to other customers. - levels: - - base - status: manual - - - id: A1.1.4 - title: The effectiveness of logical separation controls used to separate customer environments - is confirmed at least once every six months via penetration testing. - description: |- - Segmentation of customer environments from other environments is periodically validated to - be effective. The testing of adequate separation between customers in a multi-tenant - service provider environment is in addition to the penetration tests specified in - Requirement 11.4.6. This requirement is a best practice until 31 March 2025, after which - it will be required and must be fully considered during a PCI DSS assessment. - levels: - - base - status: manual - - - id: A1.2 - title: Multi-tenant service providers facilitate logging and incident response for all customers. - levels: - - base - status: manual - controls: - - id: A1.2.1 - title: Audit log capability is enabled for each customer's environment that is consistent - with PCI DSS Requirement 10. - levels: - - base - status: manual - - - id: A1.2.2 - title: Processes or mechanisms are implemented to support and/or facilitate prompt forensic - investigations in the event of a suspected or confirmed security incident for any customer. - description: |- - Forensic investigation is readily available to all customers in the event of a suspected - or confirmed security incident. - levels: - - base - status: manual - - - id: A1.2.3 - title: Processes or mechanisms are implemented for reporting and addressing suspected or - confirmed security incidents and vulnerabilities. - levels: - - base - status: manual - - - id: A2.1 - title: POI terminals using SSL and/or early TLS are confirmed as not susceptible to known SSL/TLS - exploits. - description: |- - Appendix A2: Additional PCI DSS Requirements for Entities Using SSL/Early TLS for - Card-Present POS POI Terminal Connections. - levels: - - base - status: manual - controls: - - id: A2.1.1 - title: Where POS POI terminals at the merchant or payment acceptance location use SSL and/or - early TLS, the entity confirms the devices are not susceptible to any known exploits - for those protocols. - levels: - - base - status: manual - notes: |- - Related to requirements 2.2.7 and 3.5.1.1. - Service level settings for web servers such as Apache and NGINX should also be checked. - - - id: A2.1.2 - title: 'Additional requirement for service providers only: All service providers with existing - connection points to POS POI terminals that use SSL and/or early TLS as defined in A2.1 - have a formal Risk Mitigation and Migration Plan in place.' - levels: - - base - status: manual - - - id: A2.1.3 - title: 'Additional requirement for service providers only: All service providers provide - a secure service offering.' - description: |- - This requirement is not eligible for the customized approach. This requirement applies - only when the entity being assessed is a service provider. - levels: - - base - status: manual - - - id: A3.1 - title: A PCI DSS compliance program is implemented. - description: |- - Appendix A3: Designated Entities Supplemental Validation (DESV) - levels: - - base - status: manual - controls: - - id: A3.1.1 - title: Responsibility is established by executive management for the protection of account - data and a PCI DSS compliance program. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Requirement 12 - - - id: A3.1.2 - title: A formal PCI DSS compliance program is in place. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Requirements 1-12 - - - id: A3.1.3 - title: PCI DSS compliance roles and responsibilities are specifically defined and formally - assigned to one or more personnel. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Requirement 12 - - - id: A3.1.4 - title: Up-to-date PCI DSS and/or information security training is provided at least once - every 12 months to personnel with PCI DSS compliance responsibilities (as identified - in A3.1.3). - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Requirement 12 - - - id: A3.2 - title: PCI DSS scope is documented and validated. - levels: - - base - status: manual - controls: - - id: A3.2.1 - title: PCI DSS scope is documented and confirmed for accuracy at least once every three months - and upon significant changes to the in-scope environment. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Scope of PCI DSS Requirements, Requirement 12. - - - id: A3.2.2 - title: PCI DSS scope impact for all changes to systems or networks is determined, including - additions of new systems and new network connections. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Scope of PCI DSS Requirements; Requirements 1-12 - controls: - - id: A3.2.2.1 - title: Upon completion of a change, all relevant PCI DSS requirements are confirmed - to be implemented on all new or changed systems and networks, and documentation - is updated as applicable. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Scope of PCI DSS Requirements; Requirements 1-12 - - - id: A3.2.3 - title: Changes to organizational structure result in a formal (internal) review of the impact - to PCI DSS scope and applicability of controls. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Requirement 12 - - - id: A3.2.4 - title: If segmentation is used, PCI DSS scope is confirmed. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Requirement 11 - - - id: A3.2.5 - title: A data-discovery methodology is implemented. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Scope of PCI DSS Requirements. - controls: - - id: A3.2.5.1 - title: Data discovery methods are confirmed. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Scope of PCI DSS Requirements. - - - id: A3.2.5.2 - title: Response procedures are implemented to be initiated upon the detection of cleartext - PAN outside the CDE. - levels: - - base - status: manual - - - id: A3.2.6 - title: Mechanisms are implemented for detecting and preventing cleartext PAN from leaving - the CDE via an unauthorized channel, method, or process. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Scope of PCI DSS Requirements, Requirement 12 - controls: - - id: A3.2.6.1 - title: Response procedures are implemented to be initiated upon the detection of attempts - to remove cleartext PAN from the CDE via an unauthorized channel, method, or process. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Requirement 12 - - - id: A3.3 - title: PCI DSS is incorporated into business-as-usual (BAU) activities. - levels: - - base - status: manual - controls: - - id: A3.3.1 - title: Failures of critical security control systems are detected, alerted, and addressed - promptly. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Requirement 12 - controls: - - id: A3.3.1.2 - title: Failures of any critical security control systems are responded to promptly. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Requirements 1-12 - If you noticed, this requirement should be A3.3.1.1 instead of A3.3.1.2 but it was kept - this way to be aligned to the policy. - - - id: A3.3.2 - title: Hardware and software technologies are reviewed at least once every 12 months to confirm - whether they continue to meet the organization's PCI DSS requirements. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Requirements 2, 6, 12. - - - id: A3.3.3 - title: Reviews are performed at least once every three months to verify BAU activities are - being followed. - description: |- - Reviews are performed by personnel assigned to the PCI DSS compliance program (as - identified in A3.1.3). - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Requirements 1-12. - - - id: A3.4 - title: Logical access to the cardholder data environment is controlled and managed. - levels: - - base - status: manual - controls: - - id: A3.4.1 - title: User accounts and access privileges to in-scope system components are reviewed at - least once every six months to ensure user accounts and access privileges remain appropriate - based on job function, and that all access is authorized. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Requirement 7. - - - id: A3.5 - title: Suspicious events are identified and responded to. - levels: - - base - status: manual - controls: - - id: A3.5.1 - title: A methodology is implemented for the prompt identification of attack patterns and - undesirable behavior across systems. - levels: - - base - status: manual - notes: |- - PCI DSS Reference: Requirement 10, 12. diff --git a/products/sle16/product.yml b/products/sle16/product.yml index e1bcd9d0328..c6550fdbd65 100644 --- a/products/sle16/product.yml +++ b/products/sle16/product.yml @@ -35,8 +35,6 @@ platform_package_overrides: reference_uris: suse-base-sle16: 'not_publicly_available' - pcidss4_sle16: 'https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf' - anssi_sle16: 'https://cyber.gouv.fr/sites/default/files/document/linux_configuration-en-v2.pdf' dconf_gdm_dir: "gdm.d" diff --git a/products/sle16/profiles/anssi_bp28_minimal.profile b/products/sle16/profiles/anssi_bp28_minimal.profile index 03ed2faea65..6c5f7e9882d 100644 --- a/products/sle16/profiles/anssi_bp28_minimal.profile +++ b/products/sle16/profiles/anssi_bp28_minimal.profile @@ -25,4 +25,4 @@ description: |- Manual review is required to assess if the installed services are minimal. selections: - - anssi_sle16:all:minimal + - base_sle16:all:anssi_minimal diff --git a/products/sle16/profiles/pci-dss-4.profile b/products/sle16/profiles/pci-dss-4.profile index 3b1a418c6b2..68401528a42 100644 --- a/products/sle16/profiles/pci-dss-4.profile +++ b/products/sle16/profiles/pci-dss-4.profile @@ -14,4 +14,4 @@ description: |- Ensures PCI-DSS v4 security configuration settings are applied. selections: - - pcidss_4_sle16:all:base + - base_sle16:all:pcidss4 From c3699e90b15150d08b1f14e3e0fbec9b2750231a Mon Sep 17 00:00:00 2001 From: teacup-on-rockingchair <315160+teacup-on-rockingchair@users.noreply.github.com> Date: Wed, 8 Oct 2025 15:48:12 +0300 Subject: [PATCH 5/9] Fix typo --- controls/base_sle16.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/controls/base_sle16.yml b/controls/base_sle16.yml index 32ee529b81d..b9ce21648aa 100644 --- a/controls/base_sle16.yml +++ b/controls/base_sle16.yml @@ -40,7 +40,7 @@ controls: status: automated - id: SLES-16-16016030 - title: Ensure All Files Are Owned by a Use + title: Ensure All Files Are Owned by a User levels: - anssi_minimal rules: From cba17cba30a2a850f678525e11763f4932dd2dc3 Mon Sep 17 00:00:00 2001 From: teacup-on-rockingchair <315160+teacup-on-rockingchair@users.noreply.github.com> Date: Wed, 8 Oct 2025 15:49:27 +0300 Subject: [PATCH 6/9] Extend definition of installed_OS_is_vendor_supported with sle16 --- .../installed_OS_is_vendor_supported/oval/shared.xml | 1 + .../installed_OS_is_vendor_supported/rule.yml | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/linux_os/guide/system/software/integrity/certified-vendor/installed_OS_is_vendor_supported/oval/shared.xml b/linux_os/guide/system/software/integrity/certified-vendor/installed_OS_is_vendor_supported/oval/shared.xml index 98cd1fdfbb0..a028877c12a 100644 --- a/linux_os/guide/system/software/integrity/certified-vendor/installed_OS_is_vendor_supported/oval/shared.xml +++ b/linux_os/guide/system/software/integrity/certified-vendor/installed_OS_is_vendor_supported/oval/shared.xml @@ -13,6 +13,7 @@ + diff --git a/linux_os/guide/system/software/integrity/certified-vendor/installed_OS_is_vendor_supported/rule.yml b/linux_os/guide/system/software/integrity/certified-vendor/installed_OS_is_vendor_supported/rule.yml index 4858543fdf9..1cd04cfd2f6 100644 --- a/linux_os/guide/system/software/integrity/certified-vendor/installed_OS_is_vendor_supported/rule.yml +++ b/linux_os/guide/system/software/integrity/certified-vendor/installed_OS_is_vendor_supported/rule.yml @@ -8,7 +8,7 @@ description: |- {{% if 'ol' in product %}} Oracle Linux is supported by Oracle Corporation. As the Oracle Linux vendor, Oracle Corporation is responsible for providing security patches. -{{% elif product in ["sle12", "sle15", "slmicro5", "slmicro6"] %}} +{{% elif product in ["sle12", "sle15", "sle16", "slmicro5", "slmicro6"] %}} SUSE Linux Enterprise is supported by SUSE. As the SUSE Linux Enterprise vendor, SUSE is responsible for providing security patches. {{% elif 'almalinux' in product %}} @@ -39,7 +39,7 @@ identifiers: cce@sle12: CCE-83001-8 cce@sle15: CCE-83260-0 cce@slmicro5: CCE-93601-3 - cce@slmicro6: CCE-95035-2 + cce@slmicro6: CCE-95035-2 references: cis-csc: 18,20,4 @@ -63,7 +63,7 @@ ocil: |- 
$ grep -i "red hat" /etc/redhat-release
{{% elif 'ol' in product %}} 
$ grep -i "oracle" /etc/oracle-release
-{{% elif product in ["sle12", "sle15", "slmicro5", "slmicro6"] %}} +{{% elif product in ["sle12", "sle15", "sle16", "slmicro5", "slmicro6"] %}} 
$ grep -i "suse" /etc/os-release
{{% elif 'ubuntu' in product %}} 
$ grep DISTRIB_DESCRIPTION /etc/lsb-release
From 4ba06ceb69b3c80bca146d45438f787cc7f8af62 Mon Sep 17 00:00:00 2001 From: teacup-on-rockingchair <315160+teacup-on-rockingchair@users.noreply.github.com> Date: Wed, 8 Oct 2025 16:13:55 +0300 Subject: [PATCH 7/9] Fix check for installed OS SLE16 --- shared/checks/oval/installed_OS_is_sle16.xml | 37 +++++++++----------- 1 file changed, 16 insertions(+), 21 deletions(-) diff --git a/shared/checks/oval/installed_OS_is_sle16.xml b/shared/checks/oval/installed_OS_is_sle16.xml index 282e64eb0c8..c8a80169785 100644 --- a/shared/checks/oval/installed_OS_is_sle16.xml +++ b/shared/checks/oval/installed_OS_is_sle16.xml @@ -6,20 +6,16 @@ multi_platform_all - - - The operating system installed on the system is - SUSE Linux Enterprise 15. + + The operating system installed on the system is SUSE Linux Enterprise Server 16. + test_ref="test_sle16_unix_family" /> - + @@ -33,18 +29,7 @@ - - - - - - ^16.*$ - - - sled-release - - - + @@ -52,7 +37,7 @@ ^16.*$ - sles-release + SLES-release @@ -66,4 +51,14 @@ SLES_SAP-release + + + + + + ^16.*$ + + + sle-ha-release + From bafded047c36e149a57b81260f85b033db2cdd83 Mon Sep 17 00:00:00 2001 From: teacup-on-rockingchair <315160+teacup-on-rockingchair@users.noreply.github.com> Date: Wed, 8 Oct 2025 16:15:20 +0300 Subject: [PATCH 8/9] Make product work with installed_OS_is_sle16 check --- products/sle16/product.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/products/sle16/product.yml b/products/sle16/product.yml index c6550fdbd65..326e1138e52 100644 --- a/products/sle16/product.yml +++ b/products/sle16/product.yml @@ -22,8 +22,8 @@ aide_bin_path: "/usr/bin/aide" cpes_root: "../../shared/applicability" cpes: - sle16: - name: "cpe:/o:suse:sles:16.0" - title: "SUSE Linux Enterprise Server 16.0" + name: "cpe:/o:suse:linux_enterprise_server:16" + title: "SUSE Linux Enterprise Server 16" check_id: installed_OS_is_sle16 platform_package_overrides: From 852ddb9b7ad9dd53a95236236c2aac7b8f03d95b Mon Sep 17 00:00:00 2001 From: teacup-on-rockingchair <315160+teacup-on-rockingchair@users.noreply.github.com> Date: Wed, 8 Oct 2025 16:18:26 +0300 Subject: [PATCH 9/9] Mark controls and profiles as DRAFT for product sle16 --- controls/base_sle16.yml | 2 +- products/sle16/profiles/anssi_bp28_minimal.profile | 2 +- products/sle16/profiles/base.profile | 2 +- products/sle16/profiles/pci-dss-4.profile | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/controls/base_sle16.yml b/controls/base_sle16.yml index b9ce21648aa..88b54bcff2a 100644 --- a/controls/base_sle16.yml +++ b/controls/base_sle16.yml @@ -1,6 +1,6 @@ --- policy: Basis System Security Profile for SUSE Linux Enterprise 16 -title: asis System Security Profile SUSE Linux Enterprise 16 +title: DRAFT Basis System Security Profile SUSE Linux Enterprise 16 id: base_sle16 version: '1.0' source: not_publicly_available diff --git a/products/sle16/profiles/anssi_bp28_minimal.profile b/products/sle16/profiles/anssi_bp28_minimal.profile index 6c5f7e9882d..c6a90af08e0 100644 --- a/products/sle16/profiles/anssi_bp28_minimal.profile +++ b/products/sle16/profiles/anssi_bp28_minimal.profile @@ -7,7 +7,7 @@ metadata: - rumch-se - teacup-on-rockingchair -title: 'ANSSI-BP-028 (minimal)' +title: 'DRAFT ANSSI-BP-028 (minimal)' description: |- This profile contains configurations that align to ANSSI-BP-028 v2.0 at the minimal hardening level. diff --git a/products/sle16/profiles/base.profile b/products/sle16/profiles/base.profile index b1b0d2f46d3..1d6c2bcfd35 100644 --- a/products/sle16/profiles/base.profile +++ b/products/sle16/profiles/base.profile @@ -9,7 +9,7 @@ metadata: reference: not_publicly_available -title: 'General System Security Profile for SUSE Linux Enterprise (SLES) 16' +title: 'DRAFT General System Security Profile for SUSE Linux Enterprise (SLES) 16' description: |- This profile contains configuration checks that align to the diff --git a/products/sle16/profiles/pci-dss-4.profile b/products/sle16/profiles/pci-dss-4.profile index 68401528a42..60342f5fab3 100644 --- a/products/sle16/profiles/pci-dss-4.profile +++ b/products/sle16/profiles/pci-dss-4.profile @@ -8,7 +8,7 @@ metadata: reference: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf -title: 'PCI-DSS v4 Control Baseline for SUSE Linux Enterprise 16' +title: 'DRAFT PCI-DSS v4 Control Baseline for SUSE Linux Enterprise 16' description: |- Ensures PCI-DSS v4 security configuration settings are applied.