Mark O'Neill and I just published Top Ten Security Considerations for Internet of Things. It was very a lot of fun to work on this on a personal and professional level. I have been a big fan of Mark's work for along time. I only got to work with him once before when we did a full day of Web Services security at the OWASP AppSec conference, we had a full day just on WS and had a great lineup of speakers including Mark and Brad Hill.

Turns out that Web services play a leading role in Internet of Things, and the space is so full of amazing use case right now, its great to be able to tackle the security issues and work to get more secure applications than the industry managed to do for the original Internet.

We have learned a lot in 20 years on the web and now is the time to apply it to IoT. Its not so simple actually because some new curveballs come into consideration due to the nature of IoT systems. The paper is available here, and below is a summary of the top ten.

The Internet of Things (IoT) is an industry megatrend that
holds the promise to open up new ways of doing business and communicating. The
core difference between Internet of Things and previous computing revolutions
is that the human user is usually the catalyst, we go to our PC to do some work, we go to the Web to do some research or check mail. In the Internet of
Things, the thing talks back.

Context matters in security and that goes double for IOT.
The IOT use cases that have appeared so far tend to be very domain specific.
That trend looks set to continue. We will examine scenarios in the Automotive
and Utilities industry to look at the unique security considerations in those
IOT environments.

So let’s “State the problem” by listing the Top Ten Security
Considerations for the Internet of Things:

1. Protocol Proliferation

This is the Web but not as we’ve known it. The myriad of IOT
protocols make the security architect’s job vastly more complicated than web
app security which deals primarily with HTTP.

2. Initiation

IOT has many different ways to initiate the protocol dance:
active clients, passive clients, client initiation, and server initiation.

3. Keys

Many current IOT devices rely on hard coded access keys,
leaving them vulnerable to brute force, spoofing and other attacks.

4. Names

The IT industry has become reasonably good at identifying
human users, with Active Directory, LDAP and application user databases, but
objects? Not so much. Consistent naming is the key to defining and enforcing
policy.

5. Constrained Devices

Despite the challenges in IOT we do have many security
protocols to choose from, however the deployments are limited by the processing
power on the device side.

6. Time

There are many IOT technologies, such as NFC (Near Field
Communication), for smartphones and similar devices that do not have the
concept of time. This may not seem like a security issue, until you realize
that virtually all authentication protocols use time as a primary defense
mechanism.

7. Usability

Will existing protocols like Kerberos, X.509, Federation,
OAuth, SAML and others be up to the challenge of securing Machine to Machine
communications when there is not a user present to initiate?

8. Patching

Vulnerabilities will be found in IOT systems, but how will
they be patched? IOT systems require management systems for patching and
versioning.

9. Stunt Hackers

Hacking IOT is a great way to generate headlines, there will
be an endless flow of security research, the more interesting the device the
more the attacker interest.

10. Ugly failure modes

IOT apps are real things, when they fail so does your power,
your supply chain, your fleet tracking and so on. Worse as we discussed in #7
Usability retry and restart may be somewhere between difficult and impossible.

I have no interest in investing in IPOs, so I won't be buying Twitter's. It may do fine, who knows?

I do have an interest in trying to figure out how durable companies' competitive advantage is. When I think of Twitter, one obvious comparison is Facebook.

Facebook went through a much maligned IPO, it came public in the high 30s, cratered down south of 20, and was last seen heading north of 50.

Of course, short term price movers are about sentiment, Facebook rules ($38 at IPO)! Facebook sucks ($19)! Facebook rules ($50)! But this is so much noise, the important part is the moat which is determined by the competitive advantage. A big part of this is stickiness.

To me, Facebook does have a certain amount of stickiness. I am not a Facebook user, but its users upload gobs and gobs of stuff. The sheer amount of stuff, the dialogs around this leads users to 1) come back and 2) makes it hard for them to pick up and move.

I am a Twitter user (@oneraindrop) so I know more about that one. I enjoy it, but I can easily go days without worrying about checking Twitter. More to the point, I don't put much effort into maintaining twitter feeds, I do not often go back and check old tweets, and most importantly if a better messaging tool came along, how hard would it be to move to it? I think the time spent moving to a new messaging client would be measured in minutes and the end experience could likely be similar to Twitter.

Moving off of Facebook, would take much, much longer, and you would have to rebuild deeper relationships. Whereas Twitter is very point in time, so it would just be pointing your new messaging client at the next messaging service, and you are up to speed on the conference conversation or whatever. People have whole parts of their lives, family, vacation, illnesses and more on Facebook, its a real snapshot of their personal history and it exists on Facebook. Whereas, on Twitter do people worry much about perserving who tweeted what at a conference in 2009? I suspect Twitter's move to Favorites is one attempt to make it stickier, but again - anyone use del.icio.us recently?

Maybe I am missing something, may they do, but it sure looks to me like Facebook has created a way stickier long term relationship. What do you think? Am I missing something on Twitter's stickiness?

Security Metrics crying need is for metrics that serve others, outside of infosec.

In Infosec, we think of the biggest influencers as the people who give talks at conferences, I disagree. Here is my list of the top five influencers on your security, these are the people who will impact security, positively and/or negatively

The Person Coding Your App

Your DBA

Your Testers

Your Ops team

You

With the possible exception of #5, none of them work in security. This is alarming because, the security industry markets almost exclusively to security teams. Yet with very few exceptions every security decision is made outside of the Information Security team. Decisions that shape our security are made by developers, admins, architects, "the business", DBAs, customers, users, and on and on. Infosec is one very small department, yet our metrics, "breach reports" and the like are tailored to this tiny rounding error of a department (and, of course, the people who fund them).

A good way to get better, more useful security metrics is to focus on the crying need of security metrics that help other parts of the organization. FInd ways to get useful information into other team's hands, help them make and run better software.