Secure-by-Design Using Hardware and Software Protection for FDA Compliance

This webinar explores the “secure-by-design” approach to medical device software development. During this important session, we will outline which security measures should be considered for compliance, identify technical solutions available on various hardware platforms, summarize hardware protection methods you should consider when building in security and review security software such as Trusted Execution Environments for secure storage of keys and data, and Intrusion Detection Protection Systems to monitor for threats.

1. TEEs & FDA
[title tdb]
Secure- by-Design
Using Hardware
and Software
Protection for
FDA Compliance

2. About Us
2
TrustonicSecure Platform provides a certified solution for the storage and
management of security or privacy sensitive data. This can be used to protect
cryptographic keys and patient information ensuring devices use best in class
security. It can also be used to provide defense in depth to protect other systems,
such as secure communications or intrusion detection, and enable secure
manufacture and tracking of devices throughout their lifecycle.
BG Networks equips embedded engineers and penetration testers with easy-to-
use software automation tools to streamline cybersecuritytasks including
hardening, detection, and testing. BG Networks automation tools are designed to
help with adherence to regulations from the FDA, NIST, ISO, and the EU.
ICS supports our customers with software development, User experience design, platform and regulatory support to build next generation products. We provide a number of services focused on the medtechspace including human factors
engineering with a 62366 compliant process, hazard and risk analysis, 62304
compliant software development, and platform support including cybersecurity.
Cybersecurity
Services
Cyber- Testing
&
Detection
Trusted
Execution
Environments

3. Speaker Introductions
3
Chief Strategy
and Innovations
Officer for
Secure Platform
Founder & CEO
Director of
Medical
Programs &
Cybersecurity

4. Cybersecurity in Medical Devices: Practical Advice for FDA’s 510(k) Requirements
Webinar Series
1.On DemandPractical Advice for FDA’s 510(k) Requirements
2.On DemandSecure- by-Design -Using Hardware and Software Protection for FDA Compliance
3.Today Secure-by-Design-Using Hardware and Software Protection for FDA Compliance
4.September (TBC) Threat modeling and risk assessment–First step in risk management
5.Defense-In-Depth–Security control categories called for by the FDA
6.Cyber-testing –What the FDA expects
7.Cybersecurity documentation - eSTARsubmissions
8.Post Market Requirements–Fixing Vulnerabilities: SBOM –Updates -Monitoring
9.Bolting On Security – Is there anything that can be done if I already have a design
4

5. Questions For Us - A Question For You – Link to Previous Webinar
Questions for us
•Put your questions in the Q&A
•For questions we don’t get to, we’ll write answers and make them available after
A question for you to keep in mind as we’ll ask it at the end
FDA expects the level of security in a medical device scales with risk. What cyber-threats, the drivers of risk, are you
most concerned about, and do you see your devices facing?
For reference here is the previous webinar in this series and the answers to questions asked
•Link to previous webinar:
https://www.ics.com/webinar-demand- practical-advice-fdas-510k-
requirements
•Link to previous Q&A:https://www.ics.com/questions-answers-fdas-510k-requirements-webinar
•We’ll put both in the chat
5

6. Devices are increasingly complex and network connected, so open to
increasing risks
Often, they are based on standard software and hardware platforms.
Secure- by-Design means starting cybersecurity at the beginning.
By starting at the beginning, gaps in security can be avoided, security
features in hardware/software leveraged, and FDA expectations met.

7. 7
Cybersecurity is Part of Device Safety and the Quality System Regulation

8. 8
Secure Product Development Framework (SPDF)
Covers the Total Product Lifecycle (TPLC) –The FDA is Very Clear
Secure- by-Design means consider cybersecurity from the beginning
A threat model and risk assessment should be done at the start, leading to a technical specification of security features to be implemented
BG Networks and ICS are offering a Secure Product Development Framework System & Services
SPDF includes manual, 25 procedures, 25 templates (including all needed for FDA premarket submission)

9. Authentication
Confidentiality
Data, Code,
Execution
Integrity
Event
Detection and
Logging
Resiliency and
Recovery
Updates
Patches
(& SBOMs)
DM-Crypt
Crypto.
Accel.
Secure
Boot
Secure Key
Storage
OS
CPU
MPU
TPM
TripWire
Secure
JTAG
Authorization
IDS
Software
Updates
TEE
Trust
Zone
SOFTWARE
User
Authentication
Privilege
Management
FDA’s Eight Security Control Categories
Possible Ways to Implement Using Processor Hardware & Commonly Used
Software
DM-Verity,
DM-Integrity
IDSTEE
Hardware
Root of
Trust
TLS/
OpenSSL
Crypto
FDA’s Eight Security Control Categories
Possible Ways to Implement Using Processor Hardware & Commonly Used
Software

10. Building a device
•The platform is the boring but necessary bit to support your device.
•Software platforms never stop changing
•More software (from more places) also means more vulnerabilities
Potentially huge
number of sources
of code & vulnerabilities
Platforms are ripe for
attack –and you need
to defend them

11. Two broad classes of device
Microcontroller / System on a Chip* Microprocessor / System on a Module
Single chip for compute/ram/storage/…
Arm Cortex-M
Separate chips for compute/ram/storage/…
Arm Cortex-A

12. Same security needs, but different scale
Limited range of software.
no OS / Zephyr / FreeRTOS
Often embedded peripherals
(e.g. Bluetooth)
Limited choice of software
often provided with chip
Less software means fewer
vulnerabilities (typically)
Lots of software choices. Android or Linux + ‘extras’
More peripheral choice (if you
build your own board)
Lots of 3
rd
party and open-
source software
Volume of software means
vulnerabilities are inevitable
Microcontroller / M-Class Microprocessor / A-Class

13. Steps to security
Basic
Hygiene
Isolation Monitoring …
Obvious stuff
people get
wrong all the
time
Protect the
important stuff
Keeping an eye
on the device.
Software updates
Device Lifecycle
…

14. Modern SOC/SOBs have an overwhelming set of security features
An example (i.MX 8/9)
1.Secure Boot / Encrypted Boot
2.Cryptographic Accelerator
3.Key Storage
4.Unique Device Identification
5.Security Monitoring (Tamper)
6.Processor & IO Locking (Debug)
7.TrustZone (TEE support)
NXP i.MX8/9 Security Architecture
Source: NXP, What is the EdgeLock Secure Enclave
4
2
1
3
5
6
7
Platform
Security
Lockdown
Application
Security
1
2
3
4
5
6
7

15. Basic Hygiene
Secure Boot and Image Signature Verification during
update are CRITICAL to ensure the bad guys can’ t
“reflash” your device
Modern devices all have decent secure boot
But security makes life hard for developers
And there is usually a side door…
Put it place processes to ensure security is real not
imagined.
Debug ports left open, secure boot disabled,
debug keys in production, serial access ….
2022-techcon-hacking-for -fun-and-
glucose.pdf (ucsd.edu)
… there was an unconnected ribbon cable
protruding from the main board whose contacts
were covered over with polyimide tape. ….it
became clear that this was a cable used for
debugging that was not disabled or removed
when the pumps were shipped out to
consumers.

16. Trusted Execution Environments provide a ‘safe space’
General Purpose
Operating System
Security Focused Operating System
TEEREE

17. Hardware Security?
TrustZone
TM
is a feature of
all Arm application
processors which provides
hardware isolation and
privileged access to security
features.
RISC-V processors can also
provide similar isolation
when paired with a system
Memory Protection Unit
Arm A-Class
processors
all support
TEEs
RISC-V
support is
nascent

18. Hardware Security?
The TEE Operating System
takes advantage of this
isolation to provide secure
services
The TEE is responsible for
securely booting other
operating systems…
… and then providing
security focused services
for them

19. TEEs in MCUs are far less common, but the principle is the same
By dividing the MPU into
“secure” a nd “norma l”
zones, critical code can
be isolated and patients
protected
…
Create TLS Session
Poll Server
Decode TCP Packet
Decode JSON
Flash Lights
Report Status
Manage Power
…
Check signature Activate Pump
Recent Arm-m
processors
(M23 & M33)
support TEEs,
but there are
very few
offerings
today

20. Use cases for a TEE in Medical Devices
20
There are a number of key areas where security solution can enhance the customer experience & build
confidence that their data and mission critical information is secured & protected
20
Patient Data
Protecting patient data
and information.
Can be store in secure
database or file store
Location Data
Ability to keep location-
based data secure with embedded security
System Protection
Support broader system protection software such as IDPS
Link to operator
Reduce risk of compromised data through connections to a linked device e.g. Bluetooth / Serial
Sensors and Biometrics
The need to secure critical information e.g. face, voice, iris recognition for security, sensor data for health applications
Secure Comms
Protect sensitive data uploaded to cloud or server, and validate software and configuration updates sent to device
Device Lifecycle
Attest to secure manufacture and provisioning. Audit updates Manage change in patient and device recycling

21. Intrusion Detection System (IDS)
For Event Detection
•Where does the intrusion detection run:
•Host-based: IDS runs on each host device
•Network- based: IDS runs on a dedicated device or one device within the network
•Cloud-based: IDS runs in the cloud performing analysis on data collected across devices
•What is monitored:
•Network traffic: IP addresses, ports, protocols, packet inspection, etc.
•CPU: Processor utilization, performance counters
•Memory: Contents of specific data structures in memory (Flash and RAM)
•System: Process execution, system calls, file system accesses, login attempts, etc.
•Software: Control flow, function calls, software stack, execution time, etc.
•How is detection performed:
•Signature: Scan for known vulnerability by looking for predefined signatures thereof
•Rules: Define a set of rules allowed behaviors and detect violations of those rules
•Anomaly: Define or train a model of normal behavior and detect deviations from model at runtime

22. Hacking Timeline: Best Case
White/gray hat hacker
finds & reports
vulnerability
Device
manufacturer
develops fix and
discloses
vulnerability
Healthcare providers
facilitate fix
Updated or
replaced device
in use by
patient
Medical
device in use
by patient

23. Hacking Timeline: Worst Case
Medical device in
use by patient
Black hat hacker finds
vulnerability
Publicly disclose firstDemand ransom Harm patient
Device manufacturer learns of
vulnerability after attack

24. Hacking Timeline: Patients may be vulnerable
•Recalls takes time
•Time to determine and
develop appropriate fix
•Time to deploy fix
•Months to years
•Attackers often have a lead
•Can exploit before
vulnerability is known by
manufactures, regulators,
etc.
Patients Vulnerable!!
Patients Vulnerable!!

25. Object
Detection
Source
(.c)
Compiler
(gcc)
AnCyR Data
Collection
(ancyr_shm.
c)
Object
Detection
App
Monitored
Operation
s
AnCyR
Engine
Binary
Event
Stream
(.csv)
AnCyR
Firmware
OS
App
Event
Stream
(.csv)
…
Event
Stream
(.csv)
…
AnCyR Model
AnCyR
Training
Flexible Anomaly Reporting:
Anomaly score indicates the severity. Detailed forensic data
identifies affected software tasks and operations.
AnCyR Model Training:
ML-based training optimizes model accuracy.
False positive rate for demo system:
0.00000000198
AnCyR Runtime Anomaly Detection:
Detects anomalies in real time.Uses IoT-optimizedAI/ML to
accurately detect anomalies in software execution
Data
Collection
Agent
Training
Stat+Prob+ML
Analysis &
Detection
Mode
Anomaly
Detected!
AnCyR
AnCyR
Model
AnCyR
App SW
OS
AnCyR™Integration:
Simple integration of AnCyR™agent and instrumentation during
compilation. No source code modifications.
US Patent #11,868,479B2
Example: AnCyR: Anomaly Detection & Cyber- Resilience

26. Not “Secure- by-Design”
How do you know when you’re not “Secure-by-Design”?
Contrast with strap-on or retrofitted security
•Working with available architecture
•Applying point- solutions
•Without system-wide analysis
•Without contextual analysis for:
•Intended-use
•User types
•Environment of use
•Architectural Vulnerabilities
•Patient harm
26

27. Understanding “Secure-by-Design”
An integratedset of security features that
comprehensively satisfies product security
•More secure than the “sum of the parts”
•The integration makes the security architectural vs. strap-on
•Example: Secure boot; authenticate bootloader with TPM
protected keys
Systematicanalysis
•Method that prevents errors of omission
•Detailed and specific
•Demonstrably complete
Security context- Security requirements driven by
•Intended use
•Environment of use
•Risk of patient harm
27
authentication
execution integrity
resiliency recovery
Boot from
Multi-Media
Card
Spoofing Self Signed Authority
Roll-back to
Unsecure Software
Compromised Keys

28. Systematic Analysis –Water-tight
Why Systematic Analysis is important
8 Security Control Categories (Authentication, Authorization,
Cryptography, Execution Integrity, Confidentiality, Event Detection and Logging,
Resiliency/Recovery, SW Updates)
Errors of omission security leaks
SPDF (Secure Product Development Framework)
processes that manage leaks
•Threat modeling
•Risk assessment
•Mitigations
Documentation burden
Seasoned experts benefit from repetition, but,..
•Demonstrating compliance (showing your work)
•Requirements Verification
•Architectural Continuity (people following your work)
•Detailed, enduring adjudication of device security
28
authentication
execution integrity
resiliency recovery
Boot from unauthorized location
OTP Fuses
Spoof Self-Signed Authority
Root Certificate Authority
Compromised keys
Key Management System

29. Risk approach to Secure-by-Design
Redundancy & contingency
Double hulls  Defense in Depth
Bulkheads Security zones
Defense in depth
•Detection & Response (IDS)
•Layers of encryption
Security zones
•Different encryption keys
•Limited interactions between zones
•Isolation of critical systems (TEE)
This type of security can’t be retrofitted
29

30. RequirementsManagement SBOMFeatures Dev. Code Quality
CI / CD Pre-ProductionTesting Post-Production Supporting End of Life
Competence
Development
Threat Modeling
Risk Assessment
Implement
cybersecurity features
Static analysis, MISRA
C, etc..
Generation
CWE/CVE check
Validation
Pentesting
Code Signing
Release / Delivery
Key Management
Locking Hardware
Vulnerability
Monitoring
Feedback / Incident
Response
Software Updates
Diagnostic Tools
Secure
Decommissioning
Software Development LifecycleSecurity Development LifecycleLegend
30
Secure- by-Design means consider cybersecurity from the beginning
SPDF -Secure by design

31. SPDF -Secure by design
Unpacking Requirements and Features Dev.
31
Requirements Threats
Users
Environment
Security expectation
Identify
Assess
Mitigate
Design
Specifications
Tools
Integrate
Implement
Code quality
SBOM
Evaluate
From the beginning of process
enables architectural solutions
•TEE (Trusted Execution
Environment)
•IDS (Intrusion Detection
Systems)
Lengthy involved process not
suitable for retrospective
application
Requirements Features Dev.
Threat Modeling
Risk Assessment
Implement
cybersecurity features

32. Secure by Design
Take-away summary
1.Integrateddesigns security controls……………………………………………… Structural, architectural, avoids the big gaps
2.Systematic(Threat Modeling, Risk Assessment)………………………… For specific, small leaks
3.At beginningof System Design ……………………………………………… .…….. Impractical when retro-fit
32

33. Poll Question
33
FDA expects the level of security in a medical device scales with risk.
What cyber- threats, the drivers of risk, are you most concerned about,
and do you see your devices facing?

34. Thank you