Home > Uncategorized > Pushing Reset On the IT vs. SCADA Security Debate….

Pushing Reset On the IT vs. SCADA Security Debate….

Bigred
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

Categories: Uncategorized Tags:
  1. Jan
    January 23rd, 2008 at 21:18 | #1

    I think we have to thank Checkpoint for reducing the concept of firewalling to a five-tuple based on their oh-so-simple GUI in the mid-nineties when firewall admins were scarce and without a clue (yes, I know you could do much better stuff with FW-1, but hardly anyone has). Remember, we had really cool applicaton-layer firewalls before that (fwtk anyone? :)), and they are fortunately coming back to the mainstream. A WAF is just the peak of what we can do today in network access control, i.e. the most granular network access control technology currently available.
    Why can't we all just get along and understand that fundamentally, every application is more-or-less the same when it comes to securing it inside the network (i.e. minimize protocols, sanitize inputs, verify normality, maybe throw in a signature or two, etc.). The devil may be in scaling our solutions, or the current lack of WAF-like technology for arbitrary applications, but I would not really make any distinction between SCADA, the Web, or your future RPC protocol that someone will surely invent for Web 9.0.

  2. Jan
    January 23rd, 2008 at 21:27 | #2

    Before you all start flaming – I fully agree that network security guys should understand applications (in quite some depth) and their architectures. Based on this knowledge, you will be able to implement the most effective network defenses to the depth you require.

  3. January 24th, 2008 at 07:24 | #3

    Before you star lambasting the 'IT guys' in how dumb they may be, you are referring to a small number of 'whatever' people who don't give a crap, do only what's asked of them, and nothing more. Many 'old farts' (like me) *do* give a crap. Honestly, blame management for making stupid, crappy decisions about mixing IT networks with control systems' networks. Many times, it's because they don't understand (usually 90% of the time…*BING*), or it's a cost-savings measures (also…*BING*).
    I've worked for organizations that have control systems on the same network as their server farms, and their systems engineers were always complaining about network outages, etc.
    On the other side of the fence, most systems engineers usually know only ONE aspect of ONE product of ONE protocol, thinking its 'rocket science'. It ain't — sorry fellas. Many of them are a bunch of even 'older farts' getting ready to retire, had a certain usual way of starting things up, and kept their notes to themselves. If you should have ANYTHING to worry about, worry about these systems engineers *retiring* within the next several years, and taking their knowledge (and their personal notes) WITH THEM!!! That, to me, is something to be MORE concerned about.
    My 2 cents worth…and at today's prices, won't even buy you a piece of bubblegum any more (it's 5 cents now).

  4. January 25th, 2008 at 15:01 | #4

    As a person how has programmed a more than a few firewalls and PLCs (and DCS, RTU and so on) over the past 25 years I completely agree with your comments that comparing a small firewall to large control system misses the point. I see firewalls with ten rules and PLCs with ten rungs of logic and they are both easy to understand. Expand either to the size of a typical industrial enterprise and things get complex quickly. And while a firewall rule set can be as simple as defining five-tuple, it often isn't. Just try to dream up the "simple" rule set that works with multicast and NAT at the same time (both common in control systems). Or a five-tuple rule for OPC/DCOM/RPC…
    But more important, I see the IT vs. SCADA conflict as vastly overstated on both sides. Based on work we have done on some major oil companies control systems, 90% of the IT security skills, technologies and processes work well on the plant floor – it is the last 10 % difference that cause all the pain. And like you suggest, we need information sharing and cross-pollinization between the groups to address that 10% – if we don't things get ugly fast. In fact a few of us in the SCADA business even wrote an article in a control magazine on just this need to cooperate (http://www.isa.org/intech/20071205 ). The bottom line is that IT and SCADA needs to quit fighting each other and start to fight the real enemy…

  5. January 25th, 2008 at 15:20 | #5

    Thanks, Eric. Will go and read that article.
    I find it interesting that many of the folks who appear (and I'm not phrasing it this way to intimate they aren't) to be experts on the SCADA security side *come* from InfoSec/NetSec backgrounds.
    One might suggest that since they "understand" both sides they are more qualified to suggest that the concepts are so vastly different that InfoSec/NetSec folks can't understand them, or…
    …they're being hypocritical and spouting a bunch of FUD for some agenda that's not clear to me.
    Either way, I wanted to attend S4 and the latest SANS SCADA conference, but I had prior commitments but will get to one shortly to "catch up" since my last exposure was back in 2006.
    /Hoff

  6. NRC
    January 27th, 2008 at 05:53 | #6

    Hoff,
    Great article, spent a fair anount of time designing security systems for SCADA and process networks. One of the biggest challenges I found is many of these systems are from the Ark and effectively had an IP stack strapped on in a vein attempt to maintain "currency" in toddays networks. Some of the vendors struggled to give me information on how theire I{ process works – who initiated the connection etc – doesnt look good.
    We are soon to deploy our largest environment for process networks – will let you know how it goes 🙂
    NRC

  7. February 1st, 2008 at 09:14 | #7

    Hoff,
    The demographics of Industrial Integrators and most PLC Programmers is largely middle aged, white, males who have been at it on the scale of 15+ years. They are studly at understanding and "figuring out" a wide variety of industrial processes and generally consider themselves to be experts at everything. Considering safety issues and the field, they're king of their realm. The other important detail here is that in profit driven manufacturing, the mindset is that availability easily trumps the other security considerations.
    Now consider that the industrial software market in about the last 15 years has been comprised of mostly overpriced clunky crap (I'd like to see someone TRY to argue against that)- my guess is that much of it was written by industrial guys that know processes, but not software.
    Industrial networking has been historically proprietary (Does DH+ (Blue Hose) or DH485 mean anything to you?) – only recently has Ethernet really gained much ground, and they used to be mostly on closed networks.
    So integrators/industrial controls guys have been setting up the networks themselves – at about the skill level of a 13 year old "figuring it out" as he goes.
    Add "IT" to the mix who know nothing about controls and claim to know about the network. They really get in trouble trying to install a Service Pack or Windows Update that breaks the crappy HMI/SCADA software.
    So you get controls guys thinking IT's worthless, and IT guys thinking the controls guys know nothing about security (usually true, unfortunately).
    It's rough! The end users with the money demand more and more connectivity and remote capabilities. Industrial software is getting more and more "standard". IT will need to get involved, cause the crap ain't that complicated. "Years before they furnish attacks against complicated things like OPC"? Are you kidding – it's DCOM! Connecting to PLCs isn't rocket science – most don't use passwords. And controls guys or notorious for leaving modems with PCAnywhere or Gotomypc running on the SCADA development computer.

  1. No trackbacks yet.