A menudo, la reacción inmediata ante incidentes de seguridad como los ataques de ransomware que afectaron a los casinos de Las Vegas a principios de otoño es buscar la causa. Entiendo el impulso. El impacto de los ataques -huéspedes que tuvieron que facturar utilizando bolígrafo y papel, hasta $100 millones en pérdidas para una sola víctima, demuestran el elevado coste de los fallos de seguridad. Nadie quiere ser la próxima víctima de una violación de datos.
Pero en ciberseguridad no suele haber una sola causa. En la mayoría de los incidentes de seguridad, los atacantes se aprovechan de una cadena de vulnerabilidades que gradualmente les dan más acceso y control de un entorno. No es productivo buscar causas y efectos cuando normalmente no los hay. En su lugar, los equipos de seguridad deben examinar su entorno global, su arquitectura y las formas en que funciona su tecnología, así como su procesos y cultura empresariales y acercarlas a la arquitectura de confianza cero.
Al igual que los casinos que sufrieron estos ataques, tanto los ciberataques como la ciberseguridad tienden a jugar con las probabilidades. No suele ser un talón de Aquiles el que pone en peligro la ciberseguridad de una organización. Se trata más bien de azar estadístico y de riesgos que se combinan entre sí. Los equipos de seguridad no deben buscar una bala de plata, sino comprender las condiciones que pueden transformar un copo de nieve en una avalancha.
Aunque probablemente nunca conoceremos la historia completa de cómo ALPHV / BlackCat lanzaron sus ataques, sabemos algunas de las condiciones que les ayudaron a vulnerar a sus víctimas y cómo esas condiciones crearon riesgos que favorecieron a los atacantes.
En su declaración, Según ALPHV, el casino "cerró todos y cada uno de sus servidores Okta Sync tras enterarse de que habíamos estado merodeando por sus servidores Okta Agent husmeando contraseñas de personas cuyas contraseñas no se podían descifrar".
ALPHV pudo hacerlo gracias a Sincronización de contraseñas de aplicaciones de Okta, que "utiliza API estándar para sincronizar contraseñas y aplicaciones locales cuando están disponibles". La documentación del producto continúa: "Cuando se habilita Okta to Application - Sync Okta Password, el comportamiento predeterminado es sincronizar la contraseña existente. La contraseña de Okta es la contraseña utilizada para iniciar sesión en Okta".
En otras palabras, Okta tiene las contraseñas de Active Directory de sus usuarios. Esto se debe en gran parte a la arquitectura cloud-first del proveedor: sincronizar las contraseñas les ayuda con su tiempo de ejecución y les facilita el despliegue y la implantación del sistema MFA.
Aunque esta opción ayuda a las organizaciones a desplegar la solución más rápidamente, conlleva importantes contrapartidas de seguridad que van en contra de un principio básico de ciberseguridad: Evitar los datos o, en otras palabras: no almacenar o transmitir datos que no necesitan ser almacenados o transmitidos.
Es una regla de larga data porque si una organización transmite algo, entonces es más fácil para un atacante robarlo. Eso es lo que ocurrió con BlackCat y ALPHV: probablemente comprometieron el servidor en el que se ejecutaba el Okta Agent AD. A partir de ahí, pudieron establecer una escucha vampírica para copiar contraseñas, inyectar una DLL, volcar segmentos de memoria o realizar cualquier otra acción. Y ese es el punto: no importa realmente qué acciones específicas tomaron los atacantes cuando estaban en el servidor comprometido.
Por el contrario, el riesgo comenzó al desplegar una arquitectura que sincroniza las contraseñas. Esa elección estableció las condiciones que permitieron que todo lo demás siguiera. Esa decisión es el equivalente en ciberseguridad de optar por construir un edificio sobre arena en lugar de sobre roca firme: lo que construyes puede resistir, pero ¿por qué correr el riesgo?
Los ataques BlackCat / ALPHV ponen de manifiesto lo difícil que es proteger los servidores. Las actualizaciones múltiples, las contraseñas de administrador y la repetición de contraseñas se suman a una superficie de ataque grande, compleja y frágil. Este tipo de configuración suele favorecer a los atacantes.
La alternativa es basarse tanto en Secure by Design como en Secure by Default. principios, que dan prioridad a la seguridad en todas las funciones, operaciones y procesos de los productos y acercan a las organizaciones a la confianza cero.
Como muchas otras cosas, la seguridad por diseño y por defecto depende de los detalles. Es fácil afirmar que un producto da prioridad a la seguridad, pero es difícil ofrecer algo que realmente cumpla ese criterio.
RSA desarrolla soluciones que dan prioridad a la seguridad y que parten de estos principios. No sincronizamos contraseñas de Active Directory o LDAP: no disponemos de esas credenciales. En su lugar, pedimos a los clientes que desplieguen un dispositivo virtual reforzado que se conecte a sus repositorios de usuarios locales y valide las contraseñas en tiempo real, en lugar de rastrearlas y sincronizarlas con la nube.
Esta elección conlleva algunas contrapartidas: lleva un poco más de tiempo y esfuerzo desplegar un dispositivo virtual reforzado y nuestro enrutador de identidad virtual. Pero es un coste que nuestros clientes y nuestro equipo creen que merece la pena, porque al no sincronizar las contraseñas, minimizamos la superficie de ataque en lugar de ampliarla. Si no la sincronizamos, no podemos perderla y un atacante no puede aprovecharse de ella. También diríamos que las soluciones de otros proveedores consumen más tiempo y esfuerzo a largo plazo, ya que las soluciones "más rápidas" dan lugar a una superficie de ataque mucho mayor con una sobrecarga aún mayor.
RSA® Cerradura móvil, que establece la confianza en dispositivos no gestionados y ayuda a proteger el BYOD, también ejemplifica los principios Secure by Design y Secure by Default. Mobile Lock solo busca amenazas cuando los usuarios intentan autenticarse mediante RSA Authenticator para iOS y Android, y solo restringe la autenticación cuando detecta una amenaza. Además, sólo consulta el mínimo absoluto de datos para realizar sus funciones, y nuestro socio Zimperium nunca ve información personal sobre los usuarios finales. Las ganancias de seguridad de hacer algo más -como escanear continuamente el dispositivo de un usuario- serían mínimas, especialmente comparadas con la posibilidad de que un atacante pudiera apuntar a un servicio en segundo plano siempre activo.
Lo mismo ocurre con nuestro agente de autenticación multifactor (MFA). En caso de interrupción del servicio de Internet, nuestro agente MFA pasa a prueba de fallos a un despliegue local, en lugar de fallar en abierto o entrar en un modo fuera de línea en el que la validación OTP se realiza en el propio agente MFA. Esto significa que las amenazas no pueden eludir la AMF simplemente desconectándose de Internet o haciendo que el servicio backend de la AMF parezca estar fuera de línea, que es esencialmente lo que los actores patrocinados por el Estado hicieron a un ONG el año pasado.
La verdadera seguridad nunca es un exceso de ingeniería: se basa en una mezcla sensata de soluciones sencillas siempre que sea posible y más complejas cuando sea necesario. Cada componente de un servicio debe diseñarse para limitar la superficie de ataque siempre que sea posible. Eso significa recopilar sólo el mínimo de información que un sistema necesita absolutamente y utilizar esa información sólo cuando sea necesario. También significa tomar decisiones arquitectónicas que minimicen la superficie de ataque en lugar de ampliarla innecesariamente.
La ciberseguridad suele consistir en jugar con las probabilidades. Mejore las suyas jugando inteligentemente y apostando por proveedores que den prioridad a la seguridad.
