The thing that always gets me the most about Las Vegas is how easily you can get lost at the tables. The craps table, the blackjack table, the poker table. There are endless tables with blinking lights and 8bit soundscapes that soak up your time and energy, leaving you feeling dried up, spat out, and generally wallowing in malaise. But, one table I'm proud to stay stood out from the crowd: the Black Hat Embedded Security Round Table I ran with my good friend Zach Lanier.

Like any table in Las Vegas, we were met with a lot of different personalities, perspectives, and motivations. None of us sat down at our round table as perfect people, but I feel that we all came away thinking more deeply about the strategies that will help define security for the coming world of Things.

Figure 1:

Zach and I had the pleasure of running Black Hat's first ever round table, not just the first embedded security round table, and so we weren't quite sure what to expect. We didn't quite travel down all the paths I intended to tread, and we certainly didn't poke at all the bears I intended to prod, but some imperative points were made.

While I could go on and on about these points for days (and I will if you buy me drinks and/or sushi) I'll briefly comment on each of these points from the perspective of the Round Table.

Threat modeling
While this is not a new concept, many of us in information security and engineering have either evaluated or deployed Embedded/IoT projects with little or no threat model. A recurring theme at our round table was the necessity of threat modeling. While the term itself was not often used, the concepts behind threat modeling were.

Embedded systems threat modeling is about understanding not only the technology, but the business model around the technology, and the environment in which the device will be deployed. These three key attributes of a deployed product create wild variances in the cost and components required to deliver the security assurances that match not only the company's security goals, but its fiscal goals. If a threat model cannot accurately translate the threat of financial loss into security controls that mitigate or remediate classes of vulnerability that can lead to financial loss, then the security team has not done its job. If the security team does not have the information required to identify which risks are a priority to the business, the management team has not done its job.

Threat modeling is a team effort, and can take a considerable amount of coordination and effort to bootstrap. Regardless, the result of this effort can and should be a process that enables the expedited development of a threat model for each new product or service a company develops.

Projecting changes
Businesses are not static, that's just a fact of life. We like to believe that Apple suddenly appeared from the ether slinging thin black smart phones at our faces, but it didn't. It took it decades to get to that place. Groupon is a better example. It first deployed as a simple community organization service, but pivoted into selling coupons when it realized it was a better sales model. Services that are deployed or in development during a pivot must be reevaluated for new risks. If any of the three key components of a threat model (the technology, the business model, or the deployment environment) change, risks must be reevaluated to ensure existing controls accommodate for the changes.

One way to do this is to brainstorm with the management and business development teams on potential use cases of a particular technology -- not even from a "widget" standpoint but a business standpoint. In other words, engineers tend to think of a WiFi module as a component that connects wireless local area networks. A bizdev strategist may think of this same module as a channel for relaying marketing data. If a deployed device that traffics marketing data is compromised, the bizdev strategist may not see much value in securing the communications channel. But, if the bizdev strategist considers the possibility of critical back-end databases being compromised, critical databases that monitor, evaluate, and prioritize marketing data, the priority for security will surely change.

Classifying the security requirements of these changes is enormously valuable. While we certainly can't predict every possible use case, we can build scaling models based on the potential value attributed to a component or communications channel. For example, what if we reconsider the WiFi module? Instead of thinking of the data that does move through it, let's think about what data could move through it. Can we classify the data as having a low, medium, or high security priority? What changes should occur in the product design to accommodate for each security classification? If this is 

defined, it doesn't matter where the business goals of the product pivot toward, changes can be quickly made based on the new security classification by using preexisting models defined during initial threat modeling. Not bad, eh?

SDLC integration
This is another thing we preach often in Information Security: Systems Development Life Cycle integration! Security is not some separate and enigmatic exercise carried on by wizards, despite the fact that some of us in this industry would like everyone to believe such a thing. Actually, security is simply good engineering! Why? The more steps that are taken to ensure security, the less an unexpected action may occur due to an adversary (or simply an accident).

In other words, solid engineering clearly defines the behavior of a product or service, and restricts that behavior to a predefined set, even if the behavior is an exception or anomaly. Security simply integrates the idea that an adversary may try to take advantage of anomalous behavior in a manner that benefits the adversary. By augmenting the SDLC, engineers no longer ask, "Why would someone ever interact with our product in that way?" Instead, they ask, "How do we ensure a stable working environment if someone attempts to interact with our product in this way?" This simple "thought inversion" can save a company hundreds of thousands of dollars in engineering costs when a critical vulnerability is found, and potentially millions in revenues.

Security frameworks
In 2012, when I initially executed my DARPA Cyber Fast Track project, the Internet of Things could be broken up into several seemingly disparate models based on verticals in embedded industries. At the end of the year, I noticed a very obvious trend: The embedded/IoT models were collapsing into a single vertical. While there are multiple verticals from a business perspective, there were no longer multiple verticals from a component perspective.

Since everyone was essentially using the same model across all verticals to design and deploy Internet of Things technology, a framework became almost too simple. But, there are a lot of unexpected issues with IoT security frameworks. This is not because frameworks or IoT technologies hold bizarre surprises hidden under PCB boards (although some manufactured in certain countries might). It’s because the deployment environments for embedded/IoT devices bring unexpected attacks that you would not otherwise see in server or desktop environments.

Over the next few weeks, I will be releasing some of these frameworks on the Lab Mouse Security website. If you would like to contribute to these frameworks, please reach out to me on the Lab Mouse site, or through this blog post. I am looking for reviewers and contributors to ensure that the language and format are usable for all readers, regardless of their technical expertise.

Top-down regulation
Not all of us are interested in safety and security. That sucks, but it's an unfortunate fact of life. Knights, we're not, but even we unsettling imperfect souls sitting in that conference room at Black Hat understand the need for enforcement of security policy. This means architecting security through organizations that can punish entities that refuse to comply. We have the Federal Communications Commission, why not the International Security Commission? Oh, wait, we already have other organizations with the acronym "ISC" and they haven't worked out great for us ... Hmm, we'll have to work on that name.

Regardless, enforcement is an imperative. Perhaps the most important point brought up at the round table. Those of us who care will beat down the doors of decision makers at our companies to build budgets for threat modeling and security integration. Those who don't care won’t lift a finger. We can talk all day about frameworks, models, threats, actors, and more, and it will do the same good it has done us every fiscal quarter since Heartland Payment Systems was compromised: no good at all.

Now that the Internet of Things is fast becoming the most game-changing concept in Internet history, a change must be made. We must come together to help build the next generation of the Internet, to ensure it isn't sagging its jeans at the mall, or getting tattoos in languages it doesn't actually read. If you want to participate in this effort, please reach out to Lab Mouse Security.

The Information Security industry needs a team of technologically skilled individuals and public speakers who are willing to build a new security foundation for the next generation of the Internet. Together, we can make that happen without the rhetoric and hyperbole that sidelines what is a conversation that needs to happen yesterday. Don't let another organization speak for you, let's speak together.

The Internet of Things isn't about a small group of people gaining notoriety. It’s about technology that will change the way our society interacts not only with itself, but with the world around it.