Podcast: Where Do Your Bits Really Come From?

Earlier this year I attended the Public Safety Canada Industrial Control System Security symposium in Charlottetown, PEI (FYI the PSC ICS events are outstanding – worth attending, even if you are not Canadian). While there, I had a chance to meet with an old friend, Andrew Ginter, Vice President of Industrial Security at Waterfall Security Solutions. We chatted about an issue I’ve been interested in – or, dare I say, obsessed with – for a while now: the software supply chain in ICS and how to ensure that it’s trustworthy. Our conversation was the basis for the podcast Where Do Your Bits Really Come From? Let me fill you in on some of the points we discussed.

We began by talking about the field itself: just how widespread is the issue of supply chain integrity? The problem is actually much larger and complex than I suspected when I started investigating it in 2017. Initially, I thought that the problem just affected the owners and operators of ICS assets: as the 2014 Dragonfly 1.0 attacks showed us, technicians in the field risk patching their control systems with harmful updates.

Dragonfly Attacks
The Dragonfly attackers penetrated the websites of ICS vendors and replaced legitimate software with packages that had trojan malware called Havex embedded in them. Customers downloaded and installed these infected packages, believing them to be valid updates.

However, the more people I spoke with about supply chain issues, the more I realized ICS vendors had their own challenges as well. It turns out that people view the problem differently depending on which vertical they’re in and what their role is – but the same basic problem still exists for all audiences.

So what exactly is the problem? Well, that’s pretty simple: How do we, as users, trust the firmware and software that we’re loading into our industrial control systems?

And to look at it from the other side: How do vendors know that the software out in the world associated with their organization hasn’t been tampered with or did, in fact, come from them?

When dealing with software, there are multiple issues that test our trust. The two examples I discussed with Andrew were counterfeiting (injection of malicious code into the supply chain) and our inability to know exactly what components make up a software package. This latter issue is complex because of the way we develop software today: most software projects include embedded third-party and open-source code. And that embedded code has its own third-party and open-source code embedded in it. So what happens if one of those subcomponent’s subcomponents has a vulnerability? Would the ICS vendor even know about the vulnerability? Would their customers know? Unfortunately, the usual answer is “No.”

Nesting DollsPhoto by Marco Verch / CC BY 2.0 / Cropped, small doll face altered

This may sound a bit gloomy but don’t despair: we talk about how the industry is making progress in this area. For example, code signing technology is useful to address the software tampering issue, though it won’t solve the problem on its own. Unfortunately, it is complex, it’s not widely used outside of IT software – AND malware writers have figured out how to use it to their advantage!

The key is in the ability to break down the libraries so that we can identify who built which pieces and generate a reliable Software Bill of Materials, so to speak. The solution, as is often the case, lies in having better knowledge and then being able to effectively share that knowledge with users.

It’s amazing how much ground you can cover during a single conversation. After talking extensively about the problem, I shared how we are using the information available to us to find a solution. I spoke with Andrew about aDolus, how it all started, and how our team is working to address the problem with the supply chain. Vendors are keen to come on board to help us with our solution.

I’m hoping you find the challenge of securing the supply chain as interesting as the aDolus team does. If so, jump over to the Waterfall Security Solutions podcast page and listen to the full podcast. If you stick around until the end, you’ll even get to hear where the company name aDolus comes from. Enjoy!

Will the DoD’s CMMC Encourage Bad Password Habits?

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:

Bad password cartoon from xkcd

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/appA_memorized.html

Scroll to top