1
00:00:00,000 --> 00:00:10,320
Un Security Information and Event Management, un sistema SIEM, è uno strumento completo che

2
00:00:10,320 --> 00:00:15,200
agisce come centro nevralgico delle operazioni di sicurezza di un'organizzazione.

3
00:00:15,200 --> 00:00:20,800
Raccoglie logs e dati relativi alla sicurezza da una vasta gamma di fonti attraverso l'

4
00:00:20,800 --> 00:00:27,920
infrastruttura digitale, inclusi endpoints, server, dispositivi di rete, servizi cloud,

5
00:00:27,920 --> 00:00:32,960
e vari strumenti di sicurezza come firewall o sistemi antivirus.

6
00:00:32,960 --> 00:00:38,480
Il vantaggio principale di un SIEM è la sua capacità di centralizzare questi dati, che è cruciale

7
00:00:38,480 --> 00:00:43,840
per un monitoraggio e un'analisi efficaci. Questo permette ai team di sicurezza di avere una visione

8
00:00:43,840 --> 00:00:49,680
unificata di tutti gli eventi di sicurezza e logs permettendo un rilevamento,

9
00:00:49,680 --> 00:00:53,760
un'investigazione e una risposta più rapidi alle potenziali minacce.

10
00:00:53,760 --> 00:00:58,640
Una delle capacità primarie di un SIEM è il log management centralizzato.

11
00:00:58,640 --> 00:01:04,560
Aggrega logs da diverse fonti come Syslog, Windows event logs,

12
00:01:04,560 --> 00:01:11,360
e servizi cloud-based, snellendo il processo di gestione di grandi volumi

13
00:01:11,360 --> 00:01:14,320
di dati. Questo approccio centralizzato non solo

14
00:01:14,320 --> 00:01:18,640
semplifica lo storage dei dati ma migliora anche l'efficienza

15
00:01:18,640 --> 00:01:24,160
delle operazioni di sicurezza poiché gli analisti possono accedere rapidamente e correlare dati da

16
00:01:24,160 --> 00:01:28,640
vari sistemi. I sistemi SIEM offrono anche una significativa threat

17
00:01:28,640 --> 00:01:32,400
visibility. Correlando eventi da multiple

18
00:01:32,400 --> 00:01:37,040
fonti possono rilevare pattern sospetti che indicano potenziali

19
00:01:37,040 --> 00:01:41,120
minacce come lateral movement all'interno di una rete

20
00:01:41,120 --> 00:01:44,880
o tentativi di privilege escalation all'interno di un host.

21
00:01:44,960 --> 00:01:48,560
Per esempio, se un utente con diritti di accesso limitati

22
00:01:48,560 --> 00:01:54,000
improvvisamente prova ad accedere a dati sensibili, un SIEM segnalerebbe questo come un potenziale

23
00:01:54,000 --> 00:01:58,480
incidente di sicurezza. Inoltre, i sistemi SIEM giocano un ruolo

24
00:01:58,480 --> 00:02:03,440
cruciale nell'aiutare le organizzazioni a mantenere la security compliance.

25
00:02:03,440 --> 00:02:07,680
Possono essere configurati per soddisfare vari standard normativi

26
00:02:07,680 --> 00:02:16,000
come PCI DSS, NIST, o ISO 27001. Garantendo che le pratiche di sicurezza

27
00:02:16,000 --> 00:02:20,560
siano allineate con i requisiti del settore per questa compliance.

28
00:02:20,560 --> 00:02:24,400
Questi requisiti spesso richiedono un logging dettagliato

29
00:02:24,400 --> 00:02:30,080
e monitoraggio in tempo reale, entrambe funzioni core dei sistemi SIEM.

30
00:02:30,080 --> 00:02:35,040
Per esempio, una società di vendita al dettaglio potrebbe usare un sistema SIEM per monitorare i suoi sistemi

31
00:02:35,040 --> 00:02:39,840
di elaborazione pagamenti. Un sistema potrebbe essere configurato per inviare un alert

32
00:02:39,840 --> 00:02:45,280
se vengono fatti tentativi di login fuori dall'orario lavorativo

33
00:02:45,280 --> 00:02:50,880
da un indirizzo IP straniero, segnalando una potenziale violazione della sicurezza.

34
00:02:50,880 --> 00:02:55,440
Questo alert automatizzato permette al team di sicurezza di investigare la

35
00:02:55,440 --> 00:03:01,120
situazione e intraprendere azioni prima che avvenga un attacco su vasta scala.

36
00:03:01,120 --> 00:03:05,760
I SIEM iniziano la loro operazione raccogliendo logs da una varietà di data

37
00:03:05,760 --> 00:03:09,200
sources all'interno dell'infrastruttura di un'organizzazione.

38
00:03:09,200 --> 00:03:12,560
Queste fonti includono endpoint, server, switch,

39
00:03:12,560 --> 00:03:16,160
router, firewall, e appliance di sicurezza,

40
00:03:16,160 --> 00:03:20,240
tutti i quali generano logs in formati diversi.

41
00:03:20,240 --> 00:03:26,640
Per dare un senso a questi dati disparati, i SIEM impiegano un processo di log

42
00:03:26,640 --> 00:03:32,400
normalization. Questo processo comporta la conversione di logs da vari formati

43
00:03:32,400 --> 00:03:36,240
in una struttura unificata, permettendo loro di essere analizzati e

44
00:03:36,240 --> 00:03:41,040
correlati efficientemente. Il processo tecnico di log collection

45
00:03:41,040 --> 00:03:46,000
tipicamente coinvolge collectors o agents come NXLog,

46
00:03:46,000 --> 00:03:51,840
Winlogbeat, o Beats da ELK Stack, Fluentd, o altri

47
00:03:51,840 --> 00:03:57,600
che estraggono dati da queste risorse. Questi agents sono responsabili di raccogliere

48
00:03:57,600 --> 00:04:01,440
i logs e inviarli al SIEM per l'elaborazione.

49
00:04:01,440 --> 00:04:06,480
Una volta raccolti, i logs vengono normalizzati usando regole di parsing predefinite e

50
00:04:06,480 --> 00:04:11,200
field mappings. Questo passaggio converte i dati in uno schema

51
00:04:11,200 --> 00:04:16,240
coerente come il Common Event Format (CEF) o JSON.

52
00:04:16,240 --> 00:04:20,240
Questi formati standardizzano la struttura dei logs, rendendoli

53
00:04:20,240 --> 00:04:24,160
più facili da analizzare e cercare attraverso l'intero sistema,

54
00:04:24,160 --> 00:04:29,360
indipendentemente dalla fonte originale. Un altro aspetto critico della normalizzazione

55
00:04:29,360 --> 00:04:34,880
è l'unificazione del timestamp. Dato che i logs sono generati in diversi

56
00:04:34,880 --> 00:04:40,560
potrebbero essere generati in fusi orari diversi o potrebbero sperimentare clock drifts,

57
00:04:40,560 --> 00:04:44,560
è essenziale allineare i timestamp per garantire che gli eventi siano

58
00:04:44,560 --> 00:04:47,680
accuratamente correlati attraverso i sistemi.

59
00:04:47,680 --> 00:04:52,880
Senza l'unificazione del timestamp, i logs da diverse fonti potrebbero apparire fuori

60
00:04:52,880 --> 00:04:56,480
sequenza, rendendo difficile tracciare il flusso degli

61
00:04:56,480 --> 00:05:02,000
eventi e identificare incidenti di sicurezza. Per esempio, immaginate un sistema SIEM

62
00:05:02,000 --> 00:05:06,080
che riceve logs da un firewall Cisco ASA

63
00:05:06,080 --> 00:05:12,240
e un set di server Linux. Ognuna di queste fonti può generare logs in

64
00:05:12,240 --> 00:05:15,520
formati diversi. Il sistema SIEM standardizzerà

65
00:05:15,520 --> 00:05:20,000
questi logs così una singola ricerca può cercare tentativi di

66
00:05:20,000 --> 00:05:24,960
login SSH attraverso entrambi i sistemi indipendentemente dal fatto che i logs provengano

67
00:05:24,960 --> 00:05:30,640
da un firewall o dai server. Questa normalizzazione abilita gli analisti a

68
00:05:30,640 --> 00:05:36,000
correlare rapidamente ed efficientemente gli eventi portando a una più veloce

69
00:05:36,000 --> 00:05:40,080
identificazione di potenziali minacce di sicurezza.

70
00:05:40,080 --> 00:05:45,280
In sintesi, i SIEM si affidano alla log collection e normalization

71
00:05:45,280 --> 00:05:49,200
per trasformare dati diversi in un formato strutturato

72
00:05:49,200 --> 00:05:53,840
che può essere efficacemente analizzato e correlato. Questo processo garantisce che

73
00:05:53,840 --> 00:05:58,480
i team di sicurezza possano identificare rapidamente e rispondere agli incidenti

74
00:05:58,480 --> 00:06:03,360
indipendentemente dai sistemi che generano i dati.

75
00:06:03,360 --> 00:06:07,440
Le capacità tecniche dei SIEM abilitano loro di eseguire

76
00:06:07,440 --> 00:06:12,240
il tipo di analisi sofisticata. I Correlation engines

77
00:06:12,240 --> 00:06:17,600
sono al cuore di questa funzionalità. Questi motori abbinano pattern usando

78
00:06:17,600 --> 00:06:21,360
regole predefinite o stabilendo behavioral

79
00:06:21,360 --> 00:06:26,480
baselines. Facendo ciò, il SIEM può rilevare anomalie

80
00:06:26,480 --> 00:06:30,560
che deviano dal comportamento normale di un sistema

81
00:06:30,560 --> 00:06:35,280
o un utente come un numero insolitamente alto di login falliti in un breve

82
00:06:35,280 --> 00:06:39,680
periodo. Soglie ed euristiche vengono poi

83
00:06:39,760 --> 00:06:45,680
applicate per determinare quando questi pattern dovrebbero attivare un alert,

84
00:06:45,680 --> 00:06:50,880
aiutando a ridurre il rumore e focalizzando l'attenzione su eventi che sono più

85
00:06:50,880 --> 00:06:56,480
probabili indicare un incidente di sicurezza. I SIEM offrono anche la flessibilità di

86
00:06:56,480 --> 00:07:01,360
personalizzare le regole di alert per bisogni specifici.

87
00:07:01,360 --> 00:07:06,800
Per esempio, puoi creare regole basate su firme di attacco note

88
00:07:06,800 --> 00:07:11,280
come specifici pattern di traffico di rete associati a malware

89
00:07:11,280 --> 00:07:15,280
o su anomalie comportamentali come orari di login insoliti

90
00:07:15,280 --> 00:07:18,960
o attività fuori dalle normali ore lavorative.

91
00:07:18,960 --> 00:07:23,360
Inoltre, molte piattaforme SIEM supportano scripting di regole personalizzate

92
00:07:23,360 --> 00:07:30,480
in linguaggi come Lucene, SPL, Search Processing Language che è in

93
00:07:30,480 --> 00:07:34,480
Splunk, Sigma o

94
00:07:34,560 --> 00:07:39,040
Kibana Query Language (KQL) e altri, permettendo ai team di sicurezza di adattare le loro

95
00:07:39,040 --> 00:07:43,120
capacità di rilevamento al loro ambiente specifico.

96
00:07:43,120 --> 00:07:48,560
Un esempio di come la correlazione SIEM funziona in pratica potrebbe essere quando un utente fa login

97
00:07:48,560 --> 00:07:52,080
da due località geograficamente distanti come New York

98
00:07:52,080 --> 00:07:55,840
e Singapore nel giro di pochi minuti.

99
00:07:55,840 --> 00:08:00,960
Questo evento potrebbe essere segnalato dal sistema SIEM usando una regola personalizzata di geolocation

100
00:08:00,960 --> 00:08:05,360
velocity. Questa regola compara i pattern di login dell'utente

101
00:08:05,360 --> 00:08:10,880
contro le località geografiche note e segnala un cambio rapido come una

102
00:08:10,880 --> 00:08:16,880
potenziale indicazione di compromissione delle credenziali o account takeover.

103
00:08:16,880 --> 00:08:20,880
Correlando questi eventi, il sistema SIEM può fornire agli analisti di

104
00:08:20,880 --> 00:08:26,240
sicurezza alert azionabili che richiedono ulteriore investigazione.

105
00:08:26,240 --> 00:08:32,240
In sintesi, i SIEM usano la correlazione dei dati per collegare eventi e scoprire complessi

106
00:08:32,240 --> 00:08:36,720
pattern di attacco. Combinando regole predefinite, analisi

107
00:08:36,720 --> 00:08:41,600
comportamentale e condizioni di alert personalizzabili, i sistemi SIEM possono aiutare

108
00:08:41,600 --> 00:08:45,520
le organizzazioni a rilevare e rispondere agli incidenti di sicurezza più

109
00:08:45,520 --> 00:08:49,200
efficacemente ed efficientemente.

110
00:08:49,200 --> 00:08:53,360
Le SIEM dashboards sono strumenti essenziali per gli analisti di sicurezza fornendo

111
00:08:53,360 --> 00:08:57,360
visualizzazione in tempo reale delle attività di rete e sistema.

112
00:08:57,360 --> 00:09:00,880
Queste dashboard aiutano i team di sicurezza a monitorare indicatori chiave

113
00:09:00,880 --> 00:09:04,320
di performance come tentativi di login falliti,

114
00:09:04,320 --> 00:09:09,760
dinieghi del firewall e rilevamenti di virus. Mostrando queste informazioni in un formato

115
00:09:09,760 --> 00:09:13,520
facile da capire, le SIEM dashboards permettono

116
00:09:13,520 --> 00:09:16,560
agli analisti di identificare rapidamente e agire su

117
00:09:16,560 --> 00:09:21,280
potenziali minacce di sicurezza, riducendo il tempo che serve per rispondere agli

118
00:09:21,280 --> 00:09:24,960
incidenti. Una delle caratteristiche chiave delle SIEM dashboards

119
00:09:24,960 --> 00:09:28,880
è l'abilità di mostrare il volume degli eventi,

120
00:09:28,880 --> 00:09:32,880
livelli di gravità e alert attivi in tempo reale.

121
00:09:32,880 --> 00:09:38,320
Questa vista dinamica aiuta gli analisti a tracciare il flusso dei dati di sicurezza e

122
00:09:38,320 --> 00:09:42,880
dare priorità alla risposta basandosi sulla criticità di ogni evento.

123
00:09:42,880 --> 00:09:47,600
Per esempio, se c'è un'impennata nei tentativi di login falliti o un improvviso

124
00:09:47,600 --> 00:09:51,600
picco in attività di rete sospetta, sarà immediatamente

125
00:09:51,600 --> 00:09:55,520
visibile sulla dashboard, sollecitando ulteriore

126
00:09:55,520 --> 00:09:59,600
investigazione. Inoltre, molte SIEM

127
00:09:59,600 --> 00:10:03,520
dashboards includono viste drill-down.

128
00:10:03,520 --> 00:10:09,600
Questo permette agli analisti di cliccare su specifiche anomalie o alert ed esaminare

129
00:10:09,600 --> 00:10:13,600
i dettagli come la fonte dell'attività,

130
00:10:13,600 --> 00:10:17,280
l'utente o dispositivo associato e altre informazioni

131
00:10:17,280 --> 00:10:21,520
contestuali. Questa capacità velocizza il processo di

132
00:10:21,520 --> 00:10:26,240
investigazione, abilitando gli analisti a prendere decisioni informate rapidamente.

133
00:10:26,240 --> 00:10:30,000
I sistemi SIEM forniscono anche capacità di reporting,

134
00:10:30,000 --> 00:10:34,960
offrendo template predefiniti che possono essere personalizzati per soddisfare bisogni

135
00:10:34,960 --> 00:10:41,040
organizzativi o requisiti normativi. Questi report aiutano a garantire la conformità con

136
00:10:41,040 --> 00:10:47,200
standard come PCI DSS o GDPR e sono spesso usati per audit

137
00:10:47,200 --> 00:10:52,800
o sommari esecutivi. L'abilità di pianificare questi report garantisce che

138
00:10:52,800 --> 00:10:58,000
le parti interessate rimangano informate sulla postura di sicurezza e che la compliance

139
00:10:58,000 --> 00:11:03,920
sia continuamente monitorata. Per esempio, un Security Operation Center,

140
00:11:03,920 --> 00:11:08,720
un team SOC, potrebbe usare la dashboard del SIEM per monitorare tentativi di login

141
00:11:08,720 --> 00:11:14,000
SSH attraverso i server di produzione. Se avvengono più di 10 tentativi di login falliti

142
00:11:14,000 --> 00:11:18,800
entro cinque minuti su qualsiasi server, il sistema può attivare un alert.

143
00:11:18,800 --> 00:11:22,720
Questo permette ai team SOC di investigare potenziali tentativi di attacco brute force,

144
00:11:22,720 --> 00:11:26,080
prendendo rapidamente azione per prevenire una

145
00:11:26,080 --> 00:11:30,880
intrusione di successo. In sintesi, le SIEM dashboards sono molto cruciali

146
00:11:30,880 --> 00:11:34,720
per fornire visibilità in tempo reale negli eventi di sicurezza

147
00:11:34,720 --> 00:11:39,680
e snellire il processo investigativo. Combinando funzionalità di

148
00:11:39,680 --> 00:11:45,120
monitoraggio live, analisi drill-down e reporting automatizzato, i SIEM potenziano

149
00:11:45,120 --> 00:11:50,080
i team di sicurezza per rispondere più velocemente e mantenere la compliance all'interno degli

150
00:11:50,080 --> 00:11:54,560
standard organizzativi e normativi.

151
00:11:54,560 --> 00:11:58,640
Quindi, come possiamo vedere, una delle capacità chiave del SIEM

152
00:11:58,640 --> 00:12:03,440
è il rilevamento di comportamento insolito. Per esempio, se un utente fa login

153
00:12:03,440 --> 00:12:09,920
a orari strani, come alle 3 del mattino, o da una geolocalizzazione

154
00:12:09,920 --> 00:12:14,000
non familiare, il SIEM può segnalare questa attività come sospetta.

155
00:12:14,000 --> 00:12:19,360
È come User Behavior Analytics (UBA). Queste anomalie possono essere indicative di

156
00:12:19,360 --> 00:12:24,080
credenziali compromesse o tentativi di accesso non autorizzato.

157
00:12:24,080 --> 00:12:28,800
Un'altra caratteristica potente è l'abilità di correlare eventi multipli in un

158
00:12:28,880 --> 00:12:35,360
singolo alert consolidato. Per esempio, un SIEM può rilevare una serie di

159
00:12:35,360 --> 00:12:40,400
tentativi di login falliti, seguiti da un login di successo e successiva

160
00:12:40,400 --> 00:12:45,280
privilege escalation. Quando questi eventi accadono in stretta successione,

161
00:12:45,280 --> 00:12:49,760
il SIEM li collega insieme, attivando un alert che aiuta i team di sicurezza

162
00:12:49,760 --> 00:12:53,760
a identificare potenziali attacchi come tentativi di login brute force

163
00:12:53,840 --> 00:12:58,800
o lateral movement all'interno della rete. Inoltre, i SIEM possono

164
00:12:58,800 --> 00:13:03,680
integrarsi con feed di threat intelligence, per abbinare attività contro

165
00:13:03,680 --> 00:13:08,240
indicatori noti di compromissione, come indirizzi IP,

166
00:13:08,240 --> 00:13:11,680
file hashes o nomi di dominio associati a

167
00:13:11,680 --> 00:13:16,560
comportamento dannoso. Questo permette loro di segnalare traffico

168
00:13:16,560 --> 00:13:19,920
o azioni che si allineano con pattern di attacco noti,

169
00:13:19,920 --> 00:13:24,960
aggiungendo un altro strato di contesto e precisione al processo di rilevamento.

170
00:13:24,960 --> 00:13:29,040
I SIEM possono anche estrarre threat intelligence e

171
00:13:29,040 --> 00:13:34,080
indicators of compromise per aiutare altri SIEM a rispondere

172
00:13:34,080 --> 00:13:40,000
a tali attività. Vediamo, per esempio, immaginate un SIEM che rileva un

173
00:13:40,000 --> 00:13:43,040
login di account utente alle 3 del mattino

174
00:13:43,040 --> 00:13:47,040
da un indirizzo IP straniero. Se l'utente poi accede a

175
00:13:47,040 --> 00:13:50,640
file sensibili, il sistema può attivare un alert basato su

176
00:13:50,640 --> 00:13:54,400
regole di correlazione preconfigurate che collegano il

177
00:13:54,400 --> 00:14:00,000
comportamento di login insolito con il successivo accesso a dati sensibili.

178
00:14:00,000 --> 00:14:04,480
Quindi è come una kill chain. Questa sarà identificata dal SIEM.

179
00:14:04,480 --> 00:14:09,040
Questo rilevamento precoce aiuta i team di sicurezza a rispondere prontamente,

180
00:14:09,040 --> 00:14:13,120
minimizzando il rischio di un data breach.

181
00:14:13,120 --> 00:14:16,560
I SIEM moderni hanno capacità avanzate che vanno oltre

182
00:14:16,560 --> 00:14:20,960
il solo rilevare minacce. Possono anche attivare azioni predefinite

183
00:14:20,960 --> 00:14:26,640
in risposta a specifici alert, il che riduce significativamente la necessità di

184
00:14:26,640 --> 00:14:30,160
intervento manuale e accelera il processo di contenimento

185
00:14:30,160 --> 00:14:34,080
dell'incidente. Questa automazione permette ai team di

186
00:14:34,080 --> 00:14:38,320
sicurezza di rispondere a potenziali minacce più velocemente e più efficientemente,

187
00:14:38,320 --> 00:14:43,840
minimizzando l'impatto delle violazioni di sicurezza. Per esempio, un SIEM può automaticamente

188
00:14:43,920 --> 00:14:48,720
bloccare indirizzi IP, naturalmente, inviando una regola firewall allo specifico

189
00:14:48,720 --> 00:14:52,320
firewall che sono coinvolti in attività dannose,

190
00:14:52,320 --> 00:14:57,680
come quando si è in un tentativo di login brute force o attacchi DDoS.

191
00:14:57,680 --> 00:15:02,240
Quando molteplici tentativi di login falliti sono stati rilevati, il SIEM può attivare un'

192
00:15:02,240 --> 00:15:05,440
azione per bloccare l'indirizzo IP sospetto,

193
00:15:05,440 --> 00:15:10,320
prevenendo ulteriori tentativi di accesso non autorizzato.

194
00:15:10,320 --> 00:15:15,840
Un'altra azione che i SIEM intraprendono è disabilitare automaticamente account compromessi.

195
00:15:15,840 --> 00:15:21,120
Se il sistema rileva comportamento di login insolito, come login da

196
00:15:21,120 --> 00:15:26,880
altre località o orari strani, può istantaneamente disabilitare

197
00:15:26,880 --> 00:15:31,760
l'account affetto per prevenire qualsiasi potenziale data breach o escalation.

198
00:15:31,760 --> 00:15:37,280
Quindi può essere integrato il SIEM con firewall o controlli di accesso identità

199
00:15:37,280 --> 00:15:41,680
per revocare diritti ed effettivamente rispondere all'

200
00:15:41,680 --> 00:15:47,920
alert. In aggiunta, i SIEM possono inviare alert in tempo reale ai team di

201
00:15:47,920 --> 00:15:52,000
sicurezza via vari canali come email, Slack,

202
00:15:52,000 --> 00:15:55,600
o integrazione con strumenti di Security Orchestration, Automation

203
00:15:55,600 --> 00:16:01,680
and Response, come chiamiamo SOAR. Questo garantisce che le persone giuste

204
00:16:01,680 --> 00:16:07,040
siano notificate immediatamente, permettendo loro di intraprendere azione rapida.

205
00:16:07,040 --> 00:16:11,680
Facciamo un esempio. Immaginate che un SIEM rilevi multipli tentativi di login SSH

206
00:16:11,680 --> 00:16:15,280
falliti, seguiti da un login di successo da una

207
00:16:15,280 --> 00:16:18,960
fonte non familiare. Rilevando questo pattern, il SIEM

208
00:16:18,960 --> 00:16:23,440
potrebbe automaticamente bloccare l'indirizzo IP sospetto

209
00:16:23,440 --> 00:16:27,440
attraverso il firewall per prevenire ulteriori tentativi di accesso.

210
00:16:27,440 --> 00:16:32,400
Simultaneamente, potrebbe inviare una notifica email al Security Operation

211
00:16:32,400 --> 00:16:36,720
Center, al team SOC, con i dettagli dell'incidente per ulteriore

212
00:16:36,720 --> 00:16:41,920
investigazione. Vediamo uno strumento specifico, Splunk.

213
00:16:41,920 --> 00:16:46,640
Splunk è una soluzione SIEM commerciale nota per la sua scalabilità,

214
00:16:46,640 --> 00:16:50,960
ricca visualizzazione e potenti capacità di ricerca.

215
00:16:50,960 --> 00:16:56,400
Ingerisce logs e dati macchina da un'ampia varietà di fonti, abilitando

216
00:16:56,400 --> 00:17:01,760
monitoraggio in tempo reale, rilevamento minacce e reporting di conformità.

217
00:17:01,760 --> 00:17:06,400
Una delle caratteristiche chiave di Splunk è la sua Search Processing Language,

218
00:17:06,400 --> 00:17:11,200
anche come la chiamiamo SPL. SPL è un linguaggio di query

219
00:17:11,200 --> 00:17:16,480
domain-specific che abilita ricerche complesse, analisi statistica e la

220
00:17:16,480 --> 00:17:22,800
creazione di dashboard visuali. Gli analisti usano SPL di Splunk

221
00:17:22,800 --> 00:17:27,680
per immergersi nei dati e identificare potenziali minacce.

222
00:17:27,680 --> 00:17:31,120
Fornisce un'esperienza di ricerca altamente personalizzabile,

223
00:17:31,120 --> 00:17:35,600
aiutando gli analisti a identificare minacce e outlier

224
00:17:35,600 --> 00:17:39,200
in grandi dataset, come ripetuti tentativi di login falliti

225
00:17:39,200 --> 00:17:44,480
o pattern di traffico di rete insoliti. Un altro potente strumento in Splunk è il

226
00:17:44,480 --> 00:17:49,440
Machine Learning Toolkit, che permette agli utenti di costruire modelli predittivi

227
00:17:49,440 --> 00:17:53,520
per il rilevamento di anomalie e User Behavior Analytics,

228
00:17:53,520 --> 00:17:59,600
UEBA. Questo toolkit aiuta a rilevare minacce sconosciute identificando

229
00:17:59,600 --> 00:18:04,720
pattern insoliti nei dati, che potrebbero non essere segnalati dai tradizionali

230
00:18:04,720 --> 00:18:10,480
metodi di rilevamento basati su regole. Abilita Splunk ad andare oltre le ricerche base

231
00:18:10,480 --> 00:18:15,600
e fornire intuizioni sul comportamento futuro, aiutando gli analisti

232
00:18:15,600 --> 00:18:20,640
a rilevare minacce avanzate come insider threats o attacchi zero-day.

233
00:18:20,720 --> 00:18:25,520
L'Enterprise Security module di Splunk aggiunge un livello addizionale di

234
00:18:25,520 --> 00:18:28,960
funzionalità su misura per le operazioni di sicurezza.

235
00:18:28,960 --> 00:18:34,400
Include dashboard specifiche per la sicurezza, integrazione di threat intelligence

236
00:18:34,400 --> 00:18:40,000
e funzionalità di revisione incidenti. Questo modulo snellisce il rilevamento e la

237
00:18:40,000 --> 00:18:44,720
gestione degli incidenti di sicurezza offrendo strumenti specializzati per il threat

238
00:18:44,720 --> 00:18:50,160
hunting e incident response, rendendo più facile per gli analisti

239
00:18:50,240 --> 00:18:55,840
investigare e mitigare potenziali minacce attraverso l'infrastruttura.

240
00:18:55,840 --> 00:18:59,840
Per esempio, un analista di sicurezza potrebbe usare SPL

241
00:18:59,840 --> 00:19:05,280
per cercare tentativi di login falliti attraverso vari sistemi nella rete.

242
00:19:05,280 --> 00:19:09,440
La query potrebbe essere qualcosa come index equals

243
00:19:09,440 --> 00:19:15,440
auth sourcetype equals linux_secure action equals failed

244
00:19:15,440 --> 00:19:19,600
e poi stats count by user and source.

245
00:19:19,600 --> 00:19:24,080
Questo permette all'analista di individuare rapidamente comportamento anormale come un grande

246
00:19:24,080 --> 00:19:28,720
numero di login falliti da un singolo utente o indirizzo IP,

247
00:19:28,720 --> 00:19:33,520
che potrebbe indicare un attacco brute force. Usando SPL, l'analista può

248
00:19:33,520 --> 00:19:36,560
immediatamente intraprendere azioni come bloccare account o

249
00:19:36,560 --> 00:19:41,040
bloccare indirizzi IP dannosi per prevenire ulteriore escalation

250
00:19:41,040 --> 00:19:45,760
della minaccia. La combinazione di Splunk di querying avanzato, machine

251
00:19:45,760 --> 00:19:49,760
learning e moduli di sicurezza su misura lo rende uno

252
00:19:49,760 --> 00:19:53,360
strumento essenziale per operazioni di sicurezza su larga scala.

253
00:19:53,360 --> 00:19:57,120
Abilita le organizzazioni a rilevare e rispondere alle minacce

254
00:19:57,120 --> 00:20:00,640
più velocemente, fornendo visibilità e intuizioni

255
00:20:00,640 --> 00:20:05,360
azionabili sulla postura di sicurezza della rete.

256
00:20:05,360 --> 00:20:10,720
Un altro strumento, un SIEM, è l'ELK Stack, che è basato su Elasticsearch,

257
00:20:10,720 --> 00:20:16,000
Logstash e Kibana. Questa è un'alternativa open-source che ha guadagnato

258
00:20:16,000 --> 00:20:19,920
significativa trazione nelle implementazioni SIEM ultimamente.

259
00:20:19,920 --> 00:20:24,240
Mentre richiede più setup e configurazione comparato a soluzioni

260
00:20:24,240 --> 00:20:27,520
commerciali come Splunk, fornisce alle organizzazioni

261
00:20:27,520 --> 00:20:33,280
flessibilità e controllo dei costi. Questo lo rende particolarmente

262
00:20:33,280 --> 00:20:38,560
attraente per aziende con team DevOps o SecOps in-house.

263
00:20:38,560 --> 00:20:43,600
L'ELK Stack offre potenti capacità per aggregazione log, analisi e

264
00:20:43,600 --> 00:20:47,280
visualizzazione, che è chiave per mantenere un efficace

265
00:20:47,280 --> 00:20:52,320
monitoraggio della sicurezza. Al cuore dell'ELK Stack c'è Elasticsearch,

266
00:20:52,320 --> 00:20:57,840
un motore di ricerca veloce e distribuito progettato per indicizzare e cercare vaste

267
00:20:57,840 --> 00:21:02,960
quantità di dati log. Permette querying più in tempo reale,

268
00:21:02,960 --> 00:21:09,120
rendendolo ideale per recuperare e analizzare rapidamente dati log.

269
00:21:09,120 --> 00:21:15,120
Elasticsearch eccelle nel gestire grandi dataset, garantendo rapidi tempi

270
00:21:15,120 --> 00:21:18,880
di risposta anche quando si tratta di ricerche complesse.

271
00:21:18,880 --> 00:21:22,880
Questo garantisce che i team di sicurezza possano interrogare i dati efficientemente

272
00:21:22,880 --> 00:21:27,040
e identificare pattern o anomalie in maniera tempestiva.

273
00:21:27,040 --> 00:21:30,800
Successivamente, Logstash gestisce l'ingestion dei dati

274
00:21:30,800 --> 00:21:38,320
e la trasformazione. Estrae log dai dati, i dati log da varie risorse,

275
00:21:38,320 --> 00:21:43,440
li parsa e poi invia i dati processati a Elasticsearch.

276
00:21:43,440 --> 00:21:48,560
Il ruolo di Logstash è critico perché i logs sono spesso generati in formati

277
00:21:48,560 --> 00:21:54,320
diversi attraverso sistemi multipli. Garantisce che i dati siano standardizzati,

278
00:21:54,320 --> 00:21:59,440
parsati correttamente e poi arricchiti con contesto addizionale dove necessario,

279
00:21:59,440 --> 00:22:05,680
rendendoli pronti per l'analisi. Senza questo passaggio i logs sarebbero difficili da lavorare

280
00:22:05,680 --> 00:22:10,560
e ostacolerebbero qualsiasi investigazione significativa.

281
00:22:10,560 --> 00:22:15,440
Infine, Kibana serve come strato di visualizzazione dell'ELK Stack.

282
00:22:15,440 --> 00:22:21,920
Abilita gli utenti a creare dashboard interattive ed eseguire query usando

283
00:22:21,920 --> 00:22:28,000
sintassi basata su Lucene. Supportano Kibana Query Language (KQL), Elastic Query

284
00:22:28,000 --> 00:22:34,080
Language e così via. Kibana permette agli analisti di sicurezza di visualizzare

285
00:22:34,080 --> 00:22:37,520
trend di dati, identificare potenziali minacce e tracciare

286
00:22:37,520 --> 00:22:43,520
metriche chiave in tempo reale. Attraverso dashboard personalizzabili, gli utenti possono

287
00:22:43,520 --> 00:22:48,160
facilmente monitorare anomalie, creare report e rispondere a eventi di sicurezza

288
00:22:48,160 --> 00:22:53,120
emergenti con una chiara panoramica visuale che Kibana fornisce.

289
00:22:53,120 --> 00:22:57,280
Per esempio, quando si monitora per attacchi brute force SSH,

290
00:22:57,280 --> 00:23:01,440
Logstash può essere impostato per parsare i log SSH

291
00:23:01,440 --> 00:23:07,920
dalla cartella /var/log/auth.log dove i tentativi di login sono registrati su un sistema

292
00:23:07,920 --> 00:23:11,760
Linux. Questi log sono processati e indicizzati da

293
00:23:11,760 --> 00:23:17,840
Elasticsearch, un database NoSQL, rendendoli facili da cercare e interrogare.

294
00:23:17,840 --> 00:23:22,800
Kibana può poi visualizzare i tentativi di login falliti nel tempo.

295
00:23:22,800 --> 00:23:26,880
Mostrando trend e mappando gli IP sorgente.

296
00:23:26,880 --> 00:23:32,320
Questo setup permette ai team di sicurezza di identificare rapidamente pattern anormali,

297
00:23:32,320 --> 00:23:36,720
come multipli tentativi falliti da un singolo IP, che possono segnalare

298
00:23:36,720 --> 00:23:39,680
un attacco brute force.

299
00:23:40,000 --> 00:23:44,800
Quando si comparano Splunk e l'ELK Stack, ci sono diverse differenze chiave in

300
00:23:44,800 --> 00:23:49,120
termini di funzionalità, licensing e scalabilità.

301
00:23:49,120 --> 00:23:52,320
Comprendere queste differenze può aiutare le organizzazioni

302
00:23:52,320 --> 00:23:56,160
a scegliere la soluzione giusta per i loro bisogni di monitoraggio di sicurezza e log management.

303
00:23:56,160 --> 00:23:59,280
Il licensing è uno dei contrasti più

304
00:23:59,280 --> 00:24:04,720
significativi tra i due. Splunk opera su un modello

305
00:24:04,720 --> 00:24:09,600
di prezzo a livelli commerciale, significando che l'organizzazione deve pagare basandosi sulla

306
00:24:09,600 --> 00:24:14,160
quantità di dati ingeriti. Mentre questo modello offre robusto supporto

307
00:24:14,160 --> 00:24:19,280
enterprise, può diventare molto costoso all'aumentare del volume di dati.

308
00:24:19,360 --> 00:24:24,640
D'altra parte, l'ELK Stack è open source, il che significa che è gratuito da usare.

309
00:24:24,640 --> 00:24:28,160
Tuttavia, le organizzazioni che richiedono supporto addizionale,

310
00:24:28,160 --> 00:24:31,040
Elastic, l'azienda dietro l'ELK Stack,

311
00:24:31,040 --> 00:24:34,800
offre opzioni di supporto a pagamento, fornendo la flessibilità

312
00:24:34,800 --> 00:24:38,960
di scalare secondo necessità senza un significativo investimento

313
00:24:38,960 --> 00:24:45,120
iniziale in licensing. In termini di linguaggio di query, Splunk usa il suo proprio

314
00:24:45,120 --> 00:24:51,680
Search Processing Language proprietario, SPL. SPL è altamente

315
00:24:51,680 --> 00:24:56,240
flessibile e potente, permettendo agli utenti di eseguire ricerche complesse,

316
00:24:56,240 --> 00:25:00,240
analisi statistica, e persino creare dashboard personalizzate.

317
00:25:00,240 --> 00:25:05,760
Mentre SPL offre capacità avanzate, può anche avere una curva di

318
00:25:05,760 --> 00:25:08,960
apprendimento più ripida per utenti non familiari con questi blocchi

319
00:25:08,960 --> 00:25:12,160
decisionali. L'ELK Stack, in contrasto, usa

320
00:25:12,160 --> 00:25:17,120
Lucene e Kibana Query Language, entrambi i quali sono più standardizzati

321
00:25:17,120 --> 00:25:22,080
e più facili da imparare, ma meno avanzati comparati a SPL.

322
00:25:22,080 --> 00:25:25,360
Per coloro che hanno già familiarità con SQL, come

323
00:25:25,360 --> 00:25:30,560
linguaggio di query, Kibana Query Language offre un punto di ingresso più accessibile.

324
00:25:30,560 --> 00:25:35,200
Sembra simile a SQL, ma potrebbe supportare,

325
00:25:35,200 --> 00:25:40,640
potrebbe non supportare, il livello di querying complesso che fa SPL.

326
00:25:40,640 --> 00:25:46,000
Quando si tratta di complessità di setup, Splunk è noto per essere facile da deployare,

327
00:25:46,000 --> 00:25:50,320
specialmente con le sue opzioni di supporto enterprise.

328
00:25:50,320 --> 00:25:53,680
Questo lo rende ideale per organizzazioni che hanno bisogno di una soluzione

329
00:25:53,680 --> 00:25:58,160
rapida out-of-the-box con configurazione minima.

330
00:25:58,160 --> 00:26:04,080
L'ELK Stack, tuttavia, richiede più configurazione manuale e tuning.

331
00:26:04,080 --> 00:26:08,480
Può essere impostato per soddisfare requisiti specifici, ma questo significa anche che è necessario più

332
00:26:08,480 --> 00:26:12,640
sforzo per il deployment, specialmente quando si scala

333
00:26:12,640 --> 00:26:18,160
attraverso ambienti multipli. Le capacità di integrazione variano anche tra le due

334
00:26:18,160 --> 00:26:22,480
soluzioni. Splunk offre estese integrazioni

335
00:26:22,480 --> 00:26:27,920
built-in e add-on, rendendolo più facile da incorporare in un ambiente

336
00:26:27,920 --> 00:26:31,440
esistente. Queste integrazioni pre-costruite con

337
00:26:31,440 --> 00:26:36,800
sistemi popolari e strumenti aiutano a snellire i processi di deployment.

338
00:26:36,800 --> 00:26:40,000
Nel frattempo, l'ELK Stack è altamente estensibile,

339
00:26:40,000 --> 00:26:44,320
offrendo la flessibilità di integrarsi con molti sistemi attraverso plugin

340
00:26:44,320 --> 00:26:49,200
e Beats, leggeri data shippers. Gli agent su ELK

341
00:26:49,200 --> 00:26:55,280
si chiamano Beats. Questa estensibilità permette all'ELK Stack di

342
00:26:55,280 --> 00:27:00,240
essere personalizzato e su misura per specifici casi d'uso.

343
00:27:00,240 --> 00:27:04,080
Tuttavia, potrebbe richiedere configurazioni addizionali

344
00:27:04,080 --> 00:27:07,520
per garantire integrazione senza interruzioni con i sistemi.

345
00:27:07,520 --> 00:27:12,400
Infine, la scalabilità è un'area dove entrambe le soluzioni differiscono.

346
00:27:12,400 --> 00:27:17,360
Splunk è cloud-native, offrendo capacità di scaling che sono gestite da

347
00:27:17,360 --> 00:27:21,600
Splunk cloud stesso. Questo rende più facile per le organizzazioni

348
00:27:21,600 --> 00:27:27,440
scalare verso l'alto secondo necessità senza il peso di gestire l'infrastruttura.

349
00:27:27,440 --> 00:27:32,560
D'altra parte, ELK Stack richiede più gestione manuale del cluster per

350
00:27:32,640 --> 00:27:36,640
lo scaling. Mentre può scalare per gestire grandi dataset,

351
00:27:36,640 --> 00:27:41,920
questo processo richiede più sforzo pratico, inclusa la gestione dei

352
00:27:41,920 --> 00:27:47,680
nodi, gestione della distribuzione dati, e garanzia di alta disponibilità del

353
00:27:47,680 --> 00:27:53,200
sistema stesso. Graylog è una piattaforma di log management

354
00:27:53,200 --> 00:27:57,920
open-source comunemente usata per deployment SIEM di medie dimensioni.

355
00:27:57,920 --> 00:28:02,000
È costruita sopra Elasticsearch e MongoDB,

356
00:28:02,080 --> 00:28:06,240
offrendo una soluzione user-friendly, flessibile, ed estensibile

357
00:28:06,240 --> 00:28:11,360
per gestione e analisi dei log. Nota per la sua semplicità, Graylog è

358
00:28:11,360 --> 00:28:16,480
particolarmente adatta per ambienti dove facilità di setup e personalizzazione

359
00:28:16,480 --> 00:28:20,720
sono cruciali, tuttavia mantiene potenti caratteristiche che soddisfano le

360
00:28:20,720 --> 00:28:25,920
domande dei team di sicurezza. Una delle caratteristiche di spicco di Graylog

361
00:28:25,920 --> 00:28:31,200
è la sua architettura modulare. Usa componenti come inputs,

362
00:28:31,200 --> 00:28:36,400
extractors, e pipelines per processare, filtrare, e arricchire logs,

363
00:28:36,400 --> 00:28:42,480
che fornisce flessibilità in come i dati log sono ingeriti, parsati, e analizzati.

364
00:28:42,480 --> 00:28:47,520
Questa architettura permette alle organizzazioni di adattare le loro pipeline di elaborazione log

365
00:28:47,520 --> 00:28:51,520
per adattarsi a bisogni specifici, rendendo Graylog una soluzione

366
00:28:51,520 --> 00:28:56,880
adattabile per vari casi d'uso. Graylog fornisce anche

367
00:28:56,880 --> 00:29:02,240
filtraggio stream-based, che aiuta gli utenti a instradare logs in specifici stream

368
00:29:02,240 --> 00:29:07,120
basandosi sul loro contenuto. Questo abilita alerting personalizzato e

369
00:29:07,120 --> 00:29:11,280
dashboarding basato sui tipi di log che sono più importanti

370
00:29:11,280 --> 00:29:16,560
per il team di sicurezza. Per esempio, se ci sono certi logs associati

371
00:29:16,560 --> 00:29:20,000
con sistemi critici o particolari minacce,

372
00:29:20,000 --> 00:29:23,920
Graylog può essere configurato per dare priorità a questi eventi e attivare

373
00:29:23,920 --> 00:29:29,680
alert di conseguenza. Alerting e correlazione sono componenti core

374
00:29:29,680 --> 00:29:33,840
di Graylog, offrendo capacità di monitoraggio in tempo reale.

375
00:29:33,840 --> 00:29:39,040
Gli utenti possono configurare condizioni di alert basate su soglie o specifici pattern

376
00:29:39,040 --> 00:29:43,920
all'interno dello stream di logs. Per esempio, se una soglia predefinita

377
00:29:43,920 --> 00:29:47,360
è superata, come multipli tentativi di login falliti,

378
00:29:47,360 --> 00:29:50,880
in un breve periodo di tempo, Graylog può attivare un alert,

379
00:29:50,880 --> 00:29:54,560
notificando il team di sicurezza di potenziali minacce.

380
00:29:54,560 --> 00:30:00,400
Un esempio, un amministratore di rete imposta uno stream per monitorare login SSH

381
00:30:00,400 --> 00:30:04,960
falliti. Lo stream filtra logs dove event

382
00:30:04,960 --> 00:30:10,640
dot action equals SSH login failed. E se più di 10

383
00:30:10,640 --> 00:30:15,760
fallimenti accadono entro un minuto dallo stesso indirizzo IP, Graylog attiva un

384
00:30:15,760 --> 00:30:20,800
alert, aiutando a identificare potenziali attacchi brute-force.

385
00:30:20,880 --> 00:30:23,920
Da una prospettiva tecnica, Graylog supporta diversi

386
00:30:23,920 --> 00:30:27,920
metodi di ingestion, inclusi Syslog,

387
00:30:27,920 --> 00:30:34,000
GELF, che è Graylog Extended Log Format, e REST APIs è supportato,

388
00:30:34,000 --> 00:30:39,920
rendendo Graylog compatibile con un'ampia gamma di fonti log.

389
00:30:39,920 --> 00:30:44,080
La piattaforma usa Elasticsearch ancora per indicizzazione,

390
00:30:44,080 --> 00:30:47,840
che fornisce capacità di ricerca e query veloci attraverso i

391
00:30:47,920 --> 00:30:52,320
grandi dataset. Inoltre, l'ecosistema di plugin di Graylog è

392
00:30:52,320 --> 00:30:56,240
un altro punto saliente, offrendo integrazioni per geolocalizzazione,

393
00:30:56,240 --> 00:30:59,920
threat intelligence, e altri casi d'uso avanzati.

394
00:30:59,920 --> 00:31:04,560
Questa flessibilità permette alle organizzazioni di estendere la funzionalità di Graylog

395
00:31:04,560 --> 00:31:10,080
e adattarsi ai loro specifici bisogni di sicurezza e operativi.

396
00:31:10,080 --> 00:31:15,200
IBM QRadar è una piattaforma SIEM completa di livello enterprise,

397
00:31:15,280 --> 00:31:20,000
ampiamente usata in settori regolamentati, particolarmente dove robusta

398
00:31:20,000 --> 00:31:23,360
sicurezza e requisiti di conformità sono essenziali.

399
00:31:23,360 --> 00:31:27,360
Noto per il suo motore di correlazione avanzato e capacità di integrazione,

400
00:31:27,360 --> 00:31:31,520
QRadar è progettato per gestire ambienti di sicurezza complessi con facilità,

401
00:31:31,520 --> 00:31:35,600
fornendo profonde intuizioni e rilevamento di minacce in tempo reale.

402
00:31:35,600 --> 00:31:38,960
Una delle caratteristiche più notevoli di QRadar è il suo

403
00:31:38,960 --> 00:31:43,440
auto-correlation engine, che usa una logica basata su

404
00:31:43,440 --> 00:31:48,240
regole per rilevare pattern di sicurezza attraverso multiple fonti log.

405
00:31:48,240 --> 00:31:51,920
Questo motore correla automaticamente eventi da vari sistemi,

406
00:31:51,920 --> 00:31:57,920
come firewall, endpoint, e server, per identificare attività sospette.

407
00:31:57,920 --> 00:32:02,400
Un'altra caratteristica chiave di QRadar è la sua capacità di asset modeling.

408
00:32:02,400 --> 00:32:06,960
La piattaforma costruisce dinamicamente un inventario degli asset basato su osservazioni

409
00:32:06,960 --> 00:32:10,480
di traffico di rete, dando ai team di sicurezza una chiara visione

410
00:32:10,480 --> 00:32:14,720
delle vulnerabilità dei loro asset. Questo asset modeling li aiuta a

411
00:32:14,720 --> 00:32:18,240
identificare sistemi critici che vengono presi di mira

412
00:32:18,240 --> 00:32:22,800
e abilita le organizzazioni a dare priorità alle risposte di conseguenza.

413
00:32:22,800 --> 00:32:27,600
Feed di minacce integrati sono un altro vantaggio significativo di QRadar.

414
00:32:27,600 --> 00:32:31,600
Si connette senza interruzioni con threat intelligence esterna,

415
00:32:31,600 --> 00:32:36,800
con provider come IBM X-Force e altri feed di terze parti,

416
00:32:36,800 --> 00:32:40,320
arricchendo il processo di rilevamento e correlazione.

417
00:32:40,320 --> 00:32:45,280
Questa integrazione permette a QRadar di incrociare dati log in arrivo

418
00:32:45,280 --> 00:32:49,120
con indicatori di attacco noti e threat intelligence in evoluzione,

419
00:32:49,120 --> 00:32:54,160
migliorando l'accuratezza degli alert e aiutando i team di sicurezza a rispondere più

420
00:32:54,160 --> 00:32:59,280
proattivamente. Vediamo un esempio d'uso. QRadar

421
00:32:59,280 --> 00:33:04,960
potrebbe correlare ripetuti login falliti da multipli utenti sulla stessa subnet,

422
00:33:04,960 --> 00:33:09,440
seguiti da un login di successo da uno degli altri utenti.

423
00:33:09,440 --> 00:33:13,680
Questa sequenza suggerisce un attacco di credential stuffing, dove gli attaccanti usano

424
00:33:13,680 --> 00:33:18,880
credenziali rubate per ottenere accesso non autorizzato. L'auto correlation engine di QRadar

425
00:33:18,880 --> 00:33:21,680
genererà un'offesa (offense) ad alta gravità,

426
00:33:21,680 --> 00:33:26,480
avvisando il team di sicurezza di una potenziale compromissione delle credenziali.

427
00:33:26,480 --> 00:33:30,160
Da una prospettiva tecnica, QRadar è altamente scalabile,

428
00:33:30,160 --> 00:33:34,320
supportando l'ingestion di log da migliaia di fonti, inclusi firewall,

429
00:33:34,320 --> 00:33:38,880
endpoint, e piattaforme cloud. Questo rende QRadar ben adatto per

430
00:33:38,960 --> 00:33:43,040
grandi ambienti complessi che richiedono log management centralizzato e rilevamento

431
00:33:43,040 --> 00:33:47,440
di minacce. Inoltre, QRadar ha flow analytics integrati

432
00:33:47,440 --> 00:33:51,920
attraverso QFlow che gli permette di ispezionare

433
00:33:51,920 --> 00:33:56,720
traffico Layer 7, fornendo visibilità in attività a livello applicazione,

434
00:33:56,720 --> 00:34:00,480
che è essenziale per rilevare attacchi più avanzati.

435
00:34:00,480 --> 00:34:05,200
QRadar sfrutta anche il database Ariel per ricerche ad alta velocità attraverso

436
00:34:05,200 --> 00:34:09,840
terabyte di dati log, abilitando performance di query veloci,

437
00:34:09,840 --> 00:34:14,400
anche in deployment su larga scala. Questo permette agli analisti di sicurezza di cercare

438
00:34:14,400 --> 00:34:18,960
rapidamente attraverso log estesi e identificare eventi di sicurezza critici,

439
00:34:18,960 --> 00:34:24,640
che è vitale per mantenere capacità di monitoraggio in tempo reale.

440
00:34:24,640 --> 00:34:29,760
Microsoft Sentinel è una soluzione SIEM cloud-native che è strettamente

441
00:34:29,760 --> 00:34:32,800
integrata con Azure, offrendo scalabilità,

442
00:34:32,800 --> 00:34:37,600
potenti analytics, e capacità di risposta automatizzata.

443
00:34:37,600 --> 00:34:41,520
Sfrutta l'AI di Microsoft, machine learning,

444
00:34:41,520 --> 00:34:45,360
e security graph intelligence per fornire rilevamento intelligente delle minacce

445
00:34:45,360 --> 00:34:50,000
e operazioni di sicurezza snellite, rendendolo particolarmente adatto per

446
00:34:50,000 --> 00:34:55,840
imprese che usano già Azure o altri servizi Microsoft.

447
00:34:55,840 --> 00:34:59,280
Uno dei punti di forza chiave di Sentinel è il suo uso di un

448
00:34:59,280 --> 00:35:04,800
Kusto Query Language, KQL, un linguaggio di query veloce e flessibile

449
00:35:04,800 --> 00:35:07,920
ottimizzato per analisi log su larga scala.

450
00:35:07,920 --> 00:35:12,560
KQL permette agli analisti di sicurezza di cercare e analizzare rapidamente vaste

451
00:35:12,560 --> 00:35:16,720
quantità di dati log, rendendolo uno strumento essenziale per identificare

452
00:35:16,720 --> 00:35:20,320
minacce in tempo reale. Il linguaggio è abbastanza potente

453
00:35:20,320 --> 00:35:23,920
da gestire query complesse mentre è abbastanza efficiente

454
00:35:23,920 --> 00:35:27,280
da lavorare alla scala di ambienti enterprise.

455
00:35:27,280 --> 00:35:30,800
Un'altra importante capacità di Sentinel

456
00:35:30,800 --> 00:35:35,440
sono i suoi behavior analytics, che includono User Behavior Analytics,

457
00:35:35,440 --> 00:35:39,760
UEBA. Questa funzione analizza il comportamento utente e di

458
00:35:39,760 --> 00:35:44,960
sistema, per trovare anomalie di dati che potrebbero indicare attività dannosa.

459
00:35:44,960 --> 00:35:48,720
Monitorando continuamente le azioni di utenti ed entità,

460
00:35:48,720 --> 00:35:52,800
Sentinel può identificare deviazioni dal comportamento normale,

461
00:35:52,800 --> 00:35:57,840
come orari di login insoliti, pattern di accesso atipici,

462
00:35:57,840 --> 00:36:02,800
o accesso non autorizzato a risorse, che sono spesso segni di insider threats

463
00:36:02,800 --> 00:36:07,760
o account compromessi. I Playbooks in Microsoft Sentinel,

464
00:36:07,760 --> 00:36:12,640
che sono basati su SOAR, Security Orchestration, Automation and Response,

465
00:36:12,640 --> 00:36:16,720
abilitano le organizzazioni ad automatizzare la risposta agli incidenti.

466
00:36:16,720 --> 00:36:21,920
Usando Azure Logic Apps, i playbooks possono eseguire flussi di lavoro

467
00:36:21,920 --> 00:36:26,240
predefiniti per rispondere agli incidenti di sicurezza automaticamente.

468
00:36:26,240 --> 00:36:30,240
Questi playbooks aiutano a ridurre il tempo di risposta agli incidenti,

469
00:36:30,240 --> 00:36:35,040
garantendo una reazione rapida e coerente alle comuni minacce di sicurezza.

470
00:36:35,040 --> 00:36:39,920
Vediamo un esempio. Le capacità di rilevamento minacce di Sentinel

471
00:36:39,920 --> 00:36:44,080
è la sua abilità di segnalare login impossibili (impossible logins).

472
00:36:44,080 --> 00:36:49,360
Supponiamo che un utente faccia login dalla Germania e poi dagli USA, entro una finestra di due minuti,

473
00:36:49,360 --> 00:36:53,280
Sentinel userebbe query KQL sui

474
00:36:53,280 --> 00:36:58,000
log di accesso per segnalare questo come un'anomalia. Interrogando i

475
00:36:58,000 --> 00:37:04,400
dati GeoIP e timestamp, Sentinel può immediatamente identificare e alertare

476
00:37:04,400 --> 00:37:09,600
sullo scenario impossibile, indicando una potenziale compromissione di credenziali

477
00:37:09,600 --> 00:37:14,160
o un tentativo di accesso non autorizzato. Da una prospettiva tecnica, Microsoft

478
00:37:14,160 --> 00:37:17,520
Sentinel fornisce integrazione senza interruzioni con i

479
00:37:17,520 --> 00:37:23,120
servizi Microsoft, come Microsoft 365, Defender e Azure

480
00:37:23,120 --> 00:37:26,640
activity logs. Questa stretta integrazione aiuta i team di sicurezza

481
00:37:26,640 --> 00:37:30,320
a ottenere visibilità completa attraverso i loro

482
00:37:30,320 --> 00:37:34,080
ambienti cloud e on-premises. Inoltre,

483
00:37:34,080 --> 00:37:37,920
Sentinel supporta un'ampia gamma di terze parti

484
00:37:37,920 --> 00:37:42,960
e connettori come AWS, Cisco e Palo Alto,

485
00:37:42,960 --> 00:37:46,720
che permettono alle organizzazioni di ingerire dati, di ingerire

486
00:37:46,720 --> 00:37:50,800
dati da multiple fonti in una piattaforma centralizzata

487
00:37:50,800 --> 00:37:55,680
per rilevamento e analisi minacce più completi.

488
00:37:56,160 --> 00:38:01,680
Per iniziare a utilizzare Splunk, per esempio, per analisi dati log, è

489
00:38:01,680 --> 00:38:05,520
importante capire ogni passo del processo per ingestion e

490
00:38:05,520 --> 00:38:09,920
configurazione dei dati log. Il primo stadio è navigare su

491
00:38:09,920 --> 00:38:13,760
impostazioni (settings) e add data, che apre un flusso di lavoro semplice e

492
00:38:13,840 --> 00:38:17,120
intuitivo per aggiungere le tue fonti dati.

493
00:38:17,120 --> 00:38:21,360
Questo processo è critico in quanto garantisce che la tua istanza di Splunk

494
00:38:21,360 --> 00:38:25,360
possa propriamente raccogliere dati da una varietà di fonti,

495
00:38:25,360 --> 00:38:30,320
sia da file o monitoraggio in tempo reale. La prima azione

496
00:38:30,320 --> 00:38:34,320
qui è selezionare monitor files and directories.

497
00:38:34,320 --> 00:38:37,760
Questo ti permette di specificare quali file di log tracciare per

498
00:38:37,760 --> 00:38:41,440
collezione in tempo reale. Per esempio, se vuoi

499
00:38:41,440 --> 00:38:44,960
monitorare log di autenticazione da un sistema Linux, potresti

500
00:38:44,960 --> 00:38:51,760
scegliere file come /var/log/auth.log o /var/log/secure kernel o

501
00:38:51,760 --> 00:38:56,480
qualsiasi cosa. Scegliendo l'opzione files and directories

502
00:38:56,480 --> 00:39:00,560
stai dicendo a Splunk di cercare nuove voci di log

503
00:39:00,560 --> 00:39:03,680
che appaiono all'interno di questi file o directory,

504
00:39:03,680 --> 00:39:07,280
che verranno poi indicizzati per ricerca successiva.

505
00:39:07,360 --> 00:39:13,440
Questo è chiave perché significa che Splunk è costantemente consapevole di nuovi eventi,

506
00:39:13,440 --> 00:39:19,120
rendendo più facile rilevare problemi man mano che sorgono in tempo reale.

507
00:39:19,120 --> 00:39:24,640
Successivamente, una delle decisioni più cruciali nel processo di setup è

508
00:39:24,640 --> 00:39:28,320
selezionare un source type per i dati log.

509
00:39:28,320 --> 00:39:31,920
Il source type definisce come Splunk dovrebbe interpretare

510
00:39:31,920 --> 00:39:36,000
e parsare i dati log grezzi. Senza un source type appropriato,

511
00:39:36,000 --> 00:39:39,760
Splunk non sarebbe in grado di estrarre campi significativi

512
00:39:39,760 --> 00:39:44,640
o strutturare i dati correttamente. Per esempio, log di autenticazione Linux

513
00:39:44,640 --> 00:39:48,080
tipicamente usano il source type linux_secure.

514
00:39:48,080 --> 00:39:51,600
Assegnando il source type appropriato,

515
00:39:51,600 --> 00:39:55,360
garantisci che Splunk capisca il formato del log

516
00:39:55,360 --> 00:39:59,600
e possa correttamente scomporre i log in campi come nomi utente,

517
00:39:59,600 --> 00:40:05,440
timestamp, status di login come successo, fallimento, e così via.

518
00:40:05,520 --> 00:40:10,400
Dopo aver definito il source type, il passo successivo è configurare un index.

519
00:40:10,400 --> 00:40:14,480
L'index agisce come un contenitore per i log

520
00:40:14,480 --> 00:40:18,320
ed è essenziale per organizzare le grandi quantità di dati

521
00:40:18,320 --> 00:40:24,000
che possono essere ingerite in Splunk. Per esempio, log di sicurezza potrebbero essere piazzati

522
00:40:24,000 --> 00:40:28,320
in un index chiamato "security_logs", che renderebbe facile

523
00:40:28,320 --> 00:40:32,640
in seguito filtrare e cercare solo attraverso gli eventi relativi alla sicurezza nel tuo

524
00:40:32,640 --> 00:40:37,920
sistema. Raggruppando i log in diversi index,

525
00:40:37,920 --> 00:40:42,720
Splunk può recuperare più efficientemente i dati necessari per l'analisi senza

526
00:40:42,720 --> 00:40:46,160
setacciare informazioni irrilevanti, migliorando

527
00:40:46,160 --> 00:40:49,200
la performance e garantendo che le query di ricerca

528
00:40:49,200 --> 00:40:54,160
siano più veloci e rilevanti. Una volta completata la configurazione di source type e

529
00:40:54,160 --> 00:40:58,000
index, Splunk inizierà automaticamente

530
00:40:58,000 --> 00:41:02,800
ad ingerire i dati log dai file specificati nel database.

531
00:41:02,800 --> 00:41:08,160
Mentre ingerisce quei log, Splunk parsa le voci di log grezze in

532
00:41:08,160 --> 00:41:11,680
eventi strutturati secondo il source type.

533
00:41:11,680 --> 00:41:16,080
Ogni evento contiene importanti campi di metadati come time,

534
00:41:16,080 --> 00:41:21,360
host, source e source type che aiutano a categorizzare i dati e renderli

535
00:41:21,360 --> 00:41:24,960
cercabili. Per esempio, il campo timestamp

536
00:41:25,120 --> 00:41:29,680
last_time ti permetterà di cercare log per data e ora.

537
00:41:29,680 --> 00:41:33,520
Host ti dirà da quale macchina il log è originato

538
00:41:33,520 --> 00:41:36,960
e source type ti aiuterà a identificare il tipo di log,

539
00:41:36,960 --> 00:41:41,920
se è un log di sistema, log applicazione, log di sicurezza e così via.

540
00:41:41,920 --> 00:41:46,080
Questi campi rendono i dati molto più utilizzabili e ti permettono di trovare rapidamente

541
00:41:46,080 --> 00:41:50,800
voci rilevanti in un grande dataset. Una volta che i log sono stati ingeriti

542
00:41:50,800 --> 00:41:55,840
e parsati negli eventi, il passo finale è validare i dati eseguendo

543
00:41:55,840 --> 00:41:59,360
ricerche. È qui che la potenza di Splunk

544
00:41:59,360 --> 00:42:04,240
brilla davvero. Interrogando specifici index e source type,

545
00:42:04,240 --> 00:42:09,200
puoi filtrare rapidamente attraverso i log per scoprire intuizioni preziose.

546
00:42:09,200 --> 00:42:14,000
Per esempio, per tracciare tentativi di login falliti, potresti cercare tutte le voci di

547
00:42:14,000 --> 00:42:17,280
password fallite nei log di sicurezza usando una

548
00:42:17,280 --> 00:42:22,640
query come index=security_logs sourcetype=linux_secure

549
00:42:22,640 --> 00:42:26,960
e poi il messaggio "failed password".

550
00:42:26,960 --> 00:42:31,520
Questa query restituirà tutte le voci che corrispondono a quella stringa di ricerca

551
00:42:31,520 --> 00:42:36,560
che sarebbe incredibilmente utile per identificare potenziali violazioni di

552
00:42:36,560 --> 00:42:42,960
sicurezza, attacchi brute force o misconfigurazioni nel sistema.

553
00:42:42,960 --> 00:42:46,480
Una volta che i tuoi log sono ingeriti in Splunk il passo successivo

554
00:42:46,480 --> 00:42:50,320
è analizzarli usando SPL, il Search Processing

555
00:42:50,320 --> 00:42:54,640
Language. Una delle query più fondamentali in SPL

556
00:42:54,640 --> 00:42:59,520
è usare il comando stats per calcolare metriche attraverso diversi campi nei tuoi

557
00:42:59,520 --> 00:43:02,800
log. Per esempio, se vuoi analizzare quanti

558
00:43:02,800 --> 00:43:06,240
eventi stanno arrivando da diverse fonti log,

559
00:43:06,240 --> 00:43:12,000
puoi usare la seguente query SPL index=security_logs

560
00:43:12,000 --> 00:43:18,880
| stats count by source. Questo fornirà una ripartizione dei conteggi

561
00:43:18,880 --> 00:43:26,000
degli eventi da ogni fonte log aiutando a identificare quali fonti sono più attive.

562
00:43:26,000 --> 00:43:30,720
Questa analisi è importante per i team di sicurezza per monitorare i sistemi

563
00:43:30,720 --> 00:43:35,040
poiché picchi insoliti negli eventi da fonti specifiche potrebbero indicare un

564
00:43:35,040 --> 00:43:40,080
potenziale incidente di sicurezza. Un'altra caratteristica chiave di SPL è il

565
00:43:40,080 --> 00:43:44,320
comando top che identifica i valori più

566
00:43:44,320 --> 00:43:49,440
frequenti in un campo specifico. Per esempio, se vuoi vedere quali source

567
00:43:49,440 --> 00:43:53,600
type sono più comuni nei tuoi log, potresti usare la query

568
00:43:53,600 --> 00:43:59,520
index=security_logs | top sourcetype.

569
00:43:59,520 --> 00:44:04,480
I source type sono categorie essenziali che Splunk assegna ai log basandosi sul

570
00:44:04,480 --> 00:44:07,920
loro formato. Identificando i

571
00:44:08,880 --> 00:44:13,600
source type più frequenti puoi valutare se le fonti log sono

572
00:44:13,600 --> 00:44:17,920
appropriate categorizzate e se ci sono eventuali tipi di log

573
00:44:17,920 --> 00:44:22,480
inaspettati presentati. Questi source type inaspettati potrebbero puntare

574
00:44:22,480 --> 00:44:27,600
a sistemi mal configurati o nel caso peggiore potenziali

575
00:44:27,600 --> 00:44:32,880
rischi di sicurezza come una nuova fonte di dati non rilevata.

576
00:44:32,880 --> 00:44:36,720
Con questi comandi puoi facilmente immergerti nei tuoi dati log e iniziare a

577
00:44:36,720 --> 00:44:42,000
scoprire intuizioni preziose. Il linguaggio SPL supporta anche

578
00:44:42,000 --> 00:44:45,600
caratteristiche più avanzate come subsearches,

579
00:44:45,600 --> 00:44:49,440
field extractions e analytics basate sul tempo.

580
00:44:49,440 --> 00:44:53,520
Per esempio, se vuoi focalizzarti su log da uno specifico

581
00:44:53,520 --> 00:44:58,800
intervallo di tempo o filtrare eventi specifici che non sono rilevanti

582
00:44:58,800 --> 00:45:03,120
per la tua investigazione, SPL ti permette di raffinare

583
00:45:03,120 --> 00:45:08,160
le tue query secondo il tempo. Questo lo rende uno strumento versatile non solo per

584
00:45:08,160 --> 00:45:12,320
la risposta agli incidenti di sicurezza ma anche per il monitoraggio operativo

585
00:45:12,320 --> 00:45:16,880
continuo. Per rilevare tentativi di brute force, un

586
00:45:16,880 --> 00:45:20,480
metodo efficace usando Splunk è esaminare log per ripetuti

587
00:45:20,480 --> 00:45:24,480
messaggi di login fallito. Gli attacchi brute force spesso coinvolgono un

588
00:45:24,480 --> 00:45:28,240
attacco che prova ripetutamente password diverse in un tentativo di ottenere accesso

589
00:45:28,240 --> 00:45:32,480
non autorizzato al sistema. Questi tentativi falliti sono tipicamente

590
00:45:32,480 --> 00:45:36,400
registrati in log come SSH o log di autenticazione

591
00:45:36,400 --> 00:45:40,080
il che li rende essenziali per rilevare attività dannosa.

592
00:45:40,080 --> 00:45:44,400
Analizzando quei log puoi identificare pattern che indicano attacchi brute force

593
00:45:44,400 --> 00:45:48,160
in corso. Un modo per rilevare un attacco brute force è usando

594
00:45:48,160 --> 00:45:53,840
query nell'analisi log. Quindi index=security_logs "failed

595
00:45:53,840 --> 00:45:57,840
password" quindi questo è il messaggio che dovrebbe apparire nei logs

596
00:45:57,840 --> 00:46:02,400
e poi | stats count by source. Questo comando è specificamente progettato

597
00:46:02,400 --> 00:46:08,800
per trovare istanze dove tentativi di login falliscono. Ecco come funziona.

598
00:46:08,800 --> 00:46:13,280
index=security_logs specifica che la query dovrebbe cercare all'interno dell'

599
00:46:13,280 --> 00:46:17,280
index security logs che probabilmente contiene voci

600
00:46:17,280 --> 00:46:22,160
relative ai tentativi di login. "failed password" cerca eventi

601
00:46:22,160 --> 00:46:25,520
nei log che contengono la frase "failed password"

602
00:46:25,520 --> 00:46:29,840
che è comunemente usata per loggare tentativi di login non riusciti.

603
00:46:29,920 --> 00:46:34,320
| stats count by source è una funzione statistica che conta le

604
00:46:34,320 --> 00:46:39,360
occorrenze quante volte per esempio questa occorrenza è apparsa

605
00:46:39,360 --> 00:46:44,000
raggruppate per indirizzo IP sorgente. Per esempio dovrebbe essere

606
00:46:44,000 --> 00:46:48,160
un indirizzo IP e poi quante password fallite

607
00:46:48,160 --> 00:46:53,200
erano su uno specifico IP. Essenzialmente questa parte del comando aggrega i

608
00:46:53,200 --> 00:46:56,640
dati per mostrare quanti tentativi di login falliti sono venuti da

609
00:46:56,640 --> 00:47:00,480
ogni indirizzo IP unico. Il risultato da questa query potrebbe apparire

610
00:47:00,480 --> 00:47:05,440
così IP address e l'indirizzo IP

611
00:47:05,440 --> 00:47:08,960
quanti tentativi di login falliti sono apparsi

612
00:47:08,960 --> 00:47:16,720
20 per esempio index=security_logs "failed password" | top user

613
00:47:16,720 --> 00:47:21,200
questa query funziona leggermente diversamente ma mira ancora a identificare

614
00:47:21,200 --> 00:47:26,160
l'attacco brute force. Di nuovo security logs è l'

615
00:47:26,160 --> 00:47:30,240
index e failed password è la frase dentro i log.

616
00:47:30,240 --> 00:47:34,000
Il | top user è una funzione che restituisce i nomi utente più frequentemente

617
00:47:34,000 --> 00:47:38,640
presi di mira. Aggrega i dati basandosi sul

618
00:47:38,640 --> 00:47:42,320
numero di volte che ogni username appare nei tentativi di login falliti

619
00:47:42,320 --> 00:47:46,160
essenzialmente classificando i nomi utente basandosi su quante volte sono stati

620
00:47:46,160 --> 00:47:49,920
presi di mira quindi fornirà il numero più alto di

621
00:47:49,920 --> 00:47:53,280
nomi utente che sono stati provati per questi tentativi di login.

622
00:47:53,360 --> 00:47:59,120
Quindi quello è il comando top. Spiegheremo così che il risultato sarà come

623
00:47:59,120 --> 00:48:05,440
username root che è molto comune 15 tentativi username admin 10

624
00:48:05,440 --> 00:48:09,440
tentativi username super user qualsiasi

625
00:48:09,440 --> 00:48:13,840
numero di tentativi. Questo significa che i nomi utente root e admin sono stati

626
00:48:13,840 --> 00:48:18,400
specificamente presi di mira. Tali risultati suggeriscono che gli attaccanti

627
00:48:18,400 --> 00:48:22,320
si stanno concentrando su account di alto valore dalla root dell'admin

628
00:48:22,320 --> 00:48:30,160
e stanno effettivamente provando a fare attacchi brute force sui sistemi.

629
00:48:30,160 --> 00:48:34,560
Visualizzare i dati log è essenziale per individuare rapidamente attività sospette

630
00:48:34,560 --> 00:48:39,760
o comportamento anormale in tempo reale. Le dashboard in strumenti SIEM come Splunk

631
00:48:39,760 --> 00:48:43,280
forniscono un'interfaccia interattiva per tracciare e analizzare trend

632
00:48:43,280 --> 00:48:46,960
come picchi nei tentativi di login falliti o attacchi ripetuti.

633
00:48:46,960 --> 00:48:51,200
Queste visualizzazioni aiutano gli analisti di sicurezza a monitorare potenziali minacce

634
00:48:51,280 --> 00:48:55,600
senza bisogno di setacciare i dati log grezzi manualmente

635
00:48:55,600 --> 00:48:58,800
permettendo una risposta più efficiente ed efficace.

636
00:48:58,800 --> 00:49:03,120
Per tracciare tentativi brute force o altri fallimenti di login

637
00:49:03,120 --> 00:49:07,920
nel tempo puoi usare la query come quella che abbiamo spiegato security logs

638
00:49:07,920 --> 00:49:11,920
"failed password" e poi | timechart span=1h count by source.

639
00:49:11,920 --> 00:49:16,640
Questa query genera un time chart che

640
00:49:16,640 --> 00:49:22,560
traccia tentativi di login falliti per indirizzo IP sorgente su un periodo di tempo specifico

641
00:49:22,560 --> 00:49:28,320
in questo caso orario ogni ora. Scomponendo i dati in incrementi basati sul

642
00:49:28,320 --> 00:49:33,840
tempo puoi visualizzare come i tentativi di login evolvono e identificare improvvisi

643
00:49:33,840 --> 00:49:38,720
picchi o pattern che potrebbero indicare un attacco in corso.

644
00:49:38,720 --> 00:49:43,120
Per creare una rappresentazione visuale di questa query in Splunk

645
00:49:43,120 --> 00:49:48,080
chiudi i passi naviga alla sezione dashboard e seleziona create new

646
00:49:48,080 --> 00:49:51,360
dashboard. Scegli il tipo di grafico che vuoi usare

647
00:49:51,360 --> 00:49:56,000
come un grafico a linee o un grafico a colonne usa la query

648
00:49:56,000 --> 00:50:00,640
index=security_logs "failed password"

649
00:50:00,640 --> 00:50:06,240
| timechart span=1h count by source come fonte dati per il tuo grafico.

650
00:50:06,240 --> 00:50:10,720
Imposta un intervallo di tempo significativo come le ultime 24 ore per fornire la rilevante

651
00:50:10,720 --> 00:50:15,920
vista dell'attività che stai monitorando. L'output atteso è un grafico basato sul

652
00:50:15,920 --> 00:50:19,120
tempo dove puoi tracciare tentativi di login falliti per

653
00:50:19,120 --> 00:50:24,400
IP sorgente. Il grafico mostrerà quali indirizzi IP

654
00:50:24,400 --> 00:50:29,200
stanno tentando login in certi orari e puoi facilmente individuare qualsiasi indirizzo IP

655
00:50:29,200 --> 00:50:32,960
con una frequenza insolitamente alta di tentativi falliti.

656
00:50:32,960 --> 00:50:36,240
Questi sono probabili essere fonti di attacchi brute force.

657
00:50:36,240 --> 00:50:40,320
Con questa visualizzazione puoi rapidamente identificare i più attivi e

658
00:50:40,320 --> 00:50:44,720
potenzialmente dannosi indirizzi IP permettendoti di

659
00:50:44,720 --> 00:50:47,840
intraprendere azione immediata come bloccare l'IP

660
00:50:47,840 --> 00:50:53,360
o investigare ulteriormente l'attività.

661
00:50:53,360 --> 00:50:58,720
Logstash è un potente strumento nell'ELK Stack progettato per ingestione, elaborazione

662
00:50:58,720 --> 00:51:01,840
e inoltro di dati log da multiple risorse.

663
00:51:01,840 --> 00:51:05,200
Quando configuri Logstash per gestire log da un firewall

664
00:51:05,200 --> 00:51:08,880
gioca un ruolo vitale nello strutturare dati log grezzi

665
00:51:08,880 --> 00:51:13,200
in formati significativi e cercabili. Il processo inizia con l'

666
00:51:13,200 --> 00:51:16,960
installazione di Logstash sul tuo server che può essere fatta

667
00:51:16,960 --> 00:51:22,880
usando package manager o scaricando direttamente i binari.

668
00:51:22,880 --> 00:51:26,800
Una volta installato passi alla configurazione della pipeline Logstash

669
00:51:26,800 --> 00:51:31,200
che consiste di tre sezioni principali input, filter e output.

670
00:51:31,200 --> 00:51:36,400
Nella sezione input Logstash è impostato per estrarre log dal file log del tuo firewall

671
00:51:36,400 --> 00:51:42,000
o output syslog. Per esempio i log firewall sono spesso memorizzati in

672
00:51:42,000 --> 00:51:46,320
file come /var/log/firewall.log

673
00:51:46,320 --> 00:51:49,760
e a Logstash deve essere detto dove trovarli.

674
00:51:49,760 --> 00:51:55,520
L'opzione start position beginning garantisce che Logstash processi i log

675
00:51:55,520 --> 00:51:59,040
iniziando dall'inizio del file di log.

676
00:51:59,040 --> 00:52:04,400
Una volta che Logstash ha ingerito i log la sezione filter entra in gioco.

677
00:52:04,400 --> 00:52:08,880
Qui puoi usare filtri come Grok per parsare ed estrarre

678
00:52:08,880 --> 00:52:14,160
specifici campi dati dai log grezzi. Per esempio potresti usare il filtro

679
00:52:14,160 --> 00:52:18,960
Grok per estrarre l'IP sorgente, l'IP destinazione e l'azione intrapresa dal

680
00:52:18,960 --> 00:52:21,760
firewall. Questo passaggio è essenziale per

681
00:52:21,760 --> 00:52:25,280
trasformare dati log non strutturati in campi

682
00:52:25,280 --> 00:52:29,680
strutturati che possono essere indicizzati e analizzati. Infine la sezione output

683
00:52:29,680 --> 00:52:33,920
della configurazione definisce dove andranno i dati parsati.

684
00:52:33,920 --> 00:52:38,000
In questo caso puoi configurare Logstash per inoltrare i dati processati a

685
00:52:38,000 --> 00:52:42,000
Elasticsearch dove saranno indicizzati e resi disponibili per

686
00:52:42,000 --> 00:52:46,000
ricerca e analisi. I log sono solitamente memorizzati in un

687
00:52:46,000 --> 00:52:51,760
index format come "firewall_logs-date" o qualsiasi nome

688
00:52:51,760 --> 00:52:56,480
permettendo facile organizzazione e query basate sulla data in cui i

689
00:52:56,480 --> 00:53:01,280
log sono stati creati o su una diversa tattica e metodologia.

690
00:53:01,280 --> 00:53:06,480
Una volta che il setup è completo e Logstash sta attivamente processando i log

691
00:53:06,480 --> 00:53:10,400
l'output consisterà di dati strutturati che possono essere interrogati e

692
00:53:10,400 --> 00:53:15,040
visualizzati usando strumenti di visualizzazione come Kibana.

693
00:53:15,040 --> 00:53:19,120
Le sue voci firewall come una dell'indirizzo IP

694
00:53:19,120 --> 00:53:23,680
destinazione e sorgente con azione di accept saranno scomposte in

695
00:53:23,680 --> 00:53:28,400
diversi campi rendendo facile cercare trend, identificare pattern

696
00:53:28,400 --> 00:53:32,320
e ottenere intuizioni negli eventi di sicurezza di rete.

697
00:53:32,320 --> 00:53:37,440
Questa integrazione di Logstash e Elasticsearch ti abilita a creare un robusto

698
00:53:37,440 --> 00:53:41,200
sistema di log management che migliora la tua abilità di monitorare e

699
00:53:41,200 --> 00:53:45,920
mettere in sicurezza la tua rete. Una volta che i log sono indicizzati in Elastic

700
00:53:45,920 --> 00:53:49,520
search puoi usare le sue potenti capacità di query per rilevare

701
00:53:49,520 --> 00:53:54,320
potenziali minacce di sicurezza. Costruendo query mirate puoi

702
00:53:54,320 --> 00:53:58,880
identificare problemi live come accesso non autenticato

703
00:53:58,880 --> 00:54:02,480
e tentativi brute force. Questa query permette un efficiente

704
00:54:02,480 --> 00:54:06,240
monitoraggio dell'attività di rete rendendo più facile identificare

705
00:54:06,240 --> 00:54:10,080
incidenti di sicurezza. Un modo per rilevare attività sospetta è

706
00:54:10,080 --> 00:54:14,240
cercare traffico da uno specifico indirizzo IP sorgente.

707
00:54:14,240 --> 00:54:18,160
Per esempio usando la query source_ip:

708
00:54:18,160 --> 00:54:22,160
e poi l'indirizzo IP AND action:deny

709
00:54:22,240 --> 00:54:28,080
filtrerà i log dove traffico dall'indirizzo IP

710
00:54:28,080 --> 00:54:31,280
l'indirizzo specifico è stato negato dal firewall.

711
00:54:31,280 --> 00:54:35,760
Questo può aiutarti a identificare una particolare fonte se sta tentando

712
00:54:35,760 --> 00:54:40,880
accesso non autorizzato o provando ripetutamente a violare il firewall.

713
00:54:40,880 --> 00:54:45,600
Un tipico output potrebbe mostrare log indicando che a questo indirizzo IP

714
00:54:45,600 --> 00:54:50,400
è stato negato l'accesso multiple volte a diverse destinazioni

715
00:54:50,480 --> 00:54:56,080
suggerendo potenziale attività dannosa. Questi tipi di log sono

716
00:54:56,080 --> 00:54:59,520
utili per rilevare primi segni di attacco permettendo tempestivo

717
00:54:59,520 --> 00:55:04,400
intervento. Un'altra importante query si concentra sul rilevare insoliti pattern

718
00:55:04,400 --> 00:55:08,880
di accesso per porte specifiche. Per esempio destination_port:80

719
00:55:08,880 --> 00:55:13,840
AND action:allow cerca traffico permesso mirato alla porta 80.

720
00:55:13,840 --> 00:55:17,920
Dato che la porta 80 è comunemente usata per traffico web monitorarla per

721
00:55:17,920 --> 00:55:21,680
attività insolita può rivelare se ci sono pattern di accesso anormali

722
00:55:21,680 --> 00:55:26,160
come connessioni frequenti che potrebbero non corrispondere a regolare comportamento di navigazione

723
00:55:26,160 --> 00:55:30,800
web. I risultati potrebbero mostrare una lista di voci di traffico

724
00:55:30,800 --> 00:55:35,200
permesso ma è la frequenza e il contesto di queste connessioni che

725
00:55:35,200 --> 00:55:39,600
aiuterà a determinare se l'attività è legittima o

726
00:55:39,600 --> 00:55:44,640
indicativa di un tentativo di exploit. Revisionando regolarmente quei pattern

727
00:55:44,720 --> 00:55:48,720
gli amministratori di rete possono individuare le irregolarità e rispondere.

728
00:55:48,720 --> 00:55:52,000
Per rilevare attacchi brute force puoi cercare fallimenti di

729
00:55:52,000 --> 00:55:59,440
login multipli come abbiamo visto su Splunk come source_ip AND action:deny

730
00:55:59,440 --> 00:56:04,560
| stats count by source_ip. Questa query aiuta a identificare ripetuti

731
00:56:04,560 --> 00:56:08,640
tentativi di login negati per uno specifico indirizzo IP un segno comune di

732
00:56:08,640 --> 00:56:11,840
attacco brute force. I risultati potrebbero mostrare che l'indirizzo

733
00:56:11,840 --> 00:56:15,280
IP ha fatto un alto numero di tentativi di login falliti

734
00:56:15,280 --> 00:56:19,600
indicando un attacco automatizzato o una misconfigurazione di sicurezza che richiede

735
00:56:19,600 --> 00:56:23,360
attenzione. Tali query sono particolarmente utili

736
00:56:23,360 --> 00:56:27,520
per individuare attività ad alto rischio e naturalmente

737
00:56:27,520 --> 00:56:31,600
ELK Stack può essere modellato può essere personalizzato

738
00:56:31,600 --> 00:56:38,400
per usare le migliori le migliori query possibili per l'infrastruttura.

739
00:56:38,400 --> 00:56:43,520
Come abbiamo detto Kibana è lo strumento potente per visualizzare i dati memorizzati in

740
00:56:43,520 --> 00:56:47,680
Elasticsearch sull'ELK Stack e ti permette di creare

741
00:56:47,680 --> 00:56:51,360
dashboard interattive per tracciare e analizzare gli eventi.

742
00:56:51,360 --> 00:56:56,240
Usando Kibana i team di sicurezza possono facilmente identificare i trend anomalie

743
00:56:56,240 --> 00:57:00,000
e monitorare metriche di sicurezza chiave in tempo reale.

744
00:57:00,000 --> 00:57:04,320
Per iniziare puoi aprire Kibana e navigare alla sezione dashboard.

745
00:57:04,320 --> 00:57:08,000
Da lì puoi creare una nuova dashboard specificamente per i tuoi bisogni di monitoraggio

746
00:57:08,000 --> 00:57:12,800
eventi di sicurezza. Aggiungendo varie visualizzazioni alla dashboard

747
00:57:12,800 --> 00:57:16,160
ti aiuterà a tracciare importanti eventi firewall e ottenere

748
00:57:16,160 --> 00:57:21,040
diverse intuizioni nell'attività di rete. Una delle prime visualizzazioni

749
00:57:21,040 --> 00:57:25,280
che potresti voler aggiungere è il grafico a barre per top

750
00:57:25,280 --> 00:57:29,840
indirizzi IP negati. Questo grafico ti mostrerà gli indirizzi IP

751
00:57:29,840 --> 00:57:32,560
sorgente a cui è stato per lo più frequentemente

752
00:57:32,560 --> 00:57:37,760
negato l'accesso dal firewall. Per configurare questo aggregherai

753
00:57:37,760 --> 00:57:43,360
dati per il campo source IP e mostrerai il conteggio delle azioni di deny.

754
00:57:43,360 --> 00:57:47,760
Questo ti darà una vista rapida di quali indirizzi IP stanno tentando accesso

755
00:57:47,760 --> 00:57:52,160
ed essendo bloccati più spesso o potenzialmente evidenziando fonti di

756
00:57:52,160 --> 00:57:55,680
attività sospetta. Un'altra visualizzazione utile è il

757
00:57:55,680 --> 00:57:59,920
grafico a torta per ripartizione delle azioni. Questo scomporrà le azioni intraprese

758
00:57:59,920 --> 00:58:05,040
dal firewall come allow contro deny. Il grafico a torta può essere configurato

759
00:58:05,040 --> 00:58:09,680
per aggregare dati per il campo action fornendo una rappresentazione facile da leggere

760
00:58:09,680 --> 00:58:13,680
della distribuzione dei tipi di traffico. Questa visualizzazione è particolarmente

761
00:58:13,680 --> 00:58:17,360
utile per comprendere il comportamento generale della rete dell'

762
00:58:17,360 --> 00:58:21,680
attività del firewall per esempio. Infine puoi creare un grafico a linee

763
00:58:21,680 --> 00:58:26,320
per accesso negato dettagliato. Questa visualizzazione ti permetterà di

764
00:58:26,320 --> 00:58:29,520
tracciare il numero di connessioni negate per giorno

765
00:58:29,520 --> 00:58:32,400
che può aiutarti a individuare trend nel tempo.

766
00:58:32,480 --> 00:58:37,760
Configurare questo grafico a linee con un intervallo di tempo di 24 ore o cinque o

767
00:58:37,760 --> 00:58:42,560
sette giorni ti permetterà di monitorare se ci sono picchi nel traffico negato

768
00:58:42,560 --> 00:58:46,080
che potrebbero indicare tentativi in corso o ricorrenti di violare

769
00:58:46,080 --> 00:58:49,760
il firewall o i sistemi.