Understanding team-based queues in Splunk Enterprise Security
Team-based queues in Splunk Enterprise Security (ES) represent a significant evolution in how security operations centers (SOCs) manage findings and investigations. Designed to align with SOC team workflows and organizational security policies, this feature enables granular role-based access control (RBAC) by dividing the main analyst queue (AQ) into multiple team-specific queues. This article covers the design principles, intended use cases, and best practices for team-based queues.
Design fundamentals of team-based queues
Purpose and scope
Team-based queues enable SOCs to enforce access controls and delegate responsibilities according to team roles, geography, workflow, or regulatory requirements. This is achieved by creating distinct team queues that act as security boundaries, ensuring that only authorized team members can access and act on findings and investigations assigned to their queue.
This feature applies across all cloud and on-premises ES editions (Essentials and higher), with phased rollout starting from ES 8.4 and full permission enforcement beginning in ES 8.5.
Role-based access control (RBAC) model
Team-based queues extend the existing Splunk core roles by introducing more granular permissions specific to team queues. Each team queue can be associated with custom roles that allow the definition and enforcement of create, read, update, and delete (CRUD), as well as run permissions. Members of the same team share the same custom role, ensuring consistent access within their queue. This lets you assign a finding or investigation to a specific team. By moving a finding or investigation into a team’s queue, you are fundamentally saying “this issue” should be examined by “this team.”
The queue itself is identified by a critical security boundary field, queue_id, and more commonly the queue name, which governs access to findings, investigations, and all their subordinate objects. All objects in a queue adhere to that queue's access policy, and a finding or investigation can belong to only one queue at a time. This is because different team queues typically have different permissions, so the same object cannot exist in two queues that enforce different access policies.
Over time, Splunk will continue to expand this system of controls to other functional areas within ES so that controls can be established for other functions within the ES suite.
Workflow and queue management
Team queues support automated sorting rules that assign findings to appropriate queues based on entity attributes, asset types, or other field level data criteria. The first matched rule gets to sort the finding and no further rules evaluation is performed after a rule matches. As rules order is important, you might need to adjust the order in which your rules evaluate findings. The rules for sorting to queues evaluate from top to bottom. If no sorting rules match a given finding by the time it reaches the end of the rules chain, it “falls into” the default AQ for manual triage by any ES user. All roles have full access to the default AQ so that no finding will go unseen. All findings will either sort to a specific team’s queue or fall into the default AQ where everyone can see it.
Findings and investigations can be transferred as a set of objects between queues to facilitate collaboration across SOC teams. If you choose to move a finding to a different queue, all the subordinate objects that are part of that finding will move with it to the new queue. The same can be said for investigations. Future enhancements aim to include workflow enforcement, such as requiring approvals or reviews before moving investigations to higher-tier queues or restricted access queues, such as confidential investigations.
API enforcement and security
Starting with ES 8.5, when you enable RBAC enforcement through the modinput function, it is handled at the API level. This RBAC enforcement lockdown step is optional and reversible so that you can define your access permissions first before your enforcement begins. Permissions are denied by default, so you will need to define your access policies before turning on enforcement. This means:
- Access to the
notableindex will be restricted to the admin user only so that non-admin roles cannot go around the team queue access policies by direct queries to the index or its related KV stores. Enable permission enforcement on this and other sensitive indexes, such astest_notable, to prevent users from circumventing their role’s configured permissions with direct queries. - UI interaction results in API queries being submitted to ES and searches are run in the context of the admin user.
- When the API queries return data, it is filtered according to the user's role and team queue permissions so that the user receives only the responses allowed by their role’s configured permissions.
- Third-party applications and integrations can rely on these APIs to enforce access controls. As the API query is run in the context of a user and the user’s roles are verified by the API before returning the response, this eliminates the need for custom permission checks.
- The
riskindex is not currently protected but is being considered for protection in a future release.
This design ensures that data access respects the configured organizational policies and the compliance requirements, and incorporates appropriate access logging for audit purposes.
Best practices for leveraging team-based queues
Planning and role configuration
Define teams and roles thoughtfully
Create custom roles aligned with your SOC structure so that team members share a role that ensures consistent permissions within their queues. Splunk will look to streamline and improve the method by which you can create custom roles in the future, but for now, these are our recommended best practices.
- If your SOC is organized to support different geographical areas, create and name your team queues and roles per your geographical boundaries.
- If your SOC is organized by tiered skill levels, create and name your team queues and roles to support the tiered structure and consider giving higher tier roles some level of access to the lower tiers to facilitate mentoring.
- If your SOC is organized to support different business units, create and name your team queues and roles to facilitate the division of work into those business unit queues.
Ensure your detections facilitate automated sorting
Sorting rules automatically place findings into the queue that is most appropriate to handle the issue based on field values present at the time the finding is created. Because of this, you should ensure that your detections populate the fields your sorting rules depend on - for example, a location field for geographic queues or a business unit field for organizational queues. Data enrichment that occurs after the finding is created will not be able to be leveraged by the sorting rules engine.
Opt-in feature
Team queues and permission enforcement are optional features. Begin with the default queue and gradually introduce team queues to match the organizational needs of your SOC. If you choose not to leverage team queues or RBAC enforcement, the default AQ will still work as it always has in the past.
Team queues will require unique sets of saved views
Since we can no longer assume that any given queue will have specific types of findings or investigations, we must scope default and custom saved views to individual team queues. The default AQ retains any custom saved views you have already created, but new team queues require you to create saved views appropriate to their finding and investigation types. The four default saved views - All, Owned by me, Unassigned, and Risk Score - exist in every queue. Each saved view returns results only for its queue; for example, "All" means "all items in this queue."
Plan for role proliferation
Large organizations might require many granular roles; plan accordingly to manage complexity. A single role can have access to one or more queues, so it is possible to give certain roles “oversight” into various team queues and grant varying levels of access to each of those queues.
Avoid using inherited roles in access policy
Many people leverage inheritance of basic roles in their creation of custom roles. While this saves a lot of time when you want to create a new role by starting with a known and working role, it can complicate the lines of access when using roles in team queue access policies. If the inherited role is used in granting access to a team queue, all roles that inherit from it will be granted access to the queue. To maintain precise control, use the custom role - not the inherited parent role - in your queue access policies.
Security and compliance considerations
Respect data handling policies
ES RBAC features work within ES only. Splunk assumes that you have created existing access policies for your event source indexes in the Splunk platform to protect that source data appropriately and in accordance with your organizational data handling policies. Ensure that underlying Splunk data indexes have appropriate access controls to prevent data leakage.
Avoid workarounds
Users should not be able to bypass queue restrictions as enforcement is expected to be strict and comprehensive. The system is designed to fail safe and requires specific permissions to be granted in nearly all cases, otherwise access will be denied. The default analyst queue is the one exception where all roles have full access. This is expected to be configurable in the future as more teams adopt these principles and the main analyst queue is expected to eventually have few to no events as organizations mature their sorting rules.
Additional resources
For detailed information on configuring and managing team-based queues, role creation, API usage, and permission enforcement, consult the official Splunk Enterprise Security documentation and Security API guides. These resources provide comprehensive guidance on implementing and adapting to the ES RBAC model and the team queue organizational system.