Absolutely! Applicable knowledge can certainly be covered without getting into specifics that are irrelevant at the level I plan on discussing.
Your story exemplefies the reason that your counterpart and IT need to be in better communication with each other. A large part of what I plan on discussing is understanding the ramifications of an operating system patch - this is something that IT should have been made aware of. Typically in a production system availability trumps security (confidentiality, integrity, and potential vulnerabilities).
A few points:
1. This paper is intended to get an overview of available
security technologies. You don't need to know exactly how to implement them to make intelligent decisions. It's ITs job to take care of that. In your case, you may need to start learning what "they" do. My paper will not cover that, but aims to give you a solid foundation to start from.
2. There are obvious, simple things about control systems that IT should know about. I worked in several IT related jobs and have worked many automation projects. The technology is fundamentally similar, but the emphasis is different. I've assisted integrators in dealing with numerous IT departments - I've yet to encounter a case where they're not reasonable when you approach them beforehand, show them your system, and explain the priorities. It's always the case where controls guys and IT personnel are at each others throats
after the fact because each side thought he was doing his job without considering the other. They are
both professions that require a broad and technical skillset.
3. I will recommend the use of vendor neutral standard technologies whenever possible (including Microsoft as a standard rather than a vendor). A sound design should minimize a lot of the off the wall problems that come up, and place the appropriate ball in ITs court. For example, use a VPN for remote programming instead of a proprietary "Industrial modem". If Windows is your VPN server, you know it'll work in 2007 after you upgrade from 2003, and it would be a big deal if security patches caused any issues here (as opposed to security patches blowing up proprietary software, which happens all the time - do a search here to see). If Windows doesn't work for you, use a Cisco router, or any brand - you get the idea. That's a service that IT can be responsible to provide.
FactoryTalk qualifies as a vendor specific proprietary technology, like Archestra, and many others. You will necessarily deal with some of these in an industrial setting. My recommendation is to identify, simplify, and minimize your potential points of failure. These tend to be your clunky links and they
will be the most troublesome because they straddle the lines of responsibility between controls and IT. You could also get IT to do their own research beforehand, possibly giving them suggestions as starting points, and see which ones they can best support. Many vendors are in bed with Microsoft and offer IT support training. I don't like this personnaly, but it mitigates risk. The goal is to be as standard as possible (too bad OPC UA isn't ready yet) and understand the most likely points of failure of your system.
Let me give you examples that you may have control over: When looking for a "historian" Vendor A allows you to store data in any standard SQL database, Vendor B offers their own modified version of Microsoft SQL Server, and Vendor C has their own "super efficient" homecooked concoction. Who do you think will be easier for IT to upgrade/maintain? Option A gives IT their choice of corporate standards and allows them to work with existing/known systems. IT could probably support B reasonably well with a little extra manual reading and a little fear of an upgrade. They will probably defer C to you as the expert when it breaks or needs to be upgraded?
Here's another. You're dealing with a distributed client application. Vendor A runs a locally installed program that requires complex configuration of either PLCs or a Server. Vendor B uses Remote Desktop, a Microsoft technology. Vendor C uses a web browser launched application. Purely focusing on replacing a "dead" terminal - A is the most complicated requiring an hour of an integrators time, B takes an integrator or IT 5 minutes, and C can be done by the anyone including the end user.
Many controls system headaches
are created by avoidable poor design decisions!
4. If IT was providing the remote access, and their patch removed the capability, they did something wrong. They can tell who's connected before making changes. I don't buy integrators comments that
this IT department is totally inept, but their systems are simple enough for me to manage with no training or experience. If your IT department is a problem - fix it! I doubt this is ever really the case.
This was aggrivated by the fact that your co-worker was patching the system without telling IT. Each side should know when they're doing a dangerous operation and schedule it accordingly.
Whew! I wonder if anyone's going to read that...
OkiePC said:
Very important subject, but can you really glean any applicable knowledge without "getting into the weeds"?
I have avoided the whole mess all this time, but it is clearly encroaching on production now with our use of RSView distributed running on Widows2003 servers managed by our IT guys in conjunction with one of my counterparts at work. If he gets hit by a bus, that abay will be be mine and I am clueless as to how to deal with all the complexity.
Just last week they made security changes that he was befuddled by and resulted in 37 minutes of downtime when he got kicked off his remote session while applying FactoryTalk patches...His patch required a windows explorer update, then his login was teminated and he was locked out of our whole network. Luckily he was able to cycle power to the servers and get our meat grinding systems HMI working again so quickly. It took all day and half the next for him to get his network login working again with a lot of help from the IT guys.
A big hole or gap in my understanding exists because of my unwillingness to soak up the quantity of details required to understand it all. It is coming though, and fast.
Where do I start?
