IMPOSED LIMITATIONS

The ability to realize the true value of a penetration test is proportionate to the client’s interpretation of security and how those assumptions are translated into restrictions placed on the test. Limitations can be introduced by the customer for many reasons that can range from financial restrictions, which force less time and inherently reduce the scope of the engagement, to restrictions based simply on political positioning, personal perspectives on security, or a misguided attempt to focus the test.

Imposed limitations are elements of the test that are not employed for reasons that may not have anything to do with security. In fact, one could argue that imposed limitations have nothing to do with security at all and materialize to simply promote control of the engagement.

Of course, imposed limitations can be very positive controls placed on the test to foster accuracy, organize scope, and manage the force of the test. Usually, restric- tions are placed on the engagement to avoid an all-out attack on the network. Without some limitations, the probability of system failure, data loss or destruction, or excessive downtime is imminent. In addition to direct impact on the client, without scope control and management of permitted tasks, intermediates may become overly involved affecting business relationships and introducing legal exposures.

Obviously, the overall goal of introducing limitations on the test is to ensure total mayhem does not ensue. Meanwhile, one has to be careful not to place undue restrictions on the test that may be critical to the value of the engagement. All too often, the planners of the test introduce boundaries that usually make for questionable results and stale deliverables.

Unfortunately, a byproduct of unrefined imposed limitations is oversimplifica- tion, resulting in the point where everything is important and cannot be exposed to a test. By segmenting the security into very broad areas a sense of what digital components are critical to the organization can be realized. This is not an uncommon practice for other security-related services, but rarely used as an opportunity to control excessive limitations imposed on an ethical hack.

Again, when placing restrictions on the test the client must consider the impli- cations to the overall value of the test. The only way to accurately distinguish what restrictions are needed and which ones are superfluous, affecting the value of the test, is to clearly articulate what is being tested—what is the point of the test? Again, this is directly related to the assumed threat type and overall exposure to those threats. Even the smallest test that only focuses on one area of the network or a single application can be valuable if the goals of the test are within the scope of overall security needs in relation to the business objectives.

Imposed limitations can have more obscure results that do not readily appear and may remain hidden from view throughout the entire engagement and the final deliverables, ultimately affecting the implementation. Many of these have to do with limiting the tools, technique, and targets of the tester. It is very common for a client to specify what systems are permitted to be attacked and which ones are not, assuming that the attack will not yield any greater insight if the excluded systems were tested. Again, this assumption can be based on the importance of the server’s uptime or simply that the client does not feel there are any vulnerabilities and therefore does not permit the test.

At the other end of the spectrum is allowing all systems to be attacked, becoming overly involved in the test, and micromanaging which tactics can be employed. The assumption of the client is that he knows more about the target system and is therefore better positioned to determine when the attack is successful or has reached a dead end. Customers that demand close involvement usually hinder the process by the implication of distrust and disturbing the flow of the tester to work her art. Therefore, an imposed limitation can materialize in the form of customer micromanagement of the test when in nearly all cases it is best to leave it up to the experts.

So what are imposed limitations anyway? Following are some very basic exam- ples that some may consider outlandish and others may regularly practice. The point of the small list is to stimulate thought and introspection about your opinions of limitations that have the potential to affect value:

• No dumpster diving.

• Only test certain IP addresses. • Do not use ISS.

• No Trojans.

• No vulnerability can be exploited until permission is obtained. • Only wardial certain telephone numbers.

• No e-mail-based social engineering. • No Web application-focused attacks. • Only attack Windows systems.

• Do not attempt to avoid detection. • Only attack one site.

• Do not attack customer DNS systems. • No user-focused attacks.

• No DoS attacks.

• No information shall be shared between testers on the engagement. • No information is to be changed.

• No calling cards are to be left behind. • Do not attempt to attack ports over 1024. • Only test services running on specified ports. • If a password file is obtained, the test must stop.

The list can go on because every permution of attack is unique to each environment, but as you can see, there are some basic limitations that can affect the outcome. A few should stand out. For example, only permitting wardialing on selected phone numbers would seem counterproductive in discovering rogue backdoors. By limiting the numbers called, there is the assumption of security associated with the excluded numbers.

The same holds true for limiting the IP addresses. Best practices for determining IP addresses for the ethical hack is to define entire ranges or networks allowing the tester to seek entities you may not even know exist. Today, many stipulate what IP address to test, when in fact you should only specify IP addresses you do not want the tester to affect at all. Using the practice of defining what IP not to attack rather than those permitted promotes greater value to the test.

Finally, any limitations defined in the planning of the engagement, or even during the test, must be documented clearly. This is to ensure when the results are placed under scrutiny that there is a record of the restriction. This can be especially valuable when the value of the engagement is questioned by someone from the client who was not involved in the planning or execution of the test.

NOTE6: IMPOSED LIMITATIONS CAN CAUSE PROBLEMS FOR EVERYONE

During the planning meeting of an engagement, the customer made several stipulations on the scope of the test without any explanation. In the positioning of providing services it’s fairly difficult to make demands of the person who is paying you. The test was performed and the final deliverable and presentation were given to the CIO and the entire management staff. About halfway through the presentation the CIO made it clear that the work performed was well below expectations and questioned the value of our involvement. When the limitations of the test were conveyed the CIO was still not convinced they would have any impact on the test results and maintained his position. In an effort to make amends and to point out that the limitations did have an impact on the deliver- able, we offered a free two-week security assessment. At the end of the assess- ment the systems that were excluded from the test—which were either directly related to the included systems or on the same DMZ—were in fact wide open and presented an enormous threat to the company. When the manager was

questioned about the exclusion of the highly vulnerable systems by the CIO there was no acceptable answer. We were paid for the penetration test as well as the assessment.

It is difficult to completely convey the negative impact of excessive restrictions, especially those founded on poor reasoning with little or no alignment to business needs. However, this discussion is not to ridicule scope management practices to ensure safe and effective tests within the realm of the customer needs. Moreover, planning a test without having restrictions is nearly impossible and determining when a restriction is overkill is not always easy.

The best method to determine the impact of a limitation in question is to understand the desired outcome and value of an approved task. If you and the consulting firm can agree that the approved portion of the test will provide insights similar to the questionable limitation, then there is no need to scrutinize it. However, the imposed limitation may not allow the tester to accomplish a valued characteristic demanded from the test, but not plausible from other approved tasks. For example, a company states that no wardialing is to be permitted, yet there is a concern for people connecting from home with modems. Without an alternative to wardialing, there is little hope in supporting this demand and providing value.