Security

Native Splunk password Complexity for Splunk admin user

Builder

Is there anyway to enforce password complexity for admin user using Splunk's native user/password authentication?

Specifically I am looking for:

1.Native Splunk Password for admin user must follow a minimum defined complexity (e.g. uppercase, lowercase, numbers, special chars and a certain length)

I saw a similar post, but for a long time ago. Hopefully something changed since then

0 Karma
1 Solution

Influencer

I'm assuming this is for an audit of some sort of variety or another. Another way to attack the problem therefore might be to prove that a process to create and set such a complex password is in place, and has not been circumvented:

If you developed a admin password generator app, similar to Skip's https://splunkbase.splunk.com/app/2722/ that through a scripted input, would generate and set a random password that would be guaranteed to meet your complexity requirements, and would record (as it is an input) that such a procedure was successfully performed for the admin user. You then add some form of file change monitoring for the splunk passwd file, and then you can demonstrate that 1) your automatic password setter is guaranteed to generate a password that meets your complexity requirements, 2) that the password setter was successfully ran at a particular time for a particular server, and 3) the password file has not been changed other than with the password setter (because lest we forget if you control the splunk system user you could in fact reset the admin password back to changeme). Other Splunk admins would of course be mapped from an external repository that would enforce such requirements independently of Splunk.

If expiration time is part of your password requirements (instead of set something and forget), then you would want your password changing app to work with a password store, and then be able to demonstrate that the passwords in the store meet the requirements, and that the passwords have been updated on the boxes on at least the prescribed basis. (again auditing that the password file only changes with your app). Developing either might be a bit of an undertaking but depending on what you need to prove in terms of requirements could be worth it. As such data is in Splunk, you could even setup alerting when the regular password changing pieces fail.

Depending on how you're installing Spunk and the exact requirement you're trying to prove compliance with, you could have your installation / configuration management scripts perform the generation of the complex password on a regular basis instead of a Splunk App.

View solution in original post

Ultra Champion

Taking on the theme from @acharlieh:

If you wanted to track changes to the admin password (i.e to make sure it is changed every X days, OR to make sure it has not been changed from the password you set which follows your security policy [i.e someone has not set it back to changeme]

This script will md5 the encrypted password, and allow you to ingest into Splunk as a scripted input. You can then configure alerts if the password is changed <X days, or send a reminder > X days that its due to be changed

#!/bin/bash
cat $SPLUNK_HOME/etc/passwd |grep admin|md5sum|awk '{print "admin_checksum="$1}'

produces output: admin_checksum=895f18890964bba6fb3e920053b6c5f1

Depending on your use case/auditor if you can demonstrate that you have a 'defined process' and a 'technical evidence control' around managing the admin password on Splunk, you should be able to demonstrate adherence to your policy.

i.e

Policy says we set the password to insert your password regex, and record the resulting md5 in a change ticket. If that md5 changes inside 90 days we trigger an alarm [with splunk] for the change to be reviewed. After 90 days an alert is sent [with splunk] [optionally automatically open a change ticket for bonus points] to remind the splunk admin to change password, and the process repeats.

Builder

@nickhillscpl, thank you for your input!

0 Karma

Influencer

I'm assuming this is for an audit of some sort of variety or another. Another way to attack the problem therefore might be to prove that a process to create and set such a complex password is in place, and has not been circumvented:

If you developed a admin password generator app, similar to Skip's https://splunkbase.splunk.com/app/2722/ that through a scripted input, would generate and set a random password that would be guaranteed to meet your complexity requirements, and would record (as it is an input) that such a procedure was successfully performed for the admin user. You then add some form of file change monitoring for the splunk passwd file, and then you can demonstrate that 1) your automatic password setter is guaranteed to generate a password that meets your complexity requirements, 2) that the password setter was successfully ran at a particular time for a particular server, and 3) the password file has not been changed other than with the password setter (because lest we forget if you control the splunk system user you could in fact reset the admin password back to changeme). Other Splunk admins would of course be mapped from an external repository that would enforce such requirements independently of Splunk.

If expiration time is part of your password requirements (instead of set something and forget), then you would want your password changing app to work with a password store, and then be able to demonstrate that the passwords in the store meet the requirements, and that the passwords have been updated on the boxes on at least the prescribed basis. (again auditing that the password file only changes with your app). Developing either might be a bit of an undertaking but depending on what you need to prove in terms of requirements could be worth it. As such data is in Splunk, you could even setup alerting when the regular password changing pieces fail.

Depending on how you're installing Spunk and the exact requirement you're trying to prove compliance with, you could have your installation / configuration management scripts perform the generation of the complex password on a regular basis instead of a Splunk App.

View solution in original post

Builder

@acharlieh, you were right. that was required for internal audit. thank you for a detailed answer and suggestions.

0 Karma

Ultra Champion

You can enforce length, but not complexity in authentication.conf

minPasswordLength = <positive integer>
        * Specifies the minimum permitted password length in characters when passwords are set or modified.
        * This setting is optional.
        * If 0, there is no required minimum.  In other words there is no constraint.
        * Password modification attempts which do not meet this requirement will be explicitly rejected.
        * Defaults to 0 (disabled).

http://docs.splunk.com/Documentation/Splunk/6.5.2/Admin/Authenticationconf

Builder

@nickhillscpl , thank you. That presents the problem. Our admin passwords not only need to meet certain requirements but we need some kind of prove that it was done. And there is only length can be enforced. I wonder what can be the work around

0 Karma