Cyber Security question about Safety PLC programs

thingstodo

Member
Join Date
Feb 2012
Location
Saskatoon
Posts
533
Hi all,

Searching the site, this is the newest/closest to my question thread I found on safety PLCs, editing the safety task, etc:
http://www.plctalk.net/qanda/showthread.php?t=112897

It does not quite answer the question that our IT/Cyber security auditor would like answered. I have expanded on the questions just a bit given the info from the above thread:

Given that someone:
- gets through our firewall
- takes over one of our Programming VMs that is running the right rockwell software, at the correct versions, to edit our Safety PLC (L81ES)
- manages to get validated from the Rockwell license server
- logs into the safety PLC
- maliciously edits the safety portion of the controller code ....

* does the PLC have to go to program mode to get the logic changes to execute

* if changes are made to the safety program(s) but no new safety signature is created, what happens when the PLC is power cycled the next time. Does it keep running the 'old' code, or run the 'new' code, or just sit there because there is no safety signature?

I have read through portions of several manuals, but this appears to be a bit too detailed for the manuals to cover.
Perhaps it is a bit too esoteric for youtube videos to cover, since they cover creating your first safety program well, but not much about editing.

I'd just try it myself, but there is only 1 safety controller on site and our spare is at a contractor site being used for off-site development.
 
This depends on how you have the safety controller configured.
There are quite a few options available to you.
1. FactoryTalk Security
2. Ensure that the controller has a Safety Signature configured for it
3. Configure controller with 'Protect Signature in Run Mode' enabled, so that the safety signature can only be cleared by putting controller into Program Mode.
4. Have Safety Application 'Locked' (this is separate from Safety Signature and uses a password)
5. Consider putting controller into Key Switch 'RUN' mode (and access controlling physical key switch)
6. Implement Change Detection in your HMI application, so any change to the safety application will generate an Alarm on your HMI and require an explicit reconfiguration of the HMI value to remove the alarms/warning indications.

An attacker will not typically use your Rockwell software to make the change. If they can breach your firewall, they will typically use their own software (whether Rockwell proprietary or other). This is why things like safety systems should be deep inside the onion. It should not be a single firewall to get to it, it should be at least two firewalls, with different passwords (and ideally different vendors).

If you are considering performing safety changes / implementation, then you should attend a Rockwell (or other) training course. Different regions have different legislation around this, but most modern societies have quite strict legislation about being 'competent' to perform safety implementations.
If you make a mistake, you're on the back-foot of defending your competence. Best you have as many certifications and training courses under your belt such that your competence can't be called into question if things go wrong...
 
For your questions:
* No, it does not need to be put into program mode for such changes. Online Edits are allowed in the safety system (without safety signature) just like in the normal logix system... a safety controller without a safety signature is just a really expensive controllogix.
* Changes made will be immediately reflected in code execution once in either Test or Assembled edits. The executed code will be identical before and after power cycle (unless memory corruption is detected, or an SD / CF card is used and configured to boot from that).

It's the extra things that contribute to the safety.
Verification and validation of all code changes.
Restriction of code changes by the use of safety signature and safety lock.
Direct traceability of current code state (via safety signature) back to test documents and functional design documents.
 
For your questions:
* No, it does not need to be put into program mode for such changes. Online Edits are allowed in the safety system (without safety signature) just like in the normal logix system... a safety controller without a safety signature is just a really expensive controllogix.

The Service Provider that is programming the robot is presently responsible for programming the Safety PLC. It's 'part of their deliverables' .. which is why I am looking for answers from an independent source. I also have a support ticket in with Rockwell asking if additional security can be added.

* Changes made will be immediately reflected in code execution once in either Test or Assembled edits. The executed code will be identical before and after power cycle (unless memory corruption is detected, or an SD / CF card is used and configured to boot from that).

The Safety signature thing is still a bit fuzzy, but I can deal with the description 'an additional level of security'.

It's the extra things that contribute to the safety.
Verification and validation of all code changes.
Restriction of code changes by the use of safety signature and safety lock.
Direct traceability of current code state (via safety signature) back to test documents and functional design documents.

Thanks for the over-view!
 
AWESOME list

This depends on how you have the safety controller configured.
There are quite a few options available to you.

This is QUITE the list! Thanks for putting in the time to write this up

1. FactoryTalk Security

This one is a tough sell to the older programmers. They are understandably worried about getting locked out of their controllers in the unlikely case that the (redundant power supplies on Cisco switch fabric) network is down. That said, we have experienced network downtime where the Admin Domain could not access the Control Domain and we had to walk up to the PLC with a laptop, a USB key for the license, and a USB cable in order to troubleshoot. :(

2. Ensure that the controller has a Safety Signature configured for it

This sounds straight forward to do. I believe it is already implemented.

3. Configure controller with 'Protect Signature in Run Mode' enabled, so that the safety signature can only be cleared by putting controller into Program Mode.

This sounds like an easy implement if it is not already done. I will verify

4. Have Safety Application 'Locked' (this is separate from Safety Signature and uses a password)

I hadn't heard of this one as yet. Or if I had heard of it, I hadn't understood what I heard. Another layer of password is another security layer!

5. Consider putting controller into Key Switch 'RUN' mode (and access controlling physical key switch)

We don't do this with any other PLC on site as it sort of defeats the flexibility of a PLC with remote access. But in this case, it makes complete sense. Not that I had remembered to implement this .. but it will be implemented.

6. Implement Change Detection in your HMI application, so any change to the safety application will generate an Alarm on your HMI and require an explicit reconfiguration of the HMI value to remove the alarms/warning indications.

The HMI is not a Rockwell product. The HMI is an Emerson DeltaV. I'll ask, but I don't believe that this is one of their options.
We do have FT AssetCenter partially implemented. It is logging changes from each of the PLCs. I'm having some issues with AssetCenter Client loading onto the programming VMs so that we get more data on the changelog.

An attacker will not typically use your Rockwell software to make the change.

Interesting. I would have thought that hacking into a windows account on one of the programming VMs would be the easiest way to access the appropriate software set up as it should be. Maybe not. I guess I don't think like a hacker.

If they can breach your firewall, they will typically use their own software (whether Rockwell proprietary or other). This is why things like safety systems should be deep inside the onion. It should not be a single firewall to get to it, it should be at least two firewalls, with different passwords (and ideally different vendors).

Way out of my area .. head office IT has the corporate firewall, there is a local firewall at site, plus some sort of 'jump client/data diode' thing.
There is a VERY STRONG SEP FIELD HERE ... Someone Else's Problem .. and I don't think IT would tell me if I asked. I would just get them very suspicious of WHY I was ASKING.

If you are considering performing safety changes / implementation, then you should attend a Rockwell (or other) training course. Different regions have different legislation around this, but most modern societies have quite strict legislation about being 'competent' to perform safety implementations.

Any safety changes would be made by the Service Provider, or under their direction. The program is so simple that I do not see changes being required after commissioning. Monitoring safety gates to prevent people from entering the zone that the robots can reach. An L81 is SO much overkill for this application .. but it allows the site guys to troubleshoot so I guess the $20K is worth it

If you make a mistake, you're on the back-foot of defending your competence. Best you have as many certifications and training courses under your belt such that your competence can't be called into question if things go wrong...

Thanks for the warning!

AND for your effort getting all of this put together. I appreciate it!
 
The safety signature is best done during the safety commissioning period, which should be staged before the machine functional (non-safety) commissioning period.

The most likely situation is that port 44818 is accidentally exposed to the internet, ala:
https://www.shodan.io/search?query=port:44818+product:"Rockwell+Automation/Allen-Bradley"

You want to put in place enough hurdles so that people will just give up if this ever happens.

Do NOT allow the service provider to install their own 4G/5G modem for remote diagnostics. This is generally how these ports get leaky. Stick with your corporate VPN arrangement and a jump box with the appropriate software on it.

In my safety work, I generally rely upon Safety Signature, not allowing it to change in Run mode, and Safety Lock password.
The Safety Signature aspect is enough to keep me pretty safe liability wise. If the end user has changed the safety code, the safety signature will no longer match what I left (and documented) at commissioning time. Since timestamp impacts safety signature, they can't go back and re-instate the original (unless they download the as-commissioned code.. but then PLC modified time will show they tried to cover tracks)
 
The safety signature is best done during the safety commissioning period, which should be staged before the machine functional (non-safety) commissioning period.

This project is a bit more R&D than most of our projects. The Service Provider is still working out how the vision system will get reliable enough and accurate enough (lighting, vision tools, et al). What worked in their shop has not worked out so well in the field. So requirements->development->commissioning is more of an iterative loop than it should be ...

The most likely situation is that port 44818 is accidentally exposed to the internet, ala:
https://www.shodan.io/search?query=port:44818+product:"Rockwell+Automation/Allen-Bradley"

Thanks for the pointer

Do NOT allow the service provider to install their own 4G/5G modem for remote diagnostics. This is generally how these ports get leaky. Stick with your corporate VPN arrangement and a jump box with the appropriate software on it.

Loud and clear! A cell modem is not an option. Significant time was spent figuring out how remote diagnostics would be done with IT, Cyber security, et al. Sufficient to state that it is slow and painful, suitable for minor issues only. For anything over a coupe of hours it is faster to drive to site than to suffer the various hoops that have to be jumped through.

In my safety work, I generally rely upon Safety Signature, not allowing it to change in Run mode, and Safety Lock password.
The Safety Signature aspect is enough to keep me pretty safe liability wise. If the end user has changed the safety code, the safety signature will no longer match what I left (and documented) at commissioning time. Since timestamp impacts safety signature, they can't go back and re-instate the original (unless they download the as-commissioned code.. but then PLC modified time will show they tried to cover tracks)

Thanks again for writing all of this out!
 
This project is a bit more R&D than most of our projects. The Service Provider is still working out how the vision system will get reliable enough and accurate enough (lighting, vision tools, et al). What worked in their shop has not worked out so well in the field. So requirements->development->commissioning is more of an iterative loop than it should be ...

In this situation it should not be integrated into the safety system.
Safety systems are really not for 'trial and error'.

Especially given that it would be compromising the other safety functions (whether lack of safety signature, or processor being unlocked, even just having a large number of safety code changes)
 
In this situation it should not be integrated into the safety system.
Safety systems are really not for 'trial and error'.

Agreed that safety systems are not for trial and error. I appear to have communicated the 'trial and error' portion badly.

The area that the robot can reach DOES need to be guarded from access by people while in operation.

The robot system requires a safety system to monitor safety gates, manage safety gate resets, etc to limit personnel from entering where the robot can reach during operation. Access to the area triggers an emergency stop for the robot.

The 'trial and error' part has to do with the vision systems correctly identifying and giving coordinates for what the robot interacts with. The vision systems also verify that each operation has completed successfully. The vision tools used, the changes in captured video due to lighting, humidity and temperature changes, the tools incorrectly identifying targets in the background of the video, that's trial and error to see what works reliably.

The safety system is implemented, the robot and vision systems are being revised/tested/commissioned during day shift when operations is not in production. This system is locked out/tagged out when the Service Provider is not on site working on it.

IMHO safety is not being compromised during this development process. The system is being monitored continuously by the Service Provider when they are working on it. Only their own trained and experienced personnel are allowed inside the safety gates when it is powered up. They have the teach pendant in their possession (that houses a portable emergency stop button) when they are testing the robot.

The corporate firewall, the site firewall, the jump client/data diode thing .. that is existing security for the existing Control Network.

The Safety PLC security is in addition. Some of it is likely already implemented by the Service Provider. I'm obviously not familiar enough with the Safety PLC security to recognize it.


Especially given that it would be compromising the other safety functions (whether lack of safety signature, or processor being unlocked, even just having a large number of safety code changes)

The safety portion of this system is commissioned, and is quite small - on the order of 30 rungs of ladder logic. I can't think of a scenario where it would need to be changed unless the requirements change.

The list of suggestions has been forwarded to the Service Provider. They will be discussed next week. I opened a service ticket with Rockwell to ask if there is anything further that can or should be done. That service ticket information will also be discussed. We'll agree what to implement and in which order. Then the Service Provider will get it done.

Thanks again for writing up all of this, and for sharing your experience!
 
Ensuring robust cybersecurity for Safety PLC programs is paramount in critical infrastructure. Implementing encrypted communication, regular audits, and access controls safeguards against cyber threats. Continuous monitoring, threat detection, and prompt updates maintain the integrity of these programs, enhancing overall safety and resilience in industrial environments.
 
Most safety Instrumented Systems I've worked on talked to eveyrthing else through Modbus RS485. Focus on the word talked, they never listened.



Can't get more cybersecure than that.
 

Similar Topics

Hi All, Does anybody know of Annual Process Control Cyber Security Conferences that are worth attending? Our company is looking at setting up a...
Replies
22
Views
8,560
- Industrial Networks & Cyber Security - Hi, We are all well versed in IT security, windoze risks & Stuxney etc.. What do we know about the...
Replies
9
Views
1,671
My newspaper this morning had an article "Preparing the Battlefield" in which they reminded me of Stuxnet and the effort to sabotage the Iranians...
Replies
8
Views
2,686
Hi, In CSI Cyber S1E02, it's shown that a PLC can be hacked by using a Blue tooth device. Is this possible? How can one avoid this? Ron
Replies
10
Views
4,705
Look like Stux is at it again. http://news.yahoo.com/gauss-stuxnet-linked-cyber-weapon-hits-lebanon-181202373--abc-news-topstories.html
Replies
2
Views
2,363
Back
Top Bottom