I've done quite a few assessments of insecure-by-design systems and have noticed a new trend: instead of creating a new protocol which has data integrity and authentication, there is a vendor push to instead wrap their existing protocols inside SSL. This is done in a variety of ways: stunnel is the easiest and cheapest way, but some vendors are even programmatically wrapping their protocol using SSL libs.
While it's good to see even this level of security on a control systems environment (where the most insecure-by-design protocols live at present), it's not a very good solution in the end. There are a lot of really smart people in the industry that believe in this method, and I respect them a lot. It's still not a very good solution.
Wrapping your insecure-by-design protocol in SSL and calling it good is easy for vendors, PITA for end users. The trouble lies in key management. Each system needs its own certificate for maximum benefit. Control systems by their very nature should not be allowed to reach out to the internet directly, and typically these systems are on a DNS domain that is not managed by ICANN. So obtaining certificates from a known CA is not practical.
In the end, certificate management is up to the client: they likely need
to run their own CA, their own certificate revocation system, and have a
plan in place to revoke and dispense new certificates if and when any
of the hosts with a certificate is compromised. This is an unfair
burden to end users, and I worry that vendors will point to this
campaign's failures as just another reason that ICS and SCADA systems
shouldn't worry about security.
Image by thievingjoker