SPLK-2003 User Management

User Management Detailed Explanation

1. What is User Management?

User Management in SOAR refers to how you control who can access the platform, what they can see, and what they are allowed to do. It helps ensure that only the right people have the right level of control — especially important in cybersecurity environments.

2. User Types

Different users in Splunk SOAR have different roles, based on their job in the security team.

a. Administrators

• Who they are: The people who set up and manage the entire SOAR system.

• What they can do:

  • Install apps

  • Manage users and permissions

  • Configure system settings

  • Create and modify playbooks

  • Change the system time, SMTP, and more

Think of them like “super users” — they have full power and responsibility over the platform.

b. Analysts

• Who they are: Security team members who investigate alerts and incidents.

• What they can do:

  • View events and artifacts

  • Run playbooks on incidents

  • Take ownership of cases

  • Add notes, interact with prompts

  • Close or escalate investigations

They are the ones actively using SOAR in their daily work to respond to security threats.

c. Custom Users

• What this means: You can create roles with very specific permissions.

• Example:

  • A “Viewer” who can only read data but not run anything.

  • A “Junior Analyst” who can view alerts and run playbooks, but not modify them.

Why it's useful: You can make sure new or external users don't accidentally break something or see sensitive information.

3. Role-Based Access Control (RBAC)

This is one of the most important parts of user management.

What is RBAC?

RBAC means that permissions are assigned to roles, not directly to users. Then, users are assigned to those roles.

Think of it like this:
Roles = job descriptions.
Users = employees.
Instead of giving permissions one by one to each employee, you define the permissions in the job description (role), and assign that role to each employee.

How It Works in SOAR

• You define a role (e.g., “SOC Analyst”, “Case Viewer”).

• You decide what that role can and cannot do, such as:

  • Run or edit playbooks

  • See certain dashboards

  • Use specific assets

• When you create or edit a user, you assign them one or more roles.

Examples:

Role Name	Can View Cases	Can Run Playbooks	Can Modify Assets
Admin	Y	Y	Y
Senior Analyst	Y	Y	N
Junior Analyst	Y	N	N

This makes it easy to scale your SOAR system securely — you don’t need to manually set every permission for every person.

4. Authentication Options

Authentication is the process of verifying a user’s identity when they log into Splunk SOAR. Splunk SOAR offers multiple ways to authenticate users, depending on your organization's needs and security requirements.

a. Local Authentication

This is the simplest form of authentication, and it works out of the box.

What it is:

• Each user has a username and password stored directly in the SOAR system.

• Users log in through the SOAR web interface with those credentials.

Pros:

• Easy to set up.

• Doesn’t require external systems.

Cons:

• Not ideal for large teams.

• Password policies need to be enforced manually.

Use Case:

You’re setting up a small SOAR instance or testing environment with just a few users.

b. LDAP / Active Directory Integration

LDAP (Lightweight Directory Access Protocol) and Active Directory are widely used in enterprises to manage employee accounts and access.

What it is:

• SOAR connects to your company’s existing directory server.

• Users use their corporate usernames and passwords to log in.

Pros:

• No need to manually create user accounts in SOAR.

• Password policies and login history are managed centrally.

• You can sync groups from AD and assign SOAR roles based on group membership.

Cons:

• Requires some IT knowledge to configure.

• Needs to be tested carefully before enabling in production.

Use Case:

Your organization already uses Active Directory or LDAP for employee logins, and you want seamless access control.

c. SAML (Single Sign-On)

SAML (Security Assertion Markup Language) allows users to sign in using a Single Sign-On (SSO) provider like:

• Okta

• Azure Active Directory

• Google Workspace

• OneLogin

What it is:

• When a user tries to log into SOAR, they are redirected to a trusted identity provider (IdP).

• After logging in there, they are allowed into SOAR automatically — no separate password needed.

Pros:

• Seamless user experience.

• Very secure (especially with multi-factor support).

• Centralized login control across multiple platforms.

Cons:

• Requires configuration on both the SOAR and the IdP side.

• Misconfiguration can prevent users from logging in.

Use Case:

Your company uses Okta or Azure AD and wants all employees to use the same login everywhere.

d. Two-Factor Authentication (2FA)

Two-Factor Authentication adds a second step to the login process. After entering a password, the user must enter a one-time code from a mobile app.

What it is:

• SOAR supports TOTP (Time-based One-Time Password) apps like:

  • Google Authenticator

  • Authy

  • Microsoft Authenticator

How it works:

1. The user logs in with username + password.

2. They are prompted to enter a 6-digit code from their authenticator app.

3. If both steps are correct, access is granted.

Pros:

• Strong protection against stolen passwords.

• Easy to set up per user.

Cons:

• If a user loses their phone, they’ll need to reset access.

• Not available by default with all auth methods (e.g., some SSO setups handle this externally).

Use Case:

You want to protect admin accounts or all logins with stronger security.

Summary Table:

Method	Easy Setup	Good for Small Teams	Enterprise Ready	Secure (2FA Support)
Local Authentication	Y	Y	N	Y (optional)
LDAP / Active Directory	N	N	Y	Y (via AD config)
SAML / SSO	N	N	Y	Y (via IdP)
2FA (TOTP)	Y	Y	Y	Y

User Management (Additional Content)

1. Account Lockout Mechanisms and Password Policy

SOAR supports several local authentication security mechanisms that help enforce security compliance within enterprise environments.

a. Account Lockout on Failed Logins

• Splunk SOAR does support configurable lockout policies for failed login attempts.

• Admins can define:

  • The maximum number of failed login attempts

  • The duration of the lockout period

• This is useful to prevent brute-force login attacks.

This configuration is typically managed through the Admin UI under Authentication Settings, and it applies to users who authenticate using local credentials (not via SAML or LDAP).

b. Password Complexity Enforcement

• SOAR supports local password policy configuration, including:

  • Minimum password length

  • Character complexity requirements (e.g., uppercase, lowercase, numeric, special characters)

• These rules can be applied only to locally managed users, not those managed by external identity providers.

c. Password Expiration and Rotation

• Admins can also enforce:

  • Password expiration intervals (e.g., every 90 days)

  • Password history rules (e.g., disallow reuse of the last N passwords)

  • Mandatory password changes on first login

This feature supports compliance mandates such as NIST, PCI-DSS, or ISO/IEC 27001.

Summary:

Capability	Supported for Local Users?
Lock after failed attempts	Yes
Password complexity	Yes
Expiration policies	Yes
Applies to SAML/LDAP users	No (controlled externally)

2. User Auditing and Activity Logging

Monitoring user activity is essential for both security and compliance auditing.

a. What Is Tracked?

Splunk SOAR maintains detailed audit logs for:

• Login attempts (success/failure)

• User account changes (creation, role changes, deletions)

• Playbook executions

• Manual actions taken during investigations

• Modifications to system settings or configurations

This enables tracking of who did what, when, and where within the platform.

b. Where to View User Activity Logs

• Logs can be found in the UI under:
  Administration > Audit Logs or Administration > System Settings > Logs

• Alternatively, logs are also written to the file system:

  • Authentication and web activity:
    /var/log/phantom/phantomd.log

  • Playbook execution and actions:
    /var/log/phantom/playbook.log

• Logs can be exported and ingested into Splunk for long-term retention, alerting, and correlation.

c. Use Case for Exams

Example question:
“How can an administrator verify whether User A manually triggered a playbook yesterday?”
Answer: Use the Audit Logs section or query the relevant log files for timestamped user activity.

3. Default Roles and Built-in Permissions

Splunk SOAR includes several predefined user roles with varying levels of access. Understanding these roles is important for both platform governance and exam scenarios.

a. Built-in Roles

Typical default roles include:

Role	Description
Administrator	Full control over the platform, including user and system configuration
Automation	Designed for machine accounts or app integrations; can execute playbooks but not access the UI
Analyst	Can view and respond to incidents, run playbooks, add notes
Manager	Similar to Analyst, but may have broader visibility and reporting access

These roles are not hardcoded — administrators can customize permissions further by cloning and modifying roles.

b. Role Permissions and Limitations

• Automation role:

  • Can run actions and playbooks via API

  • Cannot log into the web interface

• Analyst role:

  • Can manually execute playbooks

  • Cannot modify system settings or user configurations

• Only Admins:

  • Can create or delete users

  • Can install apps and configure assets

Common Exam Trap:

A question may ask:
“Can a user with the Automation role trigger playbooks via API?”
Yes. However, they cannot access the UI.

Final Tip for Exam Readiness

Expect multiple-choice questions that challenge your understanding of:

• What happens when login attempts fail repeatedly

• Who can perform system-level actions

• How audit logs can verify user behavior