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.

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:

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.

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.

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:

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.

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.

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..

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.

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.

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.

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.

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

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.

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.

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.

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.

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 no-reply@example.com 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.

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.

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.

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.

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.

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):

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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:

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.

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:

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:

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

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.

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.

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:

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 you see something like the following:

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

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

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:

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 support@acsia.io.

ACSIA is a product of 4Securitas Ltd.

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

Copyright 2022 4Securitas Ltd