Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

updated Signals Explorer topic with new column titles #27715

Merged
115 changes: 91 additions & 24 deletions content/en/security/application_security/threats/security_signals.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,10 +16,30 @@

ASM security signals are created when Datadog detects a threat based on a detection rule. View, search, filter, and investigate security signals in the [Signals Explorer][2], or configure [Notification Rules][8] to send signals to third-party tools.

In the [Signals Explorer][2], filter by attributes and facets to find critical threats. Click on a signal to see details about it, including the service owner and attack details. Attack details include the authenticated user and their IP address, what rule they triggered, attack flow, related traces, and other security signals. From this page, you can block IP addresses and users, and also click to create a case and declare an incident.

{{< img src="security/application_security/threats/security_signals/appsec-threat-signals.png" alt="Overview of investigating threats in signals explorer with details side panel">}}

## Signals Explorer columns

Check warning on line 21 in content/en/security/application_security/threats/security_signals.md

View workflow job for this annotation

GitHub Actions / vale

Datadog.headings

'Signals Explorer columns' should use sentence-style capitalization.

The Signals Explorer displays the following columns.

Severity
: There are five severity states: **Info**, **Low**, **Medium**, **High**, and **Critical**. **High** and **Critical** indicate a major impact to service availability or active compromise.

Title
: The name of the signal. Titles might update when new data correlates and changes the impact of the attack.

Service/Env
: The service and environment identified in the attack. Hover over the service name to link to the service page and code repo, and to see who is on-call for the service.

Entities
: The attackers and the victims of an attack. Attackers are indentified by IP addresses. Victims are identified as authenticated users. Hover over the IP list and then click an IP to see details such as **Threat Intelligence** and **Security Activity**.

Triage State
: You can assign a responder and set a triage state for the signal. Available states are **Open**, **Under Review**, and **Archived**.

Creation Date
: The date when the signal was first created. Signals are sorted by date by default.

## Filter security signals

To filter the security signals in the [Signals Explorer][2], use the search query `@workflow.triage.state:<status>`, where `<status>` is the state you want to filter on (`open`, `under_review`, or `archived`). You can also use the **Signal State** facet on the facet panel.
Expand All @@ -28,53 +48,100 @@

You can triage a signal by assigning it to a user for further investigation. The assigned user can then track their review by updating the signal's status.

1. On the [Signals Explorer][2] page, select a security signal.
2. On the signal side panel, click the user profile icon and select a user.
1. On the [Signals Explorer][2] page, click the user profile icon in the **Triage State** column.
2. Select a user to assign the signal.
3. To update the status of the security signal, click the triage status dropdown menu and select a status. The default status is **Open**.
- **Open**: The signal has not yet been resolved.
- **Under Review**: The signal is actively being investigated. From the **Under Review** state, you can move the signal to **Archived** or **Open** as needed.
- **Archived**: The detection that caused the signal has been resolved. From the **Archived** state, you can move the signal back to **Open** if it's within 30 days of when the signal was originally detected.

**Note**: To modify security signals, you must have the `security_monitoring_signals_write` permission. See [Role Based Access Control][9] for more information about Datadog's default roles and granular role-based access control permissions available for Application Security Management.

## Create a case

Use [Case Management][6] to track, triage, and investigate security signals.

1. On the [Signals Explorer][2] page, select a security signal.
2. On the signal side panel, select the **Create a case** dropdown. Select **Create a new case**, or **Add to an existing case** to add the signal to an existing case.
3. Enter a title and optional description.
4. Click **Create Case**.

## Declare an incident

Use [Incident Management][4] to create an incident for a security signal.

1. On the [Signals Explorer][2] page, select a security signal.
2. On the signal side panel, click the **Declare Indident** dropdown menu and select **Create an incident**, or **Add to an existing incident**.
3. On the incident creation modal, configure the incident by specifying details such as the severity level and incident commander.
Declare an incident if:

- An issue is or might be impacting customers.
- You believe an issue (including an internal one) needs to be addressed as an emergency.

If you don't know whether you should call an incident, notify other users and increase severity appropriately.

1. On the [Signals Explorer][2] page, select a security signal to open its details panel.
2. On the signal panel, click **Declare Indident** or select the dropdown arrow and select **Add to an existing incident**.
3. When you declare a new incident, in the **Declare Incident** settings, configure the incident by specifying details such as the severity level and incident commander.
1. Estimate impact. Severity levels go from SEV-1 (critical) to SEV-5 (minor impact). When in doubt, always choose the higher severity.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this list supposed to include a separate step for selecting the incident commander? It feels a little odd to have an ordered list with just one item in it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. The substep is simply adding detail to severity level.

4. Click **Declare Incident**.

## Run a workflow

Use [Workflow Automation][5] to manually trigger a workflow for a security signal.

1. Make sure the workflow you want to run has a security trigger.
2. On the [Signals Explorer][2] page, select a security signal.
3. Scroll down to the **What is Workflow Automation** section.
4. Click **Run Workflow**.
5. On the workflow modal, select the workflow you want to run. Depending on the workflow, you may be required to enter additional input parameters.
2. On the [Signals Explorer][2] page, open a security signal.
3. In the **Respond** section, click **Run Workflow**.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same note as above about my concern that users might not know to click "Show all actions" to expose this section or button.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not worried.

5. In **Run a workflow**, select the workflow you want to run or click **New Workflow**.
- Depending on the workflow you select, you might be required to enter additional input parameters.
- If you selected **New Workflow**, Run a Security Workflow opens. To learn more about workflows, see [Workflow Automation][5].
6. Click **Run**.

## Review and remediate

1. On the [Signals Explorer][2] page, select a security signal.
2. On the signal side panel, click each of the tabs, such as **Attack Flow**, **Activity Summary**, and **Rule Details**, to review the information.
3. Review the **Suggested Next Steps**, and take action:
1. On the [Signals Explorer][2] page, open a security signal.
2. In the signal details, view each of the sections, such as **What Happened**, **Activity Summary**, and **Rule Details**.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Has the last section been renamed recently/is it going to be renamed imminently? I'm seeing "Detection Rule" instead of "Rule Details."

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be Detection Rule. I'll fix it. Great catch.

3. Review the **Next Steps** and take action:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just wanted to check whether "take action" is intentionally vague to let users choose their own adventure here. I can't tell if these are all options that a user could take, or if a typical user should do all of them, or if a user can choose multiple, or if they're mutually exclusive. But sometimes when course of action are vague, this is all you can really say.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a subset with details.

- Click **Block all Attacking IPs** (by specific duration or permanently).
- Click **Automated Attacker Blocking** (based on [detection][10] rules).
- Click **Automated Attacker Blocking** (based on [detection][10] rules). This setting requires the Application Security Management **Protect Write** permission.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the whole permission name be bolded? It is in the UI:
image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it shouldn't. The perm is Protect Write.

- Click **[Block with Edge WAF][11]**.

## Bulk actions

When you select one or more signals, you can use **Bulk Actions** to perform the following.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, there's an interesting UI quirk where if you've scrolled down the table of signals (not improbable if you're selecting multiple), you can't see the Bulk Actions button. Might be worth mentioning that it's at the top of the table? I usually don't like to do that, but I like to if I feel like I need an insurance policy against users getting lost in the UI.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think they can find it. It appears once you select a row.


### Set state

Set the signal(s) state to **Open**, **Under Review**, or **Archived**.

### Assign the signal to users

Select **Assign selection** and then select the user(s) to assign to the signal.

Select **Remove all assignments** to reset the signal assignment to none.

### Case management

Datadog [Case Management][6] offers a centralized place to triage, track, and remediate issues detected by Datadog and third-party integrations.

1. On the [Signals Explorer][2] page, select a security signal.
2. In **Bulk Actions**, select **Create a case**.
3. Select **Create a case** or **Add to an existing case** to add the signal to an existing case.
4. Enter a title and optional description.
5. Click **Create Case**.

When you click **Create case** you are directed the Case Management and the project you selected.

## Saved views

You can save different configurations of the Signals Explorer as views. For example, you could filter the explorer to show all unassigned signals and then save that as a view.

When a configuration is saved as a view, you and your teammates can reuse it later.

Check notice on line 128 in content/en/security/application_security/threats/security_signals.md

View workflow job for this annotation

GitHub Actions / vale

Datadog.oxfordcomma

Suggestion: Use the Oxford comma in 'When a configuration is saved as a view, you and'.

A view contains the explorer's current selections for:

- Time and query
- Displayed columns and sorting
- Analytics aggregation settings
- Timeline visibility
- Displayed facets
- Aggregate by detection rule

1. To save a view, configure the explorer to display the view you want and then click **Save**.
2. Enter a name for the view, and then select the teams you want to share the view with.
3. Click **Save**.

To see all of the saved views, click **Views** next to the **Signals Explorer** page title.

## Further Reading

{{< partial name="whats-next/whats-next.html" >}}
Expand Down
Loading