R-TF-030-003 Cyber Security Assessment Report

Scope

This document covers the security risk assessment report of the medical device.

It contains:

• The security risk analysis,
• The security risk assessment report,
• The security risk traceability matrixes with software requirements and test cases.

Terms and definitions

Term	Definition
API	A set of rules and protocols that allows different software applications to communicate and interact with each other.
Health Care Provider	Organization that delivers medical services to individuals
REST API	Representational State Transfer Application Programming Interface, a type of web service that allows communication between systems over HTTP.
Security Level (SL)	It represents the degree to which a system or component can withstand threats and potential attacks.
Capability Security Level (CSL)	It specifies the degree to which a component, such as a device, system or application, meets the security requirements necessary to resist certain threats
Transport Layer Security (TLS)	A cryptographic protocol designed to provide secure communication over a computer network. It is widely used to secure communications over the internet.

Security risk analysis

Intended use

The intended use is available in the description and specifications

Context of risk assessment

The device is a computational software-only medical device leveraging deep learning and computer vision algorithms to process clinical and dermoscopic images of skin structures, providing quantitative data on clinical signs and an interpretative distribution of ICD-11 categories to support healthcare professionals in the assessment of dermatological conditions.

This context comprises:

Device Architecture and Components

The medical device is implemented as a distributed system with the following software components:

• RESTful API Layer (FastAPI-based):
  • Handles incoming HTTPS requests and routes them to appropriate services
  • Implements JWT-based authentication and authorization (OAuth 2.0)
  • Provides automatic data validation and serialization
  • Supports asynchronous request handling for optimal performance
• Authentication and Authorization Service:
  • Manages user registration and login
  • Issues and validates JWT tokens with 1-hour expiry
  • Implements role-based access control
  • Stores user credentials securely (email, hashed passwords, organization details)
• AI Model Inference Services:
  • ICD-11 category distribution classifier (deep learning models)
  • Binary indicator algorithms (malignancy, dermatological condition, critical complexity)
  • Image quality assessment models
  • Clinical signs quantification models (erythema, induration, desquamation)
  • Segmentation models for lesion identification
• Data Storage Layer:
  • AWS DocumentDB: User registration data, API interaction history, model version registry
  • Amazon S3: AI model weights, clinical images submitted by users, training/validation datasets
  • DynamoDB: Audit records
• Version Control and Build System:
  • Git/GitHub for source code management with branch protection
  • Bazel build system for reproducible, deterministic builds
  • GitHub Actions for CI/CD pipeline automation

Operating Environment

• Cloud Infrastructure: AWS data centers hosting virtual machine instances
• Network Security:
  • TLS ≥ 1.2 (AES-256-GCM) over port 443 for all communications
  • VPC isolation for database instances
  • Network access controls and security groups
• Deployment Environments:
  • Development: For software development and unit/integration testing
  • Staging: Pre-production environment mirroring production configuration for validation testing
  • Production: Live environment serving end-users with high-availability multi-AZ deployments
• Software Update Mechanism:
  • Secure deployment pipelines via GitHub Actions
  • Semantic Versioning (MAJOR.MINOR.PATCH) with release candidate tagging (vX.Y.Z-rcN)
  • Bazel-based reproducible builds from tagged commits
  • Automated verification tests before production deployment

User Profiles and Access

• Healthcare Professionals (primary users):
  • Dermatologists, general practitioners, nurses, medical assistants
  • Access via authenticated API endpoints
  • Use device outputs for clinical decision support
• IT Personnel (infrastructure management):
  • IT administrators managing user accounts and permissions
  • IT teams responsible for network security and integration
  • Limited access to configuration, not to patient data
• Development Team (device lifecycle):
  • Software engineers with repository access (role-based permissions)
  • QA/validation team for testing and verification
  • Access controlled via GitHub authentication and branch protection
• Patients (indirect):
  • Data subjects whose images are processed
  • No direct access to the device

Data Types and Processing

• Input Data:
  • Clinical and dermoscopic images (JPEG/PNG, max 10 MB)
  • Patient metadata (age, sex, body site) - optional and non-identifying
  • JSON-formatted API requests
• Processed Data:
  • ICD-11 probability distributions across skin condition categories
  • Binary indicators (malignancy, urgency, priority)
  • Quantitative clinical sign measurements
  • Image quality scores and validation flags
  • Segmentation masks for lesion boundaries
• Stored Data:
  • User authentication credentials (hashed passwords, email, organization)
  • API request/response history with timestamps and HTTP status codes
  • JWT issuance/expiry events
  • AI model weights and configuration files
  • Training and validation datasets
  • Audit logs, application logs, and monitoring metrics
  • Historical versions of models and microservices

Network Interfaces and Protocols

• External API Interface:
  • HTTPS/REST endpoints for client integration
  • JSON payload format with base64-encoded images
  • Authentication via /login endpoint returning JWT
  • Protected endpoints require valid JWT in Authorization header
• Internal Communication:
  • Service-to-service communication within VPC
  • Database connections over TLS
  • S3 API calls with AWS IAM authentication

Third-Party Software (SOUP)

The complete list of Software of Unknown Provenance (SOUP) components is available in R-TF-012-019 SOUPs.

Constraints and Limitations

• User Responsibilities:
  • Healthcare providers must use the device according to Instructions for Use
  • Institutions must follow their own security and cybersecurity policies
  • Proper network security measures must be maintained by the healthcare organization
  • Device is intended to augment, not replace, clinical judgment
• Security Boundaries:
  • Device security is limited to components under manufacturer control
  • Cannot guarantee data security if used in insecure external environments
  • Dependent on healthcare organization's network and endpoint security
• Emergency Access:
  • No emergency bypass mechanisms that circumvent authentication
  • All access requires valid credentials and authorization
  • No provision for degraded security modes

Assets

The list of assests is:

• Hardware
  • Servers allocated in AWS data centers as virtual machines.
• Software
  • Legit.Health Plus stored in https://github.com/Legit-Health/md-legit-health-plus including:
    • AI models.
    • Control plane
    • Experts
    • Report builder
    • Report exporter
• Data
  • Audit records stored in DynamoDB.
  • Weight files of AI models stored in S3 buckets.
  • Configuration files.
  • User interaction records stored in AWS Dynamo DB (request/response history, API call records including timestamps, HTTP status codes, JWT issuance/expiry events).
  • User registration information stored in AWS Dynamo DB (email, password, name, organization, and authentication credentials).
  • Training datasets for AI models stored in secure cloud storage.
  • Validation and test datasets for AI model evaluation.

Actors

The following actors may have an access / operate the medical device throughout its lifetime:

• Manufacturer
  • Software development team
  • Production team
  • Technical support team
  • Seller
  • Trainer
• End user
  • Health Care Provider staff (dermatologists, general practitioners, nurses, medical assistants)
  • IT administrators of Health Care Providers
  • IT team of Health Care Providers
  • Patients (indirectly, through data they provide)

Diagrams

Connection diagrams

The connection diagrams show how the system components are connected together and what are the type connections.

They are available in the section Global System Views of the document Software Architecture Description.

Data flow diagrams

The data-flow diagrams show the data exchanged between the system components.

They are available in the section Global System Views of the document Software Architecture Description.

Threat model diagram

The device threat model diagram below depicts the system used to perform the threat model analysis.

This diagram has been built in Microsoft Threat Modeling Tool.

The "Internal Network Trusted Boundary" represents the secure network environment where the device operates, protected by firewalls and access controls.

The "AWS Trusted Boundary" represents the secure cloud infrastructure provided by AWS, which includes various services and resources used by the device.

The device interoperates with:

• Users (Healthcare Professionals and IT Personnel) who access the device via HTTPS requests over the internet.
• Let's Encrypt Certificate Authority, which issues TLS certificates to secure communications.
• PyPI Repository, which hosts third-party Python packages used by the device.

Multi-patient harm view

The multi-Patient harm view is available in the section view Multi-Patient Harm View of the document Software Architecture Description.

Updatability / Patchability view

The updatability/patchability view is available in the section Updatability / Patchability View of the document Software Architecture Description.

Security use case views

The security use case views are available in the section Security Use Case Views of the document Software Architecture Description.

Security analysis report

DEKRA conducted a CASA Tier 3 security evaluation of the D.med Software platform https://base-pre.legit.health/. The report describes the scope, objectives, and evaluation boundaries applied to the system’s cloud-based API.

Methodology

A black-box penetration test was performed following DEKRA's OSE framework, covering 133 evaluation cases. The assessment relied on tools such as Burp Suite, Fuff, Nuclei, Nikto, and OpenSSL.

Synthesis

All major evaluation areas achieved PASS, including authentication, access control, validation, and API security. Minor issues include one outdated dependency and the persistence of valid JWTs after account lockout.

Description of the report

The document compiles evaluation procedures, test evidence, and mitigation recommendations for identified findings. Each item includes impact details and concrete remediation guidance.

Static Analysis

The evaluation reviewed dependency versions, exposed components, and error traces to identify outdated or vulnerable elements. No insecure patterns or deprecated technologies were identified in the API stack.

Dynamic Analysis

Runtime testing validated request handling, schema enforcement, cryptographic behavior, and API endpoint resilience. Communication, data validation, and file management workflows behaved securely during executed probes.

Threat Modeling

Architecture and design checks assessed authentication flows, access control boundaries, and data handling structures. The evaluation confirmed adherence to least-privilege principles and absence of tampering paths.

Penetration test results

Penetration testing verified resistance against common API and web exploitation techniques. Findings highlight an outdated DCMTK dependency and the need to adjust JWT invalidation, while all remaining cases passed CASA Tier 3 criteria.

Report

Security Controls Traceability Matrix

Mapping ID	Security Control Description	Test ID	Test Description	Software Requirements
1.1. User Authentication	Use unique user credentials (username/password) combined with biometric authentication or smart cards.	V1-2-V1.2.3	Verify that the application uses a single vetted authentication mechanism that is known to be secure, extended to include strong authentication, and has sufficient logging and monitoring to detect account abuse or breaches.	SRS-WER. Endpoint Access Control
1.4. Account and Role Management	Role-Based Access Control (RBAC) with Least Privilege Principle to restrict users to essential functions.	V4-1-V4.1.3	Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege.	SRS-A25. Role-Based Access Control (RBAC) with Least Privilege Principle to restrict users to essential functions
1.4. Account and Role Management	Automatic account deactivation for inactive users.	V3-3-V3.3.1	Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties.	SRS-MM8. Generated JWTs must have an expiration date
1.4. Account and Role Management	Conduct periodic access review to verify permissions align with job functions.	V4-1-V4.1.1	Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.	SRS-X9J. Conduct periodic access reviews to verify permissions align with job functions
1.5. Secure Authenticator Management	Enforce strong password policies.	V2-2-V2.2.1	Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unl	SRS-U8M. Enforce strong password policies (min. 12 characters, complexity rules, expiration policies)
1.5. Secure Authenticator Management	Use hashed and salted passwords.	V2-4-V2.4.1	Verify that passwords are stored in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using an approved one-way key derivation or password hashing function. Key derivation and password hashing functions take a password, a salt, and a cost factor as inputs when generating a password hash.	SRS-U8M. Enforce strong password policies (min. 12 characters, complexity rules, expiration policies)
1.7. Unsuccessful Login Attempts	Lock accounts after five failed attempts.	V2-2-V2.2.1	Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unl	SRS-TPK. Lock accounts after five failed attempts
1.7. Unsuccessful Login Attempts	Implement progressive delays between failed login attempts.	V2-2-V2.2.1	Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unl	SRS-28X. Implement progressive delays between failed login attempts
2.1. Authorization Enforcement	Logging of all access attempts for auditing and anomaly detection.	V7-1-V7.1.3	Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures.	SRS-PU2. Comprehensive Event Auditing
2.3. Session Management	Auto log-off inactive users after a predefined period.	V3-3-V3.3.1	Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties.	SRS-MM8. Generated JWTs must have an expiration date
2.3. Session Management	Implement session termination upon detecting suspicious activity	V3-3-V3.3.1	Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties.	SRS-MM8. Generated JWTs must have an expiration date
2.4. Audit Logging and Monitoring	Tamper-proof logs stored in a Security Information and Event Management (SIEM) system.	V7-3-V7.3.3	Verify that security logs are protected from unauthorized access and modification.	SRS-A57. Audit Trail Data Retention Policy SRS-T5P. Audit Record Integrity Protection
2.4. Audit Logging and Monitoring	Log overflow protection to prevent loss of critical data	V7-3-V7.3.1 & V7-3-V7.3.3	Verify that all logging components appropriately encode data to prevent log injection. Verify that security logs are protected from unauthorized access and modification.	SRS-LOG. Log Overflow Protection
3.3. Software and Information Integrity	Perform or support integrity checks on software, configuration and other information as well as reporting the results of these checks.	V10-3-V10.3.2	Verify that the application employs integrity protections, such as code signing or subresource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet.	SRS-IC4. Software and Configuration Integrity Verification
3.4. Input Validation	Validate the syntax, length and content of any input data that directly impacts the action of the solution.	V5-1-V5.1.3 & V5-1-V5.1.4	Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (allow lists). Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers, e-mail addresses, telephone numbers, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match).	SRS-ID7. Input Data Validation
3.5. Error Handling	Identify and handle error conditions in a manner that does not provide information that could be exploited.	V4-1-V4.1.5	Verify that access controls fail securely including when an exception occurs.	SRS-EH4. Security-Safe Error Handling
4.1. Encryption for Medical Data	AES-256 encryption for data at rest.	V6-1-V6.1.1 & V6-1-V6.1.2	Verify that regulated private data is stored encrypted while at rest, such as Personally Identifiable Information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR. Verify that regulated health data is stored encrypted while at rest, such as medical records, medical device details, or de-anonymized research records.	SRS-WGF. AES-256 encryption for data at rest
4.1. Encryption for Medical Data	TLS 1.3 or TLS 1.2 encryption for data in transit	V1-9-V1.9.1 & V9-1-V9.1.2 & V9-1-V9.1.3	Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers. Verify using up to date TLS testing tools that only strong cipher suites are enabled, with the strongest cipher suites set as preferred.Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the preferred option.	SRS-1KW. Secure Communication Protocol Enforcement
4.3. Cryptography	Use cryptography security mechanisms according to internationally recognized security practices and recommendations.	V6-2-V6.2.2	Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography.	SRS-WGF. AES-256 encryption for data at rest SRS-1KW. Secure Communication Protocol Enforcement
6.2. Denial of Service Protection	Traffic Rate Limiting and Intrusion Prevention Systems (IPS).	V11-11-V11.1.4	Verify that the application has anti-automation controls to protect against excessive calls such as mass data exfiltration, business logic requests, file uploads or denial of service attacks.	SRS-CCD. Intrusion Prevention and Malicious Traffic Detection
6.3. Backup and Disaster Recovery	Regular, encrypted backups with integrity verification.	V8-1-V8.1.6	Verify that backups are stored securely to prevent data from being stolen or corrupted.	SRS-BK7. Encrypted Backup and Integrity Verification

Mapping IEC 62443-4-2 to FDA, IEC 81001-5-1, and IEEE 2621

Mapping Id	IEC 62443-4-2	FDA	IEC 81001-5-1	IEEE 2621
1.1 User Authentication	CR 1.1 - Human User Identification & Authentication	Identity management, user authentication (FDA premarket guidance 2023)	Identity and Access Management (IAM)	Authentication & identity requirements
1.2 Device Authentication	CR 1.2 - Software Process and Device Authentication	Device identity & integrity (FDA Cybersecurity 2023)	Device authentication & security policies	Secure device authentication
1.3 Multi-Factor Authentication (MFA)	CR 1.1 - RE(2) Multi-Factor Authentication	Required for critical functions (FDA 2023 draft)	Strong authentication methods	Multi-factor authentication (MFA)
1.4 Account and Role Management	CR 1.3 Account Management	Role-based access (RBAC) requirements	User provisioning & access control	Role-based access authentication
1.5 Secure Authenticator Management	CR 1.5 Authenticator Management	Password policy & encryption (FDA 2023)	Secure storage of security credentials	Password security best practices
1.5.1 Enforce strong password policies	CR 1.7 Strength of password-based authentication	Password policy & encryption (FDA 2023)	Secure storage of security credentials	Password security best practices
1.5 RE(1) Store authentication secrets in Hardware Security Modules (HSMs) or secure vaults	CR 1.5 RE(1) Hardware security for authenticators	n/a	n/a	n/a
1.6 Public Key Infrastructure (PKI)	CR 1.8 - Public Key Infrastructure (PKI) Certificates	PKI for device authentication (FDA Cybersecurity)	PKI-based authentication management	Secure key authentication management
1.7 Unsuccessful Login Attempts	CR 1.11 Unsuccessful Login Attempts	Password policy & encryption (FDA 2023)	Strong authentication methods	Password security best practices
1.8 Access via Untrusted Network	NDR 1.13 Access via Untrusted Networks	Segregation of networks	Zoning & access control	Network isolation techniques
1.8 RE(1) Explicit access approval for third parties	NDR 1.13 RE(1) - Explicit access request approval	Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” (2022)	n/a	n/a
2.1 Authorization Enforcement	CR 2.1 - Authorization Enforcement.CR 6.1 - Audit log	Least privilege, role-based access (FDA premarket)	Role-based access enforcement	Authorization & access control
2.2 Wireless Use Control	CR 2.2 - Wireless Use Control	-	-	-
2.3 Session Management	CR 2.6 - Remote Session Termination	Secure remote access policies	Auto-logoff and inactivity	Remote access control
2.4 Audit Logging and Monitoring	CR 2.8 - Auditable Events	Security logging & auditing (FDA Premarket 2023)	Audit trail & traceability	Event logging, retention policies
3.1.1 Malware Protection	CR 3.2 - Protection from Malicious Code	Software whitelisting & antivirus	Threat mitigation & malware	Anti-malware mechanisms
3.1.2 Detect Software Tampering	EDR 3.2 - Protection from malicious code	Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions	Threat mitigation & malware protection	Anti-malware mechanisms
3.2 Secure Software Updates	CR 3.10 RE(1) Update authenticity	Software integrity verification	Digital signatures & integrity checking	Integrity checking mechanisms
3.3 Software and Information Integrity	CR 3.4 - Software and Information	Software integrity verification	Digital signatures & integrity checking	Integrity checking mechanisms
3.4 Input Validation	CR 3.5 - Input Validation	Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions	-	-
3.5 Error Handling	CR 3.7 - Error Handling	Resilient system design (FDA Cybersecurity)	Error logging & failure	Secure error reporting
3.6 Secure Boot	CR 3.14 Integrity of the boot process	Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions	Secure Boot	-
4.1 Encryption for Medical Data	CR 4.1 - Information Confidentiality	Encryption of sensitive data	Data classification	Data encryption requirements
4.2 Secure Data Storage and Erasure	CR 4.1 - Information Confidentiality.CR 4.2 - Information Persistence	Encryption of sensitive data	Data classification & protection	Data encryption requirements
4.3 Cryptography	CR 4.3 - Use of cryptography	NIST-approved cryptography	Cryptographic modules (ISO 19790)	Secure key storage
5.1 Segmentation and Firewalling	CR 5.1 - Network Segmentation	Segregation of networks	Zoning & access control	Network isolation techniques
5.1.1 Deny-all, permit-by-exception	CR 5.2 RE(1) - Deny all, permit by exception	Segregation of networks	Zoning & access control	Network isolation techniques
5.2 Remote Access and Vendor Support Security	NDR 5.2 - Zone Boundary	Segregation of networks	Zoning & access control	Network isolation techniques
6.1 Continuous Monitoring	CR 6.2 - Continuous Monitoring	Continuous security monitoring	Intrusion detection & monitoring	Anomaly detection
6.2 Denial of Service Protection	CR 7.1 - Denial of Service Protection	Load balancing, DDoS protection	Resource availability assurance	Resilience mechanisms
6.3 Backup and Disaster Recovery	CR 7.3 - Control System Backup. CR 7.4 - Control system recovery	Secure backup & restore	Data recovery planning	Backup encryption

Threat analysis

The threat analysis has been performed with the threat modeling methodology STRIDE in order to identify the threats on the device.

The threat modeling methodology STRIDE has been chosen because it allows to analyze systems and networks used by the device context, classifying threats in a prioritized list, based on the likelihood of them occurring and the scale of their potential impact.

The threat analysis has resulted in the identification of 32 threats, which have been documented in the Security Risk Matrix, available in the document R-TF-030-004 Security Risk Matrix.

Security Assessment Activities Performed

Security Activity	Description	Responsible Party
Security Requirements Definition	Identify and document security requirements based on industry standards and regulatory obligations.	Cybersecurity Manager
Product Security Plan	Develop a comprehensive security strategy, outlining security controls, risk assessments, and compliance needs.	Cybersecurity Manager
Threat Modeling	Identify and assess potential threats, attack vectors, and vulnerabilities in the system architecture.	Security Champion
Penetration Testing	Simulate real-world attacks to identify security weaknesses and validate the effectiveness of security controls.	External Security Team
Traceability Matrix	Ensure all security requirements are mapped to design, development, and verification activities.	Security Champion
Security Risk-Benefit Analysis	Ensure whether the residual cybersecurity risks are acceptable in light of the device’s intended use.	Cybersecurity Manager

Summary of Unacceptable Risks and Residual Risks

Threat/Vulnerability	Risk Description	Potential Impact	Likelihood	Residual Risk (CVSS)	Risk Treatment	Acceptance Justification
n/a	n/a	n/a	n/a	n/a	n/a	n/a

Description of Benefits

The Legit Health solution provides significant benefits aligned with its intended clinical or operational purpose. No unacceptable safety-related risks were found. The device continues to provide essential value to users while operating within an acceptable cybersecurity risk profile.

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003, JD-004
• Approver: JD-001