Fix false positives in "AWS Attached Malicious Lambda Layer" rule

[imall4n]

Summary of the Pull Request

The rule generates false positives because it monitors function configuration updates in a generic way, without specifically targeting Lambda Layer changes. Currently, the rule triggers on any configuration update, such as changes to execution time, memory size, or description. The suggestion is to add a new condition field to check if the "requestParameters" contains the "layer" field, ensuring the rule only triggers when Lambda Layers are modified.

Changelog

new: detection:selection:requestParameters.layers|contains - added new condition to ensure the rule triggers only when Lambda Layers are modified.

Example Log Event

The rule triggers when the function configuration is not related to Lambda Layers changes, such as:
...
"eventSource": "lambda.amazonaws.com",
"requestParameters": {
"ephemeralStorage": {
"size": 512
},
"memorySize": 1024,
"functionName": "Example-Function-Name",
"description": "Example function description.",
"snapStart": {
"applyOn": "None"
},
"timeout": 121
}
...

The rule should only trigger when the request has the 'layers' field, such as:

...
"eventSource": "lambda.amazonaws.com",
"requestParameters": {
"functionName": "Example-Function-Name",
"layers": [
"arn:aws:lambda:us-east-1:123456789123:layer:example-function:1"
]
}
...

Fixed Issues

SigmaHQ Rule Creation Conventions

• If your PR adds new rules, please consider following and applying these conventions

[github-actions]

Welcome @imall4n 👋

It looks like this is your first pull request on the Sigma rules repository!

Please make sure to read the SigmaHQ conventions document to make sure your contribution is adhering to best practices and has all the necessary elements in place for a successful approval.

Thanks again, and welcome to the Sigma community! 😃