Security Policy Lessons from SCADA Attacks

Reports from the last few months have generated another wake-up call for those concerned with the security of the nation’s critical infrastructure. In addition to audit reports of widespread vulnerabilities among agencies managing the infrastructure, the first malicious software was discovered “in the wild” that specifically targets the SCADA system employed to manage these networks.

While there have been many warnings in the past about vulnerable systems, this was the first attack targeted at software used to manage large-scale industrial control systems used by manufacturing and utility companies. The malware was unique in both its sophistication (combining multiple vulnerabilities) and specificity (targeting specific systems and software). Several governments (including Iran) confirmed that their networks had been infected.

What went Wrong?

While it might be tempted to write off these incidents as specific to SCADA systems, doing so would miss a great learning opportunity. In fact, the vulnerabilities that were exploited in these attacks are quite common in many production applications and can teach us some valuable lessons about the importance of security policies. So let’s walk through a few of the lessons as they relate to these SCADA attacks.

Policy Lesson 1: Identify Critical Systems – It appears that the computers running control system software generally had lax security controls. While there is no way to know this, we can assume that either (1) the infected organizations did not know that these systems were critical or (2) failed to identify them as part of a risk-assessment process. Because of their ability to control large-scale systems, it is obvious that these systems are business critical. The more likely scenario was that they were not identified as needing any specific security policy controls.

Q: Do you have any critical systems lurking in your network that have not be identified and rated? Do your written policies require a critical system inventory and risk assessment?

Policy Lesson 2: Disable USB Drives to Critical Systems – The primary attack “vector” for this malicious software was propagation through USB drives. The simplest policy control is to disable USB drive access for critical systems. A less-restrictive policy is to require scans of all connected drives for malicious software.

Q: Do your security policies address the issuing, labeling and control of portable storage?

Policy Lesson 3: Prohibit Fixed Passwords in Software – One of the key elements of the attack was that the malicious software searched for specific versions of the SCADA software (written by Siemens). The software employed an embedded and fixed password for access to the SQL system database. The great tragedy of this approach is that the logical fix (change the password) will likely break the software. (In fact, Siemens admitted this in their instructions to customers.)

Q: Does your organization develop or buy custom software? If so, do you have a secure application development policy that prevents these problems?

Policy Lesson 4: Watch for your Software IP in the wild – Apparently this fixed password has been discovered and published for some time on the internet. That enabled the malware authors to craft the specific attack. Several releases ago we included several security policies that enabled organizations to perform basic searches to see if their software source code and had been compromised and available on the web. (A technique called “Google Hacking.”) Organizations that develop mission-critical software can implement these policies with a minimum of effort to reduce the likelihood of vulnerabilities being publicly posted.

Q: If your organization does develop custom software, do you know if it has been compromised and available online?

Policy Lesson 5: Don’t focus only on Regulations – This attack is a classic example of how focus on “compliance” can lead organizations to miss a large number of “persistent” threats. Both FISMA (NIST) and NERC-CIP have been recently criticized for focusing more on compliance documentation while not addressing evolving threats. That is why we incorporate lessons from real-world incidents into our security policy libraries. In some cases (like this one) most of the policy controls already existed. But in many other cases these attacks lead us to specific policies that would never be identified by focusing on regulatory compliance.

Q: Is your security policy program designed to incorporate new controls to address the latest technologies and real-world threats?

The GOOD News

Looking at this attack in some detail, the good news is that any one of these existing security policies could have helped eliminate this threat. In fact, each of these topics has already been addressed within our PolicyShield Security Policy Subscription. That is why our mission is to help organizations get security policies implemented and updated as effectively as possible. While there are certainly many legacy systems in production that were developed using security principles, we know enough today to build the secure applications of the future.