What is Data Masking?
ISO/IEC 27001:2022 introduces a new data masking rule under Annex A’s controls. It’s interesting that this control has taken so long to be added to ISO. When we look at other standards that address protecting data, such as PCI DSS, data masking has been a core control for decades. But as they say, it’s never too late 😀
So, what exactly is data masking and what is involved to perform this dark magic? Pretty simple really. It’s simply hiding data from those that are not authorised to view the data. To use a simple example, imagine a service desk operator that receives a call from a customer and brings up the customer’s record. Do they need to be able to see every bit of information on that customer? Not generally. A perfect example is their credit card details. It’s highly unlikely there is a reason to be able to view this information in its entirety. The same goes for other sensitive information such as a date of birth, driver’s license or passport number, unless they are used within caller verification questions.
This all comes back to basic security principles. One of the core tenets of information security is the principle of least privilege. A person should only ever have the bare minimum access they require to perform their job function. If they don’t need it, don’t give them access. This reduces your attack footprint and limits your potential exposure. With data masking, someone may have access to a customer record, but the fields within that record are limited based on what they need to do their job.
What is ISO 27001 Annex A 8.11’s expectation?
Looking at the new 8.11 Data masking control in the 2022 version of ISO/IEC 27001, we are provided with the standard short description:
“Data masking shall be used in accordance with the organization’s topic-specific policy on access control and other related topic-specific policies, and business requirements, taking applicable legislation into consideration.”
What’s interesting about this control is the reference to topic-specific policies on access control, other related policies, business requirements and legislation. What this is really saying is it is up to you as to what you mask, based on your specific business and your risks, including compliance risks. This provides flexibility, which is one of the many reasons I love ISO/IEC 27001 and why it’s an amazing standard if you understand how to actually implement it. It takes a risk-based approach to security and is not prescriptive. It’s not a box-ticking standard.
Compliance requirements your business may have need to be considered. For example, the Australian Privacy Principles are relevant if you are managing personally identifiable information (PII). If you store, process, or transmit credit card information, you have these requirements under PCI DSS but now ISO is also saying you need to do it.
Your access control policy and other policies you may have, such as a data lifecycle management or data classification policy, will dictate who has access and to what types of data. Data masking should now be used for restricting this information to those that are authorised. As with many of the new ISO/IEC 27001:2022 controls, you may find you already have this in place, and this may just formalise what you have always done.
ISO 27002 data masking implementation advice
Like I usually do, let’s look at ISO/IEC 27002:2022 as it provides a purpose and implementation guidance for ISO/IEC 27001. As with all other Annex A controls, you don’t have to use 27002 to satisfy the controls, you can use another controls framework, but it provides an excellent insight into what 27001 is looking for and if you are certifying to ISO, what you auditors are going to be looking for.
First up, 27002 provides an additional purpose:
“To limit the exposure of sensitive data including PII, and to comply with legal, statutory, regulatory and contractual requirements.”
Pretty simple and supports what our assumptions above already were. How great are we? See, this compliance stuff isn’t that hard 😀
Next up we have the guidance section which starts with:
“Where the protection of sensitive data (e.g. PII) is a concern, the organization should consider hiding such data by using techniques such as data masking, pseudonymization or anonymization.”
Woah there cowboy! Pseudonymisation or anonymisation??? When most people think of masking data they think of hiding data from view. A perfect example is the password field where you type in your password and (hopefully) all you see are asterisks. Your password is masked. Talking about pseudonymisation or anonymisation of data is going beyond what we generally think of when we discuss data masking as these involve modification of the original data, not just covering it up from view.
Pseudonymisation or anonymisation
Firstly, let’s clarify these terms. ISO/IEC 27002’s 8.11 reference gives us the definition at the end of the control under Other Information.
“Anonymization irreversibly alters PII in such a way that the PII principal can no longer be identified directly or indirectly.”
and
“Pseudonymization replaces the identifying information with an alias. Knowledge of the algorithm (sometimes referred to as the “additional information”) used to perform the pseudonymization allows for at least some form of identification of the PII principal. Such “additional information” should therefore be kept separate and protected.”
There is another critical piece of text under these definitions that is actually key to this whole requirement and honestly, should have been right at the top as the first paragraph in the Guidance section:
“Data masking is a set of techniques to conceal, substitute or obfuscate sensitive data items. Data masking can be static (when data items are masked in the original database), dynamic (using automation and rules to secure data in real-time) or on-the-fly (with data masked in an application’s memory).”
So here we have it folks. Conceal, like in your typical data masking, but also substitute and obfuscate. This gets a bit trickier to perform as no longer are you implementing simple things like a UI field showing asterisks instead of data, or access controls restricting users by database columns, you are manipulating and replacing actual data.
Securing Test Information
Do you want my opinion on why pseudonymisation and anonymisation have been added to the data masking control? Because of data used for testing purposes. The use of live production data for testing has always been an issue and hasn’t been managed well. Test information was addressed in the old 2013 version of ISO/IEC 27001 under 14.3 Test data. In the 2022 version, this has been shifted to 8.33 Test information and one additional bullet point has been added:
“d) protecting sensitive information by removal or masking (see 8.11) if used for testing;”
This has been long overdue and is why we are now seeing pseudonymisation and anonymisation in 8.11. Honestly, it would have made it way clearer and easier for organisations if 8.11 Data masking just addressed data masking and pseudonymisation and anonymisation were included within 8.33 Test information where it’s far more relevant as a control. It would also reduce many organisation’s requirements as a lot of companies don’t use test data so could have this excluded from their Statement of Applicability (SOA). We tend to see test data used most within organisations with a development function, which excludes a lot of organisations.
How do I comply with ISO 27001:2022 Annex A 8.11?
So how do we comply with all this without this control blowing out into a massively overengineered and costly undertaking?
First up, let’s go back to the original Annex A control in ISO/IEC 27001. The control states ‘in accordance with the organization’s topic-specific policy on access control and other related topic-specific policies, and business requirements, taking applicable legislation into consideration’. So once more, it is 100% up to you based on your business, the data you hold, how you use that data, and your risks.
27002 also states ‘Where the protection of sensitive data (e.g. PII) is a concern, the organization should consider…’. Note the two key parts here:
- Protection of sensitive data
- Should consider
You don’t have to implement pseudonymisation or anonymisation as a rule, but it should be considered as a potential control if it addresses the protection of sensitive data. If you have other controls in place and your risks are reduced to an acceptable level, you don’t really need to implement these additional controls. Just bear in mind while reducing any risk to an acceptable level for your business should be based on your risk appetite and risk tolerance, you don’t have this flexibility when it comes to “taking applicable legislation into consideration”. If you need to implement pseudonymisation or anonymisation to reduce risk to the level expected of your legislative or regulatory compliance requirements, you will need to go down this path.
One of my key recommendations to comply with this requirement, and a key principle that should drive anyone’s security strategy, is to reduce the scope of what you need to comply with and what you need to secure. That is, reduce the data you collect where feasible. If you missed my article on 8.10 information deletion a couple of weeks ago, I highly recommend reading it, specifically, the section titled ‘What you collect dictates your exposure‘. Organisations generally over-collect. Reduce what you collect, and you reduce the need to protect the data.
This control goes one step further and the reason it discusses pseudonymisation and anonymisation is it is trying to reduce the scope of data you collect, or more so, reducing the value of the data you have collected. If PII can’t be tied back to an individual or lacks the details to be used for identity theft and other uses, it has no value to a threat actor. If you are collecting PII and you can manipulate that data to remove its value to a threat actor yet still have value to your business, you are in the perfect place. An example is where you need statistical or demographic data. What are you trying to extrapolate from the data? It’s unlikely you need all data unmodified and the ability for it to be tied back to an actual person.
To comply with this requirement, without discussing methods for pseudonymisation or anonymisation as that’s a whole other article (but reach out if you want to chat) you will need to focus on a few key areas first:
- Identify your compliance obligations and specifically, requirements around the protection of personal and sensitive data. Few organisations I’ve seen have a comprehensive list of what compliance standards they must comply with, especially in the information security realm, let alone the details within those standards.
- Follow the principle of least privilege and only provide access to data that a person requires for their job function. If it’s data coming from a database for example, do they need access to data in every column of a table or only one or two? It’s very easy to provide too much access because it takes a bit more effort to define exactly what a role needs, but the payoff is worth the effort eg. Reducing exposure in a breach, and ultimately, cost to the business.
- When you know what your access controls are, they of course need to be implemented, but you also need to ensure the applications and systems you use support this type of granular access, as well as masking of specific fields within user interfaces.
Hopefully, this gives you a good idea of what this control is trying to achieve, how to comply, and how to get started on leveraging this control to reduce risk. It’s a complex topic, and if you want to discuss it further, please reach out.
0 Comments