New Scam Out There

Here’s a new twist on an old scam that may be affecting retailers.

The old scam was to get small business owners to purchase office supplies, copier paper, copier toner, etc. at inflated prices and pay exorbitant shipping costs. The scam was driven by unscrupulous distributors that had sales people do the old hard sell on a merchant’s support personnel who didn’t know any better.

The new scam involves an automated calling system that dials the retailer. The message delivered from this automated system is that the retailer’s credit card terminal is not PCI compliant and that the retailer needs to order new terminals to ensure that they meet legal requirements and remain PCI compliant. The automated system then asks the call’s recipient to press a key to order terminals.

At its best case, this may just be another take on the old office supplies scam and is being run by an unscrupulous credit card terminal dealer to jack up sales. In a worst case scenario, this may be an attempt by some form of organized crime to get doctored terminals into the retail stream so that they can collect credit card data for resale.

Either way, the word needs to get out that retailers are being targeted.

Advertisement

Simple PCI Compliance – Part 2

eWeek published an article by Evelyn de Souza entitled ‘How To Achieve Payment Card Industry Compliance: 5 Simple Steps’.  The article is focused on small merchants and while the article points out five great ideas, in my experience, it’s the implementation of those ideas that create the problem.  So let’s look at another one of those ideas.

The second point is to make sure that a small merchant uses a PA-DSS compliant point of sale (POS) solution.  First I have a nit to clear up.  Ms. de Souza refers to the PA-DSS as being Visa’s program which is not true.  Visa’s program was called the Payment Application Best Practice (PABP) certification.  The PABP program was turned over to the PCI Security Standards Council last year and became the basis for the Payment Application Data Security Standard (PA-DSS).  PA-DSS compliant applications are just being certified given the newness of the certification process, so most applications at this point are only PABP compliant.  However, we expect to see PA-DSS certified application very soon.  And PABP compliant applications are still allowed to be used under the PCI DSS.

While PABP compliant applications have been available for almost four years, the vast majority of small merchants are using POS software solutions that are nine or more years old.  This is because most merchants replaced their POS solutions just before 2000 for Y2K and expected to get around 10 to 15 years out of their POS solution.  Since most of these merchants operate on thin margins and the economy has tanked, most cannot afford the expense of new hardware and software at this time.  After all, current POS software requires Windows XP or greater, so just upgrading the POS application is not going to be an option on 10 year old hardware.

Just because you use a PABP/PA-DSS compliant application does not mean that it does not store cardholder data.  It does mean that if the application stores cardholder data that it is stored securely.  But wait, wasn’t Ms. De Souza’s first rule to not store cardholder data?  Software vendors are required to provide an implementation guide that describes the steps necessary to implement the software so that the merchant maintains compliance with the PCI DSS.  The implementation guide will explain that backups, key management and other PCI DSS requirements must be met by the merchant.

Which leads to my final point which is there is the assumption that because the software is PABP/PA-DSS compliant that it somehow confers PCI DSS compliance on the organization that uses the software.  PABP/PA-DSS compliance just means that the software properly protects cardholder data.  PCI DSS compliance requires more than just a compliant application.  There are numerous issues that need to be complied with that are outside of the application vendor’s control and therefore not covered by the PABP/PA-DSS certification.  As a result, there is plenty of additional work to be done to ensure that PCI DSS compliance is achieved.

So, PABP/PA-DSS does not confer PCI DSS compliance on a merchant.  A merchant still has quite a bit of work to do in some cases to be compliant.

Simple PCI Compliance – Part 1

eWeek published an article by Evelyn de Souza entitled ‘How To Achieve Payment Card Industry Compliance: 5 Simple Steps’.  The article is focused on small merchants and while the article points out five great ideas, in my experience, it’s the implementation of those ideas that create the problem.

Ms. De Souza’s first idea is to not store cardholder data.  This is easier said than done.  First, a lot of small merchants still use a manual embosser, otherwise known as a ‘knuckle buster’.  A knuckle buster captures everything on the front of the card on the charge slip.  One copy of the charge slip goes with the customer and the other copy goes with the merchant.

At this point, it seems like a good time to discuss Ms. de Souza’s fifth rule, protecting cardholder receipts.  Those knuckle busters can generate a lot of receipts that contain cardholder data.  Under the PCI DSS, the merchant is responsible for securing their copy of the charge slip.  Merchants typically need to hang onto this slip for a minimum of 90 days and a maximum of around 120 days in the event of disputes or chargebacks.  Keep in mind that even a lot of large merchants still have knuckle busters as their backup in the event that their automated systems fail.  While such failures are rare, large merchants can generate thousands of transactions in a very short time even with knuckle busters.  We typically get a lot of push back from clients that believe the PCI DSS only concerns electronic information.  The PCI DSS is responsible for securing ALL cardholder data, regardless of whether it is electronic, handwritten, embossed or whatever.

For small merchants that have moved into a more modern era, they have invested in a VeriFone, Hypercom, Nurit and the like credit card terminal.  These terminals get their information from the cashier swiping the card.  The terminal connects to the credit card processor through a dialup or Internet connection.  Once the transaction has been approved, the terminal generates a receipt using a thermal printer.  At the end of the day, one of the merchant’s supervisory personnel generates an end-of-day (EOD) report to balance our the cash register.  It’s the EOD report where things go wrong because most of these terminals are not properly configured, so the EOD report prints out the card numbers for every transaction since the last EOD report run.  One would think that the source of the terminal would have properly configured the terminal so that it truncated the card numbers, but for whatever reason, they do not.  In addition, I have run into instances with customers where I have contacted the terminal vendor and they have indicated that the terminal needed a software upgrade and then reconfigured to truncate the card numbers – for a brand hew terminal!

As you can see, while trying not to store cardholder data is an admirable goal, it can sometimes be difficult to implement.

Compliance Morass

I promised more comments regarding Mr. Robert Gezelter’s blog post entitled ‘Securitization: A Risk To Compliance Integrity’.

To paraphrase Mr. Gezelter, he indicates that compliance programs become irrelevant due to the fact that there is no provision for feedback into the compliance program that periodically adds new requirements and reevaluates existing requirements to ensure that they are still relevant or that they are updated to reflect new conditions.  Mr. Gezelter is absolutely right about compliance programs remaining relevant as irrelevant programs no longer provide any benefit.

The PCI compliance program is kept relevant by the participating organizations, the card brands, the QSAs, the ASVs, the PA-QSAs, the PCI SSC and other relevant parties.  All of these groups are charged with periodically reviewing the various relevant PCI assessment processes and making suggestions for additions, changes and deletion of requirements.  The problem with this process is that with so many groups with their different constituencies involved, permanent changes can take a while to get published.  However, this is somewhat addressed by the fact that the PCI SSC can issue ‘clarifications’ to the PCI compliance programs to address immediate concerns with the programs.

If there is a problem with the PCI compliance process it is that it is conducted as of a point in time although there are some requirements such as vulnerability scanning and penetration testing where a year’s worth of reporting is required.  The problem with this is that the organization is compliant at the time of their assessment, but may not have been compliant at any other time.  This typically confuses people because Reports On Compliance (ROC) and Self Assessment Questionnaires (SAQ) are required to filed annually.  Thus most organizations assume that this implies that the assessment process covers the entire time between filings.  Nothing could be further from the truth.

Since organizations are not likely PCI compliant all of the time, companies can suffer breaches even when they are supposedly PCI compliant.  Even when organizations that are extremely diligent on their compliance they can still suffer breaches because there are still humans involved.  It’s not until the forensic examination is complete after a breach has occurred that a company is actually determined to have been PCI compliant or not.  Given the odds, I would say that most organizations for one reason or another are not compliant at the time of a breach.  And given that security is not a perfect science, it’s also likely that the breach was not necessarily the result of not being PCI compliant.

In the end, I think the PCI standards are being kept up to date and relevant, so Mr. Gezelter’s concern there is unfounded.  However, I do believe there is a gap in the compliance assessment process that gives organizations a false sense of security that if they are compliant, all is good all of the time.  And that is just not the case.

A Problem with ASV certification?

Mr. Robert Gezelter’s blog post entitled ‘Securitization: A Risk To Compliance Integrity’ discusses his organization’s encounter with an approved scanning vendor (ASV) and their vulnerability scanning.  Mr. Gezelter discusses in his posting that the ASV conducted testing through a firewall and intrusion detection system against a system that was powered down.  While I would question the ASV’s qualifications, Mr. Gezelter brings up a valid point regarding his experience and concerns with the vulnerability scanning process.

One of the problems lies with the fact that the ASV certification process certifies an entire firm, not an individual.  That means that a firm can use its best personnel to get their ASV certification.  Once certified, they then turn it over to low skilled personnel (i.e, low cost) to conduct the customers’ scans.  Or worse yet, the ASV implements an automated solution that customers set up for scanning.  All of this increases their margin on their work, not their accuracy or customer service.  A reputable ASV will use highly qualified personnel to configure and conduct the scanning and interpret the results.  These personnel will have a good understanding of the PCI compliance process and what the scanning is to accomplish.  This is why there is such a variance in scanning costs and results.  This would all be addressed by making the ASV certification by individual and not by firm and then requiring the scans be conducted by a certified individual.

Another part of the problem comes from the sales cycle by the ASV.  The sales cycle for those cost conscious customers usually results in a customer keying in the IP addresses of what they think is their PCI in-scope systems into a Web site and then setting up a scanning schedule.  Whether or not the scan will be properly conducted is anyone’s guess.  A reputable ASV will have informed personnel walk a client through the scanning process and ask appropriate questions to determine the amount of effort required to get the correct results.  Again, you get what you pay for.  However, this would be addressed by requiring scans to be conducted by a certified individual using tools, not just a tool.  Until tools cannot generate false positives and false negatives, they will always require an experienced human to interpret the results.

Finally, using an automated tool is only part of the compliance process.  The results produced by the tool need to be interpreted, false positives determined and documented and then the real vulnerabilities dealt with.  Tools produce false positives and false negatives and these must be resolved by someone with experience so that the correct results are addressed.  Most organizations using these automated solutions are not qualified to interpret the results and therefore are likely only complying with the scanning and not with the remediation.  Again, this can be addressed by requiring a certified individual to conduct the scanning and determine what remediation is required.

Only time will tell if the PCI SSC will address this situation.

Network Segmentation

To paraphrase Supreme Court Justice Potter Stewart, “I know good network segmentation when I see it.”
There doesn’t seem to be a more discussed topic in the PCI compliance space than network segmentation.  Why is this such a discussed topic?  Because there are as many potential solutions as there are network equipment vendors.  So each implementation needs to be assessed on its own individual merits.
Why is network segmentation important?  For most organizations, it can mean the difference from a straightforward, relatively simple PCI assessment or a nightmare.  If an organization’s network is properly segmented and their PCI assets are physically or logically segregated from non-PCI assets, then the scope of a PCI assessment can be reduced.  This can take 50% or more of the organization’s network out of scope.
But what constitutes good network segmentation?  Here are the key concepts that I look for when assessing the segmentation of a network for PCI.

• How is network traffic controlled?  The key here is the ‘how’.  By controlled, I’m looking for controls that physically or logically isolate PCI in-scope systems from out-of-scope systems.  Those controls can be the use of firewalls, virtual LANs (VLAN), totally separate networks and everything in between.  The most common techniques we see are firewalls or VLANs.  However, you segregate your networks, there needs to be access control lists (ACL), port/service restrictions or other controls put into place to limit and/or restrict access from the in-scope network to the not-in-scope network.
• How is network traffic monitored?  The key here is usually whether or not the network is monitored.  While good controls are a great start, if you are not monitoring those controls, then anything could be going on and you will not know it until it escalates into a bigger problem.  What I look for is the ability to generate alerts when unauthorized traffic is blocked or detected.
• What happens when an alert is generated?  If you have controls and monitoring in place, what do you do when an alert occurs is key.  If you do not have an incident response process for an alert, then nine times out of ten, the alert just gets ignored.  Alert response process needs to identify the alert and then have a detailed process of how to diagnose whether the alert is real or a false positive.  Either way, there should be documentation generated that proves the process was followed and the actions taken as a result.
• Who has access to these network devices?  Finally, what you have done to limit access to the network devices is the last key item to be considered.  The first three considerations are moot if anyone can go in and make changes to these devices.  So, the final area I look for is how access to these devices is controlled and how access is monitored.

While these are the key concepts I look for, there are nuances in each area that bring in other considerations.  So, here are your starting points for network segmentation.

The Weakest Link

Most organizations have implemented a plethora of technological security solutions in the form of firewalls, network monitoring, anti-virus, real-time log monitoring and all the other requisite technologies. The PCI Data Security Standard is predominantly focused on these technological solutions and their appropriate care and management.

Regardless of all of the technology solutions for securing sensitive information, people still interact with this information for the purpose of getting their jobs done. The PCI Data Security Standard recognizes this and directs organizations to minimize the number of employees with access to sensitive information. In addition, Section 12.6 ensures that a security awareness program exists, that employees are periodically reminded of their responsibilities to protect cardholder data and that employees attend at least annual awareness training.

Organizations have not done themselves any favors in this area. For more than 20 years, organizations have based their customer service training on the premise that it is cheaper to retain an existing customer than to court a new customer. This training neglects the fact that some customer requests are made with ill/bad intentions—and it therefore does not encourage employee skepticism of customer requests.

Traditional customers aren’t the only people employees are trained to provide exceptional service for. Internal client servers, those who work at the help desk or even the receptionist, are encouraged to bend over backwards for other employees as well. In our customer-focused society, everyone is tripping over themselves to be the most helpful. To make matters worse, most organizations reward customer-focused activities through employee incentive programs. Employees must learn to consider the ramifications of what their assistance may put at risk., and that’s what’s missing in our customer service training.

This lack explains the recent rise in social engineering attacks. Organizations have most of the technological security solutions, but they have not focused on the threat their own employees present. Social engineers use this to their advantage and obtain user identifiers and passwords, account numbers, encryption keys and other sensitive information just by leveraging an organization’s customer-centric service philosophy.

Disgruntled employees also threaten the practicality of the customer-centric philosophy. Not all of these people are necessarily on the firing line. At their worst case, they can be everyday, reliable employees who hold a grudge. However, when they decide to act, a disgruntled employee only cares about extracting revenge. And they will do whatever it takes to extract that revenge such as destroying records, releasing sensitive information or even murdering other employees.

This is why section 12.6 is a vital section of the PCI Security Assessment Procedures. Security awareness programs are one of the most important aspects of minimizing social engineering activities. However, the tests suggested in the current PCI Security Assessment Procedures are just a start. In order for organizations to truly have an effective security awareness program, reminding employees of their responsibilities is just not good enough. Social engineering testing must be conducted periodically against random groups of employees to ensure that all of the awareness training is put into practice. Without testing, it’s anyone’s guess how well an organization’s awareness training is working. That is why, in future releases of the PCI Security Assessment Procedures, I expect to see section 12.6 expanded as attacks move from the technological back to social engineering and, eventually, hybrids of both.

Is social engineering testing a silver bullet? No. Regardless of how much training and testing an organization does, people are fallible. It’s human nature. But a good awareness program with social engineering testing minimizes the risk to the organization from social engineering attacks. That’s more than customer service training alone can do.

Compliance Does Not Remove Risk, It Reduces Risk

Mr. Robert Gezelter recently posted a blog entry entitled ‘Securitization: A Risk To Compliance Integrity’.  It raises a number of issues that I will further expound upon in future blog entries of my own.

In his blog entry, Mr. Gezelter raises the point regarding the fact that data breaches are inevitable.  That is because, regardless of the security measures an organization puts in place, if someone REALLY wants to get the organization, they will take whatever measures necessary to get the organization.  Security’s goal is to minimize as best possible, the risk presented.  It is NOT perfect and never will be.  So we all need to get over the fact that security is not an end to the problem, it is a continuing journey.

Just look at banks.  Even with all of the vaults, alarms, video monitoring, dye packs and the like, they still get robbed.  Why?  Because the odds still favor the occasional criminal, i.e., the robber that only robs a bank once or only once in a great while.  And there’s the rub.  In order to be a ‘successful’ bank robber, you need to rob a lot of banks.  And that’s where the odds eventually catch up with the criminals and they get caught.

This is the way it will become with network security.  As we strengthen network security, it won’t necessarily stop the breaches, but it will lead to the solving of most of them.  Enough so that it will deter all but the most fervent criminals.

Those of us in the security industry need to better manage others’ expectations surrounding security.  We need to politely explain time and again that security is NOT the end, it is a continuing journey.

Dispelling Rumors – CVV/CVC

One of the things I hate about blogs is that they seem to generate more rumors than dispel. One of the reasons I created this blog was to get rid of some of the rumors surrounding the PCI process. Where these rumors come from, I’m not sure. However, the sooner they are dispelled, the more secure we will be.

The rumors I would like to dispel in this posting are related to why merchants seem to think they need to retain the card verification value or code otherwise known as CVV/CVC. It’s that three digit code on the backs of Visa or MasterCard cards and four digit value on the front of American Express cards. Actually, to be correct, American Express calls it the CID. Regardless of what it’s called, it is NOT allowed to be retained once a transaction has been processed.

The first rumor is that by using the CVV/CVC in transactions merchants reduce their interchange fees with their processor and the card brands. This is not true.

What is true is that by including the CVV/CVC value when a merchant submits a transaction for authorization, should a dispute or chargeback situation arise, the processor and/or card brands will reduce their fees on the dispute or chargeback. The rationale being that the processors and card brands assume that by having the CVV/CVC, it is less likely that the transaction will result in a dispute or chargeback.

The second rumor is that merchants conducting repeat transactions need to submit the CVV/CVC for the original and all subsequent transactions. Again, this is false.

There are two ways to conduct such recurring transactions. The easiest way is to use a processor that can provide you with a reference number from the original transaction and then process all subsequent transactions by allowing you to use the reference number so that your organization does not have to store the cardholder information. The other option is for your organization to store the cardholder’s name, account number and expiration date. Of course, if your organization is storing this information, you need to ensure it is stored securely either by encrypting it if on a computer or physically securing it if using a manual system.

Why The PCI Standards Seem To Constantly Change

One of the biggest complaints about the PCI standards is that they always seem to be changing.

The reason why this seems to be the case is that the security measures of networks and applications are always changing.  Why?  It’s the attackers.  Every time we close up one way in, they find another.  When the threats change, so do the tactics to secure resources.  Hence, the PCI SSC issues clarifications to the PCI DSS to address new threats.

As an example, in v1.2 of the DSS, you now have to conduct vulnerability AND penetration testing on the inside of your network.  Vulnerability scans at least quarterly and penetration testing at least annually or whenever significant changes are implemented.  Why?  For a number reasons that are the result of changes in the threat landscape.

• First, because applications are becoming browser-based, you now not only have Web-based applications facing the big, bad Internet, but they are also on your internal network.  If they can be abused from the Internet, do you think they can also be abused on your internal network? You bet!
• Second, it’s not just the Internet you have to worry about these days. You need to worry about your own employees. Huh? You think those 20-somethings you have working for you are working all of the time? They get breaks and they tend to want to surf the net. The other bad news is that in a lot of cases, your younger employees may know as much or more about your technology than your IT department. FBI statistics state that 70% or more of all attacks have an internal component. Either an attacker used social engineering to get information for accessing your network or computers or an insider is an active participant.
• Finally, statistics point to security threats increasing on the inside of your network. Of course your IT department is on top of internal security, right? But, you haven’t funded a lot of security initiatives on the inside because you have all of those policies and standards that tell people not to do bad things to your network and the information you store. You have invested in all of those new browser-based applications. While those applications may not face the Internet, they still could be susceptible all sorts of vulnerabilities such as cross-site scripting or SQL injection attacks. And those vulnerabilities could be used to compromise your cardholder data as well as any other sensitive information.

All you have to do is look at the latest breaches such as Heartland and RBS.  They all had a strong internal component. In response, the PCI DSS is being adjusted to address the new internal threat.

So, if you want the PCI DSS and related standards to remain static, you need to stop the attackers from finding new methods of attack.