Devices are the network equipment in your network that transfer and implement policies to filter malicious traffic.

The device service of the Platform API supports the creation, configuration and deletion of device entries.

Accounts are provisionned with a contractual limit on the number of devices that can be created. Not all accounts have access to every device type. The API enforces these limits.

Device types

ThreatSTOP supports three types of devices:

  • IP Devices, such as firewalls and routers, which filter traffic based on source or destination IP addresses.
  • DNS servers, which filter lookups of malicous domains and DNS records.
  • ThreatSTOP Roaming devices, which implement a DNS Firewall on Windows and OSX desktop or laptops.

Each physical device is associated with a device entry on the ThreatSTOP platform, to manage configuration settings such as the policy to be loaded on the device.

Each supported device is identified by a manufacturer and model. The list of devices currently supported is available on the Product documentation website.

Trial devices

  • ThreatSTOP provides two types of trial devices which allow testing the product on a test device, without requiring touching a production environment.
    • The ThreatSTOP Live ISO, a bootable Linux ISO image preconfigured with an IPTables IP firewall and a BIND DNS firewall.
    • Roaming trial devices, with the same set of features as regular roaming devices, except that they only support a set of predefined policies.

Integration types

The device integrations perform the following:

  • initial configuration (policy objects, logging)
  • ongoing policy updates
  • optional log upload for reporting features
  • optional telemetry for health checks

The mode of integration depends on the device’s capabilities and configuration tools. The different modes are:

  • configuration with no software deployment (e.g. BIND servers)
  • ThreatSTOP software running on the device itself (e.g. Vyatta, Juniper)
  • ThreatSTOP software running on a virtual machine to interface with the CLI or API on the device (e.g. Cisco ASA, Palo Alto Networks PanOS)

The minimal configuration of a device includes identifying information (a nickname, the device’s public IP address or hostname) and the policy. In this mode, manual configuration of the integration software is also required.

Most devices also support our Web Automation integration, which allows managing the complete set of integration settings from the Admin Portal or via the API.

Setting changes for devices configured with Web Automation are propagated from the API to the device itself within 5 minutes.

Immutable fields

The settings that identify the device itself (TDID) and its type (Manufacturer, Model, Integration) are immutable.

Device IP addresses

Public IP address

ThreatSTOP requires the public IP of the device (either for the device itself when running the ThreatSTOP integration on the device itself, or for the TSCM, when running the integration on the TSCM virtual machine) to grant access to the ThreatSTOP cloud services (e.g. to retrieve the policy updates).

Typical deployment use a static IP address for the device: set the ip_type to static and store the IP address in the device_ip field. If your device (or TSCM) has a dynamic public IP address, you can set the ip_type to dynamic and store the value of a FQDN that resolves (A record) to the device’s IP address in the dyndns_name field. The ThreatSTOP system will detect changes to the A record and updates its ACLs accordingly.

Private IP address

Device integration using a TSCM require configuring the internal IP address of the firewall. The internal IP address is used for:

  • the TSCM to connect to the device and update the policy, typically over SSH or HTTP
  • or, the device to connect to the TSCM to retrieve a policy, typically over SFTP or HTTP)

Web Automation / CTP

There are typically two modes of configurating the device integration software that connects your device to the ThreatSTOP cloud to update policies and (optionally) send log files.

In manual mode, the device settings are configured and maintained on the device itself. A change to the policy selection must be reflected on the device.

Using the Web Automation features, which is implemented in most of our integrations, the device settings are configured on the Admin Portal and updated automatically using a secure protocol. This allows managing the entire configuration from the portal.

The Device service supports the creation of devices with Web Automation settings. It is the recommended approach for easier integration. In the API objects, the web automation fields are referred to as CTP.

Optional features

Security Assessments

Accounts that have the Security Assessment feature enabled can configure the device as a security assessment device to enable support for PCAP and Netflow log formats.