الفرق الزرقاء — الدفاعخبير110mL57

Detection Engineering — تكتب Detection بتشتغل فعلاً

Sigma و KQL و Splunk — تقلّل false positives وتغطّي ATT&CK

#SIEM#Sigma#KQL#Splunk#Detection

Detection Engineer vs SOC Analyst — مين بيشتغل ايه؟

تشبيه — شرح مبسط
الـ Analyst هو الحارس اللي بيرد على الجرس. الـ Detection Engineer هو اللي بيصمّم نظام الإنذار نفسه: الجرس بيطن إمتى، بيفضل ساكت إمتى، أنهي حتة محتاجة كاميرا زيادة.

- طب يا حضرتك، أنا analyst كويس، يعني أنا detection engineer برضو؟؟

لأ يا مستجد. كنت متوقّع كالعادة في السؤال ده. السؤال عند الـ engineer مش "المهاجم جوّه؟". السؤال "لو دخل النهارده، هشوفه؟". الفرق دقيق بس بيفرّق بين blue team محترم وبين dashboard شغّال.

طب لو الـ Analyst بس عندك، انت مش بتراقب — انت بتـ react. الـ adversary لو عرف انت بتراقب ايه (وده سهل يعرفه)، هيدخل من اللي مش بتراقبه. الـ Detection Engineering بتقفل السكة دي: تكتب rules، تختبرها بـ Atomic Red Team، تقيس coverage على ATT&CK، وتـ tune عشان تقلّل الـ FP من غير ما تفقد الـ TP. ده الفرق بين blue team محترم وبين SOC شغّال على alerts الـ vendor الافتراضية.

دورة حياة قاعدة الكشف — من الفكرة لحد الـ runbook

01
Hypothesis — افتراض محدد
"المهاجم بيفرّغ LSASS عن طريق comsvcs.dll" — جملة واضحة و مربوطة بـ ATT&CK technique (T1003.001).
02
Data Source — مصدر البيانات
أنهي log هيكشف ده؟ Sysmon Event ID 10 (Process Access). أكّد إنه مفعّل فعلاً و بيوصل للـ SIEM. مفيش data = مفيش detection.
03
Detection Logic — منطق الكشف
اكتب الـ query في الـ SIEM. ابدأ واسع، و ضيّق حسب الـ noise.
04
Validation — اختبار حقيقي
جرّب بـ Atomic Red Team أو CALDERA. قاعدة مش بتطن على هجوم فعلي = قاعدة ميتة.
05
Tuning — التهدئة
راقب الـ FP rate أسبوع. لو عدّت 5/اليوم، ضيّق الـ context filter.
06
Documentation — توثيق
سجّل ATT&CK ID، الافتراضات، الـ FPs المعروفة، و runbook للرد. قاعدة من غير runbook = ملهاش لازمة.

Sigma — لغة قواعد الكشف الموحدة

Sigma هو YAML format مش مرتبط بأي SIEM. اكتب القاعدة مرة، و ترجمها لـ Splunk SPL أو KQL أو Elasticsearch عن طريق sigmac. توفير وقت و عقل.

yaml
title: LSASS Memory Dump via comsvcs.dll
id: a8e2d456-1234-5678-9abc-def012345678
status: stable
description: Detects MiniDump of LSASS using rundll32 and comsvcs.dll
references:
  - https://attack.mitre.org/techniques/T1003/001/
author: Detection Eng Team
date: 2026/01/15
tags:
  - attack.credential_access
  - attack.t1003.001
logsource:
  product: windows
  service: sysmon
detection:
  selection_proc:
    EventID: 10
    TargetImage|endswith: '\lsass.exe'
  selection_caller:
    SourceImage|endswith: '\rundll32.exe'
    CallTrace|contains: 'comsvcs.dll'
  condition: selection_proc and selection_caller
falsepositives:
  - Microsoft tools that legitimately call MiniDumpWriteDump (rare)
level: high

KQL — Microsoft Defender / Sentinel

kusto
// Same hypothesis in KQL against DeviceProcessEvents
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName == "rundll32.exe"
| where ProcessCommandLine has_all ("comsvcs.dll", "MiniDump")
| where ProcessCommandLine has "lsass" or ProcessCommandLine matches regex @"\b\d{3,5}\b"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName
| sort by Timestamp desc

// Pivot: who logged on to that host before the dump?
DeviceLogonEvents
| where DeviceName == "WS-EXEC-04"
| where Timestamp between ((ago(2h)) .. (now()))
| project Timestamp, AccountName, LogonType, RemoteIP

Splunk SPL

spl
index=sysmon EventCode=10 TargetImage="*\\lsass.exe"
| where match(SourceImage,"rundll32\.exe")
| where match(CallTrace,"comsvcs\.dll")
| stats count by host, SourceImage, GrantedAccess, _time
| where count > 0

// Hunting variant: any process that accessed LSASS with high rights
index=sysmon EventCode=10 TargetImage="*lsass.exe" GrantedAccess IN (0x1010, 0x1410, 0x1438)
| stats values(SourceImage) as accessors, count by host
| where count > 5

تقليل الـ False Positives — مفيش حد بيسمع جرس بيطن طول الليل

تلات تقنيات أساسية بتفرق:

Process Lineage — السياق
rundll32 اتفتح من cmd في session تفاعلي؟ ده مقلق. لأ، اتفتح من service؟ أهدى بكتير. الفرق في النسب.
Allow-list معروف
ساعات الـ EDR نفسه بيحقن أداة legitimate بتقرا LSASS. حطها في allow-list مع توقيع الناشر. عشان متطنش عبثاً.
Threshold و time-window
أداة admin بتشتغل دفعة بتطلع 50 alert في دقيقة. اجمعهم في incident واحد بدل ما المحلل يتحرق.

قياس التغطية — ATT&CK Navigator

لوّن مصفوفة ATT&CK حسب اللي قواعدك بتكشفه. الناتج = خريطة "أنا شايف إيه" قصاد "المهاجم بيعمل إيه". الفجوة دي بتقولك الأولوية الجاية.

$ # تصدير coverage matrix إلى ATT&CK Navigator JSON
$ python attack-navigator-export.py --rules /detections/*.yml -o coverage.json
Coverage report: TA0001 Initial Access: 17/22 techniques (77%) TA0003 Persistence: 14/19 techniques (73%) TA0006 Credential Access: 9/16 techniques (56%) <-- weak TA0011 Command & Control: 11/16 techniques (68%)
مبادئ مهندس الكشف — ناشفة
  • True Positive Rate أهم من Coverage: قاعدة واحدة شغّالة أحسن من 100 قاعدة بـ 95% FP. الـ analyst اللي بيقفل alerts من تعب = ما عندكش detection.
  • اكشف بالسلوك مش بالـ IoC: الـ hash بيموت في يوم. السلوك بيفضل عايش لأن الـ adversary مش هيغيّر TTP بسهولة.
  • اختبر كل قاعدة: Atomic Red Team أو CALDERA. مش مرة. كل يوم. لو القاعدة وقفت، انت ما عندكش detection للـ technique دي.
  • Versioning في git: قواعدك code. PR review، history، diffs. Detection-as-code.
  • كل alert عنده runbook: الـ analyst بيعمل ايه في أول 5 دقايق؟ لو ما يعرفش، الـ alert راح. SOAR هنا بياخد الـ playbook ويـ enrich automatically.
غلطات الـ junior detection engineer
  • بيكتب rule على string match بسيط من blog post. أول obfuscation بسيطة بتكسرها.
  • بيـ deploy للـ production بدون testing. الـ rule بتولّد 10000 FP في يوم. الـ SOC بيـ disable-ها. القاعدة ماتت.
  • ما بيـ document-ش الـ false positives المعروفة. الـ analyst التاني بيـ investigate نفس الـ FP عشر مرات.
  • بيركّز على coverage. "أنا غطّيت 95% من ATT&CK". 95% من القواعد عنده بـ noise. الـ 5% الباقية بس بتشتغل.

الخلاصة الناشفة

Detection engineering مش "كتابة rules". ده engineering discipline كامل. data sources -> hypothesis -> query -> test -> tune -> runbook -> metrics.

لو ما عندكش CI/CD للـ detections، انت ما عندكش detection engineering. عندك "list of queries". الفرق كبير.

ولو الـ analyst بيـ disable rules بدل ما يـ tune-هم، انت ما عندكش SOC. عندك dashboard.

اكتبها على الحيطة اللي قصاد شاشتك: قاعدة من غير runbook = قاعدة ميتة. وقاعدة بـ 95% FP = قاعدة بتعلّم الـ analyst يقفل عينه.

مصادر للتعمق

  • Sigma Project — github.com/SigmaHQ/sigma
  • Atomic Red Team — Red Canary
  • The DFIR Report — حالات حقيقية + queries جاهزة
  • SpecterOps — Detection Engineering Methodology
  • Florian Roth blog — Sigma و detection engineering