• State Verified Answer
  • Replies 6 replies
  • Subscribers 15 subscribers
  • Views 4246 views
  • Users 0 members are here
Options
Related

Repository Viewer "Search" versus gathering and storing in Audit Database

shrum brian
over 3 years ago

Today we are storing security events in a repository.  We then have a search set up each night to grab logon info for the previous day.  This has been working for a couple of years, and gives us the info we need.  However, the only option is to store this in a CSV/PDF, which doesn't give us a lot of options for storage or enhancing the report.  Currently we pull user ID information out of the report and query AD for more information on said user.  A manual process that we want to automate.  In addition, we'd like to utilize PowerBI to build reports off of this information.  Having a CSV works, but not for a nightly report since the file name changes on each report.

I started looking at using the InTrust Manager for a gathering rule that would write to the database.  I wouldn't necessarily need the data to stay there if I could get what I want from the table as I know over time this database would get very large.  However, I am not seeing nearly the amount of data in the table from the gathering rule that I see when the same events are stored in the repository.  So on the surface this doesn't seem to be a good option.

Is there a way to write the Repository Viewer search data to a SQL table? 

Do the gathering policies in InTrust Manager collect less detailed information that what is stored in the repositories for Security events?  If the answer is "No", then I must not be doing something correctly with the gathering policy.  

I am VERY new to this InTrust product, so I am not positive I am doing everything correctly.  I know there is an SRS option, and at this point we don't have it enabled.  I don't know that it would help us for 2 reasons: 1) the lack of detail from the security events, and 2) the need to have Active Directory information added to our reports.

What we have today in our report from Repository Viewer:  

Date, Type, Who, Computer, Logon Type, Where From

Type is "success audit", Who is user ID, where from is an IP address....all of this info comes from the event in the repository.  

Hopefully this makes sense and someone knows if we have any options. 

Parents
  • +1 over 3 years ago

    To address your very valid concerns about audit database growth, my best practice is to create dedicated audit databases for reporting on high volume events.  When performing the imports to these databases, one should try (via filtering) to optimize the events being imported as much as possible.

    So typically, in InTrust Manager, you would create a scheduled workflow that would consist of the following jobs:

    Import data from the repository

    Execute your reports (see note)

    Purge your audit database

    ...repeat daily (or whatever makes sense for your needs)

    NOTE:  If you choose to use something other than an InTrust reporting job to generate your reports, then this step can be omitted.

  • 0 over 3 years ago in reply to JohnnyQuest

    Thank you for the information.  I have set up an import from the repository, and I can see there is data in the Audit database as expected.  However, as I mentioned in my original post, we are grabbing more detail out of the repository in our reports.  You mentioned we should be able to get more detailed info out of the database, but how do I do that?  Is there a table I can link to with this info.  The events table doesn't seem to have what I need, at least not the details I need.  I am struggling to find where the rest of the info is kept.  I did find eventstrings, but not sure that has everything I need, or how to connect it to the events table.

    If I can figure out the database I can surely set up this whole thing including a cleanup job.

    Thanks for your help!

  • 0 over 3 years ago in reply to shrum brian

    The events are (conceptually) stored in basically two tables:  events and event strings.  

    Here's an article about the database structure:


  • 0 over 3 years ago in reply to JohnnyQuest

    Not sure how much you know about the structure of Event log data but when it comes to an event, you have the metadata like the time and the event ID and then you have the event strings which are typically used to construct the details of an event as depicted in the Description in Event Viewer.  This is quite often the data that you are looking for when performing reporting.

  • 0 over 3 years ago in reply to JohnnyQuest

    I actually know very little about any of this, but am learning what I can.  Your info was very helpful.  Thank you!

Reply Children
No Data