Securonix Guide: Running Threat Content, UEBA and Data Ingestion Well

A Securonix deployment only detects what it ingests, scores and tunes, so the value comes from how the customer runs data ingestion, threat content and behaviour analytics, not from the licence alone. Securonix describes its Unified Defense SIEM as combining SIEM, UEBA and SOAR on a cloud data platform, with threat content delivered as a service by its Threat Labs team. This guide explains how those parts fit together and what to set up, tune and measure: the data pipeline, the violation to threat model to incident chain, content updates, behaviour baselines and peer groups, and the accounts that integrate with the platform. It is written for SOC leads, detection engineers and platform owners running or onboarding a Securonix tenant.

This is an independent guide from NHI Mgmt Group, based on Securonix's public documentation as of November 2026. It is not sponsored or reviewed by Securonix. Product features change, so confirm settings against Securonix's current documentation.

Key takeaways

• Detections are layered. Policies raise violations, threat models chain and weight violations into higher-fidelity threats, and analysts work the resulting incidents; tune at the layer where the noise starts.
• Ingestion quality decides analytics quality. UEBA baselines and peer analysis need clean identity attributes (division, department, job and manager) and consistent user and asset keys across sources.
• Content arrives continuously and is opt in. Content Manager pushes new and updated connectors, parsers, policies and threat models outside platform upgrades; test them in a sandbox before production.
• Retroactive sweeps close the gap for new threats. Autonomous Threat Sweeper searches historical data for newly defined threats that fresh content alone would only catch going forward.
• Integration accounts are privileged identities. API access uses dedicated accounts with the ROLE_API role; give each integration its own account, store its credentials as secrets and review them like administrators.

How the platform fits together

Securonix public material names a small set of building blocks. Knowing which one owns a problem saves time when a detection is missing or noisy.

For the general architecture of a SIEM programme see the SIEM Guide.

Data ingestion

Securonix describes the Hub as deployable in the cloud or on premises, built on containers and infrastructure as code, with automated upgrades. According to Securonix, a single Hub scales vertically to 80,000 events per second per data source, and more nodes can be added for totals beyond 2 million events per second. Customers and partners can view each Hub's status, cumulative events per second and CPU, memory and disk use without opening a support case.

Ingestion priorities

1. Identity sources first: load the HR or directory feed that supplies the user attributes peer analysis relies on (division, department, job key and manager title appear in Securonix peer analysis views). Without them, peer groups are guesses.
2. Authentication and access: identity provider, VPN, privileged access and cloud control plane logs feed most insider and account compromise threat models.
3. Endpoint, email and network: Securonix lists network, storage, cloud infrastructure, EDR, identity and email threats among its content coverage areas; onboard the sources that match the content you plan to enable.
4. Business applications: data access logs from file shares, SaaS and databases support data exfiltration and IP theft use cases.

Ingestion checks

• Hub health: watch events per second and resource metrics per Hub, and alert when a Hub or source goes quiet.
• Parser coverage: confirm key fields (user, host, source IP, action, outcome) are populated for each source before enabling policies that depend on them.
• Identity correlation: check that account names in logs resolve to identities, including service accounts, so behaviour is attributed correctly.
• Response path: because the Hub also carries SOAR response actions back to devices, treat its network access and credentials as part of the response control plane.

Pipeline design questions that apply to any platform are covered in the Security Data Pipeline Guide.

Threat content: policies, threat models and updates

Securonix content is layered. Partner documentation describes threat models built from observed policy violations, with each threat event given a weighted score, which makes threat events higher fidelity than individual violations. The API exposes the same layers: violations (top violations by policy name and ID), threats (top threats by threat model), violators and their risk score and history, incidents with their contributing policies, watchlists, peer groups, resource groups and policy lists.

Content delivery

• Threat Labs and the Content Library: Securonix Threat Labs validates intelligence from community, third-party and in-house research before adding content to the library, where tenants can select and deploy it.
• Content Manager: introduced in the Jupiter 6.4 release, it shows new and updated connectors, parsers, policies, threat models, reports and dashboards as they are produced. Updates are pushed and customers opt in; content is not tied to core platform upgrades.
• Sandbox first: Content Manager supports testing new content in a sandbox before moving it to production. Use it for every policy and threat model change, including vendor updates.
• Coverage tracking: Content Manager and the Threat Coverage Analyzer assess coverage against MITRE ATT&CK; use that view to choose which gaps to close next, weighted by which sources you actually ingest.
• MSSP tenants: content deployments can be customised per tenant, so record which tenant runs which version.

Treat custom policies as code: name an owner, describe the hypothesis, keep test cases, and review changes. See the Detection Engineering Guide and the Detection as Code Guide.

UEBA: baselines, peers and risk

Securonix UEBA compares activity with individual baselines and peer-group norms, flagging rare activity, unusual access, volume spikes, suspicious sequences, privilege misuse and risky tool use. Its datasheet shows behaviour analysis, event rarity analysis and peer analysis views, threat chain models mapped to MITRE ATT&CK and US-CERT, packaged use cases for insider threat, IP theft and fraud, and watchlists for high-risk users. Its more recent material extends behaviour analytics to AI agents: agent actions, API calls, tool use, permissions and sensitive data interactions.

• Design peer groups deliberately: peer analysis is only as good as the attributes behind it. Agree with HR and identity teams which attribute (department, job code or manager) defines a peer for each use case.
• Give non-human identities their own baselines: service accounts, API clients and AI agents behave differently from people. Tag them in identity data so they are not compared with human peers, and so their rare actions stand out.
• Use watchlists with exit criteria: add leavers, users under investigation and accounts with recent privilege changes, and remove them on a set date.
• Allow baselines to settle: expect noisy scores while baselines form after onboarding a source; partner guidance reviews at least two weeks, ideally 30 days, of history before deciding what goes to the SOC.
• Explain scores: analysts should see which violations drove a risk score; if they cannot, tuning will stall.

The method behind behaviour analytics is covered in the UEBA Guide, and programme design in the Insider Threat Programme Guide.

Where identity fits

The SIEM holds sensitive data and can trigger response actions, so its own accounts deserve privileged treatment.

• API accounts: integration documentation states that API accounts must hold the ROLE_API role and authenticate to the tenant host (for example <tenant>.securonix.net) with a username and password; queries go to endpoints under /Snypr/ws/. Create one account per integration, store the credentials in a secrets manager, rotate them on a schedule and disable accounts when an integration is retired.
• Analyst and admin access: separate content authors, analysts and platform administrators, and require MFA through your identity provider.
• Response permissions: SOAR playbooks that act on devices through the Hub should run with credentials scoped to the actions they need, with human approval for disruptive steps.

See the Service Account Security Guide and the API Key Management Guide.

How to implement

1. Define use cases: pick the first 10 to 20 threat scenarios (for example account compromise, privileged misuse, data exfiltration) and list the sources each needs.
2. Deploy Hubs and onboard identity data: size Hubs for expected events per second, then load HR and directory attributes before activity logs.
3. Onboard activity sources: add sources in priority order and validate parsing and identity resolution for each.
4. Enable content in the sandbox: turn on the policies and threat models that match onboarded sources, run them in the sandbox, and measure volume.
5. Promote in stages: move content to production one use case at a time; roll back by disabling the policy or threat model, not by stopping ingestion.
6. Tune with outcomes: review incident dispositions weekly and adjust thresholds, exclusions and weights at the noisiest layer.
7. Turn on sweeps and updates: decide which Content Manager updates and Autonomous Threat Sweeper features to opt into, and who triages their output.

Detection and measurement

• Source health: percentage of priority sources reporting within their expected interval, per Hub.
• Identity resolution rate: share of events attributed to a known user or entity.
• ATT&CK coverage: techniques covered by enabled, tested content, from the coverage view.
• Incident precision: true positive rate of incidents by threat model.
• Content currency: days between a vendor content update and its sandbox test and promotion decision.
• Time to triage: median time from incident creation to first analyst action.

Ways to cut noise without losing signal are in the Alert Fatigue Reduction Guide.

Framework mapping

Common misconfigurations

• Activity before identity: onboarding logs before HR and directory data, leaving peer analysis and attribution weak for months.
• Content enabled without its sources: threat models switched on for data that is not ingested, giving false confidence in ATT&CK coverage.
• Straight to production: new or updated policies promoted without a sandbox run, causing alert floods.
• Permanent exclusions: benign account exclusions with no owner or expiry, which later hide real misuse.
• Shared API accounts: one ROLE_API account used by several integrations, with credentials in scripts.
• Silent Hubs: no alerting when a Hub or source stops sending, so gaps are found during an investigation.

Practitioner checklist

• Use cases listed with the sources each needs.
• Hubs sized and monitored for events per second and resource use.
• HR and directory attributes loaded and mapped for peer analysis.
• Non-human identities tagged and baselined separately.
• Policies and threat models enabled only where sources exist, tested in the sandbox.
• Exclusions and whitelists carry an owner and expiry.
• Content Manager updates reviewed on a set cadence.
• One ROLE_API account per integration, credentials in a secrets manager.
• Weekly tuning review driven by incident dispositions.

Standards and references

• Securonix: UEBA
• Securonix: UEBA Datasheet
• Securonix: Unified Defense SIEM Datasheet
• Securonix: Bi-Directional Data, Connecting the SIEM to Your Environment
• Securonix: Advanced Content Capabilities Working in Symphony
• Securonix: Stay Ahead of Advanced Threats With Securonix Content Manager
• ThreatQuotient: Securonix Unified Defense SIEM CDF
• Fortinet: FortiSOAR Securonix SNYPR Connector

Related NHI Mgmt Group resources: UEBA Guide, SIEM Guide, Security Data Pipeline Guide, Detection Engineering Guide.