pci_dss_v1-2 (1027411), страница 6
Текст из файла (страница 6)
Misconfiguredwireless networks and vulnerabilities in legacy encryption and authentication protocols can be continued targets of malicious individuals whoexploit these vulnerabilities to gain privileged access to cardholder data environments.PCI DSS RequirementsTesting Procedures4.1Use strong cryptography andsecurity protocols such as SSL/TLS orIPSEC to safeguard sensitive cardholderdata during transmission over open,public networks.Examples of open, public networks thatare in scope of the PCI DSS are:4.1.a Verify the use of encryption (for example, SSL/TLSor IPSEC) wherever cardholder data is transmitted orreceived over open, public networksVerify that strong encryption is used during datatransmissionFor SSL implementations:- Verify that the server supports the latestpatched versions.- Verify that HTTPS appears as a part of thebrowser Universal Record Locator (URL).- Verify that no cardholder data is required whenHTTPS does not appear in the URL.Select a sample of transactions as they are receivedand observe transactions as they occur to verify thatcardholder data is encrypted during transit.Verify that only trusted SSL/TLS keys/certificates areaccepted.Verify that the proper encryption strength isimplemented for the encryption methodology in use.(Check vendor recommendations/best practices.)The Internet,Wireless technologies,Global System for Mobilecommunications (GSM), andGeneral Packet Radio Service(GPRS).PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCIn PlaceNot inPlaceTarget Date/CommentsOctober 2008Page 26PCI DSS Requirements4.1.1 Ensure wireless networkstransmitting cardholder data orconnected to the cardholder dataenvironment, use industry bestpractices (for example, IEEE 802.11i)to implement strong encryption forauthentication and transmission.Testing ProceduresIn PlaceNot inPlaceTarget Date/Comments4.1.1 For wireless networks transmitting cardholder dataor connected to the cardholder data environment, verifythat industry best practices (for example, IEEE 802.11i)are used to implement strong encryption forauthentication and transmission.For new wireless implementations,it is prohibited to implement WEPafter March 31, 2009.For current wirelessimplementations, it is prohibited touse WEP after June 30, 2010.4.2Never send unencrypted PANs byend-user messaging technologies (forexample, e-mail, instant messaging,chat).4.2.aVerify that strong cryptography is used whenevercardholder data is sent via end-user messagingtechnologies.4.2.bVerify the existence of a policy stating thatunencrypted PANs are not to be sent via end-usermessaging technologies.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 27Maintain a Vulnerability Management ProgramRequirement 5: Use and regularly update anti-virus software or programsMalicious software, commonly referred to as “malware”—including viruses, worms, and Trojans—enters the network during many businessapproved activities including employees’ e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation ofsystem vulnerabilities.
Anti-virus software must be used on all systems commonly affected by malware to protect systems from current andevolving malicious software threats.PCI DSS Requirements5.1 Deploy anti-virus software on allsystems commonly affected bymalicious software (particularly personalcomputers and servers).5.1.1Ensure that all anti-virusprograms are capable of detecting,removing, and protecting against allknown types of malicious software.5.2 Ensure that all anti-virusmechanisms are current, activelyrunning, and capable of generating auditlogs.Testing ProceduresIn PlaceNot inPlaceTarget Date/ Comments5.1For a sample of system components including alloperating system types commonly affected by malicioussoftware, verify that anti-virus software is deployed ifapplicable anti-virus technology exists.5.1.1 For a sample of system components, verify that allanti-virus programs detect, remove, and protect against allknown types of malicious software (for example, viruses,Trojans, worms, spyware, adware, and rootkits).5.2Verify that all anti-virus software is current, activelyrunning, and capable of generating logs by performing thefollowing:5.2.a Obtain and examine the policy and verify that itrequires updating of anti-virus software and definitions.5.2.b Verify that the master installation of the softwareis enabled for automatic updates and periodic scans.5.2.c For a sample of system components including alloperating system types commonly affected bymalicious software, verify that automatic updates andperiodic scans are enabled.5.2d For a sample of system components, verify thatantivirus software log generation is enabled and thatsuch logs are retained in accordance with PCI DSSRequirement 10.7PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 28Requirement 6: Develop and maintain secure systems and applicationsUnscrupulous individuals use security vulnerabilities to gain privileged access to systems.
Many of these vulnerabilities are fixed by vendorprovided security patches, which must be installed by the entities that manage the systems. All critical systems must have the most recentlyreleased, appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicioussoftware.Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do notconflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standardsystem development processes and secure coding techniques.PCI DSS Requirements6.1Ensure that all systemcomponents and software have the latestvendor-supplied security patchesinstalled.
Install critical security patcheswithin one month of release.Note: An organization may considerapplying a risk-based approach toprioritize their patch installations. Forexample, by prioritizing criticalinfrastructure (for example, public-facingdevices and systems, databases) higherthan less-critical internal devices, toensure high-priority systems and devicesare addressed within one month, andaddressing less critical devices andsystems within three months.6.2Establish a process to identifynewly discovered security vulnerabilities(for example, subscribe to alert servicesfreely available on the Internet). Updateconfiguration standards as required byPCI DSS Requirement 2.2 to address newvulnerability issues.Testing ProceduresIn PlaceNot inPlaceTarget Date/ Comments6.1.a For a sample of system components and relatedsoftware, compare the list of security patches installed oneach system to the most recent vendor security patch list,to verify that current vendor patches are installed.6.1.b Examine policies related to security patchinstallation to verify they require installation of all criticalnew security patches within one month.6.2.a Interview responsible personnel to verify thatprocesses are implemented to identify new securityvulnerabilities.6.2.b Verify that processes to identify new securityvulnerabilities include using outside sources for securityvulnerability information and updating the systemconfiguration standards reviewed in Requirement 2.2 asnew vulnerability issues are found.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 29PCI DSS RequirementsTesting Procedures6.3Develop software applications inaccordance with PCI DSS (for example,secure authentication and logging) andbased on industry best practices, andincorporate information securitythroughout the software development lifecycle.
These processes must include thefollowing:6.3.a Obtain and examine written software developmentprocesses to verify that the processes are based onindustry standards, security is included throughout the lifecycle, and software applications are developed inaccordance with PCI DSS.6.3.b From an examination of written softwaredevelopment processes, interviews of software developers,and examination of relevant data (network configurationdocumentation, production and test data, etc.), verify that:6.3.1 Testing of all security patches,and system and software configurationchanges before deployment, includingbut not limited to the following:6.3.1 All changes (including patches) are tested beforebeing deployed into production.6.3.1.1 Validation of all input (toprevent cross-site scripting, injectionflaws, malicious file execution, etc.)6.3.1.1 Validation of all input (to prevent cross-sitescripting, injection flaws, malicious file execution,etc.)6.3.1.2 Validation of proper errorhandling6.3.1.2 Validation of proper error handling6.3.1.3 Validation of securecryptographic storage6.3.1.3 Validation of secure cryptographic storage6.3.1.4 Validation of securecommunications6.3.1.4 Validation of secure communications6.3.1.5 Validation of proper rolebased access control (RBAC)6.3.1.5 Validation of proper role-based accesscontrol (RBAC)6.3.2 Separate development/test andproduction environments6.3.2 The development/test environments are separatefrom the production environment, with access control inplace to enforce the separation.6.3.3 Separation of duties betweendevelopment/test and productionenvironments6.3.3 There is a separation of duties betweenpersonnel assigned to the development/testenvironments and those assigned to the productionenvironment.6.3.4 Production data (live PANs) arenot used for testing or development6.3.4 Production data (live PANs) are not used fortesting and development, or are sanitized before use.6.3.5 Removal of test data andaccounts before production systemsbecome active6.3.5 Test data and accounts are removed before aproduction system becomes active.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCIn PlaceNot inPlaceTarget Date/ CommentsOctober 2008Page 30PCI DSS RequirementsTesting Procedures6.3.6Removal of custom applicationaccounts, user IDs, and passwordsbefore applications become active or arereleased to customers6.3.6 Custom application accounts, user IDs and/orpasswords are removed before system goes intoproduction or is released to customers.6.3.7Review of custom code prior torelease to production or customers inorder to identify any potential codingvulnerabilityNote: This requirement for code reviewsapplies to all custom code (both internaland public-facing), as part of the systemdevelopment life cycle required by PCIDSS Requirement 6.3.
Code reviews canbe conducted by knowledgeable internalpersonnel or third parties. Webapplications are also subject to additionalcontrols, if they are public facing, toaddress ongoing threats andvulnerabilities after implementation, asdefined at PCI DSS Requirement 6.6.6.3.7.aObtain and review policies to confirm allcustom application code changes for internal applicationsmust be reviewed (either using manual or automatedprocesses), as follows:Code changes are reviewed by individuals otherthen the originating code author, and byindividuals who are knowledgeable in code reviewtechniques and secure coding practices.Appropriate corrections are implemented prior torelease.Code review results are reviewed and approvedby management prior to release.In PlaceNot inPlaceTarget Date/ Comments6.3.7.b Obtain and review policies to confirm that allcustom application code changes for web applicationsmust be reviewed (using either manual or automatedprocesses) as follows:Code changes are reviewed by individuals otherthen the originating code author, and byindividuals who are knowledgeable in code reviewtechniques and secure coding practices.Code reviews ensure code is developed accordingto secure coding guidelines such as the OpenWeb Security Project Guide (see PCI DSSRequirement 6.5).Appropriate corrections are implemented prior torelease.Code review results are reviewed and approvedby management prior to release.6.3.7.c Select a sample of recent custom applicationchanges and verify that custom application code isreviewed according to 6.3.7a and 6.3.7b above.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 31PCI DSS Requirements6.4Follow change controlprocedures for all changes to systemcomponents.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
