DLP is Short for Disturbing Lack of Process?
Ted Ritter has suggested that we rename
Ted Ritter has suggested that we rename DLP a Disturbing Lack of Process…
Indeed DLP is not a well-defined term – since so many vendors (Kaspersky anti-virus, McAfee anti-virus, Symantec anti-virus, Trend Micro Provilla, CA Backup…you name it) have labeled their products "Data loss prevention” products in an attempt to turn the tide of data breaches into a franchise that will help them grow sales volume.
I disagree however – that DLP might be renamed as a "Disturbing lack of process”. Not even as a joke.
I do not think that lack of business process is the issue.
Any company still afloat today has business processes designed to help them take orders, add value and make money.
"The question is not lack of process but whether or not security is being used to help enforce business process in the relevant areas ...”
- Danny Lieberman
- Blogger, Information Security Resources
They understand by themselves that they must protect their intellectual property from theft and abuse.
The question is not lack of process but whether or not security is being used to help enforce business process in the relevant areas of product safety, customer service, employee workplace security and information protection in business-to-business relationships.
In a profitable company, the business processes are aligned with company strategy to one degree or another.
Good companies like Intel are strong on business strategy, process and execution while government organizations tend to be strong on strategy (President Obama) and regulation (FISMA) and short on execution (Obama Nobel Peace Prize).
This is true in most countries, maybe Germany, Singapore and Japan do a better job than most.
I think we are doing most businesses an injustice by asserting that they have a "disturbing lack of process”- instead we should focus on the question of where and how security fits into the business strategy and how it can help enforce relevant processes in the areas of customer protection and privacy, customer service, employee security and privacy and information protection with business partners.
An approach that uses data security for process enforcement automatically aligns data security with company strategy (assuming that the business processes support the company strategy, we may assume an associative relationship).
Using data security for process enforcement also simplifies DLP implementations since the number of business processes and their data models is far smaller than the number of data types and data records in the organization.
Easier to enumerate is easier to protect.
It is indeed immensely easier to describe a 7 step customer service process and use DLP to enforce it than try and perform e-Discovery on 10 Terabyte of customer data contained in databases and workstations.
The 3 basic tenets of information security are data confidentiality, integrity and availability.
DLP addresses the confidentiality requirement, leaving integrity and availability to other technologies and procedures that are deployed in the enterprise.
The key to effective enterprise information protection is making information security part of enterprise business processes – for example:
- Confidentiality: not losing secret chemical formulas to the competition. (Note that credit card numbers on their own, are not confidential information according to any of the US state privacy laws. A single credit card number without additional PII is neither secret nor of much use).
- Integrity: not enabling traders to manipulate forex pricing for personal advantage.
- Availability: protecting servers from DDOS attacks.
DLP is having an uphill battle because (in the US at least), DLP technologies are point solutions deployed for privacy compliance rather than for business process enforcement and enterprise information protection.
DLP technology is best used as a process enforcement tool not as a compliance trade off; unlike PCI DSS 1.2 section 6.6 that mandates a Web application firewall or a software security assessment of your web applications.
It is easier (but perhaps more expensive) to buy a piece of technology and check off Section 6.6) than fix the bugs in your software – or enforce your business processes.