Skip to main content

Community Common Dashboards

Download With Dependencies

A pack that contains community dashboards

Community Common Dashboards

This content pack contains two dashboards:

  • CISO Metrics
  • XSOAR Value Metrics

CISO Metrics Dashboard

This dashboard uses OOTB widgets configured to present a consistent overview of XSOAR operation.

XSOAR Value Metrics Dashboard

This dashboard provides XSOAR value metrics for the XSOAR implementation:

  • Time to respond to alerts
  • Cost to respond to alerts

Time to respond metrics are measured by overall incident duration and SLA timers that have been implemented. Cost to respond 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 alerts and the relative costs of handling different types of alerts factor into the overall cost to respond. An automation is ran periodically to collect incident statistics and stores the results in XSOAR lists. This allows monitoring metrics over years without the requirement of incidents being retained - for long term trending within the XSOAR console. The automation manages the current year metrics and previous year metrics. Dashboard widgets retreive data from these lists for display. Additional functionality is available through adding lists and customization of the automation and script arguments to use these lists.

There are three XSOAR lists used by the automations and dashboard:

  • Incident effort - user provided estimates for each incident type
  • This year metrics - populated by XSOARValueMetrics
  • Last year metrics - populated by XSOARValueMetrics

Setup and Use

After installing this content pack, setup the XSOAR Value Metrics dashboard as follows:

  • Run the XSOARValueMetrics automation in the playground and identify the incident types found
  • Create the IncidentEffort XSOAR list (default list name) and provide the manual and automated effort to respond estimates for each incident type
  • Review the XSOAR Value Metrics dashboard

The XSOARValueMetrics automation is executed periodically to collect incident statistics, monthly or quarterly for example. You may want to wait a month before executing the automation to allow incident closure to occur. For example, for a windows Jan 1st - Mar 31st, execute this automation May 1st. The expected duration of incidents determines if this delay makes sense. If incident open duration is days, then delaying a month may make sense. If incidents are close within a day the are created in XSOAR, then executing this on April 1st for a Q1 window is reasonable.

XSOAR Lists Used

The dashboard and widgets can be customized and extended by using additional lists as needed. The XSOARValueMetrics automation and the XSOAR Value Metrics dashboard by default are configured to use the following list names:

  • IncidentEffort
  • MetricsThisYear
  • MetricsLastYear

Incident Effort XSOAR List

The incident effort list is a JSON dictonary with two values for each XSOAR incident type with a format of: incident_type_name: [Manual_effort, Automated_effort]

  • Manual_effort: average analyst minutes per incident if the incident is responded to without XSOAR
  • Automated_effort: average analyst minutes per incident if the incident is responded to with XSOAR

Example:

    {
        "Malware": [20, 2],
        "CloudAccess": [10, 0],
        "Phishing": [45, 7]
    }

This Years Metric and Last Years Metric XSOAR Lists

The XSOARValueMetrics automation updates JSON dictionaries stored in these lists containing the monthly metrics collected. The dashboard widgets pull data from these lists for display.

Example:

    {
        "YEAR": "2023", 
        "Incidents": {
            "TestMalware": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "672", "Dec": "455"}, 
            "CloudAccess": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "1", "Dec": "0"} 
        }, 
        "Closed Incidents": {
            "TestMalware": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "672", "Dec": "60"}, 
            "CloudAccess": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "0", "Dec": "0"} 
        }, 
        "Incident Open Duration": {
            "TestMalware": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "2849292", "Dec": "8166"}, 
            "CloudAccess": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "0", "Dec": "0"} 
        }, 
        "SLA Metrics": {
            "contime": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "0", "Dec": "0"}, 
            "dettime": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "0", "Dec": "0"}, 
            "remtime": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "0", "Dec": "0"}, 
            "asstime": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "28", "Dec": "36"}, 
            "tritime": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "0", "Dec": "0"}
        }
    }

Automations

XSOARValueMetrics

This automation collects 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 annual data for:

  • All Incidents
  • Closed Incidents
  • Open Duration
  • SLA Timer Durations

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.

Inputs
  • firstday - required argument to set the start day for searching incidents

Example:
firstday=2024-01-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:
    • increment
    • noupdate
    • initialize

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 thats support 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 any 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 to 4 hours

XMetrics

Dashboard widget script that presents monthly values over the year from the metrics list

Inputs
  • listname - the XSOAR list with stored metrics for the year
  • efflistname - XSOAR incident effort list with manual and automated effort estimates by incident type
  • metrictype - type of metric to display in the dashboard widget
    • SLA Metrics
    • Closed Incidents
    • Incidents
    • Incident Open Duration
    • Effort Reduction

Example:
XMetrics listname=MetricsThisYear efflistname=IncidentEffort metrictype="SLA Metrics"

XMetricsTotal

Dashboard widget script that presents annual totals over the current year from the metrics list

Inputs
  • listname - the XSOAR metrics list with stored metrics for the year
  • efflistname - XSOAR incident effort list with manual and automated effort estimates by incident type
  • metrictype - type of metric to display in the dashboard widget
    • SLA Metrics
    • Closed Incidents
    • Incidents
    • Incident Open Duration
    • Effort Reduction

Example:
XMetricsTotal listname=MetricsThisYear efflistname=IncidentEffort metrictype="Effort Reduction"

XMetricsYear

Dashboard widget script that reads the year from a metric list

Inputs
  • listname - the XSOAR metrics list with stored metrics for the year

Example:
XMetricsYear listname=MetricsLastYear

Community Common Dashboards

This content pack contains two dashboards:

  • CISO Metrics
  • XSOAR Value Metrics

CISO Metrics Dashboard

This dashboard uses OOTB widgets configured to present a consistent overview of XSOAR operation.

XSOAR Value Metrics Dashboard

This dashboard provides XSOAR value metrics for the XSOAR implementation:

  • Time to respond to alerts
  • Cost to respond to alerts

Time to respond metrics are measured by overall incident duration and SLA timers that have been implemented. Cost to respond 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 alerts and the relative costs of handling different types of alerts factor into the overall cost to respond. An automation is ran periodically to collect incident statistics and stores the results in XSOAR lists. This allows monitoring metrics over years without the requirement of incidents being retained - for long term trending within the XSOAR console. The automation manages the current year metrics and previous year metrics. Dashboard widgets retreive data from these lists for display. Additional functionality is available through adding lists and customization of the automation and script arguments to use these lists.

There are three XSOAR lists used by the automations and dashboard:

  • Incident effort - user provided estimates for each incident type
  • This year metrics - populated by XSOARValueMetrics
  • Last year metrics - populated by XSOARValueMetrics

Setup and Use

After installing this content pack, setup the XSOAR Value Metrics dashboard as follows:

  • Run the XSOARValueMetrics automation in the playground and identify the incident types found
  • Create the IncidentEffort XSOAR list (default list name) and provide the manual and automated effort to respond estimates for each incident type
  • Review the XSOAR Value Metrics dashboard

The XSOARValueMetrics automation is executed periodically to collect incident statistics, monthly or quarterly for example. You may want to wait a month before executing the automation to allow incident closure to occur. For example, for a windows Jan 1st - Mar 31st, execute this automation May 1st. The expected duration of incidents determines if this delay makes sense. If incident open duration is days, then delaying a month may make sense. If incidents are close within a day the are created in XSOAR, then executing this on April 1st for a Q1 window is reasonable.

XSOAR Lists Used

The dashboard and widgets can be customized and extended by using additional lists as needed. The XSOARValueMetrics automation and the XSOAR Value Metrics dashboard by default are configured to use the following list names:

  • IncidentEffort
  • MetricsThisYear
  • MetricsLastYear

Incident Effort XSOAR List

The incident effort list is a JSON dictonary with two values for each XSOAR incident type with a format of: incident_type_name: [Manual_effort, Automated_effort]

  • Manual_effort: average analyst minutes per incident if the incident is responded to without XSOAR
  • Automated_effort: average analyst minutes per incident if the incident is responded to with XSOAR

Example:

    {
        "Malware": [20, 2],
        "CloudAccess": [10, 0],
        "Phishing": [45, 7]
    }

This Years Metric and Last Years Metric XSOAR Lists

The XSOARValueMetrics automation updates JSON dictionaries stored in these lists containing the monthly metrics collected. The dashboard widgets pull data from these lists for display.

Example:

    {
        "YEAR": "2023", 
        "Incidents": {
            "TestMalware": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "672", "Dec": "455"}, 
            "CloudAccess": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "1", "Dec": "0"} 
        }, 
        "Closed Incidents": {
            "TestMalware": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "672", "Dec": "60"}, 
            "CloudAccess": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "0", "Dec": "0"} 
        }, 
        "Incident Open Duration": {
            "TestMalware": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "2849292", "Dec": "8166"}, 
            "CloudAccess": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "0", "Dec": "0"} 
        }, 
        "SLA Metrics": {
            "contime": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "0", "Dec": "0"}, 
            "dettime": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "0", "Dec": "0"}, 
            "remtime": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "0", "Dec": "0"}, 
            "asstime": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "28", "Dec": "36"}, 
            "tritime": {"Jan": "0", "Feb": "0", "Mar": "0", "Apr": "0", "May": "0", "Jun": "0", "Jul": "0", "Aug": "0", "Sep": "0", "Oct": "0", "Nov": "0", "Dec": "0"}
        }
    }

Automations

XSOARValueMetrics

This automation collects 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 annual data for:

  • All Incidents
  • Closed Incidents
  • Open Duration
  • SLA Timer Durations

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.

Inputs
  • firstday - required argument to set the start day for searching incidents

Example:
firstday=2024-01-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:
    • increment
    • noupdate
    • initialize

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 thats support 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 any 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 to 4 hours

XMetrics

Dashboard widget script that presents monthly values over the year from the metrics list

Inputs
  • listname - the XSOAR list with stored metrics for the year
  • efflistname - XSOAR incident effort list with manual and automated effort estimates by incident type
  • metrictype - type of metric to display in the dashboard widget
    • SLA Metrics
    • Closed Incidents
    • Incidents
    • Incident Open Duration
    • Effort Reduction

Example:
XMetrics listname=MetricsThisYear efflistname=IncidentEffort metrictype="SLA Metrics"

XMetricsTotal

Dashboard widget script that presents annual totals over the current year from the metrics list

Inputs
  • listname - the XSOAR metrics list with stored metrics for the year
  • efflistname - XSOAR incident effort list with manual and automated effort estimates by incident type
  • metrictype - type of metric to display in the dashboard widget
    • SLA Metrics
    • Closed Incidents
    • Incidents
    • Incident Open Duration
    • Effort Reduction

Example:
XMetricsTotal listname=MetricsThisYear efflistname=IncidentEffort metrictype="Effort Reduction"

XMetricsYear

Dashboard widget script that reads the year from a metric list

Inputs
  • listname - the XSOAR metrics list with stored metrics for the year

Example:
XMetricsYear listname=MetricsLastYear

PLATFORMS

Cortex XSOARCortex XSIAM

INFO

Supported ByCommunity
CreatedNovember 30, 2023
Last ReleaseNovember 19, 2024
WORKS WITH THE FOLLOWING INTEGRATIONS:

DISCLAIMER
Content packs are licensed by the Publisher identified above and subject to the Publisher’s own licensing terms. Palo Alto Networks is not liable for and does not warrant or support any content pack produced by a third-party Publisher, whether or not such packs are designated as “Palo Alto Networks-certified” or otherwise. For more information, see the Marketplace documentation.