Schneier on Security

Clive Robinson • April 17, 2012 6:55 PM

As many have observed both in this post and many previous to it dealing with SCADA etc “remote access” is the issue to be resolved.

One way where only monitoring is required is the simple cutting of TX wires in either a serial or network lead (sugested in quite a few Unix Security books from the last century). Likewise blocking / locking up other “data connectivity” ports such as USB, firewire, etc, etc.

But the reality is managment want remote “full control” irrespective of what the risk is, worse they want to “maximise shareholder value” so it has to be done as cheaply as possible, which usually means always open public access connections.

There are a couple of old “extend the secure network by VPN” ideas but the reality is, these days this is fairly easy to bypass, as has been shown by those who have taken over peoples PC’s with “malware” that actually fakes user input to access bank systems etc.

This sort of attack is possible because people will use “Commodity OS’s”, now I don’t care if you are talking about MS or *nix platforms, the simple fact is there are way to many lines of active code and way to little formal design to say they are even remotly secure, the best yoou can say is attackers have not yet got around to “attacking them in anger” yet.

And due to the complexity of the systems in use it’s not realy possible to spot anything other than the most blatant of unknown exploits in use or known attacks, so stealthy use of zero-day will most times slide past without triping any alarms.

To actually design the hardware and software to do the remote access with a high degree of assurance is actually not that difficult for low complexity systems. But quickly becomes prohibativly more dificult at a slightly greater rate than the complexity increases.

Thus common sense would say “if we have to have remote access, lets strip it’s complexity and thus functionality to a minimum”. But no common sense is not sexy or particularly cheap, all singing all dancing whiz bang systems requiring the latest hardware fully maxed out on memory etc is what gets purchased…

These are the sad realities of life and they are not going to change untill the “business drivers” change managements outlook on life. And all sorts of easily avoidable industrial accidents that happen every day tell you all that management will do is “externalise the risk” by spending on insurance and lawyers, not fixing the problem as that costs more.

And you will find this management attitude / outlook all the way up the supply chain…

For years now I’ve said people need to make “security” into a “quality process”, because most management are happy to spend on quality systems. Not because they understand them or the inherent benifits, but because they see the positive change in the bottom line of the accounts, and it is this and this alone that their “pay and conditions” are based on….

Clive Robinson • April 18, 2012 4:57 AM

@ B,

He said he didn’t have access to that information, that that information was classified and that I really didn’t want to know.

Talk about “out of the mouths of babes and fools”, I’ve heard almost exactly the same from so many bureaucrats in the past I’ve given up counting.

I once actually decided to push on such a “pompous bureaucrat” to see if he would fall over or wobble back up again by asking the overbearing idiot in a Q&A Session the simple question,

If as you say, you don’t have access because it’s classified, then how on earth can you possibly make a valid evaluation sufficient to say I “don’t want to know”?

I’ll let you guess what colour he went… oh and for some strange reason I haven’t received an invertation back to similar events…

The real answer is that the whole thing is a political embarrassment, I posted a link to the “official statment indicating the change of classification policy” back in Nov 2011 ( http://www.schneier.com/blog/archives/2011/11/hack_against_sc.html ) which I picked up from Ralph Langner’s blog.

The part of the DHS with responsability (ICS-CERT) has decided to abdicate it’s responsability to act as a CERT and just collect data and instantly classify the majority of it and only hand out the knowledge to a “select few” which appears not to include the vendors or users of vulnerable products etc…

I cann’t remember the link of the top of my head but the statment was made at the Applied Control Systems (ACS) Conference in Washington, where ICS-CERT Director Marty Edwards, said that the agency was changing the process for handling reported vulnerabilities.

Basicaly anything that was at all serious would be treated not as a reportable vulnerability but as a “systemic design features” which due to the classified nature of such things would only be reported to those with the appropriate clearances…

However things that a vendor could produce a “quick fix patch” for would be reported…

Thus a simple buffer overflow bug would get reported to the vendor who would make a patch then ICS-CERT would report (advertise?) the patch availability and thus make the specific exploitable bug public to the detriment of nearly all because the majority cann’t patch in a timely manner (see other posts above for why). But… something more serious such as a protocol error that effectivly throws all security away would be treated as a “systemic design feature” (which is what my now very old joke about “Bugs are CREeping feATURES” was ment to highlight amongst other design failings).

So you actually get a worse result with the DHS’s ISC-CERT than you would without it…

There are a few (possibly cynical) view points you can take on this,

The first is that this is because the problem would require ICS-CERT to actually do some work as opposed to running around “networking with industry” to get future high paying job options etc.

The second is again because if the actually did some work to resolve the issues then they could not run arround on the hill being “Chiken little” in front of the purse string holders so they could get a bigger slice of the pie.

Thirdly is they are involved in that latest sexy craze of “Cyber-Weapons” and infact their “chosen few” are tasked with developing them for another Stuxnet…

And quite a few other even less flattering views of ISC-CERT and Marty Edwards…

Lest people think I’m being a little harsh on Marty and his DHS ICS-CERT, I’m not the only person with these view points. A quick Google will pull up quite a few including,

http://threatpost.com/en_us/blogs/dhs-thinks-some-scada-problems-are-too-big-call-bug-092611

Clive Robinson • April 19, 2012 5:04 AM

@ Paul,

The “data diode” scheme, whether in software or hardware, may be harder to implement than you think.

A software data diode has complications a hardware data diode does not normaly have in that the software is usually (due to poor design of commodity OS’s) mutable remotely, where as “cut TX lines” tends to require an “on site visit” to change.

With regards,

Unless you’re willing to live with corrupted monitoring data (and never being able to reconfigure your monitoring needs) you will need some kind of flow-control, packet ack, retransmission request and so forth.

Not of necessitie true. Think back to the original concept of “Data Warehousing” and what it was designed to achieve and how.

Look at it this way,

1, ICS
2, ICS control/monitor (PC)
3, Serial/ethernet cut RX lines at 2
4, Data store PC with shared Data Drive.
5, Firewall or software data diode
6, Access control PC with restricted software.

You as an attacker have to first get SU rights on the Access Control PC (6) to get around the software that limits what you can do. Whilst not difficult with a poorly setup system there are plenty of ways you can make this quite secure (have a look at some Open Sorce RAS systems). One little trick is to have the limiting software do application level encryption on the outbound path to the Firewall/Datadiode using an ephemeral key held in rapidly mutating data shadows. Thus not only do you have to get root you also have to get the encryption system and key (not impossible but way beyond that which has sofar been exhibited by APT types).

Having got your root level access etc (on 6) you then have to get root access etc on the fire wall or software Data Diode (5) to disable the application level command sanitation, which again uses ephemeral keys for bot data from 6 but also to 4. Provided appropriate logging is implemented tripwires should have set off alarms long before such access became possible.

But the Firewal/Datadiode then has only “read only access to the warehouse data stored on the shared drive (of 4). And again the comms and requests are locked down.

The warehouse data is actually generated by the ICS control/monitor PC (2) and it “dumps” all data to the data warehouse (4) via the hardware diode (3)

This warehouse data can be protected in a number of ways. The first is some OS’s have fairly solid “Append Only” file systems which can be put in place (on 4). Secondly blocks of data can be “crypto signed” (by 2)and “tracing data” can be added (this is where you add a checksum that has been augmented by an IV from a generator using say AES in CTR mode, the legitimate “remote” user knows what the unencrypted counter value and AES key are unlike the attacker who therefore cannot generate valid checksums).

There are other precautions you can add to improve the likely hood of detecting an attack and dealing with it. Whilst it is not 100% no passive defensive system ever is, what it does do is buy the legitimate system users time to get staff on site etc to either thwart the attack or disconnect the system.

The problem is that although these systems can be (and in very rare cases are) built they generaly are regarded as way to expensive just for “Remote system Monitoring”.

Whilst “Remote system Control” is always going to be risky there are ways it can be reduced. One way is by “scripted actions” you see this with emergancy ssystems such as “Red Shutdown”. The simple opening of a switch, trigers a hardwired response in the ICS. Because it is only a single bit of data (switch open or closed) it can only communicate the desired effect (of doing an emergancy shutdown). Thus in effect the only attack that can be performed is “fails safe” and is of (expensive) nuisance value as are many Denial Of Service attacks.

Most Control System Engineers know how to define action scripts that are either “fail safe” or “kept within limits” or “made safe” by other autonomous control measures. The hard work is developing the “one bit / script” communicatiions and ensuring there are no exploitable “control loop” or “race” conditions or cascade effects in these normalised activity scripts (google “Generator Aurora attack” which is similar to the attack Stuxnet did to the seperator centrifuges).

The very hard work is stopping what are effectivly insider attacks, where a person with direct or indirect access to the ICS (say via removable media) can hide software that opens a “covert channel” such that the “single bit” communications channel which has a time or phase components as a natural consequence of it’s ordinary function is used as a side channel to convey information “morse code like” which is decoded by the added software to carry out non scripted functions.

The two usuall solutions for this are “limit access” to the ICS so that the decoder software cannot be installed and “limit the bandwidth” such that the one bit signal line has a very very low bandwidth. Another technique is “clock the inputs and clock the outputs, with hard fail on error” of an intermediate node in the communications path such that the error recovery system cannot be used as a covert channel. And another technique is “re-modulation” where you add “jitter” to data edges such that pulse width and phase cannot be used as covert channels.