[0:07]Supervisión, monitorización y alarmas. Acá quiero marcar bien la diferencia entre lo que es un Network Operation Center y lo que es un Security Operation Center, que son dos temas que vamos a desarrollar con más detalle a lo largo de la materia, ¿no? El Network Operation Center tiene la función de supervisar y monitorizar la infraestructura. Control de fallos, control de actividad, control de ancho de banda, caídas, enlaces, eh, no, perdón, no funcionamiento, disco, temperatura, humedad, capacidades remanentes. Esa es la función de un NOC. El Network Operation Center tiene que velar para que la infraestructura funcione. Y solucionar problemas de caídas y y mantener disponible la infraestructura. En cambio, el Security Operation Center tiene que ser proactivo y preventivo eh eh proactivo y post-activo en todo lo que sean medidas de seguridad, ¿no? El Security Operation Center es el que tiene que hacer los penetration test, las auditorías de seguridad, el control de bastión, el control de contraseñas, la monitorización de ataques desde el exterior, el control de los IDS, la operación de reglas de firewall, tiene que velar por la seguridad. Entonces, son dos roles muy muy muy bien diferenciados. Entonces, el Network Operation Center maneja herramientas de supervisión, monitorización y alarmas, relacionadas a la función de de disponibilidad de de su infraestructura. En cambio, el Security Operation Center utiliza herramientas de supervisión, monitorización y alarmas de la seguridad de esa red. La verdad que son dos roles muy muy, cuando uno tiene acceso a a grandes redes y ve el trabajo del día a día de un NOC y de un SOC, la verdad que se ve se ve bien la diferencia de estas cosas, ¿no? ¿Qué suele suceder? Es muy normal que una empresa pueda tener un NOC para el funcionamiento, cuando ya tiene una infraestructura importante, pero un SOC suele costar más caro, entonces a veces el NOC asume funciones de SOC y tenemos ese doble perfil, ¿no? Que bueno, eso depende de los recursos que tenga la empresa. Muchas veces el NOC no se mete a cuestiones de SOC y el SOC se terceriza con cierta periodicidad, que realicen revisiones, que realicen auditorías, que realicen penetration tests, que hagan investigaciones de que me mantengan al tanto de alarmas y alertas de seguridad, etcétera. Pero bueno, son dos cosas muy diferentes, ¿no? Lo importante es ser muy conscientes de esto, tener en cuenta que cuando hay una anomalía cualquier fallo tiene mucha potenciabilidad de dejarme las cosas fuera de servicio, entonces siempre hago hago hago hincapié en que debe tener un procedimiento muy bueno, ¿no? ¿Qué cuáles son indicadores raros? Pues un incremento raro del ancho de banda, si permanentemente mi flujo era de 100 megabits por segundo en los rutes de salida en un segmento determinado y de golpe se me va a 3 GB, algo raro está pasando. Cuando se sature el ancho de banda, las plataformas de supervisión me lo suelen marcar clarito, ¿no? En semáforos verde, amarillo, rojo, si un ancho de banda que venía perfecto en verde en un momento se me empieza a poner amarillo y tira para el rojo, algo raro hay. Caídas secuenciales, en cualquier red, eh, a veces, cuando uno va a las primeras veces a a auditar, a controlar un NOC, la verdad que siempre llama la atención la cantidad de alarmas rojas que hay, ¿no? Pero a medida que uno empieza a entender el funcionamiento de un NOC que maneja 10.000 dispositivos de red y de TI, es normal que eh todavía no se haya actualizado el antivirus, el sistema operativo, la aplicación, la actualización del disco, que se caiga una interfaz de red, son problemas cotidianos. Lo raro es cuando empieza secuencialmente a producirse un mismo daño, ¿no? Es decir, se me cayó un servidor Windows 2016, al rato el otro, al rato el otro, al rato el otro, eso no es normal ya. Se me cayó la aplicación o se me saturó un disco duro eh en en el clúster X, se me clúster el mismo disco duro, la misma función en el clúster I, esas son cosas cuando se concatenan fallos de similares tecnologías son síntomas de alerta. Propagación abusiva de un determinado patrón de tráfico. Vamos a ver dentro de un ratito, nos vamos a meter ya con el tema de IDS y si yo mis IDS los tengo bien ajustados, este, cuando me empiezan a saltar alarmas sobre un mismo patrón de tráfico que empieza que antes no estaba o tenía una una un un hit cada 4 horas y de golpe empiezo a tener ese mismo hit, esa esa salta esa alerta tres veces por minuto, algo raro hay. Los ataques a DNS son algo muy común, tanto porque sirven para lo que se llaman ataques de amplificación, como para por supuesto alterar las rutas, cuando yo me creo que me estoy conectando a Google y realmente no es Google, sino que es un una página de hacking, ¿no? Entonces, los DNS son plataformas que hay que tenerlas muy muy controladas y cuando hay algo raro en el flujo de los DNS, es algo peligroso. Cuando se me empiezan a saturar los logs de forma imprevista, de forma anormal, es raro. Mensajes de anómalos en los logs de los elementos, ¿no? Cuando aparecen mensajes raros, cosas que antes no me aparecían. Bueno, alarmas base de datos, alteraciones de ruta, fallos de sistema, estas son cuestiones que poco a poco un NOC debe empezar a a controlar, ¿no? Cuando suceden, tengo un procedimiento, sé qué pasos seguir, todo esto si no se ensaya, no se practica, no se escribe, no se implanta, esto es lo que hace que la reacción de una red pueda ser catastrófica, ¿no? Dentro del workflow, acuérdense que yo siempre hablo de mantener un un robusto sistema de ticketing, ¿no? Que me quede el historial de cada cambio, de cada modificación, cada cosa nueva, cada baja que se haga en la red. Está contemplado ticket para este evento determinado. Está tipificado este flujo, los sistemas de ticketing en general están eh cuando se desarrollan, son eh muy parametrizables, que es una herramienta como Remedy, que es muy conocida, eh uno puede cuantificar cuál es el flujo de cada tipo de de de detonante de un ticket, ¿no? Eh, es muy importante tener el flujo de los diferentes tickets que afectan a la seguridad, para que cuando alguien lo tenga, pique alarma, en ruta, en puerto, en switch, tal, en tal segmento, eh derivado a tal segmento de operación de red, responsable, teléfono, esos tickets ya los tenga armados, ¿no? Y la jerarquía, como tiene que escalar.Bueno, esta es la parte teórica, ¿no? Estas tareas entonces, eh, tenemos que tener en cuenta NOC, SOC y algunos centros de supervisión de red que a veces los hay y específicos, ¿no? Cuando mi red tiene diferentes zonas, por ejemplo, eh una red grande como la red de una empresa de telefonía. Tiene áreas que son específi, áreas, yo hablo de cientos, miles de personas que solo saben de la red móvil, gente que solo sabe de la red fija, gente que solo sabe de la red de acceso, gente que solo sabe de la red de transporte, gente que solo sabe del core IP, gente que solo sabe de las plataformas, infraestructura. Entonces, hay áreas muy muy específicas que son cientos de personas, ¿no? Cada una de esas áreas, independientemente de los NOC centrales o descentralizados que tenga la empresa, suele haber cuando las magnitudes son muy grandes, centros específicos que están supervisando el funcionamiento de 4G en la red de acceso. Y es la gente que mide, por ejemplo, la calidad de la red 4G, ¿no?
[9:05]¿Qué otro tema, qué otra plataforma suele haber? Centralización y explotación de logs, eso vamos a verlo ahora mismo. Estas plataformas SIEM nacen de dos dos conceptos diferentes, Security Information Management y Security Event Management, ¿no?
[9:31]Eh, nosotros vamos a utilizar un SIEM que es la plataforma o SIEM. Los SIEM comerciales eh que yo conozco, suelen ser EnVision de RSA, que ahora creo que se llama esto es eh no es más de RSA. ArcSight de HP y Splunk son las tres plataformas que siempre pongo, ¿no? Este, cuando se ha desplegado o ya está en producción este tipo de plataformas, desde el punto de vista de seguridad deberíamos verificar estos dos grandes aspectos de la misma. El nivel de implantación y el nivel de seguridad en la gestión. Es decir, cuando uno implanta un SIEM, se cree que tiene que empezar a recibir a lo bestia todos los los logs de todos los elementos de la de la infraestructura y no es así, porque si es así lo reviento. O empiezo a meter tal cantidad de árboles que dentro de ese bosque yo soy capaz de de identificar cuál es el árbol que tiene problema, ¿no? Entonces, el nivel de implantación y explotación tiene que ser muy analizado y y estudiado, ¿no? Es decir, a mí no me interesa que me logueen todas las reglas de de ese firewall como acaban de ver. A mí me interesa que ciertas reglas lo bien, a mí no me interesa que la la infraestructura de log de Unix o de Windows me machaque con el 100% de los logs. A mí me interesarán los accesos, los accesos no autorizados, los fallos de autenticación, eh, algunos logs de de peligrosidad de bastionado. Tengo que ir muy muy al detalle de cuáles son los logs que realmente me interesa centralizar, ¿no? Y poco a poco empezar a explotar esos logs. De nada me sirve recibir millones de log por minuto si no empiezo a estudiar y a correlacionar, ¿no? A mezclar que cuando este usuario entró por esta interfaz, escaló a root y luego saltó, si yo no empiezo a obtener reglas lógicas que me correlacionen los logs que voy recibiendo, no me sirve de nada, es un mero repositorio. Eso no es un SIEM. Un SIEM es algo que tiene que empezar a generar reportes que me den valor agregado a la a la infraestructura, ¿no?
[11:51]Entonces, bueno, qué aspectos, nivel de implantación. Bueno, da una mirada, esto es rollo de teoría, ¿no? Nivel de seguridad en la gestión de la plataforma. Miren, vamos a ver una presentación de RSA EnVision, que tiene el interesante esta esta presentación. Aquí están viendo los distintos tipos de dashboard que puede tener el cómo se componía, esto ha cambiado, ¿no?, pero cómo se componían en esos momentos del conjunto de paquetes. Esto, fíjense que esto es interesante, ¿no? Está recibiendo, en este ejemplo, está recibiendo en tiempo real logs de diferentes lugares del mundo en este caso, ¿no? Y a su vez, todo esto lo va guardando dentro de una API, ¿no? Esto a través de una API va recibiendo reporting y alertas, investigaciones, análisis de malware y esto lo puede ir derivando a a un análisis de gestión de incidentes, de criticidad de activos, de cumplimiento legal, estas son las correlaciones que puede hacer. Y a su vez, tiene todo un sistema que a medida que estas bases de datos se procesan, va sacando los indicadores clave de rendimiento API y eso se almacenan en bases de datos que ya van a largo plazo. Entonces, cuando yo quiero sacar, detecto un error de cumplimiento y quiero hacer el análisis de todo eso durante el último mes, eso ya no me lo va a dar en tiempo real, por supuesto, porque no puede procesar los miles de millones de eventos que ha recibido, pero sí, si supe definir bien los indicadores clave, yo puedo generar un reporte a largo plazo y ya fuera de tiempo real de algo que ha sucedido y hacer todo el forense de ese evento, ¿no? Bueno, big data, alta potencia, inteligencia integrada, una infraestructura de big data que me permite sacar elementos de las diferentes valores. Bueno, esto es una presentación que quería que vieran un poco las características que puede tener un IDS caro, como es este, y de de alta capacidad. En general, los IDS tienen siempre el gran defecto que a medida que empezamos a acumular, acumular, acumular, todo ese reporte histórico, si yo no le he definido bien la la las indicadores clave de rendimiento, generar un reporte del último mes, me puede tardar dos días en estar. Entonces, detalles, de seguridad, ¿cómo se despliega? Ven las diferentes infraestructuras que yo quiero controlar, van conectados a este warehouse, que es la parte a a largo plazo y el modelo de metadatos, cómo quiero que esos indicadores clave se gestionen. Todo eso a través de una API va a una consola donde puedo hacer investigación, análisis de malware, administración, repositorio, etcétera. Estamos hablando de toda una infraestructura, esto no es un hardware solo, ¿eh? Cada uno de los recolectores de logs lo decodifican, concentran, decodificar los logs, tengan en cuenta que hay que normalizarlos, ¿no? No es lo mismo un log de Oracle que un log de Macintosh, que un log de base de datos MySQL, que un log de Internet Explorer, que un log de Unix, cada una de esas cosas tienen formatos diferentes que si no los normalizo, no los puedo correlacionar.
[15:04]Bueno, cómo se se puede procesar. Bueno, esta es una presentación que, para si tuviéramos tiempo, merecería la pena, pero bueno, quería que sean conscientes de que cada una de estas cosas son son despliegues que en una infraestructura grande no es trivial, ¿eh? Tiene mucho, mucho trabajo y mucho mucho cantidad de de avance y ajustes a lo largo del tiempo, no es algo yo lo planto ahí y trabaja por sí solo, ¿eh? Qué cosas raras, ¿ven? Estos son ejemplos de logs que puede estar recibiendo un IDS. En esto que están viendo acá abajo, ¿qué cosa les llamaría la atención? ¿Por qué me debería generar una alarma esto que están viendo aquí en azul? ¿Qué les parece? Piense que es totalmente ilógico, pero absolutamente ilógico que el protocolo ICMP tenga la misma dirección ICMP es el Internet Control Messaging Protocol, por ejemplo, el ping, ¿no?
[16:01]El comando ping, es el ICMP tipo cero, la de request, y el tipo ocho la respuesta, ¿no? El traceroute, hay un montón de comandos, el el protocolo ICMP tiene eh tipos y códigos, ¿no? Y dentro de los tipos y códigos tiene infinitas cantidades a saber si un servicio es alcanzable, si está administrativamente prohibido, si ese puerto está abierto, hay un montón de combinaciones entre tipo y código que lo hacen extremadamente peligroso. El protocolo ICMP es uno de los protocolos tal vez más peligrosos a nivel red. No tiene ninguna lógica que haya protocolo ICMP en la misma fuente y el mismo destino, es decir, por la misma interfaz me estoy haciendo ping a mí mismo. Esto sí que es muy raro, ¿eh? En un segundo se han generado 10 paquetes con el mismo protocolo, el mismo, el mismo destino. 10 paquetes por segundo ya sí que a mí esto sería casi casi un umbral para que a mí me diga, Ali, empeza a mirar esto, empeza a mirar esto, porque acá potencialmente puede haber algo raro, ¿eh? No digo que ojo que hay veces que se repiten, hay paquetes que hay determinados tipos de tráfico en grandes redes que sí suceden más de un paquete por segundo. Pero bueno, si yo trabajé bien con mi SIEM y está recibiendo este tipo de eventos, esto podría ser el inicio de una alarma. No digo que esto esté bien o mal, pero si yo estoy en un NOC, yo acá ya debería empezar a ver alguna aguja que se me pone en amarillo, algún semáforo que me está diciendo, guarda con este tráfico. Esa es la función de un SIEM. Y por último, ¿hm? Hemos agrupado acá detección, prevención y mitigación, ¿no? Esto lo vamos a ver como IDS o IPS. En el libro de seguridad por niveles tienen todo lo que habla sobre IDS, pero acá sí, para no hacer tan larga la clase del día de hoy, vamos a pasar a la forma práctica. Bueno, en la parte de descargas, en la parte de tecnología, en artículos, hay un artículo que, a ver si lo encontramos, metodología Nexus Snort. Miren, bajense este archivito de la web, yo en el año 2001, 2, 3, por ahí, con este chico, José Ignacio Bravo, que es un genio, esto es una de las mentes más brillantes que yo he visto en España, soy muy amigo, eh, tuvimos la posibilidad de hacer el mayor despliegue de de IDS de Europa, ¿no? Y lo hicimos todo con Snort, nos pusieron a disposición todos los, hicimos un laboratorio con seis, siete diferentes fabricantes de IDS y Snort, que es gratuito.
[19:10]Este, y a partir de ahí, empezamos a generar tráfico con Nessus y es una herramienta para ver el nivel de bastionado y generar ataques y reportes del nivel de bastionado. La vamos a usar, quédense tranquilos. Entonces, lo importante es que en ese en ese en ese trabajo que hicimos, empezamos a ver que, hablamos de hace 20 años atrás prácticamente, ¿no? Que cada IDS respondía de forma distinta en base al patrón de tráfico que se generaba, por eso escribimos ese primer artículo que se llamó Nivel de Inmadurez, porque no era lógico que si yo atacaba con la regla N, un IDS me diga A, el otro B, el otro C, el otro no lo detecta, etcétera. Entonces, en ese momento estaba muy inmaduro. El lenguaje que utiliza Nessus para generar las reglas, se llama NASL. Que es un lenguaje muy muy sencillo, no tiene mucha complicación, es muy parecido al código Bash, al lenguaje de programación de Linux. Entonces, nosotros creamos reglas y algunos las detectaban y algunos tenían ya vulnerabilidades conocidas o no. Entonces, cuando cuando el IDS no tenía la regla, generábamos lo que se llaman local rules, ¿hm? Es decir, generamos nuestras propias reglas para que Snort las pueda detectar. Entonces, ese es el trabajo que vamos a hacer nosotros, porque estoy seguro que es lo más importante que les puede llevar a ustedes para el conocimiento de un IDS. Es decir, si ustedes están en capacidad de entender y generar reglas en Snort, que es lo más potente que hay en cuanto a personalización de reglas, les aseguro que van a ser gente importante en su capacidad de operar con IDS. Eh, yo he trabajado, como les decía, con muchos IDS y sigo considerando que Snort es lo mejor lejos que hay en el mercado. Y es lo mejor porque justamente tiene un nivel de ajuste de reglas que no creo que lo pueda tener ningún producto comercial. En este artículo, entonces, acá está explicado cómo enviábamos el ACK, etcétera, cómo buscábamos patrones de tráfico, fíjense que estas son capturas de Wireshark. Y esos mismos patrones de tráfico íbamos generando las reglas de Snort, que es lo que quiero que aprendamos, ¿hm? Entonces, acá están viendo cómo cómo se ve cuando uno quiere abrir una determinada regla con Nessus, uno puede ver cómo es el patrón de ataque que lanza Nessus. Pero bueno, todavía con Nessus no me quiero meter, pero sí me quiero meter con Snort, que es lo que viene acá abajo, en este artículo.
