تحلیلگر امنیتی در مقابل مهندس امنیتی: واقعیترین تقسیمبندی چیست؟
تفکیک عملی نحوه متفاوت بودن نقشهای تحلیلگر امنیتی و مهندس امنیتی در کار روزمره، مهارتها و مسیرهای شغلی.
این عناوین در آگهیهای استخدام به جای یکدیگر استفاده میشوند، اما کار روزمره کاملاً متفاوت است. اگر دنبال مسیری برای تحصیل هستید، فهم این تقسیمبندی ماهها را نجات خواهد داد که صرف شناسایی گواهینامهها و مهارتهای اشتباه شود.
یک تحلیلگر واقعاً در طول روز چه کار میکند
یک تحلیلگر امنیتی اکثر وقت خود را صرف نظارت، طبقهبندی و تحقیق میکند. یعنی نگاه کردن به SIEM (Splunk, Sentinel, QRadar)، کار با صف هشدارها و تصمیم گیری درباره اینکه آیا یک فرایند پرچمدار روی یک workstation یک false positive است یا شروع یک incident. بخش بزرگی از این کار نوشتن یافتهها به شکلی واضح است که یک مدیر یا کلاینت بدون پیشزمینه امنیتی بتواند بفهمد چه اتفاقی افتاده.
تحلیلگران Tier 1 طبقهبندی میکنند. تحلیلگران Tier 2/3 عمیقتر بررسی میکنند — درختهای فرایند را میکشند، تلمتری EDR را در چیزی مثل CrowdStrike یا Defender for Endpoint بررسی میکنند، لاگها را در سراسر فایروالها و identity provider ها correlate میکنند تا یک timeline بسازند. ماهیت این شغل reactive است: اتفاقی میافتد، شما متوجه میشوید که به چه معناست و چه باید دربارهاش انجام شود.
یک لیست کار نمونه برای تحلیلگر: بررسی هشدارهای شب، بستن false positive ها با reasoning مستند، escalate کردن یک PowerShell execution مریب، بروزرسانی runbook بعد از نمودار phishing جدید، و حضور در call یک incident. این کار تحقیقی و پر از ارتباطات است.
یک مهندس واقعاً چه میسازد
یک مهندس امنیتی سیستمهایی میسازد و نگهداری میکند که تحلیلگر بر آن تکیه میکند. یعنی نوشتن detection rule در Sigma یا KQL، tuning کردن SIEM تا صف را با noise پر نکند، deploy و configure کردن EDR agent در 5000 endpoint، یا خودکار کردن یک phishing response playbook در SOAR platform مثل Tines یا Cortex XSOAR.
مهندسان همچنین upstream از incident کار میکنند: hardening کردن cloud config در AWS یا Azure، راهاندازی network segmentation، نوشتن Terraform برای enforce کردن security group rule، patch کردن CI/CD pipeline تا secret به git history نریزد. بسیاری از کار مهندسی invisible است تا زمانی که fail کند — کسی یک WAF rule خوبپیکربندیشده را نمیبیند، اما همه وقتی آن گم شود متوجه میشوند.
جایی که یک تحلیلگر میپرسد «اینجا چه اتفاقی افتاد»، یک مهندس میپرسد «چطور این رده از چیزها را جلوگیری کنیم یا حداقل بار بعد سریعتر detect کنیم». مهندسان اغلب کد مینویسند — Python برای automation، گاهی Go یا Rust برای tooling، YAML و Terraform برای infrastructure.
مهارتهایی که واقعاً این دو را از هم جدا میکند
تحلیلگران به pattern recognition قوی، روانی در log analysis و توانایی نوشتن incident report تحت فشار زمان نیاز دارند. ابزار: Splunk SPL, Wireshark, basic malware triage, MITRE ATT&CK mapping. گواهینامههایی که خوب map میشوند: Security+, CySA+, GCIH، گاهی به GCFA برای کار forensics عمیقتر.
مهندسان باید واقعاً چیزها بسازند: scripting (Python, Bash), infrastructure-as-code, API integration بین ابزار امنیتی، و دانش کافی از systems/network برای اینکه بدانند چرا یک rule production را break میکند. گواهینامهها اینجا به سمت GCED، cloud security cert (AWS Security Specialty, AZ-500) و در نهایت OSCP اگر نقش lean کند به سمت offensive-adjacent متمایل هستند.
تقاطع واقعی وجود دارد — یک تحلیلگر خوب یاد میگیرد که query enrichment خود را script کند، و یک مهندس خوب باز هم نیاز دارد که لاگ را بخواند تا بداند detection آنها واقعاً fire میکند یا نه. اما center of gravity متفاوت است: تحلیلگران در alert queue زندگی میکنند، مهندسان در config file و code repo.
مسیرهای شغلی و نحوه حرکت افراد بین آنها
اکثر مردم به عنوان تحلیلگر شروع میکنند چون نقشهای SOC بیشتر position entry-level استخدام میکنند و learning curve به شما یاد میدهد «normal» در یک environment واقعی چگونه است. این foundation حتی اگر در نهایت بخواهید engineer شوید مهم است.
از Tier 1 analyst، یک مسیر رایج این است: Tier 2/3 analyst، سپس یا threat hunter یا detection engineer، که یک نقش hybrid واقعی است که detection را بر اساس آنچه تحلیلگران miss میکنند در queue مینویسد. از آنجا، برخی کاملاً به سمت security engineering (ساخت platform) یا architecture (طراحی کل برنامه امنیتی) حرکت میکنند.
مهندسان گاهی از درب متفاوتی میآیند — developers یا sysadmin های نرمافزاری که تخصص امنیتی را میگیرند به جای شروع در SOC. این مسیر فاز alert-fatigue را skip میکند اما میتواند gap در instinct های incident response بگذارد.
کدام یک باید اول هدف شود
اگر دوست دارید تحقیق، نویسندگی و حل puzzle تحت فشار، با سمت analyst شروع کنید. اگر ترجیح میدهید کد بنویسید و root cause را fix کنید تا chase کردن alert، سمت engineer را هدف کنید، اما انتظار داشته باشید که نیاز به experience analyst-adjacent دارید تا credible باشید — کسی detectionای را که ساختهاید trust نمیکند اگر خود هرگز alert queue را کار نکردهاید.
هر دو مسیر در نهایت در levelهای senior converge میکنند، جایی که کار کمتر درباره عنوان است و بیشتر درباره فهم کل attack surface. Korra Studio بخشهایی درباره SOC workflow، SIEM query writing و cloud security engineering fundamentals دارد که برای دیدن day-to-day tooling برای هر دو track از نزدیک درخور تماشا است.
با کمک هوش مصنوعی نوشتهشده، بازبینی و منتشرشده توسط Michal Pilch (CISSP)، Korra Studio.
این یکی از یادداشتهای پایگاه دانش Korra Studio است — پلتفرم هر موضوع را با مربی یکبهیک جفت میکند.
شروع رایگانarrow_forward