I need some help regarding the design of SIEM requirments. In regard to large databases, what general requirements do I need to provide in order to provide coverage related to DB security?

Some of the use-cases I can think of are:

  1. use of privilege roles / accounts DBA, sysadmin
  2. Unauthorized Access to certain views/tables
  3. Report on deletion/addition of certain db table entries against certain time-based policy (date/time: xx-xx-2012/xx:yy:zzzz)
  4. Sending alert based upon security tampering baseline policy?
  5. Able to logs data/entries effected by certain malicious change?
  6. Able to identify attributes of service/application that draws SQL statements.

Are these enough or do I add more?

  • See also my answer here, while that is for a log management solution (and not exactly SIEM) there is a lot of overlap. In fact it might be close enough to close as a duplicate...?
    – AviD
    Commented Sep 11, 2012 at 14:39

2 Answers 2


Looks like a good start from a db outward view by analyzing logs. You'll have the inevitable tradeoff of performance vs amount of logging so give actual numerical requirements in your RFP. You should also take into account the environment around the database. One example is validate the software that accesses the database had static scanning done to find sql injection vulnerabilities. Another is to make sure the SIEM is also monitoring the surrounding systems so events can be correlated. The SIEM should should also accept inputs from third party db security tools.

http://chuvakin.blogspot.com/2010/11/how-to-write-ok-siem-rfp.html recommends you don't write an rfp at all, and suggestions if you do have to. Ones I particularly liked was explain the mission (eg compliance vs risk management). Another is be specific - vague specs will just get unenforceable 'yes' answers.


Maybe I am a bit late to discussion but someone might need this later.

My company is in SIEM business for 5 years and we have been reading lots of RFPs so far. What I would like to point out is that what you would need in the long run is always scalability so look for solution that has some kind of clustering in mind. That usually means scheduling jobs to remote nodes, their own database that supports some kind of sensible and fast clustering (please avoid mysql and similar databases). Also since there is chance that you will have lazy sysadmins in long run to keep that SIEM going ( this is how it usually looks after few years) I would look for log source auto-detection features and vendor who regularly updates your security/alerting indexers.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .