Blog

The Data Security Lifecycle: Beta 1

By Rich

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.

No Related Posts
Comments

I can’t help but think about the ISO/IEC 11770 when I read this. The 11770 describes key management lifecycle of cryptographic keys. It describes 11 services and 5 states. They are expressed as a matrix with services in the left column and transitions as the first row and the intersections are numbers linking to paragraphs that describe the intersection.

I think that what you have here is something very similar, your attempting to describe data services and align them to the data transitions and they don’t map into a linear diagram well.

I imagine the data states as follows: generated, modified, stored, distributed, archived, and destroyed. And this is very similar to the taxonomy that you proposed as it differs only in label not in function.

However, for me what is interesting is the corresponding cryptographic services and how they intersect with the ‘states of data throughout its lifecycle.’

I have only given this a few minutes thought so please excuse the repetition and or incompleteness of the edge cases: (copy and paste into a ascii editor to see the chart)

            | generated | modified | stored | distributed | archived | destroyed |
|————————-+—————-+—————+————+——————-+—————+—————-|
| Encipherment   |        |      |  x   |    x   |    x   |        |
| Digital Sig   |    x   |    x   |      |        |      |    x   |
| Access Control |        |    x   |  x   |    x   |    x   |    x   |
| Integrity     |    x   |    x   |  x   |    x   |    x   |        |
| Auth Exchange   |        |      |      |    x   |      |        |
| Routing Control |        |      |      |    x   |      |        |
| Notarization   |    x   |    x   |      |        |      |    x   |
|————————-+—————-+—————+————+——————-+—————+—————-|

I don’t know if those are the correct places for the x’s - I’ll leave that for you to work out. Additionally, I also borrowed heavily from the ISO 7498-2 since there are known services and standards to reference for those mechanisms. To me this is a much clearer start on the security services mapping, and certainly describes the paper to be written. For example when do you sign generated data? What countermeasures does this provide against what threats? Is this forensically important and when? What laws and regulations are applicable in what jurisdictions? Not to mention the many other business ramifications like - do we need a TTP or a PKI, what does that cost to deploy and manage and what additional threats does it introduce; and how does it impact the existing architecture and services?

Cheers,

Dennis

By Dennis Groves


[...] The Data Security Lifecycle [...]

By Data Security Lifecycle- Technologies


[...] be sorely disappointed. Long term, it’s a powerful platform to anchor major portions of the Data Security Lifecycle, and the really interesting times still lay [...]

By Updated) DLP Acquisitions: The Good


[...] be sorely disappointed. Long term, it’s a powerful platform to anchor major portions of the Data Security Lifecycle, and the really interesting times still lay [...]

By DLP Acquisitions: The Good


[...] post on this topic we covered the technologies that encompass the Create and Store stages of the Data Security Lifecycle. Today we’ll detail out the tools for Use and [...]

By Data Security Lifecycle- Technologies


[...] week or so ago I published the Data Security Lifecycle, and so far the feedback has been very positive. While the lifecycle is a high-level list of [...]’,

By Data Security Lifecycle- Technologies


I like it, it’s certainly a workable model, but there a couple of things I’‘d like to consider - the physical and logical boundaries for one, which become very important when considering the controls.
At first glance, the controls are good, but could be ordered as to when they happen in the cycle, the phases can use more detail. I’‘m going to put something together and send it to you for a critical eye - possibly over the weekend as I’‘m pretty busy with the new job right now. You are right about policy, but you will see what I mean when I say it is important - it helps when the physical boundaries are drawn. This will make sense when I show you.

By Rob Newby


Again, if you check the ILM definitions that’s the closest I can get. I don’‘t want to belabor it too much since that’s just a giveaway I tossed in to show ILM types where things fit in. Also, the box is meant to overlap Archive and Destroy.

I don’‘t want to get all hung up on policy. Policy is the tool you’‘ll use to codify all of this into enterprise law. Classification, rights, and the rest all have to be defined in policy someplace.

Unless I’‘m not understanding you properly. Which is possible. Because I’‘m an American.

What do you think of the phases and control mappings?

By rmogull


I’‘m not sure archive can be considered the "final settlement", even if it lasts a very long time, data will always be finite surely? Therefore "destroy" seems good enough as an end point to me. Anyway, security too often gets sidetracked in semantics.
I’‘m just drawing some of my own stuff out, and it seems to me that there should be a mention of policy in this, covering everything from creation to destruction, if it is to be effective.

By Rob Newby


A final settlement.

I believe. That’s directly out of ILM materials and not a term I created. That bottom slide maps the Data Security Lifecycle to ILM.

To be honest, not sure who came up with the "official" Information Lifecycle, but that’s where it came from.

By rmogull


If you like to leave comments, and aren’t a spammer, register for the site and email us at info@securosis.com and we’ll turn off moderation for your account.