Questa guida si applica solo ad ACSIA XDR Plus versione 5.0.0 e successive
1. Introduzione
Il server può essere distribuito in un ambiente fisico o virtuale. Questa guida ti mostrerà i prerequisiti per l'installazione di ACSIA, i dettagli dell'installazione e della configurazione del prodotto, l'amministrazione, la risoluzione dei problemi di deployment e le domande frequenti.
2. Cos'è ACSIA XDR Plus?
ACSIA è un'applicazione automatizzata di intelligence sulla sicurezza informatica che consente alle organizzazioni di proteggersi da attacchi dannosi e entità non autorizzate che prendono di mira i propri dati.
3. Installazione e configurazione
Come qualsiasi altra applicazione software, ACSIA ha bisogno di alcuni requisiti preliminari per comunicare con i clienti connessi e svolgere i suoi compiti.
3.1.Prerequisiti
3.1.1. Requisiti minimi
La piattaforma ACSIA Server richiede le seguenti specifiche minime:
- Il server può essere distribuito in un ambiente fisico o virtuale
- Nel caso di un ambiente virtuale, il server avrà bisogno di una Macchina Virtuale, e potrà funzionare su qualsiasi hypervisor scelto (VMWare, HyperV, VirtualBox, Proxmox, ecc...) ma non su container (Docker, Kubernetes, LXD, LXC, Vagrant, ecc...)
-
È possibile utilizzare una qualsiasi delle seguenti distribuzioni Linux: è preferibile Ubuntu 20.04
-
16GB RAM (negli ambienti virtuali, devono essere dedicati)
-
8 vCPU
-
200 GB SSD Storage (come minimo a seconda della politica di conservazione dei log)
- Connettività di rete (per scaricare e installare il server, ricevere i nostri feed di intelligence sulle minacce, connettersi con i client, aggiornare il sistema e verificare la licenza)
-
Partizionamento: non è richiesto un partizionamento specifico per ACSIA VM; tuttavia, quando ACSIA è ospitato in locale (al di fuori delle piattaforme cloud), si consiglia vivamente di configurare una partizione LVM in modo che lo spazio di archiviazione possa essere facilmente esteso
La specifica precedente supporterebbe un carico di lavoro standard tipico di oltre 100 host monitorati. ACSIA scala in modo relativamente lineare, quindi risorse aggiuntive supporteranno ambienti client più grandi.
ACSIA Client (con l'agente) richiede le seguenti specifiche minime:
- L'agente può essere distribuito su tutti i sistemi operativi (anche nelle macchine virtuali), ma consigliamo vivamente di utilizzare sistemi aggiornati e che il nostro supporto può essere limitato su sistemi operativi che non sono ufficialmente supportati dai fornitori.
- Al momento, non abbiamo requisiti minimi per CPU, RAM e Storage perché i nostri agenti sono estremamente leggeri in termini di consumo di hardware. Suggeriamo di eseguire l'installazione su una macchina con almeno 2GB di spazio libero
- Funziona su qualsiasi piattaforma Linux con kernel superiori alla versione 2.6, Windows e macOS con qualsiasi distribuzione.
- Connettività di rete verso ACSIA Server (come di seguito specificato)
3.1.2. Interfaccia utente Web porte di rete
Sorgente | Destinazione | Protocollo | Porta | Note |
Qualsiasi PC che gestisce ACSIA | IP del server ACSIA | TCP | 443 |
Usato per HTTPS
|
IP del server ACSIA | license.acsia.io | TCP | 5150 |
Attivazione della licenza
|
L'unica richiesta di ACSIA prima e dopo l'installazione è la connettività abilitata per TLS alla porta 5150 (TCP) su license.acsia.io. Questa connettività è sempre richiesta (verifica della coppia di chiavi privata e pubblica per la licenza), sebbene ACSIA consenta fino a 48 ore di perdita di connessione prima che entri in uno stato senza licenza. L'unica eccezione a questo requisito è dove ACSIA viene distribuito da Amazon AWS Marketplace.
Inoltre, ACSIA richiede l'accesso a Internet durante l'installazione per gli aggiornamenti, i feed di informazioni sulle minacce e gli aggiornamenti delle licenze.
3.1.3. Porte client-server ACSIA con installazione dell'agente
Se si sceglie di configurare l'agente ACSIA sui client (server o workstation), l'unico requisito affinché l'agente possa comunicare con il server ACSIA è la porta TCP 443 (HTTPS) e 444 (TCP/UDP). Se queste porte non sono aperte, assicurarsi che siano aperte.
Sorgente | Destinazione | Protocollo | Porta | Note |
Qualsiasi host con l'agente ACSIA | IP del server ACSIA | TCP | 443 | Utilizzato per le connessioni |
Qualsiasi host con l'agente ACSIA | IP del server ACSIA | TCP & UDP | 444 | Used per i pull |
Qualsiasi host con l'agente ACSIA | wimi.xdrplus.com | TCP | 443 | Used per il pull dell'IP |
3.1.4. Configurazione agentless delle porte client-server di ACSIA
Il server ACSIA comunica con i client attraverso le seguenti porte; pertanto, se si sceglie l'implementazione agentless, è necessario abilitare le seguenti regole del firewall:
Sorgente | Destinazione | Protocollo | Porta | Note |
Qualsiasi host con l'agente ACSIA | IP del server ACSIA | TCP | 1515 | Utilizzato per le connessioni |
Qualsiasi host con l'agente ACSIA | IP del server ACSIA | UDP | 1514 | Utilizzato per le connessioni |
Qualsiasi host con l'agente ACSIA | IP del server ACSIA | TCP | 5044 | Utilizzato per le connessioni |
IP del server ACSIA | Qualsiasi host Windows | TCP | 5986 | Usato per i Push |
IP del server ACSIA | Qualsiasi host Linux | TCP | 22 | Usato per i Push |
3.1.5. Configurazione del Proxy ACSIA - Solo se si dispone di Proxy
Se avete un proxy e i vostri server (ACSIA VM e il vostro server da monitorare) per uscire su Internet, applicate le seguenti istruzioni.
3.1.5.1 Impostazione del Proxy in modo permanente per tutti gli utenti
Per impostare in modo permanente l'accesso proxy per tutti gli utenti, è necessario modificare il file /etc/environment
.
Step 1 - Per prima cosa, aprire il file in un editor di testo:
sudo nano /etc/environment
Step 2 - Quindi, aggiornate il file con le stesse informazioni aggiunte al file .bashrc nello scenario precedente:
export HTTP_PROXY="[username]:[password]@[proxy-web-or-IP-address]:[port-number]"
export HTTPS_PROXY="[username]:[password]@[proxy-web-or-IP-address]:[port-number]"
export FTP_PROXY="[username]:[password]@ [proxy-web-or-IP-address]:[port-number]"
...
export NO_PROXY="localhost,127.0.0.1,::1"
Step 3 - Salvare il file e uscire. Le modifiche verranno applicate all'accesso successivo.
3.1.5.2 Impostazione del proxy per APT
Su alcuni sistemi, la command-line APT necessita di una configurazione proxy separata, perché non utilizza le variabili d'ambiente del sistema.
Step 1 - Per definire le impostazioni del proxy per APT, creare o modificare (se esiste già) un file chiamato apt.conf
nella directory /etc/apt
:
sudo nano /etc/apt/apt.conf
Step 2 - Aggiungere le seguenti righe al file:
Acquire::http::Proxy "http://[username]:[password]@ [proxy-web-or-IP-address]:[port-number]";
Acquire::https::Proxy "http://[username]:[password]@ [proxy-web-or-IP-address]:[port-number]";
Step 3 - Salvare il file e uscire. La configurazione verrà applicata dopo un riavvio.
Nell'opzione NO_PROXY
, oltre ai parametri specificati sopra, è necessario aggiungere le reti e le sottoreti interne in cui si trovano i dispositivi monitorati (la rete dei server o dei PC). In caso contrario, si verificheranno problemi di connettività tra ACSIA e tali reti quando si cercherà di aggiungerle ai servizi monitorati da ACSIA. È infatti improbabile che il proxy riesca a raggiungere tali reti.
Qualsiasi modifica che riguardi le variabili di cui sopra deve essere comunicata ad ACSIA tramite il comando configureHttpProxy
seguito da acsia_restart
(questo è per quando l'installazione di ACSIA è già stata completata).
3.2. Installazione del Server ACSIA
Preparare una macchina virtuale Linux (ad esempio, Ubuntu 20.04 è attualmente supportato, controllare le note di rilascio di ACSIA) per ospitare il server ACSIA e assicurarsi che il sistema sia aggiornato.
Una volta soddisfatti tutti i prerequisiti, l'installazione di ACSIA può iniziare. Se i requisiti per l'installazione non sono soddisfatti, l'installazione fallirà e verrà fornita una spiegazione dei prerequisiti non soddisfatti.
I clienti con una licenza ACSIA valida riceveranno dal team di supporto 4Securitas un pacchetto di installazione per scaricare lo script di installazione principale acsia_prepare e un file aggiuntivo contenente le credenziali, compresa la licenza.
Seguire scrupolosamente le istruzioni fornite in questa guida per installare la configurazione server-client di ACSIA.
3.2.1. Guida all'installazione del server ACSIA
root
, copiare acsia_prepare
e le credentials.txt
che vi sono state fornite.acsia_prepare
come segue, assicurarsi che lo script sia eseguibile utilizzando il comando:chmod +x acsia_prepare
./acsia_prepare
Seguite le istruzioni fornite sullo schermo e, al termine, eseguite quanto segue:
./acsia_app/bin/acsia_install
Se tutti i requisiti preliminari sono soddisfatti secondo le linee guida, il server ACSIA sarà completamente installato in circa 5-6 minuti.
In caso di problemi, consultare la sezione Risoluzione dei problemi di questa guida, consultare le nostre guide avanzate alla risoluzione dei problemi nella nostra Knowledge Base o contattare il nostro team di supporto inviando un ticket da questo portale. Quando si richiede assistenza, si prega di fornire il maggior numero di informazioni possibili (ad esempio, screenshot, registri, ecc.); ogni dettaglio ci aiuterà a risolvere più rapidamente il problema.
Al termine del processo di installazione, dovreste avere sul vostro terminale le credenziali per il primo utente amministratore per accedere all'interfaccia web, qualcosa di simile a quanto segue:
ACSIA web and Dashboards
Admin interface: https://192.168.1.246:443
Username: admin@acsia.io
Password: kzuh21ybnsdy1=ui12b5!2iutRIf123kjojb
Una volta terminata l'installazione del server, l'installazione del client continuerà in background (il server ACSIA diventa il primo client da monitorare). Attendere l'inizializzazione del motore al termine dell'installazione del client.
Si consiglia vivamente di cambiare al più presto le password generate con altre nuove e di conservarle correttamente.
Per controllare lo stato di avanzamento dell'inizializzazione di ACSIA, eseguire:
acsia_tail_f
Se si riceve l'errore acsia_tail_f: command not found
significa che non si sta utilizzando l'utente corretto, quindi eseguire:
sudo su - acsia
Questo cambierà il vostro account in quello di acsia, permettendovi di eseguire tutti i comandi necessari.
Al termine dell'installazione del client, dovrebbe essere visualizzato il seguente messaggio in acsia_tail_f
:
2022-07-10 15:52:21.254 INFO 29440 --- [main] com.forsecuritas.AcsiaLauncher : *************** SPRING APPLICATION RUNNING *************************
Il messaggio sopra riportato indica che il motore è pronto e funzionante. Ora è possibile accedere all'interfaccia web con le credenziali fornite e attivare la licenza subito dopo l'accesso.
Al termine dell'installazione, è strettamente necessario avere a disposizione tutti i comandi di servizio di ACSIA per uscire dalla sessione in esecuzione e rientrare, in modo che le variabili d'ambiente possano essere tutte caricate.
4. Comandi di servizio ACSIA
Come già menzionato, tutti i comandi di servizio di ACSIA, compresi i servizi di avvio/arresto e i suggerimenti per la risoluzione dei problemi, si trovano nella cartella /acsia_app/bin
in $ACSIA_HOME
.
Di seguito sono riportati alcuni comandi di servizio utilizzati di frequente.
acsia_stack_status
acsia_stack_start
acsia_stack_stop
acsia_start
4.1. Elenco completo dei comandi di servizio
È possibile trovare tutti i comandi di servizio disponibili di ACSIA all'indirizzo /home/acsia/acsia_app/bin
.
Di seguito è riportata una tabella contenente tutti i comandi con le relative descrizioni:
Comando | Descrizione |
acsia_adapter_beanstalk.py | Adattatore AWS Elasticbeanstalk per ACSIA |
acsia_adapter_ips.sh | Adattatore per componenti IPS per AWS elasticbeanstalk |
acsia_admin_check_requirements.sh | Controlla i prerequisiti ACSIA |
acsia_admin_docker_subnet | Cambia la subnet di docker |
acsia_admin_health.sh | Controlla lo stato di salute di ACSIA |
acsia_admin_logs | Mostra i log dei componenti ACSIA |
acsia_admin_query | Esegui la query del DB MySQL |
acsia_admin_reset_password | Recupera il link delle credenziali utente ACSIA da resettare |
acsia_admin_unlock_indices | Sblocca gli indici se il disco ACSIA è saturo per mancanza di spazio |
acsia_ban_script | Banna un indirizzo IP |
acsia_beanstalk_ban | Banna l'IP tramite AWS Elasticbeanstalk |
acsia_beanstalk_find_banned_ip_rule | Elenca o trova gli indirizzi IP bannati in AWS Elasticbeanstalk |
acsia_beanstalk_manage_service | Gestisci i servizi e la configurazione di ACSIA in AWS Elasticbeanstalk |
acsia_beanstalk_unban | Rimuovi il ban per un indirizzo IP in AWS Elasticbeanstalk |
acsia_change_ip | Modifica l'indirizzo IP del server ACSIA |
acsia_deploy_ssl_certs | Installa il certificato SSL/TLS sul server ACSIA se è stato assegnato un sottodominio |
acsia_download | Scarica il pacchetto ACSIA per l'installazione (obsoleto nella v4) |
acsia_elastic_restart | Riavvia Elasticsearch |
acsia_elastic_start | Avvia Elasticsearch |
acsia_elastic_status | Controlla lo stato di Elasticsearch |
acsia_elastic_stop | Arresta Elasticsearch |
acsia_elastic_tail_f | Controlla i log di Elasticsearch |
acsia_export_logs | Esporta i log di ACSIA |
acsia_fix_kernel_inspector_wrong_version | Correggi la versione errata del kernel |
acsia_install | Installa ACSIA |
acsia_ip | Recupera l'indirizzo IP del server ACSIA |
install_acm_app.sh | Installa il modulo ACM quando fallisce durante la configurazione dei client |
acsia_normal_ban | Banna un indirizzo IP |
acsia_normal_manage_service | Configura e gestisci i servizi |
acsia_normal_unban | Togli il ban da un indirizzo IP |
acsia_reconfigure_acm | Riconfigura il modulo ACM per il client ACSIA per un IP specifico |
acsia_reconfigure_acm_all | Riconfigura il modulo ACM per ACSIA per tutti i client collegati. |
acsia_report | Genera ed esporta i rapporti sugli incidenti per l'ACSIA. |
acsia_restart | Riavvia solo il motore ACSIA |
acsia_set_private_ip | Assegna un indirizzo IP privato al server ACSIA |
acsia_stack_restart | Riavvia tutti gli stack con tutti i componenti, compreso il motore. |
acsia_stack_start | Avvia tutti gli stack con tutti i componenti, compreso il motore |
acsia_stack_status | Controlla lo stato di tutti gli stack con tutti i componenti, compreso il motore |
acsia_stack_stop | Arresta gli stack con tutti i componenti, compreso il motore |
acsia_start_bg | Avvia ACSIA in background |
acsia_status | Mostra lo stato ACSIA |
acsia_stop | Arresta solo il motore ACSIA |
acsia_tail_f | Mostra i log ACSIA in tempo reale |
acsia_unban_script | Togli il ban da un indirizzo IP |
acsia_uninstall | Disinstalla ACSIA |
acsia_update | Aggiorna ACSIA |
admin_insert_admin_user | Aggiungi un utente admin per ACSIA |
install_falco | Installa il modulo kernel Falco |
kibana_default_index | Ripristina gli indici predefiniti di Kibana |
kibana_import_saved_objects | Importa gli oggetti salvati, personalizzazione su Kibana |
mfa_acsia_install | Attiva e abilita 2FA/MFA |
mfa_acsia_uninstall | Disattiva 2FA/MFA |
mfa_ssh_install | Attiva 2FA/MFA per il login SSH come utente acsia sul server |
mfa_ssh_qrcode | Genera o mostra il codice QR SSH per 2FA/MFA |
mfa_ssh_uninstall | Disattiva SSH 2FA/MFA |
setInternalIP | Imposta l'IP interno per il server ACSIA |
ssl_configuration | Controlla e configura SSL/TLS |
winrm_remote | Controlla Ansible WinRM per i client Windows |
5. Configurazione e abilitazione dell'invio di e-mail da parte di ACSIA
Affinché ACSIA possa inviare notifiche via e-mail, compresa l'e-mail per l'impostazione dell'account di amministrazione, è necessario che sia in grado di comunicare con il proprio server di posta. A tal fine, le e-mail provenienti dal server ACSIA devono essere inserite nella white-list del server di posta e dei filtri antispam (se ne avete uno), ecc.
Se non si inseriscono nella white-list le e-mail provenienti dal server ACSIA, è probabile che vengano rimbalzate o inserite nella cartella spam (questo perché l'e-mail proviene da un server e non da un vero account di posta elettronica), quindi se non si ricevono e-mail provare a seguire le seguenti linee guida o controllare la sezione Risoluzione dei problemi di questa guida.
Se gli utenti hanno problemi a ricevere le e-mail di creazione dell'account, l'amministratore può eseguire il comando acsia_admin_reset_password
per recuperare il link che consente di reimpostare le proprie credenziali.
5.1. Impostare e configurare un account e-mail reale come mittente
È possibile utilizzare un account di posta elettronica autentico (ad esempio, e-mail aziendale, Gmail privato, Yahoo, ecc.) e impostarlo come mittente per ricevere le notifiche via e-mail (questo eviterà che le notifiche di ACSIA vengano respinte o inserite nei filtri antispam) senza problemi.
Per impostare e configurare un account di posta elettronica su ACSIA, accedere alla sezione Settings→Email
e aggiungere i dati del proprio account di posta elettronica.
6. Configurazione del certificato SSL per l'applicativo Web ACSIA
Per impostazione predefinita, ACSIA genera certificati SSL autofirmati per la navigazione sicura. I certificati autofirmati sono configurati utilizzando gli indirizzi IP di ACSIA (esterni o locali, se forniti). Se si desidera configurare ACSIA con una CA adeguata e avere un proprio certificato SSL, è possibile farlo durante l'installazione di ACSIA o in una fase successiva. ACSIA richiede che il certificato e la chiave siano forniti in due file: la chiave privata e il certificato pubblico (entrambi in formato .pem).
- Configurare il certificato durante l'installazione: durante l'installazione di ACSIA, utilizzando lo script
acsia_install
aggiungere semplicemente i parametri aggiuntivi:--certificate /path/to/cert.pem
,--key /path/to/key.pem
e--domain my.domain.com
. Tutti e tre devono essere presenti, altrimenti il programma di installazione mostrerà un errore. - Configurazione post-installazione: è stato fornito un nuovo script
acsia_deploy_ssl_certs
che accetta gli stessi parametri dello step precedente:--certificate
,--key
, e--domain
. Una volta configurato il tutto, sarà necessario eseguireacsia_stack_restart
per tutti i componenti, in modo che questi nuovi certificati vengano acquisiti.
Se non volete acquistare certificati SSL, potete utilizzare Let's Encrypt con Certbot; tuttavia, queste istruzioni non sono fornite in questa guida, quindi vi consigliamo di controllare i rispettivi siti web.
6.1. Integrazione di Amazon AWS Elastic Beanstalk
ACSIA è dotato della funzione AWS Elastic Beanstalk Integration per monitorare le applicazioni in esecuzione su Elastic Beanstalk.
Se si dispone di applicazioni in esecuzione su Elasticbeanstalk e si desidera che ACSIA le monitorizzi e le protegga, eseguire il seguente comando nel terminale: acsia_adapter_beanstalk.py
Vi verrà richiesto di fornire le seguenti informazioni dal vostro ambiente AWS:
-
ID della chiave di accesso AWS (IAM User)
-
Chiave di accesso segreta AWS (IAM User Secret)
-
Nome della regione predefinita (regione in cui si trova Beanstalk)
-
Formato di output predefinito: (può essere JSON o testo, ma JSON è preferibile)
-
ACL (ID della lista di controllo degli accessi alla rete nella VPC di Beanstalk)
Dopo l'installazione di cui sopra, vi verrà assegnato un indirizzo IP (IP interno/privato). L'indirizzo IP può essere recuperato in seguito eseguendo il comando: acsia_adapter_ip.sh
.
Accedere alla Console Web UI di ACSIA e aggiungere l'host Linux utilizzando l'indirizzo IP fornito in precedenza. (Getting Started->Start->Linux
).
L'installazione potrebbe terminare con alcuni avvisi e una configurazione parziale. Non fatevi prendere dal panico; questi avvisi potrebbero non essere gravi e il monitoraggio in genere funzionerà.
Assicurarsi di includere il file acsia.config
fornito nel pacchetto di avvio dell'applicazione elasticbeanstalk (pacchetto Kickstarter).
Dopo aver completato tutti i passaggi sopra descritti, accedere a un nuovo terminale sul server ACSIA e riavviare ACSIA eseguendo il comando acsia_restart
. Questo per assicurarsi che ACSIA raccolga tutte le modifiche e i file di configurazione.
7. Aggiornamento di ACSIA
L'aggiornamento di ACSIA è ragionevolmente semplice e immediato.
Per effettuare l'aggiornamento, tutto ciò che occorre fare è eseguire il seguente comando nel terminale
come user acsia
: acsia_update
Per ottenere gli aggiornamenti sono necessari il nome utente e la password di ACSIA. Queste credenziali sono solitamente fornite nella stessa e-mail con cui si ricevono le istruzioni per la licenza.
Si consiglia di eseguire gli aggiornamenti ACSIA dal terminale invece di utilizzare la funzione di aggiornamento dell'interfaccia Web. In questo modo si ottiene una maggiore chiarezza e controllo del processo, con informazioni più dettagliate sui codici di errore. Le versioni più importanti di ACSIA includono generalmente aggiornamenti dello strumento principale. Per questo motivo, quando si eseguono questi aggiornamenti, si consiglia di eseguire un arresto e un avvio di tutto lo stack. È possibile farlo eseguendo il comando: acsia_stack_stop && acsia_stack_start
8. Attivazione della licenza
Dopo aver completato l'installazione, si dovrebbe essere in grado di accedere all'applicazione ACSIA tramite un browser web. La prima azione da compiere è l'attivazione della licenza.
Se non si attiva la licenza, non si potrà fare nulla perché l'applicazione funzionerà al minimo delle sue capacità o non funzionerà affatto. Per attivare la licenza, copiare il license code
fornito e accedere al menu utente (in alto a destra, o è l'indirizzo e-mail o il nome) facendo clic suSettings
dal menu e quindi selezionare la scheda "Licenza", dove è possibile aggiungere/attivare la licenza.
La licenza può essere richiesta tramite ticket dal nostro portale di supporto https://support.4securitas.com o, in caso di problemi di accesso, contattate il supporto via e-mail all'indirizzo support@acsia.io.
9. Metodi di autenticazione utilizzati in ACSIA
ACSIA è dotato di diversi meccanismi di autenticazione integrati.
ACSIA dispone di metodi di autenticazione tradizionali come nome utente e password e autenticazione a più fattori (2FA).
9.1. Autenticazione a due fattori
ACSIA offre un metodo per l'autenticazione a due fattori che può essere implementato durante e dopo l'installazione per una maggiore sicurezza. L'autenticazione a due fattori (2FA) è disponibile per gli accessi SSH e per l'interfaccia web di ACSIA.
Il 2FA può essere abilitato per tutti gli utenti navigando dall'interfaccia Web a Settings→2FA
.
Come si può vedere dall'immagine qui sopra, il tempo di caricamento della pagina di login può richiedere fino a un minuto, quindi si prega di attendere e di non aggiornare la pagina.
9.2. Abilitazione di 2FA per SSH dalla riga di comando
Se si desidera applicare la 2FA all'utente acsia
è possibile farlo durante l'installazione. Le funzioni 2FA possono essere attivate o disattivate in qualsiasi momento rispettivamente con i comandi mfa_ssh_install
emfa_ssh_uninstall
. Se abilitato, l'utente acsia
del sistema avrà una chiave segreta TOTP (Time-based One-Time Password). Si consiglia di utilizzare strumenti di gestione dei token 2FA come Google Authenticator o FreeOTP. Se questa funzione è abilitata, durante l'installazione viene stampato sullo schermo un codice QR.
Quando è abilitata, è possibile utilizzare solo l'autenticazione basata su chiave (ssh-key) per l'autenticazione della sessione. La password + 2FA non è supportata, poiché provoca effetti collaterali indesiderati.
Al termine dell'installazione o durante l'esecuzione di mfa_ssh_qrcode
, il codice QR verrà visualizzato sul terminale e potrà essere scansionato con il gestore di token 2FA preferito.
9.3. Abilitazione della 2FA per l'accesso all'interfaccia web di ACSIA dalla linea di comando
Sebbene la 2FA SSH possa essere attivata o disattivata a scelta, si consiglia vivamente di attivare la 2FA per l'interfaccia utente, soprattutto se gli utenti ACSIA accedono all'interfaccia da Internet. Se la 2FA è abilitata per l'accesso alla WebApp, tutti gli utenti riceveranno un codice QR (che dovrà essere scansionato da, ad esempio, Google Authenticator, FreeOTP, ecc.) e dovranno presentare la chiave TOTP ogni volta che accederanno all'applicazione insieme alle credenziali di accesso tradizionali, come nome utente e password.
9.4. Accesso alla Dashboard di OpenDashboard e all'autenticazione
Il visualizzatore OpenSearch OpenDashboard fa parte dello stack ACSIA. Per accedere alle applicazioni e alle dashboard OpenSearch, viene richiesta la password utente e l'autenticazione. Gli utenti devono indicare il proprio nome utente/password ACSIA ogni volta che tentano di visualizzare le dashboard. Il nome utente e la password sono generati automaticamente dalle credenziali di accesso all'interfaccia web di ACSIA.
10. Preparazione dei server per la connessione ad ACSIA
ACSIA supporta i sistemi operativi Linux, Windows e MAC OS.
10.1. Requisiti preliminari
Se si intende monitorare i propri sistemi senza utilizzare l'Agente ACSIA (modalità agentless), vi sono alcuni requisiti preliminari, come un account utente di servizio con privilegi amministrativi. Questo utente di servizio può essere un account amministratore locale, un Domain Controller (per i sistemi Windows) o un account LDAP (per i sistemi Linux). Se invece si sceglie la modalità con agente, è sufficiente eseguire l'agente sull'end-point.
Se la vostra infrastruttura IT è ospitata su Google Cloud (Metadata Page), potete saltare i passaggi seguenti aggiungendo le chiavi SSH ACSIA al vostro progetto dalla console di Google. AWS ha una configurazione simile che può essere eseguita tramite OpsWorks.
10.2. Collegamento di un client Linux
10.2.1. Requisiti
-
Kernel 2.6 o successivo
-
Python 2.7 o successivo
-
Account utente
acsia
con privilegi Sudo e senza password (solo per agentless)
10.2.2. Distribuzione di ACSIA tramite un agente
Per tutti i client Linux, Windows e MAC OS in cui si è scelto di installare il client con l'agente, è sufficiente navigare nell'interfaccia web di ACSIA Hosts→Add Host
, selezionare il sistema operativo, ossia Linux, Windows o MAC, e scegliere Use The Agent
dove è possibile scaricarlo.
Si tenga presente che gli agenti possono essere scaricati per un solo client, il che significa che lo stesso agente scaricato dall'interfaccia utente non può essere utilizzato per un secondo host. Per ogni host, è necessario scaricare un nuovo agente, perché ogni agente ha il suo token (per motivi di sicurezza). Se si desidera scaricare un agente per più client, è possibile utilizzare la funzione "Bulk Agent Deployment", dove è possibile selezionare il numero di client che si desidera distribuire con il singolo agente.
Copiare l'agente scaricato sul dispositivo client per l'installazione ed eseguirlo come root su Linux/MAC e amministratore su Windows utilizzando PowerShell. Assicurarsi di aggiungere il permesso di esecuzione all'agente per Linux/MAC.
Se tutti i prerequisiti sono presenti dopo l'installazione dell'agente sui client, si vedranno i client elencati automaticamente (popolati) nell'interfaccia utente di ACSIA nella sezione "Hosts".
Gli agenti client si connettono al server ACSIA tramite un'API, senza requisiti di creazione da parte dell'utente o porte multiple da aprire sul firewall (tutte le porte sono consolidate in 2 porte, 443 (TCP) e 444 (UDP/TCP), come richiesto al momento della scelta dell'agente).
Gli agenti ACSIA scaricati dall'interfaccia utente hanno token che scadono dopo sette giorni e ogni download è valido per un solo dispositivo (ciò significa che per ogni dispositivo è necessario scaricare un nuovo agente o scegliere l'opzione di installazione massiva dell'agente se si desidera utilizzare un singolo download per più dispositivi). Se l'agente fornito non funziona, si prega di generare un nuovo agente perché molto probabilmente si tratta di un problema legato alla scadenza del token.
10.2.3. Distribuzione di ACSIA in modalità agentless su sistemi Linux
Se si desidera distribuire ACSIA nei client senza un agente, si consiglia di eseguire i seguenti passaggi a seconda della distribuzione:
Per CentOS / RHEL Linux
Creazione dell'utente di servizio ACSIA su sistemi CentOS
o RHEL
useradd -m -d /home/acsia -c "ACSIA Service User" -G wheel acsia
Nel comando precedente, stiamo creando un utente acsia
fornendogli una home directory, assegnandogli un nome e assegnandolo al gruppo amministrativo "wheel".
Seguirà l'abilitazione dei permessi Sudo senza password, che si ottiene modificando il file /etc/sudoers
e rimuovendo il commento #
dalla seguente stringa:
%wheel ALL=(ALL:ALL) NOPASSWD:ALL
Per Debian / Ubuntu Linux
Creazione dell'utente di servizio ACSIA su sistemi Debian
o Ubuntu
useradd -m -d /home/acsia -s /bin/bash -G sudo acsia
Controllare poi in /etc/sudoers
e rimuovere #
dalla stringa seguente (aggiungerla se non è presente):
%sudo ALL=(ALL:ALL) NOPASSWD:ALL
10.2.4. Chiave SSH
Una volta completata la creazione dell'utente di servizio sui server Linux, il passo successivo è ottenere la chiave ssh dall'interfaccia web di ACSIA. Per ottenere la chiave, andare nell'area Hosts→Add Host
, selezionare Linux
e sarà possibile vedere/copiare la chiave ssh.
Copiare/esportare la chiave ssh e importarla nell'utente di servizio ACSIA creato in precedenza (su ogni server), prestando attenzione ai passaggi relativi ai permessi dei file .ssh
e authorized_keys
.
Un modo tipico per farlo sarebbe (come utente acsia
):
echo "paste here the key" > .ssh/authorized_keys
chmod 700 .ssh && chmod 600 .ssh/authorized_keys
Questo utente di servizio ACSIA viene utilizzato per due scopi diversi:
- Distribuire gli shipper di elastic stack (filebeat, auditbeat, packetbeat), l'agente ossec/wazuh e il modulo kernel falco.
- Per consentire ad ACSIA di bloccare automaticamente le minacce e gli attacchi sul posto e di eseguire le opzioni di remediation messe in atto dall'utente.
Entrambi i passaggi sopra descritti vengono eseguiti tramite playbook Ansible che vengono inviati automaticamente dal server ACSIA ai client (in questo modo si evita di completare manualmente l'installazione su ogni singolo client).
La chiave ssh a cui ci riferiamo è una chiave a 4096 bit generata casualmente da ACSIA durante l'installazione. Questa chiave può essere sostituita da una propria chiave, crearne una nuova o sostituirla con qualsiasi altra coppia di chiavi (ad esempio AWS EC2 keypair.pem). È a totale discrezione dell'utente.
10.3. Collegamento di un client Windows senza agente
Per gestire i server Windows in modalità agentless, WinRM deve essere installato, in esecuzione e in ascolto sui server Windows. Le istruzioni riportate di seguito sono esempi forniti da Ansible.
10.3.1. Requisiti
-
PowerShell 4.0+
-
Server Windows 2008 SP1+ (o Windows 7 SP1)
-
Account
acsia
locale o di dominio con privilegi amminstrativi o equivalenti -
Servizio WinRM attivo e funzionante
10.3.2. Domain Controller - Active Directory (senza agente)
Se i sistemi Windows fanno parte di AD/DC, ACSIA dispone di una funzione di integrazione per i Domsni Controller. È sufficiente eseguire il seguente script PowerShell sul DC primario:
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 } } }
Durante l'esecuzione dello script precedente, se si scopre che alcuni client DC non sono raggiungibili tramite il nome DNS, è sufficiente sostituire DNSHostName
con Name
.
Una volta che lo script di cui sopra è stato eseguito con successo, accedere alla sessione di avvio dell'interfaccia utente di ACSIA (Getting Started
) e aggiungere il Domain Controller; durante la fase di individuazione del Domain Controller apparirà un'opzione chiamata Add all "yourdomain.local servers"
.
Qualcosa di simile alla seguente schermata, dove acsia.local
è il FQDN del Domain controller:
In questo modo, tutti i client registrati sul Domain Controller verranno interrogati e inseriti nell'interfaccia utente di ACSIA per essere distribuiti/monitorati in una sola volta.
Assicuratevi di inserire il vostro controller di dominio nel formato dell' username@fqdn, cioè user1@acsia.io.
10.3.3. Client Windows non connesso ad AD/DC (Agentless)
Se i server Windows non sono collegati a un Domain Controller, è necessario eseguire il seguente script sui client Windows per abilitare il servizio winRM, utilizzato per Ansible.
Script di configurazione WinRM
[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
Assicurarsi che l'URL non venga diviso durante l'operazione di copia/incolla.
10.3.4. Collegamento del PC e workstation ad ACSIA (senza agente)
Anche i PC e le workstation possono essere collegati e monitorati da ACSIA seguendo le istruzioni di cui sopra. Si noti che gli endpoint (come i PC e le workstation) che si trovano dietro a router domestici richiedono l'abilitazione del NATting sulla porta 5986 per l'endpoint che intende connettersi ad ACSIA (l'installazione tramite l'agente è il metodo consigliato per scenari come questo).
Aggiornare la versione di Powershell se è inferiore a 4 e assicurarsi che il firewall di Windows sia attivo.
10.4. Aggiunta di Host tramite l'interfaccia web di ACSIA (solo in modalità agentless)Accedere all'interfaccia web di ACSIA e fare clic su Aggiungi host (Add Host
) nel menu della barra laterale sinistra, nella pagina degli host. Selezionare il sistema operativo del client che si desidera connettere e si verrà inoltrati alla finestra successiva in cui è possibile aggiungere host su base IP o nome host, utilizzando un file CSV (spiegato meglio di seguito) o tramite l'agente (scaricando l'agente). È consigliabile utilizzare gli indirizzi IP per aggiungere il server, poiché i restanti dettagli degli host, compreso il nome dell'host, saranno recuperati e inseriti automaticamente da ACSIA.
Dopo aver completato il Setup degli host, il passo successivo è la schermata di Configurazione dei log (Logs Configuration
), in cui è possibile aggiungere i registri personalizzati del server web o dell'applicazione web (utilizzare sempre il percorso assoluto dei registri). Il passo successivo è la convalida dei registri inseriti; se uno di essi è inesistente, viene evidenziato in modo da poterlo correggere o rimuovere se si tratta di un errore o di un refuso e così via.
I percorsi devono essere ai file di log stessi; i symlinks ai file non sono supportati.
Per esempio, se si dispone di un'applicazione web in esecuzione su un server web Nginx (analogamente con Apache), è necessario aggiungere manualmente i log di Nginx durante la distribuzione del client (è possibile farlo anche in seguito, utilizzando l'opzione di modifica), ossia/var/log/nginx/access.log
. I registri delle applicazioni web vengono in genere rilevati automaticamente da ACSIA. Ma se per qualche motivo non sono stati rilevati, l'azione consigliata è quella di aggiungerli manualmente utilizzando la sezione "Modifica dettagli host" (Edit Host Details
) dove sono elencati gli host (nella pagina Hosts).
Una volta completata la configurazione di tutti i file di log, nella schermata successiva verrà visualizzato un riepilogo per verificare che tutto sia stato inserito, seguito da Deploy
, in cui si inizia effettivamente a configurare ACSIA e a connettersi ai server. Questa operazione richiederà alcuni minuti (a seconda della connessione di rete tra client e server) e alla fine verrà visualizzato un messaggio di dialogo che riporta il completamento della procedura di registrazione.
10.4.1. Formato del file CSV
ACSIA offre l'opzione di utilizzare un file CSV contenente i dettagli di tutti i server, dove è possibile importare semplicemente il file CSV.
La seguente schermata mostra il formato del file CSV per ACSIA:
Se si hanno più registri per un singolo host, è possibile separare ciascun registro con un punto e virgola ;
.
Una volta completata la configurazione di un client, i vostri server saranno costantemente monitorati in tempo reale per rilevare problemi di sicurezza, minacce e anomalie.
10.4.2. Dettagli Container-specific
ACSIA è container-aware e tiene automaticamente traccia degli eventi del kernel all'interno dei container. Tuttavia, se si eseguono applicazioni/web server all'interno di container e si desidera monitorare i log, questi devono essere resi disponibili all'host. ACSIA non supporta i collegamenti simbolici ai file di log: deve essere il percorso completo del file di log indicato.
I log dei container Linux possono essere presentati ad ACSIA utilizzando le opzioni docker --volume
o --mount
. Come da documentazione ufficiale di docker qui or qui se si usa docker-compose.
11. User Administration
La sezione di amministrazione per gli utenti si trova nella barra in alto a destra, cliccando sul nome utente con cui si è effettuato l'accesso e poi su Settings
.
11.1. Aggiunta di un nuovo utente all'interfaccia web di ACSIA
Aggiungere un utente non è mai stato così semplice. Basta fare clic su username
nella barra in alto a destra e selezionare Settings
dal menu.
Quindi cliccare su "AGGIUNGI UTENTE" e compilare tutti i campi; in questa sezione è anche possibile cancellare o modificare gli utenti. Tenete presente che il nome utente effettivo deve essere un indirizzo e-mail.
11.2. Liste di distribuzione
ACSIA consente di creare liste di distribuzione, è quindi possibile aggiungere membri a ciascun gruppo e impostare i tipi di notifica da inviare a ciascuna lista di distribuzione. Ad esempio, è possibile impostare una lista di distribuzione per ricevere solo avvisi di sicurezza a priorità Critical
, High
o Medium/Low
. I dirigenti di livello C potrebbero non voler ricevere avvisi al di fuori degli eventi Critical
e quindi è possibile creare una lista di distribuzione per soddisfare questo requisito.
La Distribution List
si trova nel menu della barra laterale sinistra. Per creare una nuova lista di distribuzione è sufficiente fare clic su "AGGIUNGI NUOVA LISTA".
Assegnare un nome alla Distribution List
creata e selezionare i membri aggiungendoli all'elenco insieme alla scelta del tipo di evento (Critico, Alto o Medio/Basso) che si desidera far ricevere al gruppo.
Ora è tutto pronto per ricevere le notifiche attraverso la lista di distribuzione.
11.3. Impostazioni delle e-mail
Le impostazioni della posta elettronica si riferiscono alle notifiche via e-mail del server di ACSIA. Questa impostazione si trova in alto a destra nel menu Settings
, nella scheda Email
.
Qui è possibile impostare l'e-mail del mittente e il suo nome. Ad esempio, se il dominio della vostra organizzazione si chiama example.com
, potete impostare l'e-mail come no-reply@example.com
e il nome come Acsia Alerts
e inserire l'account nella white-list dei filtri anti-spam per assicurarvi di ricevere le notifiche da quell'account e-mail.
Una volta configurato il tutto, inizierete a ricevere le e-mail di notifica come da impostazione.
Se si riscontrano problemi nella ricezione delle e-mail, l'azione consigliata è quella di impostare un vero account di posta elettronica e configurarlo. Sotto "Email Notification" invece di impostare una semplice e-mail ed etichetta, è possibile attivare i metodi SMTP e di Autenticazione in cui è possibile inserire i dettagli dell'e-mail che si desidera utilizzare come mittente.
11.4. Ricezione di notifiche tramite Slack e/o Microsoft Teams
Analogamente alla notifica via e-mail, è possibile attivare le notifiche da ricevere tramite Slack e/o Microsoft Teams. È possibile attivare questa funzione nella sezione Settings
, alla voce Integrazione, dove è sufficiente copiare il webhook desiderato (Microsoft Teams o Slack) e attivarlo per ricevere le notifiche tramite messaggistica in tempo reale.
11.4.1. Istruzioni per l'installazione di Slack (Microsoft Teams è praticamente uguale)
Installare il webhook in entrata su Slack:
-
Andare in "Applicazioni"
-
Andare alla directory "View App"
-
Cercare
incoming-webhook
-
Andare su "Aggiungi configurazione"
-
In "Post to Channel": scegliere il canale/gruppo a cui inviare la notifica
-
Fare clic su "Aggiungi integrazione WebHook in entrata"
-
Andare su "Personalizza nome": Aggiungere il nome, ad esempio:
ACSIA Notifier
-
Copiare l'URLA del WebHook
Configurazione sull'interfaccia utente ACSIA:
-
Accedere all'interfaccia Web
-
Andare su Impostazioni -> Integrazione
-
Attivare Slack o Microsoft Teams
-
Incollare l'URL copiato
11.5. Notifiche a livello di kernel
Con il monitoraggio a livello di kernel, una volta abilitato, ACSIA ha la capacità di intercettare il flusso di ogni chiamata di sistema fatta al kernel, intercettando le `syscalls e cercando anomalie/minacce in tempo reale (questo solo per i sistemi Linux).
Se si desidera ricevere notifiche a livello di kernel, si consiglia di mantenere questa funzione abilitata. Per coloro che lo desiderano, è possibile disattivarla in qualsiasi momento andando su Setting
e facendo clic su Notification
.
11.6. Abilitazione del ban automatico
Se si desidera che ACSIA gestisca la maggior parte delle minacce provenienti dall'esterno dell'organizzazione (cioè gli attacchi provenienti da Internet come BotNet, Bruteforce, Dictionary, SQL injections, attacchi XSS, ecc.) deve essere abilitata questa funzione.
Se abilitata, ACSIA adotterà automaticamente azioni correttive come il ban degli indirizzi IP sul posto. È possibile attivare l'Automatic ban
navigando in Settings
e facendo clic sulla scheda Notification
.
11.7. Abilitazione del ban manuale per gli indirizzi IP locali/privati
Per impostazione predefinita, ACSIA non può bannare gli indirizzi IP locali, per evitare interruzioni dell'attività o incidenti simili che potrebbero avere un impatto sull'attività. Tuttavia, se si desidera bannare gli indirizzi IP locali, è possibile farlo abilitando questa funzione nella scheda Settings→Notification
.
11.8. Conservazione dei log
ACSIA archivia tutti i log in arrivo dai server tra i database OpenSearch e MySQL. La durata (periodo di conservazione) dei registri può essere configurata navigando in Settings
e facendo clic su Log Retention
.
ACSIA consente agli utenti di impostare diversi periodi di conservazione per diversi tipi di log (elencati di seguito):
11.8.1. Log di accesso
Questi registri comprendono tutti i log di sistema e i log degli eventi.
11.8.2. Web Logs
I web log sono i log delle applicazioni web (ad esempio apache, Nginx, tomcat, IIS, ecc.).
11.8.3. Audit Logs
Si tratta di log di audit di Linux molto noti.
11.8.4. Network Log
Questi log sono il traffico di rete catturato a livello di server (in entrata e in uscita).
11.8.5. ACM Logs
ACM è l'acronimo di Advanced Compliance Mitigation e quindi si tratta di log relativi alla conformità (sistema, applicazione, eventi di sicurezza, ecc.).
12. Dashboard principale

- Allarme critico
- Allarme alto
- Allarme medio
- Allarme basso
- Attacco bloccato
- IP bloccato
- Grafico a linee delle tendenze degli attacchi
- Grafico dei Top 10 Offenders
- Grafico degli Host bloccati (Prisma)
- Grafico degli attacchi per categoria
- Grafico a barre dei 10 Host maggiormente attaccati
- Grafico a barre della Top 10 Authorization Access
- Grafico a barre della Top 10 delle autorizzazioni fallite
- Grafico a barre della Top 10 delle destinazioni
Le tendenze degli attacchi geolocalizzati negli ultimi 10 giorni sono mostrate nella mappa del mondo.
13. Sezione Elenco Host
La pagina dell'elenco degli host mostra l'inventario di tutti i dispositivi collegati ad ACSIA in modalità tablet. I dettagli di ciascuna cella della tabella sono brevemente elencati di seguito:
-
Host Alias: dove è possibile assegnare un alias per riconoscere meglio l'host.
-
Hostname: questo valore viene recuperato automaticamente dall'host, ma l'utente può cambiare il nome
-
Host IP: l'indirizzo IP attraverso il quale il client è connesso
-
Sistema operativo: indica quale sistema operativo ha il client
-
Stato: contiene l'elenco e lo stato di tutti gli shippers che trasmettono in streaming i log del client al server ACSIA
-
Azioni: quest'area ha 3 sottosezioni:
-
Visualizza dettagli: mostra i dettagli dell'host, ad esempio il sistema operativo, il kernel, l'indirizzo IP, i log monitorati e altro ancora
-
Modifica dettagli host: è l'area in cui l'utente può modificare i dettagli dell'host, ad esempio aggiungendo un alias, cambiando il nome dell'host, l'indirizzo IP, aggiungendo log personalizzati da monitorare e avviando/arrestando manualmente i log shipper (streamer), ecc.
-
Rimuovi host: dove è possibile rimuovere l'host collegato.
14. Sezione Eventi
14.1. Notifiche in tempo reale
Nel menu di sinistra sono presenti anche le Live Notifications
che contengono un elenco di tutti gli eventi in tempo reale che non sono ancora stati attivati. Tutti gli avvisi di sicurezza in arrivo saranno elencati in questa sezione e facendo clic sulla freccia Details
di ogni notifica in quest'area sarà possibile sfogliare ed esplorare i dettagli completi di un singolo incidente/avviso generato da ACSIA.
Abbiamo anche dei filtri in cui gli eventi possono essere filtrati e ricercati in base ai criteri, ecc.
14.2. Barra laterale delle notifiche in tempo reale
Abbiamo una barra laterale Live Events
sul lato destro dello schermo. Questa barra laterale è simile a Live Notifications
, con l'eccezione di essere statica e permanente sul lato destro, utile per monitorare gli eventi durante la navigazione tra le funzionalità di ACSIA.
Ogni evento viene mostrato con una breve descrizione e con Immediate Actions
, per consentire all'utente di intervenire e porre rimedio a un evento o incidente di sicurezza in arrivo.
15. Insights
L'area Insights
si trova nel menu della barra laterale di sinistra. Questa sezione contiene diverse dashboard che ACSIA offre per indagini approfondite sugli eventi o anche per generare report e analisi. Ogni dashboard viene visualizzata utilizzando OpenDashboard, un'applicazione web offerta da OpenSearch Stack. La Dashboard OpenSearch è integrata in OpenSearch, potete trovare qualcosa qui: Opensearch.
Ogni dashboard è ben descritta nelle sue funzioni nell'area Insights.
15.1. Conformità
L'area Compliance
contiene principalmente dashboard/report relativi alla conformità e ai quadri normativi elencati brevemente di seguito:
-
Gestione delle informazioni sulla sicurezza
-
Rapporto sugli eventi di sicurezza
-
Rapporto di monitoraggio dell'integrità
-
Rilevamento e risposta alle minacce
-
Rapporto sulle vulnerabilità
-
Mitre Att&ck
-
Auditing e monitoraggio delle Policy
-
Dashboard di monitoraggio delle Policy
-
Dashboard di controllo del sistema
-
Conformità normativa
-
GDPR
-
PCI DSS
-
HIPAA
-
NIST 800-53
-
TSC
La gestione della sicurezza e delle informazioni fornisce visibilità e report sugli eventi di sicurezza e include il monitoraggio dell'integrità dei file. Il rilevamento e la risposta alle minacce forniscono rapporti sulle vulnerabilità scoperte per i sistemi connessi.
L'audit e il monitoraggio delle Policy forniscono una visibilità completa dei controlli di audit e dei requisiti delle Policy standard.
Le dashboard di conformità normativa includono tutti i regimi normativi globali da GDPR, PCI DSS, NIST 800-53, HIPAA, TSC a Mitre Att&ck framework. ACSIA fornisce un controllo completo e una visibilità in tempo reale sulla conformità dei sistemi IT e, nel caso in cui i sistemi non siano conformi, fornisce l'esatto punto di non conformità in modo da poterlo affrontare facilmente.
16. Policy
Le Policy di ACSIA forniscono un inventario di ciò che è consentito e non consentito sui client monitorati. Quando ACSIA blocca il traffico, utilizza i firewall locali dei singoli client (firewall di Windows e tabella di routing sui sistemi Linux, ecc.) La sezione "Policy" è suddivisa in 4 sottosezioni:
-
IP Blacklist
-
IP Whitelist
-
Utenti bloccati
-
Luogo di accesso
-
Notifiche silenziate
16.1. IP Blacklist
La sezione IP Blacklist
contiene tutti gli indirizzi IP che sono stati contrassegnati come dannosi e non autorizzati e quindi inseriti nella blacklist (bannati dagli host). È possibile annullare un'azione se un indirizzo IP viene erroneamente bannato da un utente. Se la funzione di autoban
è abilitata, ACSIA gestirà automaticamente tutti i potenziali attacchi e le minacce provenienti dall'esterno dell'organizzazione (ad esempio da Internet), mentre le minacce interne saranno sempre notificate affinché l'amministratore di ACSIA prenda la decisione finale.
16.2. IP Whitelist
La sezione IP Whitelist
contiene tutti gli indirizzi IP che sono stati contrassegnati come attendibili. Si noti che la whitelist di un indirizzo IP non include le richieste web, in quanto è sensibile agli accessi a livello di applicazione web. Pertanto, quando si mette in whitelist un indirizzo IP che non si applica alle richieste web e se il traffico proveniente da quell'indirizzo IP specifico identifica una potenziale minaccia, sarà soggetto a notifica e avviso.
16.3. Utenti bloccati
La sezione Locked Users
contiene utenti specifici che sono contrassegnati come bloccati. Può trattarsi di utenti legittimi che tentano di accedere ad aree non autorizzate. In alternativa, possono essere utenti malintenzionati che hanno compromesso i dettagli dell'account legittimo di un utente e quindi sono stati bloccati. ACSIA non blocca automaticamente gli utenti legittimi, ma richiede sempre l'input dell'utente, per cui la decisione spetta all'amministratore di ACSIA.
16.4. Luogo di accesso
La sezione Access Location
si riferisce a quegli eventi di sicurezza in cui l'accesso legittimo proviene da una posizione geografica o da un indirizzo IP non autorizzato da ACSIA. Pertanto, è in attesa di approvazione, per essere autorizzato o non autorizzato. Se si autorizza un indirizzo IP basato sulla posizione di un utente, è come se l'utente fosse inserito nella whitelist solo per quell'indirizzo IP. D'altro canto, se si contrassegna un utente come non autorizzato, quest'ultimo potrà comunque accedere ed effettuare tentativi, ma arriverà ogni volta un avviso. Pertanto, il luogo di accesso è diverso dalla blacklist di un IP, a meno che non si aggiunga manualmente l'IP alla blacklist.
16.5. Notifiche silenziate
La sezioneMuted Notifications
si riferisce agli eventi di sicurezza che sono stati riconosciuti legittimamente dagli amministratori e/o dagli analisti di sicurezza di ACSIA. Una volta che un evento è stato contrassegnato come silenziato, ACSIA non notificherà più quel tipo di evento. Tutti gli eventi silenziati possono essere disattivati in qualsiasi momento.
17. Azioni immediate - Opzioni di remediation
È molto probabile che le Immediate Actions
siano le funzioni di ACSIA più utilizzate dagli utenti. Spesso queste azioni sono incorporate in tutti gli eventi di sicurezza in arrivo o nelle notifiche e-mail. Da qui è possibile intraprendere un'azione immediata e mitigare interattivamente l'evento per porvi rimedio.
Questa è la funzione interattiva di ACSIA, che richiede l'input dell'utente per la correzione di eventi e minacce:
L'ordine delle Azioni immediate (talvolta indicate come Remediation Options
), fornite con le notifiche, cambia dinamicamente in base al livello di gravità dell'evento e al tipo di evento. Ad esempio, in presenza di un avviso di potenziale compromissione dell'account, l'ordine delle azioni di rimedio sarà impostato sulla priorità, dove l'opzione che appare in cima sarà la scelta più logica, seguita dalla seconda dell'elenco e così via. Gli utenti di ACSIA trarranno grandi benefici da questa funzione anche se non hanno conoscenze di cybersecurity o hanno competenze tecniche limitate.
17.1. Azioni immediate o opzioni di remediation offerte da ACSIA:
17.1.1. Interrompi la connessione
Scegliendo questa azione, l'utente di ACSIA eliminerà il traffico di rete (in tempo reale) per quell'indirizzo IP dannoso e sospenderà tutto il traffico per quell'indirizzo IP per i successivi 15 minuti. Tutte le connessioni stabilite e le nuove richieste di connessione saranno eliminate durante il tentativo di trasmissione.
17.1.2. Riconosci e autorizza l'utente/il luogo
Scegliendo questa azione si autorizza quell'utente specifico e l'indirizzo IP associato in modo permanente ad accedere alla propria sede. L'indirizzo IP in questione sarà inserito nella whitelist di ACSIA e pertanto non si riceveranno più segnalazioni provenienti da quell'indirizzo IP associato all'utente.
17.1.3. Contrassegna questo utente/luogo come non autorizzato
Scegliendo questa azione si chiede ad ACSIA di continuare a notificare agli utenti questo evento fino a quando non si prende una decisione. Utilizzare questa opzione per gli incidenti in cui non si è ancora deciso di vietare o autorizzare l'accesso da un indirizzo IP.
17.1.4. Vieta questo indirizzo IP
Scegliendo questa azione, l'indirizzo IP viene definitivamente bannato e quindi non sarà più in grado di raggiungere i vostri sistemi.
17.1.5. Blocca l'utente
Scegliendo questa azione si blocca l'account utente all'interno del sistema.
17.1.6. Traccia questo IP
Questa azione porta alla Dashboard
dell'applicazione OpenDashboard
, dove tutte le attività di rete e di server di quell'indirizzo IP specifico saranno popolate per dare piena visibilità a ciò che sta accadendo.
17.1.7. Traccia questo utente
Questa azione porta alla Dashboard
dell'applicazione OpenDashboard
, dove tutte le attività della rete e del server vengono visualizzate per quell'utente specifico, consentendo di stabilire la legittimità dell'attività dell'utente.
17.1.8. Whois Query
Si tratta di un servizio di ricerca di nomi di dominio per cercare nel database Whois informazioni sulla registrazione di domini e IP. Fornisce informazioni rilevanti sulla proprietà dell'indirizzo IP di origine dell'utente malintenzionato.
17.1.9. Visualizza dettagli
Questo fornisce dettagli precisi sull'evento, compresa la posizione geografica dell'indirizzo IP di origine e le coordinate geografiche.
17.1.10. Chiudi l'incidente
Questo è una semplice richiesta di ignorare l'evento e, se si ripresenta, ACSIA lo comunicherà nuovamente.
17.1.11. Silenzia le notifiche
Questa azione indica ad ACSIA di ignorare e non notificare più il ripetersi di quell'evento specifico.
17.1.12. Traccia la sessione di comando - Solo per i client Linux
Si tratta di una funzione estremamente potente di ACSIA, abilitata dal monitoraggio a livello di kernel. Nel momento in cui viene rilevata un'attività sospetta o un utente ha tentato di leggere o scrivere su dati o file sensibili, viene attivato l'avviso e vengono fornite azioni correttive in tempo reale. Quando si fa clic su "Traccia sessione di comando" (Track Command Session
), viene presentata non solo l'attività specifica dell'utente che ha attivato l'avviso, ma l'intera sessione dell'utente in modalità replay. Questo livello di dettaglio forense consente di visualizzare l'intera attività svolta dall'utente e quindi di capire perché l'utente ha cercato di alterare i file e i dati sensibili e di intraprendere rapidamente un'azione correttiva.
18. Audit Logs
Audit Logs è la sezione in cui è possibile trovare tutti gli eventi che sono stati modificati e da chi (utenti ACSIA, chi ha fatto cosa sull'interfaccia web).
19. Notifica via e-mail
Di seguito è riportato un esempio di notifica via e-mail e Slack:
Come si può vedere nella schermata precedente, abbiamo ricevuto una notifica di accesso riuscito tramite l'utente acsia
al nostro server di pre-produzione. Ora sappiamo che un utente legittimo ha effettuato l'accesso, ma ACSIA ha giustamente notificato che si tratta di una potenziale compromissione dell'account.
L'utente e la posizione diventeranno legittimi per ACSIA solo se autorizzeremo l'utente con la posizione associata come legittima. Gli utenti di ACSIA devono addestrare il modulo di apprendimento automatico di ACSIA quando si tratta di accessi legittimi come questo. È qui che ACSIA richiederà principalmente l'input dell'utente. Pertanto, gli utenti ACSIA dovranno indicare per la prima volta, che questo utente è autorizzato e legittimo. Da quel momento in poi ACSIA sarà a conoscenza di questo modello e non lo comunicherà più (a meno che l'account non sia realmente compromesso).
For any further information and queries please get in touch with our support team by contacting us via our support portal (https://support.4securitas.com).
ACSIA is a product of 4Securitas Ltd.
Copyright 2022 4Securitas Ltd