13.1 Kibana Spaces for SOC Multitenancy & Segmentation

In enterprise Security Operations Centers (SOCs) and Managed Security Service Provider (MSSP) environments, a single monolithic monitoring interface quickly becomes unmanageable. Tier 1 triage analysts require streamlined, queue-oriented dashboards; threat hunters need exploratory query interfaces and ad-hoc timelines; internal audit and compliance teams require restricted read-only reporting; and MSSPs must maintain strict separation between customer organizations. Kibana Spaces provide the architectural foundation for multi-tenancy and operational segmentation within the Elastic Stack, allowing administrators to partition saved objects, configure customized application navigation, and establish operational boundaries within a single shared Kibana deployment.

---

1. Presentation-Layer Isolation vs. Elasticsearch Data-Layer Security

A foundational concept tested on the Elastic Certified SIEM Analyst exam is the strict boundary between Kibana Spaces and Elasticsearch Index Security:

• Kibana Spaces operate exclusively at the presentation and saved object layer. A space logically segments Kibana saved objects: Dashboards, Visualizations, Canvas workpads, Maps, Data Views (index patterns), Timelines, Timeline Templates, Detection Rules, Alert Views, and Cases. Spaces also control which Kibana applications appear in the navigation menu.
• Kibana Spaces do NOT restrict Elasticsearch index access. A user who is granted access to a specific space is not automatically restricted to any specific Elasticsearch index or data stream. If a user's assigned Elasticsearch role grants read privileges on logs-*, that user can execute queries across all matching documents via Discover, Lens, or the Console, regardless of which space they occupy.

$\text{True SecOps Multi-Tenancy} = \text{Kibana Spaces (Presentation)} + \text{Elasticsearch RBAC / DLS / FLS (Data)}$

To achieve true, auditable multi-tenancy, administrators must couple Kibana Spaces with Elasticsearch Role-Based Access Control (RBAC), Document-Level Security (DLS) (such as filtering documents by tenant.id or organization.id), and Field-Level Security (FLS) (redacting sensitive PII or credentials).

---

2. Space Routing, URL Architecture, and Space Mechanics

Every Kibana space possesses a unique, URL-safe identifier that dynamically prefixes browser routing:

• Default Space: The baseline space built into every Elastic Stack deployment has the fixed identifier default. Its URL does not include a space prefix (e.g., https://kibana.internal.net:5601/app/security). The default space cannot be deleted. Users see only the spaces their roles grant; there is no automatic fallback into the default space.
• Custom Spaces: Created by administrators via Stack Management > Spaces or the Spaces REST API. Custom spaces modify the URL path with the /s/<space_id>/ prefix. For example, a dedicated threat hunting space with the identifier threat-hunting routes to https://kibana.internal.net:5601/s/threat-hunting/app/security.

Space Identifiers and Rules

1. Immutability: The space identifier (space_id) is defined upon creation and cannot be modified. It must consist exclusively of lowercase alphanumeric characters, underscores, and hyphens.
2. Feature Control: When creating or editing a space, administrators can selectively disable entire Kibana applications (e.g., hiding Dev Tools, Machine Learning, or Stack Management). In a dedicated Tier 1 SOC space, disabling Dev Tools and Management declutters the navigation menu, enforces standard triage workflows, and minimizes human error.
3. Landing Page Customization: Each space can specify a custom initial landing page (e.g., routing directly to /app/security/alerts rather than the default Kibana home page).

---

3. Saved Object Lifecycles: Export, Import, and Conflict Resolution

SecOps workflows frequently require migrating detection rules, custom dashboards, and Data Views between development, staging, and production environments, or between tenant spaces. This is managed through the Saved Objects management interface or the Saved Objects API.

Exporting Saved Objects

Dashboards, visualizations, data views and other saved objects are exported as newline-delimited JSON (.ndjson) files via Stack Management > Saved Objects or the Saved Objects API:

POST /s/soc-staging/api/saved_objects/_export
Content-Type: application/json

{
  "type": ["dashboard", "visualization", "index-pattern"],
  "includeReferencesDeep": true
}

The includeReferencesDeep: true flag guarantees that all dependent objects—such as the data views and visualizations referenced by dashboard panels—are recursively packaged into the NDJSON payload.

Detection rules are handled separately. Export and import them from the Security app's Rules page (or the Detection Engine _export and _import APIs). Rule exports include the rules' exceptions, and imports match existing rules by rule_id. The import dialog offers Overwrite existing detection rules with conflicting "rule_id" and Overwrite existing exception lists (the overwrite and overwrite_exceptions API parameters). Importing rules with actions also needs Actions and Connectors privileges.

Importing Saved Objects and Conflict Resolution

When importing saved objects into a destination space (POST /s/<space_id>/api/saved_objects/_import), existing objects may share the same internal UUID. Administrators must select an explicit conflict resolution strategy:

1. overwrite: true: Overwrites any existing saved object in the target space that has a matching ID. This is standard when pushing updated rule definitions or dashboard revisions from a staging space into production.
2. createNewCopies: true: Generates brand-new UUIDs for colliding objects, preserving both the original object and the imported copy. References between imported objects are automatically updated to target the newly generated UUIDs.
3. Fail on Conflict (Default): Halts the import process and reports colliding objects, allowing the engineer to resolve conflicts on an individual object basis.

Cross-Space Saved Object Sharing

Rather than maintaining duplicate copies across spaces, Kibana supports Share to spaces for shareable saved-object types, such as data views. A shared object keeps one ID, and changes made in one space appear in every space it is shared with. Not every type is shareable. For those that are not, Copy to spaces creates an independent copy in the target space.

---

4. Detection Engine Rules and Alert Scoping Across Spaces

In Elastic Security, the Detection Engine operates within the scope of the active Kibana space:

• Space-Scoped Rules: Detection rules are Kibana saved objects that belong to the space in which they were created. Staging spaces can test experimental EQL or threshold rules without executing them against production triage queues.
• Prebuilt Rule Installation: When an administrator enables Elastic prebuilt detection rules, they are installed into the currently active space. Installing prebuilt rules in /s/soc-triage/ does not automatically activate them in /s/client-alpha/.
• Alert Segregation: When a detection rule fires, the resulting alert document records the space ID in which the rule executed. In the Elastic Security Alerts table (/s/<space_id>/app/security/alerts), analysts only observe alerts generated within that specific space. Cross-space alert aggregation requires building an executive dashboard in a parent space that queries the underlying .alerts-security.alerts* indices directly.
• Timelines and Cases: Like detection rules, Cases and Timelines are partitioned by space. An insider-threat investigation initiated in a restricted /s/executive-investigations/ space remains completely invisible to analysts working in the standard /s/soc-triage/ space.

---

5. Architectural Comparison: Single-Space vs. Multi-Space SOC Models