legislative regulation

In Annex I, for “devices that incorporate electronic programmable systems and software that are devices in themselves”, the MDR requires verification and validation under point 17.2 that the product or software was developed according to the state of the art – from the perspective of the IT security:

For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.

REGULATION (EU) 2017/745 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL
of 5 April 2017

In the Medical Device Coordination Group Document “MDCG 2019-16 Guidance on Cybersecurity for medical devices” there is now the requirement of penetration testing as a specification of the previous verification and validation requirement:

MDR Annex I Section 17.2 and IVDR Annex I Section 16.2 require for devices that incorporate software or for software that are devices in themselves, that the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of the development life cycle, risk management, including information security, verification and validation. The primary means of security verification and validation is testing. Methods can include security feature testing, fuzz testing, vulnerability scanning and penetration testing. Additional security testing can be one by using tools for secure code analysis and tools that scan for open source code and libraries used in the product, to identify components with known issues.

Medical Device Coordination Group Document, MDCG 2019-16

Participating in the Microsoft 365 Certification App Compliance Program for Microsoft Teams applications, Sharepoint Apps/Add-ins, Office Add-ins and WebApps requires performing a penetration test. In the Initial Document Submission a company needs to submit supporting documentation and evidence. Besides other topics, a Penetration Testing Report is required. A penetration testing report completed within the last 12 months. This report must include the pentest of the live environment that supports the deployment of the app along with any additional environment that supports the operation of the app. If segmentation controls are in place, these must also be validated.

The pentest requirements by Microsoft are:

• Every 12 months application and infrastructure pentesting must take place annually.
• These Tests are conducted by a reputable independent company.
• Remediation of identified critical and high-risk vulnerabilities must be completed within one month after the pentest report.
• The full external attack surface (IP Addresses, URLs, API Endpoints, etc.) must be included within the scope of penetration testing and must be documented within the penetration testing report.
• Web application penetration testing must include all typical vulnerability classes; for example, the most current OWASP Top 10 or SANS Top 25 CWE.
• Retesting of identified vulnerabilities by the penetration testing company is not required — remediation and self-review is sufficient however, adequate evidence to demonstrate sufficient remediation must be provided during the assessment. Retesting of identified vulnerabilities are nevertheless best practice in information security.
• Penetration testing reports will be reviewed to ensure there are no vulnerabilities that meet the following automatic failure criteria:
  • Unsupported operating system
  • Default, enumerable, or guessable administrative accounts.
  • SQL injection risks
  • XSS
  • Directory traversal (file path) vulnerabilities.
  • Typical HTTP vulnerabilities, e.g., Header response splitting, Request smuggling, and Desync attacks
  • Source code disclosure (including LFI)
  • Any critical or high score as defined by the CVSS patch management guidelines.
  • Any significant technical vulnerability which can be readily exploited to compromise a large amount of EUII or OUI

In addition to an ISO 27001 certification, regular penetration tests of sports betting portals must be carried out for the sports betting licence by the Darmstadt regional council. The pen tests must be carried out according to the OWASP Testing Guide or the OWSAP Testing Guide for web services.

The penetration tester must be independent and have the appropriate qualifications:

• Degree in technical computer science or a technical degree
• At least 3 years of professional experience in the field of IT security
• At least 2 years of professional experience in the field of penetration testing
• Certification as a penetration tester (including BSI-certified penetration tester, CPTC – Certified Penetration Testing Consultant, CPTE – Certified Penetration Testing Engineer, GPEN – GIAC Certified Penetration Tester, OSCP – Offensive Security Certified Professional or CEPT – Certified Expert Penetration Tester)

Penetration tests are mandatory for operators of critical infrastructures. In the BSI law under paragraph “8a Security in the information technology of critical infrastructures”, companies are obliged to take appropriate organizational and technical measures to protect their critical infrastructure.

The actual law is typically general and abstract. The wording itself does not require penetration tests for KRITIS companies to be conducted. But in the BSI publication of the controls to be carried out in order to adhere to the german law, penetrationtests are required.

In order to be included in the register of reimbursable digital health applications (DiGa), the fast-track procedure at the BfArM must be completed. With the Digital Supply and Care Modernization Act (DVPMG), the corresponding guideline included the requirement that company applicants must have a penetration test carried out for their DiGa application.

Penetration tests: With the DVPMG, this requirement was included in the DiGAV for all DiGA. Ensuring the security of the data throughout the entire application process and all conceivable usage scenarios is an essential requirement for DiGA.
Penetration tests enable the simulation of possible attack patterns and can thus help to uncover security gaps. For the product version for which inclusion in the DiGA directory is requested, a penetration test must have been carried out for all components. These tests are to be repeated as required, e.g. B. when new interfaces are added. The implementation concept for penetration tests of the BSI and the current OWASP top 10 security risks are to be used as the basis for the pentest design. Upon request, the BfArM must be provided with proof of the execution of the corresponding tests.

Inofficial translation of:
https://www.bfarm.de/SharedDocs/Downloads/DE/Medizinprodukte/diga_leitfaden.pdf
(document status as of 18 March 2022)

In principle, the requirements for a DiGa pentest can be summarized as follows:

• Implementation concept for penetration tests of the BSI
• OWASP Top 10
• for all components
• to be repeated as required (e.g. new interfaces)

I have already had several discussions with manufacturers of DiGA apps that they only want to have the actual mobile app (i.e. usually the iOS and Android versions) checked. However, the scope should not include an underlying API, which is used to implement some business functionality, which handles user authentication and is intended to serve as a central storage location for health data.

Of course, a “Mobile App” and an “API” are two different things and the regulation speaks of digital health applications (so Mobile Apps). However, this interpretation of the regulation does not achieve the goal and is simply wrong. The penetration test is intended to ensure “the security of the data throughout the application process” and the penetration test must be carried out for “all components”. Of course, this means that backend systems and APIs in the background are also included in the scope of the penetration test and not just the actual mobile app from the Android or Apple store.