S4 first covered Secure By Design in 2008 with Steve Lipner of Microsoft and the Security Development Lifecycle as the keynote for S4x08, and there have been many sessions on it in the intervening 16 years. The CISA dual initiatives of Secure By Design and trying to initiate liability when products and systems are not delivered secure by design have reenergized this topic. While we won’t have sessions on the basics of why and what on Secure By Design at S4x24, there will be many more advanced and leading edge policy and technical sessions and activities at the event. Here’s a summary:

Technical Sessions

Three Stage 2 Technical Deep Dive sessions fall into the Secure By Design category.

  1. The first is a hardware solution designed to eliminate the large class of memory safety vulnerabilities. Mo Javadi will present Stop Panicking Over Patching: CHERI Morello Memory Safety. From the University of Cambridge: “Morello is an industrial demonstrator of a capability architecture: a prototype System-on-Chip (SoC) and development board, developed by Arm, implementing a CHERI-extended ARMv8-A processor, GPU, peripherals, and memory subsystem.” Mo and his team got their hands on some of these and have been experimenting and been impressed with the results.
  2. Paul Chopineau will describe how to apply a granular remote access authentication infrastructure into automobiles with his session: Secure Authorization Of ECU Privileges In Automobiles. This is going to be applicable to Purdue Model Level 1 (and 0) access in many sectors. Sure we can say it’s not allowed, full stop. And we are likely to lose many of those arguments due to the business case. Better to find a way to design it securely up front.
  3. Shane Fry also looks at adding security to Level 1 with his session: A RASP Journey To Level 1 Device Security. From Wikipedia “Runtime application self-protection (RASP) is a security technology that uses runtime instrumentation to detect and block computer attacks by taking advantage of information from inside the running software.” It’s not a new concept, just new to PLCs.

On the Main Stage we have two keynotes on Secure By Design. One direct and one indirect.

  1. Dave Aitel will address it directly with his keynote: A Hacker’s-Eye View On CISA’s Secure By Design. I challenged Dave, as an independent and experienced voice, to analyze CISA’s efforts and program. What’s new (if anything)? What’s missing? Positives? Negatives? And maybe most important, how should we measure the success of CISA’s Secure By Design efforts. Dave Aitel is ideal for this session, and is an entertaining speaker.
  2. Stewart Baker will address this indirectly in his fireside chat. The US Government’s cybersecurity strategy and CISA’s implementation has prioritized an effort to hold “software manufacturers liable” for vulnerabilities. Stewart Baker is one of, if not the, top lawyer in Washington DC on cybersecurity policy. Along with the SEC regulatory issue, I wanted a lawyer to tell us how the courts would deal with software liability if laws were passed, or not passed. Especially in a context of CISA having documented some sort of Secure By Design consensus. The courts have addressed liability cases for many years and likely would find a way.

Many of the most active OT participants in Secure By Design, both in and out of government, will be at S4x24. We make the Birds Of A Feather room available for working sessions, not presentations or panels. There is one scheduled and another likely in this room.

  1. Matt Rogers of CISA will describe their existing efforts and then solicit feedback from the S4 audience. To increase the effectiveness and adoption of secure by design, participants will be asked to prioritize Secure by Design artifacts based on their impact, cost and ease of implementation. The CISA team will also garner feedback on what technology is needed to assist the industry as they bridge the gap between now and a secure by design future. Finally, to ensure we reach that future, CISA will collect information on what new technology is needed to implement secure by design. The data from this workshop will factor into future versions of secure by design for ICS.
  2. We are finalizing the details to have a Cyber Informed Engineering (CIE) working meeting.