Security and Risk Management Strategies Blog

Wicked Problems

Blogger: Eric Maiwald

I was catching up on my reading when I came across a short piece in the IEEE Spectrum magazine by Robert Lucky. In the article, Mr. Lucky describes problems that are so complex that they cannot be fully solved – he calls these problems “wicked problems.” While reading the article I kept coming back to the old joke about security engineering – cheaper, faster, or secure…choose any two.

In this article, Mr. Lucky talks about really hard problems that often have no elegant solution only different sub-optimal options. “Entanglement” is a word he uses to describe how these problems (and their solutions) influence other things outside of our normal boundaries. He notes that to approach such a problem, we often draw boxes around the parts of the problem we control. That sounds a lot like how some organizations approach IT problems – this is a security problem or a network problem or a development problem.

But the problems we deal with are not really that cut and dry. Should I use virtualization in my data center? If you only look at power and space consumption in the data center, the answer is an obvious yes. But what about other concerns like security? Did the virtual environments just circumvent all of the network security controls? What about service oriented architectures? Good idea? Sure but what does the use of services mean for the development process and for the implementation of controls? What about WAN optimization? Should I use it? Perhaps but there are tradeoffs in its use (for example, don’t try to optimize an encrypted stream of data because it won’t compress!). I could go on but I think you get the idea and where I’m headed with this.

I’m sure you heard the joke in security – cheaper, faster, or secure…choose any two. While we laugh at this (and mostly at the security guy who dares to intrude into the faster getting cheaper), the joke illustrates the tradeoffs involved in all large system engineering or architecture projects. Unfortunately, unlike mathematics where we can easily find the local maximum and therefore the optimal solution to a problem, engineering is a messy process that requires less than optimal solutions to these very hard problems.

So where am I going with this? In order to deal with these hard problems, security needs to work with other IT disciplines. We need to identify the tradeoffs to be made and then choose the most appropriate solution based on the requirements from the business. In the end, many of the tradeoffs cannot be solved by IT alone so the business will have to be involved and will need to understand the impact of the decisions.

To cloud computing vendors: Stop practicing security by obscurity!

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

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

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.