Researchers Find Slew of Flaws In SCADA Hardware, Software 110
Trailrunner7 writes "At the S4 security conference this week, 'Project Basecamp,' a volunteer-led security audit of leading programmable logic controllers (PLCs), performed by a team of top researchers found that decrepit hardware, buggy software and pitiful or nonexistent security features make thousands of PLCs vulnerable to trivial attacks by external hackers that could cause PLC devices to crash or run malicious code. 'We were looking for a Firesheep moment in PLC security,' Peterson told the audience of ICS security experts. They got one. 'It's a blood bath mostly,' said Wightman of Digital Bond. 'Many of these devices lack basic security features.' While the results of analysis of the various PLCs varied, the researchers found significant security issues with every system they tested, with some PLCs too brittle and insecure to even tolerate security scans and probing."
unreviewed code is buggy? (Score:5, Insightful)
So you're saying closed source, only-validate-functionality, stale code has security holes?
Comment removed (Score:5, Insightful)
Re: (Score:2)
So what your saying is the Debian bug still hasn't been solved, OMG. So what's that six years and counting. Perhaps what your saying is many eyes still sometimes take time to resolve bugs, well, everyone expects that.
The flip side with closed source code is often the bugs get found when they get exploited. So how many times was the Debian bug exploited. Also in closed source code, how many times was a bug found and left unrepaired for years.
Here's a fun windows 96 bug, their write-behind caching was no
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
Sorry. Your argument is invalid because of ponnies.
Well, and the fact that we are talking about PLC's, not full desktop operating systems.
Re: (Score:3)
Yes. When we said there are never any bugs in Open Source software we forgot those two. ( ... and just to be clear, we didn't really say that despite your efforts to imply that we did)
We Open Source developers are a weird lot. We focus more on security when we are producing products that will control nuclear power plants than when w
These things were too successful. (Score:5, Insightful)
Most of these PLCs were simply too successful for their own good. Many of these designs were created in the 70s with no real intent of ever having then live in an on-line environment, but rather to be isolated in machinery as simple as pumps, motors, and simple stand along controllers for a variety of machines.
The problem lies not with the PLCs but the questionable decision to wire these things into the network.
Some of these things are extremely simple controllers. Others, like the mentioned D20 ME [ge-energy.com] are micro computers onto themselves. These devices are built from a long line of simple process controllers, which grew to their current state from simply hanging more and more interfaces, better processors, and a mountain of legacy software, onto what started life as a very simple device.
None of them were ever intended to be put directly on the wild and wooly net, even when the did contain Ethernet ports, modems, and radios. Everyone assumed these were on their own in-plant network and that no one would hook them up to even their general purpose lan, let alone to computers accessible to the internet.
Anything less successful would have been replaced by a total redesign and rewrite from the ground up.
dident some of them have dial in only and you need (Score:2)
dident some of them have dial in only and you needed to war dial to find them and likely get very little info on what you found. But with a IP you can find some thing and get alot more info on the hardware just by running some commands / looking at what software is on the IP that that has a open port.
Re:These things were too successful. (Score:5, Insightful)
I program, install and commission PLCs in high security facilities, including prisons. We mostly use them for door control, interlocking and some low-level interfacing to other systems for which we don't have a high-level interface.
I do not believe that the responsibility for security should rest with a relatively cheap, simple bundle of IO and a processor programed in ladder logic. The security should be in preventing access to the SCADA/security network to which these controllers are attached. These things aren't servers, it's hard to imagine a reason for having them anywhere near the WWW. In our high security sites we usually have an air gap enforced by a physical barrier (two layers of four metre high razor tape fence) which is regularly broken by people disregarding policy and carrying in USB memory sticks. This is a potential attack vector, assuming whomever wrote the attack program had intimite knowledge of how the PLCs were programed. Most network security barriers are overcome in time as new vulnerabilities are discovered. Given the commission-and-hands-off nature of PLCs, rolling out updates to patch theoretical vulnerabilities is going to be a VERY hard sell, considering any change to the PLC usually requires re-commissioning every field device attached to it.
Re: (Score:2, Insightful)
The security should be [...] an air gap enforced by a physical barrier [...] [but this is] regularly broken by people disregarding policy and carrying in USB memory sticks.
You admit the fatal flaw, but still think physical security is enough? Even when it appears that all it takes to defeat your "security" is one retarded, or corrupt, security guard?
You might as well cover your ears and scream "LA LA LA I CAN'T HEAR YOU". Obviously these PLCs need to be connected to a network of some kind to be usef
Re:These things were too successful. (Score:4, Insightful)
Quick question. So you're saying that they need to secure the system from the guards so that they can't use it to open the cell doors? Wouldn't it be assumed that the guards already have the implicit capability to open the cell doors?
I love how security discussions almost always evolve into someone arguing that some particular actor in the system needs to be prevented from doing something that is actually part of their job!!
Re: (Score:2)
I was trying to say that you can't assume malicious software doesn't exist on your network; i.e. you cannot leave out basic security controls just because the thing is on a ostensibly private network. No software should be able to open a door by, say, sending a simple ASCII string on the right port (I've seen that kind of stupid crap in other software). Why not specify that
guard doesn't need to be complicit (Score:2)
I'm assuming the guards are carrying personal data (files, movies, music, etc.) on those USB sticks. All it would take is someone getting into a guard's computer and dumping a virus onto the USB stick. The unsuspecting guard carries it past the physical protection, loads it into the private network, and the virus then infects the isolated network.
Come to think of it, isn't this how the centrifuges were attacked with stuxnet?
Re: (Score:2)
Physical security is enough, but theirs isn't. Epoxy in any USB ports that can't be disabled is the canonical response to this particular problem. Smarter is to use an enclosure that simply prevents access to them, or removal of the keyboard from its port, et cetera. A determined attacker could still cut the keyboard or mouse cable in order to connect their own device, but even if you use USB you can still prevent driver installation so the worst they could do is inject custom keycodes or mouse events.
Re:These things were too successful. (Score:5, Insightful)
Agreed. My father actually works for a major company that makes these (among other things - he works in a different department, but uses the things in his line of work). I told him earlier about a story from here about a major flaw in a city's usage of it. His *first* *response* was something along the lines of "what moron decided to plug that thing into a network in the first place?".
The systems were designed and are still designed to be fully isolated from intruders. The authentication is mostly there as an afterthought, to keep the site janitor or a secretary from logging in and seeing what happens when they push the big shiny buttons. The city in question most likely hadn't even changed the password from stock, as it was still three characters long.
Remote login shouldn't ever be permitted, because it shouldn't ever be necessary. A trained operator is always on-site, in many cases because a trained operator is legally required to be on-site 365 days a year.
Yeah, a lot of the blame should fall on the people making these - they should have wisened up to security requirements ten years ago. But part of the blame goes to the people who said "sure, let's plug this into the Internet! What could *possibly* go wrong?"
Yes, keep it "offline" (Score:3, Interesting)
Serial printer port (Score:1)
Nothing new. It's called a two wire serial printer port -- can even drive a 300 baud modem.
Re: (Score:2)
Re: (Score:1)
The market opportunity is in making a product that can be switched in place of an ethernet link with as little work as possible, and in marketing the hell out of it as the "best possible" secure solution. Preferably the interface should also be very fast, so that you can pass all the raw data you could possibly need into a database on the other side of the link. Otherwise you have a bottleneck that may need special processing on both sides of the link.
Re: (Score:2)
Point a webcam at the monitor.
Re: (Score:2)
I agree. I work for a water utility and making any changes to our system requires us to physically report to the locked, alarmed office and access (through password login) a scada computer terminal, or to report to the facility in question and log in there. I often wish I could at least access current complete "read only" system data on my phone or computer so that when I'm paged by the system and it reports that a fault has occurred (example could be as simple as "pump #1 failed to start")
You are kidding yourself. Your work network is still vulnerable, even though it's isolated.
One of the great security lessons is that an isolated TCP/IP network is an impossibility. DoD found that out when they found malware on secret classified networks. The Iranians found it out when Stuxnet successfully attacked the internal process control network at the Bushehr nuclear facility. DoD classified networks have been penetrated by workers whose laptops are connected to the classified network at work duri
Re: (Score:2)
There is still a huge difference. A system that is connected directly to the internet provides a target to every pimple faced kid in the world, provided he has a computer and the will to futz around, searching for a vulnerability.
That air gapped system requires much more skill, patience, and dedication, along with some kind of feedback, than zit-face can possibly muster.
Re: (Score:2)
That air gapped system requires much more skill, patience, and dedication, along with some kind of feedback, than zit-face can possibly muster.
Exactly. This means that the only attacks you will get will be something like Stuxnet. It will be specifically targeted at your system and it will not be displaying a laughing face on your monitor. It will probably reverse the pump that sends fresh potable water into the sludge tanks.
Re: (Score:2)
You get all sorts of stupidity with this sort of thing. I know a city who put this all on there network. It's actually stopping them from getting off a bridged network as there security plan was static IP's on a different address range. This stuff is old and does fun things like arp constantly.
Re: (Score:3)
"Yeah, a lot of the blame should fall on the people making these - they should have wisened up to security requirements ten years ago."
Ask yourself, what percentage of PLC's in use today are newer than ten years? Crap - I'm using PLC's that are 30 years old! If I actually researched our stuff, I might find that some are even older. (When WAS the PLC invented, anyway?) To make things even worse, manufacturers of new machines are using technology that is 3 to 10 years old. In the same machine, we have st
Re: (Score:2)
PLCs are the natural "evolution"(if you like) of Relay control logic. Which dates to pre WWII. That is why they use ladder diagrams.
Re:These things were too successful. (Score:4, Informative)
Worse it's easy to claim a product is secure when it is not
A product is not "secure" or "insecure"
A deployment where a product is used is secure or insecure.
A deployment of a product can be highly secure in its expected deployment scenario, but the deployment horribly insecure if you plug it into an outside network which contains unmanaged devices.
There may be flaws in a TCP stack (For example), that could be exploited if an unmanaged device were allowed to produce arbitrary communications, but the deployment can be secure when all devices are managed, and there is no operator console command to generate the invalid packet, without physical access to plug a laptop into the cordoned off network.
Re:These things were too successful. (Score:5, Interesting)
Right security is about people. I agree not every single device needs to be hardened like a fort. I think this is actually a trap many security folks, especially geeks fall into. Its wrong because it ends up frustrating everyone else, and they start not cooperating, circumventing security controls and opening wide holes than existed in the first place.
The most important thing is that everyone understands what things are. If its well known that say some industrial control app is thin on input validation, does simple clear text unauthenticated communications with other devices, and has a configuration interface with a password dialog easily bypassed by rigging up a specific query string, all that might be okay. There might even be very solid reasons for it. It keeps the code base small, easily understood, might offer performance advantages on limited hardware, etc. Hardware hardened for industrial applications is often limited and expensive. You might ask why even bother with the login screen if its so easy to defeat, well its a lock for honest people, it might help oh This is Isle 3A bay 15, I am supposed to be making this change on 3B-15, oops sort of mistakes.
Clearly such devices are designed for use on closed networks, as long as everyone understands that there is no reason to make things harder for people. Its when usb sticks and laptops start getting plugged in, or someone connects it to a larger network you see problems. Manufactures need to be upfront about these things being designed for a specific ecosystem. "Yes it password protected, but its human interface feature not a security control..."
Re: (Score:2)
They have a hard outer-shell, but are far too squishy on the inside for my liking.
This is true of many corporate systems, not just SCADA. How many companies have companyname123 or some variation as their password on their internal systems? They still don't get hacked (usually), because their external firewalls. Access from outside is not possible, except through VPN for which you need a physical token.
Re: (Score:3, Informative)
Then there is Allen-Bradley with their Micro-VAX blade plugin to network and perform serious device control... The fact is, is that a lot of these devices ARE intended to be networked these days, but they are still built with a 70's and 80's non-networked mindset. My opinion, having written a LOT of software for integrating PLC's into complex manufacturing control systems for companies and organizations ranging from General Motors to Honeywell to Motorola to Rockwell to the US Navy, is that the best approa
Re:These things were too successful. (Score:5, Interesting)
On the other hand even if they were separated from the internet, they were intended to have some sorts of communication between a base (such as an office) and a remote station. I purchased a set of 33.6k programmable modems (Telindus Aster 5) once that were set up to dial in automatically into a specific location with passwords etc. pre-programmed. How easy do you think it would've been for anyone else to dial-in to those systems if they knew any of the details?
The matter of fact is that until the last 5 years none of these system makers thought about any security even though the techs in the field knew how their systems were going to be set up at the customer. I've worked with Siemens several times (both with their PLC side and their medical instruments side) and every single time I had to provide the additional security on my (or my clients) network even though it was never planned for, requested by them or even had come up in the negotiations when these things were purchased.
And to give you a reason why I think they should plan for it: Windows XP SP1 is what they not only use on their own systems but also set as a requirement for developers to use with their SDK's (together with some custom packages and Visual Studio 6).
Re: (Score:2)
From my experience this is because the changes to DCOM security in SP2 break how they've written their applications. You can get it to work by fiddling in dcomcnfg yourself but this didn't seem to be something the Siemens guys had tried.
Re: (Score:2)
Siemens? You have my pity sir. Siemens PLCs are terrible. No clue why they're so popular...
Re:These things were too successful. (Score:5, Insightful)
But yes, detaching them further is a very good plan.
Re: (Score:2)
While it is indeed laughable and sad that these unprepared devices were attached to the Internet, it is also worth highlighting that being detached from the Internet is not itself a pancaea.
In addition to being detached to the internet, the use of USB addon devices should be disabled on all SCADA operator consoles and other SCADA network connected devices. And they must not have connectivity to the same network or storage volume as _any_ other device that has internet access, USB thumb drive access, co
Re: (Score:2)
In other words: no data path from outside network to SCADA network, neither a network datapath, nor a sneakernet data path.
Of course, this would make any kind of remote monitoring impossible...
Re: (Score:2)
... unless you had something like RS232, full duplex RS485, 10baseT, 100baseT, ...
which can all work with only data lines for one direction connected...
... but then that RS485 would no longer be full duplex would it?
Re: (Score:2)
Of course, this would make any kind of remote monitoring impossible...
Not impossible. Build a private circuit from the site to be monitored to an operator console at a remote secure location; use a dedicated firewall on the monitored station side of the private circuit that only allows unidirectional encrypted traffic required to feed information into the remote monitoring station.
Re:These things were too successful. (Score:5, Interesting)
Re: (Score:2)
shutting off a single power plant is not going to cause a major systemwide blackout assuming the high voltage electrical protection was designed correctly
Brave [msn.com] assumption. [wikipedia.org].
Re: (Score:2)
Re: (Score:2)
Just tell said boss in a written memo that connecting it up would cause the company to fail a SOX audit.
(I don't know if it really would, but it certainly should.)
Re: (Score:2)
You've nailed the problem, right there. SCADA was never meant to be online. It hardly matters that some chips were designed before there was an internet - even the newest aren't meant to be online. Having an infrastructure network accessible from the internet is moronic. It is merely stupid to have an outdated operating system with inadequate security connected to the internet, but positively moronic to connect your SCADA.
Someone needs to send a news letter to all of the corporate and government idiots
Re: (Score:2)
I don't see a big deal here: you want it on the network, you put a gateway that encrypts the connection, verifies the certificates of the accessing party, etc. Like any tiny linux-running internet-enabler gizmo would do, when properly configured, even using nothing more than ssh. There's nothing inherently bad about those PLCs, it's the dumb implementers who have no clue. If you integrate solutions that involve networking, get someone with a clue in that area. Most industry "specialists" who deal with PLC h
At least not remote login ready (Score:1)
Especially the ones that require IE 6 to remotely manage. I mean in that kind of environment complete pre SP 1 XP with no firewall unpatched that uses unsigned active X controls... or not what could possibly go wrong!
run malicious code (Score:3)
Cool, sort of like having access to an industrial 3d printer. Tho picking up your finished products might be tough.
Re: (Score:3)
No problem. Since Hollywood is going bankrupt from "rampant piracy," you can probably hire the Oceans Eleven team to pick up your stuff for dirt cheap.
Awww! (Score:4, Funny)
We just got a great deal on some barely used USB sticks from Iran. Only plugged into their centrifuge controllers once.
Alot of the stuff comes from a dos / win 3 / 9X (Score:3)
lot of the stuff comes from a dos / win 3 / 9X mine set likely loaded with hacks and out stuff to keep them going so to get real security they may need to be rebuild from the ground up.
Re: (Score:2)
That's the interfaces themselves. They have no reason to be secure against a software attack as they should be 100% phsyically secure. The actual code in the PLC has nothing in common with DOS or early Windows, these things don't run operating systems, they are embedded systems as embedded systems should be, really quite simple. This is also why they lack security features.
But really what would a ground up re-write accomplish anyway? You close some security holes made by constant patchwork, and open a shit
Re: (Score:2)
Actually lots of this stuff is hardened x86 machines running DOS, and some Windows 3.x and 4.x (Windows '95 '98 etc) stuff as well.
Re: (Score:2)
If by lots you mean a few special purpose tool rather than the 4 or 5 big companies who control most of the worlds industry then sure.
There's no arguing that some of them run some form of x86 instruction set, but they have very little in common with a PC, and if anything more of them have a background that is Unix based rather than DOS. I'm sure there's some small name RTUs that have some system like that, but the big names like Allen Bradley, Foxboro, Honeywell and (the guys who started this security mess)
two decades old = lack of funds to update or PHB (Score:2)
two decades old = lack of funds to update or PHB who think if it's running now we don't need to update them or ones who say we don't need on staff IT outsource it and the outsourcing puts them on web so they can do remote admin or maybe the IP part was to be on the inside network only and some one put it on the web maybe becomes they don't know what they are doing or maybe so some can remote admin it.
Non IT engineers running the show may be at falt (Score:2)
Now there are a lot of places where engineers (non IT) run the a lot of hardware and keep IT out of it and over time more and more has moved to IP / windows / + outside venders and what you get is people who may know what they are doing with the hardware but not the under laying IT side. golf courses meeting with mangers do not help as then you can end up getting some piece of software dumped on you that may not even work that well.
Re: (Score:2)
And this is news? (Score:1)
Wait until they get to analyze the GPU processing...
No security at all. DMA in/out to any address desired. Assumptions made about the runtime library loaded with the application, assumptions made about memory handling, assumptions made about I/O.
Completely Irresponible (Score:3, Interesting)
This series of zero-day public disclosures is an abhorrent act that violates most any professional or ethical code out there.
As these vulnerabilities impact devices which are known to be networked, as well as being in control of critical infrastructure, these "researchers" have at their disposal US-CERT/ICS-CERT, as well as direct contacts with the vendors in question.
They chose to turn this into a marketing stunt to sell tickets to their conference and to attempt to sell consulting services to the control systems industry. Luckily, I see this, and I will NEVER recommend that Rapid7, Dale Peterson, Digital Bond, Dillon Beresford, Jacob Kitchel, Tenable Network Security, or Ruben Santamarta be allowed near ANY critical systems.
These individuals have shown their true colors. The vendors WANT to play along, they WANT to increase security. Instead, these fools did a complete end-run around them and just dropped EXPLOIT CODE into the hands of everyone in the world. These "researchers" clearly do not care about the users of these systems, just the $$ they can milk out of the newly instilled fear.
Re: (Score:3, Funny)
Correction Facilities PoC hack (video) (Score:2)
At a recent convention some researchers demonstrated a proof of concept hack they developed that allowed them to control many aspects of correctional facilities. Things like, oh you know, opening cell doors but showing them as closed on the guard terminals. Things like that.
Interesting preso : http://www.youtube.com/watch?v=C7O7HxHSHE0
One more quote (Score:4, Insightful)
The wired.com article has this choice quote
http://www.wired.com/threatlevel/2012/01/scada-exploits/ [wired.com]
"I didn't want a vendor to jump out in front of the announcement with a PR campaign to convince customers that it wasn't an issue they should be concerned with," Wightman said.
I can't imagine the type of two faced dickery it would take to spin weaponized exploits as something not to be concerned with.
Re: (Score:2)
Re: (Score:2)
I can't imagine the type of two faced dickery it would take to spin weaponized exploits as something not to be concerned with.
Which is why the world has lobbyists and advertisers to handle the job...
Again, Rule #1 would prevent problems (Score:2)
Rule #1 being that you do not connect control systems to the internet.
I don't care how good the hacker is, he can't overcome an airgap. Which leads to,
Rule #2 Train your people well enough not to fall for helping him.
Re: (Score:2)
Rule #1 being that you do not connect control systems to the internet. I don't care how good the hacker is, he can't overcome an airgap.
He can if those systems are connected to a Windows PC and someone plugs in a USB key so they can watch their pr0n while they work.
Re: (Score:2)
See Rule #2.
Saw a similar thing at GrrCON (Score:1)
GrrCON video of his presentation can be found here [youtube.com].
But GE operates to 6 Sigma Quality (Score:2)
So...GE makes jet engines and PLC controllers both to 6 Sigma. How come I don't feel as good about flying now?
Wikipedia: "Six Sigma originated as a set of practices designed to improve manufacturing processes and eliminate defects, but its application was subsequently extended to other types of business processes as well. In Six Sigma, a defect is defined as any process output that does not meet customer specifications, or that could lead to creating an output that does not meet customer specifications."
WOPR (Score:2)
I'm just sayin (Score:1)
Oops, pull those ethernet cables (Score:1)
The times are (slowly) changing (Score:3)
A lot of newer DCS gear is starting to have process firewalls being build in to the hardware at the controller layer. Also a change I've seen of late is that a lot of vendors software no longer runs ABSOLUTELY EVERYTHING at a privileged level as has been done in the past!!!
This should reduce the attacks on the PLC devices themselves, however the protection of the SCADA/DCS Servers (usually Windows Based) relies on GOOD system administration and knowledge about possible attack vectors..
Anything that straddles a corporate and process network NEEDS to be hardened, however more often than not this is the weak point (Process historians and other servers that provide end-user data are the biggest risk)
I've seen windows 2000 machines that are on both networks running 2000 SP1 and no later security patches THIS YEAR (Not a practice recommended by the vendor either, this was a customer who 'knew better').... lets also mention that it also had a VERY easy to guess Admin password!
Tis a scary world.
Most vendors have best practices for keeping nasties off the process networks, it's usually the customers who compromise to make their own life easier. Usually decisions made by the onsite IT people who, lets be honest, have NO idea about how/what a process system does. I work across many large sites and in general the IT people do not understand what is required and tend to be the ones who punch the massive holes in the firewalls to get things to work.
The vendors (I work for one) are now catching up by hardening things better at the hardware and software levels, but it's the legacy stuff that scares the bejeezus out of me!!!
well duh... (Score:1)
well what do you expect? these devices use microcontrollers and are limited by size of memory in the chips. its not allways possible to secure to the Nth degree, so one must analyse the risk of the hardware provided. dont connect them to a public network. at most. connect the ethernet to a windows PC that can recive emails, but is not connected to the company LAN.
PLC hardware must remain hardware modules from 20 years ago, so its no good putting in the latest and gratest microcontroller in every year, if it
1980s/1990s code (Score:1)
In the products I've seen (including some of the source code), they were loaded with factory backdoors, sloppy coding, and many designs hadn't been updated since the mid 1990s.
Certainly doesn't help that a lot of the operators of these devices hire the cheapest engineers or techs they can find, usually without a good computer eng background.
SCADA are not PLC's (Score:5, Informative)
Ok, firstly SCADA and PLC's are two different things. SCADA is the HMI control system and PLC's are the parts that actually talk to the physical devices. While sometimes they are in the same box usually they are totally different devices. Secondly PLC's can be anything from windows PC's to low level simple processors. However they have one overriding concern and that is real time control of the plant hardware. This is why PLC's are hard to secure. Often they have not the power to run encryption algorithms required for security.
But they should not need to. Almost all of them are bespoke running closed simple OS, using proprietary languages. More importantly they should all isolated both behind physical security and network within a DMZ. That's not to say security cannot be improved, however these are not your PC's connected to the internet.
SCADA machines are more problematic Generally they are standard PC's running windows(Often quite an old version of windows). The very generic nature of the hardware and OS is its biggest weakness. As are their users. One of the problems we have encountered is viruses being stuck on PC's via USB sticks brought in from outside. We have even found games installed by bored users. So why not put antivirus software on them you may ask? Well the problem there is finding AV software which does not affect the operation of the SCADA software. Secondly is maintaining updates. To do that is either a manual process(not really feasible) or connect them to a central server or internet. This introduces an attack vector of its own.
STUXNET is always highlighted when these conversations come up, but this is misleading. If reports are to be be believed this was perpetrated by national agencies with all the resources that implies. No system is totally secure in that situation, the best you can hope for is to detect and delay. However most systems will never come under such a coordinated attack. Saying that it has concentrated the PLC industries mind on security, so thats not a bad thing, but we are no where near the Armageddon scenario that such articles seem to hint at
Re: (Score:2)
Nice post. Sorry I modded it flamebait.
I'm reading slashdot in a bus on a bumpy road and my finger slipped. So basically I'm posting to remove the mod. Ignore me. K thx bye.
Re: (Score:2)
LOL
Re: (Score:1)
Re: (Score:2)
It introduces another unknown in the system and can introduce unwanted side affects. We have found software whitelisting is generally more applicable to these sort of systems than traditional AV
PLCs were NEVER supposed what they are today (Score:2)
PLCs come from the ages when "networking" was some wet dream of the die hard geeks (yes, both of them), when it was already a semi-miracle if things worked the way they should. Also the ages when speed was essential, room for the logic was scarce and generally .... fuck, you were happy you could cram the crap into the PLC at all without having to buy another expensive piece of hardware!
We're talking about ancient technology here. Sadly, it has never seen much of an upgrade. Compatibility, we love and hate y
HW Engineers Should Not Design SW (Score:2)
I've seen it a million times and it's always a disaster. Just look at the user interfaces for the vast majority of appliances & peripherals - ghastly...