It hit me during Megan Samford’s bullish comments on Secure By Design at the S4x24 Closing Panel. She believed it was possible to specify a minimum set of required security configuration parameters, development processes and security controls. While Megan referred to this in a Secure By Design context, it really is a Security Floor that components, products, and systems would need to meet.
Secure By Design is not a new development concept. Nor is there a lack of high-quality content describing how to implement a Secure By Design development program. At best CISA is reformatting and bringing attention to important guidance. At worst CISA is wasting resources reinventing the wheel. Defining a Security Floor is very different than Secure By Design.
It is two very different things to say:
Here are the principles and tasks to a Secure By Design development process.
or
Here are the minimum set of security parameters, processes and controls that are required to meet a regulation … to get a trustmark or certification … to avoid liability.
The Software Liability, Regulation, and Security Floor Nexus
Two of the main thrusts of the US National Cybersecurity Strategy are Secure By Design and Software Liability. The strategy and implementation plan and rollout treat them as separate efforts, but they are related.
Product liability is facilitated by having a near universally accepted set of requirements or standard of due care. This gives the plaintiff, the injured party, something to use in court to say the product vendor should be liable for damages for not doing what the applicable field has documented as necessary.
Judges today could hold software and OT products liable for damages due to poor security, despite the end user license agreement. No law needs to be passed. Lacking some widely agreed upon set of requirements, it is less likely for a judge to make a leap let alone having a judgment survive appeals.
Whether intentional or not, if the US Government can get agreement on a security floor for products, it is a big step forward for software and product liability caused by a cyber incident. These same requirements would also likely flow through to regulation.
If you believe this, then it is in the product vendors’ interest to keep the security floor as low as possible. Every new requirement increases regulatory and product/system liability risk. The kumbaya of let’s all work together to define a robust Secure By Design approach is endangered when vendors understand how it can, or will, be used.
This doesn’t mean that vendors won’t agree to some basic security measures as musts. It’s often a better strategy to minimize rather than eliminate. And it doesn’t mean that vendors won’t continue their journeys to implement Secure By Design as defined by SEI and others. Many ICS vendors have made huge progress on this in the last 10+ years (yes, the first Secure By Design talks at S4 were I believe at S4x13 with OSIsoft leading the way).
Will Insecure By Design ICS Protocols Die?
I’ve been begging the US Government to highlight the need to require authentication in ICS protocols that can control and configure processes. Hopefully this will be part of the security floor. As PIPEDREAM demonstrated the attackers now are understanding how to use the unauthenticated ICS protocols to take rogue control or cause physical damage. If the attacker can use documented features and functions to achieve their end goal, much of the other security elements matter little.