Licensed to be used in conjunction with basebox, only.
basebox Cybersecurity Overview and Guidance
Purpose
This document provides an overview of the cybersecurity concepts and methods which are applied during the design and development of the basebox in the section basebox Software and Cybersecurity Lifecycle.
Since basebox is running in a customer environment the customer has the responsibility to protect basebox against cybersecurity attacks to ensure the CIA (Confidentiality, Integrity, and Availability) not only of the basebox application but his complete system an IT environment. This cybersecurity roles and responsibilities including customer guidance for security is described in the section Cybersecurity Guideline.
Note
This document does not contain detailed descriptions of cybersecurity controls and analytics like threat modelling and penetration testing because this information is of sensitive nature. The threat model and other detailed cybersecurity information can be audited after consultation with the company.
Terms and Definitions
| MDS2 | The MDS2 (Manufacturer Disclosure Statement for Medical Device Security) is a voluntary standard used by medical device manufacturers to communicate crucial security-related information to healthcare delivery organizations. The MDS2 affords medical device manufacturers the opportunity to communicate this information through a form or questionnaire that is included as part of the standard. Medical device manufacturers answer a series of questions (216 questions that cover 23 security capabilities) about the device which can then be shared with the healthcare organization. (excerpted from: The MDS2 Standard and Its Role in Medical Device Security (novaleah.com).) |
| OpenIDConnect | OpenID Connect allows a range of parties, including web-based, mobile and JavaScript clients, to request and receive information about authenticated sessions and end users. The OpenID Connect specification is extensible, supporting optional features such as encryption of identity data, discovery of OpenID providers, and session management (Source: Wikipedia). |
| Security capabilities | A security and privacy capability are a combination of mutually reinforcing security and privacy controls (i.e., safeguards and countermeasures) implemented by technical means (i.e., functionality in hardware, software, and firmware), physical means (i.e., physical devices and protective measures), and procedural means (i.e., procedures performed by individuals). Source: NIST Special Publication 800-53A Revision 5, Assessing Security and Privacy Controls in Information Systems and Organizations (nist.gov), PAGE 19. |
| Security controls | A safeguard or countermeasure prescribed for an information system or an organization designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements (Source: security control - Glossary | CSRC (nist.gov). |
Cbersecurity Planning
The following aspects were considered during the planning of Cybersecurity activities for basebox:
- Integrate Cybersecurity pro-actively in the Software lifecycle of basebox by considering the requirements from:
- IEC 81001-5-1, Health software and health IT systems safety, effectiveness and security Part 5-1: Security – Activities in the product life cycle,
- MDCG 2019-16 - Guidance on Cybersecurity for medical devices,
- GDPR - General Data Protection Regulation.
- MDS2 form.
- Consider Cybersecurity requirements early in design during the establishment of the software requirements and the architecture.
- Penetration testing and threat modelling shall be performed by an independent and certified test house.
- Inform the basebox customers and any other relevant stakeholder about the security approach and any security measures which need to be considered on customer side.
basebox Software and Cybersecurity Lifecycle
The picture below reflects the Software life cycle as used for the development and maintenance of basebox. Cybersecurity activities are integrated in the life cycle activities as annotated with a shield below.
Cybersecurity Activities during Software Development
The table below provides the more detailed descriptions along the annotations from the lifecycle description int the section before.
| No | Cybersecurity Activities within the Software Lifecycle | Reference |
|---|---|---|
| (1) | User needs comprise security and privacy needs including related standards. | User Needs, Software Requirements Specification and Architecture Description |
| (2) | Software requirements refine the user needs and supplement those on a more technical level including security requirements. | |
| (3) | Software requirements including the security requirements are transformed into a software architecture. | |
| (4) | The security requirements and the architecture provide input and the analytical framework for the threat model.
The software architecture describes the security capabilities as defined in the security software requirements and in the threat model. |
basebox Threat Model (not published) refer to: Figure 2 – basebox Functional Architecture with Cybersecurity Responsibilities. |
| (5) |
The following extensive security activities are performed during coding and unit testing:
|
basebox Testing Overview |
| (6) | Integration tests are automatically executed before any merge and enable regression testing which include security tests. | |
| (7) | System testing is covering the security requirements from the SRS (SW requirements specification) and the mitigation measures from the Security Risk Analysis / Threat Modelling. | |
| (8) | Penetration testing is considering security related system testing aspects and performed by an independent 3rd party test lab. | EXECUTIVE REPORT Pentest Basebox |
| (9) |
As part of deploying and integrating basebox in the customer environment, some of the risk of secure operation is transferred to customer, while some of the risk remains with the basebox.
Customer shall ensure that all security measures he must care about to ensure a secure operational environment are implemented before the installation of basebox. The Manufacturer Disclosure Statement for Medical Device Security (MDS2) is used to communicate crucial security-related information to customers. |
basebox MDS2 form (per customer request) |
| (10) |
Maintenance requests for security reasons may be triggered through the observation of new vulnerabilities and/or threats. Those observations might arise during:
|
N/A |
Cybersecurity Guideline
As described in the section “basebox Software and Cybersecurity Lifecycle” the software was developed having cybersecurity development activities integrated in the software lifecycle. But there are shared responsibilities for using the basebox Software in a secure way. Customers should use basebox as intended and follow the “Security guidelines” which are described in the following sections to ensure not only the security of basebox but also the customer application (client) and its IT environment.
Cybersecurity Responsibilities Overview
To ensure security for basebox and for its complete application environment multi tiers of responsibilities need to be considered. The basebox architecture below provides an overview concerning the Cybersecurity responsibilities for the basebox integration and application. Basebox customer responsibilities are indicated with a black shield. basebox cybersecurity responsibility is shown with a blue shield. The security responsibilities are described in a more detail in the next sections.
Customer Security Guidelines
Ensure security for the Backend system
Since basebox is installed and running on Backend system in the customer IT environment (e.g. on a server) the basebox customer shall protect the CIA (Confidentiality, Integrity, and Availability) of his Backend system environment. This can be achieved by appropriate security capabilities which are implemented by system specific technical and organizational security controls.
The following list illustrates some important cybersecurity capabilities and its controls which establish cybersecurity for the Backend (note: the descriptions are based upon MDS2 form definition):
- Authorization (AUTH): __The ability of the device to determine the authorization of users_ may be implemented by the following controls:
- Prevent access to unauthorized users through user login requirements.
- Push group policies to the device (e.g., Active Directory)?
- Assign different privilege levels based on 'role' (e.g., user, administrator, and/or service, etc.)?
- Person Authentication (PAUT): __The ability to configure the device to authenticate users_ may be implemented by the following controls:
- Enforce unique IDs and passwords for all users and roles (including service accounts).
- Configure the device to lock out a user after a certain number of unsuccessful logon attempts.
- Enforce creation of user account passwords that meet established (organization specific) complexity rules.
- Support multi-factor authentication.
- Support biometric controls.
- Support group authentication (e.g., hospital teams).
- Ensure that credentials are stored using a secure method.
- Automatic Logoff (ALOF): The device's ability to prevent access and misuse by unauthorized users if device is left idle for a period of time may be implemented by the following controls:
- Configure device to force reauthorization of logged-in user(s) after a predetermined length of inactivity (e.g., auto-logoff, session lock, password protected screen saver).
- Audit Controls (AUDT): The ability to reliably audit activity on the device may be implemented by the following control:
- Create audit logs or reports or use operating system logs to record system activities, like successful / unsuccessful login-events, modification of user privileges, presentation of clinical or PII (personally identifiable information) data, etc.
- Malware Detection / Protection (MLDP): The ability of the device to effectively prevent, detect and remove malicious software (malware) may be implemented by the following controls:
- Support the use of anti-malware software (or other anti-malware mechanism).
- Employ application whitelisting that restricts the software and services that are permitted to be run on the device.
- System and Application Hardening (SAHD): The device's inherent resistance to cyber-attacks and malware may be implemented by the following controls:
- Harden the device in accordance with industry standards.
- Perform software integrity checks (i.e., verify that the system has not been modified or tampered with).
Note
For a complete list of applicable capabilities and cybersecurity controls refer to the MDS2 form and related standards.
Ensure security for the Frontend Device
basebox Client applications are running on Frontend devices which are be used by the customers of the basebox customer (for instance a cell phone). Those frontend devices must be also secured by appropriate measures. The basebox customer should inform his customer about required security measures for the Frontend devices to protect the Client application and basebox.
Implement OpenID Connect controls to ensure security for the Client and basebox
The basebox Client applications shall be protected by the basebox customer by implementing appropriate security features from an OpenID connect service (like Keycloak). Some security features which establish Authorization (determines the authorization of users) and Authentication (authenticates users) for the Client are: * Create credentials management of users for authorization (based upon OAuth). * Enforce unique IDs and passwords for users. * Establish a password policy which consider most recent best practices including the creation of user account passwords that meet established complexity rules (protects also from brute force attacks). * The OpenID Connect service shall lock out a user after a certain number of unsuccessful logon attempts (protects also from brute force attacks). * Support multi-factor authentication. * Configure access tokens (basebox is depending on this feature). * Limit the lifetime of access tokens (basebox is depending on this feature).
The use of OpenID Connect controls to ensure security for basebox and the Data Base
OpenID Connect features provide security means like access tokens which do not only help to establish security for the Client application they are also used to implement an additional layer of security for basebox itself. They are used within basebox to verify the authenticity and authority of SQL requests and grant access to the SQL Database services. An appropriately configured lifetime of an access token minimizes the vulnerability of the client application and basebox in case of stolen tokens because an expired access token limits a basebox session. Additionally audit logs are setup to monitor and document any Data Base activities.
Basebox Updates and SBOM (Software Bill of Material)
Basebox Updates
The basebox Gmbh is informing basebox customer by using Newsletters which include information about bug fixes, new features, and any information about known vulnerabilities and Cyber Security Upgrades (CSUP). Those Upgrades are made available via the homepage basebox.io.
SBOM
As described in the section Cybersecurity Activities during Software development basebox was developed by using the programming language Rust (Rust is used as a robust and safer language to consider security during coding). During each Integration run of a basebox version a SBOM is created automatically which is the foundation for the Rust development environment build-in vulnerability analysis. The SBOM can be exported by using formalized formats like SPDX and will be delivered to customer per request.
History
| Released | Who | Changes |
|---|---|---|
| Dec-2023 | basebox | Initial Release of this document |