CompTIA Pentest+ PT0-002 – Section 2: Planning an Engagement Part 1

4. Planning an Engagement (OBJ 1.1, 1.2, and 1.3)

In this section of the course, we’re going to cover the various considerations that you need to think of when you’re planning an engagement. in the world of penetration testing, the term engagement simply means a singular penetration testing project that has been planned and scoped by the client who’s requested the test and the analysts who are going to do the testing and assessment. Our focus in this section of the course will be on Domain 1, Planning and Scoping. Now we’re going to spend most of our time in this section of the course talking about planning, because we’re going to be covering the concepts involved with scoping an engagement in the next section of the course. So in this section, we’re going to cover parts of Objectives 1.1, 1.2, and 1.3. Objective 1.1 states that you must be able to compare and contrast governance, risk, and compliance concepts. Objective 1.2 states that you must be able to explain the importance of scoping and organizational or customer requirements.

Objective 1.3 states that given a scenario, you must demonstrate an ethical hacking mindset by maintaining professionalism and integrity. Now, as we begin this section, we’re going to first talk about how risk is made up of threats and vulnerabilities. It’s important to understand this concept as a penetration tester, since your entire job is focused on finding vulnerabilities in your client’s networks that can be exploited by a threat actor. In the case of a penetration tester, you’re working as an authorized threat actor who’s trying to identify the ways that an unauthorized intruder could cause damage to the organization’s network.

Then we’re going to move into the three types of controls, which are categorized as either technical or logical controls, physical controls, or administrative controls. These controls are important to understand as a penetration tester because you’re going to be creating a report for your client at the end of your engagement where you’re going to be recommending different controls across all three of these categories in order to thwart a threat actor from victimizing the organization’s network. Next, we’re going to move into understanding the different steps in the penetration testing methodology that we’re going to use in this course and on the exam.

After that, we’re going to discuss how to plan your penetration test for the best results. We’re also going to cover the legal and regulatory concepts that are important to penetration testers, and briefly cover the ethical hacking mindset and some concepts surrounding professionalism and integrity. So, if you’re ready to get started on your penetration testing journey, let’s jump into our lessons focused on planning and engagement.

5. Risk (OBJ 1.2)

Before we can dive deeply into the world of penetration testing, it’s important for us to take a few minutes and talk about risk. Good risk management skills are incredibly important in the world of penetration testing, because without them, you’re going to cause some horrific accidents that could cost you your job, your company its contract, or at least some serious downtime for the network that you’re conducting a penetration test against.

So let’s start with two basic questions. What is risk and where does risk exist? Now, risk at its core is the probability that a threat will be realized. Risk is a continual balancing act between vulnerabilities and the threats that try to exploit them. If you’re a cybersecurity professional working on the defensive side of the industry, like a cybersecurity analyst would, then your job is to minimize vulnerabilities. But when we’re working as a penetration tester, our job is to find vulnerabilities in a system and then exploit them to prove that the network is truly vulnerable to an outside attack. Now, when you hear the term, vulnerability, you should remember that it simply means any weakness in the system design or implementation.

Vulnerabilities come from internal factors, things like software bugs, misconfigured software, improperly protected network devices, lacking physical security and other issues like this. Vulnerabilities are within the control of the system owner to correct. So if you’re conducting a penetration test against an organization, it is within their ability to mitigate or fix most of those vulnerabilities that you find. Conversely, however, as cybersecurity professionals, we can’t fully control threats, but instead, we attempt to minimize or mitigate them. Now, when you’re conducting a penetration test, you are technically the threat actor in that situation. And so you are the enemy of the cybersecurity analyst who are charged with defending their organizational networks. In general, though, a threat is anything or anyone that could cause harm, loss, damage or compromise to our information technology systems.

These threats come from external sources, things like natural disasters, cyber attacks, data integrity breaches, disclosure of confidential information, and numerous other issues that may arise during our daily operations. But those threats can also come from internal sources, such as an insider threat who’s trying to steal corporate secrets or an employee who mistakenly leaves the back door unlocked after taking out the trash before going home at night. So now that we’ve covered the concept of vulnerabilities and threats, let’s answer our second question, where does risk exist? Well, risk exists in the intersection area between threats and vulnerabilities when we diagram them with two overlapping circles in a Venn diagram. Now, this is a key point to understand. If you have a threat, but there is no vulnerability, then there is no risk. The same holds true that if you have a vulnerability but there’s no threat against it, there’s also no risk. Let’s consider the example of trying to get to work on time in the morning. Your alarm clock goes off just after 6:00 AM and you hop out of bed, you get dressed, you eat breakfast and now you have to get from your house to your office across town. But there are many vulnerabilities and threats all around you that could cause a bad outcome, like you arriving late for work. This is an everyday example that most of us live with in the world of risk management. Let’s consider a few possible vulnerabilities.

One might be that you forgot to put gas in your car the night before. So let’s call this the vulnerability of a lack of preparation. Another might be that you forgot it was your day to drop the kids off at school before driving to work. There are a lot of possible vulnerabilities to your plan of getting to work on time. But you can control these, because vulnerabilities are internal factors. But there are several other threats to your arriving on time that are outside of your control. What if there was a traffic jam this morning? That would certainly cause a delay to your commute and you would arrive late to work, which is a realization of that threat. Another threat could be a natural disaster that’s occurring, like a flood or an earthquake that causes the road between your home and your office to become unusable. Now, I know that’s a little dramatic, but you’re getting the idea, hopefully.

You can’t stop a flood or an earthquake. It’s an external factor, and it’s a threat to you arriving to work on time if they were to happen. Now, we have several threats and several vulnerabilities that we just identified in this simple example. But what can we do about them? Well, if we’re worried about being late for work, one thing we could do is wake up a little bit earlier. That way, even if an external threat, like a traffic jam or a flooded or destroyed road was in the way, we can actually find an alternate route and still get to the office on time. This is what is referred to as risk management. It’s all about finding ways to minimize the likelihood of a certain outcome from occurring and achieving the outcomes that you really want to achieve. Now, let’s circle back to the world of penetration testing.

As you look at a system, you need to identify the vulnerabilities that it has, so that you, as the threat, can go and exploit them. Going back to my earlier statement, if there is no vulnerability, then the threat cannot put that system at risk. For example, let’s say I have a laptop here that has top secret information on it, but I never connected it to the internet. You’re going to have a really hard time conducting a remote exploitation of that laptop system, because it’s not online. By choosing to eliminate the vulnerability of a remote connection, I have effectively stopped all remote exploits against that laptop. It’s longer at risk for those. Now, unfortunately, this also means that laptop is no longer useful if I wanted to use it to do my online banking or something else that requires an internet connection. And so you have to think about the pros and the cons for each mitigation that you apply against a known vulnerability. Now, in general, a risk is any vulnerability that exists that has a threat that could exploit it. So if I have a server connected to the internet, it has some vulnerabilities that we’re going to need to mitigate as cybersecurity professionals and defenders, while a threat actor or penetration tester is on the other side of things trying to break into it. To properly manage risk in the world of cyber security, we first are going to categorize each risk. Now, risk is identified by the different risk types that exist. Things like inherent, residual and exceptions. Inherent risk is going to occur when a risk is identified, but no mitigation factors have been applied. For example, if I’m going to drive to work, there is an inherent risk that I could get into a car accident and injure myself. In everything we do in cybersecurity, as well as the real world, there is some inherent risk.

If I’m going to install a software patch to my domain controller, then there’s going to be a risk that that patch might be faulty and it could prevent the domain controller from working as designed. If my office is located in the area of world that’s prone to hurricanes like Puerto Rico, then guess what, there’s an inherent risk that we could lose power because there’s a hurricane that hits the island. Essentially, inherent risk is the level of risk in place, prior to us taking any mitigating actions to reduce the impact or likelihood of that risk being realized. Now, if you have a server that’s connected to the internet, there is inherent risk that it could be attacked.

For example, if an advanced persistent threat, or APT, wants to target your network, it really is only a matter of time and resources before they’re ultimately going to be successful in exploiting your network. Now, this doesn’t mean we can throw up our hands and give up on applying controls to make our organization more secure. But there is always going to be some level of inherent risk in all the operations we do and a cyber attacker is going to try to exploit those to be able to gain access to our systems. The second type of risk is known as residual risk. Residual risk occurs when we calculate the risk after we apply our mitigations and security controls. So going back to the advanced persistent threat example, we may decide to create operational policies to secure our network.

We’re then going to ensure that every system is fully patched and compliant, and we’re also going to make sure that they are as secure as they can be. Now, there’s still a residual risk there that there could be a zero-day vulnerability that we didn’t know about, and it’s going to be discovered by an advanced persistent threat. Now, they’re going to be able to exploit that vulnerability to gain access to our networks. That is a residual risk. That amount left over after we applied all of our security controls. It’s important to understand this when you’re conducting risk management. Now, the final type of risk we have is one known as a risk exception. A risk exception is any risk that is created due to an exemption being granted or a failure to comply with corporate policy.

Essentially, think about it this way, your organization has implemented a cyber security policy and it says that all users have to change their passwords once a quarter, which is every 90 days, to help prevent brute force attacks. Well, your CEO decides that they don’t want to follow this policy because they hate having to remember new passwords. So they have the IT department put in an exception on their user account that lets them change their password once a year, instead of once every 90 days. This exception to policy now creates a risk to the organization, and this risk is known as a risk exception. In general, risk exceptions should be avoided in your organization. But if you do need to use one, you should always have a process to track these exceptions, measure the potential impact of allowing these exceptions, and implement compensating controls to help mitigate these risks.

• Category: Uncategorized