pci_dss_v1-2 (1027411), страница 4
Текст из файла (страница 4)
An example of an insecure service, protocol,or port is FTP, which passes user credentials in clear-text.1.1.6 Requirement to review firewalland router rule sets at least every sixmonths1.1.6.a Verify that firewall and router configurationstandards require review of firewall and router rule sets atleast every six months.1.1.6.b Obtain and examine documentation to verify thatthe rule sets are reviewed at least every six months.1.2Build a firewall configuration thatrestricts connections between untrustednetworks and any system components inthe cardholder data environment.1.2Examine firewall and router configurations to verifythat connections are restricted between untrusted networksand system components in the cardholder dataenvironment, as follows:Note: An “untrusted network” is any network that is external to the networks belonging to the entity underreview, and/or which is out of the entity's ability to control or manage.1.2.1 Restrict inbound and outboundtraffic to that which is necessary for thecardholder data environment.1.2.1.a Verify that inbound and outbound traffic is limitedto that which is necessary for the cardholder dataenvironment, and that the restrictions are documented.1.2.1.b Verify that all other inbound and outbound traffic isspecifically denied, for example by using an explicit “denyall” or an implicit deny after allow statement.1.2.2 Secure and synchronize routerconfiguration files.1.2.2 Verify that router configuration files are secureand synchronized—for example, running configurationfiles (used for normal running of the routers) and start-upconfiguration files (used when machines are re-booted),have the same, secure configurations.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 14PCI DSS Requirements1.2.3 Install perimeter firewalls betweenany wireless networks and the cardholderdata environment, and configure thesefirewalls to deny or control (if such traffic isnecessary for business purposes) anytraffic from the wireless environment intothe cardholder data environment.1.3 Prohibit direct public access betweenthe Internet and any system component inthe cardholder data environment.Testing ProceduresIn PlaceNot inPlaceTarget Date/Comments1.2.3 Verify that there are perimeter firewalls installedbetween any wireless networks and systems that storecardholder data, and that these firewalls deny or control (ifsuch traffic is necessary for business purposes) any trafficfrom the wireless environment into the cardholder dataenvironment.1.3 Examine firewall and router configurations, as detailedbelow, to determine that there is no direct access betweenthe Internet and system components, including the chokerouter at the Internet, the DMZ router and firewall, the DMZcardholder segment, the perimeter router, and the internalcardholder network segment.1.3.1 Implement a DMZ to limit inboundand outbound traffic to only protocols thatare necessary for the cardholder dataenvironment.1.3.1 Verify that a DMZ is implemented to limit inboundand outbound traffic to only protocols that are necessaryfor the cardholder data environment.1.3.2 Limit inbound Internet traffic to IPaddresses within the DMZ.1.3.2 Verify that inbound Internet traffic is limited to IPaddresses within the DMZ.1.3.3 Do not allow any direct routesinbound or outbound for traffic betweenthe Internet and the cardholder dataenvironment.1.3.3 Verify there is no direct route inbound or outboundfor traffic between the Internet and the cardholder dataenvironment.1.3.4 Do not allow internal addresses topass from the Internet into the DMZ.1.3.4 Verify that internal addresses cannot pass from theInternet into the DMZ.1.3.5 Restrict outbound traffic from thecardholder data environment to theInternet such that outbound traffic canonly access IP addresses within the DMZ.1.3.5 Verify that outbound traffic from the cardholder dataenvironment to the Internet can only access IP addresseswithin the DMZ.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 15PCI DSS RequirementsTesting Procedures1.3.6 Implement stateful inspection,also known as dynamic packet filtering.(That is, only ”established” connectionsare allowed into the network.)1.3.6 Verify that the firewall performs stateful inspection(dynamic packet filtering).
[Only established connectionsshould be allowed in, and only if they are associated witha previously established session (run a port scanner on allTCP ports with “syn reset” or ”syn ack” bits set—aresponse means packets are allowed through even if theyare not part of a previously established session).]1.3.7 Place the database in an internalnetwork zone, segregated from the DMZ.1.3.7 Verify that the database is on an internal networkzone, segregated from the DMZ.1.3.8 Implement IP masquerading toprevent internal addresses from beingtranslated and revealed on the Internet,using RFC 1918 address space. Usenetwork address translation (NAT)technologies—for example, port addresstranslation (PAT).1.3.8 For the sample of firewall and router components,verify that NAT or other technology using RFC 1918address space is used to restrict broadcast of IPaddresses from the internal network to the Internet (IPmasquerading).1.4 Install personal firewall software onany mobile and/or employee-ownedcomputers with direct connectivity to theInternet (for example, laptops used byemployees), which are used to access theorganization’s network.In PlaceNot inPlaceTarget Date/Comments1.4.a Verify that mobile and/or employee-ownedcomputers with direct connectivity to the Internet (forexample, laptops used by employees), and which are usedto access the organization’s network, have personal firewallsoftware installed and active.1.4.b Verify that the personal firewall software is configuredby the organization to specific standards and is not alterableby mobile computer users.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 16Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parametersMalicious individuals (external and internal to a company) often use vendor default passwords and other vendor default settings to compromisesystems.
These passwords and settings are well known by hacker communities and are easily determined via public information.PCI DSS RequirementsTesting Procedures2.1 Always change vendor-supplieddefaults before installing a system on thenetwork—for example, include passwords,simple network management protocol(SNMP) community strings, and eliminationof unnecessary accounts.2.1Choose a sample of system components, criticalservers, and wireless access points, and attempt to log on(with system administrator help) to the devices using defaultvendor-supplied accounts and passwords, to verify thatdefault accounts and passwords have been changed. (Usevendor manuals and sources on the Internet to find vendorsupplied accounts/passwords.)2.1.1 For wireless environmentsconnected to the cardholder dataenvironment or transmitting cardholderdata, change wireless vendor defaults,including but not limited to default wirelessencryption keys, passwords, and SNMPcommunity strings.
Ensure wireless devicesecurity settings are enabled for strongencryption technology for authenticationand transmission.In PlaceNot inPlaceTarget Date/Comments2.1.1Verify the following regarding vendor defaultsettings for wireless environments and ensure that allwireless networks implement strong encryptionmechanisms (for example, AES):Encryption keys were changed from default atinstallation, and are changed anytime anyone withknowledge of the keys leaves the company orchanges positionsDefault SNMP community strings on wirelessdevices were changedDefault passwords/passphrases on access pointswere changedFirmware on wireless devices is updated to supportstrong encryption for authentication andtransmission over wireless networks (for example,WPA/WPA2)Other security-related wireless vendor defaults, ifapplicablePCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 17PCI DSS RequirementsTesting Procedures2.2Develop configuration standards forall system components.
Assure that thesestandards address all known securityvulnerabilities and are consistent withindustry-accepted system hardeningstandards.2.2.aExamine the organization’s system configurationstandards for all types of system components and verify thesystem configuration standards are consistent with industryaccepted hardening standards—for example, SysAdminAudit Network Security (SANS), National Institute ofStandards Technology (NIST), and Center for InternetSecurity (CIS).In PlaceNot inPlaceTarget Date/Comments2.2.b Verify that system configuration standards includeeach item below (at 2.2.1 – 2.2.4).2.2.c Verify that system configuration standards areapplied when new systems are configured.2.2.1 Implement only one primaryfunction per server.2.2.1 For a sample of system components, verify thatonly one primary function is implemented per server. Forexample, web servers, database servers, and DNS shouldbe implemented on separate servers.2.2.2 Disable all unnecessary andinsecure services and protocols (servicesand protocols not directly needed toperform the device’s specified function).2.2.2 For a sample of system components, inspectenabled system services, daemons, and protocols.
Verifythat unnecessary or insecure services or protocols are notenabled, or are justified and documented as to appropriateuse of the service. For example, FTP is not used, or isencrypted via SSH or other technology.2.2.3 Configure system securityparameters to prevent misuse.2.2.3.aInterview system administrators and/or securitymanagers to verify that they have knowledge of commonsecurity parameter settings for system components.2.2.3.b Verify that common security parameter settingsare included in the system configuration standards.2.2.3.cFor a sample of system components, verify thatcommon security parameters are set appropriately.2.2.4 Remove all unnecessaryfunctionality, such as scripts, drivers,features, subsystems, file systems, andunnecessary web servers.2.2.4 For a sample of system components, verify that allunnecessary functionality (for example, scripts, drivers,features, subsystems, file systems, etc.) is removed.
Verifyenabled functions are documented and support secureconfiguration, and that only documented functionality ispresent on the sampled machines.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 18PCI DSS RequirementsTesting Procedures2.3Encrypt all non-consoleadministrative access. Use technologiessuch as SSH, VPN, or SSL/TLS for webbased management and other non-consoleadministrative access.2.3For a sample of system components, verify that nonconsole administrative access is encrypted by:Observing an administrator log on to each systemto verify that a strong encryption method is invokedbefore the administrator’s password is requested;Reviewing services and parameter files on systemsto determine that Telnet and other remote log-incommands are not available for use internally; andVerifying that administrator access to the webbased management interfaces is encrypted withstrong cryptography.2.4Shared hosting providers mustprotect each entity’s hosted environmentand cardholder data.
These providers mustmeet specific requirements as detailed inAppendix A: Additional PCI DSSRequirements for Shared Hosting Providers.2.4Perform testing procedures A.1.1 through A.1.4detailed in Appendix A: Additional PCI DSS Requirementsfor Shared Hosting Providers for PCI DSS assessments ofshared hosting providers, to verify that shared hostingproviders protect their entities’ (merchants and serviceproviders) hosted environment and data.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCIn PlaceNot inPlaceTarget Date/CommentsOctober 2008Page 19Protect Cardholder DataRequirement 3: Protect stored cardholder dataProtection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intrudercircumvents other network security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable andunusable to that person.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
