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
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 time and 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 approach a pentester uses before, during, and after a pentest
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
GDPR
General Data Protection Regulation
* A European Union regulation that protects data and privacy
* Places specific requirements on how consumer data of the residents of the EU and Britain must be protected
* Personal data can’t be collected, processes, or retained without informed consent
* User has right to be forgotten—you can ask the comapny to scrub all your data from the database
* GDPR applies globally to all companies doing business with citizens of the EU and Britain
* Pentesters need to be aware of GDPR handling requirements if they obtain or access data during pentests
Three Major Factors for Pentests
Time, Cost, and Quality
They are always in competition with one another, and decisions on their priority always need to be agreed upon by the pentester and the org contracting the engagement
If you want it faster, it will cost you more money or it will reduce the quality threshold
If you want in-depth, it might cost more or take much longer
Planning Considerations
Target audience
* Are you planning a pentest for a small mom and pop shop that just need a simple PCI-DSS compliance test?
* Or is this for a multinational financial institution that needs all of their 100 branches tested?
* This changes scope of test due to sizes, operations, missions, etc
Objective
* Is the org contracting the pentest to meet compliance regulation?
* Are they doing due diligence before something is released?
Compliance
* Part of a compliance based assessment?
* If so, you have to use resources like the PCI-DSS checklist to verify compliance
Resources
* What do you need to complete the pentest?
* Resources beyond tech, like flying teams to be on-site or hire contractors etc
* What’s the cost associated with those resources?
Comms plan
* Who can pentester communicate with, and how often will that communication occur?
* Can you only speak to CTO, or whole IT department?
Product and report
* What will pentester supply at the end of the test, like powerpoint, paper, etc?
Technical constraints
* Are there any constraints?
* Can you test their databases, printers, ICS and SCADA systems, etc?
Comprehensiveness
* Are you going to look for all vulns?
* Or just looking for one way to break into the network?
* Impacts size, scope, duration, and resources required
DION NOTE: Be clear that this is a snapshot, or point-in-time assessment, and you’re only held liable for disclosing the vulnerabilities that exist at the time of the assessment
Regulatory Terms
HIPAA
* Affects healthcare providers, facilities, insurance companies, and medical data clearing houses
* PHI is relevant and keyword here
Health Care and Education Reconciliation Act of 2010
* Affects both healthcare and educational orgs
SOX
* Sarbanes-Oxley
* Affects publicly traded US corporations
GLBA
* Gramm-Leach-Bliley Act of 1999
* Affects banks, mortgage companies, loan offices, insurance companies, investment companies, and credit card providers
FISMA
* Federal Information Security Management Act of 2002
* Affects federal agencies
FERPA
* Family Educational Rights and Privacy Act
* Protects the privacy of student education records
Economic Espionage Act of 1996
* Affects orgs with trade secrets and anyone who tries to use encryption for criminal activities
COPPA
* Children’s Online Privacy Protection Act
* Imposes certain requirements on websites owner and online services that are direct to children under 13 years of age
Adversary Emulation
A specialized type of pentest that involves trying to mimic the TTPs of a real-world threat actor
Target Selection
You have to determine who your targets are, generally speaking, during the planning and scoping phase
Internal Target
* Inside the org’s firewall and requires testers to be on-site, gain access through a VPN, or exploit a user’s computer inside the organizational network
First and Third Party Hosted Assets
* Are the targets provided in the SOW hosted by the org in their own datacenter? Or will they be hosted in the cloud?
* Pentesters must be informed if they’re allowed to attack specific assets
Physical
* Is a physical assessment in-scope? Or will you only be conducting a technical assessment?
* If you’re doing physical, determine which specific locations are coverd by the scope of the test
On vs Off Site
* If you don’t know on-site you’re retarded
* Off-site could include satellite office networks, or even employee-owned devices at their homes
* Determine scope here to know where you can hit
Users
* Can you use social engineering against users?
* Can you phish them?
* Can you trick them to get you into the building?
WiFi
* Which SSID are in-scope? This is crucial
* Negotiate which network is included and which is excluded like guest network, main network, POS network, etc
IPs, Domains, Subdomains, DNS
* ASNs define a group of one or more IP prefixes run by one or more network operators that maintain a single, clearly-defined routing policy
* Maybe main domain is in-scope, but support portal is not—define, define, define this all in the scope talks
* Can you target or modify their DNS records? Watering hole, DNS poisoning, zone transfers?
Web Apps and APIs
* Web apps and their associated APIs could be used for either public-facing apps or only be used internally for the org
* What parts of all of this are in-scope? SKDs, underlying code, source code, etc?
* Is there a particular app on the system that’s mission-critical and can’t afford downtime? Patient care portals or POS systems, etc
Identifying Restrictions
Aside from the risk appetite and tolerance of an org, you have to determine other things like:
* The operational impact if things go wrong, like a server going offline during the test
* Schedule and timing, like how long pentester will be conducting the test, or if IT managers are aware of when the attack will occur
* Scope Creep: you know this from work
Wassenaar Arrangement
Outlaws the exportation of a technology that can be used both in a regular commercial setting and as a weapon
EX: encryption
This is a dual use technology that falls under the Arrangement, and you have to know what locations / countries you’re allowed to use this in
EX: Wireshark
Can decrypt encryption protocols, etc
Types of Assessments / Tests
Goals-Based
* A type of assessment with a specific goal in mind
* A pentester may find as many ways as possible to achieve that specific goal—it doesn’t matter how, as long as they’re successful
Objective-Based Assessment
* A type of assessment where the tester seeks to ensure that the information remains secure
* If information is on a file server, you can steal the HD, hack the server, phish employees, etc
* It doesn’t matter how, just as long as you ensure that information is safe from attack
* This closely emulates a real attack
Compliance-Based Assessment
* A type of assessment that focuses on finding out if policies and regulations are being properly followed
* One of the most common types of pentests
* If they take credit cards, they have to follow PCI-DSS
* Objectives are clearly defined and pentester can use a checklist to ensure everything is completed
* GDRP, HIPAA, SOX, GLBW
Pre-Merger Assessment
* A type of assessment that’s conducted before two companies merge with each other during due diligence
* Determines if the merger will weaken either one of the security posture’s for either organization
Supply Chain Assessment
* A type of assessment that occurs when a company requires its suppliers to ensure that they meet a given level of cybersecurity requirements before you do business with them
* Must get permission from the owner of the network, even if your client is not the owner but is paying
Red Team Assessment
* Execution of a pentest against the org network by its own internal pentesters, aka the red team
