Splunk Enterprise Security

Splunk ES - Completely Inactive Accounts - Multiple Logins

jonathan_cooper
Communicator

I have a question regarding the access tracker in ES, specifically the correlation search "Completely Inactive Accounts".

In my environment, user logins are not always associated with the same host consistently, besides their own personal workstation. Certain authentication tools such as AD or other applications that have load balancers, route user authentication requests to multiple servers. This is causing false positives with this correlation search as user's are being seen as inactive, generating a notable event, even though their user is logging into other hosts much more frequently (i.e. their own workstation). As a result, the significant number of "inactive account" notable events is causing errors in the dashboard rendering since the number of events far exceeds the JSChart limits.

I've been trying to figure out the best way to adjust either the correlation search or the populating searches that track all access via the access_tracker lookup table. I'm looking for suggestions on the best way to reduce these false positives.

1 Solution

jonathan_cooper
Communicator

I was able to solve this by adding a "... | dedup user | ..." to the inactive_accounts_usage macro.

Unfortunately, when I tried your suggestion, I noticed that even in 2.4 it was still organizing the data by user. For some reason though, there would still be duplicates for some users, allowing them to age beyond the 90-day mark thus causing a false positive notable event.

Thank you for your help though, it did point me in the right direction.

View solution in original post

0 Karma

jonathan_cooper
Communicator

I was able to solve this by adding a "... | dedup user | ..." to the inactive_accounts_usage macro.

Unfortunately, when I tried your suggestion, I noticed that even in 2.4 it was still organizing the data by user. For some reason though, there would still be duplicates for some users, allowing them to age beyond the 90-day mark thus causing a false positive notable event.

Thank you for your help though, it did point me in the right direction.

View solution in original post

0 Karma

hazekamp
Builder

Jonathan,

A little background on this correlation. The "Access - Completely Inactive Account - Rule" saved search is what generates "Completely Inactive Account" notable events. This can be modified to produce the results that you desire.

Currently (in ES 3.0), the ootb definition for this search is:

| `inactive_accounts(90)` | `settags("access")` | `ctime(lastTime)` | table user,dest,orig_tag,dayDiff,lastTime

As you can see this correlation search uses a macro `inactive_accounts` as the logic to determine what an inactive account is.

| inputlookup append=T access_tracker | stats min(firstTime) as firstTime,max(lastTime) as lastTime by user | `get_identity4events(user)` | eval _time=lastTime | `daysago($greaterThan$,">=")`

Since we do not split by host (only user) in our stats command, messages from a username logging into unique hosts will be consolidated (unless the usernames are unique).

Can you also elaborate on which dashboard and panel are giving you errors rendering. I have seen errors related to truncating results when too much data is passed to column/timecharts. Here are some options for charts experiencing truncation issues:

The limit is on the total number of
points that are drawn (the actual
limit is 1500 I believe), so you have
a few options:

1) choose a larger span
for timechart, or try letting it
auto-span

2) set a limit on the number
of series that are shown

3) use a line
or area chart (they have a higher
limit because they don't have the
overhead of drawing a shape for each
point)

4) In a dashboard, you can set the limit per panel like this:

<option name="charting.chart.resultTruncationLimit">15000</option>

Let me know if you have any more questions.

David

hazekamp
Builder

Regarding your prev comment about the ES 2.4 version of inactive_accounts, It looks like the inactive calculation is not as optimal as the ES 3.0 version. You can put a local override in place for the inactive_accounts(1) macro to the latest version:

inputlookup append=T access_tracker | stats min(firstTime) as firstTime,max(lastTime) as lastTime by user | `get_identity4events(user)` | eval _time=lastTime | `daysago($greaterThan$,">=")`

hazekamp
Builder

Jonathan,
Regarding removal of users from access_tracker which have been removed from the environment this would be a manual process of editing the access_tracker. To make this manual process easier, you can add access_tracker to the list of editable lookups which will allow you to edit the CSV from Configure->Data Enrichment->Lists and Lookups using our graphical editor.

jonathan_cooper
Communicator

I have a follow up question that I could not find an answer for in the docs. Once a user that is considered inactive is removed from the environment, how is that user removed from the access_tracker in order for it not be alerted on again? Is this a manual process of editing the access_tracker lookup table? I appreciate any help.

0 Karma

jonathan_cooper
Communicator

I should have mentioned before that we are running ES 2.4, not 3.0. Looking at the same correlation search everything is the same except the inactive_account macro:

inactive_account_usage | daysago($greaterThan$,">=") | sort 0 -dayDiff

And if I go a bit deeper, the macro for inactive_account_usage:

access_tracker | stats values(dest) as dest,values(tag) as tag,min(firstTime) as firstTime,max(second2lastTime) as second2lastTime,max(lastTime) as lastTime by user | eval _time=lastTime | eval inactiveDays=(lastTime-second2lastTime)/86400 | sort 0 - inactiveDays

0 Karma
Did you miss .conf21 Virtual?

Good news! The event's keynotes and many of its breakout sessions are now available online, and still totally FREE!