SCADA Security and the "Most Monumental Non-Nuclear Explosion and Fire"
You probably have to be of a certain age to remember that the Internet itself
came about as a U.S. defense project to create a distributed information network
that would still function even if parts of it were destroyed. Let me brag that
I have in fact *heard* of SCADA before, but temper that by saying that I knew
little of it and appreciate frequent guest-commentator J'e St Sauver asking us,
this week, to think about this other aspect of national security that apparently
hasn't kept up with the Internet.
-----------
SCADA Security and the "Most Monumental Non-Nuclear Explosion and Fire"
By J'e St Sauver
University of Oregon Computing Center
Like Cliff Claven (the jovial factoid-sharing postal carrier of the syndicated
television comedy, "Cheers"), I'm easily enthralled by trivia. For
example, I bet you didn't know that Hells Canyon, location in remote northeastern
Oregon, is North America's deepest river gorge, did you? Well, it is... see:
http://www.fs.fed.us/hellscanyon/overview/index.shtml
Now that you know my attraction to trivia, you can imagine my reaction when
I came across news reports of a Siberian explosion in 1982, an explosion that
was said to have been the "most monumental non-nuclear explosion and fire
ever seen from space." This incident was first disclosed by Thomas Reed,
Ronald Reagan's Secretary of the Air Force, in his new book, At the Abyss:
An Insider's History of the Cold War (Presidio Press, March 2004, ISBN 0891418210).
According to published reports, (see http://www.washingtonpost.com/ac2/wp-dyn?pagename=article&node=&contentId=A10432-2004Feb26—Found=true
) the United States arranged for the Soviets to receive intentionally flawed
process control software for use in conjunction with the USSR's natural gas
pipelines. Reed stated that "The pipeline software that was to run the
pumps, turbines, and values was programmed to go haywire, after a decent interval,
to reset pump speeds and valve settings to produce pressures far beyond those
acceptable to pipeline joints and welds." The result? A three-kiloton blast
in a remote area of Siberia in 1982, which, only by some miracle, apparently
didn't result in any deaths. (For context, the Halifax Fire Museum lists the
massive 1917 Mont Blanc ship explosion in the Halifax Harbor at a force of 2.9
kilotons.)
As with any sort of covert operation, it is hard to know for sure what really
happened, and what's disinformation. For example, a senior KGB veteran, Vasily
Pchelintsev, has publicly stated that while a gas pipeline explosion did occur
in 1982, it was the result of poor pipeline design and construction flaws, and
was a minor incident that was rebuilt in "one day." (see the English
language story at http://www.themoscowtimes.ru/stories/2004/03/18/014.html
)
Regardless of whose version of the Siberian gasline explosion story you believe,
by now you may be asking, "What d'es all this have to do with IT Trends?"
The answer is simple: While higher education IT managers have been worried
about business system-related issues, such as viruses and worms infecting office
computers or swamping networks and servers, there's a additional area of cyber
security, a hugely important area of cybersecurity, that we've been ignoring,
and that's SCADA security. (But if you're like most IT professionals, even most
IT security professionals, you've never even heard the word "SCADA"
till now.)
SCADA stands for "Supervisory Control and Data Acquisition," and
consists of the software, devices, and networks that collectively control the
world's power grids, gas pipelines, chemical plants, transportation systems,
and other national critical infrastructure.
There's ample evidence that SCADA security is a hot area right now (no gas
pipeline-fire-related puns intended); for example, note:
o The General Accounting Office has just released a 47-page report entitled
"Critical Infrastructure Protection: Challenges and Efforts to Secure Control
Systems," GAO-04-354 (http://www.gao.gov/cgi-bin/getrpt?GAO-04-354
) this past March, which concluded that "The systems that monitor and control
the sensitive processes and physical functions of the nation's critical infrastructures
are at increasing risk from threats of cyber attacks" and that improving
the security of control systems against cyberattack should be a "high priority."
o The Chairman of the House Subcommittee on Technology, Information Policy,
Intergovernmental Relations and the Census, Rep. Adam Putnam (R-FL) has been
publicly quoted as saying that the lack of a national strategy to deal with
SCADA system security makes the nation "undeniably vulnerable" to
cyberterrorism, and that "Today's SCADA systems have been designed with
little or no attention to computer security." (March 31, 2004: http://www.computerworld.com/securitytopics/security/story/0,10801,91790,00.html
)
We understand that those Washington DC folks are talking about strategic national
vulnerabilities, and that you might (perhaps appropriately) wonder whether those
"big picture" vulnerabilities are really relevant to us in higher
education, as opposed to powerline operators or refinery administrators sitting
in some control room. I believe the answer is yes, if only for three reasons:
First, and perhaps most importantly, we should be teaching our students about
SCADA security as part of our network security education efforts. There is much
we need to learn collectively about SCADA, and while SCADA systems are definitely
"their own animal," there are still many lessons from enterprise network
security that can be usefully ported to the SCADA arena.
Second, SCADA issues really are something that will be of direct local pragmatic
relevance to each of us, if only because each of our campuses have SCADA-controlled
and monitored local systems. (You may not know it, but trust me, they're out
there).
Third, and perhaps most importantly, we, as opinion leaders, have a burden
to shoulder: We need to put SCADA security on the national center stage. If
we don't speak up and make sure that folks pay attention to SCADA-related issues,
there will come a day when we will collectively wish we had.
I wish I could give you a SCADA tutorial in a single brief column, but I can't.
What I can do is give you some starting points. Everyone, each and every one
reading this, should review "21 Steps to Improve Cyber Security of SCADA
Networks," an excellent and very approachable booklet written by the Department
of Energy
( http://www.ea.d'e.gov/pdfs/21stepsbooklet.pdf
).
Assuming you want to go beyond that (and you should), the first thing you should
know is that while many legacy SCADA systems were built around closed proprietary
protocols, the modern trend is to use MODBUS (see http://www.modbus.org/)
or FIELDBUS (http://www.fieldbus.org/),
both comparatively simple open protocols, increasingly deployed over TCP/IP
ethernet-based networks. To understand SCADA security, begin by understanding
MODBUS and FIELDBUS.
As you do, you'll see that these are very simple protocols. Because security
hasn't historically been a high priority, and because there's a very real fear
that security measures may inadvertently result in a loss of positive control
during a critical incident, what you'll see will remind you of where typical
campus network security was five or ten years ago. (For example, end-to-end
encryption is still exceedingly rare in the MODBUS and FIELDBUS world, and MODBUS-aware
firewalls, except for the open source MODBUS firewall at http://modbusfw.sourceforge.net/
, are still equally scarce).
Or consider a couple of items from GAO-04-354 (pp. 18):
"…existing security technologies, as well as strong user authentication
and patch management practices, are generally not implemented in control systems
because control systems usually have limited processing capabilities, operate
in real time, and are typically not designed with cybersecurity in mind…"
and
"…complex passwords and other strong password practices are not always
used to prevent unauthorized access to control systems, in part because this
could hinder a rapid response to safety procedures during an emergency. As a
result, according to experts, weak passwords that are easy to guess, shared,
and infrequently changed are reportedly common in control systems, including
the use of default passwords or even no passwords at all…"
Not very reassuring, is it? We cannot let our critical infrastructure be deployed
this way. If you wouldn't let the PCs your campus uses for word processing get
deployed with that sort of security, we cannot as a nation run our critical
SCADA cyberinfrastructure that way either. We need to harden our SCADA systems
now, unless we want to face an "abyss" that would make Hells Canyon
look like a crack in the sidewalk.
J'e St Sauver, Ph.D. (j'[email protected]) is the director of user services and network applications at the University of Oregon Computing Center.
----------------------------
This sounds like one more call for IT managers to make sure they're in regular
communication with the folks who maintain that other infrastructure, you know,
the physical infrastructure. There are a lot of places where the information
infrastructure and the physical infrastructure meet, and it sounds like SCADA-type
issues might arise there. Thanks, J'e.
