Wednesday, July 09, 2008
Taming the Documentum Audit Trail
Laurence Hart wrote a blog entry entitled: Taming the Documentum Audit Trail that I wanted to comment on from the eyes of IT security professionals...
There are several characteristics of good audit trails that Laurence didn't discuss. First and foremost, it is a good security principle to separate log data from the system. In the example that Laurence outlines where it is in the same database, causes many problems. Consider the scenario where I want to access the latest medical information for Craig Randall and even update it for amusement purposes. If I can get access to the underlying database which I probably have as a Documentum adminstrator, I can cover my own tracks.
The proper way to think about audit trails was invented about thirty years ago and depends on a trusty protocol known as Syslog. The syslog daemon allows for logs to be stored locally on the same server, remoted to different servers which makes the job of tampering a lot harder and even can be remoted to solutions such as LogLogic where my behavior of tampering can be correlated with other log activities from firewalls, to switches, to logging into Active Directory and so on.
Logs should also have some notion of being tamper-evident. Shouldn't Documentum have the ability to sign each entry natively? What was curious about the Documentum model is the user_id field which feels incomplete at many levels? For example, if I access a Documentum application via fugly DFS, shouldn't I know the identity of the web service as well as the user calling it?
Bex Huff has stated that ECM should store content and not users. If users were external to Documentum, how would this user_id field be overloaded? A user_id would look different in a federated scenario, when I use information cards or openID or even binding against Active Directory...
GEF.jpg)
| | View blog reactionsThere are several characteristics of good audit trails that Laurence didn't discuss. First and foremost, it is a good security principle to separate log data from the system. In the example that Laurence outlines where it is in the same database, causes many problems. Consider the scenario where I want to access the latest medical information for Craig Randall and even update it for amusement purposes. If I can get access to the underlying database which I probably have as a Documentum adminstrator, I can cover my own tracks.
The proper way to think about audit trails was invented about thirty years ago and depends on a trusty protocol known as Syslog. The syslog daemon allows for logs to be stored locally on the same server, remoted to different servers which makes the job of tampering a lot harder and even can be remoted to solutions such as LogLogic where my behavior of tampering can be correlated with other log activities from firewalls, to switches, to logging into Active Directory and so on.
Logs should also have some notion of being tamper-evident. Shouldn't Documentum have the ability to sign each entry natively? What was curious about the Documentum model is the user_id field which feels incomplete at many levels? For example, if I access a Documentum application via fugly DFS, shouldn't I know the identity of the web service as well as the user calling it?
Bex Huff has stated that ECM should store content and not users. If users were external to Documentum, how would this user_id field be overloaded? A user_id would look different in a federated scenario, when I use information cards or openID or even binding against Active Directory...
