Automated and Continous Penetration Testing

Traditional penetration tests follow a fixed procedure.

1. Planning and preparation: In the planning phase, the objective of the penetration test, the scope of the test, the duration and depth of the test, exclusions, etc. are defined.
2. Scanning: During port and vulnerability scanning, weaknesses and risks are identified with the help of various tools. Passive attacks such as interception of communication are also possible.
3. Penetration/Exploits: In the third step, the vulnerabilities are exploited in order to compromise systems. In addition to penetrating systems, privileges are also extended in further steps, data is leaked and systems are taken over. The aim of the penetration tester is to find as complete a kill chain as possible from the initial intrusion to the complete takeover.
4. Report generation: The results of the test are evaluated according to risk and documented in a detailed report with evidence such as screenshots or documentation files as well as recommendations for remediation. In addition to the summary for the management, risks are also described in technical detail for administrators to understand.

The recommendations from the penetration test can then be implemented by the in-house IT department, by external service providers or with our support.

However, a fundamental disadvantage of this type of penetration test is that the test involves a relatively high level of effort and cost, which is why it is carried out less frequently.

Various providers promise to carry out automated penetration tests. Most automated penetration tests combine port scanning, vulnerability scanning and vulnerability testing through exploits in a common software.

The technology itself is not fundamentally new. For example, an automatic test can be started from the Metasploit Professional software from Rapid7. Metasploit Pro then scans the systems with the Nmap port scanner, which is called up as an external module, scans the systems with the in-house Nexpose Vulnerability Scanner or can even call up the Tenable Nessus Vulnerability Scanner via another external module and then imports the results back into the internal database. Using CVE numbers, vulnerabilities and existing exploits are combined and all possible exploits are automatically executed. After a successful intrusion, further so-called post-exploitation modules can be started, e.g. for privilege escalation, password hashes can be read and automatically cracked. Basically, these are all steps that might be carried out manually in a classic penetration test.

However, the strength of the human penetration tester lies in the creative linking of attacks to form a kill chain. At this point, any experienced penetration tester is still clearly superior to automated systems.

Most automated penetration tests are therefore more of an automated vulnerability management system for identifying vulnerabilities by the scanner and assessing the actual attackability by the exploit module. In particular, automated penetration test systems lack the ability to evaluate captured data for criticality. For example, a VM image downloaded from a share can be a backup of any unimportant client or a forgotten, highly sensitive snapshot of a domain controller. And only an experienced penetration tester knows how to become a domain administrator within five minutes in the second case.

The great strength of automated penetration tests is, of course, that they can be carried out automatically, i.e. without human intervention. As a result, automated tests are cheaper and can be carried out more frequently. While external penetration tests are carried out at most once a year in many companies and internal penetration tests are often only commissioned every two or three years, automated penetration tests can be carried out monthly, weekly or even daily for particularly critical and sensitive systems as part of vulnerability management.

Continuous penetration tests are penetration tests that are carried out every time a change is made to a web application, for example. As a rule, these penetration tests are automatic penetration tests that can carry out a large number of attacks in a very short time, for example to identify programming errors in software. A combination of static analysis of the source code and dynamic analysis is often used. In the static analysis, the program code is checked for possible errors using verification programs; in the dynamic analysis, the program code is executed and the input interfaces are maltreated with malicious and/or random input in order to find errors.

Such penetration tests offer the greatest benefit if they are actually carried out every time the program is changed. In agile software development in particular, one or more new program versions may be created every day, all of which should ideally be examined by such a penetration test. Many software developers therefore include continuous penetration tests in the build chain. The test often takes place directly after the completion of a build, with the new version only being released once the dynamic test has revealed no errors.

Of course, continuous penetration tests can also be combined with classic tests. For example, in addition to continuous testing during software development, a classic penetration test can accompany the transfer of the application from the integration system to the production system.

We work with you to design the right model for penetration testing and vulnerability management. We review the providers of automated penetration tests together with you and select the best provider for you. We support you in integrating continuous penetration testing into your development environment and your CI/CD pipeline.