An informative 3 minute video of the Ignition concept from Inductive Automation, rethinking SCADA for modern manufacturing.
Thursday, December 23, 2010
Industrial Security - a reminder from Stuxnet
I've refrained from blogging about Stuxnet for the simple reason that I'm no expert on it. You can learn more than I know about Stuxnet from Wikipedia. However, it should reinforce the need for basic security good practices. I hear too many integrators and industrial professionals write off a system as not needing any security applied because the system is on an isolated network. Consider the vector Stuxnet used to attack isolated networks - USB drives to infect the system then peer to peer Windows RPC calls. Even if you're not the target of a large attack, you need to protect yourself from the much more common "insider threat", a disgruntled or malicious employee. Let's consider some easy steps that can make a huge difference in protecting your SCADA system and industrial network.
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?
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
Going mobile with industrial computing
Mobile is hot in manufacturing! The web sites of the major SCADA vendors, industry blogs, and consumer feedback indicates a strong interest in "mobile", be it tablet, PDA or smartphone. Who wouldn't want the capability to see, if not control your process from the palm of your hand? Why deal with text messages, phone calls, or email alerting when you can see, acknowledge, and handle alarms from your mobile device in real time? What about tying this to your MES/ERP system to view production efficiencies?
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.
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.
Subscribe to:
Posts (Atom)