OpenSearch Security Analytics as a SIEM: when a self-hosted team should consider it
OpenSearch Security Analytics brings detectors, Sigma-based rules, log type mappings and correlations onto an OpenSearch cluster that your team operates, so log-driven detection can run in infrastructure you control without a per-seat SIEM subscription. The OpenSearch project is released under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe a paid edition, so the software license is not a budget line. Your spend moves to compute, storage, backups and the engineers who run the cluster. OpenSearch is a fork of Elasticsearch 7.10, and OpenSearch Dashboards derives from Kibana 7.10.2, so staff with Elastic experience will recognize much of the operating model. Before you plan around any detector, rule or correlation, confirm its behavior, rule coverage and correlation options in the Security Analytics documentation for the exact OpenSearch version you intend to run, because these features change between releases.
This path suits a team that meets three conditions. It already operates, or can staff, a search cluster with clear ownership. It can forward the log sources that detections depend on, including identity, endpoint and network data. It also has people who can read, tune and version detection logic in their own repositories. Sigma is a vendor-neutral rule format, so rule content written for another platform can often be reviewed and adapted here, though converted rules need testing against your own fields. Compare the alternatives on the same terms. Elastic Security's detection engine is listed under Platinum on the self-managed subscriptions page, a tier no longer sold to new customers, so new self-managed buyers of paid security features choose Enterprise or Elastic Cloud. Wazuh is distributed under the GNU General Public License version 2 and ships its own indexer, server and dashboard with prebuilt compliance views, which may suit a team that wants agents and rules delivered together.
Expect ongoing work after go-live. Security Analytics runs on the same cluster as your other indexes, so you own sizing, shard layout, retention, backups, patching and access control. The OpenSearch Security plugin provides role-based access control, document-level and field-level security, field masking, audit logs and TLS for node and client traffic. It can authenticate analysts through SAML, OpenID Connect, LDAP or Active Directory, Kerberos or JSON Web Tokens. Configure these controls before analysts see security data. The release cadence also shapes staffing. OpenSearch targets a new minor version about every eight weeks, and a version in maintenance receives bug fixes and security patches but no new features. If a detector capability you need appears only in a later minor release, your upgrade plan determines when you can use it.
Use a bounded proof of concept to test the decision before committing. Choose a small set of log sources, such as a firewall, an identity provider and one server group, and map them to the log types your target version supports. Import a sample of rules and record how many run unchanged, how many need field changes and which need a different approach. Test correlations at the peak event volume you expect, and measure detection latency and the false positive rate your analysts see during the trial. Ask your implementation partner or your own team to document each result against the exact OpenSearch version. Those notes will show which findings still hold after the next upgrade and which need retesting.
Which self-hosted SIEM stack fits your team: OpenSearch, Wazuh or Elastic Security
This table compares OpenSearch Security Analytics with Wazuh and Elastic Security on licensing, bundled agents and detection content, compliance views, and the paid tiers that apply to self-managed buyers. Treat each row as a question to confirm with the vendor, because packaging and feature sets change between releases. The main takeaway is that Elastic Security's paid features require Enterprise or Elastic Cloud for new self-managed buyers, while the OpenSearch and Wazuh paid terms for your deployment should be confirmed directly.
| Capability | OpenSearch Security Analytics | Wazuh | Elastic Security |
|---|---|---|---|
| License | Apache License 2.0 across the OpenSearch project | GPL version 2 with an OpenSSL linking exception | Elastic License 2.0 by default for Elasticsearch and Kibana, plus SSPL or AGPLv3 options |
| Paid tiers for self-managed buyers | The OpenSearch FAQ describes no paid edition; confirm support options with your provider | Confirm with Wazuh which features and support terms apply to self-managed deployments | Free Basic tier; Platinum closed to new buyers; Enterprise or Elastic Cloud for paid security features |
| Agents and collection | Confirm which collectors and log sources the current release supports for your environment | Agents on Linux, Windows, macOS, Solaris, AIX and HP-UX, plus agentless syslog and API collection | Elastic Agent collects logs, metrics and security data, managed centrally through Fleet |
| Endpoint protection | Confirm whether you need endpoint protection beyond log collection | Agent-based endpoint monitoring with vulnerability detection from collected software inventory | Elastic Defend adds EDR; malware and ransomware prevention and host isolation sit under Enterprise |
| Detection content | Detectors, Sigma rules, log type mappings and correlations; confirm the bundled rule set for your release | Decoders and rules on the Wazuh server; vulnerability data from the CTI platform or an offline repository | Prebuilt rules delivered automatically from the detection-rules repository, plus custom, threshold and indicator match rules |
| Compliance views | Confirm which framework dashboards ship with the current release | Prebuilt dashboards for PCI DSS, GDPR, HIPAA and NIST 800-53 | Confirm framework coverage in the current Elastic Security documentation |
| Investigation workflow | Confirm case and investigation features in your release | Confirm case handling and investigation features for your version | Timeline investigations; case management and ML anomaly detection are listed under Platinum |
| Single sign-on | SAML, OpenID Connect, Active Directory, LDAP, Kerberos and JWT authentication backends | Single sign-on is documented; confirm supported protocols for your version | SAML and OpenID Connect are listed under Enterprise |
How Security Analytics turns log data into detections and alerts
In OpenSearch Security Analytics, a detection moves through four steps: log sources send events to the cluster, each event is mapped to a log type, detectors apply rules to the mapped events, and each match produces a finding that an analyst reviews in the dashboard. Each step can fail quietly, so the team should understand all four before it enables a single detector. Most gaps in a self-hosted SIEM come from a missing or incorrect field mapping, not from a missing rule.
The first step is ingestion. Firewalls, endpoints, identity providers and applications send events to the cluster through shippers that your team chooses and operates. Each log type has a mapping that tells Security Analytics which field holds the source address, the user, the action and the outcome. Before you rely on a log type, take sample events from each source and confirm that the fields land under the names that log type expects. A rule that references a field the events never populate will not fire, and the dashboard will show nothing to indicate that the rule missed events.
Detectors bind to one or more log types and evaluate a set of rules against incoming events. Security Analytics supports Sigma-format rules in some versions, which lets teams reuse community detection content, but the supported rule formats, the bundled rule library and the fields each rule expects vary by version. Treat imported rules as drafts. Review each one against your event fields, disable those that cannot match your data, and log each change so the team can explain why a detection behaves as it does during an incident review.
A match creates a finding, and the finding is what analysts see and act on in the dashboard. Plan who triages findings, how they are assigned and how long they are kept. Role-based access in the OpenSearch Security plugin controls which users can view findings and which can change detectors, so separate the analyst role from the administrator role from the start. High finding volume usually points to rules that need tuning rather than more analysts, so track which detectors produce findings that are closed without action.
Correlation links findings across log types, so that a failed login in an identity log, an unusual process in an endpoint log and an outbound connection in a firewall log can be grouped into one investigation. The rule formats, the mapping library and the correlation syntax all depend on the OpenSearch version you run, and they change between releases. Before you build any detection, confirm the current syntax and supported features in the Security Analytics documentation for your version, then prove each detection in a non-production cluster using events from your own sources.
Setting up Security Analytics in a test cluster before production
This sequence builds a single test cluster with the Security plugin, authentication, roles and one monitored log source, then proves that known events produce the alerts you expect. Run it in a non-production environment that mirrors your production authentication and network paths. Menu paths and API calls change between releases, so check each one against the documentation for the version you deploy.
Choose an installation method and start the cluster
Your platform team picks one of the methods OpenSearch documents: Docker, Helm, the OpenSearch Kubernetes Operator, tarball, RPM, Debian packages, the Ansible playbook or Windows. Choose the method your team already operates, because it governs how upgrades and configuration changes are handled later. Deploy a small test cluster with the node roles you plan to use in production, including dedicated cluster manager nodes if your design calls for them. Done when the cluster reports a healthy status, every node joins, and the reported version matches the release you intend to run.
Enable the Security plugin with TLS
A platform engineer enables the Security plugin and configures TLS for node-to-node and client traffic, using certificates issued by your internal certificate authority. Confirm the certificate chain, hostname verification and the file locations for keys and trust stores against the security documentation for your version. Done when an unauthenticated request to the HTTP endpoint is refused and a connection presenting valid credentials or a trusted client certificate succeeds. Record the TLS settings in your configuration repository so that the test and production builds match.
Connect an authentication backend
Connect the backend your workforce already uses, such as SAML, OpenID Connect, Active Directory, LDAP, Kerberos or JSON Web Token. The identity team owns the directory side, while the platform team maps directory groups to OpenSearch roles. Test with a named analyst account and a named administrator account rather than a shared login. Done when both accounts sign in through the backend, group membership maps to the expected roles, and a test account removed from its group no longer receives that role at the next login. Confirm the exact mapping settings in the docs for your version.
Define analyst and administrator roles
Create roles that separate detection work from cluster administration. Analysts need to read alerts, view detectors and search the indices for the log source, but they should be unable to change cluster settings, security configuration or index mappings. Administrators hold the broader permissions needed to manage the Security Analytics plugin and the security configuration. Map each role to backend groups and to the index patterns for the log source you will onboard. Done when a test analyst can open alerts but cannot change security settings, and a test administrator can create a detector. Verify permission names against the role documentation for your release.
Onboard one log source
Select one source with well-understood events, such as a single Linux authentication log or one firewall feed, and send it to the test cluster through your existing collector. Keep the first source narrow so that any failure is easy to trace. Confirm the index name, the timestamp field and the ingest path, and check that volume and retention settings suit a test environment. Done when events from the source land in the expected index and every document carries the fields that your intended rules will match on.
Create a log type mapping and load rules
Create a log type mapping that tells Security Analytics which fields hold the event attributes that rules reference, such as user, source address, process name and outcome. Then import a small set of Sigma rules that match the events in your source and create a detector that uses them. Keep the first rule set to a handful of rules so that any mapping gap is obvious. Done when the detector runs without field errors, and any rule that references fields missing from your source is either shown as unmapped or removed and documented.
Replay test events and confirm expected alerts
Replay a set of known test events, such as recorded or synthetic events that you have labeled as malicious or benign, into the test index. Compare the alerts that fire with the labels: each malicious event should produce the alert its rule defines, and benign events should not. Investigate every gap, whether it is a missed detection caused by a mapping error or an unexpected alert from a broad rule. Done when the expected alerts appear, the counts and rule names match your labeled set, and the tuning changes needed before production are written down. Repeat the replay after any mapping or rule change.
Running a SIEM cluster in production: node roles, availability and upgrades
A SIEM cluster should be laid out so that losing one node does not stop log ingestion, search or detection. OpenSearch clusters use cluster manager, data, ingest and coordinating node roles, and the cluster documentation recommends dedicated cluster manager nodes so that cluster state management is not competing with indexing and searching. For a Security Analytics deployment, size data nodes and ingest nodes separately. Ingest work (parsing and enriching events before they are indexed) and data work (indexing, storage and the queries that detectors run) load the hardware in different ways, so one shared node type is hard to tune. Decide the node count for each role from your own event volume and retention, then test that layout against a representative log load before go-live.
Availability depends on where shards and replicas sit. Configure replicas so that a primary shard and its copies are placed on separate nodes, and enable shard allocation awareness so that copies are spread across the failure domains you actually have, such as racks, hypervisors or availability zones. The documentation describes these settings as the basis for availability, but the right attribute values depend on your physical or cloud topology, which only your infrastructure team can map. Confirm with your platform team which failure domains exist, how many nodes each one holds, and what happens to detector queries if one domain is down. Then rehearse a node or domain outage in a non-production cluster and record how long ingestion and alerting take to recover.
OpenSearch releases a new minor version about every eight weeks. The OpenSearch releases page lists 3.8.0 on August 4, 2026 and 3.9.0 on September 29, 2026 as examples of that cadence. A minor version in maintenance receives bug fixes and security patches but no new features, so a cluster on a supported line can take fixes without changing how detections behave. Versions stay in maintenance until the next major version enters maintenance or one year passes, whichever is longer. Put the upgrade cadence into your operating calendar, decide how far behind the latest minor release you are willing to run, and track the end-of-life dates on the releases page so the plan is set before a version drops out of maintenance.
OpenSearch documents four upgrade and migration methods: rolling upgrades, snapshot and restore, remote reindexing and Migration Assistant. Rolling upgrades change nodes in place while the cluster keeps serving requests, which suits minor moves within a supported path. Snapshot and restore builds a new cluster from a snapshot taken before the change, and remote reindexing copies data from an older cluster into a new one. Migration Assistant can move workloads across several major versions in one step, for example from Elasticsearch 6.8 to OpenSearch 2.19, and supports live traffic capture for low or zero downtime. Choose the method from your current version, the gap to the target version, and how much downtime your SOC can accept. Confirm the supported path for your exact versions in the migration documentation before you commit.
Upgrading the cluster is only half of the change. Confirm from the Security Analytics and OpenSearch release notes which fixes land in each release you plan to use, since a patch can alter how a rule, log type mapping or correlation behaves. Then plan a test upgrade of the detections as well as the cluster. In a staging environment built from a recent snapshot, load your Sigma-based detectors, log type mappings and correlations, replay a sample of production logs, and compare the alerts produced before and after the change. Keep the rule versions and mapping files under version control so that a regression can be traced and rolled back. Treat a passing cluster health check as the start of verification, not the end of it.
Securing the SIEM itself: access, audit trail and evidence integrity
Detectors, alerts and rules are only as trustworthy as the cluster that holds them. Access, audit and transport controls in OpenSearch Security decide who can change detection content, who can read sensitive events and whether the team can later prove what happened. The cards below cover those controls and the checks to run before the SIEM handles production events.
Role-based access control
Define roles for SIEM engineers, detection authors, triage analysts and read-only auditors, and map each role to specific index patterns, Security Analytics objects and cluster actions. Keep detector and rule editing in a different role from alert review, so tuning a detection and dismissing its alerts require separate grants. Confirm with test users which Security Analytics objects, such as detectors, rules and log type mappings, respond to index-level and cluster-level permissions.
Document, field-level security and masking
Document-level security limits which events a role can return, for example only events from the business units a team supports. Field-level security hides chosen fields, and field masking shows an obscured value so analysts can correlate a user or address without seeing the full identifier. Test each role with sample queries, because a permitted search on a broad index pattern can still expose fields that dashboards and saved queries were meant to hide.
Limit user impersonation
Impersonation lets one identity act as another, which helps with role testing and service integrations but becomes a risk when granted broadly. Grant it only to named administrators or specific service accounts, limit which target users can be impersonated, and review those grants on a schedule. Confirm how impersonated sessions appear in audit output, so activity performed as another user can be traced back to the operator who started it.
Audit logs stored outside the cluster
Enable the audit log categories that cover authentication, failed access and changes to security configuration, then send the records to a target that the SIEM cluster's administrators cannot quietly edit. Audit records kept only inside the cluster they describe can be altered by anyone who gains admin rights on it. Use a separate log store or write-once storage with its own access control, and confirm retention against your evidence and legal requirements.
TLS on every hop
Encrypt node-to-node transport, client connections to the cluster and dashboard access, and assign owners for certificate issuance, renewal and revocation. Agents, syslog collectors and log shippers should also use encrypted channels where the sender supports them. Confirm each ingest path during testing, because one plaintext collector can expose attacker-relevant events in transit even when the cluster itself is locked down.
Admin accounts, access paths and backups
A SIEM stores records of what attackers did, which makes it a target. Apply production-grade controls to admin accounts, bastion or VPN paths, CI/CD pipelines and dashboard access, including multi-factor authentication, named accounts and logged sessions. Snapshot repositories hold full event data, so restrict who can register or restore them and encrypt the storage they write to. Include these paths in access reviews and in your incident response plan.
Trade-offs of running detection on a general-purpose search cluster
The main trade-off is that a search cluster gives your team control over where security data is stored, how long it is kept and which license terms apply, while the operating work that a purpose-built product often handles for you moves to your team. In OpenSearch, Security Analytics detectors, Sigma rules and log type mappings run on top of the cluster, so their reliability depends on index lifecycle, shard sizing, node roles and upgrades being planned as carefully as the detections themselves. The Security plugin's role-based access control, field-level security and audit logs also need deliberate design, so analysts can work alerts without gaining read access to every index.
Four responsibilities move to your team. The first is capacity planning: as log sources are added, ingest volume, alert storage and detection query load all grow, and the cluster has to keep pace. The second is detection content maintenance: you choose, tune and retire rules and log type mappings when log formats change, and you confirm which rule sets your release supports. The third is alert triage, where someone decides which alerts become cases and how known false positives are suppressed. The fourth is on-call, because a failed node, a full disk or a stalled indexer becomes your incident. The cluster documentation recommends dedicated cluster manager nodes, replicas on separate nodes and shard allocation awareness, and each of these needs building and testing before go-live.
Two shapes are worth comparing. A purpose-built agent-and-detection product bundles collection, detection content and dashboards. Wazuh, for example, combines endpoint agents, a server that decodes and analyzes agent data, an indexer that stores alerts and a dashboard, and it is distributed under the GNU General Public License version 2. Elastic Security pairs Elastic Agent, managed through Fleet, with prebuilt detection rules that are delivered to the detection engine automatically, although its paid detection and endpoint features sit in subscription tiers. Assembling OpenSearch with log shippers, Security Analytics content and your own runbooks gives you more choice in each component, but the integration work, testing and ownership of the glue are yours. Endpoint coverage is a separate question: confirm whether your required sources need agent-based collection, and if they do, plan how you will source and operate those agents.
OpenSearch is a strong fit when your team already operates search clusters well, when data residency rules require storage in named locations, or when the network is air-gapped and a hosted SIEM cannot be reached. The Apache License 2.0 covers OpenSearch software, and the project FAQ does not describe a paid edition, which helps procurement teams separate license terms from operating cost. A managed or bundled SIEM may be the better match when no one on staff wants to be paged for the search layer, when detection engineering capacity is thin, when endpoint response must be in the same product from the first day, or when a vendor's support commitments matter more to your auditors than control over the stack. Neither option is cheaper by default, so compare them against the same written scope.
Before comparing options, write the scope in one document: log sources and their owners, ingest volume per source, retention period by log type, the detections you need in the first release, who triages alerts, who is on call and what compliance evidence you must produce. Ask each bundled vendor to price licenses against that same scope, including the tiers that unlock the features you need. Ask DeployOpen for a fixed-scope quote from the same document, and make sure it separates one-time work such as architecture, build, content mapping and testing from recurring work such as upgrades, rule maintenance, capacity reviews and retainer support. Cost comparisons built on different scopes tend to measure different things.
Limits to confirm for your environment before you commit
Security Analytics capabilities vary by OpenSearch version, log source and rule set, so treat each item below as a check to run in your own environment. DeployOpen does not issue vendor certifications, and the OpenSearch documentation for your chosen version governs how each feature behaves.
Feature set and correlation depth
Confirm which Security Analytics features, including detectors, correlation rules and alerting integrations, ship in the OpenSearch version you plan to run. Then test how far correlation reaches: whether rules can join events across log types, entities and time windows your use cases need. Record the maximum number of sources and window size each detection requires, and mark each capability as shipped, partial or missing before the architecture is approved.
Ready-made and custom log mappings
Check which of your log sources already have Security Analytics log type mappings and which need custom mappings, field normalization or parser work. Firewalls, identity providers, cloud audit trails and in-house applications often differ widely in coverage, so match your source inventory against the supported list. Budget effort for each custom source, because every mapping must be written, tested and maintained after upgrades.
Sigma rule import fidelity
Import a representative sample of your Sigma rule set into a test cluster and record which rules load, which fail and which load with changed logic. Modifiers, field names and logsource definitions may not map cleanly to your log types. Count the rules that need rewriting before you estimate detection content effort, and keep the original Sigma source under version control.
Event volume and retention sizing
Measure sustained events per second, peak bursts and average event size for each source, then size storage, memory and node count for your retention period on the hardware you control. Hot and archive tiers change both cost and query speed, and replica settings add stored copies. Run a load test with your full rule set enabled, because detection queries consume capacity alongside ingestion.
Vendor support and SLA holders
Ask whether any vendor support or service-level commitment covers the OpenSearch packages, the Security Analytics features and the detection content you depend on, and who signs it. Support from the open-source project, a commercial distributor and a systems integrator are separate arrangements with separate terms. Obtain written terms, response targets and an escalation path before you commit. DeployOpen's ongoing support and retainers are scoped separately and described in writing.
Detection content updates and testing
Define who pulls new Sigma rules and Security Analytics content, how each change is tested against sample logs, and who approves it before it reaches production. Confirm whether updates arrive from the vendor, a public rule repository or your own pipeline, and whether each release is versioned. Plan a rollback path, because a faulty rule update can flood the queue with alerts or silence a detection without an obvious error.
Questions teams ask before hiring help to run OpenSearch as a SIEM
What drives the cost of running OpenSearch as a SIEM?
Cost follows scope. The OpenSearch project is licensed under Apache License 2.0, and its FAQ does not describe a paid edition, so most of your spend goes to people and infrastructure. The main drivers are the number of log sources, the custom log type mappings each source needs, the detection content you must write and tune, and the high availability and retention design, which sets how many nodes and how much storage you run. Access integration with your identity provider adds design and testing work. Staffing for alert triage is often the largest recurring line. When you request a quote, ask for each log source listed separately, the mapping work per source type, the number of detection rules and tuning cycles, the node and storage sizing assumptions, and who performs triage and during which hours.
How long does it take to set up OpenSearch Security Analytics?
The duration depends on the same inputs that set cost, and no fixed figure applies until the scope is written. Setup time grows with the number of log sources, how many need custom mappings, how many detectors and Sigma rules must go live at the start, and whether the cluster must be highly available from the first day. Access integration adds time when the identity provider owner or your security team must approve configuration. Test events are a common delay, because each source needs sample events so detectors can be verified. Approvals for network paths, storage and retention can run in parallel with build work or become the critical path. Ask the partner for a phased plan that separates a first production source from the full source list, the dates each phase depends on from your side, and the acceptance tests that close each phase.
What must our team provide before an implementation partner starts?
Plan to provide four things: infrastructure, identity access, people and sample data. Infrastructure means cloud accounts, virtual machines, Kubernetes capacity or data center hosts, plus network paths from each log source to the cluster. Identity access means administrative access or a named contact for your identity provider, so the OpenSearch Security plugin can connect through the authentication backend you use, such as SAML, OpenID Connect, Active Directory, LDAP, Kerberos or JSON Web Token. People means owners for each log source who can confirm formats and change windows, and analysts who will review rules and triage alerts. Test events means representative samples from each source, including suspicious activity your team can generate safely, so detections can be checked. Ask for a written responsibility matrix that names each client-side task, its owner and its due point, because missing inputs are a common source of delay.
Can an internal team run OpenSearch SIEM without outside help?
Yes, an internal team can build and operate it if it has the skills for the work, and the software itself is open source under Apache License 2.0. The skills needed span several areas: OpenSearch cluster administration (node roles, shard allocation, snapshots), Security plugin configuration (roles, document and field-level security, audit logs, TLS), log pipeline engineering for each source, including parsing and mapping, detection engineering with Sigma rules and correlation, and security operations for triage. Check whether you have capacity in each area and whether one person is covering several. A practical test is whether the team can restore a snapshot, rotate certificates and tune a detector without outside help. Also plan for upgrades, since the project targets a new minor version about every eight weeks and each upgrade needs a test and patch cycle.
How does the OpenSearch upgrade cadence affect ongoing work?
The project targets a new minor version about every eight weeks, so your team needs a recurring cycle to evaluate and apply updates. Each version stays under maintenance until the next major version enters maintenance or one year passes, whichever is longer. During maintenance, a version receives bug fixes and security patches but no new features, so you can plan around patch intervals, while feature changes arrive only in newer versions. Version 1 reached end of life on May 6, 2025, and version 2 is maintained through the 4.0 GA release, so confirm the support window of your target line before you commit. The documented upgrade methods are rolling upgrades, snapshot and restore, remote reindexing and Migration Assistant. Ask the partner for the test environment, the rollback plan, the upgrade method they will use, and whether mappings and detection content are retested after each upgrade.
Should we choose a fixed-scope project or a retainer for SIEM work?
Choose a fixed-scope engagement for a defined build, such as an agreed set of log sources, mappings and detection content, with deliverables and timelines confirmed in writing before work starts. Choose a retainer for work that continues, such as ongoing support, upgrades and continuous testing. Many organizations combine the two: a fixed-scope build to reach production, then a retainer for patching, upgrades and tuning. The two differ in how cost behaves. A fixed-scope project carries a one-time cost tied to the agreed deliverables, while a retainer recurs. Changes to a fixed scope, such as adding log sources after kickoff, need a written change request. Ask for the deliverables, acceptance criteria, exclusions, how changes are priced, and which upgrade and response work the retainer covers. DeployOpen does not publish a price list, so the quote follows from the written scope.
Which identity integrations matter for OpenSearch SIEM access?
The choice follows your identity provider and how analysts sign in. The OpenSearch Security plugin supports SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token authentication backends. Map identity groups to OpenSearch roles so that analyst, reviewer and administrator access are separate. Use document-level and field-level security, along with field masking, to limit access to sensitive fields. Keep audit logs enabled to record access, and use TLS for node and client traffic. Log shippers should use dedicated service accounts with narrow write permissions rather than shared user accounts. Check the group claim format from your provider, confirm that multi-factor authentication is enforced at the provider, and test a login for each role before go-live. Confirm the exact settings against the Security plugin documentation for your version.
Who reviews detection rules and triages alerts after go-live?
Your security operations team should own triage decisions, and a detection engineer, internal or from a partner, should own rule quality. Write the split down before go-live. Rule review needs analysts who understand the normal behavior of each log source, because a detector that fires too often produces alert fatigue, and a detector that never fires may simply never have been tested against your data. Triage staffing is often the largest recurring cost, so base the estimate on alert volume measured during testing rather than on assumptions. Ask who approves a new Sigma rule, who tunes thresholds, how false positives are recorded, who is on call for the cluster itself, and how cluster health alerts reach a person. Sigma rules give you a starting point, but each rule still needs testing against your own logs before anyone trusts its alerts.
How DeployOpen scopes, builds and supports a self-hosted SIEM
DeployOpen plans, builds and supports OpenSearch Security Analytics as a self-hosted SIEM in infrastructure you control. Each engagement starts with a written scope covering log sources, detection content and access design, so the platform is sized and governed before the first detector is enabled. We do not publish a price list, so a quote follows from that written scope.
How we scope
- The written scope lists log sources, log type mappings, detector coverage and the retention period for each index.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build work starts.
- Confirm the scope covers Sigma rule import, correlation logic and the Security plugin roles each analyst team needs.
How we build
- Cluster layout follows the OpenSearch docs: dedicated cluster manager nodes, replicas on separate nodes and shard allocation awareness.
- Authentication connects to your SAML, OpenID Connect, Active Directory or LDAP source through the Security plugin.
- Detectors, Sigma rules and correlations are tested against replayed sample events before they reach production alerting.
How we hand over
- Documentation covers the architecture, role model, detector inventory and steps your team follows to add a log source.
- Runbooks cover backup and snapshot restores, OpenSearch upgrade steps and alert triage ownership for your analysts.
- Compliance evidence covers access roles, audit log settings and TLS configuration, which auditors then assess independently.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades are planned against OpenSearch's release schedule, since maintained versions receive security patches but no new features.
- Security testing of the SIEM and its detection content can be scheduled alongside the retainer.
