Reference: Payment Card Industry (PCI) Data Security Standard (DSS) Requirements and Security Assessment Procedures Version 3.2.1 May 2018
The Internet Computer provides incredible capabilities and pushes boundaries in many areas. I have recently been in discussions around using the Internet Computer to store and process cardholder information in accordance with the Payment Card Industry (PCI) Data Security Standard (DSS) Version 3.2.1 May 2018.
I started to look at a scenario in which a customer of an e-commerce site can sign up, store their cardholder info on the service (resident on the IC) and use it when the customer desires to perform a transaction, or to perform recurring payments as authorized. In this scenario, the service provider would store the cardholder info on behalf of the client.
PCI Compliance and Decentralized Nodes: The payment card industry wants to ensure that cardholder info is protected. This requires ensuring canisters operate from a PCI assessed data centre meeting service level agreements for Physical, IT , Information and Personnel security. Canisters execute on multiple nodes, each node being operated by Independent Node Operators – who are the hosting providers in PCI DSS terms. The PCI DSS requires shared hosting providers be assessed for compliance as part of the overall solution.
Complicating matters, nodes may be operated by different Independent Node Operators, each operating potentially as separate legal entities and spread across different geopolitical jurisdictions. Nodes supporting canister execution are allocated dynamically and workload can shift location over time as load dictates, membership changes, or service issues dictate. PCI compliance sets the expectation that hosting providers meet Appendix A1: Additional PCI DSS Requirements for Shared Hosting Providers and are subject to recurring reviews. All this makes achieving PCI compliance a significant challenge.
PCI compliance relies on documentation; and it is unclear if node security documentation would be available to support a comprehensive IT, Information, Physical, Personnel, Administrative and Operational Security review. It is equally unlikely that underpinning agreements with 3rd parties would be available for review. There is no contract between the node providers and the application owning entity (person, company, or DAO) consistent with the decentralized approach on the IC. This approach makes PCI DSS compliance verification daunting.
Non-traditional deployment model. The IC shields the developer from the complexities of dealing with infrastructure. All this is abstracted by the IC running smart contracts on the blockchain. Developers use the DFX command line, the Internet Identity and the NNS web sites. They are not privy to the technical details behind the scenes and below the network layer such as communications, infrastructure components, firewalls, VPNs, and filtering rules. An assessment of the PCI DSS compliance requires the production of network diagrams, confirmation of firewall configurations, cryptographic architecture, configuration settings, filtering rules, configuration management, vulnerability scanning, patch management, evidence of password controls and a review of other controls.
A PCI compliance review would require the Independent Data Centre and the Node Operators to provide detailed information. This information is not expected to be available for review as part of a compliance effort making it difficult to establish PCI DSS compliance by the hosting providers, and ultimately the Dapp. Also, the documentation of infrastructure components used to operate the IC are not likely to be available for review as part of an assessment.
Need for additional cryptography services. PCI DSS requires the use of strong cryptography, sound key management, and protection of keys to ensure cardholder data is protected. Cardholder data would have to be encrypted with strong algorithms such as AES-256 using keys that are stored separately and not linked to an Internet Identity. Encryption Keys and Key Encryption Keys (KEKs) would require secure storage. Key management for the security of cardholder info would need to be designed, documented, implemented and verified. Relying on access control to data stored with the benefits of orthogonal persistence is insufficient. Enabling secure enclaves would not remove the requirement for additional cryptographic protections of the data.
A single SSL Certificate. All communication leverages the same SSL Certificate linked to boundary.dfinity.network. It is unclear how traffic flows through the network past gateways and if it traverses in the clear or in an encrypted manner.
Audit trail needed: Audit event management would have to be built into the application. A log management/review facility, time synchronization and log archival capability would be required by dapps processing cardholder info. Also, there is no mechanism to monitor activity if a 3rd party is granted access to perform maintenance of a canister.
It would be ideal if the scope of the system to be assessed under PCI could be limited to the Dapp components (the canisters), the gateway to canister communications path and reliance on the integrity offered by the blockchain. Perhaps the activation of secure enclaves and shuffling the nodes underpinning the canisters might help limit the scope of a PCI assessment. The application of cryptography may also assist in containing the scope of an assessment.
The Internet Computer’s novel and modern approach pushes the limits of the traditional assessment process. I would be interested in other perspectives as my assumptions may be incorrect or incomplete.