IoT Slam Day 2 Recap

DZone 's Guide to

IoT Slam Day 2 Recap

The final day of IoT Slam showed off best ways to go about thinking of IoT solutions, focusing on healthcare, data management, and maintaining security.

· IoT Zone ·
Free Resource

Day number 2 of the first live IoT Slam took over where Day 1 left off. But whereas Day 1 was more of a grab bag of IoT goodness, Day 2 drilled down a bit into the changes organizations and individuals need to make to succeed in IoT.

Again, we'll be diving into the more intensive presentations over the next week or two, but for now, here's what you should know coming away from IoT Slam's second, concluding day.


Sarah Cooper, GM of Amazon IoT Solutions, made the argument during her keynote that IoT will fade into the background of everyday life. We've already seen it beginning, she said, from the moment over-the-air updates became a possibility.

"Just the ability to update software created huge changes," she said. No longer do people need outpatient surgery to update a pacemaker. It can be done through the skin. "The opportunity became, 'What can we do with those devices?'"

Now, the focus is on data gathering. Soon, we can expect a more visible shift toward differentiating the quality of data and how to use it.

"Data has a temperature," Cooper said. 

"Hot" data is freshly measured and requires immediate action. Using a robotic arm as an example, hot data would be failure reports, safety notifications, or refill notifications for consumables the arm uses.

"Warm" data, meanwhile, is measured and cached and is less immediately important. General health and diagnostic data for the robotic arm would be considered warm.

Then there's "cool" data. Cool data is stored in batches for analysis with other data. For instance, how is the robotic arm participating with the other units along the line? What's the signal strength?

And then there's "cold" data. Cold data is historical data — useful for providing context and historical insights, but not something you'll need to be frequently calling on. Measuring QA for the robotic arm (not including immediate alerts or safety notifications) falls under cold data. 

In terms of manufacturing, the hope is to move away from static products altogether. We currently have connected product lines, but connecting processes is farther off. Ideally, the hope is to move to a fully connected ecosystem, but given that there's no real incentive for businesses to share data, a requirement for that, that might be something of stopping point, Cooper said.

Cooper also gave some design principles to consider.

Innovation requires experimentation, she said, but product makers need to learn how to properly experiment. It isn't just setting up a CD pipeline, making changes, then keeping what happens to work. Makers need to go back to the scientific method: hypothesis, procedure, analysis, and conclusion.

"It’s not just about designing the data-handling part of the equation," she said. "To fail fast, you have to know you have failed. Limit the blast radius and shrug it off."

Collecting user behavior data is probably among the most invaluable options out there. "It basically gives you bite-sized pieces of function," she said. "And bite-sized pieces of function are easy to change. Limit the blast radius."

Consider a serverless solution for quick, ad hoc tests and experiments, she added, and most importantly, from the business leader perspective, let devs play.

Devs who play learn, and devs who learn innovate. A favored Easter egg might become the next big launchable product.


Security saw no shortage of coverage on Day 2, just as in Day 1. In fact, Dipto Chakravarty, senior VP at CA Technologies, went into the weeds a bit about security architecture during his presentation.

"We tend to apply what we know to new patterns," Chakravarty said. IoT brought lessons from mobile, mobile brought lessons from SaaS, and so on. "And then we iterate, and we fail fast, and we go Agile," then we build from there.

That leads to what he calls Swiss cheese architecture. Sure, you have a solution that works, but you're not considering the wider options at your disposal.

The web used to be browser- and cookie-based. Then mobile brought native apps and WebView. IoT has entirely new requirements, like low-power and an event-driven focus.

So, how does this impact IoT security? Well, the era of passwords is coming to an end. "Passwords aren't the Holy Grail," Chakravarty said. In fact, they're not even very good.

Obtaining someone's password takes between $30-$100. Cracking it can take 3 minutes to 9 hours. Obtaining a device fingerprint? Another hour. With those three in hand, you've got device access.

Instead, designers need to consider a variety of factors — not just direct and indirect authentication, but contextual information (like IP addresses, behavioral factors, etc.) and continuous options (like voice prints, facial scans, or even measuring a person's gait). We'll be diving more deeply into Chakravarty's thoughts and some architectures to consider (and their pros and cons) in another post.

Brian Geisel, CEO of Geisel Software, held a break-out section where he talked about the practical solutions to IoT security.

His advice? You don't necessarily have to be the best, but you do have to be better than the low-hanging fruit out there. Toward that end, avoid these three lines of thought at all costs:

  • "I’m too small to be interesting."
  • "No one’s going to notice this small vulnerability."
  • "We’ll get to security later."

Remember, the minute your product hits the wild, you've actively handed it over to bad actors who want nothing more than to break into it.

He proposed these three security mindsets for IoT devices:

  • Chocolate cake: Both chocolate cake and security are better in layers. Build your IoT security in layers, and always assume each layer will be penetrated to build upon the next. "If you believe your first layer of security is impenetrable," Geisel said, "you’re not going to put effort into the second layer."

  • Leprechauns: Anyone passingly familiar with Irish folklore knows about leprechauns, who hide their gold at the end of rainbows. Geisel brought up how rainbow tables are used to crack password hashes, but how BCrypt, an older algorithm, and salts work to foil them. Keep an open mind when protecting your gold.

  • Three Musketeers: "One for all and all for one" works as a snazzy catchphrase for the king's defenders, but it's horrible for IoT. We saw how Mirai brought down Dyn (and a good chunk of the Internet) in October, so why would people continue to distribute a single key to go with their product line? "The second you ship out a single key, you lose control," Geisel said.

And finally, include an update mechanism. If you don't have a way for users to update their firmware, not only do security holes remain unpatched, but you can't introduce new features down the line.


Healthcare was a huge focus of Day 2. With costs rising daily and privacy and security concerns abound, the added equipment IoT brings and the idea of opening up data to more eyes can be a frightening concept.

Unfortunately, there weren't many concrete answers to those concerns. CommonWell and Carequality are two organizations working together to create new standards for data sharing across healthcare. Their recommendations will be considered as addendums to the 21st Century Cures Act.

As for costs, it seems like that will depend on how individuals use IoT. Insurance in the US is moving increasingly toward a catastrophic coverage model, wherein they pay only for emergency care and maybe some basic preventative procedures. The solution? Wearables and integration.

For example, your Fitbit should track your steps while you log what you eat in an app. If you integrate those, you'll get a single space to monitor how long you've walked and what you've eaten. It can tell you if you're being healthy, assuming you have the discipline to keep going with it. That monitoring is what will save users money in the long run from their doctors.

Apart from that, the future of IoT healthcare looks like it's going to revolve around predictive analysis. Systems will be able to recognize the signs of sepsis or a stroke in patients so the medical staff can act quickly, sometimes even before the problem starts.

John Gresham, VP of DeviceWorks, reminded the audience that technology is only one part of an important triad. Without focusing on people, namely training staffers and considering new positions like care managers, and processes, which will determine how a solution is put together, the technology is largely meaningless.


Overall, IoT Slam was a mix of new and already-established knowledge. Security and privacy are a concern, and there is a way to go. Still, there are ways you can achieve an above-baseline level of security for your projects — and you absolutely should. The biggest takeaways were:

  • Have a use case in mind. Creating a product for the sake of it is a recipe for a lack of adoption. Make sure you're thinking of a problem to solve.

  • The skills gap is one of the major factors holding IoT back. There just aren't enough knowledgeable people working on solutions, and the general public probably isn't technologically literate enough to take advantage of IoT for the time being.

  • Edge computing will become increasingly important. The ability to have compute power and analytics capabilities close to the data source will be invaluable and open up new opportunities to make use of data.

  • The IoT is bound by your imagination. Even if it won't play a core business role, it can still save costs elsewhere, like through smart lighting. Think outside the box.

Again, we'll be diving into several of the individual presentations over the next week or two, including thoughts on blockchain and IoT and advice on how to think about security, so stay tuned! And if you tuned into the Slam through our virtual pass, we hope you enjoyed the presentations! 

healthcare, iot, iot security, iot slam 2017

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}