Data Loss Prevention – The People and Process Overlap
When we left off in Part 1 of this series, we discussed how training components that overlap technology and people can help your organization realize its Data Loss Prevention investments. While many of the items may appear to be common sense on the surface, I am astonished by the number of organizations that fail to address the overlap between areas.
For Part 2 of the series, I’ll address the importance of proper documentation and transforming tacit knowledge into explicit knowledge. However, this post is more than simply dropping breadcrumbs for the next person… It is more along the lines of having the right conversations and asking the right questions to drive and propel the artifacts necessary to realize the DLP investment.
From the conceptual standpoint, DLP is based on policies, many of which are formed from templates by the DLP software vendor. This can lead to a compliance perception, which may obfuscate the true understanding of the data structures and constructs the organization is attempting to protect.
Think about it. If an organization is in the healthcare industry, how convenient it is to click the HIPAA templates and call it a day? Do you really understand the true nature of the solution? Do you understand how your DLP software classifies specific pieces of information? Where is this information documented?
Perform solid use case testing. A software vendor may discourage or obscure the “secret sauce” of how the solution works; however, this is where solid use case testing comes in. Thoroughly testing the solution requires diligent understanding of the organization’s needs. Policy changes require incremental updates to this documentation. Furthermore, consider the impact of changing technology. Just because one uses solution ‘X’ today, does not mean that solution ‘X’ is the best solution tomorrow. Therefore, how much information will need to be performed to uncover the secret sauce of solution ‘X’ after the fact?
Consider the impact to the staff. Generally, DLP is a large enterprise system that requires care and feeding. Much of the care and feeding is done with little business oversight, meaning that there is a great deal of autonomy in the work to be performed.
Does the organization have a standard naming process for naming policies? Is it documented? Are there periodic audits into the policy to ensure that a policy named ‘Visa credit cards’ is not actually there to detect instances of the DLP administrator’s name or the CEO’s name plus the term ‘confidential’?
This is not to say that your organization’s DLP folks are rogue, but processes should be introduced to verify both the intent and effectiveness of those controls.
What is the liability to the organization if the DLP solution is a conduit to perform inside trading? What if your business thought they were protected against a specific permutation of a data classifier like social security numbers? Is it documented to ensure 123-45-6789 is being flagged as well as one-two-three-four-five-six-seven-eight-nine or a shift left of 234567891?
Your business partners expect that SSNs will not leave the company; however without documentation of the details, how can you be sure?
As before, I am sure there are plenty of questions like the ones I have presented here that are relevant to your experiences and frustrations. What opportunities do you see existing in overlapped space between people and process? Leave your thoughts on this blog, and stay tuned for the next entry in this series when I discuss the overlap between process and technology.