Skill Level Intermediate
- As you begin planning your penetration test exercise, you want to, first off, pay attention to your target audience, know who the audience actually is and also the rules of engagement. To start off with, who is your client? Is your client a large organization or is it a small organization? Or perhaps it's a federal agency or it could be a non-profit. It's important to understand exactly what type of business your client is in and what are their concerns? Are they more concerned with privacy? Are they more concerned with, perhaps, their reputation through the web? Or what are they really most interested in? The more that you understand about your client, the better job you're going to be able to do to meet their needs.
Secondly, why do they want a pen test to start with? There's lots of different reasons why organizations can come to you and require or ask for a penetration test. One could be compliance issues. Perhaps their industry is required through regulation or legislation or maybe just through standards, through industrial standards, to comply with penetration tests. For example, the payment card industry has the PCI DSS, data security standard, requirements that require any organization that accepts payment cards to undergo periodic penetration tests.
So that may be a reason why you were engaged in the first place. But it's important for you to understand who the target audience is, your client, and also why they need a penetration test. You need that in order to create your overall goals and plan to meet those goals. Secondly, it's important to define clearly the rules of engagement. Remember, you're going to be attacking systems and when you attack systems then, basically, you could cause certain systems to be compromised.
Certainly, if you're going to access privileged resources, then you have to have permission to do that. But can you access anything within the context of the client's environment or not? That's a question you have to answer with rules of engagement. For example, one thing you may want to ask is when are you allowed to attack a system? So the schedule is very important. A schedule will set up the parameters of when the attack is valid and permissible. In other words, are you allowed to attack at night? Or perhaps you're only allowed to attack at night.
If you attack during the daytime, during business hours, you may actually have some sort of impact on production. Can you attack, or should you attack, on the weekends? What about holiday periods? Or is it certain times during the day? So that's the kind of schedule information that you would want to find out when you go to attack a system. That's part of the schedule restrictions of rules of engagement. Another aspect of rules of engagement is team composition. You're going to have a penetration testing team.
Sometimes it's very small, could just be you, or it could be much larger. Where is your team located? Are you all co-located in the same area, geographically? Or are you dispersed among many different states or countries, even? You have to be concerned with how your team will be accessing the client's environment. It could all be through the same pipe, basically, or you could be geographically distributed. But you need to be concerned about where your team is, where they're located, and what type of access that they will have.
Will you all be accessing using the same ISP? Or will it be multiple hops? So lots of different details that you'll need to consider. Once you have a good idea of the schedule restrictions and your team composition, then you want to look at what type of test is this, anyway? Is it a technical-only test? In other words, you're just going to be running tools to ping systems and to hit them and try to bypass security controls. Or are you going to also be attacking people? Now, when I say attacking people, of course not physical attack but, if you use social engineering and you're going to be using crafty telephone calls or other methods to get people, users, to compromise security controls, then that may extend beyond purely technical attacks.
Or, what about physical attacks? You know, one of the easiest ways to get your hands on large amounts of data is to walk in, pick up backup media and put it in your pocket, walk out. That's actually easy because then you've got an entire copy of the client's data and you get to bang on it all you want outside of their environment. So is a physical attack part of your plan, as well? It could very well be. And that would mean that you have to physically bypass security controls to get inside some facility in order to have physical access to a system or backup media or something else.
So those are all things that you need to be concerned with. Determining what you're going to do before you can determine the list of tasks in your particular penetration test. And another part of scoping is the literal scope of your attacks. Which targets within an environment are fair game? This is something that you need to be very, very careful about and create an understanding between yourself and the client. Are all the servers and all of the network devices fair game? Are all of the data centers fair game? Or are you only allowed to attack and to assess certain subdomains or certain portions of the client's entire environment? There's many cases where the actual production box is off-limits because any impact to that may cause regulatory infractions.
It could actually crash the box. Lots of problems, so your scope may be limited as to the number and location of targets that you're allowed to actually test. So those are many of the areas that you want to be concerned with at the very high level when you first start to plan and scope this penetration test endeavor. Another area that you need to pay special attention to is communication. Communication within the penetration testing team as well as communication outside the team.
In other words, as team members communicate with others, how do you do that? When do you do that? And why would you do that? Penetration tests have risks. No matter how careful you are, it's possible that something bad could happen as a result of your pen test activities. You could do things such as crash servers or crash devices or crash any other element of an environment to where it just flat-out doesn't work. It's possible you could corrupt data. Not a very good way to pursue a good relationship with a client, but it's possible that you could actually do something that stomps on some of their data.
So you want to be very careful about it and understand that that is a risk. If you don't stomp on data or don't crash a server, it's very possible that you could render a server or some other device to be unusable through performance. There could be severe performance degradation or it could be minor, but either way, when you start impacting the availability of any part of an environment, you are impacting the ability to meet the business goals. And that's not a good thing at all. If you don't do anything bad, it's still possible that you could cause problems.
It's possible that a system is governed by certain regulatory requirements or legislation requirements to where you don't have access or shouldn't have access to a particular resource. And if you access the resource, you may violate some law, regulation or just possibly some security policy element or a rule. The idea is that you want to be very, very careful about understanding what you can do, what you can't do and how to communicate if something bad happens.
So let's assume that one of these bad things does happen. What do you do at that point? Well, first off you need to know who do I communicate with? If you don't know who to communicate with in the client organization, then when something bad happens, you're going to be sitting there wasting time, going well, who should I call? I really don't know. But if things go badly, you need to know immediately if it is a performance problem, you call this person or these people. If it is a customer-facing issue, let's assume that you crash the web server and all of the sudden your web server is down, or the client's web server is down, where they can no longer accept orders, clearly that's something that the internal management needs to know and it's possible that their support team needs to know very quickly.
So that that's something you can get ahead of. Fix the problem but also don't hide from the fact that something bad has happened. But don't get the idea that the only time you ever talk to your client is when something bad happens. That's a really bad precedent to set. There's lots of other times that you're going to need to communicate with the client and among the team. So you need to understand the expectations for general communication because throughout the process, there's going to be triggers that occur. And a trigger could be starting something new, finishing something or just simply reaching a milestone.
Also, what are the expectations? How much should you communicate within the team and with your client? And how frequent should these communications occur? How frequently should they occur? Do you communicate every hour on the hour? Probably a little bit too much. But it could be, if you have a very sensitive client that really wants to understand what you're doing and how you're doing it. You want to set those expectations. You want to make sure you communicate with your client just as much as they want and expect.
No more and no less. That way, you don't have them constantly tapping you on the shoulder, saying hey, how's it going? Are you done yet? What are you about to do? When you set the expectations and both sides have those expectations met, there's less confusion and better overall communication.