The Payment Card Industry Data Security Standard (PCI DSS) is no longer a fledgling framework. The thought and process that has gone into the revisions to mature the PCI DSS has created a prescriptive list of controls that any organization would do well to follow. However, even the PCI Security Standards Council steadfastly maintains that the PCI DSS is only a baseline of controls. So let’s go through a thought exercise about additional controls that are not in the PCI DSS but could be used improve the security of your environment.

Using Outbound Proxies

While egress traffic must be identified and documented, this mostly occurs as an academic exercise for documentation and in firewall rules that may be limited in their ability to inspect traffic. Adding outbound proxies for traffic will allow obfuscation of network topology, whitelisting of approved external destinations, validation of the data through content filtering, and provides another layer of security to protect and monitor data moving out of the CDE or a production web environment.

Creating Unique Credentials for Privileged Environments

After investing time and resources to build a segmented environment, such as the CDE or management network, that can be more closely controlled and monitored to protect sensitive data, are you letting your users access that environment with their general User IDs? Attackers that successfully obtain credentials used in non-secured environments can leverage that single User ID to gain access to the secured environments and then begin looking for vulnerabilities that provide privilege escalation. Creating unique User IDs for CDE access reduces the likelihood of credential abuse.

Adding Secondary Access Controls to the CDE

As described above, accounts that can access the CDE without additional controls beyond a passphrase are a security risk. But currently, the PCI DSS only requires that any remote access and non-console administrative access to the CDE use additional authentication factors. This doesn’t address general user access and non-interactive login access into the CDE. Add multi-factor authentication (MFA) or tighten the access lists to specific systems for all accounts accessing the CDE or sensitive systems.

Securing the Development Environment

The effect of not being able to store production data in your development environments is that many of these environments escape the clutches of well-meaning security teams that have to decide where to put their resources. But that doesn’t mean that the development environment doesn’t contain important information to protect. Any code that will be pushed into production is at risk for tampering. Ensure that general security concepts are followed in the development environment, such as least access and system hardening, to protect code before it is pushed to a more secured and monitored environment.

Deploying Runtime Application Self-Protection

In order to address the proliferation of attacks against application vulnerabilities, the PCI DSS introduced the requirement for Web Application Firewalls. Moving that concept closer to the application, Runtime Application Self-Protection (or RASP) provides protection against vulnerabilities specific to the frameworks in use without relying on signature-based pattern matching or creating a network chokepoint. Employing RASP can reduce the impact that coding vulnerabilities have on the security of your application.

Improving your 3rd Party Vendor Management

The PCI DSS does require managing your 3rd party relationships with Service Providers with whom you share cardholder data. A due diligence process is required but not defined. If you are limited to a few high-level, subjective questions about their PCI DSS compliance status and implemented security technology, you don’t have a full picture of the risk you are adding to your organization by allowing the trusted connection. This is especially important now as Software-As-A-Service (and even more perniciously, Security-as-a-Service) is able to be outsourced to newer companies with less than transparent security postures. Dive into the details with your service providers to validate that they are protecting the data you share.

Compliance frameworks are important for measuring certain characteristics of your security program. But even prescriptive programs like the PCI DSS do not cover every security need. For now, all of the controls discussed above can be implemented in a PCI Compliant environment as “above and beyond” controls and improve your overall security posture.