It is so disheartening.
Secure By Default is a straightforward and critically important security concept. The default settings for a device or application should be secure settings so an administrator must turn off security to weaken rather than turn on security to strengthen.
My Secure By Default tale starts in June at the ISA SP99 Working Group 4 meeting to begin work on Part 4 of the standard. Part 4 is a normative standard meaning there are must or shall statements rather than guidance. Applications and devices can be compliant and eventually certified to a normative standard.
During the initial meetings the group was outlining the standard, determining what was in and out of scope, and dealing with other broad issues. I raised the point that since products are going to claim to be Part 4 compliant, should we require the default settings meet Part 4 to claim compliance? In other words, does ISA SP99 Part 4 require Secure By Default?
In my mind, this was simply a clarifying statement that all would agree to. Much to my surprise about 90% disagreed with the concept of Secure By Default in control systems. Obviously I did not explain it correctly. Second try. Do we as SP99 want an asset owner to purchase a product that is certified as SP99 Part 4 compliant with all of the security requirements in Part 4 disabled at delivery? Of course not. Next informal vote and Secure By Default loses big again. The group understands the issue but disagrees with the concept of Secure By Default. Depressing and surprising since there are a lot of smart people comprising this group.
So over the last two months I’ve used the opportunity of industry events and telephone conversations to ask a lot of people about Secure By Default.
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.
The most compelling discussion was with a product manager of a very popular product line in the control system community. The product manager said Secure By Default almost cost him his job. I chuckled figuring this was hyperbole. The manager was completely serious and repeated this multiple times. They implemented Secure By Default which just required the asset owner to configure some authentication at installation. This caused widespread customer complaints as they locked themselves out, large support cost increases and actual loss of customers.
Secure By Default was removed in the next version and support has gone back down. No one is using the security features. Imagine the response this manager gets when asking for new security features or security resources. It was a long, sad emotional story.
I heard similar, if less dramatic, versions of this story repeated by many vendors. During our recent OPC testing one of the vendors said:
In our OPC server product the user can configure whether or not to obey the DCOM security settings. Do I like having a setting like this? No, but at the end of the day a large majority of customers pushed for the ability to turn DCOM security off (by default) since their environments were not tied to the outside world, so we listened to the customers and made this an option.
Note the default setting is DCOM security off.
I can’t blame the vendors this time. They are delivering what customers are demanding. I can’t blame SP99 WG4 because they are in line with the sentiment of the community.
At a minimum it would be good if a vendor offered a Secure By Default purchase option, much like you can by a FIPS 140 certified version of some products, but today I would have a hard time honestly saying this made business sense for a vendor.
At the recent Weiss event, one luminary from a chemical manufacturing asset owner made an impassioned plea for the asset owners to demand security during procurement. Even pounding on the table in an effort to wake people up. We need a lot more of that, but right now it does not look good for broad based improvement in the control system security posture over the next five years unless there is an event that wakes the crowd up like some of the worms did for Microsoft users. Let’s hope that doesn’t happen, but it is frightening to rely on hope.
My expectation is many regular readers are going to comment on how availability is more important than anything else, and we always welcome divergent views. However there are ways to pre-stage Secure By Default devices, train installers on the appropriate techniques, and be successful. Vendors need to make installing with security as simple as possible, and since they are new to this there is probably room for improvement.
When a system or device is installed there are requirements such as connecting power and cables, loading databases and setting parameters, and placing it in an operating mode. Until we start to view initializing the authentication, authorization or crypto keys in the same vein the community is simply relying on the isolation and lack of motivated attackers for the safety and reliability of the critical infrastructure.