New US CISA Recommendations on Security by Design

The answers are not perfect, but the questions are good: What do users need to know about security? And who pays for security by design?

Once again, there is news on the subject of secure by design. The US CISA (Cybersecurity & Infrastructure Security Agency) has published another paper on the subject, and half the world is joining in: NSA, FBI, and security authorities from 15 countries, including the German BSI.

It is already the second document on this topic this year. And this one again contains Secure by Design principles as well as “Secure by default practices”, “Secure product development practices” and “Pro-security business practices” for each of the three principles. (All exclusively for software.)

There are more documents with “secure by design” principles than can be counted. Another document with such principles would be worth a side note. But the CISA document contains more than that, and that’s noteworthy. It shows that the fact that secure by design is still not being practised enough is not just about technology, but that important levers (also) lie elsewhere: Communication and — how could it be otherwise — money.

Communication: What does a user need to know about a product in order to gauge its security?

Normally, publications on the subject of security by design are limited to technical recommendations on how internal development processes can be improved.

However, the CISA paper also contains concrete demands as to what manufacturers should make public.  High-level threat models, the secure software development lifecycle to which they are committed, a software bill of materials (SBOM), a policy for publishing vulnerabilities, the manager responsible for security by design, security by design roadmap, internal successes and stumbling blocks when introducing the secure software development lifecycle….

These are high standards. I’m afraid that as long as we continue to publicly beat up all manufacturers who have security problems, they’ll do everything to keep all this information out of the public — and I can understand them. Transparency only works if the public has realistic expectations regarding a product’s security characteristics and a manufacturer’s security processes. Or maybe we will only ever have realistic expectations if communicating a product’s cybersecurity becomes more normal and thus we see a broader range of realistic information communicated?

Anyway: Yes, we need a discussion about what manufacturers need to publish for users to gauge a product’s security, but also about how users and the public should deal with this public information. Security by design, it appears, is also a communication problem.

Money: Who should pay for security by design?

Normally, security-by-design publications are limited to a technical wish list. Spiteful voices could claim: A wish list for an ideal world in which budgets are infinite. At the very least, manufacturers like to argue that customers won’t pay for security.

The CISA paper contains clear ideas about who should pay for security by design.

In short: The manufacturers. Quote: “Manufacturers of products that are “secure by default” do not charge extra for implementing added security configurations Instead, they include them in the base product like seatbelts are included in all new cars. […] Security should not be a luxury option, but should be considered a right customers receive without negotiating or paying more.”

Phew. That sounds good, but far from reality — at least as long as it is a document that (quote) “urges manufacturers to follow the principles in this document”, but has no regulatory clout apart from many prominent co-editors. Jason Weiss summarised this nicely in a LinkedIn post.

After the many conversations I have had with product manufacturers and product users over the last few years about secure by design, I fear:

Manufacturers will not integrate functions that nobody pays for. They won’t feel “ urged “ to include features by anyone except their customers (or by binding laws). And that’s understandable (and, unpopular opinion, probably a good thing). There is nothing more deadly for a product than features that customers don’t want).

But the discussion is also too black and white. It suggests that security is either “built-in” or not. I know companies that have “secure versions” and “normal” versions of programming devices, for example. The difference? The price tag. Most customers opt for the normal version.

Yet security by design — just like any functional requirement — has plenty of room for negotiation (which is a good thing). Just as not everyone buys a Porsche because they don’t want to spend hundreds of thousands on a car, users of IT/OT systems will never be willing to pay for “all the security functions”.

They pay for the functions that really matter to them. This requires transparency, which brings us full circle to the first point.

Transparency is not a one-way street. Providers need to stop saying: “Nobody pays for that anyway”, and they need to start making the options for security functions and their price transparent. Customers need to stop throwing around unrealistic security requests (“Give me SL 4!”) and start being transparent about which security goals are important to them.

Manufacturers and users: consider the radical idea of talking to each other instead of throwing feature lists against each other’s heads.

Granted, it’s not just the lack of willingness to talk about security transparently, there’s also no best practices for cybersecurity communication. We have millions of secure by design principles lists, but no guidance on how to effectively communicate securie by design between manufacturers and users. But that’s another story.

No perfect answers, but good questions

The CISA publication has clear answers to both questions, the one about communication and the one about financing. The answers are not surprising, as it is CISA’s clear and explicitly stated strategy to make manufacturers more responsible for security. After all, the publication’s subtitle is “shifting the balance of cybersecurity risk”, and what’s meant here is the shift “left”, hence to the manufacturer. One does not have to fully agree with the answers provided by the publication; a more differentiated view might be desirable.

However, the underlying questions raised by the publication definitely need to be discussed if we are to make progress on the topic of security by design.

Sarah Fluchs

Sarah Fluchs is the CTO of admeritia, which specializes in security consulting for the process industry, manufacturing, and critical infrastructures. A process and automation engineer herself, Sarah is convinced that creating solid engineering methods that speak the language of automation engineers is key for security in automation. Her main research interest is to help automation security engineering grow up as a discipline. More specifically, this includes security and systems engineering, understanding security (and safety) as part of a broader resilience engineering, the use of human-readable models to make security engineering more intuitive and the use of machine-readable models to make it more efficient. To drive these research interests, Sarah leads the government-funded research project IDEAS (Integrated Data Models for the Engineering of Automation Security) and has taken a side-role as a scientific researcher at Helmut Schmidt University Hamburg in 2021. Sarah is an active contributor to ISA and IEC standards regarding automation security and a board member at both the ISA Standards & Practices board and the German water industry digitalization organization KDW. She writes a monthly "security briefing for hard hats" (admeritia.de/hardhats, in German) and a blog (fluchsfriction.medium.com, German and English). Also, Sarah is one of the founders and leaders of the Top 20 Secure PLC Coding Project (plc-security.com).