Bill’s Security Blog

ControlGlobal recently posted an article, “Advances Needed in Control System Cyber Security” discussing the Control System Security Program (CSSP).

Quoting:

CSSP has produced some significant risk reduction products, including a cyber security self-assessment tool, a detailed cyber security procurement language for control systems, a pocket guide to securing SCADA and control systems, and a set of recommended practices. CSSP has also set up a group within US-CERT to produce control-systems- related vulnerability notices, and CSSP teaches control systems security awareness and mitigation training classes. All of this information is available at http://www.US-CERT.gov/control_systems.

One of the most important initiatives CSSP has undertaken, Hoffman revealed, is the technology assessments they do under contract, and with nondisclosure agreements, for control systems vendors. “Basically, we get the hardware and the control systems engineers from the vendor, and we build a system and get it ready. Then our “Red Team”—that’s the attackers—get six weeks to invade and take control of the system.

“In four years of doing this,” Hoffman said, “we have never been stopped from gaining full operational control over the control systems.”

Now that’s what I’m talking about.

If industry can engage this kind of effort, I think they will be able to avoid ugly regulatory requirements that, IMHO, will generally be reactionary and low value.

From the looks of the CSSP, they are doing some really good things in control system security from a standards development and best-practices establishment perspective.

I’m an IT security guy, not a control systems security guy.

I hear a lot of complaining from the control system side that the IT guys don’t understand the complexities of control systems.

I’ll agree that there’s a lot I don’t know about control systems, but I also believe there’s a lot that the control system community doesn’t know about IT security.

But we can both learn from each other.

One aspect I think the IT security can bring is that, in general, IT security systems are constantly under attack, and we’ve had to embrace certain principles in order to achieve a degree of success.

Good IT security embodies the principles of:

• Secure by design
• Secure by default
• Defense in depth
• Constant monitoring and improvement the security posture

Though the same “technical security controls” I use in a corporate network may not work in the control system space, the fundamental principles can drive a good security practice.

Bill

Joe Weiss is a big fan of strong regulation to help improve critical infrastructure security in the US.

I agree that sweeping regulation can be a benefit in certain situations.  For example:

1. When there’s a need to make a large cultural shift
2. When there’s a need for consistency across a sector
3. Safety reasons

Now, I’m not as plugged in as Weiss is, and I’m not sure the scope of the NERC CIP’s or the history of regulatory work coming out of NERC and FERC, but I do have a fundamental belief that Federal agencies do few thigs well.

I believe that good Federal regulation should be:

• Performance based
• Easily verified
• Consistent

Regulation must be performance based, rather than solution specific.

As Joe pointed out, a checklist isn’t going to motivate a significant change.  The result will be to do only what is necessary to meet the items on the checklist.

If consistently improving security is what is desired, then the basis of the regulation must be performance based.

As an example, “the control network should not be impacted by events on the business network.”

Regulation should not be created in a moment of panic.  We all see the kinds of things that come out of panic… Think, TSA :(

Regulation should also be verifiable.

There must be a consistent way to measure compliance with a regulation.

For example, “compliance can be verified by ensuring the control network can withstand a targeted attack by a knowledgeable adversary.”

Regulation should be consistent.

There are two branches here.  Obviously, regulations should not create a situation where compliance with one places you out of compliance with another.

But more importantly, regulations should be consistent across sectors.

For example, there should be a set of regulations that cover power production or the energy sector at large.

Though there is institutional reasons why this would be hard to achieve (think NERC v NRC), there are substantial benefits to having a consistent set of regulation.

There are many power producers that own both Nuclear and fossil based power facilities.

A consistent regulatory body gives them to optimize their processes, procedures, and project pipelines.

Each production type that has unique characteristics can be supported by additional regulation.

Bill

This past week I was listening to the Digital Bond podcast for July, 2008.

One of the topics was whether or not the Hatch Nuclear Power Plant incident constitutes a cyber security incident.

About the Hatch incident:

The computer in question was used to monitor chemical and diagnostic data from one of the facility’s primary control systems, and the software update was designed to synchronize data on both systems. According to a report filed with the Nuclear Regulatory Commission, when the updated computer rebooted, it reset the data on the control system, causing safety systems to errantly interpret the lack of data as a drop in water reservoirs that cool the plant’s radioactive nuclear fuel rods. As a result, automated safety systems at the plant triggered a shutdown.

Southern Company spokeswoman Carrie Phillips said the nuclear plant’s emergency systems performed as designed, and that at no time did the malfunction endanger the security or safety of the nuclear facility.

Phillips explained that company technicians were aware that there was full two-way communication between certain computers on the plant’s corporate and control networks. But she said the engineer who installed the update was not aware that that the software was designed to synchronize data between machines on both networks, or that a reboot in the business system computer would force a similar reset in the control system machine.

Washington Post.com

The guests on the podcast seemed to be making sometimes contradictory arguments of why the incident was not a cyber security incident.

Arguments included whether or not participant had malicious intent, or whether or not any ‘real’ damage was caused.

I suspect that if you are in a regulated space where an event that is considered “cyber security” carries significant regulatory implication, then you would be motivated to call an event anything but a cyber security event.

But lets back up a second.

Information security seeks to ensure the confidentiality, availability, and integrity of information.

If an event affects either of those three, then it is a breach of information security.

If, when we refer to cyber security, we are really talking about digital information and information system security, does that somehow preclude the provision of confidentiality, availability, or integrity?

I think not.

Indeed, I think a proper definition of cyber security is the assurance of confidentiality, availability, and integrity of digital information and information systems.

The Hatch incident was a cyber security event by definition.

Let’s not try to confuse this stuff, it’s already hard enough.

Bill