Instead of operating separate tools for log management, file integrity, vulnerability scanning, configuration auditing and incident response, USS provides all of them through one agent, one analysis engine, one data store and one console.

Building blocks

Extended modules

Extended modules add orchestration, case management, threat intelligence, behavioral analytics and central identity. They run on your own infrastructure next to the core components and share one sign-on.

Explore the docs

Feature catalog

All USS capabilities, grouped by area. Core features are part of every deployment. Module features come with an extended module. Integration features connect USS to a specific external system and are set up per deployment.

Data collection

Detection and analytics

Endpoint and IT hygiene

Response and orchestration

Threat intelligence

Search, reporting and compliance

Platform, access and integration

Architecture

USS consists of three central components plus a universal endpoint agent. Agents send data to the USS Server, which analyzes it and forwards alerts to the USS Indexer. The USS Dashboard reads from the Indexer and manages the Server through the USS API.

Components

Core components and extended modules share one sign-on through USS Identity and are reached from a single entry point.

Ports & protocols

Deployment models

In a Server cluster, the master node holds the authoritative configuration (rules, decoders, agent groups, centralized agent configuration) and synchronizes it to worker nodes; workers receive agent traffic and synchronize agent state back to the master. Agents should point to a load balancer (or a list of server addresses) so they can fail over between workers.

Data flow

Every event follows the same pipeline from the endpoint to the analyst's screen.

1. CollectionThe USS Agent reads log files, Windows event channels, journald, command output and module results (FIM, SCA, inventory). Devices without an agent send syslog or are polled through cloud provider APIs.
2. TransportEvents are buffered on the agent (anti-flooding queue) and sent encrypted to the USS Server on port 1514.
3. DecodingPre-decoding extracts timestamp, hostname and program name; decoders then normalize the event into structured fields such as srcip, srcuser, url, status.
4. Rule evaluationRules match decoded fields, apply correlation (frequency, time windows, same source) and assign a severity level 0–15, groups, compliance tags and MITRE ATT&CK techniques.
5. AlertingEvents at or above the alert threshold (default level 3) become alerts, written to /var/uss/logs/alerts/alerts.json. Optionally all events are archived to /var/uss/logs/archives/. Active response and integrations trigger here.
6. IndexingThe alert forwarder on the Server ships alerts over TLS into the USS Indexer as daily indices (<alerts-index>-YYYY.MM.DD).
7. VisualizationThe USS Dashboard queries the Indexer for alerts and state, and the USS API for live agent and management data.

Endpoint security

Capabilities that run on every USS Agent to keep endpoints hardened, intact and patched.

Security Configuration Assessment (SCA)

SCA verifies that endpoints conform to hardening policies. Policies are YAML files containing checks for files, directories, registry keys, running processes and command output. Built-in policies are based on CIS benchmarks; custom policies can be written for organization-specific baselines.

Each check returns passed, failed or not applicable, with rationale and remediation guidance, and is mapped to compliance controls. Default scan interval: 12 hours. See the SCA configuration.

File Integrity Monitoring (FIM)

FIM builds a baseline of checksums and attributes (size, permissions, owner, inode, modification time, hashes) for monitored paths and alerts when files or Windows registry keys are created, modified or deleted.

See the FIM configuration.

Malware detection

USS detects malicious activity through several layers:

• Rootkit and anomaly detection — hidden files, processes and ports; trojaned binaries.
• FIM-based detection of suspicious file drops in sensitive directories.
• Custom rules on indicators of compromise and CDB lists of known-bad hashes and IPs.
• YARA scanning triggered through active response.
• Log-based detection of antivirus and EDR events.

Vulnerability detection

Agents report their software inventory (packages, applications, OS and hotfixes) to the Server. The vulnerability detection module correlates this inventory with a continuously updated CVE feed (online threat-intelligence repository or an offline mirror for air-gapped sites) and keeps the per-agent vulnerability state in the Indexer. Alerts are raised when a vulnerability is detected or resolved. See the vulnerability configuration.

System inventory (IT hygiene)

The inventory module collects hardware, operating system, installed packages, network interfaces and addresses, open ports, running processes, services, users and groups, browser extensions and (on Windows) installed updates. It supports asset management and IT hygiene reviews and is the basis for vulnerability detection. Default collection interval: 1 hour.

Log data collection

USS collects logs from endpoints, servers, applications, network devices and cloud services and analyzes them in one place. Collection runs on the USS Agent, on the USS Server's syslog receiver and in cloud modules.

Collection methods

Collection features

• Agent labels: add custom fields (owner, environment, criticality) to every event from an agent.
• Output formats: rewrite or enrich collected lines before sending them.
• Multiple outputs: send the same log to the USS Server and to additional sockets or collectors.
• Anti-flooding buffer: the agent queues events when the server is unreachable or a burst occurs, and limits events per second.
• Encrypted transport from agent to server, with automatic failover between servers.

From log to alert

Every event is decoded into fields, checked against the rule set and, if it matches, stored as an alert with severity, groups and MITRE ATT&CK techniques. All events can also be archived for later search. See Data flow and Rules & decoders.

Threat detection & hunting

Centralized log analysis, rule-based correlation and MITRE ATT&CK mapping.

Log data analysis

USS collects logs from operating systems (syslog, journald, Windows Event Log channels including Sysmon), applications (web servers, databases, mail, proxies), security devices (firewalls, IDS) and cloud services, then decodes and correlates them centrally. Thousands of out-of-the-box decoders and rules cover common technologies.

Rule severity levels

Custom rules and decoders

<group name="local,sshd,">
  <!-- Raise severity for SSH login failures from outside the corporate range -->
  <rule id="100100" level="10">
    <if_sid>5716</if_sid>
    <srcip>!10.0.0.0/8</srcip>
    <description>sshd: authentication failure from external address $(srcip)</description>
    <mitre><id>T1110</id></mitre>
    <group>authentication_failed,pci_dss_10.2.4,gdpr_IV_35.7.d,</group>
  </rule>
</group>

MITRE ATT&CK & threat hunting

Rules carry MITRE ATT&CK technique IDs, so alerts are automatically categorized by tactic and technique. Analysts hunt in the Dashboard by querying indexed alerts and archives, pivoting on agents, users, IPs, file hashes and techniques. CDB lists (key/value IoC lists) and threat-intelligence integrations enrich detection.

Malware detection

USS detects malware through several independent layers, so a threat missed by one layer can still be caught by another.

Detected files can be removed or quarantined automatically with a response script (see Incident response).

System monitoring

Beyond logs and files, USS watches what runs on a system and how it is configured.

Command monitoring

Agents run commands on a schedule and send the output for analysis. Examples: list listening ports, check disk usage, read installed security patches, check that a service is running. Rules alert when the output changes or matches a condition. Remote commands are disabled by default and have to be enabled per agent.

System-call monitoring

On Linux, USS uses the kernel audit system to record selected system calls: program execution, privileged commands, changes to sensitive files, and network connections by specific users. The events are decoded and correlated like any other log.

Agentless monitoring

For devices that cannot run an agent, such as routers, switches and appliances, the USS Server connects over SSH on a schedule. It runs integrity checks on files and directories and compares command output, such as running configurations, to detect changes.

Osquery integration

Agents can run osquery packs on a schedule and send the results to USS. Teams can then use SQL-style queries to examine processes, users, network sockets, browser extensions and other host state across the estate.

Agent anti-tampering

The agent can require a verification code before it can be uninstalled, so a local attacker cannot silently remove monitoring.

Incident response

Automated containment through active response, plus alert delivery to the tools your team already uses.

Active response

Active response executes scripts automatically when specific rules, rule groups or severity levels are triggered.

Built-in response scripts

Response actions can be limited to specific agents, and they can also be run on demand from the API. See the active response configuration.

Alert delivery

Cloud & container security

The same detection pipeline applied to cloud accounts, cloud workloads and containers.

Supported cloud sources

Container monitoring

• Docker listener: records container create, start, stop, pause, exec, delete and image pull events with the user and image.
• Container logs: collects logs written by containers through the host agent.
• Host hardening: CIS policies for container hosts, with FIM on container configuration files.
• Kubernetes: agents on nodes, plus collection of Kubernetes audit logs for API-level activity.

Regulatory compliance

Rules and SCA checks are tagged with control identifiers, so the Dashboard can produce per-standard compliance views and audit evidence.

USS Orchestrator

USS Orchestrator is the security orchestration, automation and response (SOAR) engine of USS. Analysts build workflows (playbooks) in a visual editor. A workflow chains enrichment, decisions, approvals and actions across USS and the other systems in your environment.

Capabilities

Example workflow: brute-force attack

1. TriggerA USS alert for repeated authentication failures from one source address.
2. EnrichCheck the address against USS Threat Intelligence and internal allow lists.
3. DecideIf the address is internal or allow-listed, notify only. Otherwise continue.
4. RespondBlock the address on the perimeter firewall through its management API, for a set time (see Integrations).
5. RecordCreate or update a case in USS Case Management with the alert, enrichment results and the action taken.
6. RevertWhen the block period ends, remove the block and add the result to the case.

Typical workflows

• Phishing triage: extract URLs and attachments, check them, and block the sender and domains.
• Malware on endpoint: isolate the host through the EDR, collect evidence and open a case.
• Compromised account: disable the account, revoke sessions and notify the user's manager.
• Vulnerability follow-up: open tickets for hosts with critical CVEs and track remediation.
• Alert enrichment: add asset owner, geolocation and indicator reputation to every high-severity alert.

How it connects to USS

• Receives alerts from the USS Server by webhook, filtered by rule level, rule group or rule ID.
• Calls the USS API to run active response, read agent data and manage IoC lists.
• Creates cases and indicators in USS Case Management and USS Threat Intelligence.
• Signs users in through USS Identity and runs fully on-premises.

USS Case Management

USS Case Management is the incident-response workspace. Analysts triage incoming alerts, open cases, and record everything about an investigation in one place: affected assets, indicators, timeline, evidence, tasks, notes and the final report.

Capabilities

How it connects to USS

• USS alerts arrive through USS Orchestrator, so related alerts are grouped into one case.
• Indicators in a case can be pushed to USS Threat Intelligence, and from there to detection and firewalls.
• Users sign in through USS Identity, with roles aligned to USS roles.

USS Threat Intelligence

USS Threat Intelligence is the platform for collecting, correlating, scoring and sharing indicators of compromise and threat information. It feeds USS detection, playbooks and network security devices.

Capabilities

Distribution to USS and network devices

• USS detection: indicators are synced to USS IoC lists, so matching events raise alerts.
• Firewalls and network security devices: indicator lists published as feeds that devices poll, or pushed through the devices' management APIs (see Integrations).
• Web proxies and DNS filters: domain and URL indicators published as block lists or RPZ zones.
• IDS/IPS: generated rule files for network sensors.

Isolated networks

In a network without internet access, feed files are brought in through the internal update server and imported on a schedule. No outbound connection is needed (see Offline updates).

USS Analytics

USS Analytics adds machine-learning anomaly detection to the USS Indexer. Detectors learn the normal pattern of a metric and flag significant deviations in near real time, including behavior that no fixed rule describes. It runs inside your network; no data leaves the environment.

Capabilities

Example detectors

Detectors are tuned during deployment against a baseline period of your own data.

USS Identity

USS Identity provides single sign-on and central identity management for all USS consoles: Dashboard, Orchestrator, Case Management and Threat Intelligence. Users sign in once with their directory account, and roles are managed in one place.

Capabilities

Integrations

USS connects to the security and IT systems around it: it collects their data, sends them alerts and indicators, and triggers actions in them. Collection by agent or syslog is part of the core. Integrations marked Custom integration use the external system's API and are built and configured for each deployment.

Integration categories

Firewall management: automated blocking

USS detects attacks such as password guessing and network scanning from server, application and network logs. It then blocks the attacking address, or a known-bad IOC, on next-generation firewalls through the firewall management server's API. When the configured time ends, the block is removed automatically. Connectors follow the same pattern for any firewall platform with a management API.

1. DetectA USS rule fires (e.g. repeated authentication failures, port scan).
2. BlockThe response script signs in to the management API, adds the address as a host object to a dedicated block group used by a drop rule, publishes the change and installs the policy.
3. VerifyThe script checks the object and the policy-installation task status, and records the result in the alert and case. Failed API calls are retried. If the policy installation fails, the change is rolled back and an alert is raised.
4. UnblockWhen the timeout expires, USS runs the reverse action: it removes the address from the block group, publishes and installs the policy.
5. AuditEvery block and unblock is logged in USS and in the firewall's audit log.

EDR platforms

• Collect alerts, events, incidents, process trees and evidence from the EDR REST API on a schedule, and index them in USS.
• Correlate EDR data with other logs through shared fields such as host, user, hash and IP.
• Run EDR response actions (isolate host, kill process, quarantine file) from USS Orchestrator playbooks.

Virtualization platforms

• Hypervisor and virtualization-management logs collected through syslog and analyzed by USS rules.
• Inventory and state (hosts, VMs, power state, configuration changes) collected through the virtualization management API.

Business applications (REST API)

Connect USS to any application that exposes a REST API, such as ERP, finance, HR, ticketing or in-house applications.

• Inbound: applications use the USS API to pull alerts and inventory into their own workflows, or to start a response within their permissions.
• Outbound: USS calls an application's REST API from response actions and Orchestrator playbooks, for example to open a ticket or look up a user.

Unified API

A single API gateway, described by an OpenAPI (Swagger) specification, exposes USS and module functions with endpoint lists, authentication, and request and response definitions:

Single sign-on and entry portal

USS Identity, connected to LDAP / Active Directory, provides a single login for the USS Dashboard and all extended modules. A start page links every console, and roles are managed centrally.

USS Server & API

The USS Server receives data from agents and other sources, analyzes it, and manages agents, configuration and response. It scales horizontally as a cluster and exposes a REST API for automation.

Server services

Server cluster

• Master node: the authoritative source for rules, decoders, indicator lists, agent groups and agent keys. It synchronizes them to workers automatically.
• Worker nodes: receive agent traffic and run analysis. Add workers to scale out.
• Load balancing: agents connect through a load balancer or a list of servers and fail over automatically.
• Cluster status and per-node statistics are visible in the Dashboard and through the API.

USS API

Ruleset testing

Paste a log line into the Dashboard or send it to the API to see exactly how it is decoded and which rule matches. This lets you test new rules safely before deploying them.

USS Indexer

The USS Indexer is a distributed search and analytics engine that stores alerts, archived events and state data as JSON documents and makes them searchable in near real time.

What it stores

Features

• Clustering: shards and replicas spread across nodes for scale and fault tolerance; node roles can be split (cluster manager, data).
• Search: keyword, full-text, field, wildcard (substring) and range queries, plus SQL-style queries for analysts who prefer them, and aggregations for dashboards and reports.
• Index lifecycle management: roll over, shrink, force-merge, change replicas, move between tiers and delete indices by age or size (see Retention).
• Snapshots to shared file systems or S3-compatible storage, with restore of single indices.
• Security: TLS on all interfaces, internal users and roles, index- and document-level permissions, and audit logging of access.
• REST API for search, export and administration.
• Health monitoring: cluster status, disk watermarks and node statistics. Disk watermarks (for example 85% high and 95% flood stage) protect nodes from filling up, and lifecycle policies delete old data before the limits are reached.

USS Dashboard

The USS Dashboard is the web console for analysts and administrators. It covers monitoring, hunting, reporting and management of the whole platform.

Security views

Management

• Agents: inventory and status of every agent, group assignment, a deployment wizard, and remote upgrade.
• Ruleset editor: view and edit rules, decoders and indicator lists in the browser, and test them with logtest.
• Server management: configuration editor, cluster status, logs and statistics.
• API console: run USS API requests from the browser.
• Index management: lifecycle policies, snapshots and index health.
• Security: users, roles and role mappings.

Dashboards and reporting

• Build custom visualizations and dashboards from any indexed field.
• Generate PDF reports from module views and dashboards on demand or on a schedule, either in the console or through the reporting API.
• Export search results as CSV.
• Use multi-tenancy to keep separate saved objects and dashboards per team.
• Apply custom branding: logos and names in the header, sign-in page and reports.

USS Agents

The USS Agent is a lightweight, multi-platform program that collects security data on an endpoint and carries out response actions.

Supported platforms

The exact supported versions are listed in the installation guide for each release.

Agent features

• Modules: log collection, file integrity, configuration assessment, inventory, rootkit checks, command monitoring, cloud and container collection, and active response, all in one agent.
• Automatic enrollment on first start, with optional password or certificate verification.
• Mass deployment with installer variables, group policy or configuration-management tools.
• Groups and centralized configuration: an agent can belong to several groups, each with its own configuration, policies and lists.
• Labels: tag agents with metadata that appears in every alert.
• Event buffer with rate limiting, so bursts and server outages do not lose events.
• Server failover across several servers or through a load balancer.
• Remote upgrade from the server, using an internal package repository if needed.
• Anti-tampering: uninstall protection with a verification code.
• Status tracking: active, disconnected, pending or never connected, with history.

Rules & decoders

USS ships with thousands of decoders and rules for operating systems, applications, network devices, cloud services and security tools. Every rule and decoder is readable, and you can add your own without changing the built-in set.

Decoders

• Pre-decoding of common headers: timestamp, host and program name.
• Parent and child decoders: a parent selects a log family and children extract the fields.
• Pattern extraction with regular expressions into standard fields (source IP, user, URL, action) or any custom field.
• A native JSON decoder for structured logs, plus special decoders for specific formats.

Rules

Managing content

• Custom rules and decoders live in their own files and are never overwritten by updates.
• Edit and test content in the Dashboard ruleset editor or through the API.
• In a cluster, content edited on the master is synchronized to all workers.
• Built-in content updates arrive with platform updates and can be installed offline.

Users & access

USS controls who can see and change what, in the consoles and in the APIs.

Console and data access

• Internal users and roles for the Dashboard and Indexer, with cluster-, index- and document-level permissions.
• Role mapping from directory groups (LDAP / Active Directory) or from single-sign-on claims.
• Single sign-on and MFA through USS Identity (OpenID Connect or SAML).
• Multi-tenancy: separate saved searches, visualizations and dashboards per tenant.
• Password management: tools to change and rotate built-in user passwords.

API access control

Audit

Sign-ins, API requests, configuration changes and data access are logged. These logs can be fed back into USS, so administrator activity is monitored like any other activity.

Configuration essentials

The main configuration file on both Server and Agent is /var/uss/etc/uss.conf (Windows agent: C:\Program Files (x86)\uss-agent\uss.conf). Agent settings can also be pushed centrally through agent groups. Restart the corresponding USS service after local changes.

Log collection

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/auth.log</location>
</localfile>

<localfile>
  <log_format>json</log_format>
  <location>/var/log/app/*.json</location>
</localfile>

<!-- Windows -->
<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

File integrity monitoring

<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency>  <!-- 12 h scheduled scan -->
  <scan_on_start>yes</scan_on_start>
  <alert_new_files>yes</alert_new_files>
  <directories>/etc,/usr/bin,/usr/sbin</directories>
  <directories>/bin,/sbin,/boot</directories>
  <directories realtime="yes" report_changes="yes">/var/www/html</directories>
  <directories whodata="yes">/etc/ssh</directories>
  <ignore>/etc/mtab</ignore>
  <ignore type="sregex">.log$|.swp$</ignore>
  <nodiff>/etc/ssl/private.key</nodiff>
  <skip_nfs>yes</skip_nfs>
</syscheck>

Security configuration assessment

<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>
  <skip_nfs>yes</skip_nfs>
  <policies>
    <policy>etc/shared/custom_baseline.yml</policy>
  </policies>
</sca>

Vulnerability detection

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>  <!-- minimum 60m -->
  <!-- Air-gapped: <offline-url>file:///path/to/cves.zip</offline-url> -->
</vulnerability-detection>

Active response

<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5710,5711</rules_id>  <!-- or rules_group / level -->
  <timeout>600</timeout>          <!-- stateful: revert after 10 min -->
</active-response>

Key file locations

Operations

Day-to-day administration: onboarding agents, distributing configuration, managing access, retaining data and upgrading.

Agent enrollment

Each agent must be enrolled to receive a unique client key that encrypts its traffic and authenticates it to the Server.

Agent groups & centralized configuration

Agents are organized into groups (e.g. linux-web, windows-dc, db). Each group has a shared directory on the Server, /var/uss/etc/shared/<group>/, containing agent.conf, SCA policies and CDB lists. Changes are distributed automatically to member agents; an agent can belong to several groups and settings are merged in order.

<agent_config os="Linux">
  <localfile>
    <log_format>apache</log_format>
    <location>/var/log/nginx/access.log</location>
  </localfile>
</agent_config>

User administration & RBAC

• Dashboard / Indexer users — internal users, roles and role mappings; LDAP / Active Directory and SSO (SAML / OIDC).
• USS API RBAC — policies (actions + resources + effect), roles and rules map API users to permissions, e.g. read-only analysts limited to specific agent groups.
• Change all default passwords immediately after installation and keep them in a secret manager.

Data retention & storage tiers

Keeping a full year of logs as searchable, replicated indices is expensive. For example, 15 GB/day × 365 days is about 6.7 TB of indexed data, or about 13.5 TB with one replica. USS combines retention tiers, index compression and compressed raw-log archives to cut this to roughly 2.3–3 TB.

Techniques and their effect

Index compression

{ "index.codec": "best_compression" }

Lifecycle policy: hot → warm → delete

{
  "policy": {
    "default_state": "hot",
    "states": [
      { "name": "hot",
        "actions": [],
        "transitions": [{ "state_name": "warm", "conditions": { "min_index_age": "30d" } }] },
      { "name": "warm",
        "actions": [
          { "replica_count": { "number_of_replicas": 0 } },
          { "force_merge": { "max_num_segments": 1 } },
          { "read_only": {} }
        ],
        "transitions": [{ "state_name": "delete", "conditions": { "min_index_age": "90d" } }] },
      { "name": "delete",
        "actions": [{ "delete": {} }] }
    ]
  }
}

Raw-log archive

• Enable archiving of all events to /var/uss/logs/archives/; files rotate daily.
• Compress each rotated file with zstd -19 (or gzip), store a SHA-256 hash next to it, and move both to archive storage (NAS / S3-compatible, ideally write-once).
• To investigate old data, decompress the needed days and re-ingest them, or search them with command-line tools. Plan minutes to hours for this and reflect it in the SLA.

Backup

• Configure Indexer snapshots to a filesystem or S3-compatible repository.
• Back up Server configuration: uss.conf, custom rules / decoders / lists, client.keys, shared group directories and certificates.
• Monitor Indexer disk watermarks; compression ratios depend on log types, so measure them on real data during sizing.

System requirements

Size the core platform by the number of data sources (agents and syslog or API sources) that send logs. The tiers below assume 30 days of hot, instantly searchable storage. Use the formula after the table for longer retention.

Longer retention

Searchable storage ≈ logs per day × days × 0.8 × (1 + replicas). Compressed raw-log archives need about one tenth of the raw volume. For example, the Medium tier with 30 days hot and 365 days archived needs about 0.8 TB hot and 1.3 TB of archive storage. See Data retention & storage tiers.

Extended modules

General requirements

• Operating system: 64-bit Linux (RHEL-compatible or Ubuntu LTS) for all server roles.
• Storage: SSD for hot data (NVMe for the Enterprise tier); at least 3,000 IOPS, or 10,000+ IOPS for Large and Enterprise. HDD is acceptable for warm and archive tiers.
• Network: 1 Gbps between nodes; 10 Gbps recommended between Enterprise indexer nodes.
• Time: NTP / chrony synchronization on all nodes and sources.
• Browser: current Chrome, Edge or Firefox.
• Headroom: keep 20–30% spare CPU and disk for growth and peak load.

All figures are guidance. Confirm the final sizing by measuring event volume and compression on your own data sources.

Offline updates

All USS updates can be delivered without internet access from inside the network. An internal update server receives update packages through a controlled transfer process (for example, verified removable media or a one-way gateway) and serves them on the internal network.

Installation & support

• Installation and configuration: architecture and sizing, cluster installation, agent rollout, integration setup, initial rule tuning and acceptance testing.
• 24×7 technical support: a contracted support line with defined response times by severity, an on-call escalation path and remote assistance.
• Training for administrators and analysts.
• Maintenance: planned upgrades, detection-content updates and periodic health checks.

Exact response times and service levels are set in the support agreement.

Upgrades & health

• Agents can be upgraded remotely from the Server (API or Dashboard) once the Server is upgraded.
• Monitor agent connection status (active / disconnected / never connected), event queue usage, dropped events and Indexer cluster status (green / yellow / red).

Hardening checklist

Secure the USS platform itself. Complete these steps after installation and review them periodically.

• Replace demo / self-signed certificates with internal-CA certificates for Indexer, Server and Dashboard.
• Change every default password (Indexer admin, Dashboard users, USS API users) and rotate periodically.
• Restrict ports: 1514/1515 only from agent networks; 1516 and 9300–9400 only between cluster nodes; 9200 only from Server and Dashboard; 55000 only from Dashboard/admin hosts; 443 only from analyst networks.
• Enable enrollment password and certificate-based identity verification for agents.
• Apply least-privilege RBAC for Dashboard and USS API users; separate admin and analyst roles.
• Protect client.keys, private keys and API credentials (file permissions, secret manager, no plaintext in tickets).
• Enable SCA and FIM on the USS hosts themselves and send their own logs into the stack.
• Define ISM retention and snapshot backups; test restore regularly.
• Keep components patched; follow release notes and security advisories.
• Document custom rules (ID range 100000–120000), active responses and owners; review false positives periodically.
• Enforce sign-in through USS Identity for all consoles; disable local accounts that are no longer needed and require MFA for administrators.
• Use dedicated, least-privilege service accounts for the firewall, EDR, virtualization and internal-system integrations; store their API keys in a secret manager and rotate them.
• Review and approve every Orchestrator playbook that performs blocking or account actions; keep approval steps for high-impact actions.
• Verify the checksum or signature of every imported threat-intelligence and update package before use.

Glossary

Active response

Automated script executed on an agent or server when a rule fires.

Agent group

Set of agents sharing centralized configuration, policies and lists.

CDB list

Constant key/value database used in rules for IoC and allow/deny lookups.

Decoder

Parser that extracts structured fields from raw log data.

FIM

File Integrity Monitoring — detects changes to files and registry keys.

ISM

Index State Management — lifecycle policies for Indexer indices.

MITRE ATT&CK

Knowledge base of adversary tactics and techniques used to classify alerts.

Rule level

Severity 0–15 assigned by a rule; drives alerting and response.

SCA

Security Configuration Assessment — policy-based hardening checks (e.g. CIS).

SIEM / XDR

Security Information & Event Management / Extended Detection & Response — both provided by USS.

System inventory

Hardware, software, network, process and user data collected per endpoint.

Who-data

FIM mode that records the user and process responsible for a file change.

Anomaly detector

USS Analytics model that learns the normal pattern of a metric and flags deviations.

Case

A managed incident record in USS Case Management, with evidence, timeline and tasks.

IOC feed

A published list of indicators that firewalls or other systems poll and enforce.

Playbook

A USS Orchestrator workflow of enrichment, decision, approval and response steps.

SOAR

Security Orchestration, Automation and Response, provided by USS Orchestrator and USS Case Management.

STIX / TAXII

Standard format (STIX) and transport protocol (TAXII) for exchanging threat intelligence.

UEBA

User and Entity Behavior Analytics, provided by USS Analytics anomaly detection.