Guardian Ops provides automated and manual workflows for managing your network’s abuse reports. One key feature is the ability to parse and identify abuse reports by event types and then match time frames to your customers through a simple API call. This quick start guide will help you achieve orchestration, aggregation, and automation in just 5 steps. Guardian Ops has two core views: 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.

​
Step 1: Forwarding Your Abuse Mailbox

Forwarding your abuse reports to Abusix for processing is easy and beneficial to your organization. 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 the abuse@ role address ([email protected]) should be forwarded by “aliasing” your abuse@ role address to the SMTP email address provided to you as shown below. Abuse mailbox forward for Guardian Ops If you want to send reports received at an email address other than the abuse@ role address, make sure to “alias” that address to the SMTP email address provided as well.
⚠️ Forwarding from an email client does not work!
Forwarding using an email client changes the formatting of messages, and every email client changes the formatting differently.
Steps:
  1. Check if your “role address” is an existing alias address and if Abusix can be added as an additional alias to the address.
  2. If your role address supports aliasing, add the Guardian Ops datachannel forwarding address (e.g., [email protected]) as an alias in your email server. You can find this address within Guardian Ops after starting your trial.
By “aliasing” role addresses, we ensure that the emails are not altered in transit, no additional headers are added, and the original report is not repackaged in a new email. For more information on forwarding your abuse data, see the abuse management page documentation.

​
Step 2: Ingest Selected Customer Data with API Resolving

Guardian Ops must resolve a customer identifier associated with the abuse report to process your data. This can be done in two ways:

​
Resolver Types

  1. IP-Based Resolution:
    Guardian Ops uses the IP address from the abuse report as customer IDs.
  2. Static Resolver:
    Guardian Ops maps values from any event attribute (IP addresses, domains, headers, etc.) to customer_id, tenant_id, and contract_id fields with automatic constraint handling and default value assignment.
  3. API Resolver:
    Guardian Ops can call your API with the IP address and event timestamp to retrieve the correct customer identifier and related information. This is ideal for dynamic IP assignments or when additional metadata is needed.
Please select the method that best fits your network and customer management setup, and follow the instructions below to set it up. Choose the method that best fits your network and customer management setup.
The IP Resolver sets the IP of the event as customer identifier.
💡 If you decide to use IPs as customer identifiers, use the IP Resolver node in your Inbound Processing flow. Step 3 of the getting started guide can help you with the configuration.
For more information on customer resolving, see the customer resolving documentation.

​
Step 3: Prepare Your Customer List - Configure Inbound Processing

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.
⚠️ Use the IP resolver or the API resolver node created in the previous step of this guide.

​
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 configuring inbound processing documentation.

​
Step 4: Cases - Stepping Up Aggregation

Now that you’ve configured the customer list, it’s time to set up your first Case groups, which will generate cases and fill your Case view. This provides functionality to aggregate reports into cases based on rules applied to event attributes.
For example, you could set up a flow that routes all copyright and spam reports to separate case groups while dropping everything else. Cases not only aggregate your reports but 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 resolver node followed by a case group that catches everything. See how the flow isn’t attached to unhandled events anymore? If you have a link to unhandled events, you can find those in the related section of your Inbound Processing settings. image.png Once new 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 and task 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].