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
📌 یک نکته مهم برای هر تیم SOC: همه چیز نباید از صفر ساخته بشه.
اگر یک تحلیلگر برای بررسی هر اتفاق، دوباره از اول دنبال Query، لاگ و روش بررسی بگرده، زمان زیادی از تیم گرفته میشه.
بهتره برای موارد پرتکرار، یک سری Runbook داشته باشید.
مثلاً برای:
🔹️ داخل هر Runbook مشخص باشه:
📌 اینطوری تحلیلگر به جای اینکه هر بار روش کار رو از خودش بسازه، یک مسیر مشخص برای بررسی داره.
و Runbook خوب، تجربه یک تحلیلگر رو تبدیل به یک فرآیند قابل استفاده برای کل تیم میکنه.
@Socroot
اگر یک تحلیلگر برای بررسی هر اتفاق، دوباره از اول دنبال Query، لاگ و روش بررسی بگرده، زمان زیادی از تیم گرفته میشه.
بهتره برای موارد پرتکرار، یک سری Runbook داشته باشید.
مثلاً برای:
- بررسی Brute Force
- بررسی Login مشکوک
- بررسی اجرای PowerShell
- بررسی ارتباط با IP مشکوک
- بررسی Malware روی Endpoint
- بررسی Account مشکوک
🔹️ داخل هر Runbook مشخص باشه:
چه چیزهایی باید بررسی بشه؟
چه لاگهایی لازمه؟
چه Queryهایی باید اجرا بشه؟
چه زمانی مورد بسته بشه؟
چه زمانی باید به Tier 2 ارجاع داده بشه؟
📌 اینطوری تحلیلگر به جای اینکه هر بار روش کار رو از خودش بسازه، یک مسیر مشخص برای بررسی داره.
و Runbook خوب، تجربه یک تحلیلگر رو تبدیل به یک فرآیند قابل استفاده برای کل تیم میکنه.
@Socroot
👏8👍1
📌 اگر مهاجم بودی، اول کجا رو هدف میگرفتی؟
فرض کن وارد یک شبکه شدی.
یک سیستم معمولی پیدا کردی، اما هنوز دسترسی خاصی نداری.
⚠️ اینجا چیزی که برای مهاجم مهمه، فقط اجرای یک ابزار نیست؛ جمعآوری اطلاعات و پیدا کردن مسیر بعدیه.
از طرف SOC هم دقیقاً همین رفتارها ارزش بررسی دارن.
📌 نکته جالب اینجاست:
مهاجم قبل از اینکه کاری خرابکارانه انجام بده، معمولاً اول سعی میکنه بفهمه کجاست و چه چیزهایی در اختیارشه.
پس گاهی برای پیدا کردن یک حمله، لازم نیست منتظر خرابکاری بمونی؛
مرحله شناخت محیط هم میتونه سرنخ مهمی باشه.
@Socroot
فرض کن وارد یک شبکه شدی.
یک سیستم معمولی پیدا کردی، اما هنوز دسترسی خاصی نداری.
حالا باید بفهمی:
چه کاربرهایی روی این سیستم هستن؟
این سیستم به کجاها دسترسی داره؟
چه سرویسهایی فعال هستن؟
چه سیستمهای دیگهای باهاش ارتباط دارن؟
آیا Credential یا فایل حساسی روی سیستم وجود داره؟
⚠️ اینجا چیزی که برای مهاجم مهمه، فقط اجرای یک ابزار نیست؛ جمعآوری اطلاعات و پیدا کردن مسیر بعدیه.
از طرف SOC هم دقیقاً همین رفتارها ارزش بررسی دارن.
مثلاً ترکیب:
"whoami"
"ipconfig"
"net user"
"netstat"
"nltest"
اگر این دستورات پشت سر هم و در شرایط غیرعادی اجرا بشن، میتونه نشون بده کسی داره محیط رو میشناسه.
📌 نکته جالب اینجاست:
مهاجم قبل از اینکه کاری خرابکارانه انجام بده، معمولاً اول سعی میکنه بفهمه کجاست و چه چیزهایی در اختیارشه.
پس گاهی برای پیدا کردن یک حمله، لازم نیست منتظر خرابکاری بمونی؛
مرحله شناخت محیط هم میتونه سرنخ مهمی باشه.
@Socroot
💯7❤1
📌 چطور بفهمم یک SOC Tier 1 واقعاً چطور کار میکنه؟
یکی از مشکلات رایج اینه که خیلی چیزها رو درباره SOC یاد میگیری، ولی وقتی وارد محیط واقعی میشی نمیدونی دقیقاً باید چه کاری انجام بدی.
برای اینکه روند کاری Tier 1 رو یاد بگیری، فقط مطالعه کافی نیست؛ باید فرآیند عملیاتی رو تمرین کنی.
📌 برای تمرین هم میتونی سناریوهای واقعی برای خودت بسازی:
Brute Force → بررسی → جمعآوری شواهد → تصمیم → ثبت → Escalation
PowerShell مشکوک → بررسی Process Tree → بررسی Command Line → Timeline → تصمیم
ارتباط با IP مشکوک → پیدا کردن Host → پیدا کردن Process → بررسی User → مستندسازی
وقتی چند بار این سناریوها رو از ابتدا تا انتها انجام بدی، کمکم متوجه میشی که کار Tier 1 فقط «دیدن Alert» نیست.
پس Tier 1 یعنی یک فرآیند مشخص برای تشخیص، بررسی، مستندسازی و ارجاع رخدادها.
@Socroot
یکی از مشکلات رایج اینه که خیلی چیزها رو درباره SOC یاد میگیری، ولی وقتی وارد محیط واقعی میشی نمیدونی دقیقاً باید چه کاری انجام بدی.
برای اینکه روند کاری Tier 1 رو یاد بگیری، فقط مطالعه کافی نیست؛ باید فرآیند عملیاتی رو تمرین کنی.
مثلاً باید بدونی:
🔹 Alert چطور ایجاد میشه و چرا ایجاد شده
🔹 چطور Alert رو Triage کنی
🔹 چه لاگهایی رو برای بررسی پیدا کنی
🔹 چطور User، Host، IP و Process رو بررسی کنی
🔹 چطور Timeline بسازی
🔹 چطور IOC رو بررسی کنی
🔹 چطور False Positive رو تشخیص بدی
🔹 چطور Severity و Priority رو تعیین کنی
🔹 چطور Case یا Ticket ایجاد و مستند کنی
🔹 چه زمانی باید موضوع رو به Tier 2 Escalate کنی
🔹 بعد از Escalation چه اطلاعاتی باید تحویل بدی
🔹 چطور وضعیت Log Sourceها و Agentها رو بررسی کنی
🔹 چطور Pending Caseها و Incidentهای باز رو پیگیری کنی
📌 برای تمرین هم میتونی سناریوهای واقعی برای خودت بسازی:
Brute Force → بررسی → جمعآوری شواهد → تصمیم → ثبت → Escalation
PowerShell مشکوک → بررسی Process Tree → بررسی Command Line → Timeline → تصمیم
ارتباط با IP مشکوک → پیدا کردن Host → پیدا کردن Process → بررسی User → مستندسازی
پس Tier 1 یعنی یک فرآیند مشخص برای تشخیص، بررسی، مستندسازی و ارجاع رخدادها.
@Socroot
👏5
Soc Root
📌 چطور بفهمم یک SOC Tier 1 واقعاً چطور کار میکنه؟ یکی از مشکلات رایج اینه که خیلی چیزها رو درباره SOC یاد میگیری، ولی وقتی وارد محیط واقعی میشی نمیدونی دقیقاً باید چه کاری انجام بدی. برای اینکه روند کاری Tier 1 رو یاد بگیری، فقط مطالعه کافی نیست؛ باید…
پیاده سازی این موضوع هم واقعا کاری نداره
یه vm لازمه
یه SIEM که روی سیستم اصلی بالا هستش
حالا حتما نیاز نیست SIEM باشه ، شما با Sysmon هم میتونی کارتو انجام بدی.
ولی SIEM باشه بهتره .
@Socroot
یه vm لازمه
یه SIEM که روی سیستم اصلی بالا هستش
حالا حتما نیاز نیست SIEM باشه ، شما با Sysmon هم میتونی کارتو انجام بدی.
ولی SIEM باشه بهتره .
@Socroot
👍4
#خارج_از_امنیت
📌 یه سایت برای پیدا کردن APIهای آماده
🔗 Public APIs
برای پیدا کردن ایده برای پروژههای برنامهنویسی هم جالبه.
@Socroot
📌 یه سایت برای پیدا کردن APIهای آماده
🔗 Public APIs
اگر برای پروژهات دنبال API هستی ولی نمیخوای از صفر یک سرویس بسازی، این سایت مجموعهای از APIهای عمومی رو دستهبندی کرده.
از آبوهوا و دادههای جغرافیایی گرفته تا بازی، فیلم، دادههای علمی و سرویسهای مختلف.
برای پیدا کردن ایده برای پروژههای برنامهنویسی هم جالبه.
@Socroot
❤4🔥1
📌 گاهی یک حساب کاربری، از یک Malware خطرناکتره
فرض کن یک مهاجم به Credential یک کاربر دسترسی پیدا کرده.
لازم نیست فوراً Malware اجرا کنه.
📌 به همین دلیل در امنیت، فقط دنبال فایل و Malware نباش.
گاهی خودِ Account تبدیل به مسیر حرکت مهاجم در شبکه میشه.
@Socroot
فرض کن یک مهاجم به Credential یک کاربر دسترسی پیدا کرده.
لازم نیست فوراً Malware اجرا کنه.
میتونه با همون حساب وارد سیستمهای دیگه بشه، به منابع دسترسی پیدا کنه و کمکم سطح دسترسی خودش رو افزایش بده.
اینجاست که بررسی رفتار حسابهای کاربری اهمیت پیدا میکنه.
مثلاً:
ورود از یک سیستم جدید
⬇️
دسترسی به یک سرور غیرمعمول
⬇️
تلاش برای دسترسی به منابع حساس
⬇️
تغییر سطح دسترسی
هرکدوم از این موارد ممکنه بهتنهایی عادی باشه، اما کنار هم میتونن یک الگوی مهم بسازن.
📌 به همین دلیل در امنیت، فقط دنبال فایل و Malware نباش.
گاهی خودِ Account تبدیل به مسیر حرکت مهاجم در شبکه میشه.
@Socroot
👏6👍2❤1
Soc Root
سخت تر از برسی و تحلیل Soc ، برنامه ریزی برای انتخاب واحد دانشگاهِ .
بالاخره تموم شد .
❤1🔥1
📌 یک نکته مهم درباره دسترسیها
یکی از اشتباهات خطرناک در محیطهای سازمانی اینه که دسترسیها بعد از تغییر وظایف افراد، همچنان باقی بمونن.
⚠️ اصل سادهای وجود داره:
هر کاربر باید فقط به منابعی دسترسی داشته باشه که برای انجام وظیفهاش نیاز داره.
این همون مفهوم Least Privilege هست.
@Socroot
یکی از اشتباهات خطرناک در محیطهای سازمانی اینه که دسترسیها بعد از تغییر وظایف افراد، همچنان باقی بمونن.
مثلاً کاربری که قبلاً به چند سرور دسترسی داشته، بعد از تغییر سمت یا مسئولیتش هنوز همون دسترسیها رو داشته باشه.
با گذشت زمان، این دسترسیهای اضافی جمع میشن و سطح ریسک رو بالا میبرن.
برای همین باید بهصورت دورهای بررسی بشه:
چه کسی به چه چیزی دسترسی داره؟
آیا این دسترسی هنوز لازمه؟
آخرین استفاده از این دسترسی چه زمانی بوده؟
آیا سطح دسترسی با وظیفه فعلی کاربر متناسبه؟
⚠️ اصل سادهای وجود داره:
هر کاربر باید فقط به منابعی دسترسی داشته باشه که برای انجام وظیفهاش نیاز داره.
این همون مفهوم Least Privilege هست.
@Socroot
👌5❤2
یه PDF با عنوان ۴۰۰ نکته کاربردی +Security همراه با یکی از اساتیدم براتون آماده کردیم
سعی شده تمام موارد داخل این ۴۰۰ نکته پوشش داده بشه .
یکم دیگه همینجا ارسال میکنم براتون و امیدوارم براتون مفید باشه ❤️🙏🏻
سعی شده تمام موارد داخل این ۴۰۰ نکته پوشش داده بشه .
یکم دیگه همینجا ارسال میکنم براتون و امیدوارم براتون مفید باشه ❤️🙏🏻
❤16👏3
400 security+ tips.pdf
466.9 KB
📘 ۴۰۰ نکته +Security تکمیل شد! 🛡
مجموعهای از مهمترین مفاهیم و نکات کلیدی امنیت سایبری برای مرور سریع و یادگیری بهتر.
پایان این کتاب، شروع مسیر یادگیری عمیقتر در دنیای Cyber Security است.
@Socroot
مجموعهای از مهمترین مفاهیم و نکات کلیدی امنیت سایبری برای مرور سریع و یادگیری بهتر.
پایان این کتاب، شروع مسیر یادگیری عمیقتر در دنیای Cyber Security است.
@Socroot
🔥15❤6
Soc Root
400 security+ tips.pdf
در کنار اینکه اینو مطالعه میکنید یه همتی کنید بشیم ۵۰۰ نفر ❤️😂
🤝11❤6
📌یک بار برای همیشه ؛ SOC و NOC یکی نیستن؛ حتی اگر بعضی وظایفشون به هم نزدیک باشه.
توی بعضی مجموعهها بهخاطر کمبود نیرو، وظایف NOC و SOC با هم ترکیب میشن و یک نفر باید همزمان چندین کار متفاوت انجام بده.
اما این موضوع میتونه روی کیفیت هر دو تیم تأثیر بذاره.
وظیفه اصلی NOC بیشتر روی دسترسپذیری و عملکرد زیرساخت متمرکزه؛ مثل:
در مقابل، SOC روی امنیت تمرکز داره؛
مثل:
🔹️ مشکل از جایی شروع میشه که کارهای عملیاتی NOC باعث بشن تمرکز تحلیلگر SOC از وظایف امنیتی خودش خارج بشه.
مثلاً اگر کارشناس SOC بخش زیادی از شیفتش رو صرف بررسی قطعی لینک، مشکلات سرویس یا Performance تجهیزات کنه، طبیعتاً زمان و تمرکز کمتری برای تحلیل امنیتی باقی میمونه.
⚠️ البته بین این دو تیم ارتباط و همکاری کاملاً ضروریه.
📌 در نهایت:
NOC → پایداری و عملکرد زیرساخت
SOC → امنیت و شناسایی و پاسخ به تهدیدها
همکاری لازم است؛
اختلاط وظایف نه.
@Socroot
توی بعضی مجموعهها بهخاطر کمبود نیرو، وظایف NOC و SOC با هم ترکیب میشن و یک نفر باید همزمان چندین کار متفاوت انجام بده.
اما این موضوع میتونه روی کیفیت هر دو تیم تأثیر بذاره.
وظیفه اصلی NOC بیشتر روی دسترسپذیری و عملکرد زیرساخت متمرکزه؛ مثل:
- بررسی وضعیت تجهیزات شبکه
- بررسی قطعی سرویسها
- Monitoring زیرساخت
- بررسی Performance
- پیگیری مشکلات ارتباطی و سرویسها
در مقابل، SOC روی امنیت تمرکز داره؛
مثل:
- بررسی رخدادهای امنیتی
- تحلیل لاگها
- Triage و Investigation
- بررسی رفتارهای مشکوک
- Incident Response
- Threat Intelligence
🔹️ مشکل از جایی شروع میشه که کارهای عملیاتی NOC باعث بشن تمرکز تحلیلگر SOC از وظایف امنیتی خودش خارج بشه.
مثلاً اگر کارشناس SOC بخش زیادی از شیفتش رو صرف بررسی قطعی لینک، مشکلات سرویس یا Performance تجهیزات کنه، طبیعتاً زمان و تمرکز کمتری برای تحلیل امنیتی باقی میمونه.
⚠️ البته بین این دو تیم ارتباط و همکاری کاملاً ضروریه.
📌 در نهایت:
NOC → پایداری و عملکرد زیرساخت
SOC → امنیت و شناسایی و پاسخ به تهدیدها
اختلاط وظایف نه.
@Socroot
❤2🔥1
📌 از هر Asset توی شبکه چه لاگی باید بگیریم؟ 🤔
یکی از اشتباهات رایج توی SOC اینه که فکر کنیم:
«هرچی لاگ بیشتر، بهتر!»
نه لزوماً.
مهم اینه بدونیم از هر دارایی چه لاگی و برای چه Use Caseای نیاز داریم.
مثلاً:
اما یه نکته مهمتر:
قبل از جمع کردن هر لاگ، باید بدونیم قراره باهاش چه چیزی رو Detect کنیم.
مثلاً اگر Use Case ما تشخیص اجرای مشکوک PowerShell باشه، فقط داشتن Windows Event Log کافی نیست؛ باید Eventهای مرتبط با Process و PowerShell رو هم درست Collect کنیم.
🎯 پس سؤال درست این نیست:
❌ «از این Asset چه لاگهایی بگیریم؟»
بلکه:
✅ «برای این Asset چه Threatهایی مهمه و برای Detect کردنشون چه لاگهایی لازم داریم؟»
این دیدگاه باعث میشه هم حجم لاگهای اضافی کمتر بشه، هم Visibility واقعی SOC بیشتر بشه.
@Socroot
یکی از اشتباهات رایج توی SOC اینه که فکر کنیم:
«هرچی لاگ بیشتر، بهتر!»
نه لزوماً.
مهم اینه بدونیم از هر دارایی چه لاگی و برای چه Use Caseای نیاز داریم.
مثلاً:
🖥️ Windows Endpoint
- Login / Logout
- Process Creation
- PowerShell
- File & Registry Changes
- USB Events
- Windows Security Events
- Network Connections
🐧 Linux
- Authentication
- SSH
- sudo
- Process Execution
- System Events
- Network Connections
- Audit Logs
🌐 Firewall
- Allowed / Denied Traffic
- VPN
- NAT
- Admin Login
- Configuration Changes
- IPS/AV Events
- Web Filtering
🔀 Switch / Router
- Authentication
- Configuration Changes
- Interface Status
- Routing Changes
- ACL Events
- DHCP / DNS Events
- NetFlow
🌍 Web Server
- Access Logs
- Error Logs
- Authentication
- HTTP Methods
- Status Codes
- Client IP
- User-Agent
🗄️ Database
- Login / Logout
- Failed Authentication
- Query Activity
- Privilege Changes
- Account Changes
- Audit Logs
📧 Email Server
- Login
- Mail Send/Receive
- Attachment Events
- URL Clicks
- Authentication Failures
- Admin Changes
اما یه نکته مهمتر:
قبل از جمع کردن هر لاگ، باید بدونیم قراره باهاش چه چیزی رو Detect کنیم.
مثلاً اگر Use Case ما تشخیص اجرای مشکوک PowerShell باشه، فقط داشتن Windows Event Log کافی نیست؛ باید Eventهای مرتبط با Process و PowerShell رو هم درست Collect کنیم.
🎯 پس سؤال درست این نیست:
❌ «از این Asset چه لاگهایی بگیریم؟»
بلکه:
✅ «برای این Asset چه Threatهایی مهمه و برای Detect کردنشون چه لاگهایی لازم داریم؟»
این دیدگاه باعث میشه هم حجم لاگهای اضافی کمتر بشه، هم Visibility واقعی SOC بیشتر بشه.
@Socroot
🔥6
📌درکل Runbook و Playbook توی SOC چه فرقی دارن؟
این دوتا رو خیلی وقتها با هم اشتباه میگیرن، ولی تفاوتشون خیلی سادهست.
در اصل Playbook میگه وقتی با یک سناریوی امنیتی مواجه شدیم، کلاً چه مسیری رو طی کنیم.
اما Runbook میگه هر کدوم از این کارها رو دقیقاً چطور انجام بدیم.
⚠️ پس خیلی خلاصه:
Playbook = مسیر کلی کار
Runbook = روش انجام یک کار مشخص
در یک SOC درستوحسابی، این دوتا کنار هم استفاده میشن تا تحلیلگر وسط یک Incident ندونه «خب حالا باید چیکار کنم؟»
@Socroot
این دوتا رو خیلی وقتها با هم اشتباه میگیرن، ولی تفاوتشون خیلی سادهست.
در اصل Playbook میگه وقتی با یک سناریوی امنیتی مواجه شدیم، کلاً چه مسیری رو طی کنیم.
مثلاً برای یک Ransomware مشخص میکنه:
اول وضعیت رو بررسی کنیم، بعد شواهد لازم رو جمع کنیم، محدوده درگیری رو مشخص کنیم، سیستمهای درگیر رو مهار کنیم و در ادامه مراحل پاکسازی و بازگردانی رو انجام بدیم.
اما Runbook میگه هر کدوم از این کارها رو دقیقاً چطور انجام بدیم.
مثلاً:
چطور Endpoint رو ایزوله کنیم؟
چطور لاگ جمع کنیم؟
چطور Process Tree رو بررسی کنیم؟
چطور Hash یک فایل رو بررسی کنیم؟
⚠️ پس خیلی خلاصه:
Playbook = مسیر کلی کار
Runbook = روش انجام یک کار مشخص
در یک SOC درستوحسابی، این دوتا کنار هم استفاده میشن تا تحلیلگر وسط یک Incident ندونه «خب حالا باید چیکار کنم؟»
@Socroot
👏6