Penetration testing is a method for evaluating the security of an information system by simulating the t ypes of attack that are known to occur in the wild. The process can vary widely according to the requirements and purpose of the testing. Even the name given to this type of testing can vary widely.
During testing, we mimic rea l-world attacks to identify methods for circumventing the security features of an application, system, network, control system, business or process. This often involves launching attacks on real systems and data that use tools and techni ques commonly used by attackers.
The majority of penetration tests involve looking for combinations of vulnerabilities on one or more systems and/or processes that can be used to gain greater access than could be achieved throu gh a single vulnerability. Penetration testing can also be useful for determining:
- how well the system tolerates real world-style attack patterns
- the likely level of sophistication an attacker needs to compromis e the system successfully
- additional countermeasures that could mitigate threats against the system
- defenders? ability to detect attacks and respond
What sort of penetration test ing do I require
You may simply be looking to have the security of an individual system or application tested before it is deployed, or you may be interested in the wider security of your network. The testing may be needed for c onnection to a particular network and the precise nature of the testing will depend on the requirements for that network.
The depth and breadth of the testing performed will vary according to your requirements so make sure that these are clear before you consider any testing. You may just require a simple vulnerability scan of your external networks, or you may need many hours of involved manual testing.
The industry generally acknowledges three dist inct types of testing; White box, Grey box and Black box testing.
The testing team has complete carte blanche access to the testing network and has been supplied with network diagrams, hardware, op erating system and application details etc. prior to a test being carried out. This does not equate to a truly blind test but can speed up the process a great deal and leads to more accurate results being obtained. The amount of prior kn owledge leads to a test targeting specific operating systems, applications and network devices that reside on the network rather than spending time enumerating what could possibly be on the network. This level of information can allow a tester to focus on specific areas of interest and systems that are more likely to be vulnerable to attack. This type of test equates to a situation whereby an attacker may have complete knowledge of the internal network.
The testing team would simulate an attack that could be carried out by a disgruntled, disaffected staff member. The testing team would be supplied with appropriate user level privileges and a user account, and acce ss granted to the internal network by relaxation of specific security policies present on the network i.e. port level security. For example, testing using authenticated access to a web application can provide more information on the secu rity of an application than a black box test which may just end up testing the security of your authentication obtained. The amount of prior knowledge leads to a test targeting specific operating systems, applications and network devices that reside on the network rather than spending time enumerating what could possibly be on the network. This level of information can allow a tester to focus on specific areas of interest and systems that are more likely to be vulnerabl e to attack. This type of test equates to a situation whereby an attacker may have complete knowledge of the internal network.
The testing team would simulate an attack that could be carried out by a disgruntled, disaffected staff member. The testing team would be supplied with appropriate user level privileges and a user account, and access granted to the internal network by relaxation of specific security policies present on the network i.e. port level security. For example, testing using authenticated access to a web application can provide more information on the security of an application than a black box test which may just end up testing the security of yo ur authentication.
CREST provides a series of assessments for penetration testers and has been targeted more at the commercial world. The qualifications are now also valid as an equivalent to CHECK, and holding the relevant CREST accreditation's and SC clearance will allow you to be CHECK accredited. CREST provides separate assessments for both web applications and infrastructure, and now offers an entry level ?registered te ster? status, which is equivalent to the CHECK Team Member qualification.
Many companies offer a range of tests that vary in the amount of information that is provided to them. ?Whibox? testing entai ls providing full information, while ?Blackbox? testing presumes that the attacker has no privileged knowledge about the systems. Our recommendation is that the former is more beneficial to most organisations and since you are paying for time, it also provides the best value for money.
Typically you will be required to provide as much information as possible on the networks you wish to be tested: IP ranges, domains, URLs of applications, which systems and appl ications you consider key, and what IP addresses and systems should be avoided.
A main point of contact within the organisation, who is readily available, should also be agreed with the testing team before the testing takes pla ce in case of any problems the tester(s) encounter.
All of the information regarding the testing process should be compiled into a document by the testing company and should be signed off by a person within the organisation wit h the relevant authority before any testing should take place.
What else do I need to prepare?
In preparing for an assessment, users and administrators sometimes modify settings, to make their systems more s ecure resistant to attack, or compliant with policies and other requirements. While this can be viewed as positive, changes made under these circumstances are often only maintained for the duration of the assessment, after which the syst ems are returned to their previous configurations.
Providing no advance notice of assessments to users and administrators helps to address this challenge. Many organisations perform occasional unannounced assessments to supplem ent their announced assessments.
As security weaknesses are identified during an assessment, administrators may want to take immediate steps to mitigate them and expect assessors to re-assess the system quickly to confirm that the problems have been resolved. Although this desire for quick mitigation is admirable, assessors should communicate the importance of following the organisation?s change management policies and procedures.
Security assessment is often incorporated into development or deployment with little notice and narrow timeframes.
With advanced planning it can be made a regular part of the development or deployment cycle.
Time is a challenge when tes ting critical systems and networks that are in production: if testing techniques have the potential to cause loss of availability or other problems, then systems and networks may need to be tested out of hours. Remember that assessors ar e often restricted to testing timeframes while real attackers are not limited by such constraints.
Similarly, if you use any Intrusion Detection Systems IDS), make sure that they are disabled, or the testing) systems white list ed, so that their operation does not impact the testing and prevent the full extent of a vulnerability being explored. Testing of an IDS should normally be considered separately.
During an assessment, the organisation?s inciden t response team may detect an incident. This could be caused by the assessors? actions, or by a real adversary that happens to perform an attack while the assessment is in progress.
The incident response team or individual disc overing the incident should follow the organisation?s normal escalation procedures, and assessors should follow the guidelines set forth by the testing plan. It is recommended that assessors stop assessing the systems involved in the inc ident while the organisation carries out its response.