Correlation by Repository and Risk

SPLUNK detection rule by Patrick Bareiss, Splunk · Apache-2.0

This search has been deprecated and updated with Risk Rule for Dev Sec Ops by Repository detection. The following analytic detects by correlating repository and risk score to identify patterns and trends in the data based on the level of risk associated. The analytic adds any null values and calculates the sum of the risk scores for each detection. Then, the analytic captures the source and user information for each detection and sorts the results in ascending order based on the risk score. Finally, the analytic filters the detections with a risk score below 80 and focuses only on high-risk detections.This detection is important because it provides valuable insights into the distribution of high-risk activities across different repositories. It also identifies the most vulnerable repositories that are frequently targeted by potential threats. Additionally, it proactively detects and responds to potential threats, thereby minimizing the impact of attacks and safeguarding critical assets. Finally, it provides a comprehensive view of the risk landscape and helps to make informed decisions to protect the organization's data and infrastructure. False positives might occur so it is important to identify the impact of the attack and prioritize response and mitigation efforts.

name: Correlation by Repository and Risk
id: 8da9fdd9-6a1b-4ae0-8a34-8c25e6be9687
version: 4
creation_date: '2021-09-06'
modification_date: '2026-05-13'
author: Patrick Bareiss, Splunk
status: removed
type: Correlation
description: |-
    This search has been deprecated and updated with Risk Rule for Dev Sec Ops by Repository detection. The following analytic detects by correlating repository and risk score to identify patterns and trends in the data based on the level of risk associated. The analytic adds any null values and calculates the sum of the risk scores for each detection. Then, the analytic captures the source and user information for each detection and sorts the results in ascending order based on the risk score. Finally, the analytic filters the detections with a risk score below 80 and focuses only on high-risk detections.This detection is important because it provides valuable insights into the distribution of high-risk activities across different repositories. It also identifies the most vulnerable repositories that are frequently targeted by potential threats. Additionally, it proactively detects and responds to potential threats, thereby minimizing the impact of attacks and safeguarding critical assets. Finally, it provides a comprehensive view of the risk landscape and helps to make informed decisions to protect the organization's data and infrastructure. False positives might occur so it is important to identify the impact of the attack and prioritize response and mitigation efforts.
data_source: []
search: '`risk_index` | fillnull | stats sum(risk_score) as risk_score values(source) as signals values(user) as user by repository | sort - risk_score | where risk_score > 80 | `correlation_by_repository_and_risk_filter`'
how_to_implement: For Dev Sec Ops POC
known_false_positives: unknown
references: []
tags:
    analytic_story:
        - Dev Sec Ops
    asset_type: AWS Account
    mitre_attack_id:
        - T1204.003
    product:
        - Splunk Enterprise
        - Splunk Enterprise Security
        - Splunk Cloud
    security_domain: network
deprecation_info:
    reason: Detections updated to use the datamodel
    removed_in_version: 5.2.0
    replacement_content:
        - Risk Rule for Dev Sec Ops by Repository

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

0d63f470-9f0a-45ce-a3b1-f93be1b99f80

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion