Tuning Hygiene

Tuning hygiene names false-positive control, exclusions, testing, and change tickets — document tuning plan on YOUR $SOC_LAB rule sketch only.

Tuning Hygiene• Audio Walkthrough

00:00/03:19

Visual · t29_tuning_hygiene

Rule tuning literacy. $SOC_LAB only. Original Cyberlium.

Every untuned rule eats L1 sleep — literacy names exclusions and test plans before production noise.

Tuning reduces false positives: service account exclusions, maintenance window suppressions, geo allowlists, threshold adjustments, and enrichment requirements. Change control means ticket, peer review, rollback plan, and measure alert volume before/after — practiced as paperwork on lab rules. Cyberlium writes tuning plan for YOUR $SOC_LAB brute-force sketch — fictional service accounts and maintenance windows. Next: Rules Lab.

1. Tuning techniques (named)

Exclusions: known scan accounts, vulnerability scanners with ticket ID. Threshold tweaks: raise count or widen window after baseline. Enrichment gates: alert only if also proxy deny. Suppression: change window with documented end time.

On $SOC_LAB, list two exclusions you would document for noisy auth rule on sample data.

Command guide

Try these commands — Tuning techniques (named)

═══ LINUX / BASH (SOC Analyst Triage) ═══

Filter system logs for security-relevant warnings and errors

Command — copy this

journalctl -p 3 -xb --no-pager | head -20

Search for suspicious persistent cron entries or service changes

Command — copy this

ls -lat /etc/cron.* /etc/systemd/system/ | head -15

═══ WINDOWS POWERSHELL ═══ Triage recent system service installations (Event 7045)

Command — copy this

Get-WinEvent -FilterHashtable @{LogName='System';Id=7045} -MaxEvents 5 -ErrorAction SilentlyContinue | Format-Table TimeCreated, Message -Wrap

Check open listening network connections with process owners

Command — copy this

Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess | Sort-Object LocalPort

Primary tools to practice this lesson: grep, python3. Reference sites: Sigma false positives (https://github.com/SigmaHQ/sigma/wiki/Rule-Creation-Guide); MITRE T1110 (https://attack.mitre.org/techniques/T1110/); NIST detection (https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.

2. Why tuning is a team sport

L1 feedback feeds L2 rule owners. Untuned brute-force rules fire on every password typo Monday morning. Document who approved exclusion and when it expires.

Defenders track alert KPIs — students write before/after hypothesis on lab paperwork.

3. Literacy ≠ silent prod changes

Forbidden: editing production rules without ticket or peer review. Allowed: tuning plan — two exclusions, one threshold change, test checklist, $SOC_LAB rule reference.

Ship: tuning plan for YOUR lab rule sketch. Next: Rules Lab.

4. What you ship: tuning plan for $SOC_LAB rule sketch

Exclusions, threshold note, test checklist. $SOC_LAB named. NO silent prod edits. chmod 600.

5. What you record before the next lesson

Date. Tuning plan. $SOC_LAB named. File t29-m05-l03-tuning-hygiene.txt chmod 600.

6. Wrong vs right: stranger SIEM vs YOUR sample logs

Worked failure — same MSF word, opposite target. Right never needs a café Wi-Fi or classmate laptop.

Wrong: Disable rule in production without ticket because noisy. Add permanent exclusion without expiry review.
Right: Write tuning plan for YOUR $SOC_LAB rule sketch. Next: Rules Lab.

Hands-on Exercise