NOTA: Aún no se completó la actualización de la versión en español a v2, sugerimos usar la versión en Inglés por ahora.
La seguridad no es responsabilidad del equipo de seguridad, es responsabilidad de todos.
Las áreas suelen colaborar con tareas de seguridad, como las copias de seguridad, que suelen realizar las áreas de TI. Los desarrolladores suelen crear infraestructura como código.
Documente todas las colaboraciones con otras áreas en una matriz de asignación de responsabilidades RACI (Responsable/Autoridad/Consultor/Informado).
Por ejemplo, TI puede ser el Responsable de realizar las copias de seguridad, el equipo de seguridad es quien tiene la autoridad de controlar que la copia de seguridad se realice correctamente. La definición de la frecuencia de las copias de seguridad y el nivel de almacenamiento probablemente será una tarea diferente, donde la seguridad es responsable, pero se consulta a la empresa sobre los requisitos.
En muchas circunstancias el equipo de seguridad no es el indicado para tomar todas las decisiones, y no es una buena práctica que el equipo de seguridad evalúe situaciones de bajo riesgo, se comunique con el negocio para consultarles su punto de vista y en base a eso tome la decisión, sino que muchas veces es conveniente establecer mecanismos automatizados para recolectar el punto de vista del negocio y tomar una decisión automatizada según lo que el negocio considera.
Veamos un ejemplo.
Si se está detectando un ataque a una vulnerabilidad crítica de la aplicación, no consultaremos al negocio si desea permitirlo o no, simplemente lo bloquearemos.
Sin embargo, si detectamos un comportamiento anómalo asociado a un grupo de direcciones IP tal como una cantidad elevada de pedidos detectado por una Rate-Based Rule en el AWS WAF, que solo impacta en mayor carga para la aplicación, pero podemos soportarlo sin poner en riesgo la estabilidad de la misma… podríamos enriquecer la información agregando los nombres de los usuarios autenticados asociados a dichas direcciones IP, y enviar un correo al negocio indicándole los datos del hallazgo, explicando la situación, y dejar en ellos la decisión sobre permitir que el tráfico continúe, o bloquear en base a sus criterios (por ejemplo, podría tomarse en cuenta indicadores de fraude en esos usuarios, tales como la fecha de creación, o la cantidad de transacciones exitosas en el pasado, o el uso de datos de contacto de baja reputación)
De este modo, cuidamos al recurso mas escaso del equipo de seguridad, a sus humanos calificados, permitiendo que ellos tomen roles menos operativos y mas estratégicos.