What You Should Know About Penetration Testing: Expectations vs. Reality
By Douglas Bernardini
For the purposes of this article, we will define penetration testing as: “A method for gaining assurance in the security of an IT system by attempting to breach some or all of that system’s security, using the same tools and techniques as an adversary might.”
Penetration testing should be viewed as a method for gaining assurance in your organisation’s vulnerability assessment and management processes, not as a primary method for identifying vulnerabilities.
A penetration test should be thought of as similar to a financial audit. Your finance team tracks expenditure and income day to day. An audit by an external group ensures that your internal team’s processes are sufficient.
Pen Testing: The ideal
In an ideal world, you should know what the penetration testers are going to find, before they find it. Armed with a good understanding of the vulnerabilities present in your system, you can use third-party tests to verify your own expectations.
Highly experienced penetration testers may find subtle issues which your internal processes have not picked up, but this should be the exception, not the rule. The aim should always be to use the findings of a penetration test report to improve your organisation’s internal vulnerability assessment and management processes.
What should a penetration test tell you?
Typically, penetration tests are used to identify the level of technical risk emanating from software and hardware vulnerabilities. Exactly what techniques are used, what targets are allowed, how much knowledge of the system is given to the testers beforehand and how much knowledge of the test is given to system administrators can vary within the same test regime.
A well-scoped penetration test can give confidence that the products and security controls tested have been configured in accordance with good practice and that there are no common or publicly known vulnerabilities in the tested components, at the time of the test.
What sort of system should be tested?
Penetration Testing is an appropriate method for identifying the risks present on a specific, operational system consisting of products and services from multiple vendors. It could also be usefully applied to systems and applications developed ‘in-house’.
Using penetration testing effectively
A penetration test can only validate that your organisation’s IT systems are not vulnerable to known issues on the day of the test.
It’s not uncommon for a year or more to elapse between penetration tests. So, vulnerabilities could exist for long periods of time without you knowing about them if this is your only means of validating security.
Third party penetration tests should be performed by qualified and experienced staff only. By their nature, penetration tests cannot be entirely procedural, an exhaustive set of test cases cannot be drawn up. Therefore, the quality of a penetration test is closely linked to the abilities of the penetration testers involved.
Types of testing
Penetration testers can be used to perform a wide-range of testing. The following list is illustrative, not comprehensive.
1. Test basis
Tests can be carried out by testers armed with varying amounts of information about your system:
- Whitebox testing – Full information about the target is shared with the testers. This type of testing confirms the efficacy of internal vulnerability assessment and management controls by identifying the existence of known software vulnerabilities and common misconfigurations in an organisation’s systems.
- Blackbox testing – No information is shared with the testers about the internals of the target. This type of testing is performed from an external perspective and is aimed at identifying ways to access an organisation’s internal IT assets. This more accurately models the risk faced from attackers that are unknown or unaffiliated to the target organisation. However, the lack of information can also result in vulnerabilities remaining undiscovered in the time allocated for testing.
2. Test type
Each of the tests described below can be run as either a blackbox or whitebox operation:
- Vulnerability identification in bespoke or niche software – Most commonly used in web applications. This type of testing must give feedback to developers on coding practices which avoid introducing the categories of vulnerability identified.
- Scenario driven testing aimed at identifying vulnerabilities – The penetration testers explore a particular scenario to discover whether it leads to a vulnerability in your defences. Scenario’s include: Lost laptop, unauthorised device connected to internal network, and compromised DMZ host, but there are many others possible. You should consider, based on previous incidents, which scenarios are most relevant to your organisation.
- Scenario driven testing of detection and response capability – In this version of scenario driven testing, the aim is to also gauge the detection and response capabilities your organisation has in place. This will help you understand their efficacy and coverage in the particular scenario. This is an area of current work by the NCSC, further information will be available shortly, please contact us if you have a particular need in this area.
If you have a particular scenario that requires additional assurance, a specifically targeted penetration test may be a good way to obtain that assurance. A suitably qualified penetration testing team will be able to guide you through the selection and scoping process required in this case.
A model penetration test engagement
A typical penetration test will follow this pattern: Initial engagement, scoping, testing, reporting and follow up. There should be a severity rating for any issues found.
For this model we assume that:
- You wish to know what the impact of an attacker exploiting a vulnerability would be, and how likely it is to occur;
- You have an internal vulnerability assessment and management process
- Initial engagement of the external team
- You should ensure that the external team has the relevant qualifications and skills to perform testing on your IT estate. If you have any unusual systems (mainframes, uncommon networking protocols, bespoke hardware etc.) these should be highlighted in the bid process so that the external teams know what skill sets will be required.
Scoping
Scoping a penetration test should involve:
- All relevant risk owners
- Technical staff knowledgeable about the target system
- A representative of the penetration test team
- Where the goal of the test is to ensure good vulnerability management:
Special requirements: During scoping, you should outline any issues which might impact on testing. This might include the need for out-of-hours testing, any critical systems where special handling restrictions are required, or other issues specific to your organisation.
Plan of action
The output of the scoping exercise should be a document stating:
- The technical boundaries of the test;
- The types of test expected;
- The timeframe and the amount of effort necessary to deliver the testing – usually given in terms of resource days;
- Depending on the type of approach agreed, this document may also contain a number of scenarios or specific ‘use cases’ to test
The penetration testing team’s requirements: This will allow you to do any necessary preparation before the date of the test. For example, by creating test accounts or simply allocating desk space
Legal timeline: PenTest the testing plan must meet any specific reporting requirements, for example the inclusion of CVSS scores or use of CHECK severity levels, any compliance or legislative requirements, any specific time constraints on testing or reporting, that a penetration testing company will need to consider when allocating resources
Testing
Staying in contact: During the test phase, you should ensure that a technical point of contact is available at all times. The point of contact does not need to spend all their time working with the test team but should be available at short notice. This allows the test team to raise any critical issues found during testing, and resolve problems which are blocking their testing (such as network misconfiguration).
Taking care: The testers should make every effort to avoid causing undue impact to the system being tested. However, due to the nature of penetration testing, it’s impossible to guarantee that no unexpected reactions to testing will occur.
Changing scope: During a penetration test or security assessment, the testing team may identify additional systems or components which lie outside of the testing scope but have a potential impact on the security of the system(s) which have been defined as in scope.
In this event, the testing team may either suggest a change to the scope, which is likely to alter testing time frames and cost, or they may recommend that the exclusion of such components be recorded as a limitation on testing.
The decision on which would be the preferred option will generally be down to the risk owner, with the penetration team responsible for clearly articulating the factors to consider.
Reporting
The test report should include:
- Any security issues uncovered
- An assessment by the test team as to the level of risk that each vulnerability exposes the organisation or system to
- A method of resolving each issue found
- An opinion on the accuracy of your organisation’s vulnerability assessment
- Advice on how to improve your internal vulnerability assessment process
- A debriefing can also be useful. At this meeting the test team run through their findings and you can request further information or clarification of any issues.
- Severity rating
- When rating vulnerabilities it is common for penetration testers (often at customer behest) to use the Common Vulnerability Scoring System which attempts to give a numerical score identifying the severity of a vulnerability.
To simplify this measurement, CHECK reports are required to state the level of risk as HIGH, MEDIUM, LOW or INFORMATIONAL in descending order of criticality. For CHECK reports, scoring systems such as CVSS may be used in addition to (but not in place of) this.
Whilst vulnerabilities are ordinarily categorised at one of these levels in a consistent manner, exceptions can sometimes occur. For example, other mitigating controls in place could minimise the effectiveness of a vulnerability, or the presence of additional vulnerabilities could have a synergistic effect.
Any deviation from associating a vulnerability with its standard rating should be documented and justified by the penetration testing team.
source:
