4 Replies Latest reply on Nov 10, 2015 12:02 PM by dan2

    Understanding Client Data Sources

    rabremmer

      I've been reading the Client Data Source topics in the user guides and I don't have a warm fuzzy on what is the best use for client data sources.  I understand that using client data sources and extend the number of data sources allowed on a receiver.  However, if this is not an issue, why would I use client data sources vs. having all my data sources unique?  For example, after running Auto Learn I end up with multiple syslog data source types per IP address.  This is not unexpected as the OS is one type and various application coule be other types.  Do I add each type as a unique data source or do I make the OS as parent and applications as client?  Does it make a difference, what are the pros and cons?  What's the best practice? 

       

      Appreciate the advice,

      Russell

        • 1. Re: Understanding Client Data Sources

          Hi Russell,

          The two main benefits of using client data sources. The first of which you are already aware of.   Using child datasources will extend your Receiver data source limit past 255.  The secondbenefit is for grouping purposes.  All client data sources will use the same parser type designated by the parent data source configuration.  This provides easier viewing of similar data source types by highlighting the parent datasource when viewing events in the navigation tree.  This also allows for easier editing and client additions to the group just by adding the name and IP address instead of all the selected parser details.  You can also export the datasources to csv and take advantage of the formatting and just add new clientslisted under the parent then import the csv back into the Rec and the new clients will be listed.

           

          Let me know if you have any additional questions in regardsto Client data sources.

           

          Thank you,

           

          Tony Ruger

          SIEM Support

          • 2. Re: Understanding Client Data Sources
            dcobes

            Russell,

             

            To give you a real-life example for a large enterprise (which hopefully gives you a warm but maybe not fuzzy). In our environment we have Parent data sources split up by a specific device type, ie WindowsOS. Depending on how many individual devices you have coming in you could make multiples (ie WindowsOS_1, WindowsOS_2, WindowsOS_3, and so on). The Parent data source is setup with a dummy ip that doesn't exist and our client data sources are set to "match on IP", we then add our real clients as "child sources". This way we have all device-specific data in order for easy management.

             

            Few tips:

             

            -Know how many different data sources your environment currently has

            -Know approximiately how many possible data sources you may add in the near future

            -Know a good estimate of your event rates for the data sources (useful for determining which devices to put on which receiver -- if you have multiples)

            -Come up with a good way to group your data sources (ie by device, by division, by OS/App, etc)

            -Draw out your plans on a white board or paper to get a good view of what you will be doing

             

            -d

            • 3. Re: Understanding Client Data Sources

              I just thought of another major benefit for Parent > Client (not child) data source configurations. 

               

              Policy rollouts.  You are most likely already familiar with seeing the millions of innocuous (noise) events generated by Windows systems on a daily basis.  Creating discard (filtering) rules can be very useful to a Receivers performance and for viewing and reporting on the useful Windows WMI events.

               

              When using a Parent > Client configuration, rolling out policy after creating new or modifying existing rules, would only need to be rolled out to one system rather than (in some cases) hundreds of systems.  This is a big time savor when working with regex string creating filtering (discard) rules that many times need to be tweaked along the way.

               

              Creating a custom policy with all windows systems under this policy will give you the same benifity, but you have to initially have to drag one system at a time under the custom policy before being able to use the customer policy folder and you must remember to do the same for all new windows systems you add.  So I favor the Parent > Child configuration over custom policy.  

               

              This is a key benefit when working with WMI default rules and or custom filtering rules.

               

              Tony.

               

              Message was edited by: tnitro on 12/21/12 3:14:11 PM CST

               

              Message was edited by: tnitro on 12/21/12 3:15:13 PM CST
              • 4. Re: Understanding Client Data Sources
                dan2

                You mentioned to "export the datasources to csv and take advantage of the formatting and just add new clientslisted under the parent then import the csv back into the Rec and the new clients will be listed." I am adding over 100 wireless APs as datasources now. could you please give more information? I have use following method to do the zone management. Is it the same?

                 

                1) export the file

                  Note: You can only make changes to the top level zone, not the sub zones

                2) make a copy of the file

                3) remove all lines that are for sub zones while keeping the top level zones and the header line

                4) put REMOVE in front of the remaining top level zones and import the file

                5) make any changes needed to the backup file from step 2

                6) put ADD in front of every line in the file except the header

                7) import the file.