Reporting based on Security Tag Groups

qcj3 · ‎09-09-2019

I'm looking for a method of reporting on number of SIRs impacting CIs and Affected Users in a particular business division for leadership. (i.e. HR, IT, Manufacturing, etc.) I cannot use CI and Affected User attributes because often these do not line up and an employee moves around the company thereby changing their reported department. Also, often an SIR could impact multiple departments.

The method that I'm considering is using Security Tags. My thought is that I could create a Tag group then report on the tags in the group. It looks like I cannot run a report that groups by Security Tag let alone a specific tag in a tag group. Does anyone have a trick that would help me on the reporting?

andy_ojha · ‎09-19-2019

Hey there - Here's a way to report on both, applied Security Tags, as well as Security Tag Groups...

Within the the SIR Application, they give us a neat Table that creates a record, every time a Security Tag is applied to a record.

Table = sn_sec_cmn_applied_security_tag
What's cool here, is you can perform a "Group by" on the Security Tag
This is because, each row, represents one Tag -> so the Group by is supported
Unfortunately, we cannot dot-walk to fields and their values, for a given SIR record that a Security Tag was applied to

If we want to be able to create Reports to consume data from SIR records, and Group them by Security Tags, we can create a Database View to accomplish this.

A database view in ServiceNow, essentially joins two (or more) tables together
Reference -> Create a database view

Here's an example of approaching this:

You want to perform this in the "Security Incident" App Scope
Navigate to [Database Views] in the App Nav
- Create a new record here (a new DB View)
- In this DB View our goal is to join two tables together:
- - [sn_si_incident] - SIR Table
  - [sn_sec_cmn_applied_security_tag] - Applied Security Tags table
- We can join these tables by using the {sys_id} of the SIR record, and {record_id} of the Applied Security Tag record
Now, you can consume data from this Database View to ask questions like:
-> Show me SIR records created in the past 3mo, with Category = Privilege Escalation -> and *Group them by Security Tags

Consuming Database View (Grouping SIRs, by Applied Security Tag):

Setting Up Database View (Join SIR Table and Applied Security Tags Table)

Creating Reports Using your DB View

Additional thoughts to consider:

After you get going with the DB View - keep in mind that if an SIR has more than one Security Tag applied, it will show up more than once in the results returned (you'll get one record, per instance of the Security Tag being applied).

Depending on who will need access to these reports, there may need to be some ACL entries introduced so that users can <read>, based on the ServiceNow `roles` they have.

View solution in original post

Shiva Thomas · ‎09-09-2019

Hi qcj3,

Brainstorm mode on… 😅

I understand that the Affected User, and it's single department, may be too fluid, but maybe you could assign CI to departement?
Using a many 2 many table, you could even have multiple departments for each CI and still be able to have easy reporting on those.

Of course, now this looks a lot like the CMDB relationship model!

So… maybe you can go out-of-the-box and use one of the existing relationship [cmdb_rel_type] like "Owns" to connect your impacted CI with Business Services CI based on your main business division?

∴
Best regards from Switzerland
Shiva :¬,

If this reply assisted you, please consider marking it 👍Helpful or ✅Correct.
This enables other customers to learn from your thread.

qcj3 · ‎09-10-2019

Shiva,

I appreciate the response. The idea is to count the number of SIR's that impacts a department if that CI or Affected User (AU) belongs to the department. I can generate a report for AUs but only from the sn_si_m2m_task_affected_user, this doesn't collect CIs. Also, while many of the "areas" are internal departments two of them are not. (Franchisees, Suppliers) The tags were to act as an aggregation of the areas based on different criteria. Super complicated.

Thank you.

Eric Feron · ‎09-12-2019

Hello all, bringing this back to the attention of the community for more input.

Thanks.

andy_ojha · ‎09-12-2019

Hey there - the use-case you are solving for makes sense.

You may have already thought about this -> but just a thought...

When a Security Analyst is triaging, handling and closing a Security Incident -> they are typically determining the scope - (i.e. the "so what" or "how bad is it")
Traditionally, one would take the alert or "security incident" at hand and as part of their investigation to determine if this is isolated to a specific user, network subnet, VLAN, cluster of servers, one DMZ or multiple DMZs, etc.

Given the curveballs and complexities of making this purely data driven (i.e. capturing the Business Division, for the SIR overall)...

Would it be appropriate to have the Security Analyst determine the respective Business Division the SIR impacts, and let them capture this on the SIR record as part of their process (i.e. a choice field, that points to a given set of values)?
You can present the information they need to make this decision (i.e. show them dot-walked fields from the CMDB_CI, and / or Affected user record.
If you have network based SIEM alerts creating SIRs, sometimes the only artifact an analyst has is an IP Address, and they will need to make a determination of which part of their org is impacted and track that accordingly
The Security Analyst can then determine if multiple Business Divisions are impacted, and choose a respective value for that as well
In most Security Incidents, what starts off as a small "thing" will typically grow as you poke at log data, network traffic data, etc - where the scope can likely increase to multiple Business Divisions
Leadership is typically interested in the true picture of the SIR - based on findings from the Analyst (i.e. they care about the information after triage and analysis -> post processing / true information)

It is a bit more manual effort, but it avoids the curveballs you are running into when trying to solution this to be purely data driven. The Security Analyst is probably (or should be) evaluating the scope of their investigations; and you can leverage that data as part of this process. You also allow them to guide the investigation here, versus being bound to a system calculated value.

Leadership should then have high assurance in the reports that you will be providing to them (data completeness, accuracy, validation, etc.).

The decision on Business Division for a given SIR, becomes the output of the Security Analyst's triage and response efforts, and this is great value in determining the "so what", of a security incident. You might provide some data points to help the Security Analyst make the call (e.g. CI data, User Data, etc) -> but they will make the final call after triaging and handling the Security Incident.