1
00:00:08,429 --> 00:00:22,769
Buenas tardes, Carlos. Hoy día, 15 de mayo, a las 20 horas, estamos convocados a través de Jefatura del Departamento para la defensa del módulo profesional del proyecto del ciclo formativo de grado superior de Administración del Sistema Informático ENRE.

2
00:00:23,350 --> 00:00:37,189
Le informo que esta grabación se usará en entornos cerrados de EducaMadrid, con fines educativos, y sólo estará a disposición de los profesores en el aula virtual para llevar a cabo la evaluación y calificación de la defensa del proyecto.

3
00:00:37,189 --> 00:00:42,570
En el lado virtual del proyecto habéis sido informados de los criterios y rúbricas de calificación

4
00:00:42,570 --> 00:00:45,829
El orden de la presentación del proyecto es el siguiente

5
00:00:45,829 --> 00:00:52,710
15 minutos máximos para defender el proyecto y 5 minutos para preguntas por parte del tribunal

6
00:00:52,710 --> 00:00:57,570
Dicho esto, tu tiempo de exposición comienza a partir de este momento

7
00:00:57,570 --> 00:00:59,609
Adelante y mucha suerte

8
00:00:59,609 --> 00:01:02,210
Perfecto, muchas gracias Agustín

9
00:01:02,210 --> 00:01:05,209
Muy buenas tardes, mi nombre es Carlos

10
00:01:05,209 --> 00:01:09,650
y vengo a presentarles una solución para la seguridad y monitorización de la red,

11
00:01:10,150 --> 00:01:15,530
utilizando estas cuatro herramientas, Suricata, Loki, Promtail y Grafana.

12
00:01:18,219 --> 00:01:22,540
Mientras hablamos, más de 4.000 ataques de ransomware ocurren diariamente.

13
00:01:23,159 --> 00:01:27,900
Los atacantes permanecen un promedio de 277 días en los sistemas antes de ser detectados,

14
00:01:28,680 --> 00:01:30,719
como ocurrió en el caso de SolarWinds.

15
00:01:31,140 --> 00:01:33,540
SolarWinds, descubierto en diciembre de 2020,

16
00:01:33,540 --> 00:01:35,840
es considerado uno de los ciberataques

17
00:01:35,840 --> 00:01:37,319
más sofisticados de la historia.

18
00:01:38,299 --> 00:01:40,480
Fue un ataque a la cadena de suministro

19
00:01:40,480 --> 00:01:43,040
donde los hackers, posteriormente atribuido

20
00:01:43,040 --> 00:01:45,780
al grupo CosyVR, APT29,

21
00:01:46,000 --> 00:01:48,519
comprometieron el software Orion de SolarWinds,

22
00:01:48,640 --> 00:01:50,439
una herramienta de monitorización de redes

23
00:01:50,439 --> 00:01:53,920
utilizada por más de 33.000 clientes en todo el mundo.

24
00:01:54,500 --> 00:01:55,959
¿Qué hicieron exactamente?

25
00:01:56,319 --> 00:01:58,780
Los atacantes comprometieron el entorno de desarrollo

26
00:01:58,780 --> 00:01:59,680
de SolarWinds.

27
00:02:00,359 --> 00:02:01,819
Hicieron una inserción de malware,

28
00:02:01,819 --> 00:02:08,000
modificaron el código fuente de Orion para incluir una puerta trasera. SolarWinds, desconociendo

29
00:02:08,000 --> 00:02:13,259
todo lo que estaba sucediendo, obviamente distribuyó las actualizaciones firmadas digitalmente

30
00:02:13,259 --> 00:02:19,340
a sus clientes. El malware permanecía dormido durante más de 14 días y solo se activaba

31
00:02:19,340 --> 00:02:25,500
en objetivos muy específicos. Una vez activado, activaba comunicaciones contra servidores

32
00:02:25,500 --> 00:02:31,360
C2 y permitía a los atacantes moverse dentro de redes comprometidas. Y aquí vamos al segundo

33
00:02:31,360 --> 00:02:37,300
punto, el 43% de todos estos ataques se dirigen a pequeñas empresas y el reciente caso de la

34
00:02:37,300 --> 00:02:42,080
cadena de suministro Mubit demuestra que al final, hoy en día, ser pequeño ya no significa ser

35
00:02:42,080 --> 00:02:48,960
invisible para los ciberdelincuentes. ¿Qué ocurrió con Mubit? Descubierto en 2023, fue una brecha

36
00:02:48,960 --> 00:02:53,439
masiva de seguridad que afectó a miles de organizaciones en todo el mundo. Los atacantes

37
00:02:53,439 --> 00:02:58,520
atribuidos al grupo SIOP explotaron una vulnerabilidad de día cero en Mubit.

38
00:02:59,919 --> 00:03:04,060
Un popular software de transferencia segura de archivos utilizado por empresas

39
00:03:04,060 --> 00:03:07,099
para compartir al final datos sensibles con clientes y socios.

40
00:03:07,699 --> 00:03:10,180
¿Qué hicieron exactamente los atacantes?

41
00:03:10,379 --> 00:03:15,400
Los atacantes aprovecharon una vulnerabilidad de inyección de SQL en Mubit Transfer.

42
00:03:16,379 --> 00:03:21,699
La vulnerabilidad permitió ejecutar código arbitrario y acceder a las bases de datos.

43
00:03:21,699 --> 00:03:25,699
Extrajeron información sensible al final de miles de organizaciones

44
00:03:25,699 --> 00:03:30,860
El grupo SEOP, obviamente, amenazó con publicar los datos robados

45
00:03:30,860 --> 00:03:33,360
Si no se les ofrecía un rescate económico

46
00:03:33,360 --> 00:03:38,180
Al final, muchas organizaciones desconocían que estaban afectados

47
00:03:38,180 --> 00:03:42,020
Hasta que sus proveedores les notificaron del problema

48
00:03:42,020 --> 00:03:45,139
Y llegamos al tercer punto

49
00:03:45,139 --> 00:03:49,500
Cada 39 segundos se produce un nuevo ciberataque en algún lugar del mundo

50
00:03:49,500 --> 00:03:57,659
sumado a más de 2.200 ataques diarios solamente en España. Es decir, la situación es bastante comprometida a día de hoy.

51
00:04:00,099 --> 00:04:06,780
¿Qué proponemos? ¿Qué ofrecemos? Nos basamos en tres pilares con nuestra solución.

52
00:04:07,419 --> 00:04:13,539
Una detección temprana y proactiva, reduciendo el tiempo de detección de semanas y días a minutos

53
00:04:13,539 --> 00:04:16,720
mediante un análisis de tráfico en tiempo real con Suricata,

54
00:04:16,720 --> 00:04:23,000
Identificando patrones sospechosos antes de que se conviertan en brechas para nuestra organización

55
00:04:23,000 --> 00:04:27,220
Tenemos un segundo pilar, la visibilidad centralizada y contextual

56
00:04:27,220 --> 00:04:35,160
Al final transformamos miles de alertas generadas en un log en dashboards intuitivos gracias a Grafana

57
00:04:35,160 --> 00:04:40,939
Permitiendo ver patrones de ataque, priorizar amenazas y responder a incidentes con información completa

58
00:04:40,939 --> 00:04:45,339
Nuestro tercer pilar es la adaptabilidad y la escalabilidad

59
00:04:45,339 --> 00:05:01,360
Ofrecemos una solución que evoluciona con las amenazas mediante reglas personalizables y una arquitectura modular que se adapta a cualquier entorno. Lo de las reglas personalizables, guardarlo para más adelante porque lo analizaremos.

60
00:05:01,360 --> 00:05:08,680
protegemos al final infraestructuras desde pequeñas empresas hasta infraestructuras

61
00:05:08,680 --> 00:05:17,740
críticas pymes empresas grandes infraestructuras críticas al final la solución puede abarcar a

62
00:05:17,740 --> 00:05:28,759
todo tipo de entornos cuál es la arquitectura la arquitectura que ofrecemos es la siguiente

63
00:05:28,759 --> 00:05:31,079
Suricata como motor IDS-IPS

64
00:05:31,079 --> 00:05:32,699
que analizará el tráfico

65
00:05:32,699 --> 00:05:35,120
de red y generará las alertas

66
00:05:35,120 --> 00:05:37,079
¿Qué es

67
00:05:37,079 --> 00:05:39,379
exactamente IDS-IPS?

68
00:05:40,180 --> 00:05:40,980
IDS

69
00:05:40,980 --> 00:05:43,079
es el modo

70
00:05:43,079 --> 00:05:45,000
de Suricata para leer el

71
00:05:45,000 --> 00:05:46,959
tráfico sin interferir con él

72
00:05:46,959 --> 00:05:48,980
es decir, generará alertas en el

73
00:05:48,980 --> 00:05:51,040
archivo if.json pero no

74
00:05:51,040 --> 00:05:52,019
bloqueará el

75
00:05:52,019 --> 00:05:54,720
contenido malicioso

76
00:05:54,720 --> 00:05:56,819
simplemente estará escuchando

77
00:05:56,819 --> 00:06:00,139
analizará el tráfico y nos lo volcará en los dashboards.

78
00:06:01,139 --> 00:06:06,839
En modo IPS, Suricata se colocará inline en el flujo de tráfico.

79
00:06:07,000 --> 00:06:07,819
¿Esto qué quiere decir?

80
00:06:07,920 --> 00:06:10,540
Que analizará paquetes antes de que lleguen a su destino.

81
00:06:11,360 --> 00:06:15,300
Puede descartar paquetes maliciosos según las reglas configuradas.

82
00:06:16,639 --> 00:06:22,379
Lo único y el punto importante requiere una integración con Firewalls.

83
00:06:22,379 --> 00:06:31,180
Ok, pasamos a Promptail, que será la gente que recoja los logs de Suricata y extraerá la información relevante.

84
00:06:31,339 --> 00:06:33,160
¿Qué es exactamente lo que hace Promptail?

85
00:06:33,899 --> 00:06:41,579
Lee continuamente el archivo .json de Suricata, extraerá la información clave, como por ejemplo el tipo de evento,

86
00:06:41,579 --> 00:06:57,139
la firma de alerta, la severidad, IPs de origen, IPs de destino, puertos, y transformará toda esta información en etiquetas, en labels, y enviará los logs estructurados a Loki.

87
00:06:57,139 --> 00:07:25,639
Y pasamos al punto 3, Loki. Loki al final almacena y permite consultar los logs de una manera eficiente. Recibe y almacena los logs enviados por Promtail, indexa por etiquetas, permite consultas complejas utilizando LogQL, facilita agregaciones como conteos, promedios y tendencias y nos retendrá un histórico según las políticas que configuremos.

88
00:07:25,639 --> 00:07:30,480
Al final, escala horizontalmente para manejar grandes volúmenes de alertas.

89
00:07:31,779 --> 00:07:34,899
Vale, y pasamos a la siguiente diapositiva.

90
00:07:35,120 --> 00:07:41,100
Y aquí tenemos el verdadero poder de la conjunción de todas estas herramientas.

91
00:07:42,360 --> 00:07:43,779
¿Qué tenemos aquí?

92
00:07:43,980 --> 00:07:49,120
Tenemos, por ejemplo, el panel, el dashboard de Grafana,

93
00:07:49,720 --> 00:07:51,639
con, por ejemplo, suricatas IPs,

94
00:07:51,639 --> 00:07:58,920
IPs, que nos muestra el top de origen que generan más alertas, top IP de destino que reciben más ataques.

95
00:08:00,120 --> 00:08:06,000
Luego también tenemos el Suricata Type Rules, que nos distribuye las alertas por categoría,

96
00:08:06,800 --> 00:08:14,220
las tendencias de tipo de ataque a lo largo del tiempo, signatures más activadas y la severidad de alertas por tipo.

97
00:08:14,220 --> 00:08:28,779
Luego tenemos Suricata Proto, que al final son los protocolos de red, distribución de alertas por protocolo, TCP, UDP, ISMP, HTTP, DNS, etc.

98
00:08:29,199 --> 00:08:37,419
El volumen de tráfico por protocolo, las anomalías en el uso de protocolos, protocolos no estándar o encapsulados, etc.

99
00:08:37,419 --> 00:08:57,179
Luego tenemos Suricata Destination Ports, como bien indica el nombre, top puertos de destino con más alertas, distribución de ataques temporales por puerto, puertos no estándar con actividad sospechosa, correlación entre puertos y tipos de ataque, etc.

100
00:08:57,179 --> 00:09:18,139
Esto al final son los dashboards de Grafana. Toda la información que volcamos del if.json de Suricata lo vemos centralizado en todo esto. Todo esto al final es personalizable, es configurable, es decir, podemos editar las vistas que necesitemos.

101
00:09:18,139 --> 00:09:40,559
Las reglas personalizadas. Las reglas personalizadas al final es uno de los puntos más importantes en todo esto. ¿Por qué? Porque nos permite detectar amenazas específicas para nuestro entorno que las reglas genéricas posiblemente no nos cubran.

102
00:09:40,559 --> 00:10:00,419
Cuando se visualizan estas reglas, obtenemos una capa de defensa adaptada a nuestras necesidades. Es decir, podemos generar reglas personalizadas, pues por ejemplo, una detección de desfiltración de datos.

103
00:10:00,419 --> 00:10:02,639
Perdón

104
00:10:02,639 --> 00:10:06,419
Esta regla la detecta cuando un equipo interno, por ejemplo

105
00:10:06,419 --> 00:10:11,220
Un equipo cliente de cualquier usuario dentro de nuestra organización

106
00:10:11,220 --> 00:10:14,860
Envía una cantidad inusualmente grande de datos

107
00:10:14,860 --> 00:10:18,820
Por ejemplo, más de 500K, más de 1M, más de 2M, etc.

108
00:10:19,460 --> 00:10:21,960
Hacia internet utilizando el protocolo HTTP

109
00:10:21,960 --> 00:10:24,840
¿Por qué HTTP?

110
00:10:24,840 --> 00:10:35,840
Porque al final los atacantes utilizan HTTP para filtrar datos robados ya que pasa fácilmente por los firewalls.

111
00:10:36,480 --> 00:10:45,720
Esta regla detectaría cuando alguien podría estar enviando archivos grandes, por ejemplo, bases de datos, documentos confidenciales, etc. hacia el exterior.

112
00:10:47,120 --> 00:10:50,980
¿Qué más tipos de alertas podemos generar personalizadas?

113
00:10:50,980 --> 00:11:09,179
Por ejemplo, protección de activos críticos fuera de horario. Esta regla que nos permite, por ejemplo, generar una alerta cuando un dispositivo accede a servidores definidos como críticos fuera del horario laboral, por ejemplo, de 8 de la mañana a 8 de la tarde.

114
00:11:09,179 --> 00:11:30,919
¿Por qué es importante al final este tipo de reglas? Porque muchos ataques al final ocurren fuera del horario laboral, pues evidentemente cuando hay menos supervisión. Esta regla implementa el principio de comportamiento anómalo temporal. Si nadie debería de acceder a estos servidores fuera del horario, cualquier acceso debería de ser sospechoso.

115
00:11:30,919 --> 00:11:38,259
¿Vale? ¿Qué más reglas? Por ejemplo, podemos crear control de acceso a las bases de datos SQL

116
00:11:38,259 --> 00:11:45,620
Esta regla detectaría intentos de inicios de conexión al puerto 1433 SQL Server

117
00:11:45,620 --> 00:11:49,740
Desde cualquier origen que no esté en la lista de clientes autorizados

118
00:11:49,740 --> 00:11:58,840
Esta regla es importantísima al final porque las bases de datos contienen al final información crítica y confidencial

119
00:11:58,840 --> 00:12:07,320
Esta regla implementa el principio de whitelist, es decir, solamente los sistemas explícitamente autorizados deberían poder conectarse a la base de datos.

120
00:12:11,250 --> 00:12:20,830
Ventajas al final de toda esta solución. La solución al final es modular, es escalable y basada en software libre, es decir, que al final el costo de licencias es cero.

121
00:12:21,870 --> 00:12:29,250
No es un gran desembolso económico. Nos permite una visibilidad centralizada gracias a Grafana.

122
00:12:29,250 --> 00:12:54,370
Tenemos un montón de dashboards personalizables, podemos volcar un montón de datos del tráfico de nuestra red, de lo que está sucediendo y en tiempo real, un dato muy importante al final, gracias a Suricata, está leyendo todo el rato el flujo de nuestro tráfico de la red.

123
00:12:54,370 --> 00:13:11,350
Es decir, tenemos una visión en tiempo real de lo que está sucediendo en nuestro entorno. Todo esto nos facilita la investigación de incidentes y la generación de informes. Es decir, tenemos los datos en tiempo real.

124
00:13:11,350 --> 00:13:20,590
Podemos ayudarnos de todo ello a la hora de generar informes, a la hora de investigar un incidente

125
00:13:20,590 --> 00:13:26,639
Y llegamos finalmente a la conclusión

126
00:13:26,639 --> 00:13:30,539
No es cuestión al final de si seremos atacados, sino de cuándo

127
00:13:30,539 --> 00:13:34,419
En un mundo donde cada 39 segundos ocurre un ciberataque

128
00:13:34,419 --> 00:13:38,419
La pregunta ya no es si nuestra organización será un objetivo, sino de cuándo

129
00:13:39,440 --> 00:13:43,279
La diferencia al final entre una brecha catastrófica y un incidente contenido

130
00:13:43,279 --> 00:13:46,399
está en nuestra capacidad de detección y de reacción.

131
00:13:47,340 --> 00:13:51,460
El coste de la inacción es insostenible en estos momentos.

132
00:13:52,279 --> 00:13:56,620
Mientras que implementar esta solución, evidentemente, tiene un coste inicial,

133
00:13:57,460 --> 00:14:03,220
el coste de no hacerlo puede ascender a cientos de miles y millones de euros por brecha.

134
00:14:04,360 --> 00:14:11,559
Más un dato muy importante que cada vez se tiene, obviamente, más en cuenta,

135
00:14:11,559 --> 00:14:22,360
el daño reputacional. Al final, este tipo de brechas genera una catástrofe y la pérdida de confianza en clientes y socios

136
00:14:22,360 --> 00:14:30,320
puede ser una ruina para una organización. Al final, esta solución nos ofrece ser reactivos, ser proactivos,

137
00:14:30,320 --> 00:14:39,059
pasar de ser víctimas a ser defensores, la idea de la ciberseguridad. Esta solución no solamente transformará nuestra posición técnicamente,

138
00:14:39,059 --> 00:14:57,059
Al final de esperar el inevitable ataque, un inevitable desenlace de todo esto, tenemos la capacidad de reaccionar a todo esto y a prevenir los ataques antes de que ocurran.

139
00:14:57,059 --> 00:15:17,240
Y nada, espero... No me quiero pasar de pantalla. Bueno, listo. Gracias y espero que les haya gustado la presentación y bueno, eso es todo.

140
00:15:18,100 --> 00:15:18,779
Muchas gracias, Carlos.

141
00:15:23,629 --> 00:15:23,870
Sí.

142
00:15:23,870 --> 00:15:35,289
Sí, una pregunta que te haría es, ¿qué es la parte del proyecto que más te ha costado o cuál crees tú que puede suponer lo más difícil de implementar este proyecto?

143
00:15:35,590 --> 00:15:52,070
Sí, la parte al final más costosa de implementar son las reglas personalizadas, es decir, tenemos que hacer un análisis de nuestra organización, de nuestro entorno para saber y descubrir qué es crítico.

144
00:15:52,070 --> 00:16:09,190
Es decir, qué servidores tenemos, qué necesidad tenemos de vigilarlos, definir qué es crítico, qué no es crítico, es al final lo complicado de implementar este tipo de proyectos.

145
00:16:09,190 --> 00:16:31,889
Porque requiere un análisis al final de toda la organización, contabilidad, sistemas, al final abarca un montón de cosas, producción, depende de nuestro ámbito de la empresa a la que nos queramos enfocar, tenemos que hacer un análisis individual al final de esta solución.

146
00:16:31,889 --> 00:16:42,149
Muy bien. Bueno, Carlos, pues muchísimas gracias por realizar tu exposición. Voy a proceder a detener la grabación, ¿vale?

147
00:16:42,549 --> 00:16:43,769
Perfecto, muchísimas gracias.