Security Architecture Views the FDA Expects — And How to Get Them Right
ICSinc
0 views
27 slides
Oct 16, 2025
Slide 1 of 27
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
About This Presentation
Architectural views play a pivotal role in demonstrating the cybersecurity posture of a medical device in FDA 510(k) submissions. The FDA expects, at a minimum, four distinct types of architecture diagrams. These diagrams provide a concise, intuitive way to illustrate how security has been built int...
Slide Content
TITLE SLIDE TBD
1
Security Architecture
Views the FDA
Expects —And How
to Get Them Right
Cybersecurity in Medical Devices:
Practical Advice for FDA’s 510(k)
Requirements
1
Security Architecture
Views the FDA
Expects —And How
to Get Them Right
Cybersecurity in Medical Devices:
Practical Advice for FDA’s 510(k)
Requirements
About Us
2
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.
BG Networks equips embedded engineers and
penetration testers with easy-to-use software
automation toolsincluding the first AI-from-
scratchThreat Modeling and Risk
Assessment platformthat saves 10x the time
and does not require training. BG Networks
automation tools are designed to help with
adherence to regulations and standards from the
FDA, NIST, ISO, and the EU.
Cybersecurity Services AI Automated Threat & Risk Analysis
2
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.
BG Networks equips embedded engineers and
penetration testers with easy-to-use software
automation toolsincluding the first AI-from-
scratchThreat Modeling and Risk
Assessment platformthat saves 10x the time
and does not require training. BG Networks
automation tools are designed to help with
adherence to regulations and standards from the
FDA, NIST, ISO, and the EU.
Cybersecurity Services AI Automated Threat & Risk Analysis
Speaker Introductions
Colin Duggan
Founder & CEO
Milton Yarberry
Director of MedicalPrograms
& Cybersecurity
For slides from our previous webinars email
[email protected]
Colin Duggan
Founder & CEO
Milton Yarberry
Director of MedicalPrograms
& Cybersecurity
For slides from our previous webinars email
[email protected]
Cybersecurity in Medical Devices Webinar Series
Available On-Demand
4
Available On-Demand
4
A Reminder –Latest FDA Guidance
From Our Webinar in June
H. R. 2617
March2023
Included section 524B
and information on
timeline for RTA
enforcement
H. R. 2617
December 2022
FY 2023 Omnibus
Includes:
FDORA, sec 3305
(Ensuring Cybersecurity of
Medical Devices ), 524B
H. R. 2617
March2024
FDA commentary and
guidance on what is
needed to meet 524B
statutory obligations
H. R. 2617
June2025
Section VII is mostly
the same as March
2024 with some further
clarifications
For full set of slides which summarize the changes just email us.
From Our Webinar in June
H. R. 2617
March2023
Included section 524B
and information on
timeline for RTA
enforcement
H. R. 2617
December 2022
FY 2023 Omnibus
Includes:
FDORA, sec 3305
(Ensuring Cybersecurity of
Medical Devices ), 524B
H. R. 2617
March2024
FDA commentary and
guidance on what is
needed to meet 524B
statutory obligations
H. R. 2617
June2025
Section VII is mostly
the same as March
2024 with some further
clarifications
For full set of slides which summarize the changes just email us.
Poll Question
How confident are you that your medical device processes will result in meeting FDA expectations?
MULTIPLE CHOICE ANSWERS TO POLL QUESTION
a.Not confident
b.Slightly confident
c.Somewhat confident
d.Confident
e.Extremely confident
We asked this question in our SPDF webinar back in May 2024.
We’ll compare the results both to now and at the end; also, to back then.
How confident are you that your medical device processes will result in meeting FDA expectations?
MULTIPLE CHOICE ANSWERS TO POLL QUESTION
a.Not confident
b.Slightly confident
c.Somewhat confident
d.Confident
e.Extremely confident
We asked this question in our SPDF webinar back in May 2024.
We’ll compare the results both to now and at the end; also, to back then.
Security Architectural Views What/ Why / How
7
4 Architectural View Types
1.Global System View
2.Multi- Patient Harm View
3.Updateability/Patchability View
4.Security Use Case View(s)
•Section V.B
•Appendix 2
Submission
Documentation
Makes the case for architecture importance
•Views used for design, development, maintenance
•Depth and scope of views, scale with system
complexity and risk of device
•“…at minimum the following types…”
7
4 Architectural View Types
1.Global System View
2.Multi- Patient Harm View
3.Updateability/Patchability View
4.Security Use Case View(s)
•Section V.B
•Appendix 2
Submission
Documentation
Makes the case for architecture importance
•Views used for design, development, maintenance
•Depth and scope of views, scale with system
complexity and risk of device
•“…at minimum the following types…”
8
Manufacturer is responsible for cybersecurity (524B)
•Manufacturer must implement cybersecurity controls
•Controls come from analysis
•Analysis implies context and boundaries
•“Manufacturers should analyze the entire system to understand
the full environment and context in which the device is expected
to operate”
“The objective… of security architecture information in premarket
submissions is to provide to FDA the security context and trust-
boundariesof the medical device system in terms of the
interfaces, interconnections, and interactions that the medical
device system has with external entities. … These details help to
provide a sufficient understanding of the system such that FDA
can evaluate adequacy of the architectureitself as it relates to
safety and effectiveness.”
Security Architectural Views What / Why/ How
Manufacturer is responsible for cybersecurity (524B)
•Manufacturer must implement cybersecurity controls
•Controls come from analysis
•Analysis implies context and boundaries
•“Manufacturers should analyze the entire system to understand
the full environment and context in which the device is expected
to operate”
“The objective… of security architecture information in premarket
submissions is to provide to FDA the security context and trust-
boundariesof the medical device system in terms of the
interfaces, interconnections, and interactions that the medical
device system has with external entities. … These details help to
provide a sufficient understanding of the system such that FDA
can evaluate adequacy of the architectureitself as it relates to
safety and effectiveness.”
Security Architectural Views What / Why/ How
9
•… diagrams and explanatory text
•Data flow, state diagrams, swim- lane diagrams, and call-flow diagrams, among
others
•… interfaces, communication protocols
•… threats, and cybersecurity controls used throughout the system
•… describes the sequence of process or protocol steps in explicit detail for an
associated use case
•… communication pathways between parts of the medical device system, to
include authentication or authorization
proceduresand session management
techniques.
•… sufficiently detailed such that engineers and reviewers should be able to
logically and easily follow data, code, and commands from any asset (e.g., a
manufacturer server) to any other associated asset (e.g., a medical device),
while possibly crossing intermediate assets (e.g., application).
•… should provide a system-level description and analysis inclusive of end-to-
end security analyses of all the communications in the medical device system
regardless of intended use.
•… how data, code, and commands are protected between any two assets in the
medical device system.
•… extent of these security views in a premarket submission is expected to scale
based on the architecture and potential cybersecurity risk posed to the device.
•Abundant descriptions
•Specialized diagrams
•Scope that exceeds
the device
(environment, system)
•Across and through
elements, considering
handoffs, lateral
effects, modes
•Describe how the
device reacts to
attacks
Security Architectural Views What / Why / How
•… diagrams and explanatory text
•Data flow, state diagrams, swim- lane diagrams, and call-flow diagrams, among
others
•… interfaces, communication protocols
•… threats, and cybersecurity controls used throughout the system
•… describes the sequence of process or protocol steps in explicit detail for an
associated use case
•… communication pathways between parts of the medical device system, to
include authentication or authorization
proceduresand session management
techniques.
•… sufficiently detailed such that engineers and reviewers should be able to
logically and easily follow data, code, and commands from any asset (e.g., a
manufacturer server) to any other associated asset (e.g., a medical device),
while possibly crossing intermediate assets (e.g., application).
•… should provide a system-level description and analysis inclusive of end-to-
end security analyses of all the communications in the medical device system
regardless of intended use.
•… how data, code, and commands are protected between any two assets in the
medical device system.
•… extent of these security views in a premarket submission is expected to scale
based on the architecture and potential cybersecurity risk posed to the device.
•Abundant descriptions
•Specialized diagrams
•Scope that exceeds
the device
(environment, system)
•Across and through
elements, considering
handoffs, lateral
effects, modes
•Describe how the
device reacts to
attacks
Security Architectural Views What / Why / How
Architecture Views in the Secure Product Development Framework
Where are Architecture Views produced and consumed in the SPDF?
•Threat Model (which feeds the views) should include the supply chain, manufacturing,
deployment, interoperation, maintenance, and decommissioning.
•V.A.1 “Threat model should … Capture cybersecurity risks introduced through the supply chain, manufacturing,
deployment, interoperation with other devices, maintenance/update activities, and decommission activities”
•Architecture Views are part of process for design ,development, maintenance
•V.B.2 “FDA recommends that manufacturers develop and maintain security architecture view documentation as a
part of the process for the design, development, and maintenance of the medical device system”
Where are Architecture Views produced and consumed in the SPDF?
•Threat Model (which feeds the views) should include the supply chain, manufacturing,
deployment, interoperation, maintenance, and decommissioning.
•V.A.1 “Threat model should … Capture cybersecurity risks introduced through the supply chain, manufacturing,
deployment, interoperation with other devices, maintenance/update activities, and decommission activities”
•Architecture Views are part of process for design ,development, maintenance
•V.B.2 “FDA recommends that manufacturers develop and maintain security architecture view documentation as a
part of the process for the design, development, and maintenance of the medical device system”
Architecture Views in the Secure Product Development Framework
11
M
Design Controls
Design Inputs
Product ReqA
Product ReqB
Design outputs
System SpecX
System SpecY
System SpecZ
Binaries
Verification Tests
Cyber TestX
Cyber TestY
Cyber TestZ
Security Specs
Cyber SpecX
Cyber SpecY
Cyber SpecZ
Security Controls
ControlX ControlY ControlZ
Threat Modeling
Risk Assessment
Architectural Views
Code
Known
Abnormalities
(test failures)
Static
Software
Code
Analysis
Source
SCA
Binary
SCA
SBOM
Triage &
Justifications
Vulnerability
Report
Penetration Testing
(independent white hat)
Post Market
Vulnerability
Management Plan
Customer
Transparency Plan
Published
Vulnerabilities
Threat Mitigation
Testing
(vs. ReqA, ReqB)
Vulnerability
Testing
(i.e. malformed input, fuzzing, etc.)
Cybersecurity
Assessment
Security Risk
Management
Report
(PMA -Annual)
Security Risk
Management Plan
Security Risk Test
Plan
SPDF
composition
Mitigations
Created
Used
Maintained
11
M
Design Controls
Design Inputs
Product ReqA
Product ReqB
Design outputs
System SpecX
System SpecY
System SpecZ
Binaries
Verification Tests
Cyber TestX
Cyber TestY
Cyber TestZ
Security Specs
Cyber SpecX
Cyber SpecY
Cyber SpecZ
Security Controls
ControlX ControlY ControlZ
Threat Modeling
Risk Assessment
Architectural Views
Code
Known
Abnormalities
(test failures)
Static
Software
Code
Analysis
Source
SCA
Binary
SCA
SBOM
Triage &
Justifications
Vulnerability
Report
Penetration Testing
(independent white hat)
Post Market
Vulnerability
Management Plan
Customer
Transparency Plan
Published
Vulnerabilities
Threat Mitigation
Testing
(vs. ReqA, ReqB)
Vulnerability
Testing
(i.e. malformed input, fuzzing, etc.)
Cybersecurity
Assessment
Security Risk
Management
Report
(PMA -Annual)
Security Risk
Management Plan
Security Risk Test
Plan
SPDF
composition
Mitigations
Created
Used
Maintained
Architectural Views: How deep to go?
•Revisit: ‘Depth and scope of views, scale with system complexity
and risk of device’
•Architecture Views Threat Modeling
•Number/depth attack surface identified in the Threat Modeling
•Threat Modeling methods are numerous
•Top-down or bottom-up (i.e. threat-actor vs asset)
•Used together they get better coverage –and can save you work
•Choose for best value (most effective at managing risk)
12
•Revisit: ‘Depth and scope of views, scale with system complexity
and risk of device’
•Architecture Views Threat Modeling
•Number/depth attack surface identified in the Threat Modeling
•Threat Modeling methods are numerous
•Top-down or bottom-up (i.e. threat-actor vs asset)
•Used together they get better coverage –and can save you work
•Choose for best value (most effective at managing risk)
12
13
What’s in the submission? Diagrams and Details
Detailed diagrams and supporting explanatory text that identify all assets,
including:
•Device hardware itself (including assessments for any commercial platforms);
•Applications, hardware, and/or other supporting assets that directly interact with the
targeted device, such as configuration, installation/upgrade, and data transfer applications;
•Healthcare facility-operated assets;
•Communications/networking assets; and
•Manufacturer-controlled assets, including any servers that interact with external entities
(e.g., a server that collects and redistributes device data, or a firmware update server).
Appendix 2 –Submission Documentation
What’s in the submission? Diagrams and Details
Detailed diagrams and supporting explanatory text that identify all assets,
including:
•Device hardware itself (including assessments for any commercial platforms);
•Applications, hardware, and/or other supporting assets that directly interact with the
targeted device, such as configuration, installation/upgrade, and data transfer applications;
•Healthcare facility-operated assets;
•Communications/networking assets; and
•Manufacturer-controlled assets, including any servers that interact with external entities
(e.g., a server that collects and redistributes device data, or a firmware update server).
Appendix 2 –Submission Documentation
14
How detailed?
Direct language asking for details
•“… this should include detailed diagrams and traces for all communication paths as described
below”
•“… the following details should be provided“
Expansive / Combinatorial
•“For every communication path that exists between any two assets in the security use case
view (and/or explanatory text), including indirect connections when there is at least one
intermediate asset (e.g., an app), the following details should be provided: “
•,… 19 details
Appendix 2 –Submission Documentation
How detailed?
Direct language asking for details
•“… this should include detailed diagrams and traces for all communication paths as described
below”
•“… the following details should be provided“
Expansive / Combinatorial
•“For every communication path that exists between any two assets in the security use case
view (and/or explanatory text), including indirect connections when there is at least one
intermediate asset (e.g., an app), the following details should be provided: “
•,… 19 details
Appendix 2 –Submission Documentation
Appendix 2 –Submission Documentation
19 Details (for every communication path between two assets)
1.Communication interfaces and paths, including
communication paths and any unused interfaces;
2.Type of data per path
3.Protocol name(s), version number(s), and
ports/frequencies;
4.Detailed descriptions for all assets, including not
currently used or enabled
5.Access control (user privileges/passwords)
6.Users’ roles and responsibility vs. assets and
communication
7.Any “handoff” sequences – and how commands are
secured/protected during handoff
8.Intended behavior in unusual circumstances (i.e.
connection termination)
9.Authentication algorithm(HMAC, EAP, RSA, DSA, TOTP)
version, strength, modes of operation
10.Descriptions of the cryptographic method used, style on
which assets participate
11.Detailed analyses by cryptography experts if a
cryptography algorithm is novel or proprietary
12.Where authentication is verified how verification
credentials (e.g., certificates, asymmetric keys, or
shared keys) are distributed
13.A precise, detailed list of how each type of credential
(e.g., password, key) is generated, stored, configured,
transferred, and maintained, for manufacturer and
healthcare facility assets
14.Identity management -how identities are
managed/transferred from manufacturer to
programmer, etc.
15.Detailed explanation of how sessionsare used
(established, maintained, and broken down)
16.Include any security configuration settings and their
default values;
17.Precise links between diagram elements (or explanatory
text), associated hazards and controls, and testing;
18.Explanations or links to the evidence that may be used
to justify security claims and any assumptions; and
19.Traceability of the asset to the SBOM component
described in Section V.B.2, above, for proprietary and
third-party code, when appropriate.
15
19 Details (for every communication path between two assets)
1.Communication interfaces and paths, including
communication paths and any unused interfaces;
2.Type of data per path
3.Protocol name(s), version number(s), and
ports/frequencies;
4.Detailed descriptions for all assets, including not
currently used or enabled
5.Access control (user privileges/passwords)
6.Users’ roles and responsibility vs. assets and
communication
7.Any “handoff” sequences – and how commands are
secured/protected during handoff
8.Intended behavior in unusual circumstances (i.e.
connection termination)
9.Authentication algorithm(HMAC, EAP, RSA, DSA, TOTP)
version, strength, modes of operation
10.Descriptions of the cryptographic method used, style on
which assets participate
11.Detailed analyses by cryptography experts if a
cryptography algorithm is novel or proprietary
12.Where authentication is verified how verification
credentials (e.g., certificates, asymmetric keys, or
shared keys) are distributed
13.A precise, detailed list of how each type of credential
(e.g., password, key) is generated, stored, configured,
transferred, and maintained, for manufacturer and
healthcare facility assets
14.Identity management -how identities are
managed/transferred from manufacturer to
programmer, etc.
15.Detailed explanation of how sessionsare used
(established, maintained, and broken down)
16.Include any security configuration settings and their
default values;
17.Precise links between diagram elements (or explanatory
text), associated hazards and controls, and testing;
18.Explanations or links to the evidence that may be used
to justify security claims and any assumptions; and
19.Traceability of the asset to the SBOM component
described in Section V.B.2, above, for proprietary and
third-party code, when appropriate.
15
•Conflicting messages
•The FDA guidance for architecture can be burdensome in scope and detail
•BUT, in order to design/develop/test effectively much of baseline is necessary
•AND the standard for compliance is mixed
•Reviewer variability
•Comparative compliance (out running the bear)
•SO, comply based on the risk
•Product risk vs.
•Submission risk
•1-2,..N rounds of questions – 180 day rule, 30- 60 day replies. Beware the reset.
•Do the homework (analysis),
•construct the collateral (explanation) –
•Anticipate defending your argument
16
Appendix 2 –Submission Documentation
A Practical Approach
•The FDA guidance for architecture can be burdensome in scope and detail
•BUT, in order to design/develop/test effectively much of baseline is necessary
•AND the standard for compliance is mixed
•Reviewer variability
•Comparative compliance (out running the bear)
•SO, comply based on the risk
•Product risk vs.
•Submission risk
•1-2,..N rounds of questions – 180 day rule, 30- 60 day replies. Beware the reset.
•Do the homework (analysis),
•construct the collateral (explanation) –
•Anticipate defending your argument
16
Appendix 2 –Submission Documentation
A Practical Approach
ARCHITECTURAL VIEW
GLOBALSYSTEMVIEW
&INTRODUCTION
AMPS- AIExample
Page1of2
AMPSINTRODUCTION
&
THREATSURFACE
INTRODUCTIONTOAMPS
1)AMPSisanacronymforAnkleWornPredictorofStroke
2)Vitalsignsandsensor dataisacquiredby thedevicewornon
thepatient'sankleoveraperiodofmonths,transmittedtothe
smartphoneapplicationandthentothecloudwhereitisstored
3)Afterafewmonthsaphyscianwillaccessthedatainthecloud
andmakeadeterminationofthepatientisatariskofstroke
4)Sinceitisapreventativecaredeviceimpacttopatientsafety
willneverbe "veryhigh".
THREATSURFACEFORAMPS-AI
1)BluetoothinterfaceontheAMPSdevice
2)USBinterfaceontheAMPSdevice
3)JTAGinterfaceontheAMPsdevice
4)SerialinterfaceontheAMPsdevice
5)Phone app store
6)Phone app input fields
7)Bluetoothinterfaceonsmartphone
8)Wifi/cellularinterfaceonsmartphone
9)Cloudgatewayforphone app
10)CloudgatewayforClinician application
SECURITYCONTROLS
Forreferencefollowingareallthesecuritycontrols
implemented.Theyareorganizedbythe8securitycontrol
categoriesfromAppendix1oftheFDA'spre-marketguidance
andthe85sub-controlsalsolistedinAppendixI
SOFTWAREUPDATEPROCESS
MoredetailedsoftwareupdateinformationisshownintheUpdateability/PatchabilityView.Belowisasummary
specificalyfortheGlobalSystemViewwhichisacomplementtotheUpdate/PatchabilityView.
1)SoftwareupdatesforthePhoneAMPSAppandtheAMPSdevicecomesthroughthePhoneAppStore.Fortheupdate to
theAMPSdevice,onceitisreceivedbythePhoneAMPSApp,itissentfromtheAPPviaBluetoothtotheAMPSdevice.
GLOBALSYSTEMVIEW
&INTRODUCTION
AMPS- AIExample
Page1of2
AMPSINTRODUCTION
&
THREATSURFACE
INTRODUCTIONTOAMPS
1)AMPSisanacronymforAnkleWornPredictorofStroke
2)Vitalsignsandsensor dataisacquiredby thedevicewornon
thepatient'sankleoveraperiodofmonths,transmittedtothe
smartphoneapplicationandthentothecloudwhereitisstored
3)Afterafewmonthsaphyscianwillaccessthedatainthecloud
andmakeadeterminationofthepatientisatariskofstroke
4)Sinceitisapreventativecaredeviceimpacttopatientsafety
willneverbe "veryhigh".
THREATSURFACEFORAMPS-AI
1)BluetoothinterfaceontheAMPSdevice
2)USBinterfaceontheAMPSdevice
3)JTAGinterfaceontheAMPsdevice
4)SerialinterfaceontheAMPsdevice
5)Phone app store
6)Phone app input fields
7)Bluetoothinterfaceonsmartphone
8)Wifi/cellularinterfaceonsmartphone
9)Cloudgatewayforphone app
10)CloudgatewayforClinician application
SECURITYCONTROLS
Forreferencefollowingareallthesecuritycontrols
implemented.Theyareorganizedbythe8securitycontrol
categoriesfromAppendix1oftheFDA'spre-marketguidance
andthe85sub-controlsalsolistedinAppendixI
SOFTWAREUPDATEPROCESS
MoredetailedsoftwareupdateinformationisshownintheUpdateability/PatchabilityView.Belowisasummary
specificalyfortheGlobalSystemViewwhichisacomplementtotheUpdate/PatchabilityView.
1)SoftwareupdatesforthePhoneAMPSAppandtheAMPSdevicecomesthroughthePhoneAppStore.Fortheupdate to
theAMPSdevice,onceitisreceivedbythePhoneAMPSApp,itissentfromtheAPPviaBluetoothtotheAMPSdevice.
ARCHITECTURAL VIEW
GLOBALSYSTEMVIEW
AMPS- AIExample
Page2of2
PhoneApp Store
UpdateService
AMPSDevice
ControlPlane
Sensor
(FictionalSensor)
Ports
(USB,JTAG,Serial)
BluetoothNetworking
PatientCellPhone
AMPS- AIApp OtherApps
PhoneOS
Bluetooth
Networking
Cell/WiFi
Networking
AMPSCloudServices
Gateway
PatientFacingServices HDOFacingServices
Service
Data
Medical
Data
Backend
Services
AISREAIEngine
SoftwareUpdate
AMPSCompanyFacilities
Clinician Computer
WebBrowser OtherApps
HostOS
Networking
1
Mobile Phone Vendor Security : User access over
Internet-TLS 1.3, Key Exchange(ECDHE),AEAD
cypherforencryption, Multi factor user
Authentication
Bluetooth Low Energy (BLE) 4.2 security level
Mode-1 Level 4 Authenticated LE Secure
Connections(ECDH-P256) ,numeric comparison
pairing with encryption using a 128- bit strength
encryption key.
Mobile Phone Vendor Security: Developer Account Access over Internet-TLS 1.3 Key Exchange (ECDHE)
AEAD cypher for encryption , Multi Factor developer Authentication
AMPS-AI App access to AMPS Cloud Services-
Certificate based Mutual Platform authentication,
TLS 1.3. Key Exchange(ECDHE),AEADcypher
forencryption, MitM Protection, User
Authentication.
Clinician Access to AMPS Cloud Services using web browser-TLS 1.3. KeyExchange(ECDHE),AEAD
cypherforencryption, MitM Protection, Multi
factor User Authentication
Unique identity in AMPS device
through X.509 certificate chained to
manufacturer’s root CA
AI model has integrity verified before running and monitored against drift using a reference output and input
AMPS Device is securely booted
PHI and PII has confidentiality and integrity maintained at rest and in transit in all devices, including in the cloud.
GLOBALSYSTEMVIEW
AMPS- AIExample
Page2of2
PhoneApp Store
UpdateService
AMPSDevice
ControlPlane
Sensor
(FictionalSensor)
Ports
(USB,JTAG,Serial)
BluetoothNetworking
PatientCellPhone
AMPS- AIApp OtherApps
PhoneOS
Bluetooth
Networking
Cell/WiFi
Networking
AMPSCloudServices
Gateway
PatientFacingServices HDOFacingServices
Service
Data
Medical
Data
Backend
Services
AISREAIEngine
SoftwareUpdate
AMPSCompanyFacilities
Clinician Computer
WebBrowser OtherApps
HostOS
Networking
1
Mobile Phone Vendor Security : User access over
Internet-TLS 1.3, Key Exchange(ECDHE),AEAD
cypherforencryption, Multi factor user
Authentication
Bluetooth Low Energy (BLE) 4.2 security level
Mode-1 Level 4 Authenticated LE Secure
Connections(ECDH-P256) ,numeric comparison
pairing with encryption using a 128- bit strength
encryption key.
Mobile Phone Vendor Security: Developer Account Access over Internet-TLS 1.3 Key Exchange (ECDHE)
AEAD cypher for encryption , Multi Factor developer Authentication
AMPS-AI App access to AMPS Cloud Services-
Certificate based Mutual Platform authentication,
TLS 1.3. Key Exchange(ECDHE),AEADcypher
forencryption, MitM Protection, User
Authentication.
Clinician Access to AMPS Cloud Services using web browser-TLS 1.3. KeyExchange(ECDHE),AEAD
cypherforencryption, MitM Protection, Multi
factor User Authentication
Unique identity in AMPS device
through X.509 certificate chained to
manufacturer’s root CA
AI model has integrity verified before running and monitored against drift using a reference output and input
AMPS Device is securely booted
PHI and PII has confidentiality and integrity maintained at rest and in transit in all devices, including in the cloud.
ARCHITECTURAL VIEW -AMPS- AIExample
UPDATEABILITY/PATCHABILITYVIEW
PhoneapplicationSoftwareupdate
signedbydistributioncertificate
SHA-256,RSA2048
AMPSsoftwarealsosignedwithSHA-
256,RSA2048
JTAG
Bluetooth
USB
AMPSCompany
Facilities
Patient'sHome
Internet
(Phonestorecloud
toPatient'sSmartPhone)
Amps
Device
SmartPhone
Company
Facilities
LogofSoftware
Updates
Withrecords,ofall
patient,statusof
update,time,anddate
for post-market metrics
tracking
Serial
PhoneStoreCloud
Certificate
Authority
Internet
(Connectionfrom
AMPSCompanyservers
tophonestorecloud)
Softwareupdate:
forboththephone
appandAMPS
device
Telemetry,log
datapassed
backonstatusof
sofwareupdates
AppStore
Content
Distribution
Networks
Patient's
Smart
Phone
Application
SmartPhoneapp
feature toforward
softwareupdateto
AMPSdevice
SecureStorage
(Keychain) for
SoftwareUpdate
Keys
Onlyaccessableby
authorizedusers
SigningKey&
Certificate
DistributionCertificate
(SigningCertsignedby
WorldwideDeveloper
CA)
Application
signaturechecked
everytimeappis
launchedbyphone
OS
AppleRoot
Certificate(Pre-
installedonSmart
Phone)
Software
download
signature
check
SHA-256
RSA2048
Trustedpublic
keyinstalled
during
manufacturing
ForStoretoPhoneAccess
TLS1.3
KeyExchange(ECDHE)
AEADcypherforencryption
2-FactorAuthentication
SecurityControl
8.9Deliverupdatesoverauthenticatedintegritygeneratedchannles
Softwareupdate
initiatedbyApp
Store
Authorization,Authentication,
Confidentiality
Cryptography
EventDetection&Logging
Authentication,
Integrity,
Confidentiality
SoftwareUpdate
Authoriziation&
Authentication&
Confidentiality
Authoriziation&
Authentication&
Confidentiality
ForDeveloperAccount
Access
TLS1.3
KeyExchange(ECDHE)
AEADcypherforencryption
2-FactorAuthentication
Authentication,
Integrity,
Confidentiality
SoftwareUpdate
Authentication&
Encryption
BluetoothLowEnergy
SecurityMode1
Level4
withnumbericcomparison
supported
FLOWOFEVENTS
STEP- 1:AMPScompanydevelopmentteamobtainsdistributioncertificatefrom
smartphonecompanyandstorekeyinthesecurekecyhain.
STEP- 2:AMPScompanysignssmartphoneappandAMPSdevicefimwareimage
STEP- 3:BothsoftwareismadeavailableonAppStoreContentDistributionNetwork(CDN)
STEP- 4:BothsoftwareupdatesarepushedtothePatientSmartPhoneoverAppStore.
STEP- 5:Patient'sphoneappsignaturecheckedandinstalledinthePatientSmartPhone.
STEP- 6:AMPSDevicefimwareisdownloadedtoAMPSDeviceandcheckedforsignature
STEP- 1
STEP- 2
STEP- 3
STEP- 4
STEP- 5
STEP- 6
UPDATEABILITY/PATCHABILITYVIEW
PhoneapplicationSoftwareupdate
signedbydistributioncertificate
SHA-256,RSA2048
AMPSsoftwarealsosignedwithSHA-
256,RSA2048
JTAG
Bluetooth
USB
AMPSCompany
Facilities
Patient'sHome
Internet
(Phonestorecloud
toPatient'sSmartPhone)
Amps
Device
SmartPhone
Company
Facilities
LogofSoftware
Updates
Withrecords,ofall
patient,statusof
update,time,anddate
for post-market metrics
tracking
Serial
PhoneStoreCloud
Certificate
Authority
Internet
(Connectionfrom
AMPSCompanyservers
tophonestorecloud)
Softwareupdate:
forboththephone
appandAMPS
device
Telemetry,log
datapassed
backonstatusof
sofwareupdates
AppStore
Content
Distribution
Networks
Patient's
Smart
Phone
Application
SmartPhoneapp
feature toforward
softwareupdateto
AMPSdevice
SecureStorage
(Keychain) for
SoftwareUpdate
Keys
Onlyaccessableby
authorizedusers
SigningKey&
Certificate
DistributionCertificate
(SigningCertsignedby
WorldwideDeveloper
CA)
Application
signaturechecked
everytimeappis
launchedbyphone
OS
AppleRoot
Certificate(Pre-
installedonSmart
Phone)
Software
download
signature
check
SHA-256
RSA2048
Trustedpublic
keyinstalled
during
manufacturing
ForStoretoPhoneAccess
TLS1.3
KeyExchange(ECDHE)
AEADcypherforencryption
2-FactorAuthentication
SecurityControl
8.9Deliverupdatesoverauthenticatedintegritygeneratedchannles
Softwareupdate
initiatedbyApp
Store
Authorization,Authentication,
Confidentiality
Cryptography
EventDetection&Logging
Authentication,
Integrity,
Confidentiality
SoftwareUpdate
Authoriziation&
Authentication&
Confidentiality
Authoriziation&
Authentication&
Confidentiality
ForDeveloperAccount
Access
TLS1.3
KeyExchange(ECDHE)
AEADcypherforencryption
2-FactorAuthentication
Authentication,
Integrity,
Confidentiality
SoftwareUpdate
Authentication&
Encryption
BluetoothLowEnergy
SecurityMode1
Level4
withnumbericcomparison
supported
FLOWOFEVENTS
STEP- 1:AMPScompanydevelopmentteamobtainsdistributioncertificatefrom
smartphonecompanyandstorekeyinthesecurekecyhain.
STEP- 2:AMPScompanysignssmartphoneappandAMPSdevicefimwareimage
STEP- 3:BothsoftwareismadeavailableonAppStoreContentDistributionNetwork(CDN)
STEP- 4:BothsoftwareupdatesarepushedtothePatientSmartPhoneoverAppStore.
STEP- 5:Patient'sphoneappsignaturecheckedandinstalledinthePatientSmartPhone.
STEP- 6:AMPSDevicefimwareisdownloadedtoAMPSDeviceandcheckedforsignature
STEP- 1
STEP- 2
STEP- 3
STEP- 4
STEP- 5
STEP- 6
AMPSCompanyFacilities
PatientCellPhone
AMPS- AIApp OtherApps
PhoneOS
Bluetooth Cell/WiFi
Networking Networking
Patie
A
N
ntCellPhone
MPS-AIApp OtherApps
PhoneOS
Bluetooth Cell/WiFi
etworking Networking
AMPSCloudServices
Gateway
PatientFacingServices HDOFacingServices
Service
Data
Medical
Data
Backend
Services
AISREAIEngine
ARCHITECTURAL VIEW
MULTI-PATIENTHARM
AMPS- AIExample OneCaseOutofMultiple
Forillustrativepurposes,onecaseofmulti-patientharmisshown.ForanFDA
submission,atleast4othercasesofmulti-patentharmwouldneedtobeshownto
bemitigatedforAMPS- AIgiventhethreatsurfacehasentrypointstoClinician
Computers,networkinterfacetoPatientCellPhones,Bluetoothinterfacetothe
AMPS- AIdevice,andgatewaytoAMPSCloudServices.
CASE- 1:CompromisedAIModelLeadstoIncorrectMedical
Data
AlteredAImodelweightsleadtoincorrectpredictionsthataredelivered
toMultipleCliniciansandMultiplePatients.
FromThreatModel
Tamperwith AISREmodelweightstoalterstrokeriskpredictions
SecurityControls
1.12Enforcemulti-factoruserauthenticationforprivilegedroles
4.2Signeveryfirmwareandsoftwarepackage
4.4Rejectunsignedorbadly-signedupdates
4.5Usesignedupdatestopreventrollbackattacks
6.1Detecttime-stampandlogsecurityevents
PatientCellPhone
AMPS- AIApp OtherApps
PhoneOS
Bluetooth
Networking
Cell/WiFi
Networking
Clinician Computer
Web Browser OtherApps
HostOS
Networking
Clinician Computer
WebBrow
N
ser OtherApps
HostOS
etworking
Clinician Computer
WebBrowser OtherApps
HostOS
Networking
SoftwareUpdate
CI/CDPipeline
SecurityControls:
4.4Rejectunsignedorbadly-signedupdates
6.1Detecttime-stampandlogsecurityevents
SecurityControls:
1.12Enforcemulti-factoruserauthenticationfor
privilegedroles
4.2Signeveryfirmwareandsoftwarepackage
6.1Detecttime-stampandlogsecurityevents
SecurityControls:
1.12Enforcemulti-factoruserauthenticationfor
privilegedroles
4.2Signeveryfirmwareandsoftwarepackage
AISREModelWeights
(S3Bucket)
STEP- 1
STEP- 2
STEP- 3
STEP- 4
AttackPath
EntryPoint: AImodelstoredS3bucket
AttackSteps:
STEP-1: CompromiseCI/CDcredentialsviaphishingdeveloper.
STEP-2: Uploadalteredmodelfilewithsameversiontag.
STEP-3: Deploymentpullsmaliciousweightsintoproduction.
STEP-4: AISREreturnsskewedstrokeprobabilities.
PatientCellPhone
AMPS- AIApp OtherApps
PhoneOS
Bluetooth Cell/WiFi
Networking Networking
Patie
A
N
ntCellPhone
MPS-AIApp OtherApps
PhoneOS
Bluetooth Cell/WiFi
etworking Networking
AMPSCloudServices
Gateway
PatientFacingServices HDOFacingServices
Service
Data
Medical
Data
Backend
Services
AISREAIEngine
ARCHITECTURAL VIEW
MULTI-PATIENTHARM
AMPS- AIExample OneCaseOutofMultiple
Forillustrativepurposes,onecaseofmulti-patientharmisshown.ForanFDA
submission,atleast4othercasesofmulti-patentharmwouldneedtobeshownto
bemitigatedforAMPS- AIgiventhethreatsurfacehasentrypointstoClinician
Computers,networkinterfacetoPatientCellPhones,Bluetoothinterfacetothe
AMPS- AIdevice,andgatewaytoAMPSCloudServices.
CASE- 1:CompromisedAIModelLeadstoIncorrectMedical
Data
AlteredAImodelweightsleadtoincorrectpredictionsthataredelivered
toMultipleCliniciansandMultiplePatients.
FromThreatModel
Tamperwith AISREmodelweightstoalterstrokeriskpredictions
SecurityControls
1.12Enforcemulti-factoruserauthenticationforprivilegedroles
4.2Signeveryfirmwareandsoftwarepackage
4.4Rejectunsignedorbadly-signedupdates
4.5Usesignedupdatestopreventrollbackattacks
6.1Detecttime-stampandlogsecurityevents
PatientCellPhone
AMPS- AIApp OtherApps
PhoneOS
Bluetooth
Networking
Cell/WiFi
Networking
Clinician Computer
Web Browser OtherApps
HostOS
Networking
Clinician Computer
WebBrow
N
ser OtherApps
HostOS
etworking
Clinician Computer
WebBrowser OtherApps
HostOS
Networking
SoftwareUpdate
CI/CDPipeline
SecurityControls:
4.4Rejectunsignedorbadly-signedupdates
6.1Detecttime-stampandlogsecurityevents
SecurityControls:
1.12Enforcemulti-factoruserauthenticationfor
privilegedroles
4.2Signeveryfirmwareandsoftwarepackage
6.1Detecttime-stampandlogsecurityevents
SecurityControls:
1.12Enforcemulti-factoruserauthenticationfor
privilegedroles
4.2Signeveryfirmwareandsoftwarepackage
AISREModelWeights
(S3Bucket)
STEP- 1
STEP- 2
STEP- 3
STEP- 4
AttackPath
EntryPoint: AImodelstoredS3bucket
AttackSteps:
STEP-1: CompromiseCI/CDcredentialsviaphishingdeveloper.
STEP-2: Uploadalteredmodelfilewithsameversiontag.
STEP-3: Deploymentpullsmaliciousweightsintoproduction.
STEP-4: AISREreturnsskewedstrokeprobabilities.
ARCHITECTURAL
VIEW
SECURITYUSECASE
AMPS- AIExample
STEPSANDASSOCIATEDTHREATSCENARIOS(TSs)
STEP- 1:AMPSDEVICESENDSTHESENSORYDATATOTHEPATIENTCELLPHONEOVER
BLUETOOTHINTERFACETS-07,TS-05
STEP- 2:PATIENT'SPHONESENDSTHEDATATOAMPSCLOUDINFRASTRUCTURE OVERCELL/WIFI
INTERFACETS-13,TS-08,TS-14
STEP- 3:AMPSCLOUDINTERFACEPROCESSES THERAWDATAANDSTORESTHE
MEDICALDATAUNDERTHEPATIENT'SRECORDINTHEMEDICALDATADATABASETS-01,TS-09
STEP- 4:AISREAIENGINEANALYZESRAWDATAANDCALCULATESAPERSONALIZED STROKE
RISKESTIMATETHATISRECORDED INTHEPATIENTSRECORDIN THEMEDICALDATABASETS-11
STEP-1
UpdateService
AMPSDevice
ControlPlane
Sensor
(FictionalSensor)
Ports
(USB,JTAG,Serial)
BluetoothNetworking
PatientCellPhone
AMPS- AIApp OtherApps
PhoneOS
Bluetooth
Networking
Cell/WiFi
Networking
AMPSCloudServices
Gateway
PatientFacingServices HDOFacingServices
Service
Data
Medical
Data
Backend
Services
AISREAIEngine
SoftwareUpdate
STEP-2
STEP-3
STEP-4
TS-13:CompromiseofTLScertificatesenablesMITMinterceptingcomms
SecurityControls:
1.2Verifyauthenticityofinformationintransit
3.2FollowNISTforkeygenerationstoragerotationandrobustnonces
6.1Detecttime-stampandlogsecurityevents
2.4Default-denyallportsinterfacesandcommandsnotexplicitlyrequired
PhoneApp Store AMPSCompanyFacilities
TS-08:DenialofserviceoncloudservicesdisruptsAPIavailability
SecurityControls:
7.5HandleDenial-of-Serviceconditions
7.9Ignoreorhandlelargevolumesofbenignscannoisetraffic
2.4Default-denyallportsinterfacesandcommandsnotexplicitly
required
TS-14:CompromiseofAPItokensallowsunauthorizedcloudAPIcalls
SecurityControls:
1.2Verifyauthenticityofinformationintransit
5.2Guardcredentialsandcryptokeyswithstrongisolation
6.1Detecttime-stampandlogsecurityevents
2.4Default-denyallportsinterfacesandcommandsnot
explicitly required
TS-01:Unauthorizedaccesstoclouddataleakssensitivepatient
informationandlogs
SecurityControls:
1.2Verifyauthenticityofinformationintransit
5.1Encryptanydatawhosedisclosurecouldenablepatientharm
3.2FollowNISTforkeygenerationstoragerotationandrobustnonces
6.1Detecttime-stampandlogsecurityevents
TS-11:TamperwithAISREmodelweightstoalter
strokeriskpredictions
SecurityControls:
4.2Signeveryfirmwareandsoftwarepackage
4.4Rejectunsignedorbadly-signedupdates
4.5Usesignedupdatestopreventrollbackattacks
6.1Detecttime-stampandlogsecurityevents
TS-09:ExploitofcloudOSvulnerabilitygrantsadministrative
control
SecurityControls:
1.5Monitorintegrityoftherunningexecutionstate
4.1Employhardware- rootedsecurity
1.12Enforcemulti-factoruserauthenticationforprivilegedroles
6.1Detecttime-stampandlogsecurityevents
TS-07:DenialofservicebydrainingbatteryorjammingBLE
preventsdatacollection
SecurityControls:
4.11Validate message formatand value ranges
7.5HandleDenial-of-Serviceconditions
7.9Ignoreorhandlelargevolumesofbenignscannoisetraffic
TS-05:Adversaryspoofsdeviceidentityusingcompromised
keystoimpersonateanAMPSDevice
SecurityControls:
3.6Architectsonosingledevicecompromiserevealsotherskeys
5.2Guardcredentialsandcryptokeyswithstrongisolation
4.8Lock-disabledebugports
4.9Applytamper-evidentsealstosensitiveportsandenclosures
Clinician Computer
WebBrowser OtherApps
HostOS
Networking
OneCaseOutofMultiple
Likeformulti-patientharmtherewouldbemore
thanjustonesecurityusecaseviewforAMP-AI.
TS=THREATSCENARIO
VIEW
SECURITYUSECASE
AMPS- AIExample
STEPSANDASSOCIATEDTHREATSCENARIOS(TSs)
STEP- 1:AMPSDEVICESENDSTHESENSORYDATATOTHEPATIENTCELLPHONEOVER
BLUETOOTHINTERFACETS-07,TS-05
STEP- 2:PATIENT'SPHONESENDSTHEDATATOAMPSCLOUDINFRASTRUCTURE OVERCELL/WIFI
INTERFACETS-13,TS-08,TS-14
STEP- 3:AMPSCLOUDINTERFACEPROCESSES THERAWDATAANDSTORESTHE
MEDICALDATAUNDERTHEPATIENT'SRECORDINTHEMEDICALDATADATABASETS-01,TS-09
STEP- 4:AISREAIENGINEANALYZESRAWDATAANDCALCULATESAPERSONALIZED STROKE
RISKESTIMATETHATISRECORDED INTHEPATIENTSRECORDIN THEMEDICALDATABASETS-11
STEP-1
UpdateService
AMPSDevice
ControlPlane
Sensor
(FictionalSensor)
Ports
(USB,JTAG,Serial)
BluetoothNetworking
PatientCellPhone
AMPS- AIApp OtherApps
PhoneOS
Bluetooth
Networking
Cell/WiFi
Networking
AMPSCloudServices
Gateway
PatientFacingServices HDOFacingServices
Service
Data
Medical
Data
Backend
Services
AISREAIEngine
SoftwareUpdate
STEP-2
STEP-3
STEP-4
TS-13:CompromiseofTLScertificatesenablesMITMinterceptingcomms
SecurityControls:
1.2Verifyauthenticityofinformationintransit
3.2FollowNISTforkeygenerationstoragerotationandrobustnonces
6.1Detecttime-stampandlogsecurityevents
2.4Default-denyallportsinterfacesandcommandsnotexplicitlyrequired
PhoneApp Store AMPSCompanyFacilities
TS-08:DenialofserviceoncloudservicesdisruptsAPIavailability
SecurityControls:
7.5HandleDenial-of-Serviceconditions
7.9Ignoreorhandlelargevolumesofbenignscannoisetraffic
2.4Default-denyallportsinterfacesandcommandsnotexplicitly
required
TS-14:CompromiseofAPItokensallowsunauthorizedcloudAPIcalls
SecurityControls:
1.2Verifyauthenticityofinformationintransit
5.2Guardcredentialsandcryptokeyswithstrongisolation
6.1Detecttime-stampandlogsecurityevents
2.4Default-denyallportsinterfacesandcommandsnot
explicitly required
TS-01:Unauthorizedaccesstoclouddataleakssensitivepatient
informationandlogs
SecurityControls:
1.2Verifyauthenticityofinformationintransit
5.1Encryptanydatawhosedisclosurecouldenablepatientharm
3.2FollowNISTforkeygenerationstoragerotationandrobustnonces
6.1Detecttime-stampandlogsecurityevents
TS-11:TamperwithAISREmodelweightstoalter
strokeriskpredictions
SecurityControls:
4.2Signeveryfirmwareandsoftwarepackage
4.4Rejectunsignedorbadly-signedupdates
4.5Usesignedupdatestopreventrollbackattacks
6.1Detecttime-stampandlogsecurityevents
TS-09:ExploitofcloudOSvulnerabilitygrantsadministrative
control
SecurityControls:
1.5Monitorintegrityoftherunningexecutionstate
4.1Employhardware- rootedsecurity
1.12Enforcemulti-factoruserauthenticationforprivilegedroles
6.1Detecttime-stampandlogsecurityevents
TS-07:DenialofservicebydrainingbatteryorjammingBLE
preventsdatacollection
SecurityControls:
4.11Validate message formatand value ranges
7.5HandleDenial-of-Serviceconditions
7.9Ignoreorhandlelargevolumesofbenignscannoisetraffic
TS-05:Adversaryspoofsdeviceidentityusingcompromised
keystoimpersonateanAMPSDevice
SecurityControls:
3.6Architectsonosingledevicecompromiserevealsotherskeys
5.2Guardcredentialsandcryptokeyswithstrongisolation
4.8Lock-disabledebugports
4.9Applytamper-evidentsealstosensitiveportsandenclosures
Clinician Computer
WebBrowser OtherApps
HostOS
Networking
OneCaseOutofMultiple
Likeformulti-patientharmtherewouldbemore
thanjustonesecurityusecaseviewforAMP-AI.
TS=THREATSCENARIO
Traceability: Threats to Risks
Generated by Aithra
22
Excerpt from AMPs Threat Model and Risk Analysis
Aithra
•Threat & Risk analysis automation
•No training needed
•Reduces amount of work by 10x
Generated by Aithra
22
Excerpt from AMPs Threat Model and Risk Analysis
Aithra
•Threat & Risk analysis automation
•No training needed
•Reduces amount of work by 10x
SNAPSHOT: Steps to Create Architectural Views
23
Turning the crank, simplified,..
1)Create a Threat Model: Unprotected system. Consider using tools i.e. Aithra
2)Create a Risk Analysis: Consider buying templates or using tools. Create controls. Assess and repeat.
3)1 & 2 create the ingredients: Asset list, connectivity, modes, cybersecurity controls
4)Diagrams: general tools (drawio, Visio, Word) or security specialized tools MS Threat Modeling Tool
1.Global System View – all assets, all modes (production, service, etc), all phases (mfg, deployment)
2.Multi-Patient Harm View –may or may not apply
3.Updateability/Patchability View – FW/SW updates
4.Security Use Case View(s) – how the security measures go into action when attacked
** Anticipate iterative changes -Be prepared to rinse and repeat
23
Turning the crank, simplified,..
1)Create a Threat Model: Unprotected system. Consider using tools i.e. Aithra
2)Create a Risk Analysis: Consider buying templates or using tools. Create controls. Assess and repeat.
3)1 & 2 create the ingredients: Asset list, connectivity, modes, cybersecurity controls
4)Diagrams: general tools (drawio, Visio, Word) or security specialized tools MS Threat Modeling Tool
1.Global System View – all assets, all modes (production, service, etc), all phases (mfg, deployment)
2.Multi-Patient Harm View –may or may not apply
3.Updateability/Patchability View – FW/SW updates
4.Security Use Case View(s) – how the security measures go into action when attacked
** Anticipate iterative changes -Be prepared to rinse and repeat
Poll Question – The After & Comparison
24
Question: How confident are you that your medical device processes will result in meeting FDA expectations?
Results from our
May 2024 Webinar
24
Question: How confident are you that your medical device processes will result in meeting FDA expectations?
Results from our
May 2024 Webinar
Upcoming Events
25
Join ICS and BG Networks in person at Embedded World
•Anaheim, CA
•November 4-6
•Presenting
•Understanding the EU Cyber Resilience Act: What Software Publishers & Electronics Manufacturers
Need to Know
•ID 15387
Next webinar –on the EU’s Cybersecurity Resilience Act
•Anticipating the first step to CRA-compliant product security: threat modeling and risk
assessment compliant with the CRA
25
Join ICS and BG Networks in person at Embedded World
•Anaheim, CA
•November 4-6
•Presenting
•Understanding the EU Cyber Resilience Act: What Software Publishers & Electronics Manufacturers
Need to Know
•ID 15387
Next webinar –on the EU’s Cybersecurity Resilience Act
•Anticipating the first step to CRA-compliant product security: threat modeling and risk
assessment compliant with the CRA
Looking for Folks to Shape our Next Product Features
15 Minute Research Chat or Feedback Email Exchange
We’re defining the next set of automation features that will leverage AI
•We would love to hear about your most difficult medical device cybersecurity challenges
Look out for a follow up email
•It will ask your preference to convey your thoughts/feedback
Our goal is to automate much of the cybersecurity work so that product teams
can meet requirements more easily
15 Minute Research Chat or Feedback Email Exchange
We’re defining the next set of automation features that will leverage AI
•We would love to hear about your most difficult medical device cybersecurity challenges
Look out for a follow up email
•It will ask your preference to convey your thoughts/feedback
Our goal is to automate much of the cybersecurity work so that product teams
can meet requirements more easily
Q/A
For security diagrams email
[email protected]
Colin Duggan
Founder & CEO
Milton Yarberry
Director of MedicalPrograms
& Cybersecurity
For security diagrams email
[email protected]
Colin Duggan
Founder & CEO
Milton Yarberry
Director of MedicalPrograms
& Cybersecurity
Categories
BusinessDownload
Download Slideshow Get the original presentation fileQuick Actions
Statistics
- Views 0
- Slides 27
- Age 46 days
Related Slideshows
1
DTI BPI Pivot Small Business - BUSINESS START UP PLAN
MeljunCortes
28 views
1
CATHOLIC EDUCATIONAL Corporate Responsibilities
MeljunCortes
30 views
11
Karin Schaupp – Evocation; lançamento: 2000
alfeuRIO
28 views
10
Pillars of Biblical Oneness in the Book of Acts
JanParon
26 views
31
7-10. STP + Branding and Product & Services Strategies.pptx
itsyash298
27 views
44
Business Legislation PPT - UNIT 1 jimllpkggg
slogeshk98
30 views