My buddy Sean Gowing sent me a video today regarding SCADA. I'm not much of a SCADA guy, but I'm always interested in a good security debate.
You can watch the original video here.
I wanted to share some of my thoughts on this issue. Unfortunately, the "Apologists" are not only limited to the SCADA world. The video was awesome, and there was good discussion from both parties. It is good to see, in this day and age, that we can still agree to disagree and do it respectfully.
In my mind, I think apologists are a bad thing, but more on that in a moment.
In the video, Eric had posted a slide entitled "Welcome to the real world". I wanted to talk to this slide.
1) FACT: Large Industrial organizations are not agile
So? Is there actually a point here? I will give you that a lot of organizations are not agile, but are you saying that they have to be in order to be productive? Some how these organizations have accomplished great technical feats, solved business problems, and remained profitable. All ... without ... being ... agile.
I think the point Eric is trying to make here is that large organizations move slow. Okay, granted, but they should at least move. The point Dale is trying to make is that there has been little to no progress on the issue of SCADA security. In fact, the first audience question mentioned the fact that the industry is capable of producing new protocols/technologies.
2) FACT: Costs and downtime matter
I think that this is a valid point. There is going to be a battle of budgets to get this problem fixed, even if we can define or agree on what fixed means. But I think the point to take away here is that this is the cost of doing it WRONG. Had it been done right in the first place, we wouldn't be in this mess.
Yes yes, I understand that SCADA systems are old, and we didn't know things way back when. But I want to step back from SCADA here for a moment.
Many systems are designed like this. They do not build in any abstractions, and this makes the system brittle and resistant to change. They do not plan for upgrades in features or functionality. They do not plan for security. This is a systemic problem. The only thing we know for sure is the cost of having done some of this work upfront will pale in comparison to the cost of fixing the problem now.
3) FACT: Money is tight
I guess you have to look at this from two aspects. The first, is the "end-user" as Eric puts it. The second is the vendor. Actually scratch that. Most of these companies make billions of dollars a year. Don't believe me? Check out the latest on honeywell. I'm sure they can spend a little bit to improve their products.
The second point here is that Dale is clearly trying to focus the discussion on critical infrastructure. Dale brings up the point about the "cookie factory". If the CEO of the cookie company wants to accept the risk that his business could grind to a halt because of a few misplaced ping packets, more power to him. But when my water/power/heat is in jeopardy, you bet I want to be running robust systems. In some cases (most?) these utilities are handled by private companies who also make lots of money. Money is only tight because we allow substandard products to be put into the market place and now we need to continue to show the same or better profitability but increase the quality of the product.
4) FACT: Security isn't the only challenge facing the boardroom
So? Point? CEOs and their cronies take home millions of dollars a year. They get paid to deal with the company business and are entrusted to do so by their shareholders. Security of their systems is part of that business, just like HR, or the bean counter department. Like most things, the company should have a security policy and they should enforce that policy. The price of meeting the policy should be factored into project costs. It is time to grow up and look at the true cost of building IT systems, rather than always trying to shortchange it.
Conclusion
In the end, I'm mixed on the argument. I think, ultimately, I agree with both of them.
In my mind, the final message that Dale gave is the right message, and wins the argument.
When we are being consultants, we need to triage and do the best we can. We need to employ compensating controls, etc ,etc. But we also need to help our customers define what they need. This will help our customers demand more of their vendors and hopefully push for real meaningful change. I compare this to doing threat risk assessments. You identify the threat. You then list out potential solutions along with their mitigating factor. You then weight the cost of doing each solution vs the mitigating factor it provides. (Please note I do not agree with this approach, but it is the way security is "done"). The first solution, always, should be to build a secure system from scratch. If all the CEO ever sees is a checkbox saying we are secure, then we have failed at being consultants. Compensating controls are never as good as a proper solution, designed to be secure.
Secondly, when we are talking in public, we need to be evangelists. In my mind, Eric basically provided the C-level with a whole list of excuses to use when they tell their shareholders/regulators that they can't make their systems secure. The fact is that this problem is solvable. There are meaningful steps that could be taken that would push us down the right path.
Unfortunately, like Dale, I think we will need something bad to happen before this problem is taken seriously.
As a last note, I would love to see Dale and Eric work together on some of these initiatives. I think that Eric could focus on the short-term (3-5 years) on how we can make existing SCADA deployments more secure. Dale could focus on the long term (5-10 years) on how to get companies to adopt proper requirements, and how to push vendors/industry to bake security in.
No comments:
Post a Comment