Data Security Lifecycle- Technologies, Part 1

Wow, there is a lot here to digest, and I have a lot of comments, so I will be succinct as possible:
1.This looks like a ‘sensitive data security lifecycle’, as opposed to ‘data security lifecycle’, the subtle distinction being the data has a lifecycle, not the process.
2.It is implied that you know where the sensitive data is prior to the process.  That is not always the case, in fact that complete picture of data and location may be the exception rather than the rule. I understand the model is to set policy at the time of data creation, but I have never been that lucky to not carry legacy data forward.  So are you advocating a migration approach where you push all existing data through the new process or systems over time? Are you suggesting that the lifecycle is to be applied over existing systems and processes?
3. I have never been comfortable with classification and setting rights prior to discovery.  You may not have a complete picture of the sensitive data that is present, and you may not understand its use.  Some peers have stated that they believe a ‘Monitor First’ approach to discover, in essence, what you don’t know.  Then you set policy.  I tend to prefer the assessment or discovery first approach prior to setting policy.  Still, I think it has to be one or the other, otherwise your policies are quickly obsolete.
4.On the subject of Policy Management, where would this fit in? 
5.t of the Administrator Separation of duties, your point about the need for products to mature in the next 1-3 years really hits the mark, and this is one of the biggest problems.  Today all of the claims are that the products provide this, but few even come close.  The ability to set and implement policy, collect data and statistic, verify that the data meets the policy, and (even tougher) verify that the policy is appropriate is next to impossible to do so and have a reasonable expectation of catching fraud.  To hammer this point home, Oracle’s Database Vault does provide the separation of duties within the credentials, but how many auditors could describe what label security is?  How many auditors are going to be able to discover the table identifying number and the event code for a failed login to implement the policy?  Some form of tool needs to take a policy and implement it, allowing the setter of the policy not to have deep database knowledge while still providing separation of duties. 
6.Content discovery, in and of itself is good, but in terms of structural data a ‘structural discovery’ has bearing on the data security and usage. 
7.Audit of events, especially in the area of policy change?  Is this meant to be covered by monitoring and implicit to access controls?

Adrian, some responses and some follow up questions to make sure I’‘m reading you right:

1. I think I’‘m missing your point here? We need to apply controls of some sort to pretty much all data, not just the sensitive stuff, and this is centered on the data, not the process. Maybe I just need more coffee.
2. That’s what the Discovery controls are for in a couple of the phases- since this will never be perfect, and classification will even change during the life of the data depending on changing contexts or business policies, Discovery is the control to sweep the environment, find violations based on current policy, and make necessary changes. Thu we can apply the lifecycle onto existing systems and slowly migrate data into it. For example, when I write up the process for implementing data classification it will work in manageable stages, focusing on a few critical policies at a time, rather than trying to fix everything at once. Some of this will realistically take YEARS to roll out, but we have to start someplace.
3. That’s the bit about automatic classification (which doesn’‘t really exist yet) in the Create phase. We can have a mix of mandatory and discretionary policies to help guide the initial classification. It won’‘t be 100%, but that’s whay we have the layers and multiple places where we can reclassify (via Discovery) the data. We know for sure there’s some stuff that needs to be protected at a certain level. For other things we need to make changes over time. I’‘m realizing this isn’‘t reflected well in the lifecycle and I think I need to figure out a way to manage changing classification over time better, which ties in with your business context comments from the other day. I’‘m open to suggestions.
4. Ouside the cycle- I haven’‘t been publishing everything in order, but that falls in with enterprise key management and a couple other things that support the cycle but aren’‘t focused on an individual data element.
5. Absolutely agree, and it’s a big market opportunity for a database security company (nudge nudge). Oracle/IBM are basically just patching this on, they aren’‘t really solving the problem at the fundamental level. It’s also why I’‘m so hot on Database Activity Monitoring.
6. Yep, totally agree and want to see more products for this. As I think you know I’‘ve been pushing for it for at least 2 years.
7. Auditing is part of Activity Monitoring, so it fits in a few places. I haven’‘t gotten to those controls yet, but will in the next post. There’s also auditing outside of the lifecycle, which is part of that "management backplane" I keep referencing and need to write up.

Reasonable responses? Or you think the model needs to be changed?

1. The problem is having too many control ‘‘frameworks’’ buzzing in my head, because I tend to think of the entire process being assessed on some cyclic basis, so the misunderstanding was mine.  In this case, the data has a cycle that it goes through.  I love the idea that certain types of data having a shelf life, which is a concept I had not even heard discussed until the last 6 months. 
2. Both.  Got it.

I think the rest are reasonable responses. The model seems to be flexible enough conceptually to allow for most considerations. 

I do have a question that may simplify the model, based upon a bias of mine.  The bias is I do not believe that there is no such a thing as DRM on unstructured data, but rather the process of cataloging, quantifying, assigning ownership rights to, storing, encrypting and (possibly) placing in context to an application (an attribute list) in fact produces a structural reference. At that point is a media file any different than a row in a database? If you buy that assertion, does this model lose anything if you treat everything as structured data outside of a formal ‘‘database’‘?

Damn- you’‘re forcing me to reveal some cards before I’‘m ready.

I think we’‘re moving into a world where all data is broken into discrete elements with labeling/metadata to support lifecycle (security and otherwise) controls. Those labels will flow as data moves between structured and unstructured data (think back to my old slide on "there’s no such thing as data at rest" I know you’‘ve seen).

For example, if I run a query in a database, the data returned is labeled, and if I put that data into a spreadsheet the spreadsheet is modified to meet the classification label of the most sensitive data element. Longer term, we’‘ll even become granular about data elements *within* structured data, but that’s easily 5-10 years out.

Right now I feel I need to break it apart between structured and unstructured just to make it more practical when securing operational enviroments. There’s a lot of momentum to keep them separate, with different teams managing different parts of the problem, and that’s a fight I can’‘t win.

Long term, as you point out, that distinction goes away. We’‘ll talk about "data elements", and be able to apply controls on an element basis no matter where they are or how they’‘re used.

We won’‘t be out of jobs for a very long time.

Hi Rich, sorry it took me awhile to comment on this.

I do notice a DLP slant on your lifecycle.  Not a bad thing, but you need to consider that as a design bias.

I have a theory that data is like matter and never created or destroyed, just altered.  In this case, where you have create I would say something along the lines of "aggregate" or "collect".

Classification also goes hand-in-hand with determining what regulations that data goes under.  Most policy, standards, regulations, and compliance are based on the type and quantity of data.  IE, if you take credit cards, you just signed up for PCI.  Classification tells you that.

Use or share should include derivative data.  A good example is the US Census.  They collect little bits of data from everyone and then use that data to derive a whole bunch of statistical data.  The statistical data has less protection needs than the raw data, but in some cases it happens the opposite way (think intelligence work and the aggregate and analysis being more valuable than the individual points).  Point is, the derivative data needs to be forked back into the beginning of the cycle and be classified to determine how to protect it.

"Share" *could* include something like non-disclosure or other managerial controls.  Typically what you do is take your level of protection for that data type and try to hold your partners to a similar level.  Ideally, we hand them a list of protections and they take the data and spin off their own data security lifecycle.

Archive should contain something about retention periods, escrow, and off-siting.  Not sure how it all fits in, but maybe mull it over a bit.

For fun, contrast your data security lifecycle with the Apple marketing from a couple years ago: "Rip, Mix, Burn." =)

You’‘re the second person to bring up 2 issues- the retention side, and the change in context over the life of the data.

I need to figure out a better way of reflecting both in the lifecycle. Retention is easy, but changing business/use context is more difficult. I’‘m open to suggestions…

[...] our last post on this topic we covered the technologies that encompass the Create and Store stages of the Data Security [...]