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.