Document Comparison

PCI-Software-Security-Framework-Glossary-v1_0.pdf PCI-SSF-Glossary-v1_1.pdf
82% similar
9 → 10 Pages
2604 → 3006 Words
20 Content Changes

Content Changes

20 content changes. 14 administrative changes (dates, page numbers) hidden.

Added p. 2
February 2021 1.1 Updates to add and modify terminology to support the Secure SLC Program expansion and the introduction of the Secure Software Standard: Terminal Software Module.
Added p. 4
External communications Any communication method that uses a wireless, local-area network, wide-area network, or a public domain protocol or security protocol to transport data. This includes, but is not limited to, Bluetooth, Wi- Fi, cellular (GPRS, CDMA), or Ethernet, and a serial point-to-point connection that is wireless or through a hub, switch, or other multiport device.
Added p. 5
• Secure Software Requirements and Assessment Procecures (Secure Software Standard) and similar to how it is defined the PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements (PCI PTS POI Standard), firmware is considered as any code within the POI device that provides the protections needed to comply with device security requirements, or that can impact compliance with device security requirements. Firmware may be further segmented by code, as necessary, to meet subsets of device requirements. Other code that exists within the device that does not provide security and cannot impact security

•with the exception of prompt control and secure reading and exchange of data (SRED) applications

•is not considered firmware.

Payment environment Term used to holistically describe all manual and automated processes and systems involved in performing payment transactions.

Payment terminal A PCI-approved POI device.

PCI-approved POI device An electronic transaction-acceptance product that complies with the PCI PTS POI Standard and …
Added p. 9
Software-development personnel The staff or personnel who are involved with the development of software including the design, creation, and maintenance of applications, frameworks, or other software components. Depending on the activities being performed it may include individuals who specify, design, develop, document, test, and fix bugs in software.

Software vendor In the context of the Software Security Framework, an entity that produces software and/or software components for commercial purposes.

Stakeholder Entity affected by the security of the software at any stage during the software’s lifecycle. Stakeholders include entities that use, install, or integrate the software. Stakeholders may also include software vendor personnel, business partners, and other third parties as defined by the software vendor.

Terminal software Any software that is intended for deployment and execution on a payment terminal, and is not “firmware” as defined in the PCI PTS POI Standard.

• Financial Financial transaction card originated messages

• Interchange message specifications for more information.
Modified p. 1
Payment Card Industry Software Security Framework Glossary of Terms, Abbreviations, and Acronyms Version 1.0
Payment Card Industry (PCI) Software Security Framework Glossary of Terms, Abbreviations, and Acronyms Version 1.1
Modified p. 4
EMVCo A global technical body owned by American Express, Discover, JCB, Mastercard, UnionPay, and Visa that facilitates the worldwide interoperability and acceptance of secure payment transactions by managing and evolving the EMV Specifications and related testing processes.
EMVCo A global technical body owned by American Express, Discover, JCB, Mastercard, UnionPay, and Visa that facilitates the worldwide interoperability and acceptance of secure payment transactions by managing and evolving the EMV® Specifications and related testing processes.
Modified p. 4
Execution environment In the context of the Software Security Framework, a collection of services and components relied on by the payment software during operation. It includes all components and services that are used and relied on by the software to make a complete system• for example, the processors, hardware components, networks, operating systems, databases, and cloud platforms (e.g., PaaS and SaaS).
Execution environment In the context of the Software Security Framework, a collection of services and components relied on by software during operation. It includes all components and services that are used and relied on by the software to make a complete system•for example, the processors, hardware components, networks, operating systems, databases, and cloud platforms (e.g., PaaS and SaaS).
Modified p. 4
Federal Information Processing Standard (FIPS) Publication 140-2 A standard that provides four increasing, qualitative levels of security and is related to the Cryptographic Module Validation Program (CMVP), which provides for vendors to submit products to a laboratory to validate cryptographic modules to the FIPS 140- 2 standard and other cryptography-based standards. Products validated as conforming to FIPS 140-2 are accepted by the U.S. and Canadian Federal agencies for the protection of sensitive information (United States) or designated information (Canada).
Federal Information Processing Standard (FIPS) Publication 140-2 A standard that provides four increasing, qualitative levels of security and is related to the Cryptographic Module Validation Program (CMVP), which provides for vendors to submit products to a laboratory to validate cryptographic modules to the FIPS 140- 2 standard and other cryptography-based standards. Products validated as conforming to FIPS 140-2 are accepted by the U.S. and Canadian federal agencies for the protection of sensitive information (United States) or designated information (Canada).
Modified p. 5
Install base The number units of a product or service that are currently implemented and in use.
Install base The number of units of a product or service that are currently implemented and in use.
Removed p. 6
Payment software components Software components of a larger software application that are typically self-contained and often sold, licensed, or distributed independently. Examples of software components include open- source libraries, third-party APIs, and other dependencies that are part of the software architecture.
Removed p. 7
Security objective The security objectives form the primary goal and shape the intention of the control objectives and test requirements in the Software Security Framework.
Modified p. 7
Sampling The process of selecting a cross-section of a group that is representative of the entire group.
Sampling The process of selecting a cross-section of a group that is representative of the entire group. Please refer to the Payment Card Industry (PCI) Data Security Standard Glossary, Abbreviations, and Acronyms for more information.
Modified p. 7
Secure Software Lifecycle (Secure SLC or SSLC) The evolution process of a software application from inception through design, development, deployment, maintenance, and finally decommission. A Secure SLC ensures that security is integrated at all stages of the software lifecycle.
Secure Software Lifecycle (Secure SLC) The evolution process of a software application from inception through design, development, deployment, maintenance, and finally decommission. A Secure SLC ensures that security is integrated at all stages of the software lifecycle.
Modified p. 7 → 8
Seed data (for random number generators) A starting value used to initialize a pseudo-random number generator.
Seed data (for random number generators) A starting value used to initialize a pseudorandom number generator.
Removed p. 8
Software-development personnel The staff or personnel who are involved with the development of secure payment software including the design, creation, and maintenance of applications, frameworks, or other software components. Depending on the activities being performed it may include individuals who specify, design, develop, document, test, and fix bugs in payment software.

Software vendor Entity that produces and sells payment software.
Modified p. 8 → 9
Software security controls Security features and functionality built into payment software or the software’s operating environment to protect against software threats and attacks.
Software security controls Security features and functionality built into software or the software’s operating environment to protect against software threats and attacks.
Modified p. 8 → 9
SSD over-provisioning A technique used by solid state drive (SSD) manufacturers to improve performance by reserving free space. SSD manufacturers reserve an additional percentage of the total drive capacity for over-provisioning (OP) during firmware programming to use in various disk-administration functions.
SSD over-provisioning A technique used by solid-state drive (SSD) manufacturers to improve performance by reserving free space. SSD manufacturers reserve an additional percentage of the total drive capacity for over-provisioning (OP) during firmware programming to use in various disk-administration functions.
Removed p. 9
Stakeholder Entity affected by the security of the payment software at any stage during the software’s lifecycle. Stakeholders include entities that use, install, or integrate the payment software. Stakeholders may also include software vendor personnel, business partners, and other third parties as defined by the software vendor.
Modified p. 9
Stream ciphers Methods to convert plaintext to cipher text one bit at a time.
Stream ciphers Methods to convert plaintext to ciphertext one bit at a time.
Modified p. 9 → 10
Transaction types In the context of the Software Security Framework, may include: authorization (goods and services), cash (ATM), debit adjustment, refund, available funds inquiry, balance inquiry, payment from account, payment to account, etc. See ISO 8583.
Transaction types In the context of the Software Security Framework, may include: authorization (goods and services), cash (ATM), debit adjustment, refund, available funds inquiry, balance inquiry, payment from account, payment to account, etc. See ISO 8583:2003