Getting to the right depth: exploring the fundamentals of pentesting

The right people

Experienced consultants will be able to demonstrate the necessary technical skill set and qualifications to carry out penetration tests with your organisation. They will be adept at translating technical problems they identify into actionable steps for your business. A technical consultant should also be supported by a skilled team to who will be able to assist in the professional handling of your test.

Qualifications are the most common way a security consultant can demonstrate their skill and understanding. Modern, high quality qualifications require a candidate to demonstrate both deep theoretical understanding of modern networks and systems, but also the hands-on ability to test for and exploit vulnerabilities. All this should be supplemented with the ability to meticulously document findings and remediation recommendations.

An effective penetration tester builds up knowledge and experience over their career. While being a penetration tester starts with a mind-set, the ability to apply this productively, consistently and in a risk managed way on your systems comes with experience. A junior consultant should be working under the supervision of a mentor for their first year of testing and consultants, team leads and principals will have increasing levels of experience. Each level should be able to provide highly effective core services with increasing specialisations and breadth of experience to be called upon.

The wider team behind the test ensure to match the right consultant with the specific experience needed to your test.

Many Consultants have experience working as developers or system administrators. This type of background means they have hands on experience with what it is like to be on the receiving end of a security test and can tailor their support to your needs.

Adopting the right methodology when conducting a test supports the skills and knowledge of the tester. The methodology ensures that all areas of security are evaluated during a penetration test and it becomes a repeatable process. This is vital if you are looking for a level of assurance about a system or systems and enables a view of a whole enterprise to be built up and issues prioritised for addressing. Additionally, this will give you an understanding of what is happening at each stage of the assessment and what your system is experiencing, so you are not left in the dark.

Finally, as the report is the only formal output from a penetration test, it must clearly explain the business threats identified to allow the level of risk to be determined. It should have sections that concisely explain the issues to executive or board members, a section that explains the vulnerabilities and business impacts to system owners and enough detail to help the technical team understand, re-create and fix the problems. An example of how the report layout may look and how each section benefits you could be:

1. Executive Summary - The executive summary is designed to be a one-page brief giving a high-level overview of the test and the results produced for senior leaders with decision making responsibilities. This will detail, in understandable and non-technical language, the most significant issues discovered and whether any urgent action is required. In addition to this it will also briefly discuss the results of any bespoke testing actions that you have requested.
2. Issue Summary - This summary lists each of the issues identified and their rating. This provides a visual representation of the issues discovered and their urgency, at a glance. The rating should be used to prioritise the highest impact issues for remediation first.
3. Issue Description - This section details the issues discovered, where the issue is, and how it was found. This will be in technical language and will allow your technical teams to develop a clear understanding of the identified issues, but will also detail the business impact of each vulnerability. Additionally, this section offers remediation recommendations, giving an idea of possible avenues of security hardening for your business to explore.
4. Supporting Material - Some issues detailed in the issue description section will require further clarification through screenshots or console output for example. This section contains the necessary information on how to recreate the issues that have been raised. Your technical team can then use this information to test remediation implementations.
5. Rating Methodology - This section gives you an understanding of the rating methodology used, so you can be sure where you stand with each issue raised.

The goals and objectives

The key to an effective penetration test is understanding and agreeing what the target and purpose of the test is.  The level of assurance you require, and the skill of your potential adversaries and your reasons for conducting a test can each change the recommended approach.

Testing for a regulatory requirement may have a well-defined set of parameters that need to be followed. However, testing to generally improve the security of the targeted system or overall network, or to address previously identified threats, requires more investigation.  Make sure your requirements are clearly defined and communicated to the test team before the test so the results are meaningful and can be utilised effectively.

When planning your penetration test you will need to decide the level and depth of testing you want to conduct. How extensive or comprehensive does the test need to be? Is it a high-value business critical system with multiple layers where each layer needs its own assurance, or does just a single user-facing layer need to be tested? Close consideration of exactly what you need to test is also of great importance - if you include too many systems in the test it could become prohibitively costly or may impact the depth of testing that can be achieved. Conversely, if you minimize the scope of the test too much and too few systems are tested, the value of the test will be minimal and you are likely to be left with an incomplete picture of your risk, which in the long run may prove to be costly.

Efficiently conduct the test

To maximise the value of your penetration test, you will want to provide enough detail of your target systems so the penetration testing team can quickly understand the environment and provide useful and accurate results. White box testing provides the consultant with knowledge of the internal structure of the system so the penetration testing team can quickly familiarise itself and get straight to identifying security issues. Providing this information in advance of the test ensures that the consultant will have time to read it and become more familiar with your environment.

If you are aware of some of the existing vulnerabilities within a system, make sure to fix these or inform the Consultants before you start as this may affect overall coverage.  This way the team will not waste testing time on issues you already know exist. The test will also provide the opportunity to test your remediation of those issues.

Once the testing has begun there are a few key considerations during the test to make sure it is efficient and valuable.  Primary among these is a dedicated technical contact the testing team can work with to ensure that any problems are resolved quickly.  Whether it is a password re-set for a test user, diagnosing system access issues, or talking through a business process to ensure a thorough understanding; the main contact for a test must be available throughout and have the time, technical knowledge and business authority to resolve issues.

A secondary consideration is the stability of the system, beyond how frequently it encounters issues. If the environment at the focus of the assessment is still in development, or there are other users interacting with the same datasets as the consultant, both teams will have difficulty working out who is causing which changes and could lead to confusion on both sides.

Equal to ensuring the stability of the system under test is agreeing the risk profile of the system.  There are different types of testing that are usually acceptable to conduct against live, development and UAT systems, depending on what else the system is being used for.  Agreeing which of these applies and what types of testing is suitable, and when the testing team should ask permission prior to taking particular actions will help the test run smoothly and ensure the best results. This can also affect the eligibility of the issues discovered, as issues found in a developing environment may not affect the production setup, so this needs to be established early on.

What testing might you consider?

Customers often ask for advice on what types of testing they should look to conduct to ensure the safety and security of their enterprise.  Although the answer to this question is dependent on the organisation asking and their specific needs, a rough outline for an average corporate might be:

1. Infrastructure, both internally or externally accessible.  This is the basis of all systems however they are abstracted, protected, translated, containerised or hosted, and if you are building on shaky foundations you can never be secure. This testing can either be carried out as a Vulnerability Assessment (VA) which is a high level and assessment or an infrastructure assessment which involves additional meticulous manual testing of each system.
2. Cloud, integration, build pipelines. If your organisation has embraced agile working, then both the security of your pipeline processes and the resulting systems are the key building blocks of your value chain.  The business needs assurance that they are well protected from external threats, but also internal attackers or simple accidents.
3. Web applications and web services.  These are often how your customers interact with you and have real business value, they are likely to be targeted by an attacker, and have extreme reputational value.  These are often the crown jewels of an organisation and are the bread and butter of security assessments. This type of assessment can be done with and without usernames and passwords (authenticated and unauthenticated). This will give you a real, in-depth picture of the security posture of the application, inside and out.
4. Mobile - iOS and Android.  Much like web applications, increasingly customers expect to be able to interact with an organisation via a secure mobile application and these therefore become focal points for business and reputation.  Ensuring that they stay secure means testing the applications users interact with and the end points the applications call on. This form of assessment can either be carried out using physical devices or emulated devices. Physical devices are more commonly used, particularly with iOS assessments as this will provide test results that are representative of ‘real world’ usage.
5. Build & configuration reviews. These are a type of testing that is starting to move towards auditing against best practice using full administrative access to a system, rather than trying to discover vulnerabilities from the outside.  It’s an important technique for when the next level of security is needed.  This type of testing is often used on key systems such as Active Directory Domain Controllers, network devices (such as firewalls and switches), database servers or web servers hosting transactional services.
6. Scenario driven testing. This type of testing allows specific concerns to be put to the test, scenarios should be tightly defined to ensure that full assurance can be given. Examples of scenario testing include breakout testing, social engineering and phishing. Scenario driven testing is ordinarily used to address specific or bespoke concerns which would benefit from investigation, this type of test is particularly fluid and can incorporate aspects of other testing types.
7. Whole organization security. This could be any one of Red teaming, Active Directory Attack Resistance testing, White teaming etc.  Its main aim is to stop thinking about individual systems and look at your whole organisation like an attacker would.

Remediation and re-testing

Once you have considered all the above points when planning your test - perhaps one of the most important, but often not planned for activities when it comes to penetration testing is the remediation of issues found. Remediation should be planned according to the risk level of the associated issue and system, giving higher priority to issues with higher ratings.

The report from a penetration test should clearly explain the findings so the level of risk can be determined. It should also contain sections dedicated to helping the technical team understand, re-create and fix the identified problems.

Advice should be available on potential remediation ideas and whether they will effectively fix the issue. This advice will be provided either by the consultant who carried out the test or another qualified consultant. This can either happen by phone or email.

You should ensure you build time into your project to fix issues identified and to verify the effectiveness of the fixes.

A re-test is a targeted assessment that investigates and confirms the resolution of previously identified issues. This can give you peace of mind that any remediation work that has been carried out has been done correctly and has been effective and, depending on scope will also verify that no new problems were introduced by the fixes.

As an NCSC, CHECK and CREST approved organisation, Context, part of Accenture Security is trusted to carry out penetration tests by both multinational blue-chip corporates and government bodies. If you'd like to discuss your Penetration Testing needs with us, get in touch today.