Secure Default Configuration, Insecure By Design & Secure By Design

Admission: I’m adverse to large, multi-year 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 US Dept 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 OT and 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.

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 IT world has embraced this concepts since Microsoft dealt with worms back in the early 2000’s, the OT & 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 the 2012 a major vendor added a security feature that required changing the default password. Result: customer revolt, increased service costs, and 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. 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 their customers what they want.

Insecure By Design

Yes … this again in 2024.

Insecure By Design Definition: 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, turn on or off
• Sending a command to shut down the PLCs monitoring and controling 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 (often not necessary) and authentication (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+ 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 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.

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, 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 Cyber Informed Engineering 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 Dept of Energy rather than the holistic, let’s address everything approach in CIE.

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

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