Componenti tecniche

Questo documento descrive il design e l'architettura di ACSIA XDR Plus e i principali componenti al suo interno. 

Piattaforma base

Il motore applicativo ACSIA viene eseguito su qualsiasi delle principali distribuzioni Linux e può essere implementato su una piattaforma fisica, virtuale, container o cloud. Per i requisiti hardware/software minimi/raccomandati, vi consigliamo di consultare la nostra ultima guida all'installazione, disponibile nella nostra knowledge base.

Il motore ACSIA 

Il motore analitico centrale di ACSIA è scritto nel framework Java Spring che comprende Spring Boot, Spring Data e Spring Rest.

Frontend di ACSIA 

Il frontend è un'interfaccia API REST che effettua chiamate al backend utilizzando una combinazione di React.js e del linguaggio "Material Design".

Sicurezza di ACSIA XDR Plus

ACSIA è dotata dei seguenti componenti di sicurezza integrati:

• OAuth2 - Accesso delegato sicuro
• Autenticazione a più fattori - Autenticazione a 2 fattori
• TLS per comunicazioni sicure tra i client
• Pwgen - Generatore di password forti casuali

Strumenti Open Source di ACSIA

Esistono diversi strumenti Open Source utilizzati dal motore analitico di ACSIA, tra cui i seguenti:

• Whois
• Postfix
• Python pip
• Binds-utils
• Wget
• Dsnif
• Bc
• Sysstat
• Httpd-tools
• Wazuh
• OSSec
• Elastic
• Kibana
• Logstash
• Lucene
• MySQL
• RabbitMQ
• Docker
• Falco
• ElasticBeats
• Ansible
• OpenSearch
• OpenDashboard

Metodo di virtualizzazione ACSIA

ACSIA utilizza Docker (Linux Containers) che è un metodo di virtualizzazione a livello di sistema operativo per l'esecuzione di più sistemi Linux isolati (container) su un host di controllo utilizzando un singolo kernel Linux.

Sistema di gestione della configurazione ACSIA

ACSIA utilizza Ansible per automatizzare il provisioning del software, la gestione della configurazione e l'implementazione dell'applicazione.

Database di ACSIA

ACSIA utilizza due database distinti, che per motivi di sicurezza sono separati come segue:

• MariaDB/MySQL
• MongoDB (Elastic)

ACSIA Message Broker

L'architettura ACSIA include RabbitMQ, il message broker open source più diffuso.

Ambiente SIEM

ACSIA utilizza gli strumenti Elastic Stack per il suo collettore di log centralizzato SIEM (Security Information and Event Management) insieme ai seguenti strumenti:

• Open Search
• OpenDashboard
• Lucene
• Logstash
• Wazuh
• ElasticBeats (log shippers)
• OSSEC agents (log shipper)

Firewall di ACSIA

ACSIA è dotato di un firewall incorporato basato sui singoli host. Il firewall ha caratteristiche innovative come l'eliminazione delle connessioni TCP stabilite, il divieto di indirizzi IP nella tabella di routing, quindi l'inserimento in blacklist e whitelist di indirizzi IP e il blocco di singoli utenti (su base host).

La funzione "Kill Connection" (basata sull'host) è implementata utilizzando il Berkeley Packet Filter (BPF) che fornisce un'interfaccia grezza ai livelli di collegamento dati, consentendo l'invio e la ricezione di pacchetti grezzi del livello di collegamento e quindi la possibilità di bloccare i pacchetti indesiderati nello stack TCP.

I client possono essere implementati con o senza agenti.

ACSIA XDR Plus è un'architettura client-server e può essere distribuita utilizzando un agente o in modalità Agentless. Il motore applicativo è dotato di uno stack Elastic integrato (Elasticsearch, Logstash e Kibana) e utilizza i Beats forniti da Elasticsearch come log shipper. 

Qual è la differenza tra operare con un client con l'agente o Agentless?

Quando si implementa l'agente, i prerequisiti in termini di porte e requisiti dell'utente del servizio sono minimi, cioè non c'è alcun prerequisito dell'utente del servizio e le porte sono consolidate in un'unica porta che è la 443 (https). Inoltre, l'agente funzionerà autonomamente nel caso in cui il dispositivo non sia in grado di raggiungere il motore/server ACSIA.

Un'altra differenza è che l'implementazione senza agente richiede l'apertura di più porte sui firewall (sia in entrata che in uscita) e la creazione di un utente del servizio con privilegi sui dispositivi collegati. 

Sia che si distribuisca ACSIA XDR Plus con un agente o che si operi in modalità agentless, la funzione dei Beats è quella di inviare i seguenti log all'applicazione ACSIA:

• System Logs
• Web Application Logs 
• Audit Logs 
• Network Traffic
• Kernel/Registry Logs
• Compliance Related Logs

Di seguito vengono descritte le modalità di funzionamento con e senza agenti:

Implementazione dei Client in modalità Agentless

L'unico caso in cui ACSIA XDR Plus interagisce con un client connesso è quando l'applicazione vuole bandire un indirizzo IP dannoso o quando l'utente finale seleziona un'opzione di rimedio fornita con gli avvisi (azioni immediate). ACSIA esegue queste operazioni tramite il suo account di servizio (SSH o RDP), quindi non è necessario alcun agente sul client per eseguire tali azioni. 

ACSIA utilizza shipper Elastic Stack e agenti OSSEC/Wazuh per ricevere i log e il traffico dai client. Gli shipper sono chiamati Beats e comprendono:

• winlogbeat (log eventi di Windows)
• packetbeat (traffico di rete)
• falco (log del traffico del kernel)
• auditbeat (log di audit)
• filebeat (syslog principali e log delle webapp)
• ossec (log di sicurezza e di audit)

Le seguenti porte tra il server ACSIA e i client devono essere aperte: le porte 22 TCP (per i client Linux) e 5986 TCP (per i client Windows) tra il server ACSIA e i client devono essere aperte per l'uso da parte dei playbook Ansible per distribuire i Beats (shippers) sui client e per l'esecuzione di azioni di riparazione come il blocco di indirizzi IP offensivi, il blocco degli utenti, ecc. Le porte tra i client e il server ACSIA devono essere aperte a 1514 UDP, 1515 TCP e 5044 TCP. 

ACSIA richiede la creazione di un utente di servizio su ogni client (può essere centralizzato utilizzando LDAP o AD, se disponibile) per inviare i playbook di Ansible.

L'agente client

Un agente client è disponibile a partire dalla versione 4 di ACSIA XDR Plus. Con l'implementazione con l'agente, i Beats sono riuniti in un unico pacchetto per i sistemi operativi Windows, Linux e MAC OS. I pacchetti possono essere scaricati dall'interfaccia utente di ACSIA (per i dettagli, consultare la guida ufficiale) e si installeranno automaticamente una volta fatto partire il file scaricato. A differenza della modalità Agentless, l'agente ACSIA consolida tutte le porte di comunicazione in una porta unificata 443 (HTTPS) e 444 (TCP/UDP). L'agente non richiede un utente di servizio per ACSIA.

Log Shipping

I Beat forniti da Elastic Search sono utilizzati come log shipper per trasferire i vari file di log al Security Information Event Manager di ACSIA. I volumi di dati coinvolti sono minimi (misurati in kilobit), pertanto non vi è alcun sovraccarico di prestazioni sul client o sulla rete durante l'implementazione di ACSIA. 

Tutto il traffico dei client è crittografato con Transport Layer Security (TLS V1.2 o successivo) utilizzando i certificati del client server.

Design dell'architettura

High Level Architectural Block View

Il prodotto ACSIA XDR Plus incorpora le funzionalità di Endpoint Detection and Response (EDR) con Intrusion Prevention (IPS) e Intrusion Detection Systems (IDS) in un'unica piattaforma, il tutto supportato dal nostro sistema Security Information and Event Management (SIEM) in tempo reale. 

Abbiamo poi migliorato l'Extended Detection and Response (XDR) includendo un feed predittivo di Threat Intelligence che vieta l'accesso alla rete a indirizzi IP errati, nodi di uscita anonimi e fonti di malware. Eliminando così la possibilità che queste fonti di minaccia possano vedere la vostra infrastruttura di rete. Per questo motivo il prodotto viene definito ACSIA XDR Plus. 

I dati dell'endpoint non verranno estratti dall'ambiente aziendale, compresi i dati di telemetria (ACSIA verrà installato dal cliente e non raccoglierà né esporterà alcun dato del cliente). L'applicativo ACSIA viene installato sull'infrastruttura del cliente senza alcuna azione (condivisione, distribuzione, copia, ecc.).

Fig 1: Architectural Block View 

L'integrazione delle funzioni predittive, proattive, EDR, IDS e IPS in un unico Application Engine facilita l'acquisizione e la correlazione di più tipi di eventi per un rilevamento analitico di qualità superiore, una correzione automatizzata e un miglioramento continuo grazie all'intelligenza artificiale e al machine learning. 

Diagramma del flusso di lavoro interno di ACSIA XDR Plus

Il diagramma del workflow (fig. 2) illustra il flusso architetturale di ACSIA e i punti di integrazione con i componenti open source descritti in precedenza in questo documento. 

Mostra anche il flusso di lavoro del server ACSIA, in cui i dati provenienti dai client vengono ricevuti da "logstash" e memorizzati in forma non strutturata nel database "opensearch". Il flusso di dati viene accodato e gestito dal broker di messaggi "RabbitMQ" che notifica l'analizzatore contenente il motore centrale di ACSIA. 

I dati analizzati vengono arricchiti e visualizzati nell'interfaccia web di ACSIA (come avvisi, messaggistica, notifiche ecc.) e archiviati in un database MySQL. 

Kibana formatta tutti i dati OpenSearch e li presenta all'utente finale.

Fig 2: Diagramma del Workflow interno

Diagramma del flusso di dati del client agentless ACSIA XDR Plus

Il seguente diagramma di flusso (fig. 3) mostra come i client Agentless interagiscono con ACSIA inviando i loro log in tempo reale. Tutti i componenti open source utilizzati da ACSIA vengono eseguiti all'interno di container Docker, con la sola eccezione del motore analitico di ACSIA.

 Fig 3: Client Data flow Diagram

La figura sopra mostra lo stack ACSIA con OpenSearch, OpenDashboard, Logstash, OSSEC, RabbitMQ e MySQL implementati come immagini di container Docker, mentre il motore centrale e l'interfaccia utente sono installati sulla macchina virtuale.

Diagramma del flusso di dati dell'agente client ACSIA XDR Plus

Il seguente diagramma di flusso (fig. 4) mostra come l'implementazione dell'agente interagisce con ACSIA inviando i propri log in tempo reale attraverso una porta sicura consolidata, come la 443. Tutti i componenti open source utilizzati da ACSIA vengono eseguiti all'interno di container Docker, con la sola eccezione del motore analitico di ACSIA.

Fig 4: Client Agent Data flow Diagram