Now-a-days every single CIO, CTO, or business executive that I speak to is captivated by these three new technologies: Big Data, API management and IoTs (Internet of Things). Every single organizational executive that I speak with confirms that they either have current projects that are actively using these technologies, or they are in the planning stages and are about to embark on the mission soon.

Though the underlying need and purpose served are unique to each of these technologies, they all have one thing common. They all necessitate newer security models and security tools to serve any organization well. I will explain that in a bit, but let us see what is the value added by these technologies to any organization:

IoT – is specific data collection points that employ sensors placed anywhere and everywhere. Most often times the information collected by these devices are sensitive data and contain specific identifiable targeted data. IoT allows organizations to analyze behaviors and patterns as needed but also poses an interesting problem. Gone is TB (Terabytes) of data; now we are talking about PB (petabytes) of data which continue to grow exponentially. IoTs use M2M communication, which are a newer channel and create a newer set of threat vectors.

Big Data – - store massive amounts of data (some of these data are from the aforementioned IoTs) and having the necessary software and infrastructure that allow you to access them faster which promises to cost you a fraction of what it is costs today, further enabling you to capture as many data points as possible.

API – interface, enabler and interconnector between systems by providing a uniform and portable interface (whether it is to the big data or the platform that enables big data).

While each of technologies at first glance appears to be serving different constituencies within an Enterprise, there is an undeniable interconnectedness that exists. The IoT collects data from everywhere. Hence, it is pouring tons of data that need to be not only stored somewhere, but also analyzed properly so that the dots can be connected, to ultimately form meaningful patterns that people can make use of.

[In the graphic above assume all communications to the central neural system is via APIs.]

With the evolution of these technologies, there is a very raw, basic, and yet incontrovertible need being expressed. Every business yearns to be better than its competitors in catering to the needs of its consumers. I mean the “consumer” in a loose sense here – be that an individual or for that matter, an organization that is consuming your offerings. Ipso facto, this means you need to capture as much information as you possibly can about the target consumer behavior, so that it can be analyzed, protected, stored, shared selectively, and most importantly, so that it can serve your consumer better (or perhaps  to be used when strategically monetizing an area of your business).

None of these technologies is in a trial phase any more. If anything, the social media explosion provided ample evidence that these technologies are being used quite effectively already (real life POCs). Of late, all of these technologies have been gaining adoption in the sacred technology worlds, such as the healthcare and financial sectors.  However, when you employ these technologies with your production applications, you need an enterprise grade security that is built from the ground up to provide a necessary level of protection.

In the social world, the model had always been, “build [it] first and secure later based on the need” (or never in some cases). With healthcare, federal and financial sectors, that model is no longer tenable. You need to secure data at any cost, question anybody who wants access, and be hyper-vigilant without compromise.

What is particularly troublesome is that these organizations seem to be of the thought that they can extend existing security measures to protect all of these newer technologies. While your SSL, Identity systems and other existing controls can serve as the baseline for these technologies, you need a newer set of security controls and tools in place. Your security model needs to make the necessary accommodations, instead of trying to force fit everything to make the older set of tools to fit. That would be like trying to fit a square peg in a round hole. I have seen customers trying to bend RACF to fit the newer SOA, API, Big data paradigm. While it can be done, it would end up costing you more, will be very inflexible, and defeats the fundamental purpose of security. Don’t get me wrong — everything has a place in this universe.

Remember I wrote recently about the disappearing perimeter defenses and moving lines of thin defense. This is due to shared data centers, cloud adoption, multiple shared tenants, deeper integration and wider exposure to multiple partners, etc. Regardless of the scenario, you need to protect your own data and be accountable for it. Cyber attackers are very sophisticated and are funded by organizations (or even countries), which means they need to get to the proverbial data goldmine.  Without adequate protection, this can prove to be that goldmine. The thing that scares me the most is the underlying threat to all of the above technologies when you try to fit them into the older security model. Most of the above technologies, from what I have observed, are either under protected or unprotected. While it is great for organizations to maximize monetization and satisfaction of a consumer and have a competitive edge over others, that shouldn’t come at the cost of security or by increasing their risk. Especially when it comes to security, Murphy’s Law is always right; it is not a question of if a security loophole will be exploited; it is a question of when.

You not only need to identify the users, authenticate them, and authorize them but also make sure they are allowed access during that time window that they are requesting the info (throw in a location based and device based identification on top).

In addition, you also need to worry about protecting the big data store itself, including strong encryption of storage, transmission, and in process data.

But then, most important of all, you need to mitigate the threat vectors that are created by these new technologies. I will write in the next few articles about how you can protect all of these areas with minimal effort while keeping your TCO very low. I will also talk about specific usecases and usage models that will make sense.

Blake recently wrote a great blog on “touchless” Big Data security. I urge you to check it out here. Demo version is here.

The post Big Data, IoT, API …….Newer technologies protected by older security. appeared first on Application Security.

Kin Lane has started tracking what he calls API Brokers over at API Evangelist. This quote illustrates the promise of API brokerage:

I envision other new API brokers emerging, in niche areas like images, video or messaging. Imagine if you could use Twilio, Tropo or other SMS API provider, but use through a broker who will give you the best availability and costs based upon various needs. This type of API aggregation is not meant for providing users with access to multiple cloud silos via APIs, it is more about brokering API resources and establishing a marketplace.

This really resonated with me, as it is similar to something we’ve been talking about for a while:  IT as a Cloud Service Brokerage, which is an emerging specialization of API management. As SaaS, Consumerization, and the general bring-your-own trends continue to accelerate, IT shops are looking to bundle new functionality into their applications while ensuring that they still deliver the expected levels of service. Consumerization/BYO has expanded from handheld devices and ultrabooks to include cloud services like Dropbox, Evernote, and Google Docs. APIs will be the next wave in consumerization. As is the case with many cloud services, APIs with equivalent functionality can be available from multiple sources, but the longevity of the providers (or, as is often the political reality, the contract with the providers) may be uncertain. In addition to the services Kin mentions,

• Translation / localization services — remember when Google temporarily pulled the plug on the Translate API? Fortunately they changed their mind, but what if they hadn’t?
• Location / Mapping services
• Push notifications
• … One could spend weeks browsing ProgrammableWeb or Kin’s own list of building blocks and uncover dozens of domains with two or more functionally-equivalent providers

What is an IT shop to do, then, when incorporating cutting-edge functionality into applications when the only providers are fledgling startups (or even hobbies within multi-billion dollar corporations)? It seems like a few options exist:

• Bet on the current leader when the app is being developed; rip & replace if conditions change
• Code multiple providers’ APIs into the app, embedding some prioritization and fall-back logic
• Use an aggregator

Clearly the aggregation layer (whether embedded in the app or as a cloud service) offers more agility and resilience than hard-coding. The additional indirection provides protection against service outages – whether they are due to an operational issue with an API provider, an infrastructure issue with their cloud service provider, or an untimely end-of-life for the service. However, given that this domain is just emerging, most of the aggregators are likely early-stage startups themselves. Their availability and longevity may not be any better than the APIs they are proxying — in fact, it may be less.

An enterprise IT shop has another option here: acting as its own Cloud Service Brokerage. An API gateway is already acting as a proxy between clients and APIs. By adding some additional logic to the API management workflow, the gateway can offer a fallback path to a different provider. By placing the API management & brokerage layer inside the enterprise cloud (whether public, private, or virtual private), the brokered APIs will have the same availability as the rest of the enterprise infrastructure. The gateway already has remediation capabilities built in — JSON or XML fields can be renamed and reordered, omitted, or populated with default values. An enterprise could even define its own API structure that is then redirected in the format expected by the services it is brokering. If necessary, this logic can be combined with format-preserving encryption or tokenization to ensure that sensitive corporate data isn’t transmitted to a third party.

This on-prem brokerage approach is not without tradeoffs, however. First, an API management solution is not likely to be as dynamic as a specialized brokerage service. This means that market forces are less likely to be factored into the runtime routing decision. While contracts and other external forces can be incorporated at configuration time and reviewed on a regular basis, the multi-provider API management policy is most likely going to be implemented as a favored provider with fallback providers utilized for availability, not cost (on the other hand, a brokerage service’s profit margin may offset much of cost savings due to market efficiency). Also, by using a brokerage (whether internal or external), there may be functional tradeoffs: the application may be restricted to the greatest common denominator of all available APIs to allow for aggregation and avoid vendor lock-in. I find these tradeoffs to be fairly standard in Enterprise IT, however, and are widely accepted as part of the cost of providing a stable, predictable IT environment.

I’ll revisit this topic again in the context of Mobile Backend as a Service (MBaaS), but in the interim I’ll leave off with a webinar featuring Gartner on IT’s role as a Cloud Service Brokerage.

The post Be Your Own Broker: An Enterprise Perspective using API Management appeared first on Application Security.

I saw a conversation today on Twitter that asked why we don’t just embed proper security into Hadoop instead of suggesting the API gateway approach to Hadoop security that my colleague Blake proposed.  The same could be asked about any number of applications and services, but the bottom line is that we believe that a two-pronged approach is best.

Internally, we have dramatically improved Hadoop’s security capabilities via Project Rhino.  This enables best security practices like encryption at rest, which cannot be implemented anywhere else.  We are also working to standardize the authorization framework and implement token based authentication with single sign-on.  These are all core capabilities that absolutely need to be added to Hadoop’s code base.

The gateway approach addresses something else – the API layer.  While I agree that any application should protect against common attacks, consider this in the bigger picture.  First, consider the number of different features that may be required by Hadoop adopters:  tokenization, data field encryption, integration with Active Directory, mapping to OAuth for mobile applications, etc.  It would take a staggering number of man-hours to implement all of these features within Hadoop.  Now consider the number of enterprise applications that expose APIs — consider the investment required to duplicate those features within each of these application suites.  Finally, consider the job of the poor sysadmin who has to selectively enable these features consistently across everything in their domain, along with the one who gets to come along behind him and audit for compliance.  Add to that the probability (or lack thereof) that all of these vendors implemented the features with common configuration processes…

Our façade proxy abstracts much of this functionality to an external system with an easy-to-use graphical interface.  Implementation and inspection of common security policies can be managed across all APIs within the enterprise.  More complex, custom workflows can be created and reused as well.  Finally, the gateway complements the Project Rhino work which provides a solid security foundation that can then be extended (in a standard fashion) by the gateway.

Part of the objection/confusion is shown here:

@alexis_gil my problem with it is standard – adding a totally new layer in between with completely new protocol doesn’t help adoption

— Alex Gorbachev (@alexgorbachev) May 14, 2013

I want to clarify that we are talking about standard protocols – in fact, the gateway pattern is really putting a secure front on the already standardized APIs found in Hadoop such as WebHDFS and Stargate. These APIs aren’t new protocols, but the façade pattern helps with separation of concerns and lets the data scientists worry about data and the security folks worry about security.

The post Hadoop Security: Internal or External? Why not both! appeared first on Application Security.

Join us Wednesday, May 22 at 10:00a Pacific / 1:00p Eastern for our next webinar with Capital One and Mashery:

APIs are a hot topic in all sectors of IT – they have gone from being niche solutions provided by big players like Amazon and Google, to being almost as ubiquitous as corporate websites. Ad hoc API development & evangelism without a formal program can leave real revenue on the table, can unintentionally leak sensitive data, and can tarnish the corporate brand with the development community. Today, developers and partners expect to be engaged with first class API programs, while businesses expect real insights to know which APIs are profitable and which APIs to bring to market next.

In this webinar, Intel & Mashery outline the baseline enterprise pillars for constructing a first class API program. Learn from CapitalOne how they strategized to build an API program grounded in core business objectives. All attendees will receive a new Mobile API Buyers Guide that presents how to optimize APIs for mobile apps.

About the Speakers

Joshua Greenough personifies the intersection of a team athletics mentality and technology passion. He is currently the Senior Director of Innovation at Capital One, where he manages the product & engineer teams for the San Francisco Innovation Lab. His mission is to build, promote and launch innovative partners on Capital One’s groundbreaking API Platform.

Devon Biondi, Vice President of Strategy Services at Mashery, works closely with Mashery customers advising them in all stages of their API lifecycle from program conception to platform launch. Prior to Mashery she was the Chief of Staff at TIBCO Software where she worked as a strategic advisor to the CEO in all aspects of the company from acquisitions, restructures, new product development, large-scale customer retention and events.

Andy Thurai is Chief Architect and Group CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Mobile, Big Data, 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. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS.

The post Our Next Webinar: Five Practical Steps to Building an Enterprise Class API Program appeared first on Application Security.

I just wanted to send a short note that I will be talking about API Management strategy &  health care data at the Health Refactored conference next week in Mountain View. I’m hoping to learn a lot of and also share Intel’s approach to API management. We’ll have a booth there so please stop by after the talk!

Blake

The post Health 2.0 and API Management appeared first on Application Security.

Visionmobile released a new info-graphic earlier this week that puts some spotlight back on HTML5. While HTML5 is in third place compared to Android and iOS for development and deployment platforms, the most interesting aspect of the survey is the “App Monetisation” panel.

I think the data here confirms what we intuitively already know – if you release your app on more platforms, all things being equal, you will have higher average monthly revenue. This is simply because you can expose your product to a larger unit demand. In other words, the ultimate app is the one that can quickly, easily and cheaply be consumed by users in across all of the walled gardens.

In the case of the survey, the smallest percentage of developers expose their app on 6 platforms but also capture significantly more revenue per month – nearly $5000.  If we flip the discussion around and talk about costs, while it is clear that more platforms equals more revenue, the cost drivers here are going to be significantly higher unless you employ some sort of cross platform toolset, and HTML5/JavaScript seems to fit this bill quite nicely.

What about Enterprises apps? We think that the combination of HTML5 for Enterprise app development coupled with an API gateway forms the basis of a reference architecture for low cost, cross-platform app development but if we tie in this new data from Visionmobile, it seems that independent developers may also have a lot to gain from HTML5/Javascript tools when it comes to putting money into their own pocket. If you missed the webinar on this subject, be sure to check it out here.

Blake

The post All Eyes on HTML5 appeared first on Application Security.

It’s springtime and there is a buzz in the air.  The API Management market place is heating up.  Businesses are seeing the value in exposing data.  In the world of Healthcare IT, the drive to accelerate electronic health record adoption collides with the API trend.  What market sector could benefit more from the cost control and revenue generating benefits of API Management than Healthcare? Exposing healthcare data is the key to driving innovation, reducing costs and generating new revenue streams. Intel Expressway API Manager (EAM) can make it happen.

Innovate

Meaningful Use is pushing for more exposure of clinical data.  If public health records can be made accessible, healthcare can be modernized.  But data must be protected from hackers and made available only to authorized users.  Intel’s API Management solution can secure services, provide threat defense, IaaS cloud scalability, authentication/authorization, data translation and high performance for RESTful APIs access. Intel is working with public health providers to expose patient data.  Intel Expressway Service Gateway brokers the user registration process a third party identity provider (IdP). OAuth tokens ensure that communication with the IdP is authorized.  The IdP generates SAML assertions for NYeC to use to secure subsequent transactions containing patient information.  NYeC’s drive to expose the data is an exciting process to see in motion.

Reduce Cost

EAM provides the data conversion needed to transform legacy web services to RESTful services.  Data transformation features enable XML to JSON and with Informatica’s potent data transformation services embedded in Expressway, HL7 V2 can be converted to mobile ready formats. Once the services are made available, the cost savings can be even greater. APIs enable self-service and fast to market application development. In the US, healthcare costs make up the largest component of the National budget and the numbers are still growing.  API Management for healthcare services can be a factor in controlling spending in this sector.

http://www.usgovernmentspending.com/health_care_budget_2010_1.html

Generate Revenue

Removing patient specific data from the clinical information adds another layer of security. Deidentification can be achieved as part of the API Management process by encrypting the Personally Identifiable Information (PII). EAM provides powerful format preserving PII tools provided that will hide the PII from public view.  With anonymous healthcare data, the possibilities for innovation expand. Consider Aetna’s CarePass Developer Portal (powered by Mashery).  Healthcare APIs are available from Walgreens allowing mobile access to prescription refills, NutritionIx and Food Care are exposing nutrition data to power health and diet applications and Good Rx lists web services that help you find the lowest price for a pharmaceutical.  Imagine how the provider of these healthcare APIs can take advantage of the developer community to create applications that will drive new revenue.  The New York Times, Flixter and Netflix have shown what a good API strategy can do for growing business. The same revenue models can be applied to HIE. APIs allow for easy partnering EHRs with insurance providers, Physician groups with pharmacies, Patient portals with health clubs, HIE’s with labs and more.  Follow the HIE standards, securely expose the data and, as they say in API terms, Mash ‘em up!

Healthcare data exposed as APIs makes businesses sense for the healthcare industry.  The innovation that results from increased exposure of patient and clinical analysis data will generate new revenues beyond the short term bonuses from meaningful use incentives.  The changes that can come from simplifying healthcare for mobility can feed more data into decision support and can make API Management a big factor in improving patient outcomes. Join us at Health:Refactored in Mountain View, May 13-14, and see Intel Expressway API Manager in action with a case study from Blue Cross Blue Shield Association.

Resources

Read the Intel Expressway API Manager data sheet

The post API Management for Healthcare appeared first on Application Security.

Last year the Open Data Center Alliance published an excellent whitepaper that defined the concept of “cloud-aware” applications.  The ODCA paper sets forth the following recommendations:

1. Everything is a Service
2. Use RESTful APIs
3. Separate Compute and Persistence
4. Design for Failure
5. Architect for Resilience
6. Operationalize Everything
7. Security at Every Layer

I will likely revisit these concepts in future posts, but in this post I want to highlight how our multi-datacenter tokenization function can help to build PCI-compliant applications that are cloud-aware, hitting points 4, 5, and 7 above.  This is because we designed our tokenization broker as a cloud-aware application with built-in intelligence to work across disparate networks and datacenters while maintaining a low cost proxy implementation model.

 What is Tokenization?

For the uninitiated, tokenization is the process that removes personally-identifiable information (PII) or any PAN (primary account number) from a record, replacing it with an encrypted, randomized, or hashed object (or “token”) that represents the PII.  The token-to-PII mapping is stored in a separate, highly-secured database, which has the added benefit of simplifying the audit process for the custodian of the data.  The token itself is meaningless, requiring a detokenization function to extract the original, cleartext data.

A token is therefore only usable in limited contexts, compartmentalizing risk if it is compromised.  In layman’s terms, if someone steals my credit card number they can use it to make purchases anywhere until the card is canceled, but if they get the token that represents my credit card then the data is useless.  Tokenization is a best practice used to protect credit card numbers, social security numbers, and even names and addresses (for example in Personal Health Records).  It provides added security at the data layer, ensuring that customer data remains secure even if a transaction database is compromised. Tokenization also has unique applications for PCI compliance. Aside from security, tokenized credit card numbers enjoy reduced PCI scope in most cases, driving down business costs.

Why Multi-DC?

There are many reasons for an application to span data centers.  The most common reasons are to improve availability and performance (I touched on elastic scaling of APIs in an earlier blog).  Also, multiple datacenters are often an outgrowth of business expansion as traditional organizations grow into new business models utilizing public, private or hybrid clouds.

To improve availability, many applications are deployed to different availability zones within a region.  This allows multiple instances of an application (or API) to run in parallel, with the ability to route around failures all the way up to the data center level (design for failure; architect for resilience).  Performance can be improved by adding additional regions (for example, east coast and west coast) to reduce latency between the user and the application.

There may also be business process drivers for multiple data centers.  Consider, for example, a retailer with a both online and brick-and-mortar businesses.  These two channels may be run from different data centers, headquartered in different cities.  However, customer satisfaction depends on being able to buy an item online and return or exchange it in store, and may even support in-store purchases being returned via the online channel.  This requires transaction information to be visible to both channels.  While this could be handled by calling out to the other channel’s API, the best customer experience will be delivered by recognizing a customer as a single entity across both channels, regardless of where that customer originated.  To do this, the retailer may have a single customer database that spans its brick & mortar and online data centers.

 Multi-DC Tokenization

Since tokens uniquely identify data, it is critical that there is a one-to-one mapping between the tokens and the data they represent.  This effectively requires all participating data centers to agree upon roles for the tokenization process. This would seem to be at odds with the eventual consistency model I described earlier in this post. However, the importance of avoiding collisions or duplications in the tokenization process dictates that this state be shared and carefully coordinated across all sites with adequate performance and resiliency in the face of datacenter downtime.

Our approach relies on a combination of PAN partitioning and a distributed secure vault.

When a new request comes in, we route the request to the appropriate data center based on the PAN range.  The authoritative DC computes the token, returns it (via API), and stores the result in our distributed secure vault.  Subsequent references of the token can then be performed at any data center, once the secure vault synchronizes state, which happens nearly instantly (modulo network latency). On the off chance that the application attempts a read-after-write (i.e. detokenization request a few milliseconds after the tokenization request), it is possible that the secure vault will not yet be in sync – anticipating that, we will retry a failed request at the authoritative DC for the token.

By managing this shared token state independently of the application, the developer can treat the tokenization process as a black box. Data can be tokenized from nearly any source over any protocol and PAN data is extracted using common regular expressions or XPath at the application level. No SDKs or application changes are needed. The persistence state is effectively decoupled from compute, and the application’s business logic can be written as if it were a stateless app.  This reduces overhead that goes along with planning and testing for collisions, race conditions, and other corner cases, allowing the developer to spend more time focusing on their core business logic.

Summary

Multi-DC tokenization is a good use of the facade proxy pattern for API security.  Like our touchless Hadoop security, it allows an application to be secured without being modified.  APIs run in the cloud (for that matter, APIs run the cloud) — and thus they need to be cloud-aware.  Building all of that support into each application requires significant effort.  The proxy façade pattern allows developers to focus on their core business – the differentiating features – rather than investing time creating and maintaining non-differentiating capabilities.  With Expressway Token Broker’s cloud-aware tokenization, we manage your distributed token state so you don’t have to.

Resources

• Buyer’s Guide: Tokenization for PCI-DSS
• QSA Assessor’s Guide

The post Cloud-Aware Tokenization: Helping to Build PCI-Compliant Applications in the Cloud appeared first on Application Security.

The  continuing transformation of the IT industry around the externalization of  service components constitutes an exercise in abstraction.  The transformation assumes that any IT  application can be recursively decomposed into constituent services.  An application that has been re-architected  or engineered this way is known as a composite  application.

As with  any abstraction exercise, the devil is in the details.  When a particular capability is to be  replaced with a service, just as good is not sufficient to trigger change; it  needs to be much better to make the change justifiable from a business  perspective, anywhere from 3X to 10X to overcome the change hysteresis or the  incumbent alternative stays.

One  challenge is that in many cases there is no tradition in the organization of  measuring service components.  For  instance if a replacement service is said to be more energy efficient and it  comes with the metrics to prove it, these numbers are not useful if the contracting organization does not keep energy consumption statistics at the level of  granularity of the service offering: if the available historical data is at the  power distribution unit (PDU) level measuring consumption at the rack or even  row level, this information is of little use if the unit of delivery for a  service is a virtual machine (VM) and the provider furnishes energy data on a  per VM basis.

The  semantic gap between VM power and PDU power could be in principle bridged by  aggregating VM power into rack power.  However doing so would require significant research and would difficult  to do without industry consensus because the actual numbers would be dependent  on the measurement method.

One of the most  obvious metrics for a service is pricing.  For instance one could use the total cost of ownership (TCO) of a  storage appliance to derive a cost per byte over the lifetime of the  appliance.  This number can be compared  with the cost of a cloud storage service offering.  The cost of the service may be accrued on a  monthly basis, where the cost of the appliance comes in a big chunk of  petabytes over the 3 to 5-year lifetime of the appliance.  This suggests that there are more dimensions  in the process of making a decision between doing nothing or breaking up the  application into service components and start factoring out these components,  SOA style or externalizing the components through cloud service providers.  What are these dimensions?  Let’s explore a few.

Performance and Quality  of Service

Assuming that a prospective service alternative passes the  cost test the IT organization will look at performance.  It will be of little consolation if a service offering saves money if the quality of service (QoS) deteriorates to the point  that complains pile up.  The expectation  is that service offerings tend to be remote and hence result in higher latency  due to distance and lower bandwidth due to network limitations.  A cloud bursting solution may be implemented via a VPN link to remote resources offered by a service provider.  This link is a potential weakness, inducing a “tromboning” or barbell effect with two large resources connected through a  relatively thin tether, resulting in large latencies between entities connected  across the tether.

Performance deserves a careful consideration because  performance behaviors tend to be highly discontinuous.  For instance, if a service offering doubles storage latency, this may trigger transaction timeouts.  Because of the transaction retries, the  actual latencies experienced by the end users served by the IT organization may  not just double, but increase by an order of magnitude.   On the other hand, a global company  replacing a centralized database location with storage from a provider may  actually end up with improved QoS if  the provider caches and mirrors the data in the appropriate locations.

Another dimension of performance is scalability.  In the industry cloud computing is economically feasible because of specialization: the assumption is that one  entity able to fulfill a specific function on behalf of a community of service customers more efficiently than each customer separately through resource pooling and specialized expertise.  Therefore the service provider can deliver the function at a lower cost than the in-sourced alternative enough and still make a profit to stay in business.  The size of the pooled resources needs to be larger than the largest request expected from any of the customers; otherwise there will be cases where the provider will not be able to honor a request.

Security

Security is a first order concern on par with performance and cost.  It relates to preserving the privacy and integrity of the data and governance, risk and compliance (GRC) practices.  Security is often cited as a roadblock to cloud adoption in the industry. An approach to addressing this conundrum is to look at the problem as a continuum, not as a black or white issue and to look at capabilities available today.  Different application deployment models have different levels of security associated with them.  A classification of infrastructure deployment from the most to least secure could be as follows:

1)      Corporate assets deployed in corporate infrastructure

2)      Private cloud on corporate premises

3)      Provider hosted private clouds

4)      Public clouds

One solution to improve cloud security outcomes while minimizing cost is to define different types of data and institute a policy for the deployment of the data.  One example would be to have company secrets under #1, corporate e-mail stores under #2, CRM data under #3 and product brochures under #4.

IT and Business Process Standardization

This is a big one.  One  of the purposes of an ESB is to ensure there are commonly enterprise-wide procedures (“patterns” in SOA speak) for functions such as pub-sub and event notification.  For a single enterprise a single, company-wide proprietary ESB implementation, either cobbled up in-house or from a single vendor is a workable solution.  Extending this notion across multiple companies and providers is much harder. Arguably cloud computing is still an
emerging discipline with the standards to enable these capabilities not yet in place.

Even the simpler problem of moving a workload from one hypervisor environment is currently a nontrivial undertaking.  The author had the privilege of serving as an architect for a proof of concept exercise sponsored by T-Systems.  The goal of the exercise was to demonstrate the ability of moving virtual machines across hypervisor environments using publicly available conversion tools.  This was a straight implementation of the VM Interoperability Usage Model as defined by the Open Data Center Alliance.  We used four of the most well-known hypervisor environments. We found roadblocks across
most conversion paths.  Moving VMs to public cloud providers posed additional challenges because of the degree of para-virtualization or customization in public vendors’ hypervisor environments.

Metaservices

In addition to the intrinsic functional capabilities implemented by servicelets, composite applications need a number of ancillary capabilities: service customers need to find them.  A service registry would allow service provider to publish their offerings and users to discover, assess and bind the
service offerings to their applications.

Another metaservice is data encryption and transformation: data needs to be striped, replicated, compressed, encrypted and replicated to meet target quality criteria.  On the business side reliable, non-repudiable mechanisms for billing and cost settlement that work across composite applications.  For some customers the ability to do audit trails or even cloud forensics is a must have feature.  Unfortunately the state of the art leaves much to be desired, as panelists declared at a recent RSA Conference.

Epilog

In the next installment we’ll take a look at how Intel® Expressway API Manager and Intel® Expressway Service Gateway offer brokerage, discovery and security services as a present day embodiment of an ESB.  In so doing API management addresses some of the challenges for the implementation and deployment of composite applications mentioned above, not just for a single enterprise, but for whole ecosystems comprising both developers and end user communities.

The post From ESBs to API Portals: an Evolutionary Journey Part 4 appeared first on Application Security.

Over the next several posts, I will explore some of the core patterns for Service Gateways that provide access to Enterprise Mobile Applications that need to leverage enterprise apps and data. Before I go there – a word about risk. Mobile security is a hot topic. Is Android less secure than iOS? What about rooted devices? How should enterprise deal with BYOD? How do mobile dev teams write secure code for mobile platforms? And the list goes on and on, there are plenty of important questions to ask.

Amidst all these gnarly big and small questions on technical security for enterprise mobile applications. its vital to remain focused on risk. And where is the risk for enterprise mobile applications? On the apps, identity, and data housed on the numerous mobile devices? Sure. There’s risk on individual mobile apps and devices, but the lion’s share of data, functionality and identity is on the server side, and that’s where the lion’s share of the risk is too.

Boundary crossings are a key focus area for security architects. The Enterprise Service Gateway defines the boundary between “external” systems and “internal” systems (note – I am not sold that this is a valid distinction in many instances but its commonly used and holds up for the purposes of this pattern). The transition between external and internal confronts the security architect with a number of design choices. We can divide the message exchanges into two sets

1. Mobile device -> Gateway: asynchronous Web service calls via REST

2. Service Gateway -> Enterprise backend app servers: synchronous and asynchronous calls via REST, JMS, SOAP, and more

The inbound calls to the Service Gateway usually follow a simple message exchange pattern (albeit its asynchronous which is something new to many enterprises but we’ll save that for another day), whereas the Gateway -> Enterprise message exchange patterns can run the gamut. In effect, the external services simplify the experience for the user and the internal services- well they just go where the data is.

The implications here shed light on the core utility of the gateway. The gateway is the location to implement three sets of security policies.

1. External security policy: for the Mobile device -> Service Gateway message exchanges

2. Internal security policy: for the Service Gateway -> Enterprise backend message exchanges

3. External <-> Internal mapper security policy: to facilitate the right security and identity services for each boundary transition

Security is about reducing vulnerabilities (access control services) and coping with threats (hardening, defensive services).  Service Gateways play a key role in each.

In the case of access control and identity services, the identity protocols and tokens that are used by the mobile device are usually validated and terminated at the gateway. The gateway then maps the relevant user identity, such as username and attributes, and instantiates a second protocol to communicate with the enterprise backend.

In the case of defensive services, enterprise applications are not hardened for external access, after all that’s why there is a DMZ. Inbound calls, messages, and data must be inspected for malicious code targeting the enterprise.  In effect the Service Gateway is what enables the internal services to be consumed externally.

To make sure mobile security is effective, from a big picture, strategic perspective its important to keep in mind the vital role of the gateway in managing risk on both the mobile device and the enterprise backend. To execute tactically its important to divide the Gateway’s role in to how it works for each separate policy zone, and how it maps between the zones.  So many projects, start out assuming that mobile is just another front end to hook up to existing middle tiers – it isn’t. To get an idea on some key differences, I highly recommend this Mobile Middleware White Paper as a solid read for more on the subject.  In the next post we’ll look at some policy options for each zone.

The post Betwixt and Between – Service Gateway for Enterprise Mobile Applications appeared first on Application Security.

Tokenization is a major trend in application and data security and Gateways are an ideal location to deploy tokenization services. Tokenization replaces sensitive data with benign data. The classic example here is PCI DSS, and the business value of tokenization is summed up here:

Now I am no graphic designer, but let me take advantage of the Chinese saying that “1,001 words is worth more than a picture.” As much as I like the graphic above it does not tell the whole story. The 2/3 of the graphic starting from the left is “PCI Scope”, the 1/3 on the right is outside PCI scope. In my experience the value of tokenization and gateways is that its more like 10-20% of the system is isolated down to in scope for PCI and the remaining 80-90% is “out of PCI scope” – *this* is the value of tokenization – it abstracts away a ton of complexity. As we discussed in the last post, complexity is the main enemy for security people. Tokenization services are a good way to not eliminate but massively reduce the sprawl of sensitive data and in doing so reduces the burden of complexity across the system because the rest of the system isn’t dragged into scope.

The reality is that most of the system does not need to access sensitive data such as payment information, it only needs to be able to reference authorization codes and the like. There are so many ways to mess up code that simply removing the sensitive data in as many places as possible is frequently the single most effective security mechanism. To quote Ken Thompson, “when in doubt use brute force.” What’s simpler – A) exhaustive audits, quarterly vulnerability assessments, section 10 level audit logging, and the full compliance check box olympics across your whole systems or B) brute force – isolate sensitive data, audit that island and expose only tokens and authorization codes to the rest? Its not even close.

The counterargument to the above is that a gateway introduces a new layer in the system and so its another middleboxen for the app server to talk to, another system on the critical path. Fair enough, but its there for a reason same as the app server is in the middle tier. The appserver is in the middle tier so that business logic and rules are centralized and reused. This is the same rationale for tokenization on a gateway – centralize the token generation and verification. Do you want all your developers writing code for generating and verifying tokens? Not bloody likely.

Tokenization is a major trend in security because it allows systems to reduce the sprawl of sensitive data and the attendant vulnerability and audit issues. Gateways are the ideal way to deploy tokenization because

1) the internal core operations of token generation and verification are too important to be left to individual developers. They are generic enough that they can be reused.

2) the external interfaces to the tokenization servicess- generate token and verify a token – are very simple

This is a mix that solves important security problem in a simple way and in a way that scales. Frankly there are not too many times in security architecture where this is the case and that makes tokenization on gateways is a design pattern for the long haul.

The post Complexity Management with Tokenization appeared first on Application Security.

So, here are some questions that have been on my mind lately:

• How can Enterprises reduce cost drivers for mobile enablement?
• Can APIs and HTML5 provide the basis for a long term mobile strategy?
• Can Enterprises avoid lock-in with mobile walled gardens? Should they? Why?
• What would the architecture look like?

If you are interested in exploring some of these topics,please join me and my colleagues later this week for a webinar at SC World Congress eSymposium. Hope to see you there!

Blake

The post HTML5 and API Gateways appeared first on Application Security.

A few weeks ago I blogged about different Mobile Middleware usage models for enterprise.  Continuing that thread, this post will drill down into API security considerations for enterprise mobile apps.

Mobile applications are typically intended for use outside of the corporate network.  This requires the enterprise to expose APIs and web services to the Internet, where previously they were made inaccessible by the corporate firewall.  While it is a good practice to protect even inward-facing services, the likelihood of a malicious attack is orders of magnitude higher for external-facing APIs.

Even if these services were previously exposed through a web portal, additional security must be considered.  Most modern web portals adopt some variation on the classic three-tier architecture, in which only the presentation tier is exposed to the Internet.  On the other hand, many web services place business logic at the endpoint, exposing the server.  Furthermore, the API server will have access to a database, so a compromised server can lead more directly to data loss.

Classic 3-tier web hosting architecture

A services gateway allows the enterprise to minimize the attack surface for the mobilization program.  Rather than having to protect one or more servers for each external-facing API, the proxy model results in a single server or cluster responding to external traffic.  The actual web services can then be further restricted, only allowing connections to the gateway and to internal systems inside the DMZ or corporate intranet.

Mobile-optimized two-tier hosting model

A variation on this model, illustrated by the figure below, uses a pair of gateways to securely expose internal APIs while eliminating the need for a duplicate instance of the API deployed to the DMZ.  This involves deploying one gateway inside the DMZ and a second gateway inside a secure enclave.  Inbound traffic is permitted to access the first instance, while the second instance only accepts traffic from the first.  It should be noted that this is only feasible with gateways that can be deployed on-premise due to the need to securely host one gateway inside the secure enclave.

Dual-gateway security for Intranet-hosted services

Use of a security gateway also makes it easier to implement and enforce consistent security policies for all APIs.  Instead of adding custom code to each API or tuning each server individually, a consistent set of checks can be performed at the gateway layer.  For example, an enterprise can define a package of checks that includes SQL injection scanning, overflow scanning, and cross-site scripting prevention.

For more on the security and other benefits of the gateway facade, download API Patterns for Cloud and Mobile from CITO Research’s Chief Analyst, Dan Wood (foreword by John Musser of ProgrammableWeb).

The post Mobile Middleware for the Enterprise: API Security Considerations appeared first on Application Security.

In this article series we build the case for API portals, out of which the Intel® Expressway Service Gateway and the Intel® API Manager, powered by Mashery are representative examples, as the contemporary manifestations of the SOA movement that transformed IT in the early 2000s from IT as a cost center to an equal partner in a company’s execution of a business strategy and revenue generation. In the introductory article in Part 1, we discussed some of the business dynamics that led to cloud computing and the service paradigm. In part 2 we took look at the SOA transformation in the big enterprise. Let’s now examine the influence of SOA in small and medium businesses. At a first blush it would appear that only large organizations have the critical mass to a large number of application instances to make reuse under SOA economically justifiable. This is not really the case because of some unintended consequences and fortunately, a happy ending.

Let’s do a brief introduction to small businesses first to establish a context for the discussion. Between large companies and individual consumers lies the vast ecosystem of small and medium business, from mom and pop outfits to sizable companies, but perhaps not yet with global reach, the small and medium businesses or SMBs.

According to the U.S. Small Business Administration, small firms, defined as independent business having fewer than 500 employees, constitute 99.7 percent of all employer firms in the United States. Furthermore, small firms pay more than 42.9 percent of total U.S. private payroll and have created more than half of nonfarm private gross domestic product (GDP). According to the US Small Business Administration, the number of businesses in the United States in 2010 totaled about 27.9 million, out of which only 18,500 are were large firms. In other words, looking at the statistical distribution of all businesses in the United States, there is a long tail represented by SMBs. This long tail has a significant economic impact that cannot be ignored.

By their very nature of SMBs typically do not have a large IT budget, or a large IT department. Many of them have only a few IT literate employees acting as part time IT support. They could not afford the kind of “internal-only” or inside-out SOA adoption model described in Part 2. This fact effectively precludes the conditions under the inside-out SOA model.

However, it turned out that small businesses started partaking of the third party IT services used by large firms. How was this possible? That’s because service oriented IT, with metered, a la carte services enabled the delivery of IT in small, reasonably priced doses. Even a company without the resources to purchase and maintain a backroom server can purchase a cloud backup service for an affordable monthly sum.

Two factors are driving this demand from SMBs: the capital costs for a corporate owned data center, an insurmountable barrier for small firms, is now spread out over a large customer base. The service provider takes care of finding financing for the infrastructure acquisition and converts these costs to a monthly fee. The second factor is that although demand for IT services in any single SMB may be small when compared with a large company the aggregate demand is enormous as evidenced by the US Small Business Administration data, and hence serving the SMB segment can be a profitable endeavor. Companies like N-Able, CoSentry and Dataprise actually target small businesses.

Hosted servers may be an alternative. However if an IT department consists of two or three people, there may not be enough time or expertise to nurse the equipment through the entire life cycle and maintain the applications that run on them.

The dynamic playing out is that if a service can be delivered in small doses, the services used by large firms under the inside out SOA model are just as good for SMBs, and hence third party service providers enjoyed an additional tailwind coming from small businesses.

On the supply side, demand from SMBs represents a significant driver for the IT economy and presents opportunities to software and service developers in the supply chain. On the demand side we can safely claim that the IT economy has effectively reached not just SMBs but individual consumers as well. An individual consumer also follows this service model whenever she downloads a mobile application from the iPhone App Store or from Google Play, installs a Dropbox file hosting instance or activates Windows Skydrive. This practice is so commonplace today that it’s hard to imagine how revolutionary and how recent the concept is. Google Play started in 2012 and the “grandfather” of the app store, iPhone started in 2008. See Figures 1 and 2.

Figure 1.  Web Search Interest for “Google Play”.  Source: Google.

Figure 2.  Web Search Interest for “Apple App Store”.  Source: Google

Figure 3 illustrates the outside-in service integration process where a business application is built out of one or more service components available from a portal such as Intel® API Manager. The central application core described in the previous article that gets smaller as services get outsourced no longer exists. Instead applications are built from third party services, or more appropriately “servicelets” from the ground up.

Figure 3. A Compound Application with no Central Core

Given the “outside-in” potential, we conjectured back in 2008 that SOA would flourish in small organization environments as well. See the book “The Business Value of Enterprise Service Grids”, Intel Press. This prediction came to be, but with a twist: these service components live today in the cloud.

The democratization of SOA has taken a different dynamic: SOA has fled the enterprise and instead of reuse from within, or across organizations in large enterprises, a condition we thought necessary for critical mass for adoption, the critical mass actually happened across whole ecosystems, not just a single enterprise. In the process, these service components are remaking the IT industry and touching service consumers, providers and developers all the same. This dynamic essentially defines the third incarnation of the service ecosystem.

In the book, we proposed a model for SOA deployment that depended on a variety of ecosystem players providing composite applications that are used to build more complex SOA-style composite applications. Today we call these players cloud service providers or CSPs. Under this environment we can expect a degree of specialization where the individual services are provided by smaller players with the appropriate expertise. This situation is illustrated in the figure below.

To distinguish this approach from the traditional “internal only” or “inside-out” approach to SOA specific to large enterprises, we call it outside-in SOA.

The end state is a rich, diverse economic ecosystem with an excellent impedance match between technology and business needs

Who has a vested interest in making the transformation to outside-in SOA take place? It is a truism in an economic ecosystem that the cost equation for some players translates into an identical revenue consideration for another player. The whole ecosystem benefits when the value received greatly exceeds the cost expended for purchasers, and when sellers realize additional demand for products and services because of this value.

Consumers of services stand to gain because of the lower cost overall for procuring application capabilities via composite applications through composite services. SMBs get access to capabilities otherwise they could not afford. Large enterprises and service providers can generate additional cash flow from reduced capital expenses.

Canonical service components, i.e., services designed as services from the ground up, are not essential to make this scheme work. The traditional stovepiped applications in can be retrofitted through middleware shims to behave as composable services, in a manner not unlike screen scraping programs are used to extend the life and usefulness of legacy mainframe applications. The barriers to the outside-in model are lower than they appear at first analysis because the industry does not need to wait until a large repertoire of canonical reusable services becomes available.

The dynamic of this process is that as service economy matures, services will become and will be traded as commodities. This is leading to varying degrees of specialized providers. It simply will be cheaper to build specific functionality by contracting out constituent components in the marketplace rather than build the same functionality wholly in house.

The outside-in approach differs from traditional outsourced arrangements: the negotiation of an outsourced payroll function may involve months and real people at the table. On the other hand, outside-in transactions will be eminently automated, machine to machine and highly dynamic through automated registries and discovery services and using open standards. One such transaction might take from a fraction of a second to no more than a few seconds.

The externalization of service components allowing the quick assembly of applications from third party offerings brings challenges to service providers, developers and consumers alike. We will cover some of these issues in Part 4.

The post From ESBs to API Portals: an Evolutionary Journey Part 3 appeared first on Application Security.

“I have three mailboxes in my office : IN, OUT, and TOO HARD. I was joking with the MIT students that I should have a TOO HARD bin” – Warren Buffett

Even for a great investor like Warren Buffett, most investing ideas wind up in the TOO HARD bin. Investing is a great in that way, where you can pick and choose which problems to tackle. There is no penalty for sitting it out when things are too complicated.

Unfortunately, in security we do not have this luxury. Our dev teams need to ship. Preferably sooner rather than later. Oh, and attackers will be looking for holes from minute one.

Like Warren Buffett’s mailboxes, virtually EVERYTHING that comes into an Information Security team’s inbox is TOO HARD. But unlike investing, we cannot really sit it out and wait for all the planets to align, we have to act.

There is a lot of evidence that information security is TOO HARD. Over the years, there have been plenty of examples of breaches where the victim companies did not do the basics – they did not have a firewall, they did not hash/salt passwords and so on. But nowawdays the victim companies are increasingly doing many things right and still getting hit. Its not a mystery, the design, deployment and operational challenges are hard. What to do?

This brings me to another of my favorite Buffett quotes- “The sign above the players’ entrance to the field at Notre Dame reads ‘Play Like a Champion Today.’ I sometimes joke that the sign at Nebraska reads ‘Remember Your Helmet.’ Charlie and I are ‘Remember Your Helmet’ kind of guys. We like to keep it simple.”

Security is too important to be left to development teams. But integrating security is too hard to be done by the security team alone. We talk constantly about threats and vulnerabilities and 0 day and SQL Injection, but our real problem is complexity management. There are ways to improve our security, but we have to choose wisely and make the things we choose simple enough to deploy.

Keeping it simple starts with ensuring the system has the right structural security pieces in place. For many apps today like Mobile apps this means adding an API security layer. Before getting wound up about the latest and greatest threats, remember your helmet, ensure that your DMZ, Middleware and Data tiers have protection in place, not just at the network layer but at the Application and message data layer too. Its often the case that too much focus on latest and greatest security topics obscures more fundamental issues.

In the Security Gateway Buyer’s Guide, I explored some of the important capabilities that security gateways offer. It’s up to security architects to identify the right mix of security controls and then simplify the model to something that fits in the operational architecture.  Getting the right structural components in place is important because it sets you to deal with a wide range of challenges.

We know security architecture is TOO HARD. We know that whatever we do today won’t be good enough next year, threats are too adaptable and most sotware assets that we protect are not particularly resilient. We cannot predict what the next threats will be, we cannot predict what will be the right identity standard in 2016 (OAuth? SAML? Something some kid at Caltech is cooking up right now?).  But we can say with confidence, we’ll need a place to patch and defend against threats. We’ll need a place to deploy new identity protocols.

Engineering is about embracing constraints. For technical complexity and economic reasons, we simply cannot defend everywhere in the whole system. We have to choose where to locate our stronger defenses.

Boundary crossings are crucial to security, you leave one trust zone and enter a new one. The API layer is a very important boundary, it’s the logical place to drive security controls that can effectively handle application, identity and message data threats and countermeasures. When you are deploying Web, Cloud, and Mobile apps, remember this boundary. Remember your API Security.

The post Remember Your Helmet appeared first on Application Security.

Emphatic excitement is how I felt when I saw this news from the hotel technology trade association, also known as HTNG. The idea of deleting data for compliance scope is certainly not new, but the key idea that HTNG discovered is to delete data as early as possible as soon as it enters the organization’s data-center and they’ve defined something called the Payment Information Proxy (PIP) in their framework that does precisely this.

In fact, we’ve been recommending this approach to retailers for some time now, the idea being to capture PAN data in an HTTP POST when it first hits the environment to reduce compliance exposure.

In their Secure Payments Framework for Hospitality, they describe the PIP data flow quite precisely. It certainly looks like a good fit for proxy tokenization and will be something Intel(R) Expressway Tokenization Broker looks to be ideally suited for.

The post The move towards proxy tokenization – first retailers, now hotels appeared first on Application Security.

KuppingerCole analyst Craig Burton (of Burton Group originally) wrote a recent article about Façade proxies. You can read the article here: http://blogs.kuppingercole.com/burton/2013/03/18/the-faade-proxy/

As Craig notes,

“A Façade is an object that provides simple access to complex – or external – functionality. It might be used to group together several methods into a single one, to abstract a very complex method into several simple calls or, more generically, to decouple two pieces of code where there’s a strong dependency of one over the other. By writing a Façade with the single responsibility of interacting with the external Web service, you can defend your code from external changes. Now, whenever the API changes, all you have to do is update your Façade. Your internal application code will remain untouched.”

I call this “Touchless Proxy”. We have been doing the touchless gateway for over a decade, and now using the same underlying concept, we provide touchless API gateway or a façade proxy.

While Intel is highlighted in a strong note in this analyst note by KuppingerCole, Craig raises the following point:

“When data leaves any school, healthcare provider, financial services or government office, the presence of sensitive data is always a concern.”

This is especially timely as the healthcare providers, financial institutions, and educational institutions rush to expose their data using APIs to their partners.

When we were designing our API management platform that is one of the things we had in mind – Providing a context aware data protection. I wrote an article a few months ago about this, which you can read here. Essentially, not only Intel API solution can detect the sensitive data flowing through the APIs, but it can take action based on the identity, location, invocation and context of the requesting party. This is essentially important as we connect all IoTs (Internet of Things) and have M2M take over the enterprise. You can sense the PCI, PII and other sensitive data, using our Token Broker (ETB) complimentary solution to Intel API Manager, and you can choose to either tokenize the data (the original data will be stored in a secure vault of your choice and location), encrypt the data, or provide a Format Preserving Encryption (FPE) that will allow you to encrypt the data yet maintain the original format of the data.

Check out cloudsecurity.intel.com for more details.

The post The Façade Proxy appeared first on Application Security.

I am speaking at the SC World eConference this Wednesday (12:25 PM – 01:05 PM) with our customer WestJet on PCI Compliance/ Cloud Data Privacy issues. You can register at the link below. It is free. Plus you earn CPE credits! Attend the session to hear the WestJet use case on how they used Intel solution to get PCI compliant quickly without a long drawn IT engagement.

You can register here: http://tiny.cc/5p15tw

The post PCI / Cloud Data Privacy webinar – Wednesday Mar/20 @ 12:25 pm appeared first on Application Security.

The DMZ is a Web app security architecture workhorse. The DMZ operates under a different ruleset both in terms of what is allowed and in terms of the level scrutiny design, deployment and operations get. To the extent Web security works at all, its due in no small part to the isolation the DMZ provides.

The DMZ concept has lived on in the Web services world primarily through Web services gateways which limit Web Services attack surface, help developers navigate byzantine security protocols, and facilitates inbound and outbound app monitoring.

Here we are in the first or second inning of Mobile apps, will the DMZ still play a role? I think the answer is a resounding yes. The DMZ will continue to serve an important role but the nature of the role and the capabilities will adapt for Mobile apps. I think the DMZ still plays a role and is supported by the Web Service Gateway, but in addition expect to see increased deployments of API Security & Management layers to handle some front facing tasks

For Mobile Secuirty architetcure I expect each layer in the DMZ to handle similar responsbilities as they have to this point but to take on additional responsibilties with a mobile flavor.

Identity is the new perimeter, and so Identity and Access Management is a core problem at the DMZ. There is a clear need to support different token types and different protocols for mobile apps. OAuth and OpenID Connect are two of the most important here, but importantly its not just session cookies, the type ot identity token and protocol will change and so will how they are used. The session length is longer and there are local client based access control decisions to be made. The Mobile DMZ must have a way to enforce security policy for apps and data over asynchronous protocols.

In addition the access control protocol is often not just a client –> server, the security architect must account for the app developer who gets access via an API. The Mobile DMZ must have a way to issue, validate and refresh developer keys.

The Mobile DMZ serves an important function in providing defensive service, limiting what the app has access to and monitoring that access.Two additonal responsbilities include dealing with Lost/Stolen aka Remote Wipe. Many enterprises look to MDM here and that plays a role but does not help much on consumer facing applications. Client side data is often encrypted and here the Mobile DMZ is very likely involved to provision keys.

The DMZ is really about managing enterprise risk – publishing some data and functionality, while limiting the downside. This delicate balance is a result of the tension of push by development organzations and security’s job to ensure prudent measures are taken to manage the risks. API Curation is an important step ring fencing the scope of the enterprise mobile interface.

To support these activities new organizational roles must be fostered including the Service Admin and API Developer role. The Service admin readies the backend enterprise services to be published. The API Developer builds content on top of them. In addition security architects and app developers must factor in how to collaborate with these folks to ensure a clear chain of responsibility – who does what. For example, the Service Admin can instrument policies for security, measurement and monitoring, but the API developer is responsible to develop the front end. Understanding what is published and how to safely use the services is key.

So I think the DMZ is here to stay, I expect the some changes, some structural, some subtle. The structural change is the decoupling of the front facing part of the DMZ to API Security and management systems with the back end enterprise gateway served up by Service Gateways. Its still early days in mobile in general and mobile secuirty in particular but I think this shift already under way.

The post What Comprises a Mobile DMZ? appeared first on Application Security.

Hackathons help you explain APIs to developers. But, do you know who you should be really selling the value of your APIs to? It goes way beyond the developers and IT operational folks. Who do you think it is ……CIO, CTO, CSO or someone else? You will be surprised. Read my article on ProgrammableWeb for more details.

http://blog.programmableweb.com/2013/03/11/is-the-cmo-now-the-chief-api-officer/

Watch out for my API strategy article series soon to be published.  For more information, check out our API management solutions.

The post Chief API Officer appeared first on Application Security.

In this article series we would like to build a case that API portals, with the Intel® API Manager and Intel® Expressway Service Gateway, powered by Mashery are representative examples, are the contemporary manifestations of the SOA movement that transformed IT in the early 2000s from IT as a cost center to an equal partner in a company’s  execution of a business strategy and revenue generation.  In the introductory article in Part 1 we discussed some of the business dynamics that led to cloud computing and the service  paradigm.  Let’s now take a closer look  at the SOA transformation in the big enterprise.

If we look at the Google  Webtrends graph for the term “SOA”, we can use the search popularity as an  indicator of the industry we can see that the interest in SOA peaked at around  2007, just as the interest on cloud computing started rising.  There was a brief burst of interest on this term at the end of 2012 which can be attributed at people looking for precedents in SOA as the industry moves to cloud services.

Figure 1. Google Webtrends graph for “SOA.”

Figure 2. Google Webtrends graph for “Cloud Computing.

The search rate for the term “cloud computing” actually peaked in 2011, but perhaps unlike SOA, the trend is not an indication of waning interest, but that the focus of interest has shifted to more specific aspects. See for instance the graphs for “Amazon AWS” and “OpenStack”.

Figure 3. Google Webtrends graph for “Amazon AWS.”

Figure 4. Google Webtrends graph for “OpenStack.”

SOA brought a discipline of  modularity that has been well known in the software engineering community for more than 30 years, but had been little applied in corporate-wide IT  projects.  The desired goal for SOA was  to attain a structural cost reduction in the delivery of IT services through  re-use and standardization.  These savings needed to be weighed against significant upfront costs for architecture and planning as well as from the reengineering effort for interoperability and security.  The expectation was a per  instance lower cost from reuse in spite of the required initial investment.

Traditionally, corporate applications have been deployed in stovepipes, as illustrated in Figure 5 below, one application per server or server tier hosting a complete solution stack.  Ironically, this trend was facilitated by the availability of low-cost Intel-based high volume servers starting fifteen years ago.  Under this system physical servers need to be procured, a process that takes anywhere from two weeks to six months depending on organizational policies and asset approvals in effect.  When the servers become available, they need to be configured and provisioned with an operating system, database software, middleware and the application. Multiple pipes are actually needed to support a running business.  For instance, Intel IT requires as many as 15 staging stovepipes to phase in an upgrade for the Enterprise Resource Planning (ERP) SAP application.  The large number of machines needed to support most any corporate application over its life cycle led to the condition affectionately called “server sprawl.”  In data centers housing thousands if not tens of thousands of servers it is not difficult to lose track of these assets, especially after project and staff turnover from repeated reorganizations and M&As.  This created another affectionate term: “zombies.”  These are forgotten servers from projects past, still powered up, and even running an application, but serving no business purpose.

Figure 5. Traditional Application Stovepipes vs. SOA.

With SOA, monolithic applications are broken into reusable, fungible services as shown on the left side of Figure 6 below.  Much in the same way server sprawl used to exist in data centers, so it was with software, with multiple copies deployed, burdening IT organizations with possibly unnecessary licensing costs, or even worse, with shelfware, that is, licenses paid for software never used.  As an example, in a stovepiped environment each application that requires the employee roster of a company, namely user accounts, phone directory, expense reporting, payroll would each require a full copy of the employee information database.  In addition to the expense of the extra copies, the logistics of keeping each copy synchronized would be complex.

What if instead the need to replicate the employee roster somehow it was possible to build a single copy where every application needing this information can “plug in” into this copy and use it a needed.  There are some complications: the appropriate access and security mechanisms need to be in place.  Locking mechanisms for updates need to be implemented to ensure integrity and consistency of the data.  However the expense of habilitating the database for concurrent access is still significantly less than the expense of maintaining several copies.

If we access this new single-copy employee database through Web Services technology, using either SOAP or REST, we have just created a “service”, the “employee roster service”.  If every application layer in a stack is
re-engineered as a service with possibly multiple users, the stacks in Figure 5 morph into a network as shown in the left part of Figure 6. The notion of service is recursive where most applications become composites of several services and services themselves are composites of services.  Any service can be n “application” if it exposes a user interface (UI) or a service proper if it exposes an API.  In fact a service can be both, exposing multiple UIs and APIs depending on the intended audience or target application: it is possible to have one API for corporate access and yet another one available to third party developers of mobile applications.

Applications structured to operate under this new service paradigm are said to follow a service oriented architecture, commonly known as SOA.  The transition to SOA created new sets of dynamics whose effects are still triggering change today.  For one thing, services are loosely coupled, meaning that as long as the terms of the service contract between the service consumer and the service provider does not change, one service instance can be easily replaced. This feature simplifies the logistics of deploying applications enormously: a service can be easily replaced to improve quality, or ganged together with a similar service to increase performance or throughput.  Essentially applications can be assembled from services as part of operational procedures.  This concept is called “late binding” of application components.

Historically binding requirements have been loosened up over time.  In earlier times most applications components had to be bound together at compile time.  This was really early binding.  Over time it became possible to combine precompiled modules using a linker tool and precompiled libraries.  With dynamically linked libraries it became possible to bind together binary objects at run time.  However this operation had to be done within a given operating system, and allowed only within strict version or release limits.

We can expect even more dynamic applications in the near future.  For instance, it is not hard to imagine self-configuring applications assembled on the fly and real time on demand using a predefined template.  In theory these applications could recreate themselves in any geographic region using locally sourced service components.

There are also business considerations driving the transformation dynamics of application components. Business organizations are subject to both headcount and budgetary constraints for capital expenses.  Under these restrictions it may be easier for an organization to convert labor and capital costs into monthly operational expenses by running their services on third party machines hiring Infrastructure as a Service (IaaS) cloud services, or take one step further and contract out the complete database package to implement the employee roster directly from a Software as a Service (SaaS) provider.  All kinds of variations are possible: the software service may be hosted on infrastructure from yet another party, contracted by either the SaaS provider or the end user organization.

The effect of the execution of this strategy is the externalization of some of the services as shown in the right hand side of Figure 6.  We call this type of evolution inside-out SOA where initially in-sourced service components get increasingly outsourced.

Figure 6. The transition from internal SOA to inside-out SOA.

As with any new approach, SOA transformation required an upfront investment, including the cost of reengineering the applications and breaking them up into service components, and in ensuring that new applications themselves or new capabilities were service ready or service capable.  The latter usually meant attaching an API to an application to make the application usable as a component for a higher-level application.

Implementation teams found the extra work under the SOA discipline disruptive and distracting.  Project participants resented the fact that while this extra work is for the “greater good” of the organization, it was not directly aligned with the goals of the project.  This is part of the cultural and behavioral aspects that a SOA program needs to deal with, which can be more difficult to orchestrate than the SOA technology itself. Most enterprises that took a long term approach and persisted in these efforts eventually reached a breakeven point where the extra implementation cost of a given project was balanced by the savings by reusing past projects.

This early experience also had another beneficial side effect that would pave the way to the adoption of cloud computing a few years later: the development of a data-driven, management by numbers ethic demanding quantifiable QoS and a priori service contracts also known as SLAs or service level agreements.

While the inside-out transformation just described had a significant impact in the architecture of enterprise IT, the demand for third party service components had an even greater economic impact on the IT industry as a whole, leading to the creation of new supply chains and with these supply chains, new business models.

Large companies, such as Netflix, Best Buy, Expedia, Dun & Bradstreet and The New York Times found that the inside-out transformative process was actually a two-way street.  These early adopters found that making applications
“composable” went beyond saving money; it actually helped them make money through the enablement of new revenue streams: the data and intellectual property that benefited internal corporate departments was also useful to external parties if not more.  For instance an entrepreneur providing a travel service to a corporate customer did not have to start from ground zero and making the large investment to establish a travel reservation system.  It was a lot simpler to link up to an established service such as Expedia.  In fact, for this upstart did not have to be bound by a single service: at this level it makes more economic sense to leverage a portfolio of services, in which case the value added of this service upstart is in finding the best choices from the portfolio.  This is a common pattern in product search services whose function is to find the lowest price across multiple stores, or in the case of a travel service, the lowest priced airfare.

The facilitation of the flow of information was another change agent for the industry.  There was no place to hide.  A very visible example is effect of these dynamics on the airline industry, and how it changed irrevocably, bringing up new efficiencies but also significant disruption.  The change empowered consumers, and some occupations such as travel agents and car salespeople were severely impacted.

Another trend that underlies the IT industry transformation around services is the “democratization” of the services themselves: The cost efficiencies gained not only lowered the cost of business for some expensive applications accessible only to large corporations with deep pockets; it made these applications affordable to smaller businesses, the market segment known as SMBs or Small and Medium Businesses.  The economic impact of this trend has been enormous, although hard to measure as it is still in process.  A third wave has already started, which is the industry’s ability to reduce the quantum for the delivery of IT services to make it affordable to individual consumers. This includes social media, as well as more traditional services such as email and storage services such as Dropbox. We will take a look at SMBs in Part 3.

The post From ESBs to API Portals, an Evolutionary Journey Part 2 appeared first on Application Security.

Intel Expressway Service Gateway and RSA DPM: Security without pain

Top security threats for 2013 include “hacktivism” attacks, botnet malware, distributed denial of service attacks, and identity theft. The problems are well known and yet there is still resistance to spending the capital on prevention measures. Intel® Expressway Service Gateway (ESG) and RSA Data Protection Manager (DPM) have partnered to provide a painless way to protect web services and sensitive data from threats.

The beauty of the solution is that existing services do not need to be modified. Service delivery of tokenization and key management is abstracted, secured and simplified. The Expressway Service Gateway provides features made to integrate, mediate, secure, and scale services in a dynamically changing Enterprise application perimeter that may include multiple security domains. Once deployed to the network edge in a software or hardware form factor, our service gateway combined with the DPM can safely expose existing REST APIs or SOAP web services. High speed data mediation capabilities for XML, JSON, binary, and legacy data enable existing web services to be exposed as REST APIs to meet growing mobile service demands.

Tokenization in the Expressway Service Gateway

When acting as a tokenization solution, ESG in conjunction with DPM can provide PCI Compliance through the configuration of a proxy tokenization and detokenization service. This configuration provides security without modification to existing services. Data is proxied through the service gateway and tokenized before it reaches existing services. All systems behind ESG are out of scope since PAN data never reaches them, only the tokenized data. In reverse, when data needs to be transmitted out with the original PAN data it can be securely proxied through the service gateway and the tokens are replaced with the original PANs. ESG supports a wide range of protocols, HTTP(S), JMS, IBM MQ, FTP(S), FILE, SFTP, RAW TCP/IP(S), and CUSTOM which allows it to handle the various types of traffic that needs to be tokenized/detokenized on the way in and out of a customer’s data center.

For retail applications, PCI Compliance can be achieved by intercepting url-encoded web requests containing PAN data, tokenizing and forwarding to the existing backend with no change needed to the back-end service. Bulk tokenization requests, transmitted over SFTP, can be proxied to allow for tokenization. ESG can batch large requests to run in parallel in order to optimize performance. The concepts applied to PAN data also work to secure patient health information (PHI) for healthcare applications.

Data Encryption Services

When working in conjunction with DPM for key management operations, ESG acts as a secure proxy gateway to sign/verify/encrypt/decrypt data as it enters or leaves a customer’s Data Center. The advantage here is that customers do not need to modify existing services to gain this functionality. It also allows larger amounts of data to be encrypted vs. smaller PAN credit card type numbers. It is extremely flexible and desired key and Token behavior can be set to each application needs. The data center encrypt/decrypt/sign/verify use case can be applied to cloud applications too. Requests to store data in the cloud can be intercepted and encrypted/decrypted with no modification to the cloud storage services.

Resources

Read the Intel Expressway Service Gateway data sheet
Read the details on the Secured by RSA configuration

The post Intel Expressway Service Gateway and RSA DPM appeared first on Application Security.

It sounds like a parlor trick, but one of the benefits of API centric de-facto standards  such as REST and JSON is they allow relatively seamless communication between software systems.

This makes it possible to combine technologies to instantly bring out new capabilities. In particular I want to talk about how an API Security Gateway can improve the security posture of a Hadoop installation without having to actually modify Hadoop itself. Sounds too good to be true? Read on.

Hadoop Security and RESTful APIs

Hadoop is mostly a behind the firewall affair, and APIs are generally used for exposing data or capabilities for other systems, users or mobile devices. In the case of Hadoop there are three main RESTful APIs to talk about. This list isn’t exhaustive but it covers the main APIs.

1. WebHDFS – Offers complete control over files and directories in HDFS
2. HBase REST API – Offers access to insert, create, delete, single/multiple cell values
3. HCatalog REST API – Provides job control for Map/Reduce, Pig and Hive as well as to access and manipulate HCatalog DDL data

These APIs are very useful because anyone with an HTTP client can potentially manipulate data in Hadoop. This, of course, is like using a knife all-blade – it’s very easy to cut yourself. To take an example, WebHDFS allows RESTful calls for directory listings, creating new directories and files, as well as file deletion. Worse,  the default security model requires nothing more than inserting “root” into the HTTP call.

To its credit, most distributions of Hadoop also offer Kerberos SPNEGO authentication, but additional work is needed to support other types of authentication and authorization schemes, and not all REST calls that expose sensitive data (such as a list of files) are secured. Here are some of the other challenges:

• Fragmented Enforcement – Some REST calls leak information and require no credentials
• Developer Centric Interfaces – Full Java stack traces are passed back to callers, leaking system details
• Resource Protection – The Namenode is a single point of failure and excessive WebHDFS activity may threaten the cluster
• Consistent Security Policy – All APIs in Hadoop must be independently configured, managed and audited over time

This list is just a start, and to be fair, Hadoop is still evolving. We expect things to get better over time, but for Enterprises to unlock value from their “Big Data” projects now, they can’t afford to wait until security is perfect.

One model used in other domains is an API Gateway or proxy that sits between the Hadoop cluster and the client. Using this model, the cluster only trusts calls from the gateway and all potential API callers are forced to use the gateway. Further, the gateway capabilities are rich enough and expressive enough to perform the full depth and breadth of security for REST calls from authentication to message level security, tokenization, throttling, denial of service protection, attack protection and data translation. Even better, this provides a safe and effective way to expose Hadoop to mobile devices without worrying about performance, scalability and security.  Here is the conceptual picture:

Intel(R) Expressway API Manager and Intel Distribution of Apache Hadoop

In the previous diagram we are showing the Intel(R) Expressway API Manager acting as a proxy for WebHDFS, HBase and HCatalog APIs exposed from Intel’s Hadoop distribution. API Manager exposes RESTful APIs and also provides an out of the box subscription to Mashery to help evangelize APIs among a community of developers.

All of the policy enforcement is done at the HTTP layer by the gateway and the security administrator is free to rewrite the API to be more user friendly to the caller and the gateway will take care of mapping and rewriting the REST call to the format supported by Hadoop. In short, this model lets you provide instant Enterprise security for a good chunk of Hadoop capabilities without having to add a plug-in, additional code or a special distribution of Hadoop. So… just what can you do without touching Hadoop? To take WebHDFS as an example the following is possible with some configuration on the gateway itself:

1. A gateway can lock-down the standard WebHDFS REST API and allow access only for specific users based on an Enterprise identity that may be stored in LDAP, Active Directory, Oracle, Siteminder, IBM or Relational Databases.
2. A gateway provides additional authentication methods such as X.509 certificates with CRL and OCSP checking, OAuth token handling, API keys support, WS-Security and SSL termination & acceleration for WebHDFS API calls. The gateway can expose secure versions of the WebDHFS API for external access
3. A gateway can improve on the security model used by WebHDFS which carries identities in HTTP query parameters, which are more susceptible to credential leakage compared to a security model based on HTTP headers. The gateway can expose a variant of the WebHDFS API that expects credentials in the HTTP header and seamlessly maps this to the WebHDFS internal format
4. The gateway workflow engine can maps a single function REST call into multiple WebHDFS calls. For example, the WebHDFS REST API requires two separate HTTP calls for file creation and file upload. The gateway can expose a single API for this that handles the sequential execution and error handling, exposing a single function to the user
5. The gateway can strip and redact Java exception traces carried in the WebHDFS REST API responses ( for instance, JSON responses may carry org.apache.hadoop.security.AccessControlException.* which can spill details beneficial to an attacker
6. The gateway can throttle and rate shape WebHDFS REST requests which can protect the Hadoop cluster from resource consumption from excessive HDFS writes, open file handles and excessive  create, read, update and delete operations which might impact a running job.

This list is just the start, API manager can also perform selective encryption and data protection (such as PCI tokenization or PII format preserving encryption) on data as it is inserted or deleted from the Hadoop cluster, all by sitting in-between the caller and the cluster. So the parlor trick here is really moving the problem from trying to secure hadoop from the inside out to moving and centralizing security to the enforcement point. If you are looking for a way to expose “Big Data” outside the cluster, an the API Gateway model may be worth some investigation!

Blake

The post Touchless Security for Hadoop – combining API Security and Hadoop appeared first on Application Security.

Next week I am participating in a webinar called Mobile Optimized Healthcare API Programs, from a technical perspective we’ll be looking at some interesting integration between Intel’s Security Gateway and Mashery. From a healthcare standpoint, the discussion looks at what new kinds of use cases are possible in this ecosystem.

For as much hype that financial services and other sectors get vis a vis security, the healthcare security problem set really is harder than the rest. At the same time, there are dramatic benefits from enabling mobile integration for healthcare, it benefits your number one asset: you. Whether its Fit Bit, Nike+, or just healthcare pros with iPads, mobile is uniquely suited to health and wellness related applications. But what is missing is APIs and integration to deliver on the use cases.

The webinar looks at the following concerns:

• Gateway security patterns to safely repackage legacy data and services as APIs – in short enable access not attackers.
• How to construct, share, and promote APIs to developers using API workshops and branded portals – make it easy for developers to do things right
• How to build a mobile-optimized back end that securely exposes enterprise assets via standard internet protocols (e.g. OAuth & JSON) – what comprises the mobile DMZ? How is it similar and different than a plain, old Web DMZ?

As much as I enjoy middleware, security and protocols, what is most interesting about healthcare is the new types of use cases that bring all the technology together. I guess that is as it should be. Still as a technologist its neat to see after all these years that Web services and Secuity Gateways play a leading role in the leading edge technology deployments today.

Making a Mobile DMZ is subtly different than old school Web DMZs. Most of the principles remain the same but the implementation is different. In addition, there are new concerns to handle such as session management, token resolution and asynchronous protocols which function differently on mobile apps than web. In the webinar, we’ll do a deep dive on these topics and what it might mean for your organization

The post Mobile APIs for Healthcare appeared first on Application Security.

A number of analysts are beginning to suggest 2013 will likely signal the awakening of a long night in the IT industry that started with the beginning of the third millennium with the Internet crash. And just as recovery was around the corner, the financial crisis of 2008 dried the IT well once more. Both crises can be characterized as crises of demand. Just past 2000, the Y2K pipeline ran dry. Some argue that the problem was overstated, whereas others argue that the problem was solved just in time. In either case this event triggered a significant pullback in IT spending.

Faced with an existential threat after Y2K, the IT industry did not sit still. The main outcome from these lean years has been a significant increase in efficiency where the role of IT in companies with most advanced practices shifted from being a cost center to an active participant in the execution of corporate business strategy. Capabilities evolved from no accountability on resource utilization to efficient use of capital to nimble participant in a broad range of organizations and initiatives.  The second crisis reaffirmed the continuing need to do more in the face of shrinking budgets and very likely provided the impetus for the widespread adoption of cloud technology.

The state of the art today is epitomized by cloud computing under the service paradigm. From a historical perspective the current state of development for services is in its third iteration.

The early attempts came in various forms from different angles and as many vendors. The most prominent examples of this era came from application server and connectivity ISVs (independent software vendors) and from operating system vendors: Microsoft, IBM, TIBCO and various Unix vendors of that era. The main characteristic of this era that went roughly from 1995 to 2005 was single-vendor frameworks with vendors attempting to build ecosystems around their particular framework. This approach did not take off, partly because concerns in IT organizations about vendor lock-in and because the licensing costs for these solutions were quite high.

The second era was the era of SOA that lasted roughly from 2000 to 2010. The focus was to re-architect legacy IT applications from silo implementations to collections of service components working together. Most of the service components were internally sourced, resulting perhaps from the breaking former monoliths, and combined with a few non-core third party services. Vendors evolved their offerings so they would work well in this new environment. The technology transformation costs were still significant as well as the demand on practitioners’ skills.  Transformation projects required a serious corporate commitment in terms of deferrals to accommodate process reenginering, licensing fees and consulting costs. As a result, the benefits of SOA were available only to large companies. Small and medium businesses (SMBs) and individual consumers were left out of the equation.

Cloud technology drives the current incarnation for IT services following the crisis of 2008. Clouds notwithstanding, if we look at the physical infrastructure for data centers, it is not radically different from what it was five years ago, and there are plenty of data centers five years ago or older still in operation. However, the way these assets are organized and deployed is changing. Much in the same way credit or other people’s money drives advanced economies, with the cloud other people’s systems are driving the new IT economy.

Scaling a business often involves OPM (other people’s money), through partnerships or issuing of stock through IPOs (initial public offerings). These relationships are carried out within a legal framework that took hundreds of years to develop.

In the real world, scaling a computing system follows a similar approach, in the form of resource outsourcing, such as using other people’s systems or OPS. The use of OPS has a strong economic incentive: it does not make sense to spend millions of dollars in a large system for occasional use only.

Large scale projects, for instance a marketing campaign that requires significant amounts of computing power are peaky in the usage of infrastructure assets, usually start with small trial or development runs, with large runs far and few between. A large system that lies idle during development would be a waste of capital.

Infrastructure sharing across a pool of users increases the duty cycle of infrastructure assets through the sharing of these assets with multiple users.  Cloud service providers define the sandbox whereby a number of corporate or individual users have access to this infrastructure. Cloud computing increases the efficiency of capital use through resource pooling delivered through a service model.

The first step in the infrastructure transformation came in the form of server consolidation and virtualization technology. After consolidation became a mainstream IT practice, the trend has been toward the support of more dynamic behaviors. IaaS allows the sharing of physical assets not just within the corporate walls, but across multiple corporate customers. A cloud service provider takes a data center, namely $200 million asset and rents individual servers or virtual machines running inside them by the hour, much in the same way a jet leasing companies takes a $200 million asset, namely an airliner and leases it to an air carrier which otherwise would not be able to come up with the upfront capital expense. The air carrier turns around and sells seats to individual passengers, which is essentially renting a seat for the duration of one flight.

In other words, the evolution we are observing in the delivery of IT services is no different than the evolution that took place in other, more mature industries. The processes that we are observing with cloud computing and associated service delivery model is no different than the evolution of the transportation industry, to give one example.

As we will see in the next few articles, the changes brought by the cloud are actually less about technology and more about the democratization of the technology: the quantum for delivery used to be so large that only the largest companies could afford IT. Over the past few years IT became accessible to small and medium businesses and even individual consumers and developers: businesses can purchase email accounts by the mailbox with a monthly fee, and deployment models allow individual consumers to sign up for email accounts at no out of pocket cost. We will look at the evolution of the service model from a corporate privilege to mass availability. From a practical, execution perspective, products like the Intel® Expressway Service Gateway and Intel® API Manager were developed to support the life cycle of cloud enabled applications, and I’ll be pointing to aspects of these products to provide specific examples of the concepts discussed.

In the next article we’ll discuss the “big guns” services represented by the SOA movement in the first decade of the millennium.

The post From ESBs to API Portals, an Evolutionary Journey, Part 1 appeared first on Application Security.

This month the Cloud SIG of the PCI Security Standards Council released supplemental guidelines covering cloud computing. We’re happy to see APIs included as a recognized attack surface.  As this document makes clear, responsibility for compliance for cloud-hosted data and services is shared between the client and the provider.  API providers moving to the cloud should pay close attention to this document:  Section 6.5.5 covers Security of Interfaces and APIs, while Appendix D covers implementation considerations that include API-related topics.  For cloud-hosted systems, an API gateway can simplify implementation, secure PII and PAN data in motion, provide compliance and ensure auditability in these areas.

The last paragraph of Section 6.5.5 reads:

APIs and other public interfaces should be designed to prevent both accidental misuse and malicious attempts to bypass security policy. Strong authentication and access controls, strong cryptography, and real-time monitoring are examples of controls that should be in place to protect these interfaces.

While Appendix D: PCI DSS Implementation Considerations asks:

• Are API interfaces standardized?
• Are APIs configured to enforce strong cryptography and authentication?
• How are APIs and web services protected from vulnerabilities?
• Are standardized interfaces and coding languages used?
• How is user authentication applied at different levels?

Using a service gateway can ensure that access controls, PII and PAN encryption, and monitoring are consistently applied and enforced for all APIs.  This in turn reduces the likelihood that a single poorly-coded or overlooked API will compromise the entire system. Enhanced vulnerability protection is provided by a centralized point to turn away malicious exploits such as SQL injection or Cross-site scripting (XSS) attempts.  This control point also provides data leak protection for data leaving the enterprise.  The use of a gateway also allows the API provider to construct a consistent façade with standardized interfaces to be utilized for all exposed APIs and web services.

Another area where a gateway can help with PCI-DSS compliance is in containing audit scope via tokenization.  One of the design considerations for protecting cardholder data asks:

Where are the “known” data storage locations?

Using a gateway that supports tokenization can limit PCI scope to the gateway device itself.  The gateway can then be hosted on a higher-tier hosting platform (e.g. a Virtual Private Cloud) while allowing logic servers without access to cardholder data to be hosted on a more cost-effective, multi-tenant platform. A common model here is to tokenize PAN data as it enters the datacenter, minimizing scope impact, which can be done using proxy tokenization in the API gateway. This usage model is ideal for ecommerce retailers that accept credit card data over an HTML form post or other HTTP interface.

For help assessing tokenization option options, we have made available a Buyer’s Guide:  Tokenization for PCI DSS.  For the broader view covering other security gateway usage models, we are also sharing the Buyer’s Guide: Gateway Security.  Finally, we’d refer readers to the Cloud Builders program’s Cloud Security Reference Architecture for some ready-made blueprints and cloud software management platforms.

The post New PCI DSS Cloud Computing Guidelines – Are you compliant? appeared first on Application Security.

A week or so back I needed to put some stuff in storage as we’re moving house. Apparently my fine heirlooms are not conducive to selling the place, I was told. The storage facility I choose was pretty local and had the look of the scene from the end of the Raiders of the Lost Ark where the Ark of the

Box 27B/6 you say? I'm sure I passed it last Friday.

Covenant is placed. Anyway, I got talking to the staff and they were pretty happy to admit (almost proud) that they stored both healthcare and legal records there. I must have an honest face.

The place itself did not have the room to have direct access to each box, instead what they did was note where a box was in the stack and then bury that stack behind other more frequently accessed stacks of boxes. I asked what happened when they lost a box and the guy on the forklift rolled his eyes and said “You don’t want to know.”

This is all well and good until you consider that occasionally its important to access medical history in a hurry. What if there’s a hold up on a diagnosis? Or a clinician needs to give drugs or treatment for an acute condition where there’s the possibility of interfering with previous meds. I know what my luck is like with admin mishaps and these are not odds I want when my (or your) health is at stake. We’re assuming that the admin from your GP went smoothly and the request for retrieving your record was made against the right box in the first place.

At this point I could go into the waste that this kind of data being tied up in paper represents when you might want to look at a population to see what effects medicines, the environment and upbringing might have on health. The fewer paper records you look at the more the doubt is about figures that come out some the more studies need to be done. In other words, it costs a country (us) in money and lives to keep medical records on paper.

I was involved in the project to try to solve this problem in the UK the first time round. It had partial success would be one way to describe how it went. Now the UK health secretary, Jeremy Hunt, has announced a second attack at the problem. A less monolithic one hopefully, one less dependant on the pain that mega SOA architectures built on heavy weight HL7 brings. It is possible to build for health data sharing a different way based on what projects need as opposed to what government ministers wish for as a legacy.  See what the Oxford MMM project is doing in this area.

We now have new ways to tackle this problem based on the ease of exposing data over lightweight APIs – maybe a bit much for a surgery but an NHS Trust IT department could get their heads round it. Big Data in healthcare means we’re not tied to huge SQL DB suppliers or having to have health data as a strongly typed with HL7 any more where that’s not needed. OAuth 2 and SAML means we can share, track and trust access tied it to staff identity.

Anyone for a high speed messaging / API governance tool that can understand health care protocols, auth tokens AND talk to backend data services? Intel ESG for Healthcare Information Exchange. Join our mobile healthcare data web seminar as well.

The post Your healthcare data in who’s hands? appeared first on Application Security.

Registration is now open for our next webinar on Tuesday, March 5 at 10AM Pacific, 1PM Eastern – “Mobile Optimized Healthcare API Programs: New Revenue from Legacy Data”

Mobile apps, partner & developer API programs, and healthcare data are converging to create new revenue opportunities for Healthcare providers via API developer community portals. We’ve assembled a panel of experts from the industry to present case studies from Aetna that illustrate best practices for building a successful API program.

While the case studies come from Healthcare, companies any industry can apply many of the ideas from this webinar to jumpstart their own API community initiatives. The discussion will cover topics including:

• Gateway security patterns to safely repackage legacy data and services as APIs
• How to construct, share, and promote APIs to developers using API workshops and branded portals
• How to build a mobile-optimized back end that securely exposes enterprise assets via standard internet protocols (e.g. OAuth & JSON)

Our speakers will include security expert Gunnar Peterson, Mashery’s Chuck Freedman, Intel’s Blake Dournaee, and a special guest speaker from Aetna. In addition, all attendees will receive a Mobile API Architecture White Paper. We hope you’ll join us!

The post Webinar: Mobile Optimized Healthcare API Programs appeared first on Application Security.

Introduction

With the trends of consumerization and bring-your-own-device (BYOD) acceptance, enterprises are increasingly seeking to securely integrate tablets and smartphones into their environments.  Meanwhile, external customers and partners desire mobile apps that provide on-demand, self-service alternatives to traditional consumer web portals.  Mobile middleware can ease this integration, providing a consistent framework and set of interfaces for a wide range of applications and data sources.  This is the first in a series of posts intended to help the enterprise IT buyer to better understand the benefits of mobile middleware, as well as to make an informed decision when choosing among the many products in this space.

Use case 1:  Employee productivity

Mobile devices bring the potential for ubiquitous access to corporate resources, providing employees with an “always-on” connection to the enterprise.  Email, calendar, and contacts are no longer sufficient for many enterprises – Line-of-Business applications with secure access to corporate data will further improve worker productivity.

While the first stage of mobile access was delivered using off-the-shelf software packages, the next wave will include much more custom code.  According to a November 2011 Forrester study, over 50% of enterprises rely on custom applications developed either in house or by externally-contracted developers.  These applications will require access to a mix of back-end services, from existing SOAP applications to newly-developed RESTful APIs, as well as cloud-hosted services such as salesforce.com.

 An established enterprise may already have an ESB for internal services, or they may be using loosely-coupled, point-to-point connections between apps and services.  Either way,the ESB likely was not designed with wide-scale or external connectivity in mind.  Mobile middleware can help to bridge this gap, providing a RESTful interface to legacy services and data sources.  It can also provide enterprise mobile application developers with a catalog of available APIs and documentation on how to consume them, speeding development and increasing consistency across applications.

Use case 2:  External access

Many enterprises have offered their customers a self-service web engagement portal for some time.  Whether it is used for commerce, basic account management, or other purposes, this portal ultimately connects back into enterprise services.  With mobile browsers taking an increasing share of page views, portals that deliver substandard user experience are being reimplemented as native enterprise mobile applications.

Source: StatCounter

While the scope of services to be accessed by external users is typically much narrower than in the employee productivity use case, the scale and security considerations are much greater.  Also, digital natives expect integration with external identity providers, social networking, and other external cloud services.  As with internal-facing applications, mobile middleware can act as a glue layer for these customer apps, providing integration with external services while securing access to internal data.

The Case for Mobile Middleware

Regardless of which use case is the primary motivator for adopting a mobilization strategy, it’s clear that legacy web and data services are not readily consumable by mobile devices.  An enterprise, then, has two options:  remediate each service independently, or adopt a mobile middleware layer that can bridge the gaps to mobile access.  Development cost savings from the mobile middleware approach will depend on the number of services to be addressed and level of integration effort required.  However, by abstracting away these integration functions, enterprises can be assured that security policies are being uniformly implemented, enforced, and updated — no easy task if custom code is added to a large number of applications.

A mobile middleware strategy can address the issues shared by both of these use cases:  providing security and broad integration capabilities while delivering the performance necessary for a responsive user experience.

Other Resources

Over the next few weeks I will explore how mobile middleware can help an enterprise to integrate its own REST and SOAP services with 3rd-party APIs.  I’ll also describe some of the security and performance considerations that go along with different approaches.  Finally I will look at the options for application development that can benefit from the a consistent, RESTful back end.

In the meantime, here are some links to other material that should be useful when building a strategy for enterprise mobile applications:

• Comparisons of API Platforms and API Gateways
• CITO Research’s whitepaper describing API Patterns for Cloud & Mobile
• A Unified Mobile Architecture for the Modern Data Center

The post Mobile Middleware for the Enterprise (part 1) appeared first on Application Security.

Alright, I am sure you have heard this again and again but it’s worth saying it one more time. The first ever API strategy & practice conference is going be in NYC on Feb 21, 22 (http://www.apistrategyconference.com/). If you are just finding this out, it might be way too late for you to get in (But I will tweet anything interesting happening from inside :) ).  There are 72 companies that are confirmed to participate and sending their API whiz kids, gurus, learners, teachers, procrastinators there to make a difference. Intel is proud to be a Gold sponsor to this event.

Yes, Intel. Not only does Intel do software, but they do it really well too. We have an outstanding API Manager that we released recently which will be showcased there. If you happen to attend this, please stop by my 2 speaking sessions/ panels. 

Day 1: 2:20-3:30 – Track 3: API Security and Scalability

As APIs gain adoption they become ever more critical gateways to a company’s core business – ensuring access is secure and scalable are mission critical for your business. Presentations include:

1. Paul Madsen (@PingIdentity) of  Ping Identity
2. Mark O’Neil (@TheMarkONeill) of Vordel
3. Travis Reeder (@treeder) of Iron.io
4. Andy Thurai (@AndyThurai) of Intel
5. Discussion panel on the challenges and solutions for API Security and Scalability

Day 2: 11.00-12.10 – Track 1: Mobile

APIs and Mobile are symbiotic – each driving the other with a good API strategy arguably key to a good Mobile Strategy. Presentations include: 

1. Andy Thurai (@AndyThurai) of Intel
2. Max Katz (@maxkatz) of Tiggzi
3. Marc Weil (@marcweil) of Cloudmine
4. Miko Matasumura (@mikojava) of Kii
5. Discussion Panel on the evolution of API / App Ecosystems and platforms

3Scale and Kin Lane did an amazing job of putting this together again (first time was cancelled thanks to hurricane Sandy). Hope to see you all there. Don’t forget to stop by our booth. You will get a chance to see me , and win some goodies if you stop by and make your presence known, but more importantly you will get to learn about Intel API Manager.

Looking forward to seeing you all there.

-Andy Thurai (Twitter: @AndyThurai)

The post API strategy & practice conference in NYC – Are you going? appeared first on Application Security.

Apps World Focus on Enterprise Mobile Applications

My team attended Apps World in San Francisco last week.  The show almost could have been called “Mobile Middleware World”.  It was clear that we’re not the only ones who think 2013 will be the year of the Enterprise Mobile App.  While the conference had plenty of independent developers and consumer-oriented tools, many of the folks stopping by our booth were focused on the enterprise.  We received several questions about our solutions for enterprise mobile applications and API management.  API providers were also bridging the gap between consumer- and enterprise-grade services, with talks and demos both days from StackMob, eBay, Box, and SendGrid.

Intel is a Software Company?

We received a number of questions related to our API management products.  Once we got past the initial question of “Intel is a software company?“, it was clear that our vision for mobile middleware is well-aligned with what developers of enterprise mobile applications are seeking.  We received positive feedback on the end-to-end capability we offer:

• Secure and robust API management on the back end
• Best-in-class API discovery and developer onboarding through our connection to the Mashery portal
• HTML5 and Appcelerator provide flexible app development on virtually any device.

Digital Payments and Enterprise Mobile Applications

One of the bigger trends I saw had to do with digital payment systems.  This is a rapidly-evolving area, with virtual currency moving from games into other apps, potentially expanding into enterprise mobile applications.  Other payment systems, such as digital wallets and P2P, seemed to be top-of-mind as well.  It’s clear that mobile application and API security will be critical for success, regardless of which standards win out in these areas.

Building the Enterprise Mobile Application Factory

Also in our booth, Kin Lane gave a very popular talk on Building the Enterprise Mobile Application Factory.  If you missed his talk, it is available online.  Our HTML5 development talk was also very well-received, with many participants signing up right away for our cloud-based HTML5 developer tools.

It is shaping up to be an exciting year for us in the enterprise mobile applications and API management space.  Apps world was just the beginning.  For more information, stay tuned to this blog, follow us on twitter at @IntelAPIGateway, download our whitepaper on API Patterns for Cloud & Mobile, or check out some of our mobile middleware tutorials.

The post Enterprise Mobile Applications at Apps World appeared first on Application Security.

I told you I was ill.

The phrase “Don’t be a SOAsaurus” is being bandied about on twitter and the like and it got me thinking about using that particular analogy to describe SOA Web Services practises and contrast them with the clever little RESTful API Service mammals that maybe saw off the big, ugly lizards.

Before getting into computing I did spend some time in Geology so I’m coming at this argument from a slightly odd standpoint. For any Geologists reading I was structural, ophioites and terrain docking. We used to look down on this palaeontology stuff and everyone looked down on the geophysicists.

To recap the dinosaurs then. We know them from the fossil record. To become a fossil is a one in a bazillion chance so there have to be a lot of you about. By definition any fossil you find must have come from a wildly successful species. So SOAsaurus must be some form of compliment. On top of that, dinosaurs (as we commonly refer to them) lasted over one hundred million years, dominated the land, sea and sky AND gave birth to the mammals. By that analogy REST wouldn’t be here but for SOA. In the same way SOA has had it’s time in the press and still continues to have it’s time in enterprise. Fully half of the enquiries Gartner specialists like Paolo Malinverno get are from people working on SOA, installing service based architectures XML and developing new services.

The analogy extends to our RESTful mammals as well. At night they had the advantage of heat to go out scavenging dinosaurs and stealing eggs. In the same way I see technologies scavenged from SOA; sledgehammer to crack a nut UDDI re-emerges as API portal, WSDL starts to emerge as WADL. Vendors see that the wheel is being reinvented so technologies like service and security gateways extend their functionality to encompass both worlds.

When the dinosaurs did go it had taken the combined effects of millennia of climate change from the volcanic eruptions forming a decent portion of what is now India plus the impact of a meteorite big enough to form a 200km wide crater. That was big enough to wipe out two thirds of all species on the planet. It reminds me of a major UK banking group I’ve worked with whose mainframe still ran on token ring and used a protocol older than I am! Big, successful technologies are hard to kill off for several reasons, primarily they work for the frame of reference they were put in for. We’ll be living with SOA practices running organisations for many decades yet.

But maybe I got the analogy wrong. REST isn’t the mammal after all and the dinosaurs never died out. They survived by ditching the weight and becoming more agile with less in the way of teeth. In the same way its not hard to imagine why developers want to get rid of the stack of J2EE, XML, SOAP, WS-ReliableMessaging, WS-PolicyForSecureReliablePolicyIdentityFederationPolicy…. REST represents the birds and one’s about to crap on your shoulder sometime soon.

I think I agree with SOAsaurus, I like the term. SOA gets to live as Argentinosaurus, Compsognathus or Protoceratops. REST could be Albatross, Turkey or Penguin (okay, now I’m poking fun). As Archaeopteryx was no doubt fond of saying; there’s room for a bit of both.

Of course this is all fine discussing the mammals and the dinosaurs but its the bacteria that use us and let us live in the end. Any suggestion as to the computing equivalent?

Whether you’re a SOAsaurus seeking SOA governance, are looking to evolve using REST/SOA mediation, or are already walking upright with REST and need to manage APIs, we’ve got you covered.

Follow me @PeteL0gan uk.linkedin.com/in/petelogan/.

The post Who’s a SOAsaurus? appeared first on Application Security.

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)

The post Are you building your APIs the right way? appeared first on Application Security.

The post Are you PCI DSS compliant yet? What is stopping you? appeared first on Application Security.

As an Enterprise Architect for Intel IT, I worked with IT Engineering and our Software and Services group on the elastic scaling of the APIs that power the Intel AppUp® center. Our goal was to scale our APIs to at least 10x our baseline capacity (measured in transactions per second) by moving them to our private cloud, and ultimately to be able to connect to a public cloud provider for additional availability and scalability. Here’s a quick set of practices we used to achieve our goal:

1. Virtualize everything.  This may seem obvious and is probably a no-op for new APIs, but in our case we were using a bare-metal installs at our gateway and database layers (the API servers themselves were already running as VMs). While our gateway hardware appliance had very good scalability, we knew we were ultimately targeting the public cloud and that our need for dynamic scaling could exceed our ability to add new physical servers.  Using a gateway that scales in pure software virtual machines without the need for special purpose-built hardware helped us achieve our goal here.
2. Instrument everything.  We needed to be able to correlate leading indicators like transactions per second to system load at each layer so we could begin to identify bottlenecks. We also needed to characterize our workload for testing – understanding a real-world sequence of API methods and mix/ordering of reads and writes. This allowed us to create a viable set of load tests.
3. Identify bottlenecks.  We used Apache jmeter to generate load and identify points where latency became an issue, correlating that against system loads to find out where we had reached saturation and needed to scale.
4. Define a scaling unit.  In our case, we were using dedicated DB instances rather than database-as-a-service, so we decided to scale all three layers together. We identified how many API servers would saturate the DB layer, and how many gateways we would need to manage the traffic. We then defined a collection of VMs that would provision all of these VMs together. We might have scaled each layer independently had our API been architected differently, or if we were building from scratch on database-as-a-service.
   

   Example collection for elastic scaling

5. Repeat. The above let us scale from 1x to about 5x or 6x without any problem. However, when we hit 6x scaling we discovered that a new bottleneck: the overhead of replicating commits across the database instances. We went back to the drawing board and redesigned the back end for eventual consistency so we could reduce database load.
6. Automate everything.  We use Nagios and Puppetto monitor and respond to health changes. A new scaling unit is provisioned when we hit predefined performance thresholds.
   

   Automation/Orchestration workflow

7. Don’t forget to test scaling down.  If you set a threshold for removing capacity, it’s important to make sure that your workflow allows for a graceful shutdown and doesn’t impact calls that are in progress.

The above approach got us to 10x our initial capacity in a single data center. Because of some of our architecture decisions (coarse-grained scaling units and eventual consistency) we were then able to add a GLB and scale out to multiple data centers – first to another internal private cloud and then to a public cloud provider.

The post Elastic Scaling of APIs in the Cloud appeared first on Application Security.

Recently the government of Singapore passed a bill (or “Gazetted” as they call it, which sounds a lot fancier) about protecting personal data of consumers:

http://www.mica.gov.sg/DPbillconsultation/Annex%20D_Draft%20PDP%20Bill%20for%20Consultation.pdf

“Protection of personal data

26. An organisation shall protect personal data in its custody or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification or disposal or similar risks.

Cross-border Transfers

The PDPA also permits an organisation to transfer personal data outside Singapore provided that it ensures a comparable standard of protection for the personal data as provided under the PDPA (Section 26(1)). This can be achieved through contractual arrangements.”

So what they are suggesting is that gone are the days that if a business loses its customers’ data, they tell the consumers, “Oops, sorry, we lost your data…………” and that is about it. Now, the governments are taking initiatives that can hold the companies responsible for being careless with consumer data and not protecting it with their life, if not face consequences.

http://europa.eu/rapid/press-release_IP-12-46_en.htm?locale=en

This means, as a corporation, you need to protect not only the data in storage and in transit, but also given the cross-border restrictions (this is especially strictly enforced in Europe; read about them on above URL links) you need to figure out a way to keep the data and the risk to yourself instead of passing this on to third parties. The easiest way to achieve that would be to tokenize the sensitive data, keep the sensitive data in your secure vault and send only the tokens to the other end. Even if the other end is compromised, your sensitive data and your integrity will be intact, and it will be easy to prove in case of an audit that you went above and beyond not only to comply with requests/ laws such as this, but also you genuinely care for your customers’ sensitive personal data. Brand reputation is a lot more important than you think.

Who is more sensitive – you or your data?

Content/ Context / Device aware Cloud Data Protection

Part 2: Context aware Data Privacy

The post You are Gazetted… appeared first on Application Security.

Intel recently released what we call a composite API platform with our new API Manager product. What exactly do we mean by this?

A composite platform is a single platform for API management that handles both Public (sometimes called “Open”) APIs and Enterprise APIs. It’s composite because it exhibits both the cost savings of “cloud” through a multi-tenant SaaS partner portal coupled with the control of on-premises gateway for traffic management. Like a composite material, the mingling of two or more constituents gives the final solution different properties not found in either alone.

For a public or open API it’s important to have developers interact in a shared manner, generally done through a public SaaS partner management portal. True multi-tenant SaaS offerings gives the Enterprise cost advantages, as the partner management piece is akin to running a website for potentially thousands of developers.Running a successful website means people, resources, archival and a higher cost of ownership.

Further, Multi-tenant SaaS means developers may be using more than just your API as they may also be finding other APIs they are interested in advertised from other tenants. This is a good thing as these are the caliber of developers you want. After all, experienced developers can bring more to the table – they may even come up with an awesome app that mixes your data with a partner’s in a new way.

As flashy as the cloud is, not all Enterprises can risk complete movement to a public cloud environment, especially for security and compliance. The set of applications bound to the enterprise are sometimes called “gravity bound”, as they are part of an information system tied to a core business processes or cannot be outsourced due to compliance, privacy or security issues.

How do these applications gain the benefits of the API economy? What if you want to build an mobile app or partner app that interacts with a mainframe or legacy system? How do you ensure compliance for API traffic that involves sensitive information? What about security?

For these types of large scale environments, the Enterprise has good reasons to buy and own some of the components used to expose the API. Overall, the composite API platform really mixes the concepts of Public APIs and Enterprise APIs together.

All APIs are really Enterprise APIs, its the manner in which they are exposed and their purpose that labels then Public or “Enterprise”, but in reality they both support an Enterprise’s API strategy and we might argue that the most successful enterprises will actually have both.

The post What’s in a Composite API Platform? appeared first on Application Security.

This Thursday, I will be presenting a webinar with Forrester covering 4 Building Blocks to Mobilize Your Enterprise App Strategy.  As we prepared for this talk, Mike and I talked about a few trends that are emerging in response to the BYOD-driven growth of enterprise apps.  First, the pervasive 3-tier hosting architecture we all know and love may not be the best fit for hybrid or native applications, but the industry doesn’t seem to have bottomed out on what to call the new model(s) that will replace 3-tier.  Second, while it would be nice to throw out all of the legacy baggage we’re carrying around with us, the reality is that we need to securely integrate new technologies with legacy services in order to provide the best possible mobile enterprise experience.  Finally, with a stable and secure set of APIs in place, developers are looking to SDKs that can streamline multi-platform development.

In Thursday’s webinar, we’ll look at how mobile middleware is enabling native applications to access data through APIs, signaling an evolution from traditional 3-tier architectures.  We’ll also talk about how REST/JSON APIs are being integrated with SOAP services and other data sources to create composite applications.  Click here to sign up for the webinar, and stay tuned for our “Mobile Middleware Buyers Guide” that takes a closer look at some of the building blocks for enterprise app mobilization.

The post Enterprise Mobile App Strategies appeared first on Application Security.

Recently a colleague and a friend of mine wrote a great article about different ways to be PCI 2.0 compliant by tokenizing PAN data. If in case you missed it I want to draw your attention to it.

Essentially, if you are looking to be PCI-DSS 2.0 compliant there are few ways you can achieve that. The most painful would be obviously a rip-and-replace strategy and the easiest would be to do it in an incremental, less intrusive method.

First approach, the Monolithic big bang approach, is the legacy way of doing things. Once you figure out the areas of your system that are non-compliant (that is either storing PAN data –encrypted or not, or processing PAN in clear), you decide whether you need that component to be PCI compliant. As the PCI audit is very extensive, time consuming and very methodical, in which every process, application, storage, database, and system will be looked at and thereby it becomes very expensive. Once you figure out which components need to be PCI compliant you can do the rip and replace approach in which you will touch every system component that needs to be modified and rewrite the system to become compliant. This might involve touching every component and change your entire architecture. This essentially will be the most expensive, painful and the slowest before you can be compliant. While this can be the most effective for spot solutions, this could be an issue if you have to do this every time when the PCI-DSS needs change (which seems to be every year).

Second approach, API/SDK based tokenization is much more effective. In this case, you can retrofit applications, processes, systems, databases, etc. by making those components call an API (or SDK) which will convert the PAN data and return a token which can be used to replace the original PAN data. This requires you to do minimally invasive procedures. While this doesn’t require you to change your entire architecture/ system it still requires you to touch all those components that need to be compliant. Effectively this method is a lot faster and quicker to the market, while also giving you an opportunity to change quickly when the PCI-DSS needs change.

The third approach is called a gateway approach. In this you essentially monitor the traffic between components and tokenize/ de-tokenize the data in transit. This is also known as in-line tokenization. This method is effectively the cheapest, and the quickest to the market. But the biggest advantage is that your changes to your existing systems will be very minimal to nil. Essentially, you make the PAN data flow through the gateway which will take care of converting the PAN data to tokens before it hits your systems. Imagine the painful exercise when you have to make your Mainframe and legacy systems compliant by having them deal with tokenized data if you were to re-code those legacy systems. This method will essentially eliminate that.

You can read his entire article here.
Cost Effective PCI DSS Tokenization for Retail (Part I)
Cost Effective PCI DSS Tokenization for Retail (Part II)

Also, don’t forget to check out our tokenization buyer’s guide here.

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

Andy Thurai is Chief Architect and Group CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Mobile, Big Data, 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 25+ years of IT experience.

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

The post Effective PCI Tokenization Methods appeared first on Application Security.

I was at dinner with a friend who was considering enrolling in a survey class on client side web technologies. The course would cover things like JavaScript, Silverlight, HTML5, Adobe flash and the like. As she was talking, I was playing with my new Samsung Galaxy Note 2, which if you are not familiar, is somewhere between a traditional smartphone and a tablet. As a side note, that phone is pretty awesome in my book.

As she was talking about the course I gave her the phone and told her to look up the definition of a word, any word, first using the Internet and then next using an “App.” This is a simple task of course, but the experience of doing this using the web versus an app has an extremely high ‘clunkiness’ factor to it.

For the web experience, you press “Internet”, go to Google, search for “dictionary”, find one or two of the top ranked dictionary sites, wait for it to load, type in your word and find the answer amongst a panoply of side-rail ads. If you are a Google power user you can use the”definition” keyword, but not all users know about that.

For the the app experience, you open the dictionary app, put in the word and get the answer. Simple, smooth and fast. This experience is fueled by APIs, specifically an API call from the native app to the Internet or other back-end system providing the answer.

I told her, “Well, in that class you are considering, you are learning all of the technologies that enable the first experience.”

“Why would I do that?” She responded. “The first way seems so clunky.”

I considered responding with various arguments about how the web has fueled tremendous growth and the value of open standards for mark-up and a common syntax for universal resources – but then I thought of the cash-value the task at hand – getting the definition of a word, and while the web experience gets you the answer, the app experience gets the answer faster and with a better experience. When the task is well defined to a single purpose, the app shines.

The big question now is, will that native experience be restricted to devices or will it it spread to ultra-books and desktops? How much of that native app experience will spill to the larger computing devices?

Blake

The post An Anecdote: Is the Web Clunky? appeared first on Application Security.

Kin Lane recently wrote a couple of blogs about why copyrighting an API is not common. I couldn’t agree more that copyrighting APIs is uncommon. First of all, the API definition is just an interface (It is the implementation detail that is important, and needs to be guarded), so it doesn’t make any sense to copyright an interface. (It is almost like copyrighting a pretty face ). Secondly, the whole idea of exposing an API is you are looking for others to finish the work you started by just providing the plumbing work. Why would anyone want to get involved with a copyrighted API and finish your work for you?

Kin Lane says, “API copyright would prevent the reuse and remix of common or successful API patterns within a space. We are at a point where aggregating common, popular APIs into single, standardized interfaces is emerging as the next evolution in web and mobile app development.”

http://apivoice.com/2012/12/08/api-copyright-would-restrict-api-aggregation/index.php (to read his complete blog).

We have gone from the services aggregation concepts to mashups, and now I am seeing the newer trend of API aggregation.

Keep in mind APIs are generally offered by vendors who want to expose a specific functionality or platform. If you need cross platform, cross provider, cross functionality options, you need to have API aggregations. Remember during the services days how much of a hard time we used to have in integrating and aggregating services from different vendors? I know some companies are making a good living by just building aggregated APIs.

One of the common usage patterns I see time and again is customers use the strongest points from vendors of their choice. This was not possible when you were building services. You ended up buying one vendor stack, and you were limited what was offered by them, unless you custom built the weak parts by yourself.

Now imagine the power of what you are getting now. You are cherry picking the best of breed platforms, best of possible functionalities from multiple vendors of your choice and liking.

I highly encourage you to check out the following solution brief that describes a composite API platform architecture where Intel® has packaged the market leading Mashery API sharing portal with Intel’s gateway security & integration technology to deliver Intel® Expressway API Manager.

Please contact me if you need more information. I’m more than happy to send you any additional information that you may need.

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

Andy Thurai is Chief Architect and Group CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Mobile, Big Data, 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 25+ years of IT experience.

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

The post Why are APIs so popular? appeared first on Application Security.

As native mobile apps continue to remain in the spotlight of computing, the question of Enterprise applications and their associated data raises interesting questions of where data should be munged.

Take SharePoint data for example – from an Enterprise perspective there is a lot of value tied up in documents, lists, pictures, and shared documents to be made available on mobile phones for use in the field.

There are two approaches, one, lets call first generation (thick client) and one we’ll call second generation (thin client). The first roughly maps to client/server architecture with a “thick” client and the second roughly maps to the ubiquitous web browser/app-server paradigm.

Thick clients parse data on the device and thin clients rely on the server for business-logic and processing.

With a mobile middleware gateway, you can save resources on the phone and munge data on the server side, moving the compute cycles from the smart-device to the server-side. With a thick client model you have to face mobile phone SDK fragmentation and munge your data on a constrained device.

So, what’s better, being thin or being fat?

Blake

The post So… What’s best, being Thin or being Fat? appeared first on Application Security.

If you missed my Part 1 of this article, you can read it here when you get a chance (link).

As a continuation to part 1, where I discussed the issues with Data Protection, we will explore how to solve some of those issues in this article.

People tend to forget that hackers are attacking your systems for one reason only –  DATA. You can spin that any way you want, but at the end of the day, they are not attacking your systems to see how you configured your workflow or how efficiently you processed your orders. They could care less. They are looking for the golden nuggets of information that either they can either resell or use to gain some other kind of monetary advantage. Your files, databases, data in transit, storage data, archived data, etc. are all vulnerable and will be of value to the hacker.

Gone are the old days when someone was sitting in mom’s basement and hacking into US military systems to boast about their ability amongst a small group of friends. Remember Wargames,  the movie?  Modern day hackers are very sophisticated, well-funded, often in for-profit organizations, and are backed by either big organized cyber gangs or by other entities within their respective organizations.

So you need to protect your data at rest (regardless of how the old data is – as a matter of fact, the older the data, the chances are, they are less protected), data in motion (going from somewhere to somewhere – whether it is between processes, services, between enterprises, or into/from the cloud or to storage), data in process/usage. You need to protect your data with your life.

Let us closely examine the things I said in my last blog (Part 1 of this blog), the things that are a must for a cloud data privacy solution.

More importantly, let us examine the elegance of our data privacy gateways (code named: Intel ETB – Expressway Tokenization Broker) that can help you with this costly, scary, mind-numbing experience go easily and smoothly. Here are the following elements that are embedded in our solution that are going to make your problem go away sooner.

1.       Security of your sensitive message processing device

As they say, Caesar’s wife must be above suspicion (did you know Caesar divorced his wife in 62 BC). What is the point of having a security device that inspects your crucial traffic, if it can’t be trusted? You need to put in a solution/devices where a vendor  can make assertions regarding security and have the necessary certifications  to back up those claims. This means that a third party validation agency should have tested the solution and certified it to be ‘kosher enough’ for an enterprise, data center or cloud location. The certification must include FIPS 140-2 Level 3, CC EAL 4+, DoD PKI, STIG vulnerability tested, NIST SP 800-21, and support for HSM, etc. The validation must come from recognized authorities, not just from the vendor.

2.       Support for multiple protocols

When you are looking to protect your data, it is imperative that you choose a solution that not only can handle the HTTP/ HTTPS/ SOAP, JSON, AJAX and REST protocols. In addition, you need to consider whether the solution supports all standard protocols known to the enterprise/cloud, with “Legacy” protocols such as JMS, MQ, EMS, FTP, TCP/IP (and secure versions of all of the above) and JDBC. More importantly, you also need to determine whether the solution can speak industry standard protocols natively such as SWIFT, ACORD, FIX, HL-7, MLLP, etc. You also need to look at whether or not the solution has the capability of supporting  other custom protocols that you might have. The solution you are looking at should give you the flexibility of inspecting your ingress and egress traffic regardless of how your traffic flows.

3.       Able to read into anything

This is an interesting concept. I was listening to one of our competitor’s webcasts… there was complete silence when what appeared to be a dreaded question, was asked of the person speaking on behalf of that company: “How do you help me protect  a specific format of data that I use in transactions with a partner?” Without hesitation, the presenter answered the question by  suggesting their solution lacked support for it. While I’m not trying to be unnecessarily abrasive, the point is that you should have the capability to be able to look into any format of data that is flowing into, or out of, your system when the necessity arises. This means that you should be able to inspect not only XML, SOAP, JSON, and other modern format messages. A solution should be able to retrofit your existing legacy systems to provide the same level of support. Message formats such as COBOL (oh yes, we will be doing a Y10K on this all-right), ASCII, Binary, EBCDIC, and other unstructured data streams that are of equal importance. Sprinkle in the industry format messages such as SWIFT, NACHA, HIPAA, HL7, EDI, ACORD, EDIFACT, FIX, FpML to make the scenario interesting. But don’t forget our good old messages that can be sent in conventional ways such as MS Word, MS Excel, PDF, PostScript and good old HTML, etc. You need a solution that can look into any of these data types and help you protect the data in those messages seamlessly.

4.       Have an option to sense not only the sensitive nature of the message, but who is requesting it and on what context and from where

This is where we started our discussion. Essentially, you should be able to not only identify data that is sensitive,  but take necessary actions based on the context. Intention, or heuristics, are a lot more important than just sensing something that is going out, or in. So this essentially means you should be able to sense who is accessing what, when, from where, and more importantly from what device. Once you identify that, you should be able to able to determine how you may want to protect that data. For example, if a person is accessing specific data from a laptop from within the corporate network, you can let the data go with the transport security, assuming he has enough rights to access that data. But if the same person is trying to access the same data using a mobile device, you can tokenize the data and send only the token to the mobile device. (This allows you to solve the problem where location is unknown as well. ) All conditions being the same, the tokenization will occur based on a policy that senses that the request came from a mobile device.

5.       Have an option to dynamically tokenize, encrypt, format preserve the encryption based on the need

This will allow you to be flexible to encrypt certain messages/ fields, tokenize certain messages/ fields or employ FPE on certain messages. While you are at it, don’t forget to read my blog on why Intel’s implementation of the FPE variation is one of strongest in the industry here.

6.       Support the strongest possible algorithms to encrypt, storage, and use the most random possible random number for tokenization

Not only should you verify the solution has strong encryption algorithm options available out of the box (such as AES-256, SHA 256, etc.), but you should also ensure that the solutions delivers cutting edge security options when they become available – including support for the latest security updates.

7.       Protect the encryption keys with your life. There is no point in encrypting the data, yet giving away the “Keys to the Kingdom” easily

Now this is the most important point of all. If there is one thing you take away from this article let this be it: When you are looking at solutions, make sure that not only that a solution is strong on all of the above points, but most importantly, ensure that you  protect the proverbial keys with your life. This means the key storage should be encrypted, and  should be capable of having: an SOD (separation of duties), key encrypting keys, strong key management options, key rotation, re-key options when the keys need to be rotated/expired or lost, key protection, key lifetime management, key expiration notifications, etc. In addition, you also need to explore if there is an option to integrate with your existing key manager in house such as RSA DPM (the last thing you need is to disrupt the existing infrastructure by introducing a newer technology).

8.       Encrypt the message while preserving the format so it won’t break the backend systems

This is really important if you want to do the tokenization or encryption on the fly without the backend or connected client applications knowing about it. When you encrypt the data and  preserve its format, it will not only look and feel the same as the original data, but the receiving party won’t be able to tell the difference.

If you are wondering Intel comes into the picture in this area, we address of all of the discussion points mentioned in #1 to #8, with our Intel Cloud data privacy solution (a.k.a. Intel ETB – Expressway Token Broker) and a lot more. Every single standard that is mentioned in here  is supported, and we are working on adding the newer, better standards as they come along.

Check out information about our tokenization and cloud data privacy solutions here.

Intel Cloud Data Privacy/ Tokenization Solutions

Intel Cloud/ API resource center

I also encourage you to download the Intel Expressway Tokenization Broker Data Sheet:

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

Andy Thurai is Chief Architect and Group CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Mobile, Big Data, 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 25+ years of IT experience.

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

The post Context Aware Data Privacy (part II) appeared first on Application Security.

I just returned from an exhilarating trip to the Gartner AADI show in Las Vegas last week. There are a lot of exciting things happening at Intel in the Data-center Software Division (DSD), especially with respect to the Expressway Product Line.

First, we had our first live demo of the integrated solution that showcases Intel(R) Expressway API Manager and the Mashery API Management Portal. This is a true best of breed match between what we think is one of the best security gateways in the market and the de-facto market leader in API management, bringing the best possible product set to our end customers.

Second, we did multiple workshops with Gartner visionary Appcelerator. They make a slick cross-platform mobile development environment that produces native code for mobile applications, and the cool part is that the developer only has to write their code in JavaScript. So you can think of their tool as a cross-compiler that churns out native code optimized for Android, iOS, Blackberry and Windows devices but  only requires the developer to have a working knowledge of JavaScript.

The combination of Appcelerator Titanium and Intel(R) Expressway API Manager is a killer best of breed architecture for jumpstarting an Enterprise ready native mobile application. In fact, we showed a live proof of concept that went from a non RESTful back-end to a native application running on an iPhone with Enterprise grade data level security controls in 15 minutes.

Enterprises and Native Mobile Applications

Let’s walk through the scenario. Suppose you are a large Enterprise and you want to get a mobile project going at your enterprise. Furthermore, you don’t really want to compromise with HTML5 – native applications typically provide the best performance and device integration. Here are some of the hurdles – first you will likely have fragmentation in your data-center. You probably have:

• Disparate middleware and database technologies
• Disparate identity management silos
• Disparate programming languages, with different levels of expertise
• Current architecture optimized for web browsers, e.g. n-tier designed for a thin/dumb client
• Vertical integration prohibits cloud outsourcing
• Inconsistent security model across domains

And now, on top of these challenges you want:

• BYOD with enterprise native mobile applications
• Low development costs
• Fast time to market
• Robust security for Enterprise data

API Enabling Your Existing Architecture

The post Intel Expressway API Manager and The Rise of Mobile Middleware appeared first on Application Security.

In this two-part blog, I am going to talk about the Intel Cloud Data protection solution that helps our customers utilize their data, in both a context and content-aware manner.

This is a newer set of technologies that has hit the market in the last few years. In the past, we used to think just encrypting the transport layer (such as TLS/SSL) was good enough. Given the complex nature of services and API composition, we quickly realized that it was not enough. Then we moved to protect the messages (most of the time,  the entire message), or at a field level to protect the specific sensitive fields. The problem with any of these scenarios was that it was somewhat static in nature; somewhere there was a definition of what “sensitive data” is, and details related to strict protection of that data. However, when there is a real need to send sensitive data out and a need to protect that, making sure only the authenticated party can receive and/or use the message is critical.

Essentially “Content/Context Aware” data protection is data protection on steroids. Remember in prior years when we used the DLP technologies, identified data leakage/ data loss based on certain policies/ parameters and stopped the data loss but did nothing about it? The problem with DLP is that it is passive in most cases. It identifies sensitive data based on some context/policy combination and then blocks the transaction. While this can work for rigid enterprise policy sets, this may not work for cloud environments where you need these policies to be flexible. The issue with that is when someone really needs to have that data (who is authorized for it), it is unacceptable to have the transactions stopped.

What if there were a way to provide data protection which would be identity aware, location aware, invocation aware — and yet, would be policy based, compliance based, and more importantly, very dynamic? In other words, what if you were to provide data protection based on content and context awareness? Gone are the days in which you ensure that your systems are compliant, and you are done. Read my blog on why getting compliant is not enough anymore. (link here). That is because your data is NOT staying within your compliant enterprise Ft. Knox anymore; it is moving around. Getting your systems compliant, risk averse and secure, is just not good enough as your data is moving through other eco-systems, not just yours.

When you move your data through cloud providers (especially public cloud) and add removable devices (mobility) to the mix, the issue gets even more interesting. Sprinkle data residency issues on top of that to spice it up.

First of all, take a look at your cloud provider contract closely if you haven’t done so already.

• Are there any guarantees on where the data is stored (in other words, the location of the data residency)?
• Are there any guarantees on where the data will be processed (or the location of data processing)?
• Are they willing to share the liability with you if they lose your or your customer’s data?

Yes, some providers are better than others, but I have seen some other contracts, that give me heart palpitations. No wonder companies are scared to death about protecting their data when moving to the cloud!

The data residency issues are especially big for some of our European customers. This is certainly true for multi-country services, where one has to restrict data residency for data at rest,  but also where mandates exist for where data can be processed. Imagine when you are dealing with financial, healthcare and other sensitive data for a specific country and they ask that you not only store that data in a place that is within legal boundaries of that country, but also ask that you process the data within the data centers located in their country as well.  You are faced with yet additional requirements including a need to sanitize data, route messages to services located in a specific place, desensitize the data for processing, and sanitize it again for storage.

Essentially, your solution needs to be:

• Have a strong encryption engine which has all the possible security certifications that you can think of – such as FIPS 140-2 Level 3, DoD PKI, CC EAL 4+, etc.
• Use very strong encryption standards/ algorithm for data, whether in storage or in transit.
• Protect the encryption keys with your life. There is no point in encrypting the data yet giving away the “Keys to the Kingdom” easily.
• Have a solution that can sanitize the data very dynamically and very granularly, based on either pre-defined policies (such as XACML, etc.) or DLP based.
• Make a decision based on the content/context and protect the data based on the need. This means having the flexibility to encrypt the entire message, specific sensitive data in the message, have an option to preserve the format of the sensitive data of the message and/or tokenize the data based on the need.
• Encrypt the message while preserving the format, so it won’t break the backend systems.
• Tokenize the PCI and/or PII data for compliance and security reasons.
• Scrutinize the message more deeply if the message is intended to go to a non-secure location/ endpoint – such as mobile devices, cloud location, third world country, etc.
• Comply with data residency issues by mandating the processing and storage of data in to a specific instance of the service based on where it is located.
• Have an elaborate access-control mechanism to the data based on user/ application clearance, data classification and the time and day of the access request.
• Most importantly, all of the above should be policy based which can be dynamically changed based on the need.
• Do all of the above seamlessly (or “automagically”).

In part 2 of my blog, I will discuss how Intel Cloud data privacy solutions (or the Cloud encryption / tokenization gateway) elegantly solves this problem and should be the only tool kit you will ever need in your arsenal to solve this issue.

In the meanwhile, you can check out information about our tokenization and cloud data privacy solutions here.

Intel Cloud Data Privacy/ Tokenization Solutions

Intel Cloud/ API resource center

I also encourage you to download the Intel Expressway Tokenization Broker Data Sheet:

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

Andy Thurai is Chief Architect and Group CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Mobile, Big Data, 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 25+ years of IT experience.

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

The post Content / Context / Device Aware Cloud Data Protection appeared first on Application Security.

We are announcing today the availability of a new product called Intel(R) Expressway API Manager, which we call a composite API platform. What we’ve done here is integrated the Expressway Service Gateway with the developer portal and developer management features from API management market leader Mashery!

Composite API Platform

The solution is a composite because it’s ideal for large enterprises who want a hardened security gateway on-premise but also want the cost savings of a SaaS cloud for developer registration, sign-up and management. Further, Mashery has the benefit of experience, as they have been ‘doing’ API management since about 2006; their product is highly mature and a great match for Expressway.

Both teams are very excited about the new offering. Let’s highlight some of the features:

• It’s an Intel product sold and supported by Intel. We think this is important for Enterprises that want to make an investment in API management from a large vendor
• Intel customers get access to all gateway features including: RESTful service enablement, service orchestration, composition, provisioning, all authentication features, protocol and data format mediation, trust and threat processing, SLA management and API rate limiting.
• A new API console provided by Intel allows you to manage gateway services as APIs
• Intel customers also get a subscription to the Mashery cloud for developer on-boarding, registration, portal administration, content management system, community tools and developer enablement tools
• Mashery and the Intel Gateway are fully integrated for access control, basic policies and analytics, with more integration planned for the future. This means Intel customers can use Mashery for developer registration, key generation, and provisioning API rate limits

We wanted a solution that would address large Enterprise requirements which often require “on-prem” traffic processing using a certified gateway but still offer the advantages of a SaaS cloud for evangelizing APIs to internal or external developers or business partners.

Blake

The post Announcing Intel(R) Expressway API Manager appeared first on Application Security.

We are very excited to announce an Intel API management solution that was released today. The Intel® Expressway API Manager is a composite API platform.

Just creating outstanding APIs is not enough. Intel realized that you need to have a mechanism to communicate, explain, onboard, collaborate, and manage developers. Our API manager provides a composite solution that provides On-Premise and Cloud deployed API portals, and a mechanism to manage your APIs and help with developer on-boarding, registration, portal administration, content management system, community tools and developer enablement tools.

Initially I was going to write a blog about what we do best and how we are different. But I was amazed just looking at the amount of features we released in this version. So I am going to save the story and give you the straight facts below:

As part of our new solution, we provide the following:

• Easily launch a secure website for API partners. Create an online portal, with your look and feel, for enrolling and supporting developer partners.
• Take the hassle out of key management. Make key provisioning a snap, whether you’ve got a few partners or tens of thousands. Issue live keys, or require activation by a moderator.
• Keep partners engaged with reports and tools. Show partner developers how many calls they’re making, which methods they’re using, and more.
• Publish interactive API docs. Developers can execute calls directly from your API documentation.
• Run a support forum and a developer blog. Foster an active developer community with full-featured forum and blogging tools.
• Single Sign-on. Connect to your own identity store so partners don’t have to log in twice
• B.Y.O.P.: Bring Your Own Portal. If you prefer, use Mashery’s API to plug in your own content management system (CMS)
• Third-party Integration. Add outside services–such as billing engines–to your portal using Mashery’s API
• Partner Management. Enable/disable keys & developer permissions
• Your Branding. Use Javascript and CSS to completely obey your brand’s look-and-feel
• Built in with Mashery. Never worry about installation or hosting.
• Markdown Compatibility. Let forum users post formatted code samples using the popular Markdown syntax
• Role-based Access Control. Create walled-off content for beta testers and other special partners
• Comment Engine. Allow partners to post comments to your documentation
• API Value Tracking. See how your API drives key performance indicators such as traffic, purchases, and registrations.
• Detailed Activity Reports. View API usage and trends by developer, key, and method.
• Mashery Reporting API. Access all reporting and chart data through an API.
• Reports-only Role. Securely share reports with colleagues outside your API team.
• Partner Monitoring. See all activity for a specific partner or app.
• Latency Measurement. Track response times for your API service and for Mashery
• Load Statistics. See average and peak loads by endpoint over time.
• Data Export. Download reports in CSV format for use in Excel.
• Custom Report Integration. Grab call logs and report data for use in third-party applications
• Manage APIs as products. Tailor API access to suit the needs of your most important customer/partner segments.
• Define API access plans. Create custom access plans (standard, premium, etc.) without any coding.
• Get fine-grained control over resource packaging. Choose which API resources (methods) are included in each plan.
• Create response filters. Strip out response content for a plan without coding.
• Reduce work for IT. Let business-side execs securely package API access.
• Maximize API value. Give business development, marketing, and product management teams the power to negotiate custom API access.

Guess what, built into this solution is a world class API gateway solution (refer to my performance numbers and security certifications blog on this) which includes RESTful service enablement, service orchestration, composition, provisioning, all authentication features, protocol and data format mediation, trust and threat processing, SLA management and API rate limiting.

Check out Intel® Expressway API Manager for more details. I am also doing a joint webinar with Mashery on Dec. 4, “Secure, Expose, and Package APIs as Products.” You can register here.

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

Andy Thurai is Chief Architect and Group CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Mobile, Big Data, 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 25+ years of IT experience.

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

The post Get the Straight Facts…API Manager Revealed appeared first on Application Security.

Welcome back, and thanks for continuing to read our blog series on reducing PCI Scope.  In our last blog we covered why reducing PCI Scope is so important.

Before we address common approaches to Tokenization, let’s recap what PCI DSS Tokenization is:

What is PCI DSS Tokenization?­­

PCI DSS Tokenization is a means for protecting credit card data by substituting a different, non-encrypted value for a credit card number.   Usually this takes the form of random number (with some of the first digits and ending digits preserved) that appears to back end systems to be a valid credit card number.

It is important that the random elements of the token (that is the digits that are not preserved) are not in any way derived from the actual credit card number.  [i] This randomized token is stored in a secure vault, which defines the mapping from the PAN to the token.

Common Approaches to Tokenization:

The first choice that merchants must make when embarking upon a path to scope reduction through tokenization is whether to build their own tokenization technology or to acquire it from a vendor (Intel/McAfee is of course such a vendor).

In the past merchants chose to build their own solutions as commercial PCI DSS Tokenization products are relatively new (with formal guidance from the PCI Counsel only appearing in late 2011).[ii]

In order to keep this blog post to a manageable length we will concentrate on the merchant data center rather than addressing both the point of sale locations and the data center in one post.   The same principles that apply to the data center are applicable to the retail locations as well. I invite those interested in a subsequent article on point of sale scope to contact me.

Figure 1 below shows reference architecture for retail data centers.   It does not represent any particular merchant’s data center, but rather represents a set of common components aligned in a typical architecture.     Virtually every retailer has an authorization path for data, a clearing path (that is usually a mainframe with batch processing of results in TLOG or similar formats), and provisions at the point of sale to process transactions in case the internet is not available at the time of the credit card charge.

The post Cost Effective PCI DSS Tokenization for Retail (Part II) appeared first on Application Security.

Sooner or later the following (not so hypothetical quandary) will undoubtedly arise: When moving your data to the cloud, you’ll be faced with an array of decisions that will need to be made. What considerations will you make for the protection of your data? In the not-so-distant past, you most likely invested a lot of time and resources into building “enterprise Ft. Knox” – a state-of-the-art, highly advanced and very expensive solution replete with several sophisticated gadgets, strategically positioned around the enterprise perimeter. You had a moment to breathe a sigh of relief, taking solace in knowing that no one could penetrate the fortress you built. You even went so far as to give yourself a pat on the shoulder, enjoying the moment.

Alas, the respite ended with a tap on the shoulder! The King, also known as the CIO, has informed you that the rules have changed! Apparently, when you were working hard building this impenetrable boundary around the edge fixing the exposure, he made a deal for the kingdom (in this case, your company), that expanded its territory. As a result, the short but life-changing edict is to move processing to a third-world country (in other words to the cloud). Gulp.

Medieval comparisons aside, the matter of fact is that your IT systems have been moved to the cloud – public, private, or hosted. With the stroke of a quill (or pen), the circumscribed limits of your perimeter have changed. Unfortunately, protecting your databases, processes, applications, app servers, web servers, systems, middleware, and back-end systems won’t work anymore, and as in most similar scenarios, you’ll have absolutely no control over them in a cloud environment. It’s highly likely that you won’t even know where things are even running most of the time.

The advantages of moving to the cloud cannot be denied, but the new paradigm-shift is not without headaches and real concerns that come with data privacy, security, auditing, compliance, residency (at certain times you can’t let the data leave certain countries for example), in addition to having to worry about being exposed to hackers on a 24×7 basis.

Now what? Well, there is an easy way to solve this problem. Instead of protecting all of the above, you can simply just protect your data instead. This is exactly where Intel cloud encryption/ data privacy gateways shine. We created these gateways a few years ago, keeping the ever-changing landscape in mind.

So how do we do it? Well, for starters, the Intel cloud encryption gateway is the ONLY solution that is available in multiple form factors – as an appliance, software and virtual. It can also be available as a hosted solution, through our partners if you should choose that option. Our appliances are not “virtual appliances” unlike competing vendors in the market. We provide a “true” appliance. This is imperative in the security field, especially when you need FIPS 140-2 Level 3 compliance in the government (or other highly secure environments like the healthcare) space. (As a side note, I recently read a competitors spec where that company claimed to “enable” you — so you could plug in and use FIPS 140-2 if needed. It’s not certain what they exactly meant or how to parse the finely nuanced language used in their advertisements. In contrast, we are completely straight-forward about our enterprise class capabilities. And, yes, we have that feature built in already.)

In addition, our appliance has a unique set of features that include: tokenization, encryption, Format Preserving Encryption (FPE), as well as others that will help ensure the authenticity, integrity, and validity of your data. That’s not all. What makes us unique is that our cloud encryption gateways are built to fit your current eco-system. This means that regardless of the protocol, identity system, logging system, monitoring system, or data/message type, we can encrypt/tokenize the data that is flowing in and out of your organization.

Let’s think about that for a second. You get these appliances, drop them in the line of traffic, do a few configurations, and you are done. Either you keep the sensitive data and send the tokens to the cloud, or alternatively, send the protected (encrypted) data to the cloud and keep the keys to yourself. This allows you to be compliant and mitigate your risk. There are no more long drawn-out IT engagements, nor nightmare filled sleepless nights trying to figure out what will happen when moving your sensitive data to the cloud.

This is really important where time to market (TTM) is the key. We can have you up and running and poised for being production-ready, in a matter of days (or even in a matter of hours as most cases call for). When making a decision, It’s also essential for your calculus to include ROI and TCO. When you buy a similar solution from someone else, make sure to ask yourself these questions: Will I have to spend hundreds of hours building this? How long will it take me to integrate this within my eco-system? We can get you connected with most existing enterprise systems such as logging, monitoring, auditing, middleware, identity systems, database, (web) services, and SIEM systems such as Arcsight/Nitro quickly. And you get the added advantage of having mobile enablement already built-in.

There’s one last note of chuckle I want to share. I saw a competitor’s blog suggesting that they are rated by Gartner, for tokenization and encryption gateways, and are rated “close enough”, to Intel & McAfee in this area. I just want to close this out by saying we are Intel-McAfee, and we thankfully don’t feel compelled to make similar associations with someone, just to bolster our viability or engender notions of greater stability. We genuinely care for our customers and know that we will be here for many years to come.

I encourage everyone to download a very topical paper on the subject regarding Intel Expressway Tokenization Broker:

Please contact me if you need more information. I’m more than happy to send you any additional information that you may need.

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

Andy Thurai is Chief Architect and Group CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Mobile, Big Data, 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 25+ years of IT experience.

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

The post Who is more sensitive – you or your data? appeared first on Application Security.

With PCI-DSS 2.0 compliance newly mandated and recent guidance on PCI DSS tokenization[i] this is an excellent time for merchants to review their compliance and PCI scope reduction strategies. One of the more common approaches to reducing PCI DSS Scope (and hence the cost of assessments and the associated costs of remediation) is to tokenize PAN data within the enterprise.

While this blog series focuses on tokenization within a retail environment, the approaches and results are equally applicable to any tier 1 or 2 merchant with a large investment in existing data centers.

Why Reduce PCI Scope?

Most, if not all, tier 1 and tier 2 merchants are already PCI compliant and view continuing compliance as a cost of doing business. Why would the merchant decide to change its IT infrastructure to reduce PCI scope?

To paraphrase the PCI DSS 2.0 Standard [ii], PCI DSS Scope may be defined as a set of all systems that store, transmit or otherwise have access to Personal Account Number (PAN) data. That is any system that accesses credit card data in any way (encrypted or not) is potentially within PCI Scope.

Since PCI Scope is the set of systems that must be evaluated by a Qualified Security Assessor (QSA) for compliance, the cost of an assessment is directly related to the size of the task (and therefore to the size of the PCI Scope).

The average assessment costs for Tier 1 merchants are $225,000 (with 10% exceeding $500,000 annually)[iii]. This only includes direct out of pocket fees to QSA organizations and does not include the time and resources that the merchant must apply to bring systems in line with the standard.

The largest and least predictable cost is in remediation of PCI inadequacies. As a result of the yearly assessment, the merchant often has a list of remediation activities and compensating controls that must be implemented in order to maintain compliance. Often these involve disrupting or upgrading existing systems or changing where in the network or on what physical servers systems may reside. The cost of this remediation often dwarfs the cost of the annual assessment and may be revisited every year.

As much of the standard is subjective and compliance is up to the discretion of the QSA, a determination of point in time compliance one year, is no guarantee of the same outcome in the following year (even with no or minimal changes to IT infrastructure).

So not only does a large PCI Scope mean a large assessment cost and potentially larger remediation costs, but additional risk to unplanned expenditures caused by IT disruption even for IT systems that change little between assessments.

In short, it is important to reduce scope as much as possible in order to reduce both ongoing costs and the risk of large, unplanned IT expenditures. One obvious strategy here is to reduce the risk as much as possible and ‘delete’ the data. Deleting the data may involve moving the problem to someone else, changing existing business processes to remove PANs, or relying on tokenization to shrink the PCI footprint.

Common Strategies for Reducing PCI DSS Scope

Common strategies for reducing PCI DSS Scope include the following:

1. Outsourcing all credit card processing and credit card handling to another vendor.
2. Eliminating all stored PAN data from the network.
3. PCI DSS Tokenization

The first option is by far the best at reducing scope. If handled properly there is very little or no PCI DSS Scope left for the merchant. This approach is not always practical for a variety of reasons including that existing IT systems could not accommodate the change and it is often preferable for the customer to enter into new transactions without re-entering credit card data. Moreover, large merchants often can’t change existing business processes that rely on PAN data, as it may involve re-training or re-deploying existing personnel or even changing the way business is conducted, if PANs are used for analytics or in other business functions such as CRM.

The second strategy often cannot be applied uniformly due to the saved credit card problem as described above and often data warehousing applications need a unique identifier to track purchases from an existing customer (perhaps to identify profitable and unprofitable transactions and customers). Since not every customer will be a member of a loyalty program, often PAN data is used to track customer activity.

The rest of this posting will concentrate on PCI DSS Tokenization

What is PCI DSS Tokenization?

PCI DSS Tokenization is a means for protecting credit card data by substituting a different, non-encrypted value for a credit card number. Usually this takes the form of random number (with some of the first digits and ending digits preserved) that appears to back end systems to be a valid credit card number.

It is important that the random elements of the token (that is the digits that are not preserved from the original PAN) are not in any way derived from the actual credit card number. [iv] The random number is stored in a secure vault, which defines the mapping from the PAN to the token.

If this is accomplished properly, the following results occur:

1) Any breach of documents with tokens rather than actual credit card data is useless to an attacker as the attacker does not have access to the token vault which stores the mappings.

2) There is no offline attack vector for deriving a decryption key and therefore compromising tokens.

3) Systems that only touch tokens and not actual PAN data may be removed from PCI Scope and are therefore not susceptible to the direct costs or remediation exercises for PCI compliance.

4) Systems that are thus removed from scope may now have past remediations and compensating controls removed in order to free up MIPS for business processes or in order to delay or eliminate the need for costly hardware and software upgrades.

5) Contrasted with encryption, tokenization does not incur a large key management problem at each system that encrypts and decrypts data – key management is centralized to the operation and maintenance of the vault alone.

Conclusion:

There are two primary reasons most merchants evaluate PCI DSS tokenization options.

1) To reduce the cost of PCI DSS compliance (as cost is directly related to scope)

2) To increase security and to drastically reduce the risk of a data breach.

Given these constraints, my colleagues and I are under the contention that the best option is often to begin at the data center where there is the most value gained with the least effort and then utilize this effort to inform the decision of how best to secure other parts of the enterprise.

In my next blog post, I’ll discuss three common architectural approaches towards data center tokenization.

While we continue to explore Tokenization, I encourage everyone to download a complimentary copy of PCI DSS Expert and QSA Walter Conway’s PCI DSS Tokenization Buyer’s guide available here

The post Cost Effective PCI DSS Tokenization for Retail (Part I) appeared first on Application Security.