General Data Protection Regulation
The EU's most comprehensive data regulation demands high standards of data handling, and affects companies worldwide.
All organisations that collect personal data about EU citizens are affected by GDPR. Encryption plays an important role in safeguarding personal data.
However, while GDPR states what protections must be implemented, it does not specify how. ScramFS is the critical missing link, and the ideal encryption software to assist GDPR compliance.
Contents of this article:
- How does GDPR view encryption?
- Checklist of capabilities: 15 essential features to look for in an encryption system
- How ScramFS provides the encryption tools that help with GDPR compliance
- It's easy to get started with ScramFS
How does GDPR view encryption?
Under GDPR, encryption is seen as one of the major safeguards for protecting personal data. Various articles in the legislation make direct mention of encryption, and more generally, pseudonymisation. While we recommend that each organisation seeks legal advice based on their own circumstances, we see three specific messages relating to encryption.
1. Security of processing data (article 32)
Encryption is specifically cited as a an appropriate technology for safeguarding data.
|Personal data1||1. Personal data: information relating to a natural person, such as name, any kind of ID, location, IP address, or information about a person’s physiological, genetic, mental, economic, cultural or social identity. ref:Article 4(1)|
|must be secured to a level appropriate to the risk2,||2. Taking into account the state of the art, implementation costs, and risk that affects the rights and freedom of natural persons. ref: Article 32(1)|
|by technical and organisational measures including pseudonymisation and encryption3||3. Where the encryption key must be stored separately to the encrypted data. ref: Article 4(5)|
|and by ensuring ongoing confidentiality, integrity4 and availability5 of data processing systems and services.||
4. Confidentiality and integrity are guaranteed by securely implemented encryption.
5. Availability is achieved via backup and disaster recovery.
2. Privacy by default (article 25)
Encryption provides privacy by default if it is integrated into an organisation's systems and processes.
|Technical and organisational measures should be implemented to provide data protection by design and by default1,||1. Taking into account the state of the art, implementation costs and nature of the data being collected and processed, and the risks that affects the rights and freedom of natural persons. ref: Article 25(1)|
|including pseudonymisation (and encryption)2,||2. Encryption meets the definition of pseudonymisation because it processes personal data in a manner where the personal data cannot be attributed to a specific individual without additional information (the encryption key) which is kept separately. ref: Article 4(5)|
|and only personal data necessary for a specific purpose3 should be processed.||3. Including keeping the data collected, processed and stored to a minimum. ref: Article 25(2)|
3. Mandatory reporting of data breaches (articles 33 & 34)
Encryption is useful in mitigating against both the breach of data, and the burden of mandatory notification to both the authorities and affected individuals.
|When an organisation becomes aware of a personal data breach1,||1. Personal data breach: means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed. ref: Article 4(12)|
|it must be reported2 to the Supervisory Authority within 72 hours3, unless the breach is unlikely to result in a risk to people’s rights and freedoms4.||
2. Detailed in Article 33(1)
3. Where feasible. If not all the details are initially available, more can be provided later. ref: Information Commissioner's Office
4. According to IDG's interpretation, leaking securely encrypted data is unlikely to be reportable. ref: IDC Executive Brief
|Affected individuals must be notified5 if there is a high risk that the breach will affect the individual’s rights and freedoms. However, notification is not required if the organisation implemented protection measures such as encryption6.||
5. Unless individual notification requires disproportionate effort, in which case public communication can be used. ref: Article 34(1)
6. Encryption renders personal information unintelligible to unauthorised persons. ref: Article 34(3)(a)
4. Fines and penalties (article 83)
Proportional fines mean that companies that handle especially sensitive data, or that have the ability to implement sound data handling practices but fail to do so, are likely to be penalised more heavily.
Checklist of capabilities: 15 essential features to look for in an encryption system
While GDPR tells organisations what they must do, the legislation does not cover the technical aspects of how to achieve compliance.
We recognise that it can be confusing for CISOs, CTOs and CIOs to distinguish which features are necessary in an encryption system. Our analysis of past data breaches, the GDPR legislation and encryption technology in general, has narrowed down the field to 15 key requirements.
1. Protects data “at-rest” – in the cloud and locally
What this means: whenever data is placed on storage devices and systems, it is fully encrypted so as to not leak any information.
Why it’s important: all too often, access-level security measures fail to protect data. Human errors, misconfigured servers or cloud services, stolen usernames and passwords, and untrustworthy personnel can cause a security breach, meaning unauthorised people get access to your data. However, encryption is the safeguard that protects an attacker from understanding the data – because properly encrypted data is impossible to read without the encryption key. This preserves the confidentiality of the data, and stops a security breach from escalating into a data breach.
2. Protects data “in-transit” from end to end
What this means: a significant source of data breaches is transporting data from one person or company to another. For example, to copy data from company “A” to “B”, it is common to use an intermediate server like cloud storage, “C”.
In this sequence of events, data is copied from “A” to “C”, and then from “C” to “B”. Data should be encrypted for the entire duration – that is, from “A” to “B”.
Why it’s important: a common misconception is that Transport Layer Security (often referred to as TLS/SSL) is sufficient protection for data in transit. While TLS protects data as it is transported from point to point via encryption, data will be decrypted at the TLS terminator (the end-point). In the example above, data will be decrypted at “C”, meaning that the decrypted data can be breached from the cloud storage provider.
This has happened numerous times in the past, including the Verizon customer data breach of October 2017.
End-to-end encryption would have prevented this from occurring – if the data was encrypted at “A” and decrypted at “B”, any security breach at “C” would only have revealed encrypted data, therefore preventing the leak of information.
3. Encrypts files fully, not partially
What this means: encrypting and protecting not only file contents, but file names and directory names as well. Many encryption systems only encrypt file contents, leaving file names and directory names unencrypted – a source of data leakage. Other encryption systems only anonymise file names.
Why it’s important: file names and directory names often contain sensitive information, while also giving attackers clues as to the contents of files. Further, it provides inadequate security, as attackers will be able to modify the names of files and directories, and even launch integrity attacks on encrypted file contents, where the contents of files and directories may be swapped without detection. Anonymisation techniques can also suffer from integrity attacks.
4. Provides client-side encryption with user-held keys
What this means: all encryption is done on a device you own and control, not on the cloud provider’s. You hold your own encryption keys and the cloud provider never knows the keys.
Why it’s important: to satisfy GDPR, under Article 4(5) definition of pseudonymisation, the key must be held separately to the data. It is also good security practice.
Server-side encryption does not provide adequate safeguards for GDPR compliance or preventative cyber-security:
5. Provides automatic and transparent encryption and decryption
What this means: encryption and decryption is performed in real-time, “on the fly” and on demand as data is accessed.
Why it’s important: manually implementing encryption is notoriously difficult and error-prone, so the best security system is one that functions automatically, behind the scenes. Simultaneously, GDPR Article 25 calls for “privacy by design and default”. A transparent encryption / decryption system makes this possible without requiring extra effort, extra hardware or re-architecting existing systems.
6. Encrypts a wide range of data
What this means: sensitive data can come in may forms – text files, photos, videos, Office documents, PDF files.
Why it’s important: encryption is a significant investment for any organisation. To simplify the job of I.T. departments, minimise the burden of key management and promote deployment, it is advantageous to use one encryption system for all types of encrypted files. Therefore, the system needs to protect and work with all sorts of files, protecting them while in use and at rest.
An example is playback of an encrypted video: ideally, video playback should start instantly, and it should be possible to seek forwards and backwards in the video without having to decrypt the entire video file.
7. Integrates easily with existing processes
What this means: your encryption system should be easy to implement, and should make it easy to add security to existing processes. For example, your nightly backups of data from your customer relationship management system that already run as unattended cron jobs should then interface nicely with your encryption system.
Why it’s important: a main barrier to adopting encryption is the difficulty of implementation and the need to re-engineer or re-architect existing solutions.
8. Provides vendor-neutral support for different types of cloud storage
What this means: Your encryption system needs to support different cloud storage systems, instead of being tied-down to one specific cloud vendor.
Why it’s important: over time, as your organisation changes and grows, you may need to switch cloud vendors, or switch between private cloud, hybrid cloud and public cloud. Using an encryption system provided by the cloud-vendor may lock you into using that cloud vendor indefinitely, and present high switching costs.
9. Allows you to copy encrypted data from one place to another
What this means: you can copy encrypted data from one storage location to another. For example, if encrypted data is stored in on a local NTFS file system, it should be able to be copied to other local storage devices (hard drives, USB flash drives), network attached storage and iSCSI/SAN devices, no matter if they are formatted with NTFS, ext4, ZFS, or other file systems. Additionally, it should be possible to copy encrypted data to different cloud storage systems.
Additionally, when you need to copy data from one cloud to another, perhaps using the cloud vendor’s migration tools, it should be possible to copy encrypted files, without needing to decrypt and re-encrypt them.
Why it’s important: data may be stored on many different devices and in different places, so a universal encryption system will guarantee that encrypted data can be read and written anywhere.
Additionally, it is important to prevent data leakage in migration operations. Cloud vendors offer migration tools that copy data from one place to another, but that requires granting the cloud vendor migration tool access to your cloud accounts. This provides a weak point in security: if plaintext data is migrated across, this data is exposed to the migration tool. However, if you copy encrypted data from one cloud to another, the migration tool can have access to the encrypted data and perform the migration all while being unable to read that data.
10. Enables developers to protect primary copies of data – implementing security by design and default
What this means: a primary copy of data is the “master” version – for example, files on a file server, or data in a database.
Doing this requires systems to be designed and implemented with security from the start. It is the role of software developers and architects to integrate encryption into their applications to achieve security by design and default. This also means that sensitive data (for example, biometric files) needs to be stored encrypted, often in a separate storage area to regular data.
Developers should use the techniques of pseudonymisation and tokenisation to store de-identified tokens in regular databases, while those tokens can be used as reference pointers into encrypted storage.
Why it’s important: in addition to satisfying GDPR Article 25, in order to mitigate against events like hacking attempts, encrypting data early and before it’s physically stored provides the best protection. This ensures that sensitive information is inherently secure from the start, so that subsequent copies are automatically safeguarded.
11. Enables system administrators to protect secondary copies of data
What this means: a secondary copy of data is any additional copy such as a backup, archive, export, transfer or migration. Many cloud leaks happen when secondary copies of data are poorly secured at an access level. Encryption protects directly protects the data, regardless of how well or poorly the access level security has been implemented.
Sensitive data can originate from many places, and can be stored in many places. Protecting all secondary copies means encrypting all data files and file names, no matter what type the data is (e.g. database backup, photos, videos, CSV files) and no matter where it lives (e.g. cloud storage, local storage, SANs).
It is normally the responsibility of system administrators to secure secondary copies of data.
Why it’s important: Most data breaches happen from secondary copies of data. Often, the breach of data is not just done by the data controller, but by 3rd parties:
12. Provides long term security
What this means: the data you encrypt today will be safe for decades to come. With computer technology continually improving at an exponential rate, certain types of encryption will become breakable more easily than others.
Why it’s important: legislation, such as the German criminal code, states that the confidentiality of data (such as medical, legal) must out-survive the patient or client. Therefore, encrypted data needs to be secure, not only now, but in the future.
However, quantum computers are predicted to break most forms of encryption that is currently used – including RSA and ECC cryptosystems. This directly affects many systems that implement encryption for data-at-rest – including for example, Microsoft’s Encrypting File System (EFS).
13. Is a reputable, high quality solution
What this means: the encryption system must be designed, peer-reviewed and audited by noted experts in the field – such as cryptographers and software security specialists.
Why it’s important: the market of encryption software is small, and few choices are available. Unfortunately, a good proportion of the available choices suffer from one of two problems:
14. Provides cryptographic security at cloud proportions
What this means: the encryption system must be designed with the cloud in mind. The level of security provided by a cryptosystem decreases when more data is put into it. When dealing with data at the scale of the cloud, this poses challenges: with millions of people encrypting billions of files, security must still be preserved for each and every file.
Why it’s important: protecting data at cloud proportions can only be done by employing advanced cryptographic techniques and careful design. If an encryption system is not designed properly, it is impossible to “add in” security at a later date.
15. Provides integrity checking of encrypted data
What this means: the encryption system must be able to detect if modifications have been made to the encrypted data. This is necessary to protect against integrity attacks (more commonly known as forgeries). Integrity is specifically mentioned as a requirement of secure data handling in GDPR Article 32
Why it’s important: many encryption systems only protect privacy, not integrity. This requires a higher level of safeguarding.
In the age of cloud computing, where the storage device is owned and managed by external companies (the cloud provider), there are two sources of attacks where data may be modified without authorisation:
For example, block-based full disk encryption and volume-based encryption do not protect against integrity attacks, and are therefore inadequate for protecting data stored in the cloud.
ScramFS provides the encryption tools that help with GDPR compliance
ScramFS, through its world class peer-reviewed encryption, provides an easy way to encrypt unstructured file data on a large scale. This makes it ideal to help in ensuring legal compliance and avoiding fines.
ScramFS ticks the GDPR boxes
This is no coincidence, given that ScramFS was designed specifically to address the requirements of privacy legislation such as GDPR, while also being designed to be cryptographically secure.
|ScramFS Report Card|
|1. Protects data “at-rest” – in the cloud and locally|
|2. Protects data “in-transit” from end to end|
|3. Encrypts files fully, not partially|
|4. Provides client-side encryption with user-held keys|
|5. Provides automatic and transparent encryption and decryption|
|6. Encrypts a wide range of data|
|7. Integrates easily with existing processes|
|8. Provides vendor-neutral support for different types of cloud storage|
|9. Allows you to copy encrypted data from one place to another|
|10. Enables developers to protect primary copies of data – implementing security by design and default|
|11. Enables system administrators to protect secondary copies of data|
|12. Provides long term security|
|13. Is a reputable, high quality solution|
|14. Provides cryptographic security at cloud proportions|
|15. Provides integrity checking of encrypted data|
Tools in ScramFS that help with GDPR compliance
ScramFS Command Line Interface (CLI) – allows system administrators to integrate encryption into everyday processes, such as encrypting backups, transfers, and migrations.
ScramFS Application Programming Interface (API) – allows developers to integrate encryption into their applications. This is especially important in achieving Article 25 (privacy by default), as it enables developers to encrypt data as soon as it is collected and stored.
ScramExplorer (GUI) - allows all users to encrypt by drag and drop, via a file system browser that's similar to Windows Explorer and Mac Finder.
It's easy to get started with ScramFS
Thanks to ScramFS, encryption is no longer difficult, expensive or complicated:
- Easy implementation: thanks to its different CLI, API and GUI interfaces
- Lightweight: ScramFS is a single installable software package that requires no additional servers, hardware or software infrastructure.
- Scalable: start small and grow big, there’s no limit to how much or little data that can be encrypted.
The first step towards implementing encryption for GDPR compliance is taking advantage of the ScramFS 30 day free trial. We usually recommend that organisations start with a proof-of-concept project to get familiar with the technology, before rolling it out further. To get started, simply go to the ScramFS Download page and follow the prompts.