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

10. Planning a Test (OBJ 1.2)

When it comes to penetration testing, planning is incredibly important. There are three major factors for any assessment, time, cost, and quality. These three factors are always in competition with each other, and decisions on their priority have to be agreed upon between the penetration tester and the organization that’s contracting that engagement. For example, if you want the assessment to be faster, it’s going to cost you more money, or it’s going to require a lower quality threshold. If you want a really in-depth and high quality engagement then it might cost additional resources in terms of people and money, or it might take you more time. If you want an inexpensive penetration test to be conducted, then you really shouldn’t expect it to be high quality or really quick. Again, these are competing factors that you must consider during your planning. And it’s also important to understand what the company is expecting and what you can provide during the proposed timeframe.

There are various areas of consideration when you’re planning an assessment. This includes things like who is the target audience? What is the objective? Is this a compliance based assessment? What resources are required? Who will we communicate with and how often? What product will be required to be presented at the end of the assessment? Are there technical constraints placed upon the engagement? And how comprehensive will the penetration test need to be? First, we have to ask a who is the target audience for the penetration test and what kind of business do they perform? Are they a small local retail store that needs a simple Payment Card Industry Data Security Standard, or PCI DSS compliance penetration test? Or are they a large multinational bank with offices all over the world who wants you to test all 100,000 branches? Depending on the answer to these questions, the scope of your assessment is going to be vastly different because of their different sizes, missions and operations. Second, what is the objective of the penetration test? Is the organization contracting the engagement in order to meet a compliance requirement or regulation?

Are they conducting due diligence in their testing and software assurance before a product is going to be released? Both of these are valid objectives for a penetration test, but each of them requires a different approach. By understanding your target audience and their budget, you can design a better engagement that will more efficiently and effectively meet their objectives. Third, what resources will be required to carry out the penetration test? For example, if my company was hired to do a penetration test on a large chain of retail stores that’s located out in Hawaii, but that company has not allocated any funding for travel, then my team won’t be able to conduct a physical penetration test because our offices are not located in Hawaii and we’re going to have to fly out there to do it. On the other hand, if they have a really large budget, then we can support a very large or in-depth assessment, including onsite testing of their physical security, as well as resiliency to social engineering attacks.

Now we might also be able to fly people on site, hire contractors, have a longer timeline, increase the scope, and have greater access to people and technology. However, if we’re given a smaller budget, then we’re going to have to adjust the scope downward appropriately to meet those restrictions. Now let’s go back to the Hawaii example for a minute. Assuming that we have a smaller budget assigned, we’re then going to have to minimize the scope to only provide an external assessment of those networks over the internet. Now, if that meets the company’s objectives, then we can move into contract negotiation
and start agreeing to a price. However, if it doesn’t, then it’s going to be important to negotiate a larger budget in order to support an onsite assessment, or we’re going to have to turn down the assignment and recommend they hire a penetration tester who is local to their company. Now, when we’re looking at resources and requirements for this test, it’s also important to consider what resources are going to be needed and the costs associated with having those resources. Do we need to be onsite or can we achieve the same objectives remotely?

Do we need the test done from inside the company network or from an outside perspective? What requirements must be met during the test? Do we need to use end-to-end encryption? All of these requirements will take up additional resources from the project. For example, if we’re going to be required to test for both known and unknown vulnerabilities, we’re going to have to come up with our own exploits, which cost us more time more money and more resources than using existing toolkits, like the Metasploit framework with its open source and well-documented exploits. Next, we need to ask if this test is part of a compliance-based assessment. If so, the engagement becomes a little easier because there are checklists provided by most organizations or legislative bodies for your testers to you utilize, and this will ensure that all of the appropriate device have been scanned to the appropriate level.

For example, a PCI DSS scan has a specific checklist that an assessor or penetration tester has to utilize to verify compliance with the PCI DSS standards that are used for credit card processing. Even though we’re going to cover the details of those during the scoping of our assessments, it’s also important early on to be able to outline them in the planning phase to ensure that the organization understands the level of resourcing that’s going to be needed to meet the proposed requirements. Now, during our planning, we’re also going to outline our communication plan. Who can the penetration tester communicate with during this assessment and how often will that communication occur? For example, if the chief technology officer hired your company, are you only allowed to speak with them? Or can you also speak with the information technology department about the fact that you’re planning to conduct a penetration test? The answer is going to be dependent on your contract with the organization and whether they’re trying to test their systems their personnel, or both of these. Even if you’re conducting a blind test to see if people fall for your tricks in social engineering, you still are going to need a trusted agent inside that organization who you’re going to be able to communicate with if something is going wrong. This person will also contact you during the deconfliction process to determine if a detected attack is actually your penetration testing team or has some real threat actor actually hacked the organization? You need to have these lifelines established well before the testing begins. So set this up while you’re planning your engagement.

Next, we should ask what product or report will the penetration tester provide the organization at the conclusion of this engagement. Now, when we get to domain four, we’re going to talk all about reporting and communication in depth. And I’m going to provide you with the details of a standard penetration testing report, but keep in mind, these can be modified by the organization to whom you’re providing the service. Some organizations I’ve worked with previously have requested the executive summary be provided as a brief using a PowerPoint format, and others want to have something written in long form prose.

We also need to find out how detailed the report needs to be. For example, if I run a vulnerability scan, I might have a 300-page document that I can provide to the organization with every single vulnerability that was discovered in their network. But most companies would rather us prioritize which vulnerabilities they need to address first, as well as how much time and money it’s going to cost to fix them. Again, this is all negotiable and should be discussed during the planning phase. Next is the customer going to place any technical constraints on the penetration test?

For example, are you allowed to test their database servers, their web servers, or their printers? Any limitations or constraints have to be understood during the planning phase so the assessment can be properly scoped. If I was testing an organization that focuses on manufacturing, for example, one of the big concerns I have is whether or not my team and I can conduct exploits against their ICS and SCADA systems, because these systems are very likely to break if you’re using standard penetration testing tools if you don’t know what you’re doing. Often those systems are removed from the scope of our assessment, or maybe we’re required to test them and we’re going to bring in some specialists to assist us to make sure we don’t break anything. Now, either of those two options is perfectly acceptable. It’s just important to agree to it upfront and detail that decision inside of the contract and your scope of the engagement. Now when planning an assessment, it’s also important to ensure that the organization understands that the assessment is just a snapshot of their current security posture.

If we completed an assessment today, it can only tell the organization what vulnerabilities existed as of today. A new vulnerability may be discovered in a week, and it may have taken us three weeks to finalize our report. Obviously, our assessment, and in turn, our report, are not going to cover that new vulnerability. When you’re negotiating an assessment, be clear that this is a point-in-time assessment and this means that you’re only going to be held liable for disclosing the vulnerabilities that were discovered at the time of the assessment. After all, new vulnerabilities are discovered every single day. And you can’t be expected to know about a vulnerability that hasn’t been discovered yet. Finally, your client also needs to determine how comprehensive the engagement needs to be.

Are you going to go out and look for every single vulnerability or are we just trying to find at least one way to break into the network? While some clients want the former, others want the ladder. This is another key consideration, as it will greatly affect the size, scope, and duration of the assessment and the resources that it requires. Remember, the more comprehensive the engagement, the longer the duration and the larger the scope. Another thing to determine is which parts of the organization are going to be included in this assessment? Are we testing the entire organization or just the information technology department? Whichever it is, it needs to be agreed upon upfront during the planning and scoping phase, and then detailed in your final report during the reporting and communication phase.

11. Legal Concepts (OBJ 1.1)

Before you conduct a penetration test, it’s imperative that you receive written permission from the target organization. This is what prevents a penetration tester, also known as an ethical hacker or authorized hacker, from going to prison. Ethical hackers and penetration testers are separated from the criminal unauthorized hackers by simply one thing, permission. In the industry, we like to use the term for this written permission as our get out of jail free card because that’s effectively what it is. This written permission should include the names of the companies, organizations, or individuals that are authorized to perform the penetration test. It should also include what specific networks, hosts and applications are to be included in the test. It’ll also include the period of time that the authorization is valid for and the proper data handling techniques that will be required.

Additionally, the reporting guidelines and the list of people to communicate with and the guidelines that state when a test should be terminated, will also be included. It’s always important to ensure that your client is aware that certain types of testing during your engagement may cause damage to their systems or the information they house. While the penetration testers will always try to make the effort to protect the systems and their information, sometimes when a server is exploited it can cause other services to go offline. For example, if I conducted an exploit against your authentication server, it may cause the users to be unable to log into your network or even authenticate with the email server. Both of these would have a direct impact on your business’s operations during a busy work day. So it’s something that the client needs to be aware of before the engagement begins. Remember written permission for your engagement is usually obtained as part of the contracting process. There are four types of legal contracts that are covered by the exam. This is the Statement of Work, the Master Service Agreement, the Service-Level Agreement, and the Non-Disclosure agreements.

First, a statement of work or SOW. A statement of work is a formal document that details the task to be performed during an engagement. This document is going to provide the penetration tester with what must be done to complete the assessment what is not allowed to be done and what worth the company is willing to pay them for. This is an important document because if you’ve been asked to test a hundred servers and you begin to conduct your assessment and then the company asks you to test another five servers, this increases the scope. You should now require them to sign a change order or an addendum because those five servers were not part of the original statement of work that you were contracted to perform and they just increased your workload by at least 5%. The statement of work will usually contain a list of deliverables as well, such as the final report and the responsibilities of the penetration tester and the client as well as the schedule, the timeline for payments and other terms that need to be agreed upon before the engagement begins. Second, we have a Master Service Agreement.

Now, a Master Service Agreement also known as an MSA is a specialized type of contract that’s used by those who perform a lot of work for the same organization. A master service agreement is going to act as a framework agreement where most of the terms are agreed upon upfront so they can quickly issue new contracts by using a short statement of work to solidify any specific details for new engagement. A master service agreement is normally going to be used to govern future transactions and agreements with a client, and it usually contains any requirements that’ll be recurring in nature. For example, a master service agreement might state that the penetration tester has to be bonded and insured for up to 5 million in damages, that they have certain permits, licenses or certifications. And that they accept payment on a net 60 term schedule which means that payment would be received 60 days after sending in an invoice. A good example of when a master service agreement would be used is if an organization hires a penetration testing firm to conduct quarterly assessments on their PCI DSS network infrastructure.

This contract will specify the charge for each assessment the scope and other details but it’s not going to include specific permission, duration or timeline because that would be negotiated in a statement of work that’s going out for each quarterly assessment. This drastically speeds up the contracting process because most of the details have already been agreed to upfront in the master service agreement. The third type of contract we have is called an SLA or Service-Level Agreement. Now, a service-level agreement is a commitment between a service provider. In this case, a penetration tester and a client. The SLA would include not only a description of the services to be provided under this contract and their expected service levels, but also metrics by which the services are going to be measured. The duties and responsibilities of each party, the remedies or penalties for a breach of that SLA and a protocol for adding or removing metrics. A service-level agreement is commonly used for security as a service type of products or penetration testing services.

For example, I had a friend who owned a small penetration testing firm that provided both penetration testing services and remediation services. For his penetration testing services, he used an overarching master service agreement with each of his clients, and then they would issue a statement of work for each engagement during that year. Now, in addition to this he also had an SLA and that SLA stated that his firm would remediate any vulnerabilities that were found during the penetration test within seven days of their discovery if they were categorized as a category two vulnerability, or in three days if it was considered a category one vulnerability. Now I’ve also seen some outside in scanning products that are continually scanning your website or network and provide you with a weekly report of your vulnerabilities. This type of service also usually comes with a service-level agreement. The fourth type of contract we have is known as a Non-Disclosure Agreement or NDA. Now a non-disclosure agreement is a legal document that’s going to stipulate that the parties will not share confidential information, knowledge or materials with unauthorized third parties.

You should expect to sign an NDA for every penetration test that you’re ever going to perform. These non-disclosure agreements are a form of legal contract that are going to outline the confidential material or information that you may be exposed to during the engagement. And what restrictions are being placed on that material. If, for example we’re hired to assess the security of Marvel Studios. We can’t go and take a copy of the new Guardians of the Galaxy movie and distribute it to the internet without breaking that NDA. That means we’re going to suffer the penalties for doing so in breaching our NDA. Now, furthermore, we can’t go out and tell everybody about an organization’s vulnerabilities that we discovered during our assessment either because that would break our NDA. If you break an NDA, you’re going to be subject to fines, fees and even have your contract canceled depending on how the NDA is written. Now, just like an organization will almost always ask us to sign a non-disclosure agreement. We should also ask them to sign one, too.

Your version of an NDA should require that the organization not release our proprietary techniques the way we conduct our assessments or even copies of our reports all of these are considered the intellectual property of the penetration tester. And we don’t want them being shared with our competitors by using NDAs between the penetration tester and the client, both sides are basically saying I’ll keep your secrets and you keep mine. These non-disclosure agreements are put in place to help ensure confidentiality during our penetration tests. Confidentiality is the principle and practice of keeping sensitive information, private, unless the owner or custodian of that data gives explicit consent for it to be shared with another party.

During the planning stage of an engagement your team needs to gain a clear understanding of what data is sensitive to that organization that you’re going to be testing and how you can best protect it. For example, if your engagement is scoped so that you must download a copy of the database, in order to prove the data exfiltration was possible then you also need to ensure that you exfiltrate it over a secure and encrypted channel. That you encrypt the database when it’s at rest on your system and you protect it from being exposed to any third parties. A big part of confidentiality is making sure that all the data you collect before, during and after your penetration test is properly secured and handled. This usually involves encrypting the data at rest, in transit and in processing. Once the assessment is concluded, you’re also going to need to securely wipe your systems of all the client sensitive data to ensure it doesn’t fall into the wrong hands.

• Category: Uncategorized