US to tighten nuclear cyber security (voluntarily)
A post in The Register discusses a Draft Regulatory Guide for operators of nuclear reactors by the US Nuclear Regulatory Commission. Excerpts from their discussion:
Federal regulators are proposing to add computer security standards to their criteria for installing new computerized safety systems in nuclear power plants. The US Nuclear Regulatory Commission (NRC) quietly launched a public comment period late last month on a proposed 15-page update to its regulatory guide "Criteria for Use of Computers in Safety Systems of Nuclear Power Plants." The current version, written in 1996, is three pages long and makes no mention of security.
The replacement would expand existing safety and reliability requirements for digital safety system, and infuse security requirements into every stage of a system's lifecycle, from drawing board to retirement.
No successful targeted attacks against plants have been publicly reported, but in 2001 the Slammer worm penetrated a private computer network at Ohio's idled Davis-Besse nuclear plant and disabled a safety monitoring system for nearly five hours. The worm entered the plant network through an interconnected contractor's network, bypassing Davis-Besse's firewall. The NRC draft advises against such interconnections. It also advises plant operators to consider the effect of each new system on the plant's cyber security, and to develop response plans to deal with computer incidents. Vendors are told how to reduce the risk of saboteurs planting backdoors and logic bombs in safety system software during the development phase.
But for all its breadth, adherence to the new guidelines would be strictly voluntary for operators of the 103 nuclear reactors already running in the US - a detail that irks some security experts... "It's kind of sad," [Chris Wysopal] says. "I see that people have all these great notions of how we can build software and systems more securely, but it's always voluntary."
Excerpts from the report itself:
Regulatory guides are not substitutes for regulations, and compliance with regulatory guides is not required.
With respect to software diversity, experience indicates that independence of failure modes may not be achieved in cases where multiple versions of software are developed from the same software requirements.
Computer-based systems must be secure from electronic vulnerabilities, as well as from physical vulnerabilities, which have been well addressed.
The lifecycle phase-specific security requirements should be commensurate with the risk and magnitude of the harm resulting from unauthorized access, use, disclosure, disruption, or destruction of the digital safety systems.
Remote access to the safety system software functions or data from outside the technical environment of the plant ... that involves a potential security threat to safety functions should not be implemented.
[This suggests that putting the SCADA system on the Internet is a bad idea, but doesn't actually condemn it.]
The security requirements are part of the overall system requirements.
The developer should delineate its security policies to ensure the developed products (hardware and software) do not contain undocumented code (e.g., back door coding), malicious code (e.g., intrusions, viruses, worms, Trojan horses, or bomb codes), and other unwanted and undocumented functions or applications.
[No guidance on how this is actually to be done.]
The user should develop an incident response and recovery plan for responding to digital system security incidents (e.g., intrusions, viruses, worms, Torjan horses, or bomb codes). The plan should be developed to address various loss scenarios and undesirable operations of plant digital systems, including possible interruptions in service due to the loss of system resources, data, facility, staff, and/or infrastructure. The plan should define contingencies for ensuring minimal disruption to critical services in these instances.
The user should perform periodic computer system security self-assessments and audits.
No backfitting is intended or approved in connection with the issuance of this guide... The use of this revision by the licensees of currently operating nuclear power plants is entirely voluntary.
Federal regulators are proposing to add computer security standards to their criteria for installing new computerized safety systems in nuclear power plants. The US Nuclear Regulatory Commission (NRC) quietly launched a public comment period late last month on a proposed 15-page update to its regulatory guide "Criteria for Use of Computers in Safety Systems of Nuclear Power Plants." The current version, written in 1996, is three pages long and makes no mention of security.
The replacement would expand existing safety and reliability requirements for digital safety system, and infuse security requirements into every stage of a system's lifecycle, from drawing board to retirement.
No successful targeted attacks against plants have been publicly reported, but in 2001 the Slammer worm penetrated a private computer network at Ohio's idled Davis-Besse nuclear plant and disabled a safety monitoring system for nearly five hours. The worm entered the plant network through an interconnected contractor's network, bypassing Davis-Besse's firewall. The NRC draft advises against such interconnections. It also advises plant operators to consider the effect of each new system on the plant's cyber security, and to develop response plans to deal with computer incidents. Vendors are told how to reduce the risk of saboteurs planting backdoors and logic bombs in safety system software during the development phase.
But for all its breadth, adherence to the new guidelines would be strictly voluntary for operators of the 103 nuclear reactors already running in the US - a detail that irks some security experts... "It's kind of sad," [Chris Wysopal] says. "I see that people have all these great notions of how we can build software and systems more securely, but it's always voluntary."
Excerpts from the report itself:
Regulatory guides are not substitutes for regulations, and compliance with regulatory guides is not required.
With respect to software diversity, experience indicates that independence of failure modes may not be achieved in cases where multiple versions of software are developed from the same software requirements.
Computer-based systems must be secure from electronic vulnerabilities, as well as from physical vulnerabilities, which have been well addressed.
The lifecycle phase-specific security requirements should be commensurate with the risk and magnitude of the harm resulting from unauthorized access, use, disclosure, disruption, or destruction of the digital safety systems.
Remote access to the safety system software functions or data from outside the technical environment of the plant ... that involves a potential security threat to safety functions should not be implemented.
[This suggests that putting the SCADA system on the Internet is a bad idea, but doesn't actually condemn it.]
The security requirements are part of the overall system requirements.
The developer should delineate its security policies to ensure the developed products (hardware and software) do not contain undocumented code (e.g., back door coding), malicious code (e.g., intrusions, viruses, worms, Trojan horses, or bomb codes), and other unwanted and undocumented functions or applications.
[No guidance on how this is actually to be done.]
The user should develop an incident response and recovery plan for responding to digital system security incidents (e.g., intrusions, viruses, worms, Torjan horses, or bomb codes). The plan should be developed to address various loss scenarios and undesirable operations of plant digital systems, including possible interruptions in service due to the loss of system resources, data, facility, staff, and/or infrastructure. The plan should define contingencies for ensuring minimal disruption to critical services in these instances.
The user should perform periodic computer system security self-assessments and audits.
No backfitting is intended or approved in connection with the issuance of this guide... The use of this revision by the licensees of currently operating nuclear power plants is entirely voluntary.
posted by Jim Horning at 11:56 AM
0 Comments:
Post a Comment
<< NIASAWHIWB Home