Chapter 02: Planning and Scoping Penetration Tests Flashcards
Scope
The first step in most pentesting engagements
This is where you determine what should be tested, what the pentesters will do, and how their time will be spent
Assessment Types
Goals-Based / Objective Based Assessments
* These are conducted for specific reasons, like the validation of a new security design, testing an app or service infrastructure before it enters production, or assessing the security of an org that was recently acquired
Compliance-Based Assessments
* Designed around the compliance objectives of a law, standard, or other guideline
* May require engaging a specific provider or assessor that’s certified to perform the assessment
Red-Team Assessments
* More targeted than normal pentests
* Attempts to act like an attacker, targeting sensitive data or systems with the goal of acquiring data and access
* Not intended to provide details of all the security flaws a target has, which leads to an incomplete picture of the flaws in the environment
* Useful as a security exercise to train IR or validate security designs and practices
Known and Unknown Environments
Known Environment
* AKA white box, crystal box, or full knowledge
* Performed with full knowledge of underlying tech, configurations, and settings that make up the target
* Testers typically have information like network diagrams, lists of systems and IP network ranges, and someimtes credentials to the system
* Allow effective testing without requiring time to identify targets and determine paths of entry
* Often more complete because testers can get every system, service, or target that’s in scope
* May not provide an accurate view of what an external attacker would see, and controls that would be effective against them can be bypassed
Unknown Environment
* AKA black box or zero knowledge
* Replicate what an attacker would encounter
* Testers get no access or information for the environment and must gather information, discover vulnerabilities, and make their way through an infrastructure or systems
* Time-consuming for pentesters but can reveal what vulnerabilities can be exploited by someone starting with nothing
* Provides a reasonably accurate asessment of how secure the target is against an attacker of similar or lesser skill
* Won’t provide a realistic view of an attacker’s capability if your pentesters have low quality work and skill sets
Partial Knowledge
* AKA gray box
* A blend of known and unknown environment testing
* May provide some information about the environment without giving pentesters full access, credentials, or config details
* Helps focus pentesters timea nd effort while also providing a more accurate view of what an attacker would encounter
Rules of Engagement (RoE)
The Timeline for Engagement and When Testing Can Be Conducted
* Includes the time of day, days of week, or days of month
* Sometimes intentionally scheduled for non-critical timeframes to minimize the impact of potential service outages
* Sometimes scheduled during business hours to help test the org’s reaction to attacks
* From the agreed upon duration, the pentesters outline each task and determines timeline for tasks to be completed—will phish emails be sent all at once or dripped out?
* Once timeline is set, it should include date and time each task begins, it’s est duration, description of task, and who’s responsible for the task
What Locations, Systems, Apps, or Other Potential Targets Are In-Scope
* Common targets include wireless networks, specific IP ranges, domains, org’s DNS, APIs, physical locations, and internal and external services and systems
* Targret list discussion also includes how third-party service providers may be impacted by the test, like ISPs, SaaS, and CSPs
Types of Tests That Are Allowed or Disallowed
* Common limitations include limiting potentially destructive tests, avoiding social engineering, avoiding physical pentesting
Data Handling Requirements for Information Gathered During the Pentest
* Particularly important when engagements cover sensitive data or systems
* EX: Pentests can’t legally expose PHI, even under an NDA
* Requirements for handling often include confidentiality requirements for findings like encrypting data during and after the test, and how to dispose of the data after the pentest
What Behaviors Are Expected From the Target
* Defensive behaviors like shunning, blocklisting, or other active defenses can limit a pentest
* If it’s meant to evaluate defenses, this can be helpful
* If it’s meant to test a complete infrastructure, this can waste time and rsources
What Resources Are Committed to the Test
* Time commitments from the admins, devs, or other experts are necessary for an effective test
Legal Concerns
* Address things like regulatory concerns affecting the target org, pentest team, tool restrictions due to laws, remote locations, and service providers in-scope
When and How Comms Will Occur
* Define whether you want daily or weekly updates on progress, or if pentesters will simply deliver a report when their work is done
Who to Contact In Case of Particular Events
* This includes evidence of ongoing compromise, accidental breach of RoE, discovery of critical vulnerabilities, and other events that warrant immediate attention
Who’s Permitted to Engage the Pentest Team
* EX: Can the CFO request an update?
* Include this in the RoE to avoid awkward denials
* Establish your trusted agent who will servce as the in-house staff member to communicate directly with the pentester team
What Boundaries Are Permitted
* Used to refer to whaty systems may be targeted or what techniques can be utilized during the test
DION NOTES:
* Always make sure clients understand your testing may cause damage to their systems, even though we try not to
* Written permission (get out of jail free card) is necessary
Deep Dive Scoping Considerations
Detailed scoping includes answering these questions:
* Are targets first-party hosted (internally) or third-party hosted (externally), and are they on or off-site?
* Are targets hosted by the org, third party, or IaaS (AWS) service provider?
* Are targets virtual, physical, hybrid? Does this impact the assessment?
* Are there specific environmental restrictions that need to be applied to the network, apps, or cloud systems and services?
* What apps, services, and supporting infrastructure is in scope?
* What accounts are in and out of scope?
* What SSIDs and IP ranges belong to the target and are valid?
* What are the rules against IaaS and cloud providers for your test?
* What’s the risk acceptance and company policies for the org?
* Will the org and sponsor be able to accept that a pentest could cause an outage or disrutpion?
* What’s the org’s impact tolerance?
* Is a complete outage acceptable as part of the test?
* What if an account lockout happens?
* Are there days that would be better to avoid disruption?
Page 40 and 41 for all the details
Scope Creep
The addition of more items and targets to the scope of the assessment
This is a constant danger for pentesters
You’re unlikely to know all the detals of what you may uncover, and during the assessment you might encounter unexpected new targets
Plan for this with the sponsor of the pentest and know how you’ll handle it
Documentation
The documentation that an org maintains to support its infrastructure and services can be incredibly useful to a pentester. This includes:
- Internal knowledgebase articles: Provides details to discover systems and services, and potentially perform more informated attacks
- Architectural, dataflow, and other system diagrams and documentation: Provides an understanding of potential targets, how they communicate, and other config and design details
- Confing Files: Treasure troves of information that may contain details including accounts, IPs, passwords, or API keys
- API documentation: Describes how software components communicate
- SDKs: Understanding which SDKs are in use and where helps test apps and servies
- Third-Party tools, system, and service documentation: May include examples like sample app requests, API examples, or code that can validate or improve a pentest (particularly useful for tests directed at web apps or APIs)
Access and Accounts
Known environment assessments will provide direct access to the systems that are being tested
This can include permitting pentesters past defense that are normally in place
Unknown environment teams won’t have that luxury and will have to make their way past defenses manually
Common exceptions for the known environment tests include:
* Adding testers to allow lists in IPS, WAF, and other security devices so they don’t get blocked
* Security exceptions at the network layer like allowing pentesters to bypass NAC that would normally prevent unauthorized devices from connecting to the network
* Bypassing or disabling certificate pinning
* User and privileged accounts
* Physical access to a facility or system
* Network access either on-site or with VPN
Page 43 for certificate pinning definition
Budget
Budget is determined by the scope and the RoE
This is an important consideration for any pentest and makes the difference between viable business and failed effort
Pentesting Standards and Methodologies
Methodology = the systemic approach a pentester uses before, during, and after a pentest, assessment, or engagement
MITRE ATT&CK
* Adversarial Tactics, Techniques, and Common Knowledge
* Knowledgebase of adversarial TTPs
* More useful for pentesters looking for a concept or practice vs building a complete pentesting process or program
OWASP
* Open Web App Security Project
* Provides testing guides for web security, mobile security, and firmware
* Has advice on how to use other testing methodologies and standards
PTES
* Penetration Testing Execution Standard
* Ranges from pre-engagement interactions to details for how to deal with third parties
* Pre-engagement interactions –> intelligence gathering –> threat modeling –> vulnerability analysis –> exploitation –> post exploitaton –> reporting
* Includes a full range of pentesting techniques and concepts
* One of the most complete and modern openly available pentesting standard
OSSTMM
* Open Source Security Testing Methodology Manual
* Broad pentesting methodology with information about analysis, metrics, workflows, human security, physical security, and wireless security
* The real focus is auditing, validation, and verification using facts and not opinions
* Outdated (2010)
NIST
* National Institute of Standards and Technolgoy
* Provides standards for pentesting as part of NIST SP800-115
* Not modernized but influences pentesting still
* Plan –> Discover –> Attack –> Report
ISSAF
* Information Systems Security Assessment Framework
* Developed by OSSIG (Open Information Systems Security Group)
* Highly detailed pentesting framework but hasn’t been updated since 2005, with no active downloads for the standard
Legal Contracts
SOW (Statement of Work)
* Defines the purpose of work, what will be done, what deliverables will be created, timeline for work to be completed, price of the work, etc
SOO (Statement of Objectives) and PWS (Performance Work Statement)
* Alt to SOW, used by US Government
MSA (Master Service Agreement)
* Defines the terms the org will use for future work, makes ongoing SOW easier and prevents need to renegotiate
* Governs the future transactions and agreements
* EX: MSA might state pentester has to be bonded and insured for up to $$$$ amount, or payment received information, etc
* EX: States pricing and expectations for future agreements, like a quarterly PCI-DSS compliance test (speeds up contract process)
NDA (Nondisclosure Agreement) and CA (Confidentiality Agreement)
* Legal documents to enforce confidential relationships between two parties
* Companies ask pentesters to sign NDA, but pentesters should also ask companies / clients to sign an NDA so they don’t release proprietary techniques, way we conducted assessment, or the reports (this is all IP for pentester)
* I’ll keep your secrets, you keep mine
SLA (Servive Level Agreement)
* Set expectations for services, including things like availability, reliability, and quality of service
* Commitment between pentester and client
* Metrics, duties and responsibilities, penalities for breach of SLA, etc
Noncompete Agreement
* Asks you to agree to not take a job with a competitor or to directly compete with your employer in a future job
Data Ownership and Retention
Ownership of the data should be set in the MSA or SOW for each engagement
Clear expectations for who owns the data, how it’ll be store and secured, and what will be done with it once the engagement is finished
Permission to Attack (Authorization)
Required permission for a pentest to take place
Additional authorization may be needed for pentests that deal with complex IT infrastructure as third-parties are often used to host systems (SaaS, PaaS, IaaS, CSPs)
Always determine what third-party providers or partners are in scope and obtain authorization from them
Environmental Differences and Location Restrictions
Pentesting laws vary around the world, and even in the US
Understand where you’re operating, where your targets are, and how jurisdictions apply to you
Page 48 for more
PCI-DSS
Payment Card Industry Data Security Standard
* Rules to complete assessments for credit card processing environments and systems are set by the copliance standard
* An agreement that any org which collects, stores, or processess credit card customer information must abide by
* PCI DSS provides what is required for compliance, including its definition of what a Cardholder Data Environment (CDE) pentest should include
To protect cardholder data, an org must:
1. Create and maintain a secure infrastructure using dedicated appliances and software to monitor and prevent attacks
2. Employ best practices, like changing default passwords and training users not to fall victim to phishing
3. Continuously monitor for vulneabilities and use updated antimalware protections
4. Provide strong access control mechanisms and utilize the principal of least privilege
