Security and Risk Management Strategies Blog

Cloud (Un)Availability

 Blogger: Eric Maiwald

 

When you attempt to put your head into the clouds, make sure you know what you are getting into!

 

Perhaps that is the updated caveat emptor – let the cloud user beware. Think of this scenario:

 

You own a business in Australia and you have chosen to use a software-as-a-service (SaaS) product to handle your accounting instead of buying your own accounting package. The SaaS provider is based in New Zealand. As part of your due diligence before making the decision to use the product, you check out vendor. All seems fine so you sign the contract. Then a problem occurs…in Dallas, TX…in the United States…and your vendor’s systems (and the product you are trying to use) go down. Welcome to the cloud!

 

If you think I’m just being paranoid (trying to come up with the worst case scenario for everything like a good security person should), just read this article. A vendor in New Zealand (Xero) provides accounting software via a SaaS model. They host their servers at a company called Rackspace. Apparently, Rackspace had some type of power issue at its data center in Dallas, TX and this made Xero’s service unavailable. This happened even though Rackspace had other data centers around the world.

 

I don’t mean to pick on Xero or Rackspace. Accidents and failures happen and while we can implement controls to reduce the risk, the risk never really goes away.

 

The event does highlight an interesting aspect of the cloud. The customer may never really know where his data resides or what portions of the Internet infrastructure he relies on. In this case, customers were working with a company in New Zealand. The company in New Zealand contracted with an American company to provide data center space and network connectivity. The American company has data centers in the US, the UK, and Hong Kong. Where is the customer’s data? Which parts of the infrastructure are necessary to make use of the service being purchased?

 

As we layer more stuff in the cloud, these questions become more important. As a customer it is your responsibility to ask these questions.

 

There will be several cloud and SaaS security presentations at Burton Group’s Catalyst Conference. Join the conversation with us in San Diego the last week of July.

 

Storage Security, the Dynamic Data Center, and Catalyst

Blogger: Trent Henry

Here at Burton Group we’ve been looking at x86 virtualization and its impact on security. In my recent report on that topic, I specifically called out how auditors respond when they encounter virtual systems. The major issues include:

• Separating systems with perimeters and limiting audit scope Hardening systems against attack and maintaining patches (including hypervisors themselves and offline guest machines)
• Protecting data in easily replicated virtual machines
• Controlling privileged user access and activity
• Monitoring virtual systems
• Recognizing that control environments can change dynamically among hypervisors

Generally, auditors are just beginning to acknowledge these issues—especially vis-à-vis PCI. But they’re getting savvier with each passing moment.

What they don’t yet understand are storage virtualization and converged fabric. With technologies such as iSCSI and Fiber Channel over Ethernet (FCoE) emerging, lots of new security questions arise. (And it’s not just the auditors in the dark; I think the whole industry is grappling with these.):

• Block-level access to disk across ethernet: What do we do about clients whose access represents not just a single file system, but huge amounts of disk spanning multiple servers and OSes?
• Authentication: How do we ensure that proper authentication strength is enforced (despite being turned off by default) and move from simple CHAP techniques to stronger mutual authentication?
• Authorization: How do we move beyond spoofable initiator node-name authorization to something better?

In July at Burton Group’s Catalyst Conference (in San Diego), we’re dedicating an entire daylong topic to the issues of Storage, Networking, and Security for the Dynamic Data Center. Have a look at Thursday’s agenda and try to join us for the conversation.

Measuring security performance

Blogger: Ramon Krikken

Security metrics is an ongoing hot topic (and pain point) for many of our customers and the industry in general. Of course everyone would very much like to find the one elusive key risk indicator (KRI) that near perfectly predicts the future … but predicting the future as usual turns out to be difficult at best. So we are turning our eyes to security performance measurement (i.e. looking at the past) in an upcoming overview and related talk at our annual Catalyst conference.

There are certainly plenty of security metrics out there, even in the performance area. But something to the likes of “number of incidents” or “percentage of systems with up-to-date patches” is at most something to compare with others – if even that – and it certainly does not make an actionable metric. What we need are goals to track towards and ways to understand how lack of performance leads up to incidents and other bad things.  I of course don’t want to give away one of the punch lines, but let’s just say a large part of it has something to do with establishing correct frames of reference.

And there are of course other documents and presentations related to this topic. Hot off the press is an Executive Advisory Program overview “Communicating Clearly About Risk” by Bob Blakley (subscription only), we have a half-day topic devoted to “Proving the Business Value of IT” which will feature plenty of metrics, Jack Santos touches on the bad side of metrics in the “What Will Your Boss Say? The Reality of Security” presentation, and in one way to circle back to risk management Fred Cohen will present “Risk Management: There are no Black Swans.”

So stay tuned for the upcoming document, and join us for the conference July 27 – 31 in sunny San Diego. You can find the schedule at https://burtongroup.wingateweb.com/us09/scheduler/weekAtGlance.do

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.

Cloud Computing: Who is in Control?

As with real cirrus, stratus, and cumulus clouds IT’s cloud computing services come in various types and often combine with each other to make strange formations. An exposed hiker in the open might ask: "Is that but a fair weather cumulus cloud, or an ominous storm cloud?”

In the world of IT security, we call that risk assessment.

When it comes to putting your IT resources and – perhaps – even slightly sensitive data such as personal names, addresses, and phone numbers into the cloud one might start with these three questions:

• Who is in control?
• Do they provide assurances?
• Can we trust them?

In traditional IT environments, organizations generally share control over the network with service providers, but for the most part control their applications, servers, and storage infrastructure. In an internal cloud environment, the architecture changes, but not the complexion of control. As shown in the figure, however, the control architecture changes profoundly for public cloud offerings such as Amazon EC2, Google Apps, or Salesforce.

As we move from left to right in the diagram and put more and more control in the hands of the service providers, the outlook shifts from fair weather green to ominous red.

Assuming we trust our IT department to give the necessary assurances and do their jobs well, the “dedicated IT” stack is green but for its use of the Internet, which is yellow.

With server hosting providers or “colo” data center facilities we still retain substantial control, perhaps relying on the service provider only for rack space, power, and cooling. In these simple arrangements, the service hosting providers will typically provide assurances, or service level agreements (SLAs). They may help us build trust by offering site tours, audits, and track records. We may feel we can fully understand their operations and residual risks. We may feel comfortable sharing control of the server, storage, and network functions with hosting providers. Yellow is mellow.

In the world of cloud computing, everything changes. As we move from

• Infrastructure-as-a-Service (IaaS) with its line of demarcation in the server where the silicon stops, to
• Platform-as-a-Service (PaaS) where you cross the line after your code and applications are integrated with outside components, to
• Software-as-a-Service (SaaS) where you abandon all control when you hand over your data

I paint the functions these services control an alarming red. To see why, we must ask: Do they provide assurances?

No. The major public cloud computing providers generally offer no SLAs at all. They accept little or no liability even for the security measures their own advertising claims to provide.

Can we trust them? The short answer is no. Their actual security measures are obscure, vulnerabilities undisclosed, and audits unimpressive.

But each situation is unique and everything relative in risk management. With a water tight raincoat as counter-measure, the hiker need fear no rain. Lightning may be the only residual risk, and that may be acceptable. There is much more to be said about the risks of cloud computing and how one might ride this red tiger with a yellow whip; controlling enough of the data, applications, or virtual machines to accept some residual risks. Another option might be to consider internal clouds or private (community) cloud arrangements that give customers more say.

We’ll say all this at Catalyst North America and more. In our “Flying into the Cloud: Executive Perspectives on Externalized IT” track, we’ll cover practical perspectives on leveraging public clouds. We’ll cover internal or hybrid cloud strategies that maximize our control as we reap the benefits of the industry’s “big switch” to cloud’s elastic, on-demand architectures. And in “Cloud Now: Usage, Practices, and Rewards” I’ll go much more in-depth with “Security Strategies for Cloud Computing.”

A View from the Other Side

Blogger: Eric Maiwald

In security, we must understand how we are perceived by the business. What we think is critical may not matter at all to the business overall. We will not learn what matters to the business if we only focus on security vulnerabilities and the latest technology. We need to get out and learn how the business functions and how security impacts it. A recent experience brought this home to me.

I was in the Midwest visiting friends and I had the pleasure of being introduced to a man named Neil. Neil works in the maintenance division of a large agricultural services company. When he found out that I worked in IT security, he launched into a story about two IT people he knew. The first IT guy he really liked. This guy came into the division where Neil worked and helped them get their computers up and running. Neil explained how the computers helped him do his job and how this IT guy really paid attention to how the shop was run. Neil lamented the fact that this “good” IT guy took a job with another company and left.

Neil then launched into a story (you could almost call it a tirade except that Neil didn’t raise his voice) about the second IT guy (let’s call this the “bad” IT guy). The bad IT guy showed up and started changing things. He introduced a new system to track parts in inventory and then found ways to cut costs by reducing the inventory. Neil went into a long discussion about the parts inventory. It seems that his shop has to maintain a lot of equipment – much of it quite old – and they kept a lot of older parts on hand for the simple reason that some of the parts were hard to find. In addition, the mechanics would often only use components of a part if that was all that was really needed and they would keep the remaining components for use at some later time. Neil freely admitted that they were pack rats to some extent but he explained that they hoarded some of the parts because it allowed them to fix equipment quickly and get it back into operation without waiting for a part to arrive.

It is still unclear to me what position the bad IT guy held within Neil’s company (and it really doesn’t matter for this story – Neil perceived him as an IT guy) but he was able to change the parts inventory practice and get rid of a lot of the older parts. This was touted as a cost saving measure and was done without consulting with the people who did the work. Without the parts readily available, the time to repair older equipment increased. Equipment waited for parts to arrive (or in some cases to even be found!) and the overall availability of the equipment suffered.

So why am I relating this story? Neil’s perception of IT is formed by the IT people he interacts with. On the one hand, the good IT guy paid attention to Neil and his coworkers. He provided support for their work and helped them improve the shop practices. The bad IT guy didn’t learn how and why certain business practices existed in the shop. He only saw the potential cost savings without understanding how changing the practices might increase other costs and reduce the availability of equipment.

Who do you want to be? Who do you think your business perceives you to be? We need to be more like the good IT guy in the story. We need to learn how the business functions, what is important to the business, and how security impacts the business.

Cloud Computing Security and Identity Management SIG Coming Soon

Blogger: Dan Blum

Good morning! I want to announce our plans for a super meeting, and hope that lots of you enterprise security architects and strategists will be able to attend.

EVENT: Catalyst Cloud Computing Security and Identity Management SIG

LOCATION: San Diego

SPEAKERS: Dan Blum, Burton Group; Cloud Security Alliance (TBA)

DATE: July 28, 2009 8:00 AM

Cloud computing alters business risk and limits organizations’ ability to control, monitor, and audit access to their data. The cloud computing security SIG will bring Burton Group analysts, Cloud Security Alliance (CSA) representatives, end user organizations, and leading edge solution providers to discuss identity management and other issues in the rapidly emerging cloud computing security space. It will provide an opportunity for attendees to come up to speed on issues such as:

• How is cloud computing transforming enterprise security programs and approaches?
• How can identity and access management help to enable cloud adoption and enforce policies on usage and administration?
• What architectures and tools work best to project identity to and from the cloud?
• How should organizations integrate cloud and on-premise IdM and security systems and processes?

Cloudy thoughts from CSI-SX / Interop

On the first flight underway to CSI-SX and Interop in Las Vegas, we were about to land at JFK. It was early in the morning, and as is sometimes the case there were dense low-hanging clouds. We were about to touch down, dropping out of the clouds very close to the ground, when the engines revved up and we took off again. The pilot announced that “there was another airplane on the runway … not a problem … we’re just going back in for another landing shortly.” That’s about as close a call as I can handle, but this kind of occurrence is to be expected – lack of visibility cannot be completely solved with instrumentation and air traffic control.

What does this have to do with the conference? Well, in some sense flying in the clouds and computing/storing/communicating in the clouds have some similarities, and aviation certainly went through its period of disastrous events that eventually were used to implement increased control and safety. Cloud, at least in some aspects, is still in its infancy, and as I had expected the cloud discussion was well alive. It wasn’t so much in the exchanges I had with other attendees, but it certainly was front and center in the general sessions and sprinkled throughout the tracks. The bottom line? I didn’t exactly get the warm and fuzzies about either cloud security, or the general understanding thereof. It was all, well, like trying to navigate those low-hanging clouds.

It is perhaps unfair to pick on the presenters from Amazon and Google – they are not security experts – but these are after all the people who sell promises of the cloud to the CIO. Amazon’s Jinesh Varia’s slide deck touted “military-grade perimeter controls” – perhaps someone can explain to me once and for all what that’s supposed to mean. Google’s Adam Swidler spoke of the virtues of having data securely in cloud instead of on the endpoint, only to do a complete 180 and talk about offline data and applications a few slides down. The kicker was when they referred to a SAS 70 audit as “a cool thing” and “up and coming, ” respectively. In all fairness, Google’s security story around software- and platform-as-a-service can be a lot tougher to sell than Amazon’s infrastructure-as-a-service, but in the end I felt like neither was all that convincing.

A later presentation by Tanya Forsheit and Nolan Goldberg from Proskauer Rose LLP discussed legal aspects of cloud computing. The usual suspects of information ownership, the geographic location of the information, and who might be legally allowed to provide it to authorities were covered (side note: Richard Watson blogged about regulatory conflicts and cloud recently). The advice, as I boil it down, was pretty simple: assessment, contracts, and oversight. But what was more troubling to me was the notion that case law in the area of cloud computing is not yet at all established. Tanya Forsheit noted that searching for “cloud computing” in a law databases resulted in a single result having to do with a trademark dispute over the term itself, not anything having to do with actually using the cloud. But with outsourcing arrangements having existed in IT for a long time, I’m not quite sure that many aspects of cloud are all that new. So maybe this is a case of where the definition is really clouding the issues in the legal system … not a reassuring thought.

So there’s obviously a lot left to be learned about “the cloud” and its security. People were feverishly taking notes – I hope their takeaway was similar to mine: cloud is a term describing way too many things at once, discussing cloud security often conflates many issues in implementation and control, and more clarity is needed. Our upcoming report on cloud security (authored by Dan Blum) should provide a guide for at least plotting a safe initial course in the clouds, but we need to remember that – just like in aviation – we might have to witness or work through a disaster or two before we figure it all out.

Locked down desktops

Had a customer inquiry on what my recommendation was for Windows administrative rights on desktops.

My recommendation, and Microsoft’s recommendation is for enterprises to set up managed Windows workstations (i.e. organization-owned and controlled) in the “standard user” configuration.

The pre-requisite for this policy is an IT support infrastructure capable of pushing software and/or configuration changes out to client workstations, either through a tool such as Symantec/Altiris or Microsoft System Management Center, or through remote installations by IT staff depending on the situation and the number of users requiring the changes.

Standard user configuration may need to be tweaked for different types of users, for example, mobile users requiring wireless access or the ability to change time zones. Vista and Windows 7 offer more flexibility than XP; often with XP it has been necessary for administrators to unduly weaken the standard user configuration for “power users.”

There are a few cases where exceptions generally must be made:

1) Client-side application developers or testers that need to frequently adjust operating system settings, and install/reinstall software
2) Knowledge workers or market researchers that can justify a legitimate business need to frequently need to install/reinstall software
3) Users that do not have access to IT support infrastructure

If the IT support infrastructure is lacking or the policy is not strongly enforced, categories (2) and (3) can grow fairly large.

All that said, it may be that the locked down desktop will fall into the minority of what enterprises have to deal with as trends such as telecommuting, partnering, outsourcing, crowdsourcing, and consumerization gather force.

In the coming months, I'll be researching a topic along the lines of "Endpoint Virtualization to the Rescue: Protecting Against Unmanaged Desktops and Mitigating Information Sprawl."

EV Revisited - Will the Green Bar Save Your Life?

This post is a quick followup on Trent Henry's "This Green Bar Will Save Your Life!" and a subsequent call with Verisign to discuss the merits of Extended Validation SSL certificates.

If you look at the Verisign EV SSL case studies it's pretty clear what the selling point is. Lines such as "48,000% ROI" and 30% more conversions" should be enticing enough to many a merchant. The thinking, of course, is that a customer will be more trusting of the merchant's online presence (i.e. less likely to abandon a purchase). Even if the ROI isn't quite so high this may well be a case of an investment so small - to larger merchants - that it doesn't hurt to try, or perhaps a case of not wanting to be seen as an organization that "doesn't care about security because it doesn't use the green bar."

So although I'm not sold on the exact numbers I do get the economics - the ROI potential is rosy, but what about the ROSI? Let's set aside for a minute the browser-side and server-side issues with cross-domain content as discussed in Trent's post and shown by the PayPal XSS vulnerability last year, as these are not solvable with just EV SSL (I've commented on the need for better browser controls here) We'll focus on the usability side: how well does this help users resist "plain" phishing.

Two case studies we discussed on our call did actually note an increase in phishing resistance for the consumers, but - like the economic studies - these were not controlled for other variables. One was a laboratory experiment, and we cannot derive results for long-term effects. And while the other was a real-life study, EV SSL was deployed along with a consumer security awareness campaign and other controls - it's particularly difficult to determine the efficacy contribution of a single control in such a case.

In other words, I find these studies promising but inconclusive. I'm certainly not looking to diss the idea of EV SSL. In fact, from a usability perspective I think the green browser bar is a gigantic leap forward from the padlock icon. However, I'm not at all sold on the security benefits beyond the increased consumer trust (if you want to call that a security benefit) that brings more money to the merchants. My hope is that we'll see some more, better studies on this subject and work towards a better browsable future - after all you can only manage what you measure.