La moderna cadena de destrucción elude a las empresas porque no protegen la infraestructura de los negocios modernos: SaaS.
SaaS continúa dominando la adopción de softwarey representa la mayor parte del gasto en la nube pública. Pero tanto las empresas como las PYMES no han revisado sus programas de seguridad ni han adoptado herramientas de seguridad creadas para SaaS.
Los equipos de seguridad siguen insertando clavijas locales en los agujeros de seguridad de SaaS
Los controles de seguridad maduros de los que dependían los CISO y sus equipos en la era del dominio local han desaparecido. Los firewalls ahora protegen un perímetro pequeño, la visibilidad es limitada e incluso si los proveedores de SaaS ofrecen registros, los equipos de seguridad necesitan un middleware local para digerirlos e insertarlos en su SIEM.
Los proveedores de SaaS tienen ámbitos de seguridad bien definidos para sus productos, pero sus clientes deben gestionar el cumplimiento de SaaS y la gobernanza de datos, la gestión de identidades y accesos (IAM) y los controles de aplicaciones, las áreas en las que se producen la mayoría de los incidentes. Si bien este modelo de responsabilidad compartida de SaaS es universal entre las aplicaciones de SaaS, no hay dos aplicaciones de SaaS que tengan configuraciones de seguridad idénticas.
 |
| Figura 1. En el contexto de las preocupaciones de seguridad de SaaS, el proveedor de la aplicación es responsable de toda la infraestructura física, así como de la red, el sistema operativo y la aplicación. El cliente es responsable de la seguridad de los datos y la gestión de la identidad. El modelo de responsabilidad compartida de SaaS requiere que los clientes de SaaS asuman la propiedad de los componentes que los actores de amenazas atacan con mayor frecuencia. Ilustración cortesía de AppOmni. |
La investigación de AppOmni informa que, en promedio, una sola instancia de SaaS tiene 256 conexiones SaaS a SaaSmuchos de los cuales ya no están en uso, pero aún tienen permisos excesivos en aplicaciones comerciales centrales como Salesforce, Okta y GitHub, entre otras.
Entre la multitud de diferentes configuraciones de seguridad de SaaS y las actualizaciones constantes que las modifican, los equipos de seguridad no pueden monitorear estas conexiones de manera efectiva. La cantidad de puntos de entrada se multiplica exponencialmente cuando los empleados habilitan conexiones de SaaS a SaaS (también llamadas «de terceros» o «de máquina»). Las identidades de las máquinas pueden usar claves API, secretos, sesiones, certificados digitales, claves de acceso a la nube y otras credenciales para permitir que las máquinas se comuniquen entre sí.
A medida que la superficie de ataque migraba fuera del perímetro de la red, también lo hacía la cadena de destrucción. – la forma en que los actores de amenazas orquestan las distintas fases de sus ataques.
Mirar Informe y análisis de amenazas SaaS de AppOmni
El SaaS es el nuevo campo de batalla de la ciberseguridad. Vea cómo los expertos en seguridad de AppOmni analizan ejemplos reales de la moderna cadena de ataque del SaaS y las tácticas, procedimientos y procedimientos más comunes, y le muestran cómo reducir la probabilidad de éxito de los actores de amenazas.
La cadena de eliminación de SaaS moderna generalmente implica:
- Comprometer una identidad en el IdP a través de una campaña de phishing exitosa, comprar credenciales robadas de la web oscura, cadenas de credenciales, relleno de credenciales, aprovechar inquilinos SaaS mal configurados o métodos similares.
- Realizar una fase de reconocimiento posterior a la autenticación. Este paso recuerda a los ataques que se introducían en las redes corporativas de antaño, pero ahora están revisando repositorios de documentos, repositorios de código fuente, bóvedas de contraseñas, Slack, Teams y entornos similares para encontrar puntos de entrada de escalada privilegiados.
- Aprovechar sus hallazgos para avanzar lateralmente hacia otros inquilinos de SaaS, PaaS o IaaS y, a veces, hacia la infraestructura corporativa, donde sea que puedan encontrar los datos más valiosos para la organización objetivo.
- Cifrar las joyas de la corona o entregar su nota de rescate e intentar evadir la detección.
 |
| Figura 2. Las cadenas de ataque exitosas de SaaS generalmente implican cuatro pasos generales: acceso inicial, reconocimiento, movimiento lateral y persistencia, y ejecución de ransomware y evasión de seguridad. Ilustración cortesía de AppOmni. |
Rompiendo una cadena de muerte SaaS del mundo real: Scattered Spider/Starfraud
El último seminario web informativo sobre inteligencia de amenazas del líder de seguridad SaaS, AppOmni, delineó la cadena de destrucción del ataque exitoso de los grupos de actores de amenazas Scattered Spider/Starfraud (afiliados de ALPHV) contra un objetivo no revelado en septiembre de 2023:
- Un usuario abrió un correo electrónico de phishing que contenía enlaces a una página de inicio de sesión de IdP falsificada y, sin saberlo, inició sesión en la página de IdP falsa.
- Los grupos de actores de amenazas llamaron inmediatamente a ese usuario y lo convencieron, mediante ingeniería social, para que le proporcionara su token de contraseña de un solo uso basado en el tiempo (TOTP).
- Después de obtener las credenciales de inicio de sesión del usuario y el token TOTP, los actores de amenazas engañaron al protocolo MFA haciéndoles creer que eran el usuario legítimo.
- Mientras estaban en modo de reconocimiento, los actores de amenazas tuvieron acceso a una escalada privilegiada, lo que les permitió obtener credenciales para Amazon S3, luego Azure AD y finalmente Citrix VDI (infraestructura de escritorio virtual).
- Luego, los actores de la amenaza implementaron su propio servidor malicioso en el entorno IaaS, en el que ejecutaron un ataque de escalada privilegiado de Azure AD.
- Los atacantes cifraron todos los datos a su alcance y entregaron una nota de rescate.
 |
| Figura 3. La cadena de destrucción utilizada por los grupos de actores de amenazas Scattered Spider/Starfraud. Ilustración cortesía de AppOmni. |
Es probable que Scattered Spider/Starfraud haya llevado a cabo esta serie de eventos en el transcurso de varios días. Cuando SaaS sirve como punto de entrada, un ataque grave puede incluir la red y la infraestructura corporativas. Esta conectividad SaaS/on-prem es común en las superficies de ataque empresariales actuales.
La actividad de ataques SaaS por parte de actores de amenazas conocidos y desconocidos está creciendo
La mayoría de las infracciones de SaaS no ocupan los titulares, pero las consecuencias son significativas. IBM informa que las filtraciones de datos en 2023 promediaron 4,45 millones de dólares por ejemplo, lo que representa un aumento del 15% en tres años.
Los actores de amenazas dependen continuamente de los mismos TTP y el mismo manual de estrategias de la cadena de destrucción de Scattered Spider/Starfraud para obtener acceso no autorizado y escanear a los inquilinos de SaaS, incluidos Salesforce y M365, donde los problemas de configuración podrían manipularse para proporcionar acceso más adelante.
Otros atacantes obtienen acceso inicial mediante el secuestro de sesiones y la imposibilidad de viajar. Una vez que han transferido la sesión secuestrada a un host diferente, su movimiento lateral a menudo involucra plataformas de comunicaciones como SharePoint, JIRA, DocuSign y Slack, así como repositorios de documentos como Confluence. Si pueden acceder a GitHub u otros repositorios de código fuente, los actores de amenazas extraerán ese código fuente y lo analizarán en busca de vulnerabilidades dentro de una aplicación de destino. Intentarán explotar estas vulnerabilidades para exfiltrar los datos de la aplicación de destino.
El informe de inteligencia de amenazas de AppOmni también informa que la filtración de datos mediante el intercambio de permisos sigue siendo un grave problema de seguridad de SaaS. Esto ocurre, por ejemplo, en Google Workspace cuando el usuario no autorizado cambia de directorio a un nivel de permisos muy abierto. El atacante puede compartirlos con otra entidad externa mediante el reenvío de correo electrónico o cambiando reglas condicionales para que los atacantes se incluyan como destinatarios BCC en una lista de distribución.
¿Cómo protege sus entornos SaaS?
1. Centrarse en la higiene de los sistemas SaaS
Establezca un proceso de admisión y revisión de SaaS para determinar qué SaaS permitirá en su empresa. Este proceso debería requerir respuestas a preguntas de seguridad como:
- ¿Todo SaaS necesita estar certificado SOC 2 Tipo 2?
- ¿Cuál es la configuración de seguridad óptima para cada inquilino?
- ¿Cómo evitará su empresa la desviación de la configuración?
- ¿Cómo determinará si las actualizaciones automáticas de SaaS requerirán modificar la configuración de control de seguridad?
Asegúrese de poder detectar Shadow IT SaaS (o Aplicaciones SaaS no autorizadas) y tener un programa de respuesta para que las alertas no se creen en vano.
Si no supervisa a sus inquilinos de SaaS e incorpora todos sus registros con algún método unificado, nunca podrá detectar comportamientos sospechosos ni recibir alertas basadas en ellos.
2. Realizar un inventario y supervisar continuamente las cuentas/identidades de las máquinas
Los actores de amenazas apuntan a las identidades de las máquinas por su acceso privilegiado y sus estándares de autenticación laxos, y a menudo rara vez requieren MFA.
En 2023, los actores de amenazas atacaron y violaron con éxito las principales herramientas de CI/CD, Travis CI, CircleCI y Heroku, robando tokens de OAuth para los clientes de todos estos proveedores. En estas situaciones el radio de la explosión se amplía considerablemente.
Dado que una empresa promedio contiene 256 identidades de máquinas, a menudo falta higiene. Muchas de ellas se utilizan una o dos veces y luego permanecen estancadas durante años.
Realice un inventario de todas las identidades de sus máquinas y clasifique estos riesgos críticos. Una vez que los haya mitigado, cree políticas que establezcan lo siguiente:
- A qué tipo de cuentas se les otorgarán identidades de máquina y los requisitos que estos proveedores deben cumplir para obtener acceso.
- El período de tiempo durante el cual su acceso/tokens estarán activos antes de que se revoquen, actualicen o vuelvan a otorgar.
- Cómo supervisará el uso de estas cuentas y se asegurará de que sigan siendo necesarias si experimentan períodos de inactividad.
3. Desarrolle una verdadera arquitectura Zero Trust en su patrimonio SaaS
La arquitectura Zero Trust se basa en el principio del mínimo privilegio (PLP) con un enfoque de «nunca confiar, siempre verificar». Si bien Zero Trust se ha establecido en redes tradicionales, rara vez se logra en entornos SaaS.
El enfoque centrado en la red de Zero Trust Network Access (ZTNA) no puede detectar configuraciones erróneas, integraciones de máquinas o derechos de acceso de usuarios no deseados dentro y hacia las plataformas SaaS, que pueden tener miles o incluso millones de usuarios externos accediendo a los datos.
Zero Trust Posture Management (ZTPM), una herramienta de seguridad SaaS emergente, extiende Zero Trust a su patrimonio SaaS. Cubre la brecha de seguridad de SaaS que crea SASE al:
- Prevención de la derivación no autorizada de ZTNA
- Permitiendo decisiones de acceso precisas
- Hacer cumplir sus políticas de seguridad con ciclos de retroalimentación continuos
- Extendiendo Zero Trust a integraciones de máquinas y conexiones en la nube
Con SSPM, ZTPM y un Programa de seguridad SaaS Una vez implementado, su equipo obtendrá la visibilidad y la inteligencia que necesita para identificar intrusos en las etapas de bajo riesgo de su cadena de destrucción y detenerlos antes de que una infracción se vuelva devastadora.