Selecting a PCI QSA Vendor

If you are a merchant that accepts credit cards, you are required to comply with the requirements of the Payment Card Industry (PCI) Data Security Standards (DSS), and you must demonstrate that compliance each calendar year to your bank.

You can find more information about what that means to your business here. Once you are ready start your compliance effort, you will need to engage a third-party team to help make sure you are making the correct decisions about demonstrating that compliance if you are a level 1 merchant.  You’ll need to start working on changes as they occur to make sure you aren’t making poor security decisions, and a trained QSA will certify your compliance with a standard format report that lists why they think your environment is secure enough for customer transactions called a Report of Compliance (RoC).

It can be difficult to find the correct partner that can help guide you through this difficult and expensive process, but a little work in the beginning can save you headaches and expenses later in the process.

PCI DSS 4.0 – Coming Soon

In the upcoming request for comments (RFC) for the first draft of the PCI Data Security Standard Version 4.0  (PCI DSS v4.0), there are some new and exciting changes. PCI DSS v4.0 has been in the works for a while, so a discussion of what is coming is important to anyone who has to meet the standards required to maintain their compliance with the payment card industry.

The October RFC documents will include the first draft of the new PCI DSS v4.0 standard as well as a sample of the new reporting template. This will help everyone understand the new validation method to help support business implementations. There is also a Summary of Changes document that will outline the changes in the draft as well as guidance for everyone on how to review the documents and provide feedback with any issues or questions.

This draft of PCI DSS v4.0 was crafted with feedback received during prior drafts and attempts to reflect changes in security technologies, customer environments, and payment industry changes. These updates to the standard are intended to strengthen security while also adding some flexibility to how the standards are implemented.

The 12 core PCI DSS requirements remain essentially the same while several new requirements are proposed to address evolving threats to significantly reduce the overall risk to payment data. The idea is to give more flexibility to organizations so that companies can use different methodologies and solutions to meet the intent of PCI DSS requirements.

EMV Credit Card Chips Don’t Stop Fraud

New chip-enabled credit cards, known as EMV cards, which started rolling out to U.S. consumers starting in 2015 were intended to stop credit card fraud. Credit card companies like Europay, Mastercard, and Visa promoted EMV (which are the initials of the companies promoting the standard) as a merchant-funded way to force transactions over to a process known as “chip-and-PIN” where the computer chip inside the card would virtually eliminate illegal credit card cloning by organized crime.

A report from Gemini Advisory, a research firm, is showing that there were more than 60 million cases of credit card theft in the last 12 months. It also shows that 93% of the stolen cards used the new EMV chip technology that the card companies said would eliminate this type of crime.

The report states: “45.8 million…records [were] likely compromised through card-sniffing and point-of-sale (POS) breaches of businesses such as Saks, Lord & Taylor, Jason’s Deli, Cheddar’s Scratch Kitchen, Forever 21, and Whole Foods. To break it down even further, 90% or 41.6 million of those records were EMV chip-enabled,” which is stunning information.

PCI: Listed vs. Non-Listed P2PE Solutions

With credit card processing, it is important to understand the different parts and pieces that make-up the required security components. The PCI Security Standards Council (PCI-SSC) has released an assessment methodology for merchants using Point-to-Point Encryption (P2PE) solutions. The addition of the Non-Listed Encryption Solution Assessment (NESA) and the accompanying audit process provides merchants an expanded pool of encryption solutions beyond the current list of validated providers, allowing for a wider range of security offerings of the merchant is willing to accept the added liability and cost of a self-certified solution. It is very important to understand the assessment requirements of each before deciding between a listed or a non-listed solution.

The process for becoming a listed solution with the PCI-SSC begins with an audit performed by a third party independent Qualified Security Assessor (QSA) who has been certified specifically for P2PE assessments. During this technical assessment, the P2PE QSA will evaluate the solution against the relevant controls outlined in the following six P2PE Domains from the PCI-SSC:

• Domain 1: Encryption Device and Application Management
• Domain 2: Application Security
• Domain 3: P2PE Solution Management
• Domain 4: Merchant Managed Solutions (not applicable to 3^rd party solution providers)
• Domain 5: Decryption Environment
• Domain 6: P2PE Cryptographic Key Operations and Device Management

For each applicable control, the P2PE QSA will collect evidence from the solution and observe all required procedures to ensure compliance with the standard. The results of the assessment are then documented using the P2PE Report on Validation (P-ROV) template which will be submitted by the QSA directly to the PCI-SSC for final review. Once a representative of the PCI-SSC has reviewed, approved, and signed the submitted P-ROV, the solution will receive an official listing on the PCI website.

The process of implementing and validating a new or existing solution can be quite lengthy and the NESA process gives solution providers the ability to provide a degree of security assurance to customers, along with scope reduction, while they work towards a validated listing. Much like the process for becoming a listed solution, non-listed solution providers need to engage their own P2PE QSA to perform an assessment of their solution. The requirements for this type of assessment, however, have been relaxed in that a non-listed solution assessment can be completed without meeting the requirements for P2PE Domains 1, 2, or 3, but must meet all applicable requirements of Domains 5 and 6. Though the QSA will still complete a P-ROV for informational purposes, the end result of this assessment will also include a set of documents (referred to as the NESA documentation) which will include:

• A description of the solution
• A summary of the application’s full compliance, partial compliance, or non-compliance with Domains 1,2, and 3
• A statement of compliance confirming the applicable requirements of Domains 5 and 6 are met
• The assessing P2PE QSA’s recommendation as to how the solution impacts the merchants PCI scope

This set of documents serves the same purpose as a listed solution’s P-ROV or Attestation of Validation (AOV), without being submitted to the PCI Council or the Payment Brands, and will be used by PCI QSA’s when assessing the PCI compliance of a merchant utilizing the non-listed solution. As with standard PCI certification documentation, this NESA documentation should be distributed to clients on an annual basis, and whenever there are significant changes to the system.

At the merchant level, the difference between implementing a listed versus a non-listed solution becomes apparent during the annual PCI-DSS re-certification. A merchant using a listed solution in accordance with the solution providers P2PE Instruction Manual (PIM) and the pre-requisites of the SAQ P2PE automatically qualifies for a drastic reduction in PCI scope when assessing their environment. This is because the security and isolation of credit card data has been verified by a representative of the PCI-SSC. This same level of scope reduction is not guaranteed with a non-listed solution and will really depend on what is permitted by the merchant’s acquirer as well as the payment brands. In some cases, the acquirer or payment brands may require the aid of a PCI QSA to review the solution provider’s NESA documentation and the merchant’s implementation of the solution to determine what PCI-DSS requirements are covered, and to what degree. The results of this secondary solution assessment will determine which areas of the merchant environment are in scope of PCI, but will not qualify the merchant to utilize the SAQ P2PE.

You can get more information from the official PCI Security Standards Council website or your QSA.

Selecting a PCI QSA Vendor

If you are a merchant that accepts credit cards, you are required to comply with the requirements of the Payment Card Industry (PCI) Data Security Standards (DSS), and you must demonstrate that compliance each calendar year to your bank.

You can find more information about what that means to your business here. Once you are ready start your compliance effort, you will need to engage a third-party team to help make sure you are making the correct decisions about demonstrating that compliance, working on changes as they occur to make sure you aren’t making poor security decisions, and they will certify your compliance with a standard format report that lists why they think your environment is secure enough for customer transactions called a Report of Compliance (RoC).

It can be difficult to find the correct partner that can help guide you through this difficult and expensive process, but a little work in the beginning can save you headaches and expenses later in the process.

The first thing to remember is you need to run your business, and that already means having a secure information technology (IT) environment and worrying about adequate security. Being PCI compliant an having a secure network is not the same thing. The PCI DSS provides you a standard framework that list the minimum requirements for implementing a secure IT environment. You have to know your specific requirements and what makes your environment different than the “standard” IT environment. Your Qualified Security Assessor (QSA) needs to have the skills required to understand technology in general, and your specific environment, before thy can perform their job well.

Here are three tips to help you choose the right QSA for your PCI Compliance audit:

• How experienced is the QSA? You don’t want to pay to train your QSA on how to do perform their job. You want someone who already has a few years of experience.
• What is the approach to the audit used by the QSA? You have to understand how the QSA will interact with your team and how well their approach will work with your culture and corporate environment. The best-case scenario is they fit seamlessly with your employees and have the professionalism and communication skills to work well with the entire team.
• Will the QSA stand behind their work? If things go bad and there are questions about your security measures, or even a breach of customer data, you want someone who is confident in their security decisions and will defend your decisions.

Pricing is another area that can be hard to compare from company to company. I looked at 5 different companies and they gave me 5 very different pricing solutions. The cheapest was almost half the cost of the most expensive.  There are several factors that will play into pricing and those factors will vary for each company, but your overall network complexity, number of credit card transactions, and requested services can really drive huge swings in pricing. Don’t be afraid to do some comparison shopping to find a vendor with pricing that meets your budget, but the cheapest vendor doesn’t always mean they are the one you need to select.

It can be preferred to pay slightly more if you are going to get much better service and support.

 

PCI Compliance Requirements – Merchant and Validation Levels

If you deal with credit cards, you have to deal with PCI Compliance. What the exact requires are depends on some facts around the types and volume of those transactions.

The first step is to determine your “Merchant Level”, which is based on the type of transactions and the number of those transactions. Using the table below, you should be able to quickly determine if you are Level 1 (the highest level and the most expense to maintain compliance) or if you are Level 2, Level 3, or Level 4. Most small businesses fall into Level 4, but you might have enough volume to move into the other levels. It is your responsibility to verify with your bank as you move into higher levels to maintain your annual compliance.

Different Merchant Levels

Different expectations apply to merchants based on your volume of transactions. Visa ranks merchants according to the following system, applying general PCI Compliance guidelines.

Level	Merchant Selection Criteria	Validation Requirements
1	Merchants processing over 6 million Visa transactions annually (all channels) or Global merchants identified as Level 1 by any Visa region	Annual Report on Compliance (“ROC”) by Qualified Security Assessor (“QSA”) or Internal Auditor if signed by officer of the company The internal auditor is highly recommended to obtain the PCI SSC Internal Security Assessor (“ISA”) certification Quarterly network scan by Approved Scan Vendor (“ASV”) Attestation of Compliance Form
2	Merchants processing 1 million to 6 million Visa transactions annually (all channels)	Annual Self-Assessment Questionnaire (“SAQ”) Quarterly network scan by ASV Attestation of Compliance Form
3	Merchants processing 20,000 to 1 million Visa e-commerce transactions annually	Annual SAQ Quarterly network scan by ASV Attestation of Compliance Form
4	Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually	Annual SAQ recommended Quarterly network scan by ASV if applicable Compliance validation requirements set by merchant bank

The validation level can help drive the type of compliance requirements based on your merchant level. Work with your bank to verify your validation level.

Validation Levels

A	Card-not-present merchants (e-commerce or mail/telephone-order) that have fully outsourced all cardholder data functions to PCI DSS compliant third-party service providers, with no electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises. Not applicable to face-to-face channels.
A-EP	E-commerce merchants who outsource all payment processing to PCI DSS validated third parties, and who have a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises. Applicable only to e-commerce channels.
B	Merchants using only: Imprint machines with no electronic cardholder data storage; and/or Standalone, dial-out terminals with no electronic cardholder data storage. Not applicable to e-commerce channels.
B-IP	Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor, with no electronic cardholder data storage. Not applicable to e-commerce channels.
C-VT	Merchants who manually enter a single transaction at a time via a keyboard into an Internet-based virtual terminal solution that is provided and hosted by a PCI DSS validated third-party service provider. No electronic cardholder data storage. Not applicable to e-commerce channels.
C	Merchants with payment application systems connected to the Internet, no electronic cardholder data storage. Not applicable to e-commerce channels.
P2PE-HW	Merchants using only hardware payment terminals that are included in and managed via a validated, PCI SSC-listed P2PE solution, with no electronic cardholder data storage. Not applicable to e-commerce channels.
D	SAQ D for Merchants: All merchants not included in descriptions for the above SAQ types. SAQ D for Service Providers: All service providers defined by a payment brand as eligible to complete a SAQ.

If you are new to PCI compliance, you can read more here.

Anniversary Of The EMV Deadline

Today we celebrate the one-year anniversary of the EMV liability shift on point-of-sale systems imposed by the credit card companies. Credit card companies have declared limited success by showing credit card fraud from Point-Of-Sale (POS) transactions are down from last year, but card-not-present fraud transactions are up from last year.

I have written about how the rollout of new cards to support EMV mandates has been less that effective, and now other people are noting the same issues. This article by Sara Peters talks about the state of the current EMV mandates.

According to a report by The Strawhecker Group (TSG) released last week, only 44% of card-accepting merchants have EMV terminals. What’s worse, only 29% of card-accepting merchants can actually accept EMV chip-based transactions.

“You’re seeing a lot of pieces of paper over the chip readers,” says Jared Drieling, business intelligence manager of TSG. Paper, or maybe tape or stickers, he says.  

EMV Transition in the US is a Disaster

It started about a year ago in the United States. The transition of millions of credit cards from standard swipe cards with a magnetic strip to a more sophisticated card with an embedded chip inside. The new credit cards were supposed to make everyday transactions safer and more secure, but the story that you may hot have heard is it just isn’t working as expected.

Retailers spent a lot of money to meet the mandated transition of the hardware and infrastructure to support the new technology sent out by the major banks, but customers find it confusing, time consuming, and difficult to figure out when and where it will work correctly.

This problem seems to be driven by an inconsistent implementation at the retailers. Some retailers have installed the new software and are unable to support the new technology, resulting in an post-it notes asking you to just swipe your old magnetic strip and most card reading slots being taped over to block the chip readers from even being used.

In this article by Ian Kar, we learn some of the facts about this less than successful rollout:

All of this started when the US decided to move to the chip standard—known in the industry as EMV. The US process was different from those of other countries, where governments instituted a mandate to upgrade everything by a certain date. 

The US implemented something called a “liability shift”—essentially, if retailers didn’t support chip card payments by buying a new, expensive machine, they’d be held accountable for any sort of fraud that occurred in their store. Usually, that’s the bank’s responsibility. So, as long as retailers purchased the new chip-card reading terminals, liability would shift back to the bank. In a July report on the chip card transition in the US, the Aite Group, a financial services research firm, cited a lack of mandate in the US as one reason the chip card transition has been so confusing.

The liability shift date in the US was Oct. 1, 2015. But, when the date rolled around, shoppers were hard pressed to find a chain retailer that actually supported chip cards, let alone a mom-and-pop shop. In a letter from industry trade group Food Marketing Institute asking credit card companies to postpone the liability shift, the group wrote that as of April 2015 retailers were experiencing four-month delays just waiting for their new terminals to arrive.

And just because shops finally got new terminals didn’t mean they’d immediately start accepting chip cards. Their payment processors needed to certify their systems were still compliant and working correctly before the chip readers could be turned on. Even in 2016, they can only do that by physical inspection. That process can drag out for weeks, and some bigger retailers were still verifying their terminals as of early 2016, according to sources that spoke to Quartz.

 

PCI Compliance and DVR Malware

Credit Card compliance is difficult and costly, without faulty vendor software causing additional security issues. Some people have said that faulty firmware found in some security cameras sold by at least 70 vendors may be a contributor to many of the credit card breaches that have recently proved costly to retailers. Rotem Kerner based his research on a paper on the Backoff malware that RSA published back in December 2014. This malware was used to steal payment card details processed by point-of-sale systems at multiple retail locations. The U.S. Secret Service says it impacted over 1,000 U.S. businesses, including Neiman Marcus, Michaels, Target, and UPS Store.

Kerner reviewed the data that RSA collected from computers that were infected with Backoff, and found that many were running small web servers with open ports on 81, 82, and 8000. “Cross Web Server” is running as DVR (digital video recorder) software, which is used by many retailers for video monitoring. But the server software, open to the internet, was left running on the same network as payment card systems. This is an obvious potential security risk that should have been addressed.

The article provides a step-by-step analysis of the code and how to exploit the code to gain access to the target system. He also provides a list of vendor systems impacted by this vulnerability.

In order to exploit it I had to overcome few obstacles I’ve identified –

1.  Can’t use spaces or newlines + server does not understand URL encoding
2.  Length in between the slashes is limited.

 I was able to bypass the no-space restrictions with something called ${IFS} . Basically IFS stands for Internal Field Separator, it holds the value which is used by the shell to determine how to do field splitting. By default it holds “\n” which is exactly what I needed.  So this is my new attack vector –

/language/Swedish${IFS}&&echo${IFS}1>test&&tar${IFS}/string.js

And it worked! the file has been written. Lets do another test –

/language/Swedish${IFS}&&echo${IFS}$USER>test&&tar${IFS}/string.js

outputs –

root

 Great success!! As with many embed systems this one is using BusyBox so what i decided to do is invoke netcat in order to get a nice and comfy reverse shell.

Visa Credit Card Development Platform

Most people would have said that this would never happen. Visa is opening up its payment processing system directly to qualified third-party developers. Visa Developer has 150 different APIs to access Visa systems, from simple Visa Checkout and Visa Direct, to more complex solutions things like Visa’s location, foreign exchange, and tokenization services. With services like Apple Pay gaining traction, this is seen as an effort to maintain Visa’s relevance.

The “network effect” is an economics term that basically means a thing becomes more valuable the more people that use it. If Visa can stay on the development radar, it should be able to maintain it’s market dominance. You can read more about the recent announcement here.

Point Of Sale (POS) and Data Breach Prevention

Visa recently sent out a breach alert, and included these standard tips to merchants using Point Of Sale (POS) software:

• Control the Windows Administrator account. Make it more difficult for malware to gain Administrative privileges.
  • Assign a strong password for all accounts on the POS system.
  • Create a unique local Administrator password for each and every POS system.
  • Do not allow users to be local Administrators on a POS system.
  • Change passwords frequently, across the enterprise (at least every 90 days).
• Ensure the POS system functions as a single purpose machine. To reduce the risk of malicious software infections, disallow all applications and services (i.e. Internet browsers, email clients) that are not directly required as part of the POS’s core functionality in processing payments.
• Keep operating system patch levels up to date. For Windows, this means ensuring Windows Update is functioning and automatically applying monthly security patches. For non-supported operating systems like Windows XP, there should be a plan to migrate to a current operating system.
• Restrict permissions on Windows file sharing or disable file sharing altogether. Unless absolutely necessary, Visa recommends disabling file sharing on POS systems. Microsoft has published instructions on how to disable simple file sharing and set permissions on shared folders.
• Restrict remote access services use. Unless necessary, disable remote access services, ports and accounts. If remote access services are needed, enable only when needed.
• Promote security awareness. Design anti-phishing programs, defense in depth strategies, and promote shared responsibility in security awareness.

Are you and your organization doing the correct things to protect your company and your customers from a breach?

Six tips for becoming EMV compliant

If you deal with credit cards and work at keeping your business staying compliant, you have heard of the “Liability shift” change that will soon target businesses that accept credit cards, including retailers, restaurants, hotels, banks and more. On October 2015, there will be a shift of liability from banks to sellers (non-online).

Hardware, software, and payments processing vendors who operate in the POS marketplace are at various stages of EMV compliance, development, and marketing to sellers in the position of identifying the best long term solution for their organization.

Rob Chilcoat of UCP Inc., a distributor of hardware devices specifically for the acceptance of credit and debit cards for OEM cash handling and retail, notes that there are more moving parts in the current U.S. payment processing system than in years past or markets abroad: “Whereas in previous years, payment processors were the primary source of hardware equipment for retailers and sellers, there are a plethora of hardware solutions that are not simply one-size-fits-all. This adds to the mix ‘payment gateways’ that communicate between software, application, hardware & processors.” With this new component, sellers and retailers have increased flexibility to find a solution that best meets their needs, but also creates an unlimited number of options, with the need to select the appropriate hardware, application software, payment gateway, and lockdown software for your organization.

1. Start early. While you can purchase devices that are EMV-ready/EMV-compliant, the decision making and implementation process can take months.

2. Plan for the future. Buy a device and system that will modify and scale as the needs of the EMV system change.

3. Communicate. Communicate the issues, reasons, and implementation process clearly to everyone from C-level execs to the staff working with the devices.

4. Identify a list of must-haves. What functions and forms are required?

5. Select suppliers. Find suppliers that will give you the support needed. Will you need assistance in design, installation, and implementation?

6. Budget funds. Set aside funds that are earmarked for this transition. for what is necessary to purchase the proper system and equipment.

You can read the entire article from Laura Miller to get more details.

With a Filter Bypass and Some Hexadecimal, Credit Card Numbers Are Still, Still Google-able

With the current compliance requirements, you would think it would be difficult to find sensitive data just by doing an internet search on a site like Google. In the recent article by Gergely Kalman, he shows his technique and results from his efforts to see if the information could still be found.

If you know me, or have read my previous post, you know that I worked for a very interesting company before joining Toptal. At this company, our payment provider processed transactions in the neighborhood of $500k per day. Part of my job was to make our provider PCI-DSS compliant—that is, compliant with the Payment Card Industry – Data Security Standard.

It’s safe to say that this wasn’t a job for the faint of heart. At this point, I’m pretty intimate with Credit Cards (CCs) and Credit Card fraud. After all, our job was to protect our users’ data, to prevent it from being stolen or misused.

You could imagine my surprise when I saw Bennett Haselton’s 2007 article on Slashdot: Why Are CC Numbers Still So Easy to Find?. In short, Haselton was able to find Credit Card numbers through Google, firstly by searching for a card’s first eight digits in “nnnn nnnn” format, and later using some advanced queries built on number ranges. For example, he could use “4060000000000000..4060999999999999” to find all the 16 digit Primary Account Numbers (PANs) from CHASE (whose cards all begin with 4060). By the way: here’s a full list of Issuer ID numbers.

At the time, I didn’t think much of it, as Google immediately began to filter the types of queries that Bennett was using. When you tried to Google a range like that, Google would serve up a page that said something along the lines of “You’re a bad person”.

About six months ago, while reminiscing with an old friend, this hack came to mind again. Soon-after, I discovered something alarming. Not terribly alarming, but certainly alarming—so I notified Google, and waited. After a month without a response, I notified them again to no avail.

PCI DSS and SQL Server

What does PCI DSS mean for your SQL Server environment?

You might have asked yourself this question many times, especially if you have just been notified your database environment is now in scope of the PCI requirements.

The Payment Card Industry Data Security Standard (PCI DSS) applies to all entities involved in payment card processing who store, process, or transmit cardholder data or sensitive authentication data. In a nutshell, this standard applies to every company who works with credit card data. PCI DSS is maintained by the Payment Card Industry Security Standards Council (PCI SSC). The PCI SSC has been formed by American Express,Discover Financial Services, JCB International, MasterCard, and Visa Inc. The PCI DSS was originally released in 2004 and the latest version is 3.0 which was published in November 2013. The standard lists 12 requirements to secure the cardholder data and protect the sensitive data. The PCI DSS auditors perform onsite assessment annually including penetration testing, policy reviews and quarterly vulnerability scans on the network. There is a related standard which applies to software products: it is the Payment Application Data Security Standard (PA-DSS). PCI DSS compliance is mandated by both Visa and MasterCard.

This interesting article from Tibor Nagy will help you better understand the PCI DSS and how it is applied to your database environment. I recommend you read this article and the entire PC DSS before you consider any changes.

Additional article on this important subject: PCI DSS 3.o – What’s New?

The Target Breach, By the Numbers

With the Target breach in the news again as Target’s CEO Gregg Steinhafle stepped down, there has been several new stories about the credit card breach that the company originally announced on Dec. 19, 2013. Brian Krebs has a new post about the numbers behind the breach that you will find interesting.

40 million – The number of credit and debit cards thieves stole from Target between Nov. 27 and Dec. 15, 2013.

70 million – The number of records stolen that included the name, address, email address and phone number of Target shoppers.

46 – The percentage drop in profits at Target in the fourth quarter of 2013, compared with the year before.

200 million – Estimated dollar cost to credit unions and community banks for reissuing 21.8 million cards — about half of the total stolen in the Target breach.

100 million – The number of dollars Target says it will spend upgrading their payment terminals to support Chip-and-PIN enabled cards.

0 – The number of customer cards that Chip-and-PIN-enabled terminals would have been able to stop the bad guys from stealing had Target put the technology in place prior to the breach (without end-to-end encryption of card data, the card numbers and expiration dates can still be stolen and used in online transactions).

0 – The number of people in Chief Information Security Officer (CISO) or Chief Security Officer (CSO) jobs at Target (according to the AP).

You can read the entire post here, and Brian has a ton of useful information on his site if you are interested in cyber security.

 

PCI DSS – Storing Credit Card Numbers

If you have read the PCI DSS and the requirements for how you must store credit card data, you may be asking for some basic guidance for how to handle credit card numbers in your database systems.

These suggestions cover the basics – the full topic of protecting card data is easily several hundred pages long. These are basic ideas, but you should consult with your compliance team for final guidance.

1. Don’t Store Credit Card Data – PCI compliance is complex and can be very expensive. Getting hacked and dealing with the consequences of a system breach is more complex and even more expensive. Offload the problem to a vendor when possible.
2. Encrypt The Credit Card Number. If you insist on storing credit card numbers or can’t afford a better solution, they must be encrypted at rest and you have to document a key management plan that will satisfy the auditors. This applies to everywhere credit card data is stored, and it can’t be just any encryption method. You must use the acceptable encryption methods listed in the PCIDSS.
3. Don’t Store Track Data, CVV, CVV2, or PIN. Store any of these and you are automatically “non-compliant” with the PCI DSS.
4. Tokenize Card Numbers. Tokens “don’t count” as long as the tokenization method used is acceptable. Tokens let you do things like process cancellations without needing the ‘real’ card number.  Tokens do not need to be encrypted. The process is simple. The authorization process returns a token (usually a numeric or alphanumeric sequence) that is used to uniquely identify the transaction so you don’t have to store the credit card number.
5. You Can Store Masked or Truncated Data. You can store first six and last four characters of the card number. The rest of the card data is usually replaced with asterisks. You can store the expiration date and the card holder name. None of those require encryption. Don’t store it if you don’t need it. Tokenization makes this process very easy.
6. Log All Access. If someone accesses the credit card data on your system you need to know who, why, when, where, what, and how. If you use tokens, do the same for the tokenization transactions. Logs are incredibly important during you investigation as well as something that your editors will want to review. They allow you to monitor and potentially detect hackers, and they are your best chance of determining the scope of a breach when it happens. You need 90 days online and the ability to get the past 12 months in a relatively short time.
7. Delete Old Data. You need to delete old data as soon as you know you will no longer need the credit card number. This isn’t important when you have tokenized your transactions, n=but is a requirement if you want to reduce your breach scope. One example is if you are breached and your data is stolen, you will have to investigate and report ash stolen transaction. Would you rather pay for a few days of transactions or your last 3 years of transactions?
8. Test Cards In Development. Never test using real credit card numbers. Even if you’re using encryption never use valid card numbers in any type of development/non-prod/non-PCI environment. Your provider will provide you with some test credit card numbers that you can use to test authorizations.
9. Use Proper Tools. Profiler, third party monitoring tools, SSIS packages, they can all potentially capture and store card data as part of normal and seemingly routine activities. Make sure you understand what type of data is being captured by these types of tools and make sure the data from them is also treated the same as the data used on production authorization and settlement systems.

PCI DSS 3.0 – What’s New?

If your business takes credit cards, the Payment Card Industry Data Security Standard (PCI DSS) applies to your business. You should also know that it has been changed and the changes are effective next year.

I’ll tell you a little about some of the changes and their impact on the overall standard.

If you are not familiar with this the PCI DSS, you read the entire document for yourself from the PCI Security Standards Council. With nearly 100 changes, the current version has incremented one full revision and stands at v3.0.

When the council decides to make changes, it assigns each change to one of three main categories:

Type of Change	Definition of Change
Clarification	Clarifies intent of requirement. Ensures that concise wording in the standard portrays the desired intent of requirements.
Additional guidance	Explanation, definition and/or instruction to increase understanding or provide further information or guidance on a particular topic.
Evolving Requirement	Changes to ensure that the standards are up to date with emerging threats and changes in the market.

We’ll focus mainly on the evolving requirements (ER) section because most of them are additions to the standard. We’ll also touch on clarifications (C) and additional guidance (AG) some some important or interesting changes were made.

Here’s a reminder of the basic high-level PCI DSS requirements:

Control Objectives	PCI DSS Requirements
Build and Maintain a Secure Network	1. Install and maintain a firewall configuration to protect cardholder data
	2. Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data	3. Protect stored cardholder data
	4. Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program	5. Use and regularly update anti-virus software on all systems commonly affected by malware
	6. Develop and maintain secure systems and applications
Implement Strong Access Control Measures	7. Restrict access to cardholder data by business need-to-know
	8. Assign a unique ID to each person with computer access
	9. Restrict physical access to cardholder data
Regularly Monitor and Test Networks	10. Track and monitor all access to network resources and cardholder data
	11. Regularly test security systems and processes
Maintain an Information Security Policy	12. Maintain a policy that addresses information security

What’s New?

The first notable change was to remove the columns for “In Place”, “Not in Place” and “Target Date/Comments” in the requirements table. This was replaced with a “Guidance” column which aims to assist the reader in better understanding the requirement. This overall change in the document layout was intended to make the document easier to read.

Requirement 1

1.1.2/1.1.3 (C): Clarified what the network diagram must include and added new requirement at 1.1.3 for a current diagram that shows cardholder data flows.

When defining the cardholder data environment (CDE) it’s important to document which systems are in scope and how they interconnect. A network diagram is a great way to do this, but you might also want to diagram the flow of data as the credit card is scanned and moves through the systems for authorization and settlement.

The addition of requirement 1.1.3 is important because it forces you to look at how the data moves around and through your systems. This is also intended to document all the locations credit card data is stored, which may not be obvious without thinking through the entire process.

Requirement 2

2.1 (C): Clarified that the requirement for changing vendor default passwords applies to all default passwords, including systems, applications, security software, terminals, etc. and that unnecessary default accounts are removed or disabled.

This is just plain common sense, but unfortunately too many companies still misconfigure systems to keep default accounts they don’t use or fail to change default passwords. With the system documentation for just about any system being available on the internet, if you don’t change the vendor default passwords, just about anyone could find and use those default passwords to access your systems.

Requirement 3

3.5.2/3.5.3 (C): Split requirement 3.5.2 into two requirements to focus separately on storing cryptographic keys in a secure form (3.5.2), and in the fewest possible locations (3.5.3). Requirement 3.5.2 also provides flexibility with more options for secure storage of cryptographic keys.

These two requirements have added some needed guidance on key handling.

Requirement 3.5.2 even provides some examples:

• Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key
• Within a secure cryptographic device (such as a host security module (HSM) or PTS-approved point-of-interaction device)
• As at least two full-length key components or key shares, in accordance with an industry-accepted method

By the way, it is good practice to use the strongest key storage method at your disposal whenever possible. What seems like overkill today may save your company from a system breach tomorrow.

Requirement 5

5.1.2 (ER): New requirement to evaluate evolving malware threats for any systems not considered to be commonly affected by malicious software.

5.3 (ER): New requirement to ensure that anti-virus solutions are actively running (formerly in 5.2), and cannot be disabled or altered by users unless specifically authorized by management on a per-case basis.

Continuously evaluating systems for vulnerability and exploitability is good security practice. Including systems that are not thought to be a security risk is also a best practice. You may not even be aware of a security threat if you aren’t actively looking for them..

There a plenty of resources that are on the leading edge of vulnerability discovery. Here are three:

1. US-CERT
2. MS-ISAC
3. DFIR

As for requirement 5.3, we shouldn’t have to ask why this is important. If your system is compromised by a virus or malware, those credit are transactions processed on those systems won’t be safe from a potential compromise.

Requirement 6

6.5x (ER): Address common coding vulnerabilities in software-development processes as follows:

• Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory.
• Develop applications based on secure coding guidelines.

Make sure your software developers are keeping their knowledge and coding techniques up-to-date and that they always use industry best practices hen developing any custom software. You’ll have to demonstrate that your developers are using modern coding standards by producing evidence of those standards during any audit.

Requirement 8

8.2.3 (ER): Combined minimum password complexity and strength requirements into single requirement, and increased flexibility for alternatives that meet the equivalent complexity and strength.

8.3 (C): Clarified requirement for two-factor authentication applies to users, administrators, and all third parties, including vendor access for support or maintenance.

8.5.1 (ER): New requirement for service providers with remote access to customer premises, to use unique authentication credentials for each customer (effective July 1, 2015)

8.6 (ER): New requirement where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.) that the mechanisms must be linked to an individual account and ensure only the intended user can gain access with that mechanism.

You will want to use strong, unique passwords and force two-factor authentication whenever possible. Make sure people are using strong passwords and they change them at least every 90 days. Terminated employees should have their access immediately removed. This also includes any vendors that have access to your systems.

Requirement 9

9.3 (ER): New requirement to control physical access to sensitive areas for onsite personnel, including a process to authorize access, and revoke access immediately upon termination.

9.9.x (ER): New requirements to protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution (effective July 1, 2015)

These are good requirements indeed and similar measures have reduced the amount of ATM fraud. Anyone with physical access to the systems that process credit card data can be tampered with and that is a potential security risk.

Requirement 11

11.3.4 (ER): New requirement, if segmentation is used to isolate the CDE from other networks, to perform penetration tests to verify that the segmentation methods are operational and effective.

If you have specific controls in place to isolate you cardholder environment from the rest of your network, you must provide documentation on the design and configuration. You must also provide evidence the system configuration has been verified and tested.

Requirement 12

12.9 (ER): New requirement for service providers to provide the written agreement/acknowledgment to their customers as specified at requirement 12.8 (effective July 1, 2015)

Whether it’s your company or a service provider that is handling the sensitive data there will always be accountability.

What Next?

This list was not intended as an exhaustive list of all changes. This list is just a representative sample of the changes to this important and evolving document. You should read the entire document and consult a security specialist to make sure you understand the entire standard and have effectively implemented all the requirements. You can also read this article by Anthony Freed at Tripwire.

Retail Shift to EMV Doesn’t Solve Credit Card Security

Protecting and securing payment systems and consumer data is a never-ending task for all parties in a payment network, and it’s also a moving target. Retailers at the Electronic Transactions Association’s TRANSACT conference in Las Vegas (which includes credit card companies, banks, payment processors, regulators and retailers) all have the same fear. With the guild nature of security and hacking, any solution is potential only a temporary solution. They know that as soon as a new system or firewall is put in place, hackers have already figured out how to defeat or bypass it.

Most large retailers have had payment and data security teams in place for years, and have been working to migrate payment systems from the current magnetic stripe card readers to EMV systems (the chip-embedded cards and PIN-code technology widely used in Europe, often called “Chip and PIN”). Visa and MasterCard are giving merchants until October 2015 to have an EMV system in place. If merchants don’t comply, the responsibility to cover fraudulent purchasing will shift from the card companies to the merchants themselves. After the high-profile retail data breaches at Target, Neiman Marcus and Michael’s, a number of retailers are accelerating EMV technology plans.

The migration won’t be cheap or easy. Some have estimated it will cost retailers between $20 billion to $50 billion to upgrade systems to be EMV-compliant, while it will only cost about $2 billion to replace all consumer-level credit and debit cards with the new chip-embedded technology. Just weeks ago, Wal-Mart (the world’s largest retailer) enabled software at about 1,000 of its U.S. stores to accept chip-and-PIN cards, though there are few of those cards currently being used in the U.S.

Target has said upgrading its payment systems to accept chip-and-PIN cards is part of a $100 million effort to ready all of its 1,800 locations by the first quarter of 2015. The estimated cost for smaller mom and pop stores is around $3000 per store. This will move the entire point of sale system to a safer, smarter, and more secure systems.

But EMV systems are far from a panacea. When we look at the Target breach or some of the other retailers, those were breaches of retailers systems. EMV wouldn’t have done anything to stop the Target breach. EMV provides more encryption so credit card data is harder for hackers to replicate on counterfeit cards, but it wouldn’t have prevented the attackers from getting the data in an attack like what happened at Target.

How is Malware Planted on POS Systems?

If you have read the news reports in recent months, you have seen reports of malware causing credit card data breaches at several retailers, usually when their Point of Sale (POS) systems are compromised with rogue software that is designed to capture and transmit stolen credit card data to remote sites. The credit card data is later sold in large batches to be used by criminal gangs to create counterfeit copies of the stolen cards.

How is the data stolen?

To deploy their malware, a criminal must first gain access to the target system. This could include compromising POS systems prior to their installation at the retailer site or by physically tampering with the systems, but most often attackers gain access by utilizing a remote administration utility to gain remote access. These remote access utilities include Remote Desktop (RDP), Logmein, pcAnywhere, Bomgar, or RealVNC. IT support teams and POS system integrators use these utilities to perform legitimate remote administrative functions on POS systems and software. If remote access channels are not secured, however, an attacker can use them to gain access to the target as well.

Achieving access to the target environment is only the first step. An attacker also needs a username and password, preferably for an account with administrative authority. All too frequently an attacker can just use the default credentials added during installation of the POS software. With an open remote connection the attacker can breach the POS systems in a matter of seconds.

POS systems are not usually infected through common malware entry points, such as web browsing, visiting an infected site or using social media sites like Facebook. POS systems are prohibited from having general internet access. An attacker intentionally must place POS malware on the target system(s) and needs administrative privileges in order to do so.

What should I do next?

You should follow the Payment Card Industry (PCI) Data Security Standards (DSS) and take the basic security steps outlined in those standards. The relevant steps for this specific issue include:

• Changing all vendor default passwords
• Limiting or removing internet access to all POS systems
• Remove to limit remote access to POS systems
• Segment the POS network to limit systems that have access to terminals and storage systems
• Monitor access to POS systems to detect malicious software activity, including abnormal network traffic
• Install and maintain anti-virus software

Read the entire PCI DSS and implement all the required and recommended changes to help protect you network, data, and customer.

How Target Blew It

Late last year it was disclosed that the retail giant Target was breached by hackers and the data for over 40 million credit card accounts was stolen. There has been stories in the past about how the breach was executed, but why didn’t Target prevent or stop the breach? Now there is a story on Businessweek that says Target bought $1.6 Million anti-malware package 6 months before the breach, but didn’t pay any attention when the system alerted them to the detected intrusion.

For some reason, Minneapolis didn’t react to the sirens. Bloomberg Businessweek spoke to more than 10 former Target employees familiar with the company’s data security operation, as well as eight people with specific knowledge of the hack and its aftermath, including former employees, security researchers, and law enforcement officials. The story they tell is of an alert system, installed to protect the bond between retailer and customer, that worked beautifully. But then, Target stood by as 40 million credit card numbers—and 70 million addresses, phone numbers, and other pieces of personal information—gushed out of its mainframes.

If you have sensitive data in you database, you should make sure you have protected the data. If you have systems in place to alert you to  potential breach, make sure someone responds to the alert.