ISA_Part-2 Full std

• Payment Card Industry Data Security Standard (PCI DSS) was developed to encourage and enhance payment card account data security and facilitate the broad adoption of consistent data security measures globally

  
• PCI DSS provides a baseline of technical and operational requirements designed to protect account data

  
• 12 principal PCI DSS requirements

  • Install and Maintain Network Security Controls
  • Apply Secure Configurations to All System Components
  • Protect Stored Account Data
  • Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
  • Protect All Systems and Networks from Malicious Software
  • Develop and Maintain Secure Systems and Software
  • Restrict Access to System Components and Cardholder Data by Business Need to Know
  • Identify Users and Authenticate Access to System Components
  • Restrict Physical Access to Cardholder Data
  • Log and Monitor All Access to System Components and Cardholder Data
  • Test Security of Systems and Networks Regularly
  • Support Information Security with Organizational Policies and Programs
• PCI DSS comprises a minimum set of requirements for protecting account data and may be enhanced by additional controls and practices to further mitigate risks, and to incorporate local, regional, and sector laws and regulations

  
• If any of the requirements contained in this standard conflict with country, state, or local laws, the country, state, or local law will apply
• PCI DSS resources available on the PCI Security Standards Council (PCI SSC) website


  • Document Library
  • Frequently Asked Questions (FAQs)
  • PCI for Small Merchants website
  • PCI training courses and informational webinars
  • List of Qualified Security Assessors (QSAs) and Approved Scanning Vendors (ASVs)
  • Lists of PCI approved devices, applications, and solutions

  
• PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE)

  
• Cardholder data


  Primary Account Number (PAN), Cardholder Name, Expiration Date, Service Code
• Sensitive authentication data


  Full track data (magnetic-stripe data or equivalent on a chip), Card verification code, PINs/PIN blocks
• PCI DSS requirements apply to entities with environments where account data (cardholder data and/or sensitive authentication data) is stored, processed, or transmitted, and entities with environments that can impact the security of the CDE

  
• Entities that outsource their payment environments or payment operations to third parties remain responsible for ensuring that the account data is protected by the third party per applicable PCI DSS requirements
• If an entity stores, processes, or transmits PAN, then a CDE exists to which PCI DSS requirements will apply

  
• Even if an entity does not store, process, or transmit PAN, some PCI DSS requirements may still apply
• PCI DSS requirements may not be applicable if the entity does not store PAN
• Examples of when PCI DSS requirements may still apply even without PAN

  • If the entity stores SAD, requirements specifically related to SAD storage in Requirement 3 will be applicable
  • If the entity engages third-party service providers to store, process or transmit PAN on its behalf, requirements related to the management of service providers in Requirement 12 will be applicable
  • If the entity can impact the security of a CDE because the security of an entity's infrastructure can affect how cardholder data is processed, some requirements will be applicable
  • If cardholder data is only present on physical media, requirements relating to the security and disposal of physical media in Requirement 9 will be applicable
  • Requirements related to an incident response plan are applicable to all entities, to ensure that there are procedures to follow in the event of a suspected or actual breach of the confidentiality of cardholder data

  
• PCI DSS includes requirements that specifically refer to account data, cardholder data, and sensitive authentication data. The requirements apply specifically to the type of data that is referenced.

  
• Elements of account data and storage requirements

  • Primary Account Number (PAN) - Storage is kept to a minimum as defined in Requirement 3.2, must be rendered unreadable when stored as defined in Requirement 3.5
  • Cardholder Name - Storage is kept to a minimum as defined in Requirement 3.2, does not need to be rendered unreadable
  • Service Code - Storage is kept to a minimum as defined in Requirement 3.2
  • Expiration Date - Storage is kept to a minimum as defined in Requirement 3.2
  • Full Track Data - Cannot be stored after authorization as defined in Requirement 3.3.1, must be protected with strong cryptography if stored until authorization is complete as defined in Requirement 3.3.2
  • Card verification code - Cannot be stored after authorization as defined in Requirement 3.3.1
  • PIN/PIN Block - Cannot be stored after authorization as defined in Requirement 3.3.1
• If PAN is stored with other elements of cardholder data, only the PAN must be rendered unreadable according to PCI DSS Requirement 3.5.1
• Sensitive authentication data must not be stored after authorization, even if encrypted. This applies even for environments where there is no PAN present.
• PCI SSC supports the use of secure payment software within cardholder data environments (CDE) via the Payment Application Data Security Standard (PA-DSS) and the Software Security Framework (SSF)

  
• PCI SSC secure software programs

  • Validated Payment Application (PA-DSS)
  • Validated Payment Software (the Secure Software Standard)
  • Secure SLC Qualified Vendor

  
• The use of validated payment software does not by itself make an entity PCI DSS compliant. The entity's PCI DSS assessment should include verification that the software is properly configured and securely implemented to support applicable PCI DSS requirements.

  
• If PCI-listed payment software has been customized, a more in-depth review will be required during the PCI DSS assessment because the software may no longer be representative of the version that was originally validated.

  
• Entities are strongly encouraged to keep their software current and updated to the latest software versions available.
• Entities that develop their own software are encouraged to refer to PCI SSC's software security standards and consider the requirements therein as best practices to use in their development environments.
• PCI DSS may apply to a payment software vendor if the vendor is also a service provider that stores, processes, or transmits account data, or has access to their customers' account data.
• All bespoke and custom software that stores, processes, or transmits account data, or that could impact the security of account data or a CDE, is in scope for an entity's PCI DSS assessment.

  
• Bespoke and custom software that has been developed and maintained in accordance with one of PCI SSC's Software Security Framework standards will support an entity in meeting PCI DSS Requirement 6.

  
• PCI DSS requirements apply to the cardholder data environment (CDE) and system components, people, and processes that could impact the security of the CDE.

  
• Examples of system components in scope for PCI DSS


  • Systems that store, process, or transmit account data
  • Systems that provide security services
  • Systems that facilitate segmentation
  • Systems that could impact the security of account data or the CDE
  • Virtualization components
  • Cloud infrastructure and components
  • Network components
  • Server types
  • End-user devices
  • Printers and multi-function devices
  • Storage of account data in any format
  • Applications, software, and software components
  • Tools, code repositories, and systems that implement software configuration management or for deployment of objects to the CDE or to systems that can impact the CDE

  
• The entity must confirm the accuracy of their PCI DSS scope according to PCI DSS Requirement 12.5.2 by identifying all locations and flows of account data, and identifying all systems that are connected to or, if compromised, could impact the CDE.

  
• Segmentation (or isolation) of the CDE from the remainder of an entity's network is not a PCI DSS requirement, but it is strongly recommended as a method that may reduce the scope, cost, and risk of the PCI DSS assessment.
• To be considered out of scope for PCI DSS, a system component must be properly segmented (isolated) from the CDE, such that the out-of-scope system component could not impact the security of the CDE, even if that component was compromised.

  
• If segmentation is used to reduce the scope of the PCI DSS assessment, the assessor must verify that the segmentation is adequate to reduce the scope of the assessment.
• How count data comes into an organization, where it resides within the organization, and how it traverses through various systems within the organization

  Data-flow diagrams illustrate all locations where account data is stored, processed, and transmitted
• Data-flow diagrams support an entity implementing segmentation and can also support confirming that segmentation is being used to isolate the CDE from out-of-scope networks
• If segmentation is used to reduce the scope of the PCI DSS assessment, the assessor must verify that the segmentation is adequate to reduce the scope of the assessment
• Adequate segmentation


  • Isolates systems that store, process, or transmit account data from those that do not
  • Adequacy of a specific segmentation implementation is highly variable and depends on several factors such as a given network's configuration, the technologies deployed, and other controls that may be implemented
• If wireless technology is used to store, process, or transmit account data, or if a WLAN is part of or connected to the CDE, the PCI DSS requirements and testing procedures for securing wireless environments apply and must be performed
• Rogue wireless detection must be performed per PCI DSS Requirement 11.2.1 even when wireless is not used within the CDE and the entity has a policy that prohibits the use of wireless technology within its environment