ISO 27001:2022 – 8.12 Data Leakage Prevention

What do we mean by risk mitigation?

Before I get stuck into this week’s topic which looks at ISO/IEC 27001:2022′s new 8.12 Data leakage prevention control, I wanted to sidestep into discussing an important topic, especially in light of the impact this control can have on your business.

What do we really mean when we say “we will mitigate a risk”? The dictionary defines mitigate as:

“make (something bad) less severe, serious, or painful”

This is a critical concept to understand in the context of risk management and control implementation. The keyword in the definition above is ‘less’. If we decide to mitigate a risk we are looking at reducing it to an acceptable level, in line with many factors, such as our risk appetite and risk tolerance. We are not trying to remove the risk completely. If we did, our risk response would be ‘avoid‘ not mitigate, which means we no longer take the action that puts us at risk, removing the risk entirely. But mitigation is there to reduce the risk to what the business deems an acceptable level. Now we have that clear, we can discuss this week’s control 😀

What is data leakage?

When we talk about data leakage, we are talking about the exposure of sensitive information to anyone that is not authorised to access that information.

There are three main categories of data leakage:

Unintentional or inadvertent data leakage: This is where data has been accidentally shared with or exposed to someone that is not authorised to view the information. This is commonly the result of human error, such as a misconfiguration in a system or someone sending information to the wrong recipient in an email. Just look at the latest OAIC Notifiable Data Breaches Report. 25% of breaches were human error and 42% of these were PII sent to the wrong recipient in email.

Malicious data leakage: This is an intentional act where an insider within an organisation, or an external party, gains access to data and leaks it for some type of personal gain, or with malicious intent. Think of the ransomware attacks we see every day, where a malicious threat actor compromises an organisation and exfiltrates data to sell on the dark web or extort the victim organisation with. This category also covers insider threats. Examples are WikiLeaks, Edward Snowden, or other high-profile insider exposures you have heard of in the news where information was leaked for various reasons. Whatever their reason and whatever your views are on whether they should or shouldn’t have done it, it was intentional and against the wishes of the information owner, so falls under this category.

Third-party data leakage: While third-party exposures could fall under either of the above, I like having this in a third category as it’s a different threat and risk profile, with different controls needed to reduce the risk. It needs to be treated differently, generally through contractual agreements and monitoring. Third-party data leaks involve the leaking of sensitive information you have entrusted a third party with, such as information hosted within a cloud service provider.

What is data leakage prevention?

Plain and simple, data leakage prevention is exactly what it sounds like. It’s about implementing controls, whether process, technical or both, that reduce the risk of a data leak. It’s a complex topic and one that isn’t easily solved. If you’ve been around as long as me you would remember the first data leakage prevention (DLP) tools hitting the market in the very early 2000s. Many organisation’s leapt on the concept and we saw most organisations fail or get little value for their investment as, like most cybersecurity risks, it’s not for technology to solve alone.

There is no policy process out there that will solve this problem by itself, and no matter what any vendor tells you, there is no silver bullet technology that will solve the problem either, which is why my introduction about reducing risk to an acceptable level is critical in this discussion. As I said it’s a complex problem and requires a multi-faceted approach combining both process and technical controls. So let’s get into it!

What is ISO 27001 annex A 8.12’s expectation?

The new 2022 version of ISO/IEC 27001 added eleven new controls within the Annex A component of the standard, and one of these, 8.12, addresses data leakage prevention. Even though the new version of the standard calls Annex A a ‘controls reference’ versus the 2013 version which calls it ‘control objectives and controls’, the structure and wording of the controls in both versions really define an objective for the control. They are intentionally broad so you can implement controls relevant to your risk and your business, as long as they satisfy the objective. As I’ve mentioned before, this means you can use other control frameworks apart from 27002 if you so wish.

Annex A 8.12 Data leakage prevention states:

“Data leakage prevention measures shall be applied to systems, networks and any other devices that process, store or transmit sensitive information.”

As I said in our other ISO articles, this is very broad and doesn’t give much away, which is why we have 27002 which provides the purpose of the control and also provides implementation advice. By leveraging 27002 you get a much better understanding of the control’s intent.

ISO 27002 data leakage prevention implementation advice

ISO/IEC 27002 adds a purpose to the control:

“To detect and prevent the unauthorized disclosure and extraction of information by individuals or systems.”

Extraction is an interesting term, and also a critical one to pay attention to if you want to actually provide value from implementing this control. Extraction fits within the malicious data leakage category. It has intent, so rules out accidental exposure. I prefer to use the word exfiltration, which is basically the same thing, but honestly, exfiltration sounds way cooler 😂 This is the act of someone taking data away from its authorised place of storage. Think of a threat actor exfiltrating all your customer data before sending you a ransomware demand. Or a disgruntled employee taking your customer list or trade secrets before being exited or quitting their job. There are actually some interesting statistics around the exfiltration of data by employees prior to retrenchment that I posted about on LinkedIn earlier this year, but that’s for another discussion.

Exfiltration is a serious problem. I guarantee most of you have seen data breaches where they talk about terabytes of data being stolen and you say to yourself “How did this not get flagged or come up in someone’s alerts?” And here you have one of your reasons why this new control exists.

ISO/IEC 27002 provides three areas to ‘consider’ to reduce data leakage risk. Always note the terminology in these standards. Consider is not prescriptive. You should look at it and assess its relevance to your organisation.

Identifying and classifying information

This is priority number one, and if you are already certified to, comply with, or align to ISO/IEC 27001, either the 2013 or 2022 version, you should already have addressed this. Even if you have zero interest in 27001, if you haven’t done this yet, you should put this at the top of your list. How can you protect your information if:

1. You don’t know what you have
2. You don’t know how sensitive or important it is to the business
3. You don’t know all the places it is stored, processed or transmitted

If you can’t answer these questions when talking about your business information, how can you possibly know what controls to implement to keep your data secure? You need this knowledge to identify risk and then make informed business decisions to reduce that risk.

Monitoring channels of data leakage

If you haven’t identified and classified your information, I’m sorry, but you won’t be able to address this area. And even when you have addressed what information you have and where it’s located, you won’t be able to address all the potential channels it can be leaked without an organisation-wide risk assessment.

The reason I’m making this statement isn’t because Morrisec performs risk assessments (and they are awesome btw 😉), it’s from decades of experience actually performing these assessments. In most cases, the organisations we deal with, without ever performing a risk assessment, can already tell you what a whole stack of their risks are. The value in having someone with a lot of experience in this area come in and perform a risk assessment is to uncover all those areas you’ve never even thought about, or just don’t know about.

One of the most common root causes of information security risks, especially around insecure management of and potential exposure of information, is personnel performing tasks insecurely. I was about to write ‘doing the wrong thing’ but that would be unfair as 99% of the time, while it may be the wrong thing to me as someone who works day in and day out in infosec, it isn’t the wrong thing to them. They are doing what they need to do to be efficient and get the job done. They don’t realise a shortcut they have taken to complete their work faster exposes their organisation to excessive risk. This is why we perform risk assessments. It allows us to identify these risks that no one knows about, fix them, and educate people so they know how to work more securely.

I got a bit off track there but it comes down to the fact that you can’t monitor channels of data leakage until you know what all the channels are. Without a risk assessment, you will only be monitoring the channels you know about, and missing all those other ways your personnel are using, and potentially exposing, data.

ISO/IEC 27002 gives examples of email, file transfers, mobile devices and portable storage devices as potential channels to monitor. All these areas, and more, should be addressed in your data lifecycle policy. Your data lifecycle policy, which should contain your information classifications, will also define where it is acceptable to store different classifications of data, and rules around their secure transmission. As a simple example, internal classified information may be fine to send via email, but it may be a hard no to sending confidential information via email. Generally, you will have some type of matrix within your policy to define these requirements. These will then provide you inputs to going down the path of how you monitor and/or block certain information and channels.

Take action to prevent information from leaking

This is where you need to find ways to actually stop the leaking of information. This in itself is complex and sorry, I won’t be suggesting any technologies in this article. Reach out to me privately and I’m more than happy to discuss what I’ve seen working well within organisations I’ve worked with and are currently working with. One of the many great things about working for Morrisec is we don’t sell products, so you will get honest, unbiased suggestions based on real-world experience, not on-selling opportunities 😀 We also have a tonne of tips and tricks for mass classification of existing data, which can be a separate nightmare in itself and where many organisations struggle due to potentially decades of existing data.

27002 uses the example of quarantining sensitive information sent via email. This of course requires the above areas to be addressed. You need to know what is sensitive to your business, find all instances for that type of information, and then find a way to classify and label it so you can implement technical controls to do things like quarantine or block that data being sent out or exfiltrated from the business.

I could write 100 pages just on this section alone, and all the ways you can classify, label and block data across a multitude of channels. I could then write another 100 pages on how to bypass these controls. There is no 100% here I’m afraid, and I don’t advise you attempting to get there at the expense of your other controls.

Are you saying I should give up?

No!!! Why would you even think that? Geez!!! 😔

This goes back to my introduction which talked about risk reduction. I love the word commensurate when discussing anything within risk management. The remediation strategies and controls you come up with need to be commensurate with your business. The idea isn’t to reduce risk to zero. It is to reduce it to a level that is acceptable to the business.

I’ve discussed this before in other articles, but my first approach to risk management before you go implementing controls to fix the problem, is to reduce the scope of the problem. Work smarter, not harder! This will also reduce your cost dramatically when it comes to implementing controls.

If the problem we have is potential data leakage, how do we reduce the scope (size) of our problem?

1. The less sensitive data you have, the less data you have that can be leaked
2. The fewer places your data is stored, processed or transmitted, the fewer channels you have for leaking the data
3. The fewer people that have access to your data, the less chance of accidental exposure, insider threats, or external threat actors with access to compromised credentials

If you can address these three areas first, you have massively reduced your risk of data leakage long before you even start thinking about actual data leakage controls! And you will have improved your security posture as well.

How do I comply with ISO 27001:2022 Annex A 8.12?

So here is the section you’ve all been waiting for. If you skipped the previous section and jumped straight to here, go back one as that section I think is actually more valuable and provides a much greater ROI and risk reduction when it comes to data exposure than the control itself.

Here are my steps to follow to comply with this requirement, but also to provide tangible value to the business. Remember. ISO/IEC 27001 isn’t a box ticking exercise. It’s a way of life. No. Not really. I’m just tired and delirious and have way too much fun writing these articles 🤪

Locate and classify your information:

• Work out what types of data you have and what classification levels you will use. My suggestion is use as few levels as possible. The more you use, the harder it is for personnel to decide which level a piece of information falls into. 3 – 4 levels is ideal. I don’t suggest going above 4 for simplicity’s sake.
• Work out all the places each type of information is stored, processed or transmitted. You really need to perform a risk assessment to find out all the places you just don’t know about.

Next, reduce the scope of what you need to protect:

• Once you know what you have and where it is, address data duplication issues. That is, where there are multiple copies of the same data. Reduce what you have and you reduce what can leak.
• Address any over-collecting issues you may have. We love to collect data we don’t need. If you don’t need it for a business reason, don’t collect it.
• Get rid of data you don’t have a valid business reason to keep. Take a look at our 8.10 Data deletion article that addresses this exact issue.

Address how the data is managed and who has access:

• Ensure you have a data lifecycle policy in place that defines your classification levels and a matrix on acceptable places to store each type of data. Include authorised methods of transmitting that data, and specify ways that must not be used for certain types of data. This should also define what roles should have access to each type of information. Always follow the principle of least privilege.
• Label your information. This is a huge discussion itself. Look at ISO/IEC 27001 and 27002 5.13 Labelling of information for ideas, which talks about the use of metadata for digital assets.
• Ensure role-based access controls (RBAC) are in place that restrict access to those roles based on your data lifecycle policy and labels.

Now look at actual data leakage controls:

• Based on locations and channels used to store and transmit data, identify controls that are going to reduce the risk of data leakage, commensurate to your specific business risks. These should be a mix of both preventive and detective controls
• Preventive controls are there to prevent something from happening. For example, blocking a user from sending a confidential file in an email, or preventing a user from uploading a confidential file to a cloud service.
• Detective controls pick up when something is happening that breaks your rules. It doesn’t stop the event or incident, which is why you MUST have preventive controls, but it can help reduce impact and provide inputs into weaknesses that need to be fixed. An example is when I discussed terabytes of information being exfiltrated earlier in this article. Where a threat actor may have found a way around your preventive control and is uploading large amounts of information to a cloud service, a detective control will let you know it’s happening and if you can respond fast enough, you may reduce the exposure and overall impact.

I haven’t given you all the answers I’m afraid. As with most controls, how you go about reducing your risk is very dependent on your business. But I have given you some great ways to reduce your overall risk in this area. Sorry if you were hoping that I would point you to some technology that would fix this issue, but infosec is never that easy I’m afraid. Don’t get me wrong. There is some incredible tech out there and vendors I highly recommend in this space, but I wanted to keep this article away from specific products and focus on the various areas you need to address irrespective of where you land in that space, and what you have to have in place before you start looking at the supporting technical controls.

Reach out if you want to discuss further or need any help in any of these areas.