Back in Part 1 of our series on Pragmatic Data Security we covered some of the guiding concepts of the process, and now it’s time to dig in and show you the process itself.

Before I introduce the process cycle, it’s important to remember that Pragmatic Data Security isn’t about trying to instantly protect everything – it’s a structured, straightforward process to protect a single information type, which you then expand in scope incrementally. It’s designed to answer the question, “How can I protect this specific content at this point in time, in my existing environment?” rather than, “How can I protect all my sensitive data right now?” Once we nail down one type of data, then we can move on to other sensitive information. Why? Because as we mentioned in Part 1, if you start with too broad a scope you dramatically increase your chance of failure.

I previously covered the cycle in another post, but for continuity’s sake here it is, slightly updated:

  1. Define what information you want to protect (specifically – not general data classification). I suggest something very discrete, such as private customer data (specify which exact fields), or engineering documents for a specific project.
  2. Discover where it’s located (using any of various tools/techniques, preferably automated, such as DLP, rather than manually).
  3. Secure the data where it’s stored, and/or eliminate data where it shouldn’t be (access controls, encryption).
  4. Monitor data usage (various tools, including DLP, DAM, logs, & SIEM).
  5. Protect the data from exfiltration (DLP, USB control, email security, web gateways, etc.).

For example, if you want to protect credit card numbers you’d define them in step 1, use DLP content discovery in step 2 to locate where they are stored, remove them or lock the repositories down in step 3, use DAM and DLP to monitor where they’re going in step 4, and use blocking technologies to keep them from leaving the organization in step 5.

For the rest of this series we’ll walk through each step, showing what you need to do and tying it all together with a use case.

Share: