The data scraping incident that hit the Directorate General for Public Finances (DGFIP) cannot be reduced to a mere case of compromised accounts.
It is one of the key takeaways from the lessons-learned report published by the National Agency for the Security of Information Systems (ANSSI).
The document (about twenty pages) highlights a series of controls to strengthen around business applications, authentication, access rights, detection, and incident response.
However, it is necessary to distinguish facts from recommendations. The ANSSI itself notes that only a full audit of the information system and the affected applications will exhaustively identify exploitable vulnerabilities. The measures it lists do not constitute an exhaustive catalog of confirmed flaws.
Nevertheless, they outline a defense chain in which several links may have been insufficiently robust. Six levels stand out in particular.
1- Better Control of the Exposure of Business Applications
The first weakness concerns how business applications are exposed.
The ANSSI distinguishes three categories. Internal applications should be accessible only from devices managed by the DGFIP and should not be directly reachable from the Internet, except through a VPN dedicated to agents.
For applications intended for external use with limited exposure, the agency also recommends access from internal networks or via a VPN for partners. If that is not possible, limiting access to an allowed IP address list can be considered.
This recommendation is important in the incident context: the more an enterprise application is exposed to the Internet, the more it must have additional mechanisms to control who can connect to it and what they can do there.
The ANSSI does not say that all affected applications were unnecessarily exposed. But reducing this exposure clearly constitutes one of the remediation axes identified after the incident.
For applications that must remain public, the agency especially recommends geofencing, screening of poorly reputed IP addresses, and using the connection source as an alert criterion when blocking is not possible.
2 – Authentication that Must Withstand Credential Compromise
Second level: protecting accounts.
The ANSSI lessons place a strong emphasis on preventing credential theft. The agency notably recommends prohibiting the use of personal devices to access professional resources and strengthening the security level of managed workstations: updates, EDR, antivirus, and always-on VPN are cited among the measures to be implemented.
It also advocates deploying multi-factor authentication across all applications.
But the ANSSI provides an important caveat: not all MFA solutions are created equal.
The second factor must remain independent of the compromise of the first. A one-time code sent by email is thus not considered sufficiently protective if the mailbox is itself accessible with the same username and password.
The agency rather recommends physical tokens or authentication apps and counsels, when possible, the use of a separate device for the second factor.
This part of the lessons shows that the question is not only whether an MFA exists. It is also about determining which compromise scenario it actually protects against.
The ANSSI also calls for strengthening passwords and better separating professional and personal use to prevent an environment not managed by the DGFIP from becoming the entry point to professional credentials.
3 – Access Rights and Consultation Perimeters That Are Too Broad
This is the third link and one of the most important in understanding how a compromise can turn into data exfiltration.
The ANSSI recommends fine-grained management of application rights so that each user can access only the information necessary to perform their role.
It also calls for setting caps on the consultation of business resources.
The nuance is important. A user may be legitimately authorized to access an application without necessarily being able to consult an unlimited amount of data.
This distinction between access rights and data-views is fundamental in a scraping scenario.
A attacker with valid credentials can indeed issue requests that, taken individually, resemble legitimate activity. The problem emerges when the account allows chaining these requests and exploring a data perimeter far larger than what is necessary for normal use.
Restricting rights is therefore not only a confidentiality measure. It also helps contain the impact of an account compromise.
4 – Insufficient Mechanisms to Limit Scraping
The fourth level concerns volume control.
The ANSSI explicitly calls for quotas on:
- the volume of business resources consulted;
- the number of requests;
- the volume of data exchanged over a given period.
These measures are especially suited to preventing automated scraping.
They help distinguish a user who sporadically consults a resource from an account that issues thousands of requests or retrieves data volumes incompatible with typical use.
The ANSSI also advocates caps on the consultation of business resources. The aim is to create several levels of limitation rather than relying solely on authentication.
This protection would play a crucial role in a scenario where credentials have already been compromised: even when logged in with a valid account, the attacker should not be able to exploit the application indefinitely.
However, caution is needed in wording. If the ANSSI text recommends these mechanisms, it cannot by itself assert that each of them was absent at the time of the scraping operations.
5 – Detection and Response Must Be Faster
Fifth link: monitoring.
The ANSSI recommends that applications be systematically integrated into a SIEM and that multiple indicators trigger restriction measures: IP reputation, geolocation, or unusual behavior.
The document provides a concrete example: suspicious queries on E-Contact produced real positives.
This detail is interesting because it shows that the problem does not necessarily lie in a total lack of detection.
Detecting suspicious activity is nevertheless only a first step. One must then be able to qualify the event and rapidly interrupt the malicious activity.
That is why the ANSSI proposes studying the possibility of automatically blocking accounts after certain suspicious queries.
In the case of an automated operation, this capability can make a substantial difference. An alert processed manually may leave the attacker with an extra window of exploitation. An automated mechanism can, conversely, interrupt the chain before the amount of data exfiltrated becomes significant.
The challenge is therefore to move from a detection-centric approach to a detection-and-response approach.
6 – Strengthening the Management of Compromised Accounts
The final level concerns the response to the compromise itself.
The ANSSI believes that simply resetting the password should not be the sole measure.
When an account is considered compromised, its activity should be analyzed from the presumed date of compromise. The objective is notably to identify the applications the attacker may have accessed and the data they may have reviewed.
The mapping of the information system becomes essential here. Without precise knowledge of the applications to which an account can access, it is difficult to properly measure the extent of a compromise.
The ANSSI also recommends revoking active sessions on all accessible applications and portals.
This measure addresses a classic problem: changing a password does not necessarily terminate an already established session.
Finally, if the same account is compromised multiple times, the agency calls for a thorough root-cause analysis.
Incident response should therefore not be limited to simply “changing the password.” It must enable understanding what was compromised, for how long, through which access points, and why the compromise could recur.
According to the ANSSI, an action plan addressing the exploited failures was defined with the DGFiP. The deployment timetable remains to be determined.
