Payment Card Industry (PCI) requirements 6.2 and 6.5.6, formerly best practices, become mandatory requirements for PCI Data Security Standards (DSS) compliance on June 30, 2012!

How will this affect our compliance with PCI DSS?
Organizations will be required to assign risk rankings to newly detected vulnerabilities affecting the Cardholder Data Environment (CDE) as part of the on-going vulnerability identification process established in Requirement 6.2 and as part of their comprehensive Vulnerability Management Program.

Requirement 6.2 states that organizations must “establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.”

When developing a risk ranking or risk classification system, ensure that these systems are based upon industry standards or best practices.  The risk ranking assignment should classify risks in a manner which facilitates prioritization for remediation, such as a three tier model of High, Medium, Low or a decimal scale of 5.0 to 1.0.

What impacts does this have on our in-house or internally developed applications?
When application development is in-scope of an organization’s CDE, Requirement 6.5.6 will obligate testing against vulnerabilities classified as "high" risk as part of the secure application development process.

In essence, you will be required to develop your applications based on secure coding guidelines as required by Requirement 6.5. This includes preventing common coding vulnerabilities in software development processes as outlined within the sub-requirements of 6.5 and industry best practices like the OWASP Top 10. After June 30, you will also need to ensure your secure coding guidelines address “All ‘High’ vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.2).”

How else might this change impact compliance with PCI DSS?
A few other requirements are directly and indirectly affected by 6.2 and 6.5.6 becoming mandatory. They include:
• As new vulnerability issues are identified and risk ranked, you must verify that the system configuration standards and/or minimum security baselines (MSBs) required by Requirement 2.2 are updated.
• When performing quarterly internal vulnerability scans and remediation, you must continue the process until a rescan has passing results or all “High” vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved.
• When performing internal and external scans after any significant change, you must scan\rescan and remediate until:
o A passing result is obtained or all “High” vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved (internal scans).
o No vulnerabilities exist that are scored greater than a 4.0 by the CVSS (external scans).

What to expect from your QSA
When a Qualified Security Assessor (QSA) is engaged to consult on your CDE, complete a PCI Gap Assessment, and/or complete a PCI Audit to issue a Report on Compliance (RoC) they will be looking for additional evidence related to requirements 2.2, 6.2, and 6.5.6. Some of the evidence will include:
• Your organization’s Vulnerability Management Policy
• Your organization’s methodology and process to assign risk ranking or risk classification to identified vulnerabilities
• Your organization’s system configuration standards and/or MSBs and documented change requests or completed changes as new vulnerability issues are identified and risk ranked
• Your organization’s quarterly internal vulnerability scans, rescan, and remediation steps between scans

Ranking risk an increasing priority
It is important to implementing a risk ranking system within your organizations' vulnerability management program and process. Remember, just completing your vulnerability scanning is not a vulnerability management program by itself. Vulnerability Management is an ongoing process to find, categorize, and address vulnerabilities in your environment. By taking proactive measures to ensure that proper controls are in place prior to the June 30 deadline, you can reduce the risk of falling out of compliance with PCI DSS v2.0.

An interesting lawsuit has been filed by a Utah-based restaurant against US Bank after US Bank seized money from the restaurant for, US Bank claims, failure to protect cardholder data. Owners of Cisero’s Ristorante allege the bank forces merchants to sign one-sided contracts that are based on information that arbitrarily changes without notice, and that the bank imposes random fines on merchants based on what seems like arbitrary numbers without providing a sufficient method to dispute fines.

http://m.wired.com/threatlevel/2012/01/pci-lawsuit/

A Complicated Challenge

This lawsuit is the first to really challenge the PCI Data Security Standard. However, I would argue it isn't as much about challenging the PCI DSS as much as it is about challenging what appears to be a lack of notice within contractual agreements with acquiring banks as well as the methods used to impose fines on merchants.

Focus on Consistency

I definitely agree there may be some underlying issues, especially with regard to the consistency of the fines passed down by Card Brands and Merchant Banks alike. The Card Brands definitely need a method to their madness by creating some sort of formula/algorithm based on past actual damages/losses for breach of cardholder information. Obviously, I’m assuming a method such as the one mentioned does not currently exist, which, within Cisero’s counterclaim, appears to be the case. In addition, merchants need to have a way to be able to dispute claims against them, and acquiring banks need to ensure that any changes within contractual agreements are clearly communicated to their merchants.

A Strong Case in the Face of Ignorance

So with all that said, I honestly believe Cisero’s Ristorante has a strong case and, in the end, will be able to retrieve some of the seized money, primarily based on the same reasons organizations get sued for “unfair practices.” However, I do believe there are some pretty ignorant statements made in this article. First and foremost:

“It’s just like Visa and MasterCard are governments,” said Stephen Cannon, an attorney representing the McCombs. “Where do they get the authority to execute a system of fines and penalties against merchants? That’s a very important issue in this case.”

VISA and Mastercard are private organizations. No one is forcing merchants to accept these credit cards. Merchants choose to accept VISA and Mastercard because, from an overall business perspective, it makes sense. Cisero’s Ristorante basically claims that in order to compete, they had to enter into a merchant agreement. This may be so, but in the end, they ultimately CHOSE to accept credit cards. In other words, no one forced them to sign that agreement with US Bank. When a breach occurs, the Card Brands do incur financial impact. To assume anything else is a bit ridiculous. If the Card Brands experienced no sort of financial impact AT ALL with regard to breach of cardholder information, there would be no reason to pass down fines to Merchant Banks. Even if you consider no actual damage or loss to the Card Brands in the event of a breach (which I believe not to be the case), it still takes resources from the Card Brands to deal with a potential breach situation. Either way, it’s the right of the Card Brands to pass down some of the liability to Merchant Banks, whom ultimately pass down liability to their merchants. This makes sense and is seen in many more cases than simply the PCI standard. Upward contractual obligation is not a new term and is certainly not unique to PCI compliance. The problem in this specific case, among many other things, is the fact that 1) No breach of cardholder information was determined by two different forensic companies and 2) the number of unique accounts used to invoke Visa’s Account Data Compromise Recovery (ADCR) process may have been inflated when reported to Visa.

Secondly, the below comment:

“The McCombs assert that the PCI system is less a system for securing customer card data than a system for raking in profits for the card companies via fines and penalties. Visa and MasterCard impose fines on merchants even when there is no fraud loss at all, simply because the fines “are profitable to them,” the McCombs say.”

This is a pretty bold statement without many qualifying comments behind it. The PCI DSS isn’t perfect, we all can agree with that. However, without PCI, organizations wouldn’t do anything at all to secure cardholder data. How do we know this? We know this because in 2008, it costs organizations on average $2.8 million to become compliant with the PCI DSS. Does anyone really think it would have cost organizations this amount of money if they would have simply been implementing security best practices as soon as they made the business decision to accept our personal information? I mean, the PCI DSS isn’t even in line with what is typically considered security best practices. The second reason we know this, is because companies are choosing to do nothing with regard to Privacy right now, even on the verge of looming comprehensive U.S. Privacy legislation. For this same reason, it will cost organizations a significant amount of money in 3 to 5 years when comprehensive privacy regulation is passed within the U.S. (Although probably not as much as PCI, as rest assured, there will be lobbyist sitting on Capitol Hill arguing about how difficult it is to adhere to a new privacy regulation.)

Plus, how can one assert that there is no “fraud loss at all”? Is it possible that we don’t actually know the extent of the breach yet? It can take a couple of years after a cardholder breach for the attacker(s) to start using the breached credit card information in a malicious manner. Why is this? Because it helps to cover up the breach and where it occurred. After a certain number of years, it’s hard to track where the stolen credit card numbers came from.

Again, many people want to pick on the PCI. However, compliance mandates are necessary to force organizations’ hands in doing something with regard to protecting our information. There does, however, need to be a more consistent fine structure, and merchants should be able to execute their right to argue any fines passed down to them.

Transparency Needed before It’s Too Late

To summarize, although the PCI DSS is a necessary evil, so to speak, in this specific case, I actually do side with Cisero’s Ristorante but only because of the aforementioned reasons. There simply is not enough transparency right now with regard to PCI fines, and Merchant Banks are not doing a good enough job enforcing contractual requirements on their merchant, until after it is too late.

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.  Last month, David Sopata provided a great overview of the Prioritized Approach in his latest blog posting.  To build on and continue that topic, 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 our own PCI DSS gap and onsite assessments, 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 stored; 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’ve 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.  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 on 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 allow 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 organizations 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, SecureState can help you identify the gaps and come up with a prioritized plan for attaining and maintaining a secure and continuously compliant environment.

When an organization is faced with the task of implementing PCI compliance for the first time, it can be very difficult to understand where to start. In most cases, organizations do not understand their scope or the options that they currently have to reduce their scope. Understanding this criteria can save time, money, and additional resources needed to meet PCI compliance. This is where SecureState or another QSA company would come in to perform a PCI Gap Assessment to understand at a high-level how PCI would apply to their current environment. After the gaps are identified, the organization is still stuck with the universal question of “How do we fix it?”

I work with many organizations that have to deal with implementing PCI controls and they always go straight to writing the policies and procedures. I am really not sure what the reasoning is behind this. It may be that writing policies and procedures is the most boring part to them and they want to get it over with right away. Maybe it is because they figure if they write the policy now they can build the rest of their PCI controls and hold to that policy. What really happens is that the policies and procedures end up being changed and revised so many times that it would have been better to write the policy last and describe their environment and what they do. Additionally, organizations will start implementing security controls on all of their systems throughout the company without really knowing what systems should be in scope or which systems should not be in scope for PCI. Hence, the PCI DSS Prioritization Document and Tool was developed.

The PCI SSC (the council) came up with this prioritization approach during the PCI DSS version 1.2. It was meant to help organizations set a starting point, milestones, and provide a high-level roadmap. Granted, even the PCI Council stipulates that this method may not fit within your given organization; however, all requirements must be met for compliance. Not only was the prioritization approach created to give organizations a place to start and milestones to follow, but it was also developed to provide the fastest way to reduce PCI Risk. Just recently in May, the PCI Council has updated the prioritization approach document and tool for PCI DSS 2.0.

So what are the six milestones that council came up with? They are as follows:
1. Remove sensitive authentication data and limit data retention.
2. Protect the perimeter, internal, and wireless networks.
3. Secure payment card applications.
4. Monitor and control access to your systems.
5. Protect stored cardholder data.
6. Finalize remaining compliance efforts, and ensure all controls are in place.

While looking at the order of the milestones, they do make some logical sense. The first one starts with the removal of sensitive authentication data and limit data retention. The goal of this milestone is to get rid of any type of prohibited authentication data, such as the three (or four for American Express) CVV code or full magnetic track data from the credit cards. It might even make sense to delete all cardholder data all together (tokenization anyone?). Maybe there is no need to store cardholder data (CHD) within your organization after an order or transaction has been processed. This would also be the time when a discovery process may be performed to delete CHD from systems that should not have CHD, such as employee desktops, applications, or systems that really do not need to store CHD for any business process. After the unneeded CHD is removed, we can start identifying the systems that are in scope for PCI and start drawing the borders around them.

The second milestone is about drawing the borders around your PCI environment and putting in proper segmentation around your systems. This is where the organization can reduce their PCI compliance even further by segmenting theses systems by using firewalls and router Access Controls Lists (ACL). These firewall and/or router ACLs should be very granular right down to an IP address and TCP/UDP port level. This is how PCI allows organizations to reduce their PCI compliance efforts and make it a more manageable environment. This is also when it would be a good time to start performing security assessments such as Vulnerability Scans and Penetration Tests.

After segmenting the environment and reducing it to only include the systems that store, process, and/or transmit CHD, we can start applying the security controls and hardening techniques to secure these systems. The third milestone is all about securing these systems. This might include turning off unneeded services functions that are used by those systems and standardizing the systems to ensure they are all at some sort of security baseline. Additional vulnerabilities may have been found during the Assessments performed during the second milestone. These will have to be addressed and fixed as well.

The fourth milestone is about implementing logging and monitoring of the systems. After the systems have been hardened, logging and monitoring must be put in place to alert and report on anomalies within the environment. Understanding what “unusual behavior” is within the environment can be a very difficult task to undertake. There are many solutions out there but not knowing what systems are in scope, not having proper segmentation in place, and not turning on the proper logs for the systems could make this area costly and ineffective by wasting time, money, and resources. Additionally, trying to control access can produce the same effects without knowing what systems are in scope and knowing the capabilities of each system.

After securing the systems and implementing logging and monitoring, it is time to then start securing the data that resides on the systems. This is what the fifth milestone is about, ensuring that the CHD that is required to be stored is also protected. This includes implementing proper encryption and key management processes for the systems in scope. In many cases, key management tends to be the hardest area that most organizations struggle with when it comes to encryption.

Now comes the final step, documenting what you have done. The sixth milestone is about Policies and Procedures and making sure that you have all of them in place. Additionally, like any methodology, there might have been a few road blocks where something had to be skipped to keep the project moving. This is where you would tie up any of those additional “loose-ends.”

Whether you are just about to implement PCI in an environment or in the middle of a PCI implementation project, it might be time to take a step back and ask “Am I following the right approach?”

There have been numerous news stories about employees stealing credit card information before it is even entered into your information systems.  These are usually occurring out on the sales floor.  You can be fully compliant with the PCI DSS, but most of the offenses we are talking about occur outside the scope of what those requirements are designed to protect against.  The following types of scenarios are happening every day at merchants worldwide:

-          Wait staff and cashiers colluding to collect or skim card numbers from patrons for personal gain.

-          Cashiers taking credit cards that have been accidentally left behind and then using them.

-          Criminal networks using wait staff to collect card numbers with hand-held skimmers.

-          Cashiers writing down credit card information or making carbon copies of credit cards.

The Verizon 2010 Data Breach Investigations Report found that 48% of breaches are due to internal agents and 51% of those are perpetrated by regular employees or end-users.  The University of Florida conducted an inventory shrinkage study in 2009, and found that the highest source of inventory shrinkage, 43%, was due to employee theft.  What are these figures telling us?  That the risk of having malicious insiders within your organization is relatively high and we should probably do something to try to reduce it.

What’s going on here?

Not all employees are bad, of course; some of them just succumb to temptation out of desperation, and because committing credit card fraud or stealing a few numbers is easy to do.  Criminal networks like to approach lower paid service staff such as cashiers, bartenders, and wait staff because it can be easy to coerce them to hand over a few card numbers for $50 a pop.  Maybe some people just like the thrill that goes with it.  Others just do not have any money to spend and figure it will be more convenient to use someone else’s funds.  Just like with any other crime, there needs to be means, opportunity, and motive.  Let us define these and see how they apply to credit card theft.

Means – Does someone have the ability to steal credit card information? What do they need to do this?  A cashier or waiter armed with a low-tech device such as pen and paper or a high-tech handheld skimmer has the tool required to commit the crime.  Here are a few shots of what these may look like:

Opportunity – Does someone have the chance to steal credit card information?  Every time a customer hands over their credit card to make a payment, an opportunity presents itself.  Think about every time you put your card in a folio on a restaurant table and watch the waitress take off into the back to settle your bill.  Is there a difference when you hand over your credit card at a checkout counter and see the cashier making a transaction?  Have you ever even thought about it?

Motive – What are the reasons someone would steal credit card numbers?  Criminals always have different motives for their crimes, so a specific motive is hard to detect and identify before the crime is actually committed.  Examples of popular motives include: Low wages, disgruntled working conditions, quick access to money in desperate times, etc.

How can this affect my business?

While the percentage of insider theft of credit card data is pretty high, the actual number of reported card numbers that have been compromised through employee skimming and theft is low compared to those due to breaches of information systems containing central repositories of credit card data.  Does that mean we should ignore it?  Not at all.  Imagine how easy it is to do, and the likelihood that many instances of these crimes go unreported because they are not detected by the cardholder.  Some people don’t check their statements thoroughly and some criminals are smart enough to try to make their malicious activities as unnoticeable as possible by making only small charges or just selling off the information.

Cardholders are typically not liable for unauthorized charges; however, it could take time for someone to discover that they have fraudulent charges on their account.  It is very inconvenient to go through the process of reporting the fraud, monitoring your credit report, getting a new credit card, etc.  Be honest: if you found out where your card number was stolen you’d most likely be a bit upset and use a lot of expletives when talking about that shop or restaurant in the future.  You may decide you don’t want to shop or dine there anymore, and you’ll probably tell a lot of people about what happened, where it happened, and why you don’t think it’s safe to shop there anymore.  Do you think this can have any ill effects on the organization’s reputation?  What about future revenue?  How about any financial or legal liability?  Potentially, the answer could be yes to all of these questions.

What can I do?

A multi-pronged approach is recommended to help to reduce the risks of credit card skimming and theft by insiders at the point of customer interaction.  The approach includes a comprehensive awareness program for staff and managers, visual monitoring, and background checks.

Awareness: Reduce the Means – Employees and managers that interact directly with customers at the point-of-sale need to understand what to look for, who to report incidents to, and what the consequences are for this type of theft.  There are additional activities that should be done to fight card theft: develop, implement, and enforce policies that discuss what is required of personnel who handle credit card information.  Provide the employees with periodic training and give them examples of what to look for such as suspicious activity, identification of skimmers, or other unauthorized devices at the point of sale.  Report and prosecute the offenders to ensure everyone knows the consequences.  A few resources that you can use and reference include the following:

-          PCI Security Standards Council Information Supplement: Skimming Prevention – Best Practices for Merchants

-          Visa Data Security Bulletin: How to Protect Your Business and Your Customers from Data Fraud

Visual Monitoring: Reduce the Opportunity – When people know they are being watched, they tend to curb their malicious behavior or at least think twice about it.  Cameras can be set up to watch the areas where transactions take place.  Perform credit card clearing processes in public areas.  For example, restaurants should have the staff clear the transactions at the table using authorized mobile devices or at a point of sale that is in clear view of the patrons.  Do not make them go into a back area where no one can see what they are doing.  Try using systems and processes where the credit card does not leave the customer’s hand.  If they swipe it themselves, it can’t be physically stolen.

Background Checks: Reduce the Motive – It is interesting to note that PCI DSS requirement 12.7 does not make background checks a requirement for personnel who have access to only one card number at a time such as cashiers, waiters, etc.  Fortunately, many of the retailers we’ve assessed do have some type of process in place for employees at the point of sale mainly due to loss prevention practices.  The National Retail Mutual Association (NRMA) maintains a Retail Theft Database that can be used by merchants to conduct retail related background checks.  Information from member companies is collected and shared to report on incidents including credit card theft.  Many of the employees identified in the reports have no criminal records so this is a great tool to identify high-risk personnel before they are hired.  It is also a good idea to ensure your managers maintain good working relationships with their staff and try to identify when they are having problems that affect their performance and attitude.  If employees feel respected and valued, they’ll do the same for the organization.

How can SecureState help?

As always, SecureState is here to help if you have any questions or need assistance in developing and implementing comprehensive PCI and cardholder security controls.

By Konrad Fellmann

At the annual PCI Community Meeting in September, the PCI Security Standards Council (SSC) made it clear that interpretation of the standard and requirements has not been performed in the same manner throughout the industry. Some of the goals of the new standard are to improve verbiage in order to clarify the intent of individual requirements and understanding how to scope your cardholder data environment. From my review of the Payment Card Industry (PCI) Data Security Standard (DSS) version 2.0, things are definitely clearing up.

That said, a couple of weeks ago the PCI SSC released the latest versions of the Self-Assessment Questionnaires (SAQs) in alignment with version 2.0 of the PCI DSS. Not a big deal; of course, the SSC would need to update the SAQs to ensure they have the same clarifications and additional guidance that PCI DSS 2.0 has been updated with. However, a new SAQ has now been thrown into the mix: SAQ C–VT. SAQ C-VT has been specifically developed for merchants that are using secure web-browser based connections to manually enter and submit payment information to a service provider or processor. Like all the other SAQs, it provides a subset of requirements that apply to a specific process that is being performed.

What’s the issue? Well, it seems there has been some confusion in the PCI community in determining which PCI requirements actually applied to web-based virtual terminals. Doing a search on virtual terminals brings up a lot of links to various service providers that provide ‘virtual terminal’ services for merchants. Some of these providers are putting information out that states you would only need to complete SAQ A if you use these services. Well, we have some pretty definitive new guidance that increases compliance requirements around using a virtual terminal type of service to process credit card transactions.

If you are going from SAQ A to SAQ C-VT, you could have some work ahead of you to ensure that you are still compliant. SAQ A revolved around some physical security and policy requirements. You basically just needed to ensure you were using a compliant service provider. At a high level with SAQ C-VT, you’ll need to isolate those virtual terminal systems, do some system hardening, use anti-virus, and perform patch management on top of the SAQ A requirements.

I’ve heard arguments that this is just like someone making a payment online at home, so why is it in scope? Because those people making purchases through you are entrusting their card data to your organization. By processing and transmitting credit card information on behalf of a consumer, you need to ensure those systems are secure. For example, what if someone chose to put some malicious code containing a key logger on the PC that is using a virtual terminal? Without proper firewall access control rules, patch management, and anti-virus, that type of breach would go undetected. Even though the data is encrypted in the secure virtual terminal session, it’s not as it is entered from the keyboard.

This is not a change to the PCI DSS, just an effort by the SSC to clarify what the intent of the DSS always was. In my opinion, it makes scoping these types of processes during an on-site assessment much more black and white. Remember, PCI DSS 2.0 explicitly states that you must reassess the scope of your cardholder data environment at least annually, so make sure you identify processes that use virtual terminals for credit payments and include those in your scope.

By Konrad Fellmann

Too often I, as well as many of my co-workers, go into a client and throughout whatever assessment I am working on, general questions come up like, “when’s the last time you’ve had a pen test?” And the client responds, “Ohhh, we do those annually with ‘Some Corporation.’ ” And after looking at ‘Some Corporation’s’ website and seeing what they consider to be a penetration test, I am again disgusted to see that they show up with a vulnerability scanner, run it, validate some findings, and are off to their next client.


Now I know these are some brash comments made toward some random security companies, but let’s be honest here: If you’re going to do something, do it right the first time and provide your client the value of the assessment they paid for. Additionally, give the client what they paid for. If I go to a salesman to buy a sports car and he tries to sell me a Honda Civic, I’m going somewhere else to get what I asked for. On the other side of the coin is the fact that a lot of companies that want a penetration test don’t really understand what it is to begin with. It seems to me that gone are the days of true pen testing when the dreaded “Red Team” shows up to strike real fear into the hearts and minds of Security Practitioners at Fortune 1000 companies.


Any kid in their parent’s basement with savvy computer skills can fire up a Nessus scanner, Web Application Scanners, or Qualys Guard against a network and some of those people can actually interpret the results to make sense out of them. Trust me, everyone on SecureState’s Profiling Team can do that with their eyes closed, but how many security companies out there can actually run a legitimate pen test? I’m not calling anyone out and challenging them, but in all reality, I just want to know how many companies are willing to admit that what they call a “Penetration Test” is actually just a vulnerability assessment? Even worse is the number of companies who perform so called “penetration tests” and truly believe that a vulnerability assessment is the same thing as a pen test.

So let’s all be clear here: a true penetration test is over 85 percent manual and the remaining 15 percent can be a vulnerability scanner to get some other findings in a report in order to provide additional value to the client. And let’s also define manual attacks as to not be ruling out all tools. Using a port scanner is way different than using nCircle, Qualys, or Nessus. Automated scanners like these are the tools that don’t really help a pen test. And just because you use a tool like the Metasploit Framework and many of the tools in Back|Track 4, doesn’t mean you are running a vulnerability scanner. NMAP has the ability to run scripts as well, but again, it doesn’t belong in the Vulnerability Scanner category.

Many times, companies perform Attack and Penetration's due to compliance, or potentially other reasons, which is a bad idea. It gives those companies the opportunity to choose malicious compliance over the desire for truly assessing the security of the entire company. Malicious compliance is a term used when companies do the bare minimum in order to achieve a stamp of approval for whatever standards they are trying to satisfy the needs of. When companies choose to perform pen tests on only their systems affected by compliance, such as PCI or HIPAA systems, they are missing entire networks of systems which aren’t tested. When this happens, companies aren’t getting the true value of what a Pen Test can provide.

SecureState is a trend setting company, and this is where we are going to step in and say, “We Pen Test!” The PCI DSS Council has at least defined what they consider a penetration test. In section 11.3 the Council defines it to be: “vulnerability assessment simply identifies and reports noted vulnerabilities, whereas a penetration test attempts to exploit the vulnerabilities to determine whether unauthorized access or other malicious activity is possible.” Even the EC Council states that, “Penetration testing simulates methods that intruders use to gain unauthorized access to an organization’s networked systems and then compromise them. Penetration testers may use proprietary and/or open source tools to test known technical vulnerabilities in networked systems. Apart from automated techniques, penetration testing involves manual techniques for conducting targeted testing on specific systems to ensure that there are no security flaws that may have gone undetected earlier.”

The SecureState Profiling Team utilizes lower risk vulnerabilities in some systems with additional vulnerabilities in other systems and links them together into larger attacks. By pulling off an attack in this fashion, the Profiling Team utilizes what is called the Vulnerability Linkage Theory in which we can show why it's important to maintain system baselines and other security measures. The Vulnerability Linkage Theory shows how the attack was pulled off by coupling vulnerabilities in many systems to result in the end compromise. For instance, username enumeration from a website, coupled with a brute force attack on the mail system, could allow SecureState to access mail from a company. From here we can email the tech support team and social engineer them into divulging information on how to access the corporate VPN and voila: access to the internal corporate network. There is no way a vulnerability scanner can do that.

Penetration tests zero in to specific systems in order to break in and see what information can be divulged. Pilfering computers and file shares will explain the benefits of Pen Tests by finding the important documents and unencrypted data. Even finding password protected Microsoft Office files can be cracked to release potentially serious data about a company we’re hacking into. Pen Tests can also be used by Security Departments to show why things need to be fixed and get budget to move forward.

There are conflicting views on Pen Tests and Vulnerability Scans. Pen Tests aren’t performed to find vulnerabilities; they are done in order to compromise systems and networks. The main difference between the two is that in a pen test the attackers are actually exploiting vulnerabilities in systems, adding user accounts, and compromising machines across the network. A full or total compromise, which means total control over the entire network, is the end goal of a pen test. Throughout a pen test, the attackers will inevitably generate a list of findings. Many of these findings may be the same as what a vulnerability assessment will also come up with, but there are many vulnerabilities that scanners just can’t find, which leads to the fact that tools can’t think; consultants can. Consultants are able to interpret results and decide on how to use them in order to leverage certain attack vectors against machines and networks.

Don’t get me wrong: I am not discounting the need, want, or value of a vulnerability assessment. These assessments, as well as pen tests, have their place and need. What I am saying is that these assessments need to be better understood in order to know how and when they should be performed. Additionally, there have been companies that run regular vulnerability assessments and the same vulnerabilities keep coming up every single scan. These companies are either overwhelmed with the amount of vulnerabilities present in their networks and don’t know how to fix them, or they don’t see the value or need in fixing them. Penetration tests can enforce the reasoning. In turn, by better understanding what the difference is, the clients will understand what to expect as a final product and won’t be dissatisfied with the results of each test.

SecureState can perform a threat vulnerability assessment or penetration test for your organization. Talk to us about our information security programs today.

If you've been following any of the recent PCI (Payment Card Industry) breaches, you'll see two trends coming from the breached organization. One one hand, they'll say that the PCI standard is flawed since it they were compliant and still got hacked. On the other hand, they'll say the problem was their QSA (Qualified Security Assessor) messed up. Although both the standard could be better and a QSA can be more thorough, it's time for organizations to stop passing the buck and admit that they screwed up.

Now I understand that there are certainly differences of quality in each QSA. I've seen everything from rubberstamped reports that make you wonder if the QSA can spell 'PCI' to a tinfoil hat QSA who uses the standard to create new, crazy requirements. But in the end, I sometimes wonder if the organizations understand truly what makes a good QSA and what their role is. Ultimately, the QSA is supposed to be an auditor (yes, I know technically we are 'assessors'). That means the QSA is trying to make sure the processes the organization established are working properly. In order to do that, the QSA needs to typically sample the controls and do some digging around. This should allow the QSA to determine that the control is generally operating correctly. However, the QSA is NOT the master of the organization's destiny for security. Heck, the audit is only once a year and cannot turn over every stone. The organization owns and is responsible for the processes, the controls, monitoring, and reacting. If they break down, that is the organization's problem.

Now as far as the standard goes, I hear a lot of people (generally non-QSA) stating that the PCI DSS is flawed. First of all, let's just understand that this was written to push compliance, not security, to a certain level since it was severely lacking in most organizations. Just to be clear, compliance is just a hurdle and not a ceiling. What I don't understand is then what other framework or compliance is better than PCI? For example, ISO 27001 is still too general and based on business decisions. The standard is still the most thorough, prescriptive, and layered one out there. This is not only for the controls within it but also the testing. For example, testing applies both externally and internally and escalates from scans, to pentests, and even web app reviews. For all the naysayers out there, I'd love to see a better version from them. Remember, PCI was the first and still the onyl one out there that has pushed hard for web application security such as the OWASP Top 10. Now for those who think the standard isn't detailed enough, give me a break. It isn't going to tell you exactly how to do X with product Y in a Z architecture. There are just too many variables.

So let's look at the latest details on the big breaches. Now we are finally starting to get enough details to understand what happened. Let's go with the assumption that the downfall to Heartland/Hannaford was SQL injection and see where the problem hypothetically is. Well the standard clearly states that it needs to be properly coded in requirements 6.5.2. Keep in mind that a QSA will not and may not even be able to review all your code. Oh yeah, that is the organization's requirement in 6.3.7. This also needs further tested through a web application review (possible third party problem) or prevented through a web application firewall (organization's problem) in 6.6. Not to mention that this would or should be detected during the vulnerability scanning (ASV problem) and penetration testing (probably third party problem) from requirements 11.2 and 11.3. So how exactly did the standard fail here when there are at so many layers of controls and testing designed to stop this?

This brings me back to yet another ranting point. It is unbelievable the number of organizations who are constantly trying to find the absolute cheapest vendor for any of the stuff we just discussed including the QSA, the ASV, and other testing. There is little going into understanding the quality or qualifications of the vendors being selected by the organization. This absolutely leads to 'getting what you pay' for quite a bit. But just remember, that is a choice of the organization to pick a deficient vendor.

We also need to realize that even if SQL injection had worked, there were still plenty of other controls within PCI that could have stopped the breach. First of all, there is a anti-malware requirement. Yes, I know that only recently was it clearly required for all platforms, not just those 'commonly affected'. But we have seen Linux malware and it's supported by all commercial anti-virus vendors and even free ones. So did the organization just not do it because it wasn't clearly dictated as a hurdle within the standard? I guess so. There is also a requirement to restrict firewall traffic both inbound AND outbound. So why was the malware allowed to talk to the internet from payment systems? There is no good business reason there. So the standard certainly isn't as flawed as people want to assert, though there it could be improved.

In the end, we certainly can conclude a few things. First of all, despite the fact that these organizations had been assessed as compliant, the organizations clearly were not compliant. Though it is possible that a QSA missed something, that is still the organization's problem. Also, the standard cannot be perfect but it is very well built and, if followed, would have stopped these. In security, like any process, it may only take one flaw for a breach to occur - even if that was the standard or the QSA. But that's why security has to be layered and has to be based on quality, not compliance. Regardless, the whole security process is owned by the organization and they need to take responsibility when it breaks. Passing the buck doesn't undo the breach, but does make for some interesting blamestorming to watch.