Estudiar detenidamente los registros de seguridad durante horas y horas no es forma de pasar una tarde, pero es la única forma que tenemos de comprender realmente lo que sucedió durante un incidente de seguridad. Iniciar sesión en un dispositivo a la vez es la única forma que tenemos de averiguar por qué y cómo se bloqueó el tráfico en algún lugar de la red, pero no confiaría en los resultados.
La información de registro, el descubrimiento de redes y la comprensión en tiempo real del estado de la red son muy importantes para seguridad de la red que recopilamos grandes cantidades de datos de muchos de nuestros sistemas en un esfuerzo por rastrear y recordar todo lo que sucede en nuestras redes. Coleccionarlo es una cosa, pero hacerlo útil es otra cosa completamente diferente.
Configurar trampas SNMP y servidores syslog no es terriblemente difícil. Sin embargo, ser capaz de encontrar la proverbial aguja en el pajar puede ser tan tedioso y costoso que los departamentos de TI a menudo renuncian por completo al análisis forense de redes. Queremos registros extensos y, a menudo, estamos Requisitos tener registros extensos. Pero con la misma frecuencia, esos registros permanecen sin usar, sin explotar y, por lo tanto, sin sentido.
Un flujo de trabajo típico para un incidente de seguridad podría ser crear el incidente en el sistema de tickets, adjuntar la cadena de correo electrónico relevante al ticket, copiar un enlace al servidor de registro y luego cerrar el ticket. Hay poco más que alguien pueda hacer y poco tiempo para hacer algo de todos modos. Al menos así está en el sistema y el departamento de TI cumple.
El análisis forense de la red es extremadamente importante, pero es extremadamente costoso debido a la habilidad necesaria y el tiempo involucrado. ¿Cómo recopilamos datos específicos de cada dispositivo, independientemente de la plataforma? ¿Cómo nos aseguramos de que sea información precisa? ¿Y qué hacemos con todos esos datos una vez que los hemos recopilado? La seguridad de la red es importante, pero la seguridad de la red no es una configuración de conmutador o un modelo de firewall. Es todo un proceso, y no es fácil.
Recuerdo que un proveedor me preguntó quién dirigía nuestro equipo de seguridad de TI. Le di una mirada en blanco. En mi experiencia, solo las organizaciones muy grandes tenían personal de seguridad de TI dedicado y mucho menos equipos completos de ellos. Respondí que teníamos un departamento de unas pocas docenas de personas, y que la seguridad la administraba principalmente la gente de la red, ya que, para nosotros, la seguridad se trataba de firewalls, dispositivos IPS, 802.1x y otras tecnologías de red.
Pero sabemos que la seguridad de la red es mucho más que eso. Se trata de la visibilidad. Se trata de la capacidad de identificar comportamientos anómalos y de rastrear rápidamente dónde y cómo se bloquea el tráfico en una red de producción. Los ingenieros de redes pueden conocer todos los comandos para configurar el inicio de sesión en cada plataforma en su entorno, y es posible que sepamos cómo configurar una ACL mientras dormimos. Sin embargo, el proceso para hacer uso de este conocimiento e información a gran escala puede ser más costoso que el incidente de seguridad en sí.
Aquí tenemos un ejemplo muy práctico de cómo las tendencias actuales en la automatización de redes pueden ayudar al resultado final de un departamento de TI típico que lucha con los presupuestos, el personal y la extinción de incendios del día a día. Sé un poco de scripting básico de Linux y un poco de Python. Eso ayudaría, y esas son ciertamente buenas habilidades para que cualquiera las aprenda. Pero la realidad es que siempre he sido un jinete del enrutador. yo no DevOps gurú, y sospecho que la mayoría de los ingenieros de redes tampoco lo son. Entonces, ¿cómo podemos aprovechar fácilmente aspectos de la DevOps paradigma como la automatización de procesos, menor tiempo medio de recuperación, garantía de calidad y entrega continua?
La ruta más fácil y rápida para llegar allí es abstraer los procesos de secuencias de comandos y automatización detrás de un software intuitivo. De esa manera, los ingenieros de redes con conocimientos mínimos de secuencias de comandos pueden automatizar la recopilación de todo tipo de información que a menudo requeriría iniciar sesión en los dispositivos individualmente y ejecutar los comandos apropiados.
Por ejemplo, para un análisis de seguridad de la red de un cliente, me gustaría saber exactamente qué tipos de ACL se implementan en toda la red. Eso significa que tendría que mirar cada interfaz de capa 3 que tienen. En una red grande, es probable que haya muchos dispositivos con terminaciones de capa 3, por lo que esto llevaría tanto tiempo y sería tan propenso a errores que los resultados no serían confiables.
El software maduro que abstrae ese proceso sería una herramienta increíble en manos de cualquier ingeniero de seguridad. Siempre que sea algo personalizable y funcione con una variedad de plataformas principales, esto reduciría el tiempo y el costo necesarios para realizar una auditoría de seguridad y un análisis posterior al porteo. Asignar todas las interfaces de capa 3 y las ACL configuradas en ellas sería cuestión de unos pocos clics del mouse.
Además de poder mapear dinámicamente las topologías de la capa 3, este tipo de software necesita mapear visualmente la capa 2 para identificar los puertos bloqueados por Spanning Tree y rastrear las tablas ARP y MAC. Esto es increíblemente tedioso y requiere mucho tiempo para hacerlo manualmente y, a menos que un equipo de red tenga el lujo del tiempo y varios DevOps ingenieros, probablemente ni siquiera se intentaría en el análisis forense de seguridad de red típico.
Estudiar detenidamente los registros de seguridad e iniciar sesión manualmente en todos los dispositivos de una red no es forma de pasar una tarde, pero hay una forma mejor. El software que abstrae todas las partes difíciles de la automatización de la red puede convertir rápidamente grandes cantidades de archivos de registro en datos significativos y procesables e identificar dinámicamente las áreas problemáticas en un mar de Ethernet. Hoy en día, la proverbial aguja en el pajar se está volviendo mucho más fácil de encontrar sin arruinar su presupuesto de TI para el próximo año.