Schneier on Security

Clive Robinson • June 4, 2019 11:33 PM

@ Bruce, All,

The point we realy all should dwell on is,

We spend more money on cyber defense than we do on the actual losses.

There are a couple of reasons for this.

The first is the old “Defence Appropriations dilemma” of,

You only know you spent to little or unwisely because you got attacked

That is you actually never know when you are spending to much or wisely. Because after a point you have spent sufficient to deter any attackers that might give you the once over, but you don’t know that so you carry on spending untill you think you have spent enough.

Which brings us to the second reason. Because you have no way to measure the effectiveness of your spend other than by being attacked you become prey to what is in effect another form of fraud, which is the more refined form of,

Anti-Virus / Tech-sup scam.

That is much “defense spending” is made unwisely on what is in effect “Snake Oil with a dashboard and faux metric report generator.”.

They product vendors get away with it for a couple of reasons,

1, We have no measurands of use.
2, We are still a target rich environment.

I’ve mentioned these both in the past and we still don’t do anything about the important one which is “no measurands”… Because without them we fall back on the notion of “Best Practice” which is basically,

Last year our industry survey showed the twenty least attacked organisations did the following ten things in common.

So those ten things are this years best practice recommendation…

Am I the only person who sees the problems with this Best Practice idea?

Well there’s the obvious “the survey is self reporting” thus has cognative bias built in right from the get go.

But also you can be successfully attacked and not know it. That was the point about Advanced Persistent Threat (APT) attacks, they get in but you don’t see any sign that they are there. Or as a friend once chearfully put it “Even the fastest bullet is not instantly fatal, it always takes time to die even if you don’t know it” in response to a conversation about “talking heads” lifted from the basket of the Guillotine.

But there is also “probability” to consider. That is ICT is a target rich environment, so much so that comparatively very few ICT systems are actually attacked. Which means even more or less compleatly useless security measures will “appear to stop” attacks. That is those processing the survey can work on “magic umbrella” thinking. It works like this, I live in a near desert where it hardly rains, so I have this umbrella just in case it does rain. But I frequently forget to take it with me, but I’ve never seen it rain when I’ve had it with me so it must be magical… In other words it’s “observed correlation” not “proved causation”. The lower the probability of rain and the lower the probability you take the umbrella then the way way lower is the probability that it will rain on the rare day you do remember to take the umbrella… So the fact you’ve not seen any sign of successful attack in no way means the security measures you put in place actually stop attacks. So “taking two weeks vacation in the Bahamas” could be the number one “best practice” measure if you ask about holidays in the survey.

I could go on but underneath all of this is the lack of measurands. Without which you can not apply the scientific method…

Clive Robinson • June 5, 2019 6:50 AM

@ Frank Wilhoit,

Focussing on “security” risks in isolation from all of the other classifications of risk (none of which are “manageable” in any conventional understanding of the word) is simply a failure of situational awareness.

I’ve argued for a long time that security in the design of ICT is the same or part of a “Quality” process.

Also arguably in software the complexity is high and the development cycles ridiculously short.

People have talked in awe at the several milion physical parts in a modern jet liner, but software that is used day after day many times that in real instructions usually does not produce any such awe, more usually disdain for it’s usability.

There is I guess a degree of “out of sight out of mind” not just in users but developers and their managment and “first to market” in rapid “release then patch” cycles does not help issues. Because each release must contain new “features” thus new “errors” with some later “fixes” introducing further errors and so on.

When I was developing hardware and software for embeded systems which I guess you could say were the forerunners of todays IoT and mobile technology there was “no patch tuseday” and you had to be right in both hardware and software before it went out the door. The result was both hardware and software had similar development and test times.

In general I would have a prototype design for both hardware and software up within a couple of weeks and “breadbording” would have started usually within that time. That is a Chip development system would be on the bench and a skeleton circuit on “Perfboard” or “stripboard” up and running with the “user interface” on the left and “hardware interface” on the right of the Microcontroler Chip perfboard.

A second chip development system would be up and running within a week of that for “hardware development” to use. This would have a microcontroller development PCB board with user interface hardware built on and “fitted” for the case design and would usually be “finalised” in terms of the hardware interface. Thus as other custom parts arrived they would be fitted and tested electrically, test software loaded and their software interface checked and that would then get turned over to the hardware people for electronic and functional testing.

At this stage there was usually an up and running BIOS in software with the bottom side handlers and fast interupt handlers and a rapidly developing OS on top giving the top side and slow handlers for buffering etc to give the application software development a standardised abstract interface.

Then “software development proper” could get going whilst the hardware people went through various stages. A provisional software release for regulatory testing and compliance was produced and for the customers engineers and marketing people to play with. This would be “fleshed out” and “intensively tested” whilst compliance testing etc was going on. By which time things like custom parts (LCD displays, keyboard pads cases etc) would have arived thus enabling a half dozen or so units to be constructed and sent out for “user evaluation” testing and “feature tuning” and the scheaduling for “line production” started such that on the production sign off signiture from the customer custom part manufacturing would start and the finalised software sent off to the microcontroler manufacturer for “mask production” and chip production. At which point the person who had drawn the short straw would end up on a long haul to one of the factories in various F.E. countries to “get the line up and unsnaged”. On some occasions their return “hand luggage” would fill one of those aircraft hold containers as they flew back with the first units of the line so the customer could do “product launch”.

The point being the software development time was actually very short and you could type up the various “stub prototypes” in a day or two then they would undergo a week or two of mangaling whilst the software spec developed from the customer “wish list” and “this might be nice” upgrades. The flesh would be hung on those bones fairly quickly as almost independent modules, then it was comparatively a very long test&fix cycle to grind every bug that could be found into the dirt. Typically test/fix was 6-15 times the development time of first candidate software. That might sound strange to some but unlike PC Apps that have maybe five to ten hours of uptime with a user, or server apps with 4,000hour uptimes we knew some of our stuff would routienly have uptimes exceading the overall hardware MTTF of 150,000 hours. As I’ve mentioned befor I’m still supporting some ICS stuff from the late 80’s / early 90’s,that’s got atleast 220,000hours uptime on the clock.

That said there were some funny and fun times, one was when one airline for promotion purposes did a special on First Class flights having an unlimited baggage alowance. Thus some engineers flew “First Class” for a while because it actually cost less… Usually you got “economy” and a big baggage bill. Economy on some Assian Airlines of the time was the modern equivalent of the “Little ease” tourture to somebody my size. But even that could have it’s funny side. Back then I used to have “travel battle dress” that I’d developed whilst working in the off shore oil industry, heavy steel toecap dock/rigger boots or equivalent motorcycle boots, dark brown denim jeans and a long warm padded black leather coat which you could sleep in and almot use as a tent, which did not crease and stayed dry even in a monsoon torrent. Whilst not quite looking like a Hell’s Angel in a Giant’s Revenge Movie, I could have passed as an extra for a Startrek Klingon size wise. On one occasion due to a codsup I got pulled in boarding to sort out an issue because of a message that the cargo handlers passed up about insufficient hold space… Which ment I ended up having to run full tilt down the embarcation ramp, thus there was this massive boom boom as of doom as my motorcycle boots crashed into the floor and my 6ft 6 tall 250 pound broad bone and muscle rugby playing frame with my long leather coat tails streaming behind me sprinted at close to twelve miles an hour into view arms and legs pumping like some infernal machine of gothic nightmares. I must have scared the living soul out of the petit Japanese boarding hostess because all she could do was just with a fixed rictus of frozen greating and wide open staring unblinking and unmoving eyes point me into First Class rather than economy, so best free upgrade I ever got on an airplane 😉 Oh and she did warm to me after I appologised for having been late and inadvertantly scaring her half to death. I think she quickly realised I was more of a teddybear than a grizzly.