Administration

Introduction

The ThreatX platform has a number of configuration, user, sensor, and other settings that can be managed by the ThreatX SOC, by your local administrator, or a combination of both.

The administrative settings can be accessed from the ThreatX user interface or from the API. Your ThreatX account must have write access to perform these tasks.

Allow, Deny, and Block lists

An entity in the following lists is denied temporarily blocked, or always allowed to interact with any of your sites.

Lists

Blacklist: An entity in the list is prevented from interacting with any of your sites.
Blocklist: An entity in the list is prevented from interacting with any of your sites. The block lasts for 30 minutes from the time the entity was added to the list. All requests made while the threat is blocked are tracked for valuable threat intelligence.
Whitelist: An entity in the list cannot be blocked or denied.

Once added to the Blacklist or Whitelist, the entity remains there permanently until it is manually removed. An administrator or ThreatX SOC can add an IP address or CIDR range, or manually remove an entity from the list.

↪ See: Blocking

Firewall Settings

You can view the CNAME provided for your tenant. The ThreatX WAF is SNI (Server Name Indication) aware and refers to the hostname provided in each request when visualizing and routing traffic. Request traffic for each of your sites is routed to the backend you defined for that site on the site’s details page.

Risk-Based Blocking Settings

Risk-Based Blocking Timeout: Determines the length of time a threat is blocked. Applies only to those threats that are blocked automatically.
Risk-Based Blocking Threshold: Sets the Risk Level score. Any threat that meets or exceeds the score is blocked automatically.
Block Embargoed Countries: When checked, any traffic from a country that is on the USA embargo list is blocked automatically.
Block Tor Exit Nodes: These are the gateways where encrypted Tor traffic hits the Internet. When configured, all incoming traffic from a TOR Exit node is not allowed.

_↪ See: Firewall Settings

Site Settings

The ThreatX sensor operates as a reverse proxy and is designed to monitor and act on incoming HTTP and HTTPS request traffic to prevent attacks and unwanted activity from reaching your web application and API servers. The backend you define for each site can be a single CNAME or a list of IPs, wherever traffic can be properly routed to reach your origin servers.

Site Settings

An administrator or ThreatX SOC can configure the following settings.

Listener: Settings include host name, SSL/TLS, redirect traffic, HTTP2.
Backend: Backend configuration for the connection of sites to sensors can be specified as a single hostname or CNAME, or a comma-separated list of IP addresses.
Blocking modes: Determine whether threats can be automatically blocked by risk-based blocking or by rules when it is an obvious hostile attack. Additionally, you can enable users to add IP addresses to the blocked or deny lists.
Caching configuration: Enable or disable static or dynamic caching. For more information about caching, see Performance
Proxy configuration: Configure the proxy settings, such as maximum request body size, proxy read timeout, proxy send timeout, set real IP from, and custom response headers.
Site group: You can assign a site group to limit which users can access the site configuration and its associated data.

↪ See: Managing Sites and Site Groups

Sensors

Sensors can be managed by your local administrator or the ThreatX SOC. If managed locally, you need to provide a Sensor API Key, which is required to authenticate to the ThreatX cloud infrastructure.

The sensor IP addresses are available in the ThreatX user interface. These addresses must be added to the whitelist in your environment to ensure traffic can reach your application.

↪ See: Managing Sensors

Notifications

You can configure users to receive notifications on various events relating to threats, rule matches, changes to the allow, deny, and block lists, and more. Notifications are typically sent by email, but you can configure a webhook notification to another app, such as Slack.

You can subscribe to the Threat X Maintenance and System Status Notifications website for messages regarding scheduled maintenance windows and any issues that might impact your ThreatX services.

↪ See: Notifications

Access Management

User Accounts

To access the ThreatX platform, you need to add user accounts. You can configure analyst accounts to be read-only where the users can access all analytical data. For administrators, you can grant write permission where the users can configure various settings as needed.

As needed, you can restrict users to access a specific site only.

You can add, edit, or remove user accounts from the ThreatX Dashboard or the API.

↪ See: Managing User Accounts

Audit Log

The ThreatX audit feature logs events, such as updating users, updating sites, and adding IP addresses to whitelists and blocked lists. The audit log lists all events by category and actions. As opposed to the Log Emitter, the audit log focuses mostly on user actions.

The audit log is available from the user interface or by using API.

↪ See: Audit Log

API Access

The ThreatX platform uses a RESTful API and supports a full set of application capabilities that can be used ad-hoc, in scripts, and in automation toolsets, such as SOAR. Advanced administrators can use the API to prevent, allow, or block an IP address or CIDR range with an API command. Other common uses include creating and managing user accounts, provisioning new sites to be protected, and managing certificates.

↪ See: API Access