Security and Risk Management Strategies Blog

Exit process: Don't let the door hit you on the way out!

Blogger: Dan Blum

According to The Register artticle TSA worker tried to sabotage terror database, feds say a contractor was caught planting malware in an important terrorist screening database. That this almost-disaster should happen to the TSA, part of a superpower’s Department of Homeland Security, has to make you stop and think.

 On a few occasions when it was in scope for my document I’ve recommended that organizations always “walk out” off-boarding staff immediately (both logically and physically). But I have to admit that isn’t recommendation I realistically thought my clients would follow. Yet incident after incident proves it’s actually best practice.

 Why’s it so hard? Well, most people are taught to value trust and reciprocity from an early age and they bring those values and ethics into the workplace. Communities can’t function well without these values (dare I call them “goodness”?) – John Clippinger argues as much eloquently in “A Crowd of One: The Future of Individual Identity.” In the case of the TSA, the cultural values of trust and reciprocity are institutionalized by civilian government labor law and employment practices.

 How do we reconcile trust, reciprocity with some of harsher best practices for organizations and communities? Not very well. As kids we’re also taught to be wary of strangers and to distrust. But educating kids (and employees!) to “trust yet distrust” is a practical necessity. How might we do a better job of contextualizing knowledge, awareness, education, and process both in the young and in the organization is part of that critical “human factor” of security.

 So how might one implement the best practice of walking employees out? First might decompose why it’s so difficult to follow: 1) we trust the person, 2) we need the person to “keep flying the airplane” until knowledge is transferred, projects finished, 3) we don’t want to create a cold, distrustful, or uncaring organizational climate. These are all valid concerns.

 Then contextualize the knowledge and awareness process that is part of the implementation of the “walk out” policy to address the objections to it. Since understanding and accepting why a policy applies improves human compliance dramatically, one might explain it as follows:

 “We have the walk out policy because it’s necessary to protect the security of associates, customers, or citizens. We follow it for all employees and it isn’t a negative reflection on anyone. We have HR guidelines to make it a kind and gentle, though quick and  immediate exit process. If you still need the associate’s help on projects we can arrange short term consulting and provide guidelines for remote working, escorted site visits, or use of audited temporary accounts and escorted/observed sessions.”  

A separate issue remains: What if an associate anticipates being part of layoff perceived as unfair or discovers, senses, or imagines that he in particular is no longer wanted and will be fired? This is a psychological as well as a confidentiality problem and must be addressed through knowledge and awareness of psychology as well as other elements of the security program.

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.

Operation Aurora Points Out the Need for Better Threat Assessment Process

Blogger: Dan Blum

 

The debate is ongoing about whether the Chinese government is behind the Operation Aurora cyberattacks. Certainly Google believes China launched the Hydraq trojan used to breached its defenses and compromise intellectual property. And it was that determination, plus an apparently principled decision to resist Internet censorship, that motivated Google’s strong response, in which the company publicly threatened to quit China.

 

One can agree or disagree with this response. But let’s suppose the allegations are probably correct. If so, an attack by a nation state requires a different response than one by an external hacker, an insider, or other parties. And organizations with valuable intellectual property for the taking need to think about how they might deter, prevent, or respond to such attacks.

 

In my research on the threat landscape and threat assessment, I’ve found that security vendors and IT security staff spend too little time focusing on the “people” or “political” aspects of the threat. Threat reports from the vendors cover malware and vulnerabilities, but they don’t always discuss the threat’s capabilities and intents, nor why one type of organization is targeted and another goes free. Ignoring these factors may create a significant blind spot.

 

On February 17 at 2:00 ET and again on February 18 at 9:00 AM my “Threat Assessment in Dangerous Times” telebriefing will discuss my findings that organizations need to do a better job of assessing threats and developing defensive strategies. I’ll provide guidance on developing a threat assessment strategy and factoring threat intelligence into protection programs to avoid common mistakes and gain ground against adversaries.

 

I’ll also convene a small panel of experts to discuss threat assessment and the recent "Operation Aurora" attacks.

Time to refocus on security context, behavior, and accountability

Blogger: Phil Schacter

For many years I’ve been a strong proponent of investing in identity infrastructure as the basis for enforcing strict access control policies. Many organizations now have mature identity systems that support such preventative identity-based access controls, although other organizations still struggle with provisioning and de-provisioning identity and entitlements. I haven’t changed my mind about the importance of identity and identity-based controls, but now recognize that it’s not enough. There are too many cases where identity cannot be strongly established, due to the nature of the relationship, the potential for credentials to be compromised, and the uncertainty whether the accessing device is in the possession of the authorized user. Equally or perhaps more important than identity is the security context in which the request to access the protected resource or system is made.

Security context is a set of determinable factors concerning the request and the requesting user/device. These factors could include network location, geographic location, device identity and characteristics, chronological time context (i.e. relative to normal business hours), nature of the activity, and any special circumstances or unusual aspects to the request. Similar contextual and behavioral information is already used by financial systems to detect likely instances of credit card fraud. As organizations adapt to externalization, consumerization, and democratization of IT there is less likelihood that the user/device accessing an IT system is an employee using an IT-managed device owned by the organization. Many non-employees will require access to specific business and IT services, hosted in a mix of private and shared data centers, from a variety of devices and locations.

Security systems need to monitor and learn what behaviors and access patterns are normal, and which are more likely to involve compromised devices, co-opted credentials, or fraudulent activity by individuals with a direct or indirect relationship to the organization. The learned patterns of behavior then must be reviewed, internalized, and subsequently applied when making access decisions. Complementing this increased application of security context information are the logging and post-event analysis systems that ensure that criminal activity is identified and sufficient forensics information is available to support prosecution or civil litigation. In other words, establish accountability for actions as a deterrent.

Will 2010 be "the year of the data?"

I quite often have a déjà vu moment when looking at some new technology or security concern. It sure feels like IT and information security are a cycle – or perhaps a wave – and I think that by applying some creativity we could come up with an IT and information security zodiac. Linking things with astrology actually feels quite fitting for this time of year, given the plethora of Nostradamus-like risk management prophecies that inevitably pop up. It takes no crystal ball or star charts, however, to notice the loss of control associated with the ongoing information explosion and externalization of IT, and I’m left to wonder if 2010 - the year of the Tiger in the Chinese zodiac - will (finally) be "the year of the data" … and whether data-centric security, which we have been discussing for some years now, will have to become a real necessity.

We thought to have gotten a handle on information protection in the Internet age: encryption at the repository and media level alleviates a lot of the exposure associated with sensitive information on systems and mobile devices. Except for that pesky creation and use of information in the business, but for that there’s data loss prevention (DLP) protecting, with varying degrees of effort and success, the potential ingress and egress points of the information perimeter. It works – sometimes effectively, sometimes not so much – in the current enterprise IT model, and although not particularly cheap is much less of an effort than refactoring applications, data, and business processes.

But, if we believe the predictions, change in IT may well accelerate in 2010 through increased adoption of cloud computing – a change that would swiftly erode many a traditional information perimeter. In a CSO Online article, Cyberczar-to-be Howard Schmidt predicts cloud computing to be a security enabler, and states that “[t]he overall net effect will give us a better chance to develop more security in the cloud using […] robust encryption.” Using cryptography of course makes sense – crypto is at one point or another required in many technical controls -  but is the application of this traditional control in the cloud really that simple?

The answer, unfortunately, is no. Using encrypted information – for all practical purposes – requires having the key, and having to have the key at the point of processing (i.e, the cloud) is not exactly secure. Complicating the matter is the current lack of hardware-assisted cryptography potential in the cloud and virtualization (unless you want to sacrifice mobility and elasticity), and the result is a chicken-and-egg situation for protecting cryptographic key material. Sure it’s possible to have a cloud provider encrypt storage and networking for you, but how much of the threat landscape does that really address? The situation will eventually improve, but for now we’re facing some crypto-hurdles.

But then what do we do if we can’t encrypt data, or prevent it from floating around in the now externalized business process automation? Well, if it is absolutely required to be there, then we’ll just have to consider whether externalization is a good choice – it sometimes is, and sometime isn’t. But upon further examination it may be surprising how often sensitive data is in fact not needed, and this is where we can make some headway with business process and data management, and maybe also with some newer technical controls. With security teams focusing on the latter, we should probably consider data masking (de-identification) techniques, including run-time data aliasing (format-preserving encryption and tokenization, which I’ll cover in upcoming research) technologies, to complement data discovery and DLP.

Are these controls a panacea? No. Are they a necessary alternative to ‘regular’ encryption? Probably. No matter how we slice it, with an eroded or non-existent information perimeter, protecting information in a real data-centric manner is no longer optional. With new IT complicating encryption and DLP controls, and with the near inevitable expansion of information protection regulation, I think 2010 should finally be the year when enterprises get real serious about managing their large amounts of data. Sure it may be quite the undertaking (and of course more than just a security effort) but it may prove easier than it used to be, and should surely be very rewarding in the long term.

Network Zoning and Virtualization

Blogger: Eric Maiwald

During the course of 2009, I have had a number of client conversations around virtualization and its impact on network zoning. The impetus for the questions normally has something to do with the huge potential cost savings an organization might achieve by virtualizing the servers within its data center.  The more servers that can be virtualized, the greater the cost savings potential and the greater the flexibility an organization will have to load balance and recover applications. It makes a lot of sense to investigate the uses of virtualization technology.

As usual, there are tradeoffs and when we talk about virtualizing the data center, the impact of virtualization on network zoning must be considered. Network zones are built to provide some level of risk mitigation and control. Systems are placed into different zones because organizations are concerned about the potential for an intruder to gain access to sensitive information. If a system does not need to be accessed from the Internet, why should the system be accessible? The perimeters of the network zones are made up of different security and network devices. Most often, a firewall is used to separate network zones.

Many organizations deploy virtualization within a security zone and therefore they do not rely on the virtual environment to control communication between zones. However, if an organization wants to create a virtual environment that includes applications that normally exist in different network zones (the DMZ and the internal zone for example), one of the following possibilities must be true:

Possibility #1: The virtual environment provides the same (or higher) level of risk mitigation and control previously provided by the network security devices (such as the firewall).

Firewalls have been specifically built as a security device. Most firewalls have undergone significant security testing and most organizations implement some level of change control and inspection around firewall rules and rule changes. In addition, firewalls start with the idea that what is not specifically allowed is denied.

We know that applications within a virtual machine can determine that they are running within a virtual environment. This is the first step in finding ways for malicious software to affect other virtual machines or the virtual environment itself. Virtual environments have been evaluated against the Common Criteria and have achieved EAL 4 in at least two cases. However, the evaluations were made against security targets instead of certified protection profiles (see the Common Criteria Evaluated Products List).

Perhaps the bigger issue is something that Trent Henry bloggedblogged about earlier this year, the auditor’s view of the virtual environment. Some regulations (notably PCI) require traditional network segmentation approaches to separate sensitive systems from other systems on the network. Auditors may not view the controls provided by a virtual environment as equivalent to the more traditional approaches which may then open the organization up to the risk of an audit finding or a vast increase in the scope of the audit. If virtual environments are only used within a zone, this is not an issue.

One other thing to think about is that virtual environments may actually decrease some risk. The idea of a homogeneous environment with centralized management may provide some risk benefits around configuration control and logging. These potential benefits should be balanced and traded off with the increase in risk associated with the loss of separation.

Possibility #2: The level of risk has been reduced (or incorrectly evaluated originally) so that the controls provided by the dedicated security device are not necessary.

Everyone makes mistakes and it is certainly possible that the original risks were not as high as the organization thought. Alternatively, some other event has happened (such as a change in the business model) or control has been implemented so that a dedicated network security device is no longer necessary. In fact, it may be that the use of network zones may no longer be necessary. If the dedicated network security device is no longer necessary, then using a virtual environment to house applications from multiple zones makes a lot of sense. The organization should be able to show the risk assessment that provides the evidence of the reduced risk and then they should implement the virtual environment to gain the cost savings.

Possibility #3: Management’s appetite for risk has increased and so they are willing to accept greater risk.

Things change and in this case management is willing to accept greater risk to achieve significant cost savings. This is a valid position for management to take assuming they understand the risks to the business not only from intruders but also from auditors and regulators. In this case, the organization’s management has been told of the risk and has determined that the cost savings outweigh the risks involved. Management has made a deliberate decision to accept the level of risk to the enterprise. The security team should make sure that all of the risks have been identified and explained to management and management should officially accept the identified risks. Once this is done, the virtualization can be implemented to achieve the cost savings.

Virtualization is a great new technology – one that holds out a huge potential for cost savings in the data center. I’m sure that in the future, we will find additional benefits to the technology. Just because it is a “hot technology” does not mean that we should implement it everywhere. Implement it when you need to but be aware that nothing is ever free. Make sure to understand the tradeoffs associated with virtualization and do the risk analysis.

Layers of security: Off to the clouds

Blogger: Dan Blum

Visualizing the Boundaries of Control in the Cloud, which is Scott Morrison's post, reprints my previously posted stack diagram that shows how the complexion of control changes as you move from traditional IT to hosted services to public cloud IaaS, PaaS, and SaaS implementations.

Scott (VP of Engineering and Chief Architect for Layer7) goes on to say that as one cedes control of network security, one must bake security into the software services themselves. Layer7's SecureSpan product has its roots in the XML security gateway (aka web services management) category, and is being transformed into a cloud security gateway. As such, it provides appliances, virtual appliances, and policy management constructs designed to enable customers to run a secure overlay of services over hybrid cloud environments and to exchange standards-based application messages leveraging user or service identity to and from other organizations' hybrid cloud properties, or domains.

Dave Passmore (Burton Group's network research director) notes this is not first time we've seen security architecture layering changes. On seeing Scott's blog post, Dave emailed me: "The author of the blog post summarized very nicely what we’ve been trying to promote for years, long before clouds: “Secure services, not networks."

Actually, what we promote is "layers of security." When at risk, we want as many layers of security as possible. Unfortunately, security may get in the way of functionality, and we must peel back a layer. And with each layer removed, lose a bit of assurance and have to do years of engineering work to try and recover assurance somewhere else.

Let me illustrate. The most secure computer sits encased in cement at the bottom of the ocean. But if you want to use it hoist it up and put it in a locked room. If you want it on a network, lock that network down with firewalls. What if someone from the Internet needs to communicate with it? Now we're on the slippery slope to Burton Group and Jericho Forum's idea of de-perimeterization, which necessitates "secure endpoints and secure protocols."

That's what Dave's talking about. He and I worked hard a few years ago on this idea of "secure endpoints and secure protocols" to create a comprehensive perimeter and zones reference architecture that degrades gracefully from secure, controlled sites to wild and wooly SOHO or branch office sites where endpoints must self-defend or risk compromise. The reference architecture combines sites with trusted networks and sites without them into logical zones of trust leveraging a "security overlay." This is a good reference architecture and still valid. 

So we've taken our secure computers out of the locked room, de-perimeterized some of our networks, and are still in the midst of years of engineering required to properly secure endpoints and protocols - which by the way, will require ongoing redesign of hardware and drivers of all sorts to enable full-scale hardware-assisted desktop virtualization as well as changes to the Internet itself. In the midst of this, IT and security are being required by their businesses to   outsource  to the cloud. Not only have we lost control of the network, now we can't even be sure we have secure endpoints (i.e. servers in the cloud) because they may be run by one of the many (though not all) cloud service providers whose security implementations are incomplete and audit reports unhelpful at best. What to do? What to do?

Can we move the security up a layer, as we did before? Up to "secure services" as Scott suggested in his post? Not entirely. Whereas an endpoint made of hardware has some ability to isolate itself from a hostile network, a service made of software cannot isolate itself. Before a potentially hostile host OS or hypervisor, the application or virtual machine lies helpless. It's like Frodo in the Lord of the Rings: "...there is no veil between me and the wheel of fire. I begin to see it even with my waking eyes, and all else fades." 

Yet more years of engineering must be done to get public cloud computing endpoint security up to speed. As I've written elsewhere,To cloud computing vendors: Stop practicing security by obscurity! Also, we need robust NAC (that is, endpoint health assessment) for virtual machines. Before a VM handling sensitive functions fully decrypts itself to run in the public cloud, it should be able to check the Trusted Platform Module (TPM) and do other things to verify the identity of the hosting domain and the security posture of the hosting endpoint. Only then should it activate its services. Trust, but verify. This is just a vision, but perhaps its time will come.

All that being said, Scott and his team and everyone who worked on SAML, WS-*, REST security, and such are doing great work. Its critical for services to communicate securely, comply with policy, and authenticate regardless of location and hosting domain because without that we can't have secure hybrid cloud architectures. That is what the XML gateways morphing to cloud security gateways can offer. But you have to trust all the hosting domains and the hosting endpoints for this to work. And we cannot trust them particularly well right now.