PENETRATION TESTING APPROACH
Develop a penetration test plan
Establishing the test ground rules is a particularly important part of penetration analysis. The rules are captured in the penetration test plan, which defines the test objective, the product configuration, the test environment, test resources, and schedule. It is important that penetration testing use ethical evaluators who are no antagonistic toward the vendor to encourage cooperation, to protect proprietary information and vendor investment, and ultimately to yield an improved security product. Test results and flaws discovered during penetration testing must be kept strictly proprietary and not be made public by the test team.
Establish testing goal
There can be many goals for penetration testing, including security assurance, system design research and systems training. The analysis is successfully concluded when:
- A defined number of flaws are found,
- A set level of penetration time has transpired,
- A dummy target object is accessed by unauthorized means,
- The security policy is violated sufficiently and bypassed, or
- The money and resources are exhausted.
Most often the last criterion ends the penetration test, after a defined level of effort is expended. For some systems, multiple independent penetration teams are used to provide different perspectives and increased confidence in the flawlessness of the product if few flaws are found. As a holistic assurance technology, penetration testing is best used to explore the broad capabilities of the object system for flaws rather than to create a gaming situation between the vendor and the penetration team of trying to acquire an identified protected object by unauthorized means.
Therefore, much of penetration testing focuses on the design, implementation, and operational integrity of the security perimeter, the control of the boundary crossings of this critical security interface.
Define the object system to be tested.
A system intended for evaluation is delivered with a collection of material and documentation that supports the security claim, including a security policy model, a descriptive top level specification a formal top level specification. All the source and object code, the design and test documentation, and the security evidence must be under configuration management control. This controlled collection of security material will be referred to as the security ―evidence, and defines the security system to be penetration tested. Not all the evidence will be complete if the penetration testing is performed by the vendor during the development phase. The evidence must be frozen and remain unmodified during the penetration testing period to avoid testing a moving target.
Posture the penetrator
When an actual test is required to confirm a flaw, a host of test conditions must be established, which derive directly from the test objectives and the test environment defined in the plan. In open- box testing we assume the penetrator can exploit internal flaws within the security kernel and work backward to find flaws in the security perimeter that may allow access to the internal flaws.
In the case of a general-purpose system such as UNIX, open-box testing is the most appropriate posture. For special-purpose systems which prohibit user code (for example, where code is in ROM), closed-box penetration testing by methods external to the product is analogous to electrical engineering ―black-box‖ testing. In closed-box testing the penetrator is clearly seeking flaws in the security perimeter and exploiting flaws in the interface control document specifications (ICD). Open-box testing of the NTCB is still a test requirement to determine the vulnerability of the network to Trojan horse or viral attacks.
Fix penetration analysis resources.
Penetration analysis is an open-ended, labor-intensive methodology seeking flaws without limit. The testing must be bound in some manner, usually by limiting labor hours. Small teams of about four people are most productive. Interestingly, penetration testing is destructive testing. It is intense, detailed work that burns out team members if frequent rotation of the evaluators is not practiced.
The procedure for penetration testing should follow the steps described below.
1. Research information about the target system Computers that can be accessed over the internet must have an official IP address. Freely accessible databases provide information about the IP address blocks assigned to an organization.
2. Scan target systems for services on offer. An attempt is made to conduct a port scan of the computer(s) being tested, open ports being indicative of the applications assigned to them.
3. Identify systems and applications the names and version of operating systems and applications in the target systems can be identified by ―fingerprinting.
4. Researching Vulnerabilities Information about vulnerabilities of specific operating systems and applications can be researched efficiently using the information gathered.
5. Exploiting vulnerabilities Detected vulnerabilities can be used to obtain unauthorized access to the system or to prepare further attacks. The quality and value of a penetration test depends primarily on the extent to which the test caters to the client ̳s personal situation, i.e. how much of the tester ̳s time and resources are spent on detecting vulnerabilities related to the IT infrastructure and how creative the tester ̳s approach is. This process cannot be covered in the general description above, which is why there are huge differences in the quality of penetration testing as a service.
