Most years we include a secure coding session on S4’s Stage 2 Technical Deep Dives. This year it was Colin Breck‘s: It’s Not As Simple As “Use A Memory Safe Language”.
The session drew a small audience, even though it was given a prominent spot in the agenda. Those that attended were rapt, had questions, and gave it high praise. But it was a small audience. Watching it on replay I’ve pulled out several clips that hopefully will get more attention in the upcoming months.
It’s done a lot better on the S4 Events YouTube channel with 28K views and 3200 hours of watch time. Looking through the large number of comments, it’s the Rust v. C++ audience, not the OT security audience that’s viewing this. To be charitable, perhaps some of those views and comments are from software developers in OT product vendors.
This lack of interest isn’t new. Colin presented on WebAssembly in a previous S4. Adam Crain has given 2 or 3 secure coding sessions at S4 including a session on why OT protocol stacks should be coded in Rust at S4x20. He even included a Modbus client and server (Rodbus) as a takeaway. Great and important sessions, that are met with crickets. Even in the current environment where we hear the solution is secure by design.
We will continue to put one or two of these secure coding sessions on the S4 stage regardless of the response.
Why is there so little interest in the OT security community? Two thoughts and responses.
1) I’m not a software developer so this isn’t something I need to know or could understand.
If this is you, I’d encourage you to reconsider and watch the session. Yes, software developers will get the most out of it. However if you are an asset owner, integrator, consultant or anyone involved in OT security you will pull important knowledge and ideas from it.
After watching you will know enough to ask some basic questions about the development of the products you are considering purchasing/recommending/integrating. It’s like asking a vendor to see a SBOM for various versions of a product or the results from fuzz testing that was documented in their SDL. You don’t need to be an expert or spend days with the artifacts to get an understanding on the state and control of the development. What is typical is you get quick, confident and correct/reasonable answers … OR they hem and haw, struggle to create documents, and clearly demonstrate they are still decades behind in secure coding and development practice.
2) There is so much legacy code that this is a losing battle.
There is a lot of legacy code. I heard this in 2003 when I started attending OT security events. I heard it would take decades to replace this legacy code. Well, it’s been two decades. Are we going to have to wait until 2033? 2053?
Colin addresses this in his session video. My recommendation is you subtract points from a vendor’s bid if the code is from this decade and they can’t answer the questions properly. I’d also push the vendors on current secure coding practices, the age of the code in the system, and the plan to update legacy code. Don’t expect or require the complete updating of the legacy code. What you’re looking for is the analysis and plan on what legacy code is important and the program milestones.