pci_dss_v1-2 (1027411), страница 7
Текст из файла (страница 7)
The procedures mustinclude the following:Testing ProceduresIn PlaceNot inPlaceTarget Date/Comments6.4.aObtain and examine company change-controlprocedures related to implementing security patches andsoftware modifications, and verify that the proceduresrequire items 6.4.1 – 6.4.4 below.6.4.bFor a sample of system components and recentchanges/security patches, trace those changes back torelated change control documentation. For each changeexamined, perform the following:6.4.1Documentation of impact6.4.1 Verify that documentation of customer impact isincluded in the change control documentation for eachsampled change.6.4.2 Management sign-off byappropriate parties6.4.2 Verify that management sign-off by appropriateparties is present for each sampled change.6.4.3 Testing of operationalfunctionality6.4.3 Verify that operational functionality testing isperformed for each sampled change.6.4.46.4.4 Verify that back-out procedures are prepared foreach sampled changeBack-out procedures6.5Develop all web applications(internal and external, and including webadministrative access to application)based on secure coding guidelines suchas the Open Web Application SecurityProject Guide.
Cover prevention ofcommon coding vulnerabilities insoftware development processes, toinclude the following:Note: The vulnerabilities listed at 6.5.1through 6.5.10 were current in theOWASP guide when PCI DSS v1.2 waspublished. However, if and when theOWASP guide is updated, the currentversion must be used for theserequirements.6.5.a Obtain and review software developmentprocesses for any web-based applications. Verify thatprocesses require training in secure coding techniques fordevelopers, and are based on guidance such as theOWASP guide (http://www.owasp.org).6.5.b Interview a sample of developers and obtainevidence that they are knowledgeable in secure codingtechniques.6.5.c Verify that processes are in place to ensure thatweb applications are not vulnerable to the following:PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 32PCI DSS Requirements6.5.1Cross-site scripting (XSS)Testing Procedures6.5.2 Injection flaws, particularly SQL injection(Validate input to verify user data cannot modify meaningof commands and queries.)6.5.36.5.3 Malicious file execution (Validate input to verifyapplication does not accept filenames or files fromusers.)6.5.4 Insecure direct objectreferences6.5.4 Insecure direct object references (Do not exposeinternal object references to users.)6.5.5 Cross-site request forgery(CSRF)6.5.5 Cross-site request forgery (CSRF) (Do not replyon authorization credentials and tokens automaticallysubmitted by browsers.)6.5.6 Information leakage andimproper error handling6.5.6 Information leakage and improper error handling(Do not leak information via error messages or othermeans.)6.5.7 Broken authentication andsession management6.5.7 Broken authentication and session management(Properly authenticate users and protect accountcredentials and session tokens.)6.5.8 Insecure cryptographicstorage6.5.8 Insecure cryptographic storage (Preventcryptographic flaws.)6.5.96.5.9 Insecure communications (Properly encrypt allauthenticated and sensitive communications.)Insecure communications6.5.10 Failure to restrict URL accessNot inPlaceTarget Date/Comments6.5.1 Cross-site scripting (XSS) (Validate allparameters before inclusion.)6.5.2 Injection flaws, particularlySQL injection.
Also consider LDAPand Xpath injection flaws as well asother injection flaws.Malicious file executionIn Place6.5.10 Failure to restrict URL access (Consistentlyenforce access control in presentation layer and businesslogic for all URLs.)PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 33PCI DSS RequirementsTesting Procedures6.6For public-facing webapplications, address new threats andvulnerabilities on an ongoing basis andensure these applications are protectedagainst known attacks by either of thefollowing methods: Reviewing public-facing webapplications via manual orautomated application vulnerabilitysecurity assessment tools ormethods, at least annually andafter any changes Installing a web-application firewallin front of public-facing webapplications6.6For public-facing web applications, ensure thateither one of the following methods are in place as follows: Verify that public-facing web applications arereviewed (using either manual or automatedvulnerability security assessment tools or methods),as follows:- At least annually- After any changes- By an organization that specializes in applicationsecurity- That all vulnerabilities are corrected- That the application is re-evaluated after thecorrections Verify that a web-application firewall is in place infront of public-facing web applications to detect andprevent web-based attacks.In PlaceNot inPlaceTarget Date/CommentsNote: “An organization that specializes in applicationsecurity” can be either a third-party company or aninternal organization, as long as the reviewers specializein application security and can demonstrateindependence from the development team.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 34Implement Strong Access Control MeasuresRequirement 7: Restrict access to cardholder data by business need to knowTo ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need toknow and according to job responsibilities.“Need to know” is when access rights are granted to only the least amount of data and privileges needed to perform a job.PCI DSS Requirements7.1Limit access to systemcomponents and cardholder data to onlythose individuals whose job requiressuch access.
Access limitations mustinclude the following:Testing ProceduresIn PlaceNot inPlaceTarget Date/Comments7.1Obtain and examine written policy for data control,and verify that the policy incorporates the following:7.1.1 Restriction of access rights toprivileged user IDs to least privilegesnecessary to perform jobresponsibilities7.1.1Confirm that access rights for privileged userIDs are restricted to least privileges necessary toperform job responsibilities.7.1.2 Assignment of privileges isbased on individual personnel’s jobclassification and function7.1.2Confirm that privileges are assigned toindividuals based on job classification and function (alsocalled “role-based access control” or RBAC).7.1.3 Requirement for anauthorization form signed bymanagement that specifies requiredprivileges7.1.3Confirm that an authorization form is requiredfor all access, that it must specify required privileges,and that it must be signed by management.7.1.4 Implementation of an automatedaccess control system7.1.4Confirm that access controls are implementedvia an automated access control system.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 35PCI DSS Requirements7.2Establish an access controlsystem for systems components withmultiple users that restricts access basedon a user’s need to know, and is set to“deny all” unless specifically allowed.This access control system must includethe following:Testing ProceduresNot inPlaceTarget Date/Comments7.2Examine system settings and vendordocumentation to verify that an access control system isimplemented as follows:7.2.1 Coverage of all systemcomponents7.2.1Confirm that access control systems are inplace on all system components.7.2.2 Assignment of privileges toindividuals based on job classificationand function7.2.2Confirm that access control systems areconfigured to enforce privileges assigned to individualsbased on job classification and function.7.2.3 Default “deny-all” settingIn Place7.2.3Confirm that the access control systems has adefault “deny-all” setting.Note: Some access control systems are set by default to“allow-all,” thereby permitting access unless/until a rule iswritten to specifically deny it.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 36Requirement 8: Assign a unique ID to each person with computer access.Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions.
Whensuch accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.PCI DSS RequirementsTesting Procedures8.1Assign all users a unique IDbefore allowing them to access systemcomponents or cardholder data.8.1Verify that all users are assigned a unique ID foraccess to system components or cardholder data.8.2In addition to assigning a uniqueID, employ at least one of the followingmethods to authenticate all users:Password or passphraseTwo-factor authentication (forexample, token devices, smartcards, biometrics, or public keys)8.2To verify that users are authenticated using uniqueID and additional authentication (for example, a password)for access to the cardholder data environment, perform thefollowing:Obtain and examine documentation describing theauthentication method(s) used.For each type of authentication method used and foreach type of system component, observe anauthentication to verify authentication is functioningconsistent with documented authentication method(s).8.3Incorporate two-factorauthentication for remote access(network-level access originating fromoutside the network) to the network byemployees, administrators, and thirdparties.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
