No CIO Is an Island

The most important networks any organization has are the networks of its people, says Professor Eugene Clarke, Dean of Law, Business and Arts with the University of Canberra. Since a CIO alone cannot do the job of protecting infrastructure, he or she must work in cooperation with the legal team, business managers and others to develop a culture of protection.

"At the end of the day what we all tend to ignore in threats of this type are the human factors. In a way the lawyer, the risk manager, the IT possessor - that is, the CIO - but also other people in the organization all have their part of that network and they need to buy in to the same values.

"They're on the ground and are aware often of many of the problems, many of which - and the most serious ones of which - may not be technical, but may be on the human side. For that reason we have more than ever before a need to share, and a need to understand enough about the other person's discipline that we can work together to put together this human network, if you will, of protection."

Yet Clarke says an e-Frontiers study fostered by St Paul's Insurance found most organizations did not even have a committee to identify the risk. Most CEOs felt they were not as aware as they should be, and most tended to focus on identifying the technical risks and failed to appreciate sufficiently the human risk element. Worse, what worked so brilliantly in resolving Y2K problems - putting the risks in a multi-disciplinary manner on everybody's agenda, making it part of staff development, and keeping the issue at the forefront of meetings - has not been adopted to address CIP vulnerabilities.

"Sadly the study found that now that Y2K is over we've lost the importance of putting that on the agenda constantly in an inter-disciplinary way. So now people are putting off reviews, and they're saying: 'Oh well, we'll keep the technology for a little bit longer'," he says.

All CIOs in all organizations should be asking themselves whether such failures might not prove disastrous if (or when) their luck ever runs out.

The National Institute of Standards and Technology (NIST) fostered the creation of the Process Control Security Requirements Forum in 2001. The group issued the first draft of its System Protection Profile for Industrial Control Systems (SPP ICS) in October. For a copy, go to: www.isd.mel.nist.gov/projects/processcontrol/SPP-ICSv1.0.doc.

SIDEBAR: How to Meet the Security Challenge

SCADA systems have long been regarded as operating in a secure environment because of their closed network, which isn't exposed to external entities. Also, the communication protocols employed were primarily proprietary and not commonly published. This "security by secrecy" approach has led to a false sense of security that doesn't stand up to the test of an audit.

Furthermore, the notion that SCADA networks are closed systems is no longer true. Recent advances, such as Web-based reporting and remote operator access, have driven the requirement to interface with the Internet. This opens up physical access over the public network and subjects SCADA systems to the same potential malicious threats as those corporate networks face on a regular basis.

Typically, compliance with industry standards and technologies is regarded as a good thing. However, in the case of newer SCADA systems, recent adoption of commonly used operating systems and standards make for a more vulnerable target. Newer SCADA systems have begun to use operating systems such as Windows or Unix variants that are commonplace in corporate networks. While this move offers benefits, it also makes SCADA systems susceptible to numerous attacks related to these operating systems. SCADA systems also face patch management challenges as vulnerabilities for these operating systems are uncovered.

Securing SCADA

Against the backdrop of these emerging threats, security managers at institutions that use SCADA are beginning to address the challenges involved in securing these systems. Much of what needs to be done is simply implementing sound information-security practices. Here are a few key initiatives to address lingering security issues:

Secure network communications: Implement strong encryption over the SCADA network communications, ensuring that both monitored data and control commands are encrypted.

Turn on security: Implement security features with devices on your network, especially authentication. Use secure protocols whenever possible.

Know your SCADA network: Identify all connections to external networks including wireless networks, corporate LANs and WANs, and the Internet. Further secure your network by eliminating all unnecessary connections to external networks.

Harden your SCADA environment: Remove all unnecessary services from the hosts on your network. Also, just as you would in your corporate network environment, ensure that all systems are patched and up to date.

Conduct regular security audits: Ensure that security practices and procedures, such as incident response, are defined and implemented. Penetration testing of the network environment should also be prudently conducted with inspection for potential back doors into the SCADA network.

Implement real-time threat protection: With the increasing number and complexity of attacks, it's insufficient to simply patch your systems or maintain access/service control. One alternative is to implement real-time threat protection in the form of network intrusion-prevention systems. Unlike standard packet-filter firewalls, these systems perform application-layer inspection to identify attacks that are carried in the payload and block the offending traffic in real time.