7.1 Security Dashboard Architecture & SOC Layout Design

The Central Role of Dashboards in Modern SecOps

In an enterprise Security Operations Center (SOC), security analysts are confronted with millions of telemetry events every hour. Raw event logs ingested from endpoints, network perimeters, cloud infrastructure, and identity providers cannot provide immediate situational awareness when viewed in isolation. Kibana Dashboards serve as the operational bridge between petabyte-scale data lakes and decisive analyst action. A well-architected dashboard transforms disparate Elastic Common Schema (ECS) events into actionable threat intelligence, enabling rapid detection, triage, and incident containment.

However, building effective security dashboards requires more than simply dragging and dropping charts onto a canvas. Poorly designed dashboards induce cognitive fatigue, obscure critical indicators of compromise (IOCs), and can degrade Elasticsearch cluster performance by launching unoptimized aggregations across hundreds of shards simultaneously. Professional SIEM analysts must understand how to structure dashboards architecturally, matching visual complexity and query depth to specific operational roles and cognitive workflows.

---

The Three-Tier Security Dashboard Hierarchy

Enterprise security operations operate across distinct organizational layers, each requiring different levels of telemetry aggregation, refresh frequencies, and analytical depth. Attempting to create a single "do-it-all" dashboard inevitably fails both executives and front-line analysts. Modern SOC architecture establishes a three-tier dashboard hierarchy.

+-------------------------------------------------------------+
|                 Tier 3: Executive / CISO                    |
|     Strategic Posture, MTTD/MTTR Trends, Compliance SLAs    |
+-------------------------------------------------------------+
                               ^
                               |
+-------------------------------------------------------------+
|                 Tier 2: SOC Operational Triage              |
|      Real-Time Queue Health, Alert Velocity, Severity Mix   |
+-------------------------------------------------------------+
                               ^
                               |
+-------------------------------------------------------------+
|                 Tier 1: Threat Hunting & Forensics          |
|   Sub-second Pivoting, Rare Event Outliers, Deep Telemetry  |
+-------------------------------------------------------------+

1. Executive and CISO Strategic Overviews

Executive dashboards synthesize long-term security posture, risk trends, and operational efficiency for leadership (CISO, CIO, Risk Committee). Rather than tracking individual events, these views display macro-level key performance indicators (KPIs):

• Mean Time to Detect (MTTD) and Mean Time to Remediate (MTTR) measured over 30, 90, or 365 days.
• Detection Rule Efficacy: Total alerts generated versus confirmed true-positive incidents.
• Enterprise Risk and Compliance Posture: Asset vulnerability exposure, unpatched critical CVEs, and compliance drift against frameworks such as CIS Controls, NIST CSF, or PCI-DSS.
• Resource Allocation Metrics: Volume of incidents handled per analyst shift and automation containment rates.

Executive dashboards utilize broad time horizons ([now-30d TO now]), low visual density (typically 6 to 10 high-level metrics and area charts), and manual or infrequent refresh intervals (e.g., daily or weekly). Panels can query transform-built summary indices or downsampled data rather than high-cardinality raw telemetry.

2. Tier 1 & Tier 2 SOC Operational Triage Dashboards

Operational triage dashboards are the 24/7 workhorses of the SOC. Displayed on analyst dual monitors or central SOC video walls, these dashboards provide real-time situational awareness across the active threat landscape:

• Alert Velocity and Severity Distribution: Active critical, high, medium, and low security alerts grouped by status (open, in-progress, closed).
• Entity Risk Surges: Top high-risk hosts (host.name) and high-risk users (user.name) flagged by Elastic Security risk scoring engines.
• Ingestion Pipeline Health: Document ingestion rates across critical data streams (logs-endpoint.events.*, logs-firewall.*, logs-authentication.*) to rapidly detect sensor outages or telemetry gaps.
• Triage Queues: Live tables displaying unassigned alerts awaiting Tier 1 disposition.

Operational dashboards target short, rolling time windows ([now-24h TO now] or [now-1h TO now]), high data density, and automatic refresh cycles (typically 30 seconds to 2 minutes).

3. Specialized Threat Hunting & Forensic Deep-Dive Dashboards

Threat hunting dashboards are domain-specific investigation workbenches designed for Tier 2/Tier 3 analysts and incident responders. Rather than providing broad overviews, they focus deeply on specific attack vectors or telemetry families:

• Active Directory & Kerberos Anomaly Hunting: Tracking Kerberos ticket requests (Event IDs 4768, 4769), AS-REP roasting indicators, Golden Ticket anomalies, and DCSync replication calls.
• Cloud Infrastructure & Identity Exploitation: Monitoring AWS CloudTrail, Azure Activity Logs, or Google Cloud Audit Logs for anomalous AssumeRole calls, privilege escalations, and persistence mechanisms.
• Network Command and Control (C2) Beaconing: Evaluating jitter algorithms, uncommon outbound destination ports, long-duration connections, and anomalous DNS query entropy.

These dashboards feature extensive interactive controls, high-cardinality data tables, raw document previews, and deep integration with Elastic Security Timelines.

---

Dashboard Architecture Comparison

The following table contrasts the technical and architectural specifications across the three tiers of the security dashboard hierarchy:

---

Cognitive Ergonomics and Visual Layout Engineering

Cognitive ergonomics examines how visual information presentation affects human cognitive load, situational awareness, and decision-making speed. In a high-stress SOC environment where alert fatigue can lead to missed breaches, dashboard visual hierarchy is a critical defensive control.

The F-Pattern Visual Hierarchy

Eye-tracking studies demonstrate that operators process computer displays in an "F-pattern" (scanning horizontally across the top, down the left side, across a secondary horizontal band, and down to the lower quadrant). SOC dashboards should leverage this cognitive pattern through a structured three-band layout:

1. Top Banner (Executive KPI Row): Single-metric counters displaying mission-critical state indicators across the top 15% of the screen. An analyst glancing at the dashboard should instantly know if an emergency exists without scrolling. Examples include: Unassigned Critical Alerts, Active Severity 1 Incidents, High-Risk Hosts, and Total Blocked C2 Connections.
2. Middle Band (Trendlines & Categorical Breakdowns): Visualizations answering "When did it change?" and "Where is it coming from?". This layer contains time-series histograms (alert volume over time stacked by severity), categorical donuts or bar charts (top 10 targeted host operating systems, top MITRE ATT&CK tactics observed), and geographic maps (inbound network threats by source country).
3. Lower Quadrant (Granular Telemetry & Contextual Workbenches): Detailed, paginated data tables displaying individual ECS events, enriched alert details, or entity investigation lists. Analysts drill down into this band only after identifying an anomaly in the upper layers.

+--------------------------------------------------------------------------+
| [ KPI: Critical Alerts ] [ KPI: Active Incidents ] [ KPI: High-Risk Hosts ]|
+--------------------------------------------------------------------------+
|  Alert Severity Over Time (Histogram)   | Top ATT&CK Techniques (Bar Chart) |
|  [========== Layered Area ==========]   | [===============================] |
+--------------------------------------------------------------------------+
|  Interactive Telemetry Triage Table (ECS: @timestamp, host, user, rule)    |
|  | 14:02:11 | srv-app01 | admin_svc | Suspicious PowerShell Execution |   |
|  | 14:01:45 | wks-dev09 | jsmith    | Multi-Factor Authentication Bypass | |
+--------------------------------------------------------------------------+

Panel Sizing and Grid Alignment

Kibana dashboards use a 48-column grid, and panels snap to it as you drag and resize them. SecOps dashboard designers should keep consistent alignments:

• Metric Panels: roughly 8 to 12 columns wide and short. Avoid oversized single-value metrics that waste valuable screen real estate.
• Histograms and Time-Series Panels: half to full width (24 to 48 columns). Time-series require sufficient horizontal width to distinguish temporal clusters.
• Data Tables: full width (48 columns) and tall enough for a page of rows. Tables require full horizontal width to accommodate essential ECS columns (@timestamp, event.dataset, source.ip, destination.ip, kibana.alert.rule.name) without aggressive text truncation.

---

Mitigating Cluster Query Storms and Shard Overhead

A critical responsibility of the SIEM analyst is ensuring that dashboard designs do not destabilize the underlying Elasticsearch cluster. A single dashboard panel represents at least one distinct Elasticsearch query. If a dashboard contains 25 panels, opening or refreshing that dashboard fires 25 concurrent queries against the cluster.

The Shard Multi-Search Execution Mechanism

When an analyst loads a dashboard, each panel issues its own search requests through Kibana's search service. In Elasticsearch, each search fans out to the shards backing the target data view or index pattern (shards whose time range cannot match can be skipped):

$\text{Total Shard Tasks} = \text{Panels} \times \text{Indices Searched} \times \text{Shards per Index}$

Consider an enterprise cluster where logs-* spans 30 daily indices, each with 2 primary shards (60 shards total). A dashboard with 20 panels querying logs-* triggers:

$20 \text{ panels} \times 60 \text{ shards} = 1,200 \text{ individual shard search tasks}$

If 15 SOC analysts keep this dashboard open with a 30-second auto-refresh enabled, the cluster must process:

$\frac{15 \times 1,200 \text{ tasks}}{30 \text{ seconds}} = 600 \text{ shard executions per second}$

This query storm saturates the Elasticsearch search thread pool, causes task queue rejections (HTTP 429), spikes node CPU utilization to 100%, and starves real-time ingestion pipelines and detection rules.

Architectural Remediation Strategies

To prevent dashboard-induced cluster exhaustion, implement the following best practices:

1. Cap Panel Density: Restrict operational dashboards to 12–16 panels. Remove redundant visualizations that do not drive immediate operational decisions.
2. Optimize Data Views: Target specific data streams (e.g., logs-endpoint.events.*) rather than broad wildcards (* or logs-*). Searching across unnecessary metric or audit indices wastes shard execution cycles.
3. Consolidate Multi-Layer Visualizations: Use Kibana Lens multi-layer capabilities to combine related metrics (e.g., total network bytes and dropped packet counts) into a single dual-axis panel rather than creating two separate panels.
4. Enforce Reasonable Refresh Limits: Standardize operational dashboards on 1-minute to 5-minute auto-refresh intervals. Sub-minute refreshes should be reserved exclusively for mission-critical video walls displaying pre-aggregated alert indices (.alerts-security.alerts-*).
5. Leverage Summary or Downsampled Indices: For long-term trend panels (e.g., 90-day alert patterns), query transform-built summary indices or downsampled time-series data instead of raw event streams. (Rollup jobs are deprecated in 8.x in favor of downsampling.)

---

Operational Markdown Panels: Embedding SOPs and Escalation Playbooks

Dashboards should not merely display data; they should guide analyst action. Kibana Markdown panels allow dashboard engineers to embed contextual text, checklists, and hyperlinks directly within the operational layout.

In a Tier 1 triage dashboard, placing a markdown panel in the upper corner or directly above the unassigned alert queue provides immediate operational guidance:

• Triage Decision Trees: Step-by-step criteria for distinguishing benign false positives (e.g., authorized vulnerability scanners) from true malicious activity.
• Contact Matrices & Shift Rosters: Direct contact information for the Incident Response Commander, On-Call Security Engineer, and Network Operations Center (NOC).
• Playbook Hyperlinks: Direct links to internal wiki documentation, runbooks, and ticketing templates in Jira or ServiceNow.
• Escalation SLAs: Strict operational timeframes (e.g., "Critical Alerts must be triaged within 15 minutes; High Alerts within 60 minutes").

### Tier 1 Incident Triage Checklist
1. **Verify Asset Classification**: Check if `host.name` is tagged as `PCI-Scope` or `Domain-Controller`.
2. **Correlate Identity**: Search `user.name` in Active Directory for recent role or department changes.
3. **Check Network Baseline**: Verify if `destination.ip` matches known corporate CDN infrastructure.
4. **Escalation**: If malicious execution is confirmed, click the **Create Case** button in the alert table.
   - *SOC Escalation Hotline*: `ext. 4433` | *On-Call Lead*: `pager-secops@corp.internal`

---

Panel Cloning, By-Value Embedding, and Saved Object Linking

When constructing dashboards, analysts must choose how visualization panels are stored and linked within the Kibana object database. Kibana supports two distinct operational panel modes:

1. By-Reference Panels (Saved Object Library)

A by-reference panel points to a centralized visualization saved object stored in the .kibana index. If the visualization is modified in the Lens library (e.g., altering a color palette, adding a breakdown dimension, or updating an aggregation formula), that change is automatically reflected across every dashboard referencing that saved object.

• Pros: Enforces enterprise visualization consistency; updates propagate instantly across all SOC dashboards.
• Cons: An accidental edit made for one specific dashboard can break or alter visualizations on dozens of other operational views.

2. By-Value Panels (Dashboard-Embedded Panels)

A by-value panel embeds the visualization definition directly into the dashboard's saved object JSON structure. The panel does not exist as an independent entity in the Kibana visualization library.

• Pros: Complete isolation. An analyst can clone a panel, modify formulas, add filters, or alter field mappings for a specialized investigation without risking changes to standard production dashboards.
• Cons: Does not receive centralized updates. If a field name changes in the underlying schema, each by-value panel must be updated individually.

Operational Workflow Recommendation

For standardized SOC operational environments, maintain core enterprise visualizations (e.g., standard alert queues, executive posture charts) as By-Reference library objects. When an analyst requires a customized variant for a specific threat hunting campaign, they should clone the panel as By-Value, allowing ad-hoc experimentation without polluting the centralized library.