La preparación del SOC de IA comienza antes que la IA.

La preparación del SOC de IA comienza antes que la IA.

Actualmente, a todos los responsables de seguridad se les plantea una pregunta similar: ¿cuál es su estrategia de IA para el SOC? La presión por responder es real. El volumen de alertas sigue aumentando, la plantilla de analistas no crece al mismo ritmo y los proveedores están encantados de cubrir esta necesidad incorporando la IA a todo tipo de productos.

En breve: La preparación de un SOC con IA depende menos de la IA en sí y más de la madurez del entorno de automatización y operaciones de seguridad en el que se implementa. Evalúe primero ese entorno, subsane las deficiencias detectadas y solo entonces decida dónde encaja la IA.

Esa fue la tesis que subyace en el reciente trabajo de Swimlane. Cumbre virtual del SOC de IA, Un evento de dos sesiones centrado en una sola idea: no empieces a hablar de IA hablando de la tecnología. Empieza analizando con honestidad cómo funciona tu negocio hoy en día. Esta es la progresión que se presentó en la cumbre y por qué sigue siendo válida una vez que la pones en práctica.

1. Reconocer las señales

Fatiga por exceso de alertas. Analistas sobrecargados de trabajo. La automatización, que antes parecía integral, ahora presenta limitaciones. La proliferación de herramientas dificulta la coordinación en lugar de facilitarla.

Resulta tentador interpretar esto como evidencia de que su programa SOAR fracasó. Sin embargo, generalmente no es así. El volumen de alertas, la complejidad del entorno y las exigencias operativas aumentan, mientras que la automatización creada para una versión anterior y más sencilla del problema permanece prácticamente igual.

La distinción que importa: Disponer de una amplia biblioteca de manuales de automatización no es lo mismo que tener una estrategia de automatización escalable. Un equipo puede implementar una automatización considerable y aun así toparse con un obstáculo, porque este no radica en la cantidad de automatización existente, sino en si dicha automatización se diseñó para la escala, la complejidad y la velocidad a la que opera la organización actualmente.

La fricción que sientes no es un veredicto sobre decisiones pasadas. Es información sobre dónde debes mirar a continuación.

2. Modernizar sin empezar de cero.

Cuando algo deja de ser escalable, el instinto es eliminarlo y empezar de cero, especialmente cuando los proveedores ofrecen una ruptura total con el "SOAR tradicional". Resista ese instinto.

Los manuales de procedimientos deterministas representan procesos definidos: el trabajo que la organización ya realizó para determinar cómo debe ejecutarse un proceso de seguridad específico. Ese es conocimiento institucional, y no deja de ser valioso solo porque haya aparecido una tecnología más reciente.

Haz esta pregunta en su lugar: No se trata de "¿cómo empezamos de cero?", sino de "¿qué tenemos ya que funciona, dónde estamos llegando a nuestros límites y qué necesita evolucionar?".“

Esto convierte la modernización en una hoja de ruta construida sobre lo que ya existe, en lugar de una reconstrucción desde cero. La progresión se ve así:

1. Manuales de jugadas deterministas. Los procesos establecidos que ya utilizas.
2. Un marco modernizado. Los mismos procesos, ejecutándose en un entorno diseñado para una mayor escalabilidad y flexibilidad.
3. Medidas de protección para los agentes de IA. Un punto de partida intencional para determinar dónde participa la IA y cuánta autonomía se le otorga.

Las empresas consolidadas no tienen que elegir entre la automatización determinista y la IA. Utilizan cada una donde realmente encaja.

3. Establecer la línea de base

Antes de poder afirmar si la IA ha mejorado algo, es necesario tener una idea clara de cómo era la situación "antes". Esto implica responder algunas preguntas poco atractivas:

• ¿Cuáles son sus fuentes de alerta?
• ¿Cómo se accede realmente a los datos: mediante API, webhook o correo electrónico?
• ¿Qué resultados se obtienen actualmente con los diferentes tipos de alertas?
• ¿Cuáles son sus valores MTTD y MTTR hoy?
• ¿Qué porcentaje de alertas se cierran automáticamente o con la ayuda existente?

Si se omite este paso, no hay forma de demostrar que una inversión en IA haya tenido un impacto significativo, porque no hay nada con qué compararlo.

4. Evaluar la preparación en función de casos de uso específicos, no de todo el SOC.

“La IA en el SOC no es una única capacidad, por lo que la pregunta "¿estamos preparados para la IA?" no está bien formulada. Las funciones de IA se dividen en distintas categorías: investigaciones asistidas por IA o con agentes, creación de manuales de procedimientos e integraciones asistidas por IA, y funciones de asistencia como la referencia de casos y la llamada a herramientas. La preparación se evalúa específicamente para cada una de ellas, no se decide una sola vez para toda la operación.

Esa distinción es importante porque es fácil quedarse estancado en las preguntas equivocadas:

• ¿Tenemos inteligencia artificial?
• ¿Estamos evaluando la IA?
• ¿Hemos elegido un caso de uso?

Esas preguntas son fáciles de responder y no revelan casi nada. Las preguntas que realmente revelan algo son más difíciles:

• ¿Qué grado de madurez tienen los procesos que intentas mejorar?
• ¿Qué grado de madurez tiene la automatización que les da soporte?
• ¿En qué aspectos la operación ya funciona bien y dónde existen las verdaderas deficiencias?

La preparación no es tan subjetiva como parece. Se manifiesta en características específicas y verificables: objetivos claros y métricas de éxito, procesos documentados y repetibles, datos accesibles y de alta calidad, una sólida base de automatización, alineación de la gobernanza en materia de seguridad, riesgo y cumplimiento, y una supervisión definida por parte de los analistas. Una organización preparada suele contar con la aprobación de las partes interesadas, alertas de alta calidad y manuales de procedimientos bien documentados. Una que no lo está suele tener objetivos poco claros, documentación escasa y ningún presupuesto destinado a las herramientas o la formación que requiere una iniciativa de IA. Ambas son cosas útiles que conviene saber. Ninguna de las dos resulta sorprendente una vez que se ha analizado detenidamente.

5. Cierre las brechas antes de introducir la IA y trate lo que encuentre como útil.

Aquí viene la parte que contradice la forma en que se suelen presentar la mayoría de las implementaciones de IA: encontrar una deficiencia antes de introducir la IA no es algo negativo. Falta de documentación, calidad inconsistente de las alertas, enriquecimiento deficiente, gobernanza poco clara. Estos son hallazgos, no fallos, y precisamente para eso sirve una evaluación de preparación.

Trata la preparación como un ciclo, no como una puerta de entrada única:

1. Análisis. Analiza el entorno y detecta dónde se encuentran las deficiencias del proceso.
2. Planificación. Documentar cómo debería ser realmente el proceso de triaje y respuesta.
3. Implementación. Reforzar el contexto mediante documentación, enriquecimiento y herramientas adicionales.
4. Pruebas y validación. Confirma si esos cambios realmente produjeron el resultado que deseabas.

Entonces el ciclo vuelve a empezar. Esa estructura es importante porque la preparación no es una certificación que se obtiene una sola vez. Es una práctica constante, y significa que puedes introducir la IA en un proceso bien preparado a la vez, en lugar de sentir que tienes que arreglar todo el SOC antes de empezar.

6. Mantener a los seres humanos involucrados de manera apropiada.

Gran parte de la inteligencia artificial aplicada a la mensajería de seguridad parte de una premisa: que la mejora de la eficiencia y la autonomía del analista son el mismo objetivo, y que una mayor presencia de IA implica, por naturaleza, una menor intervención humana. Esta premisa no se sostiene. Mejorar la eficiencia no requiere eliminar la supervisión del analista.

La supervisión debe estar integrada en la estrategia desde el principio, no añadirse después de que algo salga mal:

• Los planes de investigación generados a partir de la documentación interna son validados por analistas y coordinadores antes de que alguien actúe en consecuencia.
• Se programan controles de garantía de calidad para las alertas que se cerraron o clasificaron sin la intervención humana.
• Las operaciones de mayor riesgo, como la ejecución de las medidas correctivas, requieren la participación humana en la toma de decisiones.

El objetivo no es la máxima autonomía, sino el nivel adecuado para el proceso específico y su perfil de riesgo. Se trata de una decisión que debe tomarse de forma deliberada, no por defecto.

7. Aplicar la IA de forma deliberada

Reúna todo el proceso: modernice la base operativa, evalúe su madurez en función de casos de uso específicos de IA, subsane las deficiencias que revele dicha evaluación y, a continuación, aplique la IA con una supervisión integrada desde el primer día, en lugar de añadirla posteriormente.

Es un camino más lento que el de "comprar la plataforma de IA y ponerla en marcha". También es más duradero, porque la IA que se introduce se implementa en un entorno que realmente puede soportarla.

Las organizaciones mejor posicionadas para beneficiarse de la IA en el SOC quizás no sean las que avanzan más rápidamente hacia la IA. Quizás sean las que primero se esfuerzan por modernizar, evaluar y comprender a fondo sus operaciones de seguridad.

El objetivo no es acelerar la adopción de la IA, sino construir una base de operaciones de seguridad que permita a su organización introducir la IA con confianza.

¿Quieres escuchar la conversación completa? Vea ambas sesiones de la Cumbre virtual de IA SOC bajo demanda para el debate completo sobre la modernización y la preparación.