📌 فقط به Alert اعتماد نکن؛ Context مهمتره
فرض کنید SIEM بهتون Alert داده که یک PowerShell اجرا شده.
خود این Alert بهتنهایی چیز زیادی نمیگه.
قبل از اینکه تصمیم بگیرید، چندتا سؤال ساده بپرسید:
⚠️ گاهی یک Event بهتنهایی کاملاً عادیه، ولی وقتی چند Event رو کنار هم میذارید، داستان کاملاً فرق میکنه.
🔎 توی SOC، تحلیل واقعی یعنی Eventها رو کنار هم بذاری و Timeline بسازی.
@Socroot
فرض کنید SIEM بهتون Alert داده که یک PowerShell اجرا شده.
خود این Alert بهتنهایی چیز زیادی نمیگه.
قبل از اینکه تصمیم بگیرید، چندتا سؤال ساده بپرسید:
چه کاربری اجراش کرده؟
روی کدوم سیستم؟
Parent Process چی بوده؟
Command Line چی بوده؟
قبل و بعدش چه Eventهایی ثبت شده؟
آیا ارتباط شبکهای هم ایجاد شده؟
⚠️ گاهی یک Event بهتنهایی کاملاً عادیه، ولی وقتی چند Event رو کنار هم میذارید، داستان کاملاً فرق میکنه.
🔎 توی SOC، تحلیل واقعی یعنی Eventها رو کنار هم بذاری و Timeline بسازی.
@Socroot
👏6
🔎 ویژگی Timeline در ELK
یکی از قابلیتهای کاربردی در Elastic Security هست که به Analyst کمک میکنه Eventهای مختلف رو کنار هم قرار بده و روند یک اتفاق یا حمله رو بهتر بررسی کنه.
📌 به جای اینکه فقط یک Log رو ببینیم، میتونیم فعالیتهای مربوط به یک User، Host، IP یا Process رو در یک بازه زمانی مشخص کنار هم قرار بدیم و بفهمیم چه اتفاقی افتاده.
⚠️ در واقع Timeline کمک میکنه از بین هزاران Log، یک داستان قابل فهم از اتفاقات امنیتی بسازیم.
@Socroot
یکی از قابلیتهای کاربردی در Elastic Security هست که به Analyst کمک میکنه Eventهای مختلف رو کنار هم قرار بده و روند یک اتفاق یا حمله رو بهتر بررسی کنه.
📌 به جای اینکه فقط یک Log رو ببینیم، میتونیم فعالیتهای مربوط به یک User، Host، IP یا Process رو در یک بازه زمانی مشخص کنار هم قرار بدیم و بفهمیم چه اتفاقی افتاده.
مثلاً بررسی کنیم: 🕒 چه زمانی یک Process اجرا شده؟
👤 کدام کاربر درگیر بوده؟
💻 روی کدام سیستم اتفاق افتاده؟
🌐 چه ارتباطات شبکهای ایجاد شده؟
⚠️ در واقع Timeline کمک میکنه از بین هزاران Log، یک داستان قابل فهم از اتفاقات امنیتی بسازیم.
@Socroot
🔥4
📌 خیلی چیزها بلدی، ولی هنوز نمیدونی توی SOC چطور ازشون استفاده کنی؟
این مشکل خیلی از افرادیه که تازه وارد مسیر SOC میشن.
ممکنه Networking بلد باشی، با Windows و Linux کار کرده باشی، SIEM و Sysmon رو بشناسی و حتی MITRE ATT&CK رو هم مطالعه کرده باشی؛ ولی وقتی یک Alert جلوت قرار میگیره، ندونی از کجا شروع کنی و چه چیزهایی رو کنار هم بذاری.
مشکل معمولاً کمبود دانش نیست؛ نداشتن چارچوب تحلیله.
📌 قرار نیست همه چیز رو همزمان استفاده کنی.
🔹️ دانش زیاد بدون چارچوب، موقع تحلیل Alert خیلی کمکت نمیکنه.
@Socroot
این مشکل خیلی از افرادیه که تازه وارد مسیر SOC میشن.
ممکنه Networking بلد باشی، با Windows و Linux کار کرده باشی، SIEM و Sysmon رو بشناسی و حتی MITRE ATT&CK رو هم مطالعه کرده باشی؛ ولی وقتی یک Alert جلوت قرار میگیره، ندونی از کجا شروع کنی و چه چیزهایی رو کنار هم بذاری.
مشکل معمولاً کمبود دانش نیست؛ نداشتن چارچوب تحلیله.
مثلاً وقتی یک Alert میبینی:
1️⃣ Alert رو بفهم
چی شده؟ چرا Alert ساخته شده؟
2️⃣ Context جمع کن
کاربر؟ سیستم؟ زمان؟ Process؟ Command Line؟ IP؟
3️⃣ لاگهای مرتبط رو پیدا کن
قبل و بعد از Event چه اتفاقی افتاده؟
4️⃣ ارتباط بین Eventها رو بررسی کن
آیا این اتفاقها به هم مرتبط هستن؟
5️⃣ با اطلاعاتی که داری تصمیم بگیر
False Positive؟ فعالیت مشکوک؟ یا Incident؟
6️⃣ نتیجه رو مستند و در صورت نیاز Escalate کن.
📌 قرار نیست همه چیز رو همزمان استفاده کنی.
🔹️ دانش زیاد بدون چارچوب، موقع تحلیل Alert خیلی کمکت نمیکنه.
⚠️ چیزی که یک SOC Analyst خوب رو متفاوت میکنه اینه که میدونه برای هر Alert، چه دانشی رو، در چه مرحلهای و برای چه سؤالی استفاده کنه.
@Socroot
🔥7
رفقا دوست داشتید بیایید و راجب مصاحبه هایی که داشتید بگید .
🔹️ اینکه چه نکاتی رو اونجا متوجه شدید ؟
🔹️ توی هر حوزه کارفرما چه انتظاراتی داره ؟
🔹️ نیاز بازار کار دقیقا چیه ؟
میتونید زیر همین پست مطلبتون رو بنویسید و ارسال کنید .
مطمئن باشید نکاتی که میگید قطعا به درد چند نفر دیگه میخوره 🙏🏻
@Socroot
🔹️ اینکه چه نکاتی رو اونجا متوجه شدید ؟
🔹️ توی هر حوزه کارفرما چه انتظاراتی داره ؟
🔹️ نیاز بازار کار دقیقا چیه ؟
میتونید زیر همین پست مطلبتون رو بنویسید و ارسال کنید .
مطمئن باشید نکاتی که میگید قطعا به درد چند نفر دیگه میخوره 🙏🏻
@Socroot
❤6🙏2🔥1
📌 یه نکته ساده ولی خیلی مهم در تحلیل Alertها
وقتی یک Alert میبینی، سریع نرو سراغ اینکه «این حمله هست یا نه؟»
یعنی یک Event ثابت، روی سیستمهای مختلف میتونه Risk متفاوتی داشته باشه.
پس همیشه این سه مورد رو کنار هم ببین:
📌 تحلیل خوب فقط بررسی کردن اینکه «چه اتفاقی افتاده» نیست؛
باید بدونی کجا، توسط چه کسی و در چه شرایطی اتفاق افتاده.
@Socroot
وقتی یک Alert میبینی، سریع نرو سراغ اینکه «این حمله هست یا نه؟»
اول بپرس:
«این سیستم معمولاً چه رفتاری داره؟»
مثلاً روی یک سرور، اجرای PowerShell ممکنه کاملاً عادی باشه.
اما اگر همون PowerShell روی یک Domain Controller اجرا بشه، توسط یک User غیرمعمول و با یک Command Line عجیب، ارزش بررسی خیلی بیشتری پیدا میکنه.
یعنی یک Event ثابت، روی سیستمهای مختلف میتونه Risk متفاوتی داشته باشه.
پس همیشه این سه مورد رو کنار هم ببین:
Event + Asset + User
📌 تحلیل خوب فقط بررسی کردن اینکه «چه اتفاقی افتاده» نیست؛
باید بدونی کجا، توسط چه کسی و در چه شرایطی اتفاق افتاده.
@Socroot
🔥5
📌 وقتی یه URL مشکوک میبینی، مستقیم بازش نکن.
اول بندازش توی urlscan.io.
⚠️ برای بررسی اولیه Phishing URLها و استخراج IOC، ابزار کاربردیایه.
🔗 urlscan
@Socroot
اول بندازش توی urlscan.io.
صفحه رو بررسی میکنه و اطلاعاتی مثل IPهای مقصد، Domainها، Redirectها، Requestها و Screenshot صفحه رو در اختیارت میذاره.
مثلاً میتونی متوجه بشی یک لینک ظاهراً ساده، در پشت صحنه به چه سرویسها و آدرسهایی ارتباط برقرار میکنه.
⚠️ برای بررسی اولیه Phishing URLها و استخراج IOC، ابزار کاربردیایه.
🔗 urlscan
@Socroot
❤4👌1
📌 وظایف یک کارشناس SOC Tier 1 چیه؟
کارشناس سطح یک معمولاً اولین نفریه که با هشدارهای امنیتی سروکار داره.
کار اصلیش اینه که هشدارها رو بررسی کنه، اطلاعات لازم رو جمع کنه و مشخص کنه کدوم مورد نیاز به بررسی بیشتر داره.
📌 در واقع کارشناس سطح یک قرار نیست همه رخدادها رو از ابتدا تا انتها حل کنه.
⚠️ وظیفه اصلیش اینه که هشدار رو درست بررسی کنه، شواهد لازم رو جمع کنه و تصمیم بگیره که مورد باید بسته بشه یا برای بررسی بیشتر ارجاع داده بشه.
یک روند ساده برای کار روزانه:
@Socroot
کارشناس سطح یک معمولاً اولین نفریه که با هشدارهای امنیتی سروکار داره.
کار اصلیش اینه که هشدارها رو بررسی کنه، اطلاعات لازم رو جمع کنه و مشخص کنه کدوم مورد نیاز به بررسی بیشتر داره.
🔹 بررسی هشدارهای جدید در سامانه مدیریت رخدادها
🔹 بررسی دلیل ایجاد هر هشدار و جمعآوری اطلاعات مرتبط
🔹 بررسی کاربر، سیستم، آدرس IP، پردازش و زمان رخداد
🔹 بررسی لاگهای مرتبط و ساختن خط زمانی اتفاقات
🔹 بررسی آدرس IP، دامنه، فایل و سایر شاخصهای مشکوک
🔹 تشخیص موارد عادی، مثبت کاذب و فعالیتهای مشکوک
🔹 اولویتبندی هشدارها بر اساس شدت و میزان ریسک
🔹 ثبت نتیجه بررسی در سامانه تیکتینگ
🔹 ارجاع موارد مهم به کارشناس سطح دو
🔹 پیگیری هشدارها و تیکتهای باز
🔹 بررسی وضعیت دریافت لاگ از تجهیزات و سامانههای مختلف
🔹 بررسی سلامت خود سامانه مدیریت رخدادها
📌 در واقع کارشناس سطح یک قرار نیست همه رخدادها رو از ابتدا تا انتها حل کنه.
⚠️ وظیفه اصلیش اینه که هشدار رو درست بررسی کنه، شواهد لازم رو جمع کنه و تصمیم بگیره که مورد باید بسته بشه یا برای بررسی بیشتر ارجاع داده بشه.
یک روند ساده برای کار روزانه:
"Alert" → "Triage" → "Investigation" → "Decision" → "Documentation" → "Escalation"
@Socroot
❤5
Soc Root
📌 وظایف یک کارشناس SOC Tier 1 چیه؟ کارشناس سطح یک معمولاً اولین نفریه که با هشدارهای امنیتی سروکار داره. کار اصلیش اینه که هشدارها رو بررسی کنه، اطلاعات لازم رو جمع کنه و مشخص کنه کدوم مورد نیاز به بررسی بیشتر داره. 🔹 بررسی هشدارهای جدید در سامانه مدیریت…
سعی میکنم تو چندتا پست یه Mind Map برای هرکدوم از این وظایف براتون ایجاد کنم تا شاید درک هر بخش چه برای خودم و چه برای شما راحتر باشه .
❤10
Soc Root
📌 وظایف یک کارشناس SOC Tier 1 چیه؟ کارشناس سطح یک معمولاً اولین نفریه که با هشدارهای امنیتی سروکار داره. کار اصلیش اینه که هشدارها رو بررسی کنه، اطلاعات لازم رو جمع کنه و مشخص کنه کدوم مورد نیاز به بررسی بیشتر داره. 🔹 بررسی هشدارهای جدید در سامانه مدیریت…
📌 بررسی هشدارهای جدید در سامانه مدیریت رخدادها
🎯 دیدگاه T1
وقتی یه Alert میاد، قرار نیست فقط اسمش رو ببینیم و سریع بگیم «خب، حمله شده!»
مثلاً اگه Alert نوشته باشه:
"Brute Force Detected"
اول باید ببینیم دقیقاً چه اتفاقی افتاده.
🧠 نقشه ذهنی ساده:
⚙️ کاری که T1 باید انجام بده:
قبل از اینکه بره سراغ Investigation، باید یه تصویر اولیه از Alert داشته باشه.
یعنی:
به زبان ساده، T1 باید اول بفهمه:
«دقیقاً چه اتفاقی افتاده و این Alert چرا ایجاد شده؟»
بعد بره سراغ بررسیهای عمیقتر.
@Socroot
🎯 دیدگاه T1
وقتی یه Alert میاد، قرار نیست فقط اسمش رو ببینیم و سریع بگیم «خب، حمله شده!»
مثلاً اگه Alert نوشته باشه:
"Brute Force Detected"
اول باید ببینیم دقیقاً چه اتفاقی افتاده.
🔹 این Alert با چه Ruleای ایجاد شده؟
🔹 چه زمانی اتفاق افتاده؟
🔹 روی کدوم سیستم بوده؟
🔹 مربوط به چه کاربریه؟
🔹 چند بار این اتفاق تکرار شده؟
🔹 Source و Destination کجا هستن؟
🔹 Alert مشابه یا مرتبط دیگهای هم داریم؟
🧠 نقشه ذهنی ساده:
Alert
│
├── اسم Alert
├── Severity
├── Detection Rule
├── زمان رخداد
│
├── Source
│ ├── IP
│ ├── Host
│ └── User
│
├── Destination
│ ├── IP
│ ├── Host
│ └── Service
│
├── تعداد رخداد
│
└── Alertهای مرتبط
⚙️ کاری که T1 باید انجام بده:
قبل از اینکه بره سراغ Investigation، باید یه تصویر اولیه از Alert داشته باشه.
یعنی:
Alert
↓
Context
↓
Initial Understanding
به زبان ساده، T1 باید اول بفهمه:
«دقیقاً چه اتفاقی افتاده و این Alert چرا ایجاد شده؟»
بعد بره سراغ بررسیهای عمیقتر.
@Socroot
🔥5❤2👏2
Soc Root
📌 وظایف یک کارشناس SOC Tier 1 چیه؟ کارشناس سطح یک معمولاً اولین نفریه که با هشدارهای امنیتی سروکار داره. کار اصلیش اینه که هشدارها رو بررسی کنه، اطلاعات لازم رو جمع کنه و مشخص کنه کدوم مورد نیاز به بررسی بیشتر داره. 🔹 بررسی هشدارهای جدید در سامانه مدیریت…
📌 بررسی دلیل ایجاد Alert و جمعآوری اطلاعات مرتبط
🎯 دیدگاه T1
حالا که فهمیدیم Alert چیه، قدم بعدی اینه که بفهمیم:
«اصلاً چرا این Alert ایجاد شده؟»
مثلاً یه Alert داریم با عنوان:
"Suspicious PowerShell Execution"
قرار نیست فقط به همین عنوان اکتفا کنیم.
باید بریم ببینیم چه Event یا چه رفتاری باعث شده Rule فعال بشه.
🧠 نقشه ذهنی ساده:
⚙️ کاری که T1 باید انجام بده:
اینجا باید از خود Alert عبور کنه و برسه به شواهد.
یعنی:
در واقع T1 باید بتونه جواب این سؤال رو بده:
«چه اتفاقی افتاد که این Rule تصمیم گرفت Alert ایجاد کنه؟»
هرچی این قسمت دقیقتر بررسی بشه، تصمیم نهایی T1 هم قابلاعتمادتر میشه.
@Socroot
🎯 دیدگاه T1
حالا که فهمیدیم Alert چیه، قدم بعدی اینه که بفهمیم:
«اصلاً چرا این Alert ایجاد شده؟»
مثلاً یه Alert داریم با عنوان:
"Suspicious PowerShell Execution"
قرار نیست فقط به همین عنوان اکتفا کنیم.
باید بریم ببینیم چه Event یا چه رفتاری باعث شده Rule فعال بشه.
🔹 کدوم Event باعث ایجاد Alert شده؟
🔹 Rule دقیقاً دنبال چه رفتاری بوده؟
🔹 چه Command یا Processی اجرا شده؟
🔹 این رفتار قبل از Alert هم اتفاق افتاده؟
🔹 بعد از Alert چه اتفاقی افتاده؟
🔹 Eventهای مرتبط دیگهای داریم؟
🔹 این رفتار برای این سیستم یا کاربر عادیه یا نه؟
🧠 نقشه ذهنی ساده:
Alert
│
├── Detection Rule
│
├── Trigger Event
│
├── Related Events
│
├── Before
│ ├── Login
│ ├── Process
│ └── Network
│
├── Alert
│
└── After
├── Process
├── File
└── Network
⚙️ کاری که T1 باید انجام بده:
اینجا باید از خود Alert عبور کنه و برسه به شواهد.
یعنی:
Alert
↓
Why?
↓
Evidence
↓
Context
در واقع T1 باید بتونه جواب این سؤال رو بده:
«چه اتفاقی افتاد که این Rule تصمیم گرفت Alert ایجاد کنه؟»
هرچی این قسمت دقیقتر بررسی بشه، تصمیم نهایی T1 هم قابلاعتمادتر میشه.
@Socroot
🆒11❤6🔥3
Soc Root
📌 وظایف یک کارشناس SOC Tier 1 چیه؟ کارشناس سطح یک معمولاً اولین نفریه که با هشدارهای امنیتی سروکار داره. کار اصلیش اینه که هشدارها رو بررسی کنه، اطلاعات لازم رو جمع کنه و مشخص کنه کدوم مورد نیاز به بررسی بیشتر داره. 🔹 بررسی هشدارهای جدید در سامانه مدیریت…
📌 بررسی User، System، IP، Process و زمان رخداد
🎯 دیدگاه T1
حالا که فهمیدیم Alert چرا ایجاد شده، باید بفهمیم چه کسی، روی چه سیستمی و دقیقاً چه کاری انجام داده.
اینجا نباید فقط به یک لاگ نگاه کنیم. باید قطعات مختلف رو کنار هم بذاریم تا بفهمیم واقعاً چه اتفاقی افتاده.
🧠 نقشه ذهنی ساده:
⚙️ کاری که T1 باید انجام بده:
اینجا باید بتونه از بین اطلاعات مختلف، یه تصویر ساده از رخداد بسازه:
مثلاً در نهایت بتونه بگه:
«کاربر X روی سیستم Y، در ساعت Z، پردازش PowerShell رو با این Command Line اجرا کرده و با IP مقصد ارتباط داشته.»
⚠️ این اطلاعات پایهی Investigation هستن.
🔹️ چون تا وقتی ندونی چه کسی، کجا، کی و دقیقاً چه کاری انجام داده، نمیتونی درباره مشکوک یا عادی بودن رفتار تصمیم درستی بگیری.
@Socroot
🎯 دیدگاه T1
حالا که فهمیدیم Alert چرا ایجاد شده، باید بفهمیم چه کسی، روی چه سیستمی و دقیقاً چه کاری انجام داده.
اینجا نباید فقط به یک لاگ نگاه کنیم. باید قطعات مختلف رو کنار هم بذاریم تا بفهمیم واقعاً چه اتفاقی افتاده.
مثلاً برای یه Alert مربوط به اجرای مشکوک PowerShell، باید ببینیم:
🔹 چه کاربری PowerShell رو اجرا کرده؟
🔹 روی کدوم سیستم اجرا شده؟
🔹 Source IP چی بوده؟
🔹 مقصد کجا بوده؟
🔹 چه Processی اجرا شده؟
🔹 Command Line چی بوده؟
🔹 این اتفاق دقیقاً چه زمانی رخ داده؟
🧠 نقشه ذهنی ساده:
Event
│
├── User
│ └── چه کسی؟
│
├── Host
│ └── روی کدام سیستم؟
│
├── Source
│ └── از کجا؟
│
├── Destination
│ └── به کجا؟
│
├── Process
│ ├── Process Name
│ ├── Parent Process
│ └── Command Line
│
└── Time
├── Start
└── End
⚙️ کاری که T1 باید انجام بده:
اینجا باید بتونه از بین اطلاعات مختلف، یه تصویر ساده از رخداد بسازه:
WHO?
↓
WHAT?
↓
WHERE?
↓
WHEN?
↓
HOW?
مثلاً در نهایت بتونه بگه:
«کاربر X روی سیستم Y، در ساعت Z، پردازش PowerShell رو با این Command Line اجرا کرده و با IP مقصد ارتباط داشته.»
⚠️ این اطلاعات پایهی Investigation هستن.
🔹️ چون تا وقتی ندونی چه کسی، کجا، کی و دقیقاً چه کاری انجام داده، نمیتونی درباره مشکوک یا عادی بودن رفتار تصمیم درستی بگیری.
@Socroot
👏6🔥1
📌 انواع لاگهایی که یک SOC Analyst باید بشناسه
در SOC برای بررسی یک اتفاق امنیتی معمولاً به یک نوع لاگ اکتفا نمیکنیم. هر منبع، بخشی از اتفاق رو به ما نشون میده.
📌 نکته مهم:
برای تحلیل یک Incident معمولاً باید چند منبع لاگ رو کنار هم قرار بدیم.
مثلاً:
در واقع هر لاگ فقط یک بخش از ماجرا رو نشون میده.
@Socroot
در SOC برای بررسی یک اتفاق امنیتی معمولاً به یک نوع لاگ اکتفا نمیکنیم. هر منبع، بخشی از اتفاق رو به ما نشون میده.
🔹️ لاگهای شبکه
اطلاعات مربوط به ارتباطات شبکه مثل مبدأ، مقصد، پورت و پروتکل.
برای بررسی ارتباطات مشکوک، اسکن و ترافیک غیرعادی استفاده میشه.
🔹️ لاگهای Endpoint
اطلاعات مربوط به سیستمهای کاربران و سرورها؛ مثل اجرای Process، ایجاد فایل، سرویسها و تغییرات سیستم.
برای بررسی رفتار مشکوک روی سیستم خیلی مهمه.
🔹️ لاگهای احراز هویت
اطلاعات مربوط به ورود موفق و ناموفق، تغییر رمز عبور و فعالیت حسابهای کاربری.
برای بررسی حملاتی مثل Brute Force و استفاده غیرعادی از حسابها کاربرد داره.
🔹️ لاگهای Windows
رویدادهای ثبتشده توسط ویندوز، مثل ورود کاربران، اجرای Process، تغییرات حسابها و دسترسیها.
Event Log و Sysmon از منابع مهم این بخش هستن.
🔹️ لاگهای Firewall
ترافیک مجاز و مسدودشده توسط فایروال رو ثبت میکنن و برای بررسی ارتباطات ورودی و خروجی کاربرد دارن.
🔹️ لاگهای Web و Proxy
اطلاعات مربوط به درخواستهای وب و سایتهایی که کاربران بهشون دسترسی داشتن.
برای بررسی URLهای مشکوک، دانلود فایل و فعالیتهای غیرعادی مفیدن.
🔹️ لاگهای Email
اطلاعات مربوط به ارسال و دریافت ایمیل، فرستنده، گیرنده، لینکها و فایلهای پیوست.
برای بررسی حملات فیشینگ کاربرد زیادی دارن.
🔹️ لاگهای Cloud
فعالیت کاربران و سرویسها در محیطهای ابری؛ مثل ورود، تغییر تنظیمات و تغییر سطح دسترسی.
📌 نکته مهم:
برای تحلیل یک Incident معمولاً باید چند منبع لاگ رو کنار هم قرار بدیم.
مثلاً:
"Network Log" → ارتباط مشکوک رو پیدا میکنیم.
"Endpoint Log" → میفهمیم چه Processی این ارتباط رو ایجاد کرده.
"Authentication Log" → مشخص میکنیم چه کاربری درگیر بوده.
در واقع هر لاگ فقط یک بخش از ماجرا رو نشون میده.
@Socroot
🔥7
📌معادل ابزار های Sysinternals در Linux
@Socroot
اگر با مجموعه ابزارهای Sysinternals کار کرده باشید، احتمالاً موقع کار با Linux دنبال معادل بعضی از این ابزارها میگردید.
در این تصویر، تعدادی از ابزارهای پرکاربرد Sysinternals در کنار معادل Linux و کاربرد هرکدوم قرار گرفته.
از بررسی Process و ارتباطات شبکه گرفته تا لاگهای سیستم، Permission و تحلیل فایلها.
یک مرجع کوتاه برای زمانی که بین Windows و Linux جابهجا میشید.
@Socroot
🔥5
📌 توی مصاحبه SOC فقط جواب درست مهم نیست؛ نحوه فکر کردنت مهمه.
ممکنه ازت بپرسن:
«اگر یک Alert مربوط به Brute Force ببینی، چیکار میکنی؟»
لازم نیست سریع بگی:
«IP رو بلاک میکنم.»
بهتره روند فکریت رو توضیح بدی:
📌 چیزی که مصاحبهکننده میخواد ببینه اینه که:
وقتی یک Alert جلوت قرار میگیره، آیا چارچوب مشخصی برای تحلیل داری یا نه.
پس برای مصاحبه SOC، فقط حفظ کردن تعریفها کافی نیست؛ تمرین کن که طرز فکرت رو مرحلهبهمرحله توضیح بدی.
@Socroot
ممکنه ازت بپرسن:
«اگر یک Alert مربوط به Brute Force ببینی، چیکار میکنی؟»
لازم نیست سریع بگی:
«IP رو بلاک میکنم.»
بهتره روند فکریت رو توضیح بدی:
اول بررسی میکنم Alert چرا ایجاد شده.
بعد مبدأ تلاشها، کاربر، مقصد و بازه زمانی رو بررسی میکنم.
بررسی میکنم آیا بعد از تلاشهای ناموفق، ورود موفقی هم اتفاق افتاده یا نه.
بعد لاگهای مرتبط رو بررسی میکنم تا ببینم این فعالیت فقط یک مورد بوده یا بخشی از یک الگوی بزرگتر.
در نهایت بر اساس شواهد تصمیم میگیرم که False Positive هست، فعالیت مشکوکه یا نیاز به Escalation داره.
📌 چیزی که مصاحبهکننده میخواد ببینه اینه که:
وقتی یک Alert جلوت قرار میگیره، آیا چارچوب مشخصی برای تحلیل داری یا نه.
پس برای مصاحبه SOC، فقط حفظ کردن تعریفها کافی نیست؛ تمرین کن که طرز فکرت رو مرحلهبهمرحله توضیح بدی.
@Socroot
👍7👌1