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 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.

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 on Security, SOA, Identity, Governance and Cloud topics. You can find him on LinkedIn at


Intel Expressway Outpaces IBM DataPower by 6x to 10x in a Direct “Apples to Apples” Comparison

Prior to the release of Intel’s XEON processor E5-2600, Intel Expressway Service Gateway (also available as McAfee Services Gateway under the McAfee Cloud Security Platform Suite) was already providing superior performance and value. However, with the record breaking E5-2600 – delivering leadership performance, best data center performance per watt and break through I/O innovation, the distance between — front-runner Intel, and IBM WebSphere DataPower XI50 has  increased dramatically.

Our customers can take advantage of continuous chip improvements with the easily upgradeable software appliance form factor. Intel Expressway Service Gateway outpaces IBM DataPower by 6x to 10x in a direct “apples to apples” comparison at a fraction of the total cost.

Read this performance comparison report to learn all about it:

For more information about Intel Expressway Service Gateway — with free webinars, tutorials and expert blogs on securely exposing Web Services in the Cloud, please visit us at:

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

Achieving unified control, visibility, and compliance for SaaS applications

Technical Information Security Policy

The first step to delivering the right control and visibility architecture for SaaS is to formalize the enterprise’s goal in a Technical Security Policy. The security policy lifecycle begins with policy creation and development. The Security architect must collaborate with policy authors, management, development and operations to define specific technical policies that will enforce the security architecture decisions. These policies may govern issues such as:

  • Define allowable & non-allowable usage
  • Security token types & issuers
  • Integrity requirements
  • Logging & monitoring requirements
  • Access control protocols
  • Message and Channel Encryption

These are a subset of some of the concerns that the Technical Security Policy must address to govern access and visibility to SaaS applications. Every organization has some type of Information Security Policy, these are typically hundreds of pages long, but are written at a high level and do not contain specific technical guidance such as the above list. The Technical Security Policy closes out this gap. Some standards such as WS-SecurityPolicy have emerged in this space and are worth studying to understand the level of granularity that can be expressed.

As a rule of thumb, the Technical Security Policy should include allowable and no-allowable usage for the application’s Attack Surface. For many SaaS applications, the Web Services Attack Surface is comprised of the application’s Data (such as XML), Methods (such as SOAP, and URI), and Communication channel (such as HTTP). In other systems such as Mobile applications the Attack surface could also include SMS, Geolocation, and other smartphone services.

The Technical Security Policy is likely to be highly contextualized based on each deployment type, and to cover a wide array of different deployment integration patterns – from network security to app security to identity management. This approach is good from a design standpoint because it allows the Security Architect to be precise and specific with guidance. It’s also problematic because the audit, review, execution and lifecycle management can be challenging.

Closing Out Technical Gaps with a Security Gateway

The Security Gateway pattern fills this gap by providing an execution environment to enforce the Security policies. Sure, each endpoint can be wired up to validate SAML assertions and enforce message integrity, but for a system with numerous endpoints, manageability and assurance quickly becomes a limiting factor to this approach. The Security Gateway pattern mediates communication to and from SaaS application providers and gives the Security Architect the ability to ensure that technical security policy is being enforced. Further, the Security Architect now has a location to manage and deploy any changes to the Security Policies. Say that a SaaS provider is initially only supporting weak username/password combination for access, but that the SaaS provider is working on an upgrade to support SAML. Instead of re-wiring all endpoints, the Security Architect can wire on SAML on the Security Gateway once the SaaS provider is operational with SAML.

The SaaS provider is home to some of the enterprise’s most important data and functionality such as customer data. The Security architect will often seek to record any CRUD access to the critical SaaS functionality and data, and to accomplish the Gateway chokepoint for inbound and outbound access is essential. Simply monitoring open and close network connection won’t cut it, when message semantics are needed to determine who did what where in the SaaS application.


The Gateway formalizes the security architecture’s roles and responsibilities with the SaaS Cloud provider. The Gateway serves to enforce the policy, making runtime access control decisions, provide a place for auditors to review the controls for compliance purposes, and for the administrators to manage the system over its lifecycle. This division of roles and responsibilities gives the enterprise the ability to retain a modicum of control while still leveraging Cloud applications for their benefits.


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

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 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.




Intel Announces a PCI DSS Solution

At the National Retail Federation (NRF) show last week, Intel announced the release of the Intel® Expressway Tokenization Broker. Offered in conjunction with Intel® Expressway Service Gateway, Intel’s industry-leading XML security gateway appliance, Tokenization Broker lowers costs and dramatically simplifies administration of Payment Card Industry Data Security Standard, or PCI DSS, compliance for organizations across all industry types, by replacing customers’ Primary Account Number, or PAN, information with secure tokens.  For downstream applications that receive such tokens, PCI scope is either reduced or completely eliminated.
Want more information? Visit the following page for a whitepaper, datasheet,  informative webinar,  and much more.