Security and Risk Management Strategies Blog

Risks Around Hosted Email

Blogger: Eric Maiwald

Email is information on the move! It is different than information at rest.

In talking to analysts in Burton Group’s Collaboration Strategies Service about one of their talks at Catalyst, I heard a very disturbing idea. We were discussing hosted email and one of the analysts, Bill Pray, mentioned that enterprises that were moving toward using hosted email (email in the cloud) were keeping “sensitive” departments (HR, finance, etc.) on internal email systems. The reasoning was that these departments dealt with sensitive information and therefore should not be included on a hosted system.

But wait! This assumption may sound right on the face of it but it does not hold on further analysis. Back in (ancient) history, information was stored in filing cabinets. Cabinets in HR and finance were locked to prevent unauthorized people from seeing the information. As we moved to a more computerized environment, sensitive departments were given their own file servers so all of the sensitive information was stored together and the number of people authorized to access the files was limited. This worked as the information was at rest.

Email is information on the move and violates this base assumption. You can segregate the email from HR, Legal, Finance, and other sensitive departments to protect it, but as soon as someone sends email out of the protected environment, all bets are off! Most email is likely to be between team members but not all. Just think about HR. Employees may send sensitive emails to HR people and vice versa. The sensitive information exists in the email system – not just within the HR email system. The same is true for any of the other departments as well.

Don’t just assume that the paradigm used for information at rest works for information in motion. You have to treat them differently!

Of course, the bottom line for very sensitive information is: Do not send it over email in the first place. If you absolutely, positively, have to send very sensitive information over email, use some type of encryption mechanism along with a strong authentication mechanism to protect it.

Where is Enterprise Digital Rights Management Going?

[Blogger: Trent Henry]

Burton Group has long covered enterprise digital rights management (known varyingly as ERM or E-DRM). Our most recent report on E-DRM describes the technology as “driving security to the data.” Similar to consumer DRM schemes that protect Windows media or Apple iTunes content, E-DRM uses cryptography and fine-grained policies to limit what a user can do with data. Unlike consumer media, however, E-DRM is used exclusively by enterprises to protect corporate data and is typically targeted at word processing files, spreadsheets, email, and related content.

Here in Prague at Burton Group’s Catalyst Conference, many of our security talks have been geared around the trend of information-centric security. As a result, several attendees have approached me to ask, “Where is E-DRM going?”

Good question, but a hard one, because even Burton Group is of a mixed mind on the topic. On one hand, we see E-DRM as software-based technologies whose consumer counterparts have suffered one break (attack) after another. In short, they’re low-surety solutions. In addition, the products suffer from an in-your-face user experience that necessarily adds complexity for employees. On the other hand, E-DRM is arguably the finest example of security surrounding data itself: fine-grained policies (e.g. “You cannot print this document and may only email to other Finance Group members”), cryptographic protection, and prevention of other sorts of leakage (e.g. no copy/paste to unauthorized applications).

The vendor landscape for E-DRM has changed substantially in the last 18 months. Microsoft has made significant strides in adding E-DRM support to SharePoint. Oracle, through its acquisition of Stellent, picked up SealedMedia. And EMC, through its acquisition of Documentum, did the same with Authentica. The remaining standalone vendors are Adobe and Liquid Machines. It’s clear that vendors are solving one typical objection to E-DRM: the management of yet another silo of policies. By linking Enterprise Content Management (ECM) and E-DRM, the content repository’s security settings can automatically be reflected in DRM-protected documents that leave the ECM environment.

Where does that leave us?

•  We have cautious optimism that E-DRM will continue to receive uptake, even though today’s deployments tend to be relatively small and tactical.
• We expect vendors to enhance protection, making use of trusted platform modules for integrity validation and hardware cryptomodules for improved cryptography handling.
• We expect additional integration between rights management and content management solutions.
• Ultimately, we think there will be interesting synergies between virtualization and E-DRM, where mobile workloads (on virtual machines) and the sensitive content they contain can be managed, tethered, and persistently secured via rights-management no matter where a machine image lands.

WHAT IS OPENID FOR?

Blogger: Bob Blakley

There’s been a bit of a dust-up over OpenID recently in the blogosphere. First Eugene and Vlad Tsyrklevitch published a paper at BlackHat 2007 outlining a bunch of weaknesses in OpenID. Then Stefan Brands amplified the critique in a long blog post. David Recordon fired back in a post of his own, in which he expresses confidence that OpenID 2.0 will fix all of OpenID’s problems. I have less confidence than David, but I’ll leave that topic for later. What I’d like to do first is talk about getting the horse before the cart.

What I’d really like to see, as a security guy, is a problem statement and a risk analysis. Specifically, before we start arguing about whether OpenID 2.0 is the answer, I’d like to know the following things about the question:

1. What are the assets to be protected?

What do OpenID’s designers intend it to be used to protect? Blog comment lists? Blog entries? Persistent consumer accounts on commercial servers? Persistent employee accounts on corporate servers?

2. What are the services to be offered?

What services do OpenID’s designers intend it to offer? Authentication of users as the legitimate possessors of OpenID URLs? Linkage of OpenID URLs to user accounts on web-facing systems? Linkage of OpenID URLs to user attribute information (e.g. Information Cards)?

3. What quality of protection is claimed for these services?

Is the OpenID protocol intended to protect against phishing? Is it intended to protect against man-in-the-middle attacks? Is it intended to protect against attempts by one OpenID party to induce another party to execute malicious code? Is it intended to protect against session-splicing or session hijacking? Is it intended to protect against active or passive wiretapping?

4. What is the threat model?

What threats is OpenID designed to protect against? Accidental failures at a participating party? Malicious behavior by users? Malicious behavior by relying parties? Malicious behavior by OpenID providers? Wiretappers? Hackers attempting to penetrate a relying party? Hackers attempting to penetrate a provider? Hackers attempting to penetrate a client system? Cryptanalysts?

5. What is the trust model?

Who trusts whom to do what? Does the user trust the OpenID provider to actually check his password? Does the provider trust the relying party not to send maliciously constructed OpenID URL strings? Does the relying party trust the provider not to reissue OpenID URLs to different parties at different times? Does the relying party trust any particular OpenID provider to issue OpenID URL strings in a particular part of the namespace (e.g. “.gov”?)

All the arguments about OpenID are entertaining, but the claims and counterclaims are very difficult to evaluate in the absence of a coherent problem statement which includes answers to questions like these. The OpenID 2.0 Specification signally fails to address these issues; in this sense it’s a solution looking for a problem.

Beware the iPhone?

Blogger: Eric Maiwald

There were lines around the block. People waited to catch a glimpse of one and hopefully buy one. There were news stories about it. What could have caused this much anticipation? Was it a concert for some famous rock star? Was it a championship game? Was it a chance to catch Barry Bonds’ 756 home run ball?

Nope. It was the iPhone. Of course, the iPhone is not just any new cellular phone. With its slick graphics and user interface, it is leaps and bounds ahead of anything mortal man has seen before!

Well…maybe not.

One thing is certain, the iPhone has caused some concern for large enterprises. Since many employees are purchasing iPhones and hooking them up to their computers at work, there is a fear that large amounts of sensitive information may be transferred to the devices. Of course, this is nothing new (not really anyway). Many employees have PDAs, SmartPhones, or even USB memory sticks and use them to store sensitive information. Maybe it is just the fact that the hype around the iPhone has made it more visible than the other devices and that has gotten the attention of the enterprise.

Handheld devices like phones, PDAs, and memory sticks are so common as to be invisible while in plain sight. We all know that portable computers can hold sensitive information. The news media has seen to it that any time a portable computer is lost or stolen, the details of how many credit card or social security numbers were on it is a front page story. Of course, portable computers are assets that are tracked by enterprises. If an employee loses one, there tends to be a loss of productivity. I can just see a Dilbert cartoon coming:

Dilbert: “Hey Wally, why haven’t you responded to my emails?”
Wally: “I didn’t see them.”
Dilbert: “Why not? Don’t you check your email?”
Wally: “I lost my computer a few months ago so I haven’t been checking my email.”
Dilbert: “Three months ago? Why didn’t you call the help desk and get a new one?”
Wally: “I figured it would be easier to just wait for the hardware refresh cycle.”

So when a portable computer is lost or stolen, the enterprise hears about it. If the computer contains personal identifiable information (PII), the breach notification laws require customers to be contacted and a negative consequence occurs for the enterprise. Notice that the loss of PII may not in itself be a negative consequence to the enterprise. The cost of replacing credit cards is incurred by the banks. The cost of fraudulent purchases is incurred by the merchants. The individuals may incur costs associated with identity theft. The enterprise incurs costs because of the requirement to notify the individuals and admit the loss or theft. The banks and merchants may then sue them as is happening in the case of TJX.

Let’s go back to the handheld devices. If a PDA, phone, or memory stick is lost or stolen will the enterprise even know about it? Are these devices tracked as assets of the enterprise? Do employees report the loss or theft if the devices belong to them instead of the enterprise? In many cases, the enterprise will not know about the loss or theft and will likely not have any idea what information is on the device.

Does the enterprise want to know? That is not an easy question to answer. I’m sure that the enterprise wants to know if an event will impact the business. So a memory stick that includes secret designs, patent applications, or other trade secrets would interest the enterprise. Perhaps there are things that could be done after the fact to control or limit the negative consequences.

What if the information is PII? The negative consequences are going to occur to some other entity (banks, merchants, or the individuals). The negative consequences occur to the enterprise only if it knows that the information was lost when unencrypted. If the enterprise doesn’t track the devices and never learns that the device was lost or that it contained PII, then the enterprise can’t be expected to report it to the media or the individuals. If the PII is used to commit fraud or identity theft, will it be possible to follow the trail back to the lost device? Probably not.

So should enterprises track the use of handheld devices and memory sticks? Should the enterprise try to control them? Ethically, I think the answer is yes. Enterprises have a responsibility to protect sensitive information in their possession. However, from a risk management stand point, the decision may sometimes go the other way.