The world continues to see a proliferation of highly insecure IoT/embedded products. How can companies making embedded products design security in from the start, and why don t they do it today? Importantly, security needs to be baked in while remaining lean and moving quickly towards an MVP product. Discussions will range from hardware chip selection, cryptographic protocol design, and firmware security — both at the design and security pen test phases.
Visit https://www.securityweekly.com/psw for all the latest episodes!
To learn more about our sponsors visit: The Security Weekly Sponsor’s Page
Hacking IoT Devices
We keep seeing the same vulnerabilities in embedded / IoT – hardcoded passwords, outdated open source packages, unnecessary network exposure. While some exploited vulns are complex chains, most remain simple, fixable issues. However, we continue to see thousands of new embedded devices (consumer IoT to industrial and critical system) that don’t fix these issues (summary of landscape from f-prime at https://s3-eu-central-1.amazonaws.com/evermade-fsecure-assets/wp-content/uploads/2019/04/01094545/IoT-Threat-Landscape.pdf). This creates the need to start identifying these issues earlier in development since patching cycle times in embedded are long.
- Shifting security left
– We looked at our past data from 10 years of services work, and found that it’s more expensive for firms to respond to 1 vulnerability disclosure than it is to do an end-to-end embedded secure design process https://www.riverloopsecurity.com/blog/2019/08/proactive-reactive/
- Where security teams/expertise can help
- Considerations for embedded
– There’s a special order of operations when it comes to embedded systems – hardware changes can be incredibly expensive (for a PCB turn), and there’s a goal to always minimize BOM cost. This manifests itself as issues with chip selection and hardware design which create vulnerabilities from the start – that have no easy fix in the field. This makes the initial threat modeling, architecture, and key design decisions (e.g. chip selection) critical to get right
- Using tooling
– We’ve open sourced some things that may be relevant, such as https://www.riverloopsecurity.com/blog/2019/04/secure-embedded-development-banned-h/ to help developers avoid memory safety issues in the first place as much as possible. Firmware Security Analysis – quickly growing field – There are tools for firmware evaluation, including some open source ones such as https://github.com/cruise-automation/fwanalyzer and more in-depth commerical ones such as one we launched, https://pilot-security.com. If you want, we could talk about what such types of tools can/can’t do – and how people can use them to find bugs early in development.
- Our next webcast is February 13th with Sri Sundaralingam, Vice President, Product and Solutions Marketing at ExtraHop where we will discuss Cloud Native Network Detection and Response! Register for our upcoming webcasts by visiting securityweekly.com, selecting the webcast drop down from the top menu bar and clicking registration.
- Join us at InfoSecWorld 2020 – March 30 – April 1, 2020 at the Disney Contemporary Resort! Security Weekly listeners save 15% off the InfoSec World Main Conference or World Pass! Visit securityweekly.com/ISW2020 and click the register button to register with our discount code!
- Attend RSA Conference 2020, February 24-28 and join thousands of security professionals, forward-thinking innovators and solution providers for five days of actionable learning, inspiring conversation and breakthrough ideas. Register before January 24 and save $900 on a Full Conference Pass. Save an extra $150 by going to securityweekly.com/rsac2020 and using our code to register!