Print

Print


security purposes - tracking is done w/ barcodes entered into the preservation metadata database, and vault system databases do not usually "refresh" with each other, so the 2 are not in sync.

Again, not saying by any stretch this should/ could be considered "best practices" - it's just what typically happens. Refresh cycles (while another topic) are also a problem in this environment, as there is typically less interest in subsequent updates of the data tapes that have not "recouped" their initial cost of creation. I guess I'm trying to convey there is more interest in keeping the 10-20% of backups that have been profitable than a consistent policy that treats all digital preservation files equally.

The hope is that one would not have access to the LTO tape...again, not by any stretch would I consider this the best approach, but there is a level of physical security for unauthorized people to access the tape.

John

On Feb 13, 2012, at 12:34 PM, Karen Cariani wrote:

> This may be a na´ve comment/question, but are you talking about content
> encryption for security purposes or tracking purposes?
> 
> On 2/13/12 12:46 PM, "John Spencer" <[log in to unmask]> wrote:
> 
>> Andrea,
>> 
>> I'll have a go at it - not going to get too far "in the weeds", but maybe
>> this will be of some help. Please see my inserts below in your message.
>> 
>> John
>> 
>> John Spencer
>> [log in to unmask]
>> www.bmschace.com
>> office 615.385.1251/ fax 615.385.0153
>> mobile 615.714.1199
>> 
>> On Feb 13, 2012, at 11:17 AM, Goethals, Andrea wrote:
>> 
>>> I hope you all don't mind my starting this series off. I think this
>>> would work best if we pass the virtual baton around to a different
>>> person after each topic. We can queue up a list of topics on the wiki so
>>> people know what's coming next.
>>> 
>>> The first topic is encryption in preservation storage. I am thinking
>>> about hardware or software or file encryption primarily imposed by the
>>> repository (but whether or not you accept content encrypted by others is
>>> also interesting). I am thinking less about encrypting for transport
>>> (e.g. https). Say what you want about it but I'll pose some questions to
>>> get you thinking about it.
>>> 
>>> 
>>> 
>>> *         Do you have any opinions on it? What are your reasons for
>>> your opinions (gut feelings are OK)?
>> The majority of the preservation data we deliver to our clients is stored
>> on LTO data tapes - without encryption. We do use WORM capability if the
>> client is OK with it. Our reasons are mainly based on the the assumption
>> that we do not have any control over who can access the tape, now or in
>> the future, and staffing changes might stifle the client's ability to
>> recover the preservation files ("now where did the last person put the
>> list of encryption keys?")
>>> 
>>> *         What kinds of problems do you think it might create in the
>>> future?
>> See above. We're most concerned that staffing issues combined with
>> object-based vault management infrastructures in place could lead to
>> problems. Certainly not saying that is the best rationale, but it is
>> based on current reality.
>>> 
>>> *         Do you have any current requirements to do this (laws,
>>> policies)? What are the conditions under which you need to encrypt? Do
>>> you know of any upcoming requirements for you to do this?
>> no
>>> 
>>> *         If you do it what technique(s)/strategies do you use? Do you
>>> isolate encrypted content from non-encrypted content?
>> no answer
>>> 
>>> *         Do you know of any relevant studies/papers, etc. about this
>>> topic?
>> no answer
>>> 
>>> Someone proposed that we keep each topic discussion to around 2 weeks
>>> so let's see if we've said what we want to by March 2. We can always
>>> extend this one since there was no advance notice of the topic.
>>> 
>>> Thanks,
>>> Andrea
>>> 
>>> Andrea Goethals
>>> Digital Preservation and Repository Services Manager
>>> Harvard Library Office for Information Systems
>>> [log in to unmask]
>>> (617) 495-3724
>>> 
>>> 
>>> ############################
>>> 
>>> To unsubscribe from the NDSA-INFRASTRUCTURE list:
>>> write to: 
>>> mailto:[log in to unmask]
>>> or click the following link:
>>> 
>>> http://list.digitalpreservation.gov/SCRIPTS/WA-DIGITAL.EXE?SUBED1=NDSA-IN
>>> FRASTRUCTURE&A=1
>> 
>> 
>> ############################
>> 
>> To unsubscribe from the NDSA-INFRASTRUCTURE list:
>> write to: 
>> mailto:[log in to unmask]
>> or click the following link:
>> http://list.digitalpreservation.gov/SCRIPTS/WA-DIGITAL.EXE?SUBED1=NDSA-INF
>> RASTRUCTURE&A=1
> 
> ############################
> 
> To unsubscribe from the NDSA-INFRASTRUCTURE list:
> write to: mailto:[log in to unmask]
> or click the following link:
> http://list.digitalpreservation.gov/SCRIPTS/WA-DIGITAL.EXE?SUBED1=NDSA-INFRASTRUCTURE&A=1

############################

To unsubscribe from the NDSA-INFRASTRUCTURE list:
write to: mailto:[log in to unmask]
or click the following link:
http://list.digitalpreservation.gov/SCRIPTS/WA-DIGITAL.EXE?SUBED1=NDSA-INFRASTRUCTURE&A=1