The USG should be deploying thousands of security engineers armed with the latest coding models and agents, in attempt to secure systems before they're hacked. A few billion dollars spent here could save us trillions.
And true air gapping isn't possible because it'll need to be monitored somewhere central so there'll have to be some vpn or mpls whatever. Meaning it can be hacked.
Having it exposed to the public internet is not good practice but should be far from the only layer in its security.
And really, when a PLC is found unfirewalled on the public internet, you can bet that's far from the only security screwup in that infrastructure. If they won't even handle the low hanging fruit.
The largest threat isn't bombs falling on our heads, it's incompetent fools leaving the door open to their enemies.
These aren't mistakes that can be excused. Failing in one's duty to steward important infrastructure must mean immediate replacement of leadership.
Let me give an example: I once worked with an integrator who was working on an AHU feeding an extremely critical portion of a datacenter (I was a lead by this point and mostly played babysitter). During certain points of the day you couldn't open the door to this room due to negative pressure because the logic was over-ramping the exhaust fans. As I watched this contractor work, I saw him open his laptop, with Windows on it (because Microsoft has had a death grip on this industry for decades now), and proceed to backup the PLC program into a massive folder with God knows how many other "customer projects" he was carrying around in this thing. He then proceeded to go do some physical checks in the field, came back, and prepared to upload the fixed program. As I watched, I noticed he _grabbed a backup from ANOTHER customer_ and I immediately had to intervene. Who knows what untold damage I saved from that single move.
I tell this story to demonstrate just how far into the dark ages this industry is. I vividly recall coming into the data center for a fortune 50 company, one everyone here would know, and being astonished that they had never heard of Network Attached Storage or RAID and why they might want to consider a disaster recovery plan for their multi-million dollar mechanical plant.
This industry is in _desperate_ need of strong technical help, but unfortunately the "higher ups" tend to be the same people who are "comfortable" with the way thing are and refuse to move. I literally tried for a decade before giving up and moving into software engineering proper.
So, anyways, just imagine the most archaic and barbaric set of IT software, controls, and procedures, dumb that down even further, and you've landed on the infrastructure/teams that operate probably half of critical infrastructure.
While that’s not the job of the NSA, they do produce a lot of good cybersecurity guides.
They should provide guidance, but I’m not sure we really want the NSA inside of networks more than they already are.
If voters and CEOs don’t want to spend the money required to secure their infrastructure, that’s on them.
While he was on site, I asked him why there was nothing on the PLC or its enclosure to identify his old boss or give any contact information, and he seemed surprised and told me that no one ever does that. I asked how a new owner is supposed to get support, and he shrugged.
If this thing ever fails, I’ll probably replace it with an Arduino or an ESP32 or something along those lines. Or I’ll just find something off the shelf to replace the entire system.
sounds like cope for a bunch of felons that management, its director and congress can't get a handle on.
And remote access to hardware definitely makes management and maintenance a lot easier and quicker. (else you need to drive out for every minor issue)
one argument: only services which need to be available to unauthenticated endpoints should be default reachable.
all other services should be default unreachable (no data plane until authorized ...then use internet and other networks to establish the connections).
yes, that is not always easy. it is much more possible than it used to be.
and arguably we now need to commit to the tradeoffs of default unreachable services.
“Have no access to” I have doubts
It is not a duty nor their responsibility. It is however bad for nation overall if companies don't dedicate some resources to security, so a sane administration will do something to advocate for it.
For example, the NSA should be successfully infiltrating every major foreign hacking team in the world and monitoring and/or disrupting their activities.
In water/wastewater much of infrastructure is physically remote and physical security is the typical engineering trade offs. https://validmfg.com/product/lift-station/
Inside this box you have access to the “production” network, if you will. Unfortunately, most SCADA systems implicitly trust their RTUs/PLCs, so this has always been a weak point for the system. Hopefully the situation has improved.
The reality is that critical infrastructure is rarely tested against genuine hostility, except in times of war. There is “cyber” activity going on all the time, but attacks that require physical proximity will probably only happen when things have escalated to hardware. Hopefully the NSA’s of the world run “pen testing” for these companies from time to time.
If that's an old GE 90-30 (a common FANUC system), it's time to replace it. You're currently in that period when the CPU has reached end of life but the modules are still supported and the vendor has an easy upgrade path. Emerson owns the brand now, and can sell you a new unit that'll run your old program with minimal changes. You can call them and get a list of integrators in your area. It'll be pricey, but you won't need to do it again for another quarter century.
As soon as AI can automate the development and deployment of physical infrastructure and the firmware that drives it, watch how willing to embrace the "cutting edge" those same higher-ups become.
I’ve been doing industrial controls for 15 years and surprisingly infrastructure is some of the most poorly funded. I believe a lot of these places are run by operating companies, so it’s bidded out (we all know how bids work I think). I’m not surprised when I walk into these places and see the computers are running EOL operating systems and the networking is essentially flat.
It is amazing how much of the sysadmin community just doesnt believe this is a thing you need to work with, everyone insisting its just security people being lazy and so on.
Same with SCADA: just as bad as what you describe.
It's HARD to do the right thing. Dragging and dropping files into proprietary hardware management programs is the de facto standard.
Then you layer on top the unfortunate reality that sometimes electricity does weird stuff, people design weird circuits or wire the wrong components in, and firmware tends to have to deal with non-deterministic inputs a lot more often than, say, an API on the web. It's rough.
The pay is also so much worse in my experience.
Breaking into the industrial market is tricky if you don't have connections too. And if you're hired as the PLC programmer, it's sometimes an afterthought AFTER the plant is already built. "What do you mean it'll take another month? The plant is finished, isn't it?".
Oh, and some projects ban "PC"s to begin with. Which sort of excludes any kind of PC programmer. And it sort of even makes sense. A lot of default PC behaviors (especially commercial software), are no longer user-unfriendly but potentially very expensive or even user-lethal when attached to a physical plant.
Sounds like I could learn some things from you (and maybe vice versa). Poke me on the email in my HN profile!
One morning, I heard something terrible while my boss's boss's machine was booting. Something akin to grinding. The thing was angry.
I gave boss^2 a heads-up that his hard drive might be failing, and that he might want to run a S.M.A.R.T. check on the poor thing. I also asked where the backup hard drives were, because I was brand-new and assumed that I just hadn't been issued one yet.
I checked the supply closet, found no hard drives, popped over to the office admin person, and recommended a deal I'd seen on some WD black drives before I realized that the place had gone quiet.
Everyone looked at me like I was from Mars.
Exactly 7 days later, boss^2's hard drive failed. We lost a week of work and had to zero out a 5 days x 3 employees worth of billable hours. We also ended up delivering late.
The client was pissed.
Based on the nasty looks that I got afterwards, it appeared that the standard assumption was that I had tampered with the drive to prove a point. (Um, nope).
I have since learned to ask prospective employers about their backup strategy.
A good system integrator is worth their weight in gold. Sure they cost more, but getting a whole package turned over to you is worth a million more than 5 years into the lifecycle of a factory when someone wants to make mods/fix a bug/etc and has to reinvent the whole car, not just the wheel.
This industry is always 10-20 years in the past. My company’s preferred vendor only just started supporting virtualization (this is for a DCS) in the past 10 years. I still have to tell my sales people to provide A/V and minimalistic backup and recovery on every project (they essentially cost nothing compared to the rest of any project).
It's very common for the proprietary software for interfacing with ancient, expensive machines to break after OS upgrades, so they're probably unpatched... you might not even need to burn a 0-day.
The only exception I can think of would be for meter reading, which should be a separate, read only device with no ability to do harm altogether.
1. Connected naively to the internet.
2. Behind a hardened VPN endpoint which is on the internet.
3. Has a separate physical private network.
4. Requires physical access.
I think it's obvious that #1 should be prohibited in favor of #2. After that point we need to ask what the impact is of a Denial of Service attack that prevents anyone from remotely accessing the system.
The difference between #2 and #3 may depend on whether things could be Very Bad if the system is disconnected at a time of the attacker's choosing. For example, disabling access to flood-control valves during a hurricane.
Obviously we need open source designs.
Perhaps the easiest way would be a Raspberry pi set up with an opto isolated CGA/EGA/VGA/SVGA capture that could be viewed via the internet? (I mean, we're probably talking systems still running MS-DOS or Windows 98 running these systems)
Folly to think otherwise.
I'm sure this exists, but I'd expect CIA to be more involved in any sort of covert operations across nation state lines, especially if undercover humans are involved.
I'm told a box with two optical NICs in it with only one fibre in it, TX->RX, works quite well, plus a bit of software to wrap around it.
But these sorts of organisations love a bit of bureaucratic regulation, and "certified" devices and that sort of thing, so there's probably not much of a market for a data diode without the paperwork.
On the opto isolated idea - I think there was a QR-code and camera based data transfer tool posted on HN a few days ago!
This is already the case. Some PLC allows you to store and retrieve the source code of the programmed directly in the flash of the PLC. Sometimes this feature is behind a higher access level or password.
I remember a time where I was beating the drums on security and ended up in a meeting with a senior red team member in the company. This person was absolutely convinced we were not running Windows Server 2008 anywhere in the company (the year was 2019 at the time of that meeting). Needless to say, he was very concerned when I showed him the 50+ servers running it globally, all covering critical infrastructure.
I think eventually Ragnarok will happen and things will improve. I just hope it's not as detrimental as it seems setup to be.
Incompetence will cost them their job.
If I had fuck you money I'd just call them incompetent fucks and laugh at them.
The result is that anybody who can program well enough to develop software is doing so. Those with any programming skills who remain behind are smart-but-undisciplined programmers, people who have a reason to be in a particular geographic area, too old to think about changing careers, or just plain nuts.
This is what "lack of investment in manufacturing, research, and infrastructure" looks like. Sow what you reap.
Disclosure: I might be one of those people. I came out of grad school in physics research, and programmed an entire plant. Thankfully, that was before it was economical to put every controller on the Internet.
integration tests (which can be trickier when it requires a hardware test bed.)
I use this as a fizzbuzz-type test when I'm interviewing at hardware companies: do they have development hardware in a rack with programmable power supplies and mini-PCs (or similar)? It's a low, low bar for testing, and rules surprisingly many companies.They'll often just have The Guy running manual tests instead.
https://www.cbsnews.com/news/cybersecurity-agencys-top-recru...
That will probably just disappear. Maybe with good intention or maybe with bad, but it's probably gone either way.
If it doesn't disappear, then it's hanging right there for any of the competitors to use. That's a problem for the original installer's ongoing employment.
And if it includes the programming software, then that lets Joe (from over in shipping) have a go at rejiggering the packaging machine. That's a problem for whoever has to pay someone with a clue to show up and fix it.
I'm kind of worried (probably unnecessarily) that posting ideas would get me on some list, but it seems like there would be many simpler terrorism opportunities once you have physical access.
Maybe today I'd do micropython on ESP32. Download text file from device, edit, upload back on.
Taking things offline and properly airgapped can also work, but wouldn't the cost of that exceed making specialized things and maintaining them?
We got into this situation due to cost, not ignorance. Both choices are higher cost than putting ancient devices on the internet.
I think that's one of the core difficulties with PLC programming. You have to have strong knowledge on traditional science fields like thermal dynamics, material sciences, fluid mechanics, etc., while also understanding the limitations of a 16 bit floating point integer and why overflowing that can be catastrophic.
Honestly, I think it's an advantage at this point. Way too much diversity to easily attack remotely.
These things are walled gardens. You never see the operating system. You can only change their behavior using the vendor's software. They generally run a single program (that you write using the vendor's software) on a fixed scan cycle. They read the inputs, run your program, write the outputs, then repeat.
While you're giving up the nearly infinite possibilities that an SBC gives you, the benefits more than make up for the lack of flexibility. They run (and have parts and support available) for decades. Modules are easy to diagnose and replace. An electrician who isn't a programmer can follow ladder logic and troubleshoot problems. Integrators can quickly come up to speed and understand your code.
There's a reason companies will pay tens or even hundreds of thousands of dollars for these things.
Now, if you really want to use rpi as a plc, you need something like openplc or codesys as a runtime, add some HATs for I/O, and use protocols like modbus. It will be a software plc but you are missing the hardware certification and other features. Rpi is good as edge computing rather than plc, like processing vision or data logging, it’s why in drones you need the autopilot AND rpi or companion computer, each does certain functions.
All the ones I've encountered in the wild ran VxWorks
This guy is very happy when someone literally does that: https://www.youtube.com/@Cursed_Controls (great channel btw), because usually he has to deal with worse.
> And if it includes the programming software, then that lets Joe (from over in shipping) have a go at rejiggering the packaging machine. That's a problem for whoever has to pay someone with a clue to show up and fix it.
You'd think Joe from shipping wouldn't be given a key to the cabinet with the PLC.
Is that really an issue? Do PLC vendors have concerns about other vendors turning up and yanking USB drives out of critical infrastructure with reckless abandon? Do the facilities themselves see no issue with potential vendors yanking operational utilities out of their systems while they are running?
Plus, yea, someone could really make a mess even if they have the best intention. A guy from my company almost uploaded the wrong program to a large bioreactor. At best it would have made the bioreactor just unusable until corrected. At worst it could have broken the equipment or caused a safety issue. This guy had been around the block a few times too. Luckily someone noticed before it was too late.
This is a great theory, but practice (over centuries now if not millennia) tells us that critical infrastructure is rarely properly maintained. "If it ain't broke, don't fix it" is the motto of governments and large organizations everywhere when it comes to proper maintenance. As opposed to improper (keep the existing thing running) maintenance, proper maintenance requires being proactive and is expensive, often requiring partial or full replacements of systems while also keeping the old system running until a hand-off time. In order to get a government or corporation to be proactive, they have to see a problem.
No problem, no worry. That it can be hacked is not a problem from their perspective. That it has been hacked might be a problem to them, but only if their constituents find out. More likely, they'll make it the poor engineer's problem, the engineer who had no budget and no staff to address it beforehand.
When it's time to cut costs, proper maintenance is one of the first places organizations look to because it's not a present problem. Then it becomes normal to not do the work, from an organizational perspective, and all those engineers and technicians are just a bunch of Cassandras.
Ostensibly yes, but so far I haven't seen anyone really use a PLC in a way that requires hard real time (so far). The cycle on eg a siemens S7-1200 is anyway much too slow for anything really exciting, and a Pi might very well be more reliable in actual practice, were it not for the very unfortunate tendency to eat SD cards. :-P
(And revolution pi actually ships a hardened Pi for industrial use. So that's one way to go about it. I'm not a big fan of that brand, but it's a data-point. Meanwhile in personal experience some regular pi's left in industrial cabinets for one-off emergency monitoring purposes have managed to stay annoyingly alive over time.)
If you need a computer system to be actually secure, rule #0 is absolutely ensure it cannot receive unauthorized inputs of any kind (airgapped, big Faraday cage, JB Weld all the ports, big scary guys with guns, redundant locks, blast doors, etc). Otherwise you've lost against any sufficiently motivated adversary.
The system I mentioned in my other post controlled some VFDs, and one would occasionally get stuck running at minimum speed forever instead of turning all the off when it should have. Fortunately the only harm done was a stupid waste of power and and nothing was physically damaged. If it had gotten stuck at maximum speed it might have been a different story.
And nuclear isn't exactly a great option.
But on the other hand, even though the Americans suspected that people who merely looked Japanese might be traitors, AFAIK there aren't any clear examples where the people who were sent to camps actually were enemy spies who'd have sabotaged America given the chance. And in Britain the counter-intelligence operation was so successful that when captured German spymasters revealed their list of agents in Britain, every name was already either working for Twenty Department (20 = XX = Double Cross, we can't resist a pun) or in prison for espionage or dead.
† notably in WWII if as a woman you say you want to be on a ship of the line, or crew front line aircraft and attack the Nazis you will be told women can't serve front line roles and at most you'll be doing delivery runs in relative safety. But if you know the right people to become a spy they will cheerfully send you behind enemy lines even though if caught you will almost certainly be horribly tortured and then probably killed and the government which sent you won't even acknowledge you existed for years.
So, maybe the risk from people who are already where your infrastructure is is much lower that you'd think if you haven't invaded them and occupied their land. On the other hand remote adversaries are definitely always a risk.
Like: We took care of the centralized controls for the inmate portion of a jail that was built in the 1980s. We rejiggered the controls for that whole jail back around 2010 or so with new kit and had been taking care of it since then.
All the wiring for all of the individual doors and intercoms was documented in one old 3-ring binder. (There were probably 3 copies originally -- for the architect, the maintenance room, and the equipment room, but just 1 remained and it had hand-written notes.)
One day, around 2020-ish, they called us because the book was missing. I didn't have it (I never once left the equipment room with it), and the co-workers who had been there insisted that they didn't have it either.
As time passed, we'd get occasional phone calls of "Hey, we really could use the book for our building back if you guys ever find it." They weren't angry calls, but sheesh: That book had real value and getting stuff done without it was difficult. So every time when they'd call again, I'd ask around our shop -- again -- if it had turned up anywhere.
And then, finally: One of our guys cleaned out his truck and found it. He must have taken the book out to look at and have a smoke about some problem or other, and then it just stayed in his truck. For years.
This shit happens. People are imperfect and sometimes we screw stuff up.
It's just a thumb drive, on a lanyard, hanging in a cabinet. It's not like it has guards posted. :)
Maybe Joe (from shipping) took it back to his desk to have a squiz at it and try to passively learn something new during some otherwise-downtime and never returned it -- years ago. That cabinet is in his area, so he has the key.
Maybe Tim (the plant electrician) borrowed it to get something else done, and it unintentionally disappeared somewhere along the way. Tim has all of the keys for all of the things.
Maybe Emily (the ubergeek who prides herself on being able to code her way out of a mess on any system) had it in her office before she got hit by a car and lost the ability to communicate with polysyllabic words. She borrowed Joe's cabinet key after he mentioned an issue.
Either way, it was just a thumb drive that had been inside of the cabinet, and now it is gone.
While that works for Chernobyl, if you have a real world systems you might want somewhat more practical access.
Of course exposing industrial hardware directly on the internet is the other extreme, and you get what you're asking for.
Do something in between, if you even just apply normal network security you'll be ahead of the pack.
Problem is, a lot of these systems are not built by IT people. While they have a lot of quite admirable skills, it's just not their primary job, and thus they tend to lack the necessary paranoia at times.
I'd love to see more formal methods come to the field. Part of me says I'll return one day, maybe if AI kicks me out of my software field, but I'd really want to come back at a position I could healthily influence towards safety and correctness.
Meanwhile having a separate copy of the plant is also not often viable, once the plants get to any kind of size.
edit: After having 'someone' fact check and remind me: there are quite a number of simulation tools available that can sometimes partially do the work.
The problem is there's no good way to actually enforce this. Every organization has their own idea of what is "good enough". The NSA has some pretty good advice[0]. But as far as I know there's no written-in-stone engineering standard organizations have to meet, just "best practices". If the building inspector finds fault with the construction of your facility, it gets evacuated and shut down until the defect is remedied. There's no inspector for your network security. That's the problem.
[0] https://media.defense.gov/2022/Jun/15/2003018261/-1/-1/0/CTR...
Yes. I follow up. No one ever knows.
> And that's regular,
Yes
> expected
Yes
> and desired?
No.
And the thumb drive is still gone, isn't it?
---
No, it's not regular. It's not desired.
Does shit never go wrong in your world? If not, then: Perhaps you should start expecting it to. :)