Creación de capacidades de respuesta ante incidentes en SaaS

Artículo escrito conjuntamente por James Robinson y Vadon Willis

Todo departamento de seguridad que funcione tiene un plan de respuesta ante incidentes. La estrategia y la preparación previas son absolutamente imprescindibles para garantizar una respuesta rápida a las fugas de información, al ransomware y a otros numerosos desafíos, pero la mayoría de las empresas desarrollaron ese plan hace años, si no décadas, y ahora sólo lo revisan periódicamente. Esto es un problema.

¿Cuántas organizaciones han desarrollado un plan de respuesta ante incidentes dedicado para abordar los riesgos únicos de la era del software como servicio (SaaS)? Muy pocas. 

Piénselo: La respuesta de un departamento de seguridad corporativa a una brecha de seguridad relacionada con una solución SaaS gestionada por un tercero es, necesariamente, muy diferente de su respuesta a un ataque a la red corporativa, al centro de datos o a los puntos finales. Esto no sólo se debe a que el departamento de seguridad tiene menos control sobre el entorno SaaS, sino también a que tiene menos información que ayudaría de manera crucial a dar forma a la respuesta. Una respuesta eficaz a un ataque requiere una serie de pasos: identificación, contención y erradicación de la amenaza, recuperación y aprendizaje de la experiencia. Pero la identificación, contención y erradicación requiere un acceso profundo y visibilidad en el sistema de software y sus ficheros de registro de logs. 

Ahora, considere cada una de las aplicaciones SaaS de las que depende su empresa. ¿Cuánta visibilidad tiene realmente en esos sistemas? Y, teniendo esto en cuenta, ¿cómo sería la investigación de un incidente si esa aplicación SaaS sufriera una brecha? 

Si no lo sabe, es hora de que eso cambie.

Diagnosticando SaaS

He aquí una historia basada en una serie de eventos que sabemos que realmente ocurrieron en el mundo de la seguridad. Digamos que la empresa A tenía un sólido plan de respuesta ante incidentes construido sobre la base de años de experiencia con investigaciones y análisis forenses en las instalaciones locales, pero, francamente, no habían pensado lo suficiente en las formas en que ese plan tendría que cambiar en caso de tener un problema con una aplicación SaaS. 

Entonces, un empleado hizo pública una grabación de una reunión que incluía información patentada muy confidencial. Su intención no era maliciosa. En un esfuerzo por ser útil y poner la información a disposición de los nuevos empleados, colocó la grabación en un repositorio de la aplicación de videoconferencia basada en la nube donde tuvo lugar la reunión. Afortunadamente, un colega se alertó al darse cuenta de este error y notificó al departamento de seguridad.

Lo primero que supo la empresa A es que no tenían acceso a sus registros de log con este proveedor de conferencias. Ni siquiera tenían mucha información sobre su configuración de seguridad. Afortunadamente, cuando se pusieron en contacto con ellos, el contacto de ventas del proveedor fue muy receptivo a sus preocupaciones y consiguió que las personas adecuadas participaran de inmediato. Rápidamente descubrieron que la grabación no era segura—cualquier persona del mundo con la URL correcta podía acceder a ella—y que ni siquiera tenían permiso para cambiar la configuración de seguridad.

Esta fue una crisis que inicialmente dejó a todos los miembros del departamento de seguridad sintiéndose impotentes. No tenían visibilidad para saber si alguien se había aprovechado de la situación, así que no tenían ni idea de cuáles podrían ser las ramificaciones, o cómo debería ser la mitigación. Era difícil aceptar que habían estado ciegos ante este riesgo particular de SaaS.

Sin embargo, una vez que identificaron el alcance del problema, trabajaron estrechamente con el proveedor de videoconferencias en dos frentes: Hicieron que el proveedor cambiara inmediatamente la configuración para que el vídeo problemático fuera privado, y solicitaron acceso a todos los registros de log pertinentes. Investigaron las descargas del vídeo y las visualizaciones dentro de la plataforma de videoconferencias, correlacionando los registros de log de SaaS con sus registros de log internos para determinar qué acciones implicaban a personas ajenas a la empresa. 

El resultado fue un alivio: No había habido ningún acceso que pudieran verificar como procedente de fuera de su red corporativa. Tuvieron suerte: ese “gato” utilizó una de sus nueve vidas y siguió adelante. Aprendieron de esta experiencia y cambiaron su política —-y la configuración de todas las plataformas de comunicación que utilizan—para evitar que los vídeos se puedan compartir públicamente.

Diligencia debida y respuesta ante incidentes

Esta situación pone de manifiesto el hecho de que los incidentes de seguridad pueden ocurrir en las plataformas SaaS y que, si no nos preparamos con antelación, puede que no haya mucho que podamos hacer. Como resultado, aquí hay una lista informal de las mejores prácticas de seguridad SaaS que hemos desarrollado aquí en Netskope. Son las siguientes:

1. Evalúe la seguridad desde el principio. Una revisión de la seguridad debería ser un componente central de la diligencia debida en cada decisión de selección de aplicaciones SaaS. Cuando una empresa revisa a los posibles proveedores, el departamento de seguridad debe preguntar qué capacidades para registrar logs están disponibles, quién tiene acceso a los archivos de log y cuál es el proceso de respuesta ante incidentes, en caso de que algo vaya mal. 

Muchos proveedores SaaS están empezando a entrar en el espacio de la seguridad, considerando el soporte a los departamentos de seguridad de los clientes como una venta adicional. Me pone de los nervios, pero es algo habitual: La oferta estándar de SaaS del proveedor es opaca y los clientes que quieren acceder a los registros de log tienen que pagar más. Obviamente, en este entorno, la gestión del riesgo del proveedor debe realizarse antes de la firma del contrato. Una vez que la empresa ha seleccionado una solución SaaS a un precio determinado, el departamento de seguridad se enfrentará a una ardua batalla para añadir capacidades de registro de logs a un coste mayor.

2. No olvide la cadena de suministro de software. La revisión de la gestión de riesgos del proveedor también debería incluir una investigación detallada de la cadena de suministro de software SaaS. Esto me recuerda otra situación en la que una organización, llamémosla empresa B, tenía una relación establecida y de confianza con un proveedor y se pasó a su solución SaaS con una diligencia debida limitada. No se dieron cuenta de su error hasta que otro proveedor de software de esta solución SaaS sufrió un ataque de ransomware.

La solución SaaS estaba construida sobre una plataforma de otro proveedor, que no era nativa de la nube ni estaba diseñada para soportar sistemas en la nube. Cuando la plataforma fue víctima de un ataque de ransomware, descubrieron no sólo que la empresa B no tenía visibilidad del incidente, sino que su proveedor de SaaS tampoco la tenía. El proveedor tercero no se comunicaba directamente con la empresa B, y el proveedor de SaaS tardó bastante tiempo en entender lo que había sucedido. 

¿Qué podemos aprender de este incidente con la empresa B? Debido a las complejas y distribuidas cadenas de suministro de las aplicaciones SaaS, los departamentos de seguridad nunca deben escatimar en la diligencia debida, incluso si confían en el proveedor con el que contratan.

3. Establezca los contactos adecuados. Otro componente importante del proceso de diligencia debida de SaaS es establecer contactos dentro de la función de seguridad del proveedor. En el incidente de la empresa A con el proveedor de sistemas de conferencias, su contacto de ventas actuó rápidamente y les ayudó a contener el riesgo. Sin embargo, los departamentos de ventas cambian, y a veces no responden por diversas razones. En algunos casos, ponerse en contacto con el departamento de ventas por un problema de seguridad puede retrasar la respuesta al incidente.

Las funciones de soporte de los proveedores de SaaS desempeñan un papel importante en las relaciones con los clientes, pero tienen flujos de trabajo internos que también pueden crear retrasos innecesarios en una crisis. El escenario ideal es que el departamento de seguridad del cliente tenga contactos directos dentro del grupo de seguridad del proveedor, a los que pueda recurrir en caso de emergencia.

4. Planifique su respuesta. A principios de este año, la Cloud Security Alliance (CSA) publicó un marco de respuesta ante incidentes en la nube que proporciona una excelente orientación sobre cómo los clientes deben reaccionar ante un ataque a una solución en la nube. Netskope ha desarrollado un enfoque ligeramente diferente, pero con bastantes coincidencias. Todo plan de respuesta ante incidentes de SaaS debería:

• Especificar qué acciones se tomarán cuando se descubra un incidente —tanto el diagnóstico inmediato como los esfuerzos de contención y erradicación a más largo plazo. Estas acciones pueden incluir la desconexión de los sistemas, la puesta en cuarentena de los departamentos, la restricción de la conectividad de los usuarios y/o la alerta a las partes interesadas sobre el problema. La CSA recomienda desarrollar una escala de clasificación de incidentes que correlacione cada tipo de evento de seguridad con la respuesta adecuada. 
• Delimitar las funciones y responsabilidades, así como los contactos de emergencia y los canales de comunicación preferidos en cada proveedor de SaaS.
• Definir cómo funcionarán la supervisión y las alertas dentro de cada solución SaaS.
• Aclarar los métodos a través de los cuales el departamento de seguridad interno obtendrá visibilidad de un incidente. Idealmente, esto implicará el acceso a los registros de log de todas las actividades de gestión y llamadas a API en cada plataforma SaaS que la organización utilice.
• Proporcionar un proceso post-mortem para aprender las lecciones del incidente e incorporarlas a la mejora continua de la seguridad. Aplicar las lecciones de un incidente con una aplicación a otras soluciones SaaS refuerza la seguridad en la nube en toda la organización.

5. No deje que ninguna nota de publicación de nuevas versiones quede sin leer.Los cambios son muy rápidos en la nube. En muchos casos, la mejor información que tienen los clientes de la nube para entender esos cambios viene en forma de notas que detallan la publicación de nuevas versiones. Los departamentos de TI que hacen malabarismos con un sinnúmero de soluciones que parecen actualizarse continuamente puede que no den prioridad a profundizar en cada versión menor—pero deberían hacerlo.

Ya sea que una versión introduzca nuevas características o solucione un problema con la versión anterior, los cambios que se introducen pueden tener implicaciones involuntarias para la seguridad. Todos los proveedores de software son culpables de esto. Los cambios en una parte del producto acaban rompiendo otra, y los usuarios deben (como mínimo) volver a establecer la configuración de seguridad que la versión ha alterado. 

Las notas de publicación de nuevas versiones son la notificación del proveedor de estas situaciones. No revisar cuidadosamente todas y cada una de ellas significa que el departamento de seguridad no entenderá lo que está cambiando, y las nuevas brechas de seguridad creadas pueden pasar desapercibidas. En Netskope, nuestra prioridad es asegurarnos de que todo nuestro departamento de seguridad esté informado de las posibles ramificaciones cada vez que uno de nuestros proveedores de SaaS publica una nueva versión.

Exija más a los proveedores SaaS

La empresa media tiene alrededor de 1.200 proveedores en la nube. Algunos de ellos son proveedores de infraestructura como servicio o plataforma como servicio, que tienden a dar a los clientes más control sobre su entorno de seguridad. Pero alrededor del 90% de los proveedores en la nube de una empresa típica son proveedores de SaaS. Esto significa que la organización de seguridad de la empresa media es responsable de proteger los datos de más de 1.000 aplicaciones, sobre las que tiene un control mínimo y una visibilidad limitada. 

Las aplicaciones SaaS se han convertido en algo demasiado importante para las operaciones del negocio como para que los departamentos de seguridad dejen que esta situación continúe. Tenemos que asegurarnos de que participamos en la selección, la arquitectura y el diseño de todas las soluciones SaaS que utiliza nuestra organización. Tenemos que pensar constantemente en cómo responder a un fallo de seguridad SaaS. Tenemos que adaptar nuestros planes de respuesta ante incidentes locales para que se ajusten al mundo SaaS, modificando nuestras guías de procedimientos para las diferentes soluciones SaaS. Y como profesión, tenemos que insistir en que nuestros proveedores SaaS proporcionen la información que necesitamos para gestionar eficazmente el riesgo de ciberseguridad de nuestra empresa.