OAuth2 for the Enterprise? Not so fast… Exploring SAML for REST with Expressway Service Gateway

There has been some recent chatter about the lack of strong, proven standards for API authentication when using the REST paradigm. Recent discussions seem to suggest that 2-Legged OAuth2 is the de-facto champion for securing so called lightweight web services based on the REST paradigm.

The trouble is, for all it’s hype, Enterprises looking to secure critical parts of their B2B communication and supply chain tend to view OAuth2 similar to an excited, overanxious know-it-all teenager, one that you just don’t trust quite yet.

In fact, in talking with some of our potential customers the chief complaint is that OAuth2 doesn’t have the same trusted track record as other established standards, most notably SAML. The problem is, SAML has no official binding for REST based API communication and it is often accused of being too heavyweight due to the XML and XML security processing it imposes on applications. What if there was a way to solve both of these problems for the Enterprise?

At Intel, we’ve long believed that XML is the way to go and the use of an XML Gateway decouples the expensive security, parsing, and transformation features from the developer, making things like SAML processing a snap.

About the second problem. We’ve thought about it and came up with a new feature in the latest version of Expressway Service Gateway that solves the binding problem using a simple approach. Rather than start a new OASIS group or other heavyweight process, we’re suggesting that SAML assertions, either holder-of-key or bearer, be encoded using standard base64 encoding into the HTTP Authorization header. Further, in order to provide an adequate security model, SSL is a must as the assertion itself (while it may be signed) will not be cryptographically bound into the header.

The approach is extremely lightweight and will allow any Expressway customer to protect REST APIs using SAML as the required token mechanism. On the client side, the developer still needs to generate an assertion on their own (or use a gateway product like Expressway), but if they are already using SAML as a token for SOAP messages or other purposes, the assertion is likely already available.

Let’s see how it works in the product. There are two sides to this interaction, the client and then the service. On the client side Expressway can act as a client gateway and attach a SAML assertion to a REST call. To do this, We’ve added a new REST security action to the palette.

In the previous picture, we have a new action that will do the work of creating a new SAML assertion and attaching it into the header. The next question is, how do we control the options? For this, the action is connected to a REST security policy. Here, we are specifying that the output is the HTTP Authorization header and choosing SAML holder-of-key. Remember, for the scheme to be secure, the API call must be done over SSL.

The previous two screen shots suggest a way to generate the assertion and attach it to an outbound call. What about processing it on the service side? For this, we’ve rolled the SAML for REST processing into the existing AAA action.

As you can see in the previous screen shot, all that is needed is a AAA step. The mechanics are pretty simple and extra options are available from the AAA policy – shown in the following screen shot.

In the previous screen shot, you can choose how you want to obtain the assertion. For instance, if you are grabbing the SAML assertion from a standard place (such as SOAP header), a workflow variable, or the two SAML for REST options from the HTTP Authorization header.

We’d really like your feedback and comments on this approach. We’ve already heard the requirement from a few large Enterprise customers – please let us know what you think! -Blake

Intel Expressway Service Gateway Achieves DoD PKI Certification

Hello Expressway Fans -

I just wanted to let everyone know that Intel(R) Expressway Service Gateway has just received official DoD PKI certification!

What does this certification mean? In short, its a battery of 76 certificate path processing tests covering an extensive combination DoD defined test cases. The tests ensure more than just path validation, or the act of stringing together a valid path from one certificate to a trust root. They also include policy mapping and path length checks that go beyond what is normally utilized for path validation in Enterprise cases.

In addition to evaluating how our path processing algorithm works, the testing also includes retrieving, importing, and exporting keys and certificates, storing keys and related certificates, and revocation checking (including CRL and OCSP tests).

Finally, the DoD also verifies communication protocols, the application configuration and performs a documentation review – phew!

The best part is that aside from a few options on the web interface, the feature is transparent to most users – it’s a function of how the gateway performs path processing and certificate policy evaluation based on DoD requirements.

The full battery of tests is described here.

We’re also proud to say that we are the first and only vendor to have a software appliance form-factor verified for use with the DoD PKI!

-Blake

6 Minute Podcast Primer on Cloud Access Security

Join Intel Director of  Product Management, Vikas Jain, of the Application Security & Identity Products Group in this brief podcast as he summarizes some key issues around Cloud Access Security. Some things you’ll learn:

• What is Cloud Access 360?
• How can you simplify and secure account management with cloud apps through automatic provisioning / deprovisioning of accounts?
• What is Single Sign On (SSO) and  how do you get seamless connectivity to the cloud, and between applications already in the cloud?
• What is Client Aware Security and what is Intel doing to ensure that requests are coming from attested clients?

Listen to the podcast:  here You can get more information about Cloud Access 360 by visiting: www.dynamicperimeter.com

CloudTweaks.com Discusses Expressway Cloud Access 360

Make sure to read the informative and insightful discussion about Intel Expressway Cloud Access 360 between Intel Director of Product Management for Application Security and Identity Products, Vikas Jain, and Anthony Park, from Cloudtweaks.com. Read the post and understand why Anthony calls Cloud Access 360 a “very impressive and elegant solution”.

Posting can be found here

Intel® Expressway Cloud Access 360 is a software product that enables federated access from the enterprise to the cloud and vice-versa. It bundles provisioning, federated single sign-on(SSO), strong authentication, and client aware access control – all into one packaged solution providing control, visibility and compliance to enterprises adopting cloud SaaS applications.

You can learn more about Expressway Cloud Access 360 and even download an evaluation of the software by visiting www.dynamicperimeter.com

Securing the Extended Enterprise with Bi-Directional Protocol Handling

Large Enterprises face a constant challenge in balancing technology costs with new business goals. Many enterprises have existing business processes bound up in applications that communicate using ‘legacy’ protocols such as FTP and MQ, which were really designed for behind the firewall operation in a trusted network. Given these constraints what’s the best way for a large Enterprise to extend these applications to external customers and partners without relying on an expensive re-engineering effort or concentrating risk in a single vendor?

One option is to use a security gateway such as the Intel® Expressway Service Gateway to centralize security policy deployment, increase performance, reduce development costs, and simplify the architecture. In this post, Blake Dournaee describes a recent customer use case for a Service Gateway that highlights the value of this class of products.

http://software.intel.com/en-us/blogs/2011/01/28/beyond-the-simple-proxy-using-a-service-gateway-to-secure-the-extended-enterprise-with-bi-directional-protocol-handling/

 

 

 

Interop: WCF and Intel SOA Expressway

Want to get down to the code level? Read Boris Kaplounovsky’s blog, Securing SOA.

http://securingsoa.blogspot.com/

World of SOA

The Service Gateway as a Control Agent

A service gateway is a new class of platform designed for massive scalability and control for mediating service interactions from the Enterprise to the cloud. As a control agent, the gateway sits at the edge of the physical network and provides runtime enforcement of security policies, threat prevention, quality of service enforcement, and the mediation of identities and credentials for cloud services. The service gateway is also able to enforce persistent security properties on Enterprise data. This is an important point and refers to message level data protection such as encryption and digital signature operations. This capability extends the perimeter of the Enterprise directly into the cloud provider itself by protecting the data even while it is outside of Enterprise control.

The service gateway also has additional properties such as compatibility with any Enterprise and cloud service, is itself scalable through virtualization in the private cloud, and the capability to run on low cost, commodity server hardware already deployed throughout the Enterprise. Moreover, the service gateway must help preserve and leverage existing Enterprise IT investments from major ISV vendors and must also provide integration and compatibility with existing software investments such as identity management and access control systems.

 

The Figure depicts the service gateway deployed at the traditional Enterprise perimeter. The service gateway has an outward defensive posture towards the cloud and improves security around the four areas of cloud security under the Enterprise control. The service gateway connects to existing information systems, identity management systems, and security monitoring systems and may also broker interactions directly from the end-user via a browser. It is also important that the service gateway be scalable in software with no dependencies on specialized XML processing hardware or custom ASIC. Otherwise, the cost, development, and scalability benefits of virtualized control points will be lost as specialized hardware cannot be effectively virtualized across general purpose hardware.

In this model, the service gateway is an edge-oriented policy enforcement point (PEP). It enforces security, threat, authentication, and authorization policies that are typically set and controlled in the identity management policy decision point (PDP). The split between PEP and PDP allows the Enterprise to control policies locally but have these policies enforced at the network edge, as traffic flows in and out of the organization.

Also shown in this picture is the identity management PDP communicating with existing enterprise information systems, which may include directories, middleware, databases or other applications. In this communication, the PDP is using additional context, such as resources and attributes to make policy decisions that are enforced at the external control point.

With respect to event monitoring, the application level security gateway can send logs and events to a security information management product which can aid in correlation and search for security and compliance as data moves from the Enterprise to the cloud.

API Protection and Strong Authentication

For API protection the service gateway acts as a secure proxy for all application level interactions with the cloud service provider, performing content scanning, attack protection and mitigating denial of service attacks. For strong authentication, while the gateway cannot invent strong authentication requirements at the cloud provider when they don’t exist, it can enforce strong authentication of the cloud service when available. This enables the Enterprise to know who it is talking to as well as enable increase capability of internal systems to call cloud services securely through the use of pre-built cloud connectors on the service gateway, saving development and testing costs inside the Enterprise itself.

Message Level Protection and Confidentiality

For data protection at the message level, a key attribute of the service gateway is to extend data protection into the cloud to increase control and compliance. This can be done by selective field level data protection on sensitive data done transparently by the service gateway before the messages reach the cloud. This type of data protection, when done properly, also aids in supporting compliance for standards such as PCI DSS that require encryption of specific pieces of information such as credit card numbers, names and customer addresses.

Auditing and Monitoring

For audit and monitoring, the service gateway is the single point control for data entering or leaving the Enterprise and given the full application level proxy capabilities of this control point, it can audit and log every interaction. Moreover, when responding to threatening events such as authentication failures, content threats and excessive traffic it can feed this information into Enterprise security information management (SIEM) systems to help build a comprehensive security event dashboard for the Enterprise. A SIEM system working in concert with the service gateway can alert a security administrator of a chain of events that involve the misuse of cloud computing resources such as an insider attack.

For example, a SIEM system can generate a predictive alert based on an Enterprise user downloading a “password” file internally first and then subsequently logging in to a cloud service and uploading the fi le to an infrastructure (IaaS) service, which could signal the use of cheap cloud computing resources for a brute force attack on the stolen password fi le. Service gateways are unique in their ability to capture not just network level events, but the full application level traffic, which can reveal details such as message-level method calls, parameters, request sizes, content-types, identity tokens and message rate, all of which can be expressed in log files that can be effectively captured and searched by Enterprise SIEM systems to build a cloud security dashboard that reveals a significant amount of forensic data regarding the usage of cloud services in the Enterprise.

Access Control and Authorization

For user authentication and authorization, Enterprises have invested heavily in Web access management, identity federation and identity management systems and are just now beginning to layer fine grained authorization capabilities into their architecture. Enterprise Web access management systems are a key system for managing and enforcing security policies, and are generally called a PDP, or policy decision point. From the perspective of the identity and access management system, it is the single source of managed security policy for authentication and authorization. The PDP extends its reach into the applications and infrastructure with policy enforcement points (PEPs) that are either embedded in the application container or act as security proxies, such as security gateways, that can parse and inspect the full application payload and stop traffic to request decisions from the PDP. This model allows centralized control of policies and along with distributed enforcement through PEPs throughout the internal enterprise architecture and the enterprise edge.

A typical use case that combines the capabilities of the enforcement point and decision point is a web services-based transaction bearing identity credentials within the XML message. In this case, the cloud service and the enterprise are passing XML documents back and forth and the service gateway is intercepting inbound traffic, performing content attack prevention, throttling, denial of service enforcement and then extracting the identity and credentials and passing this to the internal identity and access management system for an access policy decision. A second usage model involves a control point for identity federation (federated SSO) between internal identity systems and cloud-based SaaS applications. To date, cloud service providers each handle identities in their own way, but many such as Google and Salesforce.com offer federation through technologies such as SAML and OAuth.

The enterprise challenge then becomes how to broker existing enterprise identities and sessions, which are often stored in LDAP or databases or accessed through deployed identity systems, to the cloud, without a “forklift” style upgrade. A concrete example of this would be an Enterprise user attempting to access a cloud-based SaaS application. In this case, the user who is already logged in to the Enterprise network needs to be able to seamlessly access the SaaS service without a second login and without the SaaS service needing critical Enterprise employee data. We can also consider the case of authorization as an additional check on top of federated single sign-on. It has already been noted that cloud providers currently offer very coarse levels of access control and are opaque to existing fine grained authorization logic deployed inside the Enterprise. The introduction of cloud services in the Enterprise without an enforcement point simply offers users a way around fine grained authorization controls already in place. Even worse, Enterprises may have spent time and money getting fine grained authorization controls implemented and then face additional difficulties in scaling these controls to cloud services. It may make sense for an identity management system or security gateway to help bridge this gap. In other words, before requests for cloud services leave the Enterprise they can be identified as targeting specific resources with well-defined actions, all at the message level. These resources and appropriate actions can then be checked against the subjects and attributes provisioned in existing authorization system deployed in the Enterprise.

DESIRED MODEL: Centralized control of policies through a PDP with distributed enforcement through PEPs across internal architecture and Enterprise edge.

World of SOA

Security in the Cloud

Security risks are a concrete expression of the lack of control a business faces when considering moving critical business systems to the cloud. From the perspective of the enterprise, there are seven major risks to be considered. Of these seven, four can be easily controlled or mitigated by the Enterprise. The remaining three remain the responsibility of the cloud provider of which the Enterprise has little real control, other than voting with their wallet. It may be argued that the Enterprise should make “demands” of the cloud provider through the use of contracts or third party audits, but in reality the market will determine the amount of security provided to Enterprises by cloud service providers and the level of acceptable risk. It may turn out that the cheaper price of cloud computing comes with necessarily increased risk, which may be a self-limiting factor in itself to the pervasive use of cloud computing by Enterprises.

We outline the top security risks as follows:

1. Insecure, Porous APIs: Most cloud services offer two categories of web-accessible APIs: Those based on web services (called SOAP) and those based on pure HTTP (called REST). Increasingly, some cloud providers are offering only REST style APIs which lack robust “Enterprise class” message level security and authentication mechanisms. Some APIs, such as the Twitter API are purposely designed for rapid development and allow and even encourage the use of unprotected user credentials which are more susceptible to man in the middle or replay attacks. While some providers, such as Amazon.com offer strong authentication mechanisms, it’s not clear yet how well these APIs stand up to content-based threats such as code injection, denial of service attacks, script injection, or malicious XML content. Moreover, it’s also not clear how much trust should be placed in data received by the Enterprise from a cloud API for potential threats. A compromised cloud service API session may be a direct avenue for an attack. Internal information systems exposed to the cloud at the API layer offer a universal tunnel for a savvy attacker. Without explicit protection, cloud APIs essentially expose previously guarded Enterprise data across the Internet into the hands of a third party. Moreover, for IaaS systems that expose XML based APIs for image management, these management APIs also require strong authentication and access control as an attacker may conveniently replace a trusted machine image with a rouge one.

2. Logical Multi-Tenancy: With shared cloud computing infrastructure, the division of Enterprise data is now logical rather than physical. This logical separation is typically achieved through the use of virtualized infrastructure which is a cheap and easy way to support a multi-tenant architecture at the cloud service provider. The perceived risk in this scenario is for an attacker to subvert the logical division provided by the guest virtual machine and gain access to the data of another tenant. A number of attacks on virtual machines, from detecting the presence of a hypervisor to running arbitrary code on the host have been documented3. These attacks highlight the uncertain security of multitenant, shared environments for critical Enterprise data. An Enterprise horror story would be an attacker signing up for a “free” account at the cloud service provider, detect the presence of a virtual machine and “escape out” of the VM instance to access the physical server operating system and potentially gain access to the Enterprise data. Technology such as Intel® Trusted Execution Technology (TXT) are available that can mitigate this type of attack, but responsibility for implementation ultimately still lies with the cloud service provider.

3. Data Protection and Confidentiality: Data stored, processed or indexed in a remote cloud service defines the extent of the new perimeter for the Enterprise. This new “fuzzy” boundary changes and moves with the data itself, not the traditional firewall. A necessary complication here is that for data to be used effectively by cloud services it must remain unencrypted or else SaaS providers will have a hard time indexing it for any function that relies on search. Common examples include spell-checking in a Google document or looking up sales leads in a CRM application. The Enterprise may have to give up encryption and data privacy requirements for some of its data but should also recognize the option of applying selective field or message level protection mechanisms for data before it reaches the cloud. A practical example of this is protecting employee or critical customer information on messages before the data is released to the cloud. This is one aspect of data protection that an Enterprise can control on data before it reaches the cloud service provider.

4. Data Loss and Reliability: When critical business data is moved to a cloud service, there is some inherent risk of data loss. Even if cloud service vendors offer multiple back-ups and data redundancy, there is no perfect way to protect against the failure of physical media and disasters are apt to strike at just the wrong time. To take an example, services such as Amazon’s storage service offer “credits” in the face of data unavailability4 within a given month. This SLA may be too weak a proposition for business critical data and Enterprises may need more protection to manage this risk. Data loss and unavailability at precisely the wrong time may completely cripple an Enterprise. It may be argued that this is a false risk because the Enterprise has a similar risk of catastrophic data loss inside its own datacenter and simply moving the data to the cloud doesn’t change the equation. This claim ignores the fact that the cloud service provider is offering the same product at a much cheaper price and the reliability that the Enterprise has built around its data may simply not be present with the cloud service provider. It should be noted that this risk may turn out to be a red herring. The convenience and cost savings of the cloud service and record of actual failures may reduce this potential risk to near-zero, but it is too early to tell.

5. Audit and Monitoring: The first step in managing the security of any system to know when specific risky events occur. If an Enterprise decides that cloud services provide value to the Enterprise but wants to audit when these services are accessed to evaluate risk, it needs a way to know when data flows to and from the cloud. Enterprises need to know who is making the service request, when the request is happening, how much data is sent or received and how the data is used. Given the convenience and ease with which cloud service providers can be accessed the biggest risk to an Enterprise concerns the use of unmanaged “rogue” cloud services or projects that go unnoticed or unmanaged by the Enterprise CSO.

6. Cloud Provider Insider Threats: A potential problem or weak spot with cloud services is the mismatch between the security requirements inside the Enterprise as compared to those employed by the cloud service provider. To take an example, many large Enterprises make special efforts to secure “endpoint” data on IT-issues laptops with two-factor authentication technology, forced password rotation and fully encrypted hard-disk drives. Moreover, data is often segmented with access controls that distinguish between full employees and contractors, especially in large companies with diverse geographies. In most cases these controls increase the security of the Enterprise data. It should be noted that has taken Enterprises many years to reach this level of increased protection. Once the data is moved from protected assets to the cloud, however, an instant “weak spot” is created. Security breaches are often breaches of the weakest link, and a determined attacker motivated either by financial gain or industrial espionage will likely find it easier to execute an insider threat from the cloud service provider to gain access to the Enterprise data rather than try to execute a brute force attack on an encrypted hard disk. It should be noted that this is not the same as “hacking into Amazon’s API” or “hacking Google documents.” Sophisticated attackers use social engineering techniques and insider connections to find the weakest link. A motivated attacker may even take a low level job at the cloud provider itself if it provides an easier path to the Enterprise data.

7. Account Hacking, Tiered Access Control and Authorization: While hacking an account through a stolen password or compromised credential is nothing new, Enterprises to date have done a decent job of segmenting credentials and access control throughout their infrastructure. This is actually a property or benefit of the somewhat localized security inherent in individual operating systems and the uses of role based (RBAC) and attribute based access control (ABAC) within the Enterprise. In other words, if an attacker gains root access to a networked system or database they may have access to other assets, but the breach of a single system is more often than not directly localized to the breached system. Further, breaches of a single account are self-limiting by the role or attributes associated with that account in the Enterprise LDAP system. It is true that sophisticated attackers can use information from any compromised system as a stepping stone for more sophisticated attacks, but more work is required by the attacker unless they are extremely lucky in breaching the exact system they need. If we contrast this to cloud service providers, a few such as Salesforce.com have rudimentary segmented access control and privileges5, but for the majority of these a breach of one account may grant the keys to the entire castle. In fact, the pay-off for an attacker who knows that he must hack just one account to gain access to all of the Enterprises resources may seek to employ cheap, readily available cloud computing resources for brute force attacks on passwords and cryptographic keys. Moreover, fine-grained authorization of Enterprise resources is a problem just now being solved inside the Enterprise and it will be some time before cloud providers reach the same sophistication of locking down the use of individual data elements, fields, URIs, resources or API calls to individuals with a specific role or specific attributes. Account hacking from an Enterprise insider also needs to be considered. Once the Enterprise moves to cloud computing traditional insider attacks can be more costly because the Enterprise must rely on the cloud provider to help prevent the insider breach. In short, not only are the keys to the castle held in the cloud, but the Enterprise has to protect its traditional assets and now cloud assets from insider attacks. 

The previous seven risks are summarized in Table 1. Here we list the risks, a description of the threat and which party (Enterprise or Cloud Provider) is on the hook for reducing the threat. Ultimately, shoring up security risks is the job of both the Enterprise and the cloud providers. Short of a boycott, however, Enterprises have little real control over how security is implemented on the provider side. Cloud providers have yet to segment their offerings to provide increased levels of security targeted for Enterprise requirements such as higher levels of risk protection, integration with Enterprise identity systems, guarantees around multi-tenancy platform sharing (or isolation) and integration with monitoring, alerting and security event management systems. Instead, providers appear to be implementing minimum levels of security for their perceived target market. Whether this minimum security will rise as the industry matures is an open question, but for Enterprises that need to reduce risk while cautiously adopting cloud services we advocate the use of a high performance edge-oriented service gateway for those categories of risk that the Enterprise can control. This provides the necessary balance between the cost savings promised by cloud computing and the management of tangible risks that are under the Enterprise control. The next section outlines the concept of a service gateway and how it can reduce risk in four areas: (a) API protection and strong authentication, (b) Data protection and leakage, (c) Auditing and Monitoring, (d) Access Control and Authorization.

World of SOA

Barriers to the Cloud

It comes as no surprise that most businesses are reluctant to pervasively deploy cloud-based services for their core mission-critical applications. For years, businesses have strived to increase vertical backward integration of core business processes, data and supply-chains. In other words, businesses inherently gain more certainty, control and competitive advantage by directly owning the data critical to their supply chain. Undermining this control for cost savings and time-to-market advantages is a challenging cost-benefit analysis.

The wholesale adoption of cloud-based services may reduce resource costs for businesses, but cuts down operational effectiveness by bludgeoning control of business data and introducing new security, privacy, legal and in some cases, performance challenges. This being said, we cannot ignore the fact that significant time to market advantages and capital cost savings can be achieved through the selective use of cloud-based services. To use a concrete PaaS type of example, all it takes is an IT person with a credit card to get a farm of servers up and running and available for use. The setup, physical datacenter costs, maintenance and patching for the servers are all rolled into the monthly bill. In this sense we can talk about businesses being conservative with existing systems but aggressive in selecting cloud services that will provide some competitive cost and cycle advantages, either for partnership, new technology R&D or some new service their existing infrastructure cannot provide.

Next Security in the Cloud

CIO Healthcare Summit

 

The healthcare industry is changing. Will your organization survive?

The CIO Healthcare Summit is a gathering for C-suite executives and industry thought leaders to discuss IT challenges currently facing the healthcare industry, including improving patient care, controlling costs and meeting government regulations. With a renewed focus on decreasing healthcare costs, the Obama administration’s goals for the industry have created a buzz. CIOs are looking to utilize available resources, improve efficiency and find new IT solutions.

The summit is more than a typical technology conference; it’s a dynamic event designed to ensure that participants’ time and energy is well spent in a productive and innovative environment. Whether attending a panel discussion, networking event, one-on-one executive exchange or thought-leadership workshop, the CIO Healthcare Summit engages participants in candid discussions and promotes the development of smart IT solutions through collaboration and idea sharing.

The CIO Healthcare Summit will be held May 9-12, 2010, at the exclusive InterContinental Montelucia Resort, Scottsdale, Ariz. North America’s leading healthcare companies will be present to debate and network. Imagine the possibilities.

We will be speaking on Tuesday May 11th at 11:40 during the Executive Exchange. We are partnering with EMC to talk about:

“Platform Approach to IT – Staying Competitive in the Face of Healthcare Reform”

Today, healthcare IT platforms’ ability to respond to change has become the defining factor that determines profitability as institutions seek to connect data and business processes across a community of care.  Portals,  analytics, EHRs, and HIE solutions all have a contributing role to play but there are no complete or turnkey solutions. Moreover, ARRA and regulatory concerns are driving new information sharing and data capture requirements for each system and event under the CIO IT charter. The keys to success? Best-of-breed solutions that focus on security, standards based interoperability, and flexible SOA architectures. In this presentation, Intel and EMC reexamine how healthcare information is shared and present principle driven, platform approach to healthcare information integration and exchange.  A sample case study from Newark Beth Israel Medical Center is showcased to illustrate how collaborative portals when combined with SOA connectivity can prepare for “Meaningful Use” in less than 6 months.

Hope to see you there!