# Will PLCs be obsoleted



## NC Plc (Mar 24, 2014)

I've been in a lot of facilities and none of them were willing to use stuff like Productivity Open over traditional PLCs. Didn't matter if it was a lumber mill, utility site where they have 11 gas turbines, small fiberglass operation, a brick making plant, or whatever. People have been predicting that **** (Richard) Morley's invention will be supplanted for decades, when relay banks were still being used alongside custom processing units and PLCs, and it still hasn't happened yet. 

What I've seen happen is PLCs become more user friendly, easier to program, less usage of IL, and more capable of complex calculations. They made cards for some PLC lines where you can program the card in C/C++ (I forget which it was) to handle complex complications, while the main program was either LD or ST. 

I'm sure things will keep evolving and more interesting devices will come along. I'm not holding my breath that PLCs will become a niche artifact from a bygone era, like COBOL in banking, anytime before I retire.


----------



## canbug (Dec 31, 2015)

Airport lighting used to be turned on in the tower with pushbuttons and thumb wheels for brightness, lots of relays. Then we moved to PLCs for about 20 years and now we are completely windows based with touch screens.
Just saying.

Tim.


----------



## Jefferson Jakes (Jun 26, 2021)

mburtis said:


> I didn't want to derail @paulengr thread on PLCs to much but Paul kinda hinted at something with his mini computer comment that I've been thinking about lately.
> 
> I know the traditional plc with never truly fade away and there will always be legacy installs, but is it going to be less and less common? They are coming out with all these smart sensors (I think they call it industry 4.0) and the electronics are so small and cheap now. Is the system of the future sensors and other componets with built in smarts (scaling, filtering, data logging, communications etc.) That just talks directly to a computer or a webserver via ethernet or wifi. It seems hmis are already moving in the html, css, Javascript direction similar to web devolopment and leveraging the power of mobile devices.
> 
> Will the industrial automation tech of the future look more like a current day web developer than an electrician? This is the random stuff I think about as I look towards the next 30 years in this industry.


The future is bringing some amazing stuff, I was meeting with a guy who is privy to whats coming up at the gear manufacturer he works for. He says theres a universal module that will be available in a few years that is a breaker, a starter, a drive, you just tell it what you want it to do with an ipad and yes there are PLC capabilities built in. Its all SCR control, even the breakers, no such thing as "contacts" anymore. Its similar to DALI if youre familiar with that, EVERY device will have an address.


----------



## macmikeman (Jan 23, 2007)

What will survive all this change is............. Jackchain. And flashlights. You gonna have to think about this a bit .


----------



## Jefferson Jakes (Jun 26, 2021)

macmikeman said:


> What will survive all this change is............. Jackchain. And flashlights. You gonna have to think about this a bit .


LOL!


----------



## SWDweller (Dec 9, 2020)

I remember when PLC's were cheaper than a computer. (still are) If the use did not need a screen just function; if this, then do that. Pretty simple. The first one I ever got a hold of would not run the ladder program because it did not have enough memory. Boss was upset until we sat together and I found out he spec'd the hardware. If I remember we had to get the next CPU up and change over all of the cards to the new back plane.
I have used "smart I/O only a couple of times. Mostly for safety. I have never wanted to hurt anyone with my programing. Once the industry sort of landed on Ethernet it solved a lot of problems and created some others. Ya got know how to sub divide the network using bridges not hubs when the network is a busy one. I still hate wireless, and anything that has to do with some "cloud" that someone saw once. I live in an area where there is a lot of area with "NO G" at all. 

The auto industry has gone to "PLC's/ ECU's" and they are working just fine in the wild. 
I believe we will see the PLC name fade into some other term made up buy the younger generation as time marches forward.

I was never any good at programing with anyone around. I prefer listening to Andrea Bocelli when coding. Reason I listen to an Italian singer? My brain skips over the vocals and keeps with the music. Lets the other part of the brain stay with the tech part that needs to get done.
White noise in fewer words


----------



## splatz (May 23, 2015)

PC architecture is cheap due to economies of scale. It's very hard to beat the processing power you get for your dollar in a PC. However the regular PC hardware is not suitably hardened for industrial use, and it's getting so that the faster stuff is going to be very hard to cool in an industrial environment, so that's an issue. There is PC architecture hardware that's built for some industrial environments, but that stuff is not cheap, you lose a lot of the economies of scale. The operating systems readily available for PCs are not real time and the architecture isn't that well suited to deterministic processing. 

I think the most efficient architecture has PC architecture servers doing things that require heavier processing while small, lean, efficient, reliable special purpose machines - PLCs - do the simple repetitive tasks, and the two communicate as necessary to work together.


----------



## NC Plc (Mar 24, 2014)

The lack of optoisolation on PCs, their suceptibility to dust / EMI / vibrations, glitchiness of an OS that isn't burned onto the IC causing machines to glitch, the cost of downtime, hackability, easy of troubleshooting LD, etc are all reasons we don't even consider moving away from PLCs for our large-scale facilities. Yeah, we use SCADA in the control room but on the production floor it's primarily PLCs. I know that yes, PLCs are hackable and were not designed with security in mind. For example an AB PLC has a flaw where a malformed packet would freeze the PLC until the power is cycled, and in a large plant overseas the PLCs were hacked to fill the atmosphere with H2S to create a lethal and explosive atmosphere with the safety sensors disabled. Still, those issues can be mitigated with adequate network security practices and having your safety stuff set up in a more hardened manner.

We stick with PLCs, as many others on my side of things do, because they're designed to be powered on and run a program for 15 or 20 years (historically, I don't know how new PLC lines are with regards to longevity). I don't think they're perfect for every solution but in some areas they're staying around for the rest of my career. 

My biggest concern is exposing PLCs to the internet without considering the risks involved. Governmental entities I've worked with have a decent security setup so I think the network security side of things is catching up, it's far better than it was even 8 years ago.

I could be wrong but I feel comfortable in my future of I&C, PLC programming, PLC networking, and electrical work.


----------



## just the cowboy (Sep 4, 2013)

NC Plc said:


> They made cards for some PLC lines where you can program the card in C/C++ (I forget which it was) to handle complex complications, while the main program was either LD or ST.


This started back in PLC 2 days they had a 1771-BAS card that did *BASIC *programming for complex stuff or printing. 

As for the OP post things have gone round in circles for years but it always seems to come back to ladder logic.

Coding, Scripting, Function Blocks, Seq function charts, Structured text all go up and down while Ladder is like the eneginerzer bunny it just keeps on going.

First HMI I did was an AB Advisor system programmed in a version of C, 
Line from pixel 125,125 to 125,0 = Color 16
Line from pixel 125,0 to 250,0 = Color 16
Line from pixel 250,0 to 0,125 = Color 16
Line from pixel 0,125 to 125,125 = Color 16
Fill Color 10
Activate O:001/11

or something like that


----------



## NC Plc (Mar 24, 2014)

just the cowboy said:


> This started back in PLC 2 days they had a 1771-BAS card that did *BASIC *programming for complex stuff or printing.


That's pretty wild. I haven't even seen a PLC 2 in the field, the oldest stuff I've seen are those GE 90-30 and 90-70s. Doing math in a DL-06 wasn't enjoyable; I wonder if it was easier or harder doing it in BASIC.


----------



## mburtis (Sep 1, 2018)

I'll never forget my first project with a plc. We bought a used 250 ton hydraulic press. It showed up on the truck and I had this older electrical engineer there who was helping me learn about plcs and controls. He opened the door on the massive control cabinet and says "fxxx me, it's got a modicon" then closed the door and didn't say another word. As a young mechanical engineer getting interested in controls it was a memorable moment. I didn't realize at the time how instrumental that project would be in changing the course of my career.


----------



## u2slow (Jan 2, 2014)

I believe the Siemens PLCs we got not even 5 years ago are obsolete. Glad we got a frw spares on the build-out, but we've dug into some of those already. Methinks our next hardware failure is going to be a problem.


----------



## gpop (May 14, 2018)

plc's will get better and programmers will get lazier.

how many tag's are you using ...... don't care
What is the memory allocation ...... don't care
Have you optimized the program .... Less than 2ms scan rate seems like its doing fine.


----------



## micromind (Aug 11, 2007)

PLCs are not immune to being hacked.......look up Stuxnet Virus. 

Actually, I think that virus was one of the most brilliant things ever.


----------



## just the cowboy (Sep 4, 2013)

micromind said:


> PLCs are not immune to being hacked.......look up Stuxnet Virus.
> 
> Actually, I think that virus was one of the most brilliant things ever.


Have you seen this one. I think it was cool how they just changed the sync point 180 and blew it up.








How 30 Lines of Code Blew Up a 27-Ton Generator


A secret experiment in 2007 proved that hackers could devastate power grid equipment beyond repair—with a file no bigger than a GIF.




www.wired.com


----------



## micromind (Aug 11, 2007)

That was a good one.

One of my friends (yes, I do indeed have friends........) is PUCO engineer, we have lunch together once in a while. One day the subject of grid reliability came up and we figured that if either one of us had total access to all PUCOs computers, we could trip about 2 dozen breakers and bring the entire national grid down. 

Estimates for bringing it back up again vary from a few weeks to a few months to maybe never.


----------



## paulengr (Oct 8, 2017)

mburtis said:


> I didn't want to derail @paulengr thread on PLCs to much but Paul kinda hinted at something with his mini computer comment that I've been thinking about lately.
> 
> I know the traditional plc with never truly fade away and there will always be legacy installs, but is it going to be less and less common? They are coming out with all these smart sensors (I think they call it industry 4.0) and the electronics are so small and cheap now. Is the system of the future sensors and other componets with built in smarts (scaling, filtering, data logging, communications etc.) That just talks directly to a computer or a webserver via ethernet or wifi. It seems hmis are already moving in the html, css, Javascript direction similar to web devolopment and leveraging the power of mobile devices.
> 
> Will the industrial automation tech of the future look more like a current day web developer than an electrician? This is the random stuff I think about as I look towards the next 30 years in this industry.


That’s called Fieldbus. Back in the 1990s this system came out called Foundation Fieldbus. So in a traditional PLC system you would program a controller that reads the temperature set point and a temperature sensor. Then it fires an output to control a heater, either with on/iff (aka bang-bang) control or an analog signal like a damper. The difference with Foundation is that the Nest sends the set point to say the temperature sensor. It can run the control loop and directly send the signal to the heater, no PLC needed.

Unfortunately Foundation was grossly overcomplicated, slow, and hard to make it work with anything else. The latest version of this is probably MQTT. MQTT has Microsoft support. That’s a big deal. With MQTT devices “publish” tags and other devices “subscribe” to those tags. Unlike Foundation (and ABs EthernetIP) MQTT is very simple. So for a data logger for instance you just set up the tags you want to log and set up a database to record the MQTT tags. MQTT can work over anything but it works over any “IP” network (Bluetooth, Ethernet, WiFi, internet).

Back in the 1980s we had the same arguments. There are major differences between PCs though and PLCs. The first one is look at a laptop. How many ports do you see? Even very port heavy PCs may have a dozen ports. Compare that to say the low end Automation Direct Click PLC. The base PLC has 3 communication ports and 14 digital IOs plus an expansion port that allows up to 8 IO cards with up to 16 IOs per card for a total of around 150 IO ports.Plus more if we use networking but PCs can do that, too. PLCs are simply optimized specifically for handling hundreds to thousands of devices, especially very cheap ones like a push button. You can argue for more complicate network systems but if you’ve ever spent time troubleshooting networks vs 24 VDC push buttons you can appreciate the simple approach. And that’s my second point.

The third point is that PLCs essentially simulate relay logic. Ladder logic is a very natural language for industrial controls electricians and engineers. Most of them are not “programmers”. Javascriot and HTML (never mind the back door methods to pass communication around like REST or XMLHTTPRequest) are far more complicated to use in practice. As a great example node.js and subsequently Node RED were developed specifically to make HTML 5 and Javascriot easier to use.

The fourth point is if you notice what happens to laptops in the field. Or when an engineer excitedly brings an embedded PC out and wants to use it on an industrial plant. As an example MCCs are electrically very “noisy” places with nearly constant surges. VFDs generate tons of harmonics, and even a simple heavy contactor generated an enormous transistor destroying inductive kick. A PLC has RC snubbers or diodes on the outputs, high side drivers, and optocouplers on inputs. Even without considering dirt, dust, vibration, and moisture the electrical environment itself easily blows up most “Arduino” type devices.

So no I’m not expecting PLCs to disappear any time soon and my interest in Codesys is not going away from PLCs. It’s simply recognizing that a PLC IS a computer running a very specialized computer language and operating system.


----------



## mburtis (Sep 1, 2018)

I think it will be interesting to see what automation will look like in 30 years. If you would have shown an hmi wirelessly connected to an iPad to somebody in 1990 they wouldn't have believed it. I did just that the other day with cheap hardware.

I mean a lot of modern temperature or pressure sensors aren't just a simple device that puts out some raw signal. They have the brains built right into them to take care of scaling into engineering units, calibration, data logging, alarm setpoints, and a host of other programmable features. 

It really doesn't seem that far of a stretch to envision components that talk directly to each other. For instance a pressure or level sensor that talks wirelessly to a pump or pumps. The pumps have vfds and other smarts built into them and automatically adjust speed depending on the information the pump is receiving from the sensor. At the same time the sensor and the pump are wirelessly sending data to a database somewhere that's connected to a mobile app for monitoring and control. No in-between controller needed, just configuration of programmable smart devices. The technology to do this exists now, just imagine what might be possible in another 30 years. Now this would require a globally common and open communication and control design so that everything can talk to everything. That's never been a strong desire among automation companies.


----------



## Navyguy (Mar 15, 2010)

I think the main issues continues to be robust security. Generally speaking when we use specialized equipment like PLC, we tend to keep them off the admin network, which for many keep a physical air gap between the outside world and the process.

Now with the promotion of IoT (which actually has been around for quite awhile) the potential for continued security violations will increase as we move toward a “ethernet” connected device structure that can be connected to any wired or WiFi network.

Only companies that are spending the time and money on creating a DMZ between their process (industrial) network and their administrative network are the one situated for this type of transition.

I think the future will be that all sensors, readers, controllers, etc. will be network connected via standard TCP/IP and the actual processing of command will either be in the device directly or on a network server.

Cheers
John


----------



## paulengr (Oct 8, 2017)

Navyguy said:


> I think the main issues continues to be robust security. Generally speaking when we use specialized equipment like PLC, we tend to keep them off the admin network, which for many keep a physical air gap between the outside world and the process.
> 
> Now with the promotion of IoT (which actually has been around for quite awhile) the potential for continued security violations will increase as we move toward a “ethernet” connected device structure that can be connected to any wired or WiFi network.
> 
> ...


Your description is a bit off. Local networks (Zigbee) are good when you get into crazy situations. For instance it’s one thing to send a digital or even analog signal across a slip ring on a machine with a pivot but very different to send network signals. AGVs (autonomous vehicles) and crane controls are the extreme example. That’s where wireless communication makes sense. But most of the “wireless everywhere” schemes miss the obvious that you still have to run power. And although HART itself is crap and in need of competition HART allows “smart” sensors to do communication and even configuration on existing 2 wire 4-20 mA loops. You can even do wild things like add another sensor to an existing one piggybacking on HART. The closest equivalent digital system is either ASI bus or POE Ethernet.

IOT is more of a matter of use. A big one is water plants. It is very common to have remote pumping stations (boosters, lift stations, raw water stations), as well as water towers and such scattered over a large area. Many cities have hundreds of them (Virginia Beach has over 400). Years ago they used various FM radio systems (Moscad was popular). These were all slow but had good range (10-20 miles). Eventually this has given way at first to WiFi. But the cost of data only low bandwidth cellular has gotten so cheap (under $5/month/radio) that in many cases they aren’t maintaining their own networks anymore and simply going to cellular data radios (“IOT”). An extreme example is the GuardDog SCADA system. You basically buy and hook up a cellular data box in your existing enclosure. Login to GuardDog, put in the serial number and pay for the new device. It automatically sets up everything else. No expensive system integrators needed. There are also lots of companies selling wireless remote vibration monitoring, security (Ring and competitors), and similar stuff. It all works very well in the right application.

An example of IOT gone bad is in a kiln operation in North Carolina. A very talented Honeywell salesman managed to convince the plant to put in battery powered WiFi sensors even replacing existing but not working sensors. This is what you are suggesting. It “head” end was essentially a Modbus server. It worked when the kiln was down. Almost immediately there were issues. The biggest one is the output was “hold last state” and had no diagnostic data on batteries or dead sensors. So you basically had to notice nothing was changing. After that in kiln conditions the “5+ year” battery life turned out to be measured in months, not years. Granted this is an example of massively bad applications and hardware but still…fixed infrastructure is massively simpler, cheaper, and easier to troubleshoot and repair.

If you’ve ever tried solving network issues never mind wireless you’d appreciate troubleshooting simple 2 wire thermocouples or 3 wire RTDs or 2 wire 4-20 mA any day.


----------



## NC Plc (Mar 24, 2014)

Navyguy said:


> I think the future will be that all sensors, readers, controllers, etc. will be network connected via standard TCP/IP and the actual processing of command will either be in the device directly or on a network server.


I come from a hobbyist background with regards to poking around networks, security escalation, etc. My hope and prayer is that we do not embrace Industry 4.0 until network is treated with greater care than physical security, even though physical security is rarely adequate. 

It's easier to keep a network with PLCs connected to each sensor safe than to put every sensor onto a TCP/IP network and keep things safe because you've expanded your attack vector list by orders of magnitude. As it stands, with few exceptions, if it's connected to a TCP/IP network it can be hacked. Either there will be a zero day, or patches not being applied, or the network will not be properly layered, or privileges will be given out too freely, maybe they gain access using a simple ARP poisoning attack, or whatever. Every device you put onto a network is a potential vulnerability and the manufacturers of our networking components do not put adequate work into testing for vulnerabilities, adequate speed and resources into responding to issues found by security researchers, are often hostile towards said researchers, and do not have the infrastructure in place to adequately alert every owner of said networking devices to let them know to patch their devices. The owners may not have the capabilities to patch the devices either. 

Network security is the wild west right now. What I always say is companies invest the absolute minimum into network security and a little more into physical security, while adversaries are investing billions collectively to break in and look around. The last thing we need is every sensor on TCP/IP until network security is taken seriously.


----------



## splatz (May 23, 2015)

NC Plc said:


> As it stands, with few exceptions, if it's connected to a TCP/IP network it can be hacked.


I see what you mean, however I don't think IP itself is the culprit. I don't think there's anything inherent in IP that makes it less secure than say modbus over rs485.

Think about what happened here. At one point in time a computer that could run a full operating system like Windows or Linux was physically large and fairly sensitive, it was not practical to try to make it run something like a PLC. Now, you can get cheap powerful hardware in a tiny package, and you can run Linux on a Raspberry Pi. You might even be able to make the hardware industrial duty. 

But the more capabilities are built into the operating system, the more attack vectors are present, and the larger the security exposure. Run ps aux or look at the task manager in windows and see all the stuff that's running in the background on a full service operating system, that's the problem. On an embedded system, a lot of that is stripped out, but the full scale operating systems can only be stripped so much. 

So someone designs an HMI and rather than build an OS from scratch - costly, expensive, requires a lot of know how - they embed linux. Maybe they even outsource the development to India or China. That system has a lot of security vulnerabilities lurking under the covers. 

If you go another way, and take a special purpose operating system - no general purpose fat lurking under the covers - and add IP capabilities to it, it has a far smaller security exposure. If you add some reasonable security practices, like encryption on the wire and client and server certificates, things would be pretty damn tight if you ask me. 

These systems are largely forgotten now, but something similar happened with general purpose systems back in the 90s. The IBM AS/400, and it's successor the iSeries, added IP capabilities to their exceptionally secure operating system. It wasn't that hard for IBM to develop these systems, they were already secure and added IP capabilities in a secure manner. It will be a much bigger step for industrial products, they've been ignoring security from the ground up, relying on the lock on the cabinet door to be their main security.


----------



## mburtis (Sep 1, 2018)

I'll admit the security aspects of the modern control system scare the hell out of me. I don't know enough about it and don't really want to. As you guys have brought up, security seems to be the biggest challenge looking to the future.


----------



## paulengr (Oct 8, 2017)

The big advantage of IP packets is the whole point of the internet itself. It is very easy and has become standard practice to use firewalls and other methods to restrict the available attack surface.

As an example after repeated problems with Google basically giving my personal data to spam networks and charging me for the photo service I found myself running my own server. On the first attempt I just set it up “wide open”. I know and understand security and felt pretty secure. What I immediately say was dozens of attacks per hour, mostly from IP addresses in Russia and China. To be honest I don’t care. They were all pathetic attacks like attempting to login with “password”. None of it was anything sophisticated at all. But it flooded my security logs and it was annoying. So at first I limited all ports except the essentials (photos, file sharing, etc). I did all my administration from the LAN so remote access except to critical functions like photos was blocked. Only secure ports were allowed Eventually I moved to a CDN for performance reasons and at that point blocked everything not originating from the CDN or the LAN (because I can). Obviously I don’t even see the traffic, pathetic or not, because the attack surface is so tiny.

You can’t get this aggressive with a PLC but you can come close. I see no reason that the PLC can or should be involved.


----------



## NC Plc (Mar 24, 2014)

splatz said:


> I see what you mean, however I don't think IP itself is the culprit. I don't think there's anything inherent in IP that makes it less secure than say modbus over rs485.


A big one is the proliferation of tools available. Anyone with Google can download Kali, read some blogs, and start breaking into stuff that have not been set up correctly. None of these protocols are set up to be secure, TCP/IP was designed to make communication possible and not to keep it secure. 

Morley actually invented the PLC because he was tired of spending so much time implementing the computers (whatever they were called) he had to implement and wanted to automate things since often times they were more similar than they were different. He hated when people called them computers and designed them specifically with industrial environments in mind. He wanted something rugged and built it from the ground up to make his job easier. 

The problem with running Windows or Linux is the computers that they're glitchy, slow, full of security holes, resource hogs, not industrially hardened, etc. Even now, decades after the mess that was Windows 95, Windows is still a sluggish resource hog that randomly freezes. We need reliability and uptime in the PLC world, not glitches. When I set up a PLC for a site I want to know that if something happens it's due to a power surge, equipment failure, or operator error and not due to a hack. 

Verizon's AS/400 was hacked. Regardless of how secure the system is believed to be, there is almost always a way in. Sometimes, it's as simple as the administrator not setting things up properly. 

The biggest issue with putting everything on IP is that there have been many cases of IP devices sourced from China having unknown (or intentional) flaws in the hardware. Here is one example. I could pull up at least a dozen more. Putting every sensor on IP just opens up your plant to a excessive amount of risk and you have to have a competent IT security team to set up the network layering,keep everything patched, monitor the network for any suspicious activity, etc. Sometimes, even encryption isn't sufficient. 

It's a complicated minefield and I think we should move things slowly while we try to navigate it. The first people across the minefield are unlikely to make it across unscathed.



paulengr said:


> I know and understand security and felt pretty secure. What I immediately say was dozens of attacks per hour, mostly from IP addresses in Russia and China. To be honest I don’t care. They were all pathetic attacks like attempting to login with “password”.


Those are just bots scanning the internet for routers that haven't been set up. Sometimes, the router has a backdoor, and if they find a router like that while scanning they'll visit it later. I can't recall who it was off the top of my head but a major router manufacturer had a huge flaw in their routers that let anyone that knew the flaw gain access to the admin portions of the router. If I recall correctly it was a setting that shouldn't have been included which allowed anyone to transfer files to and from it. When security researchers notified the company of the flaw, they basically ignored it until the security researchers forced their hands by uploading a note to tens of thousands of routers that they were vulnerable and going public. 

The PLC shouldn't handle security, that didn't exist when Morley made them, but if you keep your sensors as HART and connect them to the PLC, you reduce the attack surface from a thousand sensors to 1 PLC. That's a lot more manageable, even though Triton is an example of PLCs being modified in an attempt to create a disaster. 

This doesn't even touch on stuff like SIM swapping, where 2FA was being hacked by cloning phones. I bring it up due to how many years it took phone companies to get off their ass and start offering ways to prevent it. It's still a problem and many phone companies don't even offer anything to deal with it, which goes to show how lightly companies take security when it should be a high priority. 

I'm absolutely not a NetSec guy and my knowledge is minimal compared to a CISSP, but the digital landscape is a wild place and it feels like we're at least a decade or two from things being properly secure given how slow things move. I love the convenience of being able to dial into sites remotely to help them out, instead of playing phone tag and trying to direct them through the HMI to figure out the issue, but I don't like the idea of how lawless things can be.


----------



## splatz (May 23, 2015)

NC Plc said:


> A big one is the proliferation of tools available. Anyone with Google can download Kali, read some blogs, and start breaking into stuff that have not been set up correctly. None of these protocols are set up to be secure, TCP/IP was designed to make communication possible and not to keep it secure.


You notice that Kali is mostly for breaking into Linux based things and old versions of Windows? 

You'll read that statement many many times, that TCP/IP was never meant to be secure. If you peel the onion, what does it really mean? TCP/IP is kind of an odd term. IP (*I*nternet *P*rotocol) is at layer 3 in the OSI model. TCP (*T*ransmission *C*ontrol *P*rotocol) is at layer 4, along with UDP (*U*ser *D*atagram *P*rotocol). However a bunch of other higher level protocols are included in what people refer to as TCP/IP, they call it a "suite" of protocols, including higher level protocols. What they seem to be referring to as TCP/IP is all the network stuff in BSD Unix. (All this stuff was developed long before Linux, which started as a project to make Unix run on intel 386 processor machines.) I think when people make blanket statements they're aiming them at the entire suite, including application layer protocols like SMTP, NTP, syslog, HTTP, DNS. I think there's a lot of legacy rehashed code in almost everyone's products there and that's where the security stumbles. 

In fact maybe it's that security belongs at the higher levels. (How much could you implement in the transceivers?) Saying IP is insecure seems a bit like saying Cat5 is secure, like blaming the truck for the truck bomb.


----------



## splatz (May 23, 2015)

NC Plc said:


> Verizon's AS/400 was hacked. Regardless of how secure the system is believed to be, there is almost always a way in. Sometimes, it's as simple as the administrator not setting things up properly.


This is what I read. 

A Verizon employee database was stolen by a hacker, now held for ransom - The Verge 

A hacker *claims *to have perpetrated a social attack by calling a Verizon employee and getting them to allow a remote support session, then ran malware to steal info in an employee directory, then demanded a ransom threatening to release the data. Verizon claims the data was in a publicly available directory - employee names, ID numbers, work phone numbers, and work email addresses - nothing sensitive, no social security numbers, etc., and that they did not pay. Hacking a person that has access to the AS/400 isn't hacking the AS/400.


----------



## NC Plc (Mar 24, 2014)

splatz said:


> You notice that Kali is mostly for breaking into Linux based things and old versions of Windows?


That's not true at all. Kali is widely used to poke around in modern networks. 



splatz said:


> Saying IP is insecure seems a bit like saying Cat5 is secure, like blaming the truck for the truck bomb.


That's an apples to oranges comparison. TCP doesn't have any security checks to prevent eavesdropping, packet modifications, IP modification, it doesn't offer data encryption, etc. It wasn't designed with those in mind, so we have no choice but to implement security at other layers. 



splatz said:


> This is what I read.
> 
> A Verizon employee database was stolen by a hacker, now held for ransom - The Verge
> 
> A hacker *claims *to have perpetrated a social attack by calling a Verizon employee and getting them to allow a remote support session, then ran malware to steal info in an employee directory, then demanded a ransom threatening to release the data. Verizon claims the data was in a publicly available directory - employee names, ID numbers, work phone numbers, and work email addresses - nothing sensitive, no social security numbers, etc., and that they did not pay. *Hacking a person that has access to the AS/400 isn't hacking the AS/400.*


To respond to the part in bold, social engineering is an aspect of gaining unauthorized access to systems you wish to penetrate. It has always been an aspect of hacking and some hackers are not so much technical as they are brilliant social engineers.

From an article discussing the hack you linked above:



> While the database does not include information such as Social Security Numbers, passwords, or credit card numbers, the stolen information is still potentially dangerous. It could be useful by criminals who want to target the company employees—or impersonate an employee while talking to another one—to get access to internal tools. Such an attack would give the hackers the ability to impersonate Verizon employees and, if they’re able to trick them, have full access to systems that could allow them to look up users’ information and transfer their phone numbers in what is commonly known as SIM swapping.


Technical link about the breach.

"A little bit of a mouthful there, but the reference to AS/400 is purely to be in line with Verizon’s report. So, what happened in this hack? Well, *a hacker was actually able to take advantage of some known vulnerabilities in the payment software*, that they were using and was able to extract more than 2 million records out of that database. "

A separate link explaining the hack.

Privilege escalation attack from the internal network. This link is a report of from a security researcher hacking the AS/400.

Also, social engineering is a big part of how many hacks are executed, and they have an entire area dedicated to it at DEF CON. When pentesters are hired to hack a bank, they'll go to the bank during normal business hours and deposit a rubber ducky, and sometimes they're able to take machines out of the banks.

I can say with confidence that the AS/400 has been hacked.


----------



## splatz (May 23, 2015)

NC Plc said:


> Privilege escalation attack from the internal network. This link is a report of from a security researcher hacking the AS/400.
> 
> I can say with confidence that the AS/400 has been hacked.


I am not buying that example. Look at this 

[QUOTEFrom this point, the test user is no longer restricted to the functions of the initial program but can execute arbitrary commands (with its own privileges) ][/QUOTE]

That is by design. The system is not intended to keep a user off the command line; it's a command line system. The user would be at the command line with only the privileges they are supposed to have. If someone implemented a system based on the assumption this screen keeps them off the command line, they didn't really understand the system. The AS/400 command line is far, far more secure than the *nix command line. 

If someone wants to separate the user and the command line, you would typically use a three tier architecture with middleware keeping them apart. Most modern (like post 1990) AS/400 systems have middleware between.


----------



## splatz (May 23, 2015)

NC Plc said:


> That's not true at all. Kali is widely used to poke around in modern networks.


I am familiar with the tools on the Kali distro, AFAIK they are just exploiting the unsalted hashes in Microsoft fallback authentication. In a peer to peer network the vulnerability is always there and in older Windows implementations it's there, but in current Active Directory environment authentication doesn't use the fallback methods and they can even be disabled if that level of security is necessary.


----------



## NC Plc (Mar 24, 2014)

splatz said:


> The user would be at the command line with only the privileges they are supposed to have.


They specifically say they have side stepped those restrictions and gain access to commands they didn't initially have access to. It's stated that they took advantage of the machine not being configured correctly and elevate to Security Administrator authority. This is by definition hacking the AS/400. Privilege escalation is just one avenue hackers can use to sniff around areas they shouldn't be privy to.



splatz said:


> I am familiar with the tools on the Kali distro, AFAIK they are just exploiting the unsalted hashes in Microsoft fallback authentication. In a peer to peer network the vulnerability is always there and in older Windows implementations it's there, but in current Active Directory environment authentication doesn't use the fallback methods and they can even be disabled if that level of security is necessary.


The Kali distro has around 600 tools in it for checking a variety of areas in a network. A big area in hacking is just looking for known vulnerabilities that haven't been patched; often those vulnerabilities are added to tools for things to check for when sniffing around.










This is what I was referencing in an earlier post about routers having inherit vulnerabilities. PoC.


----------



## paulengr (Oct 8, 2017)

Let’s focus on IP for a second. IP is as simple as it gets. It has a source (that may be faked), a destination, and some data. That’s it. There is no security at this level and there shouldn’t be.

At the next level up we have UDP, TCP, ARP, ICMP, and a few others. At this point we are getting into more complex protocols. We are vulnerable to DDoS attacks and with TCP various hijacking and man-in-the-middle attacks. There are also routing issues whether used for good (PI Hoke) or evil. At this point though attacks are very low level. There are things that can be done though and this is where basic firewalls come in.

Above this level we get into applications and that’s where the attack surface greatly expands, but where we finally get into security. We can do end-to-end encryption and authentication such as DNSSEC and DNS based authentication.

But this is all focused on external attackers. Most of my serious network problems came from IT making network changes in the middle of the day without the slightest thought or hesitation as to the consequences. Or in programming issues that crapped all over other things. Physical network design and security, rate control (not the Cisco kind), matter.

Each PLC (or system) should be an island as far as it’s primary functions. As far as Ethernet vs say HART, I’ve got news for you. Long term, you can forget about playing that game. Ethernet interfaces are mass produced in huge quantities which makes it so cheap even serial protocols (CAN, Modbus, etc.) can’t compete. AB accepted this reality with Ethernet/IP. Siemens tried to duck it with Profinet. Beckhoff and others have improved on it with Ethercat. And Modbus TCP is just about the most simple of all. All of this points to the idea that at least at the Fieldbus level, the PC hardware win. Ethernet is the universal protocol at least to some degree. That being said although as I mentioned security is nonexistent with all of these. A possible exception is safety functions. Although not built for security as such tampering with safety functions shuts down a system. So it comes down to that and blocking ports. But frankly you can’t stop the human element internally. Better to use traditional security methods to take care of that.

As far as “industrial” Windows in any version is getting better but hardly what I’d consider anything I like dealing with, even in the HMI-SCADA side of things. My home server is Linux. Uptimes are in years. I have rebooted them once about a year ago but that was for a major operating system upgrade. On my 5+ year old laptop that has never been disgraced by Windows except in VMs it takes about 20 seconds for the BIOS to boot. Linux itself boots in under 5 seconds. That’s on par with most PLCs and VFDs. The BIOS POST is the slowest part of the entire boot process. I’m only using a SATA SSD and I’m using a fairly bloated version of Linux. On the same machine Windows VMs are noticeably slower but that’s true of Windows in general. Who knows what the last time it was refactored.


----------



## splatz (May 23, 2015)

I think we're mostly in agreement but I still don't consider that a hack to the AS/400. Keep in mind, the AS/400 system was audited by people way, way more formidable than the blogger you posted, government, military, banks, etc. etc., for many years, and legendary for security. If a hacker finds a hole in a day or so of playing around, that would be like setting up a lab and figuring out cold fusion in a day. Well, maybe a week  

Social hacking is not hacking the AS/400, it's hacking the end user. Social hacking is what you have to resort to if the system you want into is too tight for your hacking abilities. Anyone can find a sucker, there's one born every minute. It's the lowest form of hacking, people are supposed to be that way. Least-privilege is what trims the exposure to social attacks, but you can't eliminate it until the systems run with no humans involved. 



NC Plc said:


> They specifically say they have side stepped those restrictions and gain access to commands they didn't initially have access to. It's stated that they *took advantage of the machine not being configured correctly* and elevate to Security Administrator authority. This is by definition hacking the AS/400. Privilege escalation is just one avenue hackers can use to sniff around areas they shouldn't be privy to.


There you go: that's not hacking the AS/400, that's hacking some administrator's or programmer's insecure setup on the AS/400. 

What was happening there I think you already understand but what that system was set up to do was replace the user's shell - by default the OS400 command line - with an application program. The program was running with more privilege than it should, lazy programmers and administrators do this *all the time *because it's easier to run with unlimited privilege rather than iron out proper least-privilege access. They figure the end user is safe in the sandbox they create, but they forgot about spawning a subshell, which would be at the parent processor's permissions - and they opened that wide open. 

(Programmers and tech support people do this all the time. I can't tell you how many times I have had tech support people tell me to turn off UAC and the windows firewall as the third troubleshooting step. Steps one and two are make you reproduce the problem, then reboot the computer and reproduce it again, then turn off all security "nuisances" <<-sarcasm> like firewalls and UAC...)

If someone loads insecure application software on the AS/400 and it results in a breach, it's not the AS/400 operating system that got hacked, there's not going to be a security update for OS400 to fix that, OS400 worked as programmed and somebody did something stupid with it. It's more complicated but it's really no different than using a weak password, I don't consider that a security flaw in the operating system.


----------



## NC Plc (Mar 24, 2014)

splatz said:


> I think we're mostly in agreement but I still don't consider that a hack to the AS/400. Keep in mind, the AS/400 system was audited by people way, way more formidable than the blogger you posted, government, military, banks, etc. etc., for many years, and legendary for security. If a hacker finds a hole in a day or so of playing around, that would be like setting up a lab and figuring out cold fusion in a day. Well, maybe a week


I get where you're coming from but hacking has evolved from what it used to be back in the day. These days hacking includes the privilege escalation the blogger showed utilizing a test account on the internal network, exploiting a vulnerability in a router to gain admin access, exploiting Teamviewer to gain remote access, exploiting software loaded onto a machine that hasn't been patched, having the user unknowingly install a root kit and using that to gain access, etc. It also includes the social aspect as well, the way Verizon cell cloning happens is sometimes social engineering, sometimes running into the store and grabbing the manager's PDA to quickly clone so you can bypass the 2FA and transfer funds within 10 minutes, etc.

Back to the AS/400, DEF CON had a speaker that spoke about hacking it. I'll have to watch this later to see what they're talking about and how they got into it, or whatever they did. DEF CON is a hackers convention where white, black, and gray hats come together to talk about nerd ****.

Pen testing is a job that ethical hackers perform where, with permission, they use any means necessary to break into the target. The target could be a building, a computer, whatever. The objective could be manipulating customer service to gain unauthorized access, or getting into a bank to deposit a rubber ducky onto one of their computers, to walk out of the bank with computers, to get into a fortune 5 company's R&D building, whatever. Social engineering is one of the most common ways for hackers to gain unauthorized access these days. Legally speaking, when I used privilege escalation to hide games on my high school's computers, I was hacking. Even though I didn't use custom written scripts or anything, I just poked around and found that their network wasn't properly set up which allowed me to hide SCBW on a networked computer. I'd copy it over to my computer, play, then delete it at the end of class. When I was a teenager I found a flaw in AOL that let me swap users without knowing my parents password, which let me change my account's permissions so I could look at boobs on the internet then change it back when my parents came home. It's all hacking, even if it's wildly varying methods and levels of technical know-how. My stuff was amateur hour and was more dumb luck than technical know-how. 



paulengr said:


> But this is all focused on external attackers. Most of my serious network problems came from IT making network changes in the middle of the day without the slightest thought or hesitation as to the consequences. Or in programming issues that crapped all over other things. Physical network design and security, rate control (not the Cisco kind), matter.


That's the thing, you gotta have a good NetSec guy to set it all up and maintain it. A lot of businesses just aren't willing to make that investment and lock everything down properly so Jim Bob the Net+ IT guy can't make random changes and cause a network storm or whatever. Target's database hack, where millions of customer's info was leaked, was due to a flat network IIRC. They also didn't salt the database which is... ridiculous... but it just shows that when it comes to the NetSec side a lot of companies just don't take it seriously. This is just a casual outsider's observation though, I never went through with my NetSec education. I'll probably cover it in my CompE degree but for now it's on the back burner. 



paulengr said:


> Each PLC (or system) should be an island as far as it’s primary functions. As far as Ethernet vs say HART, I’ve got news for you. Long term, you can forget about playing that game. Ethernet interfaces are mass produced in huge quantities which makes it so cheap even serial protocols (CAN, Modbus, etc.) can’t compete. AB accepted this reality with Ethernet/IP. Siemens tried to duck it with Profinet. Beckhoff and others have improved on it with Ethercat. And Modbus TCP is just about the most simple of all. All of this points to the idea that at least at the Fieldbus level, the PC hardware win. Ethernet is the universal protocol at least to some degree. That being said although as I mentioned security is nonexistent with all of these. A possible exception is safety functions. Although not built for security as such tampering with safety functions shuts down a system. So it comes down to that and blocking ports. But frankly you can’t stop the human element internally. Better to use traditional security methods to take care of that.


Yeah I know and I'm not against Ethernet supplanting the seemingly dozens of mfg specific protocols, it makes me roll my eyes when a plant is using brain terminal instead of HART or even FF. I wouldn't want HART to be used for everything but I do like it for connecting transmitters to PLCs and wireless HART is a thing these days. Since everyone wants PLCs to be able to be monitored remotely, which is a security nightmare, I can feel a little better if they're keeping all I&C controlled with HART and the PLCs / HMIs as the sole points of contact for the network. It at the very least reduces the number of attack vectors from thousands to dozens, which is far more managable. Then just stick a hardware firewall and restrict the IP ranges that can access stuff, as a start. While most plants don't take the internal human element seriously, look at people plugging USBs they find into work computers ala Stuxnet, it's a lot easier to manage that than a massive network with multiple layers and redundant rings. 


paulengr said:


> As far as “industrial” Windows in any version is getting better but hardly what I’d consider anything I like dealing with, even in the HMI-SCADA side of things. My home server is Linux. Uptimes are in years. I have rebooted them once about a year ago but that was for a major operating system upgrade. On my 5+ year old laptop that has never been disgraced by Windows except in VMs it takes about 20 seconds for the BIOS to boot. Linux itself boots in under 5 seconds. That’s on par with most PLCs and VFDs. The BIOS POST is the slowest part of the entire boot process. I’m only using a SATA SSD and I’m using a fairly bloated version of Linux. On the same machine Windows VMs are noticeably slower but that’s true of Windows in general. Who knows what the last time it was refactored.


I'm with you in that I abhor Windows. I use it, because I have to, but outside of my college tower and work computer I use Linux distros. I don't want it replacing PLCs but it's highly preferred to Windows for me. Unfortuantely a lot of software I have to use like MicroCap, CAD, PLC programming platforms, etc keeps me on Windows at work. I'm at the point where I will probably start running Windows in a VM when I upgrade my tower again with all the bloat/spyware they put on it these days. It's only going to get worse.


----------

