Security
Headlines
HeadlinesLatestCVEs

Headline

ANSSI-BP-028 security recommendations updated to version 2.0

ANSSI, the National Cybersecurity Agency of France (Agence nationale de la sécurité des systèmes d’information), provides a configuration guide for GNU/Linux systems. It’s identified as ANSSI-BP-028 (formerly known as ANSSI DAT NT-028). Recently, ANSSI published an update of its ANSSI-BP-028 configuration recommendations. In this post, I review what has changed from version 1.2 to 2.0, and what it might mean for you as a Red Hat Enterprise Linux (RHEL) user. Most importantly, I also illustrate how to verify compliance of your systems with this updated Security Content Automation Protocol (S

Red Hat Blog
#mac#linux#red_hat#git#pdf#ibm

ANSSI, the National Cybersecurity Agency of France (Agence nationale de la sécurité des systèmes d’information), provides a configuration guide for GNU/Linux systems. It’s identified as ANSSI-BP-028 (formerly known as ANSSI DAT NT-028). Recently, ANSSI published an update of its ANSSI-BP-028 configuration recommendations. In this post, I review what has changed from version 1.2 to 2.0, and what it might mean for you as a Red Hat Enterprise Linux (RHEL) user. Most importantly, I also illustrate how to verify compliance of your systems with this updated Security Content Automation Protocol (SCAP) profile.

The first version of BP-028 was published in 2015. Red Hat introduced Security Content Automation Protocol (SCAP) content covering this version of recommendations in RHEL 7.9.7 and RHEL 8.5. After a series of minor changes, a major update of the guide, marked as version 2.0, was released in October 2022. We have concluded updating RHEL ANSSI SCAP profiles to align them with the latest version of the security recommendations.

****ANSSI GNU/Linux configuration guide****

The guide sets out a number of security measures that should be implemented to enhance the confidentiality, integrity, and availability of GNU/Linux information systems. It focuses on generally useful system configuration recommendations based on security principles and common sense practices that should be applied when deploying a system.

These recommendations are not specific to any use case, but are instead intentionally broad in scope. Evaluate them based on the purpose of the system being deployed and the ecosystem it’s going to integrate into.

The guide defines 4 levels of hardening; Minimal, Intermediary, Enhanced, and High.

Some points covered by the guide:

  • General security and hardening principles
  • Hardware configuration
  • Securing the boot chain
  • Kernel configuration
  • Privilege and access management
  • Configuration of system services
  • Partitioning solutions

The guide in English can be downloaded from https://cyber.gouv.fr/sites/default/files/document/linux_configuration-en-v2.pdf

****What changed between ANSSI-BP-028 1.2 and 2.0?****

The guide was restructured to better organize the principles and hardening recommendations, strongly emphasizing the principle you should have in mind when evaluating the recommendations.

In version 2.0, the levels (Minimal, Intermediary, Enhanced, and High) remained the same, but the definitions have been updated. Most notably, the implementation of the Intermediary hardening level is now strongly recommended once the Minimal level is applied successfully. And the recommendations were updated to account for new technologies and threats, the next section mentions some of the recommendations that changed. For the full list of changes between versions, see appendix C of the ANSSI BP028 version 2.0.

****Notable recommendations that changed hardening level****

These recommendations have been moved from Intermediary to Enhanced:

  • Implementation of logging systems
  • Hardening of services and components
  • Partitioning of services
  • Creation of a dedicated group for sudo users

Other recommendations’ hardening levels have gone down:

  • Installation of strictly necessary packages dropped from Intermediary to Minimal
  • Disablement of unused user accounts dropped from Enhanced to Minimal
  • Configuration of Sticky bit on world writable directories dropped from Intermediary to Minimal
  • Configuration of a boot loader password dropped from Enhanced to Intermediary
  • Loading of Yama module dropped from Enhanced to Intermediary
  • Use of Mandatory Access Control (MAC) dropped from High to Enhanced
  • Activation of IOMMU dropped from High to Enhanced

New recommendations have been added:

  • UEFI, secure boot and protection of kernel command lines
  • Configuration of memory options during boot. For example, Page Table Isolation and Speculative Store Bypass
  • Kernel compilation options like CONFIG_FORTIFY_SOURCE, CONFIG_MODULES, and CONFIG_SECCOMP
  • Restriction for files and directories without an associated owner

****Automating compliance with ANSSI-BP-028 2.0****

Like the ANSSI -BP-028 policy itself, Red Hat’s SCAP content has been significantly updated.

Here are some interesting statistics collected through the tooling available in the upstream ComplianceAsCode/content project repository. First, let’s look at the state of the ANSSI BP028 High profile, which naturally corresponds with the High level of the underlying security policy. We can compare its coverage by our SCAP content between the last update of version 1.2 and the current state covering version 2.0.

Before we delve into exact numbers, let us define what the “coverage” of a control means in the context of the ComplianceAsCode/content project. When reading a security policy and expressing it with SCAP rules, we generally separate requirements (controls) into four main categories:

  • Fully covered: A control is assessed and fully covered by SCAP rules where possible. This can also mean that the whole requirement or its part cannot be automated for technical reasons. In this case, we try to achieve maximum possible coverage of the control
  • Partially covered: Part of the requirement is assessed and already automated with SCAP, but there’s still some part of the requirement that requires analysis
  • Not assessed: The requirement is not assessed yet
  • Not applicable: The requirement is not applicable with regards to a product or a technology. For example, there is a requirement specific to 32-bit Linux kernels (x86 architecture), but Red Hat Enterprise Linux 9 supports x86_64, Power, IBM Z, and ARM. In this case, the whole requirement is marked as not applicable

The profile corresponding to the security policy version 1.2 for RHEL 9 was composed of 204 rules. This version of security policy was composed of 69 controls. The SCAP content fully covered 27 controls (39.13%) and partially covered 14 more (additional 20.29%). The remaining 28 controls were not assessed.

The current coverage of the ANSSI-BP-028 High profile version 2.0 for RHEL 9 is much better. The updated profile now contains 432 rules. The policy defines 80 controls. It was decided that 4 controls are not applicable for Red Hat Enterprise Linux systems. All remaining 76 controls are fully assessed and where possible also automated.

You can read more about automating compliance with ANSSI security requirements in appendix B of the guide.

****How to confirm that you are using the latest compliance automation****

Anyone tasked with the security of an IT environment can appreciate ANSSI’s efforts in clarifying the configuration recommendations and how they can be applied with automation tools in mind. Now you know the key takeaways from the update to ANSSI-BP-028 version 2.0, and its implications for securing your digital assets.

If you’re using Red Hat Insights or Satellite, then the compliance automation content is updated automatically for you. If your source of the SCAP artifact is the scap-security-package, then update to the latest 0.1.73 version.

Red Hat Blog: Latest News

Automatically acquire and renew certificates using mod_md and Automated Certificate Management Environment (ACME) in Identity Management (IdM)