Es posible que sepa poco sobre el SOC, pero aún será intuitivamente claro que solo hay dos cosas que son más importantes en su trabajo: identificar incidentes y responder a ellos. Al mismo tiempo, si no toma la situación cuando se trata de fraudes internos complejos o signos de la actividad de un grupo profesional, la respuesta, por regla general, consiste en una serie de medidas técnicas muy simples (eliminación del cuerpo o software viral, bloqueo de acceso o cuenta) y medidas organizativas (la aclaración de la información de los usuarios o la verificación y el enriquecimiento del análisis dan como resultado fuentes inaccesibles para el monitoreo). Sin embargo, por varias razones, el proceso de respuesta del cliente ha comenzado a cambiar significativamente en los últimos años, y esto requirió cambios por parte del SOC. Además, dado que estamos hablando de una respuesta, donde "no solo todo" es importante, y la precisión,tanto la integridad como la velocidad de acción: es muy probable que si su SOC interno o externo no tiene en cuenta los nuevos requisitos para este proceso, no podrá manejar el incidente normalmente.
Ahora hay muchos de nuestros clientes que se sienten más cómodos con recibir una respuesta como un servicio de "ciclo completo"; en este caso, bloqueamos el ataque a las defensas de la compañía y acompañamos el proceso de respuesta en el área de responsabilidad del servicio de TI. Por ejemplo, ayudamos con la justificación del bloqueo, lo que teóricamente puede conducir a problemas en los procesos de negocios, o asesoramos sobre el trabajo que parcialmente debe hacerse de su lado: bloqueo de cuentas, aislamiento de host, etc.
Pero la mayoría aún prefiere involucrarse en una respuesta técnica por su cuenta, y nos exigen la detección oportuna de un incidente, el análisis y el filtrado de falsos positivos, así como el suministro de información analítica con recomendaciones sobre acciones prioritarias en respuesta a un incidente.
¿Quién estuvo involucrado anteriormente en este proceso y fue responsable del resultado por parte del cliente? Como regla general, uno o dos especialistas en seguridad de la información que combinan la respuesta trabajan con otras tareas del departamento y no siempre tenían una gran experiencia en el nicho en el análisis de ataques (como puede ver en el párrafo anterior, esto no era necesario). Sin embargo, siempre se ha tratado de especialistas en seguridad de la información que comprenden los riesgos, las amenazas y el contexto de lo que está sucediendo.
Recientemente, la responsabilidad por la integridad y la puntualidad de la respuesta del lado del cliente se distribuye cada vez más entre la seguridad de la información y los servicios de TI, y he aquí por qué.
Primero, el número de incidentes y sospechas de incidentes ha aumentado significativamente. Si antes el número promedio de notificaciones se medía en uno o doscientos por mes, ahora ha aumentado varias veces. Parte del problema es el crecimiento de la entropía en las infraestructuras corporativas debido a los cambios constantes (y no siempre fijos) causados por lo que ahora se conoce comúnmente como el término de moda "digitalización" o "transformación digital". Un efecto secundario es que las acciones del usuario se vuelven más variadas, y las soluciones técnicas tienen más probabilidades de clasificarlas como anomalías de comportamiento, que, a su vez, pueden ser confundidas con un atacante por un oficial de seguridad. Estos son falsos positivos, digamos, del primer tipo.
En segundo lugar, la actividad de los cibercriminales, por supuesto, también está en constante crecimiento (en otras palabras, hay más ataques), esto lo notamos nosotros, otros actores de la industria y los propios clientes. Como resultado, el SOC debe inventar constantemente escenarios de detección de ataques cada vez más inteligentes y asegurarse de conectarlos con el cliente. Esto, por supuesto, también conduce a un aumento en el número de operaciones, un aumento en el no determinismo de las acciones del cliente y la necesidad de información sobre el incidente para contener un contexto externo (de quién es la estación de trabajo, es habitual en la compañía usar herramientas de acceso remoto, y si es así, cuáles, quién se pueden usar para qué y similares).
En realidad, esto lleva al hecho de que para acelerar el proceso de respuesta, cada vez más empresas están tratando de transferir el SOC externo a la interacción directa no con la seguridad de la información, sino con los departamentos de TI. Y esto es bastante lógico: los incidentes que requieren la eliminación del software o el bloqueo de la cuenta se envían directamente a TI, lo que requiere el aislamiento de la red del host, a los departamentos de red + servicio de asistencia, etc. Si la empresa tiene su propio centro de monitoreo, a menudo está obligada a transferir disparadores del sistema SIEM a TI.
Sin embargo, cualquier cambio en el proceso es el riesgo de ralentizarlo, el riesgo de información incompleta para las partes y, en última instancia, una disminución de la eficiencia. Afortunadamente, la mayoría de las empresas entienden esto, por lo tanto (y a veces debido a requisitos legislativos, en particular sobre la creación de centros GosSOPKA), ahora existe una demanda creciente para verificar el nivel real de respuesta: integridad, calidad y oportunidad de las recomendaciones de los departamentos de TI y seguridad de la información. compañías.
Sin embargo, antes de realizar auditorías, es necesario dar a las personas una herramienta para lograr el resultado; en otras palabras, el SOC debe adaptar los resultados del análisis de cada incidente para un enrutamiento claro en TI. Mediante prueba y error, hemos compilado una lista de requisitos para la información del incidente enviada al cliente.
En estos resultados del análisis del incidente, el empleado responsable de la respuesta técnica debe estar claramente identificado. ¿
Cuáles son las dificultades? Para identificar correctamente a esa persona a cargo, es necesario identificar con precisión la ubicación del incidente: un departamento específico, la crítica del anfitrión, su afiliación comercial, el tipo de incidente Esto requiere una inmersión muy profunda en la infraestructura del cliente en la etapa de inventario (y, lo que es más importante, una actualización constante de estos datos).
Se necesita la misma información para determinar la importancia de un incidente. Por ejemplo, el banco está listo para reaccionar a una infección de virus de un automóvil en una sucursal de Magadan mucho más lentamente y con la ayuda de un especialista local en seguridad de la información. Si hablamos del AWP local del KBR, el incidente requiere una respuesta y participación inmediata, incluido el CISO del cliente para coordinar el riesgo, así como los especialistas del centro de comunicación en el sitio para aislar inmediatamente al host.
Por lo general, responder a un ataque a una aplicación web en el segmento de comercio electrónico requiere la participación no solo del personal de seguridad, sino también de especialistas en aplicaciones que pueden determinar con mayor precisión los riesgos asociados con su implementación y descargar información sobre los pedidos de la base de datos en el mismo host, por el contrario, en ningún caso debe involucrar a los solicitantes (son uno de los posibles atacantes), o incluso a los especialistas en TI, pero además de la seguridad de la información, a menudo requiere la participación del servicio de seguridad económica.
Todos estos escenarios, a quienes involucramos cuándo, en qué etapa y con qué propósito, deben resolverse con anticipación y acordarse con el cliente. SOC conoce mejor la seguridad de la información, pero el cliente conoce mejor su negocio y los riesgos más importantes para él, por lo que los scripts se desarrollan juntos.
Esto también se aplica a la descripción de la amenaza y sus riesgos, y al nivel de detalle en la descripción de las recomendaciones de respuesta. Además, idealmente, la secuencia de acciones requeridas debe dividirse en un árbol de eventos obligatorios y auxiliares. Por ejemplo, si el SOC registra el lanzamiento de la Herramienta de administración remota en el host final, pero el nivel de auditoría no es suficiente para distinguir la actividad del usuario de un posible lanzamiento de una puerta trasera por parte de un atacante, entonces el primer punto obligatorio será la comunicación del especialista con el usuario para averiguar si inició esta actividad. Si la respuesta es sí, esta es una actividad regular o, como máximo, una violación de la política de seguridad de la información. Si es negativo, puede ser parte de un ataque de piratas informáticos y requiere un trabajo de respuesta completamente diferente.
La verificación de los resultados de la respuesta debe contener la posibilidad de un control técnico tanto del hecho de la implementación de las recomendaciones (usando registros en SIEM u otras herramientas) como del hecho de que el incidente no se repetirá en el futuro.
Continuemos el ejemplo con la ejecución de RAT en el host. Por ejemplo, fuimos a la primera sucursal: actividad del usuario que violó las políticas de seguridad de la información. En este caso, se le recomendará al servicio de TI que elimine la RAT en el host. Además del inicio controlado de la secuencia de comandos de eliminación o la verificación de la ausencia / presencia de una utilidad en el host, las herramientas de inventario deben vincularse con el incidente anterior cuando se vuelve a activar. Esto indica no solo una violación reiterada, sino también una posible implementación de baja calidad de la recomendación por parte de la respuesta.
Finalmente, el contexto o vecindario del delta del incidente es importante. Es muy importante lo que le sucedió exactamente a esta máquina / cuenta durante el último intervalo de tiempo, si hubo incidentes similares o potencialmente relacionados que podrían recopilarse en la cadena de eliminación. Esta información le permite determinar rápidamente si necesita involucrar de inmediato al equipo de seguridad o al equipo de respuesta a incidentes del proveedor en el incidente.
Cada SOC está buscando sus propias respuestas a estos desafíos y puede realizar estas tareas utilizando diferentes herramientas, lo principal es controlar que lo haga en principio. Debido a que en incidentes menores, los retrasos y las dudas en la respuesta pueden ser imperceptibles, y en incidentes críticos, un proceso no regulado simplemente no funcionará. Y es como si no hubiera culpables.