1. Agenda:
a. Why is there a demand for security in emerging technologies?
b. What are the expectations?
c. How can we implement those expectations?
2. Why is there a demand for security in emerging technologies?
a. Research
I. Upcoming in healthcare.
II. Real-world evidence (RWE) ACCRUAL DATA outside of studies. More decentralized trials popping up. RWE has a lot of tools. Apple Watch and Fitbit are RWE.
b. Empower:
I. CVS runs health studies every year.
II. More people are choosing convenience over everything else.
III. Screening tests on phones.
a. Scale
I. How these devices are going to connect across companies, industries, regulators, etc. healthcare is fragmented, and people want to fix that.
II. Cloud-based services-connecting it to a cloud…data is going somewhere. Amazon, Google, etc. develop cloud-based systems to apply AI.
b. Market Need
I. Everyone wants telehealth. Providers do their own studies.
II. Engagement is increasing with telehealth and digital tools used for communication/ test results.
III. During covid, people got comfy taking tests at home. FDA was extremely collaborative.
c. Breach (Ball) Trends:
I. 51% of all breaches that happened are health-related
II. Healthcare has the MOST value to threat actors.
III. There is a lot of research into the major vectors for these threats to breach or hack. These are called “exploits” of a “vulnerability”.
IV. Whenever there is a breach, there is a regulatory reaction.
V. Regulators are actively getting involved and costing companies more, and executives are promising an increase in security.
VI. Companies will turn this into a product feature. Customers want convenience and companies turn this into a market need.
3. What are the expectations?
a. Withholding expectations is not a good start. What are NOT Expectations:
b. Slow updates, poor user experience, etc. Biweekly cycle patch days, exploit Wednesdays. Psychological acceptability: if a human thinks it is an impediment for a person to do a job, they won’t do it. The easier you make it for someone to achieve something, the easier they are to do it. as a manufacturer, how will you make it easy for hospitals to meet their needs?
4. How: every product has a vulnerability.
a. Frameworks vs. standards vs. regulations:
I. Hospitals have their own regulatory items to work with.
II. Voluntary frameworks connect them.
b. Joint security plan:
I. What is it?
I. A voluntary framework for healthcare security. Created by the Healthcare Sector, Coordinating Council and endorsed by FDA, device manufacturers, and Hospitals
a. Should be used to critically assess an organization and its maturity.
b. Created by the healthcare sector (hospitals, FDA, etc.).
c. Asks, “Do you have X people doing X things,” giving people an outline of what is needed.
II. Why use it?
a. Comprehensive organizational maturity check.
b. Recommended FDA expectation (See SPDF requirement in draft guidance)
c. Referenced by OUS guidance
III. How use it?
a. As the most generic document here, it should be used to critically assess an organization and its maturity. The terminology used is consistent with HDO requirements and will enable you to create labeling and communication processes that will reduce complexity regardless of which regulatory authority you are conversing with.
b. Standards: IEC 80001 Series
I. What is it?
a. Comprehensive set of adaptable standards
b. Applicable to all Medical Device Manufacturers
II. Why use it?
a. HDOs (US) require MDS2 form for connected platforms23
b. Referenced by MDR (MDCG 2019-16) other standards such as IEC 8230 4-1 and UL 290 0 -224
III. How to use it?
a. Maps all 19 capabilities to technical standards for implementation
c. Standards: AAMI TIR 57
I. What is it?
a. Medical Device specific security risk management standard that emulates 14971
II. Why use it?
a. FDA-recognized and familiar design
b. Enables separation of security and safety domains
III. How to use it?
a. Use to interface safety risks to security root causes
b. Develop holistic risk management plans with acceptance criteria for security risks
d. Guidance: MDCG 20 19-16 Guidance
I. Information on the Minimum IT requirements as required by the EU MDR.
II. Both the FDA and EU guidance should move towards a consistent approach after the IMDRF guidance is established.
e. Guidance: FDA’s cybersecurity guidance
I. The FDA recently updated its draft guidance.
II. The prior draft guidance requirements of “tiering” was removed.
III. Discrete documentation that the agency will begin requesting either as part of submissions or for post-market inspections.
IV. More aligned with JSP and EU guidance.
f. FDA’s future plan: FDA Software Pre-Cert Pilot
I. Intended to inform the development of a future regulatory model that will provide more streamlined and efficient regulatory oversight of software-based medical devices.
g. FDA’s future plan: FDA Software Pre -Ce rt Pilot
I. Repeatable practice for product development
II. Start with the organization. Procedural. Product. Global view.
a. Organization: 2 million shortage of security professionals. Know what you are missing.
b. Process and Product
o Thread modeling: designed to be lightweight and iterative. Key principle of all security management to understand where threats come from and communicate to reviewer. Need a design and security engineer and a quality person.
Enumerate assets: assets are what you’re trying to protect. Know what you need to protect.
Identify boundaries: Cannot identify vulnerabilities until you know how the data is flowing. Need to decompose products and create a data flow diagram.
STRIDE: Spoofing, Tampering, Repudiation, Info disclosure, Denial of service, Elevation of privileges.
Address: mitigate, defer, accept, or eliminate. Ensure Documentation.
• Data Flow Diagram
• Vulnerability: how a threat event can occur. Visit CVSS.com and see how bad the vulnerability is. Identify using threat models and use scanners.
• Case Studies:
o Case study 1: Successful remote attempts as well as from the kiosks at the hospital.
Mixed asset management is ineffective.
o Case study 2: AI and trained models. When training a machine to make an algorithm, people developing the algorithm do not fully understand what the system is looking at to output (e.g., broken bone). They look at patterns within the image itself. Ground truth: skewed. People may disagree with the algorithm’s outcome.
c. Design Control
I. Procedural View: where and what the security processes are. Fill in security control and what you did to verify it.
II. Security Risk Management File
a. This document should record the acceptable risk levels for the organization
b. Create a summary of threats, develop your own idea of occurrence, and the idea of severity, and work through overall risk.
c. People get “tripped up” when trying to connect occurrence and severity with security.
d. Semi-Qualitative rubrics for Likelihood vs Acceptability of risk.
e. Asset and Vulnerability Libraries can be referenced in the SAD and further extrapolated as need be for use in Vulnerability Management (scanning) or customer notification (SBOM or Security Operations Manual)
f. Overall Risk: This is the qualitative determination of the threat event as well as post mitigation assessment
III. Documentation: all regulators reduce auditing when a 3rd party has verified.
a. Most of the items mentioned above are existent design documents. Keep the final assets as part of the Design History File (DHF)
b. Submit as required by guidance documents for the pertinent geography (See slides 18-19).
c. Following the JSP and accepted standards should meet expectations for additional information requests.
IV. Monitoring:
a. Still evolving and each company handles it differently.
i. Surveillance
1. Vulnerability Management
2. Customer Feedback
ii. Communication
1. Coordinated Disclosure
2. Bills of Materials
a. Software Bill of Materials
b. List of third-party software components necessary for functionality.
c. Intended to promote transparency and empowerment of HDOs
3. Operations Manual
a. Software Operations Manual
iii. Lifecycle
1. Patch Management
2. End-of-Life
V. Global View
a. Monitoring also includes understanding the other govt requirements that may impact your strategies.
i. US: HIPAA and some states (five states have CDP Consumer Data Privacy laws) enacted that may need to be reviewed for compliance.
ii. EU: GDPR is a data protection bill that has implications for studies, emerging technologies, and consumer protection. EU MDR and Clinical Regulations will take precedence over GDPR in a few cases but overall, have a legal review for most compliance requirements.
iii. China: Chinese Cyber Security Law has implications for data sent over the cloud to other countries. Overall, this impedes centrally established data protection and requires in-country implementation that may impede smaller companies
iv. India: Over the past few years, India has been implementing legislation to protect citizen rights. Recently, this was repealed but may be incorporated into other laws in the future.
v. Brazil: A new guidance based upon IMDRF is now available for cybersecurity
VI. References
