DATA LEAKAGE

PREVENTION

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 DLP To prevent the actual leakage of data, DLP tools need to
Interest in DLP technology quickly waned when it first came be carefully configured to block activities that put data at
to market due to the complexity of deployment, cost of risk. However, many organisations are reluctant to enable
investment, and inability to demonstrate business value. the blocking functionality for fear of disrupting business
However, cloud adoption, mobile computing and remote operations. This can limit the effectiveness of DLP.
working, coupled with major data breaches and new regulatory
requirements, such as the EU General Data Protection
NEED FOR A HOLISTIC APPROACH
Regulation (GDPR), have prompted organisations The full benefits of DLP can only be realised if organisations
to take a fresh look at DLP. implement DLP for clearly defined purposes and in a
structured, systematic manner that incorporates people,
Meanwhile, DLP technology has matured and is steadily process and technology. ISF Members reported that DLP can be
progressing towards a mainstream security control.1 a success when approached as part of a dedicated programme
DLP’s recent surge in popularity is reflected within the ISF for reducing the risk of data leakage.
Membership – to date, 42% of surveyed ISF Members have
implemented DLP and a further 45% are either running a Figure 1: Survey results of ISF Members who have implemented
DLP pilot or planning for deployment.2 a DLP programme

DLP CAPABILITIES
In 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. 57% delivered return
72% achieved 72% demonstrated
objectives on investment risk reduction
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 Based on the experience of ISF Members, this report provides
USB. Although DLP technology is evolving to protect newer guidance on how to optimise a DLP deployment, describing
channels, it does not capture all types of sensitive data or the ten key attributes of a successful DLP programme. It
cover all conceivable scenarios of data leakage. emphasises that a focus on technology alone will likely lead to
the relegation of DLP tools to shelf-ware.

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.
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 There are many different types of information that are valuable to organisations (known as information
protect against leakage 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 Digital data can leak through a variety of channels (also referred to as vectors) including email, social media
of data leakage 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 There are a range of actions that can be taken to stop data from leaving an organisation (e.g. alert users to
from leaking 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
Email Internet Removable Collaboration Cloud Database/
– Intellectual property media devices platforms File storage
Log Notify Block
– Business & governance data
+
– Financial data

– Sales & marketing data Printer/MFD File-sharing Camera Paper Clipboard Voice
applications

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.

2 Data Leakage Prevention Information Security Forum

DLP POLICIES
To 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 A technical DLP policy is not the same
conditions, exceptions and actions against which data, files, document content as an organisational policy. The term
and messages are evaluated to detect and prevent data leaks. Through DLP policies, is commonly encountered in DLP
products as a central component
organisations can define:
of deploying the tool and is used
‒‒ what data can and cannot be sent, posted, uploaded, moved, or copied and pasted throughout this report to refer to the
‒‒ where data can be transmitted configuration of rules for detecting
and protecting data.
‒‒ 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 Allow transfer of data to Block transfers containing source code
proprietary source code company X, selected to conduct (including web postings, email messages
a source code review and copy of files)

Credit cards Detect content that matches None Quarantine data in cloud applications,
the credit card number, using files and messages:
a Luhn algorithm − send an email notification to the user
− allow the user to provide business
justification for release

Project penguin Detect content containing key phrase Allow transfer of data Block transfer of content to external recipients
‘project penguin’ and intended for to John Doe (external Encrypt email transmissions to John Doe
an external recipient legal counsel)

Medical records Detect content that matches words Exclude emails marked Block transfers including copy of health
or expressions from a list of common as ‘personal’ data to a portable storage device
medical conditions Display on-screen notification stating file
transfer violates a specific 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.

Information Security Forum Data Leakage Prevention 3

IDENTIFY DATA
DLP 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 data

Figure 3: Types of data ISF Members protect using DLP
Sensitive data is information that could cause harm to organisations
Personal 85%
if it were disclosed to unauthorised parties, for example, merger and
acquisition plans, personally identifiable information, product designs, Customer 80%
pricing models, source code and social security numbers. Data can be Financial 66%
deemed sensitive for many reasons, such as regulatory requirements, Business and governance 62%
internal policies and the potential impact of unauthorised disclosure.
Intellectual property 55%
Surveyed ISF Members focused predominantly on protecting personal
and customer data, as shown in Figure 3. Sales and marketing 51%

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 data

Identifying what data should be included within the scope of DLP is a core
82% of surveyed ISF Members
activity that can determine whether DLP delivers value and reduces the risk ! found engagement with the
of data leaking. A DLP tool can only detect data if it is configured to look for business to be of high value for
that data. Deploying a tool that is incorrectly configured will result in the identifying sensitive data.
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 Matches content using regular expressions, defined strings, keywords, patterns or dictionaries (a list of specific
matching 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 Takes a cryptographic hash of a sample file or file contents to create a ‘fingerprint’. Content is then checked against
(Indexing) 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 Uses algorithms and statistical techniques to determine if content is similar to example documents, which are
(Statistical analysis) 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 Analyses image files (e.g. screenshots or scanned documents) and extracts text to find matches for sensitive content.
recognition
(Image recognition)

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).

4 Data Leakage Prevention Information Security Forum

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

Yes Scheduled Under consideration No
Corporate email
Internet usage
Portable storage devices
External file-sharing applications
Cloud services
Collaboration platforms
Enterprise database and file storage
Office equipment
Screen capture
Physical information
Voice
Cameras

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

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 threat

Figure 5: Three types of risky behaviour
DLP 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 Conscious decision No conscious
to act decision to act
malicious activities as well as accidental data leaks by well-meaning inappropriately inappropriately
employees (e.g. mistakenly sent an email to the wrong recipient).
MALICIOUS NEGLIGENT ACCIDENTAL
DLP tools themselves lack insight into the business context or motive
of users to distinguish between the different types of risky behaviour. Motive to harm No motive to harm
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.

Information Security Forum Data Leakage Prevention 5

ACT TO PREVENT DATA FROM LEAKING
DLP 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 action
A 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.

Blocking
Hard block, for example: Soft block, for example: Other actions to remediate incorrect
‒‒ block transfer of email message or file ‒‒ move file to another location handling of data, for example:
‒‒ disable download, copy or print options ‒‒ quarantine email message pending ‒‒ add visual tag
‒‒ delete attachment or file. business justification for release ‒‒ change access controls to restrict access
‒‒ redact sensitive data in web post or to the file
email and allow transfer. ‒‒ encrypt file or message.

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

Data at rest Data in motion Data in use Not performed
Log
Encrypt
Notify
Block
Quarantine
Prevent download,
copy or print
Cancel or delete
Redact

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

6 Data Leakage Prevention Information Security Forum

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, DLP tools can monitor network traffic through network sniffing and deep content
such as the internet or a private inspection to identify sensitive data travelling via a variety of means including email,
network (e.g. local area network). file transfer and HTTP (web).

Data in use Data that is being processed on DLP tools can provide visibility of how users interact with data on endpoints by
endpoint devices. 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 DLP tools can inspect storage repositories and systems (indexing, opening, reading
systems, servers, databases, the and analysing files) to detect files that contain sensitive content. Scans may be set to
cloud and endpoint devices (e.g. occur in real time, at regular intervals or on demand (e.g. ahead of a security audit).
laptops and desktops). 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 CENTRAL MANAGEMENT CONSOLE DLP FOR STORAGE

– Policy creation and management
– Reporting & dashboard
– Management of policy violations
Email Internet – System administration Cloud

DLP FOR ENDPOINT

Software as a Other network File Database Web

Service (Saas) protocols server server server

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.

Information Security Forum Data Leakage Prevention 7

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 77% of surveyed ISF Members
at risk, whether initiated by the user or system generated. Additional benefits can implement DLP to reduce the
frequency or magnitude of accidental
also be derived from DLP, which include:
data leakage; almost the same
‒‒ supporting compliance with global, regional, country and industry-specific implement DLP to mitigate malicious
regulatory requirements data leakage (76%).
‒‒ 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 “DLP isn't something you switch on and everything
‒‒ monitor all channels of data leakage is protected.” – ISF Member
‒‒ 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.

8 Data Leakage Prevention Information Security Forum

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 PROGRAMME

Simply 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.

Information Security Forum Data Leakage Prevention 9

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 B. PREPARATION C. IMPLEMENTATION

– Obtain executive support – Involve business stakeholders – Improve security awareness
– Define DLP programme objectives – Prioritise what data to protect of data leakage

– Assign roles and responsibilities – Select DLP tools – Determine how to respond
to policy violations
– Integrate DLP tools into existing
environment – 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

10 Data Leakage Prevention Information Security Forum

PHASE A: GOVERNANCE
Obtain executive support
Gaining the support of executive management is often a prerequisite for deploying any 77% of surveyed ISF
security tool, but it is particularly important for the success of DLP. A DLP programme Members considered
typically has a wide reach across an organisation and can change how users handle data. executive-level
Actions performed by a DLP tool can interrupt business operations and workflow, causing involvement to be of
high value to their
employee frustration. Backing from executive management lends legitimacy to a DLP
DLP programme
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 objectives

Before 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?
71% of surveyed ISF
‒‒ how to respond to DLP policy violations, including whether and when to block? Members deploy
their DLP programme
Organisations should determine whether to apply DLP enterprise-wide or to a specific enterprise-wide
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 responsibilities

Surveyed 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.

Information Security Forum Data Leakage Prevention 11

PHASE B: PREPARATION
Involve 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

DLP activities activities, collaboration with business stakeholders can help
Surveyed ISF Members recommended engaging with the business detect business processes that are undocumented or cause
to conduct the following DLP activities (this is not an exhaustive list): data to leak, revealing security weaknesses in business
‒‒ identifying the types of data handled by each business unit and operations. Decisions on how to remediate risky processes
the impact of that data leaking should be made with the relevant business owner to ensure
‒‒ defining what data is important to protect, who accesses it and that the changes introduced satisfy business requirements.
where it resides
To protect against data leakage requires the business not only
‒‒ determining what existing controls are in place to protect data,
to support DLP but also to be accountable for adjusting their
their relation to DLP and how good they are
practices and processes to reduce risk. A DLP programme is
‒‒ remediating insecure business processes without disrupting best placed to succeed if business representatives recognise
business operations
they are the custodian of data while handling it. This requires
‒‒ understanding the context of user behaviour and whether it the business to take responsibility for treating the risk of data
involves legitimate business transactions
leakage, with information security providing usable solutions
‒‒ reviewing and responding to policy violations. and options to enhance protection – whether that be DLP or
other relevant security controls.

Prioritise what data to protect Prioritising data for protection

Data can take many forms and exist in various locations across an Factors influencing the priority for protection may
organisation. In preparing for a DLP programme, it is important for relate to the:
organisations to understand the different types of sensitive data it handles ‒‒ data, for example:
and determine what data to protect using DLP. • data that is of greatest value to the organisation
• data that would attract high publicity if leaked due to
Not all data leaks are equal: the business impact varies depending on its profile (e.g. celebrity data)
the data leaked, to whom it is exposed and the extent of exposure. • location of data and extent of user access
Organisations should identify what data is the highest priority for • impact of data leakage, including costs and severity of
the consequences
protection and which channels to focus on securing first, considering a
• likelihood of data leaking
range of factors as shown in the box on the right.
• how well the data is already protected by existing tools
ISF Members recommended prioritising DLP activities according to the ‒‒ channels of data leakage, for example:
business risk associated with data leaking. This involves assessing the • channels through which the data most commonly
leaks
business impact of leakage for each type of data (e.g. regulatory fines, loss • volume of data processed by a channel
of competitive advantage, customer attrition, damage to the brand and • speed and ease of protecting a channel
direct financial losses). Consideration should also be given to where data is
‒‒ business operations, for example:
at the highest risk of unauthorised disclosure and the likelihood of it leaking. • impending launch of new business product or services
• contractual, legal or regulatory requirements
Risks can then be prioritised to concentrate DLP efforts on the data leakage • impact of data leaking for customers and
scenarios that pose the greatest risk to the organisation before a DLP business partners.
programme incrementally expands to the desired level of coverage.

12 Data Leakage Prevention Information Security Forum

Select DLP tools
To 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:

Before procuring a DLP tool, organisations should test
‒‒ features and functionality of the tool, including detection
the product thoroughly to ensure it meets requirements.
techniques and the interface for managing DLP policies
Undertaking a proof of concept (POC) will enable
‒‒ hardware and architecture requirements for deployment, organisations to assess the capabilities of the product and
including ease of installation and use determine whether it can interact well with other related
‒‒ reliability and performance of the tool, including availability technology in the target environment.
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
Complementary technologies
‒‒ overall cost of ownership, including installation, configuration
and resourcing. Integrate with DLP tools:
‒‒ data classification tools
Integrate DLP tools into existing environment ‒‒ cloud access security brokers (CASB)
‒‒ security information and event management (SIEM)
To function correctly, DLP tools need to integrate with existing ‒‒ digital rights management
infrastructure, including servers, storage platforms, endpoint ‒‒ role-based access control
devices, email services, proxies and web gateways. As presented ‒‒ third-party encryption tools
in the box on the right, there are also a range of complementary ‒‒ enterprise mobility management
technologies that can enhance the performance of DLP tools and ‒‒ enterprise directories (e.g. Active Directory).
support the objectives of implementing a DLP programme. Support DLP objectives:
‒‒ user and entity behavioural analytics
By adopting some of these technologies, organisations can ‒‒ application and website whitelisting
address the shortcomings of DLP tools, extend the protection of ‒‒ sandbox technologies
data and improve the value delivered by their DLP programme. ‒‒ USB security management
For surveyed ISF Members, integration of DLP tools with a data ‒‒ collaboration platforms e.g. Yammer, Slack
classification scheme ranked as the most important technology- ‒‒ file compression tools.
related factor for a successful DLP programme.

Integrating DLP with data classification

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.

Information Security Forum Data Leakage Prevention 13

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

Complementary management and physical security controls

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).

14 Data Leakage Prevention Information Security Forum

PHASE C: IMPLEMENTATION
Improve 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

ISF members reported a drastic reduction in DLP policy violations in Eliminating the noise attributable to poor security awareness allows
areas where the level of security awareness was raised, whether due other policy violations to be investigated in more depth and is a useful
to notifications, blocking or a security awareness campaign. metric by which to demonstrate the value of DLP.

Deploying DLP may require a culture shift within an organisation to There is the potential for employees to become careless and
create a corporate environment, where security is regarded as a complacent in their handling of data under the false assumption
priority. Just as DLP can improve security awareness via educational that DLP tools or other technology is able to detect and correct all
pop-up messages, a security conscious culture will benefit DLP user mistakes. This is why training needs to be refreshed at regular
implementation. intervals.

Video and gamification were identified by ISF Members as being

particularly effective for delivering security awareness messages
tailored to DLP.

Determine how to respond to DLP policy violations

Before DLP tools are deployed, organisations should determine the process for handling
DLP vendors use the term
policy violations, specifying who responds, the options for corrective action and the criteria
‘incident’ to refer to a DLP
for investigation. The response process needs to be appropriately resourced according to policy violation.
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

Information Security Forum Data Leakage Prevention 15

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 incrementally

A 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.

Maintenance and improvement

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.

16 Data Leakage Prevention Information Security Forum

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.

Information Security Forum Data Leakage Prevention 17

Data Leakage Prevention
JULY 2018

CONTACT
For further information contact:
Steve Durbin, Managing Director
US: +1 (347) 767 6772
UK: +44 (0)20 3289 5884
UK Mobile: +44 (0)7785 953 800
steve.durbin@securityforum.org
securityforum.org

PUBLISHED BY
Information Security Forum Limited
+44 (0)20 3875 6868
info@securityforum.org
securityforum.org

AUTHOR
Emma Bickerstaffe

REVIEW AND QUALITY ASSURANCE

Andy Jones
Mark Sowerby
Jason Creasey

DESIGN
Kim Whyte

ABOUT THE ISF

Founded 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.

WARNING
This 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 info@securityforum.org. 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.

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

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