When should you do a penetration test?
Penetration Testing and Linux
The information security field is filled with all kind of tests and assessments. One of them is the penetration test, also abbreviated to pentest or pen test. Last years, many security consultancy firms offer this test as part of their security services. So what is it really and when should you undergo a penetration test? Continue reading!
What is a pentest?
The short question to what a penetration is: a hack attack on your environment, executed by professionals, with approval and a written understanding (or contract). The attacking party has your permission to perform possibly harmful actions to your network, data, and people. Although most of the actions might be technical, it could also include non-technical steps. One of them might be tricking your staff to provide access or sensitive information, which we call social engineering.
Scope and jail
Within the penetration test there is a clear scope on what is included, and what not. If you only want your external web servers to be targetted, then the firm performing the penetration test is limited in what it can do, or is allowed to do. Another key component is the permission you provide. There should be a written statement that you ordered the security firm to execute possibly harmful actions. And if you do things correctly, you clearly state what is not allowed, like peeking in the mailbox of the CEO. For some assignments, the pentesters even get a “Get Out of Jail Free” card, which they can show to security guards or IT staff, in case they get caught during the assignment.
Besides scope, there might also be restrictions in the time that the assignment can happen. This could be the specific moment of when the actions happen or the total time of the assignment (e.g. one week). And to add another level, penetration tests might be “white box” or “black box”. This means that any information is shared upfront (white box), or none at all (black box).
Let’s use an example: company Acme has a website running on Red Hat Linux. The website accepts online payments, including credit cards. The company needs to be PCI DSS compliant and as part of the standard is required to have a penetration test performed. They ask the fictional firm RTP (Red Team Pentesters) to perform a penetration test on their website and Linux infrastructure.
Every well-executed pentest is performed by finishing the activities ordered in several phases. While each company has their own approach, there is a generic way of working. These steps are:
Let’s go through these steps quickly to learn why these phases are important.
Step 1. Reconnaissance
When the penetration test is started, the “attackers” start with collecting information about the target. They want to gather as much information as possible, before launching any other actions. This first phase is called reconnaissance. We might learn from job postings on the web that Linux is used, together with Apache and MySQL.
Step 2. Enumeration
After the first round of information gathering, more in-depth tests are being performed. This is called enumeration and can be considered a technical term for interrogating the system. For example, during reconnaissance we learned there is a website and who owns the domain name. We might now do an actual attempt to learn what software components are used. This can be done by looking at the HTML code of the website or request non-existing pages to see if there are information leaks. During the penetration test our fictional firm RTP might learn that WordPress 4.5.1 is being used, together with several outdated plugins.
Step 3. Exploitation
With all the information we gathered we can now try actual attempts against our target systems. Program code is executed to test if it triggers an expected or unexpected result. This might be leaking more information, or finding actual vulnerabilities. A vulnerability is usually a program error or weakness the software itself. The actual code being executed is called an exploit, hence the exploitation phase.
In this case, the pentesters of RTP find that they could use a successful exploit against the WordPress code. They gained access to the system and in steps retrieved more details step by step. Finally
Step 4. Documentation and reporting
Any successful achievements will have to be documented, like retrieving the password of the system administrator. It includes the steps taken on how the “price” was obtained, together with advice. Such advice could be related to protect against the used attack, or how to solve a discovered vulnerability.
The challenges with pentesting
With all the scoping and types and possibilities, pentesting looks like a customized project. That is actually the right way to approach it. It should have a clear begin and end, and define what outcome would make it a successful assessment. This is where things get difficult.
When a security company succeeds and is able to break in, you can say it was the right choice to do it. On the other hand, when the security company is not able to achieve a certain outcome (like obtaining administrator credentials), does that mean things are really secure? Maybe the skills of the related people are lacking, resulting in weaker capabilities to obtain the precious crown jewels. In other words, the pentest is as good as the people involved. Most systems can be breached if you have skilled personnel doing the pentest and give it enough time. With this thought in mind, all parties involved should be honest about the possible outcomes, the available time, and related costs.
Vulnerability assessments != pentest
Some penetration tests executed are actually vulnerability assessments. Instead of a well-executed penetration test that is based on a good understanding of the goals, a simple list of vulnerabilities is shared with the client. Although it may uncover flaws in the environment of the requester, it might lack the depth which a penetration test can provide.
One of the biggest mistakes that may happen is related to the title of this post: when should you do a pentest? Unfortunately too many companies do it too early. Sometimes because they are required by others, for compliance reasons, or being sold the magic powers by security firms. Consider that you want to test if your house is safe against burglars. Would it make sense to have a security assessment if you already knew there was not a lock on the front door, and no alarm system was present at all? Probably not. This is what often happens when the idea of a pentest is sold to the IT manager or owner of a company.
Correct order: Audit, Vulnerability Scan, Penetration Test
If you consider the phases a penetration tester performs during an assessment, we can apply the same steps. Each step gets a specialized security scan of its own.
Step 1: Reconnaissance = Audit
The first step was reconnaissance, or gathering basic details. This is similar to perform an audit. This may be a generic IT audit, looking at documentation in particular. This includes processes and the implementation of them in the daily IT practices of the company. On a technical level, we can perform a system audit. This gives a better understanding of the quality of all technical measures implemented and any room for improvement. It may include system hardening, intrusion detection capabilities, and dealing with automated security patching. Audits may also help with determining compliance with internal baselines and external standards like ISO27001/ISO27002, PCI DSS, and HIPAA.
Some audit tools can also help with information collecting and storage similar to a configuration management database (CMDB). The CMDB provides insights and details on the systems, their configuration, and ownership.
Related Linux software during this audit phase includes:
Step 2: Enumeration = Vulnerability Management
When the right procedures are in place and systems are properly hardened, the next level is digging in the details of our software. With software being a regular reason for systems being compromised, we can perform vulnerability scans. We look specifically on the software being used and see what possible exploits could be used against it.
Related software for Linux systems include:
- nmap (with plugins)
Step 3: Exploitation = Pentesting
Only when we have the right procedures in place and we did a deep technical scan of our environment, pentesting will be useful. Although security is an ongoing process, at some stage we should be confident enough that we did the right things. Now it is time for others to perform simulated (and real) attacks against our environment.
Related software during the exploitation phase includes:
Step 4: Documentation = Reports
The last step is about doing something with the data that some of the mentioned tools above provided. This could include live dashboards, PDF reports, or plain textual output. Especially program output can be powerful when collecting it centrally and parsing it into formats that your colleagues can use to plan the next cycle of improvement.
Penetration testing is a powerful measure to test your security defenses. Its value really shows when security is already part of the company culture, with the basics properly implemented. Then the pentest may uncover flaws that were missed before and encourages continuous improvement.
Pentests needs to be properly scoped, together with the right amount of time. This way both the security firm and tested company have a better assurance that the right things were tested and can withhold serious attacks.
For the Linux platform there are many tools to help with auditing, scanning for vulnerabilities, or even distributions that guide the pentest. Some are mentioned above. Got some great tools you use? Share it in the comments.