Applied to eHealth, this domain focuses on using large cryptographic keys as well as different encryption mechanisms and applying these to both data that moves and data that is stored.

Avoid managing the private keys of your clients and users

Key management is essential for the secure usage of a system or software. While it could be convenient to manage the private keys of your users or clients, you expose yourself to several risks: the risk of losing these keys, of having them stolen by someone else, or of misusing them by accident, which could further incur a liability risk in case of a dispute. If you stay away from managing private keys of others, these risks disappear. You can, however, offer help on creating keys, but never deal with private keys yourself.

Use encryption for data being stored

Any backups that you manage or that you have access to, on behalf of your clients in the healthcare sector, constitute medical data being stored. The same applies to any data that your software records and keeps for future reference. This includes calendar entries with appointment related data, logs, patient records, payment information, etc. Consider encryption for all the data that your system or your software stores. This can be done by using disk encryption software or file-system encryption (offered by the operating system), or using encrypted databases. This will be useful to protect it against theft, loss and corruption particularly in the healthcare sector, where the impact of these incidents on the ultimate individuals is very high. For a comparison of disk encryption software, you can uses link.

Use encryption for data in transit (including a total export)

Whenever your software, email client or system connects and exchanges data with the world (or even your own network) consider to configure encrypted connections. For http connections, we recommend using https. Disable or replace any SSL or deprecated TLS connections with up-to-date TLS connections (consider IANA’s recommendations and secure encryption cyphers). For data transfers, please use SFTP and avoid FTP at all costs. If data is sent by mail, or transferred to any media storage, then it should be at least protected in a ciphered archive (using 7zip for instance). Emails between your company and your clients should also be encrypted - using PGP plugins is supported by most email clients.

Use a “state of the art” key length for your encryption algorithm

Using longer key lengths better protects you against brute-force attacks. For this reason, you should stay up to date with the latest recommendations in terms of key length, because they change over time. At the moment of writing of this list, for example:

• If you use symmetric encryption (e.g., AES), you should move away from 128-bit keys and use keys of 256 bits.
• If you use asymmetric encryption (e.g., RSA), you should know that 1024-bit keys are considered deprecated since 2002, and what is recommended by the community since 2015 are 2048-bit keys

For the latest recommendations consider to check sites such as this one or this one from the BSI.

Consider using both symmetric and asymmetric encryption

Symmetric encryption uses the same key for encryption and decryption, unlike asymmetric encryption. Since the whole mechanism of symmetric encryption depends on keeping the key as a secret but sharing it with another party to decrypt the content -- scalability is difficult and the risk of compromise is high. Despite this key management issue, symmetric encryption is fast and tends not to drain CPU or network resources, which is not always the case for asymmetric encryption. Asymmetric encryption is a much more complicated process than symmetric encryption but tends to be more secure; in addition, the private key is not shared but the public one is. Use asymmetric cryptography when you need to establish a secure communication channel, when digital signatures are required, or for messaging applications; symmetric encryption is adapted when large portions of data need to be encrypted and transferred.

In terms of choosing algorithms for symmetric and asymmetric encryption, recent recommendations from the BSI mention:

• For block cyphers (symmetric encryption), the usage of AES-128, AES-192, AED-256, as well as Twofish and Serpent;
• For stream cyphers, no stream cypher is recommended;
• For asymmetric encryption, the use of RSA of a key length of between 2000 and 3000 bits.

• You may support your customers on creating keys, but never deal with the private keys yourself
• Useful information and a comparison of disk encryption software can be found here
• Use https, up-to-date TLS and SFTP for encrypted data exchange
• For the latest recommendations related to key length for encryption, consider to check sites such as this one or this pages from the BSI

For eHealth software, this domain focuses on the need to keep both eHealth applications and their underlying systems up-to-date (using the latest versions, updates and patches).

Stay informed and apply necessary security patches to both operating system and application environment

In relation to the environment you manage or maintain on behalf of your users, be informed and apply necessary security patches (depending on your operating system and your application environment), plan your updates and be transparent towards your customers about your plan. Whenever you install these patches or security updates, you should use an account with the least privileges for the task of updating and patch management.

Automate instead of relying on users

It is essential to keep software up to date. Users might forget to keep an eye on updates, or might just want to delay installing them because of unwelcome disruptions in their work. For these reasons, don’t rely on users to inform you that they need to update their software. Rather, have automatic updates pushed to their workstations if possible. In that case, remember it is important to warn users before updating anything, and do your update outside working hours. You could also schedule periodic on-site checks otherwise.

• Be informed and apply security patches regularly
• Respect the least privileges recommendation
• Consider enabling automatic updates outside working hours

When ensuring the remote maintenance of workstations in doctors’ cabinets of practices, some good practices relating to the start, operation and end of the remote session will make your work easier on the longer term.

Consider data exfiltration risks when accessing remote computers

When debugging or updating client workstations remotely, errors or mistakes (e.g., accidental data downloads, accidental disclosures to externals) can happen. Consider that when you access user workstations, there are some risks of data exfiltration. Always rely on the permission of the user, avoid permanent connections, and ensure logging and tracing of activities performed.

Always rely on the explicit permission of the user for each remote session, and avoid as much as possible being connected remotely for long periods of time with no particular reason. It is important as it could become another way for malicious individuals to gain access to a system.

Your remote session should last as short as possible

In the interest of your own time, but also from a risk point of view, end the remote session as soon as possible after completing the task it was required for.

Never ask for authentication data of your user (e.g. their password)

Never ask the user’s password, always use your own access or ask the user to type it for you. Only if absolutely necessary, ask them to type it themselves. Use your own credentials for the task you need to remotely perform. It is important as the knowledge of a password can engage your own responsibility in some cases.

Ensure that the remote access is eventually removed by the user or automatically after the task is completed

Inform the user to immediately close the connection or that the connection was closed.

The processing of personal data (DCP) is governed by Regulation (EU) 2016/679 or RGPD, which determines the scope of application and sets out the principles for protecting DCP.

Given that healthcare is an area in which large quantities of medical data are processed by every medical practice, it is essential to think about protecting all data that identifies individuals against loss, theft, alteration or fraudulent use.

Keep in mind basic definitions

Personal data is any information relating to an identified or identifiable natural person (Art 4.1 RGPD). By extrapolation, this means data that directly or indirectly identifies a person. Names, photos, CNS numbers, IBAN codes and IP addresses are all examples of PII.

Personal health data (PHCD) is data relating to the past, present or future physical or mental health of an individual (including the provision of healthcare services) which reveals information about that individual's state of health. This is sensitive data covered by a special regime (Art 9.2 RGPD).

The processing of personal data (Art 4.2 RGPD) refers to any operation involving the handling of DCP (collection, organisation, sorting, return, communication, destruction or even simple consultation of DCP). The processing medium is irrelevant (computer or paper).

The processing of DCP is regulated by a legal basis (Art 6.1 a to f): consent, performance of a contract, compliance with a legal obligation, need to safeguard vital interests, performance of a task in the public interest, legitimate interests.

The processing of healthcare PDS has an even more restrictive legal basis (Art 9.2 et seq.): explicit consent, vital interests, important public interest grounds based on EU or national law.

The data controller is the entity that determines the purposes and means of the data processing. Obligations and liability (civil, criminal, administrative) rest with the data controller.

The joint controller represents another entity involved in the processing of DCP for its own purposes, so that it is decisive in determining the purposes and means of the processing. It is advisable to set out responsibilities in a contract.

A processor is an entity that processes data on behalf of and under the instruction (by contract) of the data controller. The contract must include RGPD clauses in accordance with Article 26.3 adapted for the project. The RGPD applies for certain parts also to the processor.

No unnecessary processing of any personal data

Apply the principle of proportionality/minimisation of data. Only collect data that is truly necessary for the purpose determined upstream and implemented on the basis of a justified legal basis.

Don't store personal data unnecessarily

Adapt the data retention period to the purpose for which it is to be used. The period may be fixed (e.g. 1 year, legal provision) or variable depending on a specific objective criterion (e.g. the duration of the contractual relationship).

Clearly identify the role and function of those involved

Demonstrate transparency in the information and communication channels used to exercise individual rights (access, rectification, deletion of data). In the event of joint responsibility for data processing, establish the division of roles in the exercise of individuals' rights.

Secure personal data processing

Apply high physical, logical and organisational security measures to ensure confidentiality, integrity and availability in the processing of healthcare DCPs.

Incident management involves monitoring, detecting and reacting to events in the network or one or more computers that are related to the security of the data or of systems hosted at the doctor’s practice.

Set up a security incident handling process or procedure

No matter how good your information security controls are, incidents will happen sooner or later. It is essential that you handle them in the same way every time. For that, you should prepare a list of steps to perform, and make sure you stick to it when an incident happens. In this way, you will not forget or delay actions that should be performed right then.

What should be included in an incident handling process or procedure? A few elements include:

• performing common steps to limit damage,
• isolating the source of the incident,
• taking recovering actions,
• who and when to inform,
• keeping a record of each incident and how it was managed,
• learning from previous incidents so that they do not happen again.

In case you are subject to an information security incident (attacks, malware, etc.) and require another expert point of view, you can always ask SecurityMadeInLuxembourg’s CIRCL team for help (info@circl.lu)

In information security, risk management means understanding and responding to existing factors or possible events that can harm the confidentiality, integrity and availability of an information system. These factors and possible events should be examined in advance and measures should be established to protect the information system when these events happen, as they can have an impact on the security and privacy of the data from the doctors’ practice.

Review the maturity of your information security risk management

To understand how mature your organization is, you should verify your maturity in information security risk management to ensure you are not the weak link. You can use CASES’s Fit4Cybersecurity or Fit4Privacy tools that are available for free to perform a self-assessment of your maturity in risk management.

Discover the actual weaknesses of your systems or software

Even if you might think your systems or software have certain vulnerabilities, it can be that they are not the only ones, or maybe others are more stringent and you might not yet be aware of them. At least once in a while, you could perform a vulnerability scan or a penetration test. You can use tools such as:

The common vulnerability search offered by CIRCL (https://cve.circl.lu/),
the Cybersecurity Ecosystem annuary offered by SecurityMadeinLuxembourg, in case you want to select and contact an expert to perform the scan for you.

Know your own information security risks

You should periodically perform an overview of the information security risks that your activity is subject to.

Some risks are permanent while some others can be new or can have a different impact than in the past. You should take into consideration the threats you have encountered, but also vulnerabilities that you might have, or that are known to the medical or ICT community in the Greater Region. Do not overlook the “human factor” among these risks, and the possibility of social engineering attacks, including phishing mails or calls from people who impersonate you or your clients. To minimize the chance that attempts like these succeed, consider double checking sender or caller identity, and using digitally signed emails. In addition to digital signatures, if the email contains confidential information (e.g., medical data in the body of the email or the attachment) then always encrypt your email and/or its attachments.

If you are able to list these risks, you should also list the actions that you have performed or will perform to deal with these risks, so that their impact is minimal. For a good risk management tool that comes for free, we can recommend MONARC.

Good risk management involves preparation but also transparency towards your customers. In terms of transparency, you should ensure that the contracts with your customers define what are the responsibilities regarding the most important information security risks that relate to the service provided.

• You can use CASES’s Fit4Cybersecurity or Fit4Privacy tools that are available for free to perform a self-assessment of your maturity in risk management
• Inform yourself here via the common vulnerability search offered by CIRCL
• Access the Cybersecurity Ecosystem annuary offered by SecurityMadeinLuxembourg, in case you want to select and contact an expert to perform the scan for you.
• Consider using MONARC as your risk management tool

For providers of medical software that they develop themselves, this domain covers various good security practices that relate to writing secure software.

Include password complexity and password validity requirements

Whenever you include the usage of passwords in the software you develop, never hard-code them. Instead, let the user choose them and impose password complexity and password renewal periods. This is to avoid trivial passwords that are easy to guess, or passwords that are used over and over again. It is not easy to strike a good balance between complexity, validity and usability. Users will always want something easy to use or will tend to avoid remembering too complex passwords. On the other hand, it is your responsibility as a software developer to put in place the mechanisms to protect the confidentiality of the data and the system that uses it. You should also remember to update these requirements as time passes; one of the examples could be to follow some security standard or website/blog (e.g. CASES recommendations). For more specific password complexity recommendations you go to https://www.nc3.lu/pages/knowledge/glossary/Password.html (English and French), or NIST’s password recommendations.

Embed role-based access in your software

Not all users should access all medical data in the same way. You can minimize confidentiality risks by designing role-based access features, e.g., for doctors, support staff, external specialists, and allow only the least permissions to each role from the beginning. In this way the software restricts access to types of data, depending on the permissions associated to those roles and adding new permissions will be better under control than if they had been granted altogether in the beginning. In addition, it should be clear to your clients and to you if the maintenance of permissions, roles and accesses is the user’s responsibility or that of the vendor.

Include strong encryption for data in transit and at rest

In the software you develop, include strong encryption features for storing data in databases, as well as for outgoing or incoming connections (especially where there would be a medical data flow) from the beginning. In this way, you create mechanisms for securing data from the beginning. Avoid hardcoding any authentication information, and stay away from storing private encryption keys of the users of your software.

Pay attention to the testing data set and the testing environment

The testing environment should be completely separated from the production environment because like this there is no risk to produce accidental or unauthorized modifications (or even disruptions) to the operational system already in place. The dataset you use to test your code should be realistic (as much as possible), and avoid using complete real patient data in your testing environment because that could be the start of a data leak.

Use secure coding principles, code management and perform code reviews

Apply and follow officially defined secure coding principles as recommended by OWASP here, M. Howard’s “Writing Secure Code” reference or G. McGraw’s “Software Security: Building Security In” book.

In order to keep track of the source code modifications relative to a source code repository, you should consider using source code management software, which will help you:

• keep track of changes over code,
• keep activity logs will also keep track of which developer performs changes over which pieces of code,
• manage conflicts when multiple contributors make changes over the same files.

Secure backups of your source code, as performed by GitHub or other specialized software, will help you ensure you would never lose your latest or earlier versions of your source code.

When a developer finishes writing the code for a software feature, two good practices to perform include:

• testing of the code performed, to determine if it is fit for use. Software testing can be done either [HZ6] [GG7] as unit testing (testing if a specific part of the code works as it should), integration testing (testing if interfaces between different components work as they should), system testing (testing if a completely integrated system works) or acceptance testing (testing if the operating environment, external testers or users accept the software). Your development process should include all of these test types.
• having another developer review the code. This could be useful to spot logical errors, fulfillment of specifications, the coverage of the tests in place, or adherence to development guidelines.  In this way, no single developer is the bottleneck and bugs are identified faster through the 4-eye check. Along with manual reviews, code reviews can also benefit from automated tools (for static or dynamic code analysis).

Consider the good practices of security testing

Security testing is done before the software is released, and focuses on discovering vulnerabilities in the design and implementation of the code. This goes beyond functional testing, and aims to perform adversarial tests, probing for simple boundary conditions (no particular attacker skills required). For example, probing for an SQL injection in the code of your website could be done at this stage. Another example is if someone enters the wrong password multiple times. If you perform boundary value testing, you prepare for the case when an attacker probes the boundary on purpose.

Stay away from deprecated libraries, programming languages and operating systems

You should be regularly monitoring whether the operating systems, programming platforms or libraries that you use are still up to date and maintained. For example:

• If you are using legacy operating systems (e.g. Windows XP, Windows Server 2008 R2 or earlier), chances are the maintenance costs are higher, and there is little or no support from the vendors. If you are unsure of the lifecycle support for your Windows system, you can check this Microsoft page.
• Any third-party libraries included in the development you perform in-house should also be regularly monitored in case new versions appear, or older versions are no longer supported.
• When downloading third-party libraries to be integrated within your software, be sure to use trustworthy sources and where possible, verify the integrity of the library by means of checksum verification.

In terms of development platforms, consider the use of modern programming languages which are supported by their vendors as well by large community and are provided with regular updates and security patches. To be sure, please check the vendor website for end-of-support notices, and if it is the case for your language of development, consider to move to the latest supported version.

Avoid data transfers using unprotected or public wireless connections

If, in your software, you want to allow users to open connections to external machines or (semi-)mobile devices (e.g., echograph, tablet, mobile phone, MRI scanner), avoid at all costs unprotected wireless connections. Without any encryption, those connections will be used to transfer confidential data that could be intercepted by malicious actors.

• Find here more specific password complexity recommendations or NIST’s password recommendations.
• Secure coding principles, visit OWASP, M. Howard’s “Writing Secure Code” reference or G. McGraw’s “Software Security: Building Security In” book
• Source code management software like GIT, Subversion etc. find more information here
• Lifecycle support for your Windows system, you can check this Microsoft page.
• Click here for good cybersecurity practices