13.2 Role-Based Access Control, Feature Privileges & Index Security

Security operations teams operate under strict compliance and operational governance mandates. An outsourced Tier 1 analyst should never possess the authority to modify production detection rules, export unredacted employee credentials, or execute terminal commands on domain controllers. Conversely, detection engineers and incident responders require specialized privileges to tune correlation rules, access raw telemetry streams, and initiate host containment actions. In the Elastic Stack, Role-Based Access Control (RBAC) enforces these boundaries across two distinct layers: the Kibana Presentation Layer (Feature Privileges) and the Elasticsearch Data Layer (Index and Cluster Privileges).

---

1. Dual-Layer Authorization: Presentation vs. Data Engine

A critical failure mode in SOC access design occurs when an administrator assigns privileges at one layer while omitting the other:

+-------------------------------------------------------------------------+
|                   Layer 1: Kibana Feature Privileges                    |
|               (Controls UI buttons, navigation, and spaces)             |
|   - Security: All or Read (rules, alerts, Timelines); Cases separate   |
|   - Elastic Defend sub-features (e.g. Host Isolation, Operations)     |
+------------------------------------+------------------------------------+
                                     |
                                     | User triggers an action in the UI
                                     v
+-------------------------------------------------------------------------+
|                 Layer 2: Elasticsearch Index Privileges                 |
|               (Controls raw Lucene storage read/write access)           |
|   - logs-*-*: read, view_index_metadata                                 |
|   - .alerts-security.alerts-<space>: read, write, maintenance         |
|   - Document-Level Security (DLS) & Field-Level Security (FLS)         |
+-------------------------------------------------------------------------+

• Scenario A (UI granted, Data denied): An analyst is assigned 'All' privileges on the Security app in Kibana, but their Elasticsearch role lacks read privileges on logs-*. The analyst logs in, opens the Security app, but every search query fails with an Elasticsearch security_exception (HTTP 403 Forbidden).
• Scenario B (Data granted, UI denied): An analyst has full all index privileges on logs-* in Elasticsearch, but their Kibana role grants 'None' for the Security feature. The analyst cannot view the Elastic Security app in the Kibana navigation menu, though they could query the index directly via the Elasticsearch REST API.

To perform any operational action, a user's role must satisfy the requirements of both layers simultaneously.

---

2. Kibana Feature Privileges for Elastic Security (8.15)

Kibana feature privileges are assigned per space in Stack Management → Roles. In Elastic Stack 8.15, the Security app is governed mainly by one feature privilege, Security, set to All, Read or None:

• Read gives read access to all of Elastic Security except Cases. With the right index privileges, users can view alerts, rules, Timelines and dashboards.
• All allows creating and managing rules and exceptions, Timelines and other Security objects, again combined with the matching index privileges.
• In 8.15 there are no separate sub-feature privileges for rules, alerts or Timelines. Rules versus alerts access is separated by index privileges on the system indices, described in the next section.

Related features are assigned separately:

• Cases has its own feature privilege (All or Read). Pushing cases to external systems also needs Actions and Connectors privileges.
• Elastic AI Assistant and Attack discovery are their own features.
• Machine Learning, Dashboard, Discover and Maps apply to those apps (for example, the Network page map needs Maps privileges).

Elastic Defend Sub-Feature Privileges

The Security feature's only sub-feature privileges in 8.15 are for Elastic Defend. They must be assigned to all spaces. Selecting All for Security does not enable them: turn on Customize sub-feature privileges and grant each one (All, Read where available, or None):

• Endpoint List: The Endpoints page and host integration details.
• Trusted Applications, Host Isolation Exceptions, Blocklist and Event Filters: The pages that manage those endpoint artifacts.
• Elastic Defend Policy Management: The Policies pages and Elastic Defend integration policies.
• Response Actions History: The history of response actions.
• Host Isolation: Isolating and releasing hosts.
• Process Operations: The processes, kill-process and suspend-process response actions.
• File Operations: File-related response actions in the response console (for example retrieving a file).
• Execute Operations: Running shell commands and scripts. These run with the full privileges of the Elastic Defend service, so grant this very sparingly.
• Scan Operations: Folder scan response actions.

---

3. Elasticsearch Index Privileges for SecOps Workflows

Elasticsearch index privileges decide what a role can do with each index or data stream. Elastic's detection requirements for 8.15 are:

Two consequences matter for exam questions:

• An analyst with Security All but only read on the alerts index can view alerts but cannot change their status. The update fails with an authorization error until write access (with maintenance) is granted.
• Rules run in the background with an API key created from the privileges of the last user who edited the rule. If a user without the needed index privileges updates a rule, the rule stops working.

4. Advanced Data Security: Document-Level & Field-Level Security

Enterprise security policies often mandate that certain data within an index remain hidden based on user clearance or organizational tenancy.

Document-Level Security (DLS)

Document-Level Security restricts query visibility by embedding a query (written in Elasticsearch Query DSL) directly into the role definition. When a user queries an index, Elasticsearch silently appends the DLS query to the user's search criteria in filter context:

{
  "names": ["logs-endpoint-*"],
  "privileges": ["read", "view_index_metadata"],
  "query": {
    "bool": {
      "must_not": [
        { "terms": { "host.name": ["ceo-laptop", "cfo-macbook", "domain-ctrl-01"] } }
      ]
    }
  }
}

In this example, an outsourced Tier 1 analyst can query endpoint logs across all standard corporate workstations, but any event originating from executive or domain controller hosts is completely filtered out of their search results and aggregations.

Field-Level Security (FLS)

Field-Level Security controls which fields within a document are returned to the user. Administrators can define a whitelist of permitted fields or a blacklist of redacted fields:

{
  "names": ["logs-*"],
  "privileges": ["read"],
  "field_security": {
    "grant": ["*"],
    "except": [
      "user.password_hash",
      "http.request.body.content",
      "customer.credit_card_number",
      "patient.ssn"
    ]
  }
}

When a user assigned this role queries raw web proxy or application logs, the redacted fields do not exist from their perspective. Aggregations on those fields return zero hits, and document inspection tables display the fields as absent, preventing inadvertent privacy or credential violations.

---

5. Built-in Roles vs. Custom Least-Privilege SOC Roles

Useful Built-in Roles

• superuser: Full access to the whole stack. Avoid it for day-to-day analysts.
• kibana_admin: Full access to all Kibana features and spaces. It does not grant access to data indices.
• editor and viewer: All or read access across Kibana features, still requiring index privileges for the data being queried.

Elastic recommends replacing broad roles such as superuser with custom roles that grant only the feature and index privileges each job needs.

Example Least-Privilege SOC Role Matrix

---

6. Security Feature and Index Privilege Mapping