Monday

Tag: PCI DSS

History and Status of the PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) was created in response to the rapid growth of credit card transactions in the 1990s causing thousands of small companies to start storing credit card data and processing consumer transactions on unprotected networks.  Since many of these small businesses didn’t know how to properly secure these credit card transactions, it also led to a rapid increase in data theft and a growing concern from banks and credit card companies about ways to protect their brand and consumer accounts. In an effort to resolve the growing concern around payment card fraud and cybercrime in general, industry leaders such as Visa, MasterCard, and American Express got together and created a global security standard to protect online card payments.

The PCI DSS standard was established to set basic guidelines and requirements around how businesses must create a safer cardholder data environment, using basic requirements to drive minimum requirements around security that would lead to more secure business systems. As the standard evolved and procedures more refined, PCI DSS became an internationally accepted standard for all merchants and service providers.

PCI DSS History

PCI DSS was introduced in December 2004, after Visa and other brands had introduced their own standards.  These brand-specific standards weren’t well received by merchants and service providers, since these were small companies that didn’t need the confusion of multiple standards.

Continue reading “History and Status of the PCI DSS”

PCI 101: Becoming PCI Compliant

The Payment Card Industry (PCI) has established compliance requirements to help merchants protect customer credit card data. Since criminals want to harvest credit card data so they can steal the information and use the data to create fraudulent transactions, customer credit card data must be protected. The banks have developed some sophisticated algorithms to help detect and prevent this type of fraud, but the bulk of prevention happens at the merchant level with controls to prevent thief of the card holder data (CHD).

Overview

I’ll discuss the highest-level requirements, known as Level 1, because they are the most complex and difficult to implement. If the banks and credit card companies got their way, they would want everyone to be at Level 1 so they would know security compliance efforts would be at the highest level possible. You are assigned a level by your bank based on the number of credit card transactions performed in a 12-month period. If you have several million transactions, your CHD is at a higher risk than a smaller business with just a few transactions per week. The basic breakdown is based on VISA transaction counts: Continue reading “PCI 101: Becoming PCI Compliant”

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.

Continue reading “Selecting a PCI QSA Vendor”

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.

Continue reading “PCI DSS 4.0 – Coming Soon”

PCI 101: Becoming PCI Compliant

The Payment Card Industry (PCI) has established compliance requirements to help merchants protect customer credit card data. Since criminals want to harvest credit card data so they can steal the information and use the data to create fraudulent transactions,  customer credit card data must be protected. The banks have developed some sophisticated algorithms to help detect and prevent this type of fraud, but the bulk of prevention happens at the merchant level with controls to prevent thief of the card holder data (CHD).

Overview

 

I’ll discuss the highest level requirements, known as Level 1, because they are the most complex and difficult to implement. If the banks and credit card companies got their way they would want everyone to be at Level 1 so they would know security compliance efforts would be at the highest level possible. You are assigned a level by your bank based on the number of credit card transactions performed in a 12-month period. If you have several million transactions, your CHD is at a higher risk than a smaller business with just a few transactions per week. The basic breakdown is based on VISA transaction counts:

  • Level 1  – Merchant processes over 6 million VISA transactions per year (or is designated Level 1 because of a previous breach or identified security issues)
  • Level 2 – Merchant processes between 1 and 6 million VISA transactions annually.
  • Level 3  – Merchant processes between 20,000 and 1 million VISA transactions per year.
  • Level 4 – Merchant processes fewer than 20,000 VISA payments per year.

Continue reading “PCI 101: Becoming PCI Compliant”

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.

Continue reading “EMV Credit Card Chips Don’t Stop Fraud”

PCI DSS – Centralized Log Management System

The collection of event logs is required under the PCI DSS, which would be used to reconstruct the scope and timeline of a data breach if the network of a company that accepts credit cards is compromised. This means more companies are using their security logs to detect and analyze malicious incidents. While some might say these companies could be collecting too much log data (think billions of events per day) it is easier to exclude data in your analysis than to find details of an attack without enough log data. Collect as many events as your company can afford to put in your budget.

A centralized log management system can help you collect all the relevant logs into a standardized format, help prevent editing/deletion of valuable evidence, provide a simple interface to perform analysis, limit who has access to the logged events, and provide one location to schedule a backup of huge amounts of data.

Security event logging basics

The best guide to security logging is the National Instituted of Standards & Technology (NIST) Guide to Computer Security Log Management (Special Publication 800-92). Although it was originally written in 2006, it still provides the basics of security log management, so it can be very helpful to anyone new to the process.

Continue reading “PCI DSS – Centralized Log Management System”

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

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.

LevelMerchant Selection CriteriaValidation Requirements
1Merchants 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
2Merchants 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
3Merchants processing 20,000 to 1 million Visa e-commerce transactions annually
  • Annual SAQ
  • Quarterly network scan by ASV
  • Attestation of Compliance Form
4Merchants 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

ACard-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-EPE-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.
BMerchants 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-IPMerchants 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-VTMerchants 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.
CMerchants with payment application systems connected to the Internet, no electronic cardholder data storage. Not applicable to e-commerce channels.
P2PE-HWMerchants 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.
DSAQ 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.

Terminology

  • 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.

PCI 101: Becoming PCI Compliant

The Payment Card Industry (PCI) has established compliance requirements to help merchants protect customer credit card data. As you might imagine, criminals want to harvest credit card data so they can steal the information and use the data to create fraudulent transactions. The banks have developed some sophisticated algorithms to help detect and prevent this type of fraud, but the bulk of prevention happens at the merchant level with controls to prevent thief of the card holder data (CHD).

Overview

I’ll discuss the highest level requirements, known as Level 1, because they are the most complex and difficult to implement. If the banks and credit card companies got their way they would want everyone to be at Level 1 so they would know security compliance would be the highest. You are assigned a level by your bank based on the number of credit card transactions performed in a 12-month period. If you have several million transactions, your CHD is at a higher risk than a smaller business with just a few transactions per week. The basic breakdown is based on VISA transaction counts:

  • Level 1  – Merchant processes over 6 million VISA transactions per year (or is designated Level 1 because of a previous breach or identified security issues)
  • Level 2 – Merchant processes between 1 and 6 million VISA transactions annually.
  • Level 3  – Merchant processes between 20,000 and 1 million VISA transactions per year.
  • Level 4 – Merchant processes fewer than 20,000 VISA payments per year.

The PCI DSS contain 12 pillars for data security. You are expected to address all 12 areas, and have an external auditor validate, at least once per year, that you are performing all the prescribed actions and that you have all required controls in place. Once the auditor verifies this compliance with an annual audit, they will issue a Report of Compliance (ROC) that lists all the reasons why your business is compliant, and you must provide this document to your bank.  Failure to remain compliant, and prove it with a ROC, will mean your bank could refuse to let you accept credit cards and they could fine you thousands of dollars for misleading them as to your level of compliance.

Requirements

The summary of the 12 PCI DSS Requirements:

  1. Install and Maintain Firewalls – You must have a perimeter firewall between the systems that collect, process, and store CHD and the internet. You will need to properly configure you firewalls to prevent unauthorized access to the CHD systems, and have controls in place to manage who can make changes to that approved configuration.
  2. Eliminate Vendor Supplied Default Passwords – Nearly every piece of equipment used in IT comes with a standard password that you are allowed to change once you have installed the equipment on your network. This issue is a lot of people never change those default passwords, and almost anyone who is in IT knows what the default passwords are on which piece of equipment. Always change the default passwords and make sure only a select few people know what they are at any time.
  3. Protect the CHD – Make sure you know where your credit card data is collected, processed, and stored so that you can identify the systems that require protection.
  4. Encrypt Transmission of CHD – Never send credit card data across the internet without the proper level of industry approved encryption.
  5. Protect against Malware and Viruses  – Make sure your systems are protected against malware and viruses. Maybe anti-virus software doesn’t always work as well as you like, but this basic protection is better than nothing at all.
  6. Maintain Secure Systems – You should configure your in-scope systems to be as secure as possible, and have documentation to show how you did that when the system was installed and after any maintenance.
  7. Restrict Access – Only approved people should have access to in-scope systems. Make sure the systems are secure and you have limited who has physical and remote access to those systems as much as possible.
  8. Authenticate Access –  Ever user that accesses those systems should have their own unique login. You don’t share accounts, and the system knows your unique identity so if something gets compromised they can link the crime to a specific person.
  9. Restrict Physical Access – Put your corporate servers behind a locked door. Limit access to corporate switches so that only approved personnel have physical access. These basic controls improve security and limit unauthorized changes to configuration and system settings.
  10. Track Network Access – You need to know who has access to the systems and make sure terminated employees lose access immediately. You also want to log system activity to identify abnormal activity and unauthorized system changes.
  11. Regularly Test Security – Make sure you have a Incident Recovery Plan and that you test procedures for a system failure or security breach at least once per year.
  12. Maintain a Security Policy – Write a security policy and publish it to the entire company. Make sure everyone knows their part in protecting customer data, including credit card transaction data. Make sure they acknowledge they have been briefed on the contents each year with sign-off sheets and evidence of training.

Actions

What actions must you take to complete this compliance action?

  1. Talk to your bank – Make sure they understand your concerns and answer your questions about your level based on your transactions, as well as the timeline and expectations for when they expect you to complete the compliance process and submit your ROC. The bank drives this process, you you must work directly with them to make sure you are meeting their expectations.
  2. Understand Penalties – Make sure you understand the cost of non-compliance. It should be much cheaper to demonstrate compliance than pay the expected penalties and fines that will be imposed by your bank if you do nothing. Use this information to help understand your budget as well as sell the project to your management team. Remember: Businesses may also be subject to lawsuits and governmental prosecution for failing to protect customer data through non-compliance, so you may need to seek legal advice if you choose not to take the compliance route.
  3. Read the PCI DSS – The PCI Council creates the compliance requirements and provides you will the written requirements in the format of a document called the Payment Card Industry Data Security Standard (PCI DSS). The documentation is free and you should download everything you can fin and start reading.
  4. Engage a QSA – You will need a Qualified Security Assessor (QSA) to review your infrastructure and verify you are meeting the PCI DSS requirements. This is going to cost some money, but it is required. A level 1 merchant is required to have an external QSA sign-off that they have verified you are meeting all the requirements and issue a Report of Compliance (ROC) each year. Your QSA should also help you create the evidence required, make sure you are performing all the tests correctly, and help you document all the new policies and procedures they will need for the audit.
  5. Start Network Scans – You will also need to engage an Approved Scanning Vender (ASV) to start performing external network scans and penetration tests. These services are important to provide evidence that your network is secure from external attacks, properly configured, and patched with the latest vendor security updates. You will also need to either do internal scans yourself, or hire someone with the relevant skills, to scan your internal network. These internal scans are looking for security vulnerabilities and incorrectly configured systemsthat have access to CHD.
  6. Passwords – Start reviewing all systems looking for default passwords. Change vendor provided passwords immediately, and implement a password program for all your employees. Passwords should be changed regularly in compliance with vendor instructions, generally meaning every 90 days.
  7. Protect In-Scope Systems – Your systems should be protected with anti-virus and malware detection software.  You will also need to develop policies and procedures that prohibits users from adding unapproved software (games, internet applications, etc.), that could compromise the in-scope systems. No user should access those systems with shared accounts. Each user needs their own account, and the permission on their account should provide the least permissions required for that person to perform their job. You will also need to monitor all in-scope systems for file changes and collect event logs to track all activity on those same systems.
  8. Information Security Policy – You will need to create, among other policies, a formal Information Security Policy. This document will be the key evidence of what steps you and your employees are doing to make your systems compliant and how you are keeping them compliant all year long.
  9. Incident Recovery Plan – If you don’t already have one, you will have to create one for the QSA. You will also need to conduct a test of the plan at least once per year. The QSA will help you create a plan that matches your environment while also including the sections required for the compliance effort. They can also help you understand how to schedule, conduct, measure, and document a test and help make sure you are ready for future issues while demonstrating compliance today.
  10. Conduct an Audit – Once you have everything in place, the QSA will conduct an audit to verify you are performing the correct actions and have ample evidence to prove you are compliance. They will then issue you a ROC as well as the other required documents.
  11. Submit the ROC – Your bank will have given you a deadline to submit your ROC. If you provide the ROC before the deadline, the bank will inform the payment card companies you are compliant and you will continue to allow you to accept credit cards without any penalties or fines.
  12. Lather, Rinse, Repeat – Keep doing what your QSA told you to do on the schedule they tell you to do each action. They will continue to complete the same steps on a fairly regular quarterly schedule, with an annual assessment timed to issue a new annual ROC right before the bank generated deadline. Work directly with your QSA and your bank to maintain compliance.

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.

MasterCard Selfie Verification For Mobile Payments

MasterCard is testing the ability to verify mobile transactions in England by requiring the use of a selfie to indicate you are present for the transaction. The current testing is to have the customer opt into either a fingerprint of selfie verification mode for mobile payments, instead of traditional passwords or PIN numbers.

There is no word on the scope of testing or how much of a delay this adds to the transaction process, but the goal is to reduce or eliminate the $118 Billion issue of false declines each year. You can read more about the project here.

Inside Target After 2013 Credit Card Breach

In a recent article by Brian Krebs, we get a little more insight into the credit card breach at Target back in late 2013. In the attack that led to over 40 million credit card accounts being compromised and has cost Target about $100 million, we are now seeing some information coming out as a result of the lawsuits making their way into court. In this article we get some helpful tips on what they did wrong, so you might not make the same mistakes. Verizon was hired by Target as the breach was discovered, and their report is the most detailed information about the breach we have seen so far:

  • No controls limiting their access to any system, including devices within stores such as point of sale (POS) registers and servers
  • HVAC vendor given 24×7 access to the network, without limits to systems or network segments
  • Target has a password policy, but the Verizon security consultants discovered that it was not being followed
  • Within one week, the Verizon security consultants reported that they were able to crack 472,308 of Target’s 547,470 passwords (86 percent) that allowed access to various internal networks
  • Penetration testers also identified many services and systems that were either outdated or missing critical security patches
  • Networks were internally tested using Nessus, but issues were never remediated

This makes for an interesting read.

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 Compliance Guide

PCI/DSS Security Overview

What is the PCI Data Security Standard (PCI DSS)?

The PCI DSS is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures associated with credit card account data. This comprehensive standard is intended to help organizations proactively protect customer credit card account data that is either stored, processed, or transmitted.

All merchants, regardless of the annual transaction volume (merchant level assigned) are required by the various card brands (Visa, MasterCard, American Express, Discover, JCB) to follow the standard. Merchants not adhering to the standard are subject to substantial fines levied by the card associations.

What are CISP and SDP?

Compliance with the PCI DSS is in addition to the requirements specified by each card association’s “validation” program (Visa’s CISP and MasterCard’s SDP). CISP stands for “Cardholder Information Security Program,” and SDP stands for “Site Data Protection.”

Therefore, PCI DSS refers to “compliance,” while CISP and SDP refer to “validation” of that compliance. The validation of compliance requirements are those of CISP and SDP, which are incorporated into the card associations’ rules. Merchants are required contractually to adhere to all card association rules.

What are Merchant Levels?

In accordance with Visa’s CISP and MasterCard’s SDP, each merchant is assigned a “merchant level,” to help an acquirer determine what procedures are to be taken by the merchant to demonstrate “validation” of the merchant’s compliance with the PCI DSS. The level assigned to a merchant is based primarily upon the merchant’s annual transaction volume, taking into account e-commerce transactions only, and all transactions regardless of acceptance channel.

Level 1 Merchant

Level 1 is the most stringent level and is assigned to a merchant with all Visa transactions exceeding 6 million annually, or with all MasterCard transactions exceeding 6 million annually, or any merchant that has experienced a security breach that resulted in an account compromise. A level 1 merchant is required to have an annual on-site PCI security audit performed annually, while the other three levels do not require such on-site annual audit.

Level 2 Merchant

A level 2 merchant is one, regardless of acceptance channel, processing 1,000,000 to 6,000,000 Visa or MasterCard transactions per year. Level 2 merchants are required to complete an annual self-assessment questionnaire, and to perform a vulnerability network scan at least quarterly (for external-facing IP addresses).

Level 3 Merchant

A level 3 merchant is one processing 20,000 to 1,000,000 Visa or MasterCard e-commerce transactions per year. Level 3 merchants are required to complete an annual self-assessment questionnaire, and to perform a vulnerability network scan at least quarterly (for external-facing IP addresses).

No date has yet been established for a level 3 merchant to provide an attestation to Visa of its compliance.

Level 4 Merchant

A level 4 merchant is a merchant that has either – fewer than 20,000 Visa or MasterCard e-commerce transactions annually; or one, regardless of acceptance channel, fewer than one million Visa or Mastercard transactions.

Completion of the annual Self-Assessment questionnaire and conducting of a quarterly vulnerability network scan (same as required of a level 2 and 3 merchant) are recommended by Visa and MasterCard, but may be required by the merchant’s acquirer (STMS or other processor).

No date has yet been established for a level 4 merchant to provide an attestation to Visa of its compliance.

You can get more information about PCI from here.

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 ChangeDefinition of Change
ClarificationClarifies intent of requirement. Ensures that concise wording in the standard portrays the desired intent of requirements.
Additional guidanceExplanation, definition and/or instruction to increase understanding or provide further information or guidance on a particular topic.
Evolving RequirementChanges 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 ObjectivesPCI DSS Requirements
Build and Maintain a Secure Network1. 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 Data3. Protect stored cardholder data
4. Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program5. 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 Measures7. 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 Networks10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes
Maintain an Information Security Policy12. 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.

%d bloggers like this: