Notes on PCI Security Update…


The new requirement adds 50 controls, covering five control targets. The following is a high-level view of each goal.

(Photo: Alex via Adobe Stock)

On April 29, 2021, the PCI Committee announced an update to the security software standard, which defines the evaluation and listing standards of various payment software. The PCI committee made some clarifications on the controls in the standard, added additional guidance to several sections, and added a new module specific to terminal software requirements, which is suitable for software intended to be deployed and executed on payment terminals.

The new module specific to the security software standard, Module B, terminal software requirements focus on software for deployment and execution on payment terminals or PCI-approved PIN Transaction Security (PTS) Point of Interaction (POI) devices. A total of 50 controls have been added to the new section, covering five control targets.

Let’s look at each goal from a high level. (Note: “Software” refers to software that is assessed for compliance with standards.)

Terminal software documentation
The main goal of terminal software documentation is to ensure that all aspects of the software are documented. This includes application programming interface (API), user interface (UI), data flow, processing of sensitive data, configuration settings, all input/output, error conditions, encryption algorithms, remote updates, and remote access.

Sensitive data (for example, orbital data) is of particular interest because it refers to three data states recognized in the industry: static/storage, in use/processing, and in transit. In addition, it describes which configuration options affect the security of sensitive data and the definition of methods for safe deletion from storage (temporary and permanent).

Terminal software design
The focus of terminal software design is to ensure that the software does not allow changes to the payment terminal, thereby bypassing security features, functions or features. This control target has a lot of control. Among them:

  • Control objectives ensure that the software is intended to be deployed on specific payment terminals—especially PCI-approved POI devices. Each POI identified in the software documentation must be checked and compared with the PCI SSC approved PTS device list to obtain the matching model, PTS approval number, hardware version, and firmware version number. The software must use the built-in features and functions in the POI instead of implementing its own similar features or functions. The main goal of this is to ensure that external software does not introduce new vulnerabilities or weaknesses in the POI.
  • Open protocols can be used, but only if they comply with the security guidelines/policies of the POI vendor. If open protocols are used, they are not allowed to circumvent or add services or protocols beyond those provided by the payment terminal. This should be documented in the security guide/policy of the payment terminal provider.
  • In addition, the encryption provided by the payment terminal is prohibited from being bypassed and/or disabled by software. The account data shared between the payment terminal and the software is prohibited from being shared with “other” software or software not included in the evaluation in clear/unencrypted state.

Terminal software attack mitigation
The title of this control objective says it all: implement software security controls to mitigate software attacks. Safe software development best practices play a role in this control goal, including validating external input and string values, correct handling of buffers, memory handling and error conditions, and avoiding race conditions.

Terminal software security test
Similar to terminal software attack mitigation, terminal software security testing clearly points out the need to ensure that software is “rigorously” tested for vulnerabilities before each release.

Software developers should have a documented process to test software for vulnerabilities before each update or release. Control testing in this objective continues to emphasize secure software development best practices-testing unnecessary ports or protocols, identifying insecure account data transmission, identifying default credentials, hard-coded authentication credentials, testing accounts or data, and/or invalid Software security control.

Terminal software implementation guide
Similar to the previous PA DSS standard, organizations deploying payment software must provide clear and thorough guidance on the secure implementation, configuration, and operation of the software on payment terminals approved for use with the software.

Navigating in an ever-changing standard environment can be difficult, but if experienced security professionals can combine compliance with overall business goals, they will find that adopting updated compliance protocols is most successful. When it comes to standards issued by PCI SSC, always make sure that the organization that provides guidance is registered with the committee, especially when it performs certification work for your organization.

Sean Smith is the head of Optiv’s PCI consulting services practice and has over 18 years of experience in credit card security and compliance.He is currently the chairman of Optiv’s PCI leadership committee. In addition to promoting quality, he also oversees all PCI projects… View full bio

Recommended reading:

More insights

Related Articles

Back to top button