Several different methods are used to assess the level of information security of a certain system or a customer’s ICT environment. The attack surface of the environment is analyzed with technical tools (such as a vulnerability scanner) using techniques based on open source intelligence and by interviewing the customer’s responsible persons. Technical information security controls are assessed against the industry’s best practices and applicable frameworks in order to get a good understanding of their adequacy and comprehensiveness in relation to the intended use of the system under consideration. In some cases, the customer wants to take the process even further and test the level of information security with penetration testing. In this kind of testing, a “white hat hacker” tries to gain access to the target system using different means agreed upon together with the customer. The purpose is to demonstrate possible deficiencies in the target’s security controls. This article describes in detail the kinds of tasks system penetration testing can typically include.
A suitable testing method is agreed upon together with the customer
Testing can be performed using different models, such as a black box or white box model. The most suitable testing method is agreed upon with the customer. In black box testing, the early stages require more time and effort from the “attacker” because no inside information about the target system, such as documentation or source code, is available.
In white box testing, the “attacker” has more information about the target to begin with and possible access rights to the source code or the system itself. For this reason, it is possible to speed up the white box penetration testing process and make it more efficient. For example, the tester can use the system’s source code to locate possible vulnerabilities more quickly or make use of “captured” basic user access rights to log into the system. Therefore, the architecture of the system being tested, and the technologies used can be better taken into account when planning and estimating the amount of work compared to black box testing – and based on this, the special expertise needed for testing can be selected. The points mentioned above make white box testing a more cost-effective method for achieving results. System knowledge also improves the possibilities for targeting the reporting to different subsystems.
How does penetration testing work in practice?
1. Kick-off
The scope of the system to be tested and the method of testing affect the required amount of work and time. By default, penetration tests carried out by Netum include a kick-off meeting, where issues relevant to the assignment are discussed: for example, the object or objects of the inspection, the technologies used, the customer’s and Netum’s contact persons, communication channels and details about data processing and storage of materials. In the meeting, practical issues related to testing are also agreed upon, such as the arrangement of necessary network access and user rights. In addition, it is agreed when the execution phase of the assignment will start, and it is also ensured that the necessary stakeholders (for example, server administrators) are aware of the testing.
2. Implementation
The implementation can include, for example, vulnerability scanning or source code analysis (white box). Penetration testing always includes a significant amount of manual work by an expert, with which an experienced “white hat hacker” checks out possible access paths to the target system. The access process aims to exploit detected vulnerabilities, but the testing methods may also include non-technical approaches, such as phishing for user data or passwords with so-called “social engineering” methods. In white box testing, it is possible to provide detailed descriptions of exploiting the vulnerability (proof-of-concept), the possible effects caused by the vulnerability, the criticality assessment and correction proposal, even down to the source code level. The recommendations include guidelines for fixing the vulnerabilities, based on, for example, the OWASP guidelines (Open Web Application Security Project).
3. Final results and testing benefits
After the testing, the customer receives a detailed report with a clearly described executive summary and detailed descriptions of the assignment’s background, scope and execution. The report contains all observations described in detail (including the verification of the observation), the estimated effects, an assessment of the criticality of the observation, and clearly described correction proposals.
The report is discussed in detail together with the customer, which enables the customer to ask for additional information, whether it is related to the report, findings or correction proposals. In addition to vulnerability correction proposals, other measures related to the target architecture to improve the level of information security can also be proposed to the customer. Examples of these include the introduction of secure operating processes or long-term development proposals that are estimated to improve the product’s information security and maintainability. Such development proposals can include, for example, the introduction of a tool suitable for static code analysis as part of the DevOps process, as well as the organisation of training related to secure application development.
With the help of our experts, you can identify your company’s or organisation’s cyber security, information security and data protection risks and ensure that your organisation’s cyber security level meets the set requirements and the needs of your operations.
