Wednesday, July 1, 2015

Axway (Vordel) API Gateway skills required in Raleigh, North Carolina

Readers of this blog might be interested in this position in Raleigh, North Carolina, for a Network Security Engineer (API Gateway). Responsibilities include to "Manage and Design highly complex firewall and network environments for security of Fidelity's critical resources and enablement of revenue producing services". API Gateway skills are required, with Vordel (Vordel was acquired by Axway in 2012) specifically mentioned.

Good luck!

Tuesday, June 30, 2015

API First, beyond "portal first", for Electronic Health Records

This week, ProgrammableWeb has a very interesting article by Martin Brennan about how Electronic Health Record (EHR) portals are moving to use APIs. He quotes a Health Data Management story which says that:
"If the proposed Stage 3 Meaningful Use rule is finalized in its current form, application programming interfaces (APIs) could supplant portals as the preferred method adopted by providers to enable patients to “view, download and transmit” their health information.",apis-rivets-for-the-composable-enterprise.aspx/0

This can be seen as part of the overall movement to an "API First" orientation. EHR began by being "Portal First". But, as Martin Brennan explains, an API First approach enables more innovation by empowering developers to use the patient data.

Of course, security and privacy are never far from mind in this discussion. Once EHR data is enabled via APIs, it's important to ensure that only authorized clients can see their own data. Sophisticated "dynamic authorization" rules can be applied, such as "only the patient can access their own data, unless they are under 18 in which case their parents or guardians can also access the data". An API Gateway is ideally suited to enforcing these types of dynamic authorization policies.

In APAC for example, the Axway API Gateway technology has been deployed as part of a personally-controlled EHR architecture. This is smart since it allows security to be applied at the API layer. Brant DeBow at Mobile Surge explains the security benefits of "API First" well:
"...focusing on APIs bring additional security benefits. With an API, you are separating different layers of your app. There’s a whole host of security issues that can sneak in when the UI is directly coupled back to core functionality."
So it is with EHR portals. By focusing on the API, you not only enable innovation, but you also have a point to apply security. I look forward to EHR moving more and more to being truly "API First".

Friday, June 19, 2015

APIs - the weak security link in IoT / Home Automation - How an API Gateway can help

ProgrammableWeb recently had a story about how Randy Westergren detected that the API into his home controller system was insecure. As he mentions, the response was "No, there is no authentication, your local network is supposed to be safe environment and protected from outside world using Wi-Fi passwords and firewalls" and a recommendation to use a proxy for security.

So this is obviously a bad thing, right? But wait... From a security point of view, it can often be a good thing to deploy a proxy to enforce security. A proxy, or Gateway, acts as a security enforcement point and means that the developers of the API can focus on building the API itself. The API Gateway is specifically designed for security. Last night at the Boston API Craft meetup, I used this slide which explains the API Gateway pattern (adapting a slide from my colleague Daniel Wille - thanks Dan!):

An API Gateway like Axway's API Gateway implements standards such as OAuth and OpenID Connect. This saves the developers from this trouble. It also implements API threat detection, checking for attacks like SQL Injection or (for older style APIs) XML based attacks like the XML Bomb. An API Gateway also does quota management and API usage throttling, plus orchestration of APIs.

Product APIs

You can think of APIs into home automation systems as an example of "Product APIs". Randy Heffner of Forrester often talks about the important of  Product APIs as a class of APIs, which are sometimes overlooked. In his recent report "A Developer’s Guide To Strategies For API Success", Randy says:
" must start by understanding the four major categories of APIs: open Web, B2B, internal, and product APIs. The first three of these are commonly discussed in the industry, sometimes using the monikers public, partner, and private APIs. The fourth category, product APIs, is not often discussed, but is critical as an alternate perspective into brainstorming possible APIs and business ecosystems."
Product APIs can be too fine-grained for external consumption, and indeed they may just "do what they need to do" from a functional standpoint, purposefully leaving security up to a proxy or Gateway. It sounds like this was true in the case of the home automation APIs which Randy Westergren mentions. As well as security, the Gateway provides more value for Product APIs, by orchestrating them into more high-level APIs which are more suitable to high-level consumption.

So next time you hear of a Product API like a home automation API not having security built in, think of how an API Gateway can help. 

Friday, June 12, 2015

API Security - protecting yourself from being the next breach - Boston API Craft Meetup

Over on ProgrammableWeb, Jennifer Wiggins has written a great round-up of discussion about the Buffer API security breach. Although it happened back in 2013, it continues to be a widely-cited API security issue. As Jennifer mentions, one of the recommendations is to use standards, such as OAuth. Ironically, the implementation of those standards themselves has to be secure.

Another good practice is to take advantage of two essential approaches: (a) API Security Testing to proactively probe for vulnerabilities, and (b) an API Gateway to provide protection.

API Security testing is an emerging category, and it's one which I'd argue is distinct from its cousin, Web Application Security. API Security testing has been a big interest of mine for a long time - I recall presenting about REST security at OWASP back in (yikes) 2005. Fast forward to today, and Smartbear is a vendor which provides API Security testing products (see this great blog post on the topic from them: API Security Testing: Think like a bad guy). This, alongside the fact that they are spread between Boston and Ireland, means they are a vendor after my own heart :). API Security testing complements API Gateways very well, as the yin and yang of security - testing and protection.

Next Thursday, June 18, I'm speaking alongside Mike Giller from Smartbear on the topic of "Beyond the OWASP Top Ten – protecting your API from new threats". It's at the Boston API Craft meetup, at 6.30pm at the Smartbear offices in Somerville. Come along if you're interested in API Security (and in not being the next big API Security publicized breach...)

Tuesday, May 26, 2015

Linking B2B with APIs

Bill Doerrfeld at Nordic APIs has written today about how APIs are evolving the B2B landscape. This is a particularly interesting article for me, because my personal background is working for an EDI provider, where I linked EDI processes from the private network to the Internet, over 15 years ago. Vordel was founded to allow new Web Services APIs to be used for B2B. Axway, a B2B software company, acquired Vordel in 2012 to link B2B with Web APIs. This caused a domino effect, with other API Management vendors being acquired shortly afterwards. However, none of the acquirers of the other startups had the B2B depth of Axway.

And since the acquisition we have been executing on that plan. In last month's Gartner MQ for Application Services Governance, in which Axway is classed as a "leader", Gartner reports that: “Axway acquired Vordel in November 2012 to mix integration, governance and cloud functions in a B2B infrastructure offering with API management capabilities, and it has been executing that plan since.”

APIs compliment B2B in many ways. In this white paper by Mark Boyd, I list some of them:
Often there are clear interfaces that make sense with APIs: price catalogs, order status lookups and shipment lookups, for example. B2B will require ways to go in and look at these interfaces, so they are good candidates to have available to partners as an API.
It's very exciting to see the ongoing usage of APIs for B2B, and for Axway to be at the center of this.