Data-Centric Security: Mix Technology, Process update from February 2010
Aligning protection with data involves navigating corporate politics and business requirements and seeking out knowledge owners. A few key technologies can help, too.
February 18, 2010
As vendors, security industry pundits, politicians, and CISOs fire volleys back and forth over the best way to protect data, attackers are taking advantage of our confusion: The consensus among the infosec community is that 2009 was worse than 2008 in terms of data loss, and that's saying something. Remember 2008? The year 285 million records were breached--a number exceeding all of the records exposed from 2004 through 2007?
Respondents to our InformationWeek Analytics Data-Centric Security Survey know something needs to give--and they hope it's not the gates holding back the marauding hordes.
"Executives would like to believe that we're on par with others in our industry group, but this is not so," says one survey respondent. "I keep pounding the table for an independent evaluation. I know of holes. I fear that it will take a serious breach of [personally identifiable information] before we move forward with more robust security measures." Adds another: "We have cash-flow problems. And there are political problems when risk assessments unearth issues with outside vendors who we thought were properly managing data."
Speaking of outsourcing, we're seeing organizations large and small begin looking at mechanisms to off-load risk. These include the buzzword du jour, cloud computing--really just a bucket description for IT infrastructure, development platform, or software resources provided as a service. Organizations are also looking at third-party data storage and tokenization systems, where a sensitive piece of information, such as a credit card number, is traded for a one-time token that is then used in applications in lieu of the credit card number.
Of course, if outsourcing were anything close to a security silver bullet, we'd all be working for IBM. The reality is, putting large amounts of sensitive information into a few behemoth data centers simply creates bigger targets for attackers. Now, this doesn't mean transferring risk is always a bad idea. Many companies don't see security as a core competency and are better off hiring help. But they must do a darn good due-diligence job, because customers and regulators don't care if data is in your castle or your friend's castle--it's still your responsibility, and you'll be sending breach notifications.
Last year also brought a marked increase of involvement by both federal and state government agencies in cybercrime and cybersecurity matters. The Obama administration appointed Howard Schmidt to oversee the nation's cybersecurity initiatives, and the Senate Judiciary Committee approved two bills that seek to create a unified federal notification standard for U.S. businesses to follow, in addition to imposing prescriptive requirements for corporate data security programs. State legislatures are also getting into the regulatory mix.
We think the only sane response for IT is to adopt a security strategy that's focused on protecting both structured and unstructured data when it's in use by customers or employees, as it rests on network file systems, and as it traverses the LAN or leaves the corporate boundary. "The data-centric security approach is the key to transitioning an IT information security program to enterprise risk management," says Ken Rowe, director of enterprise systems assurance and information security for the University of Illinois. "As a university, we have data distributed across several major campuses, and just protecting devices doesn't scale."
Evolution, Not Revolution
As Rowe and others have learned, there's no such thing as a perimeter anymore. But the road to any new paradigm is rarely smooth. While our survey respondents are generally confident in their technical staffs' ability to implement a data-centric security model, they're constrained by funding and a lack of management sponsorship and organizational will.
The result: Most organizations we work with today still follow the castle/moat security policy paradigm: We have a bunch of data on a bunch of servers at our data center, and we'll control what goes in and out by putting guardians at the gates and forcing people to cross a moat. Firewalls, intrusion-detection/prevention systems, and Web application firewalls all follow this model, yet every major breach analysis has shown that data is much less likely to be stolen because of a vulnerability in the transport mechanism (for example, attackers figuring out a way to steal money from people walking over the moat's bridge) than by attacking vulnerabilities in the storage of the data (that is, the king's treasury is behind an unlocked door).
Now, we're not saying that firewalls and intrusion-detection systems are useless. Clearly, attackers are constantly testing our perimeters. But these devices no longer reduce risk as much as they used to, and in fact, the data-centric security concept is a natural evolution of the idea of defense in depth: Focus on the value of data and the fallout should it be compromised, rather than on how a compromise might occur.
Determine The Process
To get to this new paradigm, CISOs must articulate what makes data-centric security different from what they're doing now. In our practice and reflected in our research, mature adopters of the data-centric security model share some characteristics. They align their security priorities with business requirements by focusing on who and what get access to data. They align IT security controls and policies with quantified risk. And most important, they assign a data owner who is nontechnical, and upper management vests that person with full decision-making authority.
Read that one more time: We said nontechnical data owner with full decision-making authority. These data owners are tasked with answering the Four W's: Where is the data? What is the data? Who has access to it? And why do they need access?
When we put it like that, it seems like a no-brainer. That's why we were discouraged by the responses when we asked in our survey how widely data-centric security is used. Just 14% of survey respondents cite pervasive deployment of data-centric policies across their enterprises. Ten percent say minimal or nonexistent. The top response, at 37%, was fairly broad adoption, but mostly just on structured data, and 25% say they do just enough to meet regulatory requirements.
There are two main reasons the data-centric model hasn't taken hold more broadly. First, there's very little written information on best practices, and starting with a blank slate is daunting. Second, IT groups that attempt to implement data-centric security too often start out on the wrong foot. Almost every major data-centric security program our practice has seen gets labeled as "too expensive and worthless." They fail because of two basic flaws. First, the IT implementers focused on the data. Whoa, wait a minute, you say: Why would focusing on the data sink a program? Because despite the "data-centric" moniker, in practice, it isn't the data you secure, it's the container that holds that data. It's the business representatives' job to focus on data classification.
Second, IT took too prominent a role. In our survey, 42% of respondents say that IT manages the data types and makes the decisions. This means technical people are deciding the Four W's. Only 12% of respondents to our survey say they have a specific person or committee responsible for making decisions on enterprise data types.
To that we say: You don't ask business users to choose the server virtualization system you'll deploy, so why are you asking technologists to rate the criticality of data to the business? In organizations that implement data-centric security well, the data owner is a single person or focused committee for each data type and is empowered with the ability to make the Four W decisions. This person or committee must understand the data they have power over, which is why this role shouldn't be assigned to an IT person.
In organizations where the business has difficulty understanding technology, we recommend a three-person committee for each major data type: an IT representative, a business user with deep knowledge of the data, and a business user who is equal to or higher on the org chart than the data expert.
In our survey, a hybrid approach, where the business makes the decision and IT executes on it, is very common as well; 32% of respondents use this method. But the devil is in the details--just 12% of respondents say data owners have decision-making authority.
Furthermore, policies that define such areas as data classification, data retention, and data encryption are most often written by IT security executives or managers, who in our experience rarely align these policies with business drivers. The comments provided in our survey reinforce this point. Only 20% of respondents say their organizations have gone through data breach notifications, yet we saw an overwhelming response basically begging for a security breach to happen to "prove to management they need to take this seriously."
"Casual users still don't respect the value of data," says one respondent. "Unfortunately, the only thing that will get the attention of the sources of the problems is a catastrophe."
We've seen this attitude before in other surveys. We don't think IT really wants a serious breach, but we do understand where respondents are coming from. Perhaps CISOs are just prioritizing the wrong things when working with business management. We all know CFOs who view IT security as a cost with minimal business benefit. Fighting such an uphill battle can be discouraging, and when a breach does occur, IT security teams often fire back: "You didn't give me the money to stop it!"
If this lack of consensus isn't resolved, data-centric security will be impossible to implement.
The Technology Angle
While tight budgets are often cited as a factor in weak security, having plenty of money doesn't always equate to strong protection (though it surely helps). For example, companies that have deployed data loss prevention systems generally have mature data-centric security strategies. Is this a chicken-and-egg situation? It's possible that a mature strategy led these companies to consider DLP, as opposed to the DLP implementation forcing them to make their practices more mature. In many ways, this feels like network access control all over again: The CIOs who needed it knew they needed it and made the investment. The rest of the market didn't.
Although DLP is difficult to implement, in terms of cost and deployment time, it does seem to be worth the effort. In our survey, 60% of DLP users say they're satisfied with the technology, while 32% say they're very satisfied. Just 8% are somewhat (7%) or very (1%) dissatisfied.
We strongly advise enterprises to create and implement data-centric security policies before purchasing technology, whether DLP or data encryption or identity and access management. In fact, in his extensive review of DLP technology (informationweek.com/ 1240/dlp), InformationWeek Analytics contributor Randy George found that a successful deployment requires not just policies aligned with the business and an assigned data owner, but also a plan for discovery, integration, and ongoing administration. Each of these steps entails significant resources and time, but the payoff seems apparent.
Still, just implementing DLP and identity and access management isn't enough. Focus on identifying the containers of sensitive data types and then securing those containers. Once a container has been identified, whether it's an application or a database, policies should trigger appointment of a dedicated data owner or committee to ask the Four W's.
There are other keys to success.
First, ensure that management understands the need for your new direction, and secure high-level support. That's a weak point for our survey respondents, as 54% say a technical person is leading the charge. As mentioned, it's common to hear IT pros grouse that the business will understand the severity of the threat only if there's a security failure that leads to a data breach requiring notification.
We trust that this sentiment isn't being shared with business leaders. Doing so would be counterproductive at best, and very possibly career limiting. Instead, work up a presentation that explains the concept of data-centric security, references security issues in companies similar to yours, and describes how a new security direction could better protect your organization.
Next, enlist data owners to assign classifications. Judging from the survey respondents who left us comments, this is a sticking point, but it has to be done, and sooner rather than later. We asked respondents how they classify data; a system based on regulatory definitions of personally identifiable information was the top choice. The second largest number of respondents say they perform their classifications based on who will receive a given piece of data--for example, internal user, external partner, or customer. That's a distinction businesses can make easily, and most nontechnical executives can quickly assess the associated risks. We recommend basing classification policies on terms that the businesses actually use and not just on what their DLP systems can handle out of the box, even if that requires some customization.
"University security policies can't be dictated but have to be evolved through collaborative processes that engage all the campuses," says the University of Illinois' Rowe. "It's essential that the business owners be completely engaged in this process to ensure data classification is usable."
If all this technology and integration sounds expensive and hard to implement and manage, well, you've hit on the reasons why more organizations aren't deploying effective data-centric security strategies. But aligning security initiatives with data, and therefore business requirements, is the best way to ensure funding and executive-level buy-in.
Michael A. Davis is CEO of Savid Technologies, a Chicago-based security consultancy.
Write to us at [email protected].
You May Also Like