Security testers and why your company needs them
Considering the speed of technological change, the development of cybercrime, and the demands on risk management, a security tester is an extremely challenging job in IT security. It's worth taking a look at how security testers meet these challenges and the thought patterns and approaches they follow.
Many young, enthusiastic techies opt for the field of IT security because here one can fight "evil" on the front line, so to speak, and also become a hacker oneself for legitimate reasons. In IT security research, the threats are often quite abstract, and you don't have to deal with real opponents. If, on the other hand, you work as a tester in the field of product security, the threats and opponents become much more concrete. In any case, however, it makes sense to keep some basic considerations and procedures in mind when dealing with daily, demanding tasks.
Wouldn't it be fun if a company hired you to hack their website/network/server? Well yes!
Although companies recognize that they cannot make every system 100% secure, they are extremely interested in knowing exactly what security issues they are dealing with.
What are penetration tests?
There are various types of security tests for IT systems and networks, but the best known is probably the penetration test, or pentest for short. The term originates from the military and refers to simulated attacks whose goal is to penetrate the enemy's defenses. For a company commissioning a pentester, this means that the contracted security company should attempt to break through or bypass the target's digital barriers and protective measures and gain access to the company's internal systems and data.
Of course, this must take place within a legally secured contract so that both sides are protected from damage. On the one hand, companies secure themselves by ensuring that exfiltrated data and found vulnerabilities remain under lock and key and may not be used for further purposes. At the same time, it is important for the testing security company to have written permission, as testing without this would be a criminal act. In principle, security tests may only be carried out with the permission of the owner of the object being tested.
It is important to note that pen testing is not the same as vulnerability testing. Vulnerability testing is intended only to identify potential problems, while pen testing is intended to attack those problems.
The existential question of meaning
An existential question in IT security is whether testing and patching matter at all. If there are thousands of vulnerabilities, does finding and patching ten make any difference at all, since the product will still be vulnerable? However, that would require that the vulnerabilities all have the same severity. Metrics are being developed to solve this dilemma. They are designed to show, for example, how many bugs there are per million lines of code, how many of these bugs cause security problems, and how many of these vulnerabilities are exploitable in a given threat scenario. However, a sound evaluation is only possible in retrospect.
In practice, the focus should therefore be on the general goal of defensive security. In doing so, one tries to increase the costs for the attacker in such a way that the attack is not worthwhile. Every patched vulnerability in the product means a lower chance for the attacker to find a vulnerability. This is one of the ways to make sense of one's work in the face of the above uncertainties.
Security testing can make all the difference. For example, the Android operating system has introduced additional containment strategies. These include better access control, attack surface reduction, and architectural decomposition – especially for parts of the system that suffered most from vulnerabilities, such as the media framework.
A healthy dose of paranoia
For security managers, staying on top of daily security-related news is already a challenge. Even political and legislative news can have an impact on security testing.
Another profound question any security tester approaching a new test target must ask is, "To trust or not to trust?" The information asymmetry (capabilities and knowledge of the respective parties are not public) among security stakeholders provides fertile ground for myths and plain paranoia. The reality, however, is that given the complexity of today's technologies, there are always some things that must be assumed as ground truths.
Cryptography is a case in point. Virtually all communication technologies rely on standardized cryptographic algorithms. In practice, only algorithms that are computationally secure are used. This means that they cannot be cracked within a reasonable time with reasonable resources in terms of cost, energy consumption, and so on. So you have to trust that the standardization process will ensure that approved algorithms are subject to close scrutiny by multiple independent experts so that no one has a significant advantage in deciphering the algorithms.
However, this does not absolve security managers from keeping abreast of security issues, conducting background research, and maintaining a healthy level of paranoia in order to make trust-based decisions. After all, there are always cases, such as that of Edward Snowden, who used leaked documents to suggest that weaknesses in a standard cryptographically secure random number generator called the Dual Elliptic Curve Deterministic Random Bit Generator were already known, and yet it was included in the lists of approved algorithms of an internationally recognized standards body from 2006 to 2014.
The purpose defines the direction
It has already become clear that threats are not black or white, but have different shades of gray depending on the perspective from which they are viewed and who is assessing them. Therefore, some sober facts are needed to provide clarity.
Testers should therefore ask themselves: What role does the test object play in the overall security situation? How is it used by customers and what are the security policies? What is the testing effort based on available resources and expertise? If a vulnerability is found, can we fix it? Is there a code refactoring or design change coming in the near future for the target system? Can the tests be automated? What is the history of the tested code base and is it maintained? What are the trends in vulnerability research?
These evaluations should be made before actual testing can begin. So, to do this, you need to increase the color contrast, so to speak, instead of defining the exact shade of gray. Defining the purpose of the test is of utmost importance in order to be able to work efficiently and purposefully.
From the black box…
In addition to tests for product security, penetration and security tests for external networks and devices are also part of the daily routine of a security tester. This is usually done either as black-box testing (no prior information about the target) or gray box testing (some information such as IT architecture documents is used as prior information). Discovering information about the target (what technologies are used, how it is configured, what the protected assets are, and sometimes even clues about the thought processes of the developers) through reverse engineering and reconnaissance is exciting in itself.
But this approach is even more open-ended in terms of results and expectations than white-box security testing, where the details of most parts of the implementation are available. Since it's hard to find out how well you've done your job, e.g., in terms of test coverage, there's constant pressure to finish testing with a valuable result – such as the discovery of a critical vulnerability on the target.
…to the White Box
White box tests have a different approach. However, experience gained in block box testing can be valuable here as well. This is because many white-box tests today start with a mess of complex frameworks and system environments and interconnected dependencies. As a result, sometimes even some basic pieces of code don't work as expected, which can be discovered through some kind of black-box testing.
In the field of product safety, the white-box approach is considered more efficient. However, this did not mean that testing can be done in less time, although the same coverage can be achieved faster. When you play your cards close to your chest, there are also higher expectations of a worthwhile outcome.
When code is available for review, new testing certification techniques and tools such as source code auditing and static and dynamic code analysis are possible. Worth mentioning here, for example, is fuzz testing, a testing technique that uses invalid, unexpected, or random data as inputs and is also an important part of black-box testers' arsenal. It could be used more efficiently through instrumentation – which enables faster, coverage-oriented fuzzing – and sanitizers that uncover previously unnoticed security problems.
We would like to point out that the tools you use for pen testing can be divided into two types – in simple terms, they are scanners and attackers.
That's because pen testing exploits vulnerabilities. So there are some software/tools that show you the vulnerabilities and some that show and attack. In the true sense of the word, the "showers" are not pen-testing tools, but they are inevitable for their success.
Testing tools used in black-box testing, such as vulnerability scanners, network traffic and attack analysis tools, and security scanners for Android applications, are also valuable. In theory, you could rely only on these tools (and their checklists), but usually, the goals are so unique that the tools don't cover all the relevant aspects. Therefore, security testing is not always about picking things apart, but also about developing the right tools for the job.
What should you look for in a pentest?
Unfortunately, many vendors no longer distinguish between these tests by name, as they sell best under as "penetration tests". For this very reason, we want to set a good example and present the different security tests as clearly as possible. Each test has its advantages and disadvantages, and it would be wrong to pigeonhole them all in the same way. Anyone who wants to commission a pentest should definitely clarify the following points:
Does the provider make a serious impression?
Has the provider explained what they mean by a pentest and how it works?
Has it been made clear what is being tested and under what conditions?
Scope: Were the systems to be tested and those excluded from the test clearly defined?
Time period: On which days and at which times may testing take place?
Source: From which IP addresses will tests be performed?
Contact: How can the penetration testers be reached in an emergency?
Goal: What is the goal of the security test and does this match the selected test type?
Has it been determined what will be included in the final report?
Summary of results.
A detailed description of the vulnerabilities.
Risk assessment of the vulnerabilities.
A sequence of the simulated attack
Instructions for eliminating the vulnerabilities
Do you have questions about penetration tests or other security tests? Feel free to contact us at any time or use the comment function, we will get back to you as soon as possible to clarify your questions.
What are the advantages of a pentest for companies?
A penetration test is primarily used to clarify specific security issues and test risks or scenarios. Unlike other security tests, this not only checks whether a vulnerability exists, but also whether it can be exploited and what an attacker gains from it. The final report summarizes the test results and usually contains not only an overview of the vulnerabilities but also a sequence of the attack and a detailed explanation of the exploited vulnerabilities and the exploits used.
In addition, penetration tests can be extended to include attacks that are not based on technical vulnerabilities. For example, employees can be tested in a simulated attack via social engineering methods to find out how employees behave in the event of an attack. Similarly, the physical security of the office building and employee behavior can be tested by having a penetration tester attempt to gain access to the office and thus gain access to company data. Tests that involve employees can also be combined well with other measures, such as security training for all employees.
Clarifies specific questions and allows testing of specific risks or scenarios.
Provides demonstrable evidence of whether and how a vulnerability can be exploited.
Explains how vulnerabilities have been exploited and what an attacker can accomplish as a result.
Can be extended to include social engineering and physical testing to test office building and employee security.
How does a pentest differ from other security tests?
Besides pentests, there are other ways to test the security of an infrastructure. These include automated vulnerability scans, manual vulnerability assessments, and internal security and compliance audits. Vulnerability scans provide a quick overview of the security status of a target system and are comparatively low in effort and therefore usually less expensive than other security tests. Vulnerability analyses, on the other hand, are based to a large extent on manual tests, in addition to automated scanners, and thus offer far more depth in terms of examining the target object, but are correspondingly more time-consuming and cost-intensive.
However, both security tests aim to uncover as many vulnerabilities as possible in order to improve the security of the tested system. Security and compliance audits, on the other hand, check whether a system is configured in accordance with a defined set of rules or standards and point out violations. The goal is usually to achieve 100 percent compliance with the selected set of rules. Penetration tests are less suited to uncovering rule violations or as many vulnerabilities as possible, but rather to answer specific questions. For example, the goal of a pentest could be to answer one or more of the following questions:
Is it possible to penetrate the internal company network from the outside?
Is it possible to steal internal company data?
Is it possible to take over the work equipment of the managing director?
Is it possible to record audio or video in certain meeting rooms?
These are just a few examples of how the objectives of a pentest differ from vulnerability scans, analyses, and audits. The objectives can be used to clearly determine whether a penetration test is appropriate or whether another security test is more suitable.
Summary
Security testing is a never-ending journey. Even for an "old hand" it is still exciting to find and fix new weaknesses in every test. The mix of certifications, the chance to learn something new every day, the challenge to resolve open issues, analytical thinking, the necessary pragmatism, and the collaboration with great colleagues and teams, still makes working in IT security a dream job for many.
