5 ms·

If a virus can cause accident that releases radiation, it's not a computer safety problem, it's a failure in nuclear plant automation design. Modern nuclear

If a virus can cause accident that releases radiation, it's not a computer safety problem, it's a failure in nuclear plant automation design. Modern nuclear plant's usually have analog monitoring and safety system's parallel to digitized control in critical parts like neutron flux measurement and calibration, fuel loading monitoring, control rod position indicator, control rod actuators, .... Any error caused by virus attempting sabotage the plant should result shutdown. You can divide the system into 1) process automation 2) limiting systems and 3) Protection systems. Process automation can be fully digitized and computerized. If it fails or computer virus attempts to sabotage the system, it should not cause critical conditions because limiting systems have diversified digital and analog control systems that limit given parameters. If that fails independent protections systems trigger shutdown if those same parameters are exceeded. Another way to divide the safety is four principles: 1) parallel principle: parallel subsystems 2) separation principle: parallel subsystems are placed so that simultaneous damage to all of them is very unlikely. 3) diversity principle: same function is implemented with different operating principles. The same valve can be operated using electric motor, compressed air, or manually. 4) safe-state principle: system failing falls back to the safe state

roywiggins 8y ago
A shutdown is still a denial of service attack, which might be bad enough on its own. How well can the grid compensate for one or several plants suddenly dropping offline? We know cascading grid failures can happen. But, I guess the risks there are about the same for a nuclear plant as they would be for a computerized non-nuclear plant.
- topspin 8y ago
  > How well can the grid compensate for one or several plants suddenly dropping offline? One? Pretty well usually. Reactor trips are common enough that the grid is designed to handle it. If multiple reactors shut down simultaneously the loss of supply could exceed available margins and disrupt service. Here is the most recent (June 6th, BRAIDWOOD) full power trip reported in the US: https://www.nrc.gov/reading-rm/doc-collections/event-status/event/2018/20180605en.html https://www.nrc.gov/reading-rm/doc-collections/event-status/... There was another last week but it was only from 2% power at the time. We see a couple every month and few ever notice.
- Nokinside 8y ago
  This is a unique new category for networked digital automation that is absent from other systems. I don't think computer security people take it seriously enough. Say, you sabotage "dumb" automation system to break and turn the car suddenly right. When the failures starts to happen, manufacturer eventually notices it and recalls vehicles. Maybe tens or hundreds of people will be injured. But what if the system has access to date and time trough CAN bus? If design a system that steers all affected cars suddenly right at the same time the cascade can kill and injure thousands and cause huge panic. People are afraid to drive until the problem is fixed.
  - nickpsecurity 8y ago
    High-assurance security has been pushing separation kernels to solve that kind of problem for a long time. Vendors even list automotive in their Solutions menus. Two got evaluated by NSA for security. I think NSA cancelled that protection profile because the hardware and firmware were having too many leaks to find a software solution believable. The boards aimed at that market are also increasingly complex. However, the separation kernels and virtualization platforms were the strongest thing produced for this goal with some still available. Here's a good explanation of default, architectural style used in high-assurance security from a team that FOSS's a lot of their prototypes: https://os.inf.tu-dresden.de/papers_ps/nizza.pdf https://os.inf.tu-dresden.de/papers_ps/nizza.pdf Here's a commercial one used in an automotive platform that got certified to high assurance at EAL6+: https://www.ghs.com/products/safety_critical/integrity-do-178b.html https://www.ghs.com/products/safety_critical/integrity-do-17... I'm not endorsing the [closed-source] product so much as the methods it claimed to use to get the job done. Look at the architecture, minimalist runtimes (esp for Ada), determinism, partitioning, and certification data on bottom-right. That last part hints at the kinds of things they have to do and get reviewed for the certification. If a developer claims to do security, ask to see the Covert, Channel Analysis of their product. That certification requirement/activity is how cache-based, timing channels were discovered in 1992 by VAX Security Kernel team among other leaks. Covert and side channels are getting popular again but most still don't apply storage/timing analysis. You'll find that most developers and "security professionals" don't build secure stuff using methods proven to work in the past. Companies building tech like this sell it for high price since there's so few buyers. The networking-oriented ones started at $50,000 when I priced them. You can bet the big companies whose products are getting hit could've afforded them, though. Especially the royalty-free options.
- fulafel 8y ago
  A plant dropping offline is still a relatively friendly and controlled event. In a malicious case you could imagine a plant acting in a maximally adverserial way to the grid's direction.
fulafel 8y ago
Do you have a reference to sources or requirements documents saying that the plants must tolerate a malicious actor in control of the computerized parts of a plant, control rooms and supporting infrastructue? This sounds like quite a hard problem to solve. Safety, meaning defense against accidental events, is in some respects much easier than defense against malicious events. Diversity and redundancy for example are much less effective: failure comes, not from a coincidence of two very unlikely failures, but from the adversary just successfully attacking an additional subsystem in a workflow of several attacks.
- Nokinside 8y ago
  Diversity and parallel principles are more general than cybersecurity. If these the design is properly implemented, complete failure in one subsystem (even intentional) is not going to cause a catastrophe. All the attacker can do is to trigger controlled shutdown from analog subsystems. Different countries have different safety requirements for nuclear power plants, all plants are not necessarily equally secure. Safety is expensive to implement and manufacturers provide different choices.
  - fulafel 8y ago
    I'm sure we agree but a caveat like "if properly implemented" is quite a big one to make in this business - bad stuff happens largely because of implementation bugs. And we don't know how to eliminate implementation bugs. And this is one reason why we see successful attacks on systems with multiple "sound if properly implemented" levels of security.
    - adrianN 8y ago
      We know how to eliminate almost all implementation bugs. I hope nuclear power plants are one of the areas where people are willing to pay for that level of correctness.
    - moring 8y ago
      I remember reading elsewhere that bad stuff happens largely because of incomplete or conflicting requirements, and that implementation bugs are secondary. My own experience confirms this, even though I usually deal with systems where a problem at worst results in lost sales / orders and thus sloppy coding and implementation bugs are much more common. Makes me wonder how well-polished the requirements analysis for (nuclear) power plant software is...
blablabla123 8y ago
It's nice that they have all these principles. And they are not only there for digital systems but literally anything created by engineers in the Nuclear Power Plants. Still there have been accidents. Paradoxically Chernobyl was caused by human fault by the Operators. Possibly it might not have happened if there had been digital systems in place for direct control of the nuclear processes. IMHO Nuclear technology is inherently insecure and every attempt to make it "secure" is just a hack. I mean if you just compare what best practices there are in security, like openness especially when it comes to incidents. So many incidents came out through detours and sometimes only after years.
- cjslep 8y ago
  > I mean if you just compare what best practices there are in security, like openness especially when it comes to incidents. So many incidents came out through detours and sometimes only after years. You're going to have to be specific about claims like this, because this comes across as FUD in the US given the stringent transparency requirements the NRC holds licensees accountable. To see current events: https://www.nrc.gov/reading-rm/doc-collections/event-status/event/en.html https://www.nrc.gov/reading-rm/doc-collections/event-status/... Edit: Also your argument about the failure of Chernobyl is not compelling as you provide no evidence of how the existing analog systems failed in a way that digital systems would not leading to an an aversion of the accident. It is generally accepted that it was a combination of [lack of] system redundancy (analog or digital does not matter), inherent risk with the beta reactor design coefficient, and poor operator understanding of the neutron poison buildup from the low power excursion.
  - blablabla123 8y ago
    Chernobyl was discovered through measurements by western states, not by disclosure. In fact worse happened for accidents that happened in the west. Even in the recent years, just read about them, no need to reference. It's not "my argument" but you can read it for instance on Wikipedia. I'm aware that the official requirements are stringent but that means not much I'm afraid.
erentz 8y ago
Back during SQL Slammer (IIRC) I was working in security and subsequently SCADA security for critical infrastructure. There was a well known story about a nuclear plant in the US that had its network taken down by the worm. The problem was they had become so reliant on automation that only had two operators on duty, not nearly enough. The lesson too often ignored I quickly found all over in the critical infrastructure space was, yes, the software is terribly insecure, but more critically when all is well organizations develop an overreliance on automation always going well meaning they’re under equipped for when it stops going well.
- archgoon 8y ago
  Is this the incident? https://www.securityfocus.com/news/6767 https://www.securityfocus.com/news/6767 'The Slammer worm penetrated a private computer network at Ohio's Davis-Besse nuclear power plant in January and disabled a safety monitoring system for nearly five hours, despite a belief by plant personnel that the network was protected by a firewall, SecurityFocus has learned. The breach did not pose a safety hazard. The troubled plant had been offline since February, 2002, when workers discovered a 6-by-5-inch hole in the plant's reactor head. Moreover, the monitoring system, called a Safety Parameter Display System, had a redundant analog backup that was unaffected by the worm. But at least one expert says the case illustrates a growing cybersecurity problem in the nuclear power industry, where interconnection between plant and corporate networks is becoming more common, and is permitted by federal safety regulations.' Sounds like the plant was being operated by a skeleton crew since it was mostly disabled.
  - erentz 8y ago
    That could be it but that sounds much less concerning than how the guy at INL who was telling me about it described it. He may have enhanced the story. :-)

roywiggins 8y ago

A shutdown is still a denial of service attack, which might be bad enough on its own. How well can the grid compensate for one or several plants suddenly dropping offline? We know cascading grid failures can happen. But, I guess the risks there are about the same for a nuclear plant as they would be for a computerized non-nuclear plant.

topspin 8y ago
> How well can the grid compensate for one or several plants suddenly dropping offline? One? Pretty well usually. Reactor trips are common enough that the grid is designed to handle it. If multiple reactors shut down simultaneously the loss of supply could exceed available margins and disrupt service. Here is the most recent (June 6th, BRAIDWOOD) full power trip reported in the US: https://www.nrc.gov/reading-rm/doc-collections/event-status/event/2018/20180605en.html https://www.nrc.gov/reading-rm/doc-collections/event-status/... There was another last week but it was only from 2% power at the time. We see a couple every month and few ever notice.
Nokinside 8y ago
This is a unique new category for networked digital automation that is absent from other systems. I don't think computer security people take it seriously enough. Say, you sabotage "dumb" automation system to break and turn the car suddenly right. When the failures starts to happen, manufacturer eventually notices it and recalls vehicles. Maybe tens or hundreds of people will be injured. But what if the system has access to date and time trough CAN bus? If design a system that steers all affected cars suddenly right at the same time the cascade can kill and injure thousands and cause huge panic. People are afraid to drive until the problem is fixed.
- nickpsecurity 8y ago
  High-assurance security has been pushing separation kernels to solve that kind of problem for a long time. Vendors even list automotive in their Solutions menus. Two got evaluated by NSA for security. I think NSA cancelled that protection profile because the hardware and firmware were having too many leaks to find a software solution believable. The boards aimed at that market are also increasingly complex. However, the separation kernels and virtualization platforms were the strongest thing produced for this goal with some still available. Here's a good explanation of default, architectural style used in high-assurance security from a team that FOSS's a lot of their prototypes: https://os.inf.tu-dresden.de/papers_ps/nizza.pdf https://os.inf.tu-dresden.de/papers_ps/nizza.pdf Here's a commercial one used in an automotive platform that got certified to high assurance at EAL6+: https://www.ghs.com/products/safety_critical/integrity-do-178b.html https://www.ghs.com/products/safety_critical/integrity-do-17... I'm not endorsing the [closed-source] product so much as the methods it claimed to use to get the job done. Look at the architecture, minimalist runtimes (esp for Ada), determinism, partitioning, and certification data on bottom-right. That last part hints at the kinds of things they have to do and get reviewed for the certification. If a developer claims to do security, ask to see the Covert, Channel Analysis of their product. That certification requirement/activity is how cache-based, timing channels were discovered in 1992 by VAX Security Kernel team among other leaks. Covert and side channels are getting popular again but most still don't apply storage/timing analysis. You'll find that most developers and "security professionals" don't build secure stuff using methods proven to work in the past. Companies building tech like this sell it for high price since there's so few buyers. The networking-oriented ones started at $50,000 when I priced them. You can bet the big companies whose products are getting hit could've afforded them, though. Especially the royalty-free options.
fulafel 8y ago
A plant dropping offline is still a relatively friendly and controlled event. In a malicious case you could imagine a plant acting in a maximally adverserial way to the grid's direction.

fulafel 8y ago

Do you have a reference to sources or requirements documents saying that the plants must tolerate a malicious actor in control of the computerized parts of a plant, control rooms and supporting infrastructue? This sounds like quite a hard problem to solve. Safety, meaning defense against accidental events, is in some respects much easier than defense against malicious events. Diversity and redundancy for example are much less effective: failure comes, not from a coincidence of two very unlikely failures, but from the adversary just successfully attacking an additional subsystem in a workflow of several attacks.

Nokinside 8y ago
Diversity and parallel principles are more general than cybersecurity. If these the design is properly implemented, complete failure in one subsystem (even intentional) is not going to cause a catastrophe. All the attacker can do is to trigger controlled shutdown from analog subsystems. Different countries have different safety requirements for nuclear power plants, all plants are not necessarily equally secure. Safety is expensive to implement and manufacturers provide different choices.
- fulafel 8y ago
  I'm sure we agree but a caveat like "if properly implemented" is quite a big one to make in this business - bad stuff happens largely because of implementation bugs. And we don't know how to eliminate implementation bugs. And this is one reason why we see successful attacks on systems with multiple "sound if properly implemented" levels of security.
  - adrianN 8y ago
    We know how to eliminate almost all implementation bugs. I hope nuclear power plants are one of the areas where people are willing to pay for that level of correctness.
  - moring 8y ago
    I remember reading elsewhere that bad stuff happens largely because of incomplete or conflicting requirements, and that implementation bugs are secondary. My own experience confirms this, even though I usually deal with systems where a problem at worst results in lost sales / orders and thus sloppy coding and implementation bugs are much more common. Makes me wonder how well-polished the requirements analysis for (nuclear) power plant software is...

blablabla123 8y ago

It's nice that they have all these principles. And they are not only there for digital systems but literally anything created by engineers in the Nuclear Power Plants. Still there have been accidents. Paradoxically Chernobyl was caused by human fault by the Operators. Possibly it might not have happened if there had been digital systems in place for direct control of the nuclear processes. IMHO Nuclear technology is inherently insecure and every attempt to make it "secure" is just a hack. I mean if you just compare what best practices there are in security, like openness especially when it comes to incidents. So many incidents came out through detours and sometimes only after years.

cjslep 8y ago
> I mean if you just compare what best practices there are in security, like openness especially when it comes to incidents. So many incidents came out through detours and sometimes only after years. You're going to have to be specific about claims like this, because this comes across as FUD in the US given the stringent transparency requirements the NRC holds licensees accountable. To see current events: https://www.nrc.gov/reading-rm/doc-collections/event-status/event/en.html https://www.nrc.gov/reading-rm/doc-collections/event-status/... Edit: Also your argument about the failure of Chernobyl is not compelling as you provide no evidence of how the existing analog systems failed in a way that digital systems would not leading to an an aversion of the accident. It is generally accepted that it was a combination of [lack of] system redundancy (analog or digital does not matter), inherent risk with the beta reactor design coefficient, and poor operator understanding of the neutron poison buildup from the low power excursion.
- blablabla123 8y ago
  Chernobyl was discovered through measurements by western states, not by disclosure. In fact worse happened for accidents that happened in the west. Even in the recent years, just read about them, no need to reference. It's not "my argument" but you can read it for instance on Wikipedia. I'm aware that the official requirements are stringent but that means not much I'm afraid.

erentz 8y ago

Back during SQL Slammer (IIRC) I was working in security and subsequently SCADA security for critical infrastructure. There was a well known story about a nuclear plant in the US that had its network taken down by the worm. The problem was they had become so reliant on automation that only had two operators on duty, not nearly enough. The lesson too often ignored I quickly found all over in the critical infrastructure space was, yes, the software is terribly insecure, but more critically when all is well organizations develop an overreliance on automation always going well meaning they’re under equipped for when it stops going well.

archgoon 8y ago
Is this the incident? https://www.securityfocus.com/news/6767 https://www.securityfocus.com/news/6767 'The Slammer worm penetrated a private computer network at Ohio's Davis-Besse nuclear power plant in January and disabled a safety monitoring system for nearly five hours, despite a belief by plant personnel that the network was protected by a firewall, SecurityFocus has learned. The breach did not pose a safety hazard. The troubled plant had been offline since February, 2002, when workers discovered a 6-by-5-inch hole in the plant's reactor head. Moreover, the monitoring system, called a Safety Parameter Display System, had a redundant analog backup that was unaffected by the worm. But at least one expert says the case illustrates a growing cybersecurity problem in the nuclear power industry, where interconnection between plant and corporate networks is becoming more common, and is permitted by federal safety regulations.' Sounds like the plant was being operated by a skeleton crew since it was mostly disabled.
- erentz 8y ago
  That could be it but that sounds much less concerning than how the guy at INL who was telling me about it described it. He may have enhanced the story. :-)