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

[Security Solution] [Threat Hunting] [Cases] Allow User to Specify ServiceNow Incident Category/Sub Category #75622

Closed
shimonmodi opened this issue Aug 21, 2020 · 7 comments
Assignees
Labels
Feature:Actions/ConnectorTypes Issues related to specific Connector Types on the Actions Framework Feature:Cases Cases feature Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@shimonmodi
Copy link

shimonmodi commented Aug 21, 2020

Describe the feature:
Our current case capability allows users to send a case to external systems like ServiceNow ITSM, Atlassian Jira and IBM Resilient. This feature will allow users to categorize the case based on types supported by the external system.

Describe a specific use case for the feature:
Elastic's case feature supports analyst workflow for collecting various pieces of evidence that are relevant to an investigation, and as a collaboration feature that lets other analysts view the existing details and comment on it. There are several Incident fields that a user will want to fill out for each case. For example, the type of case (phishing, malware, C2 communication, identity privilege escalation) is critical to capture, persist and send to the external systems using their taxonomy. When an analyst is ready to push a case to an external systems configured as a connector, they will be provided Incident fields that are populated from ServiceNow ITSM Incident data model.

Currently we allow users to fill out the following ServiceNow ITSM Incident fields directly from Alerts UI:

  • Urgency
  • Severity
  • Impact
  • Description
  • Short Description
  • Additional Comments

Along with the above mentioned, we should add the following field selections when we recreate this capability in Cases:

  • Category
  • Sub Category
  • Assigned to

List of categories and sub-categories supported by ServiceNow ITSM available here: (https://docs.servicenow.com/bundle/orlando-it-service-management/page/product/incident-management/reference/r_CategorizingIncidents.html)

@elasticmachine
Copy link
Contributor

Pinging @elastic/siem (Team:SIEM)

@SHolzhauer
Copy link

Looking forward to this!

@cnasikas
Copy link
Member

cnasikas commented Oct 6, 2020

Urgency, severity, and impact were implemented in #77327. Description, short description, and comments were already implemented.

@MindyRS MindyRS added Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Feature:Cases Cases feature labels Oct 27, 2020
@SHolzhauer
Copy link

Possible note for the category and subcategory fields. These can be customized in ServiceNow with extra values, supoprting custom values would add to the value.

@cnasikas
Copy link
Member

cnasikas commented Mar 8, 2021

@SHolzhauer Category and subcategory implemented in #90547. We fetch the values directly from ServiceNow.

@cnasikas cnasikas added Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Feature:Actions/ConnectorTypes Issues related to specific Connector Types on the Actions Framework and removed Team:SIEM v7.10.0 Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. labels Jul 8, 2022
@elasticmachine
Copy link
Contributor

Pinging @elastic/response-ops (Team:ResponseOps)

@cnasikas
Copy link
Member

The "Assigned To" field will be addressed by this issue #140920

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Actions/ConnectorTypes Issues related to specific Connector Types on the Actions Framework Feature:Cases Cases feature Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
None yet
Development

No branches or pull requests

6 participants