Tuesday, September 4, 2012

Threat Models For Archives

I spent some time this week looking at a proposed technical architecture for a digital archive. It seems always to be the case that these proposals lack any model of the threats against which the data has to be protected. This one was no exception.

It is a mystery how people can set out to design a system without specifying what the system is supposed to do. In 2005 a panel of the National Science Board reported on the efforts of the US National Archives and Records Administration to design an Electronic Records Archive (ERA):
"It is essential that ERA design proposals be analyzed against a threat model in order to gain an understanding of the degree to which alternative designs are vulnerable to attack."
That same year the LOCKSS team published the threat model the LOCKSS design uses. Despite these examples from 7 years ago, it seems that everyone thinks that the threats to stored data are so well understood and agreed upon that there is no need to specify them, they can simply be assumed.

From 4 years ago, here is an example of the threats paper archives must guard against. The historian Martin Allen published a book making sensational allegations about the Duke of Windsor's support for the Nazis. It was based on "previously unseen documents" from the British National Archives, but:
"... an investigation by the National Archives into how forged documents came to be planted in their files ... uncovered the full extent of deception. Officials discovered 29 faked documents, planted in 12 separate files at some point between 2000 and 2005, which were used to underpin Allen's allegations."
Is this a threat your digital preservation system could prevent or even detect? Could your system detect it if the perpetrator had administrative privileges? The proposed system I was looking at would definitely have failed the second test, because insider abuse was not part of their assumed threat model. If the designers had taken the time to write down their threat model, perhaps using our paper as a template, they would have either caught their omission, or explained how it came to be that their system administrators were guaranteed to be both infallible and incorruptible.

2 comments:

JStrass said...

The humble checksum could be powerful proof that a document was tampered with or replaced, as long as the list of checksums were secure.

David. said...

Checksums are made of the same bits as the content. They are just smaller. So if you have a technique that guarantees the checksum will survive unchanged, you can apply it to the content and you don't need the checksum.

In practice you can't guarantee survival of the checksum. It can help, but it isn't a panacea.