The Department of Energy recently published 21 steps to improve the security of the smart grid and other public assets (i.e., power and water) that are remotely managed and monitored.

The history of these networks is classic IT, from mainframe orientation to distributed and now networked. However, the impact of open source has not truly been felt in the document because secrecy is still seen as valuable. 

The reality of security standards is that the relationship between open and secure has become closely aligned. It turns out that the “keep quiet” strategy about security breaches only makes it easier for the black hats to penetrate multiple sites.

Open conversations are the way to improve security for everyone. One of the most used forms of vulnerability is to attack the software looking for bugs that can be used to penetrate the servers and once found can be used to inject or shut down operations.

These software flaws are best discussed in open forums to enable the most people to provide quality assurance. This is the way that open source solves the quality assurance aspects of development, which has a heavy impact on the roll-out of a solution. In systems I’ve worked on, often quality assurance was a third of the cost and time associated with our solutions.

The public discussion does represent the risk of helping the hackers to discover flaws. However, the battle assumes an equal playing field. Like drug wars and porn, the resources are unevenly matched. The amount of money for attacking the intended goals (peace and love) outweighs the monies distributed for the public good.

Likewise the public discussion of the SCADA systems requires an acceptance on the private industries’ part that the way to protect vulnerabilities is not to keep to itself. Here are the 21 steps recommended by the DoE:

1. Identify all connections to SCADA networks.

2. Disconnect unnecessary connections to the SCADA network.

3. Evaluate and strengthen the security of any remaining connections to the SCADA network.

4. Harden SCADA networks by removing or disabling unnecessary services.

5. Do not rely on proprietary protocols to protect your system.

6. Implement the security features provided by device and system vendors.

7. Establish strong controls over any medium that is used as a backdoor into the SCADA network.

8. Implement internal and external intrusion detection systems and establish 24-hour-a-day incident monitoring.

9. Perform technical audits of SCADA devices and networks, and any other connected networks to identify security concerns.

10. Conduct physical security surveys and assess all remote sites connected to the SCADA network to evaluate their security.

11. Establish SCADA “Red Teams” to identify and evaluate possible attack scenarios.

12. Clearly define cyber security roles, responsibilities, and authorities for managers, system administrators, and users,

13. Document network architecture and identify systems that serve critical functions or contain sensitive information that require additional levels of protection.

14. Establish a rigorous, ongoing risk management process.

15. Establish a network protection strategy based on the principle of defense-in-depth.

16. Clearly identify cyber security requirements.

17. Establish effective configuration management processes.

18. Conduct routine self-assessments.

19. Establish system backups and disaster recovery plans.

20. Senior organizational leadership should establish expectations for cyber security performance and hold individuals accountable for their performance.

21. Establish policies and conduct training to minimize the likelihood that organizational personnel will inadvertently disclose sensitive information regarding SCADA system design, operations, or security controls.

I am not sure how far along the industry is in the assessment phase, and I doubt that “Red Teams” have truly laid out all the possibilities from disaster to malfunction. However, keeping quiet about a problem does not work.