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 emp