Schneier on Security

Clive Robinson • February 24, 2021 10:41 PM

@ fed.up,

notice FE testimony to Congress said put everything in the cloud for safekeeping
then this PaloA video is also very interesting says the opposite

I’m not going to watch it because I’ve been through the variois arguments in the past.

You will find that the answer selected very very rarely has anything what so ever to do with security and almost everything to do with reducing cost. Such is the sad state of afaires within even the likes of the CIA and other IC and LEA entities.

To see this you can plot what is close to two curves on a graph, one for “In House” one for “In Cloud”. The y-axis being frequency of data set access/usage and the x-axis being size of the data set.

The results I’ve ploted tell you a couple of things. Firstly that the decision-making was “cost based”, with just one or two outliers. Secondly the cloud is being used as a dumping ground for rarely processed data.

This “dumping ground” is oddly not to disimilar to how the NSA Blufdale is assumed by many to work. A kind of “write continuously, read rarely” which once used to be done by “tape farm” archiving.

My data set of points is a small fraction of the number of entities and also in a way “self selecting”… So as they say “Your mileage may vary”.

I suspect other peoples information is likewise covered by “Confidentiality” or “Non Disclosure Agreement” thus getting the true picture is not goneng to be easy “for commercial reasons”.

That said my view has always been,

“Is your data an asset or a liability?”

Far to many people are storing way to much data and not only is it building up a longterm cost tsunami, the reality is many will not be able to justify the cost of pulling it out of the cloud onto their own secure servers.

That is any financial gain in keeping the data is at best speculative and in the main very questionable. So the reality for many is their mountains of data are actually very costly to store and use, for little gain, so at best not exactly a worthwhile asset.

Now, when you consider the data in terms of “how can it harm me” few if any appear to consider this aspect or correctly if they do so. So they build massive databases of every scrap of information the comes into, is generated by, or sent out by, the organisation, in effect documenting everything good, indiferent, or bad. But… It is estimated that upto 1 in 5 people will do things they know to be moraly or ethically wrong or clearly illegal for the sake of “quick results” and likewise the majority will do things that can be viewed as questionable when looked at from a certain perspective, and this has been true for centuries, yet we still…

So whilst many attribute to Cardinal Richelieu,

“If you give me six lines written by the hand of the most honest of men, I will find something in them which will hang him.”

It turns out it is probably not true. There is no contemporary documentation. However in a memoir written[1] after the Cardinal had passed it was reported that,

“as I have heard his friends tell, [The Cardinal] was in the habit of saying that with two lines of a man’s handwriting, an accusation could be made against the most innocent, because the business can be interpreted in such a way, that one can easily find what one wishes.”

So just “two lines to make an accusation”…

Thus to some a trove of information that some organisations keep, is without doubt a liability waiting to happen, when an opportunist sees advantage in doing so.

Thus the old quip of “One man’s meat, is another man’s poison” can be seen to apply.

Thus my advise to most people is “If you must keep data, then only keep processed data not raw data, where the processing removes or minimizes liability”.

In most cases the data can not be processed to remove or even reduce liability, and as it’s probably an asset of little worth, destroying it in an appropriate way is probably best…

But it may well be to late for many. Because it’s probably fair to say,

“What goes into the cloud stays in the cloud beyond your control.[2]”

So as my advise for a longer period of time than this century so far, has been “Don’t let your data out of your control”.

You can guess probably guess where my view point is since before the cloud was seen as anything other than one of the SaaS’s or “Stotage as a Service”.

[1] https://en.m.wikipedia.org/wiki/Françoise_Bertaut_de_Motteville

[2] If the data traveled across a network like the Internet, or most Telco networks to get into the cloud. There is a fair chance it’s been “hovered up along the way” so is in other peoples databases very definately beyond your knowledge let alone control.

Clive Robinson • February 25, 2021 3:16 PM

@ fed.up,

I thought logs were unmodifiable, but if they are not to be trusted, then doesn’t this imply that the source code wasn’t just “looked at”?

You’ve hit on one of my favorite points about the difference between “paper records” and “data records”.

Paper records are such that trying to remove or alter a single record whilst not impossible is actually quite difficult, and extreamly difficult if somebody decides to have a closer more forensic look.

Data records however are “made to be altered easily” in some cases where things like records and file block size align it’s way less than trivial and can be “done in place” on the hard drive with a low level driver that just flips bits in a block[1]. Thus all the file system stuff like time stamps does not happen, and the less well known forensic technique that looks at the order blocks on the disk platters are used in, fails as well.

However the idea of “immutable logs” is seductive even though with a few seconds thought you realise that the usefull form of “appened only” is not fundementaly possible, thus needs the OS and more importantly the file system to support it properly which still does not stop the raw write issue. One way to make the raw write issue hard is to use a randomising encrypted file system. Whilst it can be got around the work involved is way beyond most peoples capabilities.

Which is why “net-logs” using UDP packets to a server on a “write only cable” that is also hardened in both software and hardware is the way some people go these days. The old way was to send the logs to the reserved / system console that was actually a genuine output to paper TTY but back in the 70s and 80’s sending a few thousand form/line feeds intersperced with random charecters to get all the paper out of the TTY became a standard but anoying trick, that some sysadmins solved using a filter and tape backup unit that could write just a block at a time.

Yes I know it makes me sound like one of those suspender wearing long white bearded guru tropes that certain cartonists take the Michael out of. But the upshot is unless you do take what looks like extream care to protect logs an attacker will blitz them some how. Which means your other points become valid.

But what is extream care? If you want the modern way to do it, create a network based log-server or net-log system, using a second network that only the servers are attached to via a second NIC. So then use an IDS to silently watch packets over the wire, and if it senses odd behaviour it can pull various plugs to stop an interactive attacker dead in their tracks and raise all sorts of alarms via pagers or SMS. Not perfect but then nothing that gets used for real work ever is.

[1] Back in the early days of *nix, there were certain file system limitations that positively encoraged certain software companies like Oracle to use entire file systems as raw devices. That is the application compleatly bypassed the OS file systems and security. If you knew what you were doing you could get Oracle’s software to do inplace block overwrites with no audit information recorded anywhere… Not sure if you can still do it I’ve steared well clear of Oracle stuff this century. However the down side of developing your own drivers for raw devices, is that when the original reason for doing it is gone, even long gone, there are always “new reasons” used to keep doing it. Often those new reasons are entirely spurious to cover up the real reason of “because costs / profit”.

Clive Robinson • February 26, 2021 7:03 PM

@ fed.up, SpaceLifeForm,

If software logs cannot be trusted and the software manages any regulated data then the software cannot be sold in the USA.

Trusted in what way?

As a general rule of thumb, data on hard drives or removable media,

“Are not worth the paper it’s written on”.

You have to have some way of ensuring,

1, Time accuracy.
2, Order accuracy.
3, Data accuracy.
4, Log isn’t a fake construction
5, Log isn’t a substitution.

Doing all of them is not an easy thing to do without some “interesting mathmatics” and some interesting equipment, and even then not that reliable.

Take “time accuracy” obviously any computers two internal clocks (Tick and Wall) can be fritzed with in some way, the mechanism to do so is built in for administration and syncing reasons. So you go for an extetnal clock of some kind and sync to it. But how do you authenticate it is real? GPS clocks can be fritzed if you know what you are doing, and GPS does not have a reliable authentication mechanism anyway… But what about “replay attacks”?

Similar can be said of the other requirments.

As I point out to people “You are not your cell phone, and your cell phone is not you”. That is there is a very distinct disconnect. I could walk your normal lunch route carrying your phone whilst you were off at some secret rendezvous. I could even send a couple of texts you had told me to send as well.

So if people believe the technology is authenticating, then who was at the secret rendezvous?

Authenticating “data” and the “logs” it appears in is even harder and subject to just as many work arounds.

Whilst there are partially secure ways, most of them are based on mathmatical assumptions or publication of the data either to “the public” or an independent but trusted third party. For an overwhelming number of cases such sharing is not just undesirable but potentially not legal.

Clive Robinson • March 1, 2021 5:26 AM

@ Cassandra,

These days, one can use blockchain techniques to render logs difficult to amend or forge.

Their “proof” relies on a “public ledger” held as “multiple copied” in “multiple locations” by “multiple disassociated entities”.

Which renders their use in general not “practicle” for the hundreds of millions if not billions of log files filling up every day.

But the “public” is a real issue even when using “encrypted data”, it leaks data by the bit bucket load via “traffic analysis” amongst other things, which is technically a “no no” under various pieces of legislation.

And that’s all before we talk of that minor technical problem of using electricity by the oil barrel full just to support the “work factor” of the desired security level against attacks.

The blockchain was and still is an interesting idea, but it got hyped beyond all credability by people on the make and it’s shortcomings fairly quickly appeared.

Clive Robinson • March 1, 2021 8:46 AM

@ Cassandra,

(Perhaps) I was overcomplicating the issue. Periodically closing the log and placing a cryptographic hash of the logfile just closed in the newly opened next log file makes it difficult to amend closed log-files.

Ahh a “different beast” upon which “Merkle trees” ride, and the “blockchain” rides like an evil elf.

But the original idea goes back to the equivalent of a “chain cipher”

The problem with such a system is if I know you only have upto block n[i] I can append as many blocks after as I wish without you being able to say if they are genuine or not.

Also they depend on there being no easy way to find a collision. If I can find a colision then I can change the contents of the block.

But unless the hashes are “publicaly verifiable” on all blocks as they are created then there is no security.

The problem with that is the blocks of data leak meta-data to a public space. Thus size of block or frequency of blocks gives away information about activity, at the very least.

So we still need a private logging system that is secure there are some ways potentially to do this but there is the question not just of QC that can in theory break such a system, but what follows on after QC. Humans are creative little critters just like chipmunks. And just like chipmunks, we have a habit of destroying that which comes before in the name of progress.

I remember a time when “experts” were making bold claims of asymetric crypto… Likewise the irreversibility of “one way functions” that in a practical form give us the basis for CS-hash functions. If we lookback we see the litter of those high pedestals on which the claims were placed smashed and broken…

There is no reason to think that such pedestal smashing is going to stop any time soon…

Clive Robinson • March 1, 2021 9:56 AM

@ Cassandra,

one possible technique is to generate a list of random numbers, which you keep secret. Each time you roll over to a new log file, you record the next random number in your list in the new log file.

What you realy mean is not “random” but “verifiable, but unpredictable to others”

Two such ways exist in most litrature,

1, Running hash,

S = H(H(H(H(seed))))

That is you take a secret seed value and just keep hashing it each time you need a new Secret.

2, Crypto counter,

S = Ek(CNT+n)

You have a counter that is loaded with a secret seed and you Encrypt it with a secret key k. Each time you need a new secret you simoly increment the Counter.

Both of these have issues, and you want to make it more difficult to forge.

One thing suggested in the past is you take the front page headline of a well known newspaper, and you encrypt it under a secret key which is changed daily, you could use either method 1 or 2 to genetate the daily key.

Whilst all methods jave some advantages, they also have disadvantages as well.

However bringing in “verified public daily data” to form the start of a log record has merit, so ideas along those lines are interesting.