Reflecting on ICS/SCADA Software and Hardware Security Vulnerabilities

On a fairly regular basis someone will send me a link about a newly disclosed vulnerability in ICS/SCADA control system software or hardware and ask me what I think about it.  Recent examples include backdoor remote access embedded into hardware with trivial authentication and weak cryptography, systems that are left unpatched due to lack of vendor support, control system software and hardware with a myriad of security holes and vulnerabilities, etc.  The list is long, and seems to be increasing at an alarming rate.  My guess is because there are an increasing number of security researchers who are actively trying to get the message out about the insecurity of these systems.  Many of these, like trivial authentication and lack of patch management, are dirty little secrets that are not surprising to those that work in the industry.  What is different is the press and attention they are receiving of late.

I won't comment on the motives of these researchers, but some of them definitely have a vested interest in the attention it draws to the security problems in ICS/SCADA, in the hopes that it will generate buzz and attention to their company and to the security problems in general with the ICS/SCADA equipment.  Nevertheless, these vulnerabilities and problems do exist, are pervasive, and neither the industry nor the vendors seem to be acting very quickly to correct the situation.  Trying to correct these security issues after the fact just doesn't work very well.  As security professionals, we understand that security must be integrated into the entire development life-cycle of hardware and software.  

So who is responsible for the security of these systems and what can we do?  ICS/SCADA manufacturers and integrators need to step up their game and create solutions that meet security best practice standards, at the very least. If they want to continue providing products and services in the Electrical Energy Sector (or many other SCADA environments), they also need to be able to demonstrate that their products are not only secure but are compliant with, and facilitate compliance with, NERC CIP and other regulatory standards.

End user entities of ICS/SCADA hardware and software need to "Trust, but verify", to coin a phrase.  These entities should be asking questions.  Lots of questions.  Create and ask for validation and verification testing that the equipment, designs, and other solutions are going to meet your operational, security, and compliance requirements.  Do this early in the process of selection and procurement.  Engage with your vendors and let them know your concerns and find out what their path forward is for creating and supporting security throughout the life-cycle of their products.

If you aren't comfortable with putting your vendors to task, enlist the services of a company like Critical Assets.  We can help you develop design selection and testing criteria that meets your specific needs as well as facilitate testing in your facility or ours.  Ensuring that your ICS/SCADA hardware and software is secure, compliant, and operational can be a difficult task, but it can be done and there is help available.