Plot twist: the second foundation is the NSA.

I'm sorry, let's see if I can do better.

By air gap I mean that I think that DCS systems should by default be fully disconnected from the Internet, e.g. instrument engineer workstations should be on a different physical network and they have to have two computers to do their job - one to check email and do MSOffice stuff, and another that they develop the DCS logic on. This is very inconvenient for both the instrument engineers and the normal manufacturing engineers (who just need read-only access), leading to a loss of productivity.

Many systems are not air-gapped. Instead the DCS network is put on a separate VLAN with a firewall and either Windows Terminal Servers or an X11 client at the border. This is the alternative that I am arguing should be avoided in the future.

However, I have only seen an air-gapped network once, and that was mostly due to the age of the system: it was installed in the 1980's and barely even had TCP/IP between the operator consoles and the DCS servers. Last I heard it was in the process of upgrading to a more modern system and it would be connected at the border like the other plants in the company.

That could be true. SCADA systems -- where a single operator screen needs to control many stations miles apart from each other -- are probably economically infeasible to operate on a wholly independent set of physical wires. But even then I would push for a network design that forces the instrument engineers to use a different physical machine than the one they check email on.

In truth I am in the minority even in the chemical industry. People want the convenience of checking the true operator consoles from their desk, IT departments want the convenience of VLANs over separate physical wires, and (yay) there haven't been any significant events attributable to external network attacks to trigger action. I suspect that if we had another Texas City caused by (insert hostile hacker group here), it would either be treated like a typical industrial accident (meaning beef up the SIS), or an overt act of warfare (meaning go invade a country).

It's really tough to get ChemE's to believe that an intelligently lying DCS can even exist much less be capable of causing an accident that the SIS won't stop. OTOH it's tough to get buy-in from IT departments to keep these networks separate when all their ChemE clients are demanding convenience over security.

I'm a chemical engineer with a bit of experience in designing control systems. Based on the systems I've seen in the field, I too would argue that air-gap-by-default is better in most circumstances.

Most plants have both vastly oversized equipment (especially heat exchangers and pumps) and catastrophic failure modes that can easily be reached by all those pieces operating within limits - it's the "swiss cheese" model of failure. Add a "pretty" control system like DeltaV or ABB that a) usually runs on Windows, and b) can almost always be modified if you have a engineering-acceess password, and I can see a path to a disaster. It would go like this:

1. The attacker gets access to the business-side Windows network.
2. They get access to a privileged account on that network.
3. They sift through the AD and find the instrument engineer accounts and personal workstations, and then install keyboard monitors on those workstations. Within a few days they have both the engineering passwords and access to the DCS.
4. They examine the DCS looking for weaknesses in the physical process itself: valves with lots more room on them, areas with lots of interlocks, exothermic reactor vessels, distillation columns that could rapidly overfill, etc.
5. Somewhere they will find a spot that has DCS interlocks but no corresponding SIS interlocks, and now it's game over. They could re-span one level indicator and disable one interlock and it would be Texas City 2005 all over again. Or they could make one temperature indicator lie and it would be Morganton NC 2006. If they wanted to get really evil they could just close a valve on a flare line while showing an open valve on the DCS screen.

A lot of this stuff can't be limited by mechanical safeties or more smarts at the PLC level. The only difference between a mission-critical exothermic reaction vessel and a bomb is how much stuff is put is into it before adding catalyst. And Iran has enough chemical engineers who could see this stuff if they had sufficient motivation.

The only thing we really have to protect the process is an independent SIL-rated SIS with its own indicators and solenoids, which is from this standpoint just an air-gapped DCS that can't be messed with.

You were doing really great until the end there. "But nobody knows how to use a terminal, and you can't do it on a tablet!" is actually a real business concern that needs a plan to address it, even if that plan is "we will never outsource data entry or use anything other than desktop/laptop for it".

Point-of-sale systems are moving to tablets/phones right now - that's how the food trucks here in Boston are running their businesses. I'm sure there will be businesses moving data entry to it also. Perhaps the better response would be "The plan is to keep data entry on the existing systems, but move the data entry portions into the process itself so that we don't need humans here at all. When the data entry becomes trivial then we will look to either combine it with another role or push it to an outside firm."

Just so you know, both parties aggressively pursue the expanded police state. If anything, the Dems push the boundaries and the GOP solidifies the gains.

The network effect comes back to haunt them. It seems that the only thing people really want from Microsoft is Win32/64 compatibility afterall.

The two problems I'm seeing (Dickey may see more) are:

1) The sequences use a non-standard opening. This means for terminal writers that we need several new states in the state machine just for this terminal. We're unlikely to do this, especially when OSC/DCS/etc. already exist for this precise purpose, and this is indeed how xterm does it.

2) The sequence is (sometimes) terminated by a control character in the C0 set. Control characters are normally processed separately from the rest of the state machine. Also, NUL specifically is discarded as per VT100 spec.

Right now between these two things the sequences will leave artifacts on the screen for any terminal not modified to fully support them. Switch to OSC like xterm and you will immediately get a clean display from any decent terminal,

They should have used the future-proofed OSC, DCS, SOS, PM, or APC prefixes instead of this new ESC{ sequence. And then they terminate the sequence with a control character (NUL)! This is worse than "ANSI music".

Terminology authors, if you are reading this, could you PLEASE talk to Ted Dickey (xterm and ncurses maintainer) about the RIGHT way to do this? Otherwise you're going to find yourselves with your own version of brokenLinuxOSC.

So what stops the police from becoming the goon squad?

I like the raw console too, so much so that I wrote an ncurses-based terminal emulator that for several years only looked right on the true raw console. Then Debian's console packages came along and fucked up the CP437 glyphs and I learned that it is a real pain to get the true raw console anymore in a modern distro, even when using UTF-8. My emulator is still ncurses-based but now looks best under xterm with the bolkhov VGA or Terminus fonts and explicitly mapping the colors back to the VGA colors (i.e. yellow = bright brown).

I wouldn't mind if the console could play nice with stuff like Unicode, keyboards, and multi-seat by default. Plus we could get things like a long *persistent* scrollback and much better VT100 support: who wouldn't like to see double-width/double-height lines? And we could retire that godawful palette sequence (CSI ]) that breaks normal OSC behavior.

I suspect the right approach will be three consoles: serial for embedded, KMSCON for normal laptops/desktops, and VT for servers. My favorite Linux feature: we can usually have our cake and eat it too.

Indeed. I work for one of the major "silicon crushers". Converting sand to metallurgical grade silicon (97%+) takes an arc furnace, lots of electrical power required. Then comes grinding and classifying it and most processes deliberately spray the dust with water to put an oxide layer on the particles to prevent a dust explosion.

If one has to migrate off Win32/64 to something new, why not just port to Qt/GTK and get all the platforms for the same development price?

Microsoft CAN'T re-invent Win32 without losing their business.

I'm genuinely surprised the TCP window algorithm would throw away packet 6-20 in this case. Kermit sliding windows wouldn't, they would NAK 5, ACK the rest, and then the sender would re-send 5 and pick back up again at 20 once it got the ACK to 5.

And that was described in detail in The Kermit Protocol back in 1986.

A-fuckin-men. Seriously an HP/Asus/Acer/Dell that shipped with a decent Linux distro - ANY distro - would be awesome. Get good 3D graphics drivers, wifi, sound, etc., pay Microsoft $0, maybe even allow some limited crapware if they needed those subsidies too. Invest more in Wine for Windows app support.

Alternatively, fund ReactOS to get to API parity with Server 2003 and sell direct to corporates.

At this point any hardware company that isn't looking at a non-Microsoft offering is just asking for a knife in the back.

I wonder if this kind of thing pops up anywhere else? It would be great if there were some kind of standard way to distinguish between "value A/B/C/D" vs "nothing was entered here". Hmmm....

Nah. Can't possibly be, otherwise Oracle would know the difference between "" and NULL.