Chapter 2

Planning and Scoping a Penetration Testing Assessment

Many things can go wrong if you do not scope and plan a penetration testing engagement appropriately. In particular, you need to be aware of local laws and legal concepts related to penetration testing. In this chapter, you will learn the importance of good planning and scoping in a penetration testing or ethical hacking engagement. You will learn about several key legal concepts and the different aspects of compliance-based assessments.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 2-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Q&A Sections.”

1. Which of the following documents includes the penetration testing timeline?

1. Rules of engagement

2. SOW

3. MSA

4. WSA

2. Which of the following is not an element of pre-engagement tasks?

1. Creating the SOW

2. Signing an NDA

3. Establishing different communication paths

4. Selecting targets by running Nmap or a similar scanner

3. Which of the following is true about the base group of CVSS?

1. The base group represents the intrinsic characteristics of a vulnerability that are constant over time and do not depend on a user-specific environment.

2. The base group assesses a vulnerability as it changes over time.

3. The base group represents the characteristics of a vulnerability, taking into account the organizational environment.

4. The base group is optional; the only mandatory field is the environmental score.

4. You can obtain several support resources from an organization that hired you to perform a penetration test. Which of the following is an example?

1. Active Directory accounts

2. SOW

3. A Swagger document

4. An NDA

5. Which of the following are true about a penetration testing engagement contract? (Select all that apply.)

1. The contract is one of the most important documents in your engagement. It specifies the terms of the agreement and how you will get paid, and it provides clear documentation of the services that will be performed.

2. The document should be very specific, easy to understand, and without ambiguities. Any ambiguities will likely lead to customer dissatisfaction and friction.

3. Legal advice (by a lawyer) is always recommended for any contract.

4. The contract must be signed at least 30 days from the start date of the engagement.

6. Which of the following is not true about the statement of work (SOW)?

1. The SOW specifies the activities to be performed during the penetration testing engagement.

2. The SOW defines confidential material, which is knowledge and information that should not be disclosed and should be kept confidential by both parties.

3. The SOW specifies the penetration testing timelines, including the report delivery schedule.

4. The SOW specifies the location of the work.

7. In which of the following circumstances might you encounter scope creep?

1. When there is poor change management in the penetration testing engagement

2. When the contract changes the date of the testing engagement

3. When the NDA is signed

4. When there is a good and effective identification of what technical and nontechnical elements will be required for the penetration test

8. Which of the following are types of penetration testing assessments? (Select all that apply.)

1. Goals-based (objectives-based) assessments

2. FedRAMP

3. Compliance-based assessments

4. PowerShell-based assessments

9. Which of the following is not an example of regulations or regulatory bodies applicable to the financial sector?

1. Title V, Section 501(b) of the Gramm-Leach-Bliley Act (GLBA) and the corresponding interagency guidelines

2. New York’s Department of Financial Services Cybersecurity Regulation (23 NYCRR Part 500)

3. Federal Deposit Insurance Corporation (FDIC) Safeguards Act and Financial Institutions Letters (FILS)

4. HIPAA

10. Which of the following statements is true?

1. PCI DSS applies only in the United States.

2. PCI DSS must be adopted by any organization that transmits, processes, or stores payment card data or directly or indirectly affects the security of cardholder data.

3. HIPAA must be adopted by any organization that transmits, processes, or stores payment card data or directly or indirectly affects the security of cardholder data.

4. GLBA is regulated by the PCI DSS standard.

Foundation Topics

Explaining the Importance of the Planning and Preparation Phase

One of the most important phases (if not the most important) of any penetration testing engagement is the planning and preparation phase. During this phase, you clearly scope your engagement. If you do not scope correctly, you will definitely run into issues with your client (if you work as a consultant) or with your boss (if you are part of a corporate red team), and you might even encounter legal problems. The following are some key concepts you must address and understand in the planning and preparation phase:

• The target audience

• The rules of engagement

• The communication escalation path and communication channels

• The available resources and requirements

• The overall budget for the engagement

• Any specific disclaimers

• Any technical constraints

• The resources available to you as a penetration tester

The following sections cover these key concepts in detail.

Understanding the Target Audience

You must understand who the target audience is for your penetration testing report, and you must also understand the subjects, business units, and any other entity that will be assessed by such a penetration testing engagement. Penetration testing reports typically have different target audiences. You must also understand who will be the primary recipient of the report and how you will create a good hierarchical structure to support the different audiences.

Chapter 10, “Reporting and Communication,” covers penetration testing reports in detail; here we present a few general key points that you need to take into consideration during the preparation phase of your engagement. You need to understand the different characteristics of your target audience, including the following:

• The entity or individual’s need for the report

• The position of the individual who will be the primary recipient of the report within the organization

• The main purpose and goal of the penetration testing engagement and ultimately the purpose of the report

• The individual’s or business unit’s responsibility and authority to make decisions based on your findings

• Who the report will be addressed to—for example, the information security manager (ISM), chief information security officer (CISO), chief information officer (CIO), chief technical officer (CTO), technical teams, and so on

• Who will have access to the report, which may contain sensitive information that should be protected, with access provided on a need-to-know basis

Rules of Engagement

The rules of engagement documentation specifies the conditions under which the security penetration testing engagement will be conducted. You need to document and agree upon these rule of engagement conditions with the client or an appropriate stakeholder. Table 2-2 lists a few examples of the elements that are typically included in a rules of engagement document.

Gantt charts and work breakdown structures (WBS) can be used as tools to demonstrate and document the timeline. Figure 2-1 shows an example of a Gantt chart.

Another document that is often used and that is important for any penetration testing engagement is the permission to test document. This can be a standalone document, or it may be bundled with other documents, such as the main contract. Contracts and statement of work (SOW) documents are covered later in this chapter.

Communication Escalation Path

You should always have good open lines of communication with your client and the stakeholders that hired you. You should have proper documentation of answers to the following questions:

• What is the contact information for all relevant stakeholders?

• How will you communicate with the stakeholders?

• How often do you need to interact with the stakeholders?

• Who are the individuals you can contact at any time in case there is an emergency?

Figure 2-2 provides a simple example of a contact card for your reference.

You should also ask for a form of secure bulk data transfer or storage, such as Secure Copy Protocol (SCP) or Secure File Transfer Protocol (SFTP). You should also exchange any Pretty Good Privacy (PGP) keys or Secure/Multipurpose Internet Mail Extensions (S/MIME) keys for encrypted email exchanges.

Confidentiality of Findings

You must discuss and agree upon how confidential data will be handled. For example, if you are able to find passwords or other sensitive data, do you need to disclose all those passwords or all that sensitive data? Who will have access to the sensitive data? What will be the proper way to communicate and handle such data?

Similarly, you must protect sensitive data and delete all records, as agreed upon with your client. Your customer could have specific data retention policies that you might also have to be aware of. Every time you finish a penetration testing engagement, you should delete any records from your systems. You do not want your next customer to find sensitive information from another client in any system or communication.

Budget

When it comes to penetration testing and ethical hacking, you can raise questions about budget and return on investment (ROI) from both sides—the client side and the tester side. The client will always ask questions like these:

• How do I explain the overall cost of penetration testing to my boss?

• Why do we need penetration testing if we have all these security technical and nontechnical controls in place?

• How do I build in penetration testing as a success factor?

• Can I do it myself?

• How do I calculate the ROI for the penetration testing engagement?

At the same time, the tester needs to answer questions like these:

• How do I account for all items of the penetration testing engagement so I do not go over budget?

• How do I do pricing?

• How can I clearly show ROI to my client?

The answers to these questions clearly depend on how effective you are at scoping and clearly communicating and understanding all the elements of the penetration testing engagement. Another factor is understanding that a penetration testing is a point-in-time assessment.

Point-in-Time Assessment

Penetration testing engagements are considered point-in-time assessments. Consider, for example, the timeline illustrated in Figure 2-3.

In Figure 2-3, a total of three penetration testing (pen testing) engagements took place in a period of two years at the same company. In the first engagement, 1000 systems were assessed; 5 critical-, 11 high-, 32 medium-, and 45 low-severity vulnerabilities were uncovered. A year later, 1100 systems were assessed; 3 critical-, 31 high-, 10 medium-, and 7 low-severity vulnerabilities were uncovered. Then two years later, 2200 systems were assessed; 15 critical-, 22 high-, 8 medium-, and 15 low-severity vulnerabilities were uncovered. Is the company doing better or worse? Are the pen test engagements done just because of a compliance requirement? How can you justify the penetration testing if you continue to encounter vulnerabilities over and over after each engagement?

You can see that it is important for both the company and the pen tester to comprehend that penetration testing alone cannot guarantee the overall security of the company. The pen tester also needs to incorporate clear and achievable mitigation strategies for the vulnerabilities found. In addition, an appropriate impact analysis and remediation timelines must be discussed with the respective stakeholders.

Impact Analysis and Remediation Timelines

You need to clearly understand and effectively communicate the impact of the vulnerabilities discovered in order to prioritize remediation of the vulnerabilities and understand the remediation timelines. In Chapter 10 you will learn how to write an effective penetration testing report. Here we talk about just one important aspect of such a report: the severity risk ranking. You have to effectively communicate the overall risk to the corporation. The report should clearly document how the severity or risk ranking is derived. You should adopt industry-standard score methodologies such as the Common Vulnerability Scoring System (CVSS). CVSS was created by security practitioners in the Forum of Incident Response and Security Teams (FIRST). You can find detailed information about CVSS at https://first.org/cvss

In CVSS, a vulnerability is evaluated under three groups, and a score is assigned to each of them:

• Base group: The base group represents the intrinsic characteristics of a vulnerability that are constant over time and do not depend on a user-specific environment. This is the most important information and the only group that’s mandatory for obtaining a vulnerability score.

• Temporal group: The temporal group assesses a vulnerability as it changes over time.

• Environmental group: The environmental group represents the characteristics of a vulnerability, taking into account the organizational environment.

The score for the base group is between 0 and 10, where 0 is the least severe and 10 is assigned to highly critical vulnerabilities. For example, a highly critical vulnerability could allow an attacker to remotely compromise a system and get full control. In addition, the score comes in the form of a vector string that identifies each of the components used to make up the score. The vector is used to record or transfer CVSS metric information in a concise form. The vector string starts with the label CVSS: and a numeric representation of the CVSS version, followed, for each metric, by a metric name in abbreviated form, a colon, :, and the associated metric value in abbreviated form. The following is an example of a CVSS 3.0 vector:

Click here to view code image

CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L

The formula used to obtain the score takes into account various characteristics of the vulnerability and how the attacker is able to leverage these characteristics. CVSSv3 defines several characteristics for the base, temporal, and environmental groups.

The base group defines Exploitability metrics, which indicate how the vulnerability can be exploited, as well as Impact metrics, which measure the impact on confidentiality, integrity, and availability. In addition to these two metrics, a metric called Scope (S) is used to convey the impact on systems that are impacted by the vulnerability but do not contain vulnerable code.

The Exploitability metrics include the following:

• Attack Vector (AV) represents the context in which a vulnerability can be exploited. It can assume four values:

  • Network (N)

  • Adjacent (A)

  • Local (L)

  • Physical (P)

• Attack Complexity (AC) represents the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. The values can be the following:

  • Low (L)

  • High (H)

• Privileges Required (PR) represents the level of privileges an attacker must have to exploit the vulnerability. The values are as follows:

  • None (N)

  • Low (L)

  • High (H)

• User Interaction (UI) captures whether a user interaction is needed to perform an attack. The values are as follows:

  • None (N)

  • Required (R)

• Scope (S) captures the impact on systems other than the system being scored. The values are as follows:

  • Unchanged (U)

  • Changed (C)

The Impact metrics include the following:

• Confidentiality (C) measures the degree of impact to the confidentiality of the system. It can assume the following values:

  • Low (L)

  • Medium (M)

  • High (H)

• Integrity (I) measures the degree of impact to the integrity of the system. It can assume the following values:

  • Low (L)

  • Medium (M)

  • High (H)

• Availability (A) measures the degree of impact to the availability of the system. It can assume the following values:

  • Low (L)

  • Medium (M)

  • High (H)

The temporal group includes three metrics:

• Exploit Code Maturity (E), which measures whether a public exploit is available

• Remediation Level (RL), which indicates whether a fix or workaround is available

• Report Confidence (RC), which indicates the degree of confidence in the existence of the vulnerability

The environmental group includes two main metrics:

• Security Requirements (CR, IR, AR), which indicate the importance of confidentiality, integrity, and availability requirements for the system

• Modified Base Metrics (MAV, MAC, MAPR, MUI, MS, MC, MI, MA), which allow the organization to tweak the base metrics based on specific characteristic of the environment

For example, a vulnerability that might allow a remote attacker to crash the system by sending crafted IP packets would have the following values for the base metrics:

• Access Vector (AV) would be Network because the attacker can be anywhere and can send packets remotely.

• Attack Complexity (AC) would be Low because it is trivial to generate malformed IP packets (for example, via a Python script).

• Privilege Required (PR) would be None because there are no privileges required by the attacker on the target system.

• User Interaction (UI) would also be None because the attacker does not need to interact with any user of the system in order to carry out the attack.

• Scope (S) would be Unchanged if the attack does not cause other systems to fail.

• Confidentiality Impact (C) would be None because the primary impact is on the availability of the system.

• Integrity Impact (I) would be None because the primary impact is on the availability of the system.

• Availability Impact (A) would be High because the device could become completely unavailable while crashing and reloading.

Additional examples of CVSSv3 scoring are available at the FIRST website: https://www.first.org/cvss.

In numerous instances, security vulnerabilities are not exploited in isolation. Threat actors often exploit more than one vulnerability “in a chain” to carry out attacks and compromise victims. By leveraging different vulnerabilities in a chain, attackers can infiltrate progressively further into the system or network and gain more control over it. Developers, security professionals, and users must be aware of this because chaining can change the order in which a vulnerability needs to be fixed or patched in the affected system. For instance, multiple low-severity vulnerabilities can become a severe one if they are combined.

Performing vulnerability chaining analysis is not a trivial task. Although several commercial companies claim that they can easily perform chaining analysis, in reality, the methods and procedures that can be included as part of a chain vulnerability analysis are nearly endless. Security teams should use an approach that works for them to achieve the best end result.

Exploits cannot exist without a vulnerability; however, there isn’t always an exploit for a given vulnerability. An exploit is a piece of software or a collection of reproducible steps that leverages a given vulnerability to compromise an affected system.

In some cases, users call vulnerabilities without exploits “theoretical vulnerabilities.” One of the biggest challenges with theoretical vulnerabilities is that there are many smart people out there who are capable of exploiting them. If you do not know how to exploit a vulnerability today, it does not mean that someone else will not find a way in the future. In fact, someone else may already have found a way to exploit the vulnerability and perhaps is even selling the exploit of the vulnerability in underground markets without public knowledge.

Cybersecurity professionals (including pen testers) should understand that there is no such thing as an “entirely theoretical” vulnerability. Sure, having a working exploit can ease the reproducible steps and help verify whether that same vulnerability is present in different systems. However, because an exploit might not come as part of a vulnerability, you should not completely deprioritize it.

One thing to keep in mind is that penetration testing engagements might not always guarantee the identification of every occurrence where a security control may be sufficient or insufficient. For example, if you find one buffer overflow vulnerability in a system or an application, it might not reveal all instances of this vulnerability in the environment. In many instances, if you find a vulnerability in one area, it may indicate weakness in process or development practices that may have replicated or enabled similar vulnerabilities in other areas of the organization. It is therefore important for your client or the organization that hired you to carefully investigate weak systems or applications that are the results of ineffective security controls when remediating and not to simply deploy “point fixes.”

You should help a client organization take the necessary steps to remediate any exploitable vulnerability within a reasonable period from the time that you originally find it. You can do this by clearly documenting the impact of the vulnerability, explaining any mitigations or workarounds, and providing a severity or prioritization score. You can also help with the scope of a follow-up test to verify the effective remediation of the vulnerabilities found. Similarly, you can offer a “knowledge transfer” session in which you teach the organization’s staff to find low-hanging-fruit vulnerabilities on their own. This allows them to incorporate such testing in their development or deployment practices.

Disclaimers

You might want to add disclaimers to your pre-engagement documentation, as well as in the final report. For example, you can specify that you conducted penetration testing on the applications and systems that existed as of a clearly stated date. Cybersecurity threats are always changing, and new vulnerabilities are discovered daily. No software, hardware, or technology is immune to security vulnerabilities, no matter how much security testing is conducted.

You should also specify that the penetration testing report is intended only to provide documentation and that your client will determine the best way to remediate any vulnerabilities. In addition, you should also include a disclaimer that your penetration testing report cannot and does not protect against personal or business loss as the result of use of the applications or systems described therein.

Another standard disclaimer is that you (or your organizations) provide no warranties, representations, or legal certifications concerning the applications or systems that were or will be tested. Your penetration testing report does not represent or warrant that the application tested is suitable to the task and free of other vulnerabilities or functional defects aside from those reported. In addition, it is standard to include a disclaimer stating that such systems are fully compliant with any industry standards or fully compatible with any operating system, hardware, or other application.

Of course, these are general ideas and best practices. You might also hire a lawyer to help create and customize your contracts, as needed.

Technical Constraints

During your pre-engagement tasks, you should identify testing constraints. Often you will be constrained by certain aspects of the business and the technology in the organization that hired you. The following are a few examples of constraints that you might face during a penetration testing engagement:

• Certain areas and technologies that cannot be tested due to operational limitations (For instance, you might not be able to launch specific SQL injection attacks, as doing so might corrupt a production database.)

• Technologies that might be specific for the organization being tested

• Limitation of skill sets

• Limitation of known exploits

• Systems that are categorized as out of scope because of the criticality or known performance problems

You should clearly communicate any technical constraints with the appropriate stakeholders of the organization that hired you prior to and during the testing.

Support Resources

There are several support resources that you might obtain from the organization that hired you to perform the penetration test. The following are some examples:

• Application programming interface (API) documentation: This includes documentation such as the following:

  • Simple Object Access Protocol (SOAP) project files: SOAP is an API standard that relies on XML and related schemas. XML-based specifications are governed by XML Schema Definition (XSD) documents. Having a good reference of what a specific API supports can be very beneficial for a penetration tester and will accelerate the testing. The SOAP specification can be accessed at https://www.w3.org/TR/soap.

  • Swagger (OpenAPI) documentation: Swagger is a modern framework of API documentation and development that is now the basis of the OpenAPI Specification (OAS). Swagger documents can be extremely beneficial when testing APIs. Additional information about Swagger can be obtained at https://swagger.io. The OAS is available at https://github.com/OAI/OpenAPI-Specification.

  • Web Services Description Language (WSDL) documents: WSDL is an XML-based language that is used to document the functionality of a web service. The WSDL specification can be accessed at https://www.w3.org/TR/wsdl20-primer.

  • GraphQL Documentation: GraphQL is a query language for APIs. It is also a server-side runtime for executing queries by using a type system you define for your data. Additional technical information about GraphQL can be accessed at https://graphql.org/learn.

  • Web Application Description Language (WADL) documents: WADL is an XML-based language for describing web applications. The WADL specification can be obtained from https://www.w3.org/Submission/wadl.

• Software development kit (SDK) for specific applications: An SDK, or devkit, is a collection of software development tools that can be used to interact and deploy a software framework, an operating system, or a hardware platform. SDKs can also help pen testers understand certain specialized applications and hardware platforms within the organization being tested.

• Source code access: Some organizations may allow you to obtain access to the source code of applications to be tested.

• Examples of application requests: In most cases, you will be able to reveal context by using web application testing tools such as proxies like the Burp Suite and the OWASP Zed Attack Proxy (ZAP). You will learn more about these tools in Chapter 6, “Exploiting Application-Based Vulnerabilities,” and Chapter 9, “Penetration Testing Tools.”

• System and network architectural diagrams: These documents can also be very beneficial for penetration testers, and they can also be used to document and define what systems are in scope during the testing.

Understanding the Legal Concepts of Penetration Testing

It goes without saying that you have to be very aware of the different legal concepts related to penetration testing. You have to be aware of local laws to ensure that none of the activities in a penetration test violate these laws. For example, if you collect packet captures or obtain information from a voice over IP (VoIP) system or voicemails during a penetration test, that action could be considered wiretapping in some countries.

In addition to local laws, you will be responsible for creating certain legal documents, such as contracts, statements of work (SOWs), master service agreements (MSAs), and non-disclosure agreements (NDAs).

Contracts

The contract is one of the most important documents in a pen testing engagement. It specifies the terms of the agreement and how you will get paid, and it provides clear documentation of the services that will be performed. The document should be very specific, easy to understand, and without ambiguities. Any ambiguities will likely lead to customer dissatisfaction and friction. Legal advice (from a lawyer) is always recommended for any contract.

Your customer might also engage its legal department or an outside agency to review the contract. A customer might specify and demand that any information collected or analyzed during the penetration testing engagement cannot be made available outside the country where you performed the test. In addition, the customer might specify that you (as the penetration tester) cannot remove personally identifiable information (PII) that might be subject to specific laws or regulations without first committing to be bound by those laws and regulations or without the written authorization of the company. Your customer will also review the penetration testing contract or agreement to make sure it does not permit more risk than it is intended to resolve.

Written Authorization

Another very important element of your contract and pre-engagement tasks is that you must obtain a signature from a proper signing authority for your contract. This includes the written authorization of the work to be performed. If necessary, you should also have written authorization from any third-party provider or business partner. This would include, for example, Internet service providers, cloud service providers, or any other external entity that could be considered to be impacted by or related to the penetration test to be performed.

SOW

The SOW is a document that specifies the activities to be performed during the penetration testing engagement. It can be used to define some of the following elements:

• Project (penetration testing) timelines, including the report delivery schedule

• The scope of the work to be performed

• The location of the work (geographic location or network location)

• Special technical and nontechnical requirements

• Payment schedule

• Miscellaneous items that may not be part of the main negotiation but that need to be listed and tracked because they could pose problems during the overall engagement

The SOW can be a standalone document or can also be part of an MSA.

MSA

Master service agreements (MSAs) are very popular today. MSAs are contracts that can be used to quickly negotiate the work to be performed. Having a “master agreement” means that the same terms do not have to be renegotiated every time you perform work for a customer. MSAs are beneficial when you perform a penetration test and you know that you will be rehired on a recurring basis to perform additional tests in other areas of the company or to verify that the security posture of the organization has been improved as a result of prior testing and remediation.

NDA

An NDA is a legal document and contract between you and an organization that has hired you as a penetration tester. An NDA specifies and defines confidential material, knowledge, and information that should not be disclosed and that should be kept confidential by both parties. NDAs can be classified as any of the following:

• Unilateral: With a unilateral NDA, only one party discloses certain information to the other party, and the information must be kept protected and not disclosed. For example, an organization that hires you should include in an NDA certain information that you should not disclose. Of course, all of your findings must be kept secret and not disclosed to any other organization or individual.

• Bilateral: A bilateral NDA is also referred to as a mutual, or two-way, NDA. In bilateral NDAs, both parties share sensitive information with each other, and this information should not be disclosed to any other entity.

• Multilateral: This type of NDA involves three or more parties, with at least one of the parties disclosing sensitive information that should not be disclosed to any entity outside the agreement. Multilateral NDAs are used in case an organization external to your customer (business partner, service provider, and so on) should also be engaged in the penetration testing engagement.

Export Restrictions

You should become aware of any export control restrictions that might be present in the country where a penetration test will be performed. For example, there might be tools, software, and hardware that cannot be exported outside the country (for example, certain cryptographic software or encryption technologies). For several years, more than 40 countries have been negotiating export controls under the Wassenaar Arrangement. The Wassenaar Arrangement was established for export control of conventional arms and dual-use goods and technologies. Specific security tools (software and hardware) could be considered “arms” and could be controlled and restricted by certain national laws in various countries.

Corporate Policies

Your customer might have specific corporate policies that need to be taken into consideration when performing a penetration test. In most cases, the customer will initially disclose any items in its corporate policy that might have a direct impact on the penetration testing engagement, but you should always ask and clearly document whether there are any. Some companies might also be under specific regulations requiring them to create vulnerability and penetration testing policies. These regulations might specify restricted and nonrestricted systems and information on how a penetration test should be conducted according to a regulatory standard.

Learning How to Scope a Penetration Testing Engagement Properly

Scoping is one of the most important elements of the pre-engagement tasks of any penetration testing engagement. You not only have to carefully identify and document all systems, applications, and networks that will be tested but also determine any specific requirements and qualifications needed to perform the test. The broader the scope of the penetration testing engagement, the more skills and requirements that will be needed.

Scope Creep

Scope creep is a project management term that refers to the uncontrolled growth of a project’s scope. It is also often referred to as kitchen sink syndrome, requirement creep, and function creep. Scope creep can put you out of business. Many security firms have suffered from scope creep and have been unsuccessful because they have had no idea how to identify when the problem has started or how to react to it. You might encounter scope creep in the following situations:

• When there is poor change management in the penetration testing engagement

• When there is ineffective identification of what technical and nontechnical elements will be required for the penetration test

• When there is poor communication among stakeholders, including your client and your own team

Scope creep does not always start as a bad situation. For example, if your client is satisfied with the work you are doing in your engagement, to the client might request that additional testing or technical work be performed. Change management and clear communication are crucial to avoid a very uncomfortable and bad situation.

If you initially engaged with your client after a request for proposal (RFP), and additional work is needed that was not part of the RFP or your initial SOW, you should ask for a new SOW to be signed and agreed upon.

Types of Assessment

There are a few different types of penetration testing and security assessments. Two of the major types are goals-based, or objectives-based, assessments and compliance-based assessments.

In a goals-based assessment, the company and the penetration tester agree on a specific goal or outcome. For example, a penetration tester might be hired to demonstrate how a threat actor could steal information from a specific system or application. It is important to make the scope very narrow and precise. Another example is that a penetration tester might be hired to perform a physical penetration assessment, along with social engineering limited to only one office location, and test the effectiveness of its physical security controls.

In a compliance-based assessment, the penetration tester is hired to verify and audit the security posture of the organization and to make sure the organization is compliant with specific regulations, such as the following:

• Payment Card Industry Data Security Standard (PCI DSS)

• Health Insurance Portability and Accountability Act of 1996 (HIPAA)

• Federal Risk and Authorization Management Program (FedRAMP)

Most of these regulations and specifications require the regulated company to hire third-party penetration testing firms to make sure they are compliant and to ensure that their security posture is acceptable.

Special Scoping Considerations

There might be company-specific scoping elements that you need to take into consideration. For example, you might have been hired to perform a penetration test of a company that is being acquired by the company that hired you, as part of the pre-merger process. For example, the acquiring company might ask the company that is being acquired to show whether a penetration testing has been conducted in the past year or the past six months. If not, the company being acquired might be required to hire a penetration testing firm to perform an assessment.

Many organizations are raising awareness about the need to better understand and reduce the security risks associated with the use of third-party software and the importance of supply-chain security. Numerous organizations now require penetration tests of hardware and software they are purchasing from a vendor prior to deploying them in their environment. In addition, many vendors hire full-time penetration testers to perform detailed security assessments of the products and services they sell as part of their security development life cycle (SDLC) programs. Each of these special engagements requires different skills and qualifications, depending on the technology and solutions being assessed.

Target Selection

During the scoping phase, the target selection process needs to be carefully completed with the company that hired you, or, if you are part of full-time red team, with the appropriate stakeholders in your organization. The organization might create a white list or a black list of applications, systems, or networks to be tested. A white list is a list of applications, systems, or networks that are in scope and should be tested. On the other hand, a black list is a list of applications, systems, or networks that are not in scope and should not be tested.

In certain circumstances, white and black lists also apply when configuring certain technical controls in the organization in preparation for a penetration test. In some cases, organizations might configure rules in their firewalls, intrusion prevention systems (IPSs), web application firewalls (WAFs), or network access control (NAC) systems to allow you as the penetration tester to carry out the penetration test without being blocked and without unnecessary alerts being triggered. In many cases, security controls are not changed in order for a penetration tester to demonstrate and find ways to bypass those security controls.

The scope and target lists might also include wireless service set identifiers (SSIDs) that will be part of the penetration test and those that will not. The target list can also include a list of users who will be within scope of the penetration test, for both a technical assessment and a social engineering engagement.

After the scope of the test is agreed upon between the penetration tester and the client or appropriate stakeholder, the penetration tester could do target discovery by performing active and passive reconnaissance. In Chapter 3, “Information Gathering and Vulnerability Identification,” you will learn how to perform information gathering and reconnaissance, how to conduct and analyze vulnerability scans, and how to leverage reconnaissance results to prepare for the exploitation phase.

Strategy

There are three major categories of penetration tests, based on knowledge about the target:

• Black-box testing: In this type of test, the penetration tester gets the absolute minimum information about the application, system, or network that he or she will be assessing.

• White-box testing: In this type of test, the penetration tester is given detailed information about the target. For example, the penetration tester may be given architectural diagrams, design documentation, or even the source code of applications running in the systems to be tested.

• Gray-box testing: In this type of test, the penetration tester is given some information about the target, but he or she needs to perform additional reconnaissance to be able to find security flaws, configuration errors, or vulnerabilities in the application, system, or network to be tested.

Risk Acceptance, Tolerance, and Management

A good cybersecurity governance program examines the organization’s environment, operations, culture, and threat landscape and compares them against industry-standard frameworks. It also aligns compliance to organizational risk tolerance and incorporates business processes. In addition, having good governance and appropriate tools enables you to measure progress against mandates and achieve compliance standards.

In order to have a strong cybersecurity program, you need to ensure that business objectives take into account risk tolerance and that the resulting policies are enforced and adopted. Governance includes many different types of policies. The following sections provide examples of the most relevant policies.

Risk tolerance is how much of an undesirable outcome a risk taker is willing to accept in exchange for the potential benefit. Inherently, risk is neither good nor bad. All human activity carries some risk, although the amount varies greatly. Consider this: Every time you get in a car, you are risking injury or even death. You manage the risk by keeping your car in good working order, wearing a seatbelt, obeying the rules of the road, avoiding texting while driving, driving only when not impaired, and paying attention. Your risk tolerance is that the reward for reaching your destination outweighs the potential harm.

Risk taking can be beneficial and is often necessary for advancement. For example, entrepreneurial risk taking can pay off in innovation and progress. Ceasing to take risks would quickly wipe out experimentation, innovation, challenge, excitement, and motivation. Risk taking can, however, be detrimental when it is influenced by ignorance, ideology, dysfunction, greed, or revenge. The key is to balance risk against rewards by making informed decisions and then managing the risk while keeping in mind organizational objectives. The process of managing risk requires organizations to assign risk management responsibilities, determine the organizational risk appetite and tolerance, adopt a standard methodology for assessing risk, respond to risk levels, and monitor risk on an ongoing basis.

Understanding Risk Management

Risk management is the process of determining an acceptable level of risk (risk appetite and tolerance), calculating the current level of risk (risk assessment), accepting the level of risk (risk acceptance), or taking steps to reduce risk to an acceptable level (risk mitigation). We discussed the first two components in the previous sections. The following sections discuss the others.

Risk Acceptance

Risk acceptance indicates that the organization is willing to accept the level of risk associated with a given activity or process. Generally, but not always, this means that the outcome of the risk assessment is within tolerance. There might be times when the risk level is not within tolerance, but the organization will still choose to accept the risk because all other alternatives are unacceptable. Exceptions should always be brought to the attention of management and authorized by either the executive management or the board of directors.

Risk Mitigation

Risk mitigation implies one of the following actions (or a combination of them):

• Risk reduction: Reducing the risk by implementing one or more countermeasures

• Risk sharing: Sharing the risk with another entity

• Risk transference: Transferring the risk to another entity

• Risk avoidance: Modifying or ceasing the risk-causing activity

• Risk monitoring: Continuously monitoring the overall cybersecurity risk

Risk reduction is accomplished by implementing one or more offensive or defensive controls in order to lower the residual risk. An offensive control is designed to reduce or eliminate vulnerability, such as enhanced training or applying a security patch. A defensive control is designed to respond to a threat source (for example, a sensor that sends an alert if an intruder is detected). Prior to implementation, risk reduction recommendations should be evaluated in terms of their effectiveness, resource requirements, complexity impact on productivity and performance, potential unintended consequences, and cost. Depending on the situation, risk reduction decisions can be made at the business unit level, by management, or by the board of directors.

Risk Transfer, Avoidance, and Sharing

Risk transfer or risk sharing is undertaken when an organization desires and has the means to shift risk liability and responsibility to other organizations. This is often accomplished by purchasing insurance.

Risk sharing means shifting a portion of risk responsibility or liability to other organizations. The caveat to this option is that regulations such as GLBA (governing financial institutions) and HIPAA/HITECH (governing healthcare organizations) prohibit covered entities from shifting compliance liability.

Risk avoidance might be the appropriate risk response when the identified risk exceeds the organizational risk appetite and tolerance, and a determination has been made not to make an exception. Risk avoidance involves taking specific actions to eliminate or significantly modify the process or activities that are the basis for the risk. It is unusual to see this strategy applied to critical systems and processes because both prior investment and opportunity costs need to be considered. However, this strategy may be very appropriate when evaluating new processes, products, services, activities, and relationships.

Risk Appetite and Tolerance

Risk appetite is defined by the ISO 31000 risk management standard as the “amount and type of risk that an organization is prepared to pursue, retain or take.” In other words, it specifies how much risk you are willing to accept within your organization. Risk tolerance is tactical and specific to the target being evaluated. Risk tolerance levels can be qualitative (for example, low, elevated, severe) or quantitative (for example, dollar loss, number of customers impacted, hours of downtime). It is the responsibility of the board of directors and executive management to establish risk tolerance criteria, set standards for acceptable levels of risk, and disseminate this information to decision makers throughout the organization.

There is no silver bullet for accepting and setting risk appetite; however, the method used should be owned by the board of directors executives and should reflect the collective informed views of the board. The risk appetite should be defined in measurable terms. Using subjective measures such as high, medium, and low is not a proper way of classifying such risk because these measures mean different things to different people. Risk appetite and tolerance should be articulated in terms of acceptable variance in the organization’s objectives (including its budget).

Learning the Key Aspects of Compliance-Based Assessments

As you learned earlier in this chapter, periodic penetration tests are required by several regulations in the industry. Several rules must be followed when completing compliance-based assessments. Some regulatory bodies provide checklists and guidance on how to perform security assessments and remain compliant.

Rules for Completing Compliance-Based Assessments

In order for you to become familiar with the rules related to completing a compliance-based assessment, you should become familiar with the some of the key underlying regulations.

Regulations in the Financial Sector

Financial services institutions such as banks, credit unions, and lending institutions provide an array of solutions and financial instruments. You might think that money is their most valuable asset, but in reality, customer and transactional information is the heart of their business. Financial assets are material and can be replaced. Protection of customer information is necessary to establish and maintain trust between a financial institution and the community it serves. More specifically, institutions have a responsibility to safeguard the privacy of individual consumers and protect them from harm, including fraud and identity theft. On a broader scale, the industry is responsible for maintaining the critical infrastructure of the nation’s financial services.

The following are a few examples of regulations applicable to the financial sector:

• Title V, Section 501(b) of the Gramm-Leach-Bliley Act (GLBA) and the corresponding interagency guidelines

• The Federal Financial Institutions Examination Council (FFIEC)

• The Federal Deposit Insurance Corporation (FDIC) Safeguards Act and Financial Institutions Letters (FILS)

• The New York Department of Financial Services Cybersecurity Regulation (NY DFS Cybersecurity Regulation; 23 NYCRR Part 500)

Compliance with some regulations, such as NYCRR and GLBA, is mandatory.

GLBA defines a financial institution as “any institution the business of which is significantly engaged in financial activities as described in Section 4(k) of the Bank Holding Company Act (12 U.S.C. § 1843(k).” GLBA applies to all financial services organizations, regardless of size. This definition is important to understand, because these financial institutions include many companies that are not traditionally considered to be financial institutions, including the following:

• Check-cashing businesses

• Payday lenders

• Mortgage brokers

• Nonbank lenders (for example, automobile dealers providing financial services)

• Technology vendors providing loans to their clients

• Educational institutions providing financial aid

• Debt collectors

• Real estate settlement service providers

• Personal property or real estate appraisers

• Retailers that issue branded credit cards

• Professional tax preparers

• Courier services

The law also applies to companies that receive information about customers of other financial institutions, including credit reporting agencies and ATM operators.

The Federal Trade Commission (FTC) is responsible for enforcing GLBA as it pertains to financial firms that are not covered by federal banking agencies, the Securities and Exchange Commission (SEC), the Commodity Futures Trading Commission (CFTC), and state insurance authorities, which include tax preparers, debt collectors, loan brokers, real estate appraisers, and nonbank mortgage lenders. GLBA mandates that financial organizations undergo periodic penetration testing in their infrastructure. Additional information about the GLBA can be obtained at https://www.ftc.gov/tips-advice/business-center/privacy-and-security/gramm-leach-bliley-act.

Another example is the NY DFS Cybersecurity Regulation. Section 500.05 of this regulation requires the covered entity to perform security penetration testing and vulnerability assessments on an ongoing basis. The cybersecurity program needs to include monitoring and testing, developed in accordance with the covered entity’s risk assessment, which is designed to assess the effectiveness of the covered entity’s cybersecurity program. The regulation dictates that “the monitoring and testing shall include continuous monitoring or periodic penetration testing and vulnerability assessments.” The organization must conduct an annual security penetration testing and a bi-annual vulnerability assessment. The NY DFS Cybersecurity Regulation can be accessed at http://www.dfs.ny.gov/legal/regulations/adoptions/dfsrf500txt.pdf.

Regulations in the Healthcare Sector

On February 20, 2003, the Security Standards for the Protection of Electronic Protected Health Information, known as the HIPAA Security Rule, was published. The Security Rule requires technical and nontechnical safeguards to protect electronic health information. The corresponding HIPAA Security Enforcement Final Rule was issued on February 16, 2006. Since then, the following legislation has modified and expanded the scope and requirements of the Security Rule:

• The 2009 Health Information Technology for Economic and Clinical Health Act (known as the HITECH Act)

• The 2009 Breach Notification Rule

• The 2013 Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules under the HITECH Act and the Genetic Information Nondiscrimination Act; Other Modifications to the HIPAA Rules (known as the Omnibus Rule)

The U.S. Department of Health and Human Services (HHS) has published additional cybersecurity guidance to help healthcare professionals defend against security vulnerabilities, ransomware, and modern cybersecurity threats. See https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity/index.html.

The HIPAA Security Rule focuses on safeguarding electronic protected health information (ePHI), which is defined as individually identifiable health information (IIHI) that is stored, processed, or transmitted electronically. The HIPAA Security Rule applies to covered entities and business associates. Covered entities include healthcare providers, health plans, healthcare clearinghouses, and certain business associates:

• A healthcare provider is defined as a person or an organization that provides patient or medical services, such as doctors, clinics, hospitals, outpatient services; counseling; nursing home and hospice services; pharmacy services; medical diagnostic and imaging services; and durable medical equipment.

• A health plan is defined as an entity that provides payment for medical services, such as health insurance companies, HMOs, government health plans, or government programs that pay for healthcare, such as Medicare, Medicaid, military, and veterans’ programs.

• A healthcare clearinghouse is defined as an entity that processes nonstandard health information it receives from another entity into a standard format.

• Business associates were initially defined as persons or organizations that perform certain functions or activities involving the use or disclosure of personal health information (PHI) on behalf of, or provide services to, a covered entity. Business associate services include legal, actuarial, accounting, consulting, data aggregation, management, administrative, accreditation, and financial services. Subsequent legislation expanded the definition of a business associate to a person or an entity that creates, receives, maintains, transmits, accesses, or has the potential to access PHI to perform certain functions or activities on behalf of a covered entity.

The U.S. Department of Health and Human Services has published HIPAA Security Rule guidance material at https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html.

Payment Card Industry Data Security Standard (PCI DSS)

In order to protect cardholders against misuse of their personal information and to minimize payment card channel losses, the major payment card brands (Visa, MasterCard, Discover, JCB International, and American Express) formed the Payment Card Industry Security Standards Council (PCI SSC) and developed the Payment Card Industry Data Security Standard (PCI DSS). The latest version of the standard and collateral documentation can be obtained at https://www.pcisecuritystandards.org.

PCI DSS must be adopted by any organization that transmits, processes, or stores payment card data or that directly or indirectly affects the security of cardholder data. Any organization that leverages a third party to manage cardholder data has the full responsibility of ensuring that this third party is compliant with PCI DSS. The payment card brands can levy fines and penalties against organizations that do not comply with the requirements and/or can revoke their authorization to accept payment cards.

Before we proceed with details about how to protect cardholder data and guidance on how to perform penetration testing in PCI environments, we must define several key terms that are used in this chapter and are defined by the PCI SSC at https://www.pcisecuritystandards.org/documents/PCI_DSS_Glossary_v3-2.pdf:

• Acquirer: Also referred to as an “acquiring bank” or an “acquiring financial institution,” An entity that initiates and maintains relationships with merchants for the acceptance of payment cards.

• ASV (approved scanning vendor): An organization approved by the PCI SSC to conduct external vulnerability scanning services.

• Merchant: For the purposes of PCI DSS, any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard, or Visa) as payment for goods and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly service.

• PAN (primary account number): A payment card number that is up to 19 digits long.

• Payment brand: Visa, MasterCard, Amex, Discover, or JCB.

• PCI forensic investigator (PFI): A person trained and certified to investigate and contain information cybersecurity incidents and breaches involving cardholder data.

• Qualified security assessor (QSA): An individual trained and certified to carry out PCI DSS compliance assessments.

• Service provider: A business entity that is not a payment brand and is directly involved in the processing, storage, or transmission of cardholder data. This includes companies that provide services that control or could impact the security of cardholder data, such as managed service providers that provide managed firewalls, intrusion detection and other services, and hosting providers and other entities. Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded.

To counter the potential for staggering losses, the payment card brands contractually require that all organizations that store, process, or transmit cardholder data and/or sensitive authentication data comply with PCI DSS. PCI DSS requirements apply to all system components where account data is stored, processed, or transmitted.

As shown in Table 2-3, account data consists of cardholder data as well as sensitive authentication data. A system component is any network component, server, or application that is included in, or connected to, the cardholder data environment. The cardholder data environment is defined as the people, processes, and technology that handle cardholder data or sensitive authentication data.

The PAN is the defining factor in the applicability of PCI DSS requirements. PCI DSS requirements apply if the PAN is stored, processed, or transmitted. If the PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply. If cardholder name, service code, and/or expiration date are stored, processed, or transmitted with the PAN or are otherwise present in the cardholder data environment, they too must be protected. Per the standards, the PAN must be stored in an unreadable (encrypted) format. Sensitive authentication data may never be stored post-authorization, even if encrypted.

The Luhn algorithm, or Luhn formula, is an industry algorithm used to validate different identification numbers, including credit card numbers, International Mobile Equipment Identity (IMEI) numbers, national provider identifier numbers in the United States, Canadian Social Insurance Numbers, and more. The Luhn algorithm, created by Hans Peter Luhn in 1954, is now in the public domain.

Most credit cards and many government organizations use the Luhn algorithm to validate numbers. The Luhn algorithm is based on the principle of modulo arithmetic and digital roots. It uses modulo-10 mathematics.

The following are the typical elements on the front of a credit card:

• Embedded microchip

• Primary account number (PAN)

• Expiration date

• Cardholder name

The microchip contains the same information as the magnetic stripe. Most non-U.S. cards have a microchip instead of a magnetic stripe. Some U.S. cards have both for international acceptance.

The following are the typical elements on the back of a credit card:

• Magnetic stripe (mag stripe): The magnetic stripe contains encoded data required to authenticate, authorize, and process transactions.

• CAV2/CID/CVC2/CVV2: All these abbreviations are names for card security codes for the different payment brands.

The PCI SSC provides great guidance on the requirements for penetration testing at https://www.pcisecuritystandards.org/document_library.

Key Technical Elements in Regulations You Should Consider

Most regulations dictate several key elements, and a penetration tester should pay attention to and verify them during assessment to make sure the organization is compliant:

• Data isolation (also known as network segmentation): Organizations that need to comply with PCI DSS (and other regulations, for that matter) should have a network isolation strategy. The goal is to implement a completely isolated network that includes all systems involved in payment card processing.

• Password management: Most regulations also mandate solid password management strategies. For example, organizations must not use vendor-supplied defaults for system passwords and security parameters. This requirement also extends far beyond its title and enters the realm of configuration management. In addition, most of these regulations mandate specific implementation standards, including password length, password complexity, and session timeout, as well as the use of multifactor authentication.

• Key management: This is another important element that is also evaluated and mandated by most regulations. A key is a value that specifies what part of the algorithm to apply and in what order, as well as what variables to input. Much as with authentication passwords, it is critical to use a strong key that cannot be discovered and to protect the key from unauthorized access. Protecting the key is generally referred to as key management. NIST SP 800-57: Recommendations for Key Management, Part 1: General (Revision 4) provides general guidance and best practices for the management of cryptographic keying material. Part 2: Best Practices for Key Management Organization provides guidance on policy and security planning requirements for U.S. government agencies. Part 3: Application Specific Key Management Guidance provides guidance when using the cryptographic features of current systems. In the Introduction to Part 1, NIST describes the importance of key management as follows:

The proper management of cryptographic keys is essential to the effective use of cryptography for security. Keys are analogous to the combination of a safe. If a safe combination is known to an adversary, the strongest safe provides no security against penetration. Similarly, poor key management may easily compromise strong algorithms. Ultimately, the security of information protected by cryptography directly depends on the strength of the keys, the effectiveness of mechanisms and protocols associated with keys, and the protection afforded to the keys. All keys need to be protected against modification, and secret and private keys need to be protected against unauthorized disclosure. Key management provides the foundation for the secure generation, storage, distribution, use, and destruction of keys.

Key management policy and standards should include assigned responsibility for key management, the nature of information to be protected, the classes of threats, the cryptographic protection mechanisms to be used, and the protection requirements for the key and associated processes.

Limitations When Performing Compliance-Based Assessments

There are several limitations that you will encounter when performing compliance-based penetration testing, including the following:

• Limited network access

• Limited storage access

Some regulations, such as PCI, include guidance on how to document some of the limitations that you may encounter in a penetration testing report, in the “Statement of Limitations” section. According to the PCI SSC, a penetration testing report should include a “Statement of Limitations” section that “documents any restrictions imposed on testing such as designated testing hours, bandwidth restrictions, special testing requirements for legacy systems, etc.”

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple choices for exam preparation: the exercises here, Chapter 11, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep software online.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topics icon in the outer margin of the page. Table 2-4 lists these key topics and the page number on which each is found.

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

rules of engagement

Common Vulnerability Scoring System (CVSS)

Simple Object Access Protocol (SOAP)

Swagger (OpenAPI)

Web Services Description Language (WSDL)

Web Application Description Language (WADL)

software development kit (SDK)

statement of work (SOW)

master service agreement (MSA)

non-disclosure agreement (NDA)

risk management

risk tolerance

risk transfer

risk appetite

Q&A

The answers to these questions appear in Appendix A. For more practice with exam format questions, use the Pearson Test Prep software online.

1. The HIPAA Security Rule is focused on __________________.

1. safeguarding electronic protected health information

2. safeguarding electronic payments and credit card information

3. safeguarding system configuration

4. none of the above

2. What is risk appetite?

1. A tactical way to accept risk tolerance and budget impact

2. The amount and type of insurance that an organization is prepared to obtain

3. The amount and type of risk that an organization is prepared to pursue, retain, or take

4. None of these answers are correct.

3. __________ indicates that the organization is willing to accept the level of risk associated with a given activity or process.

4. A ________-box test is a test in which the penetration tester is given some information about the target but not all information.

5. Which of the following is a group of cybersecurity experts and penetration testers that are hired by an organization to mimic a real threat actor?

1. Red team

2. Blue team

3. Purple team

4. CSIRT

6. Which of the following is a corporate security team that defends the organization against cybersecurity threats (such as the security operation center analysts, computer incident response teams [CSIRTs], and information security [InfoSec] teams)?

1. Red team

2. Blue team

3. Purple team

4. PSIRT

7. A penetration testing firm has not properly identified what technical and nontechnical elements will be required for a penetration test. The scope has increased, and the firm finds itself in a bad situation with a customer, as it may not have time to complete all the tests that were advertised. Which of the following terms best describes this situation?

1. Scope transit

2. Scope creep

3. Scope model

4. None of these answers are correct

8. Which of the following documents includes elements such as the scope of the work to be performed, the location of the work, and the payment schedule?

1. SOS

2. MSA

3. NDA

4. SOW

9. REST and SOAP are examples of ____________ standards and technologies.

1. API

2. Swagger

3. XML

4. JSON

10. You can create a document or include text in a contract, an SOW, or your final report specifying that you conducted the penetration testing on the applications and systems that existed as of a clearly stated date. This is an example of which of the following?

1. Addendum

2. Appendix

3. Disclaimer

4. Disclosure agreement