How Coretek consolidated a managed SOC and observability onto one Elastic platform across 50+ client estates

Coretek, the largest Azure cloud solution provider in the United States, consolidated its managed security operations center (SOC) and cloud infrastructure monitoring onto a single Elastic platform. One joint team, sharing a single architect, now runs both practices on a single consumption-based cost model. Consolidating let Coretek standardize client onboarding and share context across security and infrastructure.

Coretek is a managed service provider and the number one Azure cloud solution provider in the United States, delivering managed IT, security, and observability to commercial and public sector clients. Its security and infrastructure teams ran on separate tools with no shared context: a SIEM whose per-ingest cost and 90-day retention no longer fit a managed-service model, and an infrastructure monitor that fired on thresholds without the data to explain them. Coretek consolidated both onto Elastic Cloud on Azure, running its managed SOC on Elastic Security and migrating roughly 50 clients to Elastic Observability in five months, using API-scripted onboarding, centrally managed detection rules, and one shared investigation context. Alert volume fell about 50% (observability, day one) and 70%–80% (security) versus the prior SIEM, and retention went from 90 days to a full year on one platform.

Coretek manages security and cloud infrastructure for a large book of commercial and public sector clients, ingesting event data across network, server, and user activity and generating thousands of alerts a day. In a managed-service business, that volume is not just an engineering problem; it is tedious, time-wasting work: every false positive a junior engineer chases is capacity Coretek cannot bill against higher-value work. The company had been running its security and observability practices on separate tools with separate cost models and no shared context. Its answer was to consolidate both practices, its security operations and its infrastructure/observability teams, onto one Elastic platform, run by a joint platform team that spans the two business units and shares a single Elastic architect. Every alert, from either practice, now lands on one investigation timeline in Kibana instead of in a separate tool per domain. That move meant fewer but more meaningful alerts, shared context across teams, and junior engineers who could assess and escalate faster instead of working through the noise.

Coretek hosts its Elastic deployment on Azure and runs most client estates inside the Azure ecosystem. Elastic entered the picture on the security side about 18 months ago, as clients matured and hit the cost and retention limits of their existing SIEM. As those bills climbed, Coretek needed a better-fitting, lower-cost option to bring to clients, and Elastic became that option.

The turning point was a single client. As Coretek finished onboarding the client's data into the prior SIEM, the monthly bill landed just under $20,000. Coretek ran the same detection coverage across the same data sources on Elastic and brought it to the client for roughly $4,000. That comparison became the internal case for leading with Elastic rather than the incumbent SIEM.

Once security was proven, Coretek's infrastructure team adopted the same platform for observability, replacing the tool it had used for monitoring. The decision was as much about the operating model as the technology: a consumption-based platform that grows with the business instead of a prepaid, add-on-by-add-on model, plus the ability to share resources, best practices, and a single architect across two teams that had previously run their own tooling. A shared team of Elastic and automation architects now works behind both practices, building the shared dashboards, saved searches, investigation guides, knowledge-base articles, and agents that the SOC and NOC both draw on.

On the security side, the prior SIEM's cost scaled unpredictably as ingest grew, and it was especially expensive for non-Microsoft data. Its 90-day retention could not meet the one-year audit-log mandate most clients carry, so clients had to find and pay for a separate retention store. Bringing in a new data source was a multi-day setup effort. For a non-Microsoft source such as a firewall, an engineer often had to build a custom logging configuration profile on the source itself, configure the SIEM to accept those logs in that custom format, and then write specific alerting rules against the new, custom data before it was usable. The practical result was that SIEM cost frequently blew client budgets, and Coretek lost deals on price.

On the observability side, the prior infrastructure monitor reported a resource-utilization threshold breach and little else: a server had crossed 90% memory, say, with no logs or context attached, leaving the engineer to go find out why. The answer was usually in the logs, but the old tool stopped at the threshold, so finding the cause meant leaving the alert and searching elsewhere, in a static table view that required knowing the underlying data schema to query at all. New capabilities tended to arrive as separate purchasable add-ons, and the prepaid resource model did not grow smoothly with the business.

Across both practices, engineers spent their time jumping between consoles and assembling context by hand. Working a single alert routinely meant moving between three and five separate tools, more when a client spanned multiple Azure subscriptions or tenants.

Coretek runs both practices on Elastic Cloud hosted on Azure. Elastic Agent is deployed across client servers for native infrastructure and endpoint telemetry, and Azure logging and event hubs feed into Elastic alongside it. Data lands either in Coretek's multitenant environment or, for clients who want it, in the client's own Azure tenant provisioned through the Azure Marketplace. Detection runs on Coretek's own centrally managed rule set, rolled out across clients through Elastic's APIs and Agent Builder. Investigation and monitoring happen in Kibana, Elastic's investigation workspace, where the network operations center (NOC) and SOC engineers work: each alert arrives with its related context, the logs, metrics, and events around it, on a single timeline, so work starts from evidence rather than a blank search.

The onboarding path is one of the clearest expressions of the whole model. Because most of what is available in the interface is also available as an API call, Coretek scripted client onboarding end to end: an intake form and a single button deploy the Elastic tenant, configure single sign-on, create the initial collection policies from the client's declared data sources, and stand up the Azure event hubs and logging. A new client can go from kickoff call to a functioning SIEM and observability platform in an afternoon.

Rule migration is automated in the same spirit. Automatic Migration translates existing detection rules from Splunk, Microsoft Sentinel, or QRadar into Elastic rules, tagged to the relevant source data and mapped to MITRE ATT&CK, so a screenshot of a legacy rule becomes a managed, code-tracked detection.

Technical highlights

• Isolate every client, keep one view: each client runs in its own dedicated Elastic deployment on Azure, with a central deployment doing cross-cluster search so the SOC and NOC see every client's alerts in one place; capacity purchased as consumption (Elastic Consumption Units)
• Deploy into the client's own tenant when required: client-owned deployments provisioned through the Azure Marketplace
• Collect natively everywhere: Elastic Agent for infrastructure and endpoint telemetry across client servers
• Bring any source online in ~5 minutes: Palo Alto Networks, Fortinet, Oracle, on-prem infrastructure, Citrix, AVD, networking, and custom in-house applications
• Change a detection once, push it across every client: centralized rule rollout scripted through Elastic's APIs
• Migrate legacy detections automatically: Automatic Migration translates Splunk, IBM QRadar, or Microsoft Sentinel rules into Elastic rules mapped to MITRE ATT&CK
• Onboard a client in an afternoon: one scripted API workflow provisions the tenant, SSO, collection policies, and Azure event hubs
• Answer one-year audits in a single query: 365-day on-platform retention, no separate store
• Operate at scale: security ingest spans network, server, and user-activity sources at high volume

A managed SOC on a single back end

Coretek runs its managed SOC on Elastic Security as the SIEM back end for its MSSP services. Consolidating Microsoft and non-Microsoft security data in one place ended the console-hopping that the prior stack forced, where even Microsoft endpoint data lived in a second console the analyst had to search separately. Against a prior SIEM deployment, Coretek reports a 70%–80% reduction in alert volume, built up over a roughly 10–12 month head start on the security side. The drop comes from consolidation rather than from turning detections off: signals that used to fire separately across Microsoft and non-Microsoft consoles now land in one normalized dataset, where duplicate and related events resolve together instead of each raising its own alert. The move to 365-day retention also changed what analysts can answer: a question like whether a given IP address or file hash was seen nine months ago, previously impossible under a 90-day cap, is now a single query on the same platform that holds the audit logs.

Fewer alerts, and the context to act on them

On the observability side, Coretek migrated roughly 50 clients off its prior infrastructure monitor onto Elastic Observability for infrastructure monitoring. Where the old tool reported a breached threshold and stopped, Elastic carries the surrounding data, the logs and metrics around the threshold, that an engineer needs to understand why and get to a root cause. On day one, with minimal tuning, alert volume across those clients fell about 50%, again from bringing every source into one normalized view rather than from suppressing signals, so the same conditions surface as fewer, more meaningful alerts. With thousands of alerts a day, halving the volume lets the NOC focus on what matters. The time it gets back now goes to fixing the root causes of persistent alerts and to projects that benefit clients, rather than working a flood of alerts and treating symptoms. Coretek has begun using AIOps and machine learning, applying anomaly detection to suppress normal cyclical behavior, and is working to push it further to reduce alert noise.

Ingest anything, then act on it

Both alert reductions, on the security and observability sides, rest on the same foundation: the flexibility to bring in any source, normalize it, and treat it like any other data. Built on Elasticsearch, Coretek's platform lets it ingest and act on any source uniformly: Microsoft and Azure, third-party security tools (Palo Alto Networks, Fortinet, Oracle), and clients' own homegrown applications. A new data source that was a multi-day setup effort on the prior SIEM is roughly a five-minute job on Elastic, whatever the source: Coretek points the logs at Elastic over an API, syslog, or OpenTelemetry, and the data arrives normalized to the same schema as every log before it, so existing rules, searches, and dashboards work immediately, with no per-source custom formatting. For a security team whose priorities can change day to day, that flexibility is the difference between protecting what the business actually values and protecting only what the tool made easy.

Investigation starts from context, not a blank search

When an engineer opens an alert, the relevant data is already in one back end and much of it is assembled on the timeline, so the work starts from context rather than from a blank search across separate consoles. In Elastic Timeline, a junior analyst can build the query by dragging, dropping, and filtering fields with the mouse, often without touching the query bar, so getting to an answer is not gated by how well someone knows a query language.

Coretek has already reclaimed real capacity by halving alert volume, and the roadmap builds directly on that result. The team is building on the anomaly detection and machine learning it already runs, and extending Agent Builder, to cut alerts further and move toward auto-remediation. Separately, it is adding application performance monitoring to reach the 60 managed-services clients it is onboarding next and the 200-plus cloud-solution-provider clients beyond them. Coretek is also evaluating Elastic Agent Builder and Elasticsearch for its own AI development. Its stated ambition is to become a leading Microsoft data and AI partner, with Elastic foundational to the visibility, governance, and cost control that AI adoption demands. As Rishad Anwar, architecture and engineering lead at Coretek, puts it, the platform has become the default for anything new the business takes on.

In a managed-service market defined by constant margin pressure, Coretek treats platform economics, flexibility, and modern machine learning and AI capabilities as the competitive edge that keeps it in business and lets it deliver better service to clients. Your organization may not be running a multitenant MSP platform across 50-plus client estates today, but the same principles apply whether you are consolidating your first two tools or scaling to hundreds of client environments: API-driven provisioning, centrally managed rules and configuration, and one shared investigation context.

• Elastic Security
• Elastic SIEM
• Elastic Observability
• Infrastructure monitoring
• Application performance monitoring
• AIOps
• Elasticsearch
• Security Labs

Topics: Managed SOC, MSSP, SIEM, infrastructure monitoring, APM, AIOps, alert reduction, Elastic Security, Elastic Observability, Elasticsearch, Elastic Cloud on Azure, multitenant, log retention, Software & Technology

See how running security and observability on one Elastic platform consolidates your data and cuts alert noise, or start now with a free trial.