Professional penetration tests for organizations

Methodology

In this white-box penetration test we combine automated SAST techniques with in-depth manual source code analysis to reliably identify implementation errors, faulty security logic and structural weaknesses at the code level. Beyond machine-based detection, our experts specifically examine security-critical areas, architectural decisions and complex control flows that automated tools often cannot capture.

The dynamic application security test (DAST) is extended by our penetration testers with creative attack techniques, combinations of attack vectors and individual attack-path analyses that go beyond the capabilities of any automated solution. While DAST tests the running application and its interfaces for exploitable vulnerabilities, our testers additionally take into account the specific application context, the business processes mapped and possible unintended interactions between components. This reveals complex vulnerabilities that can only be identified through a human understanding of the application and its processes.

Through the combination of SAST + manual code analysis as well as DAST + creative manual attack simulation, we achieve a particularly high test depth and cover both static implementation errors and realistically exploitable vulnerabilities in the runtime environment.

Test object and test depth

The following test object was defined during the preliminary discussion for the quote:

• Web application
  • We check whether the web application is resilient against the most common vulnerabilities in web applications. Here we test the vulnerability classes of the OWASP Top 10 2025:
    • A01:2025 - Broken Access Control: We check whether users can only access the resources and functions they are authorized for, and whether unauthorized access is prevented by faulty access controls.
    • A02:2025 - Security Misconfiguration: We check whether systems, servers and applications are configured securely, e.g. no unnecessary services are active, default passwords have been changed and security-relevant headers or permissions are set correctly.
    • A03:2025 - Software Supply Chain Failures: We check whether the libraries, dependencies, build processes and software components used come from trustworthy sources and are protected against manipulation or compromise.
    • A04:2025 - Cryptographic Failures: We check whether cryptographic methods are implemented correctly and current standards are used to ensure the confidentiality and integrity of sensitive data.
    • A05:2025 - Injection: We check whether user input is correctly validated, sanitized and parameterized to prevent attacks such as SQL, command or script injection.
    • A06:2025 - Insecure Design: We check whether the application was already designed securely at the architecture level, for example through threat modeling, security principles and the targeted use of protective mechanisms.
    • A07:2025 - Authentication Failures: We check whether authentication mechanisms are implemented securely, e.g. through strong password policies, multi-factor authentication and correct session management.
    • A08:2025 - Software or Data Integrity Failures: We check whether software, updates and data are verified for integrity and authenticity to prevent manipulation and unauthorized modification of content.
    • A09:2025 - Logging and Alerting Failures: We check whether security-relevant events are sufficiently logged and alerts are triggered so that attacks or anomalies can be detected and handled promptly.
    • A10:2025 - Mishandling of Exceptional Conditions: We check whether error and exception conditions are handled correctly, without disclosing security-relevant information or creating unintended states.

Scope limitation Within this penetration test, no physical attacks, social engineering tests or denial-of-service (DoS/DDoS) scenarios are carried out.

Regulatory framework for the penetration test as part of the FDA premarket submission

When carrying out a white-box penetration test in the context of an FDA premarket submission, the test methods follow the security-relevant recommendations of the current FDA guidance for medical devices.

The test plan is developed individually during the preparation phase and forms the basis for all subsequent tests.

The following security requirements serve as a structured overview of the key test points:

• Authentication
  • We check whether the authentication mechanisms of the software and operating system reliably prevent unauthorized access, and whether identities are stored, managed and verified securely.
• Authorization
  • We analyze role and permission concepts to ensure that unauthorized access to safety- or patient-related functions is ruled out.
• Cryptography
  • We assess the implementation of cryptographic mechanisms with regard to the confidentiality, integrity and authenticity of data, and their correct configuration.
• Code/Data/Execution Integrity
  • We check whether protective mechanisms against manipulation, unauthorized code execution or integrity violations are implemented effectively.
• Confidentiality
  • We examine whether sensitive patient, diagnostic and system data are adequately protected during storage, transmission and processing.
• Event Detection & Logging
  • We assess whether security-relevant events can be detected, logged and evaluated in order to identify attacks quickly.
• Resiliency & Recovery
  • We test the system’s resilience against attacks, malfunctions or data corruption and assess existing restart and recovery mechanisms.
• Updatability / Patchability
  • We analyze whether security-critical updates, patches and maintenance procedures can be carried out in a traceable, secure way without endangering clinical functionality.

Note: The security requirements listed above serve as an overview. A detailed test plan, which forms the basis for the white-box penetration test, is developed by zentrust’s testers during the preparation phase.

Analysis of hardware and physical interfaces

The white-box penetration test includes an analysis of the hardware components and their physical interfaces. These components are analyzed for vulnerabilities and security flaws that could be exploited by an attacker with temporary access to the test object (example: a patient left briefly unattended with the test object).

In this phase, the testers primarily use attack tools available “on the open market” to do justice to the chosen attack scenario / attack potential (see below).

Analysis of software, operating system and interfaces (SAST & DAST)

The analysis of software and interfaces follows the same methodology as described in the web application example above: automated SAST techniques combined with in-depth manual source code analysis as well as DAST, extended with creative manual attack techniques and individual attack-path analyses. This finds errors in the code as well as vulnerabilities that can be exploited in the running system.

In addition, the hardening of the Microsoft Windows operating system for the defined environmental and operating conditions is analyzed during the white-box penetration test. The hardening analysis includes a comparison with internationally recognized standards (security recommendations) for the secure operation of the operating system.

For this purpose, the CIS (Center for Internet Security) benchmark for Microsoft Windows 11 / Windows 11 Enterprise is used as the primary reference standard. The CIS benchmark serves as a baseline for recommended configuration and security measures (group policies, registry settings, services, audit configurations, firewall and encryption settings, etc.). The test takes into account the current version of the CIS benchmark relevant to the target build.

Assessment of attacker potential (CEM, Common Methodology for IT Security Evaluation)

To assess the security of the test object, the attacker potential was determined per the Common Methodology for Information Technology Security Evaluation (CEM). Determining the attacker potential serves to classify the expected capabilities, resources and motivations of potential attackers and thereby make the required test effort and the validity of the test results traceable and reproducible. Factors such as expertise, knowledge of the ToE, window of opportunity, equipment and elapsed time (see Table B.2 of the CEM) are used to characterize the expected attacker potential.

This approach enables a transparent classification of the test results in relation to the threat scenarios realistically to be expected within the intended use and operating environment of the test object.

The resulting score allows the effort required to successfully exploit a vulnerability to be classified into one of five categories (see Table B.3 of the CEM):

Within the white-box penetration test, the effectiveness of the protective measures implicitly required by the security requirements from the FDA guidance is expected to withstand the calculated attacker potential. If effectiveness cannot be demonstrated, this is recorded as a deviation (fail). In the attack scenarios listed below, the calculation specific to the described scenario is presented in tabular form.

Attack scenarios and attacker potential

Scenario “Physical”

This attack scenario simulates an attacker who gains unsupervised physical access to the test object for a short period. It is assumed that the attacker acts for financial motives and has a particular interest in accessing insufficiently protected patient information (confidentiality). If access is successful, this information could be sold or used for extortion.

Example: A patient (attacker) is led into the examination room of a medical practice for an examination. The door to the corridor is closed with the note that the doctor will appear shortly. During this period, the attacker has unsupervised physical access to the test object.

Since the attacker wants to remain undetected, elaborate physical manipulation, for example opening the housing, is ruled out. The attack therefore focuses on physically accessible interfaces and the system’s input and output devices.

Calculation of the attacker potential for this scenario:

Scenario “Network”

This attack scenario simulates an attacker who accesses the test object over the network. It is assumed that the attacker is already inside the internal network of a medical practice.

The attacker acts for financial motives and aims to access sensitive patient information or impair the functionality of the medical device in order to make ransom demands. The main focus here is on the confidentiality and availability of the processed data.

Example: After successfully compromising a workstation in the practice network, the attacker scans the internal network for reachable devices. The test object is identified as a networked medical device that communicates via standardized protocols (e.g. TCP/IP, HTTP or proprietary interfaces). The attacker tries to gain access to the device or the transmitted data via known or insecurely configured network services, default accounts or missing authentication mechanisms.

Since the attack takes place covertly and remotely, no physical manipulation options are available to the attacker. The attack scenario requires technical expertise about network infrastructures, common attack vectors and knowledge of the test object’s communication interfaces.

Calculation of the attacker potential for this scenario:

Scope limitation

Within this penetration test, no social engineering tests are carried out.