Security is not a responsibility of the security team, it’s everyone’s responsibility.
Areas often collaborate with security tasks, such as Backups that are often done by IT areas. Developers often create infrastructure as code.
Document all the collaborations with other areas in a RACI (Responsible / Accountable / Consulted / Informed) responsibility assignment matrix.
For example, IT may be the Responsible for taking the backups, Security team is Accountable to control that the backup is properly taken. The definition of the Backups frequency and storage tier will likely be a different task where security is responsible, but the business is consulted regarding the requirements.
While attacks will be blocked and normal traffic will be allowed, there are abnomalies where it’s not so clear whether the security team should block them or not. In these circumstances, the security team is not the right team to make the decision. Often security teams don’t have the manpower to investingate all low-risk abnomalies. In this situation its better to establish mechanisms to gather the point of view with business owners showing the potential loss and the reason why we suspect, for them to provide feedback on approve/reject.
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 any security team, the qualified security specialists, allowing them to take more strategic actions instead of operational tasks.