Are you sure you do not store any payment card data or PII (personally identifiable information) in some MySQL database?

The first step in protecting credit card and customer data is to know what sensitive data you really store, classify what you have and set up the appropriate security controls.

Here is a policy for any merchant or payment processor who want to achieve and sustain PCI DSS 2.0 compliance and protect customer data.

I. Introduction

You need to identify and apply controls to the data types identified in this policy. The data types identified below are considered digital assets and are to be controlled and managed as specified in this policy while retained or processed by the organization. You should identify and inventory all systems that store or process this information and will audit these systems on a semi-annual bases for effectiveness of controls to manage the data types.

II. Background

The Payment Card Industry (PCI) Security Standard is a requirement for all financial institutions and merchants that use or process credit card information. This security standard is designed to help protect the integrity of the credit card systems and to help mitigate the risk of fraud and identity theft to the individuals who use credit cards to make purchases for goods and services.

The PCI Security Standard was originally introduced by by VISA as the Cardholder Information Security Program (CISP) and specified the security controls for each level or merchant and credit card processor. In 2004 the major brands in the card payment industry agreed to adopt the CISP standard and requirements and a single industry standard in order to reduce the costs of implementation and assessment and increase the rate of adoption. Most organizations were required to meet all requirements of the PCI security standard by June 30th 2005 and it is now an ongoing compliance process with merchants, payment processors and issuers.

III. General Policy Statement

All Credit Card Information and associated data is company confidential and will not be transmitted over public networks in the clear. Credit Card information can only be transmitted encrypted and only for authorized business purposes to authorized parties that have been approved to receive credit card information.

If a little compliance creates a false sense of security then a lot of compliance regulation creates an atmosphere of feeling secure, while in fact most businesses and Web services are in fact very insecure.

Is a free market democracy doomed to suffer from privacy breaches – by definition?

My father is a retired PhD in system science from UCLA who worked for many years in the defense industry in Israel and California. At age 89 he is sharp, curious and wired, with an iPad and more connected and easily accessible on the Net than most people are on their phone.

He sent me this item which turned out to be yet another piece of Internet spam and urban legend that has been apparently circulating the Net for over 10 years and has resurfaced just in time for the US Presidential elections.

A democracy is always temporary in nature; it simply cannot exist as a permanent form of government….The average age of the world’s greatest civilizations from the beginning of history, has been about 200 years.During those 200 years, these nations always progressed through the following sequence:From bondage to spiritual faith;
From spiritual faith to great courage;
From courage to liberty;
From liberty to abundance;
From abundance to complacency;
From complacency to apathy;
From apathy to dependence;
From dependence back into bondage

I told my Dad that it looks and smells like spam. A quick read shows that it is a generalization from a sample of one. The Roman Empire lasted about 500 years. The Ottoman Empire lasted over 700 years. The British Empire lasted about 200 years from 1783 to 1997 (withdrawal from the Falklands). The Russian Empire lasted 200 years and the Soviets lasted less than 80. The Byzantine over 1000 and so on… See http://listverse.com/2010/06/22/top-10-greatest-empires-in-history/.

Rumors of the downfall of American democracy are premature, even though the US is more of a service economy than a manufacturing economy today than it was 200 years ago.

The US has shifted over the past 40 years from manufacturing and technology innovation to technology innovation, retail, outsourcing and financial services. An obvious observation is Apple, with most of it’s manufacturing jobs outside the US, a net worth of a not-so-small country and perhaps, the most outstanding consumer technology innovator in the world. Another, and more significant example is Intel, one of the world’s technology leaders with a global operation from Santa Clara to Penang to China to Haifa and Jerusalem. World class companies like Intel and Apple are a tribute to US strengths and vitality not weaknesses. In comparison, excluding Germany, Poland and a handful of other European countries, the EU is on the edge of bankruptcy.

In this period of time, has the US improved it’s information security in the face of rapidly increasing connectivity, mobile devices and apps and emerging threats such as APT (advanced persistent threats)?

Apparently not.

In the sphere of privacy and information security, the US leads in data security breaches while the EU leads in data security and privacy. The EU has strong, uniform data security regulation, whereas the US has a quilt-work of hundreds of privacy and security directives where each government agency has it’s own system for data security compliance and each state has it’s own legislation (albeit generally modeled after California) for privacy compliance.

The sheer volume and fragmented state of US data security and privacy regulation is practically a guarantee that most of the regulation will not be properly enforced.

On the other hand, the unified nature of EU data security directives makes it easier to enforce since everyone is on the same page.

We would argue that a free market, American style economy results on more technology innovation and economic vitality but also creates a chaotic regulatory environment where the breach of 300 million US credit cards in less than 10 years is an accepted norm. The increase in compliance regulation by the Obama administration does not impress me as a positive step in improving security.

As my colleague, John P. Pironti, president of risk and information security consulting firm IP Architects, said in an interview:

The number-one thing that scares me isn’t the latest attack, or the smartest guy in the street, it’s security by compliance, for example with PCI DSS 2.0

Security by compliance, he said, doesn’t do a company any favors, especially because attackers can reverse-engineer the minimum security requirements dictated by a standard to look for holes in a company’s defense.

In that case, if a little compliance creates a false sense of security then a lot of compliance regulation will create an atmosphere of feeling secure, while in fact most businesses and Web services are in fact very insecure.

Historical data in log files has little intrinsic value in the here-and-now process of event response and mediation and compliance check lists have little direct value in protecting customers.

Software Associates specializes in helping medical device and healthcare vendors achieve HIPAA compliance and improve the data and software security of their products in hospital and mobile environments.

The first question any customer asks us regarding HIPAA compliance is how little he can spend. Not how much he should spend. This means we need simple and practical strategies to reduce the risk of data breaches.

There are 2 simple strategies to reduce the risk of data breach, one is technical, one is management:

Use real time detection of security events to directly protect your customers.

Use real-time detection to directly protect your customers

Systems like ERM, SIM and Enterprise information protection are enterprise software applications that serve the back-office business of security delivery; things like log analysis and saving on regulatory documentation. Most of these systems excel at gathering and searching large volumes of data while providing little evidence as to the value of the data or feedback into improving the effectiveness of the current security portfolio.

Enterprise IT security capabilities do not have a direct relationship with improving customer security and privacy even if they do make the security management process more effective.

This not a technology challenge but a conceptual challenge: It is impossible to achieve a meaningful machine analysis of security event data in order to improve customer security and privacy using data that was uncertain to begin with, and not collected and validated using standardized evidence-based methods

Instead of log analysis we recommend real-time detection of events. Historical data in log files has little intrinsic value in the here-and-now process of event response and mediation.

Use DLP (data loss prevention) and monitor key digital assets such as credit cards and PHI for unauthorized outbound transfer. In plain language – if you detect credit cards or PHI in plain text traversing your network perimeter or removable devices, then you have just detected a data breach in real time, far cheaper and faster than mulling through your log files after discovering 3 months later that a Saudi hacker stole 14,000 credit cards from an unpatched server.

Use your customers as early warning sensors for exploits. Provide a human 24×7 hotline that answers on the 3d ring for any customer who thinks they have been phished or had their credit card or medical data breached. Don’t put this service in the general message queue and never close the service. Most security breaches become known to a customer when they are not at work.

PCI DSS 2.0 has an obsessive preoccupation with anti-virus. It does not matter if you have a 16 quad-core Linux database server that is not attached the Internet with no removable device nor Windows connectivity. PCI DSS 2.0 wants you to install ClamAV and open the server up to the Internet for the daily anti-virus signature updates. This is an example of a compliance control item that is not rooted in a probable threat scenario.

When we audit a customer for HIPAA compliance or perform a software security assessment of an innovative medical device, we think in terms of “threat scenarios”, and the result of that thinking manifests itself in planning, penetration testing, security countermeasures, and follow-up for compliance.

In current regulatory compliance based systems like PCI DSS or HIPAA, when an auditor records an encounter with the customer, he records the planning, penetration testing, controls, and follow-up, not under a threat scenario, but under a control item (like access control). The next auditor that reviews the compliance posture of the business needs to read about the planning, testing, controls, and follow-up and then reverse-engineer the process to arrive at which threats are exploiting which vulnerabilities.

Other actors such as government agencies (DHS for example) and security researchers go through the same process. They all have their own methods of churning through the planning, test results, controls, and follow-up, to reverse-engineer the data in order to arrive at which threats are exploiting which vulnerabilities

This ongoing process of “reverse-engineering” is the root cause for a series of additional problems:

Lack of overview of the the security threats and vulnerabilities that really count

No sufficient connection to best practice security controls, no indication on which controls to follow or which have been followed

No connection between controls and security events, except circumstantial

No ability to detect and warn for negative interactions between countermeasures (for example – configuring a firewall that blocks Internet access but also blocks operating system updates and enables malicious insiders or outsiders to back-door into the systems from inside the network and compromise firewalled services).

No archiving or demoting of less important and solved threat scenarios (since the data models are control based)

Lack of overview of security status of a particular business, only a series of historical observations disclosed or not disclosed. Is Bank of America getting better at data security or worse?

An excess of event data that cannot possibly be read by the security and risk analyst at every encounter

Confidentiality and privacy borders are hard to define since the border definitions are networks, systems and applications not confidentiality and privacy.

There are 5 reasons why credit cards are stolen in Israel. None have to do with terror; 4 reasons are cultural and the 5th is everyone’s problem: “confusing compliance with security“.

I could write a book on mismanagement of data governance and compliance, data security, web server security, web application software security.

In 2003, I got turned on to the notion of using extrusion prevention to prevent data loss. I had the privilege to work with some of the pioneers in data loss prevention and over a period of over 5 years, I evangelized, sold, marketed, implemented and supported data loss prevention solutions in Israel and Europe. In the course of that time, I made thousands of phone calls, met hundreds of prospects and sold a dozen systems. I developed a unique perspective to the data security space working with both vendors and C-level decision makers in a wide variety of verticals from financial services to diamonds and telecommunications.

There is no need to state the obvious common denominators between Israeli companies and their US counterparts who have suffered the ignominy of a large scale credit card data breach: Closing the barn doors after the horses have fled, thinking it won’t happen to them, relying on their Checkpoint firewall to prevent data breaches, erroneously calling an anti-virus threat management, believing their IT outsourcing provider and equating the counting of compliance check list items with effective data security.

In this essay, I will try and enumerate what I believe are the key contributing factors behind the insecurity of most Israeli businesses. Most are inherently cultural to Israel although the last factor (PCI DSS 2.0) is everyone’s problem.

Letting your piss go to your head

The first factor is cultural. It’s called in Hebrew עלה לו השתן לראש. It’s hard to translate this exactly – but a literal translation is “letting your piss go to your head”. Arguably, this may be true for many senior executives, especially those on Wall Street who run billion dollar financial service businesses.

The difference is that in Israel, a colonel who served in the Israeli Air Force and then retired at age 45 on a full military pension to work as a VP in a publicly-held Israeli company that does $50M worth of business has more piss up his head then the CEO of IBM. You are more likely to ascend bodily into heaven than to convince this person to be a security leader, implement robust data governance in his organization and implement strong data security countermeasures. There are many jokes about this in Israel. The one I like the most goes like this: “Why not have sex under an open window in Israel? Because, someone will leap through the window and tell you – move aside, I’ll show you how it’s done“. As far as I can tell, this is also the root cause for Israeli politicians like Ehud Barak, Bibi and Tzipi Livni who believe that they know what is best for the Palestinians. (Letting your success get the best of you is gender-neutral).

The Checkpoint syndrome

The second factor is also cultural. I would label it the Checkpoint syndrome. I believe that the Americans call it “NIH – Not invented here”. It is literally almost impossible to sell an Israeli CIO on the notion of innovative data loss prevention technologies when Checkpoint hasn’t really done much in that space (granted they introduced a DLP software blade for their firewall product in 2010, 7 years after Fidelis, Vontu and Verdasys already had working technology). Port Authority, later acquired by Websense, did indeed have some success in Israel – burning $60M in VC funding and selling about 30 systems in Israel due to a related syndrome that I shall call the 8200 syndrome – which is sort of an Israeli coolness factor – like Roy Hargrove and RH Factor playing funk. A related illness, which is at epidemic levels in Israel, is the Microsoft Monoculture. While Microsoft has correctly pigeonholed data security into data governance the main focus of Microsoft operating systems is access control and when key system management focus is on access control then it becomes difficult for system managers to properly assess the risk from trusted insider threats – insiders who violate security policy simply because they can. עלק אבטחה.

Retaliation instead of mediation

The third factor is political.

Saber rattling is a political gesture and retaliation is not a substitute for proactive threat analysis and premeditated risk mediation.

The Israeli government has threatened to retaliate against the hacker who last week published the credit card details of thousands of Israelis, with one senior official comparing the cyberattack to a “terrorist operation”. Danny Ayalon, the deputy foreign minister, warned that the attack represented “a breach of sovereignty comparable to a terrorist operation, and must be treated as such”. He added: “Israel has active capabilities for striking at those who are trying to harm it, and no agency or hacker will be immune from retaliatory action.”

Oh. I’m getting shivers at the thought of Israeli generals led by Ehud Barak retaliating against hackers.

There are 3 fundamental flaws behind this thinking (assuming someone is actually thinking like this, which may be assuming too much).

Due to the asymmetrical nature of hacking, there is neither payback, nor deterrence value in threatening to send a drone aircraft to shoot a hacker in Mexico/Saudia/Albania/etc….

Israeli leaders have proven track records of threatening but not delivering on their promises (the disengagement from Gaza is a case in point) and then caving in populistic, media-driven, Jewsh-mother driven demands to trade terrorists with blood on their hands for Israelis who were drug dealing (see Elchanan Tannenbaum) or soldiers who failed in their duty (see Gilad Shalit is not a hero). As a result, Israeli leadership credibility in this respect is rather low.

Threatening with retaliation is a low-cost, political do-nothing alternative to a fundamental threat analysis of the vulnerabilities in information systems, online sites and networks and careful, open and thorough implementation of strong data security countermeasures – such as locking down Web servers, outlawing Windows and securing message queue infrastructures used for B2B connectivity.

Legislation without enforcement

Several years ago, I had an interesting sales call with the CSO of Clalit, the big Israeli HMO. I made my pitch for data loss prevention and tied it into the ability of DLP to deliver real-time monitoring and visibility and assure PHI privacy compliance. He laughed at me and said: “Listen, Danny – Israeli has a dozen privacy regulations on the books, all are relevant to PHI, but no one is serious about compliance, so we do what we think we need to do in the limitations of our budget and it is what it is.”

The problem of legislation without enforcement is endemic in Israel from traffic safety to women’s rights to environmental protection: Israel is a country with more legislation and commissions of inquiry than enforcement. Perhaps, a weak system of enforcement and abiding the law may be a vestige of defense mechanisms developed while living in the Diaspora. Certainly – the Eastern European Jews who founded Israel did not come from a background of law, order and compliance. They came from a background of revolution and change.

Compliance without security

Perhaps the time has come to perform a vulnerability assessment of the standard itself.

In very simple terms, the biggest vulnerability of PCI DSS is that it’s about 10 years behind the curve. When people in the PCI DSS Security Council in Europe confess to never having heard of DLP (Data loss prevention) and when the standard places an obsessive emphasis on anti-virus, you know you’re still in Kansas.

Speaking with a senior representative of PCI DSS Security Council in Europe last year, I posed some of these questions and he replied that the situation with merchants is so bad that PCI DSS is “better than nothing”.

That is pathetic isn’t it?

Perhaps we would all be better off taking the day off and hoovering our flats instead of trying to reeducate management, fix political systems, improve our data security and prevent credit card breaches.

This article describes a plan and implementation process for disasterrecoveryplanning. The secret to success in our experience is to involve the local response team from the outset of the project.

Copyright 2006 D.Lieberman. This work is licensed under the Creative Commons Attribution License

The disasterrecovery plan is designed to assist companies in responding quickly and effectively to a disaster in a local office and restore business as quickly as possible. In our experience, participation in the planning and implementation process is more important than the process itself and helps ensure that the local response teams understand what they need to do and that resources they need will be available.

Keywords

DRP – disasterrecovery plan

BIT business impact timeline

ERT emergency response team

BIA business impact assessment

Countermeasures physical or procedural measures we take in order to mitigate a threat

PRT primary response time; how long it takes (or should take) to respond (not resolve)

RRP recovery and restore plan; recovery from the disaster and restore to original state

DR planning is not about writing a procedure, getting people to sign up and then filing it away somewhere. In the BIT (business impact timeline) we see a continuum of actions before and after an incident. In the pre-incident phase, the teams are built, plans are written, and preparedness is maintained with training and audit. After an incident, the team responds, recovers, restores service and assesses effectiveness of the plan.

T=ZERO is the time an incident happens. Even though one hopes that disaster will never strike, refresher training should be conducted every 6 months because of employee turnover and system changes and self-audits conducted by the ERT every 3 months.

Building the DR plan

Build the ERT

Assign a 2-person team in each major office (for small offices with one or two people, then the employee will do it himself) to be the ERT. The people in the ERT need to have both technical and social skills to handle the job. Technical skills means being able to call an IT vendor and being able to help the vendor diagnose a major issue such as an unrecoverable hard disk crash on an office file and print server. Social skills means staying cool under pressure and following procedure in major events such as fire, flooding or terror attack.

In addition to an ERT in each office, one ERT will be designated as “response manager”. The response manager is a more senior person (with a backup person) that will command the local teams during crisis, maintain the DRP documentation and provide escalation.

The local response team becomes involved and committed to the DRP by planning their responses to incidents and documenting locations of resources they need in order to respond and restore service.

DR Planning Pre-incident activities

Kickoff call

The purpose of the call is to introduce the DRP process and set expectations for the local ERT. Two days before the call, the local team will receive a PowerPoint presentation describing DRP, the implementation process and the BIA worksheet. At the end of the call, the team will take a commitment to fill out the worksheet and prepare for a review session on the phone one week later.

Business Impact Assessment (BIA)

In the BIA, the team lists possible incidents that might happen and assesses the impact of a disaster on the business. For example there are no monsoons in Las Vegas but there might be an earthquake (Vegas is surrounded by tectonic faults and number 3 in the US for seismic activity) and an earthquake could put a customer service center in Vegas out of business for several days at least.

Recover and Restore

Recovery is about the ERT having detailed and accessible information about backups – data, server, people and alternative office space. Within 30 days after a disaster, full service should be restored by the ERT working with local vendors and the response manager.
It may also be useful using http://www.connected.com for backup of data on the distributed PC’s and notebooks.

DR Plan Review

The purpose of the call is to allow each team to present their worksheet and discuss appropriate responses with the global response manager. Two days before the call, the teams will send in their BIA worksheet. The day after the call the revised DRP will be posted.

Filling out the DRP worksheets

There are two worksheets the BIA worksheet (which turns into the primary response checklist) and the RRP (recover and restore plan) worksheet, which contains a detailed list of how to recover backup resources and restore service.

Filling out the BIA worksheet.

In the BIA worksheet, the team lists possible incidents and assesses the impact of a disaster on the business. In order to assess the impact of a disaster on the business we grade incidents using a tic-tac-toe matrix.

The team will mark the probability and impact rating for an incident going across a row of the matrix. A risk might have probability 2 and impact 5 making it a 7, while another risk might have probability 1 and impact 3 making it a 4. Countermeasures would be implemented for the 7 risk before being implemented for the 4 risk.

BIA worksheet step by step

Add, delete and modify incidents to fit your business

Grade business impact using the “tic-tac-toe” matrix for each incident.

Set a primary response time (how quickly the ERT should respond not resolve)

Establish escalation path escalate to local service providers and response manager within a time that matches the business impact. Escalate to local vendor immediately and escalate to response manager according to following guidelines:

Risk > 6 within 15

Risk <= 6 and > =4 within 60

Risk < 4 within 2 hours.

Filling out the RRP worksheet.

In the RRP worksheet, the team documents in detail how to locate and restore backups and how to access servers (in the network and physically).

Maintaining the DR plan

DR exercises

Once every 6 months, the response manager will run an unannounced exercise, simulating an emergency. In a typical DR exercise the local ERT will be required to:

Respond to a single emergency (for example earthquake)

Verify contents of RRP check list

Physically locate backups

Self-Audit

After completion of the ER plan the local response team needs to perform periodic self-audits. A member of the local ERT will schedule an audit once every 3 months and notify the response manager by email regarding the date.

The audit should take about 1 hour and will check documentation and backup readiness

Documentation readiness

Make sure telephone numbers of critical suppliers posted at entrance to office. Make sure numbers are current by calling.

Read primary response sheet

Wallet-sized cards with emergency phone numbers and procedures, to be carried by all employees.

Onboard list who is in the office today and who is traveling or on vacation

Without realizing how it had come about, the combat men in the squadron discovered themselves dominated by the administrators appointed to serve them. They were bullied, insulted, harassed and shoved about all day long by one after the other. When they voiced objection, Captain Black replied that people who were loyal would not mind signing all the loyalty oaths they had to. To anyone who questioned the effectiveness of the loyalty oaths, he replied that people who really did owe allegiance to their country would be proud to pledge it as often as he forced them to. And to anyone who questioned the morality, he replied that “The Star-Spangled Banner” was the greatest piece of music ever composed. The more loyalty oaths a person signed, the more loyal he was; to Captain Black it was as simple as that, and he had Corporal Kolodny sign hundreds with his name each day so that he could always prove he was more loyal than anyone else.

“The important thing is to keep them pledging,” he explained to his cohorts. “It doesn’t matter whether they mean it or not. That’s why they make little kids pledge allegiance even before they know what ‘pledge’ and ‘allegiance’ means.”

I think that Data Loss Prevention is great way to detect and prevent payment card and PII data breaches.

Certainly, all the DLP vendors think so. Only problem is, the PCI DSS Council doesn’t even have DLP in their standard which pretty much guarantees zero regulatory tail wind for DLP sales to payment card industry players.

I’m actually impressed that Symantec didn’t manage to influence the PCI DSS council to include DLP in the standard. An impressive display of professional integrity and technology blindness.

A while back, we did a software security assessment for a player in the online transaction space.

When I asked the client and auditor what kind of real time data loss monitoring they have in place, just in case, they have a bug in their application and/or one of their business partners or trusted insiders steals data, the answers where like “umm, sounds like a good idea but it is not required by PCI DSS 2.0”

And indeed the client is correct.

PCI DSS 2.0 does not require outbound, real time or any other kind of data loss monitoring.

The phrases “real time” and “data loss” don’t appear in the standard. The authors of the standard like file-integrity monitoring but in an informal conversation with a PCI DSS official in the region, he confessed to not being familiar with DLP.

Here are a few PCI monitoring requirements.

None of these controls directly protect the the payment card from being breached. They are all indirect controls and very focused on external attackers – not on trusted insiders nor business partners.

Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).

Monitor and analyze security alerts and information, and distribute to appropriate personnel.

Verify through observation and review of policies, that designated personnel are available for 24/7 incident response and monitoring coverage for any evidence of unauthorized activity, detection of unauthorized wireless access points, critical IDS alerts, and/or reports of unauthorized critical system or content file changes.

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:

The system component stores, processes, or transmits cardholder data, or

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 tothe 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 connectivityregardless 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.

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.