More flexibility for exceptions

[felipesere]

Is your feature request related to a problem? Please describe.

In our current infrastructure we have control over most of the resources. The things we don't have control over are AWS resources create by ControlTower and Third-Party integrations in the form of CloudFormation Stacks. It's a lot of work to create an exhaustive list of exceptions across 30+ accounts.

Describe the solution you'd like

We were faced with a similar situation when running SecurityHub. There, we wrote a custom Go tool that is configured via a YAML file. The pattern in that YAML file are treated as regexes that are matched against ARNs like so:

 - code: S3.1
        scope: regional
        suppress:
          - pattern: "*aws-controltower-*" 
            note: "Some good reason why we suppress this finding"

Having a similar mechanic would mean that our Exceptions file becomes portable across our accounts.

Describe alternatives you've considered

We have considered generating the exceptions file manually but we think there is an ID in there that made it hard. Also, this would just alleviate the listing of resources, the size and maintainability of exceptions file would still be an issue.

Additional context

We run the same rules/exceptions over 30 accounts. We really like that pattern as it gives a good awareness of our accounts are operating. It also gives our CISO a central place where exceptions/rules are approved. The number of accounts we are operating will only grow, so this becomes a bigger and bigger issue.

[x4v13r64]

The exceptions implementation would definitely benefit from a rethink. Dynamic rules via regex/pattern matching would be a nice feature.

Moving this to medium-term as it's unlikely we'll have resources sooner. Happy to accept & support PRs though.

[bradenwright]

fwiw I added wildcard exception b/c there wasn't a way to click it in the ui / find it for ELB / HTTP clear text. That was only a 1 line change to ScoutSuite/core/exceptions.py

I updated line 25 to be if item not in self.exceptions[service][rule] and "*" not in self.exceptions[service][rule]:

[booleanbetrayal]

Note that there are some inconvenient ways around this lack of UX involving looking the path value in the findings definition JSON and using DOM inspection to determine the ID values needed.