Gestión de incidentes
Prioriza incidentes por impacto financiero y negocio
Son las dos de la mañana. El tablero del SOC marca once alertas abiertas, tres analistas en turno y ninguna regla compartida sobre qué atender primero. A las nueve, el comité de dirección pregunta por qué el equipo pasó seis horas en un servidor de laboratorio mientras un buzón comprometido seguía enviando correos a clientes.
No falló la tecnología. Falló la prioridad.
He visto esa escena repetirse en organizaciones con stack moderno y gente competente. El patrón es siempre parecido: la herramienta asigna severidad, el analista obedece el número y el negocio descubre el impacto demasiado tarde. Mientras tanto, el reloj del incidente corre y el costo crece.
La pregunta que separa a un equipo maduro de uno reactivo no es cuántas alertas detecta, sino cuál apaga primero. Y esa respuesta casi nunca vive en la consola.
Por qué priorizar incidentes importa ahora
La priorización de incidentes dejó de ser un debate técnico y se convirtió en una conversación de negocio. Los comités de riesgo ya no preguntan cuántas vulnerabilidades se cerraron; preguntan cuánto costó el último evento y cuánto habría costado uno peor.
Esto ocurre por varias razones que se cruzan al mismo tiempo. Primero, el volumen de señales creció más rápido que la capacidad de análisis. Segundo, los marcos regulatorios exigen trazabilidad de decisiones, no solo evidencias de detección. Y tercero, la dirección quiere lenguaje financiero, no puntuaciones CVSS.
Además, el perímetro se desdibujó. Un mismo incidente puede tocar identidad, nube, endpoint y un proveedor externo en la misma hora. Cuando eso pasa, la severidad que asigna una consola resulta insuficiente para decidir.
Por eso insisto en una idea incómoda: la mayoría de los equipos no tiene un problema de detección. Tiene un problema de orden de atención. Detectan razonablemente bien y deciden con criterios heredados de una época con menos ruido y menos consecuencias.
En las conversaciones que sostengo con equipos de seguridad de la región, la queja se repite con distintas palabras. El analista sabe que el incidente del ERP importa más que el del servidor de pruebas. Lo que no sabe es cómo justificarlo por escrito cuando alguien revise la bitácora tres meses después.
Priorización de incidentes: el marco de decisión
Un marco útil tiene que caber en una guardia nocturna. Si el analista necesita abrir un documento de veinte páginas para decidir, no hay marco: hay burocracia. Por eso propongo tres ejes que se evalúan en menos de cinco minutos y quedan registrados en el ticket.
El primer eje es el impacto financiero. No requiere un modelo actuarial; requiere estimar qué proceso de negocio se detiene y cuánto vale una hora de esa parada. El segundo es la criticidad del activo, entendida como dependencia real, no como etiqueta del inventario.
El tercer eje es la exposición regulatoria y contractual. Un incidente con datos personales o con obligaciones de notificación cambia de categoría aunque técnicamente sea menor. Aquí conviene anclarse en el marco de ciberseguridad del NIST, que ordena la respuesta por función y no por herramienta.
- Impacto financiero: proceso detenido, ingresos en riesgo, costo de recuperación.
- Criticidad de negocio: dependencia de clientes, proveedores y servicios internos.
- Exposición regulatoria: datos personales, obligaciones de notificación, contratos.
- Alcance técnico: propagación posible y velocidad de contención.
Cuando los cuatro criterios apuntan en la misma dirección, la decisión es trivial. El valor del marco aparece en los casos grises, donde la severidad técnica dice una cosa y el negocio dice otra. Ahí es donde la priorización de incidentes se vuelve una disciplina y no una corazonada.
Impacto financiero: la métrica que ordena
Traducir un incidente a dinero incomoda a muchos profesionales de seguridad. Lo entiendo. Sin embargo, es el único lenguaje que compite en igualdad de condiciones con otras prioridades de la empresa.
No hablo de construir un modelo perfecto. Hablo de tener un orden de magnitud defendible. Si el equipo no puede decir si un incidente cuesta miles o millones, cualquier discusión con finanzas se pierde antes de empezar.
Cómo calcular el costo de un incidente
Empieza por las horas de parada del proceso afectado y multiplícalas por el valor hora que ya usa el área de operaciones. Suma el costo de respuesta, el desgaste del equipo y las posibles obligaciones de notificación. Ese cálculo básico cubre la mayoría de las decisiones operativas.
Después añade dos componentes que suelen olvidarse: la pérdida de confianza de clientes y el costo de oportunidad del equipo desplazado. Ambos son difíciles de cuantificar, pero ignorarlos distorsiona la comparación entre incidentes.
En la práctica, la mayoría de las organizaciones no necesita precisión contable. Necesita comparabilidad. Un ranking de impacto relativo bien construido permite decidir mejor que una cifra exacta obtenida tres semanas después del evento.
El error de priorizar por severidad técnica
La severidad técnica describe una característica del hallazgo, no una consecuencia para el negocio. Confundir ambas cosas es, en mi opinión, el error más costoso que cometen los equipos de seguridad hoy.
Un ejemplo frecuente: una vulnerabilidad crítica en un sistema aislado y sin datos reales genera más ruido que un acceso anómalo a una cuenta con permisos de facturación. La primera aparece arriba en el tablero; la segunda puede pasar desapercibida durante días.
Por eso conviene complementar la puntuación con contexto de comportamiento. Los patrones de TTP del MITRE ATT&CK ayudan a estimar hasta dónde puede llegar un adversario que ya está dentro, algo que ninguna puntuación estática captura.
Dicho eso, tampoco se trata de eliminar la severidad técnica. Se trata de reubicarla: primero el impacto, después el contexto táctico, y al final la puntuación como dato de apoyo. Ese orden cambia por completo la conversación en el comité.
Señales de que tu priorización está fallando
Los síntomas rara vez aparecen como una queja formal. Se manifiestan en fricción cotidiana, en horas extra y en decisiones que nadie documenta. Estas son las señales que detecto con más frecuencia cuando acompaño procesos de mejora.
- El analista decide según quién reportó la alerta y no según el impacto.
- Las alertas de mayor severidad se cierran sin evidencia de impacto evaluado.
- El comité de dirección se entera del incidente después de la contención.
- No existe un registro de por qué se eligió un incidente sobre otro.
- La misma discusión se repite en cada guardia sin criterio escrito.
- Los tiempos de respuesta varían según el turno y no según la criticidad.
Si reconoces tres o más de estas señales, el problema no está en la plataforma. Está en el criterio compartido. Y ese criterio se diseña, se escribe y se entrena.
Un caso de priorización bajo presión real
Escenario hipotético, construido para ilustrar el criterio y no basado en un cliente concreto. Banca mediana en España, 1.200 empleados, dos alertas simultáneas: un servidor de desarrollo sin datos productivos y un correo de un proveedor con acceso a facturación.
Con priorización por severidad, el equipo dedica las primeras horas al servidor de desarrollo. Con priorización por impacto, dedica los primeros veinte minutos a verificar el correo del proveedor y a suspender la sesión.
La diferencia no está en la herramienta. Está en el orden. En el primer escenario, la contención efectiva llega en la novena hora. En el segundo, en la primera hora y media. El tiempo ahorrado es, literalmente, dinero que no se pierde.
De hecho, la mayoría de las mejoras que veo en este terreno no vienen de comprar más detección. Vienen de reordenar lo que ya se detecta.
Priorizar incidentes con datos: el playbook
Un playbook útil cabe en una página y se puede auditar. No busca cubrir todos los escenarios posibles, sino eliminar la improvisación en los primeros treinta minutos, que es donde se define el costo final.
- Clasifica el activo por dependencia de negocio, no por etiqueta técnica.
- Estima el impacto financiero por hora con una cifra validada por operaciones.
- Revisa exposición regulatoria y obligaciones de notificación.
- Evalúa propagación posible con contexto de comportamiento del adversario.
- Registra la decisión y el motivo en el ticket antes de actuar.
- Revisa el criterio cada trimestre con casos reales del propio equipo.
El punto cinco es el que más resistencia genera y el que más valor aporta. Sin registro del motivo, la organización no puede aprender de sus propias decisiones. Y sin aprendizaje, cada guardia empieza de cero.
Priorización de incidentes en el SOC diario
En la operación diaria, el criterio debe bajar al turno. Eso implica tres cosas: una matriz simple visible en el tablero, un responsable claro de la decisión y un mecanismo de escalado cuando dos criterios chocan.
Además, conviene revisar la matriz con casos reales del mes anterior. Si el equipo descubre que tres incidentes clasificados como menores tuvieron impacto alto, la matriz está mal calibrada, no el equipo.
Finalmente, la gestión de incidentes de seguridad mejora cuando el análisis posterior no busca culpables. Busca ajustar el criterio. Esa diferencia cultural determina si el playbook vive o termina archivado.
El rol del mayorista de ciberseguridad
Aquí conviene ser explícito, porque hay confusión en el mercado. Un mayorista de ciberseguridad no opera el SOC del cliente ni responde a sus incidentes. Lo que aporta es criterio técnico, comparación entre alternativas y acompañamiento en el diseño del proceso.
Desde My IT Channel trabajamos con integradores, MSSP y equipos internos en LATAM e Iberia. En ese rol, veo un patrón claro: las organizaciones que mejoran su priorización suelen empezar por el proceso y no por la herramienta.
Es decir, definen el criterio, lo documentan y después buscan la plataforma que lo soporta. El orden inverso, tan habitual, produce despliegues caros con decisiones igual de improvisadas que antes.
Implicaciones prácticas para el CISO
Si tuviera que resumir esta discusión en decisiones concretas para los próximos noventa días, elegiría cinco. Todas son de bajo costo relativo y alto retorno operativo.
Primero, valida con operaciones el valor hora de los tres procesos más críticos. Sin esa cifra, el resto del marco queda en abstracto. Segundo, escribe una matriz de priorización de una sola página y publícala donde el turno nocturno pueda verla.
Tercero, exige registro del motivo de decisión en cada incidente relevante. Cuarto, revisa trimestralmente el criterio con casos reales. Quinto, forma al equipo en conversación financiera, no solo en análisis técnico.
En consecuencia, el CISO deja de pedir presupuesto con argumentos de miedo y empieza a pedirlo con argumentos de riesgo cuantificado. Ahí cambia la conversación con el consejo, y también cambia la relación con los proveedores.
Cuando ese marco está claro, elegir tecnología resulta mucho más sencillo. Y ahí es donde el acompañamiento de un mayorista de ciberseguridad ahorra tiempo: no porque decida por ti, sino porque ya ha visto qué combinaciones funcionan en entornos comparables.
Cómo saber si la priorización mejoró
La mejora se mide con pocas métricas y bien elegidas. La primera es el tiempo desde la detección hasta la contención efectiva, segmentado por nivel de impacto y no por severidad técnica.
La segunda es la proporción de incidentes donde existe registro del motivo de decisión. Si esa cifra crece, la organización está construyendo memoria operativa. La tercera es la cantidad de escalados al comité que resultaron innecesarios, señal de que el criterio local está bien calibrado.
Por otro lado, desconfía de las métricas que solo miden volumen. Cerrar más alertas no indica mejor criterio. Indica, en el mejor de los casos, más capacidad de procesamiento.
Predicción: el fin de la severidad como brújula
Mi predicción para los próximos dos años es concreta. La severidad técnica dejará de ser el criterio principal de priorización en las organizaciones maduras y pasará a ser un insumo más, junto al impacto financiero y la exposición regulatoria.
No ocurrirá por una decisión tecnológica, sino por presión de negocio. Los comités de riesgo exigirán trazabilidad de decisiones y las aseguradoras pedirán evidencia de criterio, no solo de cobertura.
Mientras tanto, la pregunta sigue abierta: si mañana a las dos de la mañana llegan tres alertas simultáneas y solo hay un analista disponible, ¿tu equipo sabe cuál atender primero y puede explicar por qué?
Si la respuesta depende de la persona de turno, tienes trabajo pendiente. Y no es trabajo de herramienta.
¿Cómo se priorizan los incidentes de ciberseguridad?
Se priorizan cruzando tres variables: impacto financiero estimado, criticidad del proceso de negocio afectado y exposición regulatoria. La severidad técnica entra después, como dato de apoyo. Un incidente que detiene ingresos o expone datos personales va primero, aunque su puntuación técnica sea menor que la de otra alerta.
My IT Channel
Suscríbete al Ciberblog
Recibe análisis técnicos, tendencias y recomendaciones de ciberseguridad directamente en tu correo.
