How to plan for the cloud with security in mind
- Consider the tenant of "local control". This may or may not translate to "isolated network". It's better to not even think about implementation at this point. The idea is, "from where do I want to allow my operators to control equipment"?
-Decide what it is that you need to access from anywhere. This is a business decision, not a tech decision.
- In terms of your security planning, cloud hosting is basically the same as making your application accessible via the Internet. Do not confuse this with "public". Both approaches can provide worldwide access. Both can be secured with SSL/TLS and/or even require VPN connectivity. Consider the implications of a "worst case" compromise in the back of your mind.
- "The Cloud" is probably more robust than your server. The gold star for Availability more likely goes to the cloud. Consider that you're not taxing your bandwidth or storage resources and can pay more money to scale on an as needed basis. The whitepaper refers to this as leveraging or outsourcing IT costs. This is a good thing.
- Consider separating your Internet or Cloud services from the rest of your network, including control, business, public web, etc. I am not a fan of your cloud server being able to reach out to your PLC. Why would you do that except in the case of deliberate cloud based control, which is generally not recommended? It's just as easy to have your internal control system write data out to your online (Internet or Cloud) database. You might even log data to a local database then replicate that online. Control the flow of your communication!
Example
The point is, think about your security architecture requirements from a simple perspective. Don't worry about how you will implement it. For example, your thought process might go like this: I want to be able to change setpoints from anywhere within the control network of my 3 sites, I even need a secure way of doing this remotely. If the network goes down, local operators need to be able to control the system without missing a beat. QA needs to examine our realtime process in detail and management wants to be able to access production reports from anywhere. As you come up with this you'll inevitably realize that QA and management systems don't need a path to the PLC - that's the Principal of Least Privilege (POPL) in action! Keep up on defining requirements! Availability really matters at the operator terminals, but not for control between sites - so we don't need redundancy there. Maybe QA has regulatory requirements requiring strict Integrity (prevention of unauthorized data modification). Do we care if the management reports get out? Maybe a lot, maybe not at all. If so, we'll want to protect the confidentiality of the system. Notice that I'm focusing on what and not how?
Get the idea? Now we have our business requirements, driven by operators, management, and our process. Notice that we didn't even consider technical limitations or implementation details? Now it's time to come up with a tech plan, get with IT and let them know what are objectives are.
Your solution may be a complex multi-part system with firewalls, intrusion detection systems (IDS), VPNs, local systems and online ones. It could also be really simple.
Closing Advice
- First consider your business/operational requirements in the absence of naysayers who are thinking about implementation/security details.
- Keep security in mind as part of your requirements. This can be done without extreme paranoia.
- Involve IT early on the design phase. Once you provide the what they should be able to help you out with the how.
- Don't forget about upgrades/updates, backups, and other ongoing support requirements.
- Follow the good practices that you already know. Use strong passwords, update your systems, etc.
- Read this whitepaper.
