WPA2 Security Flaw “KRACK” Puts Wi-Fi Devices at Risk

What you need to know about the "KRACK Attack" vulnerability

By: David Page
Security Analyst
CISSP, QSA
If you haven’t already heard, security researcher Mathy Vanhoef recently discovered a serious vulnerability, dubbed “KRACK,” within the current industry standard encryption protocol "Wi-Fi Protected Access II" (WPA2). WPA2 encrypts traffic on all modern Wi-Fi networks, so any device connected to Wi-Fi could be affected.

On October 16, 2017, this vulnerability was made public. If exploited, it would allow hackers to decrypt and read Wi-Fi-transmitted network traffic.

How this affects you:

If you are logged onto a wireless network, and an attacker is within range, they can use KRACK to bypass WPA2 network security and then read your (unencrypted) credit card numbers, passwords, banking info, photos, chats, emails, messages, etc.

Any sensitive data passing over the network would be up for grabs.

What you should do:

  • Watch for patches and updates to be released by Wi-Fi device manufacturers and vendors in the near future. Install updates for all devices and operating systems as soon as available. All affected personal and enterprise Wi-Fi devices will need to be patched eventually. 
  • This exploit requires the attacker have access to your wireless network. Organizations will fare better if they’ve architected their critical Wi-Fi networks to limit coverage to intended areas, and followed other Wi-Fi networking best-practices. 
  • Make sure to only share sensitive data on sites with HTTPS encryption. 
  • Changing a Wi-Fi password or replacing your router won’t stop KRACK Attacks. This issue is not related to devices themselves. 
  • Android and Linux devices are most easily affected. Most versions of iOS and Windows are vulnerable but would be more difficult to exploit because of the way they originally implemented the WPA2 standard.

What does KRACK stand for?

Vanhoef coined the acronym “KRACK” to stand for “key reinstallation attack.”

How does a key reinstallation attack work?

The WPA2 protocol currently employs a “4-way handshake,” which confirms that both the client and access point have the correct credentials (a password), while at the same time creating a fresh (never used) encryption key that will be used to encrypt all subsequent traffic.

In a key reinstallation attack, a hacker would manipulate and replay the cryptographic handshake messages to trick a victim into reinstalling an already-in-use encryption key. Because the attacker forces reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged.

Vanhoef recorded a video demonstration of such an attack.
HIPAA FAQ


Your most common questions about the Healthcare Information Portability and Accountability Act, answered.

This post was updated on October 6, 2017.

hipaa, hipaa compliance, hipaa compliant
By: Jen Stone
MCSIS, CISSP, QSA
As you may expect, we get a lot of questions about HIPAA compliance. We're posting the most common inquiries along with answers, to give our readers an easy go-to source for HIPAA compliance.

What is HIPAA compliance?

HIPAA (The Health Information Portability and Accountability Act) is a federal mandate that, among other things, requires organizations to keep patient data secure. Compliance requires a myriad of privacy and security actions outlined in the mandate’s specific rules, such as password policy creation, patient data protection, and employee training.

Who is required to become HIPAA compliant?

Any covered entity (CE) or business associate (BA) that stores, processes, transmits, maintains, or touches protected health information (PHI) in any way must be compliant. Examples of covered entities include any healthcare service provider such as a hospital, pharmacy, or physician. Examples of BAs are persons or entities that provide services to a CE that involve the disclosure of PHI, such as a medical records vendor, prosthetic manufacturer, or outside medical consultant.

How do I become HIPAA compliant?

Compliance will look a little different at every organization, but most entities will complete a risk analysis, create and complete a risk management plan, conduct regular employee training, and implement updated policies and procedures.


Who is responsible for HIPAA?

Both the healthcare organization and individual staff members who accesses PHI are responsible. The organization is responsible to put all necessary safeguards in place for HIPAA compliance. Every individual (office manager, doctor, etc.) is held responsible for health information they should, can, or do access. Individuals and companies can independently face criminal charges for mishandling PHI.

SEE ALSO: HIPAA Violations. . . Who is Responsible?

What’s the difference between the HIPAA Security and Privacy rules?

The HIPAA Privacy Rule addresses appropriate PHI use and disclosure practices by healthcare organizations. The same rules, regulations and policies that regulate Privacy do not necessarily extend to the Security Rule. The HIPAA Security Rule revolves around safeguarding the systems that house or transmit PHI.

SEE ALSO: HIPAA Privacy Rule 101 Whitepaper

Who enforces HIPAA compliance?

The Department of Health and Human Services’ (HHS) Office for Civil Rights (OCR) is the federal organization responsible for enforcing HIPAA compliance.

What is the Final Omnibus Rule?

The Omnibus Rule, enacted in January 2013, is an extension of the HITECH Act that expands patient rights, assigns liability to business associates, and increases penalties for security violations. The deadline to comply with the rule was September 2013.


What happens if I don't become HIPAA compliant?

If you are found in violation of HIPAA, both the HHS and state attorney generals can levy fines against you. In fact, the HHS assesses fees of up to $50,000 per day per violation.



If noncompliance leads to a breach, you are required by law to notify the HHS, your patients, and, if more than 500 records are involved, the media. This could severely damage brand equity and publicly embarrass your organization. According to a recent survey, 76% of patients state they will stop dealing with an organization responsible for a privacy breach.



Webinar: An introduction to the HIPAA Security Rule, including its purpose and components.

What is a HIPAA violation?

Each failure to follow one or more of the HIPAA standards, requirements, or implementation specifications is considered a violation. For example, sharing passwords among nurses, not using an industry-standard firewall, and not encrypting emailed patient data are all separate violations.



What’s the difference between a required and addressable rule?

Required rules are quite cut and dried. Either you implement them, or you automatically fail to comply with the Security Rule. Addressable rules are more technical, and allow organizations of varying size the flexibility to implement different security controls that accomplish the requirement’s objective.

SEE ALSO: Required vs. Addressable HIPAA Requirements


What does it mean to have a HIPAA audit?

The HHS expects healthcare providers to actively work on their HIPAA compliance and tests them through organizational audits. An entity could be chosen for a HIPAA compliance audit at random, or because of a reported breach by an employee or customer. The best way to prepare for an audit is by having an aggressive and fully functional HIPAA compliance program already in place. You can perform a ‘mock’ audit by enlisting an experienced and knowledgeable third party to follow the HHS audit protocol.

At the end of 2016, the OCR ramped up with phase 2 of their HIPAA Audit Program. If you’re a covered entity or business associate, it’s important to watch for emails from OCR asking for your contact information. After they receive your contact info, the OCR will “transmit a pre-audit questionnaire to gather data about the size, type, and operations of potential auditees; this data will be used with other information to create potential audit subject pools.”



What should I do if I think PHI has been compromised at my organization?

Contact the HHS immediately following discovery of the breach, and they’ll tell you what to do next. You can report a breach here. See Breach Notification Rule protocols.


What is a business associate agreement? Do I need one?

A business associate agreement (BAA) is a contract required for any business associate that receives patient data from either a covered entity, or from another business associate. Covered entities and business associates are responsible for having proper business associate agreements in place. It’s their job to draft BAAs that meet their own requirements, as well as HIPAA requirements.

SEE ALSO:
HIPAA Compliance Certificate
Sample HIPAA compliance certificate

What is a HIPAA compliance certificate?

A HIPAA compliance certificate shows that you have completed all the necessary requirements your individual HIPAA consultant requires. Although this document doesn’t disqualify you for random HHS audits, it does show your willingness to make demonstrable progress towards HIPAA compliance.

What is SecurityMetrics' role in HIPAA compliance?

SecurityMetrics helps healthcare entities achieve lasting HIPAA compliance. We offer a guided HIPAA Risk Analysis (the first and most important step toward compliance), HIPAA compliance, HIPAA audits, HIPAA policy templates, HIPAA training, and other security services.

More questions about HIPAA? 

Jen Stone (MSCIS, CISSP, QSA) is a Security Analyst at SecurityMetrics with an extensive background in Information Security and 20+ years in IT.  


HIPAA, HIPAA Compliant, HIPAA Compliance


Are You Ready for PCI DSS 3.2?

By February 1, 2018, all PCI security assessments will need to use version 3.2 of the PCI DSS. 

From PCI DSS 3.1 to 3.2 

pci compliance, pci dss, pci dss 3.2The Payment Card Industry Security Standards Council (PCI SSC) announced PCI Data Security Standard (PCI DSS) version 3.2 on April 28, 2016. This latest version adds clarification, guidance as well as some new requirements to the standard.

According to Troy Leach, the PCI SSC’s CTO, the council made these changes to the PCI DSS, “to ensure it continues to protect against old exploits that are still causing problems, addresses new exploits and provides greater clarity for implementing and maintaining PCI DSS controls.”

PCI DSS 3.1 officially retired on October 31 of 2016. Since then, version 3.2 has been considered “best practice” by the PCI SCC.
Starting February 1, 2018, the changes in version 3.2 will be effective as requirements, and all assessments will need to use the new version.

PCI DSS 3.1 to 3.2 Timeline

April 28, 2016: The PCI SCC announced the change to 3.2.
May 2016: PCI DSS 3.2 published.
October 31, 2016: PCI DSS 3.1 retired. Version 3.2 considered best practices.
January 31, 2018:  Last day PCI DSS 3.1 can be used.

February 1, 2018:  Changes in PCI DSS 3.2 effective as requirements.

Important Takeaways from the PCI DSS 3.2 Changes 

Multi-Factor Authentication
  • Previously, the PCI DSS required only untrusted, remote access into cardholder data environment to require “two-factor authentication.” They changed the name to “multi-factor authentication” to clarify that at least two factors must be used—they also extended this requirement to any personnel with administrative access into the cardholder data environment. This recently recorded webinar goes in-depth on the subject of multi-factor authentication.
Changes to SAQs
Supplement on Scoping & Network Segmentation
  • The PCI SCC released this supplement in December of 2016. Its purpose is to help organizations know which of their systems should be included in their PCI scope and understand how segmentation can reduce PCI scope. One of the biggest takeaways for organizations is to make sure they also include any systems that are connected to the cardholder data environment in their PCI scope, not just systems located within the CDE. 
Segmentation Checks
    pci compliance, pci dss, pci dss 3.2
  • Starting February 1, 2018, segmentation checks (penetration tests on segmentation controls) must be performed by an organizationally independent resource (as is already required for other penetration tests). Also, service providers will be required to perform segmentation tests at least every six months and after any changes to segmentation controls/methods.
Changes for Service Providers
  • As mentioned above, PCI DSS 3.2 requires service providers to perform segmentation checks at least every six months and after any changes. There are also a few new requirements specific to service providers in the following areas: 
    • Cryptographic architecture (requirement 3.5.1)
    • Timely detection and reporting (requirement 10.8), (10.8.1)
    • Establish responsibilities for PCI and data (12.4.1)
    • Quarterly personnel Reviews (12.11, 12.11.1)
    • Penetration testing (11.3.4.1)
Migration from SSL & TLS v1.0 to TLS v1.2
  • While migration to TLS v1.2 (from SSL & TLS v1.0) is required by the PCI SSC until June 30, 2018, it’s a good idea to make sure your organization makes this change in conjunction with the PCI DSS 3.2 updates. 

Resources to Help You Comply with PCI DSS 3.2 

Since 2018 is just around the corner, we want to make sure our readers are aware of and prepared for compliance with PCI DSS 3.2. We’ve compiled some of the some of the best resources to support PCI DSS 3.2 education and compliance at your organization:

SecurityMetrics Resources

Whitepaper: How to Become Compliant with PCI DSS 3.2 
Whitepaper: PCI DSS 3.2 Segmentation Checks 
Blog: PCI DSS 3.2—Changes Your Business Needs to Know
Blog: New 3.2 Requirements for Service Providers
Blog: Guide to Understanding the PCI DSS Scoping + Segmentation Supplement

PCI SCC Resources

PDF: PCI DSS 3.2
Blog: Interview with PCI SCC CTO Troy Leach about PCI DSS 3.2
Blog: Keeping Up to Date with PCI DSS Dates
Supplement: Guidance for PCI DSS Scoping and Network Segmentation
Supplement: Penetration Testing Guidance

Compliance with PCI DSS 3.2

Because PCI compliance involves many steps, details and technicalities, it’s important to start as soon as possible with any changes you need to make in order to be compliant with PCI DSS 3.2. The changes in 3.2 are intended to make organizations safer and less likely to experience a data breach. They also help clarify previous points of confusion for merchants and service providers.

More questions about PCI DSS version 3.2? 


PCI DSS Compliance FAQ


Your most common questions about the payment card industry data security standard, answered.

Note: This post was updated September 26, 2017. 

By: George Mateaki
Security Analyst
CISSP, CISA, QSA, P-QSA
As you might expect, we get a lot of questions about PCI DSS Compliance. Here are the answers to your most frequently asked questions!

What is PCI compliance?

The Payment Card Industry Data Security Standard (PCI DSS) was established in 2006 by the major card brands (i.e., Visa, MasterCard, American Express, Discover Financial Services, JCB International).

All businesses that process, store, or transmit payment card data are required to implement the standard to prevent cardholder data theft. Your card-handling practices and processing environment determine which PCI DSS requirements apply to your business.

What is PCI validation?

The Payment Card Industry Security Standards Council mandates that all merchants comply with the PCI standard. Annual validation (or proof) is mandated by some merchant processors and is a way of documenting your compliance. Validation requirements vary based upon annual payment card transactions and may require a self-assessment or independent onsite audit.



 


Who is required to become PCI compliant?

All businesses that process, store, or transmit payment card information are required to comply with the PCI DSS.
 


Why haven't I heard of PCI compliance until now?

PCI compliance was first mandated in 2006. The Payment Card Industry Security Standards Council, the card brands, and your merchant processor are doing their best to make sure all merchants are aware of the standards.


Is PCI compliance required by law?

The government does not regulate PCI*; however, when you signed your payment card contract—and confirmed your desire to accept credit and debit cards at your business—you agreed to follow card brand rules. If you wish to safely accept Visa, MasterCard, JCB, American Express, and Discover, you must comply with PCI DSS.

*Note: Some states, including Nevada, Minnesota and Washington, have incorporated PCI DSS compliance into their state laws.

 


When is the deadline to become PCI compliant?

For most merchants, the deadline for compliance has already passed. Contact your merchant processor to receive details on your merchant account. The sooner you become compliant, the less likely you are to be hacked.

What happens if I don't become PCI compliant?

If you are not PCI compliant, you are more vulnerable to data compromise, and may also be fined by your merchant processor and/or the card brands for not validating PCI compliance.


I only process a few cards a year. Do I still need to be PCI compliant?

Yes. Even if you only process one transaction per year, you must implement the PCI DSS in your processing environment.

SEE ALSO: 10 PCI Security Standard Myths

What is required to become PCI compliant?

Typical steps for merchants to become PCI DSS compliant include, but are not limited to:
  • Determine your PCI DSS validation type (this informs your requirements)
  • Address all requirements found in your Self-Assessment Questionnaire (SAQ) (e.g., external vulnerability scans, penetration tests, employee training, etc.)
  • Attest to your compliance annually
  • Complete and report quarterly results of all scans performed by an Approved Scanning Vendor (ASV)
SEE ALSO: Is Your E-Commerce Business PCI Compliant?

What is the most current version of the PCI DSS? 

The PCI SCC recently released PCI DSS version 3.2. It replaces 3.1 “to address growing threats to customer payment information.” The new compliance requirements introduced in version 3.2 will be considered best practices until January 31, 2018. Starting on February 1, 2018, they are effective requirements.

Which SAQ am I supposed to complete?

Ultimately, you must choose the SAQ that’s right for your processing environment, but generally speaking:

  • SAQ A is for e-commerce/mail/telephone-order (card-not-present) merchants that have fully outsourced all cardholder data functions. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises.
  • SAQ A-EP is for e-commerce-only merchants that use a third-party service provider to handle their card information, and who have a website that doesn’t handle card data, but could impact the security of the payment transaction. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises.
  • SAQ B is for merchants that use imprint machines and/or standalone, dial-out terminals, and have no electronic cardholder data storage. Not for e-commerce.
  • SAQ B-IP Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor, and that have no electronic cardholder data storage. Not for e-commerce.
  • SAQ C-VT is for merchants that use a virtual terminal on one computer dedicated solely to card processing. No electronic cardholder data storage. Not for e-commerce.
  • SAQ C is for any merchant with a payment application connected to the Internet, but with no electronic cardholder data storage.
  • SAQ P2PE is for merchants using approved point-to-point encryption (P2PE) devices, with no electronic card data storage. 
  • SAQ D for Merchants is for merchants that DO store credit card data electronically. 
  • SAQ D for Service Providers is for service providers deemed eligible to complete an SAQ.

Read more about PCI DSS 3.2 SAQ updates.

What is a PCI compliance certificate?

Some QSA/ASV companies provide certificates confirming that an organization is PCI DSS compliant. An actual compliance certificate is not mandatory, and you don’t necessarily need a certificate to be PCI compliant.


Am I PCI compliant if my site has an SSL/TLS certificate? 

Unfortunately, no. An SSL/TLS certificate is an important element in a secure website, but alone does not meet PCI DSS requirements.

Do I need to be PCI compliant if I don't use a computer to process credit cards?

Yes. PCI compliance doesn't require a connection to the Internet or even a computer system. PCI compliance is determined by the way that you store, handle, or process credit card information, whether the card information is in a locked filing cabinet or on the computer.

Who enforces PCI compliance?

Generally speaking, your merchant bank enforces PCI DSS compliance. The PCI Standards Security Council was formed in 2006 by the major card brands (i.e., Visa, MasterCard, American Express, Discover Financial Services, JCB International) to regulate, maintain, evolve and promote PCI DSS compliance.

SEE ALSO: How Much Does PCI Compliance Cost?

What should I do if I think my business has been compromised?

Disconnect your system from the Internet, call your merchant processor, and call a forensic investigator. PCI forensic investigators help you find and fix the security holes in your processing environment. They help you identify how and when attackers breached your systems, determine if card data was compromised, and document for the card brands your efforts to remediate the vulnerabilities that lead to the data breach.

SEE ALSO: The 6 Phases in an Incidence Response Plan

What is SecurityMetrics' role in PCI compliance?

SecurityMetrics helps businesses get PCI compliant. We help merchants validate compliance and implement the Payment Card Industry Data Security Standard. SecurityMetrics is an Approved Scanning Vendor and is certified to perform PCI scans, onsite PCI audits, payment application software audits, point-of-sale terminal security audits, penetration tests, and forensic analysis (to assess card data compromises.)

SecurityMetrics QSAs & experts hold certifications like:

  • Certified Information Systems Security Professional (CISSP) 
  • Certified Information Systems Auditor (CISA) 
  • PCI Forensic Investigator (PFI) 
  • Approved Scanning Vendor (ASV) 
  • Qualified Security Assessor (QSA) 
  • Payment Application Qualified Security Assessor (PA-QSA) 
  • Point-to-Point Encryption Qualified Security Assessor (P2PE QSA) 
  • HealthCare Information Security and Privacy Practitioner (HCISPP)

My SecurityMetrics account has just been created, what now?

You should log in to your account and begin the process of becoming PCI compliant. Start by going through each section of the SAQ.

If you have more questions about PCI Compliance or anything related to data security, contact one of our experts.

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.


How Does Network Segmentation Affect PCI Scope?

Isolating your network can increase your security.

Gary Glover, Director of Security Assessments
By: Gary Glover
Note: This post was originally published on March 11, 2015 and has been updated.

What is Network Segmentation? 

Network segmentation is the process of sectioning off one network into smaller segments, or “subnetworks,” in such a way that limits or prevents communication between them. It’s a key security practice for any merchant that wants to protect their cardholder data and reduce their PCI scope. Reducing PCI scope in itself will save time, money, and effort.

When done properly, network segmentation provides controls that limit or stop communication from one subnetwork into another. When done improperly—or not thoroughly enough—hackers may be able to “pivot” from a less-secure area (such as an office zone) into your cardholder data environment (CDE).

In fact, the Target Data Breach of 2013 was possible thanks to a basic network segmentation error. Hackers started by using stolen credentials to log in to a 3rd-party vendor’s application, which was running in a non-CDE area of Target’s network. This area was not properly segmented. The attackers then performed a “pivot attack” and moved into Target’s CDE. From there, they installed malware and siphoned around 40 million credit card numbers from point-of-sale devices.

The PCI DSS Supplement for Scoping & Network Segmentation

To help prevent future data breaches and give additional guidance on this issue, the PCI Security Standard Council (SCC) released a supplemental guide for scoping and network segmentation in December of 2016. The supplement clarifies basic terms related to network segmentation and scoping:

  • In scope: systems directly involved with, connected to, or that impact the security of cardholder data
  • Connected-to: systems that connect to the cardholder data environment (CDE) or are indirectly involved in handling card data
  • Out of scope: systems that do not have access to the CDE

This new supplement also emphasizes the critical importance of including “connected-to” systems in your PCI scope. Overlooking such systems can have huge risks and impacts. As the supplement states, “Compromises of connected-to system components often lead to compromise of the CDE and theft of cardholder data.”

The PCI SCC points out that the CDE environment is really only a starting point when accurately determining your PCI scope. They urge organizations to critically evaluate not only the CDE, but also the flow of cardholder data in and out of the CDE, reminding them that:

  1. Systems located within the CDE are in scope. 
  2. Systems that connect to a system in the CDE are in scope. 
  3. In a flat network, all systems are in scope if any single system stores, processes, or transmits account data.

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

Network Segmentation and PCI Scope

We know that segmentation is important for preventing breaches and hacks, but as mentioned, it’s also very popular among merchants who wish to reduce their PCI scope.

A system is considered “in scope” for PCI DSS if the environment or system components are within a known card data environment, directly connected to the CDE, or can affect the security of the CDE.

Non-segmented environments, or “flat” networks, have their card-processing systems mixed in with back-office systems. In these environments, the entire network is in scope for PCI DSS compliance. This can significantly increase the amount of work needed to secure your business’s network.

And even though flat networks are inherently insecure, many businesses still use them because they are simple to understand and build. Keep in mind, this mentality can result in security risks and increased PCI scope.

SEE ALSO: PCI Scope Categories: Keeping Your Card Data Separate

How to Segment a Network

According to the PCI DSS, “To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the cardholder data environment (CDE), such that even if the out-of-scope system component was compromised it could not impact the security of the CDE.”

Depending on the complexity of your environment, segmenting your network can be quite difficult. Reach out to a QSA to assist you in this endeavor.

Get a quote for network segmentation help from our QSAs.

Here’s the process we use when helping merchants segment their environments.

1. Assign one person/group to learn all places card data flows

To reduce the scope of the CDE, you must understand how your business works, and how all card data flows in your organization. It’s a lot easier to keep track of your scope if one person becomes the expert on all places card data is used or stored.

2. Interview everyone

Your employees probably know about random processes involving data, that no one else would know about. Interview process owners, those with access to data, web developers, and your sales force to gain greater insight into your own card data environment.

For example, accounting departments often have processes for balancing the books or doing charge reversals that may gather credit card data in files on employee workstations, files stored on shared network file servers, or as printed media in big rubber-banded piles thrown in a storage cupboard. Customer service representatives may take credit card numbers over the phone or view full card numbers, so watch for handwritten or printed card data.

3. Make a data flow diagram

The best way to understand how data flows through your organization is by creating a data flow diagram to help you visually illustrate the location and flows of card data.

Learn how to create data flow diagrams.

4. Use card data discovery tools

Just like debris in a river gets caught in eddies, card data can potentially be deposited on systems that may or may not be directly involved in point-of-sale transactions. This information is virtually impossible to find manually. Tools like the SecurityMetrics PANscan can be used to search computer systems for unencrypted payment data.

SEE ALSO: Is Your Credit Card Data Leaking?

5. Decide how you want to segment

Now that you know where your card data is and how it flows in your environment, you’re ready to look at your network diagram and determine which devices and rules to use to keep information apart.

The most common way to segment is by implementing a piece of dedicated hardware that sits between network zones to limit network traffic, also known as a firewall. The most important part of firewall implementation is configuring the Access Control List (ACL) to define exactly what traffic can pass.

SEE ALSO: PCI Compliant Firewalls: 5 Things You’re Doing Wrong

Although we typically recommend the use of a firewall to segment internal network zones, here are a few other options.

  • Switches: The second most common way to segment is through network switch hardware. Switches are often used internally behind a firewall to help segment network zones. Some switches are capable of having their own set of access control lists that are independent, in addition to firewall rules between zones. Switch ACLs can be used in segmentation but are often a bit more difficult to manage than a dedicated firewall appliance. Only experienced network engineers should set up switch-only internal network segmentation.
  • Air Gap: This type of segmentation starts with two network connections provided by two totally separate Internet providers. If one network is only connected to your processing network, and the other is only connected to back office and other functions, and these segments are not connected, your card environment should be adequately separated.
  • Analog phone lines: If you’re willing to take all your credit card processing offline, the easiest and most foolproof way to segment a network is processing over analog phone lines. No Internet = no network breaches.

6. Consider P2PE…the ultimate segmentation technology

These are the most common ways to achieve segmentation, however; there’s an easier way. Point-to-point encryption (P2PE) technology. P2PE essentially eliminates the need for segmentation (as long as you’re using a validated P2PE solution).

If you use P2PE (and only P2PE) to process credit cards, your entire merchant network is out of scope. No vulnerability scan, firewalls, or logging required for PCI DSS compliance. The only thing in scope for PCI DSS is your swipe device.

Read more about P2PE.


7. Your PCI assessor must verify your segmentation is adequate to reduce your scope

Many businesses think they’ve been properly segmented, when they actually haven’t. Because there are so many variables (how your network is configured, what technologies you deploy, the controls you have to secure data, ports open between zones, etc.) it’s important to get verified by a QSA during your PCI audit.

Analysis: no pain, no gain

Network segmentation requires investment in terms of time, effort, and funds. However, it’s the best way to reduce your PCI scope, and one of the best ways to keep your business secure.

We'd love to help you with your organization’s segmentation. Speak to a specialist.


Gary Glover (CISSP, CISA, QSA, PA-QSA) is Director of Security Assessment at SecurityMetrics with over 10 years of PCI audit experience and 25 years of Star Wars quoting skills. May the Force be with you as you visit his other blog posts.