What you need to know about secure default configuration, insecure by design and secure by design

Courtesy of Brett Sayles

Admission: I’m adverse to large, multiyear programs. I don’t want to work on them, and I’m skeptical that they will achieve their goals. I favor a series of short-term, quick and significant wins recognizing the Pareto Principle, 80/20 rule.

My initial impression of the U.S. Department of Energy’s Cyber Informed Engineering and CISA’s Secure by Design effort is they are well meaning, not wrong, and unlikely to make a difference in the next three years. I hope I’m wrong.

For the operational technology (OT) and industrial control system (ICS) security world, we would be better off focusing on two areas where progress is achievable in the near term and would result in large cyber risk reduction.

The value of secure default configuration

Is the system delivered to the customer with the default configuration settings in their most secure mode? Are telnet and tftp turned off? Does the default password have to be changed at initial startup? In OPC UA are you required to approve certificates or use a CA?

The secure by default term is catchier, and misleading. It doesn’t mean the device or application is secure. It only means the most secure available option has been selected.

While the information technology (IT) world has embraced this concept since Microsoft dealt with worms back in the early 2000s, the OT and ICS security community has rejected it. The largest blame goes to the asset owner, the customer, the end user of these systems. When vendors deliver a secure configuration, it means more work and more problems. Of course, vendors should work to reduce this work, this friction, but it won’t be zero.

When ISA99 began its work two decades ago, a secure default configuration was quickly discarded by a near unanimous vote. Availability trumped all, and security could affect availability. In 2012, a major vendor added a security feature that required changing the default password. Result: customer revolt, increased service costs and the near firing of the security team.

Are asset owners ready for a secure default configuration a decade later? If yes, this is an easier step for the vendors — much easier than secure by design. If no, at least the vendors are increasingly offering the possibility of secure configuration settings.

What we were missing two decades ago and still today is asset owner demand, or at least acceptance, of a secure default configuration, and acceptance of the initial complexity and cost this will bring to the project and ongoing operation. Until this happens, it is hard to fault a vendor for giving customers what they want.

How insecure by design continues to hurt OT/ICS

Yes … this again in 2024.

Insecure by design definition: There are features and functions in a product or solution that allow an attacker to achieve their goals without exploiting some security vulnerability or misconfiguration.

Insecure by design is different and much worse than a lack of secure by design. From a cyber risk perspective, eliminating all of the bugs leading to vulnerabilities in a product does little if the attacker can use a documented feature to achieve their goals. Features such as:

  • Sending write commands to make things hotter, spin faster or turn on or off.
  • Sending a command to shut down the programmable logic controllers (PLCs) monitoring and controlling the process.
  • Uploading new logic/applications to change the process.

All without authentication!

Most of the ICS protocols either have or are developing a secure version that includes encryption (which is often not necessary) and authentication (which is absolutely necessary).

This would be the next step to add to the secure default configuration. Get these secure protocols into the solutions, and set them as the defaults.

Two additional thoughts on the move to authenticated protocols:

  1. Vendors should add this as a firmware or ethernet card upgrade rather than continue the troubling trend of requiring a purchase of a new PLC. The new ethernet card approach should work on all but the 15-plus-year-old devices. Rip and replace has been an argument against getting rid of insecure by design, and it has never been necessary.
  2. This is not ignored in secure by design or cyber-informed engineering (CIE); it’s just not prioritized. It should be pulled out and made a separate effort. The purchase and use of authenticated protocols as a percentage in critical infrastructure sectors is a great metric.

Understanding secure by design

A few quick thoughts:

Yes, this is a good and necessary philosophy and design approach.

There is plenty of information published on secure by design. Lack of information is not the problem.

No, it’s unreasonable for security to be free, with no additional product or support cost for the customer. Maybe there won’t be a standalone security premium, but all prices will go up. And this is as it should be in a world filled with for-profit companies.

The reducing consequences/engineering aspects of CIE are an area that is newer and less well known, less documented and less practiced. It would be better if this area was focused on by the Department of Energy rather than the holistic, “let’s address everything” approach in CIE.

One of the challenges of these large, multiyear programs is measuring effectiveness. The program meeting programmatic milestones and publishing documents is not success.

It would be better if the U.S. government used its influence to focus on and measure secure default configuration, secure ICS protocol availability and use and the consequence reduction approach.

Original content can be found at Dale Peterson.




Keep your finger on the pulse of top industry news