مشکلات شایع Parsing لاگ‌های ویندوز در اسپلانک
بسیاری از مشکلات SOCها از مرحله Detection شروع نمی‌شود؛ بلکه از Data Quality و Parsing اشتباه لاگ‌ها آغاز می‌شود. یکی از رایج‌ترین مشکلات، تنظیم نادرست Sourcetype است که باعث می‌شود Field Extraction و Detectionها به‌درستی کار نکنند. انتخاب بین فرمت XML و Classic Event Format نیز اهمیت زیادی دارد؛ XML معمولاً ساختاریافته‌تر است و برای Detection مناسب‌تر عمل می‌کند.
یکی دیگر از مشکلات رایج، شکست در استخراج فیلدها است؛ به‌طوری‌که اطلاعاتی مانند User، Process Name یا Logon Type ممکن است به‌درستی Parse نشوند. مشکلات Timestamp نیز می‌توانند زمان واقعی رخداد را با زمان نمایش داده‌شده در Dashboard متفاوت کنند.
در محیط‌های چندزبانه، Localization نیز چالش مهمی است؛ زیرا تغییر زبان سیستم‌ها می‌تواند Regexها و Detection Content را خراب کند. همچنین Event Loss ناشی از Queue Full، مشکلات Forwarder یا Permissionها می‌تواند باعث از دست رفتن لاگ‌های حیاتی شود.
#MSSP #تجربه #هامون
👇👇

🔴خطر و راهکار کشف
روش کشف استفاده از آسیب پذیری مطرح در لینک زیر

در صورت استفاده مهاجم از آسیب پذیری لینک زیر ، اینها رو در SOC خواهیم دید
✴️
Many CLDAP Requests
High Volume UDP/389
Unknown Source → DC
✴️
lsass.exe crash
Unexpected reboot
Netlogon failure
✴️
DC reboot
Service interruption
Authentication failures
✅️
index=network dest_port=389 protocol=udp
| stats count by src_ip dest_ip
| where count > 100

⚫️اولویت دفاع
Patch Domain Controllerها
مانیتور UDP/389
مانیتور Crash / Reboot DC
Network Segmentation
انجام Hunt روی Netlogon anomalies

این از آن دسته CVEهاست که اگر سازمان Splunk ES، SOC یا MSSP دارد، نباید صرفاً Vulnerability Management بماند؛ باید Detection Use Case هم داشته باشد.

#MSSP #هامون


https://github.com/0xABCD01/CVE-2026-41089

قبل از سونامی!!


مهاجمان معمولاً پیش از آغاز رمزگذاری، اقدام به حذف نسخه‌های پشتیبان، پاک‌سازی Shadow Copyها، دستکاری یا غیرفعال‌سازی ابزارهای امنیتی و ایجاد تغییرات گسترده در فایل‌ها می‌کنند.

پس چه باید کرد ؟

طراحی Use Caseهای مستقل در SOC برای شناسایی Backup Deletion، Shadow Copy Deletion، EDR Tampering و Mass File Modification انجام دهید.

با این موارد سونامی را زودتر کشف کنید . هشدار را از چند دقیقه تا چند ساعت زودتر ایجاد کرده و فرصت ارزشمندی برای مهار حمله و کاهش خسارت فراهم کنید.

#MSSP #هامون

مقوله Detection as Code؛ به‌کارگیری انضباط مهندسی نرم‌افزار در تشخیص تهدیدات

خلاصه مقاله

نویسنده در لینک زیر معتقد است بسیاری از تیم‌های امنیتی هنوز قوانین تشخیص (Detection Rules) را به‌صورت دستی در SIEM تغییر می‌دهند؛ بدون کنترل نسخه، بازبینی همتا، تست یا امکان بازگشت به نسخه قبلی. نتیجه این وضعیت، تولید هشدارهای فراوان، خطاهای منطقی و وابستگی به «دانش شفاهی» افراد است. Detection as Code راهکاری برای حل این مشکل است.

در این رویکرد، قوانین تشخیص همانند کد نرم‌افزار مدیریت می‌شوند. هر قانون در Git ذخیره می‌شود، دارای تاریخچه تغییرات است، پیش از انتشار بازبینی می‌شود و از طریق CI/CD به محیط عملیاتی منتقل می‌گردد. هر قانون باید دارای متادیتا مانند نویسنده، تاریخ بازبینی، تکنیک‌های ATT&CK، منبع داده و نرخ خطای مورد انتظار باشد. همچنین برای هر قانون باید تست مثبت و منفی تعریف شود تا مشخص شود چه رویدادهایی باید شناسایی شوند و چه رویدادهایی نباید هشدار تولید کنند.

مقاله نقش مهم Sigma را به‌عنوان زبان استاندارد و مستقل از فروشنده توضیح می‌دهد. Sigma امکان نوشتن یک قانون واحد و تبدیل آن به فرمت‌های مختلف مانند Splunk SPL، Sentinel KQL و Elastic EQL را فراهم می‌کند. در نتیجه، وابستگی به یک SIEM خاص کاهش می‌یابد و مهاجرت بین پلتفرم‌ها آسان‌تر می‌شود.

برای تشخیص مبتنی بر فایل و حافظه نیز YARA و YARA-X معرفی می‌شوند. YARA-X با کارایی بالاتر و قابلیت ادغام بهتر با CI/CD، امکان اعتبارسنجی خودکار قوانین را فراهم می‌کند.

نویسنده تأکید می‌کند که Detection as Code بدون تله‌متری مناسب و داده‌های باکیفیت موفق نخواهد شد. اگر لاگ‌ها ناقص یا فیلدها نادرست باشند، حتی بهترین فرآیندهای مهندسی نیز ارزشی ایجاد نمی‌کنند. همچنین هر قانون باید مالک مشخص و فرآیند رسیدگی تعریف‌شده داشته باشد.

به‌عنوان نقطه شروع، پیشنهاد می‌شود تنها پنج قانون مهم سازمان انتخاب شوند، در Git قرار گیرند، برای آنها تست تعریف شود و یک خط لوله CI ساده ایجاد گردد. سپس به‌تدریج پوشش ATT&CK، قوانین YARA، Shadow Mode و استقرار خودکار اضافه شوند. تجربه سازمان‌ها نشان داده است که این رویکرد می‌تواند حجم هشدارها را به‌طور محسوسی کاهش داده و مدیریت تشخیص را قابل ممیزی، قابل حمل و پایدار کند.

جمع‌بندی

پیام اصلی مقاله این است که Detection Engineering دیگر یک فعالیت عملیاتی ساده نیست؛ بلکه یک مسئله مهندسی نرم‌افزار است. همان‌طور که زیرساخت‌ها به Infrastructure as Code تبدیل شدند، قوانین تشخیص نیز باید به Detection as Code تبدیل شوند تا قابلیت کنترل، آزمون، ممیزی و توسعه مستمر داشته باشند

#MSSP #هامون

ثبت نام دوره CISSP از طریق بله 09902857290
https://andreafortuna.org/2026/06/17/detection-as-code/

طراحی MSSP

این روزها درحال طراحی معماری MSSP در شرکت هامون هستیم‌ . نکاتی از اون رو براتون میگذارم

معماری Escalation در یک MSSP نباید بر اساس نوع قرارداد مشتری، بلکه بر مبنای شدت رخداد (Severity) طراحی شود. رخدادهای کم‌اهمیت می‌توانند از طریق تیکت و ایمیل مدیریت شوند، اما در رخدادهای بحرانی مانند باج‌افزار، تصاحب Domain Admin یا خروج گسترده اطلاعات، اطلاع‌رسانی فوری و چندکاناله باید برای همه مشتریان، صرف‌نظر از سطح قرارداد، انجام شود. همچنین، وجود مجوزهای از پیش توافق‌شده (Pre-Authorized Emergency Action) برای اجرای اقدامات حداقلی مهار، زمان واکنش را کاهش داده و مسئولیت حقوقی MSSP را شفاف می‌کند. بازبینی دوره‌ای فهرست تماس‌ها، مستندسازی دقیق همه تلاش‌های اطلاع‌رسانی و تعریف شفاف مسئولیت‌ها، از مهم‌ترین عوامل موفقیت این فرآیند و افزایش تاب‌آوری سایبری مشتریان هستند.

#هامون #MSSP

مقاله کامل را در لینک زیر در ویرگول بخوانید

https://vrgl.ir/Lbjko

چرا هنوز بسیاری از سازمان‌ها MSSP را فقط SOC as a Service می‌بینند؟

یکی از رایج‌ترین برداشت‌های نادرست در صنعت امنیت سایبری، همسان دانستن MSSP با SOC as a Service است. این نگاه از زمانی شکل گرفت که خدمات امنیتی عمدتاً به مانیتورینگ لاگ، تولید هشدار و پاسخ اولیه به رخداد محدود بود. در حالی که SOC تنها یکی از اجزای یک MSSP بالغ است.

امروزه ارزش واقعی یک MSSP در ارائه چرخه کامل امنیت نهفته است؛ از مشاوره و طراحی معماری امنیت، مدیریت آسیب‌پذیری و مقاوم‌سازی زیرساخت‌ها گرفته تا پیاده‌سازی و مدیریت EDR/XDR، امنیت ابری، Threat Hunting، Detection Engineering، پاسخ به رخداد، دیجیتال فارنزیک و ارتقای آمادگی سایبری سازمان.

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

#MSSP #SOC #DetectionEngineering #ThreatHunting #هامون

سرعت مهاجمان از سرعت سازمان‌ها بیشتر است

نمودار حملات Log4Shell (Log4j) نشان می‌دهد که تنها چند ساعت پس از افشای یک آسیب‌پذیری، موج گسترده‌ای از سوءاستفاده آغاز می‌شود؛ از حدود ۴۰ هزار حمله در ۱۲ ساعت نخست تا بیش از ۸۳۰ هزار حمله در کمتر از سه روز. این واقعیت نشان می‌دهد که مهاجمان منتظر انتشار Patch یا تصمیم‌گیری سازمان‌ها نمی‌مانند.

در چنین شرایطی، نقش یک MSSP بسیار فراتر از مانیتورینگ SOC است. یک MSSP بالغ باید بلافاصله دارایی‌های آسیب‌پذیر را شناسایی کند، Ruleهای تشخیص را در SIEM، EDR و NDR به‌روزرسانی نماید، از Threat Intelligence برای پایش تهدیدها استفاده کند، Threat Hunting فعال انجام دهد، Patchها را بر اساس ریسک اولویت‌بندی کند و به‌صورت 24×7 رخدادها را پایش و مدیریت کند.

در این رویکرد، شرکت هامون تنها ارائه‌دهنده SOC نیست، بلکه شریک امنیتی سازمان است که فاصله بین افشای آسیب‌پذیری و اجرای اقدامات دفاعی را به حداقل می‌رساند. ارزش واقعی یک MSSP در تبدیل سریع اطلاعات تهدید به اقدامات عملی و کاهش ریسک پیش از موفقیت مهاجم است.

#MSSP #هامون

آنتی تمپرینگ Anti-Tamper در ویندوز و EDR
دانشی از CISSP به روز به همراه #تجربه عملیاتی در سازمان حیاتی

روزبه نوروزی


مطالب ترم جدید CISSP رو آماده میکردم گفتم بخشی رو اینجا به روز بگذارم

نگاهی به آنتی تمپرینگ یعنی محافظت ویندوز از برنامه های درحال اجرا چیزی چون EDR. این قابلیت نتیجه همکاری سیستم‌عامل و محصول EDR است.

ویندوز چند قابلیت مهم در اختیار EDRها قرار می‌دهد:

مقوله Protected Process Light (PPL): اجازه می‌دهد برخی سرویس‌های امنیتی با سطح حفاظت بالاتری اجرا شوند تا فرآیندهای عادی نتوانند آن‌ها را متوقف یا دستکاری کنند.

بحث Kernel Patch Protection (PatchGuard): از دستکاری غیرمجاز هسته ویندوز جلوگیری می‌کند و مانع بسیاری از حملات کرنلی علیه EDR می‌شود.

قابلیت Virtualization-Based Security (VBS) و Hypervisor-Protected Code Integrity (HVCI): از یکپارچگی کد و حافظه محافظت کرده و اجرای کدهای غیرمجاز در سطح کرنل را سخت‌تر می‌کنند.

مقوله Code Integrity (CI) و Driver Signature Enforcement: فقط درایورهای معتبر و امضاشده را بارگذاری می‌کنند و مانع نصب بسیاری از درایورهای مخرب می‌شوند.

توانایی Windows Defender Tamper Protection: برای محافظت از خودِ Microsoft Defender طراحی شده و نمونه‌ای از استفاده مایکروسافت از همین زیرساخت‌هاست.


با این حال، این امکانات به‌تنهایی کافی نیستند. هر EDR باید مکانیزم Anti-Tamper اختصاصی خود را نیز پیاده‌سازی کند؛ مانند محافظت از سرویس‌ها، جلوگیری از حذف درایورها، حفاظت از فایل‌ها و کلیدهای رجیستری، اعتبارسنجی یکپارچگی (Integrity Check)، Self-Defense و بازیابی خودکار مؤلفه‌های غیرفعال‌شده.

از دیدگاه معماری، می‌توان گفت ویندوز نقش "زیرساخت امنیتی" را دارد و EDR نقش "استفاده‌کننده از این زیرساخت" را. هرچه EDR بهتر از قابلیت‌هایی مانند PPL، VBS و Code Integrity استفاده کند، مقاومت آن در برابر Process Tampering و تلاش برای غیرفعال‌سازی بیشتر خواهد بود.

#تجربه
در یکی از مشتریان شرکت #هامون که خدمت MSSP ارائه میدهیم بحث دور زدن EDR رو هم جزو خدمات ارائه کردیم . نتیجه دور خوردن EDR بود
در فاز اول تنظیمات ویندوز که در فوق اشاره کردم را اعمال کردیم تیم قرمز با همان تکنیک اولیه موفق به کشتن Agent محصول EDR نشد در مرحله بعد با تغییر تکنیک؛ تیم قرمز توانست دوباره EDR را دور بزند این بار در مکاتبه با وندور EDR توانستیم راهکار مقاوم سازی EDR را پیاده و محیط را امن کنیم.


✅️علم و کتاب CISSP و 🔆تجربیاتی از این دست ، همه در کلاس پنج شنبه ۲۵ تیرماه

واتس اپ و بله 09902857290

#MSSP #هامون #EDR #CISSP
#آکادمی_روزبه

پاشنه آشیل راه‌اندازی یک MSSP؛ فناوری مهم است، اما فرآیند مهم‌تر است

راه‌اندازی یک Managed Security Service Provider (MSSP) تنها به خرید SIEM، EDR یا استخدام تحلیلگران SOC محدود نمی‌شود. تجربه بسیاری از ارائه‌دهندگان خدمات امنیتی نشان می‌دهد که شکست یک MSSP معمولاً نه به دلیل ضعف فناوری، بلکه به دلیل ضعف در فرآیندها، مدل عملیاتی و مدیریت خدمات رخ می‌دهد.

یکی از مهم‌ترین چالش‌ها، نبود استانداردسازی خدمات است. اگر برای هر مشتری فرآیندها، قوانین همبستگی (Correlation Rules)، داشبوردها و گزارش‌ها از ابتدا طراحی شوند، هزینه ارائه خدمات به‌شدت افزایش یافته و مقیاس‌پذیری از بین می‌رود. چالش دیگر، تعریف نادرست SLA است. وعده زمان پاسخ غیرواقعی یا پوشش ۲۴×۷ بدون ظرفیت کافی، به‌سرعت باعث نارضایتی مشتریان خواهد شد.

از سوی دیگر، کیفیت خدمات MSSP مستقیماً به کیفیت داده‌های ورودی وابسته است. جمع‌آوری ناقص لاگ‌ها، نبود Visibility کافی و عدم یکپارچگی منابع اطلاعاتی، باعث می‌شود حتی بهترین تحلیلگران نیز نتوانند تهدیدها را به‌درستی شناسایی کنند.

در نهایت، موفقیت یک MSSP وابسته به سه عامل کلیدی است: افراد (People)، فرآیندها (Process) و فناوری (Technology). بسیاری از سازمان‌ها سرمایه‌گذاری خود را بر فناوری متمرکز می‌کنند، در حالی که مزیت رقابتی واقعی از طراحی فرآیندهای استاندارد، اتوماسیون عملیات امنیت و ایجاد یک مدل خدمات مقیاس‌پذیر به دست می‌آید. یک MSSP موفق، پیش از آنکه یک شرکت فناوری باشد، یک سازمان خدمات‌محور با فرآیندهای بالغ و قابل تکرار است.

Www.Haumoun.com
#MSSP #هامون

چرا SOC as a Service راهکار مناسبی برای ایران است؟

افزایش حملات سایبری، کمبود نیروی متخصص و هزینه بالای ایجاد مرکز عملیات امنیت اختصاصی، بسیاری از سازمان‌های ایرانی را با یک مسئله جدی روبه‌رو کرده است: چگونه می‌توان امنیت مستمر داشت، بدون آنکه یک SOC کامل و پرهزینه ایجاد کرد؟ پاسخ می‌تواند استفاده از خدمات‌ سرویسی SOC یا SOC as a Service باشد.

راه‌اندازی SOC شبانه‌روزی به تحلیل‌گران لایه یک، متخصصان لایه دو و سه، مهندسان کشف، کارشناسان پاسخ به رخداد، زیرساخت فنی و فرایندهای بالغ نیاز دارد. تأمین و نگهداری این مجموعه برای بسیاری از سازمان‌ها دشوار است. SOC as a Service با اشتراک‌گذاری منابع تخصصی میان چند مشتری، هزینه را کاهش داده و دسترسی به دانش و تجربه متنوع را امکان‌پذیر می‌کند.

این مدل برای سازمان‌های مستقر در شهرستان‌ها نیز ارزشمند است؛ زیرا می‌توان نیروی عملیاتی را در محل مشتری مستقر کرد و تحلیل‌های پیشرفته را از یک مرکز تخصصی ارائه داد. محدودیت‌های ناشی از تحریم، نبود پشتیبانی پایدار محصولات خارجی و تنوع فناوری‌ها نیز اهمیت یک تیم اشتراکی توانمند را افزایش می‌دهد.

البته SOC as a Service نباید به فروش SIEM و مشاهده هشدار محدود شود؛ موفقیت آن به مهندسی کشف، پایش منابع داده، مدیریت رخداد، پاسخ‌گویی سریع، گزارش مدیریتی و SLA قابل‌اندازه‌گیری وابسته است.

اگر چه آنچه بسیار مانع پیاده سازی این مدل است ، عدم اعتماد سازمانها و نظر حاکمیت بر مخالفت است ، لیکن نظر بنده بر آن است که در شرایط اقتصادی / خصمانه امروزه ،این مدل از لحاظ امنیت و ROI، بهترین راهکار سازمانی است.

#هامون
#MSSP #SOC_as_a_Service
#مرکز_عملیات_امنیت #soc

Haumoun

تربیت متخصص SOC هامون در دوره SOC T1

مقوله SOC as a Service؛ وقتی مرکز عملیات امنیت تبدیل به «سرویس» می‌شود

بحث SOC as a Service (SOCaaS) مدلی است که در آن سازمان به‌جای ساخت و اداره کامل یک Security Operations Center در داخل مجموعه، بخشی یا تمام قابلیت‌های SOC را از یک ارائه‌دهنده تخصصی دریافت می‌کند.

در این مدل، موضوع صرفاً خرید SIEM یا مانیتورینگ چند داشبورد نیست؛ بلکه مجموعه‌ای از People + Process + Technology به‌صورت یک سرویس مستمر ارائه می‌شود.

یک SOCaaS بالغ معمولاً شامل جمع‌آوری و پایش Log و Telemetry، مدیریت SIEM، تحلیل Alert، Triage توسط L1، تحلیل عمیق‌تر توسط L2/L3، Threat Intelligence، Detection Engineering، Threat Hunting، مدیریت Use Caseها، گزارش‌دهی و Escalation است.

بسته به قرارداد، Incident Response نیز می‌تواند بخشی از سرویس باشد.

مزیت مهم SOCaaS، دسترسی سازمان به تیم متخصص بدون نیاز به ایجاد کامل یک SOC داخلی 24×7 است. هزینه جذب و نگهداری Analyst، Detection Engineer و Threat Hunter کاهش می‌یابد و ارائه‌دهنده می‌تواند تجربه حاصل از مشاهده محیط‌های متعدد را وارد عملیات کند.

اما SOCaaS مساوی برون‌سپاری مسئولیت امنیت نیست. مالکیت Risk، تصمیمات حساس، پذیرش ریسک و Governance همچنان باید در سازمان باقی بماند. همچنین SLA، زمان تشخیص و Escalation، مالکیت داده، سطح دسترسی ارائه‌دهنده، Data Retention، محرمانگی و نحوه خروج از قرارداد باید دقیقاً مشخص شوند.

از نظر معماری نیز SOCaaS الزاماً Cloud SOC نیست. SIEM و داده‌ها می‌توانند کاملاً On-Premise نزد مشتری باقی بمانند، در حالی که تیم MSSP از راه دور عملیات SOC را انجام دهد.

بهترین نگاه به SOCaaS این است:

ما «SOC ایجاد نمیکنیم ؛ قابلیت مستمر کشف، تحلیل و مدیریت تهدید را به‌عنوان سرویس دریافت می‌کنیم.»


برای دریافت این سرویس با شرکت #هامون تماس حاصل فرمایید

Www.haumoun.com

#SOCaaS #SOC #MSSP #SIEM #DetectionEngineering #ThreatHunting #CyberSecurity #SecurityOperations #IncidentDetection #BlueTeam

https://conf.splunk.com/files/2024/recordings/SEC1579B.mp4

واحد #MSSP شرکت #هامون