سالهاست که MITRE ATT&CK تبدیل به زبان مشترک دنیای امنیت شده است. تقریباً در هر SOC، هر گزارش Threat Intelligence، و هر مقاله تحلیلی ردپایی از ATT&CK میبینیم. اما با وجود این محبوبیت، یک واقعیت تلخ وجود داشت که کمتر کسی صریح دربارهاش حرف میزد:
ATT&CK برای Detection Engineerها ابزار ساخت Rule نبود؛ بیشتر یک دایرهالمعارف توصیفی بود.
نسخه ۱۸ ATT&CK این وضعیت را بهصورت ریشهای تغییر داده است. این تغییر فقط اضافهکردن چند فیلد یا مرتبسازی بهتر نیست؛ بلکه یک تغییر فلسفه است:
گذار از «توصیف رفتار دشمن» به «کُدپذیر کردن رفتار در تلهمتری».
در این مقاله سعی میکنم توضیح بدهم که مشکل ATT&CK در نسخههای قبل دقیقاً چه بود
و MITRE در v18 چه کاری کرده که واقعاً مهم است
و اینکه چرا این تغییر برای Detection Engineering، UEBA و پلتفرمهایی مثل SIEM و SOAR حیاتی است
همچنین چطور میتوان از این مدل جدید در عمل ستفاده کرد
مشکل اصلی ATT&CK قدیمی: متن بدون اجرا
اگر تجربه نوشتن Rule یا Query داشته باشید، حتماً این سناریو را دیدهاید:
میرویم سراغ یک Technique مثلاً:
T1053 – Scheduled Task/Job
در بخش Detection میخوانید چیزی شبیه به این:
> Monitor for suspicious creation of scheduled tasks or jobs.
از نظر مفهومی درست است. اما از نظر مهندسی تشخیص، تقریباً بیارزش میباشد
چون Detection Engineer باید خودش به دهها سؤال جواب بدهد:
- “suspicious” یعنی دقیقاً چه؟
- آیا همه Scheduled Taskها مشکوکاند؟
- Task ساختهشده با cmd.exe؟ PowerShell؟ WMI؟ API؟
- در چه بازه زمانی؟
- روی چه endpointهایی؟
- با چه Contextی از User؟
لذا در این شرایط و در نهایت چه اتفاقی میافتاد؟
- یا یک Rule خیلی Broad مینوشتیم با False Positive بالا
- یا یک Rule خیلی Specificو قابل bypass توسط مهاجم
- یا کلاً بیخیال Detection میشدیم در آنجا
ATT&CK حمله را خوب توصیف میکرد، اما در مورد چگونه شکار کردنش بیانی نداشت .
نسخه v18: تغییر از «توصیف» به «Blueprint»
MITRE در نسخه ۱۸ تصمیم گرفت این شکاف را پر کند. نتیجه، معرفی دو مفهوم کلیدی است:
1. Detection Strategies
2. Analytics
این دو مفهوم، ستون فقرات ATT&CK v18 هستند.
Detection Strategy: «چه نوع توری میاندازم؟»
Detection Strategy میگوید که من بهصورت مفهومی دنبال چه نوع رفتاری هستم؟
مثال:
- Detect persistence via system utility abuse
- Detect credential access via memory inspection
- Detect lateral movement via remote service execution
نکته مهم این است که Strategy وابسته به ابزار یا لاگ خاصی نیست.
این سطح، همان جایی است که Detection با Threat Intel همراستا میشود.
Strategy کمک میکند بفهمیم:
- آیا Coverage ما کامل است یا نه؟
- کدام نوع حمله را اصلاً نداریم؟
- آیا فقط روی Initial Access تمرکز کردهایم و Lateral Movement خالی است؟
و Analytics: جایی که Detection واقعاً شروع میشود
تغییر اصلی v18 در Analytics است.
یک منطق شبهکدی مشخص که نشان میدهد این رفتار در داده چگونه دیده میشود
بهجای:
> “Monitor for LSASS dumping”
این کار را میکنیم
> Alert when a process opens a handle to lsass.exe with PROCESS_VM_READ access, excluding known benign processes.
پس ما چه داریم ؟
- Object مشخص است (lsass.exe)
- Operation مشخص است (Open Handle)
- Permission مشخص است
- Exceptionها هم مشخص شدهاند
این دیگر «متن» نیست؛ Blueprint مهندسی تشخیص است.
حالا بیاین بررسی کنیم چرا این تفاوت مهم است؟
چون Analytics:
- وابسته به اسم ابزار نیست و به نیت دشمن (Intent) توجه دارد نه تکنیک ظاهری ومستقیماً قابل ترجمه به Query یا Rule است
مهاجم میتواند:
- schtasks.exe را rename کند
- از PowerShell استفاده نکند
- از API مستقیم بهره ببرد
ولی:
> برای Dump کردن credential، همچنان باید به حافظه LSASS دست بزند
و Analytics دقیقاً دنبال همین رفتار بنیادی است.
شکستن Monolithها: PowerShell دیگر یک Rule نیست
در ATT&CK قدیمی، تکنیکهایی مثل PowerShell یا Windows Command Shell عملاً Monolithic بودند:
- یا Detect میکردید و یا نمیکردید
در v18، همین تکنیکها به چند Analytic مجزا شکسته میشوند:
- Encoded Command Execution
- Download Cradle
- Script-based Discovery
- Lateral Movement via PowerShell Remoting
پس نتیجه چیه ؟
Detection دقیقتر و نویز کمتر و تیونینگ منطقی تر
مثال عملی: Lateral Movement از دید v17 vs v18
نگاه قدیمی (v17)
Technique: T1021.002 – SMB/Windows Admin Shares
Detection Guidance:
> Monitor for account login activity related to admin shares.
نتیجه در عمل؟
- هزاران Event که بدون Contextو بدون اولویتبندی
و اما نگاه جدید (v18)
Detection Strategy:
> Detect Remote Service Execution
Analytics:
- Process Create where ParentImage = services.exe
- CommandLine contains references to admin shares (C$, IPC$)
- Correlate with prior authentication from remote host
اینجا:
- ما فقط SMB را نمیبینیم
- رفتار اجرای سرویس از راه دور را میبینیم
- Context زمانی و Parent Process داریم
لذا برای ما این Detection:
- دقیقتر است
- Correlation-friendly است
- برای SIEM و UEBA ایدهآل است
از Single Event به Behavioral Correlation
یکی از بزرگترین مزایای Analyticsهای v18 این است که:
> بهصورت ذاتی برای Correlation طراحی شدهاند یعنی شما میتوانید:
- یک Analytic برای Persistence
- یک Analytic برای Credential Access
- یک Analytic برای Lateral Movement
و بعد آنها را در یک multi-stage rule کنار هم بگذارید.
مثال:
1. Scheduled Task Creation (Persistence)
2. Access to LSASS memory (Credential Access)
3. Remote Service Execution (Lateral Movement)
این دیگر Alert نیست؛ Attack Story است.
ارتباط مستقیم با SIEM، UEBA و SOAR
ATT&CK v18 عملاً Detection Engineering را به دنیای:
- Risk-Based Alerting
- UEBA
- SOAR Playbookها
وصل میکند.
برای اینکه
- هر Analytic یک سیگنال با Fidelity مشخص است
- SIEM میتواند آن را Scoring کند
- UEBA میتواند آن را در Risk Profile کاربر یا Asset لحاظ کند
- SOAR میتواند بر اساس نوع Analytic Playbook درست اجرا کند
چرا این نسخه برای سازمانهای بالغ حیاتی است؟
اگر سازمان در این مرحله است: نشان از این است که سازمان لاگ دارد، ولی Signal کم دارد
و SOC از Alert خسته شده و Detection Ruleها brittle هستند
همچنین Coverage روی کاغذ خوب است، ولی در عمل ضعیف
ATT&CK v18 دقیقاً آن «لایه گمشده» را میآورد:
> تبدیل Threat Model به Detection Model قابل اجرا
محدودیتها
ATT&CK v18 معجزه نیست باید دقت کنیم که
- Analytics بدون Telemetry مناسب بیفایدهاند
- Endpoint Visibility، Identity Context و Network Data حیاتی است
- Tuning هنوز لازم است
- Blind Spotها همچنان وجود دارند
اما تفاوت اینجاست:
> حالا مشکل از مدل نیست، از پیادهسازی است و این پیشرفت بزرگی است.
