> > > What's the story? Is database logging hot or not? :-) > > > > Hot, it is not. Necessary, yes for companies with compliance drivers. > > The reason it is not hot is because it is solely driven by compliance > and > > not by any other company requirements. > > Ouch, how about security? I guess we are dealing with some case of > mental inertia here. Otherwise, why is it not obvious that for > incident response due to system hacking you look at system logs, and > for incident response due to database or web application hacking you > look ... where DO you look if you don't have the database logs? Application transaction, OS, and DB layer monitoring are just too low on the priority list for most security budgets. Benefit is low, complexity is high, lack of vendor tools (how many SIM's support app/OS/DB auditing?), no internal champions, and not mention integration effort is high as contextual information differs from environment to environment. In my experience the only drivers are compliance. MSSP's have custom solutions to convert audit data to log data and integrate the contextual data. I know of one that does it well (but will leave vendor info off the list). So, somebody need to campaign "Database logging: it just isn't only > for auditors anymore" :-) You also need to campaign for app layer and OS logging in concert with DB logging. This is because from a security perspective, if a server was compromised or internal admin user wanted to modify data, the first thing they would do is disable auditing or logging functionality. It's like adding an alarm system to your doors but not monitoring the windows - there's no point in a partial solution. All my DB logging implementations focused implicitly on capturing admin user activity. Yes, the implementation audits all users, but heavy focus on admin users. This is driven from compliance. Admin users have carte blanche access to the environment, so you must implement app/OS/DB logging if you need to monitor their activity. >From a log aggregation & reporting perspective, you still need to integrate contextual data into your monitoring/reporting. IDS and host based messages are easy once you can parse, identify, and label the attributes of each message. A failed login message or attempt to map C drive means the same across all customers. The context here are users and assets. With app layer transactions, OS, and DB, each environment is very different and you need a paradigm to normalize this data for monitoring & reporting. _______________________________________________ LogAnalysis mailing list LogAnalysis@private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2.1.3 : Wed Mar 21 2007 - 18:58:57 PST