The “Intel” on Intel is… We do software! by Andy Thurai

Are you surprised? I start off most of my presentations/conferences with the following question:

How many of you know that Intel ‘does’ Software?

Very few hands usually go up, and that is exactly the challenge I have today in getting the word out about other exciting developments that people wouldn’t normally associate with this technology juggernaut. And while the Silicon Valley behemoth often conjures up images of powering a plethora of devices (including phones too!), it’s Application Security & Identity Products division (ASIP), my unit, that is quickly escaping the formidable shadow of the “mother ship” as it gains prominence in the world at large with Cloud, Application security, Identity and Tokenization software. Intel’s ASIP group is on the cutting edge of innovation in a myriad of ways with some very advanced technologies such as Cloud SSO, Cloud-based Identity services, Identity Manager, OTP (One Time Password), Big Data, Analytics, API Gateway, Cloud Service Broker, Security Gateway, Mobile middleware and Security as a Service.

Every Intel commercial you see on TV, or through other media channels, usually promotes Intel chips, as that is a core strength of ours. But I want you to be aware that we are far more than just chips. We are a leading edge technology company that constantly renews itself as well as its raison d’être. We hold more patents than almost anyone else in almost every field that we are in. And we employ an army of engineers in some of the largest research efforts in the world, with one of the largest research budgets.

There was a great article in Forbes not too long ago, about how Intel is one of the largest software companies in the world, that you’ve never heard about. Lead by our fearless leader, Renee James – SVP of Intel’s Software group, Intel recently announced Security as our third pillar. Our CEO Paul Otellini didn’t just stop there; he showed the world he meant it by acquiring McAfee soon after. However, we’ve also made some very key strategic acquisitions in software security and identity areas to strengthen our position. Those include, but are not limited to: McAfee, Nordic Edge, Sarvega, WindRiver… (a complete list can be seen on the Forbes link below or at Intel.com). This is consistent with our strategy. We continue to acquire and develop a lot more software/ security solutions with unwavering commitment.

You might be surprised to learn the following:

  • Intel turbo-charges the Linux community by putting hundreds of full-time engineers to work on the free operating system.
  • Intel’s tools helped Apple’s engineers move its Macintosh computers to Intel processors.
  • Intel helped Google move into the Smartphone business.
  • Maybe the company’s biggest software triumph has been its push into high-performance computing. Five of the ten fastest supercomputers in the world now run Intel’s chips.
  • Intel has a solution that helps companies Tokenize their sensitive data.
  • Intel’s Cloud Service Broker (CSB) and API Gateway solutions help companies seamlessly move their enterprise applications to the cloud.

Along these lines, Intel has been a pivotal partner on many projects that have helped to move the “proverbial needle” by developing tools, frameworks and enhancements – all of which often have gone unrecognized since the efforts are not branded with any kind of Intel logo.

With the acquisition of security software vendor McAfee last year, Intel became one of the world’s 10 largest software companies. – Forbes May 2012.
http://www.forbes.com/sites/briancaulfield/2012/05/09/intel-is-the-biggest-software-company-youve-never-heard-of/.

If you have time, I suggest you give our annual report a read. You’ll get a first-hand look at the contributions of the software division. They are impressive. Just from the numbers alone, we could easily be considered one of the largest software vendors in the world.

We, the software group of Intel, get access to information coming from the advanced security labs of McAfee and extreme performance labs from Intel. This allows our software unit to understand what is coming down the road and architect solutions for the future. That is why when you choose Intel for any of the aforementioned products, the performance comparison numbers against our direct competitors our numbers are truly outstanding. If you have any questions about this, please give me a shout and I will demonstrate to you how awesome we really are.

A very familiar AllState commercial states “Are you in good hands?”, With Intel I can guarantee you are.

Andy Thurai — Chief Architect & CTO, Application Security and Identity Products, Intel

Andy Thurai is Chief Architect and CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Governance, Security, and Identity solutions for their major corporate customers. In his role, he is responsible for helping Intel/McAfee field sales, technical teams and customer executives. Prior to this role, he has held technology architecture leadership and executive positions with L-1 Identity Solutions, IBM (Datapower), BMC, CSC, and Nortel. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS. He holds a degree in Electrical and Electronics engineering and has over 20+ years of IT experience.

He blogs regularly at www.thurai.net/securityblog on Security, SOA, Identity, Governance and Cloud topics. You can find him on LinkedIn at http://www.linkedin.com/in/andythurai.

Andy Thurai on, “the API – You Can’t Live Without It”

The unprecedented explosion of modern technologies combined with a burgeoning mobile space has forced enterprises to rethink previously held beliefs about the static enterprise perimeter. Remember the olden days when you said your enterprise was completely self-contained in one data center, with your apps inside the firewall and with everyone nearly as confident about it as being as secure as Ft. Knox?  With an explosion in mobile computing, demand for cheap or “free” usage of resources, and a sharp reduction in cost with the cloud delivery model,  it is expected (or rather demanded) that every enterprise expose their APIs not only from their enterprise but from a cloud based model. (NOTE:  The cloud is referred to in a  loosely defined delivery model be it —  public, private, community or hybrid variety).

Couple this inexorable progression for having a cloud based model with the need for mobile enablement and web 2.0 technologies,  and you are forced to expose not only your SOAP APIs,  but also JSON, REST and other fast, quick TTM (time to market) APIs that can be easily manipulated and consumed.

This brings an interesting issue to the fore-front. You are forced to rethink your corporate security strategy. Many organizations (and the C levels that I speak with on a regular basis) are scared to move their sensitive applications (and processes, data) to the cloud, mainly, because of security. But that doesn’t stop them from exploring and moving some of the non-sensitive applications to the cloud and “testing the waters”, so to speak. Once they see how easy and cheap it can be, they begin losing sleep thinking about all of the money they can save by moving everything to the “cloud” due to the constant pressure to plan and come in under budget.

It’s no wonder that API traffic has exploded over the past few years. According to a recent survey, about 60% of the enterprise traffic is API based. According to Programmable Web,  75% twitter traffic is API based. According to Programmable Web there are at least 5000+ APIs (http://blog.programmableweb.com/2012/02/06/5000-apis-facebook-google-and-twitter-are-changing-the-web/) and the pace is growing. Programmable Web has a neat tool where you can search all the publicly available APIs (http://www.programmableweb.com/apis/directory). If you check this out you will immediately notice that most of the social APIs are mostly REST/ JSON based. There is obviously a good reason for that.

When it comes to APIs there are two distinct, broad categories – Social APIs and Enterprise APIs. The Social APIs are created by, and for, our society which is hungry for instant data updates. (Remember the AT&T 4G commercial “so 42 seconds ago”  (http://www.youtube.com/watch?feature=player_embedded&v=bvVVQGgbKk0) . I miss the good old days where we found out what happened in the world by checking CNN website once an hour or so.

In general, the social APIs tend to be fast,  easy to implement, REST only — without any enterprise class security, not monetized,  and focused on publishing  content etc.

You can’t afford to have the enterprise APIs published and consumed the same way. Your Enterprise class security needs to move with your applications API wherever it is going or however it is accessed.  And it is not a question of if, it is a question of when. The success of companies with API as the core of their business models transformed the industry – look at Google, Twitter, Facebook, and other smaller players. According to Programmable Web “The most popular API category from the last 1,000 APIs is government. In total, we list 231 government APIs and nearly half of them have been added in the last four months.”  When the government adopts a technology standard, you know that there is no going back, it is here to stay forever .

As applications migrate out of your own “Ft. Knox”,  the issue will become more pronounced. You’ll still need the same quality of security, management, SLAs,  centralization of usage based information – predicated on policy & identity information.

Most cloud providers just give you the base platform and leave most of this to you.  However, your enterprise class APIs need to provide enterprise class security, governance, lifecycle management , API Key and credential management, throttling and quota management, security, protocol translation and versioning, API performance optimization, key management, discovery. The need to expose your APIs in  multiple formats (as talked above such as REST, JSON, SOAP, etc), can multiply the complexity of an implementation exponentially.

Having set the stage (without wanting to scare you about the inherent risks of exposing your APIs to the cloud), let’s talk about how Intel can help you effortlessly achieve all of these things regardless of your usage model —  without the need to be concerned about whether  APIs are REST based, or full SOAP APIs or even JSON based mobile APIs.

Intel has been in the Web Services, XML, SOAP security space since the acquisition of Sarvega (circa 2005).  Our expansion into the API security space has been a natural progression. We brought out an API security gateway last year which caught the attention of many of our customers. Especially given that it can help enterprises move enterprise grade security policies without having to rewrite the policies (and allow for subsequent enforcement of them in the cloud) makes it even more interesting.

With the addition of OAuth 2.0 to the API gateway in our latest release, it seems like a timely opportunity to talk about the capabilities of our API gateway. When you move your enterprise applications to the cloud and expose APIs from there,you can either retool your application to fit that platform/ delivery model . Or, you have a second option. Use our API gateway as the API middleware which can help you solve a lot of those issues. APIs have become strategic control points for the cloud.

So essentially you want to abstract the following functionality to API middleware:

  1. Keep your implementation technology agnostic. Provide a mechanism to support REST, JSON, SOAP, etc and mediate to the backend supported format in a non-intrusive manner. Most times this end result can be achieved by configuring the API gateway solution to act as a facade to the existing application. This is really important in the ever changing API world.  JSON, REST APIs have evolved in the past few years.  By being agnostic, you’ll be prepared for the next “flavor” in whatever way that instantiates itself.
  2. Keep your security and API management closer to your APIs and be transparent about it with your  customers.
  3. Remove security, scalability, management and audit functionality and issues away from the an actual API implementation.
  4. Ensure that you have strong API monitoring, metering, logging, auditing, & versioning features.

Check out our API Gateway details to see how we can help you make this migration easy and painless.

http://software.intel.com/en-us/articles/Cloud-Service-Brokerage-API-Resource-Center/

For more information about Intel Expressway Service Gateway, case studies, testimonials and tech tutorials, please visit www.intel.com/go/identity

Andy Thurai — Chief Architect & CTO, Application Security and Identity Products, Intel. Andy Thurai is Chief Architect and CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Governance, Security, and Identity solutions for their major corporate customers. In his role he is responsible for helping Intel/McAfee field  and technical teams and customer executives. Prior to this role he has held technology and architecture leadership and executive positions with L-1 Identity Solutions, IBM Datapower, BMC, CSC, and Nortel. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS. He holds a degree in Electrical and Electronics engineering and has over 20+ years of IT experience.

Security Expert, Gunnar Peterson, on Leveraging Enterprise Credentials to Connect with Cloud applications

Many pundits say that you must pick a Cloud Provider and trust them. I beg to differ. First off why should we trust the Cloud Provider? A Cloud Consumer wants to leverage the Cloud Provider’s capabilities for functionality and scale where it makes but why should this equate to blind naïve trust? And anyway, what specifically is the Cloud Consumer trusting the Cloud Provider? As the old country music song says, “In God, we trust, all others pay cash.”

Instead of blindly trusting the Cloud provider to do the right thing (and a glance at any recent news will show how hard this is in practice) it makes more sense for the Cloud Consumer, e.g. you, to limit how much control you choose to pass to the Cloud Provider. One technique for accomplishing this is to retain control of User Account Management at the Cloud Consumer site.

When the Cloud Consumer retains the responsibility for User Account Management, the security architecture gains in several ways:

  • Choice of authentication techniques
  • Freshest, most accurate data, and the ability to leverage enterprise provisioning
  • Visibility into account usage
  • Auditability of user account stores
  • Verification of account ownership

To realize these benefits the Cloud Consumer company must ensure that their local user account information and sessions can be integrated with the Cloud Provider. A starting point for most of these efforts relies on using SAML as a strong, standard based method to integrating Cloud Consumers with Cloud Providers. The Cloud Consumer plays the role of the SAML Identity Provider and the Cloud Provider plays the roles of the SAML Relying Party. This style enables the Cloud Consumer to retain control of the User Accounts and issue standards-based assertions for the Cloud Provider to make run time decisions based on authentication, authorization and attribute sharing scenarios.

Enterprises have demonstrated the desire to explore a wide variety of authentication techniques, driven in some cases by authentication strength and other times by constraints. Below is a list of authentication methods supported in the SAML standard:

  • IP
  • IP Password
  • Kerberos
  • Mobile One Factor Unregistered
  • Mobile Two Factor Registered
  • Mobile One Factor Contract
  • Mobile Two Factor Contract
  • Password
  • Password Protected transport
  • Previous Session
  • Public Key X.509
  • Public Key PGP
  • Public Key SPKI
  • Public Key XML Digital Signature
  • Smartcard
  • Smartcard PKI
  • Software PKI
  • Telephony
  • Telephony Nomadic
  • Telephony Personalized
  • Telephony Authenticated
  • Secure remote password
  • SSL/TLS Client Authentication
  • Time Sync Token
  • Unspecified

First off, holy protocol soup, Batman! What this clearly shows is that authentication remains a moving target. Recent troubles at RSA (http://online.wsj.com/article/SB10001424052702304906004576369990616694366.html) show there is not an end in sight to this trend. Authentication is clearly something that enterprises will continue to iterate on and attempt to improve upon.

As security architects, we should expect authentication technologies to continue to evolve and support a wide variety of techniques. The architecture should insulate the consuming applications like Cloud Providers from this change, and the standard SAML tokens and protocols give us a way to do this.

service-provider-service-consumer

 

The enterprise user’s credential, whether 2 Factor, Password, PKI or one of the myriad of other choices is insulated from the integration between the Cloud Consumer and Service provider. This separation of concerns means that changes in authentication technology or in Cloud application should not ripple through the architecture. The separation of authentication concerns from the Cloud creates a pragmatic way to address the enterprise authentication and credential choice locally at the Cloud Consumer.

To enable this separation, the security architect should work on design patterns along the following integration points:

  • User
    • Identify enterprise user credential types in use for Cloud Applications
  • Cloud Consumer
    • For the Credential types in play identify where and how they can be integrated with Access software such as SAML Identity Providers
    • Identify what use cases and level of support is required from the Identity Provider – authentication, authorization, and attribute sharing
  • Cloud Provider
    • Agree upon protocol and formats and what authentication context is required to propagate to the Cloud provider.
    • Ensure that the Cloud Provider targets can consume the selected identity use cases – authentication, authorization and attribute sharing
    • Ensure that session management implements a consistent policy

The role of the SAML provider providing access in this case play a dual role crossing the chasm from byzantine enterprise authentication to more open Cloud Providers while not losing the fidelity of the original session.

For further research on how this may apply to your planned Cloud application scenarios, the Dynamic Perimeter site shows a number of real world Use cases and integration examples

http://www.dynamicperimeter.com/products/cloudaccess360

gunnar1.jpg

Gunnar Peterson is a Managing Principal at Arctec Group. He is focused on distributed systems security for large mission critical financial, financial exchanges, healthcare, manufacturer, and federal/Gov systems, as well as emerging start ups. Mr. Peterson is an internationally recognized software security expert, frequently published, an Associate Editor for IEEE Security & Privacy Journal on Building Security In, an Associate Editor for Information Security Bulletin, a contributor to the SEI and DHS Build Security In portal on software security, and an in-demand speaker at security conferences. He blogs at http://1raindrop.typepad.com.

Microsoft RMS and Security Gateways

A new use case has just been published that shows how a large Enterprise has deployed Expressway Service Gateway to protect access to RMS-protected documents.

This is an interesting use case because it show how an Enterprise can provide secure, protected access to Microsoft RMS protected documents even when the partner identities are stored in CA Siteminder – the answer is to utilize a security gateway to provide a layer of protection, authentication, and credential mapping. It also provides a nice way to segment the network for security purposes. If partner access needs to be shut down due to increased risk, it can be done at the gateway rather than fiddling with code.

In many cases this same authentication could happen with ADFSv2, but what happens when ADFSv2 isn’t an option in the DMZ?

Another cool aspect of this use case is that the partner clients are thick office clients sending in web services requests, which I thought was interesting.

Securing Oracle* Fusion Middleware with Microsoft* Active Directory

Read Allen Shortnacy’s interesting post about how to leverage an existing Identity Management asset such as Microsoft* Active Directory along with Intel® SOA Expressway in order to bring authentication and authorization to your Oracle* Fusion Middleware SOA implementation.