Slashdot Mirror
Researcher Publishes Industrial Complex Hack
snydeq writes "Security researcher Kevin Finisterre has published code that could be used to take control of computers used to manage industrial machinery, potentially giving hackers a back door into utility companies, water plants, and even oil and gas refineries. The code exploits a flaw in supervisory control and data acquisition software from Citect. The vendor has released a patch and risk arises only for systems connected directly to the Internet without firewall protection. Finisterre, however, sees the issue as indicative of a 'culture clash' between IT and process control engineers, who are reluctant to bring computers off-line for patching due to the potential havoc wreaked by downtime. 'A lot of the people who run these systems feel that they're not bound by the same rules as traditional IT,' Finisterre said. 'Their industry is not very familiar with hacking and hackers in general.'"
If you hook up a device to the internet without any firewall protection, you deserve what you get.
The vendor has released a patch and risk arises only for systems connected directly to the Internet without firewall protection.
Why would you have critical systems like that directly connected to the 'Net anyways?
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
I don't care WHAT the reasons for connecting them to the Internet are.
The fact that it allows anyone in the world, anywhere, anytime, a chance to attack your systems is the only reason needed to refuse that.
...a standard cell phone will let you pretty much instantly hack and control anything in the country except for the utilities. For those, you need to go to 2 different locations that control all the utilities in the country.
That movie had the "Mac guy" so I totally trust it.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
or has good lawyers, because I assume releasing such a tool to the public could get Finisterre into a lot of legal trouble. I've read that utility companies don't really like being screwed with.
Part of the hardcore faithful who believed in Apple long before it was cool again to do so
" 'Their industry is not very familiar with hacking and hackers in general."
The policy of most utility plants is to never connect any type of machinery control to the internet. If you have left yourself open like this, you are not following industry practices.
Even those who arrange and design shrubberies are under considerable economic stress at this period in history.
At the place I did the work for, the control systems were completely isolated from the internet. They sit on their own network and only talk to each other. They are all running Windows Server 2003 on HP Proliant ML370s with redundant everything (RAID drives, power supplies, UPSes, etc). The closest those things get to communicating with the outside world is when they download their data to a historian server on the other side of a DMZ link. It is a one way connection to the historian server. The historian is then referenced when people offsite need to know what is going on at the plant. The only way to connect to the historian is with VNC from one specific IP/MAC.
Enough of the security tangent. The point I was originally trying to make is that most industrial machinery doesn't need to be patched. It runs one or two software applications that do a specific thing. There is absolutely no reason to touch the box once it is up and running. Security in an industrial environment needs to be handled at the physical/network layer, not at the box. Why does the hardware running your valves need internet access? Why does a box running a CNC machine need internet access?
"who are reluctant to bring computers off-line for patching due to the potential"
no shit? of course they are, an and industrial machine should ahve to come down for patching.
This is why Windows should not be used in 24/7 industrial work.
Computers need to live up to the needs of the industrial machines they serve, not the other way around.
The Kruger Dunning explains most post on
Security researcher Kevin Finisterre has published code that could be used to take control of computers used to manage industrial machinery, potentially giving hackers a back door into utility companies, water plants, and even oil and gas refineries.
Thank goodness for this security researcher. I hope that those who have failed to patch their systems will soon realize that they should have spent some consulting money on Kevin Finisterre. That would have been a wise investment. Instead, they were fools, saved some money, and now their nuclear plant leaked shit all over the place.
Dumbasses. Next time, please spend $10,000 on Kevin Finisterre. You'll be happy you did.
that blew up a Russian gas facility with the force equal to a small nuke.
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
And who are you? Seriously. Why is your opinion of what is "critical" worth anything in this discussion?
And the cost of hiring those people vs the cost of cleaning up after an attack? Skipping security is ALWAYS cheaper. As long as you never consider the cost of an attack.
#1. ATM's. No. They were not originally connected to the Internet.
#2. Driving license. So what? That would catch up to you after the traffic tickets were entered into their system.
#3. Corporate VPN's. We're talking critical systems here.
Wrong. There is access to them without having them connected to the Internet. Just as it was back in 1990.
All of your reasons come down to "cheaper".
"Cheaper" should not have more weight than "secure".
It's a mixed bag. Some (older GE Fanuc PLCs for example) have zero security features, and only have a telnet daemon wide open to the world. The obvious answer is to bitch at the vendor and mitigate it with ACLs or some such, but really you'd have to know something about what you're hacking at to force it to do anything more than lock up, which might be bad, but generally is more of an inconvenience to a worker on the floor since all mission critical environments should have people standing by in such a case with the ability to manually override.
To my knowledge there's only been one real targeted SCADA hack that caused damage, and he had inside information. Don't get me wrong, I'm all for increasing security in SCADA environments, but the biggest hurdle isn't technical; it's political. Most SCADA environments that I've seen have been set up by electricians that programmed the SCADA devices but know pretty much nothing about IT (FYI, there's a lot of Linksys gear out there). They're usually paid overtime to work on the SCADA network and they see IT personnel as a threat to their livelihood. Someone I know was threatened with a screwdriver for just trying to replace a router.
"Powers. I have them."
I work in the Industrial Network Security sector.
This guy has not won any favors here.
The Industrial network sector is not like the typical IT department where an exploit is found and a fix can be pushed out within days.
For industrial networks, even if a patch were immediately available, some companies would not be able to fully deploy the patch to all their facilities for 1-2 years.
that could be us? our legacy to our children?
'The current rate of extinction is around 10 to 100 times the usual background level, and has been elevated above the background level since the Pleistocene. The current extinction rate is more rapid than in any other extinction event in earth history, and 50% of species could be extinct by the end of this century. While the role of humans is unclear in the longer-term extinction pattern, it is clear that factors such as deforestation, habitat destruction, hunting, the introduction of non-native species, pollution and climate change have reduced biodiversity profoundly.' (wiki)
greed, fear & ego are unprecedented evile's primary weapons. those, along with deception & coercion, helps most of us remain (unwittingly?) dependent on its' life0cidal hired goons' agenda. most of yOUR dwindling resources are being squandered on the 'wars', & continuation of the billionerrors stock markup FraUD/pyramid schemes. nobody ever mentions the real long term costs of those debacles in both life & the notion of prosperity, not to mention the abuse of the consciences of those of us who still have one. see you on the other side of it. the lights are coming up all over now. conspiracy theorists are being vindicated. some might choose a tin umbrella to go with their hats. the fairytail is winding down now. let your conscience be yOUR guide. you can be more helpful than you might have imagined. there are still some choices. if they do not suit you, consider the likely results of continuing to follow the corepirate nazi hypenosys story LIEn, whereas anything of relevance is replaced almost instantly with pr ?firm? scriptdead mindphuking propaganda or 'celebrity' trivia 'foam'. meanwhile; don't forget to get a little more oxygen on yOUR brain, & look up in the sky from time to time, starting early in the day. there's lots going on up there.
http://news.google.com/?ncl=1216734813&hl=en&topic=n
http://www.nytimes.com/2007/12/31/opinion/31mon1.html?em&ex=1199336400&en=c4b5414371631707&ei=5087%0A
http://www.nytimes.com/2008/05/29/world/29amnesty.html?hp
http://www.cnn.com/2008/US/06/02/nasa.global.warming.ap/index.html
http://www.cnn.com/2008/US/weather/06/05/severe.weather.ap/index.html
http://www.cnn.com/2008/US/weather/06/02/honore.preparedness/index.html
http://www.nytimes.com/2008/06/01/opinion/01dowd.html?em&ex=1212638400&en=744b7cebc86723e5&ei=5087%0A
http://www.cnn.com/2008/POLITICS/06/05/senate.iraq/index.html
http://www.nytimes.com/2008/06/17/washington/17contractor.html?hp
http://www.nytimes.com/2008/07/03/world/middleeast/03kurdistan.html?_r=1&hp&oref=slogin
http://biz.yahoo.com/ap/080708/cheney_climate.html
http://news.yahoo.com/s/politico/20080805/pl_politico/12308;_ylt=A0wNcxTPdJhILAYAVQms0NUE
http://news.yahoo.com/s/nm/20080903/ts_nm/environment_arctic_dc;_ylt=A0wNcwhhcb5It3EBoy2s0NUE
is it time to get real yet? A LOT of energy is being squandered in attempts to keep US in the dark. in the end (give or take a few 1000 years), the creators will prevail (world without end, etc...), as it has always been. the process of gaining yOUR release from the current hostage situation may not be what you might think it is. butt of course, most of US don't know, or care what a precarious/fatal situation we're in. for example; the insidious attempts by the felonious corepirate nazi execrable to block the suns' light, interfering with a requirement (sunlight) for us to stay healthy/alive. it's likely not good for yOUR health/memories 'else they'd be bragging about it? we're intending for the whoreabully deceptive (they'll do ANYTHING for a bit more monIE/power) felons to give up/fail even further, in attempting to control the 'weather', as well as a # of other things/events.
http://www.google.com/search?hl=en&q=weather+manipulation&btnG=Search
http://video.google.com/videosearch?hl=en&q=video+cloud+spraying
dictator style micro management has never worked (
Dr. Steve Brule gave me a second start on life.
He can do it for you too!
Citect is not the only SCADA software company out there. They have a large market share, yes, but there are many other companies that author software for this market. This 'buffer overflow' affects only Citect software and none of the other company's offerings are affected. Yes there are some fools out there who will connect their systems directly to the `tubes, but there probably aren't as many as you would think. There are probably some vulnerabilities in other vendor software as well. But you know what, take a deep breath, take a break, and watch the blinking lights.
Sig this!
Firesale - call McClane.
management is stupid,
workers are stupid,
government is stupid.
the public is stupid.
now we got security 'researchers' who are stupid.
i think thats about as much stupid as the average industrial computer guy can handle.
why dont you just, while youre at it, make a skeleton key that can get into any industrial facility door, and sell it on ebay for 25 cents?
idiot.
I am a process engineer, and this can be a significant problem. I've seen large-scale equipment shut down because of computer viruses, much less full control exploits - the resulting cost to rush in an IT worker (not usually onsite) with a new box, the lost production time and resulting hash-over of the whole plant's network was astronomical, because a floor worker had figured out how to get into IE from the terminal, which was supposed to be disabled.
The implications of this may not be that far-reaching in terms of industrial loss, but with the myriad of different systems that could be conceivably controlled by the same workstation, there are definitely some scary possibilities. Frankly, though, if there were that many computers at risk, the security holes in Windows alone would have likely already resulted in their demise if they weren't behind a good firewall.
Quiz: True or False -- On a scale of 1 to 10, what is your middle name?
A CNC machine may need network access and the net work may hooked to the internet.
This is a lot like the network printers hack story that they have been used as hack points and the flaw was WITH THE SOFTWARE and not the OS.
Any even if you use Linux you still need to do the updates and update the software.
> The vendor has released a patch and risk arises only for systems connected directly to
> the Internet without firewall protection.
Such systems should not be connected to the Internet. Full stop.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
'A lot of the people who run these systems feel that they're not bound by the same rules as traditional IT,' Finisterre said. 'Their industry is not very familiar with hacking and hackers in general.'"
He's attempting to lay blame for these infrastructural issues at the feet of the engineering staff. What he doesn't understand is that engineering systems have very different operational requirements from running a server farm or a few thousand desktops. Engineers avoid IT like the plague, because IT people will come down on engineering systems like a ton of bricks, enforcing arbitrary company-wide standards regardless of the damage they do. For example, if you have a timing-sensitive real time process running on a PC, it may not be wise to put the Symantec Antivirus pig on that particular box. Yet I've seen that happen, usually without the person in charge of that equipment even being notified. Afterwards, everybody wonders what happened with something goes seriously wrong with a production process. IT's attitude in such cases is usually "we followed company policies. Not our fault." The hell it wasn't.
The reality is that IT misguided or ignorant departments are frequently a far bigger danger to process control and real-time data acquisition systems than any number of Chinese crackers. That's because they rarely make the slightest effort to accommodate the needs of the technical staff, and have often gone to extreme lengths to have upper management approve utterly Draconian policies that MUST be applied to ALL computers.
Engineers are often justifiably leery of having IT involvement in any of their projects. The consequence of that, of course, is that now you have people with no specific security training implementing remote communications. Of course, a lot of these problems could be ameliorated with some simple requirements such as "all off-site communications MUST be secured with a VPN" or something similar.
Ultimately, what it comes down to is communications being handled by conscientious, well-trained individuals that are open-minded and willing to accommodate the special needs of engineering systems. I can't tell you how rarely I've seen that happen.
The higher the technology, the sharper that two-edged sword.
That must get tricky when you talk about it.
Nerd rage is the funniest rage.
I work around a number of similar systems, and one trend I see as somewhat alarming is that they're increasingly showing up as Windows boxes with an ethernet port attached. I'm talking about things like industrial x-ray machines, industrial refrigerant control systems, PLC control systems for complex industrial machinery, all sorts of things that can go boom or otherwise cause death and dismemberment if they go sideways. It's not that Windows sucks per se, but rather that many of these systems are sent out by the vendor with documentation on how to set the thing up on the LAN and connect to it remotely, and then when I look at the machine itself, it almost always turns out to be a stock, under-patched Windows XP box with no anti-virus software and the firewall turned off. The software to manage the equipment itself is usually VB.NET (and yes, I do mean usually), and appears amateurish. So I've got this wide-open Windows XP machine that my controls engineers want put on the network so they can VPN in and talk to it remotely. Uh, let me talk to the vendor first. The vendors, if there's anyone there who actually claims to know anything about "computers," typically say don't modify the box or they won't support it, or offer dire warnings about how installing an antivirus package or enabling the firewall or patching the operating system will cause it to malfunction. It really is a clash of cultures, but I don't exactly blame the controls software people. I think they were simply sold a bill of goods: the notion that you can take a general-purpose OS, install it in your touchscreen panel machine, and look how easy .NET is to design and deploy your application! For people used to toggling the "STOR" switch on a PDP, this has got to be a long series of wet dreams come true.
Really, the problem (in my mind) lies in the concept of putting these things on a general-purpose operating system. It's designed to be all things to all people, when what is really needed is something that's damn good at doing one thing and doing it without falling over. Sure, air-gapping it from the network is also a good plan, but controls engineers have been so thoroughly inculcated in the notion that they can remote in to their equipment now (and have made that case to the honchos for long enough) that often the idea of disconnecting these systems is a non-starter.
That leaves the systems and network people with a few options, none of which really feel sufficient.
political_news.c: warning: comparison is always true due to limited range of data type
"Process control engineers, who are reluctant to bring computers off-line for patching due to the potential havoc wreaked by downtime" but if they don't then hackers are going to take over and cause potential havoc anyway. Sounds like catch 22.
Someone I know was threatened with a screwdriver for just trying to replace a router.
What's the big deal? Drink the screwdriver and then replace the router.
Some vendors of CAD/CAM software require each machine running their software to be able to communicate with a "license server" on your network before the software will run. If you buy a sitewide license for say, GibbsCAM, you need to designate a single box on your network as the "license server", and each workstation or machine running the package will "phone home" to the license server periodically to make sure that you have a valid license.
Remember "News for Nerds, Stuff that Matters"? Help make it a reality again! http://soylentnews.org
Someone needs to add the "scada" tag to this story.
One simple rule for its versus it's
If you hook up a device to the internet without any firewall protection, you deserve what you get.
We should be glad that people release these 'bugs' openly - I'm sure that this information would have made Mr. Finisterre a lot of money, if he approached the right (wrong?) person. Imagine what would happen with no firewall AND no public notification?
If you hook up a device to the internet, you deserve what you get. NOTHING long halts the truly determined.
EddieCurrents
Plain Fear mongering at work, nothing more. I have worked in Power Plants for 30 years now, from analog to digital, and he is so full of fear mongering and "what ifs" worse than a Long Island housewife. First, there being no money or "secrets" in hacking a power plant, why bother? If this was such a problem, then why don't we see it happening? Also, there is a huge cost on manpower, material, resources and lost revenue to take a powerplant down on someones fantasy security exploit, and those resources are much better spent on repair, and upgrades for efficiency and emissions. I use these systems daily, and they (unlike most computer systems available) work 24/7/365 going years without problems, quietly doing the job designed for, dumping data for engineers to study and just humming along nicely. Every now and then another fear monger comes along with new fantasy's of death and destruction if we don't drop everything and buy his/her service or patch of whatever snake oil he has for sale. Being engineers (practical, operating, not desk bound) we simply learn to ignore and move on, fixing what is broken and leaving what works alone. Our operating record speaks volumes for our work.
The national budget must be balanced. The public debt must be reduced; the arrogance of the authorities must be moderate
When you land a big juicy one, splurge a little and hire a couple of eager for work and somewhat experienced lawyers to negotiate the business proposals for disclosure with the affected utility companies. ;)
"Don't just think, think about it."
Proudly,
An Anonymous Coward
I developed an HMI using Citect, and for my needs it was significantly better than the alternatives. Actually, it was pretty excellent. But you wouldn't use it to control dangerous machines: it runs on Windows. :-) Supervisory Control and Data Acquisition is high-level: the user-friendly end of process control. We used Citect to control the machines that control the machines.
You could poke a button on Citect that said, "open this valve," but all Citect did was message an industrial PLC that performed all the safety calculations and bounds checks and actuated the relay, then sent the result back for Citect to display. Actually, a better example would be to poke a button to start the next phase of a run. You wouldn't use SCADA to open or close an individual valve much more than you'd invoke a single C function from a CLI.
I would argue that in fact the traditional rules of IT do not all apply to these SCADA systems. They are quite often single-purpose PCs that have little or no connection outside the plant floor. If they worked on commissioning day, they'll probably still work today. They don't need a lot of management. Not that machines don't get taken down for maintenance, but you don't want a surprise incompatibility in your software update keeping the system down longer than anticipated. Wreaks havoc on the supply chain. Actually, Citect can clone control stations (legitimately, not just 0wn3d), so you could do a phased deployment of patches without losing any capability; I was speaking more generally.
It is true, though, that process engineers I've known don't think much about network security. They're concerned about guarding against a china syndrome, so the important stuff is off the net and often talks to SCADA via RS-232. A hacker might steal data or stop the run, but probably couldn't make things go boom.
I work at a plant that uses SCADA systems, and where a break-in would be a national security incident and a colossal public safety nightmare. One of the systems engineers requested I allow remote control access from the Internet through our admin network, and eventually discovered that he'd plugged an air-gapped, un-patched win2k scada control pc onto our company admin network so some tech could dial in and do remote support out of shear laziness and lack of understanding of the risks - not to mention total disregard for policy. These systems need to be able to deal with that kind of stupidity, and I wish the process engineers could be made to appreciate the benefits of good IT systems management.
"Cheaper" should not have more weight than "secure".
This betrays almost unthinkable naivete. Cheaper always has weight. It's a question of overall system cost, and people tend to ignore non-obvious risk. Welcome to the human condition.
Ever go to any of those sites that tell you where your dollar bill has been? They have a place where you can put your bill's serial number, and see if anybody else has done the same. It's kinda fun!
But did you notice that there is NO SECURITY WHATSOEVER behind authenticating your possession of the dollar bill? That's OK, because the cost of compromise is unspeakably small - perhaps somebody will be annoyed... The cheapest solution, which is merely asking somebody to type something in, is plenty enough.
There's a formula at work here, something like this:
$CostOfCompromise*$LikelyhoodOfCompromise <> $CostofSecurity*$ReductionOfLikelyhood.
As long as the left side is "heavier" than the right side, you're doing the right thing. If you institute major security in an area where the cost of compromise is miniscule, you're wasting your money. Go for hookers and blow instead - at least you enjoy it!
If you don't invest significantly in security where the cost of compromise is high, or at least, the likelyhood of compromise is high, then you sure don't deserve your hookers and blow!
So, the right answer is proper risk assessment. Spend your money in areas where it'll do you some good. And be a cheap bastard if it really doesn't matter much!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
And it is cheaper still to have a drinking bird do your remote work.
If there was a previous Simpsons reference earlier in the thread, a more appropriate moderation would be "redundant".
Now where is my Tab
super lock down does not work that well and after it blows up a big job it will get canned so fast your head will spin.
Also going to the minimum will need a lot of testing to see if a app does not blow when it try's to use what was disabled and even then YOU STILL NEED TO DO THE UPDATES.
As some can use a hole in the system to be able to run code at the system level by passing the lock down.
I worked at a 100% remote plant for a short time. We were onsite during the day, but at night if the turbines needed to start they ran them from another state. At that time, the liklihood of turbines running at night wasn't very large, but it did happen once a week or so.
Even those who arrange and design shrubberies are under considerable economic stress at this period in history.
Relying on a firewall is a very poor security policy indeed, The nature of industrial control equipment is modularised / multi vendor/ and generally and integrated by barely adequate software. In most cases the software is not audited, uses no transport level encryption, and have simple (reliable) often human readable protocols and is rarely updated. In my over two decade experience in this field, little has changed security wise. The software mentioned in the article is almost ubiquitious in large control centres, sometimes sharing the same subnet as Windows based workstations. Documented breeches are uncommon, but everyone with any time in industry could tell you stories which could keep you awake at night. The problems that exist in normal IT are magnified greatly in an industrial environment due to huge pressure to continue production and minimise testing, as well as the large variety of disparate equipment engineers are expected to maintain.
I've seen the flip side of that scenario. We (engineering) designed, built and maintained a shop floor control system. It served our company for over a decade with no instances of malicious hacking. Although we were behind a firewall, we were subject to security reviews by the IT department as well as some black hat testing from within the firewall. Never been hacked. The system featured a modular, object oriented s/w architecture that could be updated on the fly from our integrated revision control system!
It suffered from one fatal flaw: It had been implemented on various flavors of Unix (we were looking at switching to Linux before IT stepped in). When our IT department made a play to take responsibility for all computing systems, one of the first things to go was anything not Windows. The system was ported, the shop has to put up with patch Tuesdays, BSODs and some clown caught switching the operator console wallpaper with an infamous Pamela Anderson/Tommy Lee photo. But, it now met the corporate computing architecture standard. And, per that standard, just like all the office desktops and Exchange servers, keeping up with vendor patches was deemed sufficient for security purposes.
Today, the only thing that protects it is the firewall. Engineers can easily bypass the revision control system (Source Safe, I believe) to make last minute patches. if anyone manages to get inside the firewall (a few botnets have made their way in) and finds this system, they could trash millions of dollars of product in a few minutes.
Have gnu, will travel.
How difficult would it be to write a simple domain scanning ocx,executable etc that fires
off a bunch of tcp modbus register writes...may take all of 10 minutes or so. Yes it could
do some serious damage if not cause bodily harm or death(think machine operators).Many of these
plc's on most networks are just directly connected without a ounce of security on them. Ever work
in a manufacturing facility? Most of this stuff is ladder programmed etc by engineers who
have no clue what tcp or modbus protocol even is, much less making it secure.
Got Code?
Actually in my opinion the SCADA PCs although vulnerable in many cases are not the best
way to attack these systems. It is much easier to just start firing junk into the registers
of the PLCS controlled or monitored by the SCADA systems. In many cases the controllers are just
hanging balls to the wind on the network. Anyone that has messed with them at the protocol level
knows that most of the protocols in use have little or no security functionality.
Got Code?
Seriously, more cracks are done INSIDE than from out. The major ones are from outside, but there a plenty of inside jobs.
From the article: "The system is composed by software installed on standard computer equipment running on commercial-of-the-shelf Microsoft Windows operating systems."
And that's the problem. It's not running on QNX, or VxWorks, or LynxOS, or MonteVista, or even Windows XP Embedded. With those systems, the system is usually built to have just the components needed to do the job, not with every gimmick Microsoft puts in their desktop OS.
And, of course, it's yet another buffer overflow, part of the defective-by-design semantics C and C++ use for arrays. (And yes, I know what I'm talking about.)
Here's the first result. http://www.cdi.org/terrorism/cyberdefense-pr.cfm
Then I assume that you are not familiar with RBAC systems like SELinux built in the kernel. In a "dangerous" environment where 1 minute of downtime is equal to 100k$'s, lockdown is the only way to go. Running as root or equivalent should never be allowed, period.
We can lock even root down to console-only access and have the user-servers loaded up from netboot and nsf mounted drives from the user-server. Roles based upon who the user is will grant access to what they need to do, and nothing more. All actions will be logged, and all critical decisions will be logged to a recording server. Why wouldn't we want to have users use dumb terminals? 2 commands can kill their session and lock them out.
Viruses will not exist, as we can literally prevent the user from executing anything, even in their home environment. Root, with other than console access, is yet another user.
I did my Master's thesis on SCADA, and it's entirely true--most of the industry is stuck somewhere in the early 80's, when unsecured modems, network lines, and radio (!) links seemed perfectly safe.
Media that can be recorded and distributed can be recorded and distributed.
-kfg
I'm more worried about hackers spoiling my coffee: http://it.slashdot.org/article.pl?sid=08/06/17/1941200
Someone needs to add the "scada" tag to this story.
I know humour is subjective and everything, but I'm surprised hardly anyone else has got the joke yet! For those who are still in the dark - in SCADA systems, a "tag" is kind of like a field that contains some data that needs to be written to or monitored.
E.g., if you were a water company and wanted to monitor tank levels, you would assign your tanks their own level tags - like TANK1_LEV, TANK2_LEV, TANK3_LEV... - each of which could then be queried for a given tank's current level.
Friends machine chop has a CAD machine in his office. CAM code gets carried on a floppy to the NC machine. The CAD box is not connected to the internet. The NC machine has had it's core memory replaced by an old laptop via the parallel port(plenty fast replacement for core in this application).
He also has a desktop machine connected to the internet for order taking, billing, porn(hey it's a machine shop!), etc.
Near as we've been able to figure by looking at the logs...here's what happened...
Visit to a .ru bride site got the internet machine compromised. It began talking to the CAD machine via IR ports and changed job specs. The night shift comes in, loads the new code to the NC machine. NC machine cranks out 12,000 Aluminum dildos which the Saturday morning shift dutifully packs up for shipment to .RU via fed ex.
Friend comes in Monday morning and realizes that his Bong order never got run and all his stock is on it's way to .RU in the form of Dildos.
Fortunately, there was a hang up at the airport and he was able to recover the material which being Aluminum was still worth 2/3 of what he had paid for the stock.
True story!!!!
"The system featured a modular, object oriented s/w architecture that could be updated on the fly from our integrated revision control system!"
Who in their right mind would upgrade a live control system, never mind connect to to the Internet, even behind a firewall
davecb5620@gmail.com
"I developed an HMI using Citect .. Citect to control the machines .. Citect .. Citect .. Citect .. Citect can clone control stations .. so you could do a phased deployment of patches ..."
davecb5620@gmail.com
"if you have a timing-sensitive real time process running on a PC, it may not be wise to put the Symantec Antivirus pig on that particular box .. IT's attitude in such cases is usually "we followed company policies. Not our fault .. Engineers are often justifiably leery of having IT involvement in any of their projects"
...
You're talking utter rubbish, if you don't mind me saying so. Who in their right mind would put a 'real time process' on a PC, it belongs on embedded hardware, as you would know, if you had the slightest clue what you were talking about
davecb5620@gmail.com
"firewalls can't protect against tunneling over most application protocols to trojaned or poorly written clients .. Tunneling ``bad''
things over HTTP, SMTP, and other protocols is quite simple and trivially
demonstrated. Security isn't ``fire and forget'' ..
..
In general, a firewall cannot protect against a data-driven attack--attacks in which something is mailed or copied to an internal host where it is then executed
A strong firewall is never a substitute for sensible software that recognizes the nature of what it's handling--untrusted data from an unauthenticated party--and behaves appropriately"
davecb5620@gmail.com
TacoMan what has a Ninja with a bucket on his head go to do with anything ? Oh, I see, it's an advert for 'stuff' to protect Microsoft Windows against security threats, as sold by .. the Microsoft corporation .. :)
davecb5620@gmail.com
If you hook up a device to the internet, you deserve what you get.
Yes, and if you walk to the supermarket, and get shot/run over/hit by a truck on the way ... well, you deserve what you get. No matter what... right?
What did THE SOFTWARE run on ? The OS is supposed to prevent amok SOFTWARE from interfering with other processes on the same OS ...
...
"Any even if you use Linux you still need to do the updates and update the software"
You don't ever update a live system, don't believe me, ask the LSE
davecb5620@gmail.com
"If this was such a problem, then why don't we see it happening?"
..
See here where a tree + a virus + someone switched-off-the-monitoring equipment-and-went-to-lunch, led to the blackout of August 2003
davecb5620@gmail.com
"The Industrial network sector is not like the typical IT department where an exploit is found and a fix can be pushed out within days"
Any typical IT dept, I've ever seen has to wait for the latest 'service pack', same as everyone else. Like, the Fax server goes down for no reason, and printers drop off the network for no reason, and we spend our time remaking Exchange profiles, that go corrupt for no reason.
davecb5620@gmail.com
"Some (older GE Fanuc PLCs for example) have zero security features, and only have a telnet daemon wide open to the world"
Is this it, the INGEAR GE FANUC PLC, and why does it run on ActiveX ? And who in their right mind would connect control gear to the Internet.
davecb5620@gmail.com
I've done a little bit of work with control systems (Honeywell) that are used to run a power plant. The author of the article is a bit disconnected from reality. You can't exactly just take one of those systems offline to patch it. Shutting the powerplant down is a complex operation that takes time. Starting it back up takes time.
Why do you need to shut things down to patch? The phone system, to take an example, is designed from the ground up to be redundant. Every component has an 'A' side and a 'B' side running in parallel.
If you need to do maintenance you bring down the 'A' side, do maintenance, and check that everything is working. Once you're sure everything went well, you do the maintenance on the 'B' side.
If you don't have this redundancy, what happens when your component fails? What happens if, after deployment, a serious bug is discovered? Seems kind of stupid not to have redundancy.
They are all running Windows Server 2003 on HP Proliant ML370s with redundant everything (RAID drives, power supplies, UPSes, etc).
Do you have multiple Proliants so that if one goes belly-up things will continue to work?
Security in an industrial environment needs to be handled at the physical/network layer, not at the box.
Until there's an insider attack. Or until Greenpeace breaks into your control centre.
Things need to be secure at all levels, cf., chain and weakest link.
In the industrial world, why would you patch a system that is working fine.
Until the politicians change the Daylight Saving Time rules on you, and you need to have your reporting system updated. Or, a year after deployment, a serious bug is found in the code.
Or the PC that everything is running on has capacitor that dries out and pops. Or something on the system's power supply shorts out.
My point is, I wouldn't want to put a patch on anything that was already working.
And the point of a lot of other people is that you can't predict when something will break, so if you're depending on a non-redundant component, you may be asking for a world of hurt.
This isn't even necessarily about patching, it's about simply being prepared. It's better to be redundant in many cases, even if you're not planning to patch, than have a non-redundant path in your system.
Until the politicians change the Daylight Saving Time rules on you, and you need to have your reporting system updated. Or, a year after deployment, a serious bug is found in the code.
In both of those cases though the system is not working fine - in the first because it no longer satisfies the requirements, and in the second because it never was in the first place, it just appeared to be.
I'm not arguing against patching when it is appropriate to do so, and would never argue against redundancy in critical systems - that's madness.
It's official. Most of you are morons.
From "Cisco IPS Active Update Bulletin: 09-11-2008"
The S356 Signature Update for IPS includes detection of this attach.
Until the politicians change the Daylight Saving Time rules on you, and you need to have your reporting system updated.
We found than changing the systems manually during idle time sufficed.
He who said 1,000,000 monkeys on 1,000,000 typewriters would eventually type the great novel, never saw an AOL chat room
Come on, they have known about this and yet they have not taken down their customer list.
http://www.citect.com/index.php?option=com_content&task=view&id=91&Itemid=148
Maybe someone should call them and tell them to fire their security staff. I mean, my god, has anyone done any risk assessments over there?
I were a customer listed on that page I would would be very concerned right now.
I'm a software engineer working on designing networked industrial controls. During some discussions with our IT people on wireless security issues I discovered that I knew more than they did (and I really didn't feel like I knew all that much). Among other things, they were convinced that LEAP was way more secure than PEAP.