Blog

Least privilege is a common security practice where systems allow users the minimum permissions necessary to operate. It prevents users from harming things they ought not harm. It is a great rule of thumb. However, policies for enforcing this practice grow complicated in large organizations where people move about and move on frequently.

Removing privileges from former employees is the most basic use case. An employee resigns, turns in her badge and waves good-bye. Yet, the employee often lingers in systems where she should have zero privileges. Even when authorization has been revoked, the user’s account can remain. The issue is a policy problem. Human resources and information security must work together to sweep up those that fall through the cracks.

Fortunately, upkeep is relatively simple in Splunk. Spunk's REST API lets users automate user and role changes. The endpoints to add, update and delete users and roles are accessible via common tools like cURL or an SDK. An update is as simple as a for loop.

Administrators should review the following endpoints before setting this policy:

User

• /services/authentication/users/{name}

Roles

• /services/authorization/roles/{name}

DELETE REQUEST

Administrators can use a simple script with input from a list of users to be deleted.

Example:

#!/bin/sh
#Splunk Bulk User Delete
HRLIST=$1
AUTH= $2:$3 #user, password

#./script.sh hrlist.list $user $password

for NAME in `cat $HRLIST`
  do
    #make a back up
    curl -k -u admin:changeme  https://localhost:8089/services/authentication/users/$NAME>> backup.bk
    #delete the users
    curl -k -u admin:changeme --request DELETE https://localhost:8089/services/authentication/users/$NAME
done;

This process is destructive, so take caution. Make a backup of affected users prior to deleting. Additionally, check the user for dependencies such as dashboards, saved searches, or other knowledge objects they may become "orphans" because the objects retain their owner even after the owner has been deleted from the system. Orphaned objects also may change behavior. Splunk checks to see that a user has permission to execute saved searches. Deleted owners lose permissions, so their savedsearches and alerts stop working. The Knowledge Manager Manual (KMM) even warns - "The search scheduler cannot run orphaned scheduled searches." Administrators should develop consistent policies to manage transistions. See "Disable or Delete Knowledge Objects" in the KMM for additional perspective. 

Also, pay attention to response codes. Because this is a REST API, the errors are reported with standard HTTP 200 for success and 400 for errors. It is the administrator’s responsibility to attend to and mitigate errors.

Conclusion

In summary, review and remove users who have left the company. If an employee’s role changes, change the role of that user in Splunk. Use the REST API to automate things. Splunk’s UI is excellent, but unnecessary for expected, repetitive tasks that should be automated. Getting the list of users from HR is worth the conversation and necessary to adhere to least privilege.

Happy Splunking

For more information, please review the documentation

http://docs.splunk.com/Documentation/Splunk/6.4.3/RESTREF/RESTaccess

http://docs.splunk.com/Documentation/Splunk/6.4.3/Security/Rolesandcapabilities