Mysterious Safety-Tampering Malware Infects Second Critical Infrastructure Site (arstechnica.com)

An anonymous reader quotes a report from Ars Technica: Sixteen months ago, researchers reported an unsettling escalation in hacks targeting power plants, gas refineries, and other types of critical infrastructure. Attackers who may have been working on behalf of a nation caused an operational outage at a critical-infrastructure site after deliberately targeting a system that prevented health- and life-threatening accidents. What was unprecedented in this attack -- and of considerable concern to some researchers and critical infrastructure operators -- was the use of an advanced piece of malware that targeted the unidentified site's safety processes. The malware was named Triton and Trisis, because it targeted the Triconex product line made by Schneider Electric. Its development was ultimately linked to a Russian government-backed research institute.

Now, researchers at FireEye -- the same security firm that discovered Triton and its ties to Russia -- say they have uncovered an additional intrusion that used the same malicious software framework against a different critical infrastructure site. As was the case in the first intrusion, the attackers focused most of their resources on the facility's OT, or operational technology, which are systems for monitoring and managing physical processes and devices. The discovery has unearthed a new set of never-before-seen custom tools that shows the attackers have been operational since as early as 2014. The existence of these tools, and the attackers' demonstrated interest in operational security, lead FireEye researchers to believe there may be other sites beyond the two already known where the Triton attackers were or still are present. "After establishing an initial foothold on the corporate network, the Triton actor focused most of their effort on gaining access to the OT network," FireEye researchers wrote in a report published Wednesday. "They did not exhibit activities commonly associated with espionage, such as using key loggers and screenshot grabbers, browsing files, and/or exfiltrating large amounts of information. Most of the attack tools they used were focused on network reconnaissance, lateral movement, and maintaining presence in the target environment."

Comments

Why are these sites connected to the Internet?

[Attila Dimedici]

I know it is inconvenient, but these sites should not be connected to the Internet.

Re:Why are these sites connected to the Internet?

[grep -v '.*' *]

I know it is inconvenient, but these sites should not be connected to the Internet

CEO: What are you talking about?? They're not -- we moved them all to the cloud!

Re:Why are these sites connected to the Internet?

[tlhIngan]

I know it is inconvenient, but these sites should not be connected to the Internet.

Except airgaps have vulnerabilities, or has Stuxnet not taught you anything?

Even isolated networks need updating - and that's where a breach of containment can take place. If your goal is to destroy protections or equipment versus exfiltrate information, that's all you need - just hop from the laptop that was internet connected to the USB drive being used to update the production network and there you go.

And because airgapped networks are a PITA to update, the software running on them is almost hilariously out of date, so finding a vulnerability so you can hop onto the network on USB insertion is laughably easy.

Unless you're a super large organization with dedicated staff who do nothing but maintain the airgapped network (like say, the military) airgapping is not a panacea.

And finally, like all factories, executives will also want some sort of feedback - production numbers and stuff. So there will need to be some sort of facility where production updates can happen in near real-time. Or perhaps some technician overseeing several facilities would like to know if some piece of equipment is failing more often than normal, or if something is approaching its end of life and needs replacement, or even better, if some common failure mode is starting to present itself. All of which are complicated if said tech has to visit every facility in question.

Re:Why are these sites connected to the Internet?

[thegarbz]

I know it is inconvenient, but these sites should not be connected to the Internet.

No it's not inconvenient. It's not actually possible to operate them efficiently anymore. Heck it may not be possible to legally operate them without external connection to push off data in realtime.

Another poster has already told you an airgap is not a panacea. I would argue worse than that, an airgap is effectively bad for security as it leads to incredible overconfidence. Give me a well designed network monitored by a security team over "airgap is our security why try harder" any day, which is ultimately what any airgapped network will reduce to.

Re:Bland language

[Mister Transistor]

Not everything has to be reported with breathless end-of-the-world doom and gloom just to be the best click-bait.

Once in a while it's nice to give the hyperbole and bullshit a rest. However, this is a serious issue that needs to be addressed quickly. Isolation from the internet is probably the best solution, but even that is not idiot-proof (think USB drives in parking lot) and it's massively inconvenient, but until we can develop remote access systems that are truly bulletproof, then we shouldn't be risking our critical infrastructure.

Time to have two operational technology systems

[davidwr]

One, that is modern and feature-rich, and a second one that is very simple, maybe even analog, well-understood, reliable systems which will provide protection when the main system isn't working.

I'll use brakes in trains as a comparison:

You can have a modern system where automated train controls can cause the train to speed up or slow down, but you still have 19th century air brakes connected to some very simple but very reliable sensors. These sensors would detect "critical" things like the train moving too fast around a curve or moving too fast downhill, among other things. If the air-brake line is damaged and loses pressure, the train stops. If any of the simple sensors detect a problem, the trains stops. To get the train going again, a human being has to go to the train and fix the problem with the air brake system or manually reset the sensors.

Apply this design philosophy to any system where you absolutely positively do not want certain bad things to happen without corrective action being taken and/or an alarm sounding, and you'll have at least some minimum level of safety even when your modern technology fails or is compromised.

Re:Time to have two operational technology systems

[dargaud]

Well, I work with critical systems and we kind of do it like this: all the real-time and critical (security-wise) stuff is done in VHDL, then it communicates with embedded systems whose software is updatable. Then those in turn communicate with data-centralization and control/command PCs. If the top or top-2 layers go down, the hardware keeps running and goes in security modes, meaning nothing blows up and things just keep going or stop (depending on the VHDL which is NOT updatable by software).

I know this is a stupid question but

[nehumanuscrede]

It's 2019, why the F*CK are ANY systems designated as critical infrastructure still connected to the GD internet.
Lease a private line FFS and air-gap the head end systems.

Yes, it's expensive.
Yes, it's not very convenient.
Yes, it's NECESSARY.

GDMIT.

Until we start throwing CEO's in prison for significant amounts of time when their incompetence results in epic level WTF, this sh*t will never get fixed.

Here we go

[Dunbal]

It's Russia again. Just when Russia was finally out of the headlines. Color me shocked. Call me when you have more proof than all the last times it was supposed to be Russia.