A “system component” is part of the cardholder data environment (CDE) if one of two conditions is met:

1. The system component stores, processes, or transmits cardholder data, or
2. The system component is “connected” to another system component (condition 1)

PCI DSS 2.0 however does not explicitly define what system application “connectivity” means. This is a curious oversight, since the PCI DSS and PA DSS standards are so detailed. Connectivity is the root vulnerability of credit card theft – without connectivity to the systems that store the credit card data, there would never be a data security breach. PCI DSS 2.0 does go into a detailed explanation of what a system component means, in the section: “Scope of Assessment for Compliance with PCI DSS Requirements”:

“System components” are defined as any network component, server, or application that is included in or connected to the cardholder data environment. “System components” also include any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors. The cardholder data environment is comprised of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Network components include but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include, but are not limited to the following: web, application, database, authentication, mail, proxy, network time protocol (NTP), and domain name server (DNS).

Now that we understand what a system component is – what kind of connectivity needs to be addressed in the credit card data security requirements?  Obviously, the standard was written by system administrators and not programmers because the notion of interprocess communications is ignored.  Once we are running online transaction applications in the cloud, the notion of public networks becomes an antiquated given.

I  submit  that application process connectivity must be more rigorously defined in order to reduce data security vulnerabilities in the cloud.  I propose testing 4 conditions of Layer 7 application process connectivity regardless of network Layer 3 connectivity (be it customer premise LAN,  VLAN, WiFi network, public Internet, X.25, VPN or whatever).

I believe that the appropriate place for these conditions would be in the PA DSS (Payment Application Data Security Standard) that is used as a guide for software security assessments of payment processing applications.

1. SaaS Web applications that transmit credit card information Web services,  REST or SOAP, JSON or any other form of serialization using the HTTPS protocol regardless of port number.
2. SaaS application processes that exchange credit card information using remote messaging such as RPC, TCP/IP sockets
3. End point client processes that receive credit card information when communicating to a remote server using the RDP (remote desktop protocol)
4. Any process that receives or transmits data to a virtualized process in the cloud – i.e software  that processes credit card data that runs on a virtual machine.
5. All messages exchanged between two application processes will be encrypted using strong cryptography

As a consumer, having your online banking account credentials stolen — either via phishing or through password-stealing malware — can be a nasty experience, but it is  not a costly one. The federal Electronic Funds Transfer Act (“Regulation E”), limits consumer liability for unauthorized transactions to $50, provided notice is given within 10 business days, or to $500 provided notice is given within 60 business days. Even so, retail banks often will work to make whole those customers who are victims of online fraud.

On the other hand, SMB that bank online do not have consumer protection. The obligations of a commercial bank and their business customers are spelled out in the agreement that both parties sign;  generally business customers agree to notify their bank of any suspicious or unauthorized transactions on the same day that the transaction in question occurs. There is no guarantee that the bank will be able to block or reverse any fraudulent transfers, and since most SMB don’t perform real time transaction or data loss monitoring – the chances of complying with the agreement are slim.