This document provides an overview of data loss prevention (DLP) systems. It defines DLP and describes how it can identify, monitor, and protect data in use, in motion, and at rest. It discusses typical DLP implementations for networks and endpoints/storage and how policies are defined. Common criticisms of DLP are outlined as well as the value it can provide by focusing on data security and improving communication between security and business teams. Lessons learned emphasize the importance of people, process, and technology in DLP deployments.

1. DATA LOSS PREVENTION
Stephen Kreusch

2. Overview
• What is DLP
• What does it look like
• DLP criticisms
• What value does DLP deliver?
• Lessons learned
• Q&A

3. DLP defined
Data Loss Prevention (DLP) is a computer security term referring to
systems that identify, monitor, and protect data in use (e.g.
endpoint actions), data in motion (e.g. network actions), and data
at rest (e.g. data storage) through deep content inspection,
contextual security analysis of transaction (attributes of originator,
data object, medium, timing, recipient/destination, etc.), and with
a centralized management framework.
The systems are designed to detect and prevent the unauthorized
use and transmission of confidential information.
- Wikipedia

4. DLP defined
• DLP as a pure play product vs. a feature
• Most organizations adopt a phased approach to implementation

5. Network DLP
• Fewer integration points so can be deployed
relatively quickly
• Mail
• Inline required for blocking
• Redirect to encryption gateway, etc.
• Web
• Sniffing
• ICAP
• SSL inspection
• Network monitoring / sniffing - chokepoints
• Provides wide coverage
• Useful when you don’t exercise administrative
control over all the endpoints

6. Endpoint and Storage DLP
• Endpoint
• Can’t deploy agents to systems you don’t already own and
manage / control
• Content matching is sometimes limited to rules based on
keywords and patterns, as opposed to fingerprints of
unstructured documents or structured data (due to size)
• Hybrid architecture with scanning duties shared between
endpoint agent and distributed network components
• Storage
• Agent-based vs. remote
• Agent intelligence vs. load
• Flexible scan control
• Gap in identifying file / content owners

7. Policies

8. Policies
• Metadata, e.g. policy group, severity, etc.
• Detection rules
• Exception rules
• Response or action to take
• Keywords / phrases
• Patterns / regular expressions
• Data identifiers
• Structured data fingerprint
• Unstructured data (document) fingerprint

9. Data Matching
- Securosis

10. Typical DLP criticisms
• DLP doesn’t prevent data leaks
• DLP doesn’t stop malicious insiders
• DLP is complex to implement and maintain
• Product and technology
• People and process
• DLP systems generate too many false positives
• Structured vs. unstructured
• Keyword and phrase
• DLP is expensive
• DLP can be bypassed
• rot13, encryption, low and slow, text vs. image
• DLP won’t deliver the expected value, won’t meet our
expectations

11. DLP benefits and value
• Forces security to focus on the data / information and business
processes rather than just the data containers / infrastructure
• Security develops a much better understanding of the business
• Security and business communicate in common terms
• Security visibility at senior levels is increased
• Gain more access to senior management
• Senior management ask ‘what are you doing about this’
• Fosters closer working relationship between HR, Legal, Public
Relations & Communications, Forensics, InfoSec and ITSec, etc.
• Many incidents are an opportunity for security education and
awareness
• Fraud detection and financial loss containment, brand protection
• Enables business unit information security officers

12. Education & awareness

13. Lessons learned
• People, process, technology – the order is important
• A DLP forum with broader representation is critical to provide
direction, guidance and clarity
• Centralized vs. de-centralized administration
• Policy development and refinement vs. incident handling
• IT generally needs to build the policies due to technical proficiency
• DLP policy management lifecycle
• Every organization probably has some information
that they don’t want monitored
• Written approval for new policies is key
• Information / policy owners must be clear on who will
be seeing incident data
• Technical policy development is part science, part art

14. Lessons learned
• Incident handling
• DLP policy ownership (e.g. new products) is key – security often doesn’t
know whether an incident is real, importance of knowing who to escalate to
• Incident handlers must be completely trustworthy
• Human resources data integration is critical to speedy incident review
(department, business unit, position, manager)
• Monitoring for one type of violation often reveals another
• Handling rules for incidents that may result in disciplinary or legal action
• Incidents often raises more questions – How did he get access to this
information? Who else has access?

15. Lessons learned
• Most DLP incidents highlight weak business processes rather than
malicious intent
• DLP systems can’t magically identify sensitive information
• Manage expectations – there is (still!) no silver bullet
• DLP exposes security gaps that need to be fixed through other
projects and solutions, e.g. IRM, secure file exchange, access
management
• The gaps often need to be fixed by business rather than IT
• “OK, I’ve found sensitive information on this file server. Who
owns it? Can I remove it? Now what?!”
• Information lifecycle management is the fundamental problem
that organization need to solve

16. Incident overview

17. Incident overview