"Success with SIR" webinar: Roles, Responsiblities and Data Sources

[Eliz Skogquist]

On July 10 & 11 Jamie Jackson, Sr. Product Success Manager, SecOps, and myself presented on the Security Incident Response (SIR) solution.  We reviewed the various roles, responsibilities, and both manual and automated data sources for getting data into SIR.  Roles were reviewed for an understanding of who can access SIR records and/or dashboards for creation, updates and/or review.  The various means for bringing data into SIR for assessment (Service Requests) and case management (Security Incidents and Tasks) were highlighted providing insight for customers getting started or wanting to mature their implementation.  

Agenda:

• Roles and Responsibilities
• Internal/Manual Data Sources
• External/Automated Data Sources (i.e. SIEM)

The webinar recording follows:

Resource Links

ServiceNow Documentation

Roles Installed (Components installed with SIR)

Security Incident Creation

Security Incident Response integrations

NowLearning.ServiceNow.com/NowCreate

Security Incident Response Assets

Watch for additional "Success with SIR" webinars that will deep dive into getting automated integrations set-up and other configuration insights.

Question	Answer
Is there a way to protect the "Create Security Incident" from misclicks?	One solution is to modify the UI action to include a confirmation modal. Another option could be moving the button to the dropdown, for more intentional access being required.
We are using a single form instead of the full catalog. Is there a form template for that catch-all to create a SIR record?	Not OOB unfortunately. But the catalog can be customized for this use case.
What if a Security Request requires a process to be followed for that particular type of request.  eg like in a Service Catalog request can have a process defined	Security Requests are generally of a lower priority. Like a scan request. We have the option to convert them to security incident, if needed. We can different types of requests by extending the security request table, for example, the security scan request.
I have scenarios where the SR is actually a request not an incident and therefore needs the ability to have something like a Playbook to ensure the request is processed accordingly.	A flow designer flow could be used for this scenario.