logo

ACSIA XDR Plus Installation and User Administration Guide

1. Preface

This guide will walk you through the prerequisites required to install ACSIA, product installation and configuration details as well as administration, troubleshooting deployment and Frequently Asked Questions. This guide applies to ACSIA XDR version 4 or later.

2. What is ACSIA XDR Plus?

ACSIA is an Automated Cyber Security Intelligence Application which enables organizations to protect themselves against malicious attacks and unauthorized entities targeting your data.

3. Installation and Configuration

Like any other software application, ACSIA needs some preliminary requirements to be satisfied in order to communicate with connected clients and to perform its tasks.

3.1. Prerequisites

3.1.1. Web UI Network ports

In order to access ACSIA’s Web UI you will need to open the following ports between your workstation (Laptop/Desktop/PC) and the ACSIA server:

  • HTTPS: 443

3.1.2. ACSIA client server ports using Agent installation

If you choose to deploy the ACSIA agent on the clients (servers or workstations) the only requirement for the agent to be able to communicate with the ACSIA server is the TCP port 443 (HTTPS) and 444 (TCP/UDP). If these ports are not open please make sure to have them opened.

  • TCP->Inbound to ACSIA Server: 443

  • TCP/UDP->Inbound to ACSIA Server: 444

3.1.3. ACSIA client server ports agentless deployment

ACSIA Server communicates with clients via the following communications ports, therefore you will need to enable at your firewall following rules if you choose the agentless deployment:

  • TCP->Inbound to ACSIA Server: 1515, 5044

  • UDP->Inbound to ACSIA Server: 1514

  • TCP->Outbound from ACSIA Server: 5986 (for Windows Clients)

  • TCP->Outbound from ACSIA Server: 22 (for Linux Clients)

Furthermore, ACSIA requires temporary internet access during the installation and for updates (typically quarterly releases). After completion of the installation this can be restricted if security policy mandates it.

The only internet connectivity required by ACSIA after the installation is the TLS-enabled connectivity to port 5150 on license.acsia.io. This connectivity is required at all times (private and public keypair verification for license), although ACSIA allows up to 48 hours of connection loss before it enters an unlicensed state. The only exception to this requirement is where ACSIA is deployed from Amazon AWS Marketplace.

3.1.4. ACSIA Proxy configuration - Only if you have Proxy

If you have a proxy and your servers (both ACSIA VM and your server to be monitored) for your servers to go out on the internet please apply the following instructions.

As first step add the following information in /etc/environment file:

Step 1
HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=127.0.0.1,localhost,172.17.0.0/16,172.18.0.0/16,elasticsearch-1,logstash,kibana,mariadb,rabbitmq,nginx,wazuh,elk

The above parameters such as username, password and the ports are of course to be replaced with your own proxy details.

If the proxy user is domain user then the format should be DOMAIN%5CUSERNAME where %5C represents the \.

The option NO_PROXY, in addition to what is specified above as parameters, you will need to add your internal networks and subnets where the monitored devices are located (your servers or PCs network). Otherwise you will have connectivity issues between ACSIA and those networks when you try to add them to the list of services to be monitored by ACSIA. This is because the proxy will be unlikely to be able to reach out to those networks.

Step 2

Store the same parameters in /home/acsia/.bashrc or simply just add source to the same. /etc/environment.

Step 3

Configure `/etc/yum.conf' using the following format:

proxy=http://10.0.1.1:8080
proxy_username=USERNAME
proxy_password=PASSWORD

In yum.conf for the domain user just use \ and no ascii code, i.e. DOMAIN\USERNAME.

Any changes affecting above variables must be notified to ACSIA via configureHttpProxy command followed by acsia_restart (this is for when ACSIA installation is already completed).

3.1.5. ACSIA Server Platform Requirements

ACSIA Server platform requires the following minimum specs:

  • Any of the following Linux distributions: Ubuntu 20.04

  • 8/16GB RAM 4vCPU

  • 100GB Storage (depending on retention policy)

  • Partitioning: There is no specific partitioning required for ACSIA VM, however, when ACSIA is hosted on-prem (outside cloud platforms) it is strongly recommended to setup LVM partition so the storage can be easily extended.

Note
The specification above would support a typical standard workload of 100+ monitored servers. ACSIA scales relatively linearly, so additional resources will support larger client environments.

3.2. ACSIA Server installation

Prepare a Linux VM (i.e. Ubuntu 20.04 are currently supported, please check release notes for ACSIA) to host ACSIA server, make sure the system is up to date.

Once all your prerequisites have been satisfied, the installation of ACSIA can commence. If the requirements for the installation are not satisfied, the installation will fail and you will be provided with an explanation of what prerequisites were not met.

Customers with a valid ACSIA license will receive an installation package from 4Securitas Support team to download the main installation script acsia_prepare, and additional files containing credentials including the license.

Please strictly follow the instructions provided in this guide for the installation of ACSIA server clients configuration.

3.2.1. Getting Started with the Installation of ACSIA Server

Login into the newly provisioned VM for ACSIA server, switch to root user, copy the acsia_prepare and the credentials.txt that are being provided to you. Execute the acsia_prepare as follows, making sure the script is executable i.e. chmod +x acsia_prepare:

   ./acsia_prepare

Follow the instructions provided on your screen and when complete, execute the following:

   ./acsia_app/bin/acsia_install

If all preliminary requirements are satisfied as per the guidelines, the ACSIA server will be fully installed in about ~5-6 minutes.

In case of any issue please refer to the Troubleshooting section in this guide or contact our support team at [email protected], if the fix you are looking for is not within this guide. When requesting support please provide as much information as possible (i.e. screenshots, logs, etc).

At the end of the installation process you should have on your screen the credentials for first admin user to login into web UI, something like the following:

ACSIA web and Kibana
    Admin interface: https://123.123.123.123:8443
    Username: [email protected]
    Password: the_password_for_admin

Once the server installation finishes the client installation will continue in the background (ACSIA server becomes the first client to be monitored) so please wait for the engine to fully initialize upon client install completion.

To check the progress status for the initialization of ACSIA run:

   acsia_tail_f

After the clients installation completed you should see the following message in acsia_tail_f:

image

The above message indicates that the engine is ready, up and running. Now you can login into the web UI with the credentials provided and activate the license as first thing as soon as logged in.

Note
After the installation is completed, in order to have all ACSIA service commands available it is strictly necessary to logout from the running session and log back in again, so the environment variables can be all loaded.

4. ACSIA Service Commands

As mentioned above, all of ACSIA’s service commands, including the start/stop services as well as troubleshooting tips can be found in the /acsia_app/bin folder in $ACSIA_HOME.

Below are some frequently used service commands.

Check if all of ACSIA services running:
acsia_stack_status
Start ACSIA all services:
acsia_stack_start
Stop ACSIA all services:
acsia_stack_stop
Start only ACSIA engine:
acsia_start

4.1. Full List of Service Commands

You can find all available service commands of ACSIA at /home/acsia/acsia_app/bin.

Below is the table containing all commands with their descriptions:

Table 1. Service Commands

Command

Description

acsia_adapter_beanstalk.py

AWS Elasticbeanstalk adapter for ACSIA

acsia_adapter_ips.sh

IPS component adapter for AWS elasticbeanstalk

acsia_admin_check_requirements.sh

Check ACSIA prerequisites

acsia_admin_docker_subnet

Change docker subnet

acsia_admin_health.sh

Check ACSIA health status

acsia_admin_logs

Show ACSIA components logs

acsia_admin_query

Run MySQL DB query

acsia_admin_reset_password

Retrieve ACSIA user credentials link to reset

acsia_admin_unlock_indices

Unlock indices if ACSIA disk is saturated due to out of space

acsia_ban_script

Ban an IP address

acsia_beanstalk_ban

Ban IP through AWS Elasticbeanstalk

acsia_beanstalk_find_banned_ip_rule

List or find banned IP addresses in AWS Elasticbeanstalk

acsia_beanstalk_manage_service

Manage services and configuration of ACSIA in AWS Elasticbeanstalk

acsia_beanstalk_unban

Remove the ban for an IP address in AWS Elasticbeanstalk

acsia_change_ip

Change ACSIA server IP address

acsia_deploy_ssl_certs

Install SSL/TLS certificate on ACSIA server if assigned subdomain

acsia_download

Download ACSIA package for the installation (deprecated in v4)

acsia_elastic_restart

Restart Elasticsearch

acsia_elastic_start

Start Elasticsearch

acsia_elastic_status

Check Elasticsearch status

acsia_elastic_stop

Stop Elasticsearch

acsia_elastic_tail_f

Check Elasticsearch logs

acsia_export_logs

Export ACSIA logs

acsia_fix_kernel_inspector_wrong_version

Fix kernel mismatch version

acsia_install

Install ACSIA

acsia_ip

Retrieve ACSIA server IP address

install_acm_app.sh

Install ACM module when it fails during client deployments

acsia_normal_ban

Ban an IP address

acsia_normal_manage_service

Configure and manage services

acsia_normal_unban

Unban an IP address

acsia_reconfigure_acm

Reconfigure ACM module for ACSIA client for specific IP

acsia_reconfigure_acm_all

Reconfigure ACM module for ACSIA for all connected clients

acsia_report

Generate and export incident reports for ACSIA

acsia_restart

Restart ACSIA engine only

acsia_set_private_ip

Assign private IP address to ACSIA server

acsia_stack_restart

Restart all stack with all components including the engine

acsia_stack_start

Start all stack with all components including the engine

acsia_stack_status

Check status for all stack with all components including the engine

acsia_stack_stop

Stop all stack with all components including the engine

acsia_start_bg

Start ACSIA in background

acsia_status

Show ACSIA status

acsia_stop

Stop ACSIA engine only

acsia_tail_f

Show real time ACSIA logs

acsia_unban_script

Unban an IP address

acsia_uninstall

Uninstall ACSIA

acsia_update

Update ACSIA

insert_acsia_user

Add user for ACSIA WEB UI

install_falco

Install falco kernel module

kibana_default_index

Reset to Kibana default indices

kibana_import_saved_objects

Import saved object, customization on Kibana

mfa_acsia_install

Activate and enable 2FA/MFA

mfa_acsia_uninstall

Disable 2FA/MFA

mfa_ssh_install

Activate 2FA/MFA for SSH login as acsia user on server

mfa_ssh_qrcode

Generate or show SSH QR code for 2FA/MFA

mfa_ssh_uninstall

Disable SSH 2FA/MFA

setInternalIP

Set internal IP for ACSIA server

ssl_configuration

Check and configure SSL/TLS

winrm_remote

Check Ansible WinRM for Windows clients

The ACSIA XDR Plus product is a modular design built with multiple open source tools. There are several service scripts for each component which will rarely be needed (unless you run into some issues). The service scripts shown above should suffice for most of the you’d ever need to perform on ACSIA.

5. Configuring and Enabling ACSIA to send Emails

In order for ACSIA to be able to send email notifications, including the email for the admin account setup, it requires the ability to communicate with your mail server. To do this the emails originating from the ACSIA server must be white-listed on your mail server and spam filters (if you have one) etc.

If you do not white-list emails originating from the ACSIA server it is likely that they will be bounced or placed into a spam folder (this is because the email originating from a server and not from a real email account), so if you do not receive emails try the following guidelines or check the troubleshooting section of this guide.

Note
if the users are experiencing issues receiving their account creation emails, the admin can run the acsia_admin_reset_password command to retrieve the link to enable them to reset their credentials.

5.1. Set and Configure a real email account as a sender

It is possible to use a real email account (i.e. business email, private Gmail, Yahoo, etc.) and set it as sender to receive notifications via mail (this will avoid email notifications from ACSIA being bounced or placed in spam filters) without hassle.
To set and configure an email account on ACSIA navigate to Settings→Email section and add your email account details.

6. Configuring SSL certificate for ACSIA Web Application

By default, ACSIA generates self-signed SSL certificates for secure browsing. The self-signed certs are configured using ACSIA IP addresses (external or local if provided). If you wish to configure ACSIA with a proper CA and have your own SSL certificate, you can do that either during the installation of ACSIA, or at a later stage. ACSIA requires the certificate and the key to be provided in two files - the private key, and the public certificate (both to be .pem formatted). 1. Deploy the cert during the install: when installing ACSIA using the acsia_install script, simply add the extra command-line parameters such as: --certificate /path/to/cert.pem, --key /path/to/key.pem and --domain my.domain.com. All three must be present, or the installer will exit with an error. 2. Post-install deployment: a new script acsia_deploy_ssl_certs has been provided, and accepts the same parameters as per previous step --certificate, --key, and --domain. Once these have been deployed, you will need to execute acsia_stack_restart for all components to pick up these newly added certificates.

6.1. Amazon AWS Elastic Beanstalk Integration

ACSIA comes with the AWS Elastic Beanstalk Integration feature to monitor applications that are running within Elastic Beanstalk.

If you have applications running on Elasticbeanstalk and you want to ACSIA to monitor and protect them, then run the following command in terminal: acsia_adapter_beanstalk.py

You will be prompted to provide the following information from your AWS environment:

  • AWS Access Key ID (IAM User)

  • AWS Secret Access Key (IAM User secret)

  • Default region name (Region where Beanstalk located)

  • Default output format: (can be json or text but json preferred)

  • ACL (Network access control list ID in Beanstalk VPC)

At the completion of the above deployment you will be given an IP address (internal/private IP). The IP address can be always retrieved later by running acsia_adapter_ip.sh.

Login onto the ACSIA Web UI Console and add the Linux host using the IP address provided earlier (Getting Started->Start->Linux).

Please note that the deployment might end with some warnings and partial configuration. Do not panic, these warnings may not be serious and the monitoring will be functioning normally.

Make sure to include the acsia.config file provided into your elasticbeanstalk application startup pack (kickstarter package).

After having completed all the above steps, login into a fresh terminal on the ACSIA server and restart ACSIA by running the acsia_restart command. This is to make sure ACSIA picks up all changes and configuration files.

7. Updating ACSIA

Updating ACSIA is fairly easy and straightforward.

To update all you need to do is to run the following command in terminal as acsia user

   acsia_update

You will require your ACSIA username and passwords to get updates. These credentials are usually supplied within the same email where you receive your license instructions.

We recommend that ACSIA updates are performed from the terminal as opposed to using the Web UI update feature. This provides greater clarity and control of the process with more granular error code information.

Note
Major releases of ACSIA will generally include core tool upgrades. We therefore recommend a full stack stop and start when performing these upgrades. You can do this by running acsia_stack_stop && acsia_stack_start

8. License Activation

After completing the installation, you should be able to access the ACSIA application via a web browser. The first action is to activate the license.

If you do not activate the license you won’t be able to do anything as the application will be functioning at minimum capacity or not at all. To activate the license, copy the license code provided and go to the user menu (top right) by clicking (it is either your email address or your name) on Settings from the menu and then select the License tab where you can add/activate the license.

Note
The license can be requested via contact form at https://4securitas.com in case you have not received your license (or by contacting support@acsia.io).

9. Authentication Methods used in ACSIA

ACSIA comes with multiple authentication mechanisms integrated.

ACSIA has traditional authentication methods such as username and password as well as multi factor authentication (aka 2FA).

9.1. Two-Factor Authentication

For better security ACSIA offers a 2FA method that can be implemented during the installation as well as after the installation. The Two-Factor Authentication (2FA) is available for both SSH and ACSIA Web UI logins.

The 2FA can be enabled for all users by navigating from Web UI to Settings→2FA.

9.2. Enabling 2FA for SSH from command line

If you wish to apply 2FA to the acsia user for SSH logins you can do that during the installation prompts. The 2FA features can be enabled or disabled at any time through mfa_ssh_install and mfa_ssh_uninstall commands respectively. When enabled, the acsia system user will have a Time-based One-Time Password (TOTP) secret key generated. We recommend the use of 2FA token handler tools such as Google Authenticator or FreeOTP etc. A QR code is printed to screen during the installation if this feature is enabled..

Note
When this is enabled, only key-based authentication (ssh-key) can be used for session authentication. Password + 2FA is not supported, as this causes unintended side-effects.

After the installation is finished, or when executing mfa_ssh_qrcode, the QR code will be displayed to the terminal and it can be scanned with your preferred 2FA token handler.

9.3. Enabling 2FA for ACSIA Web UI Login from command line

Although the SSH 2FA can be optionally enabled or disabled, we strongly recommend that the 2FA is enabled for the UI, especially if ACSIA users are accessing the UI from the internet. If the 2FA is enabled for WebApp login, all users will be provided with a QR code (which should be scanned by e.g. Google Authenticator, FreeOTP, etc.), and must present the TOTP key each time they log in to the application along with traditional access credentials such as username and password.

9.4. Access to Kibana Dashboards and Authentication

The Elasticsearch visualizer Kibana is part of the ACSIA stack. To access Kibana applications and dashboards, password user and authentication is enabled. Whenever a user attempts to view Dashboards, they must present their ACSIA username/password. The username and password is automatically generated from ACSIA Web UI login credentials.

10. Preparing Your Servers to be Connected to ACSIA

ACSIA supports both Linux, Windows and MAC OS operating systems.

10.1. Preliminary Requirements

If you intend to monitor your systems without using ACSIA Agent (agentless mode) there are some preliminary requirements such as a service user account with administrative privileges. This service user can be a local admin account, a Domain Controller (for windows systems) or LDAP account (for Linux systems). While if you are choosing the agent mode, running the agent on the end-point will suffice.

Note
If your IT infrastructure is hosted on Google Cloud (Metadata Page) you can skip the following steps by just adding ACSIA ssh-keys to your project from Google console. AWS has a similar setup that can be done via OpsWorks.

10.2. Connecting a Linux Client

10.2.1. Requirements

  • Kernel 2.6 or later

  • Python 2.7 or later

  • User account acsia with sudo privileges and passwordless (for agentless only)

10.2.2. Deploying ACSIA via agent

For all Linux, Windows and MAC OS clients, where you have chosen to install Client Agent, all you need to do is to navigate in ACSIA Web UI Hosts→Add Host, select the operating system i.e. Linux, Windows or MAC and choose Use The Agent where you can download.

Please be aware that agents can be downloaded for a single client, meaning the same agent downloaded from UI cannot be used for a second host. For each host you must download a new agent because each agent has its token (this for security reasons). If you’d like to download an agent for multiple clients then you can use Bulk Agent Deployment where you can select the number of clients you wish to deploy the single agent.

Copy the downloaded agent to the client device for the installation and execute as root on Linux/MAC and Administrator on Windows using PowerShell. Make sure to add execution permission to Linux/MAC agent.

If all prerequisites are in place after installing the agent on your clients you will see the clients automatically listed (populated) on ACSIA UI in the Hosts section.

Note
Client agents connected to ACSIA server via an API, it doesn’t have a user creations requirements or multiple ports to be opened on firewall (all ports are consolidated into 2 ports which are 443 (TCP) and 444 (UDP/TCP) as per requirements when opting for agent).
Important
ACSIA agents downloaded from UI have tokens that expire after a number of hours and each download is valid for a single device (meaning for each device you have to download a new agent or choose the bulk agent installation option if you wish to use single download for multiple devices). If the agent provided to you is not working please make you generate a fresh agent because it is most likely a token expiration issue related.

10.2.3. Deploying ACSIA in agentless mode on Linux systems

If you wish to deploy ACSIA in your clients without an agent the following steps are recommended:

An example of creating ACSIA service user for RedHat/Debian Linux systems:

From your server’s shell/console as root or equivalent:

10.2.4. CentOS / RHEL Linux

Creating ACSIA Service User on CentOS or RHEL systems

useradd -m -d /home/acsia -c "ACSIA Service User" -G wheel acsia

In the above command we are creating an acsia user, providing a home directory, tagging with a name and assigning it to the “wheel” administrative group.

Followed by enabling sudo passwordless permissions which is done by editing /etc/sudoers file and removing the comment # from the following string:

%wheel ALL=(ALL:ALL) NOPASSWD:ALL

10.2.5. Debian / Ubuntu Linux

Creating ACSIA Service User on Debian or Ubuntu systems

useradd -m -d /home/acsia -s /bin/bash -G sudo acsia

And than check in /etc/sudoers and remove the comment # following string (add if you don’t have it):

%sudo ALL=(ALL:ALL) NOPASSWD:ALL

10.2.6. SSH Key

Once completed the service user creation on your Linux servers the next step is to get the ssh-key from ACSIA Web UI. To get the key, navigate to Hosts→Add Host area, choose Linux and you will be able to see/copy the ssh-key.

Copy/export the ssh-key and import it into the ACSIA Service User created (on each server) earlier paying attention to steps in relation to .ssh and authorized_keys file permissions.

A typical way to do that would be (as acsia user):

echo "paste here the key" > .ssh/authorized_keys

chmod 700 .ssh && chmod 600 .ssh/authorized_keys

This ACSIA service user is used for 2 different purposes:

To deploy elastic stack shippers (filebeat, auditbeat, packetbeat), ossec/wazuh agent and falco kernel module. To enable ACSIA automatically ban threats and attacks at spot as well as perform remediation options actioned by user

Both above steps are performed via Ansible playbooks that are pushed from the ACSIA server onto clients automatically (this avoids the requirement to perform the installation on every single client manually).

Note
The ssh-key we refer to is a 4096 bit randomly generated by ACSIA during the installation. This key can be replaced by your own keys, create a new one or replace it by any other keypairs (i.e. AWS EC2 keypair.pem etc). It is entirely at user discretion.

10.3. Connecting a Windows Client without Agent

To manage Windows servers in agentless mode, WinRM needs to be installed, running and listening on the Windows servers. The instructions below are examples provided by Ansible

10.3.1. Requirements

  • PowerShell 4.0+

  • Windows Server 2008 SP1+ (or Windows 7 SP1)

  • Local or domain acsia account with administrative privileges or equivalent

  • WinRM service active and running

10.3.2. Domain Controller - Active Directory (Agentless)

If your Windows systems are part of AD/DC, ACSIA has an integration feature for Domain Controllers. All you need to do is to run the following powershell script on the primary DC:

ForEach ($COMPUTER in (Get-ADComputer -Filter '*' | Select -ExpandProperty DNSHostName))
{
    if(!(Test-Connection -Cn $computer -BufferSize 16 -Count 1 -ea 0 -quiet))
    {
        write-host "cannot reach $computer" -f red
    }else {
        write-host "executing script on $computer" -f green

        Invoke-Command -ComputerName $computer -ScriptBlock {
            [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
            $url = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1"
            $file = "$env:temp\ConfigureRemotingForAnsible.ps1"
            (New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file)
            powershell.exe -ExecutionPolicy ByPass -File $file
        }
    }
}
Note
While executing the above script, if you discover that some of the DC clients are not reachable through DNS name then simply replace DNSHostName with Name.

Once the above script has successfully executed go to ACSIA UI Getting Started session and add your domain controller where during discovery step of the Domain Controller an option called Add all "yourdomain.local servers" will appear.

Something like following screenshot where acsia.local is your domain controller FQDN:

image

This will poll all registered clients on your Domain Controller and populate them on ACSIA UI to be deployed/monitored at once.

Note
please ensure that you enter your domain controller in the format of username@fqdn i.e. user1@acsia.io

10.3.3. Windows Client Not Connected to AD/DC (Agentless)

If your windows servers are not connected to any Domain Controller, the following script must be executed on windows clients to enable winRM service which is used for Ansible

WinRM configuration script
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$url = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1"
$file = "$env:TEMP\ConfigureRemotingForAnsible.ps1"
(New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file)
powershell.exe -ExecutionPolicy ByPass -File $file
Note
please ensure the URL is not split into parts during copy/paste operation.

10.3.4. Connecting PCs and Workstations to ACSIA (Agentless)

PCs and Workstations can also be connected and monitored by ACSIA following the same instructions shown above. Please note that endpoints (such as PCs and Workstations) behind domestic routers will require NATting enabled on port 5986 for the endpoint intended to connect to ACSIA (Installation via agent is the recommended way for scenarios like this one)

Important
Please upgrade your Powershell version if the version is < 4 and also make sure that Windows firewall is active.

10.4. Adding Hosts via ACSIA Web UI (agentless mode only)

Login into the ACSIA Web UI and click on Add Host from the menu on the left side bar, the Hosts page. Select the operating system of the client you wish to connect and you will be forwarded to the next window where you may add hosts on an IP or Hostname basis, using a CSV file (explained better below) or via the agent (by downloading the agent). It is best practice is to use IP addresses to add your server as the remaining details of hosts including hostname will be automatically retrieved and placed by ACSIA.

After completing the Hosts Setup the next step is the Logs Configuration screen, where you can add your custom web server or web application logs (always use the absolute path of the logs). The next step is the validation of the logs entered, if any are non-existent this will be highlighted so that you can correct or remove if it was a mistake or a typo and so on.

Important
the paths must be to the log files themselves; symlinks to files are unsupported.

For instance, if you have a web application running on Nginx Web Server (likewise with Apache) you will need to add your Nginx logs manually during client deployment (can be done even later using edit option) i.e. /var/log/nginx/access.log.

The web application logs are typically detected automatically by ACSIA. But if they’ve not been detected for some reason, the recommended action is to add them manually by using the Edit Host Details where the hosts are listed (in the Hosts page).

Once the configuration of all the log files has been completed, there will be a Summary shown in the next screen to make sure that you have everything entered followed by Deploy where you actually start to deploy ACSIA and connect to your servers. This will take a few minutes (depending on your network connectivity between clients and server) and you will be eventually shown a dialogue message that reports the completion of the enrollment procedure.

10.4.1. CSV File format

ACSIA offers the option to use a CSV file containing details of all of your server details where you can just import the CSV file.

The following screenshot provides the format of CSV file for ACSIA:

image

Note
If you have multiple logs for a single host you can separate each log by semicolon ;.

Once deployment of a client is completed, your servers are set to be constantly monitored in real time for security issues, threats and anomalies.

10.4.2. Container-specific details

ACSIA is container-aware, and will automatically track kernel events within containers. However, if you are running application/webservers within containers, and wish for these logs to be monitored, they must be made available to the host. ACSIA does not support symlinks to log files - it must be the full path to the given log file.

Linux container logs can be presented to ACSIA by using docker options --volume or --mount. As per official docker documentation in here. or here if you are using docker-compose.

11. User Administration

User administration section can be found at the top right bar by clicking on the username with which you have logged in and then Settings.

11.1. Adding a New User to ACSIA Web UI

Adding a user has never been simpler. Just click on username on the top right bar and select Settings from the menu.

Then click on "ADD USER" and fill in all the fields, you can also Delete or Edit Users in this Section. Please keep in mind that the actual username has to be an email address.

11.2. Distribution Lists

ACSIA enables you to create distribution lists where you can add members to each group and set the notification types to be sent to each distribution list. For instance, you can set a distribution list to receive only Critical or High or Medium/Low priority security alerts. Your C-Level management may not want to receive alerts outside Critical events and therefore a distribution list can be created to satisfy this requirement.

You will find the Distribution List on the left side bar menu. To create a new distribution list just click "ADD NEW LIST".

Give a name to the Distribution List created and select the members by adding them to the list along with choosing the type of event (Critical, High or Medium/Low) that you wish the group should receive.

You are now all set to receive notifications through the distribution list.

11.3. Email Settings

The email settings relate to ACSIA server side notifications via emails. This setting can be found at the top right under the Settings menu Email tab.

Here you can set the sender email and the name for it. For instance, if your organization domain is called example.com you can set the email as [email protected] and the name as Acsia Alerts and white list that account on your anti-spam filters to make sure you receive notifications from that email account.

As soon as you set this up you will start receiving notification emails as per the setup.

If you experience issues in receiving email the recommended actions is to setup an actual real email account and configure Under the email notification, instead of setting a simple email and label, you can enable the SMTP and the Authentication methods where you can fill in the details of the email you wish to use as sender.

11.4. Receiving notifications via Slack and/or Microsoft Teams

Similar to the email notification, you can also activate notifications to be received through Slack and/or Microsoft Teams. You can enable this in Settings section under integration where you can simply copy the desired webhook (microsoft temas or slack) and activate to receive notifications via real-time messaging.

11.4.1. Slack setup instructions (Microsoft Teams is pretty much the same)

Install incoming-webhook on your Slack
  1. Go to Apps

  2. Go to View App directory

  3. Search for incoming-webhook

  4. Go to Add Configuration

  5. At Post to Channel: choose channel/group where to send notification

  6. Click Add Incoming WebHooks Integration

  7. Go to Customize Name: Add name i.e. ACSIA Notifier

  8. Copy the WebHook URL

Configure on ACSIA UI
  1. Access to Web UI

  2. Go to Settings -> Integration

  3. Activate Slack or Microsoft Teams

  4. Paste the URL copied

11.5. Kernel Level Notifications

With the kernel level monitoring, once enabled, ACSIA has the ability to intercept the stream of every system call made to kernel by intercepting the `syscalls`and searching for anomalies/threats in real-time (this is for Linux systems only).

If you’d like to receive kernel level notification it is recommended to keep this feature enabled. It can be disabled at any time for those who wish to do so by navigating to Setting and click on Notification tab.

11.6. Enabling Automatic Ban

If you’d like ACSIA to handle the majority of threats originating from outside your organisation (i.e. attacks originating from the internet such as BotNet, Bruteforce, Dictionary, SQL injections, XSS attacks etc) then this feature must be enabled.

If enabled, ACSIA will automatically take remediation actions such as banning IP addresses on the spot. You can enable Automatic Ban by navigating in the Settings area and click on tab Notification.

11.7. Enabling Manual Ban for Local/Private IP Addresses

ACSIA by default cannot ban local IP addresses, this is to avoid any business interruption or similar incidents that will impact on business. However, if you’d like to be able to ban local IP addresses you can do this by enabling this feature under the Settings→Notification tab.

11.8. Log Retention

ACSIA stores all incoming logs from servers between Elasticsearch and MySQL databases. The lifespan (retention period) of the logs can be configured by navigating to Settings and clicking on Log Retention tab. ACSIA enables user to set different retention period for different type of logs (which are listed below):

11.8.1. Access Logs

These logs include all system logs and event logs.

11.8.2. Web Logs

Web logs are the web applications logs (i.e. apache, nginx, tomcat, IIS, etc.)

11.8.3. Audit Logs

These are very commonly known Linux audit logs.

11.8.4. Network Log

These logs are the network traffic captured at server level (inbound and outbound).

11.8.5. ACM Logs

ACM stand for Advanced Compliance Mitigation and therefore these are compliance related logs (system, application, security events, etc)

12. Host List Section

Hosts list page shows the inventory of all devices connected to ACSIA in a table mode and details of each table cell briefly listed below:

  • Host Alias: where you can assign an alias to recognize better your host

  • Hostname: this value is retrieved automatically from the host but user can change the name

  • Host IP: the IP address through which the client is connected

  • Operating System: indicates what operating system the client has

  • Status: contains the list and the status of all shippers that streaming the client logs to ACSIA server

  • Actions: this area has 3 actionable sub-sections:

  • View Details: show the details about the host i.e. operating system, kernel, IP address, monitored logs and more

  • Edit Host Details: it is the area where the user can edit host details such as adding an alias, changing hostname, the IP address, adding custom logs to be monitored and starting/stopping log shippers (streamers) manually etc.

  • Remove Host: where you can remove the connected host

13. Events Section

13.1. Live Notifications

On the left side menu we also have Live Notifications which contains the list of all live events that are not being actioned yet. All incoming security alerts will be listed in this section and by clicking on the Details arrow on each notification in this area you will be able to browse and explore the full details of a single incident/alert generated by ACSIA.

We also have filters where the events can be filtered and searched criteria based etc.

13.2. Live Notification Sidebar

We have a Live Events sidebar on the right side of the screen. This side bar is similar to Live Notifications with an exception of being static and permanently on the right side, this is useful when monitoring events while navigating through ACSIA’s functionalities.

Each event is shown with a short brief description along Immediate Actions to enable the user to action and remediate an incoming security event or incident on spot.

14. Insights

The Insights area can be found on the left hand side bar menu. This section contains multiple dashboards that ACSIA offers for deep investigations of events or even for generating reports and analytics. Each dashboard is visualized using Kibana web application offered by Elastic stack. For details about how to use and navigate through Kibana application please use the official documentation link.

Each dashboard is self-described as you will find it under Insights area.

14.1. Compliance

The Compliance area contains primarily dashboards/reports relating to compliance and regulatory frameworks listed briefly below:

  • Security Information Management

  • Security events report

  • Integrity monitoring report

  • Threat Detection and Response

  • Vulnerabilities report

  • Mitre Att&ck

  • Auditing and Policy Monitoring

  • Policy monitoring dashboard

  • System auditing dashboard

  • Regulatory Compliance

  • GDPR

  • PCI DSS

  • HIPAA

  • NIST 800-53

  • TSC

Security and information management provides visibility and reporting about security events and includes file integrity monitoring. Threat detection and response provides reports on discovered vulnerabilities for connected systems.

Auditing and policy monitoring provides full visibility on audit controls and standard policy requirements.

Regulatory compliance dashboards cover global regulatory regimes from GDPR, PCI DSS, NIST 800-53, HIPAA, TSC and Mitre Att&ck framework. ACSIA provides full control and visibility in real-time on compliance of IT systems, and if the systems are not compliant, it provides the exact failing point so it can be easily addressed.

15. Policies

ACSIA‘s Policies provides an inventory of what is allowed and not allowed on monitored clients. When ACSIA blocks traffic it utilizes individual clients' local firewalls (Windows firewall and routing table on Linux systems etc). The Policies section is divided into 4 subsections as follows:

  • IP Blacklist

  • IP Whitelist

  • Locked Users

  • Access Location

  • Muted Notifications

15.1. IP Blacklist

The IP Blacklist contains all those source IP addresses that have been marked as malicious and unauthorized and therefore blacklisted (banned by hosts). You can undo an action if an IP address is mistakenly banned by a user. If the autoban feature is enabled, ACSIA will automatically handle all potential attacks and threats originating from outside of the organization (from the internet for example) whereas internal threats will always be notified for the ACSIA administrator to make the final decision.

15.2. IP Whitelist

The IP Whitelist contains all those source IP addresses that have been marked as trusted. Note that white listing an IP address does not include web requests due to giving sensitivity to web application level accesses. Therefore when you white list an IP address that doesn’t apply to web requests and if traffic originating from that specific IP address identifies a potential threat it will be subject to notification and alert.

15.3. Locked Users

The Locked Users contains specific users that are marked to be locked. They can be legitimate users who attempt to gain access to non-authorized areas. Alternatively they may be malicious users that have compromised the legitimate account details of a user and therefore been locked. ACSIA does not automatically block legitimate users, it always requires user input so it will be at ACSIA administrator’s discretion to make that call.

15.4. Access Location

The Access Location refers to those security events where a legitimate access originates from a geographical location or an IP address that wasn’t authorized on ACSIA. Therefore waiting for approval, to be authorized or unauthorized. If you authorize a location based IP address for a user it is like whitelisting that user only for that IP address. On the other hand, if you mark a user unauthorized, that user will still be able to access and make attempts but you will be notified every time. So the Access Location is different from blacklisting an IP unless you add the IP manually to the blacklist.

15.5. Muted Notifications

The Muted Notifications refers to those security events that have been acknowledged legitimately by ACSIA administrators and/or security analysts. Once an incident is marked to be muted ACSIA will no longer notify that type of incident. All muted events can be unmuted at any time.

16. Immediate Actions - Remediation options

It is highly likely that the Immediate Actions are going to be the most frequently used features of ACSIA by its users. You will often find these actions embedded in all incoming security events or email notifications. From there you can take immediate action and interactively mitigate the event for its remediation.

This is the Interactive feature of ACSIA where the user input required for the remediation of events and threats:

The order of Immediate Actions (sometimes referred to as Remediation Options), supplied with the notifications dynamically changes based on the severity level of the event and the type of event. For instance, if there is a potential account compromise alert, the order of remediation action will be set on priority where the option appearing on the top will be the most logical choice followed by the second in the list and so on. ACSIA users will benefit greatly from this feature even if they don’t have cybersecurity knowledge or have limited technical skills.

16.1. Immediate Actions or Remediation Options offered by ACSIA:

16.1.1. Kill this connection

By choosing this action the ACSIA user will be killing network traffic (in real-time) for that malicious IP address and suspending all traffic for that IP address for the next 15 minutes. Any established connection and new connection requests will be killed while attempting to broadcast.

16.1.2. Acknowledge and Authorize User/Location

By choosing this action you authorize that specific user and the associated IP address on a permanent basis to access your premises. That IP address will be white listed for ACSIA and therefore you will no longer receive an alert originating from that IP address associated with its user.

16.1.3. Mark This User/Location as Unauthorized

By choosing this action you ask ACSIA to keep notifying users about this event until you make a decision. Use this for incidents where you have not yet decided to ban or authorize an access made from an IP address.

16.1.4. Ban This IP

By choosing this action you permanently ban the IP address and therefore it will no longer be able to reach out to your systems.

16.1.5. Lock User

By choosing this action you lock the user account within your systems.

16.1.6. Track This IP

This action will take you to Kibana application Dashboard where the all network and server activity of that specific IP address will be populated to give a full visibility of what’s happening.

16.1.7. Track This User

This action will take you to Kibana application Dashboard where all network and server activity will be populated for that specific user by enabling you to establish the legitimacy of the user activity.

16.1.8. Whois Query

This is a domain name lookup service to search the whois database for domain and IP registration information. It gives relevant information about the ownership of the originating IP address of the malicious user.

16.1.9. View Details

This provides accurate details of the event, including geographical location of the originating IP address and the geographical coordinates.

16.1.10. Close Incident

This is to simply disregard the event and if it reoccurs ACSIA will notify again.

16.1.11. Mute Notification

This action is to tell ACSIA to disregard and no longer notify when that specific event reoccurs.

16.1.12. Track Command Session - Only for Linux clients

This is an extremely powerful feature within ACSIA that is enabled by our Kernel level monitoring. From the moment that suspicious activity has been detected or a user has attempted to read or write to sensitive data or files, the alert will be triggered and real-time remediation actions provided. When you click on this Track Command Session you will be presented not only with that specific user activity that triggered the alert, but the entire session of the user in replay mode. This forensic level of detail will allow you to view the full activity performed by the user and therefore have an understanding of why that user tried to alter the sensitive files and data and make a remediation action swiftly.

17. Event History

Event history is the section where you can find all events that have been actioned or amended and by whom (ACSIA users, who did what on web UI).

18. Email Notification

An example of email and Slack notification is shown below:

15_email-notif

image

As we can see in the above screenshot, we have received a notification about successful access using acsia user targeting our pre production server. Now, we know that a legitimate user is logged in but ACSIA has rightfully notified this as a potential account compromise.

This user and location will become legitimate for ACSIA only if we authorize the user with the associated location as legitimate. ACSIA users are to train the ACSIA machine learning module when it comes to legitimate accesses like this one. This is where mostly the user input will be requested by ACSIA. Therefore ACSIA users will need to indicate for the first time, using Immediate Actions, that this user is authorized and legitimate. From that moment onward ACSIA will know about that pattern and will no longer notify (unless the account is really compromised).

19. Troubleshooting and Common Issues

Common issues and how to troubleshoot and fix them.

19.1. Changing ACSIA server IP address

Please be aware that if you change the IP address of ACSIA manually from the configuration file you will break all communications systems with the clients connected (if any added). Also trying to change/amend manually the server IP address on individual clients connected to ACSIA will not help to restore the communication between the two since ACSIA generates SSL cert based private and public keypair between the server and it’s clients for secure and end-to-end communication. Therefore, if you happen to change the IP address of the ACSIA server the easiest fix would be to run acsia_change_ip from the ACSIA server itself.

19.2. Packetbeat failing on Windows systems

If you experience a problem with the packetbeat component failing on Windows clients, it is most likely due to an antivirus or other similar software installed on the client and not permitting for ACSIA shippers (packetbeat) to be installed correctly. To solve this issue you’ll need to login into windows client, open the file uninstall-service-packetbeat.ps1 located in C:\Program Files\Packetbeat with powershell and execute. After that, proceed with uninstalling Npcap software which should be listed among your programs using the windows uninstall feature available in the control panel.

Once you uninstall Npcap you need to reinstall it, so download from https://nmap.org/npcap/dist/npcap-1.00.exe and install. During the installation of Npcap, at the beginning, tick the options WinPcap API compatible mode and Legacy loopback. Once you have installed Npcap you will need to execute install-service-packetbeat.ps1 in powershell to complete the install. You can either try to start the network shipper from ACSIA UI or it will start automatically after 5 or 10 minutes.

19.3. Recent versions of Ubuntu versions comes without python2

Some of the most recent Ubuntu versions are not shipped with python2 by default so you may need to install it if problems arise during deployment of an ubuntu client. apt install python2

19.4. User not receiving email with the account details after the installation

If you are experiencing any issues in receiving the email containing user account details, it is likely the case that your email provider is bouncing the email, placing it into spam or quarantine area or it may as well be that your network infrastructure is not allowing the server to dispatch emails. ACSIA uses postfix as the MTA, so please check your network infrastructure configuration to make sure that the VM hosting ACSIA server is able to send emails. Also check the postfix logs at /var/logs/maillog, as well as your spam or quarantine area and/or whitelist on your mail server ACSIA email and the IP address.

19.5. Message “Deployment Failed” Kernel module

During the deployment of clients if you are experiencing an issue with the message from UI Deployment Failed this could be either the failure of the deployment partially or fully. To verify if the failure is partial just check the hosts lists on ACSIA UI and if you see that host listed then it is partial failure and most likely the kernel module failed due to missing requirements.In this case ACSIA will be operational and working on that specific client with the exception of the kernel module that is failing.

To solve this issue:

  1. Open a terminal in the ACSIA server

  2. Switch to acsia user

  3. Execute the following command (replace both client_ip with the IP of the client):

    Important
    Please note that the client_ip is followed by , to distinguish it from a filename
    ansible -i 'client_ip,' -m script -a "$ACSIA_BIN/install_falco" client_ip --become

    Example:

    ansible -i '11.22.33.44,' -m script -a "$ACSIA_BIN/install_falco" 11.22.33.44 --become

On some clients having Debian 8x falco kernel modules may fail during deployment due to falco.yml file configuration not being placed correctly. To fix this issue you may run dpkg --configure -a.

If no output is given or an output containing message W: Failed to fetch it means you are experiencing network issues to reach out to the server where the module is located. Please check your outbound connection i.e. firewall rules and make sure the server is allowed to reach the source as per requirement outlined in this guide.

19.6. Deployment failed with the message ImportError: No module named 'requests.packages.urllib3'

This is a common Fedora/RHEL/CentOS (RPM platforms) issue when a package or packages are installed using non-standard package management. (i.e. using pip or setuptools etc. rather than yum). the This issue can be addressed as follows:

sudo pip2 uninstall requests urllib3
sudo yum remove python-urllib3 python-requests
sudo yum install python-urllib3 python-requests

19.7. Deployment failed ACM (Wazuh/OSSEC module)

If you experience a problem (for both Windows and Linux clients) where the ACM module of ACSIA is failing to start, it is most likely the communication port issue related. So make sure that the communication ports are opened between the ACSIA server and the clients as per requirements. If the ports are open and the issue still persists then run the following command(s) from ACSIA server as acsia user:

acsia_reconfigure_acm --linux
acsia_reconfigure_acm --windows

Use linux parameter if the issue occurs on a Linux client, else use the windows parameter if the client system is windows.

19.8. After system update (patching) Kernel module stopped working on clients

It is not always the case but it may happen that during updates and patching activities on servers that are connected to ACSIA the kernel level monitoring may not function properly. If you experience any issues with kernel monitoring after updates all you need to do is to perform the following command as acsia user on all connected clients: cp -rf /etc/falco/falco.yaml.rpmnew /etc/falco/falco.yaml and restart the kernel module from ACSIA Web UI on clients.

19.9. Storage Saturation - Disk full on ACSIA Server

When storage saturation reaches 90% capacity on the ACSIA server, elasticsearch component switches to read_only and it won’t allow new logs to be written in the disk. This means the storage capacity should always be below 90%. If the storage capacity exceeds 90% you will need to free up space or allocate more disk space. Once storage capacity is freed, to restore elasticsearch from read-only to read-write indexes requires some fix as follows.

19.9.1. Fixing Elasticsearch Index after disk storage saturation

After adding or freeing storage space execute the following script which will restore elasticsearch to its original state (read-write):

#!/bin/bash
for i in $(curl -s -X GET http://localhost:9200/_cat/indices | awk -F ' ' '{print $3}' | sort)
do
    echo Updating ${i}: $(curl -s -X PUT -H "Content-Type: application/json" \
                               -d '{"index.blocks.read_only_allow_delete": null}' \
                               "http://localhost:9200/${i}/_settings")
done

19.10. Docker containers' IP addresses conflicting with local IP addresses

The architecture of ACSIA and its components is primarily built in Linux containers using docker-compose. During ACSIA installation the way a container platform works is that it scans the network perimeter looking for available private networks to pick up and set network configuration automatically.

It may occur that some businesses have segmented their IT infrastructure and ACSIA is not aware of their presence because it is in a segregated network. When you open for the first time those subnets to ACSIA and if they happen to be the same subnet as the ACSIA docker environment the two will get in conflict with each other. You therefore have to choose another network and set it on ACSIA docker compose configuration.

It is possible to do that as follow:

  • create/edit /etc/docker/daemon.json and add the chosen (new) subnet to assign as per below snippet and restart services as shown:

    • { "bip": "192.168.1.5/24" }

    • acsia_stack_stop

    • sudo systemctl docker restart

    • acsia_stack_start

19.11. Falco fails with agent deployment

After deploying the agent on Linux of you happen to have Kernel (Falco) fails, to investigate proceed as follow (on client terminal): - Check first if falco service is up and running systemctl status falco:

  • if the service is there but not running, just start the daemon from the UI using the Edit Host option

  • else, if the service does not exist proceed as follow

  • Check acsia_agent logs and trace down falco related logs: less /opt/acsia/agent/acsia_agent_proj/logs/agent.log or just use grep grep falco /opt/acsia/agent/acsia_agent_proj/logs/agent.log

If you see something like the following:

2022-03-01 11:37:46,034 acsia_agent.commands.operations INFO Failed Ephemeral [440efa1a-1ac3-40f8-a86c-b8944effd76d: [ansible -m script -a "/opt/acsia/agent/acsia_agent_proj/assets/install_falco 2> /dev/null" --become 127.0.0.1]

The above indicates that for some reason falco installation is failed, we therefore need to reinstall it as follow (always on client):

  • run the following to commands:

    • sudo /opt/acsia/agent/acsia_agent_proj/assets/install_falco

This should install falco, enable it and start the process automatically.

19.12. ACM fails with agent deployment

If you get an ACM failed on a Linux system, check first if the service service for wazuh-agent is running systemctl status wazuh-agent. If the service exists or is running all you need to do is to start the shipper from UI ('Host Edit' section).

Else if the service doesn’t exist then just try to install wazuh-agent via yum service i.e. yum install wazuh-agent on the client side.

From the ACSIA server terminal run the following steps as acsia user:

  • acsia_admin_query hosts (identify the host ID)

  • acsia_admin_query "update acsia_json_entry_ephemeral_command set status='NEW' where host_id=HOST_ID"

The above steps should activate the failing component.


For any further information and queries please get in touch with our support team by contacting us via our website (https://4securitas.com) or using the email [email protected].

ACSIA is a product of 4Securitas Ltd.

Main Portal: https://4securitas.com For other ACSIA documentation see: ACSIA documentation

Copyright 2022 4Securitas Ltd