Keep Employees on a Need-to-Know Basis: A Look at PCI Requirement 7

See why you should restrict employee access to sensitive data.   

By: Matt Glade
Security Analyst
Need-to-know is defined as the least amount of data required for an employee to be able to perform his/her job. PCI requirement 7 focuses on restricting access to cardholder data on a business “need-to-know” basis.

Typically, employees don’t share the same responsibilities. Your accountant has different responsibilities than your system administrator. If your accountant had the same system level privileges as your system administrator, you’ve potentially created a new attack vector within your organization. If the accountant’s system was compromised, hackers could use it as a pivot point, and leapfrog into other vulnerable systems within the network. This could eventually lead to a cardholder data breach. This is why Requirement 7 is crucial to security.

Here’s what you should know about PCI DSS Requirement 7 and restricting access to a “need-to-know” basis.

SEE ALSO: PCI Requirement 7: 5 Reasons You Should Limit Employee Access to Your Data

Why restrict access? 

Even though Requirement 7 is one of the smallest sections of the PCI DSS requirements, it’s one of the most vital.

The PCI DSS requires you to have an RBAC (Role-Based Access Control) solution. This allows you the ability to grant, suspend, and revoke access to all systems within your network, but most importantly, the systems within your cardholder data environment.
Having a well-designed RBAC solution limits access to individuals and groups on a need-to-know basis.

Not only does an RBAC solution allow system administrators the ability to create unique usernames and passwords for each individual within your organization, it also helps create a trail in tracking who, what, when, and where a system was accessed. Remember, shared or group usernames and passwords should never be used since they cannot be traced back to an individual if a breach were to occur.

Requirement 7 is fairly basic in nature, and when implemented properly, can provide system administrators the control and visibility they need to securely manage the network.

SEE ALSO: The Importance of the PCI DSS: Why You Should Get Compliant

Who needs access to your cardholder data?

Here’s a list of job roles that might require access to sensitive data:
  • Accountants
  • IT staff
  • Executives
  • Support staff
  • Call center agents
User access applies to anyone in need of access to your systems. The big question to ask yourself is, how much access does each individual employee need? This should be answered in the documentation and approval section of Requirement 7.

Document your list 

Restricting access on a need-to-know basis is only a portion of PCI DSS Requirement 7. All employees that are granted access to your network must be approved and documented by authorized personnel (see Requirement 7.1.4). For example, you should document the following:
  • Employee’s name
  • Employee’s username
  • RBAC Group or Role
  • Type of User
  • Managing Supervisor’s Signature
  • Manager’s Approval
This exercise of documentation and approval helps system administrators, supervisors, and managers track which users have access to what systems and the permissions they’ve been granted. As users move about the company (e.g., promotions, demotions, on-boarding, off-boarding) these documents need to be updated to reflect their new RBAC roles and permissions.

Additional tips 

Here are a few additional PCI DSS Requirement 7 compliance tips:
  • Periodically audit your RBAC solution (e.g., quarterly or semi-annually) for inactive users and either permanently disable or delete them
  • During your defined periodic RBAC system audit, look for users with superfluous permissions and revoke them
  • Set up unique usernames and passwords to make sure each employee has unique credentials
  • NEVER use group or shared usernames and passwords
  • Train employees on limited access policies. Keep your employees in-the-know by providing ongoing security awareness training
  • Work with a QSA to help you find areas you may need to focus on
  • Properly harden and configure your firewall to protect your RBAC system from compromise
Need help getting PCI compliant? Talk to us!

Matt Glade (CISSP, QSA) has worked in the IT sector for over 20 years. He currently performs security assessments for merchants and service providers looking to become PCI compliant. He also performs HIPAA Risk Analysis/Assessments and HIPAA Compliance Assessments. He has been a Security Assessor for SecurityMetrics for over 4 years, lending his extensive knowledge of the IT industry in performing assessments for clients who wish to achieve PCI or HIPAA compliance.

A Look at the PCI SSC’s E-commerce Guidance: What to Know about PCI 3.2

Learn what PCI 3.2 expects from e-commerce merchants. 

George Mateaki, SecurityMetrics, CISSP, QSA
By: George Mateaki
Security Analyst
Many e-commerce merchants face similar issues when it comes to securing cardholder data.

The PCI SSC recently released a guidance for e-commerce websites. This guidance updates and replaces the PCI DSS E-commerce Guidelines published in 2013. It offers more guidelines for e-commerce businesses in reference to PCI DSS version 3.2.
Here are a few things from the guidance that your e-commerce business should know with PCI 3.2.

Know your e-commerce payment implementations’ security needs

e-commerce guidance
There are several technical tools and implementations e-commerce businesses can use as payment solutions. These tools, while often fairly secure, can come with some security risks that you should address. Here are a few examples:

iFrames are used to embed a web page within another web page. Businesses often use this tool in the checkout process to embed the page that handles cardholder data.

Using an iFrame will make you eligible for SAQ A, but remember that the iFrame could still be vulnerable to malware attacks, specifically malicious scripts coming from the website itself. You will need monitoring and alerting controls to help identify and prevent these types of attacks.

Direct post method (DPM)
The DPM method uses your business's website to generate a shopping cart and payment web pages. This puts your systems in scope for additional PCI DSS controls. You will need a subset of security controls to protect the web server, and the payment form. Tools like firewalls, vulnerability/penetration testing and patch management will also be required. With this method, you can fill out SAQ A-EP.
Application programming interface (API)
This method involves system-to-system data transmission where you control the progress of the payment transaction. Customer cardholder data is sent from the customer browser back to your website before it’s sent to the PSP. Often larger businesses and enterprises use this method, since it allows them to handle more customers.

With API, the risks are minimized, though since your business handles the cardholder data, you should apply the entire set of PCI controls applied to your in-scope systems. If you use this method, you should fill out an SAQ D.

These payment methods all have different risks and require different sets of security controls. Whichever one you use depends on the nature of your business and which works better for you. Just keep in mind that you should apply the correct security controls.

e-commerce Update your certificates

When it comes to your digital certificates, it’s crucial that they are updated and secure. Attacks like target non-secured certificates. Customers will also not visit your website should the certificate be labeled as not secure.

It’s highly recommended you use the current TLS certificates that provide the most modern encryption and are proven to be secure. Do not use SSL, which is outdated and has proven to have multiple exploitable vulnerabilities. PCI 3.2 has required that all businesses migrate from SSL to TLS certificates by January 2018.

Encrypt where needed

Per PCI DSS Requirement 4.1, cardholder data must be encrypted across open, public networks. There will be times where you will need to encrypt sensitive data. Make sure any data you do store is encrypted.

Encrypting cardholder data doesn’t remove it from scope of the PCI DSS. You should ensure that strong cryptography is used to secure data, which includes data in transit and in storage (even temporarily).

SEE ALSO: Securing Mobile Devices with Mobile Encryption

Remember that your e-commerce business will have its own security challenges. Make sure you properly secure any sensitive data to protect your business and your customers.

Need help with getting PCI compliant? Talk to us! 

George Mateaki (CISSP, CISA, QSA, PA-QSA) is a Security Analyst at SecurityMetrics with an extensive background in Information Security and 20+ years in IT.

SecurityMetrics 2017 Guide to PCI DSS Compliance
A Quick Look at SAQ P2PE: Reducing Your PCI Workload

Learn more about this SAQ and who qualifies for it.   

By: George Mateaki
Security Analyst
The P2PE SAQ is for merchants that use a P2PE solution for their payment transactions. By doing so, they greatly reduce the number of SAQ questions they have to fill out.

Compared to SAQ D, which has 329 questions, SAQ P2PE has only 33 questions and doesn’t require a vulnerability scan or a penetration test. This makes PCI compliance much easier and faster for merchants that use P2PE.

SEE ALSO: Updating PCI DSS SAQs to 3.2: The Changes You Should Know

These merchants don’t have any access to clear-text cardholder data on any computer system, and only deal with data through hardware payment terminals from a PCI SSC-approved P2PE solution.
Here are a few things you should know about SAQ P2PE.

Who qualifies for SAQ P2PE?

SAQ P2PEAccording to the PCI SSC, here are some factors that qualify merchants for this particular SAQ:
  • All payment processing is through a validated PCI P2PE solution approved and listed by the PCI SSC
  • The only systems in the merchant environment that store, process or transmit account data are the Point of Interaction (POI) devices which are approved for use with the validated and PCI-listed P2PE solution
  • Your business doesn't otherwise receive or transmit cardholder data electronically
  • There's no legacy storage of electronic cardholder data in the environment
  • If your business stores cardholder data, that data is only in paper reports or copies of paper receipts and isn't received electronically
  • Your business has implemented all controls in the P2PE Instruction Manual (PIM) provided by the P2PE Solution Provider
Remember that this SAQ does not apply to e-commerce businesses. This SAQ also includes questions that apply to a specific type of small merchant environment.

What requirements does it cover? 

P2PEThis SAQ covers fewer requirements than other SAQs, mostly since P2PE helps eliminate many potential security issues with card data. Here are the requirements it handles:
  • Requirement 3: Protect Cardholder data
  • Requirement 9: Restrict physical access to cardholder data
  • Requirement 12: Maintain a policy that addresses information security for all personnel
Keep in mind that while this SAQ covers a few requirements, it would be a good idea to look over the other PCI requirements to ensure your business is fulfilling them where applicable.

What questions will I address? 

Here is a sample of a few questions you’ll be answering for this SAQ:
  • Are there specific retention requirements for cardholder data? 
  • For all paper storage, is the card verification code not stored after authorization? 
  • Is all media destroyed when it’s no longer needed for business or legal reasons? 
  • Are devices that capture card data through direct physical interaction with the card protected against tampering and substitution? 
  • Are personnel trained to be aware of attempted tampering or replacement of devices? 
  • Do security policies and procedures clearly define information security responsibilities for all personnel?
  • Has an incident response plan been created to be implemented in the event of a breach? 

Additional tips

Here are a few things to consider when getting PCI compliant:
  • Limit access to data: Make sure to restrict physical access to card data to only the employees that need it 
  • Establish a stolen device policy: Have a procedure set in place for what employees should do if they discover a device has been stolen/tampered with
  • Train employees at least quarterly: It’s crucial that your employees are aware of and follow security policies and procedures 
Need help with PCI compliance? Talk to us! 

George Mateaki (CISSP, CISA, QSA, PA-QSA) is a Security Analyst at SecurityMetrics with an extensive background in Information Security and 20+ years in IT.

SecurityMetrics' Guide to PCI DSS Compliance
New Multi-Factor Authentication Clarification and Supplement: The Principles You Should Know

Learn more about the multi-factor authentication that is required of your business operations. 

By: Christopher Skarda
Security Analyst
Multi-factor authentication (MFA) can be used to enhance the security of your data, particularly in remote access applications. But many businesses don’t know how it applies to PCI DSS compliance.

The PCI DSS standard has both old and new MFA requirements that you need to be aware of.  The PCI Security Standards Council also released a supplemental guide on multi-factor authentication, clarifying the industry-accepted principles and best practices associated with MFA. Here are a few things you should know.

What is multi-factor authentication? 

multi-factor authenticationMulti-factor authentication is an effective way to secure your CDE, and is a requirement under PCI DSS. When multi-factor authentication is properly enforced, you must provide at least two of these three categories of credentials to authenticate: 

  • Something you know (e.g., password/passphrase, PIN) 

  • Something you have (e.g., token device, one-time password) 

  • Something you are (e.g., fingerprint scan, retina scan)
This diversity of required credentials greatly reduces the risk of unauthorized access to your secure environments.

The existing requirements

Requirement 8.3.2 of the PCI DSS 3.2 states that you must “incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network.”

In other words, MFA must be enforced for all remote access to your corporate networks that are part of your cardholder data environment, or have access to your cardholder data environment. This requirement is maintained from previous versions of the PCI DSS.

multi-factor authentication requirements PCI 3.2 changes

Requirement 8.3.1 is new to PCI DSS 3.2. It’s currently best-practice, but it becomes effective as a requirement after January 31, 2018.

This new requirement states: “Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.” Previously, MFA was required only for remote access by employees, administrators, and third parties. This additional sub requirement states that MFA is required for all non-console administrative access to the CDE internally as well. 

SEE ALSO: 2 Things You Should Know about PCI 3.2 Multi-Factor Authentication Updates

Supplement clarifications

The Multi-Factor Authentication Informational Supplement from the PCI Security Standards Council provides the following guidelines and industry best practices that should be followed when implementing MFA:
Authentication mechanisms should be maintained independent of one another.
This ensures that access to one factor does not grant access to another, and the compromise of any one factor does not affect the integrity or confidentiality of any other factor. For example, if the same set of credentials (e.g., username/password) is used as an authentication factor and also for gaining access to an e-mail account where a secondary factor (e.g., one-time password) is sent, these factors are not independent. Another faulty example is if you use a software certificate that is stored on a mobile device and protected by the same username and password that is used as part of MFA.

No knowledge of the success or failure of any factor should be provided to the individual.  Instead, a collective success or failure message should be given once all factors have been submitted. In the event of failed authentication, there should be no indication of which provided credential is incorrect.

What applications should use multi-factor authentication?

Here’s a list of applications that should use multi-factor authentication:
  • Remote access technologies
  • Cloud storage used for sensitive documents
  • Email accounts
  • Cloud computing administration interfaces
  • Hosting services
  • Password management tools
  • Any account with access to sensitive information
Remember, multi-factor authentication is an additional layer of security you should apply to all of your sensitive data.

Need help with PCI compliance? Talk to us!

Christopher Skarda (CISSP, QSA, CCNA) is a Security Analyst at SecurityMetrics and has worked in data security for thirteen years and the PCI sector for three years. He has a Bachelor of Science in Information Technology from BYU.

PCI Requirement 6: Updating Your Systems

See why updating and patching your systems is crucial to security.  

George Mateaki
Security Analyst
Requirement 6 deals with consistently updating your systems and patching any vulnerabilities that appear.

Here are a few things you should know about requirement 6.

Why patch and update systems?  

PCI requirement 6Requirement 6.1 states merchants must “deploy critical patches within a month of release” to maintain compliance. 

Application developers are not perfect, which is why updates to patch security holes are frequently released. Once a hacker knows he can get through a security hole, he passes that knowledge on to the hacker community, who then exploit this weakness until the software has been updated.
Quickly implementing security updates is crucial to your security posture.
You should patch all critical components in the card flow pathway, including:
  • Internet browsers 

  • Firewalls 
  • Application software 

  • Databases 

  • POS terminals 

  • Operating systems 

This is especially true for Windows systems. Older Windows systems can make it difficult for merchants to remain secure, especially when the manufacturer no longer supports a particular operating system or version (e.g., Windows XP). Operating system updates often contain security patches to exposed vulnerabilities. If you use an unsupported operating system that doesn’t receive updates and patches, the vulnerability potential increases exponentially.

Be vigilant and consistently update the software associated with your system. Don’t forget about critical software installations like credit card payment applications and mobile devices. To help keep up to date, ask your software vendors to put you on their patch/upgrade email list. 

SEE ALSO: Security Patches in Your Business: Complying with PCI Requirement 6.1

Establish software development processes

If you develop payment applications in-house (e.g., E-commerce websites, POS applications) you must use very strict development processes and secure coding guidelines as outlined in the PCI DSS.

Don’t forget to develop and test applications in accordance with industry accepted standards like the Open Web Application Security Project (OWASP). This will guide you in your application development process by enforcing secure coding practices and keep software code safe from malicious vulnerabilities (e.g., cross-site scripting, SQL injection, insecure communications, CSRF, etc.).

Use web application firewalls

Requirement 6In addition to updating and securing applications, web application firewalls (WAFs) should be implemented in front of public-facing web applications to monitor, detect, and prevent web-based attacks. They can also be used to perform application security assessments. Even though these solutions can’t perform the many functions of an all-purpose network firewall (e.g., network segmentation), they specialize in one specific area: monitoring and blocking web-based traffic.

A WAF can protect web applications visible or accessible from the Internet, including outward facing or intranet applications that involve payment card acceptance. As per PCI DSS regulations, your WAF must be up to date, generate audit logs, and either block cyber-attacks or generate a cyber security alert if an attack is suspected.

Migrate away from SSL and TLS

SSL and TLS 1.0 are no longer considered acceptable forms of encryption when data is transmitted over open, public networks. The PCI Council has recently extended the migration deadline from June 30, 2016 to June 30, 2018 because so many companies require more time to migrate their systems to at least TLS 1.2 or higher. It’s crucial that you move away from these versions to more secure versions as soon as possible.

SEE ALSO: DROWN Attack and SSL: What You Need to Know

While you work towards this goal, you are required by the PCI Council to write a Risk Mitigation/Migration Plan, which details how you will mitigate this risk until you’ve completed the migration.

Need help with PCI compliance? Talk to us!

George Mateaki (CISSP, CISA, QSA, PA-QSA) is a Security Analyst at SecurityMetrics with an extensive background in Information Security and 20+ years in IT.

SecurityMetrics 2017 Guide to PCI DSS Compliance