Avoid Becoming a Security Statistic

Wednesday, October 12, 2011

Konrad Fellmann

07c90faf3632560a12dd6e98069813f2

Avoid Becoming a Security Statistic – Prioritize PCI Goals and Know Your Threats

Over the last few months the Prioritized Approach for PCI DSS Version 2.0 and Verizon 2011 Data Breach Investigations Report were released for our reading pleasure. 

I took a look at the correlation between actual breach statistics within Verizon’s report and the prioritized guidance for complying with PCI DSS requirements and found that it’s spot on. 

Based on data collected from PCI DSS gap and onsite assessments performed by SecureState, I wanted to highlight some typical findings and methods for reducing cardholder data environment risks that are aligned with the most common threats and priorities.

Per the Prioritized Approach, the first goal for securing the cardholder data environment is to “remove sensitive authentication data and limit data retention”.  Basically, identify all locations where cardholder data is store, figure out if you really need it, and identify how long you need it for.  If you can’t find a reason to hold on to it, get rid of it. 

We have seen many situations where organizations hoard data, but have no idea why.  Some of our common findings are a lack of ownership over the business process and no defined retention policies for cardholder data. 

A business owner needs to figure out why the data needs to be kept, who will use the data, and how long it needs to be kept for business, legal or contractual reasons.  Once defined, IT can implement proper controls to protect the data.

I’ve seen many instances where retention policies have been defined, but can’t find anyone or any process that utilizes the data after a transaction has been processed.  The easiest way to reduce the risk of a cardholder data breach is not to store it.  If a breach does occur, not storing the data will greatly reduce the amount of records that can be compromised. 

Many card processors and payment application developers are introducing more and more alternatives to traditional storage.  These include, redirection of web-payment forms to processor sites, end-to-end encryption from the point of sale to the processor, and tokenization schemes that can help to reduce the amount of data stored.  None of these solutions are one-size fits all, so do your homework before going down any of these routes. 

The second goal for securing the cardholder data environment is to “protect the perimeter, internal, and wireless networks”.  So, once an organization has determined that cardholder data is something they need to store, process, and transmit, it can go about locking down access to those systems. 

Based on Verizon’s report, malware and hacking were identified as the biggest threats and resulted in the largest percentage of breaches and compromised records.  As such, it would be wise to include these types of threats in your annual risk assessment and ensure your controls are properly defined to mitigate vulnerabilities that can be exploited through hacking and malicious code.

The top types of malware threats identified were backdoors installed allowing unauthorized remote access and the use of collection agents that would forward data to an external site.  PCI DSS Requirement 1 requires restriction of both inbound and outbound traffic to only that which is necessary. 

Access control lists should be defined which limit traffic based on specific addresses and ports.  In many cases, we’ll find rules allowing open access to the Internet on ports 80 and 443 from systems in the cardholder data environment.  This will not prevent collection agent and backdoor malware from disclosing cardholder data information. 

Segmentation of internal cardholder data systems, explicit and specific ACLs, regularly updated anti-virus software, identification of required ports and protocols, and file integrity management form a layered defense to protect against these types of breaches.  If access to Internet sites is required, proxy servers using a white-listing approach can be effective. 

We’ve found that many organizations can provide evidence of required biannual firewall rule set reviews being completed, but do not have any documentation over what the required ports, protocols, and services are for their cardholder data environment.  If you don’t know what needs to be open, how can you review the rule set and verify that it’s properly restricting access?

On the hacking side, exploitation of backdoors and easily guessed credentials were the top threats with the highest number of breaches and records compromised.  SecureState’s profiling team confirmed that weak passwords are one of the main vulnerabilities that allows for their successful compromise of many client networks.  This is most likely why the PCI SSC has made the changing of vendor defaults a key priority for PCI compliance. 

Organizations should ensure that their security testing and change control processes catch these types of vulnerabilities before systems are placed into production environments.  Third-party conducted penetration testing will also give you an attacker’s view of the exploitable vulnerabilities within your environment.

I’m not trying to re-invent the wheel here.  Just about all of the recommendations identified here are specified as requirements within the PCI DSS.  Organizations need to ensure they are performing risk assessments at least annually and when new systems are put into place to ensure they know what to protect against. 

Sources such as the Verizon Breach Report can help to identify threats that may affect your organization.  I’d like to see organization move away from the mindset that a PCI assessment is just an annual nuisance and move toward maintaining a continually compliant security posture. 

If you’re new to PCI and trying to figure out where to start, we can help you identify the gaps and come up with a prioritized plan for attaining and maintaining a secure and continuously compliant environment.

Cross-posted from SecureState

Possibly Related Articles:
4342
PCI DSS
Information Security
PCI DSS Compliance Storage malware Data Classification Data Loss Prevention backdoor
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.