Researcher Publishes Industrial Complex Hack 190
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.'"
Well (Score:4, Insightful)
If you hook up a device to the internet without any firewall protection, you deserve what you get.
Re:Well (Score:5, Insightful)
what do you get? internet herpes?
a firewall will protect your computer from many exploit attacks, but that's not a reason to rely solely on a firewall for protection.
running a system with a bunch of unpatched security vulnerabilities and simply relying on a firewall to protect you is just as foolish as connecting to the internet without a firewall. after all, what happens if the firewall fails, is bypassed, or has a security vulnerability of its own?
Re: (Score:2)
I'm sitting at work, where our firewall restricts internet access. Yet here I am, posting on Slashdot.
Firewalls are amazingly easy to bypass.
Re:Well (Score:5, Funny)
From the inside, certainly.
-:sigma.SB
Re: (Score:2)
They are much easier to circumvent from the inside, but I've yet to see a firewall that can't be breached.
Re: (Score:2, Interesting)
Re: (Score:2)
You don't see many firewalls do you? If I have a machine inside the firewall and it's not communicating with the outside world, as far as you, and a properly configured firewall is concerned, it doesn't exist. There's no established route from the firewall to the computer because the firewall doesn't need to talk to it.
Pretty sure this is an easy configuration.
Re: (Score:2)
when the use of seatbelts is brought up in a discussion about running red lights.
saying that someone who doesn't use a firewall when connecting to the internet deserves what they get contributes nothing useful to this discussion, unless you're implying that this vulnerability is moot because we should all be using firewalls.
Re:Well (Score:5, Insightful)
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?
Re: (Score:3, Informative)
These kind of issues seem to [slashdot.org] come up [slashdot.org] here a [slashdot.org] fair bit [slashdot.org].
http://google.com/search?q=site%3Aslashdot.org+SCADA [google.com]
Re: (Score:2)
Why ... (Score:5, Insightful)
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?
Mod parent up. (Score:2)
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.
Re:Why ... (Score:5, Informative)
Why would you have critical systems like that directly connected to the 'Net anyways?
To reduce costs. Its cheaper for an engineer to remote-in to check on something than have them physically drag their butt to work. Fewer people are able to monitor more 24/7 systems this way.
And its almost always cheaper to use an Internet connection than a dedicated leased line for this sort of thing.
Re:Why ... (Score:4, Insightful)
It will only take one incident to loose any cost savings by an order of magnitude.
Seriously, you can't get into any of your machines for an hour, how much does that cost? the machines start doing the wrong thing?
Re:Why ... (Score:5, Interesting)
If an engineer can get eyes on without disrupting operation (talking over the phone), then he might be able to avert a problem.
What if the machine is part of a chemical plant?
Same as above.
As an engineer in both instances, you would probably move more than an hour away.
Since there are usually junior engineers on at night it can be very helpful to have a senior engineer with eyes on. It wasn't until I had 10 years of experience before I realized that I didn't have the knowledge or experience to handle an emergency during my first 5 years.
And the powers that be wouldn't think of paying for someone that had more experience to be there.
So some of the accidents that occur at night which are blamed on people being tired are due to them not having enough experience.
I agree that more money and security are needed.
But very few managers get paid extra for spending more money.
The worst I've seen is where a controller was connected to a phone line. That controller had about 20 chemical reactors tied to it. Another controller also had a phone line and it had 4 reactors tied to it. But before this sounds really dramatic, if someone had hacked in they probably could have done some damage to the reactors, but it would not have caused a danger to humans.
The worst I saw (safety/security) was where someone had installed pipelines carrying caustic chemicals without using a double-walled pipe (Yeah, Electrical Engineers are the same as Chemical Engineers). Yep , sure enough they had a leak. Luckily no one was injured. Some equipment was trashed, but they had insurance.
The funniest was when the insurance guys came and wanted it to be turned on to confirm that it wasn't working. The engineer told him that he highly recommended that the equipment not be turned on. He actually showed them the fuzzy crap that was growing on the controller boards. He and another guy went and gathered five fire extinguishers, put those at their feet and told them to pull out the big red button and to press this button to start it up, if they really had to. Then told them they would be waiting outside. The insurance guy turned popped out the emergency stop button. The robotics went nuts and white flashes could be seen from the vents of the controller panel. Never got to the power on button. Experiment lasted about 3 sec. Insurance agent nearly drove the Emergency off button into the panel.
There were 3 more systems and they decided that they could just look at the fuzzy stuff on the control cards. Didn't need to turn them on after all.
So considering all the trouble we had with keeping safety standards in check, I'd say good luck with handling getting money for proper security costs.
And they finally did double-wall their chemical lines and eventually it became a legal requirement. So from then on there wasn't a problem with getting chemical lines double-walled and properly labeled, not with just the yellow caution tags, but with flags. Flags weren't a legal requirement, but they are cheap.
Re: (Score:2)
It will only take one incident to loose any cost savings by an order of magnitude.
Seriously, you can't get into any of your machines for an hour, how much does that cost? the machines start doing the wrong thing?
The people who put these systems in place know what they are doing, and aren't throwing money out of the window needlessly.. These aren't machines in the server room down the hall, these are machines in unmanned installations, which may need constant monitoring.
Re: (Score:3, Interesting)
And when stuff goes poof, the CEO gets a golden parachute, and writes a nice goodbye letter to the company staff.
Of course people then say, "See that's why a good CEO is worth $$$$$$$$", yes that's true, the funny thing is companies keep paying bad CEOs a lot too rather than have stuff like a "probation period" or having the $$$$ linked to what happens to the company 3 years later.
Re: (Score:2, Funny)
mod parent +1,funny (Score:2)
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
Re: (Score:2)
and the bird can increase efficiency 200%
Re: (Score:2, Informative)
Seriously? If you can't afford to buy some sort of basic protection for internet connected equipment, you need to re-think your business model. If you can't afford the downtime to install a simple firewall, then you really won't be able to afford the downtime it will cause when somebody breaks in.
Re: (Score:2, Insightful)
The nuclear station that went down due to slammer wasn't because they did not have firewalls.
Typically, it's the authorized users who're the biggest problems.
Re:Why ... (Score:4, Funny)
If only there were some sort of virtual private network available that could give them a reasonably secure low-cost option for remote access.
Re: (Score:3, Informative)
Maybe, but I doubt it. The people who continuously monitor control systems are not engineers, they are operators. Engineers are usually "exempt" employees, so their overtime is free. I might also say that if your control engineers are stretched too thin by call-outs, the solution is not more engineers, it's different engineers. I used to work as THE process control engineer at a small chemical plant. Having to go into work at 3 am to fix a problem is very strong incentive to find the real cause of that
Re: (Score:2)
imagine you're a multinational oil company with 300 billion dollars worth of oil and gas reserves, and want to know the exact amount of oil and gas coming out of each well every day or even hour by hour...
and you're doing this without the internet because you like rolling out your own private wide area network? much easier to make a WAN that sits on top of the internet.
remote administration is a lot cheaper than flying admins to every site too. so the question really is, why wouldn't these systems be hooke
Re:Why ... (Score:5, Insightful)
Re: (Score:2)
I don't know too many power plants, electrical generation facilities, or oil/gas operations that are 100% automated and don't have any people around.
yes, but are there qualified people available to do the adjustments on site? What about those un-manned off shore oil rigs? I bet the engineers were pushing HARD for remote access there..
Re: (Score:2)
Re: (Score:3, Interesting)
Re: (Score:2)
http://www.oilrig-photos.com/picture/number172.asp [oilrig-photos.com]
the caption, read the caption. it does have a helipad, so apparently there are times when it's manned, but not all the time.
as to salvage rights, it's not a boat.
They exist (Score:2)
Re:Why ... (Score:5, Insightful)
a) What is critical to you may not be critical to me
b) Keeping them offline might make sense for security, but it makes servicing them more difficult, and so more people need to be hired, and so it is more expensive (which is bad, apparently)
c) Sometimes, critical systems need to be online, and widespread. For example, if banking wasn't networked, then ATMs wouldn't work. If you had your license suspended, it would take hours to get that information to all the other cops, and you could keep driving without penalty. Also, work-from-home wouldn't 'work', and corporate VPNs would be pointless.
Critical systems *should* be connected to the 'net, so we can have access to them. But, they should also be better protected, and backed up offline.
Re: (Score:2)
Not to mention the cost savings that come with remote management... I'm happy with anything that keeps the cost of living down.
Re: (Score:2)
not all firewalls are made of the same stuff. especially consumer grade firewalls, and any unmanaged firewalls. if ports inbound can be opened by spoofing a 'return' packet (full open firewall) then hackers can get inside it.
but yeah, there are reasons to put systems on the internet, and there are reasons to not skimp on it, and get admins who have a clue about security and what hackers can really do.
as for banking networks, they kind of evolved before the internet evolved, so it's possible that banks ATM
Re: (Score:2)
for instance, if you have a routine scan of your brain waves, chances are it's going over modem to a place in Tennessee to be evaluated, and not over the internet.
Well, it will be sent over the phone/modem for now. Until some bean-counter realizes that it is cheaper to use the 'net...
By the numbers. (Score:4, Insightful)
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".
Re: (Score:2)
As for my opinion of critical? Well, if I owned a large, multi million dollar company, then I would consider anything that had a major impact in my ability to make money AS CRITICAL.
To be even more callous
Re: (Score:2)
Just to play devils advocate a bit. "Cheaper should not have more weight than secure" is not true. Think about space travel. "Secure" would involve thicker shells to protect better from debris and more lead to protect against radiation and so on and so forth. The "Cheaper" in this case allows it to happen at all because all of that extra layering would make the whole thing pretty cost prohibitive.
I can think of tons of reasons these things should be networked. I am having a hard time with why they shou
Re: (Score:2)
"Cheaper" should not have more weight than "secure".
It is a trade off. Everything costs money - failures cost money, security costs money, redundant engineering costs money. Since we do not have an infinite supply of money the goal is to get a handle on all of the risks involved and pick the combination that reduces total cost.
The hard part is to properly evaluate those risks (and then re-evaluate them as circumstances change).
Better security isn't always better! (Score:3, Insightful)
"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 y
Re: (Score:2)
Have you ever heard of identity theft?
All of your reasons come down to "cheaper". "Cheaper" should not have more weight than "secure".
I'm sorry we can't all live in your world, but in my world, immediate cost savings outweigh spending a never ending wad of cash on security.
Most companies have to be hit with a pile driver to enact costly security or safety measures. So either the
Re: (Score:2)
If you had your license suspended, it would take hours to get that information to all the other cops, and you could keep driving without penalty.
You can anyway - they need PC in order to pull you over and run your license. Anyway, all of your examples miss the mark; your ATM doesn't need to be sitting on the internet (probably doesn't). It needs a network connection, but that's covered with VPN type tech or a private network. The cost angle needs to be weighed against the risk of doing things on the cheap - no need for direct access, at least not naked access.
Re: (Score:2, Insightful)
Re: (Score:2)
Here is the thing, do you remember all those stories about the NSA working with OS vendors to secure them? Some thought that was good, others (like me) thought it a bit dubious. Well, all that work was for nothing, as evidenced here in this story. No matter what they did, no federal governmental department did anything to secure our IT infrastructure. Now, I'm not going to mention 9/11 conspiracies, but you can just imagine how all this plays out. can't you?
They have those systems connected to the Internet
Re: (Score:3, Insightful)
Re: (Score:2)
The biggest problem with "[...] and risk arises only for systems connected directly to the Internet without firewall protection" is the assumption that all the bad guys are on the other side of the firewall. In reality, a very large portion of penetrated systems are penetrated from the inside.
If you don't see inside penetration as a problem, why not run all your machines inside the firewall without passwords?
Well according to Die Hard... (Score:5, Funny)
...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.
Re: (Score:3, Funny)
That movie had the "Mac guy" so I totally trust it.
that movie had bruce willis, so I totally trust it.
oh, and I love macs. [fireball20xl.com]
Re: (Score:2)
Dvorak?
We don't need to be (Score:2)
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.
Disconnected from reality (Score:5, Informative)
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?
Re: (Score:2)
It is a one way connection to the historian server.
Truly one-way? Not even ONE packet is sent from the historian to ACK receipt?
Re: (Score:2)
Obviously not.
Like I commented on his thread, I do the same thing with my security camera recording point. All of it's over wifi with 1 sending, the other receiving.
It's completely 1 way. Radio-direction-finding proves I'm not emanating signal on that rf card.
Re: (Score:2)
You are assuming TCP.
I try to never assume; everyone knows that every time you assume, you make an ass of Uma Thurman.
I was actually thinking serial communication, especially with legacy systems.
Re:Disconnected from reality (Score:5, Interesting)
You make a fair point but what happens if one of those machines does fail? Believe me, I've had triple redundant power supplies fail on me before it will happen.
The IT world believe in redundancy and so too I would have thought does the industrial world where uptime has to be 100%. Rebooting your Exchange server should not result in any downtime if email is considered mission critical.
So if there are redundant control systems in place why can't individual machines be brought offline and patched as necessary?
The only argument I can see that holds water here is that an update could theoretically break the tool but if it is properly redundant then it won't come back online when you're done and the problem stops there until the node can be replaced or updated.
Re: (Score:2)
Re: (Score:3, Insightful)
If the system is not connecting directly to the internet, why open yourself up to problems.
The original author said that they are using Windows Server 2003. I have seen many places where windows 3.1 and windows 95 are still in use.
Haven't had a patch in well, I don't know how long.
My point is, I wouldn't want to put a patch on
Re: (Score:2)
So if someone gets a bot onto that computer to access it remotly, then they can compromise the entire system.
In the system I worked at, if you want to know what is going on, you called. If you need history you called and we burned you a disk. If you brought a computer device(PDA, Smart Phone, laptop) into the control room, you were reprimanded. do it again and you got the opportunity to work for someone else.
"Why does a box running a CNC machine need internet access?"
Porn~
Re: (Score:2)
Re: (Score:2)
I have a server at home set up like that.
my camera hooked up feeds data to a wifi channel 1 on an unspecified ssid. Data is sent essentially to the aether.
I have another hidden box with wifi receiving only recording all udp packets with certain parameters. My recording server. There's no way to probe it, no way to attack it, no way to know it even exists.
Re: (Score:2)
Unless you wrote your own wireless driver, I highly doubt so.
Re: (Score:2)
Thats the key. Nobody knows about it, nor would casual scanning find it.
And what makes you think that there's no security? Its called a shared secret. And the UDP overflow gunk: I throw away any packets over X size.
Re: (Score:3, Interesting)
Why does a box running a CNC machine need internet access?
After I was caught playing solitaire on a CNC lathe (working one summer in a factory), the engineers thought it would be a good idea to network all the windows controlled CNC machines so they could do remote monitoring and updates. They were mechanical engineers, not IT guys ... and They didn't bother with any security, and so I could browse their 'mshome' workgroup with read/write access. I always wondered what sorts of havok I could have caused ...
A CNC machine may need network access and the net (Score:2)
A CNC machine may need network access and the net work may hooked to the internet.
Re:Disconnected from reality (Score:4, Interesting)
I have done quite a bit of work in the scada area in the past. What we had was the machine network physical separated from everything.
A serial link was used to query the scada system and recorded all the interesting points.
There was no way to write to the scada system via the serial link. That system then dumped the data to sql databases, where it was then queried by the internal web server and provided lookups and pretty pictures for those that dont really need to know, but want to.
The webserver was then on the office network, but could also be accessed by dialup, the office network was not internet facing.
Think that is a bit more secure due to the fact that we actually took 10 minutes to think of a method that would be
Re: (Score:2)
They end up with Internet access for ease of troubleshooting and remote support.
Likely an even greater risk to the security of most such machines is that they are likely using the same passwords today that were being used when the machines were first deployed. Even if they were switched from the default valu
CNC machines and network connections.... (Score:2)
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.
Re: (Score:2)
are you high?
you CAN take the SCADA system offline without affecting the plant. They continue operation just fine with the SCADA pc's offline.
I suggest you learn about modern (1990-now) SCADA it's very different now and relies on the AB systems more than the PC running the crappy software.
Re: (Score:2)
You're wrong. Most of these systems are on networks and they're wide open for precisely the reasons cited in the article.
IT needs to serve the customers needs. (Score:2, Troll)
"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.
Re: (Score:2)
Re: (Score:2)
http://www.linuxdevices.com/articles/AT8574944925.html
Unfortunately, it seems to have died before I could get my hands on one. :(
-:sigma.SB
Re: (Score:2)
This is why Windows should not be used in 24/7 industrial work.
I worked in a factory that used completely unpatched XP (sp1) for everything. Time clocks, CNC control, Quality control records and monitoring... Whenever I had a bad day in production with out of spec parts, I'd just unplug the ethernet cable a little bit, so they wouldn't receive any of my readings (but I could see them). About half an hour later, someone from QA would come by, examine my gauges, and tell me to make SURE I was measuring things properly. At that point, I'd stop measuring, because any par
Maybe they should look at the CIA hack (Score:2)
that blew up a Russian gas facility with the force equal to a small nuke.
SCADA security is a mixed bag. (Score:5, Informative)
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, [computerworld.com] 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.
some threat (Score:3, Funny)
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.
Re: (Score:2)
Worked on a bunch of large scale systems myself. The best were where they used a serial link that was read only from the large scale plc systems and feed to a sql system, which then fed a linux web server, with another net connection to the office network.
The plant network was not connected in any way to the office networks directly.
The only outside connection was logging in to a dialup to view stuff remotely.
Reality check needed... (Score:2, Informative)
Firesale (Score:2)
Firesale - call McClane.
IIAPE (Score:2)
The implications of this may not be that far-reaching
This is a lot like the network printers hack story (Score:2)
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.
Air gap (Score:2)
> 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.
He doesn't get it ... (Score:4, Interesting)
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.
Re: (Score:2)
Amd im an EE student that was going into computer and network engineering.
There's a way to introduce engineering methods in IT. I just treat each network as its own system and hook those systems together like black boxes. As long as we diagram the traces (read network connections), we can follow trouble patterns and diagnose problems quickly. We can then map virtual networks above as we would have a 2 layer circuit board. Since we know what goes where, we can easily see why a level 2 network connection woul
super lock down does not work that well and after (Score:2)
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.
Re: (Score:3, Interesting)
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
Re: (Score:3, Informative)
And I am an IT person with a CS degree that worked as a historian and i/o integrator, industrial software developer, and most recently have been working on a project to integrate equipment w/ layer 4 scheduling data.
Most of the places I have done work for I have seen at least a small number of HMIs that were running on Windows (InTouch, ProcessBook, RsView, etc). I agree that kiosks can be built running off of a read-only image, etc but that takes a great deal of effort, especially for a system that likely
Grades of Shay (Score:2)
SCADA SCHMADA (Score:3, Insightful)
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.
add the SCADA tag (Score:2)
Plain fear mongering (Score:2, Interesting)
It's not as bad as it sounds. (Score:5, Informative)
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.
We're from IT and we know better (Score:2)
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!
Not really rocket science (Score:2)
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, mu
The problem: Microsoft Windows (Score:3, Insightful)
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.)
True Dat (Score:2)
Re: (Score:2)
That was the first thing I thought. I hope for his sake that the guy is European, but he has a very American-sounding name.
Re: (Score:3, Funny)
he has a very American-sounding name.
... where do you think most americans came from?
...
... besides mexico
Re: (Score:2)