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
xdotoolorwmctrl
On Wayland, window control tricks don’t work reliably.
Iframe embedding also failed for us because of:
X-Frame-Options- CSP
frame-ancestorsrestrictions - 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-infobarsImportant details
--kioskremoves 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
wmctrldon’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
socdisplayuser - 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.