TRAC: B6.6: Logging access failures

B6.6 Repository logs all access management failures, and staff review inappropriate
“access denial” incidents.

A repository should have some automated mechanism to note anomalous or unusual denials and use them to identify either security threats or failures in the access management system, such as valid users being denied access. This does not mean looking at every denied access. This requirement does not apply to repositories with unrestricted access.

Evidence: Access logs; capability of system to use automated analysis/monitoring tools and generate problem/error messages; notes of reviews undertaken or action taken as result of reviews.

---

ICPSR maintains access logs using two methods.

One, we maintain a record at the file-level of each successful download.  This captures information such as the identity of the downloaded (including anonymous), a timestamp, the web property via which the download took place, the size of the download, and much more.  As one might expect this information is used to generate aggregate-level reports for member Organizational Representatives (OR), funding agencies, and so on.

Two, we maintain an error log that shows when something went awry.  Summaries of these logs receive a light level of review on a daily basis, but a much more thorough, detailed analysis when someone reports a problem to ICPSR.  A typical - but still infrequent - failure-mode is that someone is trying to download member-only data, and the system denies access because it does not believe that they have logged in from a "member-owned" IPv4 address block within the past few months.  In the few times I've been involved directly in the trouble-shooting, it has been the case that a campus added a new block of IP addresses, but the OR has not notified ICPSR (probably because s/he wasn't aware of the new block either).