Who doesn’t have their RGS certification?
In its latest retour d’expérience — a lessons-learned report — CERT-FR makes no direct comment on the matter. It nevertheless recalls that the process is mandatory for all public entities…
In fact, far from a true retex, what we have here is more of a list of recommendations accompanied by a few field observations. Topic: data breaches in the context of web applications.
The right combinations for disk encryption
CERT-FR cites the case of a vendor providing a solution for the remote transmission of medical data. As a result of an error during a maintenance intervention on a server, patient data were exposed on the sites the company had designed.
This example introduces a series of recommendations regarding data governance. CERT-FR advises, among other things, to protect storage media against extraction, even after use. The proposed means: systematic encryption with a key managed in hardware cryptographic components or via a key server. On Linux, one will typically pair Clevis with LUKS to bind the disk to the TPM, with a Tang server for remote unlock. On Windows, one will combine BitLocker with the Network Unlock service.
Think about header-based restrictions
In several incidents, CERT-FR noted the use of public IP addresses inside application infrastructures. There is no risk as long as the routings remain strictly segmented. But this complicates the interpretation of observed traffic, in addition to aggravating any misconfiguration of routing protocols and causing issues in certain security products that rely on inferences based on the IP subnets in use. Therefore, one should respect the RFC 1918 address space, which defines the IPv4 ranges reserved for private networks.
To limit application exposure, CERT-FR also invites to prefer identifying services by host name rather than by path. For example, favor https://admin.example.com over https://www.example.com/admin. Rationale: this makes it easier to apply different filtering policies while minimizing both cross-exposure on URL-routed services and implicit data sharing within the browser.
Another recommendation: configure applications that handle HTTP traffic to include in headers evidence of the origin of the connection. One will use, for instance, the X-Forwarded-For field. In parallel, include the IP address in the logs of firewalls, VPNs and perimeter devices, for example with the remoteip field.
At the application level, one can supplement IP-based filtering with header-based restrictions. Many attackers leave telltale values, explains CERT-FR. And give the example of a user account performing a valid login with a user-agent characteristic of a Python library. This is an indicator that the credentials are potentially compromised.
Monitor the DBSC standard for protecting session cookies
No field feedback per se about authentication. But a reminder: the W3C is working on the DBSC (Device Bound Session Credentials) standard, aimed at combating cookie theft and session hijacking. In broad terms, the browser generates a key pair stored in the TPM and regularly proves possession of the private key to renew cookies in the background. The cookies, ephemeral, cannot be refreshed on another machine unless that private key can be extracted.
For now, among the major browsers, only Chrome handles DBSC. Adoption of the standard requires a slight evolution of the negotiation in applications (handling the Secure Station Registration choreography). In modern web architectures, this is often done at the IDP level.
Don’t forget the zero-trust option
Calling for moving beyond the simple login / password pair, CERT-FR proposes, among other measures, transitional steps for internal users of applications. It starts from the premise that all manually entered authentication factors are vulnerable to phishing. Proposed solution: deploy hardware-backed keys and TLS certificates in the browsers of protected client machines. A cryptographically strong approach, but one that does not resist infostealers capable of extracting the certificates and their private keys not safeguarded by hardware security modules.
The traditional measures to protect session cookies (httpOnly and secure flags, strict TLS encryption) do not protect against infostealers either, adds CERT-FR. Hence the reference to DBSC. Even while waiting for the standard to spread, one can leverage the session expiration delay, coupled with measures that facilitate quick re-authentication, such as passkeys. Or choose the zero-trust option: “bind the session to its usage conditions,” to use CERT-FR’s words. And remember mobile users, whose IP address can change frequently.
Adopt UNIX logging with millisecond precision
CERT-FR notes that it frequently encounters UNIX log configurations that store timestamps without date and with second-level precision. It recommends adopting a Syslog-compliant streaming format (RFC 5424) and millisecond precision. It also advocates having a common time source across all equipment that emits logs and events, and harmonizing the time zone of the records (GMT recommended).
Other common configurations: application logs that lose the information about the source IP address. Connections then appear to originate from the front-end equipment. On these devices, one should use the HTTP headers likewise as at the application level (X-Forwarded-For, Forwarded, X-Real-IP).
From network interfaces to administration services, disable what isn’t used
CERT-FR explains that it frequently observes services intended for local use but configured to listen on all the system’s network interfaces. It recommends avoiding this practice. In addition, disable unused administration and monitoring services within applications and in the system’s foundational layer. For example, SNMP, still active on many devices.
Regarding blocking Internet traffic to administration consoles, CERT-FR focuses on services that are production-differentiated only by a path (for example, “/admin”). It suggests blocking them at the WAF or reverse proxy level.
Reflect the application logic in the structure of requests
To define thresholds for anomaly detection, ideally engage in discussions with the business teams. And in the face of attackers who operate over long durations, plan for cumulative thresholds.
CERT-FR draws attention to the configuration of blocks and throttling rules in the WAF. There are thresholds that are easy to define, such as those based on the amount of data per session or the origin of the connection. But for finer rules (for example, correlating user groups with object accesses), the application logic must be reflected in the structure of the requests. Otherwise, analysis becomes more complex. Front-ends may even become causes of denial of service.
