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.

Continue reading “PCI DSS – Storing Credit Card Numbers”


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 3rd 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.


Rethinking Mandatory Password Changes

We are told to change our passwords every 90 days. The primary reason given to uses is that users pick bad passwords and they can only be trusted for less than 90 days before they could be hacked.  Many users will complain that it is difficult to select at least 4 complex passwords a year. If you pair that with the inability to reuse the last 6 passwords (minimum PCI DSS requirement), and the fact that users have more than one account that requires a password, you are looking at the requirement for potentially hundreds (current and recently used) of unique passwords that they may have to remember.

FTC Chief Technologist Lorrie Cranor wrote in March 2016 that it is time to reconsider mandatory password changes:

Unless there is reason to believe a password has been compromised or shared, requiring regular password changes may actually do more harm than good in some cases. (And even if a password has been compromised, changing the password may be ineffective, especially if other steps aren’t taken to correct security problems.)

Their research also showed that once a user password has been hacked, they were able to guess the next password the user would select with relative ease.

The Carleton researchers also point out that an attacker who already knows a user’s password is unlikely to be thwarted by a password change. As the UNC researchers demonstrated, once an attacker knows a password, they are often able to guess the user’s next password fairly easily. In addition, an attacker who has gained access to a user’s account once may be able to install a key logger or other malware that will allow them to continue to access the system, even if the user changes their password.

While there are environments that are less flexible because of compliance requirements, you should look at other solutions to the threat of hacking.

A change in the frequency and type of passwords you require addresses the issue from a users perspective, but doesn’t address the problem of the cyber-mess a user must face when an internet site it hacked and their very complex and long password may still be compromised.

Research suggests frequent mandatory expiration inconveniences and annoys users without as much security benefit as previously thought, and may even cause some users to behave less securely. Encouraging users to make the effort to create a strong password that they will be able to use for a long time may be a better approach for many organizations, especially when combined with slow hash functions, well-chosen salt, limiting login attempts, and password length and complexity requirements. And the best choice – particularly if your enterprise maintains sensitive data – may be to implement multi-factor authentication.

Maybe this holiday season is a good time to rethink your password procedures to see if there is anything you can do to make the situation better for your users.

PCI Compliance Requirements – Merchant and Validation Levels

credit-cards - SeniorDBA

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.

PCI Update Targets PIN Vendor Systems


The Payment Card Industry (PCI) Security Standards Council has updated its requirements for payment device vendors to help address increased attacks against point of sale (POS) systems that allow interaction via a PIN. This new guidance also covers the manner in which payment devices are manufactured, stored, and transported to the merchants that end up using the devices.

The PCI Security Council now wants payment device vendors to demonstrate that changes in operational or environmental conditions do not compromise a device. This includes subjecting these POS devices (including PIN pads) to abnormal operating voltages or temperatures or outside normal range. Starting with this update, payment devices are also required to support vendor firmware updates. The device must cryptographically authenticate the firmware update and reject any update if it is unauthenticated.

Now vendors of PIN entry devices must ensure their devices cannot be modified while bring transported to a customer facility, and the opportunity for tampering is minimized.

Understanding Hacking

Most people today have heard about hacking and malicious attacks. You might have even seen the effects of this activity on the news, in your personal life, or while at work. What you might not understand is what a hacker really is and how they are different from other types of network users.


  • Malicious User – Usually an internal attacker that have limited access to company resources and decides to access sensitive data from within the company or even launch attacks on corporate systems from inside the network. This is usually an intentional attack, but can also be unintentional because their system has been compromised by another user through malware or virus.
  • Hacker – For many years this was defined as someone who liked to tinker with technology and experiment with ways to make technology useful in their environment. This has more recently meant someone who is remotely attacking systems for personal gain. Hackers usually have increased status with their friends if they can prove they accessed high profile environments or networks, but often attacks are completed without any acceptance of responsibility.
  • Ethical Hacker – This is someone who attempts to hack network systems to test the security of the systems involved, and use their knowledge to protect the target systems from unauthorized access or misuse. There are people who do this as part of their jobs, and are generally referred to as “system auditors” or “security specialists”, but that isn’t really ethical hacking.

Ethical Hacking is attempting to find new ways to use technology to improve a process or a different way to use something that is wasn’t intended to be used that way and it is helpful or doesn’t do any harm. It can also be the practice of attempting to find new security vulnerabilities in a piece of network hardware or in the software used in those devices. Security specialists or system auditors generally are testing systems against a list of known vulnerabilities, and ethical hackers are usually finding those new vulnerabilities. These different technology groups are doing different jobs, but are generally working together to make corporate network environments safer and more secure.

You should also be aware that there are several laws and guidelines that dictate the difference between unlawful and lawful activity when it comes to network security. You need to be aware that HIPPA, HITECH, GLBA, NERC, etc. all govern activities under U.S. federal law. There are also private guidelines like the PCI DSS requirements written by the credit card companies. If you stray outside of their requirements you could be identified as a hacker and on find yourself on the wrong side of the law. You should also be aware of any policies your company might have about network activity before you attempt any probing of your network security settings.

Understanding the Need to Hack

You have to think about Ethical Hacking like a treasure hunt. The first person who finds the treasure determines how it is used. If an ethical hacker finds the vulnerability, it can be reported and quickly fixed by the vendor before it can be used for illegal purposes. If a hacker finds the vulnerability, they will not report the issue and will use the new weakness to attack systems for personal gain.

To discover a new vulnerability, you have to think like a hacker. You have to understand what systems they would normally attack, what techniques they would use to compromise those systems, how to test against known vulnerabilities, etc. Since hackers prey on weak system security, you have to make sure you have the strongest possible security and force the average hacker to move along to another system that has weaker security. A determined and skilled hacker will often find a way into your network, but that doesn’t mean you have to make it easy for them to attack your systems.

A good ethical hacker will periodically attack their own network, simulating an attack by a determined hacker. The more vulnerabilities you test against, adding more variety in your attack techniques, and focusing on common attack methods while constantly adjusting and improving your network settings will help achieve your goal of total network security.

Ethical Hacking Techniques

As an ethical hacker, your goal is to secure your network systems:

  • Prioritize systems so your efforts are focused on the systems that matter the most.
  • Use nondestructive attacks to test systems for vulnerabilities.
  • List all known vulnerabilities and which ones you have tested so you can double-check your results and report to your corporate management the scope of your efforts.
  • Immediately address any vulnerabilities discovered on your network.

Another area of attacks to your network systems is non-technical attacks. This can be as simple as calling a few employees until you find on that will provide you with their network password. It could also involve sorting through discarded trash in the dumpster outside of your corporate office. You might also have success just walking around the office and looking for passwords taped to monitors or laptops. The key to improving the non-technical security is education of non-technical users.

One great resource for a list of known vulnerabilities is the NIST Vulnerability Database (NVD).

Remember, if you are going to be an Ethical Hacker, you have to have the highest moral standards and be trustworthy. Any misuse of the systems you are attacking is strictly forbidden and you must respect the privacy of the information discovered.