10 nasty software bugs put thousands of fuel storage tanks at risk of cyberattacks Tens of thousands of fuel storage tanks in critical infrastructure facilities remain vulnerable to zero-day attacks due to buggy Automatic Tank Gauge systems from multiple vendors, say infosec researchers. Automatic Tank Gauges (ATGs) are used to monitor fuel levels in storage tanks and ensure that the tanks don't leak. The …
Its obvious to people in IT, but the people who deployed these things were chemical engineers. The guy who understood Windows the best was probably chosen by his boss to read the manual on the new geewhiz device and make it accessible so the boss could check everything was OK from home.
"Its obvious to people in IT, but the people who deployed these things were chemical engineers."
I don't know about the US but in AU I recall chemical engineering students in the mid 1970s using computers to monitor and control physical and chemical processes - this at a time when the great unwashed wouldn't have known a computer even if it were dropped on them with a flashing sign displaying "Computer."
So I suspect the selection of device and subsequent connectivity choices weren't made by chemical engineers.
Twenty+ years ago, sad to say, the main culprits in attempting to put anything and everything on the internet were from IT (excepting the paranoid BOFH and the rare security minded bird.) Daft then, dangerously insane now.
Most of these monitoring devices could communicate over wet string but certainly don't require 10Gb ethernet so the resources for dedicated disconnected networks for this stuff aren't a great ask as they could run over a single wire pair and not even require the complexity of tcp.
I would guess tike a lot of monitoring kit the basic device is fairly simple consisting of one or more physical sensors with some integrated microelectronics to produce digital output. The problem starts when these devices are integrated with a single board computer (with networking) and rather than just organising the sensors' output and communicating the data to upstream monitoring systems some genius thinks "wouldn't it be great if we ran a full OS and web server on the device and allow remote (re)configuration of the system and sensors' parameters?" [Hint: No it wouldn't.]
"I don't know about the US but in AU I recall chemical engineering students in the mid 1970s using computers to monitor and control physical and chemical processes - this at a time when the great unwashed wouldn't have known a computer even if it were dropped on them with a flashing sign displaying "Computer.""
Similar here in the US ... Try connecting to the gear that monitors The Beam at SLAC, for example. Or the controls for the Stanford Dish. Or San Francisco's Hetch Hetchy water supply. Or rather, don't bother. You can't. Grad students wanted to hook 'em up to the fledgling 'net back in the late '70s or early '80s. The sane among us put the kibosh on their plans.
Commercial interests of today, however, are truly insane. We've tugged on their capes, and got shrugged off. We tapped 'em on the shoulder & were elbowed away. We pulled on their shirts, and were thrust aside. Some even kissed their boots, and were trodden upon. Our message was always the same: "Please, PLEASE, **PLEASE!!** don't connect SCADA kit to publicly available networking systems!"
But do they ever listen? No. They do not. The idiots.
And all so they can show their mates a pretty real-time graph down the pub, and nothing else. Sad thing is, most of them don't have the foggiest idea what the graph means ...
On the bright side, those of us with a clue are making a pretty penny in our retirement, cleaning up the resulting mess :-)
Yes, I know, I've posted this or similar before. Prior posting doesn't affect reality, nor appropriateness.
I think you'll find that the people who deployed these systems were either vendor reps or specialist instrumentation techs. But the systems themselves should have been protected, and the IT bods who hooked them into the corporate network should have understood the risks of compromise and mitigated them.
"but the people who deployed these things were chemical engineers."
I have the feeling it's manglement. They want to be able to call up every asset on the books and look at the reading. Very fancy when you are trying to impress somebody, but has no real world function outside of that. It would be easy enough for each site to have measured things report their readings to a log every so often and the log is all that's visible, not what's feeding it. Any direct polling should be locked down something fierce.
It's a fuel gauge. I understand why it needs to be connected to the net, but maybe on a VPN? Maybe output-only?
I remember seeing a (water, I think) tank with a cable attached to a pointer running down the side. No danger of hackers getting into that measurement system.
To clarify, I don't blame the IT teams so much as their bosses who NEVER EVER GODDAMN listen them when it comes to security.
However, I've also worked with my fair share of wankers in IT as well who were utterly clueless about security 101. So there's that as well.
So raspberries all around!
Often lags behind the IT thinking on security.
Some OT, by its very nature of operations, is incredibly old, lacks connectivity and may or may not pose a risk.
Then we bring in the concept of IT/OT convergence, which is 90% convenience and cost cutting of engineering staff and maybe 9% operations and 1% security related.
All of a sudden we have all these vendors with edge devices that can interconnect your old SCADA/PLC/HMI etc., then present a picture to you across the internet and we get over excited middle/senior management who are being told it will "save" so much money (read you can lay off staff) but costs millions to deploy for minimal/nugatory amounts of validated and realised improvements!
The idea that we need connectivity to critical OT and plant equipment across the public internet is the lions share of the problem.
Plant operations are generally very light on engineering staff in comparison to a similar IT estate, so deploying an engineer to identify, validate and rectify an issue can seem cumbersome and slow in comparison to a GUI and a manager sitting miles away from the issue, the same manager is being sold that it helps them do the work.....
It needs serious support from vendors to come up with secure methods of operation and the ability to react to CVEs/vulnerabilities as they are identified.
Different "operations".... nigh on 20 years ago my college installed card-operated exterior doors. Cuts the cost of making, issuing, tracking, and recalling metal keys. I look at this and run a jiffy IP scan on my network. Find the controller. Try to log-on and got the maker's name. Googled that and... golly, a full PDF Owner Manual and in there the default root credentials. Which worked. They hadn't changed the password. This in an era where a fresh Windows install would be infected before setup finished, worm-density was that high. The door-security system had been installed by people with NO clue about network security. I printed out a few configuration pages and forwarded to our quite professional network folks.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
