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
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.
- 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/
- 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
- 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.
|[caption id="attachment_210" align="alignleft" width="120"] Jeff Man - Sr. InfoSec Consultant[/caption]||[caption id="attachment_210" align="alignleft" width="120"] Larry Pesce - Senior Managing Consultant and Director of Research[/caption]||[caption id="attachment_210" align="alignleft" width="120"] Lee Neely - Senior Cyber Analyst[/caption]||[caption id="attachment_210" align="alignleft" width="120"] Paul Asadoorian - Founder & CTO[/caption]||[caption id="attachment_210" align="alignleft" width="120"] Tyler Robinson - Managing Director of Network Operations[/caption]|
|[caption id="attachment_210" align="alignleft" width="120"] Jeff Spielberg - Managing Partner[/caption]||[caption id="attachment_210" align="alignleft" width="120"] Ryan Speers - Security Researcher[/caption]|