YARA Style Guide: Comprehensive Best Practices for Naming, Structuring and Maintaining Detection Rules

Florian Roth’s YARA Style Guide has been translated and adapted by security specialist Maxim Motikov of the Russian company Garda to help teams maintain large, consistent collections of detection rules. The guide addresses the common problem that YARA lacks a strict naming or formatting standard, causing rulebases to become disorganized over time.

Rule Naming Conventions

Rule names should combine threat category, context, target platform and creation date so that analysts can understand the purpose of a rule without opening the file. Recommended category prefixes include MAL for malware, HKTL for hacktools, WEBSHELL, EXPL for exploits, VULN for vulnerabilities, SUSP for suspicious patterns and PUA for potentially unwanted applications.

Context tags such as APT, CRIME, RANSOM and ANOMALY can be added, followed by malware type indicators like RAT, Implant, Stealer, Loader or Crypter. Platform and technology suffixes cover operating systems (WIN, LNX, MacOS), architectures (X64, X86, ARM) and file formats or languages (PE, ELF, PS1, VBS, JS, NET, Go, Rust, PHP and others).

Packers such as UPX, Themida and NSIS should be noted when relevant, and specific threat actor or family names (Lazarus, CozyBear, CobaltStrike, PlugX, QakBot) are written in full. Unique suffixes such as May23 or _1 help prevent naming collisions.

Rule Structure and Metadata

Every rule follows a consistent layout with meta, strings and condition sections. Mandatory metadata fields are description (starting with “Detects …”), author, reference and date in YYYY-MM-DD format. Optional but recommended fields include score (0–100), hash (preferably SHA256), modified date and license.

The score helps prioritize alerts: values above 85 indicate high-confidence detections, while lower scores flag generic or low-severity indicators. Additional tags can be stored in a dedicated meta field when they are not central enough for the rule name.

String Organization and Readability

Strings are categorized into three groups: high-specificity strings prefixed with $x*, group strings prefixed with $s* and preliminary filter strings prefixed with $a*. False-positive indicators receive the $fp* prefix so that matches on legitimate patterns can suppress alerts.

Hexadecimal byte sequences should be accompanied by ASCII comments when possible, and long values may be split into 16-byte segments. Simple text strings must never be written as hex unless they contain control characters.

Condition Formatting

Conditions should follow a logical order: header checks, file-size limitations, other constraints, string combinations and finally false-positive filters. Each “and” clause is placed on a new line, and “or” groups are indented for clarity.

By adopting these conventions, teams can create self-documenting rules that remain understandable months or years after creation and reduce the time required to triage large numbers of alerts.