2017 PANscan Study: How to Better Protect Your Card Data

See how much unencrypted card data PANscan found on business networks in 2016. 

By: George Mateaki
Security Analyst
CISSP, QSA
Want to see how businesses did with card data in 2016? Check out our infographic “2017 PANscan Data Analysis.”

More businesses store unencrypted card numbers than you think, and the numbers have gone up this year.

According to our 2017 PANscan study, 67% of businesses that used PANscan had unencrypted card data in their networks. Additionally, 5% of businesses stored track data.
PANscan found over 88 million unencrypted cards on business networks in 2016.
Let’s compare these statistics to the 2016 PANscan study: Businesses have increased storage of unencrypted card data from 61% to 67%. This is a pretty significant change, especially since the previous years saw numbers like 62% and 60%. But businesses have also decreased storage of track data from 10% to 5%.

Overall, businesses still struggle to keep PAN secure, but they seem to be doing better with track data.

Protecting card data can get tricky sometimes. Here are some ways to better protect your businesses’ stored card data.

SEE ALSO: PCI DSS Requirement 3: What You Need to be Compliant

Don’t store card data

If you can run your business without the need of storing card data, it’s highly recommended. It will help simplify your security process, and reduce your PCI scope greatly. For example, if you store and handle card data, the PCI DSS will require you to fill out SAQ D, which has over 300 questions. If you don’t store card data, you can fill out SAQ A, B, or C, which have less than 100 questions.

Some ways to avoid storing card data are to use tokenization or outsource card data handling to a third-party. This will mean that another company will handle your card data. You’ll still need to make sure they follow PCI requirements, but most of the responsibility and liability won’t be on your business.

Remember, the less card data you store, the less you have to worry about.

Monitor your card data flow

Many businesses that store unencrypted card data often don’t realize they’re storing it. Card data can be found in areas you may not initially think about.

You should make a card flow diagram that tracks the process your business goes through as it uses, stores, or transmits card data. This will help you see where card data enters and exits your business.

Here are some areas unprotected card data may be unintentionally hiding:
  • Printers often store old jobs, which could include card data
  • Error logs frequently contain the card number in plaintext during a failed authentication
  • Customer service may take card numbers over the phone, so watch for printed card data
  • Sales departments may have emailed or printed forms with card numbers
  • Web browser cache may store card data inadvertently

Encrypt card data

Your card data should be encrypted when not in use. This keeps your card data safe, even if it should get stolen. It’s recommended you use point-to-point encryption (P2PE) as it encrypts the data from the point of interaction until it’s processed.

P2PE prevents non-encrypted card data from existing in the payment environment. Even if a hacker should steal this data, they would only get encrypted card numbers with no way to decode them.

SEE ALSO: Securing Mobile Devices with Mobile Encryption

Implement network segmentation

While network segmentation isn’t required by the PCI DSS, it’s good practice to keep your networks that handle card data separate from your other networks.

Whether you do it physically or through a firewall, make sure your systems that store, process, and transmit card data are kept separate from other systems. This reduces your PCI scope, and keeps card data from spreading to unknown areas.

SEE ALSO: New 3.2 Requirements for Penetration Testing and Segmentation: What You Don’t Know

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.

PCI Done Right: Talk about PCI at TRANSACT17!

TRANSACT 17

Win a DJI Phantom 3 Drone, get some sweet SecurityMetrics swag, and get questions answered by our QSAs and security experts!

TRANSACT 17Who’s excited for TRANSACT this year? We definitely are! This year, we decided to do something a little different.

We’re giving you the chance to talk to some of our QSAs and address any questions you have about PCI DSS compliance! We’ll also be giving out hard copies of our new 2017 Guide to PCI DSS Compliance.

Ask a QSA

First, head on over to booth 722 at TRANSACT16. We will have a QSAs there who can answer any questions you may have about PCI DSS compliance, forensic investigations, and data security.

Win a DJI Phantom 3 drone and other prizes!
We’ll also be doing 2 drawings where you can enter for a chance to win a DJI Phantom 3 drone. You can also get other SecurityMetrics swag including
  • “PCI Hero” t-shirts
  • custom SecurityMetrics edition socks
  • insulated mugs that keeps your drink cold up to 24 hours

PCI Done Right!

transact 17Getting PCI compliant can be a headache, and if it’s not done right, you still may be vulnerable to attacks. SecurityMetrics wants to change that and help you do PCI compliance right! You’re in control, and we want to help you reach your security goals and get compliant with PCI DSS.

Come to booth 722 to discuss how you can boost your portfolio’s PCI program to reduce merchant frustration. Or come talk to us about how to elevate your own organization’s security through penetration testing, PCI audits, or security training. Or, if you simply have questions about EMV, encryption, hacking, or the future of the industry, our experts are ready to answer your questions.
Talk PCI with us at TRANSACT17!

Golf Anyone?

Golf Tournament
Every year, we sponsor the TRANSACT golf tournament. Last year, attendees had a beautiful day on the Reflection Bay Course in Las Vegas.

Reflection Bay

This year, it’s on Tuesday, May 9 at 1 pm at the TPC Las Vegas Golf Course. Isn’t this place beautiful? Check out that view!

TPC Las Vegas

We can’t wait to meet you at booth 722!

SecurityMetrics 2017 Guide to PCI DSS Compliance
PCI Requirement 5: Protecting Your System with Anti-Virus

Learn what you need to know about anti-virus software. 

By: George Mateaki
Security Analyst
CISSP, QSA
Need help with PCI compliance? Read the SecurityMetrics 2017 Guide to PCI DSS Compliance

Do your systems have antivirus installed? Do you regularly update the software? Do you have a way to prevent your systems from getting infected by malware? These are some of the main issues that PCI DSS Requirement 5 covers.

Requirement 5 deals primarily with installing and maintaining an anti-virus software. Any business with systems that could be affected by malware should install anti-virus.
Here are a few things you should know about PCI Requirement 5 and anti-virus software.
SEE ALSO: Ditch Typical Anti Virus for True PCI Requirement 5 Compliance

Why install anti-virus?

PCI requirement 5PCI DSS requires anti-virus to be installed on all systems that are commonly affected by malware
(e.g., Windows). Beyond financial requirements, anti-virus software also offers an additional layer of security to any system within a network.

When system administrators understand that anti-virus adds another line of defense to their environment, they have an advantage when it comes to securing the sensitive data it contains.

Using outside sources such as the United States Computer Emergency Readiness Team (US-CERT), SANS Institute, and vendor/anti-virus threat feeds, you can identify emerging malware and attacks on systems. You can then configure systems to alert and report on suspicious activity, such as new files added to known malware directories or unauthorized access attempts.

Updating anti-virus

requirement 5
It’s not enough to simply install an anti-virus software on your systems. You need to make sure these programs are updated on a regular basis to detect known malware. Maintaining an up-to-date anti-malware program will prevent new known malware from infecting systems.

Vigilant vulnerability management is the most effective way for you to proactively reduce the window of compromise, greatly narrowing the opportunity for hackers to successfully attack your systems and steal valuable data.

System administrators have the responsibility of making sure their anti-virus software, including the signatures, are up to date. This applies to either a master anti-virus server client-based configuration or single server/workstation installations. Additionally, PCI DSS requires anti-virus scanning to occur on a regular basis.

Depending on your relationship with your POS vendor, they may or may not maintain your anti-virus scanning. If your vendor is not handling anti-virus, it’s up to you to ensure up-to-date, regular scanning.

SEE ALSO: 3 Data Security Best Practices

What if you use Linux?

Linux servers are considered systems not commonly affected by malware. However, if a Linux server is web facing, it’s highly recommended that anti-virus be installed for any web-facing Linux server.

Contrary to popular belief, malicious coders target Linux systems as well as Windows. The risk is too great not to run anti-virus on web-facing Linux systems.

Additional tips 

Here are a few other things to consider when getting compliant with Requirement 5.
  • Document everything: Make sure all procedures regarding anti-virus are documented and shared with your employees
  • Scan your systems regularly: You’ll need to find vulnerabilities before your business suffers a breach. Schedule regular vulnerability scanning for your systems
  • Maintain and evaluate audit logs with IT staff: make sure you have someone going through the logs. A warning of a breach is no good if no one can hear it. 
Need help getting compliant with PCI DSS? 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
SAQ B-IP: Protecting Your Card Data

SAQ B-IP

Learn who qualifies for SAQ B-IP and what you need to do get compliant. 

Michael Simpson, QSA, CISSP
By: Michael Simpson
Principal Security Analyst
QSA, CISSP
SAQ B-IP addresses merchants that don’t store card data in electronic format but use IP-connected point-of-interaction (POI) devices. These merchants may handle either card-present or card-not-present transactions, and do not store card data on any computer system.

Here’s what you should know for SAQ B-IP.

Who’s required to fill out SAQ B-IP?

Here’s what qualifies you for SAQ B-IP:
    SAQ B-IP
  • Your business uses only standalone, PTS-approved POI devices connected via IP to your payment processor to take your customers’ payment card information 
  • The standalone IP-connected POI devices are validated to the PTS POI program as listed on the PCI SSC website (excludes SCRs) 
  • The standalone IP-connected POI devices are not connected to any other systems within your environment 
  • The only transmission of cardholder data is from the PTS-approved POI devices to the payment processor 
  • The POI device doesn’t rely on any other device (e.g., computer, mobile phone, tablet, etc.) to connect to the payment processor 
  • The business has only paper reports or paper copies of receipts with cardholder data, and these documents are not received electronically
  • Your company does not store cardholder data electronically

What’s the difference between SAQ B and SAQ B-IP?

Both SAQs refer to merchants that deal with card data that isn’t in electronic format. The biggest difference between the two SAQs is how data is transmitted from the terminal to the processor.

SAQ B refers to merchants that process card data through dial-out POI terminals (connected through a phone line). SAQ B-IP refers to merchants that process card data through POI devices that are connected to an IP network.

SEE ALSO: SAQ B: What Your Business Needs to Do

What requirements does SAQ B-IP address?

This SAQ does address elements in several of the PCI requirements, which includes:
    self assessment questionnaire
  • Requirement 1: Install and maintain a firewall configuration to protect data
  • Requirement 2: don’t use vendor-supplied defaults for system passwords 
  • Requirement 3: protect stored cardholder data
  • Requirement 4: Encrypt transmission of cardholder data across open, public networks
  • Requirement 6: Develop and maintain secure systems and applications
  • Requirement 7: Restrict access to cardholder data by business need to know
  • Requirement 8: identify and authenticate access to system components
  • Requirement 9: Restrict physical access to cardholder data
  • Requirement 11: regularly test security systems and processes
  • Requirement 12: Maintain a policy that addresses information security for all personnel 
Remember that while this SAQ doesn’t require you to attest to all the requirements in PCI DSS, you are still responsible to be compliant with all applicable requirements.

What questions to ask? 

Here is a list of sample questions you’ll need to address for SAQ B-IP.
  • Is direct public access prohibited between the Internet and any system component in the cardholder data environment?
  • Is strong cryptography implemented according to industry best practice and/or vendor recommendations? 
  • Is sensitive authentication data deleted or rendered unrecoverable upon completion of the authorization process?
  • Are policies in place that state that unprotected PANs are not to be sent via end-user messaging? 
  • Are critical security patches installed within one month of release?
  • Are vendor remote access accounts monitored when in use? 
  • Is media sent by secured courier or other delivery method than can be accurately tracked?
  • Are quarterly external vulnerability scans performed?
  • Is a list of service providers maintained?
SEE ALSO: 5 Simple Ways to Get PCI Compliant

Additional Tips

There are a few things to consider when getting compliant with SAQ B-IP. Here are some additional tips:
  • Train employees on security policies: Your policies won’t do much unless your employees are implementing them. Hold quarterly if not monthly trainings.
  • Segment networks: Make sure your networks that handle card data have no connectivity with the rest of your business environment.
  • Use restricted access: Allow access to card data to only the employees that need it. 
Need help getting PCI compliant? Request a quote.

Michael Simpson (QSA, CISSP, CCNP) is a Principal Security Analyst at SecurityMetrics and has been in the IT Security industry for 15 years. He has a Bachelor of Science in Computer Science and a Masters in Business Administration.


SecurityMetircs 2017 Guide to PCI DSS Compliance
PCI Scope Categories: Keeping Your Card Data Separate

Learn what scope categories your systems fall into. 

By: Michael Simpson
Principal Security Analyst
QSA, CISSP
When it comes to PCI DSS scope, many businesses can feel a little confused about what to consider in-scope in their environment.

The PCI SSC recently released a supplemental guide to PCI DSS scope, which provides further information on scoping, what’s considered to be in scope, and what businesses should secure.

Within this guidance, the different categories of scoping are defined and clarified. Here’s a look at each category.

SEE ALSO: PCI DSS Supplemental Guide to Scope: Understanding PCI DSS Scope and Segmentation

In-scope systems

PCI scopeThis category relates to all systems and networks that are directly involved in the card data environment (CDE). To be in this category, the system component stores, processes, or transmits cardholder data. Or the system is on the same network segment as systems that deal with cardholder data.

These types of systems are all part of the CDE, and need to follow all applicable PCI DSS requirements to properly protect cardholder data.

Sample systems considered in-scope:
  • POS devices
  • Servers containing card data
  • Networks that transmit card data
  • Firewalls providing segmentation of the cardholder data environment
SEE ALSO: Finding and Reducing PCI Scope: How to Make Compliance Easier

Connected-to-scope systems

This category refers to all systems that are connected to the CDE, either directly or indirectly. Due to this connectivity, these systems can affect the security of the cardholder environment, and all applicable PCI DSS controls must be implemented to reduce the risk of a security breach through one of these connected systems.

 This category applies to systems that:
  • impact the configuration of the CDE
  • provides security services to the CDE
  • have a communication path to the CDE
Since these systems did not store, process, or transmit cardholder data, many businesses felt they were out-of-scope and PCI DSS requirements did not apply.

In the latest supplemental guidance, The PCI Council has very clearly stated that these systems must be secured to the same standard as in-scope systems.

All applicable PCI DSS requirements must be in place for any system connected to the CDE.
All applicable PCI DSS requirements must be in place for any system connected to the CDE.

Sample Systems considered connected to the scope
  • Code deployment servers
  • Antivirus systems
  • Domain Controllers
  • Hypervisors that host CDE systems
  • DNS servers
  • Log servers
  • Update/patch management servers
  • Authentication servers

Out-of-scope systems

PCI scoping categoriesThis category includes systems that aren’t in the CDE, or aren’t connected to the CDE. To be in this category, here’s what qualifies the system:
  • The system component doesn’t handle card data,
  • It isn’t on the same network as those that handle card data
  • It isn’t connected to any system in the CDE
  • It doesn’t meet any criteria to be in the connected to category
Only if the system component meets all these requirements will it be considered out of scope. The problem many businesses have is determining whether something is out of scope.

When scoping an environment, you should begin by considering all systems as in-scope until you can verify that enough segmentation controls are in place to remove the system from scope.

Segmentation validation tests (PCI DSS Requirement 11.3.4) can help determine if a device or network segment can be considered out of scope. This test will determine if the device or network segment has any connectivity to the CDE.

You should also determine what connectivity the device has to any connected-to system and if the device could use a connected-to system to gain access to the CDE. If a system has no better attack vector to the CDE than a system on the public internet, it can safely be determined as out of scope.

Note: Out-of-scope systems could still pose a risk to the organization and possibly the CDE if they’re not secured. It’s recommended that security best practices be implemented for all out-of-scope systems/networks.

Sample systems considered out of scope.
  • The public Internet
  • Systems with no connectivity to the CDE or to connected-to systems
  • Systems that connect to systems in the connected-to category, but cannot gain access to the CDE using this connection.

Additional tips

Here are some additional ways to scope your business.
  • Make a card flow diagram: This helps you keep track off and identify where your card data flows in and out of your environment, and what systems are affected by the flow of data
  • Create and maintain policies: Have policies in place for handling card data, securely transmitting data, and keeping the CDE separate from the rest of your business. Defined policies and procedures will give employees direction on how to maintain a compliant environment throughout the year
  • Re-scope your environment annually: Perform and document a scoping exercise annually. Changes to the environment or the threat landscape during the year may affect the scope of the environment. This process should be conducted at least annually to ensure all systems that can affect the security of cardholder data are addressed appropriately
  • Remember the people: While this post focuses on what systems should be included in your PCI scope, remember that the CDE consists of systems, processes, and people. Determine who is involved in receiving and processing cardholder data, and who is involved in securing the technology in the CDE
The PCI Council’s release of the Information Supplement on scoping and network segmentation did not change existing PCI DSS requirements, but it has provided clarification on what systems these requirements must be applied to.

Determining what systems directly or indirectly affect the security of cardholder data in the environment will help you know where PCI DSS controls must be in place.

Most data compromises could have been avoided by applying basic security controls on appropriate systems. The security controls outlined in the PCI DSS can help reduce the risk of compromise only if they are applied to all systems that can affect the security of the data.

A proper scoping exercise is key to protecting your customer’s data.

Need help with PCI Compliance? Talk to us!

Michael Simpson (QSA, CISSP, CCNP) is a Principal Security Analyst at SecurityMetrics and has been in the IT Security industry for 15 years. He has a Bachelor of Science in Computer Science and a Masters in Business Administration.

SecurityMetrics Guide to PCI DSS Compliance