Skip to main content
 
Splunk Lantern

Badge readers with abnormally high read failures

 

Security in your data center is restricted, and both control of access to such facilities and monitoring of such access are required. You want to monitor failure rates for badge reader(s) over a specific time period.

Required data

Procedure

  1. Ensure your lookup file is uploaded to your Splunk deployment.
  2. If needed, adjust field names to match what is available in your lookup files.
  3. Run the following search. You can optimize it by specifying an index and adjusting the time range.
    | sourcetype=<physical card reader logs>
    | lookup <error code to status mapping> errorCode OUTPUTNEW status
    | lookup <badge reader ID to location mapping> readerID AS badgereaderId OUTPUTNEW description active
    | lookup <badge to user info mapping> cardId AS badgeId 
    | eval fullName=firstName+" "+lastName 
    | fields _time badgeId description fullName status 
    | search status="ACCESS-DENIED" OR status="READ-SUCCESS" 
    | streamstats count reset_on_change=true window=2 BY description 
    | search (count > 1) AND status="ACCESS-DENIED" 
    | bin span=5m _time 
    | stats count list(badgeId) AS Badge list(description) AS Location list(fullName) AS Name BY _time 
    | where count > 1 
    | rename _time AS Time 
    | convert ctime(Time) 
    | table Time Location Badge Name
    

Search explanation

The table provides an explanation of what each part of this search achieves. You can adjust this query based on the specifics of your environment.

Splunk Search Explanation
| sourcetype=<physical card reader logs>
 
Search only your physical card reader data.
| lookup <error code to status mapping> errorCode OUTPUTNEW status Look up the error codes and output the associated status for each.
| lookup <badge reader ID to location mapping> readerID AS badgereaderId OUTPUTNEW description active Look for matches between the badgereaderId field in your events and the readerID field in the <badge reader ID to location> lookup table. When matches are found, output the values in the readerID field into a field called description.
| lookup <badge to user info mapping> cardId AS badgeId  Look for matches between the badgeId field in your events and the cardId field in the <badge to user info> lookup table. 
| eval fullName=firstName+" "+lastName  Concatenate the first and last name fields into a single value called fullName.
| fields _time badgeId description fullName status  Display only the fields shown in the search results.
| search status="ACCESS-DENIED" OR status="READ-SUCCESS"  Search for only events with an access denied or read success status.
| streamstats count reset_on_change=true window=2 BY description  Keep track of the previous events, and add to the results as more events come in.
| search (count > 1) AND status="ACCESS-DENIED"  Return only results where the event count is greater than 1 and the status is access denied.
| bin span=5m _time  Group results into 5-minute buckets.
| stats count list(badgeId) AS Badge list(description) AS Location list(fullName) AS Name BY_time  Count and list the badge IDs and description of events, grouping them by user.
| where count > 1 Filter results to those with a count of greater than 1.
| rename _time AS Time  Rename the fields as shown for better readability.
| convert ctime(Time)  Convert epoch time to a human readable time.
| table Time Location Badge Name Display the results in a table with columns in the order shown.

Next steps

High failure rates may potentially be indicative of a physical issue with a badge, or of an external situation where more physical security may be required.

Finally, you might be interested in other processes associated with the Monitoring badges for facilities access use case.