Retailers and financial services are among the first companies deploying OpenStack with software-defined networking – so, from the start, an important design criterion is PCI compliance. Safeguards developed by the Payment Card Industry Security Standards Council are meant to protect cardholder data as merchants and banks process and store it. While the virtualization and automation in OpenStack clouds might seem to make compliance more difficult, used correctly these tools can actually make payment card transactions even more secure.

While PCI compliance is mandatory, the goal isn’t just checking off a list of requirements to get a certificate. The ultimate test is keeping the data safe and preserving customer trust. Recent breaches demonstrate the consequences of failure: millions of card numbers stolen, hundreds of millions of dollars in damages, executives fired and boards facing no-confidence votes from shareholders.

And even if you don’t process payment cards, PCI safeguards can provide guidance for protecting other sensitive data, such as confidential health records, undisclosed financial results, product design secrets or employee Social Security numbers.

The latest PCI requirements were published in April 2015, the Data Security Standard Version 3.1, comprising 12 main requirements, each with numerous sub-requirements. In the context of OpenStack and software-defined networking, several topics warrant particular attention.

Creating isolated network segments is so crucial that it’s among the first design principals called out in the PCI DSS document:

Network segmentation of, or isolating (segmenting), the cardholder data environment from the remainder of an entity’s network is not a PCI DSS requirement. However, it is strongly recommended… Without adequate network segmentation (sometimes called a "flat network") the entire network is in scope of the PCI DSS assessment.

Why this special attention? Because intruders will attack sensitive data via the network, so the more systems subject to compromise on the same network segment, the greater the risk.

A bank CIO recently explained that, across the bank’s dozens of business units, it now runs more than 10,000 distinct applications. Increasingly these applications are accessible not just to employees at terminals, but also to customers via Web and mobile apps. Such external access means that these applications are subject to constant attack. What is the probability that, at any given time, not one of these applications has been compromised? Essentially zero.

This harsh reality means that traditional data center design, with firewalls toward the outside and everything trusted inside, is obsolete and dangerous. Instead, each application must be treated the same way public cloud providers treat each tenant: untrusted and isolated in its own network segment. (One big breach began with the company’s HVAC controllers, raising the question: Why should air conditioning computers have access to credit card computers?)

Why does PCI DSS recommend but not (yet) require network segmentation? Because traditional networking techniques make extensive segmentation ponderous and difficult. In particular, using separate virtual LANs requires extensive configuration of physical switches throughout the data center, subject to human error and, therefore, even worse instability and insecurity. Furthermore, most physical switches have a hard limit of around 4,000 virtual LANs, well below the number of applications in a large enterprise.

No public cloud provider would consider using virtual LANs to isolate its tenants. Instead they construct physical networks that are unperturbed by customer changes, then overlay software-defined networks connecting each tenant’s virtual machines. Adopting this approach in an enterprise data center or private cloud, isolating each application within its own virtual network domain, is called “micro-segmentation.” As SDN tools become widespread, expect micro-segmentation to become a requirement for PCI and best-practice for OpenStack deployments.

PCI DSS Requirement 1.2 specifies that an OpenStack cloud designer must:

Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.

It then provides this definition:

An “untrusted network” is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity's ability to control or manage.

But, as observed in the context of the bank with thousands of applications, the notion of “external” is increasingly meaningless, and the amalgamation of all those applications is increasingly “out of the entity’s ability to control or manage.”

Thus, the only way to comply with this requirement and, more importantly, to safeguard sensitive data, is to separate applications into the smallest possible groups (again, micro-segmentation) and apply firewall-style restrictions between them – a zero-trust approach. Such fine-grained control is only possible with SDN.

PCI DSS Requirement 4.1 specifies that a designer must:

Use strong cryptography and security protocols… to safeguard sensitive cardholder data during transmission over open, public networks.

Encrypting credit card numbers before they traverse the public Internet makes obvious sense. In fact, now nearly everything on the Internet is encrypted, even YouTube videos. But as the notion of safe “internal” networks continues to erode, the requirement to encrypt all data traversing any network will increase. Software-defined networks can already encrypt data streams on demand, and as processor performance continues to improve, such encryption will likely become the default everywhere.

The current PCI DSS version contemplates environments with different levels of human versus computer control, providing this sort of guidance:

This process may be automated or manual or a combination of both.

Meanwhile, a key design goal of OpenStack clouds is to provide a DevOps environment where applications can update their compute instances, storage, and network configuration as needed in a matter of moments. Such rapid response demands complete automation. Perhaps taking humans out of the loop will compromise security?

Humans like to believe our judgment provides a crucial safeguard in a complex system. And at a design level, that’s true. Our ability to imagine unexpected scenarios and devise appropriate responses is indispensable. But for the tedium of ongoing administration, our tendency towards boredom, fatigue, and distraction means that it’s best to hand over control to computers.

Consider a modern assembly line, where a robot can repeat welds with a degree of consistent quality impossible for even the best human technician. New self-driving cars navigate, if anything, too safely, or so it might seem to the impatient humans along for the ride. And baseball strike-zone monitoring systems show that human umpires are wrong about 15 percent of the time.

The same concept applies to OpenStack clouds with software-defined networks: no more relying on humans responding to tickets, manually bringing up compute instances, and stitching them together with a virtual LAN spanning the data center. Instead, automated API calls that are preconfigured and validated can make it happen in moments, without the inevitable lapses that would otherwise compromise stability and security.

The PCI Security Standards Council will continue to publish new versions of its Data Security Standards. These updates will respond to new threats, since attacks will continue as long as billions of dollars flow through payment card systems. And these updates will also flow from new technical capabilities. Requirements can only mandate that which is possible.

OpenStack with software-defined networks introduces new possibilities including micro-segmentation, zero-trust networking for every application, default encryption, and preconfigured and validated automation. All of these tools enhance data protection, so not only do they support PCI compliance today, they lay the foundation for even better security moving forward.