-
Notifications
You must be signed in to change notification settings - Fork 6
Alert
Alert events are configured as described in the Detect section.
By default, alerts are sent to the docker console. A typical alert looks as follows:
{
"type": "alert",
"content": {
"Time": 1715956535,
"RequestID": "f916b220-3c2c-493d-9ff4-a543bc39816c",
"DestinationIP": "172.19.0.5:8000",
"Url": "localhost:8000",
"Server": "myapp",
"SourceIP": "172.19.0.1:35692",
"Authenticated": true,
"Session": "c32272b9-99d8-4687-b57e-a606952ae870",
"Username": "Bob",
"Useragent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0",
"Path": "/",
"Method": "GET",
"DecoyType": "KeyValueModified",
"DecoyKey": "role",
"DecoyExpectedValue": "user",
"DecoyInjectedValue": "admin",
"Severity": "HIGH"
}
}
Some of the fields' content depends on where the application is deployed and on the configuration of the config-default.json file. Details below:
The UTC time at which the alert is triggered, in timestamp format.
a log should always have a timestamp, for correlation.
The value of the x-request-id header added by Envoy to each received request
may be useful for correlation with other Envoy logs or with application logs.
The requested destination(s), as resolved by Envoy. In the IP:PORT format. Can be an array if more than one IP is resolved.
useful for internal attribution, in complement or as a replacement of the server name or of the URL.
The base URL, as requested by the user. Does not contain the path.
useful for internal attribution, in complement or as a replacement of the destination IP or of the server name.
The server name, if exists. This server name is the Pod's name in a kubernetes environment. Can be an array if more than one name is found. Can be empty (will be empty in the demo docker-compose setup).
useful for internal attribution, in complement or as a replacement of the destination IP or of the URL.
Can be overwritten in the config JSON file, see Server for details.
The source IP, as resolved by Envoy. In the IP:PORT format. Can be an array if more than one IP is resolved. The real source IP may be hidden behind a VPN or proxy.
useful for correlation, and for alert response. May be used for geo-localisation. May be checked against known VPN lists - most non-malicious users won't try to hide their real IP address.
Boolean value, resolved as per the configured session section of config-default.json.
See Session for details. May be wrongly set to 'true' if an attacker forges an invalid session token.
useful for alert prioritization, and for external attribution. An alert coming from an authenticated request is a sign of user account impersonation or of an insider attack.
If cloud active defense thinks that the request is authenticated, this field will contain the session token as configured in config-default.json. Otherwise the value will be empty. May be forged if the session value is taken from the user's request. See Session for details.
useful for correlation with other activities performed in this session. Can be used to identify the concerned user account as a complement or as a replacement of the Username value.
If cloud active defense thinks that the request is authenticated, this field will contain the value resolved through the configured username section of config-default.json. Otherwise the value will be empty. May be forged if the session value is taken from the user's request. See Username for details.
useful for correlation with other activities performed by this user. Can be used to identify the concerned user account as a complement or as a replacement of the Session value.
The user-agent, as sent by the user. May be forged.
useful for correlation, and for alert response. May be checked against known default tool's user agents, such as wget or dirbuster. Non-malicious users won't try to spoof their real user agent.
The requested path.
useful to know which part of the application is targeted
The used method (GET, POST, ...)
useful to know which part of the application is targeted
The observed behavior which triggered the alert: KeySeen (for whenSeen), KeyAbsent (for whenAbsent), KeyValueModified (for whenModified), KeyValueComplete (for whenComplete). If multiple behaviors are triggered, DecoyType will contain them all, comma-separated (for example: KeySeen, KeyValueModified)
useful to understand what triggered the alert
The configured decoy key plain value, or the configured decoy dynamicKey regular expression.
useful to understand which decoy was triggered
The configured decoy value plain value, or the configured decoy dynamicValue regular expression. Will be set for KeyValueModified and for KeyValueComplete decoy types, will be empty otherwise.
useful to understand how to received value violates the assumption
The received decoy value, as sent by the user. Will be set for KeyValueModified decoy type only, will be empty otherwise.
useful as intel on what the attacker tried to do.
The alert severity, can be LOW, MEDIUM or HIGH.
useful for prioritization.
Alerts are sent by the proxy container and displayed in the console. These alerts can be forwarded to a SIEM of your choice for proper monitoring or auditing. To facilitate this effort, we provide the following configuration, which leverages a Fluent-Bit agent. The agent forwards the alerts to a Fluent-Bit container, which displays the result in its own console. How events consumed by Fluent-Bit can be sent to another system is off-topic for this project. If you're not sure how to proceed, please refer to Fluent-Bit's documentation.