It’s inevitable, your SCADA system that you have been so careful with has been discovered to be running software that has remote vulnerabilities. What do you do? These servers have to be up and running, but you know that with every packet coming in, there is a chance that it’ a hacker taking over the system. This is a situation that many groups face trying to maintain the systems that run key infrastructures like energy, water, and food.
A pair of the most recent vulnerabilities in some versions of Simatic WinCC SCADA , could provide remote code execution to an attacker who sent a crafted packet. Simply put, if an attacker could send a packet to the vulnerable SCADA server, then they could do whatever they wanted. This could include gathering data from the system to affecting the function of the SCADA itself. Now, more than two months later, the patch has been released to fix these issues.
Two months is a long time to try and mitigate a remote vulnerability. The only way to do so with any level of assurance is to have proper access control over both internal and external connections. External connections can be managed well by the firewall and VPN, but what about the internal? ACL’s, which are folder controls, aren’t enough in this case since the attacker just needs a packet to reach the server to succeed in their attack. Instead what we need is the far more granular true access control for our network.
Vulnerabilities aren’t going to disappear, they are as inevitable as death and taxes. What we need is to develop an environment around our systems where we can control what users are actually doing on our networks. Only when we have achieved this local control over our network will we start being able to really fight back against the hackers.