Email Subscription

I have been sitting on this blog/thought for awhile but it’s even more timely now with the Global Payments breach (Reported first by Brian Krebs on his security blog). Global Payments is a merchant acquirer that has contracts with retailers for handling the processing of card transactions (credit card, debit cards, gift cards of all brands). Though the information about the breach is still being assembled, it is estimated that information about 10 million+ accounts was lost. Though Global specializes in “mom-and-pop shop” transactions, the company itself is very well established ($167 Billion worth of transactions last year alone). This breach happened in spite of having decent security measures in place. What is worse is that the data stolen is full “ track 1” and “track 2”, which means using that stolen data, one could easily produce counterfeit cards. (Be on the lookout for unauthorized charges in your account – it is hard to dispute a transaction when someone swipes a card unless you catch it early – I can tell you that from personal experience).

The problem lies in the whole complex payment systems that were developed years ago for payment transactions. In those days, security was not on everyone’s mind. That was partly because because most of these systems ran on private networks (and leased lines) and the hackers those days were not that savvy. It is sad, but true, that it is much cheaper for the companies to deal with the breaches than to make their systems more secure. You might recall a serious breach with Heartland Payment systems a couple of years ago, where they lost about 130 million cards. Last year hackers stole payment card information for more than 100 million customers of off Sony’s PlayStation Network. Suffice it to say – that in between these events, there were multiple smaller breaches that went unnoticed.

If you are a security architect and are wondering how you can safeguard your company from such disasters, we here at Intel can help you. While we have many solutions that can help in various areas, I would like to talk about a particular solution, our Tokenization Solution – Intel Expressway Tokenization Broker (Intel ETB).

A few years ago, PCI-DSS released a new directive that opened the door for a new concept called tokenization. Of paramount importance when dealing with sensitive data is the overarching need to keep it secure. Up until a few years ago, that was done by encryption. While an encryption solution is very good for what aims to achieve, the attendant issues ended up becoming major issues (key management, key rotation, encryption strength, etc). If a hacker catches a transaction in flight, or hacks in to the systems and catch that transaction in memory/ process (where the data might be in clear) the issue becomes even graver.

In order to avoid this, PCI-DSS released a directive (and updated it late last year with PCI DSS 2.0 Aug 2011) for tokenizing the PAN (Primary Account Number) information. At the heart of this directive is the fact that if you create a true random token (i.e., format preserving surrogate) there is no way that a hacker who intercepts that message can get the original information back. Hence, there is no monetary loss if someone were to capture the token in flight or from storage.

Intel provides hardened proxy Token Brokers that one can either slide in front of or in back of any application (we do support almost all standard protocols and data formats) that can sit in the line of traffic and perform these tokenization actions. Essentially that means very little or no work is required on the applications/API/services side. By sliding our proxies in the line of traffic, you can ensure that all of the channels are secure and that no one can sneak in.

An application needing original data can come back to Intel ETB and then be provided with the original data. This can be either a side call (as in a call to an API to reverse the data) or via an in-line reverse translation, so that the receiving application will receive the original data without a need for modification. In this scenario, only the necessary applications (or the proxies) would know where to go to resolve the token. Such an application would need to be white listed. Moreover, the connection could be made as a 2-way mutually authenticated SSL that would establish the identity of both sides, ensuring that the information travels securely end-to-end.

Tokens are stored in a hardened database which is nearly impossible to breach and which only Intel ETB can connect to. All the communication from Intel ETB to the database is secure and the database has a white list of only tokenization brokers that it, in turn, can connect to.

In short, by using Intel Tokenization Broker (Intel ETB) solution you get,

Storage and processing using surrogate data and not the original data.

Also, check out this whitepaper by Walter Conway, QSA, who is an expert on this subject.

As George Santayana once wrote, “those who cannot remember the past, are condemned to repeat it.” I’m hopeful that we will be able to help our customers protect their enterprises so that these things won’t happen in the future.

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.

How does an Enterprise with a hybrid cloud strategy use emerging platforms such as PaaS and IaaS?

This is one of several questions that Intel Product Manager Blake Dournaee will help answer in this short 5 1/2 minute video. When utilizing those platform services for API communication, you need to typically worry about perimeter defense, Authentication Access Control and Authorization (AAA), Data Protection, Auditing, and Visibility as transactions move from the Enterprise to the Cloud.

Watch this short video and quickly ramp up on 3 use cases for a Service Gateway and how it can address all these domains of concern. Learn how a Service Gateway can act as a single control point and provide the necessary visibility when using PaaS or IaaS. Also learn about the Cloud API management and Cloud Service Brokerage usage models.

For more information about Intel Expressway Service Gateway (also available from McAfee as McAfee Services Gateway), please visit: www.intel.com/go/identity

A few weeks ago I had a conversation with a customer of mine and we discussed this very topic. How do you measure perfection? It’s a good question worthy of inquiry. I was really surprised at the different answers suggested in the conversations that ensued.

Perfection is, as stated by Merriam-Webster dictionary, “broadly, a state of completeness and flawlessness, an unsurpassable degree of accuracy or excellence”. Some would also would say perfection is the absence of judgment. :)

If you operate within a Math or Science context, the term perfection is actually used to designate a range of diverse concepts. These concepts have historically been addressed in a number of discrete disciplines, notably mathematics, physics, chemistry, ethics, aesthetics, ontology and theology.

To an extent, “perfection” is a state of mind. Why am I telling you all of this? I was asked the question “Is your solution Perfect for our situation”? So instead of pursuing a quest for the meaning of perfection (and the meaning of life) I thought I would take this opportunity to write a series of blogs within which I am going to highlight our solution capabilities and recent enhancements that may make our solution perfect for you! (You knew that plug was coming right)?

A few years back (I used to work for a competitor at that time), I was visiting a customer of ours to discuss a complex architectural issue they were having. I sat down with the Security Architect, Enterprise Architect, and the CISO of a big insurance company (who shall remain unnamed) to discuss an issue. At the time, to show me the issue at-hand, they pulled up a specific transaction to analyze. There it was, the admin password for the system (the holy grail), for their important backbone component, baring its nakedness to us in clear text. In all fairness, the ‘most verbose log feature’ was turned on to debug a specific issue in that situation. After we joked about the fact that I then knew the admin password for their the backbone and for their entire enterprise, I was told I was going to spend most of my life in a corner of their data center sleeping on a rug!

The conversation got very serious when we talked about how admin passwords should NEVER be displayed, in clear text, on any log for any reason. I took this noted and avoidable vulnerability back to my Product Management/Engineering teams. To my surprise, the concern was brushed aside as a non-issue.

A risk of this magnitude could easily be considered a major compliance issue if you are an organization that deals with HIPAA and/or PCI compliance. Regardless of whether you have the most verbose mode turned on or not, if you leave PCI or PII (personally identifiable information) clearly visible in logs, in clear text, you are creating potential breaches. As is sometimes the case, log data gets lost and at the most innoportune time — could be unearthed during an audit. Aside from exposing one’s self to the risk associated with not properly safeguarding data, those risks multiply when failed audits lead to very expensive fines.

The California supreme court recently ruled in a case, Pineda v. Williams-Sonoma, that zipcodes are really “personally identifiable information” (PII). In a California’s Song-Beverly Credit Card Act, California Civil Code section 1747.08, reversing the Court of Appeal‘s decision the supreme court made a ruling on this. Penalties of up to $250 for the first violation and $1,000 for each subsequent violation could accrue, without there even being any allegations of harm to the consumer.

Section 1747.08 of this law states that a retailer cannot ask their customers for PII information (including zip codes), or record it during credit card transactions. (I have distilled the legalese for you. However, those so inclined may read about the ruling in its entirety at http://www.leginfo.ca.gov/cgi-bin/displaycode?section=civ&group=01001-02000&file=1747-1748.95. Though this information is applicable only to PCI compliance right now, there are laws pending in California (and in other states) around the essence of PII. This may end up being germaine to medical records, EHR (Electronics Health Records), and prescription Information, etc.

Initially it could be limited to include SS#, PAN (credit card info), date of birth, zip codes, address, age, gender, password (in the corporate world), etc. However, safeguarding data could potentially expand into several other domains. All organizations need to be cognizant of how the laws and regulations continue to change at a state and national level and how they may vary from one country to another. Imagine if you are using a cloud provider, which is hosting your data in a country (not of your) choice, where you have virtually no control.

In the next few blogs I am going to talk about our Log Redact, Data Redact, Data privacy, Compliance, Encryption and Tokenization capabilities, which will help address some of the aforementioned issues. They not only help you address today’s needs but will also enable you to “change direction” as necessary as incipient changes come to fruition.

You may already know that Intel acquired McAfee, the leader in the security software business, over a year ago. We are quickly seeing the successful integration of both entities. However, as part of this perfection series, I’m going to share with you in greater detail, our integration efforts with McAfee security components. At the end of this series, you’ll get a sense of palpable energy abound, and the synergies that are helping us to bring even better solutions together for our customers.

As far as that company that had given me a rug to sleep on in the datacenter corner for sharing their family secrets? I wish I had this solution set handy when I was at that meeting! Oh well, comfortable sleep is often over rated anyways.

If you would like a sneak preview of some of the solutions that I’m going to address in this blog series, please visit:

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.

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.

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.

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:

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.

Keep your security and API management closer to your APIs and be transparent about it with your customers.

Remove security, scalability, management and audit functionality and issues away from the an actual API implementation.

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.

In a recent conversation with a large customer of ours, some interesting facts came to light. This blog is a recapitulation of the insights I got from that discussion. I’ll not only tell you how this customer is using our solution, but also, how it is helping them to take their online presence to the proverbial next level.

Our customer, an online university, is using our solution, as middleware – providing both security and data mediation functions, to push through SOAP & REST API transactions to the backend. They are processing about 18 million messages per day. Now think about that for a second. The number in itself is mind staggering. While most educational institutions use freeware middleware solutions due to being part of an ultra cost-conscious milieu, this University decided to use our solution to bring their presence to a whole new level — while still doing so in a completely cost effective fashion.

We also helped the University integrate with a home grown single sign-on solution fairly easily so they would not be forced to “rip and replace” all of their technology, unlike some of the implementation plans that would be thrust upon them by some of our competitors. We integrate with identity management systems, as well solutions that address governance, various registries ,and an array of monitoring solutions. For us, it’s never about pushing an entire stack to a customer. Instead we feel customers should have the latitude to choose a technology from a range of available options, consistent with a “best of breed approach.”

Though it initially started off as more of an academic security experiment for a University, our solution has been embraced much more widely and has grown into a solution that encompasses SSL offloading, XSLT transformation, service aggregation, and service mediation. In addition, our solution is being used to abstract the authentication layer to communicate with a custom authentication service. We provide the backbone of their social SOA.

The initial services were mostly SOAP based, however, when the REST services were ready — we were ready too, to help them out with a product that similarly could address all of the same relevant security concerns.

The true reason everyone is excited, though, is because the University is looking to move their service offerings to the cloud. At first glance, moving all your services (or even just a service abstraction layer) to the cloud and exposing that 24×7 to hackers can be quite the daunting task! Another concern revolves around their customers’ resource utilization. Especially when you are offering your services for free (at least most of the time,) if you expose those services without throttling them, can be asking for a lot of trouble. Rest assured — Intel has a feature built in our solution set that will help them with both their security concerns and their ability to implement throttling .

Our Quality of Service (QOS) functionality allows service providers to limit the usage of services, a classic need in a cloud delivery model which is often overlooked due to the perception about the elasticity of the cloud. In my mind, just because you can throw resources without any limit – ignoring fundamental architecture design principles such as TOGAF, DoDAF, Zachman – should be a huge concern, and “top of mind” for everyone. While you can implement some of these functions at the application/services level, , a lot of overhead will be added to the application itself. Moreover, here will be no uniformity across applications on how this feature is implemented.

If, on the other hand, you were to use our QOS functionality – you can monitor API usage, meter the usage based on the identity of the user (technically, not only based on the identity, but you can even go lower than that. Think more along the lines of something location + identity + invocation based).

You not only can limit the service usage based on predefined policies, but you can enforce those policies globally. Our solution provides for the ability for a backend application to recover in case of overload. This built-in “self healing” feature should allow many services to recover without a need to bounce / reboot often. And the built-in auditing, reporting, logging tool keeps extensive details so it can be used not only for a forensic analysis, should the need arise, but also when implementing a charge back system if so desired.

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.

Essentially that is what it is. Recently we announced our Force.com based Cloud SSO solution. What is unique about this is that we are the first (and as of now the ONLY) solution that will allow Force.com user identities to be federated not only across Force.com applications, but also across other cloud providers as well.

We provide Identity for the cloud in the cloud – now that is different, isn’t it?

I know, I know… there are about half of a dozen vendors that claim to provide a Cloud SSO solution. So why are we different or better than the others?

We provide a fusion, bringing together the best of McAfee and Intel. We bring years of advanced security research , our multi-tenant offering cloud security suite from McAfee, coupled with Intel’s Identity offering that includes SSO, hardened provisioning/de-provisioning and an escalated authentication (OTP) solution.

Everyone knows that salesforce.com is all about the cloud and SaaS, right? But once you set up your users/ identities in the Force.com platform it can be only used there. If you need to setup another SaaS application then your administrator needs to setup the user base all over again. Even though there are tools available to make this process easier it is still a chore. Imagine if you could have the power to set up the identities and policies once and run forever. If your users have to remember only ONE password then you could enforce the passwords to be very strong. This would not only reduce the security risk (imagine a SaaS application having a weak password… what can be more dangerous than that) but it could also help with eliminating a lot of help desk password reset calls from frustrated users.

One pivotal and unspoken benefit is the increase in productivity where a user can seamlessly navigate between applications.

Our solution also includes a hardened, proven provisioning/ de-provisioning which takes care of syncing identities across applications and across multiple cloud providers. And there is also a built-in escalated authentication of identity using a second form factor which comes in handy when someone tries to use sensitive applications. Our OTP (One Time Password) solution allows the users to provide the second factor (of what you have in addition to what you know).

If you missed our recent announcement about the beta release at RSA check it out here.

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.

Have you read the latest case study involving a top defense contractor that deployed Intel* Expressway Service Gateway at the DoD?

The top contractor deployed Intel Expressway Service Gateway to secure data sharing and achieve wire-speed content attack prevention, provide support for multiple message formats without the need for custom programming and lower their cost and time to implementation.

You can learn more about Intel Expressway Service Gateway and the other Intel Expressway products by visiting www.intel.com/go/identity