IEEE DFW Sensor & IoT Technology

1. Fundamental Best Practices in
Secure IoT Product Development
DFW Sensor & IoT Technology Meetup
Sept 15th, 2017
Mark Szewczul, MSEE CISSP
IoT Security Architect
marks@zimperium.com @vslick1

2. Bibliography - Citation
• Future-proofing the Connected World:
13 Steps to Developing Secure IoT Products
• Copyright 2016: CSA - IoT Working Group
• I am a Key Contributor

3. IoT Best Practices
Top 5 Security Considerations:
1. Design and implement a secure firmware/software update process
2. Secure product interfaces with authentication, integrity protection & encryption
3. Obtain an independent security assessment of your IoT products
4. Secure the companion mobile applications and/or gateways that connect with your IoT
products
5. Implement a secure root of trust for root chains and private keys on the device

4. The Need for IoT Security
• To protect consumer privacy & limit exposure of PII/PHI
• To protect business data & limit exposure of sensitive information
• To safeguard against IoT products being used in DDoS attacks or as
launching points into the network
• To guard against damage or harm resulting from compromise of
cyber-physical systems (CPS)

5. IoT Products can Compromise Privacy
• Product not securely designed, due to vulns:
• Baby Monitors
• Physical Access, LAN Access, Internet Access
• Product is securely designed
• VTech Toys
• But: forgot to use TLS when creating account
• Fitness Trackers
• But: forgot Randomization of BT MAC addresses for privacy

6. IoT Products can Compromise Privacy
Lessons Learned:
• Encrypt all account registration using Transport Layer Security (TLS)
• Implement software assurance techniques within your
development team
• Thoroughly review protocol specifications for security/privacy
updates

7. IoT Products can Launch DDoS Attacks
• CCTV devices from 70 manufacturers had RCE vuln.
• Default passwords across groups of products
• Shodan crawls the web for open ports and takes a snapshot if lacks
authentication.

8. IoT Products can Launch DDoS Attacks
Lessons Learned:
• Implement software assurance techniques within your
development team
• Never ship IoT products without password protection
• Do not share default passwords across a class of devices without
requiring immediate password updates on first use

9. Medical Devices are Vulnerable to Attack
• Wirelessly reprogrammable IMD: Infusion Pump
• Lack of authentication for Telnet sessions
• Wi-Fi WPA for hospital wi-fi network stored in plain-text on the device
• The device was running a vulnerable version of a webserver
• A hard-coded credential was assigned to the File Transfer Protocol (FTP)
service

10. Medical Devices are Vulnerable to Attack
Lessons Learned:
• Implement software assurance techniques within your
development team
• Authenticate access to all ports
• Encrypt keys that are stored on devices
• Provide ability for customers to patch software components
• Do not share default passwords across a class of devices without
requiring immediate password updates on first use

11. Drones are a Platform for Reconnaissance
• ZigBee war driving
• ZigBee malicious firmware injection
• WiFi war-driving returns
• MITM, Rogue AP, etc.
• BlueTooth attacks
• Bluebugging, Bluesnarfing, etc.

12. Drones are a Platform for Reconnaissance
Lessons Learned:
• Carefully evaluate the chosen IoT communication protocols for your
product and configure modes that limit the amount of information
shared

13. Critical National Infrastructure may Connect to the Cloud
• Older ICS don’t have security mechanisms built-in
• Some SmartGrid systems have been taken down: social chaos

14. Critical National Infrastructure may Connect to the Cloud
Lessons Learned:
• Upgrade Legacy Protocols
• Incorporate Safety Engineering into product design
• Implement Secure Interface Connectivity

15. Autos are Becoming Connected & Autonomous
• Attacks on car brakes, transmissions, etc.
• Large attack space: V2V, V2I, V2X
• Research to compromise Traffic Management Systems

16. Autos are Becoming Connected & Autonomous
Lessons Learned:
• Implement software assurance techniques within your
development team
• Do not share default passwords across device classes without
requiring immediate updates
• Implement secure interface connectivity
• Incorporate Safety Engineering into product designs

17. Why Implement “Security by Design”?
• Reduces likelihood of becoming counterfeited/impostered
• Limits PII/PHI being compromised
• May limit liability
• Limit ability for an attacker to cause damage or harm via ICS/CPS
• Reduces likelihood of negative press; loss of revenue

18. IoT Device Security Challenges
• IoT products may be deployed in insecure or physically exposed environments
• Security is new to many manufacturers and there is limited security planning in development
methodologies
• Security is not a business driver and there is limited security sponsorship and management support in
development of IoT products
• There is a lack of defined standards and reference architecture for secure IoT development
• There are difficulties recruiting and retaining requisite security skills for IoT development teams including
architects, secure software engineers, hardware security engineers, and security testing staff
• The low price point increases the potential adversary pool
• Resource constraints in embedded systems limit security options

19. IoT products may be deployed in insecure or physically exposed environments
Recommendations:
• Apply policy based security to force IoT products to update latest
security critical FW/SW
• Identify flexible self-service identity management capabilities for
IoT products
• Identify and encrypt key material within mobile applications when
used to establish trust relationships with IoT products

20. Security is new to many manufacturers and there is limited security planning in
development methodologies
Recommendations:
• Create an IoT security training program for the development team
• Identify and participate in threat sharing (e.g., ISAC) initiatives and
establish a framework for threat modeling the product
• Obtain buy-in from senior management on the need to incorporate
security into the product
• Review and update your development processes to incorporate security
at all stages
• Incorporate privacy by design principles into all IoT product
developments

21. Security is not a business driver and there is limited security sponsorship and
management support in development of IoT products
Recommendations:
• Begin each product development with a threat model
• Derive security requirements from the output of the threat model
and track those requirements through to closure

22. There is a lack of defined standards & reference architecture for secure IoT
development
Recommendations:
• Carefully evaluate the environment in which devices are deployed,
and choose technologies accordingly to the required security level
• Evaluate the performance vs security tradeoff, exploiting the best
matching protocol stack in order to reduce security risks and
breaches
• Evaluate the security features offered by the IoT components (e.g.,
TPM hardware, etc) and use whenever possible

23. There are difficulties recruiting and retaining requisite skills for IoT development
teams including architects, secure software engineers, hardware security
engineers, and security testing staff
Recommendations:
• Create an IoT security training program for the development team

24. The low price point increases the potential adversary pool
Recommendations:
• Consider physical safeguards such as tamper detection to guard
against physical access to sensitive internals
• Lock-down physical ports (including test ports) on the product using
passwords

25. Resource constraints in embedded systems limit security options
Recommendations:
• When possible, use hardware-based security controls to safeguard
sensitive information

26. IoT Startup Security Survey
Key Findings
• Startups don’t consider information stored on a device as sensitive (any sensitive data is stored on a server).
• Users want to share information (sharing mentality).
• Startups rely heavily on the use of COTS services.
• Most startups are using AES, although most also consider encryption to be not important.
• Most devices don’t share a master key shared across devices; admin at server side.
• No security applied to the development environment.
• No threat modeling of products.
• No secure firmware updates.
• Investors don’t seem to care about security, much more focus on functionality.

27. Guidance for Secure IoT Development
IoT Types of Threats
• Spoofing Identity
• Tampering with Data
• Repudiation
• Information Disclosure
• DOS
• Elevation of Privilege
• Bypassing Physical Security

28. Guidance for Secure IoT Development
1. Secure Development Methodology
• OWASP IoT Top Ten
• Microsoft Security Development Lifecycle (SDL Threat Modeling)
• IEEE Center for Secure Design
• Adam Shostack’s book “Threat Modeling: Designing for Security.”

29. Guidance for Secure IoT Development
1a. Build a Secure Process
• Building Security In Maturity Model (BSIMM)
• Identify software defects found in operations monitoring, and feed to development
• Use external penetration testers to find problems
• Ensure host and network security basics are in place
• Perform security feature review
• Ensure QA supports edge/boundary value condition testing
• Identify gate locations and gather necessary artifacts
• Build and publish security features
• Identify PII obligations
• Provide awareness training
• Create a security portal
• Use automated tools along with manual review
• Create a data classification scheme and inventory

30. Guidance for Secure IoT Development
1b. Perform Safety Impact Assessment
• What harm or damage occurs
• from malicious event?
• from device (HW/SW) failure/defects?

31. Guidance for Secure IoT Development
2. Implement a Secure Development & Integration Environment
• Evaluate Programming Languages
• Integrated Development Environments
• Continuous Integration Plugins (OWASP ZAP)
• Testing & Code Quality
• Processes (vetting libraries, Configuration Management / monitor
SC)

32. Guidance for Secure IoT Development
3. Identify Framework & Platform Security Features
• Selecting an Integration Framework
• Device Onboarding
• Configuration
• Asset Management
• Discovery
• Secure Connections
• Cloud Gateways

33. Guidance for Secure IoT Development
3. Identify Framework & Platform Security Features
• Popular Frameworks:
• FIWARE
• AllJoyn
• HomeKit
• IoTivity
• ThingWorx
• Xively
• Embedded Java ME

34. Guidance for Secure IoT Development
3. Identify Framework & Platform Security Features
• Evaluate Platform Security Features:
• Evaluate the security features at all layers to create a defense-in-depth based model
• Popular RTOS:
• TinyOS, Contiki, Mantis, Nano-RK, LiteOS, FreeRTOS, SapphireOS, uCLinux, ARM Mbed
OS, RIOT OS, VxWorks, LynxOS, Zephyr, Win10 IoT, QNX, Linaro, Android Things,
Ubuntu

35. Guidance for Secure IoT Development
4. Establish Privacy Protections
• GDPR, FTC, HIPAA, NIST
• Design IoT systems to collect only the minimum amount of data
necessary & avoid data leakage
• Analyze device use cases to support compliance mandates as
necessary
• Design opt-in requirements for IoT system features

36. Guidance for Secure IoT Development
5. Design in Hardware-based Security Controls
• MCU selection, HSM
• TPM (Trusted Computing Group)
• TEE (GlobalPlatform)
• Incorporate Physically Unclonable Functions

37. Guidance for Secure IoT Development
5. Design in Hardware-based Security Controls
• Use of specialized security chips/coprocessors
• Tamper-detection & tamper-evidence.
• Conductive shield layers in the chip that prevent reading of internal signals.
• Controlled execution to prevent timing delays from revealing any secret information.
• Automatic zeroization of secrets in the event of tampering.
• Chain of trust boot-loader which authenticates the operating system before loading it.
• Chain of trust operating system which authenticates application software before loading it.
• Hardware-based capability registers, implementing a one-way privilege separation model.

38. Guidance for Secure IoT Development
6. Protect Data
• Security Considerations for Selecting IoT Communication Protocols
• Wired & wireless scanning & mapping attacks
• Protocol attacks
• Evesdropping attacks (loss of confidentiality)
• Cryptographic algorithm and key management attacks
• Spoofing and masquerading (authentication attacks)
• Denial of Service and jamming

39. Guidance for Secure IoT Development
7. Secure Associated Applications & Services
• CSA Mobile Application Security Testing (MAST)
• CSA Cloud Controls Matrix (CCM)

40. Guidance for Secure IoT Development
8. Protect Logical Interfaces/APIs
• Do NOT rely on using API keys alone
• Implement more robust authentication / authorization controls
• Guard against replay attacks
• OWASP REST Security Cheat Sheet
• Employ certificate pinning to prevent MITM attacks

41. Guidance for Secure IoT Development
9. Provide a Secure Update Capability
• Avoid malicious firmware:
• Initial firmware via secure manufacturing facility
• Roll-back to avoid bricking
• No DOS during upgrade
• Deny FW downgrades
• Root of Trust: Secure Bootloader, Secure Storage (keys), Signed FW, HW
Crypto, Anti-Tampering, Encrypted FW

42. Guidance for Secure IoT Development
10. Implement Authentication, Authorization & Access Control Features
• Authentication Protection: E2E, TLS, Mutual, MFA
• Certificates for Authentication: PKI
• Biometrics for Authentication
• Certificate-Less Authenticated Encryption (CLAE)
• OAuth 2.0
• IETF Draft 6749: Best Current Practice: OAuth 2.0 for Native Apps
• User Managed Access (UMA) by Kantara

43. Guidance for Secure IoT Development
11. Establish a Secure Key Management Capability
• Keys:
• Generation, Derivation, Establishment, Agreement, Transport, Storage, Lifetime,
Zeroization, Accounting
• New keys can be provisioned in myriad ways:
• Sent by or retrieved from a central key management server using enterprise key
management software.
• Securely embedded in new software or firmware.
• Generated by the device.
• Established by the device with another party.

44. Guidance for Secure IoT Development
11. Establish a Secure Key Management Capability
• Keys Management Questions:
• Is secure storage for keys provided?
• How are keys wiped after use or expiration?
• What key lengths are used?
• Is the source of entropy sufficiently random?
• How are certificates verified?
• How are certificates revoked & expired?
• Who has access to key management systems? How?
• Are you using Perfect Forward Secrecy?
• What key management protocols are you using?

45. Guidance for Secure IoT Development
11. Establish a Secure Key Management Capability
• Design Secure Boot Functions
• Foundation for many of the security features of an IoT device
• Installed manufacturer certificate allows IoT device to securely
bootstrap into a new system

46. Guidance for Secure IoT Development
12. Provide Logging Mechanisms
• SIEM/SYSLOG needed as forensics trail:
• Connection Requests
• Authentications (failed / successful)
• Privilege abuse attempts / elevation of privilege attempts
• Receipt of malformed messages
• Successful / failed Firmware/Software updates
• Local log-in attempts
• Configuration changes
• Account updates
• Protected memory access
• Physical tampering

47. Guidance for Secure IoT Development
13. Perform Security Reviews (Internal & External)
• HW (Common Criteria) Review
• SW Review(OWASP feedback loops that link design, development & test)
• OWASP’s AppSec Pipeline
• continuous feedback & optimization across product lifecycle
• defects/vulns identified must be fed back into the design & threat modeling
process, resulting in:
• updates to hardware & software baselines for re-test to ensure that patches did not introduce
new vulnerabilities.

48. Guidance for Secure IoT Development
13. Perform Security Reviews (Internal & External)
• Tests to maintain security posture of IoT device:
• Static Application Security Testing (SAST)
• Dynamic Application Security Testing (DAST)
• Interactive Application Security Testing (IAST)
• Attack Surface & Vectors
• 3rd Party Libraries
• Fuzzing
• Customized per threat vector

49. Thank You!
Mark Szewczul, CISSP, is an IoT Security Architect at Zimperium with over 20 years of experience
from Semiconductor, Telecom/Datacom, and Computing sectors. He currently is Director of
Marketing at the Dallas/Fort Worth Cisco Users Group, has led the IEEE-Electromagnetic
Compatibility Society and co-founded the IEEE-Consumer Electronics Society, both in Dallas. Along
the journey, he has mastered design, testing, integration and deployment of numerous
systems. His passion entails implementing best practices of security and privacy principles at all
7-layers and beyond. He has his MS in Information Science and Systems from Texas A&M
University and 3 patents.