ETC Eos and SMBv1 vulnerabilities (RE WannaCry)

I'm a big proponent of air-gaped lighting networks for this reason. There is zero functionality to be gained by putting your lighting network on a public facing network. Don't put yourself into a situation where your system is vulnerable to such attacks.

I'm a big proponent of air-gaped lighting networks for this reason. There is zero functionality to be gained by putting your lighting network on a public facing network. Don't put yourself into a situation where your system is vulnerable to such attacks.

I see your point, however if we have potentially untrusted devices from external technicians connecting to our air gapped control network that have previously been on the internet they may be infected with something that could potentially propogate to the console. (We use ETC Nomad in client mode regularly as a remote control)

I personally don't agree with the "it's insecure, we know, so just don't connect it to a network" argument considering patches have been released (I understand that they will have to be tested with the specific version of Windows XP embedded running on our Element) and that EOS appears to be using SMBv1 which is known to be very vulnerable when there are newer more secure iterations of the protocol available.

Obviously if there is a critical feature that relies on a specific functionality in SMBv1 that isn't replicated in the later versions that would explain a longer development time to move away from that protocol.

If ETC were to come back and say we need to upgrade our Element to a Windows 7 mainboard I would far rather attempt to find the budget (we are a student theatre run by volunteers on a very small budget) than run quite such a vulnerable system.