Friday, 8 February 2019

Security Incident Response Setup / Configuration Understanding.

With Security Incident Response (SIR), manage the life cycle of your security incidents from initial analysis to containment, eradication, and recovery. Security Incident Response enables you to get a comprehensive understanding of incident response procedures performed by your analysts, and understand trends and bottlenecks in those procedures with analytic-driven dashboards and reporting.
Following are my understanding or observation from Security Incident Response.
Activate Security Incident Response
Security Incident Response activates these plugins
True/false indicates availability of plugin 
  • Service Management Core [com.snc.service_management.core]àtrue
  • Task-Outage Relationship [com.snc.task_outage] à true
  • Tree map [com.snc.treemap] àTrue
  • Threat Core [com.snc.threat.feeds] àFalse
  • Security Support Orchestration [com.snc.secops.orchestration] àTrue
  • Security Incident Response support [com.snc.security_support.sir]àFalse
  • WebKit HTML to PDF [com.snc.whtp] àTrue
  • Security Incident Analyst [] à True
  • Security Incident Response  [com.snc.security_incident] à True
Configure Security Incident Response
The options for configuring the applications are organized under Business Process, Assignment and Add-ons tabs.
There are few properties available under these tabs which allows to control the behavior of Security Incident
  • The Business Processtab contains options for setting up the request life cycle, creating catalogs and requests, and configuring notifications.
  • The Assignmenttab contains options for setting up manual and auto-assignment.
  • The Add-ons tab contains options for enabling the knowledge base, managed documents, and task activities.  
Optional setup steps include:
Create a Security Incident Response process definition
I have gone through the ServiceNow docs about it and tried reaching associates here regarding this process but it seems there is no definite process for S
Security Incident unlike Best Practice - Incident Resolution Workflow for Normal Incident
You can create a process definition to define the way security incidents transition from one state to the next. Process definitions give service desks and end users help tracking the problem throughout its life cycle
Before you begin
Role required: sn.si_admin
  • Navigate to Security Incident > Administration > Process Definition.
  • Click New.
Security incidents can be logged or created in the following ways:
  • From Security Incident form.
  • From events that are spawned internally, or created by external monitoring or vulnerability tracking systems via alert rules, or manually.
  • From external monitoring or tracking systems directly.
  • From the service catalog
Create a security incident group
  • If you have the user_admin role, you can create security incident assignment groups.
  • If you have the sn_si.admin role, you can create and edit security incident assignment groups.
  • Navigate to User Administration > Groups or Security Incident > Setup > Groups
    • Fill all the information as required
  • I have tested this by creating a group name “SIR WalkThrough” in my PI.
  • In the Roles related list, add the roles that each member of this group receives.
  • For example, if you are making a group for Security Incident Response team members, add sn_si.analyst. If you are making a group for Security Incident Response administrators, add sn_si.admin
 Create a Security Incident Response SLA
  • This can be configured based on the requirement we have.
  • Navigate to Security Incident > Setup > SLAs
 Create a Security Incident Response runbook
  • Navigate to Security IncidentManual RunbookCreate New Runbook
  • We need to have knowledge base articles in the Security Incident ResponseRunbook knowledge base
We can achieve that by adding Security Incident Response Runbook in Knowledge Base
I have found few important terminology below in Security Incident Response, Try to have these in mind when you are going to start it.
Scoring in security incident
The risk score is calculated as an arithmetic mean that represents the risk based on the priority of a security incident, the type of security incident (Denial of Service, Spear Phishing, or Malicious code activity), and the number of sources that triggered a failed reputation score on an indicator.
Following business rules trigger automatic calculation of risk scores:
  • Calculate Severity
  • Update risk score
  • Update SI risk score
Note: The risk score is calculated using weights defined in Risk score configuration
If a security incident has a Business impact set to 2-High and a Priority set to 3-Moderate, the respective weights in the Risk Score Weights table are looked up and calculated thus:
Security Incident Business Impact with a value of 2 = a weight of 60.
Security Incident Priority with a value of 3 = a weight of 40.
60 + 40/2 = a risk score of 50.
  • The work notes are updated when the following fields are changed (causing the risk score to be updated):
    • Business impacton the Security Incident form
    • Priorityon the Security Incident form
    • Severityon the Security Incident form (hidden by default)
    • Business impacton the Affected Users related list
    • Business impacton the Affected Services related list
    • Business impacton vulnerabilities on the Vulnerable items related list
Risk score override
Select this check box to override the automatic update of the risk score. The override will be reflected in the work notes
You can also manually enter a new Risk score. This can be useful if you want to keep a particular security incident at the top of the list of security incidents you are analyzing. If you enter a new Risk score, the Risk score override check box is automatically selected. Regardless of the changes made in the security incident, a manually-entered risk score is not automatically recalculated
Secure notes
  • Click the lock icon to unlock the field, enter work notes that are visible to the security users, and click the icon again to lock it.
  • The work notes that are encrypted and not visible to the customer.
Read access
  • Gives a user with the special accessrole read access to the security incident. The user is able to read and write work notes.
Privileged access
Gives a user with the special access role read and write access to all fields of the security incident except Assigned to. Users with special access roles have their own module containing all security incidents assigned to them. No other modules are available to them. No one else can see the Visible to Me module
  • If a user is added to both Read accessand Privileged accesslists, then only
the Privileged access permissions persist
  • Only an assigned user or someone with a security role (for example, sn_si_analyst or sn_si.admin) can change the Assigned to
SIR Lifecycle
Draft à Analysis à Contain à Eradicate à Recover à Review à Closed
  • Normally it will follow NIST process but you can jump or skip one or two state and directly go for Recover or Review.
  • We can’t close any Security Incident until we complete or close all the related tasks.
  • We can close Security Incident after contain state before that we don’t even have option to close it.
  • Assignment Group and Assignee are auto populating as one workflow (Assignment Workflow for SM) is running behind which is checking skill based resource and assigning the incident to him.
  • We can cancel Security Incident from button that appears on header when state changes from Draft to Analysis
  • But I could fine cancelled state for response task.
    • Ready à Assigned à Work In Progress à Complete à Cancelled
Reference Link:

No comments:

Post a Comment