Setting Up Guardian Ops - Quick Start Guide
Guardian Ops provides automated and manual workflows that manage your network’s abuse reports. One of the key features of Guardian Ops 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. Here is a quick 6-step start guide.
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.
If you send reports that you receive at an email address other than the abuse@ role address, “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:
- Check if your “role address” is an existing alias address and if Abusix can be added as an additional alias to the address.
- If your role address supports aliasing, add the Data Channel forwarding address (e.g., [email protected]) as an alias in your email server.
By “aliasing” role addresses, we ensure that the emails are not altered in transit, no additional headers are added, and the report is not repackaged in an envelope in an email.
For more information on forwarding your abuse data, see the abuse management page documentation.
Step 2: Subscriber Resolving via an API and Target System (e.g., CRM or RADIUS Server)
API Subscriber Resolver
By default, Guardian Ops assigns events to cases based on the IP address of the incoming event. This IP serves as the Customer Identifier.
Guardian Ops provides a set of Resolvers to extract and evaluate different pieces of metadata. One of the most powerful is the API Resolver.
What Is the API Resolver?
The API Resolver allows you to pass information (such as the IP address and event timestamp) from an incoming event to your RESTful API endpoint.
Your backend system (e.g., CRM or RADIUS) then returns the correct Subscriber Identifier.
Common Use Case
Look up the subscriber assigned to an IP address at the time of an event using:
IP address
Event timestamp
How to Configure an API Resolver
To configure an API Resolver in AbuseHQ:
- Open the Admin Portal.
- Click Settings in the left menu under Guardian Ops.
- Click on New API resolver in the top right.
- Fill in the name and description.
- Provide the API endpoint, authentication credentials, and any required parameters.
⚠️ If your API is behind a firewall, ensure the following outgoing IPs are allowed: 18.193.183.51 52.57.46.129 18.158.191.233
For more information on API resolvers, see the customer API resolver documentation.
Step 3: Configuring Inbound Processing
Inbound Processing, located in the AbuseHQ settings under Automation, gives you the power to decide which events reach AbuseHQ and how to enrich those events.
The configurable Inbound Processing Flow Chart presents the journey of your events before they enter AbuseHQ.
- The “Incoming Events” (input node) is where parsed email and API events enter the inbound processing flow.
- Events are then triaged and tagged with an event type.
- Finally, data is sent to AbuseHQ, where it is orchestrated.
Configuring Inbound Processing
To configure Inbound Processing:
- Open the Admin Portal in AbuseHQ.
- Click Settings in the left-hand menu.
- Under Automation, click Inbound Processing.
Default Configuration
The default AbuseHQ Inbound Processing setup includes:
- A filter called
IsRecent
- A resolver called
IPResolver
Understanding IsRecent
- If an event matches the date filter, it proceeds to the
IPResolver
. (Shown by a green arrow in the flow chart.) - If it does not match, the event is dropped and not processed further. (This is shown with no link from the “Failed” red output.)
UnderstandingIPResolver
- This resolver enriches the event’s IP address and adds a Subscriber ID.
- The event is then forwarded to AbuseHQ (AHQ).
- Some resolvers can resolve domain-based reports (e.g., phishing) to an IP address to help identify the correct subscriber.
Configuration Steps:
- Click the
IsRecent
node. - Fill out the form on the right:
- Set a name, description, and the filter logic.
- Example: check if an event’s date is newer than
30d
.
For full guidance, see the configuring inbound processing documentation.
Step 4: Creating Cases, Case Rules, and Case Groups
Cases are collections of events that can either be open or closed. Each case can have one associated playbook, defining how events within that case should be handled.
Case Creation
The process of creating a case revolves around applying rules to events. Below is a detailed breakdown of the workflow and rules involved in case creation.
Workflow for Case Creation
To create cases, the user must determine which events should follow specific case rules. A case rule defines how and when a case is created or associated with an event. Users can configure a workflow to assign appropriate case rules to different events.
- Events without assigned case rules will not be associated with a case and will be left unprocessed in terms of case management.
- Events that match a rule will either be grouped into an existing case or trigger the creation of a new case based on the specified criteria.
Case Rule
A case rule defines the logic for creating or associating a case with an event. By default, the system provides one primary rule:
- Default Rule: For every incoming event, one case is created per customer.
- The case ID is a C followed by a UUID, e.g. C-2A51B5A1-BD0C-42F1-AF43-FCFA0FD03607
The process works as follows:
- Search for an Existing Case: The system checks if an open (state is not resolved) case already exists for the customer that fits the rule.
- Create a New Case: If no open case exists, a new case is created and its status is set to “new.”
In addition to the default rule, users can customize case creation using the following options:
Case Creation Options
- Separate Case per Contract: A case is created not only for each customer but also for every contract the customer holds. This means there could be multiple cases for the same customer, each tied to a different contract.
- Single Event per Case: This option disables the search for an existing case. A new case is opened for every event, ensuring that each event has its own individual case, following the rules specified above.
Combination of Rules
All the above options can be combined, allowing for highly flexible case creation workflows. For example, you can create a rule that opens a new case for each contract and each event type while also ensuring that each event gets its own case.
For full guidance, see the cases documentation.
Creating Case Groups
Case Groups allow you to group or separate different event types based on your specific handling procedures and policies.
Every Case Group is associated with a Playbook, which defines a workflow with multiple states.
Accessing Case Groups in AbuseHQ
To configure Case Groups, access the System Settings menu in the Admin Portal:
- Click Settings in the left menu under AbuseHQ.
- Click Case Groups under Automation.
- If this is your first time creating a Case Group, click the Add Case Group button.
- If not, click Define a new Case Group.
Creating a New Case Group
- Enter a name for the Case Group.
- Choose a color for easy identification.
- Click the Rule button.
- For Event Type, select:
- Event:
Complainant
- Condition:
does contain
- Value:
shadowserver
- Event:
- Click Rule again to add another:
- Event:
open-mongodb
(keep the other fields the same)
- Event:
- From the dropdown, select the Playbook you created for this event type.
- Click the Save button.
- Finally, go back into the newly created Case Group and click the green Activate button.
For full guidance, see the case group documentation.
Step 5: Configuring Playbooks
Playbooks are powerful workflow tools in AbuseHQ that allow you to move through new cases quickly—either manually or automatically.
Accessing Playbooks in AbuseHQ
To configure Playbooks:
- Open the Admin Portal in AbuseHQ.
- Click Settings in the left-hand menu.
- Under Automation, click Playbooks.
Creating a New Playbook
-
Click the Add new Playbook button.
-
Enter a name for the Playbook.
💡 Tip: Choose a name that helps you identify it later.
-
Click the Add Transition button.
Creating a Transition (Step 1)
- Enter a name for this transition.
- In the Source State dropdown, select:
NEW
. - In the Target State dropdown, click
+ new State
and name it (e.g.,CustomerNotice
). - Under Type, select:
Manual
. - In the Integrations dropdown, select the Mail Template you previously created for notifications.
- Click Add/Apply.
Creating a Transition (Step 2)
Now we’ll add another transition to continue the workflow:
- Click Add Transition again.
- Enter a name for this transition.
- For Source State, select:
CustomerNotice
(the one we just created). - For Target State, select:
Resolved
. - Under Type, select:
Automatic
. - Click the pencil icon next to the Precondition field to define a condition.
Defining a Precondition
- Click the Rule button.
- For Event Type, select:
Case
,State Entry Date
. - For the operator, select:
is more than
. - For the time range, enter:
7 days
. - Click Add/Apply.
You’ll be brought back to the Transition page, and the Precondition field will now show the data you defined. Click the Add button.
Finalizing the Playbook
You’ll return to the main Playbook page.
- Click the green START arrows to enable the transition steps.
- Click the Save button.
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].