Security and Risk Management Strategies Blog

To cloud computing vendors: Stop practicing security by obscurity!

2009-07-08T15:31:52-04:00

Blogger: Dan Blum

Does cloud computing security need to be “secret”? Google, Amazon, Salesforce, and other cloud computing vendors seem to think so.

Eric Maiwald (Research Director for Burton Group Security and Risk Management Service) made an excellent post on the risks associated with resource aggregation in the cloud. He used the recent Rackspace outage to make his point that customers had better know their providers environment before using their services. In fact, there is a whole cloud computing incidents database on Wikipedia. What this all shows is that cloud computing is subject to the same (in)security dynamics as the rest of IT.

Over the years, security professionals have learned that security by obscurity doesn’t work. There is a balance to be struck between opacity (to the attacker), transparency (to the customer), and disclosure (by the vulnerability researcher).

Concerning transparency, I quoted John Clippinger's “A Crowd of One” book in an internal Burton Group email:

“Trust…can only exist as a consequence of mutual expectations being fulfilled. Trust requires measurement, feedback, and accountability. In most social networks, the consequences of low trust are high transaction costs, that is, constant monitoring, negotiation, bickering, and dispute resolution…The ability to build and leverage trust among members of a group builds social capital and significantly reduces transaction costs.”

That really got some discussion going! Research Director Drue Reeves blogged on Cloud Infrastructure Secrecy: Competitive Advantage or Disadvantage…

And Jamie Lewis, Burton Group CEO makes a great post within a post, here:

“Lack of cloud computing vendor transparency reflects the immaturity of the marketplace. If vendors think security is a competitive advantage, then they are sadly mistaken. And they will have to go through a painful cycle to learn that lesson.

At Catalyst 2008, George Sherman of Morgan Stanley gave a fantastic keynote for the IdPS track. At the end of the presentation, he said that anyone should feel free to come up to him in the hall and ask questions because, at Morgan Stanley, they don’t see security is as a competitive advantage. He pointed out how the financial services industry as a whole relies on confidence and trust to operate smoothly, which makes sharing information in everyone's best interests. If one bank’s security fails in public and horrible fashion, all banks suffer a loss in confidence. (Our current crisis shows just how true this is.)

Is it not fair to say that the same dynamic applies to cloud service providers? If one or more providers suffers the breach/disclosure/PR/investigations/fines cycle from hell, does it not harm all service providers? Isn’t this even more true when said “other” providers refuse to disclose (even to us) enough details on the security posture to allow a reasonable assessment of that posture?

It’s not just that they have to get used to being in the spotlight. It’s that they have to completely get over the notion that security is a competitive advantage. No one will believe them if “trust me” is their only answer. The “cloud industry” needs to understand that it’s in all of their collective best interests for the buyer to have a reasonably good feeling about the security of ALL providers in order for any one provider to be able to sell successfully on the real competitive advantages: service levels, price, performance, and ability to support business needs.”

And Research Director Bob Blakley concludes:

“I’ve got a really simple response to anyone who wants me to buy a security and availability pig-in-a-poke. It’s this:

You don’t want to give me details of how you handle security or what your availability numbers & history are. That’s fine, I understand. You obviously understand that I have to manage my risks, and without these numbers I can’t assess risk or buy insurance. So here’s the deal. We have three options:

You tell me what I want to know, or
You accept unlimited liability for breach or outage in our contract, or
I take my business somewhere else”

That's really telling 'em!

Considering Secure Architecture for Critical Infrastructure

2009-07-06T12:23:33-04:00

Bloggers: Ken Agress, Kim May, Doug Simmons, and Bob Smock

Compliance concerns aren’t anything new in today’s market. For the electric utility industry, what has been emerging is a set of standards issued by the North American Electric Reliability Corporation (NERC). These standards cover Critical Infrastructure Protection (CIP) and define requirements for both physical and cyber-assets that electric utility companies must address. The Federal Energy Regulatory Commission (FERC) has made these standards mandatory beginning this month (July, 2009), and has the power to levy significant fines to enforce compliance. Like many legal or regulatory issues, the NERC requirements have many electric utility companies concerned about their ability to adopt and implement the standards required in a timely fashion.

It’s at times like these that a systematic and comprehensive approach to protection and other technology areas really pays off. By following a formal architecture process or methodology, electric utility companies can evaluate the impact of new regulations or requirements on a number of fronts:

Where does the enterprise already comply with the standards?
How does the current architecture fail to comply?
Do planned projects or activities already in a technology roadmap provide or improve compliance?
What architectural changes must the enterprise make to comply?

These are all key questions, particularly when confronted with relatively wide-ranging standards like the NERC standards. But these challenges aren’t unique to NERC. They exist for PCI or modifications to legal requirements like Sarbanes-Oxley.

Enterprises that adopt a structured, formal approach to setting technology standards, like the Burton Group Reference Architecture, are much better positioned to assess the impact of new standards, identify gaps that must be addressed, and implementing remedies in a timely fashion. Further, this approach identifies requirements and relationships between different areas of the technology environment that help define all of the impacted technology areas, which is important since protection and security requirements can easily impact network, identity, and application standards.

Burton Group is in the process of preparing a report that covers just these issues – demonstrating how our Reference Architecture maps to the NERC requirements and how the architecture process can assist electric utilities in assessing the overall impact and making the changes necessary to meet the compliance requirements. Indeed, our review of the NERC requirements shows that our Reference Architecture maps to NERC requirements on a nearly one-for-one basis.

Which goes to emphasize one point – it’s not that the technologies themselves are hard to implement or impossible to integrate. It’s that our thinking within IT needs to focus on more than the “here and now” and day-to-day operations. Structure and strong standards are what arm us to meet both immediate and future needs and adapt rapidly when new business requirements are introduced.

Cloud (Un)Availability

2009-07-02T17:31:43-04:00

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

2009-07-02T16:06:57-04:00

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

2009-06-29T13:02:05-04:00

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

2009-06-26T12:52:18-04:00

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?

2009-06-25T16:39:57-04:00

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

2009-06-05T11:29:52-04:00

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

2009-05-28T10:00:42-04:00

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

2009-05-22T16:19:28-04:00

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.