Safeguarding Logix500 + 5000 Programs / HMIs

Here's my problem: the company I work for is a small OEM which has one PLC guy who's become seriously disgruntled. I'm taking over for him, and suffice it to say: I'll get no training, or etc. - just a marching order.

My first line of business (aside from learning all this stuff as fast as inhumanly possible) is to assess our exposure to this guy in terms of plc programs.

I'm taking steps to ensure the programs on Logix5000-based machines aren't source protected which, it is my understanding, means that in a worst-case scenario I could always retrieve a working, complete, unsabotaged program if in a pickle.

I'm curious to know if such a source protection (runtime level) exists for Logix500 plc's as well.

Also, can the(se) source protection be set / managed remotely?

If anybody could also give me a few idea of what else I could do to safeguard against potential malice in this situation, it'd be a great help, and greatly appreciated!

Burn a CD of everything. Today. Make two. Take one home.

Don't forget drawings and drawing files as well.

Check timers in the code, some disgruntled employees have been known to leave in 'Easter Egg' type of timers that will a few weeks after thay have left cause the program to 'stop'. If these are password protected etc...or the comments have been removed it can become very difficult to repair or fix them. But this is very rare. My advice would be to get a backup of everything including comments.

Making a CD's not even a sure thing because there's no way of ensuring that the source laying around the office is anything intact - only the code on a working machine can really be trusted. Thank both for your inputs. I'm grateful for anything else anyone has to contribute...

If possible, get copies of the annotated logic; even older copies & listings are better than nothing. Real I/O is easy enough to annotate but the internals can be a bear.

Look in the recycle bin on his computer. I was called in on a job that a guy dropped little EASTER EGGS all over. No documentation at all. I found most of the documentation in his Recycle Bin on his computer. If there is a common server look for backups on it. People always forget to cover all thier tracks. I love this CSI reverse engineering stuff.

There are several different protection modes for RSLogix 5000 controllers. The RA Knowledgebase has a good summary of them in Document 8378.

The most common one is "Source Code Protection", where a user program running inside RSLogix 5000 controllers can be protected from upload by computers that lack both the original project file and the SK.DAT security key file that was used to secure the code.

It is vital to get your hands on the *.ACD files for RSLogix 5000 projects. Unsecured projects will lack the SK.DAT file (usually in C:\RSLogix5000\Projects), but secured ones absolutely require it.

SLC-500 projects have password security, but passworded offline program files (*.RSS) can be "cracked" by RA Tech Support. Programs loaded into SLC controllers can be secured so that they cannot be uploaded at all; this is called the "OEM Lock" function.

Your first priority should be finding all the *.ACD and *.RSS files and backing those up. Don't forget the SK.DAT file if it exists on an RSLogix 5000 workstation.

I appreciate all the responses, and it's greatly put my mind at ease on this. Eddie - that was exactly exactly what I was trying to hear! Cheers to all, and hopefully once I get my bearings on all this I'll be able to pay a little forward.

ieseng said:

Check timers in the code, some disgruntled employees have been known to leave in 'Easter Egg' type of timers that will a few weeks after thay have left cause the program to 'stop'.

Click to expand...

My predecessor did that. Before he left he negotiated a consulting fee and minimum charge if he was needed for tech support. The first time bomb went off about five weeks later. I found it in a matter of minutes. After I showed the manager what I had found he had me check everything else. I found time bombs in several other controllers, all buried in different parts of the program and all set for different times over the next year, none of them were very clever.

Well, as my sole source of learning right now is dissecting his code, I'll find anything that's hinky (I'm fairly thorough). My first red light was seeing many of the outputs to energize valves and pumps linked to InAuto instead of DOEnergize which would make sense if these were things intended to be energized at all times, but fact is they're not and there is logic in the ladders intended to control these devices according to the theory of operation. If it were once or even twice, I'd say he clicked on the wrong little box, but this is pretty widespread. Very hinky! Thanks, Alaric.

Probably already mentioned, but make certain you've got copies of the SLC 500/Micrologix series PLCs on Logix500, and if/any PLC5 series PLC's on Logix5.

If you don't have those on your specific laptop/computer your going to get online/program with, you can have the possiblity of no documentation within the program and it makes it easily 10x harder to troubleshoot.

You don't have to worry about that scenario with Logix5000.

Well, I think I have an action in place that should limit our exposure to any potential malice. Thanks again for all the helps!

tvich said:

...
You don't have to worry about that scenario with Logix5000.

Click to expand...

Last time I used RSLogix5000 (5 minutes ago v16.03) it did not store annotation with the processor, only tag names. Unless a newer version has added this feature, I would be careful about assuming it does.

Well, I have source for all the 5k stuff, I'm just not sure how much I can trust the source. Still, a 95% intact, fully-annotated code laced with a few timebombs is a lot better than nothing. Either way, in dire straits, I've got enough pieces to put the puzzle together if / when called upon to do so. I'm just trying to preempt any possible 'unforeseeables.'

+1, good plan