[SEC-1639] Add impossible travel detection methods #13204
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Adds documentation for the new "impossible travel" detection method for log detection rules.
greentruff
approved these changes
Feb 24, 2022
|
|
||
| #### Location attribute | ||
|
|
||
| The `location attribute` specifies which field holds the geographic information for a log. It cannot currently be changed and defaults to `@network.client.geoip`, which is the output of the [GeoIP parser][2] logs processor which enriches a log with location information based on the client's IP address. |
There was a problem hiding this comment.
It cannot currently be changed and defaults to
How about something like "The only supported value is @network.client.geoip which is enriched by the [GeoIP parser][2]`?
|
|
||
| ### Time windows | ||
|
|
||
| An `evaluation window` is specified to match when at least one of the cases matches true. This is a sliding window and evaluates in real-time. |
There was a problem hiding this comment.
I know this is the same phrasing as for the other rule types but matches true seems off to me.
sarina-dd
reviewed
Feb 25, 2022
|
|
||
| #### Location attribute | ||
|
|
||
| The `location attribute` specifies which field holds the geographic information for a log. It cannot currently be changed and defaults to `@network.client.geoip`, which is the output of the [GeoIP parser][2] logs processor which enriches a log with location information based on the client's IP address. |
There was a problem hiding this comment.
Suggested change
| The `location attribute` specifies which field holds the geographic information for a log. It cannot currently be changed and defaults to `@network.client.geoip`, which is the output of the [GeoIP parser][2] logs processor which enriches a log with location information based on the client's IP address. | |
| The `location attribute` specifies which field holds the geographic information for a log. The only supported value is `@network.client.geoip`, which is enriched by the [GeoIP parser][2] to give a log location information based on the client's IP address. |
|
|
||
| #### Baseline user locations | ||
|
|
||
| Tick this checkbox if you'd like Datadog to learn regular access locations before triggering a signal. |
There was a problem hiding this comment.
Suggested change
| Tick this checkbox if you'd like Datadog to learn regular access locations before triggering a signal. | |
| Click the checkbox if you'd like Datadog to learn regular access locations before triggering a signal. |
|
|
||
| #### Baseline user locations | ||
|
|
||
| Tick this checkbox if you'd like Datadog to learn regular access locations before triggering a signal. |
There was a problem hiding this comment.
Suggested change
| Tick this checkbox if you'd like Datadog to learn regular access locations before triggering a signal. | |
| Click the checkbox if you'd like Datadog to learn regular access locations before triggering a signal. |
|
|
||
| If selected, no signal will be triggered in the first 24 hours. In that time, Datadog learns the user's regular access locations. This can be helpful to reduce noise and infer VPN usage or credentialed API access. | ||
|
|
||
| Leave the checkbox unticked to detect all impossible travel behavior. |
There was a problem hiding this comment.
Suggested change
| Leave the checkbox unticked to detect all impossible travel behavior. | |
| Do not click the checkbox if you want Datadog to detect all impossible travel behavior. |
|
|
||
| ### Time windows | ||
|
|
||
| An `evaluation window` is specified to match when at least one of the cases matches true. This is a sliding window and evaluates in real-time. |
There was a problem hiding this comment.
Suggested change
| An `evaluation window` is specified to match when at least one of the cases matches true. This is a sliding window and evaluates in real-time. | |
| An `evaluation window` is specified to match when at least one of the cases is true. This is a sliding window and evaluates in real-time. |
|
|
||
| An `evaluation window` is specified to match when at least one of the cases matches true. This is a sliding window and evaluates in real-time. | ||
|
|
||
| Once a signal is generated, the signal will remain “open” if a case is matched at least once within this `keep alive` window. Each time a new event matches any of the cases, the *last updated* timestamp is updated for the signal. |
There was a problem hiding this comment.
Suggested change
| Once a signal is generated, the signal will remain “open” if a case is matched at least once within this `keep alive` window. Each time a new event matches any of the cases, the *last updated* timestamp is updated for the signal. | |
| Once a signal is generated, the signal remains “open” if a case is matched at least once within the `keep alive` window. Each time a new event matches any of the cases, the *last updated* timestamp is updated for the signal. |
|
|
||
| Once a signal is generated, the signal will remain “open” if a case is matched at least once within this `keep alive` window. Each time a new event matches any of the cases, the *last updated* timestamp is updated for the signal. | ||
|
|
||
| A signal will “close” regardless of the query being matched once the time exceeds the `maximum signal duration`. This time is calculated from the first seen timestamp. |
There was a problem hiding this comment.
Suggested change
| A signal will “close” regardless of the query being matched once the time exceeds the `maximum signal duration`. This time is calculated from the first seen timestamp. | |
| A signal closes regardless of the query being matched once the time exceeds the `maximum signal duration`. This time is calculated from the first seen timestamp. |
sarina-dd
approved these changes
Feb 25, 2022
Co-authored-by: Alexandre Trufanow <alexandre.trufanow@datadoghq.com>
muffix
added a commit
to DataDog/terraform-provider-datadog
that referenced
this pull request
Apr 1, 2022
Updates the provider for security monitoring rules to accept rules with the new detection method `impossible_travel`. See also: - DataDog/documentation#13204 - DataDog/datadog-api-client-go#1357
muffix
added a commit
to DataDog/terraform-provider-datadog
that referenced
this pull request
Apr 7, 2022
…od impossible travel (#1402) * Update provider for detection method impossible travel Updates the provider for security monitoring rules to accept rules with the new detection method `impossible_travel`. See also: - DataDog/documentation#13204 - DataDog/datadog-api-client-go#1357
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Adds documentation for the new "impossible travel" detection method for
log detection rules.
Motivation
Preview
https://docs-staging.datadoghq.com/bjorn.marschollek/SEC-1639/security_platform/cloud_siem/log_detection_rules?tab=impossibletravel
Additional Notes
Reviewer checklist