Mobile APIs for Healthcare

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

By Gunnar Peterson – this post originally appeared on the 1Raindrop blog

New PCI DSS Cloud Computing Guidelines – Are you compliant?

This month the Cloud SIG of the PCI Security Standards Councilreleased 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.

Your healthcare data in who’s hands?

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.

About Peter Logan:

App Engineer & Pre Sales for Intel’s Application Security & Identity Products Group. I spend my time wandering about looking at interesting customer problems and generally getting messaging to go better, faster and safer. What I aim to give here is general tech goodness about actually using Intel® SOA Expressway in real world applications for SOA, security, integration and more. But I hope you find its not just howtos you’ll find here. I also want to talk about why you’d want to do things this way with Expressway.

 

 

Enterprise Mobile Applications at Apps World

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.