Last week CISA published Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default. While most of the attention has been on Security by Design, Security by Default can be a much more immediate result and a long fought win for the OT community. From the CISA document:
A secure configuration should be the default baseline. Secure-by-Default products automatically enable the most important security controls needed to protect enterprises from malicious cyber actors, as well as provide the ability to use and further configure security controls at no additional cost.
The CISA definition goes farther then the typical secure by default definition by mixing in a bit of secure by design. The default definition, I believe, is that the configuration of the features and functions of the product have a default secure setting. There may be missing features and functions to address known threats in the secure by default configuration, but those that do exist have the default, out of box setting as the secure option.
Common examples:
- Telnet, http and other plaintext protocols turned off
- Idle timeouts set rather than requiring this feature to be turned on
- Security logging enabled
- Requiring the default password be changed on first use
After Microsoft found the wisdom of secure by default in the early 2000’s, I assumed this would be what was recommended in OT as well. As I learned in a 2007 ISA99 meeting this was not the case at that time or going forward.
Shortly after this a friend at an ICS vendor shared a story that validated this. The friend’s security team implemented a feature that required the user to change the default password on initial use. Great. Default password use remains a big problem in OT even 15 years later. New and upgraded products would no longer have default passwords when operational.
As the new version began to roll out, the calls to support increased dramatically. The user set a password at deployment and forgot it. There was no backdoor recovery capability, because this would be a security weakness in some ways worse than a default password. Asset owners had to start over, and if they had not backed up logic/applications it got even uglier.
The more the new version was used; the bigger the problem. Support calls and costs up. Customer satisfaction down. Angry calls to executives from large customers up. This security enhancement was quickly rolled back, and my friend said they thought they would get fired. Executives yelled don’t come to me with any more new security features!
The straight answer from my 2007 article was right:
Here’s the straight answer: the vast majority of asset owners do not want security and vendors are not going to spend money or infuriate asset owners by forcing security on them.
Will the new push for Secure by Default by CISA and other governments around the world get enough asset owners to accept this? Demand this from their ICS vendors? I hope so.
The second bullet in the CISA document could be setting us up for failure.
The complexity of security configuration should not be a customer problem.
Yes, we should reduce the burden of security on the system’s users and administrators to the degree possible. That being said, the complexity of security configuration will be a customer problem.
Consider OPC UA. You can get encryption and authentication out of the box with self-signed certificates. Of course anyone, including an attacker, can then create their own certificate and communicate with the OPC UA server. You will have the “security” that the communication between the attacker and OPC UA server cannot be read or altered in transit.
OPC UA requires the customer, the asset owner, to have some sort of certificate architecture or approval process. For small and static networks it can be simple, but it is a customer problem. The same is true of any authentication scheme including those buzzwords that CISA and community are so hot on – – MFA and Zero Trust.
The goal should be to reduce the complexity of security configuration, especially for users and put the burden on administrators. This bullet is at least wrong and at worst misleading and anti-vendor. Remember in many (most?) cases in OT it has been the asset owners and integrators that chose not to implement security because it adds complexity to an already complex project and operation. One more thing that could go wrong and cause an outage.
I was also disappointed by the last paragraph of the Secure by Default section in the CISA document.
Manufacturers of products that are “Secure-by-Default” do not charge extra for implementing additional security configurations. Instead, they include them in the base product like seatbelts are included in all new cars. Security is not a luxury option but is closer to the standard every customer should expect without negotiating or paying more.
Ok. This is a reasonable position, and it is leaving out something equally important. Customers should expect to pay more for the standard version. More in product cost, more in support, and more for their own ongoing cyber maintenance.
I have a lot of thoughts on the Secure By Design part of the documents, but that’s another article. Two quick points that I’ll expand on later. 1) Getting rid of Insecure By Design is straightforward (not always easy, but straightforward). What Secure By Design is a much more complex and uncertain answer … and a lot harder. 2) I think the document missed the mark with the anti-vendor tone.