The Community Common Dashboards content pack in the XSOAR Marketplace contains dashboards for monitoring the operation and use of XSOAR.
The CISO Metrics dashboard provides a set of customized OOTB widgets from multiple dashboards that present a single overview of XSOAR operation using a consistent visual style and nomenclature.
The XSOAR Value Metrics dashboard focuses on two areas of XSOAR value for executive management reporting:
This dashboard enables an organization to determine the overall value of XSOAR by baselining cost and time metrics in responding to security alerts coming into XSOAR. These metrics feed automation optimization efforts by incident type driven by their frequency and current level of effort and response times. Cost to respond and time to respond metrics are tracked and stored in XSOAR lists so trends are tracked over multiple years without requiring incident retention in the XSOAR database or expensive queries across long time spans. Data for the dashboards is collected by an automation from the content pack and an XSOAR job.
Cost to respond to alerts is based on per XSOAR incident type estimates of the effort it would take to respond to an alert without use of XSOAR compared to the time to respond to the alert with XSOAR and the quantity of alerts processed by XSOAR. The mix of incidents and the relative effort handling different types of incidents factor into the overall cost to respond and the reduction in effort provided by XSOAR.
Below is an example from the XSOAR Value Metrics dashboard that highlights effort metrics. Based on per-incident effort estimates with and without XSOAR provided by the customer, the dashboard tracks monthly and annual effort reduction using XSOAR to automate incident response. The dashboard defines the contribution of each incident type to that effort reduction to guide long term optimization of the XSOAR implementation.
Time to respond metrics are measured by overall incident duration and SLA timers implemented by the customer. Incident duration is based on the data from the incident populated in the openDuration field when an incident is closed. There is a parameter to the data collection automation that allows the duration to be computed from the created and closed field timestamps in situations where the openDuration field does not have valid data with cases like imported incident data.
Both standard XSOAR SLA timer fields and custom SLA timer fields are monitored by the dashboard. For each timer, the monthly and annual average durations are provided. In addition, a custom user-defined duration can be specified where the customer specifies two SLA timers; the start time of the first timer and end time of second timer define the duration.
The dashboard also provides monthly and annual data on incident counts by incident type that were used to generate the effort and time metrics above. Closed versus active incidents are tracked to provide visibility into changes in incoming and closure rates of incidents.
The dashboard is supplied with data by an automation executed periodically, typically monthly, by the customer to collect incident statistics and store the results in XSOAR lists. This allows monitoring metrics over several years without the requirement of incidents being retained for long term trending within the XSOAR console. The automation manages the current year metrics and rolling over to a new year. There are options to filter incidents using several parameters or pass a full incident search query.
By defining different lists as the automation’s output, groups of incidents are displayed by changing the name of the list the dashboards widgets pull data from. Customization enables different organizational groups to have their own dashboards, or for the organization to trend metrics over multiple years, for example.
The “Details” tab of the content pack explains the setup for the dashboard and has descriptions of the automations and lists used. The XSOARValueMetrics automation is responsible for collecting metrics for a specified time window and generates metrics for the top 20 incident types in that time period. The automation creates a small CSV with four tables in the war room as well as storing the metrics in JSON dictionaries in two XSOAR lists specified in the “thisyearlist” and “lastyearlist” arguments..
The four tables in the war room CSV contain collected data by month for:
The time window is expected to be a complete month specified by the “firstday” and “lastday” arguments. If partial months are used, the open durations and SLA metrics is the average of the last set of incidents found, while incident counts are incremented. For more details on how the data is updated, see the “mode” argument for different options.
firstday - required argument to set the start day for searching incidents
Example: firstday=2024-03-01
lastday - required argument to set the last day for searching incidents
Example: lastday=2024-03-31
thisyearlist - required argument for XSOAR list where current year results are stored
Example: thisyearlist=MetricsThisYear
lastyearlist - required argument for XSOAR list when the year rolls, “thisyearslist” is copied here
Example: lastyearlist=MetricsLastYear
mode - argument controls saving monthly statistics in this year’s XSOAR list (a JSON
object) as specified in the “thisyearlist” argument:
The default mode is mode=increment and expects the time windows for each query to be contiguous months with no gaps or overlaps in the time window specified by the “firstday” and “lastday” arguments. If the time windows overlap, then incidents will be double counted. If there are gaps between time windows, then incidents may be missed. If the query needs to run and not update the saved statistics, use mode=noupdate. In the event a month with saved statistics needs to be rebuilt, use mode=initialize with the first day and the last day of the month to reset the values.
slatimers - optional argument for a CSV list of custom SLA timer fields to include in the metrics
Example: slatimers="customsla1,customsla2,customsla3"
filters - optional argument is a CSV list supports the following field names to filter incidents on:
severity
unknown
information
low
medium
high
critical
status or notstatus
pending
active
done
archive
type - is the name of a single incident type
owner - is the name of a single incident owner
Example: filters="type=typea,status=done,severity=high"
query - if this parameter is passed, the “filters” argument is ignored. The “query” parameter is a Lucene/Bleve search string the same as is used in the incidents search box in the XSOAR console. The “query” string is used to select which incidents - you do not specify dates. These are controlled by the “firstday” and “lastday” parameters
windowstart and windowend - if these parameters are passed with the name of timer fields as values, the duration is calculated from windowend.endDate - windowstart.startDate for the “UserWindow” synthetic SLA metric
esflag - If using Elasticsearch, you may need to set this to “true” if more than 10000 incidents in a two day period. Elasticsearch has a 10000 incident search limit and this flag reduces the search windows from 2 days to 4 hours
computeduration - Computes the incident open duration from the created and closed fields in cases where the openDuration field does not have valid data - such as import of incidents
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| Subject | Likes |
|---|---|
| 4 Likes | |
| 4 Likes | |
| 2 Likes | |
| 2 Likes | |
| 1 Like |
