Cybersecurity In-Depth: Feature articles on security strategy, latest trends, and people to know.

New requirements add 50 controls covering five control objectives. Here's a high-level look at each objective.

Sean Smith, Manager II, PCI Compliance Services, Optiv

June 9, 2021

4 Min Read
(Image: Alex via Adobe Stock)

On April 29, 2021, the PCI Council announced an update to the Secure Software Standard, which defines the criteria for various types of payment software for evaluation and listing. The PCI Council made several clarifications to controls within the standard, added additional guidance to a couple of sections, and added its new module specific to Terminal Software Requirements, which applies to software intended for deployment and execution on payment terminals. 

Specific to the new module of the Secure Software Standard, Module B, Terminal Software Requirements focus on software intended for deployment and execution on payment terminals or PCI-approved PIN Transaction Security (PTS) point-of-interaction (POI) devices. In total, the new section adds 50 controls covering five control objectives.

Let's take a high-level look at each objective. (Note: "Software" refers to the software being evaluated for compliance with the standard.)

Terminal Software Documentation 
Terminal Software Documentation has a primary objective to ensure that all aspects of the software are documented. This includes application programming interfaces (APIs), user interfaces (UIs), data flows, handling of sensitive data, configuration settings, all input/output, error conditions, cryptographic algorithms, remote updates, and remote access. 

Sensitive data (e.g., track data) is of particular concern because it references the three industry-recognized states of data: at rest/stored, in use/processed, and in transit. Additionally, it describes definitions for what configuration options can affect the security of sensitive data and the method(s) of secure deletion from storage, temporary, and permanent. 

Terminal Software Design 
Terminal Software Design is focused on ensuring the software does not permit changes to the payment terminal that would allow circumvention of security features, functions, or characteristics. This control objective has a sizable set of controls. Among them:

  • The control objective ensures that the software is intended for deployment on specific payment terminals – in particular, PCI-approved POI devices. Each POI identified in the software documentation must be inspected and compared against the PCI SSC's List of Approved PTS Devices for matching model, PTS approval number, hardware version, and firmware version number(s). The software must use the features and functions built into the POI instead of implementing its own similar features or functions. The primary goal of this is to ensure the external software doesn't introduce new vulnerabilities or weaknesses in the POI.

  • Open protocols may be used but only if they conform to the POI vendor's security guidance/policy. If open protocols are used, they aren't permitted to circumvent or add services or protocols above and beyond those provided with the payment terminals. This should be documented in the payment terminal vendor's security guidance/policy.

  • Additionally, the encryption provided by the payment terminal is prohibited from being bypassed and/or disabled by the software. Account data shared between the payment terminal and the software is prohibited from being shared in a clear/unencrypted state with "other" software or software not included in the evaluation.

Terminal Software Attack Mitigation 
The title of this control objective says it all: The software security controls are implemented to mitigate software attacks. Secure software development best practices come to play in this control objective, including validation of external inputs and string values, proper handling of buffers, memory handling, and error conditions, and avoiding race conditions.   

Terminal Software Security Testing 
Similar to Terminal Software Attack Mitigation, Terminal Software Security Testing clearly calls out the need to ensure software is "rigorously" tested for vulnerabilities prior to each release.

The software developer is expected to have a documented process that is followed to test software for vulnerabilities prior to every update or release. The control tests in this objective continue to highlight secure software development best practices – testing for unnecessary ports or protocols, identifying unsecure transmissions of account data, identification of default credentials, hard-coded authentication credentials, test accounts or data, and/or ineffective software security controls.

Terminal Software Implementation Guidance 
Similar to the previous PA DSS standard, organizations that deploy payment software have to have clear and thorough guidance on the secure implementation, configuration, and operation of the software on the payment terminals approved for use with the software. 

Navigating the ever-changing standards landscape can be difficult, but seasoned security professionals will find the most success in adopting updated compliance protocols, if they can blend compliance with overarching business goals. When it comes to standards published by the PCI SSC, always ensure the organization(s) providing guidance is registered with the council, particularly if it is performing attestation work for your organization.

About the Author(s)

Sean Smith

Manager II, PCI Compliance Services, Optiv

Sean Smith is the head of Optiv's PCI Advisory Services practice, with over 18 years of experience in credit card security and compliance. He currently chair's Optiv's PCI Leadership committee and provides oversight for all PCI projects in addition to facilitating quality assurance measures for the practice.<br /><br />Smith has over 20 years' experience in both consulting and enterprise environments. His experience ranges from small businesses to Fortune 500 corporations in a multitude of industries. He has extensive experience in executive leadership, security technology implementations, vulnerability assessments, penetration testing, auditing, control development, risk and advisory processes. Smith is experienced with multiple regulatory requirements and frameworks including PCI-DSS, HIPAA, HITECH, NIST, HITRUST, ISO 27001 and Sarbanes-Oxley ("SOX").

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights