1. EZID data security and risks Situation – EZID is “system of record”: data is irreplaceable, authoritative – Forever Challenge – How to protect data against loss & corruption?

2. 1) Database dependency DBMS software is sole means of access – Backups, too Leads to total reliance on: – Having DBMS software – Database is running now – Database is running correctly – Database has been running correctly in the past

3. EZID’s strategy EZID DBMS vendor 1 DBMS vendor 1 DBMS vendor 2 DBMS vendor 2 text dumptext transaction log AND/OR comparison tool fixup tools offsite backup continuous, real-time daily rebuild tools

4. 2) LDAP dependency Problem: identifier owners are identified by ARKs – “ark:/28722/... is owned by ark:/99166/p9...” – LDAP: ark:/99166/p9... = merritt Strategy – LDAP attributes are cached with owner ARKs in EZID’s database – As a result, data is self-describing

5. Risks Availability – DBMS integrity failure – Data loss – DBMS service availability – Security intrusion, DOS – Geo-localized failure – Human failure (error, malicious) –... Interpretability – Dependent information – Knowledge embodied in select staff –... Many others...

6. SPOT model for risk assessment Availability Identity Persistence Renderability Understandability Authenticity Vermaaten, Lavoie, Caplan (2012), “Identifying Threats to Successful Digital Preservation: the SPOT Model for Risk Assessment,” D-Lib Magazine doi:10.1045/september2012-vermaaten

7. SPOT model for risk assessment Renderability – Necessary software is not available – Software can’t be operated or maintained – Necessary environment is unknown – Not possible to verify integrity/accuracy of rendering – Salient characteristics were not preserved

8. Questions Is there a principled way of identifying (and mitigating) risks? – Yes: think NASA space missions – But in this area? What constitutes “enough” mitigation?