Last Wednesday (September 11), the U.S. Department of Defense released a draft of its Cybersecurity Maturity Model Certification (CMMC) for public comment. The idea is for the DoD to create a unified framework for defense contractor cybersecurity.
Now you might think that none of this is new. After all, DFARS 252.204-7012 has been in effect since December 2017 and it requires that defense contractors comply with the National Institute of Standards and Technology's Special Publication 800-171 (NIST SP 800-171). Unfortunately, it has become obvious that full compliance with NIST SP 800-171 is overkill for many contractors and projects. It also isn’t clear who needs to comply with what portions of NIST SP 800-171 and how that is enforced.
This new document attempts to make the DoD requirements fit better with the specific security needs of a given department or project by allowing contractors to operate at five different maturity levels. I won’t go into all the details, but the U.S. legal firm Arnold & Porter provided a nice in-depth analysis of both the need for and challenges of a CMMC framework in their recent blog.
With others commenting on the policy issues, I decided to look at the CMMC from a technical point of view. In other words, does each requirement seem appropriate for the maturity level it is assigned to?
For the most part, the CMMC is reasonable. For example, there were sensible requirements for the use of password managers and Multi-Factor Authentication (MFA) for contractors operating at Maturity Level 4. However, I was shocked to see a requirement that was straight out of the days of the mainframe:
Identification and Authorization (IDA) L3-5: A minimum password complexity, including change of characters, is defined and enforced.
While this requirement has its history in NIST SP 800-171, it is diametrically opposed to the current NIST guideline for password management, NIST Special Publication 800-63B. Section 5.1.1.2 of that document explicitly requires that organizations NOT force users to use the complex mix of numbers, letters, and punctuation. The UK has a similar policy on password composition rules for any organization supplying services to its government.
Why prohibit composition rules for passwords? To quote NIST:
Composition rules also inadvertently encourage people to use the same password across multiple systems since they often result in passwords that are difficult for people to memorize.
Today no one who studies cryptography thinks enforced password complexity is a good security strategy. It is not a secret that humans are poor at remembering random sequences of characters. They may be able to remember a few important sequences (such as their phone number) but as soon as they are required to memorize more than a handful, they resort to “tricks” to help out. Writing passwords on Post-it Notes is one trick. Adding a number or a special character to a simple word or an existing password is another common solution.
So when companies force users to invent complex passwords, users resort to using secrets like Password!. In other words, they use passwords that are easy to remember but are extremely insecure. The bad guys understand human nature and start with the faux-complex passwords like Password! when they are hacking a system.
Unfortunately, as this latest DoD document shows, these old-fashioned policies are still prevalent throughout many IT departments and required in many security guidelines, including NIST SP 800-171. It is time for them to go.
What should DoD be asking contractors to do instead? First, they should require contractors instruct their staff to NEVER reuse passwords, especially across systems. Each password should be completely different from any previous password you have used.
Second, employees should be coached to choose passwords that will never be found in a dictionary. The UK government advises creating passwords using three random words:
You just put them together, like 'coffeetrainfish' or ‘walltinshirt’.
It is a good strategy and the famous techie cartoon xkcd shows why this works:
Staff should be warned not to get cute and substitute numbers for letters (such as “5” for “s”) as the bad guys are already onto them and try passwords like Pa55w0rd.
I hope passwords will die out soon, to be replaced with far better technologies like Multifactor Authentication (MFA) and Fast Identity Online (FIDO). In the meantime, if contractors train their users to make every password different, ideally from a string of random three or four words, the DoD’s IT and OT systems will be far more secure than annoying password expiry policies ever made them.
For More Reading:
NIST 800-63-3 Appendix A: The Strength of Memorized Secrets: https://pages.nist.gov/800-63-3/sp800-63b.html#appA
Eric Byres
Eric is widely recognized as one of the world’s leading experts in the field of OT, IT and IoT software supply chain security. He is the inventor of the Tofino Security technology – the most widely deployed OT-specific firewall in the world. When not setting the product vision, or speaking at a conference, Eric can be found cranking away on his gravel bike.
Stay up to date
Browse Posts
- May 2024
- February 2024
- December 2023
- October 2023
- April 2023
- March 2023
- February 2023
- October 2022
- April 2022
- February 2022
- December 2021
- November 2021
- August 2021
- July 2021
- June 2021
- May 2021
- February 2021
- January 2021
- December 2020
- September 2020
- August 2020
- July 2020
- May 2020
- April 2020
- January 2020
- October 2019
- September 2019
- November 2018
- September 2018
- May 2018
Browse by topics
- Supply Chain Management (16)
- SBOM (15)
- Vulnerability Tracking (15)
- #supplychainsecurity (10)
- Regulatory Requirements (10)
- VEX (8)
- EO14028 (6)
- ICS/IoT Upgrade Management (6)
- malware (6)
- ICS (5)
- vulnerability disclosure (5)
- 3rd Party Components (4)
- Partnership (4)
- Press-release (4)
- #S4 (3)
- Software Validation (3)
- hacking (3)
- industrial control system (3)
- Code Signing (2)
- Legislation (2)
- chain of trust (2)
- #nvbc2020 (1)
- DoD CMMC (1)
- Dragonfly (1)
- Havex (1)
- Log4Shell (1)
- Log4j (1)
- Trojan (1)
- USB (1)
- Uncategorized (1)
- energy (1)
- medical (1)
- password strength (1)
- pharmaceutical (1)
Post a comment