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 disclosure in an event of theft or loss and alteration particularly in the healthcare sector, where the impact of these incidents on the people concerned is very high. For a comparison of disk encryption software, you can use this link.

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

Whenever your software, email client or system connects and exchanges data with other systems (outside or even within 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 - consider using Regimail (provided by Agence eSanté for the communication between professionals) or PGP plugins which are as well supported by most messaging softwares.

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 being compromised 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 with of a key length of min. 2048 bit and higher is recommended.

• 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 page 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 as soon as possible

In relation to the environment you manage or maintain on behalf of your customers, 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 access rights 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 little 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.

As healthcare is a domain where large quantities of medical data are being processed by each doctor’s practice, it is essential to keep in mind the protection of any data that identifies individuals against loss, theft, alteration or misusage.

Keep in mind basic definitions

Personal data is any data that can identify individuals or make them identifiable. It can be signatures, photos, CNS numbers, IBANs, etc. Medical data is a high-risk type of personal data, that should be carefully managed.

Processing personal data is any operation on personal data (reading, writing or modifying personal data, deleting personal data, or transferring personal data somewhere else). Merely having access to personal data is also processing it.

Data controller is an entity that makes decisions about processing personal data. A data controller has the overall control and is responsible of the processing. An ICT service provider can become a data controller if they process personal data outside of the instructions of any cabinet/medical center.

Data processor is a natural or legal person who processes data on behalf of a controller. A service provider is a data processor as long as they act within the boundaries of a contract with a data controller.

No unnecessary processing of any personal data

Do no keep anything that you do not need, especially if it is medical data. The reason is that processing data outside of the strict contractual agreement with a medical practice, hospital or doctor exposes you to data protection risks (because you need to do more work to ensure GDPR obligations).

Know your role (data processor or a controller)

At any point in time, irrespective of whether you are a controller or a processor, you are expected to know what personal data you process. It is your responsibility to protect this data against the risk of loss, theft or alteration, to be transparent and enable patients, doctors, other data subjects to exercise their GDPR rights.

Follow the GDPR roles and obligations in your contracts

It is great that you know your role as a controller or processor but it is not enough: it should also be mentioned in your contract with the users or clients. This is because it would be more difficult to prove that you do or do not perform certain personal data processing if the contract doesn’t describe that framework. Also, if it is written in the contract that you have one role or the other, stick to it and do not go above, because you expose yourself to potentially unnecessary risks.

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,
• preventing that the same event occurs again in the future.

• 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.

Know 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., these CASES recommendations, …). For more specific password complexity recommendations you go to https://cases.lu/knowhow/glossary/Password.html(English and French), or NIST’s password recommendations

Embed role-based access in your software

Not all users are allowed to access the medical data in the same way. You need to minimize confidentiality risks by designing role-based access features, e.g., for doctor's assistant, 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 access rights associated to those roles. Adding new access rights will be easier to manage than if they had been granted altogether in the beginning. In addition, it must be clear to your clients and to you if the maintenance of access rights, 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 within 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 and representative (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, for example as recommended by OWASP, 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 and encrypt backups of your source code, as performed by GitHub or other specialized software, will help you to ensure integrity and to 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 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 practice 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 antagonistic tests, probing for simple boundary conditions (no particular hacking 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 tests, you prepare yourself for the case where an hacker deliberately tests the boundary.

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 service providers. 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 software providers 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 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 more specific password complexity recommendations here or at NIST’s password recommendations.
• Apply 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