CompTIA Pentest+ PT0-002 – Section 3: Scooping an Engagement Part 3

18. Identifying Restrictions (OBJ 1.2)

Every organization has a different risk tolerance threshold. This risk tolerance threshold will become a big point of contention during the planning of the timing, the tempo, and the scope of your engagement. If the organization is quite risk averse, you’re going to need to be extra careful not to cause any disruptions to their operations, and therefore you might have a smaller scope and perform a very tightly controlled engagement. If, however, they have a higher risk tolerance, then the penetration tester may be given more leeway to conduct a larger scope or faster tempo engagement. Always remember there are four things that can be done with risk, avoid, transfer, mitigate, and accept. If an organization wants to avoid risk, they’re going to tightly control the engagement, including the scope and the tempo.

If they want to transfer the risk, they may want to move the risk to another entity, such as making the penetration tester sign an agreement that states that if a system crashes during the assessment, the penetration tester is going to be responsible for getting it fixed and paying for any damages. Or they may want us to mitigate the risk by only allowing the penetration tester to conduct that assessment during certain times, or they’ll exclude testing from occurring on certain days, such as during peak business hours.

The organization can also simply accept the risk. If they have a high enough risk tolerance, that organization may just say, “Go ahead and start your penetration test any time. We’re willing to accept the risk of any downtime that you might cause.” Now, with the risk tolerance and the restrictions agreed upon by both the penetration tester and the client, it’s now going to be important to determine the exact impact of this tolerance and ensure that the organization understands it as well.

You’re going to have to answer the question of what is the impact operations if things go wrong? For example, if we begin a penetration test and we cause a server to trip offline, how is that going to affect the company? They’re going to have to consider this in the risk calculus by balancing the needs of conducting a full assessment against their needs to continue their business operations. As a part of this, they may exclude certain things from the scope of the engagement, too.

For example, if I hired you as a penetration tester, I might create a scope for you to test my company’s internal network storage servers, our web servers, our internet connection, and all of our physical security, but I might specifically exclude our email servers, our e-commerce servers, our public databases, and our public Wi-Fi. Now that you understand your restrictions, you can then go and plan and build the engagement plan with those specific scoping limitations in mind. These different restrictions are going to be placed upon you because of the risk that I, as your customer, am willing to accept during this particular engagement.

Now, your client organization’s risk tolerance will directly affect the scope of our assessment, but it will also impact our schedule and timing. How long will we be on the network conducting your assessment? Will the organizational network defenders be informed ahead of time of your schedule? Perhaps they’re going to know that the penetration tester was hired and they’re going to attack sometime within the next three months, or maybe they’re being provided with the exact date and hour for the attack window to occur.

This again is negotiated during your engagement’s planning and scoping phases. If the organization wants the penetration tester to participate as part of a red team/blue team engagement, then the defender should be aware that the red team is planning to attack. However, if you want to simulate a true thread actor during a penetration test, the defenders probably shouldn’t be aware of that schedule or even that a penetration tester has been hired.

But this again is up to the organization who hires you for that engagement. Once we identify any time and date restrictions, client-stakeholder negotiations, and the total list of included and excluded targets, we can then build a schedule with the organization’s trusted agent to decide how and when the penetration test is going to occur. Finally, you need to be wary of scope creep. This occurs when a client starts asking for more services than what was originally listed in the statement of work.

If, for instance, we agreed to do 10 servers at the time of signing the contract and drafting up the scope of work, but now, halfway through the assessment, you come back and ask us to scan another five servers. Well, that’s a big change in scope, because it’s a 50% increase. Also, this is going to cost us additional time and resources. I recommend that you always place a contract in your master service agreement and your statement of work that either states that all changes must be submitted as an addendum to the contract, or include a prearrange cost for expansion beyond the initial scope. Both of these measures will help to control scope creep from occurring during your engagements.

Now, remember, while it’s easy for the organization just simply ask for us to scan another five servers, for example, they’re going to stop and think about that before they do it if you’re telling them that each additional server will cost them another $1,000, or whatever the value has been set inside of that master service agreement or scope of work. This again helps keep scope creep from occurring and it helps them from becoming excessive during your engagements. Anytime there is scope creep, document it as a change order to the statement of work. Make it clear to your client by stating how long it’s going to take, the resources necessary, and the additional cost to make that change to the scope occur. In addition to the client organization’s requirements, there’s also going to be some restrictions that are placed upon you based on the location of the client organization, the location of the penetration tester, or the location of the third party hosted services that may be in the scope of an engagement.

Remember, each country, state, city, and town has their own regulations and laws that could affect your penetration tests. Now, we’re not going to cover every law in this lesson, but instead, you need to be aware of the fact that there are restrictions out there based on the different location involved in a given penetration test. For example, if you’re conducting a penetration testing in Europe, you need to be aware of the GDPR regulations and your requirement to adhere to proper data handling techniques for any data you obtain during the testing, because it could contain privileged personally identifiable information on that organization’s customers or users. There are some countries that actually view minor actions like port scanning and vulnerability scanning as a form of illegal hacking. Again, before you start an engagement, it’s always best to consult with your lawyer, especially before you accept your contract, to ensure that you can legally perform all the services that you’re offering based on the countries and the locations that are going to be involved in that engagement.

Finally, it’s important to understand that even some of our penetration testing tools have restrictions placed upon them by different regulations. The best example of this is the export restrictions placed upon many of our tools due to the United States Export Administration Regulations, known as the EAR. There’s also another regulation that was created by 42 participating countries that implements export restrictions on technologies that they consider dual use. This is known as the Wassenaar Arrangement. Now, the United States is actually one of those 42 participating countries as well.

This arrangement essentially states that if a technology can be used by both a regular commercial setting and also used as a weapon, then the exportation of that technology may be outlawed by the US government, or any of these 42 participating countries. A great example of this is encryption. Encryption is considered a dual use technology and it’s covered by the Wassenaar Agreement. For a long time, many products could not use strong encryption, like 128 bit AES, because of this export restriction. If you are using a high level of encryption, you may need to check the restrictions regarding in which countries you may not use it from. For example, North Korea, Iran, and others are on an export restriction list and you can’t give them that type of technology.

Another example is Wireshark, which is a powerful open-source protocol analysis tool that can decrypt many different types of encryption protocols like IPsec, Kerberos, SSL, and TLS. In some locations, it can be illegal to use a cell phone jammer, a Wi-Fi jammer, or even a lock picking set as part of your penetration test. As you can see, many of our penetration testing tools can also be considered surveillance tools or weapons under this Wassenaar Arrangement, and therefore they’re going to fall under an export restriction. So it’s important to consider this when you’re dealing with your international clients, because otherwise you could be subject to fines, fees, or even imprisonment for violating these export controls. Again, this is a case where consulting your attorney to ensure you stay out of trouble is well worth the attorney’s consultation fee.

19. Rules of Engagement (OBJ 1.2)

After you’ve defined and clarified the scope of the assessment, you’re then going to need to agree upon the rules of engagement for that penetration test with your client. Now, the rules of engagement, also known as the ROE, are the ground rules that both parties must abide by both the organization and the penetration tester. Think of it like a soccer game in which everybody needs to know and play by the same rules. Everybody knows that the goalie is the only player allowed to use their hands. And so both teams understand this common rule and we can play the game accordingly. Rules of engagement cover five key areas, timeline, locations, time restrictions, transparency, and boundaries for the test, Both the organization and the penetration tester need to agree upon the timeline for the engagement. A timeline is used to represent a series of events that transpire within a discreet period of time. This includes when the test will occur and the total duration of the engagement.

Will the assessment be conducted over a couple of days, a week, a month or a year? This will be negotiated as part of your contract and becomes part of your rules of engagement. From this agreed upon duration, the penetration testing team will then need to outline what tasks are going to be performed and estimate the amount of time required for each task to be completed. For instance, if a phishing campaign is going to be utilized as part of a social engineering assessment, will those emails all be sent out at the same time or are we going to spread them out over several days or weeks in an attempt to be more covert and more likely effective? Once the timeline of events is created, this will often be provided to the trusted agent within the targeted organization to aid them in deconfliction and to get their concurrence before we execute the assessment. Now, when completed the timeline should include the date and time that each task is going to begin, its estimated duration, a brief description of the task, and who’s responsible for performing that task within your penetration testing team.

The second major concern is the location. Will the penetration testing team be conducting the attacks onsite or from a remote location? If the target organization has multiple locations, will the pen tester be required to go to every single location or to test all the locations? Or will they just use a sample set or maybe just the corporate headquarters? The rules of engagement will specify which locations are authorized to be targeted and which ones are considered off limits and out of scope. As a penetration tester, it’s always important to consider if any of the target locations are located across international orders as well. For example, some organizations have offices in California, London and Hong Kong. Now each of those three locations will require the penetration tester to become familiar with the laws and regulations that are applicable in those areas. All authorized locations should be listed in the rules of engagement, especially any of that cross international borders. The third key area in the rules of engagement is time restrictions. Now time restrictions are used to specify certain times that the penetration tester is authorized or unauthorized to conduct their exploits and attacks.

For instance, if a company always does server maintenance on Saturday nights from midnight to 2:00 AM and they can’t afford any additional downtime during those hours, the targeted organization may specify that the penetration testers simply can’t conduct their assessments during those hours. Another example is if the target organization is typically a business organization, and they may allow us to attack during weekends and holiday days when a large portion of their staff are not at work. As a penetration tester, I really love conducting assessments during a holiday period because there’s less people working, and the ones who are really not paying that close of attention.

Conversely, though, if we’re conducting the PCI DSS compliance for a retailer organization and we want to conduct our attack on Christmas Eve, well, guess what? That retailer is probably going to disapprove that, because they don’t want to take anything offline or lose sales during one of their busiest days of the year. It all comes down to what the organization and the penetration tester are going to agree upon. Now, with all that being said, if your client does not maintain an operation on a 24/7, 365 type of schedule, you should really explain to your client’s key stakeholders the importance of conducting the penetration test during their normal business hours. By conducting the test during their normal business hours, the organization’s reaction to an attack can be more clearly measured because those defenders are there during the day at work during that potential attack and exploits that you’re creating during the engagement.

Whichever timeline restrictions are agreed upon should clearly be stated inside of your rules of engagement. For example, there might be a line in that document that says activities for the engagement will be conducted only on weekdays from 9:00 AM to 5:00 PM U.S. Pacific Time, unless otherwise stated and approved within an individual test plan. This would mean that the bulk of the engagement is going to happen during normal business hours. But maybe you have an individual test plan that you want to try and conduct a physical penetration test of their data center at 2:00 AM on a Sunday because there’s not as many people there and you need the cover of dark to make that happen. If that plan gets approved, it’s going to be okay to do that outside of normal business hours because it is a separately approved test plan that’s meeting the goal. Now our fourth area to and center is transparency. We need to know who in the target organization is going to be told that an engagement is scheduled to occur or is ongoing. Now, some organizations will keep this information confidential and highly controlled so that only senior executives like the chief security officer or chief technology officer are going to be aware of the engagement. Other organizations, though, may tell some of their system administrators or their director of information technology that this is going to happen.

Again, this really depends on the rules of engagement that are going to be established and the objectives of the overall assessment. Now, this person inside the organization that you’re allowed to communicate with, we call them a trusted agent. This trusted agent is an in-house staff member who’s going to be designated as a monitor in the organization during this assessment. It’s really important to work with that trusted agent before, during and after the engagement to ensure success. Now, this person is somebody who’s inside the targeted organization and they’re going to receive all the details of the penetration test while it’s being conducted. They are empowered to communicate directly with the penetration testing team so that the attacks can be deconflicted, and if there’s any negative effects on the operational network, the penetration testers can be told to stop their exploitations that are in progress while the organization recovers their systems back to normal operations. The trusted agent can also provide the penetration testers with resources if you’re doing unknown environment tests, things like network diagrams, source code, and a list of the operating systems.

Now, if the objectives require an unknown environment test, though, those type of resources are not going to be provided and the penetration testers will instead be required to conduct the assessment in the blind. The final area that we need to think about is one of boundaries. Now, what exactly will the penetration tester include in the assessment? Now this will already be covered inside of your statement of work, but in the rules of engagement you should also include any rules about what you can and cannot test from a technical, physical, or operational perspective. For example, is the penetration tester authorized to conduct social engineering as a method of gaining access to the network? Or are they only allowed to use openly available technical exploits? Some organizations simply want to see their technical vulnerabilities, and therefore, they’re going to exclude social engineering attacks, like phishing, from your assessments.

These organizations aren’t necessarily concerned with testing their user awareness. Instead, they want to see if their systems are correctly configured to prevent somebody from attacking outside of the corporate network to inside the corporate network. Again, this comes down to agreeing to the boundaries for the assessment in order to meet the engagement objectives. Remember, boundaries are used to refer to what systems may be targeted and what techniques can be utilized. If we’re doing a physical security test are we allowed to climb their fence? Well, maybe we can, maybe we can’t. But the boundaries established in the rules of engagement will confirm what is authorized.

• Category: Uncategorized