Lessons from the KRÉTA Case from a Data Protection Perspective

According to a press article published on the Telex news portal on November 7, 2022, the company developing the Public Education Registration and Study Base System (KRÉTA) was hit by a cyber attack, and a serious data breach may have occurred. The NAIH did not delay much; a day later, it launched an official inspection, followed by a data protection administrative proceeding. The decision concluding the proceeding was recently published, which – not yet final – imposed a data protection fine of HUF 110,000,000 on the defaulting company. This article provides a brief summary and the lessons learned from the case.

The KRÉTA system

As an introduction, let us find out what KRÉTA is and what kind of personal data it processes? Perhaps its best-known function is the electronic gradebook; however, it also has more than twenty similar modules, such as: e-administration, school catering, healthcare, student signaling system, management, and the data provision system for adult education also falls under KRÉTA. It is clear from the above list that the scope of the processed data is quite broad, including, among others, the natural identification data of teachers, students, and parents, tax identification numbers, social security numbers (TAJ), health data (e.g., integration, learning, behavioral, and educational difficulties, special educational needs), and student evaluations. According to the company’s estimate, the personal data of approximately 225,000 employees (mostly teachers), 1,500,000 students, and 1,870,000 parents are found in the KRÉTA system. This represents nearly 60,000,000 personal data entries regarding the total volume.

How did the attack happen?

The operation of the KRÉTA system was carried out by eKRÉTA Informatikai Zrt. as a data processor, based on contracts concluded with public education institutions (or their maintainers). The data controllers were the public education institutions where children go to study and educators go to teach. On September 15, 2022, unknown individuals carried out a phishing attack. One of the company’s employees performing support activities opened an infected element sent in the phishing email, through which the attackers obtained the employee’s passwords and gained access to the system. The support employee had all access privileges to both the test and live KRÉTA systems, as well as the related databases.

Furthermore, as part of their support activities, the employee frequently downloaded personal data from the live system to their own computer. During the September 2022 attack, the entire datasets of twelve educational institutions were found on their computer. The employee notified the company’s management about the incident days later. The company replaced the computer of the employee who fell victim to the phishing attack, deleted their login IDs and permissions, and then the employee received a new computer and new passwords.

Following the password change, no significant data movement was detected regarding the system, so the company concluded the investigation and considered the matter closed. Nearly two months later, however, came the proverbial “bitter pill”; on the day the Telex article was published (November 7, 2022), even staff members who do not read the online press could learn about the attack, as the attacker posted a notice on the company’s internal communication channel stating that the system had been hacked. Only after this did a more comprehensive and thorough internal data protection investigation and the official notification of the data breach take place.

The question arises: how was it possible to hack the KRÉTA system if the employee’s passwords were changed after the September 2022 phishing incident? In short, two circumstances played a role. One was that the employee stored all their login details in their Google account. However, Google not only stores but can also synchronize data. This means that when data changes, Google uploads the new data in place of the old ones. When the employee received new login credentials after the September 2022 incident, Google updated and stored these. The other key factor was that through a session left open, the attackers still had access to the employee’s Google account, thus they easily obtained the new passwords, which allowed the system to be hacked.

Findings of the Authority

The NAIH divided the data breach into two parts:

1. The September 2022 incident primarily affected the entire datasets of those 12 institutions that the employee had downloaded from the live system to their computer. In this case, a data breach was demonstrably realized.
2. In the case of the incident known in November 2022, it could only be established that the attackers could have had access to the entire KRÉTA database. It was not possible to prove beyond reasonable doubt in the proceedings whether the attackers actually downloaded personal data from the KRÉTA system or not.

The company’s procedure constituted a legal violation: on the one hand, it did not take appropriate technical and organizational measures and did not ensure adequate data security requirements (GDPR Article 32), and on the other hand, it did not report the data breach without undue delay (GDPR Article 33).

Key lessons from the case, failures of the company

Reporting without delay

According to the NAIH’s position, given the volume and sensitive nature of the processed data, the September 2022 incident should have definitely been reported, as a high-risk data breach had occurred beyond any doubt in this case. Although the data breach notification should have been made not by the company as a data processor, but by the educational institution as the data controller, only the company was in a position to assess the severity of the incident and notify the data controllers of this.

Saving passwords to a Google account is risky

Saving sensitive passwords into any account or browser carries risks in itself; however, in the case of personal data of the quantity and quality affected by the KRÉTA case, this is a serious and unacceptable data security error. Other, more secure password storage options (e.g., installed on the computer) exist.

Automatic session logout

The fact that automatic logout was not configured was also assessed as a serious data security failure.

The actual use of data is irrelevant

The company tried to defend itself by stating that it had conducted a search on the dark web and the data of KRÉTA users were not found there. The NAIH — correctly — attributed no significance to the demonstrable use of the data, as attackers will not necessarily disclose the data publicly, and on the other hand, future misuse of the data cannot be ruled out either.

Inadequate investigation

The investigation of the September 2022 phishing attack was not comprehensive. Deleting user accounts and generating new passwords is not sufficient, especially considering the volume and sensitivity of the personal data processed in the system. A thorough investigation could have prevented the situation from escalating. According to the NAIH’s good practice, the network traffic associated with the employee should have been monitored, which would have allowed for determining which traffic belonged to the employee and which to the attackers. The company was unable to separate the activities of the employee and the attacker from each other. If it had been capable of this, it should have detected the presence of the attacker.

Insufficient logging

As mentioned at the end of the previous point, the logging performed by the company did not facilitate the discovery of the incident. If the attacker logged into the system using the employee’s profile, it could not be determined from the log whether the attacker or the employee was present. According to the NAIH’s expectation, the log must be suitable for the proper discovery of the incident.

Two-factor authentication

Two-factor authentication was only introduced on November 10, 2022, whereas for a system of the KRÉTA level, it would have been a minimum expectation from the start.

The human error factor

As the saying goes, only those who don’t work don’t make mistakes. Accordingly, the possibility of human error must be taken into account, “since no business can rely on the fact that its employee ‘will not make a mistake anyway'”. Data security measures must be introduced that are capable of preventing serious consequences even in the event of human error.

An attack must be expected

According to the NAIH, in certain cases, e.g., due to the volume and sensitivity of the processed data or in the case of actors in economic life, it is expected that they prepare for being exposed to an information technology attack. Their security system must be designed accordingly.

Conclusion

Finally, the saddest conclusion of the case can be linked here. The NAIH decision also mentions that the company was presumably aware of the system’s vulnerabilities even before the attack; however, due to negligence and/or carelessness, they failed to build an adequate security system. This is indicated by the fact that after the hacking of the system, fundamental changes were implemented (their listing alone contains nearly twenty points) and the conditions for secure data processing were established. The question is, why did they have to wait for this until the system was hacked and unauthorized persons gained access to the entire KRÉTA database?