Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
  • Records
  • TF_Legit.Health_Plus
    • Legit.Health Plus TF index
    • Legit.Health Plus STED
    • Legit.Health Plus description and specifications
    • R-TF-001-007 Declaration of conformity
    • GSPR
    • Clinical
    • Design and development
    • Design History File (DHF)
      • Version 1.0.0.0
        • Requirements
        • Test plans
        • Test runs
          • TEST_001 The user receives quantifiable data on the intensity of clinical signs
          • TEST_002 The user receives quantifiable data on the count of clinical signs
          • TEST_003 The user receives quantifiable data on the extent of clinical signs
          • TEST_004 The user receives an interpretative distribution representation of possible ICD categories represented in the pixels of the image
          • TEST_007 If something does not work, the API returns meaningful information about the error
          • TEST_008 Notify the user image modality and if the image does not represent a skin structure
          • TEST_009 Notify the user if the quality of the image is insufficient
          • TEST_010 The user specifies the body site of the skin structure
          • TEST_011 We facilitate the integration of the device into the users' system
          • TEST_012 The user can send requests and get back the output of the device as a response in a secure, efficient and versatile manner
          • TEST_013 The data that users send and receive follows the FHIR healthcare interoperability standard
          • TEST-014 The user authentication feature is functioning correctly
          • TEST_015 Ensure all API communications are conducted over HTTPS
          • TEST_016 Ensure API compliance with Base64 image format and FHIR standard
          • TEST_017 Verification of authorized user registration and body zone specification in device API
          • TEST_018 Ensure API stability and cybersecurity of the medical device
        • 🥣 SOUPs
    • IFU and label
    • Post-Market Surveillance
    • Quality control
    • Risk Management
  • Licenses and accreditations
  • External documentation
  • Procedures
  • Records
  • TF_Legit.Health_Plus
  • Design History File (DHF)
  • Version 1.0.0.0
  • Test runs
  • TEST_018 Ensure API stability and cybersecurity of the medical device

TEST_018 Ensure API stability and cybersecurity of the medical device

Test type​

System

Linked activities​

  • MDS-449

Result​

  • Passed
  • Failed

Description​

This test run is planned to ensure our medical device API is both reliable and secure. It focuses on two main objectives. First, it aims to verify that the API is available 99% of the time by continuously monitoring the API's performance and uptime over a one-month period. We'll check for any instances of downtime or interruptions, noting how often they occur and how long they last.

Second, the test run includes a security evaluation using the Intruder.io tool. This security scan will identify any critical vulnerabilities in the API that could be exploited by malicious actors. Intruder.io will conduct a series of tests to detect weaknesses like outdated software, misconfigurations, or potential unauthorized access points. The results will help us assess the overall security of the API and determine any necessary steps to strengthen it.

Run environment​

Here are the technical specifications of the runtime environment in which the test was conducted:

  • Operating system: macOS Sonoma (version 14.5)
  • Hardware specifications:
    • CPU:
      • Model name: Intel Core i9
      • Number of cores: 8
      • Thread(s) per core: 2
    • GPU:
      • Devices:
        • Intel UHD Graphics 630 (1536 MB)
    • RAM: 16 GB
    • Storage: 1 TB
    • Network:
      • Mean speed: 380 Mbps
      • Mean latency: 5 ms
  • Other relevant software: No particular software was used.
Penetration test environment

We have entrusted the vulnerability analysis to Intruder.io. As an external service, we do not have information about the technical specifications of the infrastructure used for the penetration tests against our API.

Test case runs​

The following test cases have been executed in this batch:

PLAN_018​

Outcome​

  • Passed
  • Failed

Expected results​

  • The monitoring program is running continuously for one month, sending GET requests to the API at the specified interval.
  • The database contains records of each request and the corresponding response information.
  • The total uptime, calculated as the percentage of successful requests out of the total requests sent, is at least 99% over the period of one month.

Actual results​

  • The monitoring program is running continuously for one month, sending GET requests to the API at the specified interval:

  • Since we started the background monitoring program, it has continuously emitted these types of log messages via the console for the past month, indicating that the service is up and running:

  • The database contains records of each request and the corresponding response information:

  • The total uptime, calculated as the percentage of successful requests out of the total requests sent, is at least 99% over the period of one month:

  • The percentage of API uptime was directly obtained from the dashboard provided as an add-on to the monitoring program:

Remarks​

No comments to add. The test was carried out manually without any issues.

TEST_019_001​

Outcome​

  • Passed
  • Failed

Expected results​

  • No high or critical severity vulnerabilities have been found that compromise the security of the REST API.
  • No medium or low severity vulnerabilities have been identified. Although these do not pose a significant security risk to the API, they could potentially lead to a security breach if they are left unresolved.

Actual results​

  • No high or critical severity vulnerabilities have been found that compromise the security of the REST API:
caution

Medium and low severity vulnerabilities have been identified. The findings report above shows that two issues were discovered during the analysis: one of medium severity and one of low severity. Thankfully, the report offers guidance (remediation advices) on effectively addressing these vulnerabilities.

Remarks​

No additional comments are required.

Summary of results​

  • Total cases: 2
  • Passed: 1
  • Failed: 1
  • Pass rate: 50 %

Defects and issues​

Defect IDDescriptionSeverityStatusReported byAssigned toActivities generatedRemarks
SWX_005_01MongoDB Database Exposed To The InternetMediumClosedAlejandro Carmena (JD-017)Alejandro Carmena (JD-017)Migration from MongoDB to AWS DocumentDB
SWX_005_02Strict Transport Security HTTP Header Not SetLowClosedAlejandro Carmena (JD-017)Alejandro Carmena (JD-017)Including the HSTS header in all API responses

Observations and recommendations​

During the test run, two minor security vulnerabilities were detected. While these issues do not necessitate immediate action, they must be addressed before the release of a new software version. It is recommended that the assignee prioritizes resolving these vulnerabilities to ensure the security and integrity of the software.

Previous
TEST_017 Verification of authorized user registration and body zone specification in device API
Next
🥣 SOUPs
  • Test type
  • Linked activities
  • Result
  • Description
  • Run environment
  • Test case runs
    • PLAN_018
      • Outcome
      • Expected results
      • Actual results
      • Remarks
    • TEST_019_001
      • Outcome
      • Expected results
      • Actual results
      • Remarks
  • Summary of results
  • Defects and issues
  • Observations and recommendations
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)