MITRE D3FEND در عمل؛ از تکنیک مهاجم به کانترمژر دفاعی و پیاده‌سازی روی استک
MITRE D3FEND چیست و چطور با ATT&CK ارتباط دارد؟ معرفی دسته‌ها و ساختار artifact، روش گام‌به‌گام مپ کردن تکنیک حمله به کانترمژر، چهار نمونه پیاده‌سازی عملی و چکلیست ارزیابی استک.
MITRE D3FEND چیست؟
MITRE ATT&CK رفتار مهاجم را می‌شمارد: تکنیک‌ها، تاکتیک‌ها، ساب‌تکنیک‌ها. اما برای «کار دفاعی» ما معمولاً چیزی به همین شفافیت نداریم. D3FEND (Detection, Denial and Disruption Framework Empowering Network Defense) همان کار را برای دفاع انجام می‌دهد: یک گراف دانش از کانترمژرهای دفاعی، با ساختار رسمی و رابطه‌های معنایی.
نکته کلیدی D3FEND این است که این چارچوب، یک **ontolog** یعنی یک مدل مفهومی از «digital artifact» هاست. هر تکنیک دفاعی مشخص می‌کند روی کدام artifact کار می‌کند (فایل، ترافیک شبکه، lookup دامنه، credential و...) و هر تکنیک مهاجم هم مشخص می‌کند کدام artifact را تولید یا دستکاری می‌کند. این مشترک بودن artifact است که ارتباط دو طرفه را ممکن می‌کند، نه یک جدول دست‌نویس.
## ATT&CK در مقابل D3FEND
| بعد | ATT&CK | D3FEND |
|---|---|---|
| مخاطب | رفتار مهاجم | کانترمژر دفاعی |
| سؤال | مهاجم چه می‌کند؟ | دفاع چه می‌تواند بکند؟ |
| خروجی | تکنیک + تاکتیک + داده‌های توصیفی | تکنیک + artifact + رابطه |
| نوع رابطه | tactics → techniques | techniques → artifacts → relations |
| کاربرد | coverage، gap analysis | انتخاب و ارزیابی کنترل |
دقت کنید: D3FEND به طور پیش‌فرض یک رابطه یک‌به‌یک از «تکنیک حمله» به «کانترمژر» نمی‌دهد. رابطه از طریق artifact استنتاج می‌شود. مثلاً تکنیک اسکن فعال (T1595) ترافیک شبکه ورودی تولید می‌کند؛ هر کانترمژری که روی همان artifact کار کند (Inbound Traffic Filtering) با آن رابطه می‌یابد.
## دسته‌های اصلی D3FEND
چارچوب فعلی این دسته‌ها را پوشش می‌دهد:
- **Model:** مدل‌سازی دارایی، شبکه و وابستگی‌ها (مثلاً Asset Inventory)
- **Harden:** کاهش سطح حمله قبل از تماس (Application Configuration Hardening، Credential Hardening)
- **Detect:** شناسایی فعالیت جاری (File Analysis، DNS Traffic Analysis، Network Traffic Analysis)
- **Isolate:** محدود کردن دسترسی مهاجم پس از ورود (Executable Allowlisting، DNS Allowlisting، Network Traffic Filtering)
- **Deceive:** محیط غیرواقعی برای آشکارسازی و مهار (Decoy Environment، Decoy File، Decoy User Credential)
- **Evict:** حذف فعالیت مخرب پس از تشخیص
- **Restore:** بازیابی به حالت عادی
## ساختار یک گره D3FEND
هر تکنیک با شناسه D3-XXX شناخته می‌شود، مثلاً:
| شناسه | نام | دسته | artifact |
|---|---|---|---|
| D3-FA | File Analysis | Detect | File |
| D3-DNSTA | DNS Traffic Analysis | Detect | DNS Lookup |
| D3-EAL | Executable Allowlisting | Isolate | File / Process |
| D3-MFA | Multi-factor Authentication | Harden | Credential |
| D3-EF | Email Filtering | Isolate | Email |
| D3-DF | Decoy File | Deceive | File |
این ساختار به شما اجازه می‌دهد دقیقاً مشخص کنید کنترل‌تان روی کدام artifact کار می‌کند و چه رابطه‌ای با تکنیک مهاجم دارد.
## روش گام‌به‌گام مپ کردن تکنیک مهاجم به D3FEND
1. تکنیک مهاجم را انتخاب کنید (مثلاً T1071.004 – Application Layer Protocol: DNS).
2. artifact تولیدشده یا دستکاری‌شده را مشخص کنید: DNS Lookup / Network Traffic.
3. کانترمژرهایی که همان artifact را تحلیل، فیلتر یا محدود می‌کنند بیابید: D3-DNSTA (تحلیل)، D3-DNSAL/D3-DNSDLD (فیلتر)، D3-NTF (ترافیک).
4. کنترل واقعی خودتان را با آن گره matched کنید و سطح پیاده‌سازی را مشخص کنید.
سه مپ کاربردی:
| تکنیک ATT&CK | artifact مرتبط | کانترمژرهای D3FEND |
|---|---|---|
| T1110 – Brute Force | Credential | D3-MFA، D3-CRO (Credential Rotation)، D3-CH (Credential Hardening) |
| T1566 – Phishing | Email / URL | D3-EF (Email Filtering)، D3-UA (URL Analysis)، D3-HD (Homoglyph Detection) |
| T1059.001 – PowerShell | Process / File | Dynamic Analysis، Executable Allowlisting، Decoy File |
توجه: فهرست بالا از روی artifact استخراج شده، نه یک جدول دستی. همیشه artifact را اول مشخص کنید تا نتیجه درست بیرون بیاید.
## پیاده‌سازی روی استک خودتان: چهار نمونه عملی
**1. DNS Traffic Analysis (D3-DNSTA)**
لاگ DNS را جمع‌آوری و روی الگوهای مشکوک فیلتر کنید. روی لینوکس:
```bash
# جمع‌آوری DNS از Zeek یا حتی یک عامل ساده
# هشدار روی queryهای خیلی بلند یا TXT رکوردهای مشکوک
awk '$8 == "TXT" || length($9) > 60 { print $1, $9 }' dns.log | tee /var/log/dns-suspicious.log
```
خروجی را به SIEM ببرید و برای rcount بالا در یک پنجره زمانی، هشدار بسازید.
**2. Multi-factor Authentication (D3-MFA)**
ساده‌ترین و مؤثرترین کنترل در برابر credential-based attack. برای پنل‌ها و دسترسی‌های مدیریتی، TOTP یا WebAuthn اجباری کنید. این کنترل را در ماتریس خود به‌عنوان Harden ثبت کنید.
**3. Executable Allowlisting (D3-EAL)**
روی سرورهای production فقط ابزارهای مورد نیاز را نصب کنید و اجرای فایل‌های جدید را محدود کنید. در سطح Docker می‌توانید با قیدهای امنیتی اجرا را محدود کنید:
```yaml
services:
app:
image: nginx:1.27
security_opt:
- no-new-privileges:true
cap_drop:
- ALL
cap_add:
- NET_BIND_SERVICE
read_only: true
tmpfs:
- /tmp
```
**4. Decoy User Credential (D3-DUC)**
یک اکانت دروغین با نام جذاب (مثلاً `backup_admin` یا `svc_sql`) در دامنه یا روی سرور بسازید، هیچ سرویسی به آن وصل نیست و هر فعالیت با آن باید **صفر** باشد. اولین ورود یا تلاش برای احراز هویت، یک هشدار قطعی است.
## محدودیت‌ها و نکات منفی D3FEND
- **پوشش ناقص:** تعداد زیادی از تکنیک‌ها در حوزه ICS هستند و برای محیط IT عمومی کم‌کاربرد.
- **هیچ تضمینی برای کارایی نمی‌دهد:** وجود کانترمژر در ماتریس به معنای مؤثر بودنش نیست. این ماتریس یک فهرست گزینه‌هاست، نه یک استاندارد پیاده‌سازی.
- **جایگزین مهندسی نیست:** D3FEND به شما می‌گوید کنترل چه نقشی دارد؛ اینکه چقدر خوب پیاده شده، بر عهده خودتان است.
- **کاربرد واقعی:** D3FEND زمانی ارزش دارد که آن را به پروژه تبدیل کنید (مثلاً «هر تکنیکی که در coverage ما پوشش‌داده‌نشده، اول یک کانترمژر D3FEND معادل برایش تعریف کنیم»).
## چکلیست ارزیابی استک با D3FEND
1. لیست کانترمژرهای فعلی (MFA، filter، isolation، deception) را بنویسید.
2. هر کدام را با گره D3FEND نام‌گذاری کنید.
3. پوشش را در برابر تکنیک‌های ATT&CK خودتان بسنجید: کدام artifact ها بدون هیچ کانترمژری رها هستند؟
4. برای هر artifact بدون پوشش، یک کنترل عملی انتخاب و پیاده کنید.
5. نتیجه را در داشبورد coverage خود ثبت کنید و هر فصل مرور کنید.
اگر تازه شروع کرده‌اید، ترتیب پیشنهادی من این است: اول Isolate و Harden برای کاهش فوری ریسک، بعد Detect برای دیدن آنچه از دست رفته، و Deceive در مرحله سوم وقتی پایه‌ها درست شده‌اند.
---
*Published: 2026-10-19 | Category: Defensive Security | Author: Alireza Abedi*