Security and Risk Management Strategies Blog

Security in Context – Take 2

Blogger: Eric Maiwald

Back in November, I put up a blog post on Security in Context. I want to revisit that concept in light of a client question I received today. The client was asking about securing employee access to data – access anytime, anywhere, from any device. Clearly this is a problem that will only increase as enterprises move to the consumerization of client devices.

This is clearly a business issue – the business wants employees to be able to work wherever they are and when the employees want or need to work. At the same time, the data that the employees need to access is sensitive and needs to be protected. Just saying “no, you cannot access the data” will not work. So how can the risk to the information be managed?

There are options but all have disadvantages. Remote desktops could be used but that requires good, solid connectivity. If the business wants employees to be able to work on airplanes, remote desktops probably will not work. Enterprise rights management could be used to allow only authorized users to access data or perform only authorized activities. The choice of ERM solutions depends on the format of the data, how the files will be created, and the actions the user may want to take on the files. Client-side virtualization might be something the enterprise should look at in the future but the use of client-side virtualization may require some type of trusted hypervisor on the endpoints.

While it may seem that there is no real solution here, the fact is that there are potential solutions but these need to be evaluated within the context of the business problem. In this case, the problem is that sensitive information needs to be accessed by employees who are using unmanaged devices. A more detailed discussion needs to take place between security, IT, and the business to see which option offers the best solution to the problem.

Security in Context is the theme for security and risk management at Catalyst this year. Please join us April 19-22 in Prague or July 26-30 in San Diego for a discussion of Security in Context. If you are coming to Prague, you can use the promotion code “INSIDER” when you register for a discounted price of €995.

Beyond the Tipping Point: Responding to Operation Aurora

Blogger: Dan Blum

 

Hack attacks referred to as “Operation Aurora” by the multiple groups of Chinese hackers that reportedly perpetrated them from 2006 onwards hit at least 34 companies in the technology, financial and defense sectors.

 

Ladies and gentlemen of the jury, let me remind you that in this court of public opinion we do not have legal jurisdiction over the Government of China. We do not have to prove beyond reasonable doubt that said government is guilty of conducting a massive and continuing cyberwar linked in nefarious ways with an international world of cybercrime. Our life of information security is a civil life. Our response to Operation Aurora is a civil action.

 

So do not ask me, as someone did during my “Threat Assessment in Dangerous Times” telebriefing (client access required) yesterday whether I can “prove” China was behind Operation Aurora. To reach a verdict in the civil court of life we don’t have the same standard or proof you saw required at the OJ Simpson trial, for example. We only need a preponderance of the evidence. We only need to be 51% sure, not 100% sure. Myself, and a lot of people, are well past 99% sure. Hillary Clinton, who spoke for the U.S. in officially denouncing the attacks, would not do so lightly, and would probably agree with me.

 

Get past the confusion about how we prove origin of incidents that begin with a threat behind smokescreens of onion routers and proxies in uncooperative jurisdictions. That is not the issue. Individuals and organizations, cast off your paralysis. Respond to Operation Aurora.

 

But respond how? Google must have calculated it had less to lose in a China syndrome of continuing intellectual property theft and brand erosion. Google went public. But many other organizations export (or hope to export) to China. They fear the repercussions of standing up to China, even if they think (or know) that the government is perpetrating, supporting, or tolerating cyberattacks against them.

 

 

http://commons.wikimedia.org/wiki/File:IllegalFlowerTribute1.jpg  

 

Commercial organizations may be in a quandary, but their publics and their governments will respond. To paraphrase what one panelist from a leading threat intelligence company said during my telebriefing: “We’ve blown past the tipping point where traditional protection paradigms apply. We’re in the third wave of electronic information protection. From worms and cyber pranks beginning in the 1970s we escalated to widespread cybercrime beginning in the 1990s and recently to cyberwar. Just think about the Estonia, Georgia, and Operation Aurora incidents. Governments are responding. Massive amounts of money will be thrown at the problem and for the next few years no one will know who is in charge.”

 

Government response is necessary because no individual and few organizations can resist the related juggernauts of China cyberwar and worldwide cybercrime. But government response is also dangerous and could make cyberwar worse. In my opinion, however, that risk is less than the risk of not responding to an unacceptable status quo.

 

So my final editorial comment and advice is that if your organization thinks or knows it’s been attacked, try not to roll over and play dead. Go public like Google if you can or if you dare. The more companies and individuals speak out, the less any one of us will face repercussions, and the sooner we’ll see positive change.

 

But if you can’t go public, at least advocate among your peers for a discreet report of the incident either to law enforcement or to information sharing groups. Our public response to Operation Aurora and what will surely be ongoing problems of international cyberwar and cybercrime is going to require the best factual information about incidents, the best deliberations, and the best lobbying, diplomacy, legal, economic, and infrastructure responses possible.

An Introduction to Data aliasing, AKA “tokenization” and “pseudonymization”

Blogger: Ramon Krikken

I recently finished a set of documents on what we now call data aliasing. If nothing else, the issue of terminology proved to be a challenge, with different industries having their own terms to describe this process of reversibly transforming confidential data into an alias that maintains, or is similar to, the original data format. In health informatics this transform is called pseudonymization, which allows private health information (PHI) to be de-identified for certain uses. In the world of payment systems it is called tokenization, and applies – perhaps obviously – to reduce the amount of sensitive card information subject to PCI-DSS regulation. To use a generalized term, data aliasing (as subset of data masking) it is.

 

At the surface the concept is simple, but the devil – as usual – is in the details. There are different aliasing algorithms (randomization versus encryption), aliasing service architectures (interfacing, and location of databases), and application architectures (where is the aliasing performed). The choice of what to use, in today’s environment where product choices are limited, is not trivial. Luckily, as products mature we should see more flexible solutions that are conducive to supporting many of these options, and proper architectural planning can go a long way.

 

However, the enterprise should not jump on the product bandwagon without considering the big picture. The business and IT should work together to decide on whether to suppress, redact, anonymize, or alias information in order to protect it (and consider not only the security pros and cons, but also those related to usability, availability, etc.) As I discussed in “Will 2010 be "the year of the data?" an information-centric security strategy is vital … perhaps we can use the current buzz around data aliasing, mostly in the form of data tokenization for PCI-DSS, as a way to focus on information as being the core asset.

 

This is only the beginning of an ongoing thread on data management and data security. Joe Bugajski from out Data Management Strategies team and I will lead off the information-centric security track of our Catalyst Europe conference, discussing how trends in data management and security interact and drive the needs and solutions in the enterprise. And at the RSA 2010 conference I will be on a panel to discuss tokenization in the payment industry. Hope to see you at these conferences, and stay tuned for more.

Electronic Discovery and Privacy: Puzzling

I was in Germany last week giving a talk on Unified Communication (UC) Security. UC involves the convergence of lots of different types of communication over IP (and thus, the Internet): voice, video, email, instant messaging, and so forth. It also creates new types of interesting sensitive data, such as presence—where users are located, what types of devices they use and their capabilities, and online status. Clearly, security teams need to think about the security implications of UC, including protecting the confidentiality and integrity of these channels.

They also have to think very carefully about the electronic discovery of information that flows through these channels. In the past, instant messages and voicemail were considered short-lived. They were rarely saved for a significant period of time and weren’t treated as essential records for doing business. In the world of UC—where many different types of communication can be sent, saved, forwarded, archived, and otherwise be endlessly manipulated—suddenly these assumptions change. Executive voicemail messages with terms of a pending merger may be forwarded via email; customer service interactions with clients may be recorded over instant messages; a videoconference with the new sales manager may be saved on the corporate portal. Each of these may be construed as critical business communications, and under U.S. law may need to be preserved for evidence in court. (Certain regulated industries may have already recognized such messages as business communication and taken steps for retention and protection.)

The problem is a fundamental conflict between the data preservation requirements of electronic discovery and the privacy protection requirements of EU laws. Speaking with a German audience, we all nodded in agreement about the dizzying array of Scandinavian, French, German, Swiss, and other privacy requirements surrounding business data. To comply with privacy law, many organizations choose to de-identify personal information in some way: mask, anonymize, alias, redact, or otherwise obscure data records to ensure that personal details can’t be linked to specific users (whether customers or employees). Often this applies to metadata—logs, message envelopes, etc.—rather than the content of a message, although it could be either. Generally, de-identification satisfies privacy requirements, but it raises all sorts of interesting complications for discovery. Once records or messages have been saved in this modified state—with many details changed or removed—what’s their status as evidence in court? Can the records be submitted to opposing counsel “as-is” (de-identified)? Must they be reconstructed to include private details? Or do they have to be originally saved in an unaltered state (re-introducing the privacy problems we tried to avoid in the first place)?

The Sedona Conference (www.thesedonaconference.org) is working on this problem. There’s acknowledgement in the legal community of the issues, but there’s not enough precedent for security teams to know how to proceed at this point.

What’s the next step? I shall fall back on the last refuge of a security scoundrel with this advice: talk to your lawyers. However, some of these issues were discussed at the 2009 Conference on Cross Border Data Flows, Data Protection and Privacy. A panel discussion on Cross-Border Discovery Conflicts highlights some practical steps that organizations can take to tackle the problem. The Georgetown E-Discovery Law Blog nicely summarizes at www.law.georgetown.edu.