¡Cuidado con la brecha! ¿Quién es responsable de la protección contra amenazas a la identidad en su organización?

Las amenazas a la identidad (es decir, el uso de credenciales comprometidas para acceder maliciosamente a recursos específicos) se han convertido en el elemento dominante del panorama de amenazas actual. Además, estas son las amenazas contra las que a las organizaciones les resulta más difícil protegerse, con movimiento lateral y la propagación del ransomware causa daños generalizados aparentemente a diario. Sin embargo, dentro de la mayoría de las organizaciones existe una brecha en términos de quién es realmente responsable de prevenir estos ataques. Y esta brecha es una de las razones fundamentales por las que las organizaciones luchan por tomar ventaja contra las amenazas a la identidad.

En esta publicación, discutiremos esta brecha examinando un caso de uso de muestra, con el propósito de incitar a todos los profesionales de la ciberseguridad a reflexionar sobre qué tan presente está esta brecha en su organización y cómo se puede resolver.

Los equipos de identidad no son responsables de prevenir los ciberataques

Conoce a Jack. Jack es un administrador de identidad y acceso (AMI) ingeniero en su empresa. Parte del rol de Jack es implementar la autenticación multifactor (MFA) protección del acceso de sus usuarios. Al ser un profesional consumado, Jack evalúa, compra e implementa un solución MFA en todas las aplicaciones web y SaaS de su empresa, así como para el acceso VPN remoto al entorno local y el acceso al Protocolo de escritorio remoto (RDP) dentro del mismo.

Pero porque AMF para el PDR Implica instalar un agente en cada servidor del entorno, se toma la decisión de no implementarlo en un grupo específico de servidores más antiguos que admitan varias aplicaciones críticas para el negocio. La preocupación aquí es que la carga adicional de los agentes MFA colapsará estos servidores, lo que provocará un tiempo de inactividad inaceptable. Por lo que el proyecto se considera exitoso dadas estas consideraciones.

Los equipos de seguridad no son responsables de evaluar e implementar productos de protección de identidad

Conozca ahora a Jill, quien es gerente del Centro de operaciones de seguridad (SOC) en el equipo de seguridad de su empresa. Su KPI es prevenir, detectar y responder a ciberataques. Jill es consciente de que ransomware Los ataques que se extienden por todo el entorno empresarial son una amenaza crítica. Los adversarios logran esta propagación utilizando credenciales de usuario comprometidas para iniciar sesión en tantas máquinas como sea posible. Para evitar esto, el equipo de Jill invierte un esfuerzo significativo en responder a las alertas y buscar de manera proactiva accesos de usuarios anómalos que puedan indicar que se está produciendo dicha propagación.

Sin embargo, ni Jill ni nadie de su equipo han participado en la evaluación, prueba e implementación de la solución MFA que ahora está implementada en todo el entorno de su empresa. Dado que su atención se centra exclusivamente en los ciberataques, su única reacción es alegrarse de saber que el proyecto MFA se completó con éxito.

El resultado: los ciberataques que incluyen amenazas a la identidad encuentran poca defensa

Un día llega el ransomware. Los adversarios se dan cuenta de que los servidores de aplicaciones de la organización son el mejor objetivo para mantener como rehenes. Para obtener el control de estos servidores y cifrar los datos que contienen, intentan iniciar sesión a través de RDP utilizando las credenciales de un usuario comprometido. Y como no hay MFA en estos servidores, el intento tiene éxito. Ahora los adversarios tienen el control total y pueden imponer sus demandas de ransomware a la organización.

Dejemos nuestra historia y reflexionemos sobre lo que pasó aquí.

Lecciones aprendidas: cuando nadie es dueño del riesgo, el riesgo es tuyo

Entonces, ¿qué hizo posible esta infracción, a pesar de que existían equipos de identidad y seguridad dedicados y talentosos? La respuesta está en cómo Jack y Jill perciben el papel que se les ha asignado en su organización.

Por su parte, a Jack no se le encomendó la tarea de prevenir la propagación del ransomware, sino implementar una solución MFA.. Desde su perspectiva, los servidores sin protección MFA no fueron vistos como un riesgo de seguridad sino como un porcentaje faltante en la tasa general de cobertura MFA del proyecto. Y una tasa de cobertura del 90% es significativamente mejor que la tasa anterior del 0%. Se hicieron los mejores esfuerzos y, aunque los resultados no fueron perfectos, definitivamente fueron lo suficientemente buenos.

Jill, por otro lado, no participó en absoluto en el proyecto MFA. A diferencia de un SIEM o un EDR, MFA no se considera un producto de seguridad sino más bien un foco del equipo de identidad. Si Jill hubiera estado involucrada en las discusiones sobre MFA, podría haber descubierto que los servidores de aplicaciones estaban expuestos y haber sido presionada para actualizarlos de modo que el proyecto MFA no se considerara completo antes de que estos servidores estuvieran completamente protegidos.

Entonces, ¿Jack tiene la culpa de la infracción? En realidad no, porque esto nunca fue parte de su responsabilidad. ¿Significa eso que Jill es la culpable de la cobertura parcial del MFA? En realidad no, porque el MFA nunca ha sido parte de su jurisdicción.

Y ésta es exactamente la brecha de rendición de cuentas de la que estamos hablando.

¿Podría existir una brecha de rendición de cuentas en su entorno?

Esta historia es un buen ejemplo del estado de Protección de la identidad hoy. Vale la pena analizar por separado cómo se desarrolló esta brecha de responsabilidad y por qué se encuentra solo dentro de la protección de identidad (a diferencia de la protección de terminales o de red). Lo que es más importante es que preguntes si un escenario similar podría ocurrir en tu entorno.

Aquí hay algunas preguntas clave que debe hacerse:

• ¿Están sus equipos de SecOps involucrados en la implementación de controles de protección de identidad como MFA y PAM?
• ¿Su CISO tiene voz en el diseño y la implementación de la infraestructura IAM?
• ¿Su equipo de identidad se da cuenta de que las soluciones que evalúan e implementan son en realidad la última línea de defensa contra ataques que podrían poner en riesgo a toda la organización?

Y la pregunta más importante: ¿Existe una única parte interesada en su organización que tenga tanto la responsabilidad de prevenir amenazas a la identidad como la autoridad y el conocimiento para determinar las medidas de seguridad que se deben implementar para lograrlo? Esto no quiere decir que la protección de la identidad será completa después de resolver la brecha de rendición de cuentas. Ciertamente, hay otros desafíos que superar antes de llegar allí. Pero es un primer paso esencial para hacer posible esta protección. En última instancia, no importa si la persona responsable proviene del lado de la identidad o de los equipos de seguridad. Siempre que haya un propietario claro en su organización, se logrará el hito inicial de tomar ventaja sobre las amenazas a la identidad.