IoT Security Exposed: From PLC Flaws to the Imperative of SBOM
summary
Detailed case studies show an SD card design flaw that lets an attacker overwrite PLC configs and passwords, a protocol fuzzing issue that stops the main PLC service over the network, and automated firmware analysis that finds multiple vulnerable third‑party components. The Cyber Resilience Act makes SBOMs mandatory, yet an OpenSSH regression in a PLC took 23 days to patch. Advice is continuous multi‑layer testing, SBOM generation and verification, and active vulnerability monitoring rather than blind trust.
AI-written summary · about
chapters (10)
- 0:00IoT security challenges
- 3:21What IoT devices include
- 5:05IoT vulnerabilities layers
- 7:58Supply chain risks and SBOM
- 9:20Cross-layer IoT testing
- 9:42PLC security flaws case
- 14:43Cyber Resilience Act and SBOM
- 16:33Legacy device risks
- 17:39Secure IoT development lessons
- 18:42Verifying SBOMs
related talks
51mIndustrial Control Systems : Pentesting PLCs 101 (Part 2/2)
58mIndustrial Control Systems : Pentesting PLCs 101 (Part 1/2)
49mSBOMs for Evil: From Software Supply Chain Documentation to an Attack Path
30mPractical Attack Vectors and Their Ideal Defensive Strategies for ICS & SCADA
47mWhy is SCADA Security an Uphill Battle?
39mVulnerabilities in Old Third-Party Software Components- Importance of Having SBoM for IoT/OT Devices
52mPanel: Industrial Systems In The Crosshairs: What It Really Takes To Defend OT
21mIndustrial IoT security issues and countermeasures