An informative 3 minute video of the Ignition concept from Inductive Automation, rethinking SCADA for modern manufacturing.
Thursday, December 23, 2010
1. First, get the best "bang for your buck" - take care of your low hanging fruit. Embarrasingly, in industrial systems this means: get rid of shared accounts and no passwords, don't connect the control network to the Internet or harden your business necessary connection point, ensure that you have a working backup, check your backdoors (old modems, etc).
2. The strength of your system lies in a Defense in Depth approach, meaning taking advantage of strengths of overlapping security mechanisms. While adhering to point #1, knock out the really easy and obvious ones. There's no reason to get fancy until you have your basics covered.
3. Architect your system with security in mind. For example, if you decide to start with Windows XP SP 1, you're just asking for trouble. I get it that patching often has negative side effects with industrial/SCADA software, but you need to (minimally) begin with a baseline that isn't hugely vulnerable. Design around industry standard technologies and protocols such as OPC-UA. Don't try to roll your own security solutions!
4. Develop a security policy and train your users. It's important that management understands and accepts the level of risk that the system takes on. It's important that users know what's allowed and that consequences are serious. Require that they sign an Acceptable Use Policy (AUP). A successful security program is as much about users, policy, and procedure than equipment, applications, and configuration.
5. Establish individual accountability (auditing). Ensure that users have individual accounts and that their activity on the system is logged and periodically reviewed. I know this often doesn't happen in manufacturing, but it should.
You have far too much value in your HMI, SCADA, industrial system. Ask yourself, how much does downtime cost? How can you afford to not secure your control system?
Wednesday, December 22, 2010
Sure there are red flags - you will probably have an increased requirement for security including physical access, user accountability (auditing), and all the typical considerations. For most organizations the benefits will most likely outweigh the risk and cost. Security is a mature enough field - if the credit card companies, banks, financial institutions, and even the military can be successful with it, so can you. Apply defense in depth, implement/follow your company policy, adhere to strong practices, hire experts if you need it - nothing new here.
From my perspective, industrial computing has been following the path of commercial computing. Those same basic technologies that have become widespread in your office will usually show up on the plant floor in some form. You can trace industrial controls from relays to PLCs as opposed to vacuum tubes then transistors, but the technologies have been converging and are basically one in the same.
Perhaps a driving force of computing paradigms is the relative shift in local processing power versus the capability of the "network". How thick versus thin is the ideal environment - in other words, do we want to perform the computing locally or remotely? We've seen this shift between centralized and de-centralized SCADA systems - the balance between central administration versus local setup, scalability and performance, and dependence on the network. The models roughly share the considerations we've seen in the migration between: Mainframe, Micro, Mini, and PC.
So where are we going next? Cloud computing or even thinner clients? To me, mobile computing represents an advance in both categories. That's not to say that smart phones won't get more computationally capable - they will continue to shrink and get faster and faster. However, with the increasing reliability of infrastructure, "the network", it makes more sense to centralize your control applications. Why? In one word, ubiquity. For the same reason the web has standardized on HTML. Users will demand access from anywhere they deem appropriate, regardless of the mobile platform. Will they create a separate app for each: iPods/iPads, Blackberry, Droid, Win 7 phones, Palm PDAs, embedded MS OSs, Linux devices, etc, etc? Each of those platforms has a large enough user base to support its own "apps" - Solitare, or a web browser, which turns out to be the common denominator.
I don't think organizations will put up with only supporting one mobile platform. This is somewhat akin to requiring you to buy a Bell phone in order to use the phone network. Nor is it acceptable for a complex installation or configuration. Successful SCADA vendors will need to support feature rich mobile applications that run on most, if not all, mobile devices out of the box. As our networks get more robust, secure, and cheap, we'll be rewarded with new levels of capability that make that transition from novelty to necessity - just like PCs once did. In the end, competitive organizations from all industries will benefit from these incredible mobile technologies.