DEV Community: Bulwark Advisory

Security Telemetry on a Budget: Building a Practical Elastic Baseline for a Growing Product Team

Ivan Piskunov — Sun, 20 Sep 2026 22:00:00 +0000

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:

a baseline view of high-value security signals;
a small, understandable set of alerts;
a shared dashboard for engineering and DevOps;
lightweight response guidance;
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:

Area	Examples of useful signals
Identity & access	repeated failed logins, privileged access changes, account-related events
Kubernetes & infrastructure	warning events, suspicious exec activity, RBAC changes
Applications & ingress	401/403 spikes, authentication anomalies, unusual access patterns
Host / system activity	selected process and system events useful for investigation
Cloud activity	selected access, identity, and configuration changes

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

Before	After
Logs existed, but security context was fragmented	A shared security-oriented view in Elastic
No clear alert priority	P1 / P2 / P3 operating model
No lightweight response path	A simple triage and escalation workflow
Security recommendations centered on new products	Existing stack reused first
Visibility depended on individual troubleshooting	Repeatable dashboards and review habits

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

Bulwark Advisory: From Hands-On Security Work to a Focused Product Security Practice

Ivan Piskunov — Sat, 12 Sep 2026 12:34:33 +0000

Introduction

For years, I had already been doing many of the things people associate with running a consulting practice. I wrote technical and commercial proposals, scoped projects, discussed pricing, negotiated contracts, performed security assessments, worked directly with customers, and sometimes delivered the actual work behind another company's brand.

I just did not have a company name for all of it. Around 2017, I was already experimenting with promoting my own cybersecurity services through professional communities and social platforms in Russia. Later, I worked independently, registered as self-employed in Moscow, performed contract work for other companies, and helped build and sell cybersecurity services inside established businesses.

So when I eventually created Bulwark Advisory, I did not wake up one morning and suddenly decide to become a cybersecurity entrepreneur. By that point, most of the underlying work had already happened. The company came last.

A Business Built After the Experience, Not Before It

I have already written about the longer version of my career story, from my first years in cybersecurity to hands-on engineering, offensive security, leadership, research, consulting, and entrepreneurship.

Bulwark Advisory is not a break from those stories. It is one of the consequences of them. For a long time, my professional identity was simply my name: Ivan Piskunov. My articles, research, GitHub projects, conference work, consulting, teaching, security reviews, and public materials all existed under that name. That worked well for years.

But over time, the work itself became broader than a personal profile page could explain in a few lines. There was a clear pattern in what I was doing, the kind of problems I was best at solving, and the kind of clients I wanted to help. At some point, I needed a professional home for that work.

I Had Already Been Learning the Commercial Side for Years

One thing I learned fairly early is that technical expertise alone does not create a consulting business.

You can be excellent technically and still be terrible at turning that expertise into a service another company can understand, buy, and use. Over the years, I had to learn the other side of professional work too.

I prepared proposals. I discussed budgets. I estimated effort. I negotiated contracts. I had to explain what the client was paying for and what result they should expect. I had to define scope clearly enough that both sides understood where the project started and where it ended. I also learned how different selling a security service is from actually delivering it.

A proposal can sound impressive and still lead to a useless project. A report can contain hundreds of findings and still fail to help the people responsible for the product. A consultant can be technically correct and still create more confusion than value.

That changed how I think about consulting.
The client does not need the longest report.
The client does not need the largest number of findings.
The client does not need more security theater.
The client needs a useful outcome.

Sometimes that means a clear architecture decision. Sometimes it means a prioritized remediation plan. Sometimes it means putting security controls into CI/CD. Sometimes it means helping leadership understand which risks actually matter. Sometimes it means telling a company that something does not need to become an urgent security project at all. That kind of judgment only comes from combining technical depth with experience, context, and business understanding.

Product Security as the Focus

I have worked across different areas of cybersecurity during my career. I came through technical work. I spent time in offensive security. I worked with systems, application security, DevSecOps, cloud environments, architecture, security engineering, leadership, and program development.

All of those areas influenced the way I work today. But I do not believe that having experience in many parts of cybersecurity means I should sell every cybersecurity service that exists. I do not want Bulwark Advisory to become another company that claims to do everything from penetration testing and forensics to SOC operations, awareness training, compliance, incident response, cloud security, and twenty other unrelated services.

That is not the kind of company I want to build. My strongest focus today is Product Security. To me, Product Security is the place where security, software engineering, architecture, cloud, DevSecOps, automation, and business risk meet.

It is not simply application scanning. It is not just penetration testing. It is not a checklist before release. It is the broader question of how software is designed, built, tested, released, and operated in a way that reduces risk without making engineering slower than it needs to be.

That philosophy is very close to how I think about Product Security. My offensive background still matters. It helps me look at architecture, trust boundaries, attack paths, and assumptions differently. But the purpose of my work today is not to prove that something can be broken. The purpose is to help companies build products that are harder to break in the first place.

From Personal Expertise to a Company Structure

Bulwark Advisory is intentionally founder-led. I stay involved in discovery, technical analysis, architecture, prioritization, workshops, delivery, and recommendations. I did not create the company so that my name could disappear from the work. I created it so that the work could have a clearer structure.

That distinction matters to me. The company gives clients one place where they can understand what I do, what I do not do, what kind of problems I work on, and how I think about security. But the responsibility is still personal. If I put my name behind an assessment, a recommendation, or a security program, I need to be comfortable defending it technically and professionally.

The Kind of Consulting Business I Want to Build

My principles are simpler.

Be clear about the scope.
Be transparent about the commercial terms.
Keep bureaucracy as low as possible.
Do not invent urgency.
Do not sell work that is not necessary.
Stay technically serious.
Communicate directly.
Finish the job.

And if the client needs help again later, be there. I value long-term professional relationships, but I do not believe long-term relationships should be created through dependency. They should be created through trust. If a client comes back six months later because the previous engagement was useful, that is the kind of repeat business I want.

The Commercial Part Is Not Something I Hide

I also do not want to create a romantic story in which money somehow does not matter. Bulwark Advisory is a commercial business.

I want it to make money. I have never believed that useful professional work becomes less honorable because someone pays for it.

Expertise has value. Time has value. Good judgment has value. Years spent learning from failures, projects, mistakes, incidents, architecture decisions, audits, research, and leadership have value too.

The important question is not whether a business makes money. The important question is how it makes money.

I do not want growth to depend on selling unnecessary tools, creating fear, inflating project scope, or convincing every client that they need every cybersecurity service imaginable. I would rather solve real problems and charge fairly for solving them. That is a much simpler business model. It is also the one I can respect.

Proof in Public

Publishing what I learn has been part of my professional life for years. I did it before Bulwark existed, and I intend to keep doing it.

Over time, I have written articles, shared technical notes, published research, created guides, built repositories, and documented practical security work because I believe useful knowledge becomes more valuable when other people can learn from it.

One of the clearest examples is my Product Security Knowledge Base.

It contains material on Product Security programs, Secure SDLC, threat modeling, application security, DevSecOps, cloud, Kubernetes, software supply chain security, security automation, metrics, leadership, and other areas I work with regularly. The same principle now applies to Bulwark Advisory on GitHub, where I publish practical material around Product Security engineering and program development. There is also Bulwark Advisory on DEV Community, where I continue publishing technical and professional material under the company brand.

If I say that I know how to build a Product Security program, people should be able to see how I think about one. If I talk about DevSecOps, CI/CD security, cloud security, or engineering practices, there should be something more substantial behind those words than a service description. A potential client should be able to read the material, review the repositories, look at the methodology, and decide whether the way I think makes sense for their organization. That is a much better starting point for a professional relationship than a generic sales pitch.

The Next Chapter

I spent a large part of my career learning how security works. Then I had to learn how engineering works, how organizations work, how clients make decisions, how services are sold, how contracts are negotiated, how risk is explained, and how professional reputation is built over time.

Bulwark Advisory is where those experiences finally meet.

I do not know exactly what size the practice will become or what it will look like ten years from now. That is part of the journey. What I do know is what I want it to stand for: technically serious work, honest communication, clear commercial terms, useful results, and security that helps good products become better products.

I want to continue working directly with technology.
I want to continue publishing what I learn.
I want to help engineering teams build security into products without turning security into unnecessary bureaucracy.
I want clients to understand exactly what they are paying for.
And yes, I want to build a healthy commercial business around expertise I spent many years developing.

After more than fifteen years in cybersecurity, this does not feel like starting another career. It feels like finally putting my own name on the door.