Real Security goes Beyond Compliance, and Integrates with Validation and Security Processes.
Ecommerce is becoming commonplace for many businesses, as more companies embrace software as a service (SaaS) and platform as a service (PaaS) models. Late last year the Payment Card Industry released version 2.0 of the PCI DSS standards for processing payments online. While millions of businesses learn to understand and adopt the new standards, it’s important to remember that just because your online business is compliant, doesn’t mean it’s secure. These standards were developed as universal guidelines for every business that processes payment card information. Within each of those millions of businesses are unique environments, processes and infrastructure. These variables leave companies open to attack, even after compliance is achieved.
Real security goes beyond compliance, and integrates with validation and security processes. This causes confusion for many organizations as they pursue compliance standards. So let’s break it down. What drives PCI 2.0 compliance?
• Protection of sensitive and classified information. It’s vital that individuals and organizations can rely on the protection of sensitive information including Social Security numbers, credit card numbers, personal information, personal health information and diplomatic and military secrets.
• Industry regulation in the form of the Payment Card Industry (PCI) Data Security Standard (DSS) 2.0.
• The IT industry’s acknowledgement of the need to secure information to protect corporate and trade secrets. Especially now with so much data living in cloud environments.
Once a company has achieved PCI 2.0 compliance, understand that this is just a piece of pie to securing the web entity. The compliance measures simply provide the baseline security that standards controls are designed to deliver –- it does not secure the entire organization from all vulnerabilities that may pose a threat to their environment. An organization’s unique infrastructure or business practices may not directly map to a compliance control often leaving overlooked, unmitigated risk.
Here are some holes you’ll likely need to address after compliance is met to ensure security:
Checkbox Mentality. As organizations undergo PCI compliance and other regulatory compliance audits, their mentality can sometimes be to simply implement a product or technology to satisfy a “checkmark” for each particular control. Just because something is checked off of a list doesn’t mean it was implemented well with the rest of the infrastructure, or sustainably for that matter. Poorly implemented technologies can introduce new risks or not reach their full potential in terms of making an organization more secure. Example: Web application firewalls can be deployed with out-of-the box policies. Applications may require special tuning to prevent certain attacks above and beyond OWASP depending on custom code and functionality requirements. The 6.5 controls in the PCI-DSS 2.0 standards set minimum requirements for vulnerability scanning. There are literally thousands of potential vulnerabilities an application can be vulnerable to.
So, make your own checklist to accompany the one you’re working from the PCI Security Standards Council. This checklist should include all of the processes that will ensure the compliance measures were implemented correctly and are being maintained. Then include a list of vulnerabilities that need to be scanned, going well beyond the minimum. Be sure to include the “least likely” as those are usually the ones that get you.
Web Application Vulnerability Scanning. PCI-DSS 2.0 controls 6.5, 6.6, and 11.2.2 require scanning of externally-facing IP addresses and Web applications on a regular basis. External network scans are to be performed by an Approved Scanning Vendor (ASV) and Web application scans by manual or automated tools. Vulnerabilities should be addressed in a timely manner. Scenario: An ASV runs a scan for an organization on a Web application and the scan comes back clean and compliant. Consider the fact that the post-authentication portions of the Web application are commonly not scanned by ASVs. This leaves tons of potentially unmitigated vulnerabilities that an authorized attacker may be able to exploit, and they know it.
Mobile devices. The PCI SSC recently delisted once approved mobile applications it previously deemed PCI compliant. We all know that mobile devices don’t have firewalls. You could actually be violating the PCI 2.0 standards by processing credit cards over a mobile device. This includes laptops, tablets and smartphones, and chances are you or someone(s) on your team are conducting business over one or more of these kinds of devices at any given time. It’s a good idea to not allow, as a policy, the most critical data get on these devices. If you have to, modify security policies that address mobile devices. For instance: password protect all mobile devices, don’t let employees do work from unsecured networks and make them use a secure encrypted network connection such as VPN.
Compliance is the byproduct of a good security program
The PCI Security Standards Council is straightforward about the distinction between compliance and security, writing in the introduction to PCI DSS Version 2.0, “PCI DSS provides a baseline of technical and operational requirements designed to protect cardholder data.”
The PCI DSS standards simply can’t comprehend and address every risk that exists. Businesses have unique infrastructures and challenges that must be addressed independently of the compliance mandates. Security is a broad spectrum ranging from super secure to super vulnerable. Depending on the regulatory compliance your organization obtains, you can fall somewhere in between. It’s up to the PCI Security Standards Council to ensure organizations processing and storing credit card data are doing their part to address risks common to all organizations in the industry. It’s up to you to ensure your customers’ information is secure.