04. Aug 20
ISO/IEC 27001 - understand our way of thinking
![](/media/hminmy3v/pexels-burst-374103.jpg)
We have prepared this practical example of the implementation of ISO 27001 to our customer support as it will give you:
- the insight about how we approach information security in this seemingly simple example
- that ISO 27001 is not just a collection of dead letters, but a way we really operate for the benefit of both business of our customers and us
- that ISO 27001 is one of the tools to grow your business and consequently our business
If you have not read the resource about our ISO/IEC 27001 conformity and compliance, please do so, before reading this as this example will make more sense.
In this example, the scope of ISO 27001 implementation is customer support. For the sake of brevity, we'll focus on one business event: sending opening a case by sending an email to our helpdesk.
The security event is described by the following bullet points:
- Anna Smith is employed at ACME Shipping Ltd. as an IT administrator
- ACME Shipping Ltd. is a parcel delivery company based in London and our customer that uses our InfraNS product to announce shipment arrival to the recipient.
- Anna Smith sent a panic-driven email to our helpdesk saying: John Jones has received an SMS message to his mobile number +44-555-3004-833 that is intended for him saying "Dear Martha Evans, your shipment from Fertility Clinic will be delivered today between 12:00 and 14:00 to the address 9362 Park Lane, London, SW59 4RX instead to number +44-555-5361-717" saying that received SMS was intended for John Jones and that system must be malfunctioning.
- Anna Smith raises a GDPR privacy concern and CC's her boss James Taylor and Data Protection Officer of ACME Shipping Ltd. named Robert Walker and asks that we check if any other messages have been sent to the wrong recipient
- The email that Anna Smith has sent's has received our internal helpdesk case number #1337
Let's look at the information we learned from case #1337:
- 5 different names: Anna Smith, John Jones, Martha Evans, James Taylor, and Robert Walker
- Anna Smith, James Taylor, and Robert Walker work for ACME Shipping Ltd.
- The mobile phone number of one John Jones is +44-555-3004-833
- The mobile phone number of one Martha Evans is +44-555-5361-717
- One Martha Evans resides at the address 9362 Park Lane, London, SW59 4RX
- One Martha Evans should receive a shipment from Fertility Clinic
Let's look at the potential implication of an event described in that case:
- Due to the malfunction of the messaging system that we provided to our customer has caused that an unknown person John Jones to receive the home address of one Martha Evans and that Martha Evans has business with Fertility Clinic, potentially learning about her health information.
- Such an event could be unauthorized disclosure of personal data of one Martha Smith
- Such an event can have legal and reputational consequences to ACME Shipping Ltd.
- Such an event can have legal and reputational consequences for us
- Such an event could mean financial damages and statutory fines for both ACME Shipping Ltd. and us
What could be our potential steps if we haven't implemented ISO 27001 standard:
- our support agent can simply open high severity bug just by copying and pasting the whole email from Anna Smith to a bug description and escalate it as the potential implications are extreme
- following our agent's copying and pasting Anna Smith's email in its entirety to a bug description our developers would learn personal information about John Jones and Martha Evans, which they do not need to perform the task further disseminating personal information even worsening the possible consequences, causing further unauthorized disclosure of information and not following the principle of data minimization that GDPR mandates
Because we have implemented ISO 27001 in our customer support process Anna Smith could have sent an email stating just this:
"Message identifier f880d0fb-64b5-4c1a-8025-a6a241d6c632 has been sent to 1jnegOg5j0i+qlqbZPTIFqrBCg1gZZ3MXxxKuW3noMc= instead to 9cnTZgFzyWrXObjDL74slb4OS0gPm3nL18a3zerIHXc= causing potential unauthorized disclosure of personal information. Please investigate, report to us the root cause and check if this is an isolated event or are there more events like this."
If support case #1337 was reported like this:
- We would receive minimal information to identify the message to perform a task
- Anna Smith wouldn't disclose what type of message is she referring and by that adding to the security of her support ticket
- Anna Smith wouldn't send unnecessary information like the name, address, and mobile phone number of one Martha Evans or the name and phone number of one John Jones, and therefore not processing data unnecessarily and respecting law mandated principle of data minimization
- Anna Smith wouldn't send sensitive information (only phone numbers) encrypted and therefore using reasonable protection of data mandated by law
For the sake of this example let's say that we investigated and have undeniably concluded that:
- Martha Evens has actually changed the mobile phone using Shipping Manager, as permitted
- That Anna Smith has failed to check if such change actually happened, even though she had means
- Martha Evens has mistyped her phone number when she was changing and by chance that was the phone number of John Jones and therefore she is responsible for information disclosure
We would report back our findings to Anna Smith. However, is our job done here? If because we follow ISO/IEC 27001 requirements we know that:
- security event has occurred
- there is a risk of some kind of event happening again, so the risk has to be further evaluated and decided upon the treatment of such risk
Because we understand that ISO 27001 has a risk-based approach to information security we know that risk treated with so-called controls. Controles are synonyms for safeguards or countermeasures and represent means of managing the risk, including policies, procedures, guidelines, practices, or structures which can be administrative, technical, managerial, or legal and can be generally classified as:
- Deterrent, reduce the likelihood of risk by discouraging someone from doing something risky
- Preventative, stop the risk from occurring by reducing risk consequence value (either by reducing the likelihood or severity of an event)
- Corrective, reduce the effect of risk after risk has taken place
- Detective, discover risks and trigger preventative controls
The root cause of the unauthorised disclosure of personal data of one Martha Evans is mistyping her mobile phone number. How do we prevent that?
In order to prevent that we analyzed the process of how a user changes his or her mobile phone number used for shipment notifications and for the sake of brevity we will present one solution for each control class:
- Deterrent control: implement a warning in Shipping Manager that would say: "Dear user is +44-555-3004-833 your new mobile phone number. Please read it carefully as typing the wrong number might cause that you don't receive the messages or that your personal data could be disclosed to someone else, providing that this new phone number belongs to somebody else"
- Preventative control: implement a mechanism of identification - verification key pair process that consists of the user receiving SMS with an identification key to an already registered phone and SMS with a verification key to a new phone and enter both in the Shipping Manager web form, thus confirming new phone
- Corrective control: add a sentence to SMS that says: "If you are not intended recipient of this message, you are required to delete it under the penalty of the law"
- Detective control: implement automatic risk scoring criteria of changing a phone number for every shipment that would decide what preventative measure should be used, if there are multiple preventative controls available
Of course, different measures most often cause additional costs. In the above-mentioned example, deterrent control causes the cost of development, preventative control causes cost of development presumably higher than deterrent control, corrective control causes the recipient of the SMS would most likely receive 2 SMS messages causing SMS costs to rise, detective control causes cost of development that is certainly higher than preventative control as it assumes that at least one preventative control is developed and scoring mechanism should be developed as well.
Risk treatment could also be to do nothing (for instance, the event happens so rarely that the cost of controls is unjustifiable).
Those controls would decrease the likelihood that our helpdesk support staff receives excessive and therefore treat the risk. Does it stop there? No. Even if the above-mentioned controls are implemented, what is stopping Anna Smith to open a case just like #1337 transmitting the same excessive amount of personal information to us?
Following the requirements of ISO 27001 and GDPR, if Anna Smith was to send an email with excessive personal information, ACME Shipping Ltd could implement controls on their side following those examples:
- Deterrent control: issue guidelines about how to submit such helpdesk case and see that all relevant staff of ACME Shipping Ltd. adheres to it under penalty of employment contract termination
- Preventative control: implement the mechanism of outbound emails to be sent to our helpdesk if they do not detect personal information by implementing data classification that doesn't sent and email if such information is detected but notifies the sender.
- Corrective control: add a sentence to all outbound emails that say: "If this email contains personal data that is not necessary for you to perform the requested action, you are required to delete it under the penalty of the law"
- Detective control: implement automatic risk scoring criteria of sending an email to our helpdesk that would decide what preventative measure should be used, if there are multiple preventative controls available
Coming back to the scope of implementing ISO 27001 in the customer support process we could do as follows
Following the requirements of ISO 27001 and GDPR, if Anna Smith was to send an email with excessive personal information, ACME Shipping Ltd could implement controls on their side following those examples:
- Deterrent control: educate helpdesk staff what is excessive personal data and mandate them to formally warn the DPO that Anna Smith is acting against GDPR regulations
- Preventative control: implement a mechanism that support cases can be opened by a web form with a guided wizard that would prevent input of any excess information
- Corrective control: educate helpdesk staff that classifies if personal data amount is excessive and implement that Anna Smith is notified with email: "Because your email contains excessive personal information we have permanently deleted it from all our systems and your support case has not been opened. Please submit the helpdesk case using guidelines in the attachment"
- Detective control: implement automatic risk scoring criteria of all inbound email to our helpdesk that would decide what preventative measure should be used, if there are multiple preventative controls available
This blog post is made available by the author who is a licensed ISO 27001 Internal Auditor and has extensive experience in managing privacy. This blog is intended for educational purposes only as well to present views of the author how business understands the law, not to provide specific legal advice. By using this blog site you understand that there is no attorney-client relationship between you and this blog publisher. The blog should not be used as a substitute for competent legal advice from a licensed professional attorney. Views of the author do not necessarily represent views of Infranet (see our incorporation details) nor does it constitute a promise. Photos: Pexels.com
Recommended blog posts
-
14. Aug 20
How to know if data is personal data: avoid rookie GDPR mistakes
What data should be designated as personal data and what does it mean to directly identify an individual or make identification indirectly? How to recognize personal data when it's not apparent that data actually should be dealt with as if it is personal and enjoy the full protection of GDPR. Why isn't more people discussing the context of data processing? Some of our views in this blog post might make you think twice.
-
06. Aug 20
Cookie consent and GDPR - avoid common mistakes
What data should be designated as personal data and what does it mean to directly identify an individual or make identification indirectly? How to recognize personal data when it's not apparent that data actually should be dealt with as if it is personal and enjoy the full protection of GDPR. Why isn't more people discussing the context of data processing? Some of our views in this blog post might make you think twice.
-
04. Aug 20
ISO/IEC 27001 - understand our way of thinking
When it comes to information security our goal is that you understand our way of thinking. We believe if you understand how we think that you'll better understand the real importance of following ISO 27001 standard and all benefits it brings to your business.
-
11. Sep 20
Avoiding breach of sensitive personal data
A personal data breach can occur inadvertently, not because of negligence, but because analysis sometimes shows that certain data is not personal data, whereas, in fact, it is. Our view is that if designating data as personal depends on many factors, mostly on the context of data processing. Handling special categories of data requires extra care.
-
09. Sep 20
Indirect identification of an individual using personal data
GDPR just mentions indirect identification as a method of identifying a person but leaves everyone in the dark about the rest. It's not only about if one wants to identify someone, but it also's about the intrinsic value of data and its inherent ability to facilitate the process of identifying someone, regardless if one intends to do it or not.
-
02. Sep 20
Direct identification of an individual using personal data
What is direct identity confirmation? How to navigate through GDPR, as it broadly reads: "identifiable natural person is one who can be identified, directly or indirectly" without mentioning a word what is direct identification and what does it entail. The authors' views might help you shed some light on it.
-
30. Aug 20
Identification of an individual using personal data
How to confirm the identity of a person? What are the principles of identity confirmation and their relationship with authentification? How to be GDPR compliant, prevent identity theft and personal information data breaches? This blog post summarizes some of the GDPR topics we were tackling at a high level. If you are just embarking on a GDPR ship with a demanding project, hopefully, our views can make your journey faster and more cost-effective.