Part 5 of the series picks up from A.10 Cryptography. Click here to see the other posts in this series.
Cryptographic Controls
The ISO 27701 Standard points out that some jurisdictions require encryption to be used on some forms of PII data.
It then provided additional guidance that data subjects should be informed when encryption is used to protect data subject data.
I don’t like this statement. It appears to perpetuate the myth, that if data was encrypted, then it is secure and cannot be read. This only applies when valid access credentials are not stolen too.
So your laptop is reasonably safe providing you do not have your username and password written on a post-it note stuck to the screen of the laptop.
But if you have gained privileged access to systems by hacking into them, no amount of encryption will help if you have the valid credentials to read this data.
Your database may be encrypted at rest, and your data transmissions may be encrypted across the network, but if you have valid access to the database and have sent it a query, you will get the data you asked for back, unencrypted.
You should have a process that ensures that data availability is not put at risk through poor key management practices. Any errors in cryptographic key management may have a dramatically bad effect on your data availability.
Example of Key Management Issue
Fred is receiving some sensitive data from a client. Fred is sensible and security-aware, so he asks the client to encrypt the data before sending it to him. He also asks the client to send the key across to him by different means, let’s say by SMS to his phone.
Fred receives the data and the key and all is fine. However, if there is no mechanism for the key to be retained against the file or a process that forces the file to be stored unencrypted, eventually we get to a point where Fred will not remember the key and the availability of the data is lost. This is particularly acute when employees leave the organisation. It’s Fred’s phone. The key is in Fred’s SMS messages. Fred finds another job. No-one else knows the key for the file. Data availability is lost. This is a Data Breach.
Before you start encouraging security behaviours, that are for the best of intentions trying to protect data in transit, you must have a process in place to manage keys appropriately.
Physical Security Perimeter
The ISO 27701 Standard has very little to say in this area until we get to asset disposal.
However, there are specific requirements that are needed with regard to Data Protection whilst we are trying to protect data physically.
Several physical security controls capture personal data.
CCTV monitors your access into and out of the company building. Electronic access control records when you enter or leave the building.
This data could be used inappropriately. You could, for instance, use the data to check if an employee is coming to work on time, as you suspect they are often late for work. And whether they are working a full day, by comparing access into and out of the building. Or how long employees are taking for lunch.
Employers must show how these physical security controls will be used, and how they will protect the rights of employees captured daily by the systems, and not use the data for anything that the system was not intended for.
Securing Offices, rooms and facilities
You should ensure that any additional protections required by your data classification are provided. If your security policy says that high-risk data must be stored in lockable filing cabinets, then those facilities need to be provided in the locations where that work is undertaken.
Secure Disposal or re-use of equipment
The ISO 27701 standard says that any unmarked device should be treated as though it contains PII. All removable media should be disposed of appropriately and hard-copy should be shredded. This should already be your default process under ISO 27001. If it has no label, then assume it is sensitive for handling purposes.
Operations Security
The ISO 27701 Standard chooses to make no additional guidance recommendations against this section.
Operation Security requires the documenting of operational procedures to allow a capability maturity to exist within the function. It should be a standard review process for any operational documentation that they are reviewed from the perspective of personal data minimisation.
It should be shown that as part of the review process for each operational document, a data minimisation exercise is done to remove excess personal data that is not required for the successful functioning of the operating procedure.
Good Documentation Walks
Documentation has a propensity to leak, especially good documentation.
It could be shown to clients who want evidence of the existence of a process.
It could be removed from the organisation by a particularly proud individual that helped to create it, under the misapprehension that it in some way belongs to them.
You should always assume that if it is worth taking, it will be taken. Where you have tools like DLP (Data Leakage Protection) to assist in tracking this movement, these should be utilised so that you can intercept this activity.
Operational Procedures can become a list of names and mobile phone numbers very quickly.
Take care to obfuscate this data where it does not impede the operational process.
An incident management call tree needs to have names, roles and contact details. Many other operational processes do not.
Backups
The ISO 27701 Standard writes a lot of additional guidance for this section.
Data retention of PII and the storage of such data in Backups should be understood and appropriate processes created to manage any potential data integrity issues.
Under the GDPR and several other privacy legislations globally, the data subject/consumer has the right to have their data deleted in some circumstances.
This could lead to some concurrency issues as follows:
- Data Subject requests removal of their data. Organisation complies with the request and deletes it.
- File system or database corruption issue discovered that requires data to be recovered from backup, which recreates the Data Subjects data that you had previously deleted.
So the Data Subject thinks it’s deleted because that is what you have told them, but their data is back on the live system.
There should be processes in place to ensure that any data deletion or rectification work done at the request of the data subject, can be re-done should it be required as a result of backup restoration activity.
Information Transfer
There currently exists a mismatch is requirements between information security and privacy on this subject. ISO 27001 wants to ensure that any data sent between two parties arrives as it was sent, not interfered with and protected until it reaches its destination.
Information Transfer in the Privacy domain means something very specific and it is different from what is described above.
Information Transfer in a Privacy context is about ensuring that the organisation you are sending the data to, has compatible controls to ensure the protection of the data during its lifetime with that organisation. It is not about protection during transit. It is about the protection of the data completely, and to provide it with a specific set of protections as defined by the Transfer Agreement.
ISO 27701 misses the opportunity to explain this nuance. Whilst the guidance given in ISO 27701 does indeed cover the transit parts of the information transfer, it doesn’t apply any additional guidance to what is expected when transferring PII outside of the organisation, potentially to another legal jurisdiction.
Additional guidance should explain how a data transfer agreement differs from the original context of information transfer in ISO 27001 and should ensure that this distinction is clear when controls are applied.
A Process needs to exist that creates and maintains Data Transfer Agreements with all external organisations that require one as part of legislative requirements.
Secure Development Policy
This section of the ISO 27701 standard is actually quite complete. It refers to Privacy by Design and Privacy by Default. It also captures the basic principle of data minimisation. The same is true of the Secure Systems Engineering Principles section.
Protection of Test Data
This section has some rather strange additional guidance. Firstly, it insists that synthetic test data should always be used. Where that is not feasible, then controls equivalent to the production system should be used to protect the test data in the test system. Where that is not possible, a risk assessment should be conducted and mitigating controls applied.
The reality is that the opening two gambits only obscure the appropriate solution, which is: Always conduct a risk assessment so that appropriate mitigating controls can be applied.
If the appropriate mitigating control is to use synthetic data, that is a valid outcome of the risk assessment. But it is concerning that controls are recommended without appropriate context, when the correct solution is to take a risk-based approach to find the appropriate solution.
Response to Information Security Incidents
The wording in this section is quite loose and does not adequately distinguish between the words “incident”, “event” and “breach”.
It does cover the basic requirement that your incident process must take account of whatever legal and regulatory requirements you have for PII, in whatever jurisdiction you are under.
Primarily these are notifications to authorities and to data subjects of a breach, where this is necessary.
Redundancies
The original scope of this clause was to protect information processing facilities and systems from single points of failure. It should be extended to include data redundancy and ensuring that a single point of data availability does not exist that could cause a data breach, through the loss of data availability.
This covers the standard additions to clauses the pre-exist in ISO 27001. So are we finished? Unfortunately not. The second half of the ISO 27701 standard goes on to add specific controls for specific data processing requirements and we will start on those in part 6 of the series.
