# Dhiraj Sharan

Dhiraj Sharan writes about SIEM architecture and security data. Their work traces how security systems have struggled to keep up with growing, scattered data, and explains a Security Data Mesh approach that searches data where it already lives.

- Profile: https://b2binfluencer.marketing/creators/dhiraj-sharan/
- LinkedIn: https://www.linkedin.com/in/dhirajsharan
- LinkedIn followers: 5,033
- Based on 9 dated posts, latest 2026-10-07

## Summary

Most useful for explaining a Security Data Mesh and federated search approach to security analytics practitioners.

- Best for: Technical thought leadership or data-mesh product campaigns aimed at SOC architects and security data engineers.
- Not for: It does not fit centralization campaigns for CISOs or vendors competing with Query's product-led Security Data Mesh message.
- Check first: Confirm audience demographics and engagement data before contacting them.

### Takeaways

- Every attempt to centralize security data eventually loses to the data.
- Describe the data instead of moving it.
- The SIEM should be an analytics brain, not a repository.

## Main ideas

- **Every attempt to centralize security data eventually loses to the data**: Sharan argues that security teams keep rebuilding SIEMs to pull data into one place, and each generation fails for the same reason: data outgrows the architecture. The pattern emerges from a career that began as an ArcSight engineer in May 2001: a single box fed by a handful of important sources; clustering and a move from SQL to NoSQL columnar storage as the number of sources exploded; tighter pipelines that filtered out noisy events, fields and raw data in exchange for scale; batching and aggregation instead of live streaming; and, finally, a security data lake beside the SIEM. Their conclusion is blunt: centralizing security data for analytics becomes a costly, impractical, unscalable losing move every time.
- **Describe the data instead of moving it**: Sharan’s proposed alternative is to stop relocating data and start describing it. A federation layer added to the security stack creates metadata for each source—its location, content, schema and the APIs needed to reach it—makes the data discoverable and addressable, connects and joins relevant pieces, and returns results in one unified data model. Storage, indexing, retention and scaling are decided per source rather than billed as one block for everything. Sharan attributes the architecture to Query, calls it a Security Data Mesh, and says it has been built and refined over the last five years.
- **The SIEM should be an analytics brain, not a repository**: If the data stays where it lives, Sharan argues, the SIEM does not need to own it. Its role shifts from storage to analysis: it becomes the analytics layer that knows what data exists, where it is and how to reach it, then queries it on demand. This explains why the Security Data Mesh is framed as an addition to the security stack rather than a replacement for existing tools.
- **Federated search should match how analysts think about their sources**: The product writing shows the same idea in daily use. The core claim is that a Splunk environment is only as powerful as the data it can reach, and that most enterprises leave security data in lakes, object storage, EDR platforms, identity providers and cloud audit logs because ingestion costs are not justified. The Query app connects to those sources and makes them searchable and detectable from inside the Splunk console without moving the data—“centralize the knowledge, not the data.” The 3.0 release added a security-investigation copilot, natural-language search across federated sources without writing SPL, follow-up questions about results, such as whether something is malicious and which MITRE techniques apply, analytics across distributed stores, and OCSF-normalized results. The 3.1 release addresses a practical irritation: with dozens or hundreds of connected sources, recalling exact connector names adds overhead. Analysts can assign short aliases and group connectors with tags such as #edr, #identity and #env/prod, mix tags, aliases and names in one search, and exclude specific sources.
- **Ending posts with a question to peers, not a conclusion**: Both architecture posts close by asking readers about their experience. The retrospective asks anyone who has re-platformed a SIEM more than once what drove the work and how it is going; the follow-up invites readers to agree or disagree and says Sharan would love to learn from their experiences. The posts present the argument as open to correction by practitioners who have done the same work.

## Work to read

- [Twenty-five years of rebuilding SIEM—and the problem that kept beating it](https://www.linkedin.com/posts/dhirajsharan_siem-cybersecurity-data-activity-7487943275614470145-p18p)
- [The Security Data Mesh, stated plainly](https://www.linkedin.com/posts/dhirajsharan_siem-cybersecurity-data-activity-7503798489705820160-xXZ1)
- [What the architecture looks like as shipped software: Query Splunk App 3.1](https://www.linkedin.com/posts/dhirajsharan_edr-identity-env-activity-7473059958981414912-gEwo)

## Brand relationships

- **Query** (disclosed_partnership)
- **ArcSight** (employment)
- **Splunk** (mention)

## Partnerships

Dhiraj Sharan's posts do not describe a sponsorship program or provide a media kit, rate card, sponsored-format description, disclosure, or official partnership inquiry page. They do show product-led publishing: posts explain Query's Security Data Mesh architecture and announce the Query Splunk App 3.1 release. The realistic collaboration route is a vendor or co-marketing conversation about Query's security data products, rather than a paid creator placement. Buyers can expect architecture-level technical content for SOC, security-engineering, and security-data audiences. Ask the vendor directly about terms, pricing, and approval process.

## Alternatives

- Marcel Dybalski: Dybalski is the better choice when a campaign needs to teach a data-platform architecture argument to a mixed audience of data and analytics leaders before security specifics matter. The reviewed post lays out seven layers of a data platform: source systems, ingestion, storage, processing and orchestration, curation and transformation, serving and distribution, and experience and consumption. It also covers vertical concerns such as access control, data classification, lineage, pipeline cost, CI/CD and monitoring. The post argues that buying a storage layer such as Databricks, Snowflake or BigQuery does not create a platform, and that tools are roughly 20% of the equation, with strategy, architecture and execution making up the rest. For a security analytics vendor whose product story depends on reaching distributed data without moving it, that layered framing offers a vendor-neutral way to show why federation and per-source retention belong in the architecture. Choose Dybalski over Sharan when data leaders need the platform layers explained before engaging with security telemetry, or when the campaign must avoid naming a competing SIEM or data-lake product.
- Okan YILDIZ: YILDIZ is the better choice when a campaign needs hands-on practitioner enablement rather than an architecture thesis. The posts are a Microsoft Sentinel zero-to-SOC home lab walkthrough and a pentest report field manual. The lab moves from an Azure subscription and a Log Analytics workspace through Sentinel enablement, Windows security logs, KQL, failed-login hunting with Event ID 4625, analytics rules, triggered incidents, investigation, automation rules and playbooks. The pentest post argues that a report should show how compromise actually happens: scope, attack path, evidence, root cause, remediation and retest, including which tester actions the SOC should have detected. Both are structured as step-by-step teaching, with questions for the reader. For a security analytics vendor targeting SOC analysts and detection engineers, YILDIZ can carry a build-it, detect-it, investigate-it campaign that an architecture post cannot. Choose YILDIZ over Sharan when the deliverable is a lab, a detection walkthrough or a report-review checklist, or when the audience is analysts who adopt tooling by using it rather than reading strategy.
- Steve Faruque: Faruque is the better choice when the campaign angle is AI-era threat detection rather than security data architecture. The posts cover AI-native attacks: indirect prompt injection against Salesforce Agentforce, the ForcedLeak example, agentic intrusions, AI-accelerated zero-days, and a detection and guardrail stack ranging from delimiter spotlighting and security code review to Lakera Guard, Azure Prompt Shields, behavioral anomaly detection, output filters and monthly automated red teaming against the OWASP LLM Top 10. They also include panel and event promotion with a free-invite call to action. For a security analytics vendor positioning its data layer as the foundation for detecting AI-native threats, Faruque supplies the threat narrative and detection use case. Choose Faruque over Sharan when the campaign is about AI security, prompt injection or detection engineering for AI systems, or needs a current, high-urgency threat topic to anchor the product's value.

---
AI-assisted summary of public posts. Audience demographics are not available. Engagement appears only where we checked recent posts. Method: https://b2binfluencer.marketing/methodology/