I think that perhaps I have chosen a poor approach in trying to raise awareness for process control and SCADA (in)security. You can find recent SCADA posts here, including the "awareness campaign" Mogull and I launched a couple of weeks back that got a ton of eyeballs ...
I believe I reacted poorly to the premise that some of those who assert expertise in this area tend to dismiss anyone who has a background only in what they define as "IT Security" as being unable to approach understanding -- let alone securing -- this technology.
Let me take a step back for a moment.
I'd like to get to the bottom of something regarding the alleged great divide between what is being described as diametrically opposed aptitude and experience required to secure "IT" infrastructure versus process control systems such as SCADA.
I notice a similar divergence and statements being made between those who specialize in web application security (WebAppSec) versus information or network security (InfoSec/NetSec.)
For example, WebAppSec is a discipline and specialty that some suggest requires a level of experience and expertise that goes beyond that of traditional "information security" or "network security" practitioners. It is suggested that in order to truly secure web applications, one generally requires programming experience, understanding complex data structures, databases, distributed application architecture, etc., at a very detailed level.
I think these statements are reasonable, but does it preclude an InfoSec/NetSec practitioner from contributing to effectively manage risk in a WebAppSec environment?
A network security practitioner can deploy a web application firewall and generally configure the solution, but the antagonists suggest that in order to provide a level of protection commensurate with the complexity and dynamics of the code which they are attempting to "secure," it cannot be done without an in-depth understanding of the application, it's workflow and behavior.
Again, in reflection, I'd say that's not an unreasonable assessment. However, WebAppSec and NetSec/InfoSec guys in mature organizations generally should know what they don't know and work together to implement a holistic solution across layers. It doesn't always work out that way, but in order to secure the WebApps, we can't ignore the underpinnings of the network or information security foundations, either.
It really should be a discussion, then, on how to unify complimentary approaches at various levels with an overall focus on managing risk. However, what I find is a downright civil war on the "IT" vs "SCADA" security front. I have to ask why?
Here's an excerpt from a post I found on Dale Peterson's excellent Digital Bond blog. It was a review of a SCADA security presentation at a CCC event in Italy regarding an introduction (of sorts) to SCADA security. The premise isn't really important, but I think that this does a good job of explaining some of the issues and sentiments that I am referring to:
Now here’s the good news: Asset owners, you don’t need to worry about
hackers. When they talk about “owning critical infrastructure”, they’re
just sharing their wildest dreams. In reality, they have nothing in
their hands. Zero. Nada. Niente. It will take several more years until
the hacker community has learned to master various flavours of PLCs
with their different protocols and vulnerabilities. It will take
further years until they get to things like OPC and furnish advanced
attack methods against it. And by the time they come up with decent
exploits for the various SCADA applications that we use today, most
CxOs will already be retired. We have heard over and over again that
the IT folks aren’t particularly good at securing SCADA environments.
Guess what, they aren’t good at attacking them either. However our
hackers do think nobody will notice because the stuff is all so
complex. That’s what I call “insecurity by obscurity”.
This whole notion of "it's so complex and so few people know anything about it so we have nothing to fear" seems to be the point of divide.
There's another really telling post on Dale's site (authored by him) titled "Firewalls are easy, control systems are hard" wherein the following inaccurate premise is painted which reduces the scope of the entire infosec/netsec profession down to a five-tupule in a basic packet filtering firewall:
One of the common refrains heard again at ISA Expo is that IT
firewalls are too difficult to configure and deploy. Several
presenters, especially those promoting field security appliances,
mentioned this, and it seemed to be generally accepted. While I’m all
for simplicity and credit the vendors for trying to ease deployment,
firewalls are simple compared to the deploying PLC’s, defining points
in the SCADA database, developing displays, control loops, and the
myriad of other detailed configuration required to make a control
system work.
A firewall ruleset is as simple as defining rules by source IP,
destination IP and port. Since communication in control systems is
limited as compared to the corporate network, the ruleset is usually
very small.
How simple is that compared to monitoring and controlling a complex
process distributed over a plant or large part of the country with 5000
points or 100,000 points? I was introduced to control systems in 2000
and have worked on a large number of SCADA and DCS in a variety of
industry sectors and I still marvel at the effectiveness and attention
to detail in these systems. There is nothing in firewall or any other
IT security system configuration that comes close to the complexity in
configuring and deploying control systems
That maybe true in an SME/SMB network, but the reality is now that firewalls in a large enterprise (which is a much more reasonable comparison) are just a small piece of the puzzle. Endpoints numbering in the thousands (if not tens of thousands) which run hundreds of application combinations aren't exactly chopped liver to secure. Add in Web Application Firewalls, Database Monitoring, Encryption (at rest, in motion,) IDS, IPS, Proxies, A/V, URL Filtering, Anti-spam, NBAD, SIEM, etc. and it just gets more complex from there.
If life were as simple as deploying a firewall and firing off a five-tuple ruleset, we wouldn't be in this pickle.
Regardless of whether a NetSec/InfoSec practitioner knows in-depth details regarding implementing PLC's/RTU's or the inner-workings of the IEC61131-3 block programming language is neither here nor there because it's only one piece of the puzzle.
Many InfoSec/NetSec practitioners don't have expertise in SQl/pSQL, but they work with the DBA's to secure databases, right?
Once these systems are interconnected to an IP-enabled network, it requires cooperation up and down the stack. InfoSec/NetSec pro's need to become SCADA-aware and SCADA pro's need to stop suggesting that this technology is just so complex and overwhelming that it's beyond our ability to effectively collaborate and that "firewall jockeys" just can't understand.
The reality is that the bad guys look for the weakest link in the chain. Will they attack complex protocol stacks and programming languages first? No, they'll go after the low-hanging fruit like poorly-configured/secured end-nodes, bad perimeter controls and general user-driven crap like we see in the rest of the world. They won't need to even spell PLC.
We need the same level of information sharing and respective skill set cross-pollinization in this regard instead of squaring off like it's a battle between us versus them.
/Hoff
Just when you get out, they pull you back in...
Oh gosh, where do I begin Chris?
What do the first letters of SCADA stand for? Supervisory Control.
A real SCADA system doesn't issue direct controls. It issues Supervisory Controls. There should be no time critical control loops in SCADA. In other words, we have vulnerabilities. But they won't destroy anything right away. We engineers know better than to trust complex software.
Most good design practice is based upon graceful degradation. In other words, we don't send a command to open a valve. We send commands to change the pressure differential setpoint. A local controller takes care of the rest. There are sanity checks in the local controller.
You could send commands to the field that would screw things up. But most people would notice and we'd take action. Keep in mind, that while our operation is very careful and deliberate, the distribution system was built for some wild extremes including pipe breaks, extreme weather, communcation outages, and vandalism. A successful attack would require intimate knowledge of where the real vulnerabilities are.
Are you an expert at water utilities too?