All posts in the topic Audit Trails (Short link)
Summary
- There are 6 posts — by 2 authors — in this topic.
- Latest post made by Michael JasonSmith at Dec 24 06:12 UTC
| From | File | Date |
|---|---|---|
| Michael JasonSmith | audit-log-spec.xml | 2007 Sep 28 04:10 UTC |
| Michael JasonSmith | Screenshot-Activity log for Mr Lem: Example Site.p | Oct 30 02:03 UTC |
As this topic has arisen in another (closed) group, so I thought I would open the topic of audit trails here. An audit trail is what it sounds like: a record of all the changes to a system. It is used during an audit: security audit, activity audit, or simply activity reporting. Besides being a good idea, audit trails are also required by many government standards http://www.archives.govt.nz/continuum/documents/publications/s5/s5-controls.php#2 (while I am using an New Zealand document as an example, it is based on international standards). In GroupServer, I am intending audit trails to be used as the core of many things. Keeping a record of what has changed with a user's profile should also allow the user to undo changes. Keeping a record of the changing membership of a group would allow us to record how many people received messages in a particular month. Keeping a record of who accessed what can be used during a security investigation. Knowing who changed what will allow better support of users who have problems with their accounts. The way I am intending to implement audit trails is to implement the command pattern http://www.dofactory.com/Patterns/PatternCommand.aspx (I preferred the above to the Wikipedia page). Effectively, the audit-table of the GroupServer relational database will contain little snippets of XML that can be used to undo, or redo, particular actions. It is not necessary to implement audit trails in the way I propose, but the command-pattern will give us the most utility from the auditing system. As I said previously http://groupserver.org/r/post/7i4zzvM94cHbk42y6xeDUw modifying a post, or another user's profile (by a group administrator, for example) relies on the audit-trail system before it can be implemented ethically (or legally, in most of the developed world). Neither editing task needs one, technically; I promise to actively hinder all efforts to implement post-editing, or profile-editing, by an administrators without audit trails. *The* *user* *must* *know* who altered his or her profile or posts. Any other situation is reprehensible. The biggest problem for the audit-trail system is that it is not small. Large does not even cover it: every part of GroupServer will eventually be hooked into the auditing system. Extensive interfaces are needed to give people access to the audit logs associated with themselves, and the parts of GroupServer that they manage. The size of the task daunts me, but I know that many important user-tasks rely on audit trails being present…
Since Dan referred to something like an audit trail in: http://groupserver.org/r/post/1I7HqKutBUZJ0JwWMLkHr9 I thought it might be a good idea to re-visit this, since it seems likely (and useful) for email verification to be the first use of this. We can utilise the idea that audit logs are pretty much entirely event driven, and hook into the Z2/Z3 event subscription framework (so that when an event happens, it gets logged if we've written a handler for it). Having had a quick discussion of this with Mike, it seems that we have a number of fields that have fairly strong commonality for different events we might want to log:
The XML specification (below) should not be necessary. Yet ☺
The following file was added to this topic:
I have committed, and have running, the start of the Audit Trails system. The two screenshots below show a prototype view of the audit-trail log. On Monday I will make the new system live on GroupServer.Org (and the rest of OnlineGroups.Net). The audit trails system records what the users do when using GroupServer. The first screen shot below shows a log for a user (me) on my test system. As I edited my profile and changed my password GroupServer recorded the events in a log. Viewing the log allows me to see the changes that have been made to my profile. (Because it is a test, some of the entries are out of order.) A successor to this page will be the fix for Ticket 257 https://svn.iopen.net/projects/groupserver/ticket/257 Once we record the changes made to the profiles we will be able to relax the rules about who can edit profiles https://svn.iopen.net/projects/groupserver/ticket/258 The second screenshot below shows what happens when a user (me) alters the profile of another user (Mr Lem). In addition to stating what the changes were, the system also states who made the change. This can be used to identify nefarious activity, and (hopefully) allows the change to be undone. In the future we can show logs for groups, so the changes made to a group over time can be seen. The database for the audit-trails system records all the fields that Richard suggested in his earlier post [beneath the disclosure] http://groupserver.org/r/post/oLCBka5103TWEYZ8WrGCr A little voodoo is used to marshal the data from the database back into classes that can render each line item. These classes are needed because they know the specific meaning of some of the generic data that is stored in the database (specifically the "code", "instance datum" and "supplementary datum" fields). Most of the future work will be in writing the little classes that render each event type. Most of the points where we want to audit events are already marked by calls to the existing Python logger.
The following files were added to this topic:
Audit-trails are working on GroupServer.org, and the rest of
OnlineGroups.Net, with a few caveats.
* The first is very little is that logged to the audit-trail:
setting passwords, and changing profiles is it at the moment.
* Second, I have not linked to the profile, so you have to go to
the log manually. It is "log.html", and is located under your
profile.
* Finally, I cannot break the log down on a site-by-site basis
(yet).
We will be adding different modules to the audit-trail system as
time goes by, converting some of the existing logging functions.
It is nice to know we are on the right track with our audit trails system http://www.schneier.com/blog/archives/2008/12/audit.html