Sharing security tasks and responsibility

In many circumstances, the security team is not the right team to make all decisions, and it is not good practice for the security team to evaluate low-risk situations, communicate with business to consult their point of view and make the decision based on that. It is often advisable to establish mechanisms to gather business point of view and make an automated decision based on what the business considers appropriate.

Let’s look at an example.

If an attack on a critical application vulnerability is being detected, we will not query business stakeholders whether they want to allow it or not, we will simply block it.

However, if we detect anomalous behavior associated with a pool of IP addresses such as a high number of orders detected by a Rate-based Rule in AWS WAF, which only generates a greater load on the application, but we can handle it without compromising the stability of the application… we could enrich the information by adding the names of the authenticated users associated with those IP addresses, and send an email to the business stakeholders indicating the details of the finding, explaining the situation, and leave for them the decision to allow traffic to continue, or block based on their criteria (for example, fraud indicators could be considered in those users, such as the date of creation, or the number of successful transactions in the past, or the use of low reputation contact data)

In this way, we take care of what is the scarcest resource of the security team, their qualified members, allowing them to take more strategic roles instead of operational ones.