When we get on our soapbox and stress the importance of identifying and fixing what we believe our widespread implementation vulnerabilities in SCADA devices and applications we frequently hear “everyone knows the SCADA protocols have no security so what is the point of worrying about implementation vulnerabilities.”  You will even see this in many of the blog comments.

Sure the lack of security in Modbus TCP, DNP3, OPC, ICCP and other protocols is important.  This problem typically manifests itself in any user that can access a device via a SCADA protocol can often read or write to the SCADA device since neither the source or data is authenticated.  Some protocol implementations, such as ICCP servers, only allow users to read values, and there are a number of protocols that are in the process of adding security controls to address this deficiency.

Implementation vulnerabilities are much more serious.  Here is a simple parallel statement to the why worry argument we hear  “why bother patching Microsoft vulnerabilities when we know the SCADA protocols have no data or source authentication?”

Most of the SCADA security community understands why patching Microsoft vulnerabilities is so critical.  An attacker with access can scan a network, identify Microsoft vulnerabilities, get a free tool like Metasploit, and take control of the computer.  The attacker can than launch attacks from this new beachhead using a simple pivot feature.  Maybe even more likely is a worm that exploits the vulnerability finding its way into the control center network and compromising unpatched systems.

We have the same situation with SCADA protocol stack implementations.  These stacks can and do suffer from a variety of vulnerabilities commonly found due to poor software design and coding practices.  Perhaps the most serious and exposed SCADA protocol stacks are those that are used to exchange information with business partners, such as ICCP, or those used to exchange information between the corporate network and control center network, such as OPC, as shown in the diagram below.

In this diagram, an attacker from the corporate network or business partner network would be able to reach the OPC or ICCP server using those protocols, even with a least privilege ruleset. Once this server on the DMZ is compromised the attacker would launch attacks on servers in the control center, often these are similar OPC or ICCP servers.

This concern is why we have four papers and presentations on implementation vulnerabilities in SCADA protocols and devices at S4.  Two of the talks are on OPC (previewed here and here), another talk is from Matt on ICCP, and the fourth talk is detail on the Wurldtech Security Achilles test tool and methodology which I’ll preview this week.

Control system vendors are going to need to step up the security of the software design and coding as well as security QA.  If vendors need help they should check out the new effort by CERT to document Secure Coding Requirements and Recommendations.  (hat tip: The Art of Software Security Assessment blog)