Skip to main content
Guardian Ops provides automated and manual workflows for managing your network’s abuse reports. The two core views are Customers and Cases. In the Customers view, you’ll see a list of customers that received reports and can access a summary on each customer. The cases view provides detailed information about a specific breakdown of reports which can be aggregated by customer or contract. This quick start guide will help you set up Guardian Ops step by step to achieve clear and automated abuse handling.

Step 1: Connect Your Abuse Mailbox

Connecting your abuse reports to Abusix for processing is easy and essential for setting up Guardian Ops. We will parse your abuse data and extract numerous details that will give you an exact idea of what is happening on your network. Abuse reports sent to your abuse@ address (e.g., [email protected]) should be routed to the SMTP email address (Datachannel) provided by Guardian Ops. You can send multiple mailboxes to one SMTP Datachannel, but we recommend creating a single Datachannel for each mailbox. Make sure your email server sends an actual copy of the original email and doesn’t package it into a new email. Abuse mailbox forward for Guardian Ops
⚠️ Forwarding from an email client is not supported!
Forwarding using an email client changes the formatting of messages, headers, and every email client changes the formatting differently. Therefore we can’t guarantee reliable parsing.
You can find the default SMTP Datachannel within Guardian Ops after starting your trial. For more information on connecting your abuse data, see the abuse management page documentation.

Step 2: Understand Your Customer List - Configure Inbound Processing

By default, Guardian Ops sets the IP as customer ID. This is a great starting point for setting up and learning about the different features. ⚠️ Step 3 will explain how you can expand the default configuration of Customer Resolution See the Customers section in Guardian Ops that aggregates all incoming events according to their customer IDs. This provides an instant overview of fraudulent accounts in your network, sorted by abuse volume. Inbound Processing, located in the Guardian Ops settings, gives you the power to decide which events reach Guardian Ops and how to enrich and aggregate those events first to customer entities and later to cases. The configurable Inbound Processing Flow Chart presents the journey of your events before they end up in Guardian Ops.
  • The “Incoming Events” (input node) is where parsed email and API events (XARF) enter the inbound processing flow.
  • Events are then triaged and assigned with an event type.
  • Finally, data is sent to Guardian Ops, where it is aggregated.

Configuring Inbound Processing

To configure Inbound Processing:
  1. Click Settings under Guardian Ops in the left-hand menu where the Inbound Processing tab is located.
  2. Click Inbound Processing in the top navigation bar.
  3. Create a new draft by clicking the New Draft button.
  4. Drag and drop a node from the top left of the grid.

Saving and Activating the Flow

  1. After adding the nodes and configuring them, make sure to give the draft a proper name.
  2. Click the Save button to save your changes.
  3. To activate the flow, click the Activate button.
If everything is configured correctly, shortly after you receive a new abuse report, you should see the related customer in the Customer list with the report attached. For configuration examples and full guidance, see the inbound processing documentation.

Step 3: Set Up Customer Resolution

Guardian Ops requires a customer identifier to process abuse reports. This can be achieved in two ways:
  1. API requests:
    Guardian Ops can call your API with data from reports (e.g. IP address, timestamp when the event occurred, port, etc.) to retrieve the correct customer identifier and related information (customer, contract or tenant data). We strongly recommend this approach, especially for dynamic IP assignments or when additional metadata is needed. Oftentimes, IPs or domains change, but the fraudulent customer or contract stays the same. Abuse reports with changing IP addresses or domains that belong to the same customer can only be aggregated when using API customer resolution.
  2. Static fields:
    Guardian Ops maps values from any event attribute (IP addresses, domains, headers, etc.) to customer_id, tenant_id, and contract_id fields. If you cannot use resolution via API, we recommend to use static resolving using IP or domain.
Please select the method that best fits your network and customer management setup, and follow the instructions below to set it up.
Customer Resolution via API provides the most flexibility, enabling dynamic resolution and customer enrichment. Most importantly, it aggregates abuse reports to the same customer even when IPs or domains change - tracking the fraudulent actor, not just their current infrastructure. It allows you to pass information (such as the IP address, event timestamp, port, etc.) from an abuse report to your API endpoint. Your backend system (e.g., CRM or RADIUS) then returns the correct Customer Identifier and, if you want, other data that Guardian Ops can store.

Common Use Case

Look up the customer assigned to an IP address at the time of an event using:
  • IP address
  • Event timestamp

How to Configure API resolution

  1. Go to app.abusix.com.
  2. Navigate to SettingsGuardian OpsInbound Processing
  3. Add an API Caller node to your workflow
  4. Provide the API endpoint and any parameters your API requires for resolution.
  5. Hit “Test” to test credentials and receive a response to configure the mapping. To set up customer resolution, assigning a customer ID is required. Contract ID, tenant ID or fields related to these entities are optional. -> Contracts can be used to split your customers to separate automation later. For example, use contracts if you want fine grained control on which contract of a customer should be handled in automation.
  6. Save and continue to edit or activate your new Inbound Processing draft.
⚠️ If your API is behind a firewall, ensure the following IPs are in your allowlists and not blocked by any firewall: 18.193.183.51 | 52.57.46.129 | 18.158.191.233
API Caller node configuration for customer resolution

API Caller Configuration: Complete setup showing API endpoint configuration, parameter mapping, and customer resolution fields.

💡 You can utilize the static resolver if you need time to expose an API or allowlist our IPs; By default, Guardian Ops sets the IP as customer ID.
For more information on customer resolution, see the customer resolution documentation.

Step 4: Cases - Stepping Up Aggregation

Now that Guardian Ops receives your abuse reports and customer resolution is set up, it’s time to configure your first Case group, which will generate cases and fill your Case view. This helps you funnel your abuse reports into Cases which you can then set up automation for according to the needs of your abuse desk. For example, you could set up a flow that routes all copyright and spam reports to separate case groups while dropping everything else. Cases also lay the groundwork for automation with playbooks in Step 5.

Case Groups

Case groups are like buckets that cases end up in depending on a special ruleset. The configuration of case groups and their flows is done within inbound processing. A case group ends a path in your Inbound Processing flow. All cases and, therefore, events with attributes matching the rules of that path will fall into that group and end their journey through the flow.

Create Your First Case Group

  1. Click Settings under Guardian Ops in the left-hand menu, where the Inbound Processing tab is located.
  2. Click Edit to update a configuration, duplicate another configuration, or start from scratch.
  3. Drag and drop the Case Group Node from the top left list of nodes, and place it in your flow.
  4. Select or create a case group in the drop-down field.
  5. Click Save to set the changes on the case group.
  6. Click Done editing to save the Inbound Processing configuration.
Below, a minimal example with an API Caller node, configured for customer resolution, followed by a True/False node that filters Copyright reports into a copyright case group. Other reports can be found in the related section of your Inbound Processing settings. This section helps you to further refine your Inbound Processing ruleset. We recommend starting with the highest volume you see (e.g. event types or multiple types), and work toward a zero inbox approach in the unassigned events section. image.png Once more reports arrive, find your newly created cases in the Case List with all details attached. For full guidance, see the cases documentation.

Step 5: Use Playbooks to Automate

It’s time for the final piece of the puzzle: Playbooks. With playbooks, you can manually or automatically handle your cases according to the individual needs of your abuse desk processes. Playbooks offer similar flows to Inbound Processing but operate on cases. You can configure task nodes such as Delay, Wait until…, API Caller, Resolve, or apply straightforward rules to case attributes with the True/False node. See the node reference for details. Because processes vary for each abuse desk, customer group, and even event type, each case group can have a playbook assigned individually.

Managing Playbooks

Before you can assign a playbook to a case group, you need to create one.
  1. Click Settings under Guardian Ops in the left-hand menu, where the Playbooks tab is located.
  2. Click New Playbook and provide a name in the prompt (e.g., ‘copyright’ if you want to handle copyright cases specifically).
  3. In the second prompt, provide a version name such as Version 1.
  4. Click Edit to edit the newly created playbook.
    1. Drag and drop a node of your choice into the grid.
    2. Click the newly added node to set the node configuration.
    3. Repeat these three steps for all tasks you need in this playbook.
  5. Click Done editing.
  6. Go to the Inbound Processing Settings and select the flow that contains the case group to which you want to attach your created playbook.
  7. Click the case group and select the playbook in the drop-down.
  8. Save the case group and click Done editing.
All new cases matching the rules for this case group will flow through this playbook. For full guidance, see the playbooks documentation.

Questions? Send Us a Message

Having trouble with your setup or a technical issue? Get in touch with our team of Abusix experts. Click the chat button at the bottom and send us your questions. Alternatively, you can email us at [email protected].