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.

• More threat modeling is required in the embedded/IoT space
• Threat models must not only reflect the current business model, but projected models
• Security integration into the Systems Development Life Cycle must be enforced
• A security framework is needed to properly evaluate verticals in embedded/IoT verticals
• Regulation must be enforced by authoritative bodies and guided by engineers/security analysts

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