Penetration Testing involves actions that can go beyond scope to a large extent thereby presenting the need to invest more time in understanding the goals of the test. This mostly includes scope and rules of engagement for the test. While the clients have their terms prepared already, it is always advisable for the tester to engage in defining them clearly where the tester may also contribute to a better strategy avoiding scope creep. As an example, to check if a server is vulnerable to Denial of Service attack, requests are probed in huge number which may clog the network rendering the server unresponsive which is not acceptable. For such activities, the target server needs to be isolated, or metrics should be defined in terms of the number of denied requests/time to serve a request for an acceptable range beyond which an alert is triggered before it causes additional problems. Such things are to be well defined while planning the test strategy.

Scope:

Penetration Testing is not something which one can work on to experiment his skills; rather it is where things are done according to established practices/standards. Testers need to be clear on what, how, where and why of the test environment. Make sure that other things in the test environment don't get messed up due to improper planning. Be cautious to confine the test to include only the devices that are agreed by the customers during the planning stage.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Legal aspects of our pen test are to be considered with the utmost importance. Both parties need to be familiar with laws of the jurisdiction under which test environment and test location fall. There might be cases where a pen test is required to be performed remotely. In such cases, it is required to obey laws applicable at locations of the test environment and the place where actual testing takes place from. Always make sure that what you do is allowed to do. If something in the test plan approved by the customer is not permitted under local laws, it would be wise to bring that to their notice and would be better to avoid such cases though client requests you to perform those activities. While testing for vulnerabilities, one may consider using some software that is considered malicious for simulating an attack. It is important to note that use of such software is restricted in many jurisdictions. Even if it is allowed by law and the client, they might infect the test environment. So, it is advisable for the tester to make sure that the test environment is isolated for this purpose or avoid the use of such malware if the environment cannot be isolated.

Clients are also responsible for providing testers with all the information that would be needed to serve the cause of their test. If anything they feel not to be disclosed, they need to make sure that is not involved in any of the procedures that would be employed for the test. If anything the tester suggests for making the test effective but is not allowed to do; clients are required to explain to tester why they would not be permitted for a better understanding of the goals of the test.

Timelines and costs involved are something which cannot be ignored. It is important to agree upon timelines allowed for our pen test. The tester needs to estimate the time that could be consumed for the test to complete depending on the resources provided and performance of the infrastructure during the test period. It shall be ineffective if our test takes long period than the allowed time during the planning stage and it may be interrupting client's business operations. Some help of technical experts from client's organization can be used to understand the performance of test environment for our estimation.

Dealing with third parties:

If the client is served by Managed Security Service Providers(MSSP), it is crucial that our pen test doesn't violate the terms of MSSP. However, the client can request any access/privileges to MSSP's environment that serves them, but the chances are that it cannot be agreed with as there might not be dedicated infrastructure from MSSP to serve the client and they do not
want any risk to their organization. The tester may be limited to a great extent because of this and has to plan strategy accordingly. If the Managed Security Services are operating on our client's premises, then there may be a chance of performing pen test which increases scope. However, it would benefit the purpose of the test if MSSP is notified and involved in this process. With recent improvements in cloud computing services, the client might also be leveraging on cloud service providers for platforms, Infrastructure & software and in general terms, customers are not supposed to use these services for malicious purposes or simulate any attack on them even if it is not with malicious intent. Causing so may result in termination of services by the cloud service provider to our client which is not desired.

Rules of Engagement:

Most common practice is the tester carries with him, his own system with all necessary tools required for pen test to be carried out. It should be remembered that the purpose of the test is not to alter any of client's environment, but only to assess the security. So, it is better to avoid any installation of the software in a test environment or change any of the network configuration.

The tester needs to be provided access with necessary privileges to test location if the test is required to be performed with tester inside the premises. If the test is to be executed without any interruption of business operations in a live environment, it would be helpful if incident response team is informed in advance of the test. Also, the time of conducting the test needs to be selected serving the purpose of the test. One does not want the test to create an alert in working hours except if the client requires it.

These rules of engagement aligned with the defined scope should be well documented in the contract before starting off our pen test.

Documentation and report handling:

It is to be agreed in contract on how the process and results of pen test need to be documented. Each customer has their own need of what the reports should contain. Often they require a detailed report of every step performed along with outcomes, not limited to log files but also an analysis of them and also a report with less jargon for business presentations.

Also, both parties need to be clear on what is to be preserved as evidence and how. The client may be maintaining a repository of all pen test evidence and reports at some central or distributed storage location with restricted access. So, it is important to have this included in the contract what shall be handed to the client and the means of doing so. Usually, all traces are required to be wiped off before the tester moves out of the premises with data shredding procedures as per client's security policy which need to be referred before planning the test.

Become a Certified Ethical Hacker, guaranteed!

Get training from anywhere to earn your Certified Ethical Hacker (CEH) Certification — backed with an Exam Pass Guarantee.

Learn More

While open to negotiations, be aware that a pen test is not something pen testers are given the freedom to play with. They are required to follow only the procedures that are widely employed.