Greg Vedders
  • About
  • Tags
  • Posts

Building a Stable SOC Monitoring Wall with Open Tools

Visualizing your security posture

posts
February 28, 2026 • 5 min read • 856 words

There’s something powerful about walking into a room and seeing the health of your environment at a glance.

Not dashboards buried behind logins.
Not alerts hiding in email.
But a visible, living pulse of your security posture.

I wanted that for our SOC.

This post walks through how I built a four-screen SOC monitoring wall using Ubuntu, Chrome, Splunk, Grafana, and static web pages — without relying on fragile browser extensions or interactive logins.

And most importantly: how I made it stable.


The Setup

We run:

  • Ubuntu Linux desktop
  • GNOME on Wayland
  • Google Chrome
  • 4 physical displays

Screen Layout

  • Screen 1–3: Rotating security dashboards
  • Screen 4: Static system status

The rotating screens display:

  • Splunk alert dashboards
  • Threat intelligence pages
  • Vulnerability summaries
  • Aggregated security metrics

The fourth screen remains static for infrastructure health.


The Problem With Traditional Approaches

If you search for “rotate Chrome tabs,” you’ll find:

  • Old Manifest v2 extensions (now end-of-life)
  • Iframe-based embedding tricks
  • X11 window control hacks
  • Scripts using xdotool or wmctrl

On Wayland, window control tricks don’t work reliably.

Iframe embedding also failed for us because of:

  • X-Frame-Options
  • CSP frame-ancestors restrictions
  • Mixed content enforcement
  • SSL header conflicts

Even when it worked temporarily, it wasn’t stable.

In a SOC, “mostly works” isn’t good enough.


The Key Design Decision: Static Pages With Embedded Splunk Reports

Instead of rotating live Splunk dashboards with authentication sessions, we did this:

  • Create static internal web pages
  • Embed published Splunk reports inside them
  • Remove interactive login dependency

This approach:

  • Eliminates SSO/session expiration issues
  • Avoids browser auth persistence problems
  • Prevents rotation failures due to timeouts
  • Keeps everything read-only

The SOC wall is a projection system — not an interactive console.

That separation matters.


Why We Avoided Iframes for Rotation

We initially tried iframe-based rotation. It was unreliable due to:

  • Security headers
  • Cross-origin restrictions
  • JavaScript timing instability
  • Inconsistent refresh behavior

Even when technically correct, it was operationally fragile.

So we moved to something simpler.


The Most Stable Rotation Method: Full-Page Navigation

Instead of embedding dashboards inside a rotating container, we rotate entire pages at the top level.

No iframe.
No tab switching.
No window manipulation.

Just clean navigation.


The Rotation Page

Each rotating screen loads a single local “rotation controller” page.

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<script>
const pages = [
  "https://soc.local/alerts.html",
  "https://soc.local/threats.html",
  "https://soc.local/vulnerabilities.html"
];

let index = 0;

function rotate() {
  index = (index + 1) % pages.length;
  window.location.href = pages[index];
}

setTimeout(() => {
  window.location.href = pages[0];
  setInterval(rotate, 30000);
}, 100);
</script>
</head>
<body></body>
</html>

This performs a full navigation every 30 seconds.

Why this works

  • No iframe restrictions
  • No cross-origin frame headers
  • Each page fully reloads
  • Dashboards never “stall”
  • No dependency on browser extensions

It’s simple. And simple wins.


Chrome Kiosk Mode

Each screen runs its own Chrome instance:

google-chrome \
  --kiosk \
  --app=https://soc.local/rotate.html \
  --disable-session-crashed-bubble \
  --disable-infobars

Important details

  • --kiosk removes UI
  • --app= removes tabs
  • No user interaction required
  • Clean, full-screen presentation

Each display runs under its own Chrome instance.


Why Not Use a Tab Rotator Extension?

Manifest v2 extensions are gone.

Some Manifest v3 tab rotators still work, but:

  • Extensions break
  • Chrome updates can disrupt behavior
  • Extensions sometimes pause unexpectedly
  • You’re adding complexity you don’t need

For a SOC wall, stability > features.

The fewer moving parts, the better.


GNOME + Wayland Considerations

Because we’re on Wayland:

  • Window control tools like wmctrl don’t work
  • X11-based automation isn’t reliable
  • We avoid window switching entirely

We also disabled power-saving and screen locking:

gsettings set org.gnome.desktop.session idle-delay 0
gsettings set org.gnome.desktop.screensaver lock-enabled false
gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'

This ensures:

  • No screen blanking
  • No lock screen
  • No power interruptions

Hardening the SOC Display System

The display system is intentionally locked down:

  • Dedicated socdisplay user
  • No sudo access
  • Restricted VLAN
  • Read-only access to dashboards
  • No interactive Splunk privileges
  • Static pages only accessible internally

This is a projection surface, not a control surface.

That distinction reduces risk significantly.


The Four-Screen Philosophy

Each screen serves a purpose.

Screen 1 — Critical Alerts

High-severity only. Big numbers. Red when needed.

Screen 2 — Trends

Failed logins, endpoint detections, firewall anomalies.

Screen 3 — External Context

Threat intel, vulnerability exposure, risk posture.

Screen 4 — Infrastructure Health

System up/down health, load, bandwidth

The static health screen prevents alert fatigue by anchoring the room.


Lessons Learned

A few things became obvious during this build:

  • Tables are unreadable from 10 feet away.
  • Fewer dashboards rotating slowly is better than many rotating quickly.
  • Reloading on every cycle prevents stale views.
  • Removing authentication dependencies dramatically improves uptime.
  • Stability matters more than cleverness.

The best SOC wall is boring and reliable.


What I’d Improve Next

Future ideas:

  • Alert-severity-based rotation speed
  • Automatic “critical alert takeover” screen
  • Background color changes based on alert state
  • Monitoring the display system itself
  • systemd supervision for Chrome processes

There’s always room to refine.


Final Thoughts

This isn’t a flashy digital signage setup.

It’s intentionally simple.

No browser tab gymnastics.
No fragile window scripts.
No session juggling.

Just static pages, embedded reports, full-page rotation, and Chrome in kiosk mode.

And it works.

If you’re building a SOC monitoring wall, start with this principle:

Make it visible.
Make it read-only.
Make it stable.

Everything else is secondary.

Share this post
← Older Exposing Services Safely with Cloudflared Tunnels Newer → 10 Lessons from 10 Years in Higher Ed IT Security

About

Greg Vedders writes about information security, troubleshooting, photography, and the occasional unexpected fix.

Recent Posts

  • Automating CatPosters.us With a Gemini and WordPress Bot
  • Teaching Git: What I Covered in Class
  • Introducing Signage Suite — Self-Hosted Wall Displays in PHP
  • Rebuilding gregvedders.com Without a Hugo Theme
  • Hardening a Public Honeypot Server

Tags

Security SOC Linux Monitoring

Related Posts

  • 10 Lessons from 10 Years in Higher Ed IT Security
  • Exposing Services Safely with Cloudflared Tunnels
  • Advanced Splunk Techniques for Beginners
  • Searching for Threats in Firewall Logs Using Splunk
© Greg Vedders 2026