By Fatskills Exam Guides Team — the exam nerds behind 28,500+ quizzes and 2.1M practice questions across 500+ global exams.
Topics: - Governance, Risk, and Compliance - Regulatory and Compliance Considerations - Testing Limitations - Time-Based Limitations - Asset Scope Limitations - Tool Limitations - Allowed and Disallowed Tests - Contracts and Documentation - Master Services Agreement - Nondisclosure Agreement - Statement of Work - Rules of Engagement - Permission to Test - Scope and Requirements - Standards - Environmental Considerations for Scoping - Target Selection - Contract Review - Communication Planning - Professionalism and Integrity - Communication - Integrity - Risks to the Tester - Regulatory and compliance considerations for penetration tests - Legal concepts including limitations on testing, contracts, and documentation - Penetration testing types, scoping, and testing requirements - Professionalism, integrity, the ethical hacking mindset, and risks and responsibilities for penetration testers
One of the hardest things to do as a pentester is planning and preparing for a pentest engagement. Each engagement will differ from the last, and no customer is ever the same. In this guide you will learn about the various concepts that can affect penetration test scoping, ways to manage a schedule and meet customer expectations, and some of the concepts you need to know to protect yourself and your customer. Governance, Risk, and Compliance Governance, risk, and compliance (GRC) describes the processes, tools, and strategies that organizations use to address compliance with industry regulations, enterprise risk management, and internal governance. Penetration tests are often used to examine risk and comply with legal and regulatory requirements for testing. Pentests practically evaluate an organization’s security regarding their processing and handling of protected data. It is important for you to understand how pentesting fits within GRC, as it may affect various elements of the testing effort. Note: The GRC model is defined by the OCEG (https://go.oceg.org) as a standard that unifies various subdisciplines of governance, risk, audit, compliance, ethics/culture, and IT. Organizations can adapt GRC into their own framework to enable executive management, the IT department, and the security department to communicate more efficiently and effectively in order to accomplish the organization’s strategic goals. ISACA (https://www.isaca.org), NIST (https://nist.gov), and the International Organization for Standardization (https://www.iso.org) can provide additional information on how to properly implement and manage GRC. Regulatory and Compliance Considerations Laws that affect penetration testing vary across countries, regions, and localities such as states and even cities. Laws may affect what tools you are allowed to use, whether or not certain types of cryptography can be exported, and even what activities are permitted during a pentest. Scoping should consider what laws apply to the target, as well as what corporate policies affect testing. Generally, compliance-based penetration testing evaluates adherence to these policies, laws, and regulations. This type of testing considers the security of specifically defined data types, often within the context of a defined protected environment. Therefore, asking about the client’s data classification policies may be useful during scoping. Compliance requirements may affect how a penetration test must be conducted, how frequently tests must occur, and even who is allowed to conduct testing. In this section, we’ll talk a little bit about these concepts, specific impacts to testing, and give two examples of regulations and standards you might run into during test planning. Compliance Concepts You should have a basic understanding of a few common GRC concepts when discussing the penetration test with your clients. These may be mentioned in standards and regulations or internal policies, and you will need to be aware of how they affect your decisions about penetration testing. Confidentiality is the concept of limiting access to data based on need to know. Companies and individuals who own and process data are frequently held responsible by regulations and standards for preventing unauthorized disclosure of the data. As a pentester, you will typically be contractually responsible for safeguarding the secrets of your client as well. We’ll talk more about this later in this guide when we address contracts and documentation. Privacy is not the same as confidentiality. Privacy is a legal concept that addresses what rights an individual has to control how their personal information is used, collected, and disclosed. Standards and regulations can define these rights and therefore the rules under which a company handles this data. That brings us to data types. Each standard or regulation defines what it considers to be protected data. Ask your client about what data they consider important, but also what data they have that is considered to be protected data by the regulations and industry standards they follow. Then, make sure you know how to recognize this data when you see it during a pentest. For this guide, we’ll talk about three types of data you may see during compliance-based penetration tests. Personally identifiable information (PII) or personal information is generally data that allows identification of one individual over other individuals. It is often considered to be a single piece of data (such as a Social Security number or other national identifier) or a combination of data (such as a name and postal address). This information is considered sensitive due to legal requirements surrounding privacy. The specifics of each standard or regulation will define what is considered personal data. Protected health information (PHI) is similar to PII, but it applies to data that was created or used in a health care context. This may apply to medical diagnoses, provider visit details, or other attributes that define an individual’s health or health care. As with PII, individual regulations will define what constitutes PHI. For example, the U.S. Health Insurance Portability and Accountability Act defines 18 specific pieces of information that classify as PHI, including e-mail addresses, bank account numbers, last name plus first initial, biometric identifiers, and treatment dates, among others. Cardholder data (CHD) is often specific to Payment Card Industry Data Security Standards (PCI-DSS). This is a type of PII that is specifically related to cardholders. Protected data may include account numbers, authentication data for financial transactions using payment cards, and other customer data either alone or in combination. Identifying this data when it is stored or transmitted during a penetration test may be central requirements during compliance-based pentesting efforts. Impact to Testing and Reporting You will need to identify when compliance-related testing requires changes to your testing methodology, plan your penetration test accordingly, and incorporate compliance-based concerns into your discussions with the client. Your test may require special consideration for testing of access vectors and environmental boundaries, allow or forbid specific types of tests, or set rules for data access that are different from other types of pentests. Much as with data types, standards and regulations may define the concept of a protected environment. This may define where clients can store, collect, or process protected data and set requirements for segregation from other networks. As a pentester, you will need to identify these boundaries and negotiate testing parameters to appropriately evaluate security across those boundaries. This may control deployment of testing devices, requiring tests from within the protected environment and outside of it. You may be required to make sure that protected data resides only within those boundaries. Compliance-based tests may require specific tests to evaluate the secure transmission of data, such as checking cipher strength or performing layer 2 network attacks. These tests may not be applicable in other pentests. You might even be forbidden from directly accessing certain kinds of protected data during testing. Instead, construct your findings to prove that access is possible.
For compliance-based testing, clients may request special considerations for the report. In addition to redacting protected data from evidence or providing evidence without directly accessing protected data, you may be asked to link findings to specific parts of a standard or regulation. The subjective severity of findings may even change based on compliance requirements. A finding regarding unsecured data transmission may hold more risk if the data being transmitted is protected, for example. In light of the specialized knowledge this kind of testing requires, some governing bodies require that testers be qualified before the pentest can be accepted for compliance purposes. UK government entities, for example, require clearance from the National Cyber Security Centre (NCSC) via their CHECK program (https://www.ncsc.gov.uk/articles/using-check-provider). In other cases, industry certifications, such as CREST,1 may be used to justify a tester’s experience. However, it is worth noting that it is not typically your responsibility to say whether or not a tested client is compliant with an industry standard or regulation—only to identify security issues related to those compliance requirements. Let’s revisit our unsecured data transmission example. Assume a regulation requires secure transmission of protected data. During testing, you find an FTP server transmitting protected data in plaintext. Your finding states that protected data is being transmitted insecurely with the FTP server and references the section of the regulation that describes rules for transmission of protected data. The finding does not need to call this noncompliant. Instead, an independent assessor will typically determine that it results in noncompliance. Tip: Pentest planning and scoping may require additional questions about which standards and regulations apply to the client, what data types are protected, data flow diagrams, and required objectives for testing. The answers to these questions can affect test methodology, test tooling, and reporting. GDPR The General Data Protection Regulation 2016/679, or GDPR, is a law passed within the European Union (EU) that imposes data privacy and security obligations on organizations that target or collect data related to people in the EU.
It’s important to note that this applies to anyone, even if they are outside of the EU, as long as they process personal data of people in the EU or offer goods and services to people in the EU. As of the time of this writing, the law was retained in the United Kingdom after Brexit. Personal data is defined by GDPR as data that can be used to distinguish one individual from other individuals, either directly or with the use of additional information.
A nonexhaustive list provided by GDPR lists identifiers that may be used alone or in combination with one another to describe personal data. Such information, when captured in testing artifacts, may need to be anonymized or removed when stored or used in reports in order to meet the terms of the law. However, GDPR does not define what form testing must take or how frequently it must occur. Note: Performing work for an organization that is subject to GDPR may also require a discussion with your legal counsel in order to confirm whether additional contract language is required during test planning. Pentesters should also discuss whether they need to observe any special procedures when accessing, storing, or transmitting protected information during the course of testing.
A penetration test for GDPR purposes will generally evaluate the security of data transfer and data storage and the security of systems that perform transfer, processing, and storage for protected data. Testing will likely require testers to focus on identifying what protected data has been collected, where and how it is stored and transmitted, and access vectors or controls protecting that data in order to help the GDPR-obligated entity to evaluate their compliance according to the terms of the law. Tip: As a refresher to recognize GDPR questions, the type of data protected is personal data of persons in the EU. The goals of testing include security of storage, transmission, and destruction of personal data by data processors. Enforcement is handled by government. PCI-DSS In an effort to combat financial crime, the major payment card brands (Visa, MasterCard, American Express, Discover, and JCB) established the Payment Card Industry Security Standards Council (PCI-SSC) to define a series of rules that businesses that process payments using payment cards should follow in order to better secure card data and transactions. The resulting standard is called PCI-DSS. Note: Information in this guide applies to PCI-DSS version 3.2.1. For the most up-to-date version of the standard, you should refer to the standards directly in the PCI-SSC document library: https://www.pcisecuritystandards.org/document_library
According to the standard, “PCI-DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. PCI-DSS also applies to all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.”
However, PCI-DSS is a standard, not a law. Penalties for noncompliance are not enforced by governments. Instead, noncompliant merchants may be subject to fines or even lose their ability to accept payments using payment cards from the brands noted earlier at the discretion of the merchant’s service provider or acquirer. PCI-DSS defines due diligence practices for securing cardholder data and protecting the card data environment (CDE) and provides guidance for penetration tests and organizations that require penetration tests in the document “Information Supplement: Penetration Testing Guidance.”
This guidance explains some of the PCI-specific testing methodologies and tests that are expected as part of compliance testing for the standard. Tip: As a refresher to recognize PCI-DSS questions, the type of data protected is cardholder data. There are likely references to the card data environment. Goals of testing include security of storage, transmission, and retention of CHD data by data processors. Enforcement is handled within the industry.
PCI-DSS defines protections for cardholder data and sensitive authentication data as in the table below. These elements may be stored (e.g., PAN, cardholder name), but may be required to be rendered unreadable when stored (e.g., service code, expiration date). Other types of data are not allowed to be stored and may result in a pentest finding (e.g., full track data or CVV2). Testers should not only know how to recognize this data during testing and what the compliance requirements are for storage but also be aware of data handling requirements for redacting these records when storing evidence and writing findings in reports. Table: PCI-DSS Account Data8 When scoping this type of assessment, careful consideration should be done to ensure that the organization’s entry points into the network are fully covered and documented. PCI-DSS assessments, for instance, require testing from inside and outside of the regulated environment.
This affords a variance in perspectives and helps ensure consistency with how the data is protected from both outside and inside the organization. Limited access to the organization’s network and storage systems may only provide a subset of the information necessary to successfully complete a full audit. This could lead to inconsistencies with the results and jeopardize the integrity of the audit. Compliance-based assessments designed to test regulated environments have different testing requirements based on data type and data handling instead of traditional goal-oriented objectives to access or exfiltrate data through open means. However, both are point-in-time assessments. Each one captures the state of the environment at the time of testing, even though each testing type is executed differently. Note: The pentester is responsible for being aware of PCI-DSS testing requirements and communicating them to the customer during scoping. Any limitations put on testing or on the environment need to be documented. The PCI assessor is responsible for determining whether or not the defined parameters are valid for compliance. Testing Limitations Other limitations may apply when you are scoping a pentest, such as testing windows and time frames, what tools you are allowed to use, assets you are not allowed to test, and methods you are allowed to use during testing. Some of these limitations are imposed by city, state, or country laws. Others may be imposed by the organization being tested. As a pentester, you should ask what limitations apply as part of scoping. That may mean consulting with legal counsel when operating in an unfamiliar geography or having a discussion with stakeholders about the effect on the test resulting from such limitations. As these limitations affect what you are able to test, they may affect the results of your testing, so you will need to document those impacts in your reporting and contracts. Let’s look at three examples. Time-Based Limitations Assume your client wishes to limit you to testing between the hours of 8 P.M. and 6 A.M. when no users are active. Their goal is for you to explore the impact of a compromised computer inside their network. Since no users are logged in, you will not likely have success with social engineering efforts simulating a business e-mail compromise or attacks that rely on user interaction. Since your test can’t examine the impact of those kinds of attacks, the report results must reflect that. What if no business transactions occur at this time? You wouldn’t be able to get an accurate assessment of the security of those transactions within this limitation either. There are often perfectly good reasons for a client to request limitations for testing. In some cases, testing may be limited to business hours instead. Security staff may rotate based on a follow-the-sun rotation, and the client may desire to test responses of specific staff. Clients may have limited staff and want to engage in known behavior only during business hours to avoid paying overtime. A peak sales event may coincide with the contract for pentest being signed, and the pentest dates or times may need to be shifted to avoid disruption of the business-critical event. Don’t immediately reject time-based limitations. Instead, discuss them with your client so that the impact of the decision to limit testing is mutually understood. Let’s switch this for a minute and think about other time-based limitations. What if your customer wants you to perform a remote pentest against 6,000 Internet-facing web applications and only has budget for three days of penetration testing effort from one tester? Their objective is to assess the risk that an Internet-based attacker can achieve access to their network via their web applications. This kind of time limitation may affect how thorough you are able to be and affect the number or type of findings you are able to identify. Is that enough time to identify software dependencies that might result in access if a third-party software is compromised? Is that even enough time to inventory the sites and possible injection points for basic web application testing? During scoping, you may need to limit what tests are performed, renegotiate the target scope, or ask for more system access to get closer to the customer’s goals. Note: It is worth noting that thoroughness (depth and breadth) of testing are directly affected by the pentester’s skill, the amount of information about the targets that is given to the pentester by the client, and the amount of time granted for testing. These concepts bear special consideration during scoping, budgeting, and client expectation setting. Asset Scope Limitations Sometimes, certain systems must be moved out of scope. These may be systems whose security is irrelevant to the client’s goals for the pentest. These may be fragile or special systems that would respond unpredictably to normal pentest activity. They may even be mission-critical systems whose interruption or malfunction could lead to major revenue loss, natural disaster, or loss of human life. As a pentester, it is your job to examine these requirements for excluding assets from scope, document them and their impact on testing, and explain to the client how their exclusion may affect the test results. Tool Limitations You may be required to use a limited toolset during a pentest. In some cases, local laws will forbid the use of certain kinds of tools or tests. In other cases, clients may require that testers use an approved list of client tools. Sometimes, the pentester may choose to limit tools used in the interest of time or budget for the work being purchased. Each of these bears discussion during scoping to examine the impact to testing, test results, cost of the test, and resource planning.
Consider the case where you are asked to perform a pentest that involves gaining physical access into an access-controlled facility in a state where you do not live or normally work. The client’s objective is to validate the security of the locks, doors, windows, and security cameras they have chosen to secure their data center. With some research, you find that the locks are trivial to pick with a set of lock picks, and a Slim Jim would likely gain access through one or more sliding windows. However, you are not a licensed locksmith in that locale, and possession of those tools is against the law for anyone without a license. In this case, you may not legally be able to practically prove these weaknesses by performing the attack, but only present your research in the report unless you are able to partner with a licensed locksmith for that locale. Here’s another scenario. Let’s assume that the client is not a highly secured enterprise, but they want to know how they do against the biggest and the best.
They want you to throw every trick in the book at them, but their budget is limited. Development of custom exploits is certainly possible, but it would be time consuming and require the attention of your best pentesters. To keep the client happy and stay within budget, the pentester might choose to limit attacks to not include proprietary exploits, but offer to test using other techniques designed to simulate an advanced attack. Allowed and Disallowed Tests Most pentesters will automatically put destructive activities out of scope. Few companies enter into a pentest with the intention of having their assets destroyed or their business disrupted. But there are exceptions even to this rule. Some organizations may ask specifically for stress testing against their assets or to see whether it is possible to affect the integrity of transactions within a controlled environment as part of testing. Hosting and cloud providers, who also need to authorize testing, may not allow layer 2 attacks due to the security risk to co-located customers sharing the same network infrastructure. There are various good reasons to disallow certain kinds of tests. You should discuss the kinds of tests you plan to do in order to achieve the testing objectives with your client as part of scoping discussions. Contracts and Documentation Contracts are mutual agreements that are enforceable by law and require an authorized representative from each party (i.e., contract signing authority) to sign the contract. Many of these documents are subject to review by legal counsel within the businesses involved in the agreement. These agreements hold two or more parties liable to specific obligations that shall or shall not be done. They may consider environmental differences and impose certain terms and conditions, such as local and national government restrictions and corporate (organizational) policies. Export restrictions prohibit the exporting of certain goods and services to other countries, such as U.S. export laws prohibiting the exporting of certain encryption technology. Organizational policies may subject users and service vendors of the environment to background checks. These types of environmental differences are typically structured in the best interest of the organization. In relation to penetration testing, CompTIA identifies five key contracts and documents. Tip: The test might include questions that will ask which document or contract should be referenced or used in a certain scenario. Make sure to understand the differences between the types. Master Services Agreement A master services agreement (MSA) is a type of overarching contract reached between two or more parties where each party agrees to most terms that will govern all other future transactions and agreements.
The agreement will cover conditions such as: - Payment terms Negotiated schedule of payment - Product warranties Assurance that a product meets certain conditions - Intellectual property ownership Copyrights, patents, and trademarks - Dispute resolution Defines a process for resolving differences - Allocation of risk Provision that defines levels of responsibility between each party - Indemnification Parties agree to be financially responsible in certain circumstances
This type of service agreement may also cover other items, such as corporate social responsibility, business ethics, network and facility access, or any other term critical for all future agreements. Often, an MSA is used in fields that tend to be open ended and support an organization’s functional areas, like manufacturing, sales, accounting and finance, and so on. Nondisclosure Agreement The nondisclosure agreement (NDA) is a confidentiality agreement that protects a business’s competitive advantage by protecting its proprietary information and intellectual property. It is in a company’s best interest to execute an NDA during a pentest, especially when outsourcing the work to an external service vendor. In the event the organization is compromised, the vendor is obligated to maintain the secrecy of the privileged information it might obtain during the pentest. Statement of Work The statement of work (SOW) is a formal document that is routinely employed in the field of project management, which outlines project-specific work to be executed by a service vendor for an organization. An SOW can also be a provision found in the MSA. It explains the problem to be solved, the work activities, the project deliverables, and the timeline for when the work is to be completed.
The statement of work typically addresses the following subjects: - Purpose Reason for the project - Scope of work Describes the work activities to be completed - Location of work Where the work will be performed - Period of performance The timeline for the project - Deliverables schedule Defines the project artifacts and due dates - Applicable industry standards Relevant criteria that must be followed - Acceptance criteria Conditions that must be satisfied - Special requirements Travel, workforce requirements (certifications, education) - Payment schedule Negotiated schedule of payment (possibly derived from MSA) Rules of Engagement The rules of engagement (RoE) document puts into writing the guidelines and constraints regarding the execution of a pentest—most importantly, what is and is not authorized for testing; for example, whether or not brute force is an allowed tactic, whether brute-force counts are limited by password lockout policies, automated fuzzing versus manual exploitation, etc. The RoE can be part of the SOW or treated as a separate deliverable. This document requires sign-off from the service vendor, as well as the client, to show that the baseline expectations have been set and agreed upon, but it is not always subject to the same legal review as an MSA or an SOW. Cloud service provider approvals may also need to be added as an appendix to the RoE, if applicable. This document elaborates on certain subjects defined in the SOW, such as scope, location, applicable industry standards, and timelines. Communication and escalation paths are also defined so the pentest team knows who to contact and how in the event of an issue. This may include expectations for the customer as well. The RoE is established before starting a pentest.
Examples of RoEs can be found in Appendix B of the NIST Special Publication 800-115 document hosted at https://www.nist.gov and in section 2.4 of the OSSTMM hosted at https://www.isecom.org/OSSTMM.3.pdf. Permission to Test Documents that grant permission to test must be signed by someone with authority over the assets being tested. This authority must be legally able to bless the terms of testing on behalf of the asset owners in all contracts and documentation. These documents should grant permission for testing activities to occur and set clear expectations that penetration testers are not held liable for system instability or crashes and that the tester will perform due diligence to avoid damage to systems as part of testing. Pentesters must do their own due diligence to verify that the person who is requesting the testing has the authority over tested assets in order to approve the test or that additional permission has been acquired. Scope and Requirements The scope of a pentesting engagement will outline the objectives and requirements for the assessment. Most importantly, once the scope is established and signed, it defines the boundaries for what you are permitted to test. In this phase, you are attempting to address several components of testing such as testing requirements, target selection, timelines and scheduling, and testing strategies. You should gather customer requirements during the scoping process. These will include compliance requirements and goals of testing and will suggest the kinds of tests (network, web, mobile, wireless, social engineering, and physical) that need to be executed during the engagement. An effective way of capturing this type of information for an organization is by using a scoping document or pre-engagement survey, an informal document that asks general questions about the organization being tested, such as location, software, hardware, architecture, IP address ranges, etc. It also accounts for certain testing considerations, such as the amount and type of data that will be disclosed to the pentester. Examples of these types of questions can be found under the General Questions heading in the Pre-Engagement Interactions section at www.pentest-standard.org/index.php. Standards The strategy or methodology used for penetration testing will depend on the organization’s rationale for the assessment, which could be driven based on the organizational threat model. Simply put, this is how you plan to approach the task of testing the security objectives of your client. This covers details such as how much information you have about the target environment prior to testing, your vectors of attack, the types of systems you will target, and what methods of attack you will employ within your testing limitations. Several industry-recognized standards offer testing methodologies that can be used as part of a valid testing strategy. Let’s talk about a few of these. MITRE ATT&CK MITRE ATT&CK is not a holistic pentest methodology, but rather a knowledge base of attacker actions created from a survey of publicly reported attacker activities. The objective is to catalog these actions using standardized reference criteria (tactics, techniques, and subtechniques) so that different groups can discuss and document them in the same terms. Pentesters can use ATT&CK to make threat actor emulation plans9 and may be asked to provide an ATT&CK-labeled attack tree or labels inside of a report. ATT&CK is organized into matrices of attack components. Each matrix is designed to address attacker activities in different operating platforms. The Enterprise matrix addresses attacks for Windows, Linux, macOS, network-specific attacks, and cloud and container technologies. There are also matrices for mobile and industrial control system (ICS) platforms. Within each matrix, attacks are categorized by tactic. Tactics attempt to describe an attacker’s high-level objective for using that method of attack. These were originally designed to follow the phases of attack described by Lockheed-Martin’s Cyber Kill Chain, a method of describing attacks at a high level. To see how this works, consider the Initial Access tactic in the ATT&CK Enterprise Matrix. This tactic describes attacks that an attacker might use to gain a foothold on a system. Another tactic, Credential Access, describes activities an attacker might perform to gather usernames or passwords. Tip: ATT&CK is often referenced by matrices—tactics, techniques, and sub-techniques—and referenced in terms of attacker emulation plans. Its value lies in labeling attack methods.
Attack actions are then described as techniques and sub-techniques. These are high-level descriptors of what an attack does. For example, sending a phishing e-mail is a way of getting initial access. Phishing is a technique. There are several ways to use an e-mail this way, though. You might use a malicious attachment or a link. These are sub-techniques under the Phishing technique.
These ATT&CK TTPs (tactics, techniques, and procedures) can then be used to describe a pentest attack chain using a common language. It’s worth noting three things about this. First, the same technique may exist in multiple tactical categories. As an example, scheduled tasks can be used for persistence or for privilege escalation. Second, ATT&CK tactics and techniques don’t describe the attack implementation, only the classification. There may be multiple ways to implement a particular tactic, technique, and sub-technique. Determining the best tactic and technique to describe something you do in a pentest can be subjective and requires a grasp of the logic used by MITRE when creating ATT&CK. Finally, not all attacks exist in ATT&CK. MITRE does not include every possible method of attack, only those that have been publicly disclosed as actions observed by an advanced persistent threat (APT) as defined by larger agencies. There will be some cases, especially in advanced attack scenarios, where you perform actions that simply do not fit inside ATT&CK. OWASP A great example of attack knowledge that does not fit well in ATT&CK is an application-based attack. The OWASP project (https://www.owasp.org) is a nonprofit organization and open-source community effort that produces tools, technologies, methodologies, and documentation related to the field of web application security. OWASP has many well-known publications and resources, such as the OWASP Top Ten, OWASP Testing Guide, the OWASP ZAP Project, DirBuster, and Webgoat, a deliberately insecure web application created as a guide for secure programming practices. Tip: OWASP focuses on web application security and full software development lifecycle (SDLC) testing, not only testing the implementation. The OWASP Top Ten provides community awareness of the most serious web application security risks for a broad array of organizations. The data is compiled statistically from various firms that specialize in application security.
The latest revision of the OWASP Top 10, as shown below, was completed in 2017. Primarily, this list is put together to help organizations understand the importance of securing web services and the effects certain weaknesses can have on an organization. As a pentester, this list is an important artifact that describes high-impact areas and where to potentially focus your testing efforts. Figure: OWASP Top 10 – 2017 The OWASP Web Security Testing Guide addresses pentest scoping and data collection concepts that apply to web application testing concerns specifically. As an example of where the OWASP testing guide differs from other methods and standards, it focuses on design review, code reviews, data flow modeling, specific methods of testing weaknesses that are only found in application implementations, and addresses security testing at all stages of SDLC. Its sections include information gathering methods for web application security testing and testing of configuration and deployment management, identity management, authentication, authorization, session management, input validation, error handling, weak cryptography, business logic, client-side issues, and application programming interfaces (APIs). OWASP also includes a tools reference for application-specific penetration testing use, reporting guidelines, and information about using development tools that may help application pentesters contextualize their attacks and perform security research. Tip: The examples of OWASP Top Ten attacks, such as cross-site scripting, and various injection attacks are quite useful. These can help you identify which kind of attack is being referenced on the exam. NIST The National Institute for Standards and Technology (NIST) is a nonregulatory U.S. government agency. In pursuit of their mission to advance technology, they maintain several publications that describe recommendations for cybersecurity and security testing initiatives. These may be required to be followed by some organizations, often within the U.S. government, but they are not legislated for all companies. The two key publications are Special Publication 800-115, “Technical Guide to Information Security Testing and Assessment,” which describes attack and testing, and the NIST Cybersecurity Framework, which describes the defensive half of the picture for cybersecurity. Tip: NIST recommendations and standards are often referenced by U.S. government organizations and companies that support them. SP 800-115 and the Cybersecurity Framework work together to define a security testing methodology (not only pentest) and defense best practices. Special Publication 800-115 defines a methodology for information security assessment. To describe penetration testing, NIST SP 800-115 uses a four-phase model: planning, discovery, attack, and reporting as shown in Figure 1-2. We talked a little bit about the resources this document provides for planning earlier in this guide. For discovery, NIST defines network port and service identification, gathering of hostname and IP address information, employee targeting information, system information (such as shares), and application service information (version numbers, for example) as targets for information gathering.
NIST describes the attack phase with an additional four phases, which are referenced as a repeating loop: gaining access, escalating privileges, system browsing, and installing additional tools. Figure: Four-phase pentest model Further advice in NIST recommends that pentest scenarios focus on the most likely and most damaging attack patterns and on locating and targeting exploitable defects in systems. This distinction is important because vulnerabilities may exist according to reports, but are they exploitable? This is the role of a pentest: to evaluate impact and exploitability in context. Tip: While you might not need to know every letter of the NIST standard, it’s good knowledge to have, especially if you plan to work with U.S. government–sector clients. For the exam, be prepared to identify when NIST standards might apply and what makes them different from other testing standards. OSSTMM ISECOM has released an Open Source Security Testing Methodology Manual (OSSTMM), which they describe as a complete pentest methodology designed to assure thorough, legal, consistent, and repeatable testing that can be measured. ISECOM also offers certifications for pentesters as a measure of qualification for compliance requirements. This methodology attempts to apply a framework to approach security testing (not only pentesting) for use in a structured process. Version 3 of the OSSTMM provides a Security Test Audit Report (STAR) containing questions that should be answered at the end of the pentest, but recommends that you perform testing as you are accustomed to doing, provided that you keep track of targets you test, what you tested on those targets, what controls you discovered during testing, and what you didn’t test while you test. ISECOM offers certification for signed STAR entries that are submitted to the organization for review. OSSTMM recommends that you define a security test by identifying assets that need to be protected, for example, data that is considered important. Then, list the controls that protect the assets and where those controls reside. This delimits the engagement zone. Scope is determined based on a consideration of the total possible operating environment where any interaction with the asset may occur, including all channels. The manual defines five channels and methodologies for testing them: human, physical, wireless, telecommunications, and data networks. In this model, data networks covers wired transmission using protocols like TCP/IP and all other electronic systems and data, while telecommunications is a concept reserved for telephone or telephone-like wired communications. Tip: OSSTMM provides one of the most complex definitions of testing types, and ISECOM does provide certification options for testers and reports. In addition to being a full security testing methodology (not only pentest), it provides a methodology for objectively measuring the target attack surface and risk values.
Then, you would choose a testing type.
OSSTMM offers six testing types: Blind, Double-Blind, Gray Box, Double Gray Box, Tandem, and Reversal, as shown in Figure below. Testing types are common among most methodologies and are more often limited to three types: Black Box or Blind testing, Gray Box or Partial-blind testing, and White Box or Full Knowledge testing. In OSSTMM, most pentests are grouped under the blind test types, while specialized testing such as red teaming appears under the Reversal type. Figure: OSSTMM testing types In Blind Testing, the primary impacts to breadth and depth of testing are the skill and efficiency of the pentester. Defenders have full knowledge of the pentest, while the pentester has no company-confidential knowledge other than what is legally required to define and limit the scope. This tests the impact from an uninformed attacker. In Double-Blind testing, both defenders and pentesters remain uninformed, allowing organizations to also test their defensive response. In Gray Box testing, which OSSTMM categorizes as a vulnerability assessment, some knowledge is needed about the environment (e.g., schematics and user access but not source code). However, defenders only have full knowledge in the Double Gray Box scenario. OSSTMM equates this to White Box testing in other models. Tandem testing in OSSTMM is what others would consider Crystal Box testing, an extreme level of White Box testing in which the tester is provided with all knowledge, including source code. The primary limit on quality is the quality of the information to the pentester and the transparency of the target organization during the scoping process. Reversal testing, on the other hand, is designed to test defenses under a worst-case scenario. These tests are typically used to explore response to and impact from a highly skilled attacker or an informed insider. OSSTMM suggests that the main limitations for this type of testing are the creativity and skill of the pentester and the quality of information to the tester in preparation for the exercise. OSSTMM also implements a series of error labels (e.g., true positive, false positive, entropy error, etc.) that are designed to facilitate statistical analysis of test results and a series of questions that tests are designed to answer. Questions such as “How do operations work currently?” “How do they work differently than the client believes they work?” and “How should they work in order to be secure?” drive measurement. The manual establishes methodology for analyzing and reporting on the results, including the generation of a rav to show objective measurement of the attack surface through various mathematical formulae. Now, let’s look at an example of how information disclosure affects a pentest. An Internet-facing server has an exposed web port. The default page is blank. Without any other information, you could attempt to identify vhosts based on open-source intelligence (OSINT) gathering or by making guesses at the names of hosted websites. In so doing, you might miss several sites and never evaluate their security. However, if the customer is willing to provide you with a list of application URLs, you could make sure to test each application according to what you can access. If you have accounts with different degrees of access into the application, you might be able to identify business logic flaws that result in privilege escalation or information compromise. If you have the source code to the application as well as a detailed walkthrough of the data flows, you should be able to conduct a very thorough investigation of the application’s security, but what you find will not necessarily be indicative of what an otherwise uninformed Internet-based attacker may be able to find when attacking the same application. This is only one example of how testing can be influenced by the amount of information negotiated during planning. PTES PTES (Penetration Testing Execution Standard) is a community-driven effort to establish standards for penetration testing that is contributed to by a number of professionals in the pentest consulting community. It was created in an effort to disambiguate what is meant by “pentest” for businesses seeking security testing services. The standard does not provide explicit instructions for how to conduct a pentest or use specific tools, but provides a separate set of technical guidelines to address tools and methods of attack. The standard also provides best practices for the steps that should typically be taken as part of a pentest, including reporting, intelligence gathering, threat modeling, and vulnerability analysis, and it explains concepts within the scope of exploitation and post-exploitation Tip: PTES uniquely focuses exclusively on a methodology for penetration testing as opposed to other kinds of security testing. It applies largely to pentests from a consulting point of view and does not specify execution of a pentest, but what a pentest should cover. It freely incorporates other frameworks (e.g., OWASP) and technical guides as supplemental resources. ISSAF The Information Systems Security Assessment Framework (ISSAF) was provided by the Open Information Systems Security Group (OISSG) in the UK. The ISSAF is a full security assessment methodology that applies to security auditing as well as other types of security testing. It defines three phases of a pentest: planning and preparation, assessment, and reporting and cleanup. ISSAF provides best practices for engagement management, including pre- and post-assessment actions; risk assessment methodology; and information gathering for all kinds of security assessments, not only pentest.
It covers host-specific scenarios by operating system, as well as addressing different pentest targets such as databases; physical locations and social engineering; wireless; web applications; switches, routers, VPNs, and firewalls; passwords; security controls such as IPS/IDS and antivirus; and source code review. Tip: ISSAF is designed for security assessment generally, not penetration testing specifically. While it does contain best practices for engagement (planning through report delivery), the biggest distinction between ISSAF and other standards mentioned here is it lists testing tasks with their associated tools for each task. Environmental Considerations for Scoping Each of these standards and methodologies offers recommendations and templates for data collection during pentest scoping. But let’s address some environmental considerations you may encounter outside of the context of any specific model. In general, you need to understand what your client wants to protect, how they plan to protect it, and consider the possible differences between how they believe these protections work and how they work in practice. But you may also need to consider boundaries and specific needs for testing.
Three examples are with networks, applications, and cloud-based assets.
Probably the most important consideration for networks is hosting. If your customer uses shared hosting, that is, infrastructure that is managed by another organization and shared with other companies, they may not be able to provide you with full authorization to test. You might need additional authorization for certain attacks, tools, or methodologies from the hosting or cloud provider. As discussed earlier, many cohosting providers do not allow layer 2 attacks, such as Address Resolution Protocol (ARP) spoofing because of the potential impact to other customers using the same infrastructure. In these cases, you should identify who is the provider, whether additional permission or documentation is required, and make sure that has been taken care of and documented prior to testing. This also applies to cloud-hosted environments, where cloud providers have their own rules of engagement that pentesters must legally follow. You may also need to ask about what protocols and controls are used across your attack vector. An internal test against a network may present you with the objective of bypassing Network Access Controls (NACs), causing you to adjust your initial access plan. In another case, you may request that the client create an intrusion prevention system (IPS) or web application firewall (WAF) passthrough for your testing system in order to examine the direct application impact of an advanced attacker with more time than is allowed for a penetration test. Another example is with wireless testing.
Most countries use channels 1 to 14 in the 2.4 GHz band. But in North America, only channels 1 to 11 are used. It is important to know which wireless bands and channels are applicable depending on the geographic location of the engagement. In the cloud world, including virtual private clouds, methods of virtualization and what cloud offerings are used will affect your methodology and tooling. For example, what virtualization technologies are in use? Docker and Kubernetes require a different approach than traditionally hosted operating systems.
What about Software, Infrastructure, or Platform as a Service technologies (SaaS, IaaS, and PaaS, respectively)? For applications, some organizations may wish to avoid disruption to their users by requesting testing in nonproduction regions. How closely these regions mirror production configurations may affect the applicability of the results to a production environment. Gathering API endpoint information and supporting documentation for the style of testing (black box, white box, or gray box) applies here. Target Selection An organization can have many assets (people, processes, facilities, and technologies) that it considers worthy of protection. These assets can be located throughout the world, and a pentester may be asked to test all or a sample of these assets to evaluate their security. Targets are key organizational assets that, if exploited, could negatively affect the organization. Pentesters need to gain a clear understanding of the environments to be tested, as well as pertinent documentation (depending on the strategy for testing) from the client, in order to perform discovery and validation of the targets for the engagement. Wireless Since proximity is a factor, the physical location of wireless networks, including the building and even the floor, is required for wireless network testing. Documentation of in-scope service set identifiers (SSIDs) ensures you are testing only the assets that belong to your customer. If wireless networks implement different trust levels—for example, a public guest wireless local area network (WLAN) versus a private corporate WLAN—it may be useful to select one or more sample networks from each type to evaluate those trusts. IP Ranges Host targets may be supplied as hostnames, domains, IP addresses, or IP ranges. You will want to verify that the IP ranges supplied belong to the customer and identify any IP ranges that are hosted by third parties, as that may affect your authorization to test. A typo or miscommunicated subnet or IP address could easily result in a serious problem of authority for you. You may also want to establish IP addresses for load balancers versus IPs of back-end systems to avoid overloading clusters during discovery or brute-force attacks. Consider the amount of occupied space within an IP range when planning for your pentest, as time to scan and evaluate systems can quickly build up over large ranges. DNS Along with IP targets, hostnames and domains may not necessarily belong to your client due to outsourcing agreements with marketing providers, for example. You can use DNS reconnaissance to identify other services and ranges that have not been otherwise specified, but always confirm these details with the client to avoid scope overreach and ensure coverage by your authorization to test parameters. APIs and Other Support Resources Depending on the methodology, organizational budget, and type of assessment chosen for the engagement, the customer may wish to provide additional support resources to assist with the pentest. These resources can be independent artifacts either specified in the RoE or provided to the pentest team after the RoE is signed.
Examples of these resources can be found below. Table: Support Resources Physical Locations Physical locations will determine travel requirements and device deployment considerations. Selection of testing methods and locations for testing may also be affected by the controls being tested and the assets in residence.
What kinds of access control mechanisms are in use? Are the locations accessible by the general public or limited to specific staff? How are identity and authorization established? Are locations manned or remotely monitored? Under what conditions are law enforcement engaged during ingress attempts? Is security armed? Is the physical target within proximity of other facilities that may be inadvertently affected (for example, reporting suspicious behavior or having shared disposal areas for physical waste)?
Local laws affecting tool usage for physical ingress testing also bear investigation. Physical location information may also need to inform where you drop baiting devices or how you deploy surveillance equipment.
You should have a “get-out-of-jail-free” (GOOJF) card or other documentation that asserts your authorization to test, as well as a communication plan that includes contacts who can deconflict and de-escalate with law enforcement and physical security groups before any testing begins. The GOOJF is often included as part of the negotiated RoE. External vs. Internal Targets The location, source, and direction of testing provide different security perspectives of the organization. Testing can be conducted onsite at the organization’s facility or offsite. Internal testing may examine the condition in which an endpoint within the network is compromised, either by malware or a malicious insider. External testing may evaluate the security of an organization against an Internet-based attacker. These may include use of conventional methods of remote access such as the use of a virtual private network (VPN) or exploration of vulnerabilities in other remotely exposed services. Internal assessments evaluate various levels of trust between organizational systems, applications, and networks (Figure). Internal testing is defined as testing that originates behind perimeter defenses (external firewall) using a access level. You may have only a network connection. Limited access affords the initial connectivity to the targets, such as a physical connection to the network switch, the SSID and password to the Wi-Fi network, or having an IP address allow-listed. The type of access chosen depends on the type of assessment and the overall goals of the engagement. Figure: Internal testing Note: In computer security, allow-listing and block-listing are basic access control mechanisms that can be implemented in network firewalls, spam filters, web application firewalls (WAFs), etc. An allow-list denies all except members of the list. A block-list is the opposite—it allows all but denies members of the list. User-level access assumes the identity of a trusted insider with basic permissions that a typical user in the organization would have. An account can be created either locally or in the account management system, such as Active Directory, to simulate the user for testing. The goal is to gain additional levels of access through privilege escalation. Privileged-level access can be used to conduct various types of testing to include escalating local admin privileges to domain-level access, inspecting operating system patch levels, or determining if a system is configured in accordance with a specific policy, such as in the case of compliance testing. External testing provides more limited-access vectors than that with internal testing. This type of testing occurs on the outside of the network security perimeter, such as the Internet (Figure below). The evaluation is conducted from that of a malicious attacker’s point of view. This type of testing typically starts with reconnaissance to collect organization information using OSINT techniques. The goal is to discover vulnerabilities that could be exploited from the outside by external attackers. Figure: External testing Note: Some organizations may assume credentialed or guest access to Internet-facing web applications as still an external assessment, rather than internal, due to the access vector to the application (Internet only). First-Party vs. Third-Party Hosted If the targets are hosted in a first-party environment, coordination of testing activities will be easier, as the customer owns the equipment and testing is simply subject to the company’s policies. If the targets are hosted in a third-party environment, such as a cloud service provider (CSP), testing is not only subject to the company’s policies, it is also subject to the third party’s acceptable use policies. For instance, Amazon Web Services (AWS) defines prohibited and permitted activities and a procedure for requesting approval for other kinds of simulated events in their Customer Support Policy for Penetration Testing at https://aws.amazon.com/security/penetration-testing. Contract Review Companies are typically organized according to specific business purposes or functions. It’s important to understand the purpose or function of the organization your work is supporting, as it identifies the reporting levels and responsibility within the company. You will need to identify the stakeholders for the engagement based on this understanding for communication, delivery, and other aspects of project coordination.
Typically, stakeholders include people such as: - Executive management - Contracting or legal department - Security personnel - Members of the IT department - Penetration testing staff
Executive management (senior management) is typically responsible for the organization’s overall goals and success, and tests are typically not permitted without their written authorization and approval.
The contracting officer or legal representative may need to review and enforce legal and contractual commitments for all parties involved in the engagement. Both security personnel and members of the IT department are essential for communicating about organizational security policies and responding to incidental outages (account lockouts, disruption of services, etc.).
Penetration testing staff is vital to the success of the engagement, as they are responsible for identifying weaknesses within the security support structure of the organization and simulating attacks that are applicable to the organization’s threat profile. Knowing the responsible parties will help establish an effective communication strategy and escalation path for remediating issues that arise during the engagement. Note: Stakeholders are information consumers, not only escalation points. Each group will have a different understanding and expectation of the process. For instance, executive management will want to know essential information and updates in order to make strategic decisions for the organization both during and after the engagement. They will not be as concerned with the technical details of the pentest report, like the IT department or security personnel will be. These differing understandings should influence a pentester’s communications (information type and presentation) during calls, e-mails, and reporting. Part of your scoping exercise will involve discussing the nature of the test with one or more of these stakeholders. You will want to review the contracts and documentation to make certain you have all of the requirements in place to perform testing and to verify a mutual understanding of the terms of the test. Here are a few examples of details you will likely review. Time Management Chances are the client and the consultant have planned and budgeted for a prescribed amount of testing time and a specific amount of ground to be covered during the course of the engagement. You will want to review the scheduled beginning and end of testing and any deadlines or timelines that the customer has related to the test. Additionally, you may need to review the proposed testing objective and scope to ensure the work can be reasonably completed within the time frame specified. In the event that this is not the case, you may need to have discussions about reduction of the scope, changes to budget, or revisions to methodology that may align with these terms. For pentesters who may need to manage multiple engagements, time management must also consider the time it takes to write the report, deliver the results, and handle any follow-up concerns such that the needs of one engagement do not affect the execution of another engagement. Limitations During contract review, you will also want to discuss any limitations placed on testing, including hours of testing, limits to allowed methodologies or tooling, and limits to liability for the tester. The objective is to ensure these terms are mutually understood, accepted, and correct in the contract and planning documentation. Limitations on testing may have impacts to the test outcomes, and no pentester can ensure that compromise is impossible or that every possible vulnerability has been identified. Making sure that these are clearly stated, discussed, and understood by all parties is crucial to a successful engagement. Expectation Setting and the SLA Traditionally, a service level agreement (SLA) defines measurements for the expectations between the customer and the service provider, as well as the terms of what happens if those expectations are not met. Typically, this will apply to agreements when the pentester is external to the tested organization, but even internal penetration testing groups will often be held accountable for how they operate, what they deliver, and when they deliver it. Some examples of items that may fall under the SLA include measures of quality, timeliness, or cost. This information is typically addressed as part of the SOW, but separate documentation may define when reports must be delivered, how soon after the contracts are signed must testing be initiated, how soon after initiation must testing activities conclude, and so on. This also includes things like responding to communication for the purpose of clarifying testing objectives or contract language, or for scheduling testing activities within a reasonable period of time. The MSA will typically outline what recourse the client has available should the tester not meet their documented expectations, and vice versa. For example, the MSA may document financial forfeiture of all or part of the amount of the contract should the terms of the agreement not be met. Communication Planning An important part of ensuring a successful pentest is communication. There are many good reasons for communication. Communication with the customer provides the ability for deconfliction, which is the process of sorting out your pentest artifacts from the artifacts of a real compromise, for example. If incidents or outages occur while testing is in progress, administrators may be quick to look at the pentest as the cause of the problems even if these events are caused by other activities in the environment. During the planning phase, you will want to discuss the communication plan with your customer. They may have specific requirements for the interval of communication or points of contact other than those involved in the pentest planning who need to be alerted under specific testing circumstances. Generally, the communication plan should cover when you should communicate, what you should communicate, to whom you should communicate it, and how it should be communicated. This may include on-call numbers for testing that occurs outside of normal business hours, escalation phone numbers for emergencies, and direct contact information for client stakeholders and pentesters to be shared with both parties. Communication Paths A communication escalation path will need to be properly defined in the RoE to help remedy issues that may arise during testing. In addition to establishing what to do in the event that a contact is not responsive, an escalation path helps define a chain of command and helps resolve and manage conflict. In the event a critical service or system goes down during testing, the pentest team will already know which buttons to dial on the phone to let someone in the chain of command know what happened. If the organization has a network operations center (NOC), they probably already know that the service went down.
However, knowing the event was not a result of a true adversarial threat reduces the amount of alarms and investigation that needs to happen in order to remedy the situation. Communication Triggers Communication triggers are important indicators of when the pentester (or pentest team) should reach out to the customer. A few of those indicators include critical findings, completing certain stages (testing activities or milestones) in the engagement, embarking upon a potentially risky test (e.g., executing a potential SQL injection against a production web application), possible indicators of prior compromise, and anything else that results in the need for goal readjustment. When the pentester finds a critical finding on the network, such as a publicly exploitable vulnerability from outside the firewall that anyone on the Internet can exploit, it should be brought to the customer’s attention so the proper mitigation can be applied to prevent the potential risk of compromise. During the pentest you may discover malware, malicious binaries, and services running on servers or local accounts created on the server that neither you nor the customer created. These indicators of prior compromise should be brought to the attention of the customer immediately. Professionalism and Integrity The Computer Ethics Institute drafted the Ten Commandments of Computer Ethics in an attempt to structure human use of computers towards good. Since then, many organizations have attempted to document their own measurements of what it means to be an ethical computer user. But it’s worth considering these in the context of a penetration test. In general, these state that you should not use your powers to harm other people, interfere with the work of other people, snoop through other people’s data, steal, bear false witness, use proprietary software for which you have not paid, use other people’s computers without authorization or compensation, appropriate the ideas of others, design software without considering the social consequences of the software, and be inconsiderate or disrespectful of others. These all have applicability to penetration testing, as penetration testing requires a great deal of trust and therefore high degrees of integrity and professionalism. Trust must not only be earned, but preserved for the sake of future pentesting opportunities. You have access to information that is often highly protected, and if it were revealed outside an appropriate context, it could result in significant material harm to the organization that has entrusted you with this important task. Let’s talk more about what it means to be a good steward of that trust. Note: The article “Legal Issues in Penetration Testing” by Mark Rasch in Security Current covers many of these issues at a high level and may be worth a read: https://securitycurrent.com/legal-issues-in-penetration-testing/ Communication We’ve talked about communication triggers and communication pathways as part of a communication plan. Integrity demands that you always be honest and own your mistakes when it is clear that you are in the wrong. Note: Ownership does not always mean confession. We’ll talk about de-escalation in a moment. Professionalism requires you to communicate when it is expected and follow that communication plan. You should also be sure to communicate calmly and clearly with your target audience in mind and be aware of the situation so that you can manage it appropriately.
Be clear that you should be aware that you may be dealing with technical resources, executives, or even third-party stakeholders with interest in the nature and outcome of your work. For each of these groups, you should strive to remain professional, gain an understanding of what they need to know, and tailor your messaging according to their needs. Your goal as a pentester is to not seem patronizing to those who understand technical nuance while striking a balance that makes you knowledgeable without being dismissed as “the tech nerd” to business leaders who need your expertise to manage their business. You can avoid many common communication pitfalls with situational awareness. Some stakeholders may be overtly hostile, as your presence is required as conditions of an audit, for example. Business units with oppositional alignment, such as IT support staff and IT security staff, may use pentests as a tool in an internal political struggle. Technical practitioners may feel as though you are there to tell them that their hard-won successes are inadequate and be defensive about the nature of what you find. These situations (and many others) are not only realistic, but probable. So, pay attention to what stakeholders identify as their concerns. Look for areas of competition in the customer organization and remain cognizant of them while you discuss the pentest plan and the results. Be careful not to attribute blame to individuals or groups, but to practices, configurations, and policies. Approach pentesting as a way to make the organization stronger rather than as a way to show its weakness, and your message will likely be more positively received. In the case where issues are unavoidably contentious, you may need to de-escalate the situation. This may be caused by a difference in understanding regarding a technical issue surfaced during pentesting, such as an Active Directory administrator who does not believe a particular configuration is the reason you are able to succeed with a particular attack. Or it may be something you encounter during planning, such as what defines a realistic scope for an attack versus what will produce a pentest that makes things seem secure. Either way, if tempers flare or discussion becomes heated, your role is to stay calm and remain professional.
First, take a step back and let people absorb and process information and their reaction. Silence can feel awkward, but it can also be important when tensions rise. Sometimes, people simply need time to formulate their response or to get over an initial negative reaction. Make sure your body language stays neutral, your voice remains even, and keep the volume of your voice under control. Try not to make anyone look stupid in front of their boss if you can avoid it.
Use your empathy for their situation. Ask yourself why are they responding the way they are? What feeling is causing their reaction? Ask them clarifying questions about their concerns, so that you can offer them solutions. Don’t engage in arguments, and use your contract language as necessary to keep discussions civil, withdrawing from the conversation as necessary if the condition worsens.
During testing, it is possible you will identify an issue that requires immediate action or a finding that changes the initial assumptions about the test. In case this happens, you will need to refer to your communication plan and possibly discuss the goals with your customer. Goal reprioritization may be necessary to properly plan and address the new problem. A readjustment of priorities can also happen in certain attack vectors that are not available due to issues with the network or unforeseen configuration problems, and waiting to complete the testing activity could affect the overall schedule. One example of an issue that requires immediate action is evidence of criminal activity. Specifically, if you notice you are not the first person to attack a system, you should stop testing immediately; record everything you have done, including the evidence of compromise that you have identified; and initialize your communication plan. Don’t go digging for further evidence. You want to avoid accidentally destroying or tainting digital evidence that the customer needs in order to take action. Instead, you should be able to prove what you did in order to differentiate it from what else has been done and provide any information necessary for the customer to initiate incident response. But when should you report the incident to law enforcement? If you are working on behalf of another organization, they may handle the escalation. However, if the nature of your finding legally compels you to report the incident to law enforcement outside of a client agreement, you should engage your legal counsel to handle notification immediately. Prepare for all communication by maintaining organized documentation. Even if it does not make it into your report as part of evidence, and even if it is not part of a criminal finding, you will want notes that you can reference about each part of the penetration test, from planning through execution. Being able to quickly identify facts about what you did, when you did it, where it happened, and why can be a career-saving practice. Never underestimate the importance of maintaining and organizing your own documentation. Integrity As we discussed, trust in a pentester is essential. For most organizations, this is a matter of risk management. How does anyone know that a paid hacker is trustworthy? How does anyone know if a pentester has the right skills for the job? Some companies see it as less risk to select pentest organizations or staff based on their reputation in the community or on their finances. They may interview the pentesting organization about relevant skills or certifications to determine whether testers have the skills to match the environment. Employers will frequently attempt to assure integrity by insisting on background checks for testers, including credit checks or criminal records checks and possibly drug screenings.
The risk assessment examines the perceptions that someone with drug dependency or a lot of debt may be more susceptible to bribery, for example. Pentesters with a history of using their skills for crime may have a harder time convincing people they do not plan to abuse their access or sell company secrets. For federal organizations, background checks may require more extensive evaluations. Past employment performance, financial stability, and references are good indicators of capability and intent. But what about a pentester’s discretion? Observing the “need to know” principle of data access can be a challenge for a curious person, but it is absolutely an essential part of professionalism. It may be tempting to look at systems or data because they are interesting. Maybe the temptation of uncovering a scandal is compelling.
Not only would giving into these temptations be unethical and unprofessional, but it may also be illegal, depending on regional law, the terms of your contract, and what you do with the information once you access it. Instead, adhere to your RoE and access only the systems and data that are related to your objectives. If the scope needs to be changed, engage in goal reprioritization discussions with your stakeholders according to your communication plan. Generally, try to test in a way that gathers only the information you need for the next part of your test.
As an example, instead of gathering every credential on a domain (unless that’s an objective), gather credentials selectively where you can. Similarly, use only tools that the client has approved, and don’t attack anything you do not have permission to test. As part of scoping, you may define a general list of tools for discussion and document how you plan to use the tools and what tools you intend to use. Then focus only on the approved target scope, being careful to avoid any out-scoped targets. Intentionally or accidentally testing resources or organizations that are outside of your grant of authority may be illegal, depending on what you do and depending on regional laws. Communicate immediately with your client if you identify that you have mistakenly gone outside of your mandate so that additional notification can occur, if required. If you need to practice your craft, do it on systems you own or with permission only. This is one of the reasons it is so important to identify whether networks or systems are shared with other organizations outside of the scope of your contract while planning the penetration test. When you access a client’s information, handle it according to the terms of your contracts. Be sure to observe any details of the NDA and data handling requirements identified within other contract language. Don’t discuss your clients or their environments with friends, acquaintances, or business partners who do not have a need to know. Even when you know the security weaknesses in a particular environment, you shouldn’t talk about them outside of the contract terms. Limit conversations about your work in public spaces, and don’t mention the names of your clients or stakeholders in those discussions. Don’t brag about how badly you pwned a client or make other comments about the state of their environment that could damage their reputation, or you may be putting yourself at risk of a lawsuit. Risks to the Tester Failure to observe the terms of your contract could expose you personally to risk. Access or use of computer systems without permission may be considered unlawful use or access. Using data or access to conduct activity disallowed by a contract may be considered access for fraudulent purposes. Transmission of data outside of the target environment and keeping it for one’s own personal use or giving it to others may constitute data theft. Pentesters could be subject to arrest, to the confiscation of property, to extensive legal fees and fines, and to criminal charges for activities conducted without permission or outside the terms of a contract. Fines may range from a few hundred dollars to hundreds of thousands of dollars. Sentences range from probation to terms of over 20 years, depending on the type and severity of the infraction. The contract language may be the only thing between you and breaking the law. It is critically important that you review the RoE and other documents and stay within the negotiated terms during pentesting. Pentesters and companies may attempt to avoid other legal liability by carrying errors and omissions insurance. This should handle fines and cover the costs against legal action in the case a client asserts negligence.
Pentest contracts should note that a test will not find every possible weakness and define the terms of operation. However, a client who is compromised by a threat actor after a penetration test has been completed and all findings addressed may not understand this and attempt to take legal action.
References: 1. CREST: https://www.crest-approved.org/ 2. GDPR: https://gdpr.eu/tag/gdpr/ 3. Personal data: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/key-definitions/what-is-personal-data/ 4. https://www.legislation.gov.uk/eur/2016/679/article/32 5. PCI-SSC: https://www.pcisecuritystandards.org 6. PCI-DSS v. 3.2.1: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf 7. PCI-DSS Information Supplement: Penetration Testing Guidance: https://www.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf 8. PCI Sensitive Authentication Data: https://www.pcisecuritystandards.org/pci_security/glossary#S 9. Attacker emulation plans: https://attack.mitre.org/resources/adversary-emulation-plans/ 10. NIST SP800-115 “Technical Guide to Information Security Testing and Assessment” https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf 11. NIST Cybersecurity Framework: https://www.nist.gov/cyberframework 12. ISECOM Open Source Security Testing Methodology Manual (OSTMM): https://www.isecom.org/research.html 13. Computer Professionals for Social Responsibility. The Ten Commandments of Computer Ethics, written by the Computer Ethics Institute: http://cpsr.org/issues/ethics/cei/
Join 4M+ learners. Unlock unlimited quizzes, wrong-answer tracking, flashcards + reminders, study guides, and 1-on-1 challenges.