Creating an enterprise data protection frameworkDate: Oct 23, 2009
By creating a data protection plan, security professionals are able to ensure valuable data remains under control and make more effective use of the assets within a company.
This video explains the basic steps for creating a data protection plan and shows you how to implement effective data security policies and procedures.
About the speaker:
Russell L. Jones is Partner AERS - Security & Privacy Services with Deloitte & Touche.
Return to Executing a data governance strategy.
Read the full transcript from this video below:
Creating an enterprise data protection framework
Eric Parizo: Hello and welcome to Creating an Enterprise Data Protection Framework, with guest speaker Russell L. Jones of Deloitte Touche part of SearchSecurity.com's Data Protection Security School which you can visit at any time, by going to searchsecurity.com/dataprotection.
My name is Eric Parizo and it's great to have you with us.
Every enterprise has sensitive mission critical data it needs to protect but if your idea of your organization is hoping it can keep that data safe by merely crossing its fingers and hoping for the best, then that's a recipe for trouble. By creating a data protection plan, security professionals are able to ensure valuable data remains under control and make more effective use of the assets within a company.
This will explain the basics for creating a data protection plan, organizing and implementing security policies and procedures and securing key enterprise data. More specifically, we will explain how to determine the types of data that would fall within the scope of the framework such as: PII and intellectual property. Identify and select the controls that are the base of the framework using ISO 17799 and regulatory requirements, rationalize which controls remain in the framework and which ones do not. Map remaining controls where they address unique requirements within an organization, and perform a risk ranking exercise and gaff analysis between the data protection framework and the business process/IT environment.
Our speaker today, Russell L. Jones has significant experience working with Deloitte Touche clients in the development and implementation of information security, privacy and data protection programs. With more than 15 years in consulting, he has worked with a number of Fortune 500 corporations, including several in the Fortune 100.
Thanks for joining us today, Russell.
Russell Jones:Thanks again, Eric for that great introduction. Really what we're going to talk about is creating an enterprise data protection framework I guess the key thing about this particular presentation and really what I wanted to focus on with the participants is the fact that, there's great technology tools out there, which encrypt data on laptops and encrypt email and access control products, but you know, without a framework and a risk-based approach, how do you really know what the right answer is for your organization? And, our way of looking at this and helping clients address it, is by putting in place an enterprise data protection framework, which is really the focus of this presentation.
You see the agenda. Here's really what we're going to cover today. First I'm going to define a problem space which is always important. Once we've done that, then we'll talk about what are the pre-requisites to building your enterprise data protection framework. Then we'll go and talk about defining the data protection requirement sources and we say “requirements” but you can think of them as controls. They are the same thing. Then we'll talk about creating the enterprise data protection framework, now that we've kind of laid the groundwork for it in terms of the prerequisites, you know where you go get your requirement sources. Once we've created it, then we can talk about how do you leverage, what are the different things you can do with that framework, and then we'll wrap up with Q&A.
Defining the problem space. The key thing here is that data has value and that value is really driven by things like its attributes, its enterprise contracts and its associated risks. And by attributes we mean you know things like, what kind of data is it, what type of data is it? Is it digital, is it paper, and what type of data is it from a contextual standpoint; is it intellectual properties, is it personally identifiable information and so on and so forth. I mean, those attributes, those are things about the data that help us get to what type of controls should be in place to best protect it.
You also need to look at enterprise context, meaning well, how is the data used and where in the business is it used? Is it in the research department? Is it in legal? Who's touching it? Then your associated risk is what you think it is. What are the risks to that data? Whether it's the risk of the data being destroyed or it's being compromised by competitors or other parties that want to get access to it that are unauthorized.
Those things help us define the value of the data. At the same time, you have to look at the fact that the data is moving through the organization in a life-cycle. So, from the time the data is acquired or created, through storage and usage and sharing with individuals through destruction. That data is moving through that life-cycle and it's recursive, so it's constantly going on and on and on through this life-cycle. The value of the data while it's driven by those things like its attributes, enterprise context and associated risks, the value changes over time as it's moving through the life-cycle. That’s really a key concept to understand when we talk about data protection. Because, my experience has been that many organizations focus on certain types of data, let's say intellectual property, and they focus their efforts on that data in a particular place in the organization in a particular physical or logical location. They spend all their efforts putting encryption in place and other controls, feeling like they've locked it down. The reality is, that data travels from that particular server and application to many, many different places downstream, in terms of, data extracts and data feeds to other systems, eventually ending up on maybe a researcher's laptop.
The real point of this side is, you really can't focus on data protection unless you really understand the value of that data and acknowledge the fact that it's moving through a life-cycle constantly, inside of an organization and also outside the organization, when you start talking about supply chain partners and the like.
Now, just to dig a little bit deeper into this notion of data and its attributes, you know, really this guy is trying to convey that when we think about the type of controls that need to be put in place to protect data, you really have to look at it from a couple of different dimensions. One is the data attributes themselves. But the other is the end entity attributes.
We say “end entity”, as opposed to “user” to acknowledge the fact that many times it's not just a human being sitting at a keyboard that's accessing data and viewing it, changing it and sending it out in emails, so on and so forth. It can also be processes, things like Web services that also can touch that data and do the same types of actions to it. That's why we say “end entity.”
Really, the point of this slide is, you've got to look at the intersection between the attributes of the data and also the end entity attributes, so you know, human versus entity, you know, hierarchical position, functional role.
You know, really we're saying you got to look at who's touching the data, what is their functional role in the organization, are we talking about a human versus a process; are we talking employee versus contractor? Those things help to drive out really the type of control that ultimately need to be put in place to protect the data. You see off to the left side of the slide we talk about things like definition of access. Understanding and defining access control for the data in your organization really will come down to understanding the end entity attributes, who's touching it and what are the attributes of those entities and then the attributes of the data itself.
That's also going to help you define things like segregation of duty. Definitions of security levels for example. Again, this just kind of goes back with the previous slide to say, When we're going to put together a data protection framework that drives out the type of controls that you need to put in place to protect data end to end, you really have to look at the attributes of the data.
You have to look at the attributes of the entities touching the data and you have to acknowledge the fact that, that data's moving through a life-cycle constantly, inside the organization, outside the organization. All of those factors, as we'll see in the next slide, building the data protection framework, really do help you get to the answers of what type of controls will be put in place to best protect that data.
Moving on to the next section, which is “Prerequisite Work”. The key questions are: What is the data that we're talking about? What is the data in question that needs to be protected? Where is that data? Then, how is that data used and by whom and what? Right? Those are the questions.
That is the prerequisite work that you, hopefully, have done already in some form or fashion before embarking on framing an enterprise data protection framework, because the answers to these questions are inputs to the data protection framework.
Now, I'll just caveat to say, in the real world, most organizations I've worked with have some or most of these questions answered. In many cases, they don't have all the questions answered. That doesn't stop you from creating a data protection framework. But you're going to need to get the answers to those questions. When we talk about data classification, the “what”; what is the data? One way to get at that information is data classification. Assuming you have a policy in place, and you have a data classification scheme, when we talk about, where is the data, who is using it and how are they using it. Really, we're talking about things like business process flow diagrams and data flow diagrams.
We also can look at things like records management policy. For example, if you have a records management system in place. We can look at the policies and the procedures to also get an understanding of who is using the data and how is it used? How does it get stored and archived, which again, is part of the overall life-cycle of data.
We talk about data classification policy here for a moment, and all I'm saying here is, if you have a data classification policy, that's great. Usually what we see is that it's based on some standard, you know, more often than not these days we see it based off of ISO 17799 2005, which is you know one of many standards out there that help you kind of put your policy in place about how data or information gets classified. Usually what I've seen is that three to four categories max, should be sufficient in terms of how you classify your data.
More than four categories becomes very unwieldy and there's a lot of work out there, some different bodies of work on data classification out there to support what I'm saying, but that's my personal experience. You know, once you get beyond about four categories it's very difficult to manage your data classification system.
Usually, what you'll see is something like some data is classified as public, a lot of data is classified as confidential, very sensitive data is classified as confidentially restricted or some derivative of that. Again, these are just example categories. Many organizations have different names, but the same concept basically.
The thing about data classification that really helps is as you start thinking about developing your enterprise data protection framework, hopefully if you've got data classification policy and scheme in place to implement it, or at least it's been implemented in some key parts of the business, you've already got a leg up on understanding the types of data out there; intellectual property, PII, financial data, so on and so forth. You've got some sense, hopefully, of where that data is.
If you've gone through the process some of my clients have gone through, they've actually mapped some of that key data and maybe in some cases even labeled it electronically and physically in physical documents and they know where that data is and they're able to at least map back to key parts of the business and the business processes regarding that data, it’s sensitivity in terms of the classification scheme and then the types of controls they put in place.
Again, I want to re-emphasize on this slide, this is something that will save you some time as you're starting to develop the enterprise data protection framework. But if you don't have it, it's something that you're going to need to do; and how you go about doing that? There's different ways to go about doing that, but is something that is going to need to be done on one level or the other to serve as an input to the data protection framework.
So, now we move on. Well, where's the data and how's the data used? Here again, what I've seen personally with most of my clients are business process flow diagrams. I think a lot of organizations got comfortable doing this as a result of stocks. As they went through the process of documenting the controls and the business process flows as it relates to their financial recording related systems. So that's good. You've got the experience there for true data protection at the enterprise-level, the data that you’re concerned about goes way beyond financial reporting systems and stocks. It goes out into your manufacturing systems and your research areas, and so on and so forth.
In terms of the experience, an example of a business process flow, here on this slide really what you see is a small segment of the order management process. What's good about it is, assuming you have this documentation, it becomes much easier. If you think for example about a particular type of data that maybe you'd be concerned about. Maybe it's financial or maybe personally identifiable information, and being able to think about it, as you walk through the business process, and look at the actions that happen within the business process.
You look at the roles in that process and who is able to conduct that process. Who has approval authority, and so on and so forth. It becomes very easy to kind of flow and understand, let's say, PII again. Does it exist inside this business process or not? You can actually see it as you think about the roles people play in the business process and what kind of data is getting processed with the nature of these activities.
It becomes much clearer, when you're able to put a flow diagram together like this, to understand how data is being used and of those data sets being used, do you have particular types of data that need special protections, like PII for example, or very sensitive financial information?
For example, if we're talking about an HR system, employee data. Right? This is one tool that can help you to get a handle on, again, how data that is the focus of your data protection efforts is being used, who's touching it and where it's moving through the organization.
What we typically do with my clients, is we create a supplemental data-flow framework to go along with the business-process framework. The business process shows you, or management or research in a research division or HR; it shows you from a business perspective what are the major inputs and outputs, what are the activities and basically how data flows through the organization and how it gets processed.
If you go a level below that and try to understand from following, let's go to the PII example again, personally identifiable information. I'm following PII through this particular business process and a group of business processes. Now what I want to see underneath the business process is the technology systems where that data actually resides. It's being processed, it's being stored, it's being transferred. Those systems typically are things like databases, email systems, file shares, archival, records management systems, et cetera. This guide is really showing a lower-level view of that data. Again, we'll take PII as an example, and how it flows through the organization.
This is taken from an actual client. When we went through the exercise, and documented and followed the data from a business process level, and we followed it and looked at the underlying systems, that's the point of those business processes and followed the data as it flowed through the organization. Everywhere you see red, these are systems that have PII, very sensitive information that needs certain types of protective measures and controls in place.
Now the interesting thing about this kind of exercise is at the beginning of the exercise, clients always say, “We know for sure where the particular type of data that we're concerned about is. It’s on this system, it's on this database, it’s on this server”. When you actually go through the exercise of, again, flowing the data that you're concerned about through at a business process level and then tying it to the underlying support systems that support those processes.
Just about every time we've done this exercise when we get the visual map like this, people are, clients are very surprised to kind of see all of the different systems where that data ends up that we're concerned about. It usually is way beyond the scope of what people believe the data was at the beginning of the exercise. And that's really the point of it.
There's no mystery in it and also, that you have a good scope now to go and create your data protection framework, this is a very critical exercise to go do.
Finally, when you think about the archival and storage of data that you're going to protect, another good source to kind of understand that in the organization is to look at your records management policy and the procedures and standards and how you'd implement that policy. Now, again, many organizations are basing their policy and their kind of approach on an ISO standard, 1549, but there are other standards out there as well. This is just one of the most popular.
The key thing about the records management policy procedure standards is, again, it helps you to understand, at least when you think about the part of the data life-cycle where data is stored and maybe even destroyed; it helps you know, in your organization where that data is, the systems where it is if it's digital or, if it's physical, like paper or microfiche; where that data is and what form is it in.
It also helps you from a risk perspective understand the value of that data again. Because early in the data life-cycle some data might be very sensitive; it might be very time sensitive and it needs very special protective measures. Later in that life-cycle, when the data's become public or de facto public, it doesn't need the same level of protection. The risk is greatly reduced. I'm not going to labor on this more, but this section is really just to say, there's prerequisite activity that hopefully has been done. If not, you need to go and get the answers to these questions to really be able to build your data protection framework.
Okay. Now we're going to move onto the next section, called “Defining Data Protection Requirement Sources.”
Now really the question to ask yourself as you're embarking on the data protection framework is: What are the universal data protection requirements? When we say “requirements” really what we're talking about are controls. The type of controls that will need to be put in place based on the risk to that data and the context of the data in the organization.
As you start to build your data protection framework, the first thing you'll need to determine is all the different inputs from a controls perspective or requirements perspective into the framework.
Here, really, what I wanted to share with you, are some of the kind of considerations to be able to understand; what are the requirements for your organization as you go through this process? Really what it breaks down to is this: You need to understand the geographic locations of your organization. Are you a company that's based solely in the U.S. or, are you a multi-national with offices and operations in other countries? That makes a difference in terms of the type of controls that you're going to need to have in place because different countries have different rules and regulations and laws about data and how that data gets used, who uses it, is it being transferred, all that type of stuff. You need to look at the geographic locations of your organization.
You need to also understand from an industry perspective what kind of regulations are out there that kind of set forth data protection type requirements. Financial services and life sciences for example, are two good examples. We'll see in a few slides coming up some very specific examples of industry specific regulations that you've got to deal with and address above and beyond, maybe, some of the other requirements out there, other laws and so on and so forth.
Then you've got legal and regulatory requirements, legal requirements, meaning laws that you have to abide by. That you have to satisfy in terms of protecting certain types of data, dealing with your customers or your business partners. Then the regulatory requirements, again, will be coming out of the laws that have been set and they typically are coming from sector-specific, industry-specific organizations at the federal level that take the laws and promulgate regulations, if you will, based on the laws.
You also have to look at contractual requirements. You might have very specific contracts in place with your business partners that talk about how certain types of data need to be handled and protected. In coming up with the, again, controls that you'll need to put in place to protect the data that's important to you; you really need to go and look at all the different places where data is going out of the organization and coming into the organization as relates to third-party vendors, business partners and the like. Search out those contracts and understand the contractual requirements that are in place. Those contracts, in many cases, are going to dictate the type of controls that need to be in place from a contractual perspective to protect certain types of data.
Another source is data protection standards. Things like ISO standards. Those are best practices, leading industry practices that are internationally accepted, which can provide inputs as well as through the types of controls that need to be in place.
You look at the sum total of these things and that's what helps you come up with the basic set of controls that make sense for a particular organization in the context of that organization. Context meaning industry and your business models and who you do business with, so on and so forth.
Now, I want to take this and kind of walk through a fictional company to kind of show how this all comes together. Let's say for example that we have a multi-national life sciences organization. Their headquarters are in Los Angeles. They've got operations in a few different states. As you can see, Texas, Washington, so on and so forth. They've also got international operations in the UK, France, Spain, Singapore and Tokyo.
These are all important things to know as you start defining your data protection requirement. If you take this example a step further, here's what this organization has come up with in terms of the requirements that they're going to need to address from a controls perspective. In terms of industry, because they are life sciences, they have to deal with Food and Drug Administration 21CFR Part 11, as well as HIPAA, the Health Insurance Portability Accountability Act.
There are very specific security and privacy type requirements in those regulations that they're going to have to implement, so they don't run afoul of the regulations and get shut down.
Similarly, because they have operations in the US in California, Colorado and Washington, there are some data protection requirements they've got to deal with, so for example, they are headquartered in California. California has a law on the books called SP1386, which essentially says, if they lose any customer data, data of their customers, if it gets out there and they can't demonstrate that they had adequate protection in place, which the law defines as encryption, basically. They've got to notify all of their customers, regardless of whether there was an actual breach or not. It's just the fact that, if they believe that the data's been breached, they can't account for that data, somehow it got outside of the organization.
As you can see, there are similar laws in Colorado and Washington that also speak to the same issue. They have to abide by those laws and the regulations we talked about. In addition, because they have operations in the EU, they've got to also abide by the EU data protection directive, which is really the floor. It's the minimal requirements you have to have in place to protect data about individuals, in this case, personally identifiable information. It’s a very rigorous law and it's enforced much differently than we do here in the US. They've got to worry about that. In addition, the EU data protection directive is the floor, so each member state in the EU can go above and beyond that floor in terms of the type of protective measures and controls that they require:
This organization, this fictional life sciences company, is going to have to also understand what does the U.K. require, what does France and Spain require? And in addition in the Asian-Pacific region, they have their own kind of data protection privacy law in place. They're going to have to deal with that.
If you go around this pie chart to just show this fictional organization and what they've got to deal with, they also realize that they want to use ISO 17799 as they’re a good data protection standard. They're also going to leverage parts of the NIST 800 series 800-53 PCI because they do have customer-facing websites where people will do purchases and the AICPA/CICA framework. Additionally, they've looked at some of their contracts with supply-chain partners and business partners and there are confidentiality provisions in the contracts that they have to abide by.
Hopefully, what you're getting the feel of with this particular slide is all of these things are going to really help drive out the specific controls that need to be put in place for this organization to be able to address their data protection requirements. Whether that data is, again, PII, intellectual property, sensitive financial information, what have you. This really becomes your universe of requirements, if you will.
Now we're ready to move to the next section, called “Creating the Enterprise Data Protection Framework.”
We’ve talked about understanding the data and the value of the data and how it moves through a life-cycle. We've talked about prerequisite work that you need to go do hopefully, over on things like data classification, business process flows and understanding where the data is, how it moves through the organization, what systems that the data touches as it moves throughout the organization and understanding the specific type of data that you're concerned about. And then we talked about how do we come up with the basic set of requirements that make sense for a particular organization so that they can protect that data.
Now that we've done all that, we kind of bring it all together in creating this enterprise data protection framework. It's really a basic three-step process at this point.
The first thing is you really want to select some standard and again, more often than not these days, organizations are going with internationally accepted standards. ISO 17799 is a very popular one but it's not the only one. But you want to nevertheless select a standard that becomes the, I would say, the baseline of your data protection framework.
What I want you to visualize here is, take a standard like ISO 17799 for example. It's got 11 major domains or clauses as they call them, at least if you're using the 2005 version. And inside of each of those clauses, is a major control objective, so, for those of you familiar with COBIT, this is very, very familiar. A major control objective and then under that control objective, there are specific types of controls that you can implement.
For example, if you think about clause 7 within ISO 17799, “Asset Management,” there is a major control objective which says, “The objective is to achieve and maintain appropriate protection of organizational assets.” And then inside of that you get different sections that give you the specific controls that need to be implemented and then guidance around how to go implement those controls. So, 7.1.1, “Inventory of Assets,” this is a specific control. The control is, “All assets should be clearly identified and an inventory of all assets drawn up and maintained,” and so on and so forth.
Imagine taking this ISO standard and putting it in a matrix, or a spreadsheet. So you've got all the different controls and control objectives of seriously going top to bottom in the matrix. Each row essentially becomes a control that you've taken out of the ISO standard or pick your standard, as I said.
And so, that becomes your baseline. Now, the real process is to rationalize the requirement that you previously identified as you went through that exercise, you know, thinking about what industry you were in and all that good stuff, and rationalize it against this baseline standard that you picked, ISO 17799, in this case.
You go through that process and then once you go through that process, a few iterations of it, then you go out and get this enterprise data protection framework with stakeholders in the company. That's an important part of the process, because without going through and talking to key people in the lines of business, like manufacturing or legal, for example, or research, or sales and marketing, there's going to be some unique requirements that come out of those conversations. Unique to their part of the business and the type of data that they're handling, that would not necessarily make it into the standard.
On this slide, you see on the left-hand side, are all the requirement sources that we previously identified in terms of regulatory state laws, international laws etcetera. And then on the right side you see kind of the output or what we're trying to get to, which is the enterprise data protection framework. So the key is in the middle. What I call, “rationalization logic,” and again I go back to visualize this matrix, which you've built, which has, like, ISO 17799 for example, basically populating every row. Every control and ISO standard you've got populated in this matrix.
Now, the rationalization part is literally kind of lining up on each column of that matrix. Each one of the laws, state laws, industry regulations, international laws etcetera you have over here in the requirement sources, those become columns. You have this matrix that's getting really long now. Really big, but what you're going to do is, to each control that essentially is applicable from a data protection standard. That's probably one thing I should step back and talk about.
You know, with ISO or any of these standards, there are quite a bit of controls out there that have less to do with data protection and more to do with information security, and that's fine, so you can eliminate those ones, right off the bat. Essentially, just take those out of the scope of your data protection framework. Again, whether it's ISO or another standard, you can leave just the data protection relevant control in your framework. Assuming you've done that, now you're populating each column with your requirements over here to the left, and you get this really big matrix.
The rationalization process, and there's different ways to do it, but conceptually what you're trying to do is go through and for each of the controls that you've got from your standard like ISO, you want to go across and look at each of these specific requirements that you've identified and see if there is a very similar requirement that matches up to your ISO requirement.
You go through that process and I'll give you a good example here. Let's say, for example, let's go back to the asset management Part 7.1 in ISO 17799. So, if I was to kind of go through and populate this matrix with the fictional life sciences company we were talking about, I would see, for example, control 7.1.1. So inside of the Asset Management section there is a control called 7.1.1, which says, “All assets should be clearly identified and an inventory of all assets drawn up and maintained.” Right? That's my baseline control. Now, I've populated my matrix, for this particular life sciences fictional company. If I go across, I find that there is a similar control under the PCI standard, which basically says, “Properly inventory all media and make sure it is securely stored.” That's an example.
Another example is, if I come down to control 7.1.2 in the baseline standard ISO 17799, there's a control that says, “All information and assets associated with information processing facilities should be owned by a designated part of the organization, movement of assets should be tracked along with associated updates to owner information”. If I look at that particular control and I come across on my matrix that I've built, I will get to a very similar control in the HIPAA standard which basically says, “Maintain a record of the movements of hardware and electronic media and any person responsible therefore.”
What you start to see again as you line up all of the columns, all the different standards requirements that you've developed, you start to find similar requirements. Where you find similar requirements you can normalize to your baseline ISO standard. What you're left with is, like, an 80/20 rule. You'll have a set of controls here in your ISO standards that satisfy pretty much 80% of your data protection problems. Once you've gone through this complete exercise.
Now what you'll also find though, as you go through this exercise, is there may be requirements under HIPAA, there may be requirements under a state law, that don't exactly map to your baseline control in ISO. In some cases, it will just be a completely new requirement or control and that gets added to your data protection framework. In other cases, it will be similar to your baseline control, but with some additional provisions or maybe a different focus. So in that case, what you would do is modify your baseline control. You would literally modify the control, the language, to essentially now address this unique requirement coming out of another state law or international law or regulatory requirement.
Again, you'll find your own process but I call it rationalization logic, because you're going to have to go through this process and this [inaudible 00:38:54] but you're going to need to go through this process a few times to eventually arrive at a matrix that has a set of controls now that address all of your requirements over to the left. The output is what you've got on the right here, this framework, that we call it. Essentially the framework, again, this one is based on ISO 17799. You see the categories of risk assessment, security policy, asset management. They tie directly back to the ISO standard. Plug in whatever standard you want which works for your organization, but the point is, now you've got your framework.
It's a framework because we still haven't implemented anything. What we do have is a framework on what we're going to need to go implement because we've identified the controls that address all of our data protection concerns back on the left-hand side.
Okay. Now we've built this great enterprise data protection framework and again, the reason we call it “enterprise” is because the scope of it hopefully has addressed your entire enterprise, which means not just financial reporting related systems i.e. [inaudible 00:39:53] but the whole scope of your business. This would have been determined way back when, when we talked about doing the business process flows and data flows, right, where you're looking at flowing certain types of data that you want to protect, PII or whatever, across the organization from manufacturing, if you're a manufacturing organization, all the way out to the customer and looking at supply chains, so on and so forth. That’s why we call it an enterprise data protection framework. The scope of it is the enterprise.
Now that we've built this enterprise data protection framework, we can talk about some of the ways that this can be leveraged. For example, now you can perform a gap analysis of existing data protection controls. What you can do, with this data protection framework, is go out and see of the controls you've identified in the data protection framework, which ones are already implemented out in your business and how well have they been implemented? And you can find this out through assessments or through self-surveys that you send out to business process owners or IT security can go and do it, or internal audit can help you go and do it. But the point is, it's a very useful tool now, to kind of understand what do you have in place that can be leveraged from a data protection perspective. What kind of controls, what parts of the business, what technology systems.
The flip side is, now you can see the gaps. You can see areas that aren't addressed from a controls perspective, and those areas obviously those become the focus, depending on the type of data that's flowing through those parts of your business. Those become the areas where you can now start to very precisely focus resources and effort to go and address those gaps and that really becomes areas that need to be remediated, if you will, because of the exposure to the business based on the type of data.
I think the third part of it is, once you have understood the gaps in your organization, where you've gone through some type of process of understanding gaps from a controls perspective and you can go remediate those gaps and some of them are very tactical. You might find certain types of data.
For example, I worked with a client once; we were asked to do external penetration tests and within a couple of days we were able to get in and take over the entire environment and one of the things that we found, which really alarmed them, was a server that had a number of un-filed patents in various forms. That’s something that they're going to go and address immediately in terms of locking down that server and putting controls in place. They're not going to spend months putting together road maps to go and address that. Those are some very practical control issues that will fall out of this gap analysis.
There will be other control issues that really require some research and some due diligence to determine what is the best approach, what is the most pragmatic approach, cost effective approach and also the approach that has the least impact on the current business. Because business doesn't stop when you have to address these issues, it goes on, and so the way that you go about addressing these issues has to be as transparent as possible to the business.
So those kind of gaps, really, they get addressed in a better fashion when you lay out a roadmap. And that's really the step three that you've got here. From this one gap analysis you can now really look at bigger, more strategic issues around data protection in your organization and come up with a roadmap for implementation.
This particular slide shows an example for a fictional organization of a data protection roadmap that they laid out after they had gone with their enterprise data protection framework and done a gap analysis through a risk assessment process. As you can see, some of the things that they realized based on the controls that weren't in place, was they have a big problem with laptops, not having any kind of encryption on those laptops.
You can see at the top left-hand part of this roadmap, they lined up a laptop encryption pilot. They're going to do a pilot first, to look at some different vendor technologies and find the best fit for their organization and their laptop platform and their IT support services.
Once they do the pilot successfully, they're going to move to Phase 2. They're going to emphasize the point of whatever the solution is they came up with in the pilot and they're going to push that out to the organization for all people that have laptops. That's one example.
Another example that came out of this particular gap analysis process is the fact that this organization needs to enhance their data protection policy and procedures. They need to actually go back and update their policy and then they need to create some new procedures which they realize now, after looking at some of the gaps from a controls perspective and they need to enhance some other procedures, so then that becomes a project. And if you kind of follow it across, you can see that there are some other projects that deal with enterprise rights management. There is a pilot, if you look down at the very bottom center of this road map, there's a pilot and then there's a deployment of an enterprise rights management product.
What they found when they did the gap analysis using the enterprise data protection framework is they've got certain types of intellectual property that's going back and forth with some of their business partners and joint alliances through things like email in the form of PDF files and Word documents and so on and so forth. What they realized is they've lost total control over a lot of this information which could really represent billions of dollars in losses to them and things like litigation coming out of patent disputes and trade secrets disputes and those types of things.
What they realized in looking at the kind of control gaps they had around certain types of intellectual property, is that they wanted to put an enterprise rights management system in place, along with corresponding policies and procedures. That’s what you see lined up here on the roadmap.
This just gives you one example of how the enterprise data protection framework can help you again really understand where you need to focus the effort in your organization to protect certain types of data that you have recognized are critical to the business, that impact your brand, can impact your future revenue streams, that get you in trouble with the law or regulators.
The framework really helps you put some precision as well as some risk based kind of rational around how you would get to these kinds of projects we see here on the roadmap. It doesn't become a kind of put your finger up in the wind exercise, but it really becomes a risk based approach in kind of really nailing down specifically where there are control gaps in your organization and then the type of projects and solutions that need to be lined up to adjust those gaps.
With that, I have finished my formal session here and I will turn it back over to Eric at this point.
Eric Parizo: All right. Great presentation, Russell, thank you. It's time now for our Q&A segment.
Russell a couple questions for you. First and this is something I believe you touched on earlier, but what if you don't have a data classification scheme in place. How would you proceed in developing the enterprise data protection framework?
Russell Jones: That's a great question Eric. I guess I kind of alluded to that earlier in my presentation because, again in the real world, there are a lot of organizations that haven't really effectively implemented data classification schemes.
I've worked with clients that have at least come up with a policy and the scheme, but they never got around to implementing it and understanding, based on the scheme, where all the data was in the organization. That's fine.
I would say it does not preclude you from developing your data protection framework, but what you may have to do, what I've done with some clients, is, you may have to do some of this kind of in conjunction with developing your data protection framework. For example, I worked with a client recently where we did as kind of a side or parallel project, we worked with them to take the data classification scheme which they hadn't implemented, but at least they had a policy and a scheme that they had agreed on and we decided, again, based on a risk-based approach.
Everything should be risk based because there's not enough time, money, resources, to attack an entire organization all at once, given the fact that you're in business to do whatever you do. Or as you would hear Cisco say, “core versus context”.
What we did, we focused on some high risk parts of the business where they had concerns, namely the research organization for this particular client, and the sales and marketing. Right? This was the area of concern from legal, from IT and from internal audit. For those particular parts of the business as a side project, we went and applied the scheme to types of data that was in the scope of data protection, namely intellectual property and personally identifiable information.
We actually went through and we did interviews and surveys with people in the business that were knowledgeable and came up with some very high level data flow-diagrams and business process diagrams where we could show the different data classifications where their data was and the fact that the controls that were outlined in the policy and the schemes weren't in place in many cases when we actually looked at the data from a specific part of the business and business process perspective.
So, yes, you can do it and again, like I said earlier, you're going to have to answer these questions but if you don't have these things in place like a data classification policy and scheme you're going to have to potentially do some of that information. You're going to have to do some of that activity along with the data protection framework.
If you don't actually have a data protection scheme in place, I think at that point you're probably going to have to get, maybe even in a prerequisite project there's going to at least have to be some guidelines and some agreement set down by legal and the business owners, because they're going to really drive out, at least in my experience, the data owners, the business process owners, legal are really going to be the ones that decide what type of data, what should it be classified, what would be the impact to the business if it got out there. If it got compromised, if it got accessed by inappropriate parties, et cetera.
Depending on, if you don't have a scheme at all, you're probably going to need to get some involvement from again, legal and the business owners where you're focusing what parts of the business and maybe even internal audit to help give you the information and answer the questions that you need as you develop the data protection framework.
Eric Parizo: Next question for you. What are some other standards that are typically used as the basis for the enterprise data protection framework? I'm just curious what your thoughts are on some alternatives.
Russell Jones: Well, as I said earlier Eric, the primary standard that we see is the ISO 17799 2005 simply because it is an internationally accepted standard. More and more external audit organizations and internal audit organizations within a company have gotten familiar with that standard. With that said, some of the other standards I've personally seen get implemented as far as data protection, I've seen COBIT.
I've also seen Australian standard 4360, at least in one case, used as the baseline if you will, for the data protection framework. There are other standards out there as well, but I would say COBIT is one that I've seen more than a few times, when I don't see the ISO 17799. I've seen Australian Standard 4360 at least once.
Eric Parizo: All right Russell. Here's our last question. What are the characteristics of an enterprise data protection framework project? I mean, how long does it take, what kind of resources go into it and ultimately what's the cost range? I think that will probably be another long question but. . .
Russell Jones: [Laughs] Yes.
Eric Parizo: …I'll leave it to you.
Russell: The first thing I can tell you is, I won't be able to answer the part about cost simply because it depends, right? It depends on whether or not an organization is going to tackle this as a purely internal project, or if they're going to tackle it using external consultants. Then, depending on which consultants they use, the costs vary pretty drastically in terms of the rate per hour.
That said, what I will talk about is the characteristics of the project and I'll talk about it in terms of man hours. So, person hours, I should say, to give people a good feel for kind of what we're looking at. Typically, when I've worked on these projects, usually you're talking about on a small end, a 6 week, a four to 6 week project when you're talking about a mid-sized organization which includes you know, maybe data protection specialists with some oversight from a consulting firm.
Then there's going to be input from the client from IT security and maybe some interviews with people inside the lines of business and then maybe some input from some other places in the business to kind of help with the development of the framework and then maybe some of the other stuff we talked about earlier in terms of data classification, business process flows, those types of things.
Really, what it nets out to if you look at it from an hours perspective again, this is a mid-size organization, 4 to 6 week project, 3 FTE's. I mean, what is that if it's like 3 FTEs, 4 to 6 weeks you're talking 480 hours, somewhere between 400 and 600 hours to do it soup to nuts, mid-size organizations.
Larger companies that we've worked with at Deloitte, your Fortune 500s, these projects are like 8 - 12 weeks. The FTEs are somewhere between 3 - 6, and 3 - 6 will vary between 3 or 4 FTEs, could be like a consulting firm like Deloitte and 2 - 3 of those FTEs could be the internal client, but you're looking at a team of like 6 FTEs over a maybe 8 - 12 week period to really go through all the
steps of activities that we talked about in the presentation. I can't give you costs perspective, but I can give you kind of like the level of hours somewhere between, like I said, 400 to 600 hours for a medium-sized organization and up to a 1000 if you're talking about a large organization.
I would say from 500 to 1000 if you're talking about a large organization. Again there is a great deal of variability because different clients want to take a different level of responsibility in executing the project. They might put more internal resources to focus on it and use their external consulting firm as really just kind of like a QA and the subject men or specialists to kind of oversee the work that they do. So, but regardless of costs, the hours we're talking about is in that range, whether the organization does it internally or engages a consultant to do it or some hybrid.
Eric Parizo: All right. Very good. Once again, we'd like to thank Russell L. Jones of Deloitte & Touche for joining us today. For more information on how to use a common data governor framework, read Russell's exclusive companion tip via the link on your screen and be sure to check out the rest of the informative content in searchsecurity.com's data protection security school, also via the link on your screen, or any time at searchsecurity.com/dataprotection.
Thanks to all our listeners for joining us. I'm Eric Parizo. Stay safe out there.