CROC: cuando detectar amenazas deja de ser suficiente

Detectar ataques más rápido sigue siendo fundamental. Pero la madurez de la ciberseguridad pasa a depender también de otra capacidad: entender qué exposiciones representan realmente un riesgo para el negocio, decidir dónde actuar primero y mantener las operaciones críticas funcionando cuando los controles fallan. De esa necesidad nace el Cyber Risk Operations Center, o CROC.

Este es el primer artículo de una serie de Futture sobre Cyber Risk Operations, y no da por sentado que conozcas el concepto: explica de dónde viene, qué resuelve, cómo se relaciona con el SOC, GRC y la continuidad, y por dónde empezar.

La paradoja de la ciberseguridad

Piensa en el inventario de seguridad de una gran empresa hoy: un SIEM que recibe millones de eventos al día, EDR o XDR en los endpoints, SOAR automatizando respuestas, gestión de vulnerabilidades, CSPM o CNAPP vigilando la nube, gestión de superficie de ataque, IAM y PAM, threat intelligence, una plataforma de GRC, un SOC operando las 24 horas y ejercicios de Red, Blue y Purple Team.

Y aun así siguen ocurriendo incidentes relevantes. Muchas veces, la información que habría evitado el incidente estaba ahí: la vulnerabilidad se había detectado, el activo estaba en el inventario, la alerta se generó. Faltó un proceso que conectara esos puntos a tiempo y concluyera: esto es lo que más importa ahora.

Quizás el problema no sea la falta de datos de seguridad. Quizás el problema sea convertir esos datos en decisiones de riesgo.

Una organización puede tener miles de vulnerabilidades abiertas, millones de eventos al día y cientos de alertas clasificadas como críticas, y aun así no poder responder preguntas que cualquier directorio considera básicas. ¿Cuál de estos problemas representa el mayor riesgo para el negocio? ¿Qué activo sostiene, de hecho, un proceso crítico? ¿Qué amenaza tiene capacidad y oportunidad para explotar una exposición determinada? ¿Qué control reduciría más riesgo con la misma inversión? ¿Cuánto riesgo se redujo efectivamente después de la última campaña de remediación? Y, si un ataque tiene éxito mañana, ¿el negocio puede seguir operando?

Ninguna herramienta aislada responde estas preguntas. Todas exigen combinar información que vive en sistemas, equipos y lenguajes distintos — y esa combinación, hecha de forma continua, es lo que llamamos Cyber Risk Operations.

El SOC sigue siendo esencial — pero resuelve otro problema

Antes de avanzar, una aclaración importante: nada en este artículo disminuye el papel del Security Operations Center. El SOC es la capacidad que detecta, investiga, responde y contiene. Trabaja sobre eventos, detecciones, amenazas e incidentes, bajo presión de tiempo. Sin él, la organización simplemente no ve el ataque mientras ocurre.

El problema aparece cuando se espera que el SOC también responda por el riesgo empresarial. Fue diseñado para responder "¿qué está pasando y cómo lo contenemos?", no "¿qué exposición tiene mayor probabilidad de convertirse en una pérdida relevante?". Exigirle eso suele producir dos distorsiones: tratar todo como urgente, o usar la severidad técnica como si fuera riesgo.

Un ejemplo vuelve concreta la diferencia. Una vulnerabilidad con CVSS 9.8 en un servidor aislado, sin acceso desde internet, sin datos sensibles y sin papel en ningún proceso relevante, puede representar menos riesgo que una vulnerabilidad con CVSS 7.5, explotable en remoto, en un sistema expuesto a internet que sostiene el proceso de pagos. Por la nota, la primera va antes. Por el riesgo, la segunda va mucho antes.

Severidad no es riesgo. La severidad describe qué tan grave es una falla en abstracto. El riesgo depende de quién puede explotarla, de qué expone, de qué controles hay entre el atacante y el activo y de qué le pasa al negocio si todo sale mal. Lo tratamos en detalle en el artículo sobre cómo leer la nota del CVSS 4.0.

Qué es un CROC

Un Cyber Risk Operations Center es un modelo operativo para identificar, contextualizar, evaluar, priorizar, tratar y monitorear de forma continua el riesgo cibernético. El término todavía no tiene una definición estandarizada en el mercado, y algunas organizaciones usan variaciones del nombre. Lo que importa es la función: convertir señales técnicas de distintos dominios de seguridad en contexto de riesgo, priorización y decisión.

El objetivo no es producir otro dashboard — muchos paneles de riesgo se consultan una vez por trimestre, la víspera del comité. Es construir un ciclo operativo de riesgo: algo que corre todas las semanas, tiene responsables, genera decisiones y mide si esas decisiones redujeron el riesgo.

Ese ciclo parte de una cadena de razonamiento que conecta el activo con la resiliencia del negocio:

1. Activo
2. Contexto de negocio
3. Superficie de ataque
4. Amenaza
5. Vulnerabilidad y exposición
6. Control
7. Riesgo cibernético
8. Impacto en el negocio
9. Tratamiento
10. Riesgo residual
11. Resiliencia

Vale la pena definir cada eslabón, porque buena parte de la confusión sobre riesgo viene de usar estos términos como sinónimos:

De Security Operations a Cyber Risk Operations

El cambio de modelo cabe en una comparación simple. Security Operations pregunta: ¿qué está pasando? Cyber Risk Operations mantiene esa pregunta y agrega otras: ¿qué significa esto para el negocio? ¿Tenemos que actuar ahora? ¿Qué riesgo debemos reducir primero? ¿Qué decisión produce la mayor reducción de riesgo con el esfuerzo disponible?

En la práctica, este enfoque — que algunos ya llaman Cyber RiskOps — se apoya en tres capacidades. La primera es la evaluación continua del riesgo: en lugar de una evaluación anual que queda desactualizada al día siguiente, el riesgo se recalcula cada vez que el entorno cambia — un activo nuevo, una vulnerabilidad nueva, una amenaza nueva, un control que dejó de funcionar. La segunda es la reducción continua del riesgo: el tratamiento deja de ser un proyecto y pasa a ser un flujo, con cola priorizada, responsables y plazos. La tercera es el monitoreo continuo del riesgo: seguir si el riesgo residual está dentro de lo que la organización acepta y detectar cuándo sale.

Las tres forman un ciclo cerrado. La evaluación alimenta la reducción; la reducción cambia el riesgo residual; el monitoreo detecta el cambio — o su ausencia — y devuelve el resultado a la evaluación. Cuando el ciclo funciona, la pregunta "¿cuánto riesgo redujimos este trimestre?" por fin tiene respuesta.

Cómo funciona el ciclo del CROC

Desglosado en etapas operativas, el ciclo tiene diez pasos. Ninguno es nuevo por separado; lo nuevo es ejecutarlos como una secuencia conectada.

1. Descubrimiento continuo de activos. No hay gestión de riesgo sobre lo que no se conoce. El descubrimiento va más allá de los servidores — aplicaciones, nube, APIs, endpoints, identidades, datos y terceros — y debe ser continuo, porque los atacantes buscan justamente lo que quedó fuera del inventario.

2. Criticidad de negocio. Cada activo relevante debe estar vinculado al proceso que sostiene y a la consecuencia de su falla. Es la etapa que más depende de conversar con las áreas de negocio, y la que más diferencia un programa de riesgo de un programa de vulnerabilidades.

3. Exposición y vulnerabilidad. Identificar fallas, configuraciones inseguras, credenciales expuestas y, sobre todo, caminos de ataque hasta los activos críticos.

4. Contexto de amenaza. Sumar threat intelligence: explotación confirmada, grupos que actúan en tu sector, tácticas y técnicas mapeadas en referencias como MITRE ATT&CK. Es lo que separa la falla explotada ahora de la que nadie explota.

5. Calificación del riesgo. Convertir la exposición técnica en un escenario de riesgo comprensible: quién actúa, contra qué, por qué camino y con qué consecuencia. "CVE en servidor web" es un hallazgo. "Un grupo de ransomware explota una falla en el portal de clientes y detiene la facturación" es un escenario.

6. Priorización. Ordenar los escenarios por la combinación de criticidad del activo, exposición, amenaza, vulnerabilidad e impacto. Ninguno de esos factores, por sí solo, define la prioridad.

7. Tratamiento. Decidir qué hacer con cada riesgo. Las opciones clásicas, presentes en referencias como NIST SP 800-39 e ISO 31000, son mitigar, transferir (por ejemplo, mediante seguro o contrato), evitar (dejar de hacer la actividad que genera el riesgo) o aceptar formalmente, con responsable y fecha de revisión.

8. Validación de controles. Un control documentado y nunca probado es una hipótesis, no una protección.

9. Riesgo residual. Recalcular el riesgo tras el tratamiento y la validación, y compararlo con lo aceptable.

10. Monitoreo continuo. Detectar cambios — activo, vulnerabilidad, amenaza, control degradado — y reiniciar el ciclo para lo que cambió.

Cyber Risk Index: un indicador, no un número mágico

Para operar este ciclo hay que seguir el riesgo a lo largo del tiempo. Un enfoque común es un Cyber Risk Index (CRI): un indicador que consolida distintas dimensiones de riesgo en una vista comparable. No es una fórmula universal; su implementación depende de la metodología, los datos y el apetito al riesgo de cada organización. Un CRI útil suele combinar dimensiones como riesgo de exposición, riesgo de amenaza, riesgo de vulnerabilidad, configuración de seguridad, riesgo en la nube, riesgo de identidad, riesgo de terceros, criticidad de los activos e impacto en el negocio — pero el peso de cada una es una decisión de gobierno, no un dato técnico.

Un CRI tampoco puede ser la suma de las notas CVSS ni el conteo de vulnerabilidades. La suma crece con el tamaño del entorno, no con el riesgo, y el conteo trata como equivalentes una falla explotada en un sistema crítico y una falla teórica en un entorno de pruebas. Tratamos las trampas de construcción de índices — promedios que ocultan el peor activo, precisión falsa, pesos que nadie sabe explicar — en el artículo sobre cyber risk scoring.

Bien construido, un indicador de riesgo permite seguir lo que realmente le interesa a la gestión: la tendencia del riesgo en el tiempo, la reducción obtenida en cada ciclo de tratamiento, el riesgo residual que queda, y la posición de ese riesgo frente al apetito (el nivel de riesgo que la organización está dispuesta a asumir para lograr sus objetivos) y a la tolerancia (la variación aceptable alrededor de ese apetito, a partir de la cual alguien debe decidir). Sobre cómo pasar de una declaración genérica a límites medibles, mira apetito al riesgo: de la frase al número.

El CROC no reemplaza al SOC

La relación es bidireccional. El SOC alimenta al CROC con lo que observa — incidentes, detecciones, telemetría, indicadores de compromiso, tácticas vistas en el entorno —, y eso calibra el riesgo: una amenaza que ya intentó entrar no es hipotética. El CROC le devuelve al SOC lo que rara vez tiene: activos prioritarios, riesgos por encima de la tolerancia, las "joyas de la corona", las amenazas que más importan para este negocio y dónde el monitoreo debe ser más fino.

Imagina que el SOC detecta actividad sospechosa en un servidor a las dos de la mañana. Por sí sola, la alerta tiene una severidad técnica. Con el contexto del CROC, el primer triaje gana otras preguntas. ¿El activo es crítico? ¿Está expuesto a internet? ¿La vulnerabilidad que tiene presenta explotación conocida? ¿Sostiene un proceso crítico — y cuánto cuesta cada hora de interrupción de ese proceso? ¿Hay un control compensatorio entre él y los datos sensibles? ¿El riesgo asociado ya estaba por encima de la tolerancia?

Según las respuestas, la misma alerta va a la cola de la mañana siguiente o justifica activar de inmediato el plan de respuesta y a la dirección. La detección fue la misma; lo que cambió fue el contexto.

CROC y GRC: del cumplimiento periódico al gobierno continuo

En muchas organizaciones, GRC y operación técnica viven en mundos paralelos. GRC mantiene políticas, controles, marcos, aceptaciones y evidencias al ritmo de las auditorías; la operación lidia con vulnerabilidades y alertas todos los días. Los dos solo se encuentran cuando la auditoría pide evidencia y alguien reconstruye, a las apuradas, el último año.

El CROC es el punto de encuentro natural. De GRC recibe las reglas del juego: políticas, controles, marcos, apetito, tolerancia y criterios de aceptación. De la operación recibe el estado real del entorno. Al conectar ambos, el tratamiento genera evidencia como subproducto, la aceptación de riesgo gana plazo y responsable, y el desvío respecto del apetito aparece cuando ocurre, no en el informe del trimestre siguiente. Es el paso del cumplimiento periódico al gobierno continuo del riesgo — tema de un próximo artículo de esta serie.

CROC y ciberresiliencia: qué pasa cuando los controles fallan

Reducir el riesgo no significa eliminarlo. Siempre habrá riesgo residual: la vulnerabilidad desconocida, el proveedor comprometido, el error humano, el ataque por encima de lo previsto. Por eso, una estrategia madura pregunta: ¿qué pasa cuando los controles fallan?

La respuesta está en la ciberresiliencia. La referencia más usada sobre el tema, NIST SP 800-160 Volumen 2, define la resiliencia como la capacidad de anticipar, resistir, recuperarse y adaptarse a condiciones adversas, ataques o compromisos. Para fines operativos, conviene explicitar entre resistir y recuperarse una etapa que el NIST CSF 2.0 trata como función propia: responder.

1. Anticipar
2. Resistir
3. Responder
4. Recuperar
5. Adaptar

Anticipar es identificar escenarios, amenazas, dependencias y posibles impactos antes de que se materialicen — exactamente lo que produce el ciclo del CROC. Resistir es construir la capacidad de absorber un ataque sin interrumpir funciones esenciales: segmentación que impide la propagación, redundancia, degradación controlada de servicios. Responder es detectar, contener y tomar decisiones durante el incidente, con información suficiente para decidir bien bajo presión. Recuperar es restaurar los servicios críticos dentro de los objetivos definidos por el negocio. Adaptar es convertir incidentes, ejercicios y fallas en cambios estructurales — y no solo en un informe de lecciones aprendidas archivado.

El CROC conecta estas etapas con el riesgo: los escenarios priorizados alimentan la anticipación, el riesgo residual indica dónde la resistencia debe ser mayor, el contexto de negocio orienta la respuesta, y cada incidente o ejercicio vuelve al ciclo como dato.

CROC, BIA y continuidad del negocio

Hay una información que ninguna herramienta técnica entrega por sí sola: el impacto en el negocio. Ahí es donde el Análisis de Impacto en el Negocio (BIA), base de la gestión de continuidad en referencias como ISO 22301 y NIST SP 800-34, se vuelve una de las fuentes más valiosas del CROC.

El BIA parte del proceso de negocio y llega a los servicios críticos que lo sostienen, a los activos y a sus dependencias — sistemas, proveedores, personas, datos. Cuando esa cadena se encuentra con el riesgo cibernético, la priorización gana la dimensión que faltaba. Dos parámetros son especialmente útiles. El RTO (Recovery Time Objective) es el tiempo máximo aceptable para restablecer un proceso o servicio tras una interrupción. El RPO (Recovery Point Objective) es la cantidad máxima de datos, medida en tiempo, que se puede perder.

Con ellos, la pregunta durante un ataque cambia. En lugar de "¿qué servidor restauramos primero?", el equipo pregunta "¿qué servicio debe volver primero para evitar un impacto inaceptable en el negocio?". La primera la responde quien conoce la infraestructura; la segunda exige saber que la facturación tiene un RTO de cuatro horas y que el sitio institucional puede esperar dos días. Fuera de la crisis, la misma información cambia la priorización: una exposición en un servicio con RTO corto pesa más que la misma exposición en un servicio que tolera días de interrupción.

El CROC como orquestador, no como otro departamento

Visto desde arriba, el CROC ocupa una posición de orquestación. Por encima está el negocio, que define el apetito al riesgo. A su alrededor están capacidades que la organización generalmente ya tiene:

El resultado de esa orquestación es una vista única del riesgo cibernético, y el objetivo final es la resiliencia del negocio.

Para que el CROC no se convierta en una sigla más, un punto merece énfasis: no necesita ser una sala nueva ni una gran estructura con headcount propio. En la mayoría de las empresas, empieza como un modelo operativo y de gobierno que conecta capacidades existentes — un ritmo semanal de priorización, criterios compartidos, responsables de riesgo definidos y una base común de datos. La estructura puede crecer después. El modelo va primero.

Red Team y Purple Team orientados por riesgo

Un ejercicio ofensivo tradicional parte de la pregunta "¿qué podemos explotar?" y produce una lista de hallazgos, muchas veces valiosa, pero no siempre conectada con lo que más preocupa a la organización.

Orientado por riesgo, el ejercicio parte de otra pregunta: ¿podemos comprometer los activos y procesos que representan el mayor riesgo para la organización? Los escenarios priorizados por el CROC se convierten en objetivos del Red Team; el Purple Team usa esos escenarios para verificar si las detecciones del SOC funcionan contra las técnicas más relevantes; y los hallazgos vuelven al ciclo.

1. Riesgo
2. Simulación de ataque
3. Validación de controles
4. Hallazgos
5. Remediación
6. Recálculo del riesgo

El último paso es el que cierra el ciclo: después de la remediación, el riesgo del escenario se recalcula. Una prueba que no cambia la evaluación de riesgo produjo información, pero no produjo gestión.

Métricas que tienen sentido para la dirección

Las métricas de un CROC deben responder preguntas ejecutivas. Algunas, como la tasa de reducción de riesgo o el tiempo medio para evaluar un riesgo, no están estandarizadas en el mercado: cada organización debe definirlas de forma explícita y estable. Ninguna tiene un "valor bueno" universal — importa la tendencia y la comparación con el apetito definido internamente.

Cómo empezar un CROC

Nadie necesita comprar decenas de herramientas ni crear una nueva estructura de una vez. La evolución ocurre por fases, y cada una entrega valor por sí misma.

La primera fase es de visibilidad: inventario confiable, criticidad de los activos más importantes, visión de la exposición y las primeras fuentes de threat intelligence.

La segunda fase es de contexto: relacionar activos, amenazas, vulnerabilidades e impacto. Es cuando la cola de vulnerabilidades empieza a convertirse en una cola de riesgos.

La tercera fase es la operación de riesgo propiamente dicha: calificación de escenarios, priorización, tratamiento con plazos y — lo más difícil — responsables de riesgo en las áreas de negocio, que deciden y responden por las decisiones.

La cuarta fase es de validación continua: pruebas de controles, integración con el SOC, Red y Purple Team orientados por los escenarios priorizados y monitoreo del riesgo residual.

La quinta fase es la resiliencia: integración con el BIA, la continuidad, la respuesta a incidentes y la recuperación ante desastres, con métricas que muestran si los servicios críticos se sostienen cuando ocurre un ataque.

Las fases se superponen. El punto de partida es lo que ya existe; el objetivo es conectarlo.

Conclusión

El SOC sigue siendo fundamental: sin detección y respuesta, ninguna empresa opera con seguridad. Pero detectar y responder es solo una parte de la ecuación. La próxima evolución de las operaciones de seguridad está en conectar amenaza, exposición, control, impacto en el negocio, riesgo y resiliencia en un mismo razonamiento — y en hacerlo de forma continua, con responsables y decisiones.

En el fondo, cada capacidad tiene su papel. El SOC responde al ataque. GRC establece el gobierno. El CROC conecta las señales técnicas con el riesgo. La ciberresiliencia garantiza que el negocio siga operando. Ninguna resuelve el problema sola; deben funcionar como un único sistema.

El futuro de las operaciones de seguridad no se medirá solo por cuántos ataques logramos detectar, sino por cuánto riesgo logramos reducir y por qué tan resiliente permanece el negocio cuando ocurre un ataque.

En Futture defendemos este enfoque integrado entre ciberseguridad, riesgo cibernético, gobierno, monitoreo continuo, continuidad y resiliencia. Es la base de la serie sobre Cyber Risk Operations que este artículo abre; los próximos profundizan en cada conexión presentada aquí:

• #1 — CROC y ciberresiliencia: la evolución de las operaciones de seguridad (este artículo)
• #2 — SOC + CROC: cómo integrar detección de amenazas y gestión de riesgo
• #3 — Cyber Risk Index: cómo convertir señales técnicas en decisión
• #4 — Gestión de vulnerabilidades basada en riesgo dentro del CROC
• #5 — Threat intelligence orientada al riesgo
• #6 — CROC + GRC: del cumplimiento periódico al gobierno continuo
• #7 — CROC + BIA: conectando el riesgo cibernético con el impacto en el negocio
• #8 — CROC + ciberresiliencia: cómo medir la capacidad de recuperación
• #9 — Red/Purple Team orientado por riesgo cibernético
• #10 — Cómo implementar un CROC: arquitectura, personas, procesos y tecnología

Preguntas frecuentes

¿Qué es un Cyber Risk Operations Center (CROC)?

Es un modelo operativo para identificar, contextualizar, evaluar, priorizar, tratar y monitorear de forma continua el riesgo cibernético. Convierte señales técnicas de distintos dominios de seguridad — vulnerabilidades, amenazas, exposición, controles — en contexto de riesgo y decisión para el negocio.

¿El CROC reemplaza al SOC?

No. El SOC detecta, investiga, responde y contiene ataques. El CROC usa lo que observa el SOC para calibrar el riesgo y le devuelve contexto de negocio: qué activos y amenazas importan más. Los dos funcionan mejor juntos.

¿Cuál es la diferencia entre severidad y riesgo?

La severidad, como la nota CVSS, describe qué tan grave es una falla en abstracto. El riesgo depende también de quién puede explotarla, de qué expone, de los controles existentes y del impacto en el negocio. Una falla menos severa en un sistema crítico y expuesto puede representar más riesgo que una falla crítica en un sistema aislado.

¿Hace falta crear un área nueva o comprar herramientas para tener un CROC?

No necesariamente. En la mayoría de las organizaciones, el CROC empieza como un modelo operativo y de gobierno que conecta capacidades existentes — SOC, gestión de vulnerabilidades, GRC, continuidad — con criterios compartidos, responsables de riesgo y un ritmo regular de decisión.

¿Cómo se relaciona el CROC con la ciberresiliencia?

El CROC reduce el riesgo, pero nunca lo elimina. La ciberresiliencia trata de lo que pasa cuando los controles fallan: la capacidad de anticipar, resistir, responder, recuperarse y adaptarse. El CROC alimenta esa capacidad con escenarios priorizados y contexto de negocio, y recibe de vuelta los resultados de incidentes y ejercicios.

Referencias conceptuales: NIST SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems (objetivos de resiliencia: anticipar, resistir, recuperarse, adaptarse); NIST Cybersecurity Framework 2.0 (función Respond); NIST SP 800-39, Managing Information Security Risk, e ISO 31000 (respuestas al riesgo); NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, e ISO 22301 (BIA, RTO y RPO); MITRE ATT&CK (tácticas y técnicas adversarias). Las métricas presentadas son sugerencias de indicadores y no constituyen un estándar de mercado. Este artículo es educativo y no describe un producto específico.

Referencias oficiales

• NIST SP 800-160 Vol. 2 Rev. 1 — Developing Cyber-Resilient Systems
• NIST Cybersecurity Framework 2.0 (NIST CSWP 29)
• NIST SP 800-39 — Managing Information Security Risk
• NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems
• ISO 22301:2019 — ISO
• MITRE ATT&CK