DATA LEAKAGE PREVENTION · violation (also known in the context of DLP as an ‘incident’). DLP policy violations can be user or system generated (e.g. a finance system emailing

1 The enterprise DLP market is expected to grow at a compound annual growth rate of 16.28% between 2018 and 2023: Enterprise Data Loss Prevention Market – Industry Trends, Opportunities and Forecasts to 2023, https://www.researchandmarkets.com/research/npbpsp/global_enterprise?w=4.

2 Figures based on survey sample size of 147 ISF Members, correlated by ISF Security Healthcheck statistics.

Organisations handle a plethora of sensitive data, such as trade secrets, customer data, pricing lists, trading algorithms and acquisition plans. This data can be leaked to unscrupulous competitors, organised criminal groups and other entities via a multitude of channels, including email, the internet, portable storage devices and cloud services.

Data leaks can be expensive, harm an organisation’s brand and reputation, and diminish trust. Customers and shareholders alike expect organisations to take appropriate measures to properly safeguard their data and investment. A successful data leakage prevention (DLP) programme can significantly reduce these risks.

RESURGENCE OF DLPInterest in DLP technology quickly waned when it first came to market due to the complexity of deployment, cost of investment, and inability to demonstrate business value. However, cloud adoption, mobile computing and remote working, coupled with major data breaches and new regulatory requirements, such as the EU General Data Protection Regulation (GDPR), have prompted organisations to take a fresh look at DLP.

Meanwhile, DLP technology has matured and is steadily progressing towards a mainstream security control.1 DLP’s recent surge in popularity is reflected within the ISF Membership – to date, 42% of surveyed ISF Members have implemented DLP and a further 45% are either running a DLP pilot or planning for deployment.2

DLP CAPABILITIESIn today’s business environment, organisations handle a vast amount of data that is increasingly easy to access and share, and more vulnerable to leaking. DLP technology offers a set of capabilities to manage the risk of data leaks – but it has some limitations.

For instance, DLP technology can only detect sensitive data in a digital format and is used primarily to monitor conventional channels of data leakage, such as email, the internet and USB. Although DLP technology is evolving to protect newer channels, it does not capture all types of sensitive data or cover all conceivable scenarios of data leakage.

To prevent the actual leakage of data, DLP tools need to be carefully configured to block activities that put data at risk. However, many organisations are reluctant to enable the blocking functionality for fear of disrupting business operations. This can limit the effectiveness of DLP.

NEED FOR A HOLISTIC APPROACHThe full benefits of DLP can only be realised if organisations implement DLP for clearly defined purposes and in a structured, systematic manner that incorporates people, process and technology. ISF Members reported that DLP can be a success when approached as part of a dedicated programme for reducing the risk of data leakage.

Figure 1: Survey results of ISF Members who have implemented a DLP programme

72% achieved objectives

72% demonstrated risk reduction

57% delivered return on investment

Based on the experience of ISF Members, this report provides guidance on how to optimise a DLP deployment, describing the ten key attributes of a successful DLP programme. It emphasises that a focus on technology alone will likely lead to the relegation of DLP tools to shelf-ware.

DATA LEAKAGE PREVENTION

Information Security Forum2 Data Leakage Prevention

1 What is data leakage prevention?

Data leakage prevention (DLP) can be defined as the practice of detecting and preventing the unauthorised disclosure of data. Also referred to as data loss prevention and data loss protection, the main purpose of DLP is to ensure that specified sensitive data is not leaked. It can also be used to help prevent data being mishandled or improperly accessed. DLP can be broken down into the following three core activities:

IDENTIFY data to protect against leakage

There are many different types of information that are valuable to organisations (known as information assets) which need to be kept confidential (e.g. market strategies, payment card information, personal health information, source code, product designs and employee data). Information may exist in digital, physical or spoken formats.

MONITOR channels of data leakage

Digital data can leak through a variety of channels (also referred to as vectors) including email, social media and portable storage devices. Channels are monitored to understand data flows and detect activity that indicates the leakage of data. Some channels can be difficult to monitor due to their nature (e.g. verbal disclosure of information and printed documents left in an insecure location).

ACT to prevent data from leaking

There are a range of actions that can be taken to stop data from leaving an organisation (e.g. alert users to their risky behaviour, quarantine outbound email messages containing sensitive data, block the transfer of data to portable storage media, and locate office equipment in a physically secure environment).

DLP tools and related technologies are used to help perform these core activities, which are illustrated in Figure 2 and explored in more detail on the following pages.

Figure 2: Core activities of DLP

IDENTIFY MONITOR ACT

– Personal data

– Customer data

– Intellectual property

– Business & governance data

– Financial data

– Sales & marketing data

Email Internet Removable media devices

Collaboration platforms

Cloud Database/File storage

Printer/MFD File-sharing applications

Camera

+

ClipboardPaper Voice

Log Notify Block

There are an increasing number of technologies, which are labelled as DLP that vary in their capabilities and perform different aspects of DLP. The focus of this report is DLP tools, which are designed to identify data, monitor its usage and movement, and take actions to prevent data from leaking. DLP tools (also known as enterprise DLP) are usually offered as a comprehensive suite of products that cover multiple channels.

“DLP only protects what you tell it! Plan and understand the environment, have data classification and know what it is you are trying to protect.” – ISF Member

As an alternative to using DLP tools, organisations may choose to utilise DLP functionality embedded into other security products (e.g. secure web gateway, secure email gateway, email encryption and device control) or cloud-based services (e.g. Microsoft Office 365). DLP offered as a feature of existing products (also known as integrated DLP) is typically restricted in capability and may only protect a single channel.

Information Security Forum 3Data Leakage Prevention

DLP POLICIESTo monitor and control the flow of sensitive data, a DLP tool is configured using technical DLP policies. A DLP policy contains one or more rules, consisting of conditions, exceptions and actions against which data, files, document content and messages are evaluated to detect and prevent data leaks. Through DLP policies, organisations can define:

‒ what data can and cannot be sent, posted, uploaded, moved, or copied and pasted ‒ where data can be transmitted ‒ who can send and receive data ‒ how data can be shared.

Conditions instruct the DLP tool what data to look for and when to take action by defining the content to detect (e.g. type of data) as well as the context (e.g. file type, file size, sender or recipient). When data matches the conditions, the system reports a policy violation (also known in the context of DLP as an ‘incident’). DLP policy violations can be user or system generated (e.g. a finance system emailing payslips automatically). Exceptions may be added to exempt certain data or activity from matching the condition and triggering the rule.

Actions stipulate how the DLP tool acts to protect the content when the conditions are met (e.g. log the policy violation, notify the user, encrypt a file or block copy of data to clipboard). Different actions can be applied depending on the level of risk, number of matches within a given transmission or severity of the policy violation (e.g. transfer of 20 customer records versus 200 records; internal versus external sharing of data).

A DLP policy can apply to one or more channels of data leakage. It need not apply enterprise-wide; it may be more appropriate to limit its application to certain users, a user group or geographic region. Examples of DLP policies are shown in the table below.

DLP POLICY CONDITION EXCEPTION ACTION

Source code Detect content containing proprietary source code

Allow transfer of data to company X, selected to conduct a source code review

Block transfers containing source code (including web posti ngs, email messages and copy of fi les)

Credit cards Detect content that matches the credit card number, using a Luhn algorithm

None Quaranti ne data in cloud applicati ons, fi les and messages:

− send an email noti fi cati on to the user − allow the user to provide business justi fi cati on for release

Project penguin Detect content containing key phrase ‘project penguin’ and intended for an external recipient

Allow transfer of data to John Doe (external legal counsel)

Block transfer of content to external recipientsEncrypt email transmissions to John Doe

Medical records Detect content that matches words or expressions from a list of common medical conditi ons

Exclude emails marked as ‘personal’

Block transfers including copy of health data to a portable storage deviceDisplay on-screen noti fi cati on stati ng fi le transfer violates a specifi c DLP policy

DLP policies can be created by using predefined templates or building custom policies. Most DLP tools provide a library of predefined policy templates to detect data that is subject to regulatory requirements, such as the GDPR, the Payment Card Industry Data Security Standard and the US Health Insurance Portability and Accountability Act. Policy templates may cover industry-specific data that adheres to a standard format (e.g. credit card number or SWIFT code) and country-specific data (e.g. Canadian social insurance number, French passport number, Irish International Bank Account Number, New Zealand national health index number or UK driver’s licence number).

Other policy templates are more generic and designed for different use cases, such as protecting certain types of sensitive data (e.g. content classified ‘top secret’, information pertaining to oil drilling or software design documents). Tools may also include policy templates for detecting acceptable use transgressions (e.g. indecent images, profanities or racism) and employee discontent (e.g. distribution of a curriculum vitae).

Predefined policy templates should be customised to meet an organisation’s specific needs, providing a quick and easy starting point for deploying DLP tools.

A technical DLP policy is not the same as an organisational policy. The term is commonly encountered in DLP products as a central component of deploying the tool and is used throughout this report to refer to the configuration of rules for detecting and protecting data.


IDENTIFY DATADLP is intended to protect specific types of sensitive data rather than secure every piece of data handled by an organisation. For DLP to provide blanket protection of all data is not only an unrealistic ambition, but would be a resource-intensive task, irritate business users and likely result in a degradation of system and network performance.

Types of sensitive dataSensitive data is information that could cause harm to organisations if it were disclosed to unauthorised parties, for example, merger and acquisition plans, personally identifiable information, product designs, pricing models, source code and social security numbers. Data can be deemed sensitive for many reasons, such as regulatory requirements, internal policies and the potential impact of unauthorised disclosure. Surveyed ISF Members focused predominantly on protecting personal and customer data, as shown in Figure 3.

It is common for organisations to use DLP to detect and prevent the leakage of their mission-critical information assets (i.e. information assets of greatest value and would cause a major business impact if compromised). Refer to the ISF implementation guide Protecting the Crown Jewels for further guidance on approaches to securing mission-critical information assets.

Techniques for detecting sensitive dataIdentifying what data should be included within the scope of DLP is a core activity that can determine whether DLP delivers value and reduces the risk of data leaking. A DLP tool can only detect data if it is configured to look for that data. Deploying a tool that is incorrectly configured will result in the wrong data being reported, and potentially harmful leaks of sensitive data being masked, hidden or simply unnoticed.

DLP tools protect sensitive data held in a readable digital format. To protect sensitive information in physical and spoken formats, DLP tools need to be complemented by other security controls, such as procedures for the proper handling and disposal of information.

DLP tools typically incorporate different techniques to detect sensitive data (referred to as ‘content’). They are well-suited to finding explicit keywords or alphanumeric patterns within data but can fail when data is complex (e.g. scientific data sets) or purposely obscured (e.g. Zip files that can be compressed, encrypted and password-protected). Detection techniques commonly provided in DLP tools include:

Described content matching

Matches content using regular expressions, defined strings, keywords, patterns or dictionaries (a list of specific terms, keywords or key phrases). Instances of described content include credit card numbers, social security numbers, and files containing certain metadata such as a classification (e.g. confidential or secret).

Fingerprinting(Indexing)

Takes a cryptographic hash of a sample file or file contents to create a ‘fingerprint’. Content is then checked against the fingerprint for complete or partial matches (i.e. to detect either the complete text or excerpts that match the sample document). This technique can be effective for both structured and unstructured data but requires the ‘data sources’ (e.g. documents and files) to first be identified and prepared.

Machine learning(Statistical analysis)

Uses algorithms and statistical techniques to determine if content is similar to example documents, which are provided for the DLP tool to learn from as representative of the type of data to protect. Common use cases for this technique include source code, software design documents and other data that is not practical to fingerprint or difficult to describe with accuracy.

Optical character recognition(Image recognition)

Analyses image files (e.g. screenshots or scanned documents) and extracts text to find matches for sensitive content.

For global organisations, consideration should be given to how a DLP policy applies across multiple jurisdictions (e.g. using an alphanumeric pattern to detect sensitive data in one jurisdiction may cause benign information to be flagged as a policy violation elsewhere).

Figure 3: Types of data ISF Members protect using DLP

Financial

Business and governance

Sales and marketing

Intellectual property

Customer

Personal

66%

62%

51%

55%

80%

85%

82% of surveyed ISF Members found engagement with the business to be of high value for identifying sensitive data.

!


MONITOR DATA LEAKAGE CHANNELS There are multiple channels through which sensitive data can leave an organisation. For instance, data can leak via email, webmail, instant messaging, HTTP/HTTPS, file transfers, wikis and blogs. It may also be exposed to unauthorised entities when it is transferred to portage storage devices (e.g. USB), uploaded to cloud storage services or stored in unencrypted folders with no access control. By monitoring data leakage channels, organisations can establish how data is being used, understand the risks to their data and detect potential leaks.

Coverage of data leakage channels A DLP programme should ideally address all channels of data leakage but monitoring every channel can be an onerous task in terms of financial cost, resourcing and impact on systems performance. Consequently, leading organisations prioritise those channels where reducing occurrences of data leakage delivers significant benefit to the organisation or can demonstrate value most quickly. Figure 4 shows the channels of data leakage covered by the respective DLP programmes of surveyed ISF Members.

Figure 4: Channels of data leakage protected by surveyed ISF Members

0% 20%10% 30% 50% 70% 90%40% 60% 80% 100%

Voice

Physical information

Cameras

Office equipment

Screen capture

Portable storage devices

Enterprise database and file storage

External file-sharing applications

Collaboration platforms

Cloud services

Internet usage

Corporate email

Yes Scheduled Under consideration No

The findings depicted in Figure 4 show that most organisations focus on email because it is perceived to be one of their primary channels of data leakage and the easiest to protect using a DLP tool. New and emerging channels (for example mobile devices containing high-resolution cameras) are relatively poorly covered, illustrating potential gaps in channel coverage.

Monitoring the insider threatDLP tools are primarily intended to mitigate insider threats causing data to leak, whether that be theft of data by a disgruntled employee, intentional misuse of data, human error or negligent behaviour. For instance, ISF Members reported that monitoring email revealed both malicious activities as well as accidental data leaks by well-meaning employees (e.g. mistakenly sent an email to the wrong recipient).

DLP tools themselves lack insight into the business context or motive of users to distinguish between the different types of risky behaviour. As a consequence, some level of review and analysis will be required to identify the root cause of policy violations.

Refer to the ISF briefing paper Managing the Insider Threat for further details about the three types of risky insider behaviour.

Figure 5: Three types of risky behaviour

Conscious decision to act

inappropriately

Motive to harm

MALICIOUS NEGLIGENT ACCIDENTAL

No motive to harm

No conscious decision to actinappropriately


ACT TO PREVENT DATA FROM LEAKINGDLP prevents data from leaking by intervening with the use or movement of data to address risky behaviour and compensate for poorly secured business processes. There are a range of actions that can be taken to improve how users handle data and to stop attempts to exfiltrate sensitive data. Some actions are applied by DLP tools, while others involve the use of management or physical security controls (e.g. clear desk policy, double packaging to protect physical information in transit, physical protection of hardware and office equipment).

DLP tools should be not be treated as a long-term remedy for insecure business processes.

Types of actionA DLP tool can respond to a policy violation in one of three ways: log, notify or block (referred to as ‘modes’). Each mode should be enabled sequentially to ensure DLP policies are enforced appropriately and do not disrupt business operations.

“Start with monitoring/detecting before implementing any protective controls.” – ISF Member

In log mode (also known as monitoring), policy violations are recorded in log files, allowing for analysis and investigation. The individual responsible for the policy violation is not notified.

Once a policy rule has been fine-tuned and is delivering the required results, notifications can be introduced to advise individuals that they violated a DLP policy. To compel a change in user behaviour, a copy of the message may be sent to the individual’s manager. Types of notification include:

‒ sending an email to notify the user that their behaviour breached corporate policy but still permit the activity with guidance on approved handling of data

‒ presenting a pop-up warning with an option for the user to cancel the data transfer.

Blocking is the third type of action that can be applied in response to a policy violation (e.g. email containing credit card data, external file-sharing of source code or instant messaging of medical details). It can be divided into three categories: hard block, soft block and other actions to remediate incorrect handling of data, as shown in the box below.

Hard block, for example: ‒ block transfer of email message or file ‒ disable download, copy or print options ‒ delete attachment or file.

Soft block, for example: ‒ move file to another location ‒ quarantine email message pending business justification for release

‒ redact sensitive data in web post or email and allow transfer.

Other actions to remediate incorrect handling of data, for example:

‒ add visual tag ‒ change access controls to restrict access to the file

‒ encrypt file or message.

Blocking

Figure 6 shows the common actions taken by DLP tools, which surveyed ISF Members apply to data in motion, in use and at rest. These three states of data are explained on the following page.

Figure 6: Common actions taken in response to policy violations

0% 20%10% 30% 50% 70% 90%40% 60% 80% 100%

Cancel or delete

Prevent download,copy or print

Redact

Block

Quarantine

Notify

Encrypt

Log

Data at rest Data in motion Data in use Not performed


DLP TECHNICAL ARCHITECTURE DLP tools apply different techniques to monitor data depending on whether it is in motion over the network (also known as data in transit), in use on endpoints or at rest in storage, as outlined in the table below.

STATE OF DATA DESCRIPTION MONITORING TECHNIQUE

Data in motion Data that is traversing a network, such as the internet or a private network (e.g. local area network).

DLP tools can monitor network traffic through network sniffing and deep content inspection to identify sensitive data travelling via a variety of means including email, file transfer and HTTP (web).

Data in use Data that is being processed on endpoint devices.

DLP tools can provide visibility of how users interact with data on endpoints by installing DLP agents on target devices. The scope of activity monitored can vary between DLP tools but may include copy and paste between applications, print functions and download to portable storage devices (e.g. USB).

Data at rest Data in storage, such as in file systems, servers, databases, the cloud and endpoint devices (e.g. laptops and desktops).

DLP tools can inspect storage repositories and systems (indexing, opening, reading and analysing files) to detect files that contain sensitive content. Scans may be set to occur in real time, at regular intervals or on demand (e.g. ahead of a security audit). Scanning may be performed remotely or by agents installed locally.

The technical architecture for the deployment of DLP tools needs to be carefully designed to integrate with existing infrastructure. A typical DLP architecture consists of four main architectural components as illustrated in Figure 7.

Figure 7: DLP technical architecture

DLP FOR NETWORK DLP FOR STORAGE

DLP FOR ENDPOINT

CENTRAL MANAGEMENT CONSOLE

Email Internet

Software as aService (Saas)

Other networkprotocols

Cloud

File server

Database server

Web server

– Policy creation and management

– Reporting & dashboard

– Management of policy violations

– System administration

The central management console provides a single interface to author, implement and manage DLP policies across all data leakage channels covered by a DLP programme. The console also consolidates logging, reporting, review of policy violations, incident remediation and system administration.

“Business side activity: 75%; IT implementation (including testing): 25%.” – ISF Member

The network component often involves passive monitoring of network traffic, lacking the ability to intervene with user activities. To apply preventative capabilities (e.g. blocking), data needs to be passed to DLP tools for analysis and handling, which can be achieved by deploying software agents (e.g. on endpoints) or by integrating with web proxies, email services and storage repositories. Increasingly, DLP tools include the capacity to extend DLP policies to cloud services by integrating with a cloud access security broker (CASB) or cloud-delivered web gateway.


2 Benefits of a DLP programme

The primary benefit of data leakage prevention is in the name – preventing sensitive data from leaking and potentially being exploited by adversaries for financial gain, industrial espionage or other malignant purposes. Sensitive data does not just represent value to the organisation. It is also an asset that is highly sought after by adversarial threats, such as organised criminal groups, unscrupulous competitors, hacktivists, investigative journalists and disgruntled employees, particularly since data can be monetised (e.g. held to ransom or on-sold).

It does not take much effort to leak data but the business impact can be severe. Depending on the data leaked and extent of exposure, potential consequences include regulatory penalties, negative publicity, loss of competitive advantage, brand damage, erosion of customer trust and disruption to business activities, all of which can result in an organisation suffering financial losses.

DLP can help to mitigate the potential costs associated with sensitive data leaking. Securing data from unauthorised disclosure can also set an organisation apart in terms of their information security maturity, especially if DLP is mandated as a requirement by prospective clients or business partners.

DLP enables organisations to detect what data is leaking and demonstrably reduce incidents of data leakage by blocking or otherwise restricting activities that put data at risk, whether initiated by the user or system generated. Additional benefits can also be derived from DLP, which include:

‒ supporting compliance with global, regional, country and industry-specific regulatory requirements

‒ gaining visibility of the usage and movement of sensitive data ‒ improving the security awareness and behaviour of users ‒ detecting the exfiltration of data by external hackers.

Implementation of DLP can help to identify signs of hacker activity on a network by detecting suspicious attempts to exfiltrate data via channels that are monitored by DLP tools.

DLP LIMITATIONS While DLP offers many benefits, it does have limitations that organisations will need to manage. In today’s world, the explosion of information has created much more data to protect, which can leak through more channels than ever before due to technological advances and new working trends. The challenges of preventing data leakage cannot be solved by DLP tools alone due to gaps in their coverage and capabilities. DLP tools are unable to:

‒ detect all content containing sensitive data ‒ monitor all channels of data leakage ‒ act to prevent every occurrence of data leakage.

ISF Members identified the following aspects of DLP that can diminish the business value of a DLP deployment.

Data is dispersed Data is scattered across different environments – it is often replicated in various storage repositories and platforms (including cloud services and geographically distributed data centres), constantly transferred out of an organisation and accessible from personal devices or networks that may not be controlled by an organisation. This wide dispersal of data affects how it can be scanned and protected by DLP tools.

Traditional DLP tools are designed to prevent the leakage of data already within the control of the organisation. While DLP technology is evolving to extend coverage to mobile devices, the cloud environment and beyond, there will still be gaps where data remains beyond the reach of DLP tools and can leak.

Coverage is limited to digital data DLP tools are intended to prevent data from leaking in a digital format (rather than printed or spoken format). As a result, many channels of potential data leakage are not covered by DLP tools. For instance, shoulder-surfing, steganography and lost laptops are all ways that data can be leaked and need to be addressed by security controls other than DLP tools.

“DLP isn't something you switch on and everything is protected.” – ISF Member

77% of surveyed ISF Members implement DLP to reduce the frequency or magnitude of accidental data leakage; almost the same implement DLP to mitigate malicious data leakage (76%).


Detection of data needs business input Half of surveyed ISF Members found it challenging to identify what data to protect using DLP tools. In the age of the information explosion and big data, it is not easy to keep track of what sensitive data an organisation holds. Not only is data generated, consumed and shared at a staggering rate, but it may be classified incorrectly – or in a way that makes it difficult to distinguish sensitive data (e.g. a significant amount of data is classified ‘confidential’). To understand what data to detect and prevent from leaking, business collaboration is crucial.

DLP controls are circumvented Focusing DLP efforts on a select few channels of data leakage allows malicious insiders to circumvent DLP controls and exfiltrate data via egress points that are less stringently protected (e.g. collaboration platforms or voice communications). To be truly effective, a DLP programme needs to recognise patterns in human behaviour and take account of how users react to rules that prevent certain activities.

For example, if a user is blocked from transmitting sensitive data externally by email, the user will often share this data via other means, such as copying to a portable storage device, uploading it to a cloud storage service or printing the document. This is a common occurrence where DLP is perceived to get in the way of routine business activities or if a determined insider is motivated to steal data.

Excessive policy violations compromise effectiveness Without proper configuration, DLP tools can miss genuine data leakages and generate large volumes of policy violations, which can overwhelm resources. If a DLP policy rule is too specific, it can fail to detect occurrences of data leakage it was intended to capture (false negatives). If it is too general or broad, it can result in an overload of policy violations that are not intended matches (false positives). This reduces the accuracy and credibility of DLP tools, encroaching on the time and resources that should be spent investigating actual incidents. False positives can also engender a tendency for users to ignore DLP notifications on the assumption they pertain to valid communications, which in the given context do not violate a DLP policy.

50% of Benchmark respondents do not review policy violations to help minimise false negatives and false positives.

Organisations are reluctant to block The benefits of blocking should not be underestimated since it is the most effective action for actually preventing data leakage. Yet organisations are often reluctant to enable blocking for fear of disrupting business activities (e.g. preventing the business from conducting legitimate transactions by stopping email messages or other forms of communication).

Blocking can interfere with user workflow and cause a degradation in productivity. However, to leave DLP tools running purely in log or notify mode can reduce the value of deploying DLP, unless the main objective is to gain visibility into data usage and report policy violations. By carefully tuning DLP policy rules with business input, organisations can ensure blocking does not disable operations or impede business processes.

60% of Benchmark respondents do not block unauthorised user actions.

THE NEED FOR A DLP PROGRAMMESimply installing DLP tools is not enough to deliver value and stop sensitive data from leaving an organisation. Surveyed ISF Members reported that the benefits of DLP can only be fully realised by implementing a DLP programme that is designed to address a business problem; not just a technology issue. DLP is inherently linked to business operations – more so than many other security controls. Consequently, to treat DLP as a ‘fix and forget’ solution that can be achieved through technology alone will result in failure.

Significant effort and resources need to be dedicated to the planning and preparation of a DLP deployment, the success of which relies substantially on effective business engagement. A DLP programme should account for the organisational and human factors of DLP, as well as apply robust processes for securing sensitive data. It should be supported by DLP tools but not take as its starting point or primary component the selection and implementation of DLP tools. Section 3 defines the key attributes of a successful DLP programme.


3 Attributes of a DLP programme

The most effective way of implementing DLP is to adopt a formal programme supported by the right blend of people, process and technology. ISF Members identified ten key attributes of a successful DLP programme, as shown in Figure 8. These attributes can be grouped into three phases of deploying a DLP programme: governance, preparation and implementation.

Figure 8: Key attributes of a DLP programme

A. GOVERNANCE

– Obtain executive support

– Define DLP programme objectives

– Assign roles and responsibilities

B. PREPARATION

– Involve business stakeholders

– Prioritise what data to protect

– Select DLP tools

– Integrate DLP tools into existing environment

C. IMPLEMENTATION

– Improve security awareness of data leakage

– Determine how to respond to policy violations

– Deploy DLP incrementally

Effective implementation of a DLP programme is not as simple as ticking a list of check boxes. To position a DLP programme for long-term success, significant effort should be dedicated to effective governance and preparatory activities for implementation, which include – but are not limited to – deployment of DLP tools.

“You may (likely will) find that your programme will succeed or fail based on the buy-in that you get from your business partners.” – ISF Member

DLP inherently involves monitoring employees’ communications and online activities, and by extension third party messages, which raises legal concerns that need to be carefully considered prior to deploying DLP tools. There are a variety of laws relating to privacy, data protection, employment, interception of data and telecommunications that apply to monitoring and data processing in the context of DLP.

The extent to which these laws constrict the scope and coverage of a DLP programme, or otherwise mandate specific measures, will depend on the given legal system (e.g. in some countries, such as Germany and Austria, deployment of DLP technology may require agreement with a ‘works council’). For global organisations, the legal complexity can prove particularly acute given the requirement to plan and execute a DLP programme that takes account of variances in local laws across multiple jurisdictions. Legal advice should be sought to ensure implementation of a DLP programme adheres to all applicable laws.

A DLP programme does not address all aspects of protecting data but instead concentrates on implementing the relevant tools, procedures and processes for preventing specific sensitive data from leaving an organisation. A DLP programme should therefore be approached as just one element of an organisation’s data protection strategy.

This section is not intended as an implementation guide or an end-to-end process map for installing DLP. Rather, it reflects good practice within the ISF Membership and the areas on which to place focus to fully derive the benefits of a DLP programme. Each key attribute is explained on the following pages in the order that a DLP programme would typically follow.

Implementation of a DLP programme is a multi-phase undertaking that does not end with the installation of DLP tools or creation of DLP policies. To realise the value of a DLP programme and optimise its performance, organisations need to continually maintain, review and refine their DLP programme.

“DLP requires scheduled review and assessment to ensure relevance and to comply with the latest technology trends.” – ISF Member


PHASE A: GOVERNANCEObtain executive supportGaining the support of executive management is often a prerequisite for deploying any security tool, but it is particularly important for the success of DLP. A DLP programme typically has a wide reach across an organisation and can change how users handle data. Actions performed by a DLP tool can interrupt business operations and workflow, causing employee frustration. Backing from executive management lends legitimacy to a DLP programme and reinforces the need for individuals to embrace changes introduced by a DLP deployment.

Surveyed ISF Members recommended establishing a steering committee to provide strategic direction, advise on business issues, set risk reduction priorities and monitor the progress of DLP against agreed objectives. A steering committee should include representatives from key departments, such as information security, IT, legal, human resources, compliance, privacy and risk management. An executive sponsor should be appointed as early as possible to champion DLP and ensure it is a success.

Executive management should contribute to the organisation’s information risk assessments and therefore be involved in identifying DLP as an appropriate risk treatment action. This way, DLP is deployed as a business initiative endorsed by executive management from the outset, providing an important mandate for business stakeholders to dedicate time and resources to developing a successful DLP programme.

Define DLP programme objectivesBefore selecting any DLP technology, organisations should establish why DLP is required and what it needs to accomplish to be a success. Setting objectives enables an organisation to define the scope of the programme and determine steps for achieving both short and long-term goals. Fundamental questions for organisations to consider are:

‒ what data needs to be protected by DLP? ‒ which data leakage channels to cover? ‒ how to respond to DLP policy violations, including whether and when to block?

Organisations should determine whether to apply DLP enterprise-wide or to a specific system, application, business unit, division or region. For the majority of surveyed ISF Members, the end goal is to deploy DLP across the enterprise, starting with an initial pilot that is limited to a defined group or target area.

Other factors that can influence the scope of a DLP programme include speed of risk reduction, costs, resourcing and timescales. Organisations should also consider which supporting technologies and compensating controls to include within scope because they either optimise the performance of DLP tools or protect data leakage channels that are not adequately covered by DLP tools.

Assign roles and responsibilitiesSurveyed ISF Members advised that the success of DLP is highly dependent on the programme being properly staffed from its inception. A permanent DLP team should be assembled to perform the following tasks:

‒ maintaining DLP tools and related infrastructure ‒ configuring and managing DLP policies ‒ triaging, investigating and responding to DLP policy violations ‒ coordinating cross-functional involvement.

The roles and responsibilities of those involved in a DLP programme need to be clearly defined, particularly since implementation requires the input of representatives from various business functions (e.g. business operations, IT, information security, legal and HR). Of ISF Members surveyed, those with a cross-functional DLP team were more likely to achieve their programme’s objectives and deliver return on investment than Members who appointed either IT or information security to be primarily responsible for DLP.

To prevent misuse of DLP, duties should be segregated so the technical maintenance of DLP tools, the management of DLP policies (i.e. author, update and delete) and review of policy violations cannot be carried out by the same individual or function.

71% of surveyed ISF Members deploy their DLP programme enterprise-wide

77% of surveyed ISF Members considered executive-level involvement to be of high value to their DLP programme


PHASE B: PREPARATIONInvolve business stakeholders The ongoing involvement of business stakeholders throughout the planning and operation of a DLP programme is of paramount importance to its success. To be leveraged to its full potential, a DLP programme needs to align with business priorities. Without business involvement, neither information security nor IT can determine precisely what data the business deals with, the business value of that data, and how it flows within and out of the business.

An ISF Member reported that to bolster collaboration they had co-opted business representatives into their DLP team for a specified period to gain the institutional knowledge of the business. Another approach was to nominate business representatives (e.g. data owners) to provide direct support with the triage of DLP policy violations.

Regular engagement with business representatives from across the organisaion is necessary to assist with both the configuration of DLP policies and review of the policy violations generated. Short of business input, a DLP tool cannot be properly tuned to protect what is important to the business. Equally, the authorised use of data may not be apparent to those outside a given business function (e.g. whether or not an email to an external party concerning a business transaction should be blocked).

While DLP tools provide some visibility of user and system activities, collaboration with business stakeholders can help detect business processes that are undocumented or cause data to leak, revealing security weaknesses in business operations. Decisions on how to remediate risky processes should be made with the relevant business owner to ensure that the changes introduced satisfy business requirements.

To protect against data leakage requires the business not only to support DLP but also to be accountable for adjusting their practices and processes to reduce risk. A DLP programme is best placed to succeed if business representatives recognise they are the custodian of data while handling it. This requires the business to take responsibility for treating the risk of data leakage, with information security providing usable solutions and options to enhance protection – whether that be DLP or other relevant security controls.

Prioritise what data to protect

Data can take many forms and exist in various locations across an organisation. In preparing for a DLP programme, it is important for organisations to understand the different types of sensitive data it handles and determine what data to protect using DLP.

Not all data leaks are equal: the business impact varies depending on the data leaked, to whom it is exposed and the extent of exposure. Organisations should identify what data is the highest priority for protection and which channels to focus on securing first, considering a range of factors as shown in the box on the right.

ISF Members recommended prioritising DLP activities according to the business risk associated with data leaking. This involves assessing the business impact of leakage for each type of data (e.g. regulatory fines, loss of competitive advantage, customer attrition, damage to the brand and direct financial losses). Consideration should also be given to where data is at the highest risk of unauthorised disclosure and the likelihood of it leaking.

Risks can then be prioritised to concentrate DLP efforts on the data leakage scenarios that pose the greatest risk to the organisation before a DLP programme incrementally expands to the desired level of coverage.

Surveyed ISF Members recommended engaging with the business to conduct the following DLP activities (this is not an exhaustive list):

‒ identifying the types of data handled by each business unit and the impact of that data leaking

‒ defining what data is important to protect, who accesses it and where it resides

‒ determining what existing controls are in place to protect data, their relation to DLP and how good they are

‒ remediating insecure business processes without disrupting business operations

‒ understanding the context of user behaviour and whether it involves legitimate business transactions

‒ reviewing and responding to policy violations.

DLP activities

Factors influencing the priority for protection may relate to the:

‒ data, for example: • data that is of greatest value to the organisation • data that would attract high publicity if leaked due to

its profile (e.g. celebrity data)• location of data and extent of user access• impact of data leakage, including costs and severity of

the consequences• likelihood of data leaking• how well the data is already protected by existing tools

‒ channels of data leakage, for example:• channels through which the data most commonly

leaks• volume of data processed by a channel• speed and ease of protecting a channel

‒ business operations, for example:• impending launch of new business product or services• contractual, legal or regulatory requirements• impact of data leaking for customers and

business partners.

Prioritising data for protection


Select DLP toolsTo evaluate DLP tools effectively, organisations should first establish their requirements of a DLP programme, including the types of data to prevent from leaking (in order of priority), the techniques required to detect that data and which channels to monitor.

When selecting DLP tools, organisations should evaluate the: ‒ features and functionality of the tool, including detection techniques and the interface for managing DLP policies

‒ hardware and architecture requirements for deployment, including ease of installation and use

‒ reliability and performance of the tool, including availability of technical support

‒ compatibility of the product with the existing IT environment ‒ ability to integrate with relevant third-party technologies ‒ alignment with the organisation’s overall IT strategy ‒ overall cost of ownership, including installation, configuration and resourcing.

Integrate DLP tools into existing environmentTo function correctly, DLP tools need to integrate with existing infrastructure, including servers, storage platforms, endpoint devices, email services, proxies and web gateways. As presented in the box on the right, there are also a range of complementary technologies that can enhance the performance of DLP tools and support the objectives of implementing a DLP programme.

By adopting some of these technologies, organisations can address the shortcomings of DLP tools, extend the protection of data and improve the value delivered by their DLP programme. For surveyed ISF Members, integration of DLP tools with a data classification scheme ranked as the most important technology-related factor for a successful DLP programme.

Integration with data classification tools can optimise the value of DLP by improving its ability to accurately identify the data that needs to be protected against leakage. The recommendation of surveyed ISF Members was to introduce a data classification scheme before implementing DLP or in parallel. While it is possible to integrate a third-party data classification tool with DLP following the initial rollout, this is a more complicated, resource-hungry and costly option.

Data classification involves assigning agreed labels to information based on its level of confidentiality, taking into account the value of information to the organisation and potential business impact if it were disclosed. Classification labels can be applied as visual markings to messages, documents and files (e.g. using electronic watermarks, headers and footers or rubber ink stamps); embedded into the content’s metadata (e.g. document properties) or both.

Metadata labels can be read by DLP technology and DLP policies enforced based on the classification level (e.g. a classification of ‘internal only’ will tell a DLP tool to block or otherwise restrict the movement of that data outside the organisation). To generate metadata labels that are ‘machine readable’ by DLP requires organisations to install a suitable tool, such as data classification software, which is compatible with DLP technology.

To enhance a DLP programme, data classification needs to be applied consistently and accurately across the organisation. Whenever possible, organisations should supplement user-driven classification by using automated classification tools that can automatically label information and prompt users to confirm a classification.

Integrating DLP with data classification

Integrate with DLP tools: ‒ data classification tools ‒ cloud access security brokers (CASB) ‒ security information and event management (SIEM) ‒ digital rights management ‒ role-based access control ‒ third-party encryption tools ‒ enterprise mobility management ‒ enterprise directories (e.g. Active Directory).

Support DLP objectives: ‒ user and entity behavioural analytics ‒ application and website whitelisting ‒ sandbox technologies ‒ USB security management ‒ collaboration platforms e.g. Yammer, Slack ‒ file compression tools.

Complementary technologies

Before procuring a DLP tool, organisations should test the product thoroughly to ensure it meets requirements. Undertaking a proof of concept (POC) will enable organisations to assess the capabilities of the product and determine whether it can interact well with other related technology in the target environment.


While a successful DLP programme needs to be supported by DLP tools and other technologies, a holistic approach to DLP requires the programme to include non-technical controls and documented procedures that will help prevent the leakage of data in physical and spoken formats.

“When you ‘sell’ the DLP service to business, make sure you explain that this is just one control... make sure they understand where their information is still vulnerable.” – ISF Member

Management controls: ‒ clear desk policy ‒ authenticated printing ‒ authenticated network access ‒ protection of information on office equipment (e.g. password-controlled access).

Physical security controls: ‒ storing printed material containing sensitive data in a physically secure location ‒ protection of secure physical areas (e.g. installing CCTV) ‒ physical protection of hardware (e.g. restricting access to a data centre) ‒ secure transportation of sensitive physical information (e.g. double packaging to protect physical information in transit) ‒ secure means of disposal (e.g. incineration or cross-cut shredding).

Complementary management and physical security controls


PHASE C: IMPLEMENTATIONImprove security awareness of data leakage The success of DLP is significantly influenced by the human factor. Often individuals simply do not realise the risk created by their own actions, which may be undertaken in the interests of productivity or because routine business processes do not cater for the secure handling of data.

By monitoring how data is transmitted, used and stored, DLP tools can provide insight into how an organisation works and expose insecure habits that need to be addressed. In turn, DLP tools can be configured to send an email or display pop-up notifications to coach users on how to handle data appropriately with options for immediate self-remediation. This real-time feedback can result in a considerable drop in risky behaviour as users change the way they act and think about handling data.

Awareness activities tailored to DLP should be initiated ahead of deploying DLP tools to inform individuals what they can expect from a DLP programme and avoid undue surprises. It should address the value of data, why DLP is being adopted and its business benefits. This communication to the business will help foster a positive perception of DLP and prepare employees for actions that block or otherwise intervene with user activity.

Figure 9: Benefits of promoting security awareness

Video and gamification were identified by ISF Members as being particularly effective for delivering security awareness messages tailored to DLP.

ISF members reported a drastic reduction in DLP policy violations in areas where the level of security awareness was raised, whether due to notifications, blocking or a security awareness campaign.

Eliminating the noise attributable to poor security awareness allows other policy violations to be investigated in more depth and is a useful metric by which to demonstrate the value of DLP.

Deploying DLP may require a culture shift within an organisation to create a corporate environment, where security is regarded as a priority. Just as DLP can improve security awareness via educational pop-up messages, a security conscious culture will benefit DLP implementation.

There is the potential for employees to become careless and complacent in their handling of data under the false assumption that DLP tools or other technology is able to detect and correct all user mistakes. This is why training needs to be refreshed at regular intervals.

Determine how to respond to DLP policy violations Before DLP tools are deployed, organisations should determine the process for handling policy violations, specifying who responds, the options for corrective action and the criteria for investigation. The response process needs to be appropriately resourced according to the size of the organisation and scale of the DLP roll-out, otherwise the value of the DLP programme can diminish.

The initial response to a policy violation typically involves verifying its validity, the context and severity. This triage process may be performed by a small, centralised team dedicated to the task or by nominated individuals from relevant business functions, with the option to escalate to appropriate personnel – such as HR, legal or compliance – for further investigation. If a policy violation proves to be an actual incident of data leakage, it should be integrated into wider security incident management processes.

Some ISF Members use a playbook to record their DLP policies, documenting how they are configured, who the data owners are and how to respond to different types of policy violations (e.g. send an automated email to the user involved with guidance on the secure handling of data, notify the user’s manager or impose restrictions on the user pending further investigation).

“Determining a process flow for incident remediation early in the project is crucial as these incidents can escalate into huge amounts of data, which will make fine-tuning policies a little

more challenging and time consuming.” – ISF Member

DLP vendors use the term ‘incident’ to refer to a DLP policy violation.


DLP policy violations should be analysed to evaluate trends, measure the success of the programme and adjust DLP policies as appropriate. Examples of relevant metrics include:

‒ number of violations per policy ‒ business units experiencing more policy violations ‒ percentage of policy violations classified as high severity ‒ policy violations related to insecure business processes ‒ policy violations due to poor security awareness.

Deploy DLP incrementallyA systematic, phased approach to implementation is imperative to execute a DLP programme successfully and optimise its performance. Any attempt to simultaneously protect all sensitive data and channels from the outset is destined to fail.

“Obtain proof through a small deployment and then expand the deployment.” – ISF Member

An implementation pilot, which is limited to a representative group of users, a business unit or a region, should precede wider deployment. This pilot will often focus on just one type of sensitive data and target a single data leakage channel, such as email.

Deployment of DLP should start small with one or two policies relating to a single ‘use case’ to ensure proper configuration and effective performance of DLP tools. Additional DLP policies can then be introduced gradually.

Organisations should design a phased implementation plan for expanding their DLP programme, which takes account of: ‒ adding DLP policies to broaden the types of sensitive data protected ‒ improving the way existing channels are monitored ‒ extending DLP to monitor new channels of data leakage ‒ moving from logging policy violations to notify and block actions.

DLP policy rules should first be run in log-only mode (also known as monitor-only mode) to review the alerts generated and effectiveness of the policy. This allows time to fine-tune each policy to improve its accuracy and determine its potential business impact before enabling blocking or other response actions. Business input during the log phase is vital – it helps to minimise false positives, highlight business requirements and reveal business activities that the DLP policy may disrupt once response actions are applied.

When blocking is enabled, there should be a process for efficient recovery of quarantined or blocked information that is time-sensitive (e.g. relates to an urgent business transaction), otherwise the IT helpdesk (or equivalent) may receive constant requests for the release of data. This may be achieved by displaying an on-screen notification, allowing users to select from an agreed list of business justifications for the transfer of data.

For many ISF Members, the ability to confidently turn on blocking is itself a measure of a DLP tool’s success. It provides assurance that certain data cannot leave an organisation via a given channel without relying on scanning and analysis of policy violations to detect data leaking.

Following the initial DLP roll-out, DLP tools need to be maintained and enhanced to obtain maximum value from the DLP programme. The value of data to an organisation can change over a given period, meaning that the sensitivity of data can be time-bound or context dependant. DLP policies should be reviewed regularly and kept current. They may need to be modified, removed or new policies created to accommodate changing business requirements and account for new threats.Organisations are rarely static. New product lines, services or projects are constantly being introduced as organisations adapt to market trends. Organisations may also acquire, merge, divest and restructure. These changes affect the type of data that needs to be protected and the channels to monitor. It is therefore critical to continuously engage with the business to ensure the right data is covered by the DLP programme and leakage of sensitive data is kept to a minimum.

Maintenance and improvement


4 Conclusion

The increasing adoption of collaboration platforms, cloud services and social media, which are often accessed using personal devices, has introduced a host of new ways for sensitive data to leak. Well-intentioned and rogue employees alike can now share data with greater ease. This only serves to magnify the risk of disclosing data to unauthorised entities.

As data breaches continue to hit media headlines with costly consequences, organisations are realising the importance of taking a systematic, structured approach to detect and prevent the leakage of sensitive data. DLP technology has existed for some time but has experienced a resurgence in recent years. ISF Members reported that they are now achieving success with DLP technology when it is deployed as part of a dedicated DLP programme.

DLP tools alone cannot prevent the leakage of all types of sensitive data across every possible channel. DLP capabilities are now extending to the cloud, mobile devices and other emerging technologies, but blind spots will inevitably remain and obscure the occurrence of data leaks.

Ultimately, the value of DLP is to block suspected leaks and stop sensitive data from leaving an organisation, whether via file uploads, copy and paste, printing, social media posts or email. Failure to block will limit the value of DLP to simply detecting – rather than preventing – the leakage of data. A balance must be struck, however, between blocking risky activities and impeding legitimate business operations.

A prerequisite of a successful DLP programme is support from executive management and ongoing collaboration with business representatives. By implementing a comprehensive DLP programme that encompasses awareness training, tools, supporting technologies and other security controls, organisations can compensate for weaknesses in DLP technology and proactively manage the risk.

WHERE NEXT?The ISF encourages collaboration on its research and tools. ISF Members are invited to join the Process community on ISF Live to share experiences and discuss practical approaches for implementing a successful DLP programme.

REFERENCE: ISF 18 07 01 ©2018 Information Security Forum Limited. All rights reserved.

Data Leakage PreventionJULY 2018

CONTACTFor further information contact:Steve Durbin, Managing Director US: +1 (347) 767 6772UK: +44 (0)20 3289 5884UK Mobile: +44 (0)7785 953 [email protected]

PUBLISHED BYInformation Security Forum Limited +44 (0)20 3875 [email protected]

AUTHOREmma Bickerstaffe

REVIEW AND QUALITY ASSURANCEAndy Jones Mark SowerbyJason Creasey

DESIGNKim Whyte

ABOUT THE ISFFounded in 1989, the Information Security Forum (ISF) is an independent, not-for-profit association of leading organisations from around the world. It is dedicated to investigating, clarifying and resolving key issues in cyber, information security and risk management and developing best practice methodologies, processes and solutions that meet the business needs of its Members.

WARNINGThis document is confidential and is intended for the attention of and use by either organisations that are Members of the Information Security Forum (ISF) or by persons who have purchased it from the ISF direct. If you are not a Member of the ISF or have received this document in error, please destroy it or contact the ISF on [email protected]. Any storage or use of this document by organisations which are not Members of the ISF or who have not validly acquired the report directly from the ISF is not permitted and strictly prohibited. This document has been produced with care and to the best of our ability. However, both the Information Security Forum and the Information Security Forum Limited accept no responsibility for any problems or incidents arising from its use.

CLASSIFICATIONRestricted to ISF Members, ISF Service Providers and non-Members who have acquired the report from the ISF.

Documents

DATA LEAKAGE PREVENTION · violation (also known in the context of DLP as an ‘incident’). DLP policy violations can be user or system generated (e.g. a finance system emailing