In a penetration test, a cyberattack is performed on an internal or external system, network, or web or mobile application to uncover as many risks as possible and make them measurable. This also includes cloud and container security. The goal is to validate possible attack paths and reduce the overall attack surface by uncovering the existing risks. Each penetration test is individually planned and adapted to the needs with a view to the big picture. A penetration test often combines automated tools and manual queries. Efficiency is paramount and specifically the Blue Team and its response to the attack is not tested. If this is desired, a Red Teaming should be performed instead.
If the following questions are still open in your company, a penetration test is recommended:
The purpose of the scoping meeting is to define the objectives of the penetration test and to transfer sufficient knowledge about the systems to be tested so that the quotation can be prepared on this basis. The questions mostly revolve around the number of systems, functionalities of the applications, different roles and authorizations, test depth and test scenarios.
The offer is prepared on the basis of the scoping meeting. In addition to the objectives, methods, price and general conditions, it also contains a suggested timeframe for execution. Of course, nothing is set in stone and the offer will be adapted to your needs. In principle, we always charge according to the actual effort involved.
In the kick-off, the test details are discussed with the responsible persons. In particular, the definition of the exact target systems and the provision of any accounts for the test are central. Fast and smooth communication during the test is also ensured in this meeting.
The tests are carried out in close coordination with the person in charge, thus ensuring that there are no bad surprises. As much test data as possible is then collected in the time available and any critical findings are communicated immediately.
The collected data is evaluated and measures are developed. The best measures are of no use if they cannot be implemented or require too many resources. Therefore, the feasibility of the measures in the tested infrastructure is checked in particular and any workarounds are taken into account.
The results are summarized and evaluated. Measures are proposed for all risks and their priority is recorded. The report also contains information about the tools and methods used, so that these could also be used in the future.
A closing meeting ensures that the results and measures from the test can be understood and implemented. Since questions usually only arise during the remediation, we are of course always available for further queries and are happy to provide information.
All results are submitted in a final report (PDF, Excel and JSON). This is where the real work begins. Cybersecurity can only be increased if measures are also implemented. Therefore, it is a key concern for us that the findings from the tests arrive at the right place in the right format and that media breaks are eliminated.
The final report in PDF format contains an introductory section, executive summary, tools and methods, test details, positive aspects and passed requirements, results and measures with detailed description, categorization and prioritization.
The Excel contains all results and measures with detailed description, categorization and prioritization. Thanks to the editable format, this list is suitable for further processing of the results and additional information can be easily added.
The JSON file contains all results and measures with detailed description, categorization and prioritization. The JSON format is the most common format for automated further processing of information and can often be fed into existing tools with little effort.
We categorize all findings according to their probability of occurrence and impact. If required, the CVSS score can also be calculated for each vulnerability.
Each report contains an Executive Summary, in which the results and recommended measures are summarized on one page and illustrated in diagrams.
Web Applikationen werden nach dem bewährten OWASP Application Security Verification Standard (ASVS) geprüft.The Application Security Verification Standard (ASVS) is a community driven initiative that aims to provide a framework for application-level security requirements and measures. Its focus is on defining the functional and non-functional security measures required when designing, developing and testing modern web applications and web services.
The following ASVS requirement chapters can be tested as part of a penetration test:
By checking a web application for ASVS requirements, the well-known OWASP Top Ten are automatically covered. The OWASP Top Ten were designed as an awareness document to draw attention to the most critical security vulnerabilities. As such, the OWASP Top Ten describe risks and not necessarily testable requirements. Therefore, OWASP recommends the use of ASVS for establishing a security standard for web applications. By using the ASVS levels and limiting it to specific chapters, the depth of testing can still be well controlled.
The practical web app penetration test can be viewed in two parts. In the first part, hardening measures and configurations such as TLS configuration, cookie attributes, HTTP headers, session management, etc. are tested. This part can be finally assessed in a predefined time frame. The second part then tests input validation, output cleanup, character encoding, access control measures, etc. In this part, possible injection attacks such as XSS, template, SQL injection and other attacks such as remote code execution and authentication bypasses are also tested. Depending on the functionality offered and due to the many attack possibilities, automated tools are also increasingly used in this part so that the application can also be examined as comprehensively as possible. For the second part, it is best to define a time frame in which vulnerabilities are searched for according to the best-effort principle. In this way, the depth of testing can also be well controlled and sensibly selected for the second part.
In an external penetration test, the systems that can be reached externally (from the Internet) are examined for possible attacks. The scope can be set to a few systems or to an entire company as such. In contrast to a web application penetration test, not every application is examined in depth and for missing hardening measures, but the focus is on practicable attack paths that would allow a real attacker to compromise systems and further spread to internal systems.
In a penetration test, the focus is always on efficiency and the goal is to uncover as many attack opportunities as possible in a quick way. Accordingly, it makes little sense to fight against existing defense mechanisms. If the focus is on checking the existing defense mechanisms and reacting to attacks, this is more likely to be red teaming or purple teaming. The boundaries are not always strictly defined and we are happy to accommodate your individual wishes. An external penetration test can also be well combined with a phishing awareness campaign and Open Source Intelligence (OSINT) Gathering to get the most comprehensive picture of the external attack surface.
In an internal penetration test, attack paths in a company's internal network are examined. The typical question answered here is:
"What happens after a successful attack via phishing or external systems?"
The scenario is chosen such that a compromised system is assumed (assumed breach) and the same methods and tools are used to search for attack paths. Investigating and cleaning up these attack avenues is an excellent way to protect against ransomware, as they use the same methods after the initial compromise to cause maximum damage. While phishing awareness can only lower the percent rate and thus reduce the likelihood, non-existent propagation opportunities are a real show-stopper for attackers. This becomes even more central because no matter how good awareness and vulnerability and patch management can be, the phishing click rate is unlikely to ever reach 0% and attackers are often faster than the best patch management. As with any penetration test, the focus is on efficiency and testing defenses and attack response are not part of the test. Purple and Red Teamings are better suited for this.
In a mobile application penetration test, a mobile app is checked for existing security vulnerabilities and missing hardening measures. On the one hand, communication with the server is checked, but also how the data on the device is secured. The proven Mobile Application Security Verification Standard (MASVS) from OWASP is used for this purpose.
The Mobile Application Security Verification Standard (MASVS) is a community effort to establish a framework of security requirements needed to design, develop and test secure mobile apps on iOS and Android. The MASVS can be used to establish a level of confidence in the security of mobile apps. The requirements were developed with the following objectives in mind:
The MASVS defines two security verification levels (MASVS-L1 and MASVS-L2), as well as a set of reverse engineering resiliency requirements (MASVS-R). MASVS-L1 contains generic security requirements that are recommended for all mobile apps, while MASVS-L2 should be applied to apps handling highly sensitive data. MASVS-R covers additional protective controls that can be applied if preventing client-side threats is a design goal. Fulfilling the requirements in MASVS-L1 results in a secure app that follows security best practices and doesn’t suffer from common vulnerabilities. MASVS-L2 adds additional defense-in-depth controls such as SSL pinning, resulting in an app that is resilient against more sophisticated attacks - assuming the security controls of the mobile operating system are intact and the end user is not viewed as a potential adversary. Fulfilling all, or subsets of, the software protection requirements in MASVS-R helps impede specific client-side threats where the end user is malicious and/or the mobile OS is compromised.
The following MASVS requirement chapters can be tested as part of a mobile application penetration test:
In an IoT, IIoT, or OT penetration test, the security of networked devices, industrial control systems, and embedded systems is comprehensively assessed. The objective is to identify vulnerabilities in hardware, firmware, and communications that could lead to the compromise of the device, the surrounding infrastructure, or the data being processed.
At the outset, the device’s hardware components are identified and analysed. This includes, among other things, processors, memory components, debug interfaces (e.g. JTAG, UART, SWD), as well as additional communication modules. Subsequently, it is examined whether existing security mechanisms such as secure boot, debug locks, memory protection, or physical safeguards can be bypassed. A successful bypass may, for example, allow the extraction or manipulation of firmware, sensitive configuration data, or cryptographic key material.
Depending on the device’s functionality and the available interfaces, further tests are performed. These include, but are not limited to:
If required, the device firmware is additionally examined in accordance with the OWASP Firmware Security Testing Methodology. This includes both static analysis of the firmware image (e.g. file systems, configuration files, hardcoded secrets, known vulnerabilities in libraries) and dynamic analysis through emulation or runtime analysis of the firmware. This approach makes it possible to assess the actual behaviour of the system under attack conditions.
For a structured security assessment, the test is aligned with established best practices and standards, including:
Due to their flexibility, containers are used in almost all stages of software development, be it development, testing or deployment. Ideally, great importance is already attached to cyber security in the CI/CD pipeline and it is considered a fixed component of the requirements and tests. Due to automation and flexibility, small mistakes can have a big impact and a regular review of security aspects is highly recommended. The least privilege principle should be rigorously enforced, as too many authorizations can lead to fatal damage in an emergency. These are exactly the points we look at together with you and are happy to provide the appreciated flexibility also with regard to cyber security.
