Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


11:15 AM
Bryan Simon
Bryan Simon
Connect Directly
E-Mail vvv

The Truth About DLP & SIEM: Its A Process Not A Product

If you know what data is critical to your organization and what activities are abnormal, data loss prevention and security information event management work pretty well. But that's not usually the case.

I work with organizations each and every day, building out their cybersecurity programs. During my many conversations with security teams struggling with data loss prevention (DLP) and security information event management (SIEM) -- and the security vendors that support them -- I have noticed a surprising trend. Each time either DLP or SIEM is mentioned, they are described as “products”-- a “DLP Product” or an “SIEM Product.”

Butthe reality of the matter is that the “products” are not the problem. The central issue is a misunderstanding of what SIEM and DLP truly are: a process, not a product.

DLP and SIEM defined 

First, some definitions to be sure we are all on the same page. DLP is a strategy designed to prevent the loss of data. DLP is often mentioned as a way to prevent users from uploading sensitive information into email, cloud storage services, and unauthorized file transfer capabilities.  

SIEM is an approach to security management that enables organizations to collect information from all of their disparate devices. Information (or data logs) are stored in a single location which provides the opportunity for advanced aggregation and correlation of data to help complete a more holistic view of an organization’s IT security posture. Using advanced techniques for correlation and aggregation, the SIEM looks for patterns which will help security teams identify technical issues, security breaches, and attacks more easily, and more importantly, allow for more timely response. Because prevention will at some point fail, it is more important than ever to be able to nimbly respond and recover the environment. 

Seems pretty straightforward, right? Not so fast, there is more.

DLP works well if you know what data is critical to your organization. But if you don’t, your DLP efforts will likely fail. For example, I constantly hear people talk about securing credit card information and healthcare data -- all of which is incredibly important information. However, rarely is this the only important information within the company. There is other important data that needs to be secured, but you must know what it is, and where it is, otherwise you can’t secure it. The process of understanding and identifying what data is important to your company is paramount to DLP success. Yes, I said process.

In the case of SIEM, while it is great to have all of your data in one place, if you don’t know what is normal and abnormal for your environment -- or even how to make sense of all of the noise of the logs themselves -- confusion is sure to follow.

I often compare SIEM deployments to intrusion detection system (IDS) deployments, as both share some common issues. Each environment is different. What might look like (and be) an attack in one environment might simply be standard traffic within another environment. If you don’t understand your environment, your IDS deployment will fail, just like if you don’t understand your environment, your SIEM process won’t be successful. (And yes, I said process again).

Achieving DLP and SIEM success

While I would like to say vendors should play a role in fixing these issues, they aren’t in the best position to do so. Why? Because DLP and SIEM are not “one size fits all” (despite being sold as such). Thus vendors will continue to sell a “product” that is billed as ‘just install it and it works’. Meanwhile, deployment issues will continue to plague customers. So, what is the answer for achieving DLP and SIEM success?

First, everyone (vendors and security teams alike) need to realize DLP and SIEM are processes. They are not products nor do they serve as a quick fix to a problem. To succeed, security teams deploying DLP and SIEM solutions must understand their environment and what data is important.

Second, IT, infosec, and executives all need to be involved in the DLP process. Part of the issue is that it isn’t always the security team or the technical team making the decision: it is often high-level executives driving the push for a particular product or solution. They’ve heard the buzzwords and think DLP and SIEM can help with compliance, so they check a box. Don’t get me wrong -- DLP and SIEM success absolutely needs executive support and buy-in in order to be successful. Just remember that being compliant and being secure are not the same. I want my clients’ security posture to make them automatically compliant. Compliance should be a by-product of a secure posture.

Third, IT and security teams need to understand what information is critical within their environment. While many believe they know what data is important, they often overlook critical data. There are controversial questions I like to ask of my customers, and the attendees that attend my SANS training. “Do you know what makes your company your company? Do you know the mission of your company? Do you really understand the business processes that make the company viable?” You might think you know your company…but are you sure? Surprisingly, most employees do not know their company as well as they think. If you don’t understand what is important, there is no way to protect it.

Fourth, education and training is key. Understanding how to get quick, tactical wins from the data you have within your environment is essential to protecting it. Hands-on, immersion-style training from real-world practitioners is essential for helping individuals understand what they need to look for and go down the path of detecting malicious activity. The adversary doesn’t want us to know the answers to my questions about data. In fact, the adversary depends upon your ignorance.

Security is far from being a lost cause; the more we are able to detect the adversary and respond, the more our adversaries must adjust their tactics. And when we make them adjust, it actually makes them more detectable. And the best part? It is circular. The more we detect, the more we can feed into response capabilities. And the more we learn from our response, the more we can feed back into detective capabilities. Let’s put ourselves on the winning team. We need to understand what works and what doesn’t. And that starts with understanding that two of the most important things we can do in the name of cybersecurity, DLP and SIEM, are process -- not product. 

Bryan Simon is a SANS Certified Instructor and an internationally recognized expert in cybersecurity, with a special focus on defensive and offensive capabilities. Bryan's scholastic achievements have resulted in the honor of sitting as a current member of the Advisory Board ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
[email protected],
User Rank: Author
9/15/2015 | 12:55:57 PM
Re: Under-utilization of DLP and SIEM
I think the issue again is that even if we were to call it a product that requires a process, we still miss entire portions of our organizaton that has data that needs to be secured from loss. DLP isn't just our digitial data, but also, as a very simple example, data in printed form. Data in printed form is also in scope for protection. We have several public high profile examples of where individuals have carried sensitive information (paper documents) out of an organization, that needed to be protected in both digital and printed form.

Thanks for the good comments!
[email protected],
User Rank: Author
9/15/2015 | 12:51:12 PM
Re: Under-utilization of DLP and SIEM
You are exactly correct with your statements. That was why I decided to write the article. The article was written to point out that these activites are attempted to be done with technology only, which isn't possible. And further, the technology cannot do the 'process' driven portion of the work required to have a succesful implementation.
User Rank: Apprentice
9/13/2015 | 1:46:31 AM
Re: Under-utilization of DLP and SIEM
An interesting article, not sure your argument applies to SIEM as the 'process' (more of a service) is only found inside technology. Moreover the process is provided with matromony of people with technology.

A more apt example than DLP or SIEM process would be vulnerability management. Many vendors proclaim that the service resides on a device which scans your network. However, we know that finding technical vulnerabilities stretches further than seeing which server needs the latest patch or not. 

I agree that understanding what data is important is the first initial step, (then regularly refreshing) is important but I view this as a parallel activity and of which the processes are dependent upon. Finding out what is important, classifying it and safeguarding it are more GRC activities than technical ones.  
User Rank: Apprentice
9/11/2015 | 8:09:52 PM
Under-utilization of DLP and SIEM
It seems that the inability to recognize these "products" as process, or maybe it would be fair to call them a product that requires a process, results in them sitting on the shelf, and not being deployed to their full potential. This seems to be especially true for DLP. There seems to be a large challenge for organizations who are working with an older security system. This is where newer organizations in some ways have an advantage that they are starting from scratch, and can make sure to use best practices from the outset.
What the FedEx Logo Taught Me About Cybersecurity
Matt Shea, Head of Federal @ MixMode,  6/4/2021
A View From Inside a Deception
Sara Peters, Senior Editor at Dark Reading,  6/2/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-13
The package studio-42/elfinder before 2.1.58 are vulnerable to Remote Code Execution (RCE) via execution of PHP code in a .phar file. NOTE: This only applies if the server parses .phar files as PHP.
PUBLISHED: 2021-06-12
Receita Federal IRPF 2021 1.7 allows a man-in-the-middle attack against the update feature.
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an OutOfMemory-Exception while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an infinite loop while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-16 package apport hooks, it could expose private data to other local users.