I never meant to become that “data security” dude.

Back when I first transitioned from a consultant to an analyst I was given a hodgepodge of technologies to cover. Since I’d been a DBA and programmer I picked up database security. No one was covering encryption, so that fell in my lap. We’d recently lost the person covering forensics and acceptable use, so I ended up with that as well. This was all about 5 or so years ago, and at the time it seemed like a random collection of technologies.

Then I started noticing some similarities and overlap. Clients would call in to ask about these different technologies yet they were all often working on solving the same problems. At first it was defending against, “the insider threat”, but then it started to transition into protecting data/content. I started digging in and realized that although we in security have spent years talking about insider threats and protecting data, our advice was typically little more than hand waving or “encryption”, without really understanding what encryption can and cannot protect against.

I decided to try and pull this all together into a framework and my first pass was the Data Security Hierarchy. While a good start at figuring out the various layers used to protect data, it really doesn’t help you figure out when to apply controls and which ones work best under which circumstances. It was little more than an interesting conglomeration of generic technology layers that isn’t actually very practical in designing security controls.

Thus I’m proud to announce my next attempt- the Data Security Lifecycle. This time I’ve broken security controls out based on the lifecycle stage of the data. From creation to destruction, the Data Security Lifecycle shows which controls should apply at which phase. This provides more practical guidance and helps prioritize data security technology investments.

200709251024

This diagram is the high-level controls view. While in some cases these controls map directly to a specific technology, in other cases a single control may map to multiple technologies. Future posts will map specific technologies to specific controls, so don’t beat me up over the genericism quite yet. This view represents both structured and unstructured data; future posts will break them out separately since you can’t treat a database the same as a Word document. Finally, this view does not prioritize controls based on data classification. Again, that’s fodder for a future post. Yep, I’ve got a heck of a lot to write about here and will be breaking it out into manageable chunks.

In developing the Data Security Lifecycle I reviewed many of the information lifecycles out there, and paid particular attention to Information Lifecycle Management (ILM). I didn’t feel that ILM mapped as well as we needed to the security domain so I decided to borrow elements of it, but in the end designed a more security-specific lifecycle. The stages are:

  1. Create: This is probably better named Create/Update since it applies to creating or changing a data/content element, not just a document or database. Creation is defined as generation of new digital content, either structured or unstructured. In this phase we classify the information and determine appropriate rights. Sounds hard, but in many cases this will be performed by technology or default classification and rights applied based on point of origin.
  2. Store: Storing is the act committing the digital data to structured or unstructured storage (database vs. files). Here we map the classification and rights to security controls, including access controls, encryption and rights management. I include certain database controls like labeling in rights management – not just DRM. Controls at this stage also apply to managing content in our storage repositories, such as using content discovery to ensure that data is in approved/appropriate repositories.
  3. Use: These controls apply to data at the point of use- typically a user’s PC or an application. We include both detective controls like activity monitoring, and preventative controls like rights management. Logical controls are typically applied in databases and applications. I’ve also lumped in application security although that’s a massive domain on its own and mostly outside the scope of this lifecycle.
  4. Share: These controls apply as we exchange data between users, customers, and partners. This again includes a mix of detective and preventative controls, such as DLP/CMF/CMP, encryption for secure exchange of data, and (again) logical controls and application security.
  5. Archive: In this phase data leaves active use and enters long-term storage. We’ll use a combination of encryption and asset management to protect the data and ensure its availability.
  6. Destroy: Not all data is permanently retired, but when it is we need to delete it securely and use tools like content discovery to track down any lingering copies.

For you ILM geeks, here’s a mapping of the Data Security Lifecycle phases to ILM:

200709251026 All of this is a work in progress. Over the next few posts I’ll start mapping these high level controls to specific technologies (distinguishing between structured and unstructured data) and prioritize based on classification level. Not all the technologies we’ll be discussing are the most mature in the world, so we’ll also prioritize a little bit based on what’s effective and practical in today’s markets.

I don’t consider this anything revolutionary; it’s merely a logical progression, as we see improvements in both the available technologies and our understanding of how data is compromised. I’m trying to present it in an organized big picture. It’s one of those funny things that seems to take endless hours of thought and doodling to build a simple looking diagram that doesn’t look like much. Oh well.

This is still all under development and any feedback (preferably in the comments) is appreciated. Eventually I’d like to use this as a basis for a comprehensive book on data security, but that’s still a little ways out unless one of you fine readers is independently wealthy and would like to support my lifestyle while I write full-time.

Share: