Finding and Reducing PCI Scope: How to Make Compliance Easier

PCI DSS scope

Learn how to reduce PCI scope in your business and protect your cardholder data.

PCI DSS scope
Many businesses find it difficult to get PCI DSS compliant. There are so many requirements, and depending on the size of the business, filling out Self-assessment Questionnaires (SAQs) can take a lot of time and effort.

So what can you do to help your business get compliant? A good place to start is finding and reducing your business’s PCI scope.

What is PCI scope?

Your PCI scope involves anything in your business that processes, stores, or transmits cardholder data, and anything that can initiate a connection to any of the systems that handle cardholder data. 

Put simply, any device, process, or employee that involves credit card data is in your PCI scope, which means you are responsible to make sure that card data is properly secure.

Some common devices included in PCI scope can be
  • POS systems
  • Servers
  • Computers
  • QA systems
  • Databases
  • Software
  • Phones
You’d be surprised how much credit card data your business is unknowingly storing and in some of the most random places.

SEE ALSO: How Much Credit Card Data do You Store? (It’s More Than You Think.)

PCI scoping Why reduce scope?

Getting compliant with the PCI DSS can be an involved and difficult process; this is especially true for businesses that process and store a lot of card data. By reducing how much your systems come into contact with card data, your PCI validation type may change, which could reduce the overall amount of SAQ questions you’re required to answer and your total amount of work, saving time and money.

Besides saving money, reducing your scope helps ensure you’re keeping track of the card data your business processes and stores. This awareness gets you on the path to boost data protection measures.

SEE ALSO: Infographic: Reduce PCI Scope, Reduce Workload

Finding the scope in your business

The first step to reducing scope is finding out all the places and ways your business could come into contact with cardholder data.
The key to determining your PCI scope is understanding how your business works.
Some questions to ask yourself are:
  • How do you record cardholder data?
  • Where do you store the data?
  • How do you manage your systems?
  • How do you log into them?
  • How do you backup your systems?
  • How do you connect to get reports?
  • How do you reset passwords?
There are often processes you don’t think of that could be included in your scope. For example, employees could be taking card numbers over the phone or receive emails with card information. There’s also power-outage procedures where card data may be manually taken down. Follow the paper trails in your business to make sure all card data is secured. Even if card data is 10 years old, it’s still in PCI scope.

Think about all elements on your system. Even if you believe something is out of scope, it may hold temporary files, log files, or back-ups with unencrypted data. Check your devices to make sure no hidden card data is lurking.

After you find your devices in scope, find everything that can communicate with them. If you have a server that handles cardholder data, think about what else connects with that server. Who has permission to access your card data and how do you transmit it?

Also think about how your employees interact with card data. Are they storing card data at their desks? Are they taking down credit card data over the phone? These types of issues need to be taken into account as well.

Tips to reducing your scope

Once you’ve determined the scope in your business, it’s time to manage and reduce your scope.  Here are some tips to reduce PCI scope.

Segment networks
It takes more effort and time to secure all of your networks than to only secure the ones containing cardholder data. Keep the networks that handle card data separate from the ones that don’t. You can do this by installing firewalls between networks.

SEE ALSO: How Does Network Segmentation Affect PCI Scope?

Use limited access
Your janitor shouldn’t have the same access privileges as your accountant. Not all of your employees need access to cardholder data. By limiting access and having a hierarchy of employees who can handle card data, you reduce the amount of people interacting with the data. This boosts your security and makes PCI compliance a bit easier.

Outsource to third party
This may not work for every business, but if possible, it may be easier to outsource handling payments and card data to a third party. Examples include using tokens, or using business models like PayPal to ensure your company has minimal contact with cardholder data.

Keep in mind that if you do outsource your payment, you will still need to make sure the party you outsourced to is PCI compliant. You could still be held liable in the event of a data breach, should it be shown you didn’t make sure that party was compliant.

Protect your data

When it comes to PCI scope, protecting your card data should take top priority. You can’t do that unless you understand the way your business handles card data. It’s up to you to protect your cardholder data.

Need help with PCI compliance? Talk to our experts!

SecurityMetrics guide to PCI DSS compliance

The Problem with SHA-1: Updating Your Security Certificate

Learn why SHA-1 just isn’t cutting it for security anymore.  

Chase Palmer, CISSP, SecurityMetrics
By: Chase Palmer
Come January 1, 2017, SHA-1 will no longer be accepted by web browsers. So what does this mean for your business? I want to talk about SHA, why SHA-1 is becoming obsolete, and whether you need to do anything about it.

What is SHA? 

Contrary to popular belief, SHA is not an encryption. SHA stands for Secure Hashing Algorithm, which takes a bunch of data, runs it through some algorithms, and reduces it down to a small summary, or a digest. A digest is a 40-character hexadecimal string that looks like a bunch of gibberish that represents the original data. The same data put through the process should result in the same hash every time. If any part of the data has changed, the resulting hash will be different, which would notify any recipient that the data may have been tampered with.

Sha-1, SecurityMetrics
SHA is used for digital signatures and security certificates. SHA is also used in code verification and email signatures. It has a lot of applications, but the primary application is used in SSL certificates. An SSL certificate is given a signature that’s provided by an authority. You can verify that a certificate is correct through SHA-1 hashing. It’s a way the communications systems can trust they’re talking to the right server/computer.

There are three different types of SHA: SHA-1, SHA-2 and SHA-3. SHA-1 is where some of the problems are happening in data security.

What’s the problem with SHA-1?

The way SHA-1 is supposed to work is no two pieces that run through the process should ever equal the same hash.  SHA-1’s hash is a 160-bit long—a string of 160 ones and zeros.  This means that there are  2160, or 1.4 quindecillion (a number followed by 48 zeros) different combinations. Normally this would be enough to deter any brute force attacks.

However, because the number of possible hashes is finite, but the possible combinations of data input are infinite, we sometimes run into what is called a collision.

A collision is where two pieces of data will end up with the same hash. How is this possible? In statistics, there’s a phenomenon called “the birthday paradox,” which is: if you get at least 23 people in a room the probability of finding two people that share the same birthday is at least 50%.  Applied to SHA-1, this means the strength of SHA-1 is more equated to a string that is 280, which means only about half of the effort is required to find a collision.
The vulnerabilities in SHA-1 open the way to several types of attacks, particularly phishing and man-in-the-middle attacks.
This vulnerability allows hackers to act as a Certificate Authority (organizations that issue SSL certificates) and sign certificates using a key that appears to be from a true Certificate Authority.  From there, hackers can exploit other vulnerabilities to direct web traffic to a malicious website and present a seemingly valid certificate for the original website.  The browser will check the signature of the rogue certificate against the list of trusted signatures/hashes that are built into browsers, see the certificate has been signed by a trusted Certificate Authority, and connect to the website.

From there, a hacker can intercept any information entered into the website by the user. Meanwhile, the user believes they’re on the correct and secure website because they see the HTTPS address and/or the padlock icon somewhere on their browser.

Cryptologists have worked to improve the SHA process and make it much more difficult to find two pieces of info that create the same hash. SHA-2 and SHA-3 are results of that effort,

What’s being done? 

As a user, there is not much that needs to be done. Most browsers are already updated to handle SHA-2 and SHA-3. However, anyone hosting a website protected by an SSL certificate will need to pay attention.  All of the major browser vendors have stated that due to the vulnerability in SHA-1, between now and January 1, 2017, they will start displaying warnings to users that the SSL certificates in use may not be secure.  After January 1, 2017, all certificates signed with SHA-1 will be rejected and a connection will not be made.

Because of the significant impact of this weakness, there has been talk of even pushing the January 2017 date to as early as June 2016.

While the SHA-1 to SHA-2 migration isn’t being pushed directly by the Payment Card Industry, it may have an impact on merchants attempting to reach and maintain compliance. SSL Certificates signed by SHA-2 or SHA-3 are only supported by TLS 1.2 and 1.3.  According to the PCI DSS, all versions of SSL and TLS 1.1 or newer are no longer considered sufficiently secure for protecting data.

Merchants with existing implementations in place prior to April 2015 were given until July 2018 to make the migration to TLS 1.2, but the SHA-1 to SHA-2 migration may push you to update to TLS 1.2 much sooner than that.

What are people worried about? 

People are afraid the change from SHA-1 to SHA-2 will more or less break the Internet. They fear the mass migration will overload the Internet and cause damage. But it won’t, because SHA-1 and SHA-2 has nothing to do with web coding.

Everything with SHA is happening behind the browser. So it’s up to the browser to negotiate that “handshake.” The key is the browser needs to be current to use SHA-2 or SHA-3.

The good news is the latest version of nearly every browser will be able to support SHA-2 and SHA-3. Unless you’re using a very old browser, there shouldn’t be problems.

On the server side there may be more problems. If the SSL certificates used for the server/website aren’t updated to SHA-2 by January 2017, the browser will not trust the certificate and users will receive warnings of untrusted/unsecure connections.

sha-1 vs sha-2, SecurityMetrics What is SecurityMetrics doing? 

While we don’t issue security certificates, we can help companies with problems with SHA-1. We vulnerability scans, and we scan the certificates to see if they are secure.
pick up the vulnerabilities in our

If the certificate isn’t secure, it will show up as a weak encryption. This can help you see where your business may be using SHA-1 and help you strengthen your security.

What should you do? 

Contact your certificate authority on getting a new certificate with a SHA-2 signature. This is particularly important for companies that are using their own server. This impacts anyone who accesses your website.

Here are some additional things to you should do to protect your network:
Updating your servers to SHA-2 or SHA-3 is just another step in protecting your network.  It’s up to you to make sure your servers are secure.

Need help with data security? Talk to our consultants! 

Chase Palmer is the Senior Program Manager and has been working at SecurityMetrics for seven years. He manages the company’s largest corporate partners in running mass Level 4 PCI DSS programs worldwide. Chase has a Bachelor’s degree in Business Management from Western Governor’s University. He currently lives in Provo, Utah, and he loves everything about motorcycles.

SecurityMetrics Guide to PCI Compliance
Healthcare Compliance Case Studies for HIPAA Solutions

SecurityMetrics HIPAA solution testimonials from real healthcare entities like you.

Many covered entities, healthcare practices, and hospitals have experienced difficulty understanding what to do to reach compliance with the HIPAA standard.
Based on SecurityMetrics data, the average medical organization is only 57% compliant with the most basic and important healthcare compliance and security considerations.
healthcare compliance, SecurityMetricsSecurityMetrics recognized the dilemma of healthcare professionals in 2012. Because the company has successfully helped businesses with mandatory compliance regulations for over 12 years, SecurityMetrics leaders knew they could provide a streamlined, effective, and affordable solution to HIPAA compliance.

The following are case study examples for SecurityMetrics’ HIPAA solution that outline the various ways SecurityMetrics was able to help organizations reach healthcare compliance with the HIPAA law.

Case Study: Szikman Dental Group

View the PDF version of this case study

View the video version of this case study 

Having earned a reputation for “catering to cowards,” The Szikman Dental Group, P.C. has been the choice for nervous patients and dental-phobics for years. In addition to ensuring patient comfort, they strive to protect personal data and establish trust in the doctors and staff. The importance of the Health Insurance Portability and Accountability Act (HIPAA) is paramount to their staff; however, navigating the complexities of the rules has long been unclear and quite an obstacle. The Szikman Dental Group, P.C. determined to comply with HIPAA and protect patient data. Office Manager Anne-Marie Whisnant and her colleagues partnered with a compliance and security expert to reach their goals.

“SecurityMetrics helped
us so much with the intricacies of HIPAA compliance that I feel 100 percent confident that all of our i’s are dotted and t’s are crossed!” 
-Anne-Marie Whisnant,
Office Manager,
The Szikman Dental Group, P.C. 

Challenges you faced with HIPAA compliance 
  • I went to a seminar held by the ADA on what we could expect.
It was very convoluted and unclear. It almost sounded as if it was going to be a monumental and gargantuan task to get our office to be compliant, and recordkeeping was going to be time- prohibitive. We really weren’t sure what we were truly supposed to do or not do. 
  • Our recordkeeping wasn’t really up to par, and though I tried to keep our HIPAA binder up to date, it was easy to let deadlines slip by and forget to ensure that everything is current. 
  • Data security was confusing. I knew nothing of encryption when it came to emails, X-rays, hard drives or our server. Even our IT people weren’t much help in this area. 
Resolving challenges with SecurityMetrics 
  • SecurityMetrics walked us through every step of HIPAA compliance. They did an initial assessment which identified areas that we needed to improve, and gave us a checklist and instructions on every step so that we knew exactly what we needed to do and not do. 
  • Along with the assessment, they gave us information to put in our HIPAA book to show that we were in compliance with all areas and even provided us with a compliance certificate. They also reach out to us each year to ensure that we remain in compliance. 
  • The SecurityMetrics team helped us understand the need for data security and gave us information that we were able to use along with our IT team to ensure our compliance with data encryption. 

Goals achieved working with SecurityMetrics
  • Understand and feel comfortable with the HIPAA mandate 

  • Completed HIPAA risk analysis and risk management plan 

  • Increased patient data security 

Case Study: Beyond Limits Physical Therapy

View the PDF version of this case study.

hipaa solutions, SecurityMetricsBeyond Limits Physical Therapy feels when you entrust your physical therapy care to their doctors you can feel confident that the road to healing, recovery and good health is within reach. Protecting its patients’ data and increasing patient trust is also a major focus for the organization. The doctors knew about the Health Insurance Portability and Accountability Act (HIPAA), but struggled to fully understand the complex requirement. Beyond Limits Physical Therapy was determined to comply with HIPAA and protect patient data, so Doctor Matthew Sudweeks and his colleagues found a security and compliance partner to achieve their goals.

“SecurityMetrics has been good to work with. The law can be overwhelming but my support advisor
did a great job of taking me through things step by step. There is still a lot I need to do on my own but at least I know what to do and how to do it.” 
-Matthew Sudweeks, Doctor of Physical Therapy (Dpt) 

Challenges you faced with HIPAA compliance 
  • I did not even know where to start. The law was so overwhelming. I tried a risk assessment sample from an insurance company and didn’t know half the things that they were asking. 
  • Since everything went to our EMR, it was hard to think about how someone would gather my info. 
  • Overwhelmed with the time it would take to put our compliance in order. 

Resolving challenges with SecurityMetrics 
  • SecurityMetrics helped me get to a starting point and showed me what I needed to do and how to do it.
  • They broke down the HIPAA law and simplified it for me by taking me through 25 steps versus taking on a 1,000 page law.
  • Anytime I had or have questions I can always call my support advisor and he helps me out or is willing to find the answers to the questions I have. 

Goals achieved working with SecurityMetrics
  • Completed a thorough risk analysis
  • Making demonstrable progress on risk management plan
  • Increased security and peace of mind

HIPAA learning center, SecurityMetrics
Social Engineering Training: What Your Employees Should Know

Learn how to train your employees to combat social engineering attacks. 

Read the white paper 5 Tips to Train Workforce on Social Engineering.

In data security, a lot of time is devoted to the technical side of security, such as firewallsvulnerability scanning, and penetration testing. But did you know an attacker could bypass years of IT security work during a social engineer attack?

Social engineering is one of the easiest ways to steal data, especially if employees haven’t been trained on how to recognize and combat it. Social engineers make themselves look like they belong to a company, and can walk into an organization, steal data, and walk out in a very short amount of time.

SEE ALSO: 9 Ways to Social Engineer a Hospital

Since social engineering targets the workforce, the best way to combat it is to train your employees. Here are a few tips to properly train your workforce against social engineers:

Rethink training 

Training your employees when they are first hired, or having training sessions once a year isn’t cutting it anymore. The sessions are usually too long, the employees get bored, and most of the crucial security information doesn’t stick as a result.

Instead, do regular training quarterly, if not monthly. Focus on elements of social engineering and what employees can do to be aware of it.  Repetition will help your employees to remember and apply their training in everyday situations.

Need to train your employees? Let us help! 

Create policies

The main problem organizations have with social engineering is their employees don’t know what to do if they find themselves in an uncertain situation. Create policies help your employees know the proper protocol for security. Established policies on handling data properly will help your workforce spot suspicious activity.  Some specific policies may include:
  • ID anyone trying to access off-limits areas
  • Never use a USB unless directly obtained from the IT department
  • Report lost/stolen badges within 12 hours of discovery
  • Alert manager if you’ve encountered a social engineering situation. 

Make it part of the company culture

Implement a continuous training approach. For many employees, everyday work can cause them to forget crucial security information during trainings. Make social engineering training a part of the employee newsletter, send out regular emails, and put tips on bulletin boards.

If your employees are constantly being reminded to watch out for social engineering and mindful of what information they’re allowed to provide, they will know what to do when an attack occurs.

Test your staff 

It’s often said that people learn best by doing. Testing your employees gives them on opportunity practice combatting social engineering while helping you see what needs to be improved within your company’s security.

Create a social engineer team and have them test your own employees with some common social engineering tactics. Some things they could do are:
  • Pose as a janitor and try to get to a secure room without a badge
  • Dumpster dive for sensitive documents
  • Leave USB devices around your site and track where they end up
  • Try unlocked doors around the backside of buildings
  • Pose as an IT person that needs to fix the network and see how close they can get to the server room. 

Train employees to be skeptical 

A skeptical employee is a good employee. Your employees should feel safe to question something if it seems off to them. Create an environment where employees aren’t afraid to report suspicious behavior. Your employees must feel comfortable questioning strangers.
Social engineering should be taken more seriously than it often is.
If you don’t already have regular social engineering training in place, begin as soon as possible. Test all of your employees, including upper management.

If you don’t handle it now, you could be paying for it later.

For more information on social engineering and training against it, read the white paper 5 Tips to Train Workforce on Social Engineering.

PCI DSS 3.2 Changes: What Your Business Needs to Know

Learn what new requirements 3.2 is implementing into the standard. 

As you may know, PCI DSS version 3.2 has been released and version 3.1 will expire on October 31, 2016. All new requirements are best practices until February 1, 2018.

So what do these changes mean for businesses?
Here is a list of the changes PCI DSS 3.2 has made to the standard.

Updated migration dates

In December 2015, the migration dates for businesses to move from SSL and early TLS to the latest TLS were moved back from June 2016 to June 2018. The PCI Council wanted to reflect that date change in the latest version of PCI DSS.

Many businesses plan to stick with the old date to avoid dealing with the extra exposure. Having SSL encryption is very risky to security since it has many exploitable vulnerabilities. So even though the deadline has been extended, it’s a good idea to make those changes as soon as possible.

Multi-factor authentication required in and out the CDE (8.3)

Multi-factor authentication is an effective way to secure your CDE and is required by the PCI DSS. To properly configure it, you need to have at least two of three things:
  • Something you know (username, password, etc.)
  • Something you have (getting a code from your phone)
  • Something you are (fingerprints and other biometrics)
SEE ALSO: Two Factor Authentication – Security Beyond Passwords

Before 3.2, multi-factor authentication was only required for remote access to the network. Now, even if your connection is within the CDE, multi-factor authentication is required.

Incorporating designated entities supplemental validation into PCI DSS (Appendix)

PCI DSS 3.2 incorporates some extra validation procedures in the Appendix. In addition to full PCI DSS validation, designated entities determined by Acquirers or Payment Brands should have some additional validation that shows whether a business’s day-to-day practices are reflective of their compliance.

The additional validation procedures are for designated entities to make sure they’re PCI compliant on a day-to-day basis, instead of just an annual basis.

For example, you could look at a list of all the change controls in a merchant’s environment for the past year. These procedures could include anything that shows the day-to-day compliance.

Clarifying masking criteria (3.3)

PCI DSS 3.2 clarifies masking criteria for primary account numbers (PAN) when displayed. Masking hides information from view; this is not the same as encryption. When displaying a credit card number or bank identification number (BIN), you can display, at the most, the first 6 and last 4 numbers. If you go beyond these requirements, you’re not compliant.

Whether or not you should display less PAN numbers could depend on various legal requirements. Another related note worthy item, if your business stores PAN, you’re also required to encrypt and properly secure it.

Change management process (6.4.6)

PCI DSS 3.2 explains you need to have a change management process to make sure all new or changed systems are PCI compliant on completion of a significant change. You should document these updates too.

Here are some examples of requirements that could be impacted:
  • Network diagram is updated to reflect changes
  • New systems are included in the quarterly vulnerability scanning process
  • Systems are protected with required controls
  • Systems are configured with proper configuration standards

Service Provider Written Agreement (12.8.2)

PCI DSS 3.2 explains that the responsibility that a service provider has for the security of cardholder data depends on the service and the agreement between the provider and the entity. You need to maintain a list of all PCI requirements your service provider meets and a list of requirements they need to meet.

New penetration testing requirements (

In PCI 3.1, service providers were required to have penetration tests done annually. Now, service providers that use segmentation are required to perform penetration tests on segmentation controls every six months.

SEE ALSO: How Much Does a Pentest Cost?

Cryptographic architecture requirements (3.5.1)

Service providers should interview personnel and maintain a documented description of cryptographic architectures, which may include:
  • Details of algorithms, protocols, and keys used to protect cardholder data
  • Description of key usage for each encryption key
  • Inventory of HSMs and other SCS used for key management
This helps companies ensure their algorithms and encryptions aren’t getting breached and/or stolen. By documenting these keys, it helps streamline the process of encryption and prevents or detects potential thefts.

Establish a PCI DSS program (12.4.1)

Executive management of service providers must now establish a PCI DSS compliance program to
protect cardholder data.  The program should include:
  • Overall accountability for maintaining PCI DSS compliance
  • Defining a charter for a PCI DSS compliance program and communication to executive management
SEE ALSO: How Much Does PCI Compliance Cost?

Quarterly personnel reviews (12.11, 12.11.1)

Service providers must perform quarterly reviews to confirm that personnel are following security policies. Reviews should cover the following processes:
  • Daily log reviews
  • Firewall rule-set reviews
  • Applying configuration standards to new systems
  • Responding to security alerts
  • Change management processes
You also need to document quarterly review process, such as documenting the results of the review and signing off results by personnel responsible for PCI DSS.

Timely detection and reporting (10.8, 10.8.1)

Service providers must have a formal process to detect and alert to critical security failures. The longer the system is vulnerable, the more time the attackers have to find a way to compromise systems and steal data. Examples of critical security control systems include:

Getting compliant

With these new requirements, it may feel like getting PCI compliant is more difficult than ever. Here are some tips that can make getting compliant easier.
  • Scope out your network: your scope is everything in your business environment that handles cardholder data. By reducing your scope, you can reduce the amount of elements that need to be PCI compliant.
  • Hire a PCI consultant: PCI QSAs and experts know a lot about helping businesses get compliant as soon as possible.
  • Establish data security best practices: by doing basic things like implementing physical security and having firewalls, you can streamline the PCI compliance process.
  • Create a PCI compliance team: PCI compliance shouldn’t be a one-man job. Set aside a team that handles the PCI DSS.
  • Do regular PCI employee training: your employees need to live and breathe PCI. Train them quarterly if not monthly on PCI requirements and data security.
Remember, the PCI DSS is not your enemy: it’s a standard that helps you protect your company from data breaches. PCI DSS 3.2 helps you add additional security to your business to protect your data from hackers.

Read more about 3.2 from our 2016 SecurityMetrics Guide to PCI DSS Compliance!

2016 SecurityMetrics Guide to PCI DSS Compliance