Security Telemetry on a Budget

How a growing product team turned the Elastic stack it already had into a practical security telemetry baseline — without buying a full SIEM first.

DISCLAIMER: This is a real engagement from my professional practice and a project that was successfully completed. The client’s name and identifying details are not disclosed due to an NDA and confidentiality obligations.

At the same time, some non-sensitive technical details, engineering decisions, and high-level outcomes can be shared publicly without exposing confidential information. I’ve therefore anonymized the case and generalized a few details where necessary, while preserving the core challenges, approach, implementation, and results.

TL;DR

The company already had cloud infrastructure, Kubernetes, application logs, and an Elastic deployment — but almost no security-oriented visibility. Previous recommendations had focused on expensive commercial platforms and large implementation programs.

Instead, I used the existing stack to build a right-sized security telemetry baseline in roughly three weeks: selected high-value data sources, a small set of prioritized detections, useful dashboards, and a lightweight incident-response workflow that the DevOps team could actually own.

The key lesson: security maturity does not always begin with more tooling. Sometimes the highest-value first step is to make better use of the systems you already operate.

The Problem Was Not “No Tools”

The client was a growing software product company with roughly 70–100 developers and about four years of product development behind it. The environment included desktop and mobile applications, backend services, cloud infrastructure, and Kubernetes workloads.

The engineering organization was not starting from zero. It already had:

• a functioning DevOps process,
• cloud (AWS) and Kubernetes infrastructure (not bare metal),
• application and platform logs,
• and an existing Elastic / ELK deployment used mainly for troubleshooting and operations.

What it did not have was a meaningful security telemetry baseline.

There was no consistent view of failed authentication, suspicious access patterns, Kubernetes warning activity, RBAC changes, unusual container execution, or authentication spikes across services. There was also no simple answer to a very basic operational question:

If something suspicious happens tomorrow, who sees it first — and what happens next?

That gap is common. Teams often have excellent observability for availability and performance, but very limited visibility for security-relevant behavior.

CPU, memory, latency, I\O, cache and restart counts tell you whether systems are healthy. They do not automatically tell you whether someone is repeatedly failing authentication, changing privileges, opening an unexpected shell in a container, or creating a risky access pattern.

The problem was not the absence of data. It was the absence of a security-oriented operating model around that data.

Why “Buy a Bigger Commercial Security Stack” Was the Wrong First Move

The client had already seen proposals built around a familiar pattern: add a commercial SIEM, introduce more security products, pay for professional services, and potentially add headcount to operate the new stack.

That may be appropriate later. It was not the best first move here. The team did not yet need maximum platform capability. It needed usable visibility, clear priorities, and a repeatable response habit.

The first phase therefore focused on five things:

1. a baseline view of high-value security signals;
2. a small, understandable set of alerts;
3. a shared dashboard for engineering and DevOps;
4. lightweight response guidance;
5. clear ownership for triage and escalation.

That is a much smaller scope than “build a SOC,” but it creates something extremely important: momentum.

A mature program can grow from a good baseline. A complicated platform cannot compensate for unclear ownership, poor signal quality, or no response process.

The Strategy: Reuse, Prioritize, Operationalize

My approach was intentionally narrow. Rather than introduce a large new toolchain, I used Elastic as the central visibility layer and focused on the telemetry the company already had — or could enable with minimal friction.

The model was: Reuse what exists → collect what matters → prioritize the signals → make the team operationally ready.

That produced three immediate benefits:

• Lower cost: the company avoided a large first-phase licensing and implementation commitment.
• Faster adoption: engineers worked in a platform they already understood.
• Lower organizational friction: security started to look like engineering support rather than an external control function.

What the Baseline Covered

The goal was not to ingest everything. The goal was to identify the smallest set of signals that could materially improve visibility.

The baseline concentrated on five practical categories:

The point was not that these signals were sufficient for every threat model. The point was that they gave the team useful, explainable visibility immediately.

The Three-Week Engagement

Week 1 — Assess and Baseline

The first week was about understanding the environment and answering one question:
Which signals provide the highest security value with the least implementation overhead?

I reviewed the existing Elastic deployment, the cloud and Kubernetes footprint, available host and application logs, ingress/API logging, and the team’s current troubleshooting habits.

The result was a prioritized telemetry map: what was already available, what was easy to enable, what was noisy, and what was worth postponing.

Week 2 — Enable Telemetry and Dashboards

The second week turned that map into working visibility.

I organized security-relevant events into a small set of operational views that answered questions engineers could act on:

• What changed?
• What failed?
• What looks unusual?
• What needs immediate review?
• What can wait for a scheduled review?

The dashboards were deliberately practical. No “wall of charts.” No vanity metrics. Every view needed to support a decision or an investigation.

Week 3 — Train the Team and Tune the Model

The third week was about turning dashboards into a capability.
I worked with the DevOps engineers on alert interpretation, triage, escalation, expected noise, and the difference between a useful anomaly and a false sense of urgency.

We also introduced a lightweight response loop:

Detect → Triage → Contain → Communicate → Review → Improve

That was intentionally simple. The company did not need a 70-page incident-response manual. It needed a workflow people would actually follow under pressure.

The Minimum Viable Security Signals

One of the most important design choices was not trying to monitor everything. Alert fatigue destroys confidence quickly, especially when security monitoring is new to the team. So we started with a small set of signals that were easy to explain and reasonably actionable:

• repeated failed logins (linux, clourd, etc);
• successful access following repeated failures;
• suspicious privileged-account activity (Linusx. Docker, VM\EC2);
• Kubernetes warning events;
• unusual exec-style activity in containers;
• RBAC changes;
• abnormal 401/403 spikes;
• selected cloud access and configuration changes;
• and security-relevant patterns already present in existing logs.

These were not meant to be the final detection catalog. They were the first dependable layer.

A Simple Priority Model the Team Could Use

The biggest improvement was not a new dashboard. It was a shared understanding of what mattered first.

P1 — Immediate Attention

Examples included suspicious privileged access, risky Kubernetes execution behavior, and critical cloud access changes.

The expectation was simple: review quickly, validate context, and escalate if confirmed.

P2 — Investigate and Validate

Examples included repeated failed logins, RBAC modifications, unusual authentication-error spikes, and warning events that might indicate misuse or instability.

These mattered, but they did not all require an emergency response.

P3 — Watchlist and Tuning

This category covered noisy sources, emerging patterns, and detections that still needed refinement.

That separation prevented two common failure modes: treating everything as critical and ignoring everything because the queue becomes overwhelming.

Before vs. After

The technical change was useful. The operational change was more important. By the end of the engagement, the team had a shared place to review relevant signals, a short list of prioritized detections, clearer ownership, and a response process that matched its actual maturity.

What This Did Not Replace

A lightweight Elastic-based baseline is useful, but it should not be oversold.

!!! It did not magically become: !!!

• a 24/7 SOC;
• a complete endpoint detection (EDR\XDR, SIEM, SOAR) and response platform;
• a replacement for every cloud-native security control (AWS);
• advanced runtime detection for every workload (like Prisma Cloud, etc);
• or a mature enterprise SIEM program with full correlation coverage.

That was never the objective. The objective was to create a credible first layer of visibility and response without forcing the company into enterprise-scale complexity before it was ready.

This distinction is important because practical security is not about pretending a small control solves every problem. It is about knowing what a control does, what it does not do, and what the next sensible step should be.

The Business Value (client's side)

1) Lower Initial Cost

The client did not need to commit to a six-figure security program just to gain basic visibility. Reusing the existing Elastic platform reduced both tool spend and implementation overhead.

2) Faster, More Focused Triage

Relevant signals were easier to find and discuss because engineers no longer had to reconstruct the same context from multiple disconnected sources every time something looked suspicious.

3) Shared Security Ownership

Security became less abstract. DevOps knew what to watch, engineering knew how to interpret the signals, and leadership had a clearer view of what “progress” actually meant.

4) A Foundation for Iteration

The baseline created a sensible path for future improvement: add new data sources, refine detections, reduce noise, integrate more specialized tools, and mature incident handling when the risk and business case justified it.

The Real Outcome: Security Became an Engineering Capability

The most valuable result was not “we installed more security.”

It was that the organization started treating security telemetry as part of normal day-by-day Dev(Sec)Ops activity. The team did not become a SOC overnight, and that was not the goal. It became more aware, more consistent, and better prepared to investigate suspicious behavior.

Final Takeaway

Not every product company needs to begin its security journey with a large commercial platform. A better first question is often: What can we already see — and what can we make actionable — with the systems we own today?

For this team, that question led to a practical baseline, clearer ownership, better response readiness, and a much stronger foundation for future investment. They did not buy maturity overnight.

How Bulwark Advisory Approaches This Kind of Work

This type of engagement sits at the intersection of Product Security, AppSec, DevSecOps, cloud security, and engineering enablement.

The focus is not “deploy as many controls as possible.” It is to identify the smallest useful scope, create evidence quickly, and expand only where the risk and business context justify it.

Typical work can include:

• practical security baselines;
• cloud and Kubernetes visibility;
• lightweight controls for lean product teams;
• telemetry and detection design;
• incident-response operating models;
• and security roadmaps that engineering teams can realistically execute.

If a team already has part of the stack but is struggling to make security visible, actionable, and owned, that is often a very good place to start.

Ivan Piskunov
Founder, Bulwark Advisory
Product Security / AppSec / DevSecOps / Cloud Security