tech-file/Other/iec-81001.md

Basebox Compliance Conformity Assessment against: IEC 81001-5-1:2021 - Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, Activities in the product life cycle, (2021-12)

bold = TBD

Chapt	Requirements	How basebox Rel 1 development fulfilled the IEC 81001-5-1 requirements	References
	Introduction - The scope of the standard is limited to HEALTH SOFTWARE and its connectivity to its INTENDED ENVIRONMENT OF USE, based on IEC 62304, but with emphasis on CYBERSECURITY.	Introduction - Basebox is an Off-the-Shelf (OTS) DB component which can be integrated in any device which needs data base functionalility. Basebox has no specific intended use and is not a Medical Device.
1	This document defines the LIFE CYCLE requirements for development and maintenance of HEALTH SOFTWARE needed to support conformance to IEC 62443-4-1[11] – taking the specific needs for HEALTH SOFTWARE into account	In order to apply best practices for security and privacy engineering for the basebox component the requirements from IEC 81001-5-1 were followed as applicable.
2	Normative references	The following sections exlain how the requirements from the standard were applied during the design and devopment of basebox Revision 1.
3	Terms and definitions	Any requirements which were not applicable to the basebox development have an according rational.
4	General requirements	Many of the design and development documentation contain security and some confidential information. Those documents are not to be published herein. An according note is provided where applicable.
4.1	Quality management	But these design and development documents could be reviewed during any on site audit.
4.1.1	Quality management system	The establishment of an basebox adequate Quality Management System which comprises the complete life-cycle of basebox and which is based upon ISO 13485 is in preparation
4.1.2	Identification of responsibilities	Will be part of the basebox adequate Quality Management System based upon ISO 13485
4.1.3	Identification of applicability	Performed for basebox. (Note: not to be published)
4.1.4	SECURITY expertise	Security expertise was established by hiring experienced SW engineers during the start of the company but also by acquiring independent consultation from specialized external experts like the Johner Institute.
4.1.5	SOFTWARE ITEMS from third-party suppliers	These items are covered by basebox in the SBoM (Software Bill of Materials).
4.1.6	Continuous improvement	Will be part of the basebox adequate Quality Management System based upon ISO 13485
4.1.7	Disclosing SECURITY-related issues	Not applicable for basebox (since basebox is not a medical device). Any medical device company which is integrating basebox has to establish this activity.
4.1.8	Periodic review of SECURITY defect management	Will be part of the basebox adequate Quality Management System based upon ISO 13485
4.1.9	ACCOMPANYING DOCUMENTATION review	Peer Reviews were performed to ensure the completeness and correctness of any basebox accompanying documentation
4.2	SECURITY RISK MANAGEMENT	Threat modelling was perfomed for basebox. All identified threat mitigation controls were implemented and verified. Testing comprised a penetration test which was executed by an independent test house. (Note: threat model not to be published)
4.3	SOFTWARE ITEM classification relating to risk transfer	Shall be documented by any medical device manufacturer which integrates basebox.
5	Software development PROCESS
5.1	Software development planning
5.1.1	ACTIVITIES in the LIFE CYCLE PROCESS	Basebox was developed based upon state-of-the art software engineering methodologies and practices. A formalized software development process which is in compliance with IEC 62304 standard will be part of the upcoming holistic Quality Management system.
5.1.2	Development environment SECURITY	The development environment is secured according to existing security standards. E.e. by 2FA, backups, ssl and other measures. (Note: not to be published)
5.1.3	Secure coding standards	basebox was implementd by using the following public coding standard: LIST HERE. In addition, basebox has defined its own coding standards. These are: LIST HERE.
5.2	HEALTH SOFTWARE requirements analysis
5.2.1	HEALTH SOFTWARE SECURITY requirements	The Manufacturer Disclosure Statement for Medical Device Security (MDS2) form provides an overview of the standard based security requirements and capabilities which were specified and implemented for basebox.
5.2.2	SECURITY requirements review	The security requirements for basebox have been reviewed by an external and independent expert from the Johner Institute. (Note: the review results are not to be published)
5.2.3	SECURITY risks for REQUIRED SOFTWARE	tbd.
5.3	Software architectural design
5.3.1	DEFENSE-IN-DEPTH ARCHITECTURE/design	The basebox architecture and design was developed by having the defense-in-depth-strategy in mind. Security requirements were identified in lockstep with the development of the componenent and identification of its defense layers. (Note: the review results are not to be published)
5.3.2	Secure design best practices
	The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to identify, enforce and maintain secure design practices. The MANUFACTURER shall document secure design best practices, which should include but are not limited to: a) documenting all TRUST BOUNDARIES as part of the design; b) least privilege (granting only the privileges to users/software necessary to perform intended operations); c) using proven secure SOFTWARE ITEMS/designs where possible; d) economy of mechanism (striving for simple designs); e) using secure design patterns; f) ATTACK SURFACE reduction; g) removing backdoors, debug access and debug information used during development or documenting their presence and the need to protect them from unauthorized access; and h) protecting any remaining debug information from unauthorized access. The MANUFACTURER shall define a SECURITY ARCHITECTURE as part of DEFENSE-IN-DEPTH, including the practices listed above as appropriate.	The basebox architecture and design does consider secure design best practices like (non-exhaustive list): trust boundaries, economy of mechanism, attack surface reduction, removing backdoors, protecting any remaining debug information from unauthorized access. (Note: secure design best practices are not to be published)
5.3.3	SECURITY architectural design review	The architectural design review was performed by an external and independent expert from the Johner Institute. (Note: the review results are not to be published)
5.4	Software design
5.4.1	Software design best practices
	The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to develop and document a secure HEALTH SOFTWARE design and maintain the use of best practices for the secure design, taking into account: a) software technology at application level (for examples algorithms, methods); b) the programming technology used, (for example programming language); c) the secure design best practices in 5.3.2.	TBD inkl. 5.3.2
5.4.2	Secure design	Threat modelling comprised the identification of threats and efefctive mitigation-measures (also called security controls). These security controls were considered during the basebox design and implementation. (Note: the secure designs are not to be published)
5.4.3	Secure HEALTH SOFTWARE interfaces	Specification of Security settings
	The HEALTH SOFTWARE design shall identify and characterize each interface of the HEALTH SOFTWARE including physical and logical interfaces. As appropriate, the MANUFACTURER identifies as part of the design: a) whether the interface is externally accessible (by other PRODUCTS) or internally accessible – between SOFTWARE ITEMS of the HEALTH SOFTWARE- or both; b) SECURITY implications of the HEALTH SOFTWARE SECURITY CONTEXT on the external interface; c) potential users of the interface and the ASSETS that can be accessed through the interfaces (directly or indirectly); d) whether the static design includes access to interfaces across TRUST BOUNDARIES; e) SECURITY considerations, assumptions and/or constraints associated with the use of the interface within the HEALTH SOFTWARE SECURITY CONTEXT; including applicable THREATS; f) the SECURITY roles, privileges/rights and access control permissions needed to use the interface and to access the ASSETS defined in c); g) the SECURITY CAPABILITIES and/or compensating mechanisms used to safeguard the interface and the ASSETS identified in c) including run-time VALIDATION of inputs as well as handling outputs and errors; h) the use of third-party SOFTWARE ITEMS to implement the interface and their SECURITY CAPABILITIES; i) documentation that describes how to use the interface if it is externally accessible; and j) description of how the design mitigates the THREATS identified in the THREAT MODEL.
5.4.4	Detailed design VERIFICATION for SECURITY	Describe Peer reviews . What is documented and what was tested exactly?
	The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for conducting design reviews to identify, characterize and track to closure WEAKNESSES associated with each significant revision of the secure design including but not limited to: a) SECURITY requirements that were not adequately addressed by the design; b) THREATS and their ability to exploit VULNERABILITIES in PRODUCT interfaces, TRUST BOUNDARIES and ASSETS; c) identification, documentation and characterization of detailed design best-practices that were not followed (5.3.2 and 5.4.1).
5.5	Software unit implementation and VERIFICATION
5.5.1	Secure coding standards	The coding standards from 5.1.3 were applied during the coding activties
5.5.2	SECURITY implementation review	Peer review activties ensured: a) the adquate implementation of security requirements and design b) all security requirements and designs were implemented and can be traced down to code c) the coding standards (ref. 5.5.1) were applied Additionally static code analyses (SCA) was performed using TOOL D) to determine remaining secure coding errors
	The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to ensure that implementation reviews are performed for identifying, characterizing and feeding into the problem resolution PROCESS all SECURITY-related issues associated with the implementation of the secure design including: a) identification of SECURITY requirements (see 5.2) that were not adequately addressed by the implementation; NOTE Requirements allocation, including SECURITY requirements, is part of typical design PROCESSES. b) identify secure coding standards used and document any parts of the secure coding standards that were not followed (for example, use of banned functions or failure to apply the principle of least privilege); c) Static Code Analysis (SCA) for source code to determine secure coding errors using the secure coding standard for the supported programming language, as established in 5.1.3. SCA is often supported by tools, but it can be done through code inspections and codewalkthroughs. d) review of the implementation and its TRACEABILITY to the SECURITY CAPABILITIES defined to support the SECURITY design (see 5.3 and 5.4); and e) examination of THREATS and their ability to exploit implementation interfaces, TRUST BOUNDARIES and ASSETS (see 5.3 and 5.4).
5.6	Software integration testing	Integration testing was done in combination with penetration testing since basebox has to be integrated in some applications in order to perfrom those test activties. (Note: the test plan and results are not to be published)	correct?
5.7	Software system testing
5.7.1	SECURITY requirements testing	Since basebox is a sw component the comprehensive system testing shall be perfomed by the customer who is integrating basebox. But basebox is providing the list of security requirements (controls) to customers which are relevant for a secure integration of basebox in any system (medical device) and shall be considered therefore during integration and system testing activities perfomed by the customers.	correct?
5.7.2	THREAT mitigation testing	Welche verschlüsselungsmaßnahmen und andere spezifische Sicherheitsmassnahmen sind implementiert und wie sind diese getestet
	The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for testing the effectiveness of the mitigation for the THREATS identified and assessed in the THREAT MODEL. ACTIVITIES shall include: a) creating and executing adequate testing for each mitigation implemented to address a specific THREAT, in order to ensure that the mitigation works as designed; b) creating and executing plans for attempting to thwart each mitigation; and c) ensuring that the mitigation does not introduce other VULNERABILITIES to the design.
5.7.3	VULNERABILITY testing	Write list of OTS Components used in basebox (= SBoM) and check vulnarabilities of each one in public libraries and set reference link. Define relevance of each vulnarability for basebox.	Hier die Freitext Suche der cve / Mitre Web Seite. Geben Sie z.B. Windos 11 ein erhalten Sie eine lange Liste pot. Vulnerabilties, die dann auf ihre Relevenaz hin analysiert werden müssen
	The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for performing tests that focus on identifying and characterizing potential SECURITY VULNERABILITIES in the HEALTH SOFTWARE. Known VULNERABILITY testing shall be based upon, at a minimum, recent contents of an established, industry-recognized, public source for known VULNERABILITIES. As appropriate testing shall include: a) abuse case for malformed or unexpected input testing focused on uncovering SECURITY issues. This shall include manual or automated abuse case testing and specialized types of abuse case testing on all external interfaces and protocols. Examples include fuzz testing and network traffic load testing and capacity testing; b) ATTACK SURFACE testing to determine all avenues of ingress and egress to and from the system, common VULNERABILITIES including but not limited to weak access-control-lists (ACLs), exposed ports and services running with elevated privileges; c) “closed box” known VULNERABILITY scanning focused on detecting known VULNERABILITIES in (if applicable) hardware, host, interfaces or SOFTWARE ITEMS; NOTE 1 For example, this could be a network based known VULNERABILITY scan. d) SOFTWARE COMPOSITION ANALYSIS on all binary executable files including embedded firmware, to be used with HEALTH SOFTWARE and delivered by a third-party supplier. This analysis can be used to detect: 1) known VULNERABILITIES in the SOFTWARE ITEMS; 2) linking to vulnerable libraries; 3) SECURITY rule violations; 4) compiler settings that can lead to VULNERABILITIES; and 5) comparison of the software encountered to the software bill of materials. NOTE 2 Tools can support SOFTWARE COMPOSITION ANALYSIS by generating a list of software packages included. e) dynamic SECURITY testing – like e.g. fuzz testing, that detects flaws not visible under static code analysis, including but not limited to denial of service conditions due to failing to release runtime handles, memory leaks and accesses made to shared memory without authentication. This testing shall be applied if such tools are available.
5.7.4	Penetration testing	An independent pentest which did comprise fuzz testing was executed by the test lab of the Johner Institute. As mentioned above an integration of basebox in sample applications or systems were done in order to be able to perform the pen testing activities.
5.7.5	Managing conflicts of interest between testers and developers	In order to avoid the conflicts of interests between developer and tester in a small team the mentioned external and independent expertise from the Johner Institute and other security experts were consulted.
5.8.2	Release documentation	To be checked by GD when published
5.8.3	File INTEGRITY
	The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to provide an INTEGRITY VERIFICATION mechanism for all scripts, executables and other SECURITY-relevant files used with a HEALTH SOFTWARE. This ACTIVITY (or ACTIVITIES) is required to ensure that PRODUCT users can verify that executables, scripts, and other important files received from the MANUFACTURER have not been altered. Common methods of meeting this requirement include cryptographic hashes and digital signatures (which also provide proof of origin).	tbd.
5.8.4	Controls for private keys	tbd.
	The MANUFACTURER shall have procedural and technical controls in place to protect private keys used for code signing from unauthorized access or modification.	tbd.
5.8.5	Assessing and addressing SECURITY-related issues	tbd.
	The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for verifying that a HEALTH SOFTWARE or an update is not released until its SECURITY-related issues have been addressed and tracked to closure (see 9.5). This includes issues associated with: a) requirements (see 5.2); b) SECURITY by design (see 5.3 and 5.4); c) implementation (see 5.5); d) VERIFICATION / VALIDATION (see 5.5, 5.6 and 5.7); and e) SECURITY defect management (see 9.4).	tbd.
5.8.6	ACTIVITY completion	Will be part of the basebox adequate Quality Management System based upon ISO 13485
5.8.7	SECURE decommissioning guidelines for HEALTH SOFTWARE
	The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to create PRODUCT user documentation that includes guidelines for removing the HEALTH SOFTWARE from use.	tbd.
6	SOFTWARE MAINTENANCE PROCESS	A formalized software maintenance process which is in compliance with the IEC 62304 standard will be part of the upcoming basebox adequate Quality Management system. The formalized software maintenance process will consider and establish the security requirements from this standard
6.1	Establish SOFTWARE MAINTENANCE plan
6.1.1	Timely delivery of SECURITY updates	Statement in section 6 applies
6.2	Problem and modification analysis
6.2.1	Monitoring public incident reports	Statement in section 6 applies
6.2.2	SECURITY update VERIFICATION	Statement in section 6 applies
6.3	Modification implementation
6.3.1	SUPPORTED SOFTWARE SECURITY update documentation	Statement in section 6 applies
6.3.2	MAINTAINED SOFTWARE SECURITY update delivery	Statement in section 6 applies
6.3.3	MAINTAINED SOFTWARE SECURITY update INTEGRITY	Statement in section 6 applies
7	SECURITY RISK MANAGEMENT PROCESS
7.1	RISK MANAGEMENT context
7.1.1	General	Basebox is an Off-the-Shelf (OTS) DB component which can be integrated in any device which needs data base functionalility. Basebox has no specific intended use and is not a Medical Device.
7.1.2	PRODUCT SECURITY CONTEXT	For that reoson the ISO 14971 requirements are not applicable for basebox.
	The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to ensure that the intended PRODUCT SECURITY CONTEXT is documented. This ACTIVITY (or ACTIVITIES) is required to ensure that the minimum requirements of the environment and the assumptions about that environment are documented in order to achieve the SECURITY level for which the PRODUCT was designed. The purpose of defining this information is so that both the developers of the HEALTH SOFTWARE and the PRODUCT users have the same understanding about how the PRODUCT is intended to be used. This will help the developers make appropriate design decisions and the users to use the PRODUCT as it was intended. The SECURITY CONTEXT could include: a) location in the network; b) physical SECURITY or CYBERSECURITY provided by the environment where the PRODUCT will be deployed; c) isolation (from a network perspective); d) if known, potential impact to SAFETY caused by degradation of SECURITY; e) SECURITY controls implemented in dedicated hardware with which the HEALTH SOFTWARE is intended to be used. For example, it is important to document whether physical SECURITY is required. If no physical SECURITY is expected to be present, then that can add a number of related requirements such as not allowing push-button configuration on the PRODUCT. Another example is if the PRODUCT cannot feasibly (i.e. without reducing SAFETY or performance) implement a firewall of its own, it can be expected to be protected by a user-supplied firewall that connects it to the health-ITnetwork. Documenting these external SECURITY features for the PRODUCT (its SECURITY CONTEXT) allows developers to design a DEFENSE-IN-DEPTH strategy that complements this SECURITY CONTEXT and testers to validate and verify the SECURITY of a PRODUCT in an environment similar to how it is intended to be deployed. Having this PROCESS means that the deployment environment in which the PRODUCT is intended to be used is correctly represented in all PROCESSES involved in the development and testing of this PRODUCT and are documented.	But as oulined along the requirements in the previous sections of this list basebox was developed by applying state-of-the-art practices for security and privacy by design which comprises the complete life cycle of the component. Applying state-of-the-art practices for security and privacy shall help to reduce any cyber risk which might have an impact on health risk once the component ist integrated in a medical device. The referenced information may serve as input to the risk management process which has to be performed by customers: The referenced < document > describes the security context of basebox and provides security rules and controles which shall be applied by customer before integrating basebox in any customer application.	Risk Management inputs: - List of known bugs - SBoM, including the list of evaluated vulnerabilities (cve's) Security rules
7.2	Identification of VULNERABILITIES, THREATS and associated adverse impacts	Statements in section 7.1 and 7.2 apply
7.3	Estimation and evaluation of SECURITY risk	Statements in section 7.1 and 7.2 apply
7.4	Controlling SECURITY risks	Statements in section 7.1 and 7.2 apply
7.5	Monitoring the effectiveness of RISK CONTROLS	Statements in section 7.1 and 7.2 apply
8	Software CONFIGURATION MANAGEMENT PROCESS	Generic description of CI process here
	The MANUFACTURER shall establish a general PRODUCT development/maintenance/support PROCESS that includes CONFIGURATION MANAGEMENT with change controls and change history. For SECURITY obligations with HEALTH SOFTWARE already released or in the market, CONFIGURATION MANAGEMENT shall provide the capability to reproduce a list of included external components that are or could become susceptible to VULNERABILITIES.
9	Software problem resolution PROCESS
9.1	Overview	The establishment of an basebox adequate Quality Management System which comprises the post-market activties for basebox is in preparation
9.2	Receiving notifications about VULNERABILITIES	The post-market activties will comprise requirements for the sw problem resolution process which will be aligned with the following processes and activties: - receiving customer complaints - performing root cause analysis, also for potential vulenerabilties and, if required, in cooperation with customers - maintaing the threat model - performing corrective and preventive action - informing customers about known vulnerabilties
9.3	Reviewing VULNERABILITIES	Statements in section 9.1 and 9.2 apply
9.4	Analysing VULNERABILITIES	Statements in section 9.1 and 9.2 apply
9.5	Addressing SECURITY-related issues	Statements in section 9.1 and 9.2 apply
Annex A	Informative: Comprises: Relationship to IEC 62443 and IEC 62304, Risk Transfer, Secure coding best practices
Annex B	Informative: Guidance on implementation of SECURITY LIFE CYCLE ACTIVITIES
Annex C	Informative: THREAT MODELLING
Annex D	Informative: Relation to practices in IEC 62443-4-1:2018, Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements
Annex E	Informative: Documents specified in IEC 62443-4-1
Annex F	Normative: TRANSITIONAL HEALTH SOFTWARE