The Internet of Things (IoT) is a “thing”— and has been for some time. And while there has not been much talk about the IoT in relation to payments and payment security, there should be. According to a recent Payment Card Industry Security Standards Council (PCI SSC) bulletin, the use and deployment of IoT devices is “increasingly crossing over into areas of account-based payments.” This is happening for one of two reasons: either these devices are being deployed where payments are also processed, or they are being rolled out for the purpose of accepting, performing, or authorizing payments on behalf of a user.
Explanations notwithstanding, the bulletin stipulates that “in all cases, when considering deployment of IoT devices, the security of the IoT devices and the payment data needs to be considered throughout the device lifecycle. (The latter) extends from planning and purchasing to deployment, maintenance, and decommissioning.
Asking the Right Questions
The PCI SSC recommends that merchants when planning the purchase and deployment of IoT systems, refer to and seek out full answers for a comprehensive list of questions with a security bent. For example:
- If the device accepts or facilitates payments, how is this capability securely configured for such a function? Is it included in cardholder data flows for the network?
- Does the deployment plan consider how to integrate the IoT devices into the merchant’s environment in compliance with the Payment Card Industry Data Security Standard (PCI DSS)? Is it included in cardholder data flows for the network? This, according to the bulletin, may be required even for devices that do not facilitate payments or are not involved directly in cardholder data flows—depending on how they are deployed.
- Does the IoT device reflect a design in which security is a priority, and has it been tested against relevant standards, such as ANSI/CTA-2088-A?
- Does the device’s vendor guarantee updates for a set period of time? Does it have a record of providing ongoing product security support? How does this jibe with the expected duration of device employment in the merchant’s environment?
- What connectivity does the product require to deliver the features needed for its use and maintenance—including security updates? Is it possible to isolate the product into its own secure network segment?
- If network isolation is required and/or provided, how is that isolation protected from individuals operating the device? For instance, how would an individual be prevented from connecting the device to a different Wi-Fi network or network segment?
- How can the device be securely and properly decommissioned to ensure that sensitive data—like payment data—is cleared before the product leaves the merchant’s control?
The Consumer Technology Association (CTA), in collaboration with the Council to Secure the Digital Economy (CSDE) has published what it calls the “C2 Consensus on IoT Device Security Baseline Capabilities”—or “C2 Consensus” for short. According to the PCI SSC, IoT devices—including, and perhaps especially those that touch the payments realm—should offer a set of baseline capabilities that promote security. These capabilities encompass:
- Device identifiers, i.e., unique values for unique device identification
- Access is controlled through user authentication
- Protection of data in transit via cryptography
- Protection of selected stored data at rest via cryptography
- Leveraging of industry-accepted protocols (i.e., secure, widely used protocols, excluding deprecated versions) for communications to and from the IoT device
- Data validation
- Event logging
- Use of open, published, proven, peer-reviewed cryptographic methods wherever they are employed to protect payment and other data
- Ability to verifiably update devices’ software and firmware, using authenticated patches
- Flexibility for authorized users to securely reconfigure and redeploy a device post-market, especially to return it to factory defaults and securely remove data
Mapping IoT Security Controls to PCI DSS
The bulletin’s authors point out that while the C2 Consensus baseline was not designed specifically for payments and payment security, it can be mapped to (correlated with) PCI DSS requirements for deployment environments. “This mapping is not intended to imply that a device deployed in a PCI DSS-compliant environment meets the C2 Consensus Controls, or that a device meeting the C2 Consensus Controls automatically meets…mapped aspects of (the) PCI DSS,” they note. However, it shows that “requirements for IoT device security capabilities—like those found in the C2 Consensus—can be considered along with the requirements of standards such as the PCI DSS to help inform and secure deployment of IoT devices across the lifecycle of those products.”
More specifically, PCI DSS requirement #2—apply secure configurations to all system components—maps to the secured access called for in the C2 Consensus Control. PCI DSS requirements #3 and #4—protect stored account data and protect cardholder data with strong cryptography during transmission over open, public networks—correlate, respectively, with the protection of data at rest and the protection of data in transit (using industry accepted communications protocols) stipulated in the C2 Consensus Control.
PCI DSS requirement #6—develop and maintain secure systems and software—maps to data validation and system patchability called for in the C2 Consensus Control. PCI DSS requirement #7—restrict access to system components and cardholder data by business “need to know”—correlates with the C2 Consensus call for secured access capability.
There are also correlations between PCI DSS requirement #8—identify users and authenticate access to system components—and the device identifiers cited in the C2 Consensus and between PCI DSS requirement #10—log and monitor all access to system components and cardholder data—and the event logging requirement in the C2 Consensus. Finally, PCI DSS requirement #12—support information security with organized policies and programs—maps to the reprovisioning required by the C2 Consensus.