Skip to content

Instantly share code, notes, and snippets.

View brandonwmichael's full-sized avatar

Brandon Michael brandonwmichael

View GitHub Profile

Style Guide for Community Rules

Detection rules for Google Security Operations are written in the YARA-L language.

This style guide establishes baseline standards of quality, completeness, readability, and extensibility for community rules in this project. This guide also sets an example for what high quality rules look like and what components detection engineers should include in their own rules.

YARA-Style-Guide

A specification and style guide for YARA rules

Introduction

YARA is a powerful and versatile tool for malware detection, used by security researchers and analysts all over the world. YARA rules are at the heart of this tool, providing a structured way to identify and classify malware based on various characteristics such as file names, sizes, and contents.

Creating effective YARA rules is not an easy task, and it requires a deep understanding of the malware landscape, as well as knowledge of YARA's syntax and capabilities. To help security professionals create high-quality and efficient YARA rules, we have created this style guide.

This guide will cover the best practices for YARA rule structure and contents, including recommendations for naming conventions, syntax, and content selection. By following these guidelines, you will be able to create YARA rules that are accurate, concise, and easy to read and maintain.

Style Guide for Community Rules

Detection rules for Google Security Operations are written in the YARA-L language.

This style guide establishes baseline standards of quality, completeness, readability, and extensibility for community rules in this project. This guide also sets an example for what high quality rules look like and what components detection engineers should include in their own rules.

Overview of the YARA-L 2.0 language

Supported in:

Google secops Siem

YARA-L 2.0 is a computer language used to create rules for searching through your enterprise log data as it is ingested into your Google Security Operations instance. The YARA-L syntax is derived from the YARA language developed by VirusTotal. The language works in conjunction with the Google SecOps Detection Engine and enables you to hunt for threats and other events across large volumes of data.

Detection Strategy Overview

This document outlines the organization's high-level strategy for security detection development, key platforms, focus areas, and how AI agents contribute to and are measured within this strategy.

Purpose

  • To define a clear and consistent approach to threat detection.
  • To guide the efforts of the Detection Engineering team and AI agents involved in detection tasks.
  • To align detection efforts with organizational risk, threat intelligence, and compliance requirements.
  • To support the "Preparation" phase of the PICERL AI Performance Framework.

Persona: Cyber Threat Intelligence (CTI) Researcher

Overview

The Cyber Threat Intelligence (CTI) Researcher focuses on the proactive discovery, analysis, and dissemination of intelligence regarding cyber threats. They delve deep into threat actors, malware families, campaigns, vulnerabilities, and Tactics, Techniques, and Procedures (TTPs) to understand the evolving threat landscape. Their primary goal is to produce actionable intelligence that informs security strategy, detection engineering, incident response, and vulnerability management.

Responsibilities

  • Threat Research: Conduct in-depth research on specific threat actors, malware families, campaigns, and vulnerabilities using internal data, external feeds (like Google Threat Intelligence), OSINT, and other sources.
  • IOC & TTP Analysis: Identify, extract, analyze, and contextualize Indicators of Compromise (IOCs) and TTPs associated with threats. Map findings to frameworks like MITRE ATT&CK.

When alerts originate from the Cortex XDR Agent, performing alert tuning for false positives involves several options, particularly concerning the analytics engine and related behavioral detections. It is crucial to undertake alert tuning only when you are 100% sure the alert is a false positive or pertains to a legitimate action within your environment. Fine-tuning is not appropriate for true positives, which would require remediation.

Here are your options to "train" the analytics engine to stop generating false positive alerts, along with other tuning actions for informational alerts:

Training the Analytics Engine (Feedback Mechanisms)

The term "training" for the analytics engine primarily refers to feedback mechanisms that can influence its future behavior:

  • Resolve False Positive Analytics Incidents:
  • Properly resolving an Analytics incident as a "False Positive" provides valuable feedback to Palo Alto Networks' Unit 42 and the analytics team.

Cortex XDR consolidates alerts from various sources to provide a comprehensive view of security risks within your environment. The alerts can originate from Palo Alto Networks products acting as sensors, third-party integrations, or rules defined within Cortex XDR itself.

Here are the primary sources that generate alerts in Cortex XDR, along with a description of each:

  • XDR Agent Alerts
  • These alerts are generated directly from the Cortex XDR agent based on endpoint profile policy and configurations. When an alert is triggered due to endpoint activity, a minimum set of metadata is sent to the server. With Behavioral Threat Protection (BTP) or Endpoint Detection and Response (EDR) data collection enabled, the agent continuously monitors endpoint activity for malicious event chains identified by Palo Alto Networks. Alerts from the XDR Agent can fall into categories such as Malware (including WildFire, Local Analysis, Child Process, Ransomware, and Here After Protection alerts) and **

When an alert originates from the Cortex XDR Agent, a systematic approach to triage and escalation is essential to ensure effective security operations. This process involves initial review, specific tuning actions based on alert type (especially for false positives or legitimate activity), and formal escalation to technical support when necessary.

I. Triage Steps for XDR Agent Alerts

Upon receiving an alert from the XDR Agent, the initial steps focus on understanding the alert's context and determining its legitimacy.

  1. Review Alert Details:
    • Access the Alerts page (Incident Response → Incidents → Alerts Table).
    • Examine the command-line arguments (CMD), process info, and other data provided within the alert. The alert side panel provides quick details.
  • Identify the Alert Name, Category, Action (Detected or Prevented), Severity, and the Protection Module that triggered the alert. This information is crucial as recommended ac