Are you building your APIs the right way?

I keep telling my customers, it is not about what you think is important but it is about what your customers (internal, external or partners) see as important when it comes to building APIs and mobile apps, or APIs for mobile apps. This article from Intel explains the facets of WHO, WHAT and HOW very nicely. We instituted a new practice called Intel API Manager which does all of the above and more. It includes a strategy session to identify the audience (WHO) that can benefit from this, WHAT are the channels that can drive additional revenue, and HOW we can help you achieve that.

http://software.intel.com/en-us/blogs/2013/01/28/taking-your-app-to-market-the-who-what-and-how-of-your-mobile-app-marketing

And, yes Intel does software!  - and very well too!

-Andy Thurai (Twitter: @AndyThurai)

Composite Distributed Applications and RESTful APIs

I was at Gartner Catalyst last week in San Diego for a luncheon keynote where I explored the concept of a composite distributed application. This is an idea that I have been chewing on for some time and is a direct result of how Enterprises are thinking about application architecture in light of “cloud” and “big data” as well as some of the trends we are seeing in our own customer base for Intel(R) Expressway Service Gateway.

First question: Where do Enterprise applications begin and end in 2012? Let’s state the obvious: the definition of an application as a monolithic piece of object code is ancient history. Let’s try the next definition, a standard n-tier shared nothing web application. This is certainly more timely, but I would also consider it dated.

If we add external cloud services, such as xPaaS (to use Gartner’s terminology) and disparate data warehouses or “big data”, located in geographically dispersed data-centers, this n-tier definition located in a single place doesn’t quite capture all of the application and may leave out important pieces. Key pieces of functionality may live “elsewhere” and this is where our standard enterprise application becomes distributed, with pieces in different physical locations as well as composite which means the inclusion of external xPaaS services such as storage, queuing, authentication or similar services.

So when we think about the larger boundaries of a composite distributed application, what are some salient properties? I came up with the following list for my talk:

Composite Distributed Application Properties

•Hybridized – Includes new feature development as well as the integration of legacy code, which can be done by integrating legacy message or document formats and protocols. In other words, Enterprises don’t want to throw out existing functionality, even if it happens to be written in a different programming language

•Location Independent- Important pieces of logic, persistence and functionality may be split across 1-n clouds, a mix of standard data center deployment, private cloud and public cloud. The application is essentially living across different clouds. All clouds can win.

•Knowledge Complete -  As traditional enterprises emulate web companies with big data analytics and web intelligence, distributed applications must access the results of “Big Data” analytics, which are possibly owned by different factions in the Enterprise. The composite distributed application will need to aggregate results and make important predictions across these sources as well as include any relevant data warehouse and JDBC sources.

•Contextual – Produces just-in-time results based on client context, device and identity. For example, the application I/O model must meet the demands of mobile devices, such as REST APIs, as well as internal enterprise stakeholders

•Accessible & Performs – Produces data compatible with any client on any operating system, with minimal latency. Scales to hundreds of thousands of users where clients are a mix of smart phones, tablets, browsers, or devices.

•Secure and Compliant - Meets compliance and security requirements for data in transit and data at rest, such as PCI, HIPAA and other requirements. This may involve a mix of traditional “coded-in” security,  security at the message level (via a proxy), standard transport level security, and data tokenization prior to analytics

Common Service Layer

A common theme of current Intel service gateway customers is the creation of a common service layer that unifies existing back-end services.What happens is that services grow organically on different platforms and operating systems, written in different languages but can be orchestrated under a common RESTful theme (for more background on REST fundamentals see DZone’s REST Reference Card paper). For instance, many of our customers have a mix of REST-style or SOAP web services and then use a gateway facade or layer to unify these. Unification, however, is only one of the requirements. The second requirement is external exposure to new clients and partners with appropriate performance, trust, threat, and increasingly, throttling/SLA features. Trending right now are OAuth and API key mechanisms, especially when the clients are expected to be mobile devices.

How does this architecture grow into a composite distributed application? This is where location can play a role: as enterprises adopt more cloud PaaS services, their existing services will grow beyond what is found in the data-center, to what is found outside the data-center.

For example, one large service provider that we work with uses Intel Expressway Service Gateway to create a facade for 50+ RESTful services. In the future as they adopt cloud, additional services may also be delivered from the cloud that fit under the facade,  so the RESTful facade and services together may all be properly called “the application”  – here the application is a mash-up of services split among clouds.

We call it “the application” because its all three pieces, the gateway, the internal services and the cloud services that comprises the pieces.  The next question here is how to secure these API interactions and ensure this new breed of application meets performance and compliance requirements.

I think the answer here is that you have to focus on the data itself sent and received at each API hop. This means more emphasis on tokenization and encryption, as well as an understanding of the relevant authentication and authorization controls and how they apply depending on who needs to access the data. For “Big Data” this may mean pre-processing map/reduce input to provide tokenization or encryption prior to performing analytics, essentially ensuring compliance prior to processing.

-Blake

How to Harden Your APIs by Andy Thurai

The market for APIs has experienced explosive growth in recent years, yet one of the major issues that providers still face is the protection and hardening of the APIs that they expose to users. In particular, when you are exposing APIs from a cloud based platform, this becomes very difficult to achieve given the various cloud provider constraints. In order to achieve this you would need a solution that can provide the hardening capabilities out of the box, but that still permits for customization of the granular settings to meet the solution need. Intel has such a solution and it has been well thought out. If this is something you desire this article might help you foresee the many uses and versatility.

Identify sensitive data and sensitivity of your API

The first step in protecting sensitive data is identifying it as such. This could be anything like PII, PHI and PCI data. Perform a complete analysis of your inbound and outbound data to your API, including all parameters, to figure this out.

Once identified, make sure only authorized people can access the data.

This will require solid identity, authentication, and authorization systems to be in place. These all can be provided by the same system. Your API should be able to identify multiple types of identities. In order to achieve an effective identity strategy, your system will need to accept identities of the older formats such as X.509, SAML, WS-Security as well as the newer breed of OAuth, Open ID, etc. In addition your identity systems must  mediate the identities, as an Identity Broker, so it can securely and efficiently relate these credentials to your API to consume.

You will need to have identity-based governance policies in place. These policies need to be enforced globally not just locally. Effectively this means you need to have predictable results that are reproducible regardless of where you deploy your policies. Once the user is identified and authenticated, then you can use that result to authorize the user based on not only that credential, but also based on the location where the invocation came from, time of the day, day of the week, etc. Furthermore, for highly sensitive systems the data or user can be classified as well. Top secret data can be accessed only by top classified credentials, etc. In order to build very effective policies and govern them at run time, you need to integrate with a mature policy decision engine. It can be either standard based, such as XACML, or integrated with an existing legacy system provider

Protect Data

Protect your data as if your business depends on it, as it often does, or should. Make sure that the sensitive data, whether in transit or at rest (storage), is not in an unprotected original format. While there are multiple ways the data can be protected, the most common ones are encryption or tokenization. In the case of encryption, the data will be encrypted, so only authorized systems can decrypt the data back to its original form. This will allow the data to circulate encrypted and decrypt as necessary along the way by secured steps. While this is a good solution for many companies you need be careful about the encryption standard you choose, your key management and key rotation policies. The other standard “tokenization” is based on the fact you can’t steal what is not there. You can basically tokenize anything from PCI, PII or PHI information. The original data is stored in a secure vault and a token (or pointer, representing the data) will be sent in transit down stream. The advantage is that if any unauthorized party gets hold of the token, they wouldn’t know where to go to get the original data, let alone have access to the original data. Even if they do know where the token data is located, they are not white listed, so the original data is not available to them. The greatest advantage with tokenization systems is that it reduces the exposure scope throughout your enterprise, as you have eliminated vulnerabilities throughout the system by eliminating the sensitive and critical data from the stream thereby centralizing your focus and security upon the stationary token vault rather than active, dynamic and pliable data streams.. While you’re at it, you might want to consider a mechanism, such as DLP, which is highly effective in monitoring for sensitive data leakage. This process can automatically tokenize or encrypt the sensitive data that is going out. You might also want to consider policy based information traffic control. While certain groups of people may be allowed to communicate certain information (such as company financials by an auditor,etc) the groups may not be allowed to send that information. You can also enforce that by a location based invocation (ie. intranet users vs. mobile users who are allowed to get certain information).

QOS

While APIs exposed in the cloud can let you get away with scalability from a expansion or a burst during peak hours, it is still a good architectural design principle to make sure that you limit or rate access to your API. This is especially valuable  if you are offering an open API and exposure to anyone, which is an important and valuable factor. There are 2 sides to this; a business side and a technical side. The technical side will allow your APIs to be consumed in a controlled way and the business side will let you negotiate better SLA contracts based on usage model you have handy. You also need to have a flexible throttling mechanism that can help you implement this more efficiently such as just notify, throttle the excessive traffic, shape the traffic by holding the messages until the next sampling period starts, etc. In addition, there should be a mechanism to monitor and manage traffic both for long term and for short term which can be based on 2 different policies.

Protect your API

The attacks or misuse of  your publicly exposed API can be intentional or accidental. Either way you can’t afford for anyone to bring your API down. You need to have application aware firewalls that can look into the application level messages and prevent attacks. Generally the application attacks tend to fall under Injection attacks (SQL Injection, Xpath injection, etc), Script attacks, or attack on the Infrastructure itself.

Message Security

You also need to provide both transport level and message level security features. While transport security features such as SSL, TSL provide some data privacy you need to have an option to encrypt/ sign message traffic, so it will reach the end systems safely and securely and can authenticate the end user who sent the message.

Imagine if you can provide all of the above in one package. Just take it out of the packaging, power it up, and with a few configuration steps provide most of what we have discussed above?  More importantly in a matter of hours you’ve hardened your API to your enterprise level (or in some cases better than that). Intel has such a solution to offer.

Check out our Intel API gateway solution which offers all of those hardening features, in one package and a whole lot more. Feel free to reach out to me if you have any questions or need additional info.

http://cloudsecurity.intel.com/solutions/cloud-service-brokerage-api-resource-center

 

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

Next Gen Enterprise API Architecture for Mobile

The Enterprise software industry has grown up around the standard three tier-architecture for web applications, which was pioneered circa 1995. This architecture is ideal for web browsers, which have become the universal client of the Enterprise.

With the introduction of Enterprise mobile applications, we are seeing new avenues for innovation, new user experiences and increased convenience. In some ways, however, we are rolling back the clock.

Allow me to clarify: If we accept the premise that native mobile applications deliver the best functionality on disparate mobile platforms, we are at the cusp of re-introducing “thick client” applications back into the enterprise. Native mobile applications are rich in their design and functionality but behave like monolithic applications: They provide their own persistence tier, slick user-interfaces, natively compiled code, require upgrades and updates on the client device, and utilize a mix of synchronous and asynchronous communication. Sure they use REST for communication, but is this due to historical accident?

Other than the physical platform itself (which is a smartphone or tablet), native mobile applications may have more in common with old “Win32 client/server apps” that existed before the browser revolution. Are we moving forwards or backwards?

Further, what about web mobile applications that run in the browser on the mobile device? How do they factor in? How do new technologies like HTML5 affect these types of applications? How do REST APIs affect the mobile architecture?

Is the Enterprise ready for mobile? How does the standard three tier architecture fare in light of these trends?

I try to get a handle on these issues in our new whitepaper, A Unified Mobile Architecture for the Modern Data Center

Happy Reading,

Blake

New Mobile Middleware Whitepaper

The transition from a browser-only world to the mobile app proliferation of today, necessitates a host of new considerations when it comes to securing the enterprise network.  Our latest whitepaper, “A Unified Mobile Architecture for the Modern Data Center,” analyzes the mobile application landscape and what it means for the prevalent multi-tier architecture, which for some time has been tailored around browsers as the main entry point.  As RESTful API calls surpass traditional web traffic for the largest app providers, this concern becomes even more immediate.

With the understanding that most enterprise networks are a mix of both on premise and cloud-based solutions, this whitepaper takes this viewpoint as the basis for its analysis.  Given the heterogeneity of the mobile app landscape in terms of platforms and operating systems, each with their own unique programming language and set of best practices there is an added layer of complexity in adapting existing enterprise architecture for this new mobile user base.

For the complete whitepaper on mobile middleware, click here.

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.