Step-by-Step Configuration Guide

This guide leads system administrators step-by-step through the configuration of xorlab Security Platform. After completing this guide, your XSP will be customized to your needs and ready to process emails. First, you will go through the mandatory configuration needed to run XSP properly. The next article describes optional configuration steps to further customize your XSP.

​

Basic settings

1. Log in to the Control Center GUI with the URL address and credentials provided by xorlab.
2. On the main screen, click the tiles icon next to your account name and click the Admin icon in the displayed menu:
3. On the resulting Admin page, click the Expert tile:
4. In the folder view in the left pane, expand the shared folder, then click the guarded_tenants.yml file:
5. Under the domains section, enter the list of guarded tenant domains. If you need to include subdomains for a domain, add an extra entry with wildcards. Set the bccFallbackDomain to your main domain:
   shared/guarded_tenants.yml

   tenants:
   - name: xorlab
       bccFallbackDomain: xorlab.com
       domains:
       - xorlab.com
       - "**.xorlab.com" # To include subdomains; note the required quotes
   
6. Navigate to the shared folder, expand it and open the guarded_tenants.yml file. Set the value of deliveredTtlDays to the number of days xorlab should keep the metadata of processed emails if it differs from the default (90 days). After this time, emails are not searchable and are not shown in the GUI anymore. Also, you can adjust reportedTtlDays to configure the retention time of reported emails (default is two years):
   shared/guarded_tenants.yml

   tenants:
   - name: xorlab
       bccFallbackDomain: xorlab.com
       domains:
       - xorlab.com
       ## Data retention configuration
       dataRetention:
       ## Duration after which benign mails are deleted.
       deliveredTtlDays: 90
       ## Duration after which reported messages are deleted.
       reportedTtlDays: 730
   
   Retention timeIf you are unsure about the retention time, please contact support@xorlab.com. The retention time directly influences the required disk space on the XCC. If you choose the retention time too high, you might run out of disk space.
   To get an idea about the required disk space, please refer to the xorlab Security Platform Sizing Guide—it provides the required disk space for the Control Center with the retention time set to the default of 90 days.
   Quarantined emailsThese values do not influence the retention of quarantined emails. This is configured separately in Quarantines. Follow the instructions there to adjust the retention of quarantined emails.
7. Now, open the active_guard.yml file located in the activeguard/core/ folders. Set the templateDomain property to the domain that resolves to the MTAs through (possibly internal) MX records:
   templateDomain: mx.xor.activeguard.cloud
   
   For on-premises xorlab Security Platform, this domain has been setup as a part of the xorlab Security Platform VM Setup Guide. For xorlab Security Platform (SaaS), this domain is provided to you by xorlab as a part of the onboarding.

​

Trusted MTAs

Now we need to configure the trusted MTAs—please read Trusted MTAs first.

1. Open the activeguard/core/active_guard.yml file and configure the trustedMTAProfiles according to your setup. Please take a look at the examples as they might already cover what you need.
2. Open the activeguard/core/startup_cfg/spamass/local.cf file and add the IP address or the IP range of all trusted MTAs in the following way:
   # Set which networks or MTAs are considered 'trusted'
   trusted_networks 1.2/16 5/8                 # all in 1.2.*.* and 5.*.*.*
   trusted_networks 212.17.35.15               # specific address
   trusted_networks 1.                         # all in 1.*.*.*
   
   Note that this is not required if the trusted MTA sends emails to xorlab Security Platform with a private IP address (RFC1918).

​

Email routing

The email routing configuration for xorlab Security Platform is described in SMTP Configuration. Please follow the instructions there to configure the email routing according to your setup. The page includes additional configuration like TLS policies or the maximum allowed message size. Now, apply all previous configuration by clicking the Publish button and entering a comment. Afterwards, restart the corresponding components as described in How to Activate the Configuration to activate the changes.

​

List configuration

In the next step, inform XSP about special mailboxes that exist in your organization. This will allow XSP better detecting targeted attacks on high-value targets as well as display name impersonation (e.g., CEO fraud). For this, please read VIP Impersonation, High-Value Targets, and Exposed Accounts and fill at least the following lists:

• VIP names
• High-value targets
• Exposed accounts

​

Integration options

You can integrate xorlab Security Platform with your mailing system in a couple of ways. First of all, you can choose either inline or monitoring mode: the first actively filters emails, and the latter just monitors the traffic (all messages are delivered to recipients). This mode is independent of the actual type of integration and can be applied to almost all solutions. As you can see from the diagrams in the Integration chapter, XSP can be integrated both with on-prem and SaaS systems: Microsoft 365 (also using Azure AD services for SAML authentication), on-prem Exchange 2016/2019 server, and Cisco ESA (in monitoring mode). The reporting feature which allows users to report suspicious messages for further analysis (by admins or automatically), can be added to any app that offers a configurable Report Message button. In M365, case isolation feature is available: admins can delete a delivered suspicious message from a user’s mailbox just by clicking a button in xorlab Control Center (XCC).

​

Learning phase

xorlab Security Platform requires an initial learning phase in the beginning, during which it builds up the relationship models and local reputations. In the course of this phase, XSP must already see (i.e., process) all incoming as well as outgoing emails of your organization. The learning phase is configured by activating a predefined set of learning profiles. To get more information about profiles and see all available configurations, you can read Actions, Rules and Profiles. If you have already completed the learning phase, you can skip the next few instructions and go directly to Activating inbound email security. During the learning phase, xorlab Security Platform can either run with an active but reduced inbound email security or completely passive “toothless” mode (xorlab Security Platform will not do any actions on the email traffic). According to your preference, configure the corresponding mode as described here:

• Learning with active defense
• Learning with passive defense

Afterwards, you can start forwarding your emails to xorlab Security Platform to begin the learning phase. After two weeks, you can proceed with the next step to activate the default inbound email security.

​

Activating inbound email security

To activate the normal inbound email security, configure the default profiles according to the Standard profile. With this, xorlab Security Platform is ready and the inbound email defense is fully functioning.

​

Fine-tuning the system

Next, you can configure the global policies that should be active for different classifications of xorlab Security Platform by visiting the Actions panel in the XCC. You can also manually enter the rule parameters and their values into the local.properties file. We recommend you to check the Detection Tuning guide to customize the detection to your environment.

​

Reporting integration

For an additional layer of defense, your users can report suspicious emails that appeared in their inboxes. Reporting is a built-in feature of xorlab Security Platform and requires just a few configuration steps.

​

Additional configuration

When you are done with the basic configuration of XSP, proceed to the next article, which covers additional settings that you might find useful, such as event logging or user authentication.