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) and made available via the Mesher platform. 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.
Via Mesher, your current security level is recorded and you can view the return on investment for the various measures. All results are also visualized here and can be linked to existing tools thanks to integrations. With the platform, technical measures can be assigned directly with tasks to the appropriate people and agile work without media breaks is enabled.
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:
Thanks to the shared responsibility model, at least part of the responsibility can be transferred to the provider. However, according to the motto trust is good, control is better, the existing attack surface should also be regularly checked here and it should be prevented that no one sees themselves responsible in the end. In the case of hybrid solutions, for example when integrating an on-premise Active Directory with an Azure AD, new opportunities can arise for attackers, which can assume devastating proportions. Additionally, it is often easier for attackers to use stolen or leaked credentials and access to resources should be kept as restrictive as possible and audited regularly. We know the current threats and help you to keep the attack surface as small as possible despite the dynamics in this area.
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.
