An in-depth look at the PCI Security Standard Council’s recent MFA guidance supplement and what it means for your organization.  

George Mateaki Security Analyst QSA, CISSP

Moving toward true security 

In the wake of recent massive data breaches, foundational data security principles—like network segmentation, strong passwords, and multi-factor authentication (MFA)—are getting more attention from organizations, consumers and security experts.

The Deloitte data breach of September 2017 was recently tied to a lack of multi-factor authentication on an admin account. Aetna and Airbnb have announced they are shifting away from single-password authentication and towards strong, multi-factor authentication access for users of their apps.

MFA is also an important principle for any business’s internal operations, especially when it comes to remote access into a company’s cardholder data environment (CDE). There has been some confusion within the QSA community, the payments industry, and the data security/PCI compliance realm. In order to clear up confusion and offer help, the PCI Security Standard Council released a supplement in February of 2017 with additional guidance and clarification about MFA.

Even with the additional supplement, it can be confusing to keep all of the principles, terms, and definitions related to MFA straight. This post is intended to help our readers understand Multi-Factor Authentication, and the associated PCI SSC guidance, at both practical and conceptual levels.

Purpose of the MFA Supplement 

The bottom line? The PCI SSC wants to help secure remote user access. Remote access is still the biggest vector for an attack into sensitive data systems. But, strong MFA can keep criminals and hackers away from your systems.

This new supplement does not create any new requirements. Its intent is to provide further guidance and help people understand the underlying principles of security, so they can go the extra mile to truly protect their network. The overall security goal is clean, multi-factor authentication into a critical network/CDE, from anywhere outside of that network.

The supplement also does a great job of getting down to the details of MFA; it defines terms and compares authentication principles. It clears up some previous points of confusion, like what is really meant by “independence of factors,” “multi-step,” and “multi-factor.”

It’s important to note that MFA is not currently a requirement for PCI compliance. But, according to the supplement, “While PCI DSS 8.3 does not currently require organizations to validate their MFA implementation to all the principles described in this guidance document, these principles may be incorporated into a future version or future revision of the standard.” Work with your QSA now to look closely at your current MFA system, even though it may not be a requirement yet.

SEE ALSO: New Multi-Factor Authentication Clarification & Supplement: Principles You Should Know

MFA Basics

PCI DSS 3.2 requirement 8.3 says, “Multi-factor authentication requires an individual to present a minimum of two separate forms of authentication before access is granted.” In this case “two” is the minimum—not the maximum—number of factors required. For true MFA, you need at least two factors from at least two of these three categories:

• Something only you know (password)
• Something only you have (smart card, token)
• Something only you are (fingerprint, ocular scan, face scan)

While you can add other types of factors to your MFA solution—like geolocation, time, IP address, or MAC address—they don’t count towards the two-factor minimum.

“Factor Independence”

To maintain factor independence:

• Access to one of the factors can’t automatically enable access to an additional factor. For instance, if you want to use a laptop login as one factor, and an open SSH key certificate file stored on the same laptop (used to gain access to a remote server), that won’t work. You would need more server-side validated factors—like a google authentication. 
• It’s best to physically separate your factors. Good example: a password is in your head, and a token is sent to a device. Bad example: you log in to your laptop, click on a link for remote access, and a password is added automatically from a password vault or single sign-in system. In that case, you wouldn’t maintain factor independence. 

The PCI Security Standard Council reiterates that factor independence is not a PCI DSS requirement at this time, but that we should be focused on increasing security, not just compliance. The guidance supplement can help us all move up to a higher level of security.

Out-of-Band Authentication

Factors communicated through separate, protected channels and are known as “out-of-band authentication,” e.g., through a cell phone, FOB, etc. Examples:

• A remote user enters username and password, plus a one-time password sent to them on their smart phone. 
• A remote user enters username and password, and then must use a unique dynamic number found on an RSA SecurID™ token 

Be mindful when using a smart phone or another device to make a remote connection on VPN or SSH. If you use the same device to login and receive a one-time password or google authorization, this negates your factor independence.

Also, be aware of who has possession of such a device. If your text message notifications pop up and display automatically on your phone screen, you could inadvertently show someone your second-factor token. It might just be a quick SMS text message with the token, but if not secured behind a lock or pin, it would invalidate the true principles of MFA.

Cryptographic Tokens

If you’re authenticating from a single device or channel, you can enforce independence of factors by using cryptographic tokens. Here are a few examples:

• Store a token on a secure cryptographic environment like a SIM card, chip or USB, that could then be embedded directly into a device (like a laptop or cell phone, or tablet).
• Sometimes a hidden SMS text message called over-the-air programming can be sent directly to a SIM card (if the SIM card has a secure element on it). This is not something the user would be interacting with, but it would be used to run an application that would ask for a pin or fingerprint, then send you a more complex token as a second factor. In that case, you would preserve the factor independence. 

There aren’t a lot of these solutions available currently, but we keep a look out for “secure environment” methodologies. And, there will be more coming in the future.

Protect Your Factors

Whatever your factor is, you have to protect it. If it’s “something you know,” you have to use strong password principles. If it’s biometric data or “something you are,” you have to make sure it can’t be replicated. And if it’s “something you have,” make sure you’re not sharing that data with someone else, for instance with coworkers.

Understanding Multi-Step vs. Multi-Factor

The principle that has caused the most discussion and confusion for QSAs is “multi-step vs. multi-factor” authentication. We want to make sure our readers understand this principle.

The PCI DSS itself has always stated that all factors have to be verified before full access to the network or an asset is granted. It is well-understood that if any of the factors fail, no access is granted. But, the MFA supplement goes on to say that your MFA solution cannot provide any clues as to which, if any, of the factors was a failure. This additional guidance is based on strong security principles, but it is not well-understood by the community. The misunderstanding has resulted in many MFA solutions that use the following pattern:

1. Ask for a user name and password 
2. If those work, enter a second factor (like a code sent through SMS text, google authorization number, or a fingerprint.)

If you type in a wrong password and then you’re not asked for the second factor (usually with an accompanying “sorry, that didn’t work” message), then the PCI Security Standards Council—as well as the National Institute of Standards and Technology (NIST) would consider that to be a multi-step, not multi-factor authentication. This is because all factors weren’t presented at the same time and before access was or wasn’t granted, so the user can surmise which of the two tokens failed.

For true multi-factor authentication, the pattern would need to ask you to submit the username/password and the second token at the same time. Then it could subsequently grant (or not grant) access. That way the user can’t know which of the two factors failed—the password or the token.

Many of you may be using a method similar to the first example. Our advice? Move away from that. Whether you’re a merchant, vendor, QSA—find a way to achieve true multi-factor authentication. It may be difficult to hear, but the truth is that large data compromises happen through insecure remote access every day.

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

Examples of MFA 

The PCI SSC guidance document gives examples of some commonly used MFA solutions. Some are better than others. But, there are many more methods and configurations. You can work with your QSA to find the best solution for your organization.

Example 1:

• An individual logs in to workstation/device, and accesses a software token stored on that device, with one set of credentials (password A). 
• The individual then connects to the CDE/corporate network by using a different set of credentials (password B) and a “one-time password” generated by the software token as authentication.
• If both factors are valid—something you know (password B) and something you have (software token)—the authentication system will grant access.

If you use this method: make sure the software token is embedded carefully. It can’t be moved to another physical device. Protect that physical device and maintain proof of possession by the user.

Example 2: 

• An individual uses a set of credentials (password A) to log in to a workstation, and those credentials also provide access to a software token stored on the device. 
• Then the individual launches a browser window that automatically prepopulates password B (either from a cache or a password vault). Password B is then used in conjunction with the one-time password to connect to the CDE/corporate network.

This is an example of a poor MFA solution, because it does not provide independence between the two authentication factors. Password B came from a password vault stored on the device, not from memory. So, password A provides access to two factors.

Example 3:

• An individual uses one set of credentials (password A) to log in to a workstation
• The individual then uses that same password (A) and a one-time password generated by a software token on their mobile device to connect to the CDE/corporate network. 

Even though the individual used the same password (A) to authenticate the workstation and the CDE/corporate network, the one-time password from the phone provided a second, physically separate factor. Note that if you use a mobile device to get a second factor; you shouldn’t use that same device to log in to the remote system. That would negate factor independence. In this case, the phone is the device used to receive the second factor, not the device used for login authentication.

Example 4: 

• An individual uses multi-factor authentication (e.g., password and biometric) to log in to a smart phone or laptop.
• The individual then provides a single authentication factor (e.g., another password, digital certificate, signed challenge response) to connect to the CDE/corporate network.

This is a good example, although likely uncommon. The individual enters two factors right when getting into the system, and then uses a signature or client certificate stored on the device to request access to the CDE/corporate network.

If you use this method: be sure there are always two factors required to log in to the device, and that there is no way to circumvent authentication of those two factors for login. This solution could be difficult in a “bring your own device” environment; if used in such an environment, the individual user-devices should maintain a robust isolated execution environment that can’t be adversely impacted or bypassed by the user.

SEE ALSO: PCI Requirement 8: Combatting Weak Passwords & Usernames

We’re all in this together

The main thing to remember about the PCI SSC’s MFA guidance document: it’s not changing the PCI DSS. However, we in the data security realm need to learn the attributes of our current solutions and think about security, not just compliance. Are you practicing the bare minimum to achieve PCI compliance? Or have you achieved true MFA? Evaluate your solution using the principles we’ve discussed here.

Remember that we’re all in this together. We need to be ready for future changes both to the standard and to the security environment as a whole. The PCI standard helps and guides us in our quest for security. As always, it represents the “floor” of data security, not the ceiling.

More questions about multi-factor authentication? Contact 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.

Learn why you should include scans and pen tests in your info security program. 

Defects in web servers, web browsers, email clients, POS software, operating systems, and server interfaces can allow attackers to gain access to an environment. Installing security updates and patches for systems in the cardholder or sensitive data environments can help correct many of the newly found defects and vulnerabilities before attackers have the opportunity to leverage them.

But in order to patch these vulnerabilities, you need to find them first. For that you need to implement vulnerability scanning and penetration testing.

The basics of vulnerability scanning

A vulnerability scan is an automated, high-level test that looks for and reports potential vulnerabilities. All external IPs and domains exposed in the CDE are required to be scanned by a PCI Approved Scanning Vendor (ASV) at least quarterly.

PCI DSS requires two independent methods of PCI scanning: internal and external scanning. An external vulnerability scan is performed outside of your network, and it identifies known weaknesses in network structures. An internal vulnerability scan is performed within your network, behind the firewall and other perimeter security devices in place, to search for vulnerabilities on internal hosts that could be exploited in a pivot attack.

Typically, these vulnerability scans generate an extensive report of vulnerabilities found and provides references for further research on the vulnerability. Some even offer directions to fix the problem.

Remember, regular scanning is just the first step. Act quickly on any vulnerabilities discovered to ensure security holes are plugged and then re-scan to validate that the vulnerabilities have been successfully addressed. Often times organizations that have the best process have the best security.

SEE ALSO: Vulnerability Scans 101: What, Why and How to Comply

The basics of penetration testing

Just like a hacker, penetration testers analyze network environments, identify potential vulnerabilities, and try to exploit those vulnerabilities (or coding errors). In simple terms, analysts attempt to break into your company’s network to find security holes.

PCI DSS Requirement 11.3 (applicable to SAQ C and SAQ D) requires internal and external penetration testing of both the network and application layers of the CDE. But penetration testing isn’t limited to the PCI DSS. Any company that would like an unbiased look at their information security posture, should consider having a penetration test performed.

The time it takes to conduct a penetration test varies based on network size, network complexity, and the number of penetration test staff members assigned. A small environment can be completed in a few days, but a large environment can take several weeks.

Typically, penetration test reports contain a long, detailed description of attacks used, testing methodologies, and suggestions for remediation.

SEE ALSO: How Much Does a Pentest Cost?

Defining a significant change

In addition to annual penetration tests and quarterly vulnerability scans, you’ll want to perform these vulnerability assessments whenever significant infrastructure or application changes occur to determine if the changes made introduced any new vulnerabilities in the environment.

PCI DSS Requirement 11.3 requires that penetration testing be performed after any ‘significant change’ to the CDE. Due to the cost and time required to perform a penetration test, organizations often claim no significant changes have been made to their PCI environment.

How do you know when a change to the CDE is considered significant? What might be considered a major change to a smaller organization may only be a minor change in a large environment. While this should be an internal risk-based decision, here are some examples of changes that would be considered significant: OS upgrade for CDE system, replacing firewall or critical security device, adding a new payment acceptance process, moving portions or all of the environment to a cloud-hosted environment. The process your organization follows to determine if a change to the CDE is significant should be documented in internal policy and procedure documents

Penetration testing can be performed internally, if an organization has staff who are qualified to perform penetration tests and who are also independent from the systems being tested.  Someone who is actively involved in the management and configuration of systems in the CDE shouldn’t also perform the penetration test, as they would not be considered independent.  If a company lacks either the skills necessary to perform a test or the organizational independence, tests should be performed by a third-party penetration tester.

SEE ALSO: Different Types of Penetration Tests for Your Business Needs

Difference between penetration tests and vulnerability scans

As a review, vulnerability scanning, whether internal or external, is not the same as penetration testing. 


Here are two big differences:

1. A vulnerability scan is automated, while a penetration test includes a live person actually digging into the complexities of your network. 

2. A vulnerability scan only identifies potential vulnerabilities.  During a penetration test the tester will verify the exploitability of the vulnerability and look to identify the root cause of the vulnerability that allows access to secure systems or stored sensitive data. 


Vulnerability scans and penetration tests work together to encourage optimal network security. Vulnerability scans are great weekly, monthly, or quarterly insight into your network security, while penetration tests are a more thorough assessment of your overall information security posture. 


Need help with finding vulnerabilities? Talk to us about vulnerability scanning and penetration testing!

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.

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 could allow hackers to decrypt and read Wi-Fi-transmitted network traffic in some situations.

What you need to know:

• 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. See which vendors are affected and if they have been updated/patched yet.
• 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. 
• Since this attack is performed over Wi-Fi, using cellular data or an ethernet cord would remove the risk of KRACK. Also, if you connect using a virtual private network (VPN), that will encrypt all your internet traffic.
• 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 only vulnerable when using non-typical multicast communications on a wireless network.

What does KRACK stand for?

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

By: Jen Stone Security Analyst QSA, CISSP, MCSIS

As you may expect, we get a lot of questions about HIPAA compliance. Whether you're brand-new to healthcare, or currently facing a HIPAA audit, we're here to answer your HIPAA questions. Here are some of our 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 work towards HIPAA compliance?

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.

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.

What is SecurityMetrics' role in HIPAA compliance?

We offer a guided HIPAA Risk Analysis (the first and most important step toward 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.  

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 

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

Tweet

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