The FDPIC published the final reports in his investigation into the facts of the Xplain AG, fedpol and BAZG cases on April 25, 2024. publishedafter a very expeditious clarification of the facts by the standards of the FDPIC.
Background
The background to this was the well-known double extortionRansomware attack on Xplain. A fairly detailed description can be found at Inside ITas well as a Interview with the CEO of Xplain from February 2024.
The attackers, a group called Playhad captured a large amount of data in May 2023. This was critical because Xplain had been working primarily as an IT provider for the Federal Administration in the area of internal security since 2000, e.g. for the Federal Office for Customs and Border Security (BAZG). The affected systems – reference installations, development, test, administration and build environments – apparently contained around 1.5 TB of data, of which around 600 GB was exfiltrated and – because Xplain had refrained from paying a ransom – around 430 GB (146,623 files; but a large proportion were duplicates) was published; presumably without the attackers examining the content of the data more closely. The NCSC, which led the federal government’s handling of the incident, has compiled a report on the affected data and published.
Data from Xplain, fedpol, the FOJ and other agencies assigned to the FDJP, as well as the DDPS, Seco and other cantonal and federal authorities were mainly affected. The data also contained personal data, in addition to some data objects classified as internal or confidential – but not secret. The FDPIC illustrates the incident as follows:
Administrative investigation by the Federal Council
As a result of the attack, the FDPIC and the Federal Council commissioned Oberson Abels to conduct an administrative investigation from the end of August 2023. report dated March 28, 2024 was concluded (criminal proceedings by the BA are still ongoing). The subject of the investigation was how Xplain came into possession of productive data from the Federal Administration, whether this was due to a lack of sufficient TOMs and whether the Federal Administration breached its obligations in monitoring Xplain.
The report came to the conclusion that there were process deficiencies on the part of the federal government (e.g. lack of dual control principle when transferring productive data to Xplain), that Xplain had not been adequately monitored and that the federal government had also violated data protection obligations in relation to Xplain as a processor. Apparently, there was also a lack of clarity regarding the fragmented responsibilities within the various federal agencies involved. A dependency on Xplain was also established.
At its meeting on May 1, 2024, the Federal Council therefore decidedto take measures. He expects the situation to improve as early as January 1, 2024 as a result of the ISGbut it has decided on further measures to be implemented by the end of 2024:
- additional security requirements for cooperation with suppliers (created by the end of 2024) to strengthen control and audit capabilities;
- Function-related training concept for training and sensitizing employees with regard to safety requirements;
- Overview of the federal authorities’ existing means of communication;
The DDPS is also tasked with reviewing the Confederation’s basic ICT protection by the end of 2024 and proposing any necessary adjustments. The BACS will also “demonstrate” how coordination between the Confederation, cantons and suppliers will take place when dealing with cyberattacks and what criteria will be used to assess the extent of cyberattacks.
Final report on Xplain
Transitional law
In the final report on Xplain, the FDPIC comes to the conclusion that various recommendations should be made. However, as with all factual investigations initiated under the old law, the problem arises that they were or are to be concluded formally and substantively under the old FADP in accordance with transitional law (Art. 70 FADP). As a result, the FDPIC’s findings and, where applicable, recommendations are essentially of a legal-historical nature, because unlike the FDPIC when conducting the fact-finding, the addressees of the fact-finding have been subject to the new FADP since September 1, 2023. The question therefore arises as to whether the FDPIC’s recommendations would also be relevant under the new law. The FDPIC therefore repeatedly refers to the new law in the final report in order to give the considerations a little more weight; however, there is no actual examination of the extent to which the new law actually corresponds to the old FADP.
Added to this is the fact that Art. 70 FADP only provides for the old law to continue to apply to the actual clarification of the facts. Since any action brought before the Federal Administrative Court by the FDPIC or the addressee of the clarification would open a new, separate procedure – it is not an appeal procedure – a separate transitional provision would be required for this. In the absence of such a provision, neither the FDPIC nor the addressee of the final report can bring an action before the Federal Administrative Court (the addressees had a right of action under Art. 35 lit. b VGG, which was deleted by the new FADP).
If a recommendation is rejected or not implemented, the FDPIC would therefore only have an investigation under the new DPA. Since the VwVG was only applied analogously to the clarification of the facts, the FDPIC would have to reassess the facts according to the rules of the VwVG and evaluate them according to the new law. In other words, the transitional provision of Art. 70 FADP is inadequate in its approach, but is becoming less and less important (many factual clarifications are no longer pending).
Legal considerations
From a legal perspective, the final report has two main topics: the role of Xplain and compliance with data security. Here, the FDPIC relies on his findings of fact, which Xplain had classified as incorrect.
From the FDPIC’s perspective, Xplain was active in two roles:
- As the person responsible for their own processing:
Xplain acts as the controller insofar as personal data about customers, employees, etc. are processed. In doing so, Xplain must comply with the basic principles of the Data Protection Act […].
- As order processor, as far as Xplain Software developed:
Xplain’s core business is the development of standard software for homeland security […]. As part of this activity, personal data of the client is also transferred to Xplain, in particular in the context of project data and bug fixes […]. It is irrelevant that the transfer of this data is only a side effect of Xplain’s actual task. It is also irrelevant that this data processing is minor compared to Xplain’s core activities. […] As the contractual agreements show, the processing of personal data is included in particular in the services agreed with Xplain […]. In this constellation, Xplain is to be qualified as a processor within the meaning of Art. 10a aDSG.
The FDPIC does not spend time here analyzing the roles in more detail. According to the in particular from the BayLDAbut also represented by the EDSA and also received in Switzerland „Center of gravity theory”, the decisive factor would be whether the processing of personal data is the actual object of the service provision (order processing, e.g. in the case of hosting or SaaS services) or merely a side effect of a different service (activity as a controller, e.g. services of the liberal professions).
This is probably in the interests of the federal agencies – if Xplain were a controller, the question would arise as to whether Xplain may be provided with personal data at all, which is much easier in the case of a processor. It should be noted that a controller can also be an auxiliary person in the sense of (official) secrecy law and may be consulted accordingly if he or she lege artis is appointed and included.
But Xplain also has another role to play: that of the responsible because the relevant specifications are not complied with during order processing:
In its function as processor, Xplain must process personal data in accordance with the instructions of the controller, in particular in accordance with the contractual requirements and within the scope of what the client is permitted to do itself (Art. 10a para. 1 lit. aDPA).
If Xplain does not comply with these requirements, it will itself become the data controller under data protection law.
The present case shows that Xplain did not delete the personal data transmitted to it in accordance with the contract […]. Xplain is responsible for the storage of this personal data – which was later published on the darknet.
That is neither entirely true nor entirely false. Formulated in such absolute terms, there would be no processor in breach of contract, only the designated controller. However, the concept of controller is not that broad – as is well known, it requires sufficient influence on the purposes and means of processing. If a processor violates a security requirement, this does not make them a controller. Such a change of role only arises if the controller carries out its own processing for its own motives – purpose – or sets essential means of processing. However, this happens when data is stored beyond what is contractually stipulated; in this case, the processor actually becomes a controller. It is therefore in the interest of the processor, for example, to expressly regulate further storage in backups etc. – if this is not done and data is not deleted after the end of the actual processing of the order, the processor is a controller who is most likely in breach of his obligations (e.g. to inform the data subjects).
The FDPIC continues to hold:
- The commissioning federal agencies were allowed to generally assume that Xplain has taken appropriate TOMs“since Xplain, as the controller, is subject to the aDSG and must comply with atzt 7 aDSG”. This is a somewhat strange justification, but it is correct that a processor is also subject to the processing principles, including data security, and therefore has its own obligations, and that the controller may have a certain degree of confidence in compliance with the corresponding obligations. It is therefore not generally mandatory to include a list of TOMs in a DPA, even if this is common (often, however, with meaningless descriptions of very generic TOMs).
- Insofar as the person responsible Specific safety requirements However, he must contractually bind them. (In addition, the Basic ICT protection of the federal administration stipulates that the ICT security requirements of the Confederation are to be regulated by binding contract).
- The person responsible must check the implementation of and compliance with the security measures – not wrong, but not generalizable to all order processing:
The The processor itself must carry out audits and unusual security incidents to the controller. This already results from the basic protective measures of Art. 7 aDSG and from the principle of good faith. The controller may require an audit right and also obtain audit reports from the processor.
- The storage of personal data beyond what is necessary violates the principle of data protection. Proportionality.
- Xplain had neglected its duty to notify the security breach (although such a duty only existed under the aDSG on a contractual basis or in certain constellations as a consequence of the security principle):
Immediately after the ransomware incident, Xplain took various measures to minimize the damage […]. It is striking that Xplain was obviously not aware of the seriousness of the incident and did not take the Federal Administration only informed ten days after the incidentalthough a period of 24 hours was agreed for such incidents.
There is another interesting point: the FDPIC examines the Compliance with the minimum requirements for data security by Xplain and identifies violations – but without naming or establishing an abstract rule for determining the minimum standard of protection. The FDPIC rightly states that the fact of a security incident should not lead to the conclusion that the TOMs are inadequate (a notion that is not supported in Art. 4 para. 2 PrHG is expressed particularly clearly):
The mere fact that personal data from Xplain’s file server was published on the darknet does not mean that the measures were inadequate. A residual risk of a data breach remains with every data processing operation. The decisive factor is whether measures appropriate to the risk of data processing were taken.
This should also be borne in mind when transferring personal data abroad. However, the FDPIC proceeds by naming security measures that had not been taken – e.g. the operation of a SOC or the mapping of contractual requirements in its own processes – and comes to the conclusion that the FDPIC has not taken any security measures. directly to the conclusion that data security requirements were violated as a result. Even if this makes sense as a result and the FDPIC limits himself to rather generic recommendations, the procedure is actually legally incomplete. The FDPIC should have examined the factors according to Art. 1 GDPR – or rather: according to Art. 8 ff. and 20 ff. aDPA, i.e. he should have
- have to explain how the risks for those affected ex ante the scope of discretion of the controller,
-
have to assess the state of the art, and
-
the cost of implementing further possible measures, taking into account the effectiveness of the possible measures.
This is also demonstrated by the present proceedings:
- Security measures are very often neglected in a climate of trust and are only critically examined once a breach has occurred. This demonstrates the importance of external audits (e.g. pentests or other security reviews), especially in the case of close and long-term collaboration.
- It is not impermissible to leave obligations in the area of data security to the processor, in fact it is the rule. It is difficult to say how far the controller’s responsibility extends and how far the processor’s responsibility extends – but a key TOM for both parties is to regulate precisely this interface.
- Safety is also a process issue. Processes must exist and be practiced. They will not work in an emergency if they do not function in standard operation.
- Companies often have a false sense of security when it comes to their own processes, probably for two reasons: Firstly, internal processing is felt to take place in a protected space – internal process deficiencies are unattractive from this perspective, but harmless. Secondly, it is known in the abstract how frequent cyber attacks have become, but this does not lead to a feeling of threat, very wrongly though.
- Contamination of systems with personal or other sensitive data can have repercussions. This applies not only to the storage of customer data by IT service providers, but also to the failure to delete or anonymize data on your own systems that may be affected by a breach, which can lead to a need to provide explanations to those affected.
Recommendations
The FDPIC recommends the following measures to Xplain:
With regard to data security:
- Xplain shall take appropriate TOMs in accordance with the law and the contractual requirements of the Federal Administration with regard to
- the processing of particularly sensitive personal data in the context of support and maintenance processes,
- the processing of personal data under qualified confidentiality protection
- the development of software in the sensitive area of homeland security.
- Xplain regularly verifies these TOMs of the Federal Administration by
- establishes an ISMS (whereby this is to be certified according to an internationally recognized standard as long as Xplain cooperates with the Federal Administration in the area of internal security);
- established a risk management system and
- measures are evaluated on an ongoing basis;
- Xplain “sensitizes” its employees
- Xplain conducts periodic internal and external audits.
With reference to further principles:
- Xplain integrates the contractual obligations into its own processes, and
- implements a deletion concept in accordance with legal and contractual requirements.
Publication of the final report
It was disputed whether and how the final report should be published. Xplain had unsuccessfully requested that the report not be published, apparently essentially because the facts of the case had not been properly established. Xplain had also demanded extensive redactions, apparently going as far as anonymizing the final report. The FDPIC made certain redactions as usual, but not to such an extent, partly because anonymization would not have been possible in this case.
However, the question arises as to how far the FDPIC’s publication practice may go. Under both the old and the new FADP, the FDPIC can inform the public about findings and rulings, i.e. today also about investigations and rulings, but only “in cases of general interest” (Art. 57 para. 2 FADP; Art. 30 para. 2 aDSG). This wording is misleading: the FDPIC cannot provide general information in such cases, but only if there is a specific public interest in the information. A number of factors must be taken into account:
- Not every interest of the public is a public interest – this applies to the media as well as to the FDPIC. Not everything that the media want to write about is in the public interest. Media publicity therefore does not justify every publication. On the contrary, it can even be a reason to refrain from publication.
- The public’s interest in the activities of the FDPIC in general is not to be satisfied by the publication of a final report, but through activity reports or media releases.
- The FDPIC’s interest in proving its own effectiveness is not a public interest.
- The public interest in information does not require detailed information. The public’s attention span is short.
- The interest in the further development of the law and knowledge of the FDPIC’s practice is a public interest. It could and should be satisfied by guidelines and the like, not by final reports, which are often very superficially justified from a legal point of view.
Final reports in terms of fedpol and BAZG
In contrast to Xplain, the clarification of the facts in the case of fedpol and BAZG was not directed at Xplain’s internal processes, but at the actions of the authorities themselves. However, the contents of the final reports overlap.
However, the FDPIC once again clearly confirms that the controller may have a certain basic trust in the processor:
The person responsible must provide the contractor with clear specifications for safety measures and monitor their implementation and compliance. If the contractor itself is subject to the aDSG, the controller can assume that the technical and organizational data security measures (Art. 7 aDSG) are appropriately fulfilled.
However, the controller may still have to monitor the processor:
The controller is therefore obliged to carefully select, instruct and train the processor. monitor as far as necessary.
On the merits, the FDPIC sees shortcomings in particular in the contractual involvement of Xplain, in the reliance on a presumed audit by the FOCA, which was already using an application used by fedpol, and in the lack of monitoring measures.
The FDPIC recommends the following to both fedpol and the FOCA:
- The processing of order data was not clearly regulated. The processing of commissioned data should therefore be specified in such a way that the parties “make themselves aware” of whether and under what conditions personal data may leave the federal government’s systems. He recommends the following:
- To check when it is necessary for personal data to leave the Confederation’s systems and be stored in Xplain systems as part of support processes;
- to determine the necessary TOMs in each case, and in particular to ensure the principles of data minimization and data security if storage at Xplain is necessary;
- to record the corresponding data transfers in clear agreements.
- If fedpol continues to work with Xplain (which is apparently the case – the dependency identified by the investigation report will continue), “data protection criteria must be taken into account”. The data protection processes and compliance with them must be regularly monitored.
- The next time fedpol decides on further cooperation, it must check whether a certified ISMS is in place.
- The data protection processes and compliance with them must be regularly monitored by means of internal or external checks or other evidence.
- In addition, employees must be continuously “sensitized” to data protection risks.
- Contracts in the area of data security must be specified and, if necessary, standardized.
The FDPIC also recommends that fedpol, in the case of applications used by another federal office, should at least have its own SCHUBAN to be carried out.