0

I have a few questions regarding the use of Databases in SIEM technology. I would appreciate if you guys can help me understand / answer these questions. The answers from you help me design the SIEM requirements.

The questions are:-

  1. How does SIEM grows with the use of database? I'm talking in terms of high volume storage comparable to the size of banks or large country census data.
  2. How well does SIEM integrate with database solutions such as InfoSphere Guardium?
  3. What basic functionality should a good SIEM have if it needs to support logs from a large database such as teradata?
  4. What kind of filtration, normalization and aggregation rules can be applied if logs are obtained from database solely ( with no middle-ware solution included)?
  5. Do you have knowledge of SIEM products that provide out of box functionality to entertain database logs?
  6. And lastly, how does a regular SIEM saves database logs?
Saladin
  • 1,547
  • 3
  • 14
  • 23
  • 4
    These are all very good questions, unfortunately the SEI network of sites considers these types of shopping questions off-topic. The SIEM market is very complex and full of vendors with a wide range of implementations, technologies, methodologies, and supported devices/configurations. Unfortunately, it's fairly impossible to answer such high level questions considering that each question you have would require a completely different answer for each SIEM vendor. – Scott Pack Sep 07 '12 at 13:11
  • 1
    +1 to @ScottPack. If you take out item #5 and split this question into separate posts, you might have some material that better fits the StackExchange format. However, although it does ask about security-related products, this question really isn't an [security.se] question. Please read our [faq] to see what sort of questions are expected to be asked here. I'd suggest, if you want to try again, asking on [sf] instead. Particularly, I'd recommend asking items 1, 3, and 4. The rest are either not SE-appropriate, or would vary to much with specific implementations to be SE-answerable. – Iszi Sep 07 '12 at 13:41
  • 1
    @Iszi: Also, keep in mind, when reformulating that there is no such thing as a "typical" SIEM. All the vendors are going to do things, at least a little and often vastly, different. – Scott Pack Sep 07 '12 at 13:54
  • @ScottPack Thanks for shifting me focus to the right direction. Perhaps I was just trying out my luck a bit too far with those high level questions. I agree that each of these questions are worth of independent debate /or topics at SEI site i kind of thought some SIEM guru out-there can help me answer them in a nut-shell. But that all theory? – Saladin Sep 07 '12 at 17:24
  • @everyone I know i must be breaking some rules when I say but is it possible some of you who are more knowledgeable in this field can reply me with these questions outside SEI scope. Like by email. In this way there would be no worries of breaking any rules or polices. At the end i just need some help where to start ; I'm not looking for indepth i just need some industry experiences and some titbits / vendor insight etc. – Saladin Sep 07 '12 at 17:25
  • @everyone I have start a new thread and revisied it for more cleartiy and correctness. http://security.stackexchange.com/questions/19928/how-to-design-siem-rfp-keeping-in-view-large-database-requirments – Saladin Sep 09 '12 at 10:34
  • Agree about the previous comments, but I think your #3 and #4 would be better ontopic here than [sf], since as a security product these questions deal with the functionality of the product, which are in fact security requirements. – AviD Sep 11 '12 at 14:36

1 Answers1

1

As the others have said, your question is difficult to answer. Rich and Adrian over at Securosis have some research to address some of your questions. I'll stop there before I give you my own biased view on the SIEM landscape. Best you can do is to get up to speed with the niche, the basic problem these vendors are trying to solve. Choose a handful to investigate and a couple/few to test.

M15K
  • 1,182
  • 6
  • 7