In one of my previous articles, I highlighted the details of PEN tests and the options you have to automate them. Compared to manual PEN tests you would get a “near-instant” result of (potential) security weaknesses in your software system. However, manual testing tends to reveal more deeply rooted security issues and thus adds even more value to your DevOps team to secure their application(s). All of these tests are seen from a rather technical perspective. But managing risks is all about business decisions. In the end, it’s the business owner who decides what to do: roll out a new version with some security flaws or drop all the work and fix a critical security issue. PEN testing in itself and especially the results being presented in the reports is a good starting point to improve. The value of PEN testing for your business organization.
Context
In this article, I will highlight a number of important aspects of PEN testing that would really help your business organization to further improve its effectiveness in respect of PEN tests and the findings they produce. The practical implementation of these ideas varies from organization to organization, but the generic aspects apply to every organization. Pick whatever suits you fine and applies to your specific situation.
Procedures
One of the first things to arrange is to create a uniform set of procedures. Simple, easy-to-follow procedures for every DevOps team to request a PEN test (in the case of a manual test), one procedure/methodology to follow to determine which type of PEN test is conducted (black box, grey box, white box, etc).
Same steps
Each PEN test should follow the same steps to carry out a consistent way of working. These steps often include preparation, constructing an attack plan, building the RED and/or BLUE team, finding the actual target to perform the penetration tests, and in the end carrying out the data analysis and reporting about it.
Within the step of the actual tests itself, the actual people that conduct the PEN test themselves should follow the same decision tree to determine which users and corresponding roles they require. For example an audit-user with read-only permissions on all components. In addition to that a single procedure to carry out the PEN test itself.
Consistency and content are king
PEN test reports should be structured equally to benefit from a number of advantages:
- It’s possible to compare different reports and it’s content.
- It’s easier to aggregate results and draw (management) conclusions about it.
- A similar structure helps to interpret results faster since they are consistent with each other.
It’s vital that every report has the same content blocks. These include the executive summary, the statement of objectives, the methodology, the tools which are being used as well as the attack narrative concluded with the results of the various tests.
The actual content
In addition to the above-mentioned content blocks, it’s important that the blocks themselves contain the same type of information.
- Executive summary: it should explain who requested the test with its intentions, the purpose of the test as well as the perceived benefits.
- In the statement of objectives, the reader should read about the overall goals such as finding easy-to-exploit vulnerabilities or weak cryptography techniques.
- In the methodology section, the types of tests should be noted down as to how these are carried out.
- The tools section describes the tools which are being used and how these tools are used in the tests themselves.
- Tests itself should be structured including the technical approach of how to actually carry out those tests.
- Every test should be described using the same template or form and how conclusions are drawn.
- Experts and decision-makers expect a summary as well as recommended actions from the PEN test. On top of this, it should include actionable advice on how to achieve the desired improvements.
When reports contain similar content blocks and similar ways to structure the internal contents, lengthy reports are easier to digest and take action upon.
Output format
Often PEN test reports are PDF files that are sent to the requester of the tests. The PDF is generated from a system dedicated to PEN tests or from a simple text editor like MS Word or LibreOffice. In order to process PEN test results in an automated way, it’s important to have the results available in a structured format like XML or JSON. This makes storage, comparison, aggregation, and automated processing a lot easier.
Different types
Since various types of PEN tests exist, it would be advised to cover one or more of them. Organizations use a combination of multiple types to cover all different topics which are of interest. The following types are particularly useful:
- API Pen tests to make sure your APIs do not contain security flaws and/or other vulnerabilities.
- Social Engineering Testing: a bit like a “double-blind PEN test”: the targeted persons do not know they are part of the PEN test. In this type of test, the attacker tries to gain access to IT infrastructure and other systems by influencing people inside the company itself. This is also testing out “employee security”.
- Web application testing: check out web applications for vulnerabilities and other weak spots. Those can always pop up irrespective of advanced firewalls and vulnerability scanners.
- Cloud security tests offer “on-demand” security testing capabilities for your applications.
- Network security tests: protect your critical network infrastructure and network devices.
- And last but not least: IoT security tests. Check out all of your IoT devices that require security scanning as well.
By using a combination of the above-mentioned tests, your PEN testing efforts make sure you got all areas covered and potentially find security issues that you would otherwise miss.
Methodologies
It’s possible to put different PEN-testing methodologies to practice. One of the most traditional PEN testing methods is to let one or two testers work in tandem for a fixed period of time. This is usually a couple of days or 1 week. Often companies expect a fixed budget and an up-front quality of work since the methods of attack are known and they know what to expect from “their people”. Despite the benefits, this method can lead to delays and the executors can be biased since they might know the system up-front.
Different teams
Companies that are a bit larger can also set up an internal security team (RED team) that actually attacks the intended target system while the BLUE team tries to defend it from those attacks. Some benefits include extremely sensitive work, little marginal costs, and full control over the method itself. The drawbacks are the relatively high costs. Talent needs to be kept and leavers need to be replaced which makes it a bit costly.
Crowdsourced Security Penetration Testing
A completely different approach is the method of Crowdsourced Security Penetration Testing. Often, participants are paid per project or pay per result. This involves a large crowd which is not known up-front. Companies seek these methods to also include the SDLC for their software application security tests. It offers a rapid setup and time to value which might reveal interesting results. Unfortunately, this method is not suited for very big targets and highly sensitive or physical targets.
Wrap up
As seen in this article, PEN tests offer valuable insights for your (security) organization to capture security flaws and other security misconfigurations in your IT infrastructure, IoT devices, network, and application (components). Different methods exist to capture various parts of your system. Often companies combine them to gain the best results. A consistent, well-structured PEN testing report in which the results can be automatically processed proves to be extremely valuable for companies to carry out these types of activities in the most accurate way. Be sure to include all of the content blocks mentioned earlier to make sure you’ve got the most important aspects covered so the senior management can make informed decisions.