Passwords for Controllogix (and other RA PLC's)

I've plowed through all the documentation and would like to get something basic verified by Controllogix / RSLogix gurus.

It appears that anyone with a valid copy of RSLogix or RSLinx can program a Controllogix PLC. There is no authentication on the PLC. Is this correct?

I did see the ability to set source keys on routines, but this wouldn't seem to stop anyone from downloading and executing new routines.

I also saw a great deal of authentication and authorization in the RSLogix and RSMACC through the Security Server and RSAssetSecurity, which is good. However, this doesn't really control access to the asset we would care most about, the PLC.

Finally, I've also heard that V16 of Controllogix may add some security. Any news or links would be appreciated.

What you state is accurate with, well, every PLC out there that has RAM.

Anyone with valid programming software can just download an new program. At the very worst, they have to pull out or short the backup battery for a few seconds.

Put it in a locked cabinet, or epoxy over the serial port and allow no other access to any of the PLC communications networks if you are that concerned.

Thanks, rdrast.

I'm working with Controllogix with Ethernet cards accessed over a WAN, so the risk is a bit more than the serial case.

Basically it means that anyone that can ping the PLC can reprogram it.

My confusion is when you read the AB / RA brochures and docs they talk about these great authentication and authorization features in the RS family, but they seem to conveniently avoid mentioning this is only controlling access to the programming tool, not the device being programmed. So I just want to make sure I'm not missing something.

There are some PLC's that require authentication at the PLC prior to programming, and this and other security issues become increasingly important as the community moves from serial to Ethernet and IP.

With RSMACC you can define user abilities, right down to toggling a bit. However, this is not just a quick bang install. We are in the midst of our implementation, and this is a 6 month project including ordering a dedicated RSMACC server, and setting up certain PC's as clients to that server. Any other PC will have no functionality to the PLC, as will anyone who does not have security definitions defined. I guess, in a nutshell, RSMACC will do what you want, but is not a small time thing.

Russ

russrmartin said:

With RSMACC you can define user abilities, right down to toggling a bit. However, this is not just a quick bang install. We are in the midst of our implementation, and this is a 6 month project including ordering a dedicated RSMACC server, and setting up certain PC's as clients to that server. Any other PC will have no functionality to the PLC, as will anyone who does not have security definitions defined. I guess, in a nutshell, RSMACC will do what you want, but is not a small time thing.

Russ

Click to expand...

Russ - I think this is what RA wants the market to think based on the way they write their documents, but I don't think it is true. What is stopping a valid RSLogix or RSLinx install, that is not configured as a RSMACC client, from doing anything to a ControlLogix? This would need to be some setting in ControlLogix that would say only accept management from an authenticated RSMACC client or server, and I don't see anyway to do this.

RSMACC seems to provide what is needed to limit what RSMACC clients can do. I know you can set up the RSMACC with the RSLinx capability so all clients send management commands through the RSMACC server rather than directly to the ControlLogix. If the ControlLogix can be configured to only accept commands from the RSMACC then this is a solution.

If there is a setting on the ControlLogix that limits management to authenticated RSMACC servers please let me know. I hope that I'm wrong because we need a high security solution. Right now the best we can do is use router configs to limit the IP addresses and ports that can reach the PLC.

Along with limiting the IP addresses that can actually reach the PLC, you might want to go so far as to get switches that allow for MAC address based permissions.

Even if someone went as far as to spoof a MAC address, they would have to be actively snooping around to find them.

My confusion is when you read the AB / RA brochures and docs they talk about these great authentication and authorization features in the RS family, but they seem to conveniently avoid mentioning this is only controlling access to the programming tool, not the device being programmed. So I just want to make sure I'm not missing something.

Click to expand...

CPU Security Tools


It outlines the three main methods of securing code, as a CPU Lock, Source Code Protection and Programming User levels.

Thanks Philip. The CPU Lock seems to be the answer.

Also, do not forget, leave the processor in RUN and remove the key. That way no can remotely change the processor. Only someone in full view of everyone else who has to access the PLC enclosure and insert a key can change the PLC code.


Ian

cryptoguy23 said:

Thanks Philip. The CPU Lock seems to be the answer.

Click to expand...

\]

Unfortunuately CPU Lock is not the solution. It only works on the DF1 interface. If you set the password using CPU Lock, you will not be able to remotely manage the PLC over the Ethernet port.

This means any system or attacker that can ping the PLC, and has a copy of RSLinx, can take total control of the PLC. YIKES!!!

As more asset owners move from serial to IP comms this will become a huge issue. It is an embarrassing situation for a market leader. Again, I hear rumblings that it may be addressed in the next version and would like any additional info or possible interim solutions.

cryptoguy23 said:

\]

Unfortunuately CPU Lock is not the solution. It only works on the DF1 interface. If you set the password using CPU Lock, you will not be able to remotely manage the PLC over the Ethernet port.

This means any system or attacker that can ping the PLC, and has a copy of RSLinx, can take total control of the PLC. YIKES!!!

As more asset owners move from serial to IP comms this will become a huge issue. It is an embarrassing situation for a market leader. Again, I hear rumblings that it may be addressed in the next version and would like any additional info or possible interim solutions.

Click to expand...

If you expose your internal LAN to the outside world, without proper safeguards, you get what you deserve.

Sorry but what you have posted has a total contradiction:

you will not be able to remotely manage the PLC over the Ethernet port.

Click to expand...

and:

This means any system or attacker that can ping the PLC, and has a copy of RSLinx, can take total control of the PLC.

Click to expand...

Are mutually incompatible statements. The CPU Lock as I have used it is attached to the CPU via the DF1 port, but once the CPU is locked then the Tech Note states:

Once you have entered a password and secured the controller, no one will be able to go on-line with the processor by any means until the processor is unsecured.

Of course it is would remain a requirement that RSLinx can access CPU tags in order for the HMI to work....it was never the intention of the CPU Lock to stop that from working. If it did there would be little practical application in the modern world for a PLC that could not communicate to anything. What the CPU Lock is intended to do is prevent RSLogix from accessing the CPU and allowing unauthorised logic edits. I am quite sure that this applies to the backplane ports (ie Ethernet modules), as well as the DF1 front port.

The kind of security problem you are thinking of is most likely to arise if your control networks were in some manner compromised or exposed to the Internet. That is a totally different issue with a quite different solution.

rdrast said:

If you expose your internal LAN to the outside world, without proper safeguards, you get what you deserve.

Click to expand...

What about disgruntled insiders? They are inside your perimeter.

Also, there is a concept called defense in depth. Even with a strong perimeter, you want protection and detection in case the perimeter is breached.

Think of it this way, banks and financial institutions have their applications on their internal LAN's. Should they not have protection?

Once you move to IP and Ethernet the threat model changes dramatically. There are many examples of control system networks that were thought to be isolated or protected being breached.

I don't think the community can pretend these are isolated systems that are impossible to reach anymore.

Pull the Ethernet cable from the port and put the PLC in a secure vault. Problem solved.

PhilipW said:

Sorry but what you have posted has a total contradiction:



and:


Are mutually incompatible statements. The CPU Lock as I have used it is attached to the CPU via the DF1 port, but once the CPU is locked then the Tech Note states:

Once you have entered a password and secured the controller, no one will be able to go on-line with the processor by any means until the processor is unsecured.

Of course it is would remain a requirement that RSLinx can access CPU tags in order for the HMI to work....it was never the intention of the CPU Lock to stop that from working. If it did there would be little practical application in the modern world for a PLC that could not communicate to anything. What the CPU Lock is intended to do is prevent RSLogix from accessing the CPU and allowing unauthorised logic edits. I am quite sure that this applies to the backplane ports (ie Ethernet modules), as well as the DF1 front port.

The kind of security problem you are thinking of is most likely to arise if your control networks were in some manner compromised or exposed to the Internet. That is a totally different issue with a quite different solution.

Click to expand...

I believe you are right as you describe the CPU Lock functionality. The disconnect is I'm working with a SCADA network over many 100's of miles. So the ability to remotely perform logic edits is important.

If it was a factory environment, the CPU Lock and local programming would work great. Also the suggestion to place it in Run mode and remove the key would work.

ADDITIONAL NOTE - These SCADA networks typically run over private IP WAN's, not the Internet.