Apparently, I touched a nerve with my post on the National Institute of Standards and Technology (NIST) password standards discussed in Special Publication (SP) 800-63B. As a result, I thought I would walk you through my logic by using a compensating control worksheet (CCW) approach since this is what you will have to do for your PCI assessment if you chose to rely on the NIST guidance.
[SPOILER ALERT: It is possible, but I doubt it is worth all the effort.]
First, let us review all of what a CCW needs to comply with the Council’s requirements. From Appendix B of the Report On Compliance (ROC) Reporting Template.
“Compensating controls must satisfy the following criteria:
-
Meet the intent and rigor of the original PCI DSS requirement.
-
Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against. (See Guidance Column for the intent of each PCI DSS requirement.)
-
Be “above and beyond” other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.)
-
Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.”
QSAs can get stuck on the third point because the Council also seems to focus on that point in their Assessor Quality Management (AQM) reviews because QSAs miss that point so often. However, the other three are also very important to apply to the compensating controls being discussed.
Now let us focus on is section 4 of the CCW where the organization being assessed is required to describe the controls they have in place that go “above and beyond” the requirement being compensating which in this case is requirement 8.2.4 which requires password changes every 90 days or less. I pick that requirement because that is the one most often cited by clients as why they want to use the NIST standard. Most want to go to a 12-month password change interval. These controls are going to come from pages 13 through 15 of the SP800-63B.
- All passwords are required to be [value greater than eight] characters or greater in length.
- When passwords are modified, they are assessed against [name of credential verification source/service], [name of dictionary word list used], repetitive or sequential characters and context specific words are checked and rejected if found.
- Authentication is only conducted using [encrypted authentication protocol(s)].
- Passwords are hashed and salted for storage using [hash algorithm and appropriate salting technique].
- [Name of password vault solution] is used to securely store and generate strong passwords that meet the aforementioned criteria.
- A password strength meter is provided to assess the password against these aforementioned criteria to indicate to the user when they have met all of the criteria.
To comply with the NIST guidelines for passwords an organization needs to implement all of these controls.
So how do they match up with the four criteria for a CCW?
Above and Beyond
This is the easiest one to tackle because almost all of the controls are above and beyond. What? Almost?
There are a couple of controls that do not meet the above and beyond test.
The first is the easiest to discuss and that is “Authentication is only conducted using [encrypted authentication protocol(s)].”. That control does not pass above and beyond because it is required by requirement 8.2.1 under transmission must use strong cryptography. As such, that control cannot be relied upon in the CCW and must be removed.
The second one is the “Passwords are hashed and salted for storage using [hash algorithm and appropriate salting technique]” control. This discussion gets sticky because requirement 8.2.1 states that storage of credentials must also use strong cryptography which is not very specific. I would argue that any sort of reasonable response here would be required by requirement 8.2.1 and therefore this requirement would also be ineligible to be used.
Only the password length is specified by the PCI DSS and as long as a value greater than eight is picked, that meets above and beyond. However, we need to discuss this value further under intent and rigor.
All of the remaining controls are not specified in the PCI DSS, so those are all considered above and beyond.
Intent and Rigor
For intent and rigor, we need to look to the guidance provided for requirement 8.2.4.
“Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to work on breaking the password/phrase.”
Remember, we are looking at a 12 month password change interval, so we need to consider intent and rigor under that concept that we need controls that will allow a password to remain unchanged for 12 months.
So let us look at the length attribute again. Nine characters in today’s world without any complexity requirements can result in passwords able to be cracked in minutes. Ten characters can be done in hours. Only when we get to 12 characters and above do we get a value of at least 12 months or greater to crack. As such, I would argue that you need 12 character long passwords or greater to pass the rigor requirement for justifying a 12 month change interval.
Passwords are assessed against a dictionary word list, context specific words and repetitive/sequential characters. The key to this part of the second bullet is the extent of the dictionary word list. The dictionary needs to be sufficiently large to provide the control that NIST desires. The QSA is going to need to know how large the dictionary is, what is used as a reference to ensure that the dictionary has the appropriate words in its list and how often is the dictionary updated. That would likely mean that these controls would need to be separated from the credential breach service control so that those aforementioned additional controls can be documented in the CCW. This would all have to be backed up by a proper risk assessment that documents that the review and updatee intervals of the dicutionary are appropriate and mitigate the risks.
Passwords being assessed to some credentialed breach source/service introduces an interesting twist to ensuring the security of a password. But it also introduces an interesting discussion into the intent of requirement 8.2.4 which is to ensure the security of credentials. NIST is only requiring that credentials be tested at the point they are changed. But what happens if sometime during the 12 month interval that those credentials are compromised? The intent of requiring a 90 day change interval was to reduce the risk of credentials becoming compromised for an extended length of time by changing one of those credentials at least every 90 days.
But NIST does not require monitoring of the credentials other than when they change. Without constant monitoring of the credentials from a compromise service, how do you know when they need to be changed which is the intent of the change interval?
The PCI DSS does provide a bit of guidance on how the Council would likely approach this issue. For reference I point you to requirement 3.6.5 which discusses this in regard to encryption keys that are suspected to have been compromised. The reason I believe this is relevant here is that the PCI DSS does not require specific change intervals for encryption keys. I would argue that the PCI DSS would view passwords changing at long intervals as requiring the same sort of control. If the credentials are ever suspected of being compromised, then they should be changed.
Which brings up an interesting dilemma. How do you monitor something that you have hashed and cannot recover? Do we really want to have encrypted passwords in our authentication systems so that we can monitor them for compromise? I seriously doubt that would be a good practice.
So with that said, we would need some sort of monitoring and alerting capability to warn if credentials do appear to be compromised such as monitoring for excessive logons, logons when the user is out of the office, logons from systems outside of the user’s area or building or other characteristics that would provide some sort of indication of credential compromise. These controls would have to be added to the monitoring of the credential breach source to show that the credentials are changed when suspected of being compromised.
Similar Level of Defense and Be Commensurate
At this point, I think we have covered these two requirements for a CCW with our discussions about above and beyond and intent and rigor.
Where Are We With The CCW Controls?
Based on our discussion, here is what I think section 4 of the CCW would now have to look like.
- All passwords are required to be [value of 12+] characters or greater in length.
- When passwords are modified, they are assessed against [name of credential verification source/service]
- Passwords are monitored for excessive logons, excessive failed logon attempts, logons when the user is out of the office and logons that occur from systems outside of the user’s area or building to provide an indication of credential compromise.
- When passwords are modified, [name of dictionary word list/source used], repetitive or sequential characters and context specific words are checked, and the password is rejected if any of these characteristics are found. The dictionary is updated every [month/quarter/six months] and reviewed [semi-annually/annually] to ensure the dictionary contains an appropriate list of words.
- [Name of password vault solution] is used to securely store and generate strong passwords that meet the aforementioned criteria.
- A password strength meter is provided to assess the password against these aforementioned criteria to indicate to the user when they have met all of the criteria.
After looking at these controls, I would venture to say it is simpler and easier to meet the PCI DSS requirements than to implement these controls and make them work consistently and effectively. Because remember, this is just section 4 of the CCW. For section 5, you have to produce evidence that all of these controls are in place and working as designed. Never mind section 6 where you explain how you maintain all of these controls.
So for those of you bent on using NIST, there you have it but I doubt it is worth the effort you think it is. And this does not address the CCWs you will also need to write for 8.2.3 because you no longer enforce complexity and 8.2.5 because you no longer track the last four passwords used. But those could be another post. Yeah, I do not think so. Not worth the effort because those CCWs will revolve around the controls in this one.
As I said in my original post, it might be better to wait for the Council to issue their guidance in v4 of the PCI DSS.
UPDATE: The PCI Council has created an FAQ to address this situation. https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Can-organizations-use-alternative-password-management-methods-to-meet-PCI-DSS-Requirement-8
PCI Guru 
I would expect to see some reasoning concerning the justification given by NIST for their changed guidance, e.g. that changing the passwords frequently is bad for security.
Read SP800-63A as it has a lot of the logic behind what they did and why they made the changes. Mostly it was to improve the security of passwords and stop users from making bad password choices.
Guidance from an assessor newsletter. Not sure if you posted this:
How Does the NIST Password Guidance Impact PCI DSS?
The password requirements in PCI DSS include a minimum level of complexity and strength that can be met by all types of organizations via many technologies. PCI SSC encourages entities to implement stronger controls or additional security measures as appropriate to meet the security needs of their organization.
PCI DSS does not prevent an organization from implementing alternative controls than those defined in the standard, as long as the intent of the requirements is met. Entities wishing to follow a different combination of password complexity and change frequency (for example, based on the NIST Digital Identity Guidelines) can document their approach as a compensating control. The entity can then demonstrate how the risk is mitigated and how the intent of the requirement is met through implementation of other controls (for example, how controls address the risk of passwords being guessed during their lifecycle).
In the case of the recent NIST guidance, it is important not to look at any single recommendation in isolation but to take all the recommendations as a complete set of controls. For example, the suppression of the periodic password change is compensated by implementing more stringent rules to ensure that the password cannot be guessed. In other words, suppressing the requirement for periodically changing passwords without the implementation of additional compensating controls does not meet the intent of either the NIST guidance nor the PCI DSS password requirements.
PCI SSC continually monitors changes in technologies and payment environments and may incorporate updates in future PCI DSS revisions as needed to support evolving industry best practices.
Great timing as usual PCI Guru. The sad part here is we are arguing over “Passwords” like they are truly worth anything anymore. All it takes is clicking on the wrong Phishing e-mail and your credentials are gone. Granted we need to have, “something” in place but the use of passwords by themselves as control are essentially dead.
With that said, I am not convinced the PCI-DSS standard / council is requiring a compensating control here at all. The standard provides the following guidance related to 8.2.3:
This requirement specifies that a minimum of seven characters and both numeric and alphabetic characters should be used for passwords/ passphrases. For cases where this minimum cannot be met due to technical limitations, entities can use “equivalent strength” to evaluate their alternative. For information on variability and equivalency of password strength (also referred to as entropy) for passwords/passphrases of different formats, refer to industry standards (e.g., the current version of NIST SP 800-63.)
The council has always deferred to NIST, ANSI, OWASP etc to set specific guidance. In fact, I think you mentioned this in one of your posts. In the case of password security, the standards we have been enforcing for the last 18 years are inherently flawed and do not reduce risk; they were also admittedly “made up”. If you look at the research (google it), which NIST based its recommendations on, it proved conclusively that enforcing complex passwords, and password changes does not work. All we have done is made it easier for malicious actors to guess a password. For example, the research (based on the vast trove of breached passwords (thank you Yahoo, facebook, etc) shows that people will start a password with a capital letter, and will end it with a number. This number is often the result of a password change, and incrementing the number. Therefore changing the password does absolutely nothing except decrease security; because if the credential is hacked they are going to already know what the next one is. We will likely be writing compensating controls regardless to document these facts but in my experience, the council is pragmatic; provided you have clearly documented how you arrived at a conclusion. They are not going to argue with you if you reference the NIST standard and follow it.
As you posted later on, the Council is stating that any deviation from the PCI DSS requirements requires a CCW.
So are you saying that PCI DSS is stronger than NIST, or are you saying that PCI DSS is written in such a way that applying stronger controls is not worth the effort? The latter could be construed that PCI is hindering security. I’m one of those that believe forcing users to changes their password(s) every 90 days causes more problems than it solves. Applying authentication velocity throttles is a good control against brute force password attacks and does not contribute password post-it notes that many non-techie users resort to.
I am just explaining how a QSA is going to have to deal with the NIST standard against the current wording of the PCI DSS. Nothing more. As I stated, until the Council changes the DSS, a QSA must deal with any deviation from the DSS with a CCW.
It is a difficult one – especially as Microsoft has just announced the removal of password expiration as well. An update from Council on this issue is overdue..