Authentication

Document Sample
Authentication Powered By Docstoc
					Authentication
Best Practices Exchange 2006
Wilmington, North Carolina
Connie Frankenfeld, Digital Programs Librarian
Illinois State Library
Cfrankenfeld@ilsos.net
What is authentication of
documents?

Is the document retrieved from a
  depository unaltered from when it was
  deposited?

Is what gets to a user of a depository the
  same as what was put in?
Risk Assessment
 What   are we guarding against?
   Hacking  into the host computer
   Tampering with a deposited official record

   Intercepting operator control messages

   Intercepting user communication

   Replacing the contents of an official Web
    site
 Canoperations resume after damage
 occurs?
Defense against Hacking
the Host: Operating
System Security
 Up to date security patches
 Anti-virus software
 Physical security of the hardware
 Controlling privileges
 Secure protocols for sensitive connections
 Frequent reviews of logs
 Good backups
Defense against Tampering
with a Deposited Record :
Be Alert

            from administrative areas
 Restricting
 Comparing current copies with the
  original
 Quick response to possible tampering
  Defense against Intercepting
  Control Messages: Passwords
 Use non-trivial passwords
 Change passwords often
 Don’t write passwords where others can
  acquire them
 Don’t share passwords!
 Transmit passwords
   Using only secure protocols, or
   Using special purpose devices
Defense against
Intercepting User
Communication: Low Risk

 Previous actions protect near the
  depository server
 Users are everywhere
 Lack of predictability for which
  document, when and which path
Defense against “Spoofing:
Keep Users Out of Fake
Web Sites
 Register similar DNS names & point to the
  real site.
 Conduct periodic Internet searches for fake
  sites.
 Maintain controls over friendly sites & links
 Publish your URL widely
 Use a URL easy to remember & spell
 Keep DNS names long after your project
  Defense against Site Damage:
  Prepare for Restoration
 Damage  can come from hacking,
  hardware failure or environmental disaster
 Backups
   Frequent

   Offsite

   Secure  computer
   Different manufacture

   Offline

   Several locations
Illinois Systems Security: CEP
 Weekly   patches to UNIX
 Control access via HTTPs or SSH
 Remote backup after each harvest
 Backups tested
 Offline backups on Microsoft
 Offline backups—UNIX to DVD
 Offsite DVD copies
Illinois Systems Security: CEP

 Not public or advertised
 Email reports of all changed files
 Monitor changes by sampling—
  especially ours!
 Unusually large number of file changes
  at one Web site gets attention
Illinois Systems Security: EDI

 Weekly  patches to UNIX
 Control access via HTTPs or SSH
 Daily backup to dissimilar type of
  computer
 Email report of changed files
 Backups as with CEP
Illinois Systems Security:
EDI Privileges
3  GSLIS operators edit metadata &
  inspect deposits for completeness &
  viruses
 ISL Tech Services edit metadata &
  accept or reject for ingest
 Read-only password
 Individual accounts for agency
  depositors to upload files via HTTPs
Illinois Systems Security: EDI

Document Descriptors or “Blue Cards”
 MD5 crypto checksum values for all files
 Checksum created upon initial
  acquisition
 Both XML & HTML
 Minimum of 3 files would be changed &
  reported at nightly backup to alter files
“Blue Card”
Illinois Systems Security:
EDI Public Access
http://iledi.org

 Read only
 No passwords
 Via HTTP
  Thanks to
                Larry Jackson
Graduate School of Library and Information Science
     University of Illinois Urbana/Champaign
                lsjackso@uiuc.edu