Puesto
Seguridad informática
¿Con cuánta rapidez os enteráis de una vulnerabilidad crítica en un sistema que tenéis en marcha? Esa cifra decide si la ventana entre la publicación y el parche es un riesgo o solo una tarea.
Conversación inicial
Cuatro preguntas por las que empezaríamos
¿Con cuánta rapidez os enteráis de una vulnerabilidad nueva en un componente que usáis?
Si es por un boletín semanal, la ventana de respuesta es una semana sea cual sea la gravedad.
¿Cuántas veces al día una alerta resulta ser falsa?
Si el equipo ha dejado de leer las alertas, la monitorización funciona sobre el papel y no de hecho.
¿Cuándo se decide apagar un servicio vulnerable?
Si la respuesta es nunca, porque el negocio no lo permitirá, conviene saberlo antes de un incidente y no durante.
¿Qué aplazáis primero cuando hay más incidencias que personas?
Normalmente: las vulnerabilidades medias y las revisiones, que es de donde salen los incidentes de dentro de seis meses.
Nos quedamos con reunir y priorizar, vosotros con el criterio y las decisiones
Reunir información sobre vulnerabilidades, filtrar el ruido de las alertas, recoger contexto durante un incidente y llevar la documentación se pueden quitar del escritorio. Juzgar la amenaza y decidir cómo responder se quedan con el especialista.
- Una vulnerabilidad se ata a vuestro entorno. - No toda vulnerabilidad crítica os afecta, y la prioridad depende de dónde se usa el componente y de si está expuesto.
- Una alerta llega con contexto. - Qué más ocurría en esa ventana, qué eventos están relacionados, si el patrón ya se dio antes.
- Un incidente tiene su cronología registrada. - Durante y no después, porque reconstruirla una semana más tarde siempre sale peor y siempre sale más caro.
Alcance
Qué se puede quitar de la seguridad informática
Diecinueve tareas de ejemplo. Cada una tiene un punto de aprobación humana. Abajo una selección, y el alcance lo ajustamos a vuestra superficie de ataque.
Vulnerabilidades y su prioridad
- Atar una vulnerabilidad publicada a los componentes que usáis
- Señalar los sistemas donde el componente está expuesto
- Una prioridad propuesta por exposición y criticidad (decisión: el especialista)
- El estado de la remediación por sistema
- Una señal cuando una vulnerabilidad crítica lleva abierta más de lo acordado
Monitorización y alertas
- Una alerta con el contexto de los eventos de la misma ventana
- Agrupar las alertas que comparten causa
- Señalar las reglas con mayor proporción de falsos positivos, excluidas las de gravedad alta
- Una señal cuando un sistema no tiene cobertura de monitorización
Incidentes
- Reunir los datos necesarios para valorar un evento
- La cronología del incidente registrada mientras ocurre
- Avisar a las personas acordadas según la gravedad (decisión: el especialista)
- Un borrador del informe posterior al incidente (contenido: el especialista)
Concienciación de los empleados
- Un calendario de formación y simulaciones de phishing
- Resultados resumidos por departamento, sin nombrar a personas
- Material de refuerzo para las áreas con peores resultados
Cumplimiento y auditorías
- Un resumen de la evidencia exigida por la norma
- El estado de las acciones correctivas tras una auditoría
- Un registro de excepciones de seguridad con fecha de revisión
Un día de trabajo
Hoy
- Os enteráis de las vulnerabilidades por listas y boletines
- Deducir si una os afecta lleva horas por sistema
- Las alertas llegan en cantidades que nadie revisa enteras
- Durante un incidente empezáis recogiendo registros de varios sitios
- Reconstruís la cronología del incidente a posteriori
- Recogéis la evidencia para una auditoría durante dos semanas
Con asistencia de IA
- Una vulnerabilidad se ata a los componentes que de verdad tenéis
- Veis dónde está expuesto el componente, y la prioridad tiene fundamento
- Las alertas están agrupadas y se señalan las reglas que generan ruido
- Un incidente empieza con el contexto ya reunido
- La cronología se registra mientras el evento se desarrolla
- La evidencia para la auditoría se reúne sobre la marcha
- Tiempo para corregir una vulnerabilidad crítica
una ventana más corta entre la publicación y el parche
la vulnerabilidad se ata al entorno de inmediato
- Ruido en las alertas de seguridad
el equipo lee las alertas, porque son menos
se señalan las reglas que generan ruido
- Tiempo de respuesta a un incidente
menos tiempo en reunir, más en decidir
el contexto está junto al aviso
- Resistencia al phishing
se ve qué áreas necesitan un refuerzo
los resultados de las pruebas están resumidos por departamento
Empezamos por atar las vulnerabilidades a vuestro entorno, porque es lo que más acorta el tiempo de respuesta.
- Paso 1
Vulnerabilidades frente a los componentes que usáis
Qué tenéis de verdad, dónde está expuesto, qué prioridad tiene para vosotros.
- Paso 2
Orden en las alertas
Agrupación, contexto y señalar las reglas que generan ruido.
- Paso 3
Gestión de incidentes
Contexto junto al aviso y la cronología registrada mientras ocurre.
- Paso 4
Cumplimiento y concienciación
Evidencia de auditoría y resúmenes de las simulaciones de phishing. Al final, porque descansa sobre tener en orden las vulnerabilidades y las alertas.
Preguntas frecuentes
Preguntas que surgen en la primera reunión
¿En qué se diferencia esto del mantenimiento de sistemas y de la gestión de accesos?
El administrador mantiene los sistemas en marcha, la gestión de accesos decide quién ve qué. Aquí el asunto son las vulnerabilidades, las amenazas y los incidentes. Las áreas se cruzan en las actualizaciones y en los permisos excesivos, pero las preguntas del día son completamente distintas.
¿Significa esto menos gente en seguridad?
Los equipos de seguridad son casi en todas partes demasiado pequeños para el número de alertas, y por eso las alertas dejan de leerse. Quitar el ruido no reduce el equipo: le devuelve la capacidad de notar lo inusual. En una cola saturada un ataque dirigido se pierde con más seguridad todavía, y de eso trata toda esta conversación.
¿Esto entra en el ámbito del Reglamento de IA?
La seguridad informática no es un uso de alto riesgo. La línea está en los datos sobre el comportamiento de los empleados: los resultados de las simulaciones de phishing y el análisis de eventos pueden apuntar a personas concretas, así que llevamos los resúmenes por departamento y sistema y no por nombre; de otro modo sería vigilancia de la plantilla.
¿Os queda alguna pregunta que no esté aquí? Reservad una llamada
Siguiente paso
¿Cuántas de vuestras vulnerabilidades críticas llevan abiertas más de un mes?
Os enseñaremos cómo es el trabajo de un equipo de seguridad cuando una vulnerabilidad se ata al entorno y un incidente empieza con contexto.