Schneier on Security

Clive Robinson • December 26, 2019 12:29 PM

@ Think,

For those in business, in aggregate — patching is very important.

Patching is just one of several options.

At a high level you have,

1, Cross your fingers and hope.
2, If possible work around.
3, If possible patch.
4, If possible mitigate.

The first is the position of the eternal optimist, forever doomed despite the occasional respite. They indulge in “poor odds gambling” and call it “risk managment” or some other nonsense. Imagine if you will a roulet wheel where all but one slot is green for a house win, and that one slot only pays evens less tax would you play on it?. That would still be more favourable odds than most get with their Internet connected systems with modern commercial consumer OS’s and applications. The only saving grace is that it is such a target rich environment your chance of being hit is realy quite small compared to everybody else, and there are realy not that many attackers… Thus maybe options two or three might happen before your door gets rattled.

But options two and three are by no means certain to happen so waiting for them is almost as foolish.

You have to consider that whilst a few people might be able to come up with an effective work around… outside of the software developers the number capable of producing a patch let alone an effective one is quite small at best. In some cases not even the software developers can come up with an effective patch in a realistic time frame once the vulnerability is known to a large enough number of people.

The simple fact is that for various reasons –that get lumped under the term marketplace– we favour mainly pointless complexity over even a modicum of stability let alone security. Thus by now most should realise this effects both above and below the CPU ISA point in the computing stack and all points inbetween. But… whilst software developers can only realy work above the ISA usually by quite a margin attackers can be below what many consider the physical layer attacking upwards and no highlevel software running on the same CPU can protect against such attacks. As @Thoth pointed out a couple of days ago even Intel’s much hyped hardware security enclaves are nothing of the sort and can be attacked via the likes of RowHammer and similar low level physical layer attacks.

Further it should be obvious that the first three options, like a man clinging on to a cliff edge by his fingernails, is such a tenuous position and not realy tenable. With it being just a question of “when” rather than “if” the descent will begin, and how bad the landing.

This leaves us with the fourth option, of which the most obvious solution is,

Don’t use the comercial crap-ware.

By which I actually mean don’t use the comercial consumer OS’s and Applications that are so bloated with unwanted, unneeded, poorly tested functionality that the complexity is at a point where serious vulnerabilities are guaranteed.

But if you can not avoid the use of such commercial crap-ware then you need to consider other mitigations, in fact you should consider them no matter what you use.

For example for a vulnerability to be exploited an attacker has to gain access to a vulnerable system. If the systems in use are not in anyway connected to external networks then you’ve reduced your attack surface to “insider attacks” only. Whilst these do happen, they are no where near as frequent as attacks from external networks. But more importantly they are more tracable to actual individuals.

Which brings up the question of why so many “work computers” are connected directly or indirectly to external networks or communications? I’ve heard all the arguments multiple times and they all boil down to “arm waving” in by far the majority of cases. And even when there are legitimate reasons to connect, almost invariably they are done the wrong way on somebodies whim.

We have seen this repeatedly with security companies who realy realy should know better after all RSA and it’s security token issue was quite public some years ago. I’ve lost count of the number of CA’s that have lost control of key signing over this decade alone. Oh and who remembers that Italian company that developed malicious attacks that they sold to all sorts of people including repressive regimes? Yup “Hacking Team” is what they called themselves, and “got hacked” was their fate, due to stupidity and hubris. All of which they could have avoided if they had taken just a little more care… You’ld have thought they might have noticed an estimated 400GByte of data putting a big load on their outgoing pipe, but apparently not.

In theory Hacking Team were “experts” and had vast domain knowledge, so should have known not just the risks but how to mitigate them. But they had connections to public communications networks, that they dod not deal with correctly, and they got hacked… Perhaps more interestingly it looks like those who did it are not going to get prosecuted as the Italian prosecuters for various issues –not least Hacking Team’s owner’s dishonesty– have closed the investigation.

Ask yourself a serious question of,

If it can and frequently does happen to those seen as “Domain Experts” what can I do?

The answer is first off question why you have external communications. Then how you can reduce or eliminate external communications from internal systems that don’t need them. But also where you identify a supposed need realy investigate it, the chances are you will find either it’s not needed or it can be effectively mitigated.

Especially when you consider any effective mitigation against external threat entities should also work against insider threat entities as well.

In the past I’ve explained how I carry out mitigations in this area and why. The same can be done and has been done –by financial organisations amongst others– for some time now, and it’s not some nonsense “Best Practice” derived from questionnaires etc.

The real question for people to consider though is,

Am I a gambler?

Because not mitigating crap-ware you know is full of unpublished but potentially known vulnerabilities is not “risk managment” it’s the stupidity of someone who is addicted to poor odds gambling, who may well have “lost the farm” to APT and not yet found out.

Clive Robinson • December 26, 2019 5:31 PM

@ JohnKnowsNothing, ALL,

Even the most resourceful Google-Fu cannot uncover all the permutations where things are going to go pear-shaped.

A friend has a compleate listing of Unix for a PDP 11/70 not just on paper but in text file form as well.

Over the past years they have ported it to a number of platforms from Motorola 68K upwards. In more modern times to even single chip “System On a Chip” (SOC) microcontroler. During this time they have also gone through many bug and vulnarability reports updating the code. It’s an interesting hobby, but also the system appears quite secure and lacks one heck of a load of bloat.

If you don’t mind “working the command line” and using K&R style C, BASIC or FIG Forth then it’s a fun thing to work with.

But importantly is that lack of bloat and the fact you only have what you need to talk across serial lines (networking via SLIP or PPP is there if required). Makes it potentially way more secure than say a Raspberry Pi Zero with a bloated GNU / Linux.

Parallel computing whilst on the surface looking increadibly complex can be designed so it is not, and the code kept just about as simple as possible, has the potential to actually be a lot more secure than most current systems. But as each year passes high complexity threaded code with very ill definded interfaces appears to be the rule…

I guess the question is “When will we learn, and will it be to late or not?”.

Clive Robinson • December 27, 2019 4:31 AM

@ SpaceLifeForm,

Stick to plaintext for comms.

As I’ve mentioned in the past, it’s my prefered method of crossing “security gaps” using another system to check for various issues.

However at the end of the day “source code” for interpreters is “plaintext” so you also have to use a subset of even text based applications, that you know don’t have interpreters or anything sufficiently close to be one inside them. This can be awkward as many “grep” like tools do have command parsing inside them.

Old unix source code can be your friend if you have the ability to “take out the clever tricks”. Mostly they were not needed back then, and with modern resources being “t’pence a bucket full” they certainly are not needed today. Also it enables you to strip out “the kitchen sink” features you are never likely to use as well.

At the end of the day, though I hate to say it because usong your own private unpublished code is a form of “security by obscurity” it does help stop people getting a toe-hold and can make any such attempts actually “stand out”, thus alert you to something odd.

The big problem is of course “other people” more or less insist on “rich text” in it’s many forms either insisting on sending it to you or insisting on it from you “because of their business flow” etc. There are ways around this but sometimes spending half an hour to write a couple of pages of plain text, then another half hour “hand crafting” it up into another format can and is a right royal pain in the posterior.

However at the end of the day you have to do the evaluation of “what price for security”. From my perspective the first question is what price would there be for them performing a physical penetration to plant surveillance equipment etc. You then use that as your working baseline. Making that way more expensive for them can be as simple as putting door alarm sensors in all the internal doors and keeping all the doors closed, the pluss side is doing that helps reduce your heating/cooling bills as well 😉 wiring it all up to a cheap single board computer that can also work a mobile phone as an alert system helps as well. Supprisingly there are so many little security projects people have developed for the likes of the Raspberry Pi and other low cost SBC’s that you can almost “plug and play” your own security system together that even a decade or so ago would have been thought of as “very high tech”. Again doing it your own way makes an attakers life very much more difficult.

You can also take a lesson from the accient orientals who used to creat physical alarms such as floors that squeaked. If you make certain of your floor boards squeak or move in certain ways and put a sensor some distance away, the chances of an intruder finding and disabling them without setting them off is very small.

Whilst cheap safes like those you have in hotels are fairly easy to open, they can also be alarmed from the inside and the wires taken out through one of the “bolt down” holes they often have, using three bolts instead of four probably won’t be detected by an intruder.

The point being you want to detect them not stop them. You are at the end of the day protecting information not physical objects, there are ways that information can be protected at rest that they can do little or nothing about. What you don’t want to do is let them get at data when it’s unprotected because you are using it, and they can only do that if they catch you unaware. Just knowing someone is taking interest in you is often sufficient for the cautiously minded to avoid problems.