Penetration Testing Guidance

Transcription

1 Standard: PCI Data Security Standard (PCI DSS) Versin: 1.0 Date: March 2015 Authr: Penetratin Test Guidance Special Interest Grup PCI Security Standards Cuncil Infrmatin Supplement: Penetratin Testing Guidance

2 Table f Cntents 1 Intrductin Objective Intended Audience Terminlgy Navigating this Dcument Penetratin Testing Cmpnents Hw des a penetratin test differ frm a vulnerability scan? Scpe Critical Systems Applicatin-Layer and Netwrk-Layer Testing Authenticatin PA-DSS Cmpliant Applicatins Web Applicatins Separate Testing Envirnment Segmentatin Checks Scial Engineering What is cnsidered a significant change? Qualificatins f a Penetratin Tester Certificatins Past Experience Methdlgy Pre-Engagement Scping Dcumentatin Rules f Engagement Third-Party-Hsted / Clud Envirnments Success Criteria Review f Past Threats and Vulnerabilities Avid scan interference n security appliances Engagement: Penetratin Testing Applicatin Layer Netwrk Layer Segmentatin What t d when cardhlder data is encuntered Pst-Explitatin Pst-Engagement Remediatin Best Practices Retesting Identified Vulnerabilities Cleaning up the Envirnment Additinal Resurces Reprting and Dcumentatin Identified Vulnerability Reprting Assigning a Severity Scre Industry Standard References Reprting Guidelines Penetratin Test Reprt Outline Retesting Cnsideratins and Reprt Outline ii

3 5.3 Evidence retentin What is cnsidered evidence? Retentin Penetratin Test Reprt Evaluatin Tl Case Studies / Scping Examples E-cmmerce Penetratin Test Case Study Hsting Prvider Penetratin Test Case Study Retail Merchant Penetratin Test Case Study Appendix A: Quick-Reference Table t Guidance n PCI DSS Penetratin Testing Requirements Acknwledgements Abut the PCI Security Standards Cuncil iii

4 1 Intrductin 1.1 Objective The bjective f this infrmatin supplement is t update and replace PCI SSC s riginal penetratin testing infrmatin supplement titled Payment Card Industry Data Security Standard (PCI DSS) Requirement 11.3 Penetratin Testing published in This infrmatin supplement has additinal guidance t what is in PCI DSS and is written as general penetratin testing guidelines that are intended t extend int future versins f PCI DSS. The guidance fcuses n the fllwing: Penetratin Testing Cmpnents: Understanding f the different cmpnents that make up a penetratin test and hw this differs frm a vulnerability scan including scpe, applicatin and netwrklayer testing, segmentatin checks, and scial engineering. Qualificatins f a Penetratin Tester: Determining the qualificatins f a penetratin tester, whether internal r external, thrugh their past experience and certificatins. Penetratin Testing Methdlgies: Detailed infrmatin related t the three primary parts f a penetratin test: pre-engagement, engagement, and pst-engagement. Penetratin Testing Reprting Guidelines: Guidance fr develping a cmprehensive penetratin test reprt that includes the necessary infrmatin t dcument the test as well as a checklist that can be used by the rganizatin r the assessr t verify whether the necessary cntent is included. The infrmatin in this dcument is intended as supplemental guidance and des nt supersede, replace, r extend PCI DSS requirements. While all references made in this dcument are t PCI DSS versin 3.0, the general principles and practices ffered here may be applied t any versin f PCI DSS. 1.2 Intended Audience This guidance is intended fr entities that are required t cnduct a penetratin test whether they use an internal r external resurce. In additin, this dcument is intended fr cmpanies that specialize in ffering penetratin test services, and fr assessrs wh help scpe penetratin tests and review final test reprts. The guidance is applicable t rganizatins f all sizes, budgets, and industries. 1

5 1.3 Terminlgy The fllwing terms are used thrughut this dcument: Penetratin tester, tester, r team: The individual(s) cnducting the penetratin test fr the entity. They may be a resurce internal r external t the entity. Applicatin-layer testing: Testing that typically includes websites, web applicatins, thick clients, r ther applicatins. Netwrk-layer testing: Testing that typically includes external/internal testing f netwrks (LANS/VLANS), between intercnnected systems, wireless netwrks, and scial engineering. White-bx testing: Testing perfrmed with knwledge f the internal structure/design/implementatin f the bject being tested. Grey-bx testing: Testing perfrmed with partial knwledge f the internal structure/design/implementatin f the bject being tested. Black-bx testing: Testing perfrmed withut prir knwledge f the internal structure/design/implementatin f the bject being tested. Natinal Vulnerability Database (NVD): The U.S. gvernment repsitry f standards based vulnerability management data. This data enables autmatin f vulnerability management, security measurement, and cmpliance (e.g., FISMA). Cmmn Vulnerability Scring System (CVSS): Prvides an pen framewrk fr cmmunicating the characteristics and impacts f IT vulnerabilities. 1.4 Navigating this Dcument This dcument is rganized in such a way t help the reader better understand penetratin testing in a hlistic sense. It begins by prviding backgrund and definitins fr tpics cmmn t all penetratin test effrts (including scping the test, critical systems t test, applicatin and netwrk-layer test inclusins, etc.). The dcument then mves n t practical guidance n selecting a penetratin tester, methdlgies that are used befre, during, and after a test, guidelines fr reprting and evaluating test results. The dcument cncludes with case studies that attempt t illustrate the cncepts presented in this supplement. Appendix A prvides a quick-reference table t specific sectins f this dcument where guidance n a particular PCI DSS requirement can be fund. This may be useful fr thse wishing t quickly crrelate the penetratin testing requirements and guidelines presented in PCI DSS Requirement

6 2 Penetratin Testing Cmpnents The gals f penetratin testing are: 1. T determine whether and hw a malicius user can gain unauthrized access t assets that affect the fundamental security f the system, files, lgs and/r cardhlder data. 2. T cnfirm that the applicable cntrls, such as scpe, vulnerability management, methdlgy, and segmentatin, required in PCI DSS are in place. There are three types f penetratin tests: black-bx, white-bx, and grey-bx. In a black-bx assessment, the client prvides n infrmatin prir t the start f testing. In a white-bx assessment, the entity may prvide the penetratin tester with full and cmplete details f the netwrk and applicatins. Fr grey-bx assessments, the entity may prvide partial details f the target systems. PCI DSS penetratin tests are typically perfrmed as either white-bx r grey-bx assessments. These types f assessments yield mre accurate results and prvide a mre cmprehensive test f the security psture f the envirnment than a pure black-bx assessment. Black-bx assessments ffer very little in the way f value fr PCI DSS penetratin tests, since the entity prvides n details f the target systems prir t the start f the test, the test may require mre time, mney, and resurces t perfrm. 2.1 Hw des a penetratin test differ frm a vulnerability scan? The differences between penetratin testing and vulnerability scanning, as required by PCI DSS, still causes cnfusin within the industry. The differences can be summarized as fllws: Purpse When Hw Vulnerability Scan Identify, rank, and reprt vulnerabilities that, if explited, may result in an intentinal r unintentinal cmprmise f a system. At least quarterly r after significant changes. Typically a variety f autmated tls cmbined with manual verificatin f identified issues. Penetratin Test Identify ways t explit vulnerabilities t circumvent r defeat the security features f system cmpnents. At least annually and upn significant changes. (Refer t Sectin 2.6 f this dcument fr infrmatin n significant changes.) A manual prcess that may include the use f vulnerability scanning r ther autmated tls, resulting in a cmprehensive reprt. 3

7 Reprts Duratin Vulnerability Scan Ptential risks psed by knwn vulnerabilities, ranked in accrdance with NVD/CVSS base scres assciated with each vulnerability. Nte that external vulnerability scans must be perfrmed by an ASV and the risks ranked in accrdance with the CVSS. Internal vulnerability scans may be perfrmed by qualified persnnel (des nt require an ASV) and risks ranked in accrdance with the rganizatin s risk-ranking prcess as defined in PCI DSS Requirement 6.1. An external vulnerability scan is cnducted frm utside the target rganizatin. An internal vulnerability scan is cnducted frm inside the target rganizatin. Relatively shrt amunt f time, typically several secnds t several minutes per scanned hst. Penetratin Test Descriptin f each vulnerability verified and/r ptential issue discvered. Mre specific risks that vulnerability may pse, including specific methds hw and t what extent it may be explited. Examples f vulnerabilities include but are nt limited t SQL injectin, privilege escalatin, crss-site scripting, r deprecated prtcls. Engagements may last days r weeks depending n the scpe f the test and size f the envirnment t be tested. Tests may grw in time and cmplexity if effrts uncver additinal scpe. 2.2 Scpe PCI DSS defines the cardhlder data envirnment (CDE) as the peple, prcesses, and technlgy that stre, prcess, r transmit cardhlder data r sensitive authenticatin data. The scpe f a penetratin test, as defined in PCI DSS Requirement 11.3, must include the entire CDE perimeter and any critical systems that may impact the security f the CDE as well as the envirnment in scpe fr PCI DSS. This includes bth the external perimeter (public-facing attack surfaces) and the internal perimeter f the CDE (LAN-LAN attack surfaces). Guidance n penetratin test scping is as fllws: The scpe f an external penetratin test is the expsed external perimeter f the CDE and critical systems cnnected r accessible t public netwrk infrastructures. It shuld assess any unique access t the scpe frm the public netwrks, including services that have access restricted t individual external IP addresses. Testing must include bth applicatin-layer and netwrk-layer assessments. External penetratin tests als include remte access vectrs such as dial-up and VPN cnnectins. 4

8 The scpe f the internal penetratin test is the internal perimeter f the CDE frm the perspective f any ut-f-scpe LAN segment that has access t a unique type f attack n the CDE perimeter. Critical systems r thse systems that may impact the security f the CDE shuld als be included in the scpe. Testing must include bth applicatin-layer and netwrk-layer assessments. If segmentatin cntrls have been implemented t separate envirnments, segmentatin checks shuld be perfrmed frm any nn-cde envirnment that is intended t be cmpletely segmented frm the CDE perimeter. The intent f this assessment is t validate the effectiveness f the segmentatin cntrls separating the nn-cde envirnments frm the CDE and ensure the cntrls are peratinal. T be cnsidered ut f scpe fr PCI DSS, a system cmpnent must be islated (segmented) frm the CDE, such that even if the ut-f-scpe system cmpnent was cmprmised it culd nt impact the security f the CDE. Therefre, the penetratin test may include systems nt directly related t the prcessing, transmissin r strage f cardhlder data t ensure these assets, if cmprmised, culd nt impact the security f the CDE. It is nt a requirement t test frm within the CDE t the servers inside the CDE; and testing exclusively frm within the CDE perimeter will nt satisfy the requirement. Hwever, when access t the CDE is btained as a result f the testing, the penetratin tester may elect t cntinue explring inside the netwrk and further the attack against ther systems within the CDE, and may als include testing any data-exfiltratin preventin (data-lss preventin) cntrls that are in place. Testing may include lcatins f cardhlder data, applicatins that stre, prcess, r transmit cardhlder data, critical netwrk cnnectins, access pints, and ther targets apprpriate fr the cmplexity and size f the rganizatin. This shuld include resurces and assets (i.e., any resurce r asset that allws an attacker t btain the credentials with access t r a rute int the CDE) utilized by users respnsible fr maintaining the systems that stre, prcess, r transmit cardhlder data r by users with the ability and authrity t access cardhlder data. This testing shuld nly be cnducted as defined by the rules f engagement. See Sectin 4.1.3, Rules f Engagement Critical Systems The term critical systems is used in the PCI DSS t reference systems that are invlved in the prcessing r prtectin f cardhlder data. PCI DSS prvides examples f critical systems that may be impacted by identified vulnerabilities including security systems, public-facing devices and systems, databases, and ther systems that stre, prcess, r transmit cardhlder data (Requirement 6.1). Hwever, fr the purpses f a penetratin test, there may be additinal systems utside the CDE bundaries that culd affect the security f the CDE. These systems shuld als be cnsidered t be critical systems. Cmmn examples f critical systems relevant t a penetratin test might include: security systems (fr example, firewalls, intrusin-detectin systems/intrusin-preventin systems (IDS/IPS), authenticatin servers, e-cmmerce redirectin servers, etc.), r any assets utilized by privileged users t supprt and manage the CDE. Please nte that critical systems are defined by the entity, as each envirnment is different. 5

9 2.3 Applicatin-Layer and Netwrk-Layer Testing Any sftware written by r specifically fr the rganizatin that is part f the penetratin test scpe shuld be subject t bth an applicatin and netwrk-layer penetratin test. This assessment helps identify security defects that result frm either insecure applicatin design r cnfiguratin, r frm emplying insecure cding practices r security defects that may result frm insecure implementatin, cnfiguratin, usage, r maintenance f sftware. The remediatin f vulnerabilities identified during an applicatin-layer assessment may invlve redesigning r rewriting insecure cde. The remediatin f vulnerabilities identified during a netwrk-layer assessment typically invlves either recnfiguring r updating sftware. In sme instances, remediatin may include deplying a secure alternative t insecure sftware Authenticatin If the applicatin requires user authenticatin t the custm sftware, testing shuld be perfrmed against all rles r types f access assumed by these parties. Als, testing shuld be perfrmed against any rle r access type that des nt have explicit authrizatin t cardhlder data t verify accunts withut access cannt cmprmise such data. Fr custmers running applicatins n multitenant servers that prvide custmers access t their cardhlder data, authenticated testing shuld be perfrmed t ensure custmer access is prperly restricted t nly their wn cardhlder data. The custmer shuld prvide the penetratin tester with credentials that have equivalent permissin(s) as a custmer user, t allw the penetratin tester t determine whether thse credentials allw access t data beynd the entity s data PA-DSS Cmpliant Applicatins If a payment applicatin has been PA-DSS validated, the applicatin s functinality des nt need t be tested as part f the entity s PCI DSS cmpliance validatin. Hwever, the implementatin f the applicatin des need t be tested. This includes bth the perating system and any expsed services, but nt the payment applicatin s functinality (e.g., authenticatin, key management, transactin prcessing, etc.) since this was validated as part f the PA-DSS applicatin validatin Web Applicatins It is cmmn fr an envirnment t hst a web applicatin that was nt specifically cded fr the rganizatin such as cmmercial, ff-the-shelf web-mail interfaces, dcument-sharing tls, file-transfer services, netwrk-device administrative interfaces, etc. In these instances, the web applicatin des nt typically need an applicatin-layer penetratin test as the entity is nt respnsible fr the surce cde f this type f sftware. Instead, the tester shuld perfrm a netwrk-layer test and ensure the sftware was implemented, cnfigured, and is currently being maintained in a secure manner (disabling r uninstalling unused services, blcking unused prts, applying current updates, etc.). 6

10 2.3.4 Separate Testing Envirnment Because f the nature and the intent f penetratin testing, such testing in a prductin envirnment during nrmal business hurs may impact business peratins, and attempts t avid disruptin may increase the time, resurces and cmplexity f the testing. This is especially imprtant fr high availability systems that may be impacted by penetratin testing in a prductin envirnment. T avid disruptins and t speed up testing, a separate envirnment that is identical t the prductin envirnment may be used fr testing instead f the prductin envirnment. The penetratin tester wuld need t ensure the same applicatin and netwrk-layer cntrls as prductin exist in the testing envirnment. This may be accmplished thrugh methds t map ut the prductin envirnment t verify it matches the testing envirnment. This shuld be included in the rules f engagement. All explitable vulnerabilities identified during the testing must be crrected n prductin systems and testing repeated t verify that security weaknesses have been addressed. 2.4 Segmentatin Checks PCI DSS Requirement requires penetratin testing t validate that segmentatin cntrls and methds are peratinal, effective, and islate all ut-f-scpe systems frm systems in the CDE. Therefre, a rbust apprach t penetratin testing is recmmended t satisfy this requirement by actively attempting t identify rutes and paths frm netwrks utside the CDE int the CDE. All segmentatin methds need t be specifically tested. In very large netwrks, with numerus internal LAN segments, it may be infeasible fr the penetratin tester t cnduct specific tests frm every individual LAN segment. In this case, the testing needs t be planned t examine each type f segmentatin methdlgy in use (i.e., firewall, VLAN ACL, etc.) in rder t validate the effectiveness f the segmentatin cntrls. The level f testing fr each segmentatin methdlgy shuld prvide assurance that the methdlgy is effective in all instances f use. In rder t effectively validate the segmentatin methdlgies, it is expected that the penetratin tester has wrked with the rganizatin (r the rganizatin s QSA) t clearly understand all methdlgies in use in rder t prvide cmplete cverage when testing. The penetratin tester may chse t include systems lcated in these islated LAN segments nt directly related t the prcessing, transmissin, r strage f cardhlder data t ensure these systems culd nt impact the security f the CDE if cmprmised. See Sectin fr specific guidance n testing methdlgies fr validating segmentatin cntrls. 2.5 Scial Engineering Scial engineering is the attempt t gain infrmatin, access, r intrduce unauthrized sftware int the envirnment thrugh the manipulatin f end users. PCI DSS v3.0 recnfirms testing by requiring industry accepted penetratin testing appraches (many f which include scial engineering as part f their apprach) and t have an apprach t penetratin testing that "cnsiders the threats and vulnerabilities experienced by merchants in the last 12 mnths." This may include scial-engineering attacks as a methd used fr intrducing malware int the envirnment. 7

11 Scial-engineering tests are an effective methd f identifying risks assciated with end users failure t fllw dcumented plicies and prcedures. There is n blanket apprach t scial-engineering engagements. If an rganizatin chses t include scial-engineering testing as part f its annual security review, the tests perfrmed shuld be apprpriate fr the size and cmplexity f the rganizatin and shuld cnsider the maturity f the rganizatin s security awareness prgram. These tests might include in-persn, nn-technlgical interactins such as persuading smene t hld pen a dr, remte interactins such as having smene prvide r reset a passwrd, r cnvincing the end user t pen a vulnerable attachment r hyperlink. While PCI DSS des nt require use f scial-engineering techniques, an entity can incrprate it int its penetratin testing methdlgy as an nging methd t determine t determine the effectiveness f the security awareness prgram. The frequency f scial-engineering tests wuld be determined by the entity when establishing its security awareness prgram. End-user security awareness re-educatin might be sufficient remediatin fr users wh fail a scial-engineering test. The bjective is that, ver time, fewer and fewer emplyees are making pr decisins that culd allw an attacker t cmprmise security. Additinal infrmatin n establishing an effective and rbust security awareness prgram can be fund under the tab Fact Sheets and Inf Sups n the PCI SSC website. Scial-engineering testing may nt be apprpriate r prvide a meaningful result fr all rganizatins. Althugh scial-engineering testing is nt a requirement f PCI DSS, an rganizatin may cnsider dcumenting the reasn(s) fr freging scial-engineering testing and include applicable dcumentatin with the internal and external penetratin test reprts, particularly if scial-engineering attacks were encuntered in the last 12 mnths. 2.6 What is cnsidered a significant change? Per PCI DSS Requirements and , penetratin testing must be perfrmed at least annually and after any significant change fr example, infrastructure r applicatin upgrade r mdificatin r new system cmpnent installatins. What is deemed significant is highly dependent an entity s riskassessment prcess and n the cnfiguratin f a given envirnment. Because f this variability, a significant change is nt prescribed by PCI DSS. If the change culd impact the security f the netwrk r allw access t cardhlder data, it may be cnsidered significant by the entity. Penetratin testing f significant changes is perfrmed t ensure that cntrls assumed t be in place are still wrking effectively after the upgrade r mdificatin. 8

12 3 Qualificatins f a Penetratin Tester Qualified internal resurces r a qualified third party may perfrm the penetratin test as lng as they are rganizatinally independent. This means the penetratin tester must be rganizatinally separate frm the management f the target systems. Fr example, in situatins where a third-party cmpany is perfrming the PCI DSS assessment fr the entity, that party cannt perfrm the penetratin test if they were invlved in the installatin, maintenance, r supprt f target systems. The fllwing guidelines may be useful when selecting a penetratin tester (r team) t understand their qualificatins t perfrm penetratin testing. 3.1 Certificatins Certificatins held by a penetratin tester may be an indicatin f the skill level and cmpetence f a ptential penetratin tester r cmpany. While these are nt required certificatins, they can indicate a cmmn bdy f knwledge held by the candidate. The fllwing are sme examples f cmmn penetratin testing certificatins: Offensive Security Certified Prfessinal (OSCP) Certified Ethical Hacker (CEH) Glbal Infrmatin Assurance Certificatin (GIAC) Certificatins (e.g., GIAC Certified Penetratin Tester (GPEN), GIAC Web Applicatin Penetratin Tester (GWAPT), r GIAC Explit Researcher and Advanced Penetratin Tester (GXPN)) CREST Penetratin Testing Certificatins Cmmunicatin Electrnic Security Grup (CESG) IT Health Check Service (CHECK) certificatin Nte: The PCI SSC des nt validate nr endrse these certificatins. 3.2 Past Experience Apprpriate penetratin testing experience and qualificatins cannt be met by certificatins alne. Therefre, cnfirmatin f additinal criteria is necessary. Fr example, review f the extent f actual engagements that have been perfrmed and relevant wrk experience are imprtant cnsideratins when selecting a penetratin tester r team. The fllwing questins are examples fr assessing the qualificatins and cmpetency f a penetratin tester r team. This is nt an exhaustive list: Hw many years experience des the penetratin tester have? If the penetratin tester is in their first year f penetratin testing, careful cnsideratin shuld be given t the fllwing questins t ensure the penetratin tester has sufficient knwledge and is adequately trained t perfrm the penetratin test. Cnsideratin shuld als be given t the rganizatin itself by verifying the training and QA prcesses t ensure penetratin tester is qualified. 9

13 Hw many years has the rganizatin that emplys the penetratin tester been perfrming penetratin tests? References frm ther custmers may be useful in cnsideratin Has the penetratin tester perfrmed assessments against rganizatins f similar size and scpe? Fr envirnments with high availability cnstraints, unstable system cmpnents, r large infrastructures, it is imprtant t evaluate a tester s ability t handle thse restrictins (bandwidth cnstraints, time cnstraints, etc.). What penetratin testing experience has the penetratin tester r team had with the technlgies in the target envirnment (i.e., perating systems, hardware, web applicatins, highly custmized applicatins, netwrk services, prtcls, etc.)? When selecting a penetratin tester, it is imprtant t evaluate the past testing experience f the rganizatin fr which the tester wrks as it pertains t technlgies specifically deplyed within the target envirnment. Even if the penetratin tester has nt perfrmed an assessment against certain specific technlgies, if the tester has managed, maintained, been trained n, r develped said technlgies, the tester may still be qualified t perfrm the penetratin test. Cnsider what ther skills/qualificatins the penetratin tester has that will cntribute t their ability t assess the envirnment. Are there industry-standard penetratin testing certificatins held by the penetratin tester? (See Sectin 3.1.) What type f experience des the penetratin tester have cnducting netwrk-layer penetratin testing? Discussin f examples f netwrk penetratin testing effrts cnducted by the rganizatin may be warranted. Des the penetratin tester have experience cnducting applicatin-layer penetratin testing? Discussin f the penetratin tester s familiarity with testing t validate the OWASP Tp 10 and ther similar applicatin secure-cding standards and examples f applicatin penetratin testing effrts cnducted by the rganizatin may be warranted. Nte: An rganizatin may want t cnsider having a develpment-envirnment lab where penetratin tests can be perfrmed utside f the prductin envirnment and internal resurces can train and increase their experience t help bth their skills and ptential certificatins. 10

14 4 Methdlgy T ensure a successful penetratin test, there are several activities and prcesses t be cnsidered beynd the testing itself. This sectin prvides guidance fr these activities and is rganized by the typical phases that ccur during a penetratin test: pre-engagement, engagement, and pst-engagement. 4.1 Pre-Engagement Befre the engagement r testing begins, it is recmmended that all parties invlved (the rganizatin, the tester, and where applicable, the assessr) be infrmed f the types f testing (i.e., internal, external, applicatin-layer r netwrk-layer) t be perfrmed, hw testing will be perfrmed, and what the testing will target. By crdinating these details first, issues where the CDE scpe is defined imprperly r ther issues arise that wuld require a retest might be avided. This infrmatin may be gathered by cnducting a preengagement call r during an n-site pre-engagement meeting Scping The rganizatin being assessed is respnsible fr defining the CDE and any critical systems. It is recmmended that the rganizatin wrk with the tester and, where applicable, the assessr t verify that n cmpnents are verlked and t determine whether any additinal systems shuld be included in scpe. The scpe f the penetratin test shuld be representative f all access pints, critical systems, and segmentatin methdlgies fr the CDE Dcumentatin Whenever pssible, detailed dcumentatin f any cmpnents within the scpe shuld be made available t the tester. Cmmn examples f such dcuments are applicatin-interface dcumentatin and implementatin guides. This infrmatin will ensure the tester understands hw functinality shuld wrk and whether results received are expected fr the given scenari. As a part f the scping prcess, the rganizatin shuld cnsider supplying the tester with the fllwing dcumentatin: A netwrk diagram depicting all netwrk segments in scpe fr the test (Refer t PCI DSS Requirements and ) Cardhlder data flw diagram A list f all expected services and prts expsed at the CDE perimeter Details f hw authrized users access the CDE A list f all netwrk segments that have been islated frm the CDE t reduce scpe The penetratin tester will use this infrmatin during the assessment t identify unexpected attack vectrs f the CDE in additin t knwn attack vectrs, insufficient authenticatin cntrls, and t cnfirm the prper segmentatin f ut-f-scpe envirnments. 11

15 4.1.3 Rules f Engagement Prir t the cmmencement f any testing, it is imprtant t dcument and agree upn the cnditins in which testing is t be perfrmed and the degree f explitatin, if any, that is permitted. This authrizes the tester t test the envirnment and ensure the rganizatin understands what t expect frm the penetratin test. Belw are sme examples f cnsideratins that may be included in the rules f engagement: During what time windw will testing need t be perfrmed? Are there any legacy systems that have knwn issues with autmated scanning? If s, hw shuld testing be perfrmed against these systems? Is there a preferred methd f cmmunicating abut scpe and issues encuntered during the engagement? Des the entity want updates regarding nging explitatin f systems during the test? If s, the entity will need t determine whether they will r will nt act upn such infrmatin r make changes t the envirnment. The entity may als want t implement its incident respnse plan in respnse t an explit. Are there security cntrls that wuld detect r prevent testing? Cnsider whether these shuld be disabled r cnfigured t nt interfere during testing. (See Sectin fr further guidance.) If passwrds r ther sensitive data are cmprmised during the testing, des the tester need t disclse a list f all passwrds and/r sensitive data accessed? If equipment wned by the tester is t be cnnected t the rganizatin s netwrk, what steps must be taken t ensure the equipment des nt pse a threat t the envirnment (updated t the latest perating system, applied service packs and/r patches, etc.)? Des the tester need t prvide all IP addresses frm which testing will riginate? Will sensitive data shwn t be accessible during the test be retained by the tester during and after the penetratin test? Only a prf-f-cncept test shuld be perfrmed, any cardhlder data btained must be secured in accrdance with PCI DSS. (See Sectin fr mre guidance.) What steps will be taken if the tester detects a previus r active cmprmise t systems being tested? (Fr example, activate incident respnse prcedures and stp penetratin test until reslutin f the cmprmise situatin.) Third-Party-Hsted / Clud Envirnments Belw are examples f cnsideratins that may be included in the rules f engagement fr third-partyhsted/clud envirnments f the entity: If a service-level agreement requires apprval frm a third party befre penetratin tests can be cnducted, the rganizatin must receive apprval frm the third party (i.e., hsting prvider, etc.) befre the assessment is t take place. 12

16 The scpe may nt include the infrastructure prvided by the third party t the entity. The scpe may include any systems managed, built, r utilized by the rganizatin. Unless therwise nted in the scpe, web-management prtals prvided by the third party fr the entity t manage its infrastructure shuld nt be included in the penetratin test these interfaces shuld be tested and validated as part f the third party s PCI DSS cmpliance effrts, and evidence r attestatin f validatin shuld be prvided t the custmer Success Criteria The intent f a penetratin test is t simulate a real-wrld attack situatin with a gal f identifying hw far an attacker may be able t penetrate int the envirnment. Defining the success criteria fr the penetratin test allws the entity t set limits n the depth f the penetratin test. Withut agreeing upn the pint at which the penetratin test is cmplete, there is a pssibility f the tester exceeding the bundaries and expectatins f the target entity. This shuld be dcumented in the rules f engagement. Pssible success criteria may include: Direct bservatin f restricted services r data in the absence f expected access cntrls Cmprmise f an intermediary device used by privileged users t access the CDE Cmprmise f the dmain used by privileged users N cmprmise f the target systems The success criteria will be different fr every envirnment and shuld be established during initial preengagement meeting prir t testing Review f Past Threats and Vulnerabilities PCI DSS Requirement 11.3 requires a review and cnsideratin f threats and vulnerabilities encuntered by the assessed entity within the past 12 mnths. This is an histrical lk at real vulnerabilities experienced r discvered in the entity s envirnment since the last assessment. This infrmatin may prvide insight t the prcess in place t handle these vulnerabilities. The penetratin tester shuld be familiar with current vulnerabilities seen by the industry ver the past 12 mnths as well as take a detailed lk at recent vulnerabilities experienced by the entity. Depending n the type f test t be perfrmed (i.e., white bx, grey bx, black bx), the fllwing may r may nt be cnsidered in such a review: Vulnerabilities discvered by the entity which have nt been remediated within the time perid required by PCI DSS (example: quarterly), and/r by the vulnerability remediatin requirements dcumented in the crprate security plicy Existing cmpensating cntrls mitigating the nted vulnerabilities Deplyments r upgrades in prgress (cnsider bth hardware and sftware) If applicable, threats r vulnerabilities that may have led t a data breach Validatin f the remediatin f previus years penetratin test findings 13

17 Identificatin f industry state f existing vulnerabilities fr purpses f tracking vulnerabilities that may have nt been detected at the time f the mst recent penetratin test The tester may gain additinal insight f the target envirnment fr this review by: Reviewing prir penetratin test reprts Reviewing previusly issued Reprts n Cmpliance r Attestatins f Cmpliance Reviewing current vulnerability scan test results Avid scan interference n security appliances. In many envirnments, active prtectin cntrls such as an intrusin preventin system r web active prtectin systems such as intrusin prtectin systems (IPS) and web applicatin firewalls (WAF) may be deplyed t prtect expsed services. Because the intent f the penetratin test is t evaluate the services susceptibility t explitatin (vs. the active prtectin systems ability t prevent attacks), interference with the penetratin test shuld be avided entities are encuraged t review and be familiar with the sectin titled Scan Interference in the ASV Prgram Guide and cnfigure active prtectin systems accrdingly during testing. This practice helps ensure that the services themselves are cnfigured prperly and have the minimal risk f being explited in the event the active prtectin system fails r is smehw defeated r bypassed by an attacker. 4.2 Engagement: Penetratin Testing Each envirnment has unique aspects/technlgy that requires the tester select the mst apprpriate apprach and the tls necessary t perfrm the penetratin test. It is beynd the scpe f this dcument t define r utline which apprach, tls, r techniques are apprpriate fr each penetratin test. Instead, the fllwing sectins prvide high-level guidance n cnsideratins fr the apprach, tls, r techniques. Penetratin testing is essentially a manual endeavr. In many cases, tls exist that can aid the tester in perfrming the test and alleviate sme f the repetitive tasks. Judgment is required in selecting the apprpriate tls and in identifying attack vectrs that typically cannt be identified thrugh autmated means. Penetratin testing shuld als be perfrmed frm a suitable lcatin, with n restrictins n prts r services by the Internet prvider. Fr example, a penetratin tester utilizing Internet cnnectivity prvided t cnsumers and residences may have SMTP, SNMP, SMB, and ther prts restricted by the Internet prvider t minimize impact by viruses and malware. If testing is perfrmed by a qualified internal resurce, the test shuld als be perfrmed frm a neutral Internet cnnectin unaffected by access cntrls that might be present frm the crprate r supprt envirnments. 14

18 4.2.1 Applicatin Layer As mentined in Sectin 2.3, the penetratin tester shuld perfrm testing frm the perspective f the defined rles f the applicatin. The rganizatin is strngly encuraged t supply credentials t allw the tester t assume the required rles. This will allw the tester t determine if, at any given rle, the user culd escalate privileges r therwise gain access t data they are nt explicitly allwed t access. In instances where the rganizatin has created new accunts fr the tester t use, it is imprtant that the rganizatin ensure all rles and applicable security in the applicatin have been set up t allw the tester t effectively test all functinality. In instances where a web applicatin utilizes a backend API and the API is in scpe, it is recmmended that the API be tested independently f the web applicatin Netwrk Layer Since mst prtcls are well defined and have standard mdes f interactin, netwrk-layer testing is mre suitable fr autmated testing. This makes autmatin the first lgical step in a netwrk-layer test. Because f such standardizatin, tls may be used t quickly identify a service, the versin f the sftware, test fr cmmn miscnfiguratins, and even identify vulnerabilities. Autmated tests can be perfrmed much faster than culd be expected f a human. Hwever, simply running an autmated tl des nt satisfy the penetratin testing requirement. Autmated tls cannt interpret vulnerabilities, miscnfiguratins, r even the services expsed t assess the true risk t the envirnment. The autmated tl nly serves as a baseline indicatin f the ptential attack surface f the envirnment. The penetratin tester must interpret the results f any autmated tls and determine whether additinal testing is needed. Using the dcumentatin prvided by the rganizatin during the pre-engagement, the tester shuld: Verify that nly authrized services are expsed at the CDE perimeter. Attempt t bypass authenticatin cntrls frm all netwrk segments where authrized users access the CDE, as well as segments nt authrized t access the CDE Segmentatin The segmentatin check is perfrmed by cnducting tests used in the initial stages f a netwrk penetratin test (i.e., hst discvery, prt scanning, etc.). It shuld verify that all islated LANs d nt have access int the CDE. The penetratin tester shuld verify that each netwrk segment reprted t be islated frm the CDE truly has n access t the CDE. Fr envirnments with a large number f netwrk segments cnsidered t be islated frm the CDE, a representative subset can be used fr testing t reduce the number f segmentatin checks that need t be perfrmed. Testing f each unique segmentatin methdlgy shuld be used t ensure that all security cntrls are functining as intended. If it is determined during the segmentatin check that the LAN segment has access int the CDE, either the rganizatin needs t restrict that access r a full netwrk-layer penetratin test shuld be perfrmed t characterize the access. 15

19 4.2.4 What t d when cardhlder data is encuntered If cardhlder data is accessed during the penetratin test, it is imprtant that the tester ntify the rganizatin immediately. The tester shuld keep detailed dcumentatin as t exactly what data was accessed and hw it was accessed. After being ntified, the rganizatin shuld immediately review hw the cardhlder data was retrieved and, as apprpriate, shuld take steps t execute its incident respnse plan. If the utput f testing tls r activities includes cardhlder data that was accessed by the tester during the engagement, it is imprtant this utput be secured in accrdance with PCI DSS Pst-Explitatin The term pst-explitatin refers t the actins taken after the initial cmprmise f a system r device. It ften describes the methdical apprach f using privilege escalatin r pivting techniques which allws the tester, in this case, t establish a new surce f attack frm the new vantage pint in the system t gain additinal access t systems r netwrk resurces. Penetratin testers shuld be able t demnstrate the risk presented by explitable systems t the CDE and what pst-explitatin may likely ccur with thse systems. 4.3 Pst-Engagement After the engagement r testing has been perfrmed, there are activities bth parties shuld carry ut Remediatin Best Practices Penetratin testing effrts, while thrugh, may nt always guarantee exhaustive identificatin f every instance where a security cntrl s effectiveness is insufficient e.g., finding a crss site scripting vulnerability in ne area f an applicatin may nt reveal all instances f this vulnerability in the applicatin. Often the presence f vulnerability in ne area may indicate weakness in prcess r develpment practices that culd have replicated r enabled similar vulnerability in ther lcatins. Therefre, it is imprtant fr the tested entity t carefully investigate systems r applicatins with the ineffective security cntrls in mind when remediating Retesting Identified Vulnerabilities The rganizatin shuld take steps t remediate any explitable vulnerability within a reasnable perid f time after the riginal test. When the rganizatin has cmpleted these steps, the tester shuld perfrm a retest t validate the newly implemented cntrls mitigate the riginal risk. Remediatin effrts extending fr a lng perid after the initial test may require a new testing engagement t be perfrmed t ensure accurate results f the mst current envirnment are reprted. This determinatin may be made after a risk analysis f hw much change has ccurred since the riginal testing was cmpleted. 16

20 In specific cnditins, the flagged security issue may represent a fundamental flaw in an envirnment r applicatin. The scpe f a retest shuld cnsider whether any changes ccurring as a result f remediatin identified frm the test are classified as significant. All changes shuld be retested; hwever, whether a cmplete system retest is necessary will be determined by the risk assessment f thse changes Cleaning up the Envirnment It is imprtant fr the tester t dcument and disclse t the rganizatin any alteratins made t the envirnment (as permitted in the Rules f Engagement) during the test, including but nt limited t: Accunts that were created as a part f the assessment either by the entity r the tester: the rganizatin shuld then remve these accunts. Tls installed by the tester n the rganizatin s systems: these tls shuld be remved at the end f the testing. Remval f accunts and test tls will ensure the accunts r remnant tls culd nt be explited r used against the rganizatin. 4.4 Additinal Resurces There are multiple industry-accepted methdlgies that may prvide additinal guidance n penetratin testing activities, including but nt limited t: Open Surce Security Testing Methdlgy Manual ( OSSTMM ) The Natinal Institute f Standards and Technlgy ( NIST ) Special Publicatin OWASP Testing Guide Penetratin Testing Executin Standard Penetratin Testing Framewrk 17

21 5 Reprting and Dcumentatin The purpse f the reprt is t assist the rganizatin in its effrts t imprve its security psture by identifying areas f ptential risk that may need t be remediated. Merely reprting lists f vulnerabilities is nt helpful in this endeavr and des nt meet the intent f the penetratin test. The reprt shuld be structured in a way t clearly cmmunicate what was tested, hw it was tested, and the results f the testing. This sectin prvides guidance n dcumenting identified and/r explited vulnerabilities, creating reprting templates, and evaluating a penetratin test reprt. 5.1 Identified Vulnerability Reprting Penetratin test reprts shuld include a discussin f the steps, vectrs, and explited vulnerabilities that lead t penetratin during testing fr which remediatin and retesting are required. Hwever, it is pssible fr the tester t identify vulnerabilities that were nt necessarily explitable but which are deemed t pse a ptential risk t the envirnment. It is recmmended that the reprt cntain any findings that impact the security psture f the assessed entity even in cases where explitatin did nt ccur. Sme examples f identified vulnerabilities that were nt explited fr valid reasns and shuld be included in the reprt may be: Firewall miscnfiguratins that permit unauthrized traffic between secure and insecure znes Detectin f credentials btained thrugh manipulatin f a web-applicatin errr message that was nt flagged during an ASV scan due t a lw CVSS base scre Assigning a Severity Scre In rder t priritize remediatin f the penetratin test findings, it is a cmmn practice during the reprting phase fr a severity r risk ranking t be assigned fr each detected security issue. The reprt shuld clearly dcument hw the severity/risk ranking is derived. In mst cases, severity/risk ranking may be applied as a result f evaluating an industry-standard scre (e.g., NVD, CVSS) against a threshld r value that indicates risk (i.e., high, medium, and lw). Hwever, it shuld be nted that it is pssible fr a vulnerability t exist that is inherent t a particular envirnment; therefre, a standardized scre is nt available. When custm scring is part f the risk-ranking prcess, the reprt shuld reflect a traceable set f reasning fr the mdificatin f industry-standard scres r, where applicable, fr the creatin f a scre fr a vulnerability that des nt have an industry-standard scre defined. 18

22 5.1.2 Industry Standard References Sme well-knwn, industry-standard references include: Natinal Vulnerability Database (NVD) Cmmn Vulnerability Scring System (CVSS) Cmmn Vulnerabilities and Expsure (CVE) Cmmn Weakness Enumeratin (CWE) Bugtraq ID (BID) Open Surce Vulnerability Database (OSVDB) The Cmmn Vulnerability Scring System (CVSS) is an example f an pen framewrk that may be referenced fr assigning a baseline risk rating. The CVSS is the required scring system fr Apprved Scanning Vendrs (ASVs) t use fr ranking vulnerabilities detected during PCI vulnerability scans. Using this system, a standardized vulnerability scre can be adjusted thrugh the evaluatin f the traits f vulnerability within the cntext f a specific envirnment. 5.2 Reprting Guidelines Cmprehensive and cnsistent reprting is a critical phase f a penetratin test. This sectin prvides guidelines n cmmn cntents f an industry standard penetratin test. It shuld be nted that these are nly suggested utlines and d nt define specific reprting requirements fr PCI DSS penetratin tests. Testers may have different sectins, alternative titles, and/r reprt frmat, etc.; this utline represents data gathered frm a number f penetratin testing prviders and the desires f custmers Penetratin Test Reprt Outline Executive Summary Brief high-level summary f the penetratin test scpe and majr findings Statement f Scpe A detailed definitin f the scpe f the netwrk and systems tested as part f the engagement Clarificatin f CDE vs. nn-cde systems r segments that are cnsidered during the test Identificatin f critical systems in r ut f the CDE and explanatin f why they are included in the test as targets Statement f Methdlgy Details n the methdlgies used t cmplete the testing (prt scanning, nmap etc.). See Sectin 4 fr details n methdlgies that shuld be dcumented. Statement f Limitatins Dcument any restrictins impsed n testing such as designated testing hurs, bandwidth restrictins, special testing requirements fr legacy systems, etc. 19

23 Testing Narrative Prvide details as t the testing methdlgy and hw testing prgressed. Fr example, if the envirnment did nt have any active services, explain what testing was perfrmed t verify restricted access. Dcument any issues encuntered during testing (e.g., interference was encuntered as a result f active prtectin systems blcking traffic). Segmentatin Test Results Summarize the testing perfrmed t validate segmentatin cntrls, if used t reduce the scpe f PCI DSS. Findings Whether/hw the CDE may be explited using each vulnerability. Risk ranking/severity f each vulnerability Targets affected References (if available) - CVE, CWE, BID, OSBDB, etc. - Vendr and/r researcher Descriptin f finding Tls Used Cleaning up the Envirnment Pst-Penetratin Test After testing there may be tasks the tester r custmer needs t perfrm t restre the target envirnment (i.e., update/remval f test accunts r database entries added r mdified during testing, uninstall f test tls r ther artifacts, restring active prtectin-system settings, and/r ther activities the tester may nt have permissins t perfrm, etc.). Prvide directins n hw clean up shuld be perfrmed and hw t verify security cntrls have been restred Retesting Cnsideratins and Reprt Outline If the nted findings will require remediatin and retesting befre an assessr can determine the entity has met PCI DSS Requirement 11.3, a fllw-up test reprt may be prvided. All remediatin effrts shuld be cmpleted and retested within a reasnable perid f time after the riginal penetratin test reprt was prvided. It is expected that the remediatin test reprt will cver all identified/explitable vulnerabilities that require remediatin. Thse identified vulnerabilities is may be medium r high fr external penetratin tests and thse defined by the rganizatin as medium r high fr internal tests. 20