Active Directory Context In Security Analytics

[MarkKarlstrand]

Security Analytics would like to help customers harness the user and resource details stored in their Active Directory (LDAP) for behavior analytics, incident response and investigations. Behavior analytics will need very frequent access to the profile data for every user so SA will need a copy of the AD fields the solution uses. To this end we would like your feedback on the most acceptable approach to making AD data available to SA. Here are three options we are considering. It would be a great help if you would please comment on which may be most palatable to your organization and why.

1. When a customer enables SA behavior analytics they will bootstrap the system will a bulk load of AD data. To accomplish this a customer exports an LDIF of the fields needed for all users then loads it into SA. To make regular updates easy and secure the customer would issue SA a service account and configure connectivity to AD. The customer could easily configure how often SA is allowed to query AD and times of the day it should not make any queries. The default would be to query AD for updates once every 24 hrs at 200 am local time.
2. When a customer enables SA behavior analytics they will issue SA a service account and configure connectivity to AD. The customer could easily configure how often SA is allowed to query AD and times of the day it should not make any queries. The default would be to query AD for updates once every 24 hrs at 200 am local time.
3. When a customer enables SA behavior analytics they will bootstrap the system will a bulk load of AD data. To accomplish this a customer exports an LDIF of the fields needed for all users then loads it into SA. To make regular updates the customer would implement custom scripts to export and import a new LDIF file.

[JeremyKerwin]

For me, option two would work well in my organisation. I don't see the need to perform a bulk load of data to begin with.

A way to configure a service account and then configuration options about what data to pull from AD would suit me quite nicely.

[MarkKarlstrand]

Thank you for your input Jeremy. It's good to hear that #2 would be your preferred approach. From various discussions this seems to be the case for many SA customers.

[NathanOlsen]

Options 1,2 both seem useful from my perspective; the initial bulk load would make the meta creation a bit faster (it would seem) after bootstrapping since we would (probably) not see an initial surge in LDAP activity during lookup of user data.

As an ongoing method of extraction, the service account solution is useful and reasonably secure.

[MarkKarlstrand]

Thank you for the feedback Nathan. Do you have any concerns with utilizing an LDIF file export for the initial bulk load in option #1, if so what are they? If you had to choose between option 1 and 2 which would be your top pick, and why?

[NathanOlsen]

I don't know that I have any security concerns with using an LDIF file to bulk load.

I think the only real difference between 1, 2 for me is that the Network Support folks might get testy if the bulk load swamps available network bandwidth during initial bootstrap. In that regard, the LDIF export might be preferred by them.

I think personally, the SA route (#2) seems preferable because it seems like less effort to get running, even if it might gulp a lot of data initially.

The benefits of having contextual AD info in SA greatly outweigh any short term impacts, at least from my perspective.

[MarkKarlstrand]

Great, it seems the consensus across customers we have spoken with is option #2 with the addition of a throttling mechanism to limit the load on AD from the SA query. Thank you for your input!