Well I've done security audits for these systems and well lets see here:
>>> The long story short is that most of these installations are physically protected from intrusion.
Dude; I've done security audits on pipe-lines and electric power grids. Just because a substation in the middle of time-buck-two has a lock on the door doesn't mean the lock actually gets used.
>>> First rate firewalling,...
A huge percentage of firewalls deployed even by pros have at least 1 large error in them.
( http://csdl2.computer.org/persagen/DLAbsToc.jsp?re sourcePath=/dl/mags/co/&toc=comp/mags/co/2004/06/r 6toc.xml&DOI=10.1109/MC.2004.2 )
And you obviously haven't developed SCADA software long-enough to realize that on the average Plant-floor, the knowledge required to properly construct and deploy a firewall just isn't there.
The rift between the "Scada Engineering" crowd and the "IT" crowd is larger than you think.
>>> and in most cases, complete seperation of internet and operations systems are in place.
Oh wow... not directly connected to the Internet. Hmmm, that's a tough one, Not!
On average, I've found in security audits on site, 50% more network access/entry points than what the companies security officer knew about.
And separation between Control and Enterprise network, you're blessed if you have a Cisco Firewall as protection.
(Until the 3am Engineer puts in the remote dial-in modem completely screwing over your cooperate security )
>>> Physical alarms and access controls, id badges,
Amazing how you can audit the physical access controls, simply with kind-words and a smile. (Thank you Mr Mitnick)
>>> and real security guards do the rest.
Yeah, 15 to 20 security guards, one some facilities covering 10 square miles.
>>> I am not naive enough to suggest that any such situation is 100% perfect,
Good, shows you may have learned something while "Developing Scada Software"
>>> but at the very least, we are not talking about script kiddies.
The problem that I've found, is that we're not even putting in enough to stop the script-kiddies.
When a simple port-scan of a Scada device may "brick it" (Brick It: send it back to manufacture to get replaced) think what even script-kiddies can do.
>>>If someone has a real reason or agenda to break into these systems, and enough money and skillful crackers, they will get in.
You don't need money, nor skillful crackers. In the last stages of the "World Wide War-drive" effort of a year or two back, they started to get Wireless Scada networks being reported.:-)
>>> For example, WiFi ethernet networks are almost never used in these types of systems
Dude, they don't have to be used directly on the Control-Network. With the number and types of connections between Control Network and enterprise growing, the hacker just needs to find 1.
I've see and heard first hand accounts of Security professionals doing security audits on the Enterpise network and finding themselves with access to control network gear.
One particular chap, did an audit of a Cookie factory's Office network, and his scanner tool found a hole in the Control network firewall that resulted in 1million in wasted cookie dough.
Now wireless use on these systems; have you had your head in the sand for the last year or 2 ? Get real! It's the typical flood of technology again, easy of use before any thought of the security implications.
>>> -- that doesn't have the engineering necessary for this kind of data. Instead, proprietary solutions with microwave dishes, and other forms of FCC/CRTC licensed data radios are used.
>>> While proprietary != secure, it does mean that a wardriver looking for an open access point isn't equ
I to read the Forbes article, but I can approach it from a unique view point.
For the past 5 years I have been doing research work on SCADA or control system security. Some of the research findings are astounding. No one can die if a hacker port scans a printer and ruins your print job, but people can die if a hacker port scans some SCADA devices and knocks them offline.
Here's why;
Back in the good-old-days most of the SCADA/Control system networks were isolated, proprietary, and in general a real pain in the ass to get to let alone do anything with. With the Internet explosion, along comes a push from the Marketing departments, and management to integrate all system. The old days everything was serial... now they must become "ethernet enabled". Why ? Because they want to know what's coming off the assembly line, right now!
Law of supply and demand; customers demanded it, equipment vendors tried to supply it. Note; tried. Think about it people, you have equipment manufactures that have been living in there own little world for 30-40 years, now being asked to hook up to standard office style infrastructure, integrate and play well with others. Unfortunately, most equipment manufactures simply took their serial protocols from their proprietary network, wrapped the data frames up in TCP and called it an afternoon.
Serial style protocols with little to no authentication, traveling over a wire and hitting a device with as cheap an ethernet to serial converter as money can buy. Yes folks there's nothing like doing a security audit and knowing you could launch a DoS attack on you clients network with a 9600 kbps modem:-) why ? Cause that's all the poor little device's moto entry level Mac Classic CPU and handle while still running it's production process logic.
Companies/SCADA equipment users themselves are also to blame for the security shambles that SCADA/Control network. Along with in "integration push", came this novel thing called the web. And wouldn't it be nice to use a web-browser to check you production devices status, and control it? Problem being, this production device was design and manufactured before the web craze took off.
Side Note: One of the biggest differences between SCADA/Industrial networks and the office/admin style networks; Average equipment life in the SCADA network can easily be 15-20 years.
Try squeezing an embedded webserver onto a piece of equipment from the late 80's. Not much memory, storage, or processing power to play with. Somethings got to go; might as well be those pesky extra checks on the network data coming in:-) . These companies can't totally blame there Control Process Engineers. Those guys know their control gear, not network security. They really need people whom have their feet planted firmly in both worlds.
If you thought that the vulnerability window between Microsoft-bug fix and application of the patch was bad; at least it can now be measured in days, or months. In the SCADA environment, I've seen and heard deployment and fix estimates of several years.
Fortunately; a large number of the major SCADA equipment vendors have woken up and smelled the coffee. Within the last 2 years, there's been an explosion of interest in actually fixing the problem,
in conclusion;
Is it as bad as Forbes makes it out to be ?
In some areas, it's better, in others, far worse.
Slashdot Mirror
Well I've done security audits for these systems and well lets see here: >>> The long story short is that most of these installations are physically protected from intrusion. Dude; I've done security audits on pipe-lines and electric power grids. Just because a substation in the middle of time-buck-two has a lock on the door doesn't mean the lock actually gets used. >>> First rate firewalling, ...
A huge percentage of firewalls deployed even by pros have at least 1 large error in them.
( http://csdl2.computer.org/persagen/DLAbsToc.jsp?re sourcePath=/dl/mags/co/&toc=comp/mags/co/2004/06/r 6toc.xml&DOI=10.1109/MC.2004.2 )
And you obviously haven't developed SCADA software long-enough to realize that on the average Plant-floor, the knowledge required to properly construct and deploy a firewall just isn't there.
The rift between the "Scada Engineering" crowd and the "IT" crowd is larger than you think.
>>> and in most cases, complete seperation of internet and operations systems are in place.
Oh wow ... not directly connected to the Internet. Hmmm, that's a tough one, Not!
On average, I've found in security audits on site, 50% more network access/entry points than what the companies security officer knew about.
And separation between Control and Enterprise network, you're blessed if you have a Cisco Firewall as protection.
(Until the 3am Engineer puts in the remote dial-in modem completely screwing over your cooperate security )
>>> Physical alarms and access controls, id badges,
Amazing how you can audit the physical access controls, simply with kind-words and a smile. (Thank you Mr Mitnick)
>>> and real security guards do the rest.
Yeah, 15 to 20 security guards, one some facilities covering 10 square miles.
>>> I am not naive enough to suggest that any such situation is 100% perfect,
Good, shows you may have learned something while "Developing Scada Software"
>>> but at the very least, we are not talking about script kiddies.
The problem that I've found, is that we're not even putting in enough to stop the script-kiddies.
When a simple port-scan of a Scada device may "brick it" (Brick It: send it back to manufacture to get replaced) think what even script-kiddies can do.
>>>If someone has a real reason or agenda to break into these systems, and enough money and skillful crackers, they will get in.
You don't need money, nor skillful crackers. In the last stages of the "World Wide War-drive" effort of a year or two back, they started to get Wireless Scada networks being reported. :-)
>>> For example, WiFi ethernet networks are almost never used in these types of systems
Dude, they don't have to be used directly on the Control-Network. With the number and types of connections between Control Network and enterprise growing, the hacker just needs to find 1.
I've see and heard first hand accounts of Security professionals doing security audits on the Enterpise network and finding themselves with access to control network gear.
One particular chap, did an audit of a Cookie factory's Office network, and his scanner tool found a hole in the Control network firewall that resulted in 1million in wasted cookie dough.
Now wireless use on these systems; have you had your head in the sand for the last year or 2 ? Get real! It's the typical flood of technology again, easy of use before any thought of the security implications.
>>> -- that doesn't have the engineering necessary for this kind of data. Instead, proprietary solutions with microwave dishes, and other forms of FCC/CRTC licensed data radios are used.
>>> While proprietary != secure, it does mean that a wardriver looking for an open access point isn't equ
I to read the Forbes article, but I can approach it from a unique view point.
... now they must become "ethernet enabled". Why ? Because they want to know what's coming off the assembly line, right now!
:-) why ? Cause that's all the poor little device's moto entry level Mac Classic CPU and handle while still running it's production process logic.
:-) . These companies can't totally blame there Control Process Engineers. Those guys know their control gear, not network security. They really need people whom have their feet planted firmly in both worlds.
For the past 5 years I have been doing research work on SCADA or control system security.
Some of the research findings are astounding. No one can die if a hacker port scans a printer and ruins your print job, but people can die if a hacker port scans some SCADA devices and knocks them offline.
Here's why;
Back in the good-old-days most of the SCADA/Control system networks were isolated, proprietary, and in general a real pain in the ass to get to let alone do anything with. With the Internet explosion, along comes a push from the Marketing departments, and management to integrate all system. The old days everything was serial
Law of supply and demand; customers demanded it, equipment vendors tried to supply it. Note; tried. Think about it people, you have equipment manufactures that have been living in there own little world for 30-40 years, now being asked to hook up to standard office style infrastructure, integrate and play well with others. Unfortunately, most equipment manufactures simply took their serial protocols from their proprietary network, wrapped the data frames up in TCP and called it an afternoon.
Serial style protocols with little to no authentication, traveling over a wire and hitting a device with as cheap an ethernet to serial converter as money can buy.
Yes folks there's nothing like doing a security audit and knowing you could launch a DoS attack on you clients network with a 9600 kbps modem
Companies/SCADA equipment users themselves are also to blame for the security shambles that SCADA/Control network. Along with in "integration push", came this novel thing called the web. And wouldn't it be nice to use a web-browser to check you production devices status, and control it? Problem being, this production device was design and manufactured before the web craze took off.
Side Note: One of the biggest differences between SCADA/Industrial networks and the office/admin style networks; Average equipment life in the SCADA network can easily be 15-20 years.
Try squeezing an embedded webserver onto a piece of equipment from the late 80's. Not much memory, storage, or processing power to play with. Somethings got to go; might as well be those pesky extra checks on the network data coming in
If you thought that the vulnerability window between Microsoft-bug fix and application of the patch was bad; at least it can now be measured in days, or months. In the SCADA environment, I've seen and heard deployment and fix estimates of several years.
Fortunately; a large number of the major SCADA equipment vendors have woken up and smelled the coffee.
Within the last 2 years, there's been an explosion of interest in actually fixing the problem,
in conclusion;
Is it as bad as Forbes makes it out to be ?
In some areas, it's better, in others, far worse.
Cheers
Yogi