Security Incident Response Setup / Configuration Understanding Part - 2

Sandeep Kumar6 · ‎02-15-2019

Hi There,

This is in continuation of part 1 which i have posted few days back. This include few more terminologies from Security Incident Response which will help you to understand it more.

PIR- Post Incident Review

Configure Escalation Groups

If an escalation path exists for a security incident, the Escalate button is available in the security incident header.
An escalation group is available for all security incidents in the initial group. you can create multiple groups

Creation of group

https://docs.servicenow.com/bundle/london-security-management/page/product/security-operations-commo...

following this, the group which will be mentioned in the initial group here ex. application security... now when we open an SIR having its assignment group as Application Security...then only the "Escalate " Button appears in the header

Post Incident Review

Go to Trigger Condition

This is OOB Module where we configure trigger condition for Post Incident Review (already there OOB).
Trigger conditions specify when to send a particular survey and the persons to send it to.
This runs business rule (System generated Business Rule - Auto assessment business rule)
- This system generated Business rule is generated by another business rule “Generate assessment trigger condition”
- “Auto assessment business rule” again calling SNC script include (No accessible to customer) with “conditionTrigger” function. https://community.servicenow.com/community?id=community_question&sys_id=3d120fe9db98dbc01dcaf3231f96...
- Business rule (On Trigger Condition form) the system creates to monitor the selected table. When the condition is met, the business rule sends the survey to the correct user. No configuration is necessary for this business rule.
- “asmt_assessment_instance” This is an assessment table which stores all the user response."
- “asmt_metric_type” This is the table where we can see are survey configured for PIR.
  - Here we can define all the categories which we need to send.
- Survey will be send to all the used selected in Post Incident Review tab. (Open one record and click on PIR tab)

The final product of the post incident review is the post incident report. The post incident report is required to record the actions performed, the reasons for doing them, and lessons learned. The post incident report compiles all of the information related to the security incident, as well as all assessment responses if one is performed, into an initial draft that you can then edit.

If the report was generated by clicking the Format Post Incident Report (dint find this) button without sending out a questionnaire, an initial post incident report is assembled. If a questionnaire was sent out, those results are included, along with the percentages of users who provided each answer. But even if a questionnaire was not used, the post incident report provides valuable data, including:

the initial incidents that caused the security incident
changes, problems, and vulnerabilities created or linked to the security incident
a description on the security incident
the entire activity log with all work notes, response tasks, and activities

Configure Tagging (Tags, Groups, Rules)

Security tag rules provide filtering for security tag access based on role (read or write).
We can assign multiple security tag to Security Tag Group
You can assign tags (Not security Group) to security incidents, response tasks, vulnerable items, observable, IoCs, and security cases to create metadata on the responding record and define who should have access to specific types of security content.
After Navigating to Security Operations > Security Tags > Groups.

We will find three default classification groups to the base system:

*Enrichment whitelist/blacklist: This group defines whether a record is to be treated as a whitelist or blacklist record. Whitelist records are generally of less significance, so they can be ignored. Blacklist records are generally of higher interest.
*Metatag: This group is provided as demo data. You can use it to create custom classification tags that are used by security operations applications.
*Traffic Light Protocol: This group is used to ensure that sensitive information is shared with the correct audience. It employs four colors (White, Green, Amber, and Red) to indicate different degrees of sensitivity. For each color, you can assign the appropriate read/write access roles. When sharing observables to a trusted security circle, the tag assigned to the trusted security circle profile determines which TLP-tagged observables can be shared to the circle, as follows:

User-Reported Phishing Module

It’s a separate module under security incident which helps in diverting Phishing emails.

When your employees receive emails that appear to be phishing attacks, they can report them to you using a phishing email address. The suspicious email is validated using rules defined by your organization.

We can configure “Email Matching Rules” to achieve the same.

Security Operations > Email Processing > User Reported Phishing

Configure Security - Hardening

These are key settings and configurations that can be made to your ServiceNow instances in respect to security. We can go through the information in the Instance Security Dashboard to receive a quick status of missing configurations within the instance.

Example:

Input Validation
Access Control
Authorization

System Security à Instance Security Dashboard

If this is not configured and its mandatory then we can follow all the steps from below URL.

https://hi.service-now.com/kb_view.do?sysparm_article=KB0550654

Configure Encryption Contexts

This is just an encrypted field where we can keep data in encrypted form.
The work notes that are encrypted and not visible to the customer.
User with the security_admin role can view this field

https://docs.servicenow.com/bundle/jakarta-platform-administration/page/administer/encryption/task/t...

Thanks

Happy Learning 🙂

swarner · ‎09-02-2021

Can you please provide the link to Part 1? The only other post by you on this topic that I can find is from 3 years ago (not posted a few days back from this post).

alan_lowrance · ‎10-06-2022

Thanks for the write-up on this, I am currently implementing SIR and VR for my company and noticed that the user-reported phishing go into a black hole that no analysts would go look at and review and let the user know if it was an actual phishing attempt, unwanted marketing spam, or if it was from a legitimate vendor that needs to be replied to. Should I make these be actual Sec INC instead then if I want someone to review them and for them to show up on reports to show how many malware detections vs. phishing attempts etc are happening each month?