July 24th, 2013

IoT: The Weighting Game

Written by
Category IoT, M2M, Security, Twitter
 

Data Weighting for IoTThis must have been a scary few moments. On March 23, the main Associated Press Twitter account tweeted about explosions at the White House and President Obama being hurt. Guess what happened next? The Dow went down by over 100 points within minutes of the tweet.

So why did this happen? Regardless of whether the trades were executed by an algorithm or a human, both where treating all tweets from that AP feed as equal. They traded  based on the content of a single tweet – and the resulting feedback loop caused the drop in the stock market.

Fast forward to IoT and imagine that each Twitter account is a sensor (for instance, a smart meter) and the tweets are the sensor readings. Further imagine that the stock market is the grid manager balancing electricity supply and demand. If we were to attach the same weight to each data point from each smart meter, a potential attack on the smart meters could easily be used to manipulate the electrical grid and – for instance – cause the local transformer to blow up or trigger a regional blackout via a feedback loop.

Yet strangely enough – when talking about the IoT – the trustworthiness of sensor data does not appear to be of concern.  All data are created equal or so the assumption seems to be. But data have an inherent quality or weight inferred by the characteristics of the endpoint and how much it is trusted. Any algorithm using sensor data would need to not only take into account the data points as such but also weight the data based on the actual capabilities of the sensor, its identity and its trust relationship with the sensor.

I tried to capture this relationship in picture below.

Endpoint Security in IoT

How can we account for the risk that not all data are created equal?

Credit card companies provide a good object lesson in the way they have embraced inherent insecurity. They decided to forgo stronger security at the endpoint (the credit card) in order to lower the bar for use and increase market adoption. But in order to limit the risk of fraudulent use, every credit card transaction is being evaluated in the context of most recent transactions.

A similar approach will be required for IoT. Instead of chasing impossible endpoint security, we should embrace the management of (data) risk in the decision-making process. An advanced, high-performing API Gateway like Layer 7’s can be used to perform data classification at the edge of the enterprise and attach labels to the data flowing through the Gateway and into the control processes.

I’d be curious to learn if and how you would deal with the data risk. Do you assume that all data are created equal? Or does the above picture resonate with your experiences?

August 1st, 2012

Mobile Security & Management for the Enterprise: SecureSpan Mobile Access Gateway

Layer 7 SecureSpan Mobile Access GatewayThese days, enterprises face an increasing array of Mobile Access challenges, from BYOD to mobile device management. We live in an increasingly mobile and app-based world. More and more enterprises have mobile-enabled workforces that need access to enterprise data from personal smartphones and tablets.

But how do enterprises balance access control with the individual’s right to choose the apps they want? How do enterprises grant access to sensitive on-premise data via mobile devices without compromising security?

Enterprises need secure ways to surface internal information assets in mobile ready formats that can be easily consumed by both mobile developers and the apps they create. They need simplified ways to manage how enterprise applications and systems get exposed to mobile developers and apps.

Layer 7′s new SecureSpan Mobile Access Gateway does just that by streamlining the process of adapting internal data, application and security infrastructure for mobile use. Delivered as a policy pack extension to our SecureSpan API Proxy/SOA Gateway, the Mobile Access Gateway provides a centralized way to control security and management policies for information assets exposed via APIs to mobile developers and apps.

Contest: Win a $250 Amazon Gift Card
To celebrate the general availability of the SecureSpan Mobile Access Gateway, we’re having a Twitter contest and giving away a $250 Amazon gift card.

Here’s how to enter:

1. Retweet the following:

Win a $250 Amazon gift card from @layer7  http://ow.ly/cFj9i #L7MAG RT to enter!

Win a $250 Amazon gift card from @layer7 http://ow.ly/cFj9i #L7MAG RT to enter!

Tweet This for a Chance to Win

2. Don’t have twitter and still want to enter? Just leave a comment on this post, telling us your favorite mobile app.

The contest ends Aug 8 at noon. The winner will be drawn at random. If you win, we’ll send you a direct message on Twitter to let you know.

July 10th, 2012

Hey Twitter: API Management = Developer Management

Twitter APIQuick question for you: What matters most, the client or the server?

Answer: Neither —  they are really only useful as a whole. A client without a server is usually little more than an non-functional wire frame and a server without a client is simply unrealized potential. Bring them together though and you have something of lasting value. So, neither matters more and each actually matters a lot less than half.

In the API world, this is an easy point to miss. The server side always wields disproportionate power by virtue of controlling the API to its services and this can easily foster an arrogance about the server’s place in the world. This effect is nicely illustrated by Twitter’s recent missteps around developer management.

The problems for Twitter all began with a blog entry. Blogs are the mouthpiece of the platform. Tucked away within an interesting entry about Twitter Cards and the potential to run applications within tweets (something that is genuinely exciting), can be found a restatement of an early warning to developers:

“(D)evelopers should not ‘build client apps that mimic or reproduce the mainstream Twitter consumer client experience.’”

Ominous stuff indeed. This was quickly picked up on by Nick Bilton writing in the New York Times Bits blog, who pointed out that the real problem is that Twitter just isn’t very good at writing client-side apps that leverage its own API. Stifling competition by leveraging the API power card can only alienate developers — and by extension the public, who are left with a single vendor solution. Suddenly, it feels like the 1980s all over again.

This ignited a firestorm of concern that was well summarized by Adam Green on ProgrammableWeb. Green acknowledged that API change is inevitable but pointed out that this is something that can be managed effectively — which is not what Twitter is doing right now.

The irony of the whole thing is that, in the past, by exercising its power position, Twitter has actually made great contributions to the API community. In mid 2010, Twitter cut off basic authentication to APIs in favor of OAuth, a drop-dead event that became known as the OAuthcalypse. Hyperbole aside, in terms of actual impact on the populace, this cut over made even Y2K look like the end of days. Given a tractable challenge, developers cope, which is really Green’s point.

What is important to realize is that API Management isn’t technical but social. Win the community over and they will move mountains. Piss them off and they will leave in droves for the next paying gig.

The thing I always remind people is that as a trend, APIs are not about technology; they are a strategy. Truth is, the technology is pretty easy — and that’s the real secret to API’s success. You see, the communications are never the thing; the app is the thing (and that is what WS-* missed). Maintaining simplicity and a low barrier to entry counts for everything because it means you can get on with building real apps.

Now, I can give you the very best infrastructure and tools to facilitate API community. But how you manage this community… Well, that is where the real work begins and — in the end — it’s all a lot less deterministic than we technologists like to admit. People are hard to manage but communities are even harder.

If there is a lesson here, it is that APIs are really about potential and that potential can only be realized when you have two sides — client and server — fully engaged. Mess this one up and you’re left with just a bunch of unused interfaces.