Atomic Red Team و راهنمای جامع برای بهبود SOC

Atomic Red Team چیست؟ راهنمای جامع استفاده از Atomic Testing برای بهبود SOC

مقدمه

در یک تیم امنیتی، داشتن ابزارهایی مانند SIEM، EDR، NDR و سایر راهکارهای امنیتی به‌تنهایی به معنی داشتن یک سیستم دفاعی مؤثر نیست. مسئله مهم‌تر این است که بدانیم این ابزارها در مواجهه با رفتارهای واقعی مهاجم چه عملکردی دارند.

ممکن است یک سازمان صدها Detection Rule در SIEM داشته باشد، اما هیچ‌وقت به‌صورت واقعی بررسی نکرده باشد که آیا این Ruleها در زمان وقوع یک رفتار مشخص توسط مهاجم Trigger می‌شوند یا خیر.

برای مثال، فرض کنید یک Rule برای شناسایی اجرای مشکوک PowerShell در سازمان ایجاد شده است. از نظر تئوری Rule صحیح به نظر می‌رسد، اما چند سؤال مهم همچنان باقی می‌ماند:

آیا Eventهای موردنیاز واقعاً از Endpoint جمع‌آوری می‌شوند؟

آیا Eventها به SIEM منتقل می‌شوند؟

آیا اطلاعات مهمی مانند Command Line در Log وجود دارد؟

آیا Detection Rule می‌تواند رفتار مهاجم را تشخیص دهد؟

آیا EDR قبل از رسیدن Event به SIEM رفتار را Block می‌کند؟

آیا Alert ایجادشده برای Analyst قابل استفاده است؟

و مهم‌تر از همه، اگر Detection کار نکند، مشکل دقیقاً در کدام قسمت قرار دارد؟

Atomic Red Team یکی از ابزارهایی است که به تیم‌های امنیتی کمک می‌کند این سؤالات را به‌صورت عملی پاسخ دهند.

Atomic Red Team مجموعه‌ای از تست‌های کوچک و متمرکز است که برای شبیه‌سازی تکنیک‌های مهاجمان و بررسی قابلیت‌های Detection و Security Controlها طراحی شده است. این تست‌ها با MITRE ATT&CK Mapping شده‌اند و می‌توانند برای Windows، Linux، macOS و برخی سناریوهای دیگر مورد استفاده قرار بگیرند.

هدف اصلی Atomic Red Team اجرای یک حمله کامل نیست؛ بلکه ایجاد یک رفتار مشخص و قابل کنترل از دید مهاجم است تا تیم دفاعی بتواند Telemetry، Detection و Response خود را بررسی کند.

Atomic Red Team چیست؟

Atomic Red Team یک پروژه Open Source است که مجموعه‌ای از تست‌های کوچک برای شبیه‌سازی رفتارهای مرتبط با تکنیک‌های MITRE ATT&CK ارائه می‌کند.

این پروژه توسط Red Canary ایجاد شده و در طول زمان توسط جامعه امنیتی توسعه پیدا کرده است.

ایده اصلی Atomic Red Team بسیار ساده است:

به جای اینکه برای بررسی Detection یک حمله کامل و پیچیده را اجرا کنیم، یک Technique مشخص از MITRE ATT&CK را انتخاب کرده و همان رفتار را به‌صورت کنترل‌شده اجرا می‌کنیم.

به همین دلیل نام Atomic برای این پروژه انتخاب شده است؛ زیرا هر Test معمولاً یک بخش کوچک و مشخص از رفتار مهاجم را شبیه‌سازی می‌کند.

برای مثال، به جای شبیه‌سازی یک حمله کامل از Initial Access تا Lateral Movement و Credential Access، می‌توانیم فقط یک Technique مانند Scheduled Task را آزمایش کنیم و بررسی کنیم که آیا سازمان قادر به مشاهده و شناسایی این رفتار است یا خیر.

Atomic Red Team رسماً به‌عنوان مجموعه‌ای از تست‌های کوچک، قابل حمل و مپ‌شده به MITRE ATT&CK معرفی شده است.

چرا Atomic Red Team اهمیت دارد؟

یکی از مشکلات رایج در Security Operations این است که بسیاری از Detectionها بر اساس فرضیات طراحی می‌شوند.

برای مثال تیم SOC ممکن است تصور کند:

«اگر PowerShell مشکوک اجرا شود، SIEM آن را Detect می‌کند.»

اما این جمله تا زمانی که رفتار واقعی اجرا و نتیجه بررسی نشود، فقط یک فرض است.

Atomic Testing این امکان را ایجاد می‌کند که این فرضیه را به یک آزمایش قابل اندازه‌گیری تبدیل کنیم.

فرآیند به شکل زیر خواهد بود:

MITRE ATT&CK Technique
        ↓
Atomic Test
        ↓
اجرای رفتار
        ↓
تولید Telemetry
        ↓
جمع‌آوری Log
        ↓
SIEM / EDR
        ↓
Detection
        ↓
Alert
        ↓
Investigation

در نتیجه، Atomic Red Team یک حلقه ارتباطی بین فعالیت مهاجم و عملکرد تیم دفاعی ایجاد می‌کند.

Atomic Test چیست؟

Atomic Test یک تست مشخص برای شبیه‌سازی یک رفتار یا Technique است.

هر Technique ممکن است چند Atomic Test مختلف داشته باشد؛ زیرا یک Technique می‌تواند به روش‌های مختلفی اجرا شود.

برای مثال یک Technique ممکن است در Windows چند روش مختلف برای اجرای یک رفتار داشته باشد. Atomic Red Team می‌تواند برای هر یک از این روش‌ها Test جداگانه‌ای ارائه کند.

هر Test معمولاً اطلاعاتی مانند موارد زیر دارد:

• نام Technique

• شناسه MITRE ATT&CK

• توضیح Test

• سیستم‌عامل مورد پشتیبانی

• Executor

• Command یا Script مورد استفاده

• Inputها و Parameters

• Dependencyها

• دستورهای مربوط به آماده‌سازی محیط

• دستورهای Cleanup

در Repository پروژه، برای Techniqueها فایل‌های YAML و Markdown وجود دارد و برخی Testها نیز دارای فایل‌های وابستگی در پوشه‌های src و bin هستند.

به همین دلیل قبل از اجرای یک Test نباید صرفاً Command آن را Copy/Paste کرد.

ابتدا باید مشخص شود Test دقیقاً چه کاری انجام می‌دهد، چه Dependencyهایی دارد و آیا Cleanup برای آن تعریف شده است یا خیر.

ارتباط Atomic Red Team با MITRE ATT&CK

یکی از مهم‌ترین ویژگی‌های Atomic Red Team، ارتباط مستقیم آن با MITRE ATT&CK است.

MITRE ATT&CK رفتار مهاجمان را در قالب Tactic و Technique دسته‌بندی می‌کند.

Atomic Red Team از همین Techniqueها به‌عنوان نقطه شروع برای تست استفاده می‌کند.

به‌صورت ساده می‌توان رابطه را این‌گونه نمایش داد:

MITRE ATT&CK
      │
      ├── T1059.001
      │      PowerShell
      │
      │      ↓
      │
      └── Atomic Test
             ↓
       Execute Technique
             ↓
        Generate Telemetry
             ↓
           Detection

در نتیجه اگر سازمان بخواهد Coverage مربوط به یک Technique خاص را بررسی کند، می‌تواند یک یا چند Atomic Test مربوط به همان Technique را اجرا کند.

این موضوع باعث می‌شود Testing به جای اینکه به شکل تصادفی انجام شود، بر اساس یک Framework استاندارد مانند MITRE ATT&CK انجام شود.

Atomic Red Team چه تفاوتی با یک حمله واقعی دارد؟

Atomic Red Team را نباید با یک Red Team Operation کامل اشتباه گرفت.

در یک Red Team واقعی، مهاجم ممکن است یک زنجیره کامل از تکنیک‌ها را اجرا کند:

Initial Access
      ↓
Execution
      ↓
Persistence
      ↓
Privilege Escalation
      ↓
Credential Access
      ↓
Lateral Movement
      ↓
Collection
      ↓
Exfiltration

اما Atomic Red Team معمولاً یک بخش کوچک از این زنجیره را آزمایش می‌کند.

بنابراین Atomic Testing بیشتر برای موارد زیر مناسب است:

• Validation

• Detection Testing

• Security Control Testing

• Purple Team

• Detection Engineering

• Threat Hunting

• SOC Training

در مقابل، برای شبیه‌سازی کامل رفتار یک Threat Actor، ابزارها و روش‌های دیگری مانند Adversary Emulation و Purple Team Exercises مناسب‌تر هستند.

Atomic Red Team چه کاربردهایی دارد؟

1. بررسی Detection

یکی از مهم‌ترین کاربردهای Atomic Red Team بررسی Detection Ruleها است.

فرض کنید یک Rule برای شناسایی Scheduled Task ایجاد کرده‌ایم.

با اجرای Atomic Test مربوط به این Technique می‌توانیم بررسی کنیم:

آیا Endpoint فعالیت را ثبت کرده است؟

آیا Event به SIEM رسیده است؟

آیا Detection Rule آن را شناسایی کرده است؟

آیا Alert تولید شده است؟

آیا Alert اطلاعات کافی برای Investigation دارد؟

اگر پاسخ یکی از این موارد منفی باشد، یک Detection Gap داریم.

2. بررسی Visibility

گاهی مشکل Detection نیست؛ بلکه مشکل Visibility است.

برای مثال ممکن است یک Technique روی Endpoint اجرا شود اما هیچ Telemetry مناسبی از آن در اختیار SOC قرار نگیرد.

در این شرایط حتی بهترین Detection Rule نیز نمی‌تواند رفتار مهاجم را شناسایی کند.

Atomic Testing به ما کمک می‌کند بفهمیم:

Attack Behavior
      ↓
Endpoint
      ↓
Telemetry
      ↓
Log Collection
      ↓
SIEM

در کدام مرحله اطلاعات از بین می‌رود.

3. Detection Engineering

Atomic Red Team ابزار بسیار مناسبی برای Detection Engineering است.

فرض کنید Detection Engineer می‌خواهد برای یک Technique جدید Rule ایجاد کند.

فرآیند می‌تواند به شکل زیر باشد:

Technique Selection
        ↓
Atomic Test
        ↓
Generate Telemetry
        ↓
Analyze Events
        ↓
Identify Indicators
        ↓
Create Detection
        ↓
Run Atomic Test Again
        ↓
Validate Detection

در این حالت Detection دیگر صرفاً بر اساس تئوری نوشته نمی‌شود؛ بلکه بر اساس Telemetry واقعی محیط ساخته و آزمایش می‌شود.

پیش‌نیازهای استفاده از Atomic Red Team

قبل از اجرای Atomic Test باید چند نکته را در نظر گرفت.

مهم‌ترین مورد، داشتن مجوز برای اجرای Test است.

Atomic Testها رفتارهایی را شبیه‌سازی می‌کنند که ممکن است توسط EDR یا سایر ابزارهای امنیتی به‌عنوان فعالیت مشکوک شناسایی شوند.

بنابراین اجرای آن‌ها روی سیستم‌های Production بدون هماهنگی می‌تواند باعث ایجاد Alert، Block شدن Process، تغییر وضعیت سیستم یا حتی اختلال در سرویس شود.

بهتر است در ابتدا از یک Lab یا محیط غیر Production استفاده شود.

برای محیط Windows نیز معمولاً PowerShell نسخه 5 یا بالاتر مورد نیاز است.

نصب Atomic Red Team در Windows

یکی از روش‌های متداول استفاده از Atomic Red Team، استفاده از ابزار PowerShell-based به نام Invoke-AtomicRedTeam است.

این ابزار یک Execution Framework برای اجرای Atomic Testها فراهم می‌کند.

روش نصب از PowerShell Gallery به شکل زیر است:

Install-Module -Name invoke-atomicredteam,powershell-yaml -Scope CurrentUser

طبق مستندات پروژه، Invoke-AtomicRedTeam روی Windows، Linux و macOS قابل استفاده است و در Linux و macOS به PowerShell Core نیاز دارد.

پس از نصب می‌توان Module را Import کرد:

Import-Module Invoke-AtomicRedTeam

دریافت Atomic Tests

برای استفاده از Testها باید مجموعه Atomic Testها نیز در اختیار Execution Framework قرار بگیرد.

یکی از روش‌های نصب، استفاده از Installer پروژه است.

برای مثال:

IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing)

Install-AtomicRedTeam -getAtomics

در روش معمول، فایل‌های مربوط به Atomic Red Team در مسیر زیر قرار می‌گیرند:

C:\AtomicRedTeam

مسیر نصب و سایر گزینه‌های Installation مانند InstallPath و Force در مستندات Invoke-AtomicRedTeam توضیح داده شده‌اند.

ساختار Atomic Tests

پس از دریافت Repository، ساختار Testها بر اساس Techniqueهای MITRE ATT&CK سازمان‌دهی شده است.

برای مثال ممکن است با ساختاری مانند زیر مواجه شویم:

atomics/
│
├── T1059.001/
│   ├── T1059.001.yaml
│   └── T1059.001.md
│
├── T1053.005/
│   ├── T1053.005.yaml
│   └── T1053.005.md
│
└── ...

هر پوشه مربوط به یک Technique یا Sub-Technique است.

فایل Markdown معمولاً اطلاعات قابل خواندن برای انسان را ارائه می‌کند و فایل YAML ساختار Test را مشخص می‌کند.

برخی Testها نیز ممکن است فایل‌های موردنیاز خود را در src یا bin داشته باشند.

بررسی یک Atomic Test قبل از اجرا

یکی از مهم‌ترین اصول Atomic Testing این است که Test را بدون بررسی اجرا نکنیم.

قبل از اجرای Test باید حداقل موارد زیر را بررسی کنیم:

Technique چیست؟

چه کاری انجام می‌دهد؟

روی چه سیستم‌عاملی اجرا می‌شود؟

آیا Dependency دارد؟

چه Commandی اجرا خواهد شد؟

چه Telemetryای باید ایجاد شود؟

آیا Cleanup دارد؟

در مستندات پروژه نیز تأکید شده است که Testها ممکن است Dependency داشته باشند و باید قبل از اجرا بخش‌های مربوط به Get Prereq Commands، Attack Commands و Cleanup Commands بررسی شوند.

اجرای Atomic Test

پس از نصب، می‌توان Test مربوط به یک Technique را با Invoke-AtomicRedTeam اجرا کرد.

برای مثال:

Invoke-AtomicTest T1059.001

در اینجا T1059.001 مربوط به PowerShell است.

اما اجرای Command به‌تنهایی هدف Atomic Testing نیست.

مهم‌ترین بخش بعد از اجرای Test شروع می‌شود.

باید بررسی کنیم که چه اتفاقی در سیستم افتاده است.

بعد از اجرای Test چه چیزی باید بررسی شود؟

پس از اجرای Atomic Test، باید Telemetry تولیدشده را بررسی کنیم.

برای مثال در یک Windows Endpoint ممکن است مواردی مانند:

• Process Creation

• Command Line

• Parent Process

• Child Process

• Network Connection

• File Creation

• Registry Activity

• PowerShell Logging

تولید شود.

اگر Sysmon نصب باشد، ممکن است Eventهای مختلفی در ارتباط با رفتار اجراشده ایجاد شوند.

اگر EDR داشته باشیم، ممکن است Telemetry غنی‌تری در اختیار داشته باشیم.

سپس این داده‌ها به SIEM منتقل می‌شوند.

بنابراین Atomic Testing را نباید با اجرای Command تمام‌شده در نظر گرفت.

در واقع اجرای Command فقط آغاز فرآیند Validation است.

یک سناریوی ساده برای SOC

فرض کنید سازمان می‌خواهد Detection مربوط به Scheduled Task را بررسی کند.

در مرحله اول Technique موردنظر را انتخاب می‌کنیم:

T1053.005
Scheduled Task/Job: Scheduled Task

سپس Atomic Test مربوط به آن را انتخاب می‌کنیم.

بعد از اجرای Test، بررسی می‌کنیم:

آیا schtasks.exe اجرا شده است؟

آیا Scheduled Task ایجاد شده است؟

چه Processهایی در ادامه اجرا شده‌اند؟

چه Eventهایی در Windows ثبت شده‌اند؟

آیا Sysmon اطلاعات موردنیاز را ثبت کرده است؟

آیا Log به SIEM رسیده است؟

آیا Detection Rule فعال شده است؟

آیا Alert ایجاد شده است؟

Red Canary نیز برای Scheduled Task نمونه‌ای از Test را ارائه کرده و Telemetryهایی مانند Process Monitoring را به‌عنوان داده مفید برای بررسی معرفی می‌کند.

چگونه بفهمیم Detection ما درست کار می‌کند؟

برای هر Test می‌توان یک نتیجه مشخص تعریف کرد.

برای مثال:

Test Executed
      ↓
Telemetry Generated
      ↓
Telemetry Collected
      ↓
Detection Triggered
      ↓
Alert Created
      ↓
SOC Analyst Investigated

حالا می‌توانیم نتیجه را ثبت کنیم.

مثلاً:

Technique: T1053.005

Execution:       PASS
Telemetry:        PASS
Log Collection:   PASS
Detection:        FAIL
Alert:            FAIL

این نتیجه به ما می‌گوید که Endpoint و Log Pipeline احتمالاً درست کار می‌کنند، اما Detection مربوط به این رفتار وجود ندارد یا عملکرد مناسبی ندارد.

اگر Test Detect نشد چه کنیم؟

Detect نشدن یک Test الزاماً به معنی خراب بودن Detection Rule نیست.

باید مرحله‌به‌مرحله بررسی کنیم.

اول باید ببینیم آیا رفتار واقعاً اجرا شده است.

اگر اجرا شده، بررسی می‌کنیم آیا Telemetry تولید شده است.

اگر Telemetry تولید شده، بررسی می‌کنیم آیا Log Collector آن را دریافت کرده است.

اگر Log دریافت شده، بررسی می‌کنیم آیا به SIEM رسیده است.

اگر SIEM آن را دارد، Detection Query را بررسی می‌کنیم.

بنابراین:

Execution
   ↓
Telemetry
   ↓
Collection
   ↓
SIEM
   ↓
Detection
   ↓
Alert

هر مرحله می‌تواند یک Detection Gap ایجاد کند.

نقش Atomic Red Team در بهبود SOC

Atomic Red Team می‌تواند به SOC کمک کند تا از یک مدل واکنشی به یک مدل Validation محور حرکت کند.

در یک SOC سنتی ممکن است تیم منتظر بماند تا یک Alert واقعی ایجاد شود و سپس Detection را بررسی کند.

اما با Atomic Testing می‌توانیم به‌صورت Proactive Detectionها را آزمایش کنیم.

برای مثال:

Detection Rule
      ↓
Atomic Test
      ↓
Result
      ↓
Improvement
      ↓
Re-Test

این فرآیند باعث می‌شود Detectionها به‌صورت مداوم اعتبارسنجی شوند.

Atomic Red Team و Continuous Validation

Atomic Testing نباید فقط یک بار انجام شود.

فرض کنید یک Detection Rule ایجاد کرده‌ایم و Test در همان روز موفق بوده است.

چند ماه بعد ممکن است:

• Agent تغییر کند.

• Sysmon Configuration تغییر کند.

• Log Pipeline تغییر کند.

• SIEM Rule تغییر کند.

• EDR Policy تغییر کند.

• Endpoint Configuration تغییر کند.

در نتیجه ممکن است Detection که قبلاً کار می‌کرد، دیگر کار نکند.

به همین دلیل Continuous Atomic Testing اهمیت پیدا می‌کند.

Invoke-AtomicRedTeam حتی قابلیت‌هایی برای اجرای دوره‌ای مجموعه‌ای از Testها ارائه کرده است تا امکان Validation مستمر فراهم شود.

چرخه پیشنهادی Continuous Atomic Testing

یک چرخه مناسب می‌تواند به شکل زیر باشد:

Select Techniques
       ↓
Schedule Tests
       ↓
Execute Atomic Tests
       ↓
Collect Telemetry
       ↓
Validate Detection
       ↓
Generate Report
       ↓
Identify Gaps
       ↓
Improve Detection
       ↓
Re-Test

این مدل باعث می‌شود Detection Engineering به یک فرآیند Continuous تبدیل شود.

تفاوت Atomic Red Team با Red Team

Atomic Red Team جایگزین Red Team نیست.

Red Team معمولاً یک هدف مشخص دارد و تلاش می‌کند با استفاده از تکنیک‌های مختلف به آن هدف برسد.

ممکن است یک Red Team Operation هفته‌ها طول بکشد و شامل چندین مرحله باشد.

اما Atomic Test معمولاً روی یک رفتار مشخص تمرکز می‌کند.

بنابراین:

Atomic Red Team
=
Technique-level Validation

در حالی که:

Red Team
=
Objective-based Adversary Simulation

هر دو رویکرد ارزشمند هستند، اما اهداف متفاوتی دارند.

اشتباهات رایج هنگام استفاده از Atomic Red Team

اجرای Test روی Production

یکی از خطرناک‌ترین اشتباهات، اجرای Test بدون هماهنگی روی سیستم‌های Production است.

بعضی Testها ممکن است:

• Process ایجاد کنند.

• فایل ایجاد یا حذف کنند.

• Registry را تغییر دهند.

• Scheduled Task ایجاد کنند.

• Network Connection ایجاد کنند.

• توسط EDR Block شوند.

بنابراین Test باید با Change Management و هماهنگی تیم‌های مربوطه انجام شود.

اجرای Test بدون مطالعه

نباید صرفاً یک Command را از اینترنت Copy و Paste کرد.

قبل از اجرای Test باید Documentation آن مطالعه شود.

نادیده گرفتن Cleanup

برخی Testها تغییراتی در سیستم ایجاد می‌کنند.

بنابراین باید Cleanup آن‌ها اجرا شود.

طبق مستندات Atomic Red Team، بعضی Testها تغییراتی در محیط ایجاد می‌کنند و برای برگرداندن محیط باید دستورات Cleanup مربوط به Test اجرا شود.

تمرکز فقط روی Alert

ممکن است Test اجرا شود و Alert نیز ایجاد شود، اما Detection همچنان کیفیت مناسبی نداشته باشد.

باید بررسی شود که Alert آیا اطلاعات کافی برای Investigation دارد یا خیر.

یک Workflow استاندارد برای استفاده از Atomic Red Team

یک Workflow مناسب برای یک تیم SOC می‌تواند به شکل زیر باشد:

مرحله اول: انتخاب Technique

Techniqueهای مهم متناسب با Threat Model سازمان انتخاب می‌شوند.

مرحله دوم: انتخاب Atomic Test

برای Technique موردنظر یک یا چند Test انتخاب می‌شود.

مرحله سوم: بررسی Test

Command، Dependency، Input و Cleanup بررسی می‌شود.

مرحله چهارم: اجرای Test

Test در Lab یا محیط مورد تأیید اجرا می‌شود.

مرحله پنجم: بررسی Telemetry

Eventهای Endpoint، EDR، Sysmon و سایر منابع بررسی می‌شوند.

مرحله ششم: بررسی SIEM

بررسی می‌شود که Telemetry موردنظر در SIEM قابل مشاهده است یا خیر.

مرحله هفتم: بررسی Detection

Detection Rule مربوط به رفتار اجراشده بررسی می‌شود.

مرحله هشتم: Investigation

Alert تولیدشده توسط SOC Analyst بررسی می‌شود.

مرحله نهم: اصلاح

در صورت وجود Gap، Log Source، Parser، Query یا Detection اصلاح می‌شود.

مرحله دهم: اجرای مجدد

Atomic Test مجدداً اجرا می‌شود تا مشخص شود مشکل برطرف شده است یا خیر.

نتیجه‌گیری

Atomic Red Team را می‌توان یکی از ابزارهای کاربردی برای تبدیل Detection Engineering از یک فرآیند مبتنی بر فرضیات به یک فرآیند مبتنی بر Validation دانست.

با استفاده از Atomic Testing می‌توان یک رفتار مشخص از مهاجم را به‌صورت کنترل‌شده اجرا کرد و سپس تمام زنجیره دفاعی سازمان را بررسی کرد:

Adversary Behavior
        ↓
Atomic Test
        ↓
Endpoint
        ↓
Telemetry
        ↓
Log Collection
        ↓
SIEM / EDR
        ↓
Detection
        ↓
Alert
        ↓
Investigation
        ↓
Response

مهم‌ترین ارزش Atomic Red Team در خود اجرای Test نیست؛ بلکه در اطلاعاتی است که بعد از اجرای Test به دست می‌آید.

اگر یک Test اجرا شود و Detection آن موفق باشد، می‌توانیم بخشی از قابلیت دفاعی خود را اعتبارسنجی کنیم.

اگر Detection شکست بخورد، یک Detection Gap داریم.

اگر Telemetry تولید نشود، Visibility Gap داریم.

اگر Telemetry تولید شود اما به SIEM نرسد، مشکل Log Collection یا Pipeline وجود دارد.

اگر Alert تولید شود اما اطلاعات کافی نداشته باشد، باید Detection و Enrichment بهبود پیدا کند.

و اگر Alert ایجاد شود اما Analyst نتواند آن را به‌درستی بررسی کند، مشکل در فرآیند Investigation یا SOC Operations قرار دارد.

به همین دلیل Atomic Red Team را نباید صرفاً یک مجموعه Command برای شبیه‌سازی حمله در نظر گرفت.

Atomic Red Team می‌تواند بخشی از یک چرخه مستمر برای Detection Validation، Detection Engineering، Threat Hunting، Purple Team و بهبود قابلیت‌های SOC باشد.

در یک برنامه بلوغ‌یافته امنیتی، فرآیند به این شکل ادامه پیدا می‌کند:

Test
 ↓
Observe
 ↓
Detect
 ↓
Investigate
 ↓
Improve
 ↓
Re-Test

و همین چرخه است که باعث می‌شود SOC به‌جای اینکه صرفاً منتظر وقوع حمله و ایجاد Alert باشد، به‌صورت مستمر قابلیت‌های دفاعی خود را آزمایش و بهبود دهد.