The Browns Ferry incident

The reactor of an Alabama Nuclear Power Plant, Browns Ferry, Unit 3, was shutdown on August 19, 2006 as a result of a failure of a device, a special type of PLC. Whats interesting with this shutdown, is that the report of the incident actually pinpoint IT related errors, i.e. network overload, as the root cause. The report state that there was an Ethernet network installed that was to blame. This is the really, really interesting part. In a Nuclear plant, there should not be a design or implementation that could fail like this.

The incident log here and a full report from the Nuclear Regulatory Commission, NRC is available here.

As a result of this incident, the Committee on Homeland Security Committee Chairman Bennie G. Thompson (D-MS) and Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology Chairman James R. Langevin (D-RI) sent a letter to Dale E. Klein, Chairman of the U.S. Nuclear Regulatory Commission regarding the Cybersecurity at the nation’s nuclear power plants. One interesting excerpt of the letter is the following:

We have deep reservations about the NRC’s hesitation to conduct a special investigation into this incident. First, although NRC regulations only specify cyber requirements for safety systems, it is clear from the Notice that the disruption of a non-safety system can impact a plant’s safety systems. The manual scram by the operators was the only reason that the excessive network traffic in this incident did not trigger a scram by the plant’s safety systems. It is clear, therefore, that a nuclear plant’s safety systems are directly impacted by the security of its non-safety systems; a weakness or vulnerability in the non-safety network can disrupt operations and trigger a safety system shutdown.

The letter ends with seven important cybersecurity questions that the Comittee require the NRC is answering.

The details on this incident is still very scarce, with lot of interpretations by different journalists, experts, and others. We'll probably see over time what really was the source of the problem. The SCADA security bloggers at DigitalBond have several more interesting comments on the incident.