SCADA Security: Big Picture Planning is Key
Editor's Note: this is an excerpt from the Pike Research Blog.
The story goes that a group of business people were stranded on a desert island with a bountiful supply of canned and therefore imperishable food, but no way to open the cans. As the group struggled to find a solution the lone economist in the group piped up, “Assume a can opener…”
No one single solution can provide complete security for ICS networks.
Image Credit: Amco Houseworks
Sometimes it seems that’s how we approach industrial control systems (ICS) security. “Assume a secure perimeter…” It’s not fair to expect any single product or any single vendor to provide complete security for ICS networks, and yet we seem stuck in a world of point-solution purchases and security without any overriding architecture. It’s as if we’re saying, “If I can just get me some [insert technology of the week], then I’ll be secure.”
Barely 3 weeks into the new year, I have already had wonderful briefings from companies whose products lock down privileged IDs, ensure clean networks by detecting attacks at network chokepoints, heuristically identify attacks though behavior analysis rather than signatures, protect control networks from the lawless jungle that is enterprise IT, and so on.
All of these approaches are good, and all of them are necessary. But in isolation, none protects an ICS network. Cyber security still begins with risk assessment, not product purchase. Every utility is a business, and every business is unique. So before you go ask for this year’s cyber security budget, do a little planning. Skip the shortcuts.
Big Picture Cyber Security Planning is Key
To the utilities that have a shopping list of security products but no overarching plan how to use them: You might be amazed how much you can save in deployment and ongoing maintenance with just a little thought. Over the years I’ve seen countless companies purchase a less expensive product without planning how it would be supported. A bargain is no bargain when it requires an excess staff of 10 full-time employees for 10 years to support it.
To vendors happy to show up at a utility and sell only their product: think about your customer as a business, not an account. If you don’t see enterprise security planning going in, bring in some help. Maybe that help is a systems integrator, maybe it’s just a single security assessor. Maybe it’s collaboration with other cyber security vendors or even – gasp! – a competitor. No matter what, understand the whole problem, not just the problem that your product will fix.
There is some cause for encouragement. Compared to 2 years ago, vendors are much more likely now to tell me that they are part of a full cyber security solution. Utilities have become much more methodical in their approach to cyber security – especially as OT teams have become savvy and made their reliability requirements part of cyber security projects.
Does your organization do big picture cyber security planning? If not, do you see a transition in that direction? Let me know your thoughts.
|
Bob Lockhart |
Practical SCADA Security thanks Bob Lockhart and Pike Research for this article.
Related Content to Download
|
White Paper - "7 Steps to ICS and SCADA Security"
|
Related Links
- Pike Research, Blog: In Cyber Security, It’s the Whole Picture That Matters
- National Institute of Standards and Technology, PDF: Guide to Industrial Control Systems (ICS) Security
- NIST.org, Website: Home page
- Pike Research, Webpage: Industrial Control Systems Security
- Blog: Defense in Depth is Key to SCADA Security – Part 1 of 2
- Blog: Defense in Depth is Key to SCADA Security – Part 2 of 2
- Blog: #1 ICS and SCADA Security Myth: Protection by Air Gap
Comments
You can't begin to secure an ICS until you understand your risks
Amen ... Bob!
Nice to see others stressing the importance of risk as the first and probably most important step in securing industrial control systems. There are many out there that think it is about "eliminating vulnerabilities" or "removing vectors" ... but I believe that the first step is to perform a thorough risk assessment so that you understand your complete risk profile. Starting with a system, it is important to grasp your threats in terms of agents, vectors and events, followed by an understanding of your vulnerabilities. Where many fail to focus attention is on one important aspect and that is the consequences that should result if an attack was successful!
Remember ... risk requires all three: threats, exploitable vulnerabilities and consequences. If you reduce or eliminate ANY one, you effectively reduce your risk. When you begin to look at it from this approach, you will quickly realize that sometimes it may be easier to focus on managing the consequences than eliminating the vulnerabilities!
Just because an ICS component has vulnerabilities or is "insecure by design" does not necessary mean you have risk. If there are acceptable consequences, or even minimal threats, than you in fact don't have much residual risk, and that means you should move on to areas that present the greatest levels of risk to your organization.
I hope to have my talk on risk management accepted at the upcoming ICSJWG Spring conference in Phoenix where I will share more insight into this approach.
Security is not about vulnerability management, but risk management - and that is what I believe separates those that can "walk the walk" versus many that can only "talk the talk".
Stay secure ...
But not all Risk Assessments are equal!
I agree with everything that has been said with the exception of the performance of a Risk Assessment (RA) as the starting point. What constitutes a RA is the issue every engineer will face, understanding the requirements before completing a RA and then the deliverables for a RA will go a long way in saving you a lot of time, effort and money. The reason for this is simply the measurement of the risk associated to what ever is or is not there. Certain RA methodologies require certain technical controls to be in place or certain concepts such as Asset Classification and Configuration Management which is mostly not there. Additionally, the measurement or reporting on risk is dependent on your type of business, ditto for the impact.
Most companies perform a RA just to tell them what they already know. This is not the intent of the RA, the RA will give you the strategy on how to sort the issues out and minimise risks. It is a strategic decision and not operational in nature.
My experience has taught me that there are things you need to do before you do the RA and that is;
1. Approve a Risk Management methodology that makes sense to you and your business
2. Review all your existing policy documents making sure that all of them at least make sense (compare to freely downloadable content)
3. Get all your diagrams updated to be what is physically implemented - a picture tells a 1000 words or a story!
4. Put a project together to create documents and processes (AS-IS) you do not have but you require because there is a need within your organisation. NB - Only document what is required not because some standard says you require it!
5. Implement the newly created processes and measure their effectiveness - look at 6 Sigma to show you how to do measurement of a process.
Now that you are following a process approach to risk management within your daily operations, now call for a RA to tell you what you need to fix and make sure it looks at People, Process and Technology risks.
Chances are, you will require better processes and less technology.
Add new comment