9 Replies Latest reply on May 8, 2017 7:27 AM by jcandiat

    Source Customer



      I have a question as to how the ESM correlator works with multiple clients. How does he determine that the incoming records are from client X?

      Let me explain: I have two clients (client A and client B) from which we receive their LOGS records. Both have approximately 4 devices from different vendors. When the LOGS arrive, the ESM correlator processes them but, how does he know that the processed LOGS are from client A and client B?

        • 1. Re: Source Customer

          It doesn't care. All the events are sent to the correlation engine by the ESM (either internal, either ACE) which will or will not match on a filter inside a component.

          • 2. Re: Source Customer

            Hi abanaru,


            Thanks for your answer. So, how can I do so that the client can see the correlated events of their infrastructure, without seeing those of the client b? I ask it, because I'm modifying the views for the users and I was in doubt if I allowed the client to access the correlation engine to see the correlated logs, that's why I did not understand how the esm knew that logs show the client and that logs Show them to the client b.

            • 3. Re: Source Customer

              Can you provide a bit more information, I'm assuming both customers are using the same receiver and you have an ACE?


              Assuming so...


              Make sure that customer A and customer B don't have devices under the same parent.  So for example, if they both have Cisco Firewalls that use the same settings, make two different entries at the top level under the receiver.


              Next, in your ACE, you'll need to create a correlation engine per customer.  (Go To ACE Properties, Correlation Management, and Add).  We do this and have "Customer A Correlation Engine", "Customer B Correlation Engine" etc.


              Now, assign each customers devices to their own correlation engine.  This keeps their individual data separate.


              In Users and Groups, create a group for each customer.  Under devices, give them permission to their data sources and their correlation engine.  Assign users to the appropriate groups.  This way, users from the customers can only see their own logs.


              When you are logged in and looking at events, if you're looking globally, you'll have to drill down to the event details to see which data source was the source of the event.  It may help to name the data sources appropriate.  ie: Instead of "Cisco Firewall" use "Customer A Cisco Firewall" to make things a bit easier on yourself.  If you are looking at just the appropriate correlation engine, you'll know that all events are sourced from that particular customer.

              • 4. Re: Source Customer

                Sorry, I understand now that you are referring to customers as clients. This can be achieved with an ACE by creating two different Correlation Managers working in two different Zones (Client_1_Zone and Client_2_Zone).


                Client_1_Zone will include "Client 1"s subnets while Client_2_Zone will include "Client 2"s subnets.


                This makes sure that each client will have it's own events correlated.

                • 5. Re: Source Customer

                  Yes, akerrs suggestion is a good one but keep in mind that "assign each customers devices to their own correlation engine" is done using Zones like I've explained in my previous post.

                  • 6. Re: Source Customer

                    Correlation Engines are setup with filters and what I would do in this case is filter based on devices.  So "Customer A Correlation Engine" would just have a filter that only looked at events from devices belonging to Customer A.  Same thing for Customer B.

                    • 7. Re: Source Customer

                      To summarize, you are both correct. This can be accomplished with zones but since defining different correlation instances by filtering on any field is possible, they are not required.


                      Zones play more important roles in other use cases; like receiving logs from overlapping IP space.

                      1 of 1 people found this helpful
                      • 8. Re: Source Customer

                        Yes, we use them specifically to define Geolocation for private IP spaces.

                        • 9. Re: Source Customer

                          Thank you everyone!