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 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:
- Risk owners should outline any areas of special concern
- Technical staff should outline the technical boundaries of the organisation’s IT estate
- The penetration test team should identify what testing they believe will give a full picture of the vulnerability status of the estate
Assuming you have one, a current vulnerability assessment should be shared with the testers at this stage. Testing can then be designed to support a reasonable opinion on the accuracy and completeness of the internal vulnerability assessment.
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
- Any compliance or legislative requirements that the testing plan must meet
- Any specific reporting requirements, for example the inclusion of CVSS scores or use of CHECK severity levels
- Any specific time constraints on testing or reporting, that a penetration testing company will need to consider when allocating resources
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).
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.
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.
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.
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.
Follow up on the report
- Do your own assessment
The penetration test report should be assessed by your organisation’s vulnerability management group in a similar manner to the results of an internal vulnerability assessment.
The penetration test team will have rated each issue found and given a potential solution. However, it’s important to note that risk assessment and decisions on the application of fixes are your responsibility.
The test team may not have had access to all details about a specific system or the potential business impact of the exploitation of a vulnerability. Consequently, they may rate issues either lower or higher than you. This process of assessing vulnerability levels should not be used to downplay issues – it should be a process of looking at issues and identifying the risk to your organisation.
2. Previously unknown vulnerabilities
Any vulnerabilities identified by the penetration test which you did not previously know about should be given special attention, with the aim of identifying ways in which you might go about spotting such issues in future.
3. Choosing solutions
The solutions proposed by your penetration testers may not be the only ones possible. You should take advice from your own technical staff and suppliers on alternatives.
As an example, imagine your pen testers have suggested patching a piece of software. You should ask yourself, ‘Is this the only solution to the problem?’ It may be possible to simply uninstall the software if it’s not actually required, or other controls could be put in place to limit exposure to the vulnerability. It may even be that additional monitoring of the vulnerable component is sufficient to reduce the risk to an acceptable level.
Vulnerability risk assessment and mitigation is a business process and should not be wholly outsourced to the test team