While the latest version of Payment Card Industry (PCI) Data Security Standard (DSS) 2.00 is an improvement,  the scope of system component connectivity is not well-defined:

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