[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Freeipa-interest] Re: [Freeipa-devel] Feedback requested on Audit piece of IPA



On  16-Jul-2008, at 8:19 PM, David O'Brien wrote:
Karl Wirth wrote:
Currently we identified that audit system in general can be targeted to:
*Collect data from different sources
*Consolidate data into a combined storage
*Provide effective tools to analyze collected data
*Archive collected data including signing and compression
*Restore data from archives for audit purposes or analyses

We need your feedback on a couple of questions:
1) Should we store structured log data for analysis, original log data,
or both
- To do analysis of the log data, it would be better to structure it and
store it.
- But structured data is not the same as the original log file that it was taken from. Do we need the original log file format for reasons of
compliance or can we throw it away?
- Storing both parsed and unparsed data will have significant storage
impact.

I'm just a beginner but my first reaction here is How is this going to affect a forensics situation? Shouldn't we always have access to untouched/raw data? We can parse it and create whatever structure is required on demand, but if we do it immediately and trash the original data, there's no going back.

That's right. The user should always have the option of keeping the raw data. Often, there are requirements to maintain that data on write- once media, etc. so I don't think they'd take kindly to summarily trashing it. It would be great it we could accommodate the more hard- core folks, or folks who'd like the raw data for third-party log- eating tools. I feel pretty strongly that we should at least have the option of maintaining the original log file format. We can then allow the raw logs to be managed via logrotate rules for retiring, compression, signing, etc. This may mean that they do not get touched at all, which is what some customers want.

2) Should we parse the data into a structure format locally or back on
IPA server?
- Parsing locally and passing both parsed and original log data will
increase network traffic but reduce load on server

The a priori "forensic expert" in me is suspicious of munging data on the client. It seems as though we're solving a problem destructively, since we lose the ability to verify the original data. What happens if there's a bug in the parser? If we're supporting this, it should be optional.

3) What is the scope of what should be included in the audit data in
addition to what we will get from syslog, rsyslog, auditd, etc. Those will give us data like user access to a system, keystrokes, etc. What beyond that is needed. For example, is the following needed: Files user
accessed on a system

Between a keystroke logger, syslog and auditd, that takes care of just about everything, including a log of the files a user accessed on a system.

g

--
Gunnar Hellekson, RHCE
Lead Architect, Red Hat Government





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]