3 tips on how to avoid healthcare hacking in the future
A cyber security specialist lists three ways to avoid a disaster like the Vastaamo hacking incident: “Under no circumstances, should information systems show any patient information to end users without strong authentication”.
The hacking of the Psychotherapy Center Vastamo, reported at the end of October, prompted organizations to assess the level of their own data security. Jaakko Perkiö, IT Manager at Atostek, has a solution to avoiding similar situations in the future.
1. Increasing strong authentication
Strong authentication refers to user identification with methods that are more reliable than a plain password. Strong authentication is used in Kela’s Kanta service, where patient data is stored, but it is not necessarily required when logging in to a healthcare unit’s own information systems, which in turn can be connected to the Kanta via an interface.
Thus, some healthcare professionals have access to patient data in their own systems without strong authentication. That’s why Perkiö thinks all healthcare systems should use strong authentication.
“The security requirements for healthcare information systems should be tightened. Under no circumstances should information systems show any patient information to end users without strong authentication,” emphasizes Perkiö.
Social and healthcare data is transferred from one system to another via direct interfaces in healthcare providers’ own systems. According to Perkiö, there also lies a serious security risk if data is transmitted without strong authentication required during the process.
“A log entry identifying the professional who processed the data should be made whenever patient data is processed”, suggests Perkiö. “That way, the system could indicate who has done what.
2. Security audits should concern all systems recording patient data
In Finland, social and healthcare information systems are divided into two classes, A and B. Roughly speaking, Class A includes all systems connected to the Kanta service and the rest fall into Class B.
An external security audit, i.e., a security assessment, is required for Class A systems. An audit is currently not required for Class B systems. However, according to Perkiö, the risk of data breaches would be reduced if Class B systems were also subject to security audits.
“It would be justified to require security auditing for all systems in which social and healthcare data is stored”, comments Perkiö.
In addition to security audits, Class A information systems must undergo so-called joint testing to ensure their compatibility with the Kanta service. The aim of joint testing is to ensure the compatibility of Class A information system interfaces and the data transmitted via them with the Kanta services and the other Class A systems connected to Kanta. According to Perkiö, this does not, however, improve data security, so there is no need to subject more systems to joint testing.
3. Establishing a Class C
In Finland, the Government recently submitted a proposal to the Parliament on the processing of social and health service client data. It has been wrongly claimed in public that the new act would completely remove Class B and only leave Class A. This is not the case, since Classes A and B would also be included in the new Act on the Electronic Processing of Client Data in Social and Health Care Services.
Perkiö proposes a third class, Class C, in addition to these two. Class C would include systems that do not store the sensitive social and healthcare data they process. In Perkiö’s opinion, such data could, in many cases, only be stored in the Kanta service instead of local systems.
“It would be easier for such systems to implement security features and thus pass auditing, as they contain less sensitive information,” says Perkiö.
Perkiö points out that even though the Kanta service does not support the storage of all data, essential patient data could often be exclusively stored in Kanta. This way, only appointments and other less sensitive data would be stored in local systems.
