🚨 Threat Intelligence
زمانی ارزش واقعی ایجاد می‌کند که مستقیماً وارد فرایند Detection و Correlation در SOC شود؛

نه اینکه فقط به‌عنوان یک لیست IOC در گوشه‌ای از SIEM ذخیره شود.
در این مقاله، اتصال عملیاتی و واقعی پورتال شاخص‌های آلودگی AFTA به Splunk ES را مرحله‌به‌مرحله بررسی کردیم؛

از ساخت Threat Intelligence Source گرفته تا تنظیم دقیق Parser، Regex، Field Mapping و رفع خطاهای رایج ingest.

📌 داخل مقاله بررسی شده:
• ساخت Threat Intelligence Feed در Splunk ES
• تنظیم صحیح Delimiting و Extracting Regex
• مقداردهی threat_key و threat_collection
• رفع خطای معروف
No observables or indicators found in file
• تست و دیباگ Threat Intel ingest
• بررسی lookup و correlation در ES
• سناریوهای IP، Domain و Hash Feed
• نکات عملیاتی واقعی برای SOCها

📖 مطالعه کامل مقاله:

https://soclib.ir/?p=15762

📢 کانال تخصصی SOC Library:
@soclibrary

#SOC
#SIEM
#Splunk
#ThreatIntelligence
#CyberSecurity
#DetectionEngineering
#SOCAnalyst

🔔 اطلاعیه مهم

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

در صورت بروز هرگونه مشکل یا نیاز به پیگیری، لطفاً از طریق آی‌دی پشتیبانی اعلام‌شده در کانال بله با ما در ارتباط باشید.

از همراهی و صبوری شما سپاسگزاریم.

آدرس کانال بله:

https://ble.ir/soclib

🚨 یکی از بزرگ‌ترین مشکلات حوزه امنیت سایبری در ایران، کمبود نیرو نیست...

بلکه «نبود زبان مشترک» برای تعریف نقش‌ها و مسیرهای شغلی است.



چند بار آگهی استخدامی دیده‌ایم که برای یک SOC Analyst انتظار مهارت‌های Threat Hunter، Incident Responder، Detection Engineer و حتی Red Team را هم داشته باشد؟

یا چند بار از دانشجویان و افراد تازه‌وارد شنیده‌ایم:

❓ برای ورود به SOC چه چیزهایی باید یاد بگیریم؟

❓ مسیر Threat Hunting چیست؟

❓ تفاوت Red Team و Penetration Testing چیست؟

❓ برای تبدیل شدن به CISO چه مهارت‌هایی نیاز دارم؟

به همین دلیل انتشار «چارچوب ملی سرمایه انسانی امنیت سایبری ایران» را می‌توان یک گام مهم برای استانداردسازی نقش‌های امنیت سایبری دانست.



📌 برخی از نقش‌های تعریف شده در این چارچوب:

🔹 CISO (مدیر ارشد امنیت اطلاعات)

🔹 Cybersecurity Architect

🔹 General Security Specialist

🔹 Penetration Tester & Vulnerability Analyst

🔹 Threat Hunter

🔹 Red Team Specialist

🔹 Incident Responder & Digital Forensics

🔹 SOC Analyst (Level 1, 2, 3)

🔹 Security Auditor

🔹 OT Security Specialist

🔹 Cybersecurity Trainer



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

✅ مأموریت شغلی

✅ وظایف اصلی

✅ دانش تخصصی موردنیاز

✅ مهارت‌های فنی موردنیاز

این دقیقاً همان چیزی است که سال‌ها در اکوسیستم امنیت سایبری کشور به آن نیاز داشتیم.



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



💬 به نظر شما در بازار کار امنیت سایبری ایران، کدام نقش بیشتر از همه دچار ابهام و سوءبرداشت شده است؟





آدرس کانال تخصصی SOC Library در پیامرسان بله:

https://ble.ir/soclib



کانال تخصصی SOC Library:

https://t.me/soclibrary



#CyberSecurity #SOC #ThreatHunting #RedTeam #BlueTeam #DFIR #SecurityArchitecture #CISO #SOCAnalyst #DetectionEngineering #IranCyberSecurity

🚨 چرا بسیاری از SOCها نفوذهای واقعی را از دست می‌دهند؟

یک حقیقت تلخ:
بسیاری از سازمان‌ها میلیون‌ها تومان برای Firewall، EDR، Antivirus و SIEM هزینه می‌کنند...

اما مهاجم همچنان ماه‌ها داخل شبکه باقی می‌ماند.
نه به این دلیل که بدافزار نامرئی است.
نه به این دلیل که مهاجم نابغه است.

بلکه چون بسیاری از تیم‌های امنیتی روی Alertها تمرکز می‌کنند، در حالی که مهاجم روی Command & Control (C2) تمرکز دارد.

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

پس از اجرای Payload، مهم‌ترین هدف مهاجم ایجاد یک کانال ارتباطی با سیستم قربانی است.
همان چیزی که ما آن را C2 Channel می‌نامیم.
مهاجم می‌تواند:
✅ بدافزار را تغییر دهد
✅ IPها را عوض کند
✅ دامنه‌ها را جابه‌جا کند
اما یک چیز را نمی‌تواند حذف کند:
📡 نیاز به برقراری ارتباط با سیستم آلوده
و همین ارتباط، ردپای شکار تهدید است.

🎯 در Threat Hunting به دنبال چه باشیم؟
1️⃣ Beaconing
سیستمی که هر چند ثانیه یا چند دقیقه یکبار به یک مقصد مشخص متصل می‌شود.
مثلاً:
🔹 هر ۳۰ ثانیه
🔹 هر ۶۰ ثانیه
🔹 هر ۵ دقیقه
این رفتار در بسیاری از بدافزارها و Frameworkهای C2 دیده می‌شود.
حتی اگر مهاجم از Jitter استفاده کند، معمولاً در بازه‌های زمانی طولانی الگوهای تکرارشونده قابل مشاهده هستند.

2️⃣ Long Connections
برخی از بدافزارها یک ارتباط را ساعت‌ها یا حتی روزها باز نگه می‌دارند.
در بسیاری از موارد فقط با بررسی Firewall State Table می‌توان این ارتباطات مشکوک را شناسایی کرد.

3️⃣ Protocol Anomalies
گاهی مهاجم سعی می‌کند خودش را شبیه ترافیک عادی نشان دهد.
اما اشتباهات کوچکی باقی می‌ماند:
🔹 User-Agent غیرمعمول
🔹 گواهی Self-Signed
🔹 HTTPS جعلی
🔹 TLS Handshakeهای غیرعادی
به تنهایی ارزش زیادی ندارند.
اما در کنار Beaconing می‌توانند سرنخ‌های فوق‌العاده‌ای برای شکار تهدید باشند.

4️⃣ DNS Hunting
یکی از جذاب‌ترین روش‌های شکار تهدید:
دنبال دامنه‌هایی بگردید که هزاران Query دریافت می‌کنند اما هیچ کاربری واقعاً از آن‌ها بازدید نمی‌کند.
چرا؟

چون بسیاری از کانال‌های C2 مبتنی بر DNS برای انتقال داده از Subdomainهای متعدد استفاده می‌کنند.
نکته‌ای که بسیاری از SOCها فراموش می‌کنند
اکثر سازمان‌ها برای این بخش‌ها فرآیند دارند:
✅ Prevention
✅ Detection
✅ Incident Response

اما تعداد کمی از آن‌ها فرآیند مشخصی برای پاسخ به این سؤال دارند:

"اگر تمام لایه‌های دفاعی ما شکست خورده باشند، چطور متوجه می‌شویم؟"
دقیقاً همینجاست که Threat Hunting ارزش واقعی خود را نشان می‌دهد.
هدف Threat Hunting پیدا کردن بدافزار نیست...
هدف پیدا کردن ردپایی است که مهاجم ناچار به برجا گذاشتن آن بوده است.

💬 شما در سازمان خود برای کشف C2 بیشتر روی کدام داده تکیه می‌کنید؟
🔹 DNS Logs
🔹 Proxy Logs
🔹 NetFlow
🔹 Firewall Logs
🔹 Zeek
🔹 EDR Telemetry

تجربه خودتان را به اشتراک بگذارید.



آدرس کانال تخصصی SOC Library در پیامرسان بله:
https://ble.ir/soclib

کانال تخصصی SOC Library در تلگرام :
https://t.me/soclibrary

🟨 آیا Splunk Cluster شما در زمان Incident واقعاً قابل اعتماد است؟

یکی از مشکلاتی که بسیاری از سازمان‌ها بعد از پیاده‌سازی Splunk Indexer Cluster با آن مواجه می‌شوند، نه Performance است و نه Storage...

بلکه Data Availability در زمان بحران است.

در ظاهر همه چیز سالم به نظر می‌رسد:

✅ Replication Factor تنظیم شده

✅ Search Factor برقرار است

✅ تمامی Peerها Online هستند

اما حادثه زمانی شروع می‌شود که یکی از Nodeها از مدار خارج می‌شود.

در این لحظه بسیاری از تیم‌ها متوجه می‌شوند بخشی از داده‌های مورد نیاز برای Investigation در وضعیت Searchable قرار ندارند یا Bucketها به درستی Replicate نشده‌اند.

و این دقیقاً زمانی اتفاق می‌افتد که SOC بیشترین نیاز را به داده‌ها دارد.

---

🎯 یک سناریوی واقعی:

فرض کنید تیم SOC در حال بررسی یک Incident مربوط به Data Exfiltration است.

مهاجم چند روز قبل وارد شبکه شده و حالا نیاز دارید:

🔹 لاگ‌های Firewall

🔹 DNS Logs

🔹 Proxy Logs

🔹 EDR Events

را با یکدیگر Correlate کنید.

اما یکی از Indexerها دچار مشکل شده و Cluster وارد حالت Fixup شده است.

در نتیجه:

❌ بخشی از Bucketها هنوز قابل جستجو نیستند

❌ برخی Searchها ناقص برمی‌گردند

❌ Timeline حادثه به درستی بازسازی نمی‌شود

❌ تحلیلگر SOC تصور می‌کند داده‌ای وجود ندارد

در حالی که مشکل از حمله نیست...

مشکل از معماری SIEM است.

---

🔍 یکی از مهم‌ترین مواردی که مدیران Splunk باید به صورت مستمر پایش کنند:

• Replication Factor Status

• Search Factor Status

• Bucket Fixup Activities

• Excess Buckets

• Orphaned Buckets

• Cluster Health

• Peer Synchronization

---

بسیاری از سازمان‌ها Availability را فقط برای سرویس در نظر می‌گیرند.

اما از دید SOC یک سؤال مهم‌تر وجود دارد:

> آیا در زمان Incident، تمام شواهد امنیتی همچنان در دسترس خواهند بود؟

زیرا SIEM زمانی ارزش دارد که در بدترین روز سازمان نیز بتوان به داده‌های آن اعتماد کرد.

💬 اگر در محیط Splunk Cluster کار کرده‌اید:

بزرگ‌ترین چالش شما چه بوده است؟

Replication؟
Storage؟
Fixup؟
Rolling Upgrade؟
یا Search Performance؟


آدرس کانال تخصصی SOC Library در پیامرسان بله:
https://ble.ir/soclib

کانال تخصصی SOC Library در تلگرام :
https://t.me/soclibrary

#Splunk #SplunkEnterprise #SplunkCluster #IndexerCluster #SIEM #SOC #CyberSecurity #ThreatHunting #DetectionEngineering #BlueTeam #DFIR

آیا سازمان شما واقعاً در برابر اختلالات سایبری تاب‌آور است؟

سال‌هاست که در حوزه امنیت اطلاعات درباره مفاهیمی مانند امنیت سایبری (Cyber Security)، مدیریت ریسک و تداوم کسب‌وکار (BCP) صحبت می‌کنیم.

اما امروز سؤال اصلی دیگر این نیست که:

"چقدر امن هستید؟"

بلکه این است که:

"اگر فردا یک حمله سایبری یا اختلال بزرگ رخ دهد، آیا کسب‌وکار شما همچنان قادر به ادامه فعالیت خواهد بود؟"

دقیقاً همین موضوع، فلسفه شکل‌گیری DORA (Digital Operational Resilience Act) است؛ چارچوبی که توسط اتحادیه اروپا برای افزایش تاب‌آوری عملیاتی دیجیتال در صنعت مالی تدوین شده است. این چارچوب تنها بر پیشگیری از حملات تمرکز ندارد، بلکه سازمان‌ها را ملزم می‌کند توانایی خود را در پیشگیری، شناسایی، پاسخ، بازیابی و یادگیری از رخدادهای سایبری به صورت ساختاریافته ارزیابی و تقویت کنند.

آنچه DORA را متمایز می‌کند، نگاه جامع آن به تاب‌آوری است. این چارچوب پنج حوزه کلیدی را پوشش می‌دهد:

✅ حاکمیت و مدیریت ریسک فناوری اطلاعات و ارتباطات (ICT)

✅ مدیریت، طبقه‌بندی و گزارش‌دهی رخدادهای امنیتی

✅ آزمون‌های منظم تاب‌آوری دیجیتال

✅ مدیریت ریسک تأمین‌کنندگان و اشخاص ثالث

✅ اشتراک‌گذاری اطلاعات و هوشمندی تهدیدات سایبری

از نگاه من، مهم‌ترین پیام DORA این است که:

امنیت سایبری دیگر صرفاً مسئولیت تیم Security نیست.

تاب‌آوری دیجیتال به موضوعی در سطح هیئت‌مدیره، مدیریت ارشد، مدیریت ریسک، فناوری اطلاعات، حسابرسی داخلی و حتی تأمین‌کنندگان خدمات تبدیل شده است.

به همین دلیل است که امروز سازمان‌های پیشرو، علاوه بر پیاده‌سازی کنترل‌های امنیتی، روی موضوعاتی مانند:

* مدیریت ریسک مبتنی بر کسب‌وکار
* سنجش بلوغ امنیت
* آمادگی پاسخ به رخداد
* آزمون‌های Red Team و Threat-Led Penetration Testing
* مدیریت ریسک زنجیره تأمین
* Continuous Monitoring

سرمایه‌گذاری جدی انجام می‌دهند.

به‌تازگی فرصت مطالعه ترجمه فارسی «چارچوب قانونی تاب‌آوری عملیاتی دیجیتال (DORA)» را داشتم که توسط تیم حسابرسی فناوری اطلاعات بانک ملت تهیه شده است. این مستند علاوه بر معرفی مفاهیم DORA، راهنمای عملی، چک‌لیست‌های کنترلی و رویکردهای اجرایی مناسبی برای سازمان‌ها ارائه می‌دهد.

به نظر من، حتی اگر سازمان شما مشمول مستقیم DORA نباشد، آشنایی با این چارچوب می‌تواند دیدگاه ارزشمندی درباره آینده امنیت سایبری، مدیریت ریسک و تاب‌آوری دیجیتال ارائه کند.

نظر شما چیست؟

آیا سازمان‌ها باید همچنان فقط روی Cyber Security تمرکز کنند، یا زمان آن رسیده که Digital Operational Resilience را به یکی از شاخص‌های اصلی بلوغ امنیت تبدیل کنیم؟


آدرس کانال تخصصی SOC Library در پیامرسان بله:
https://ble.ir/soclib

کانال تخصصی SOC Library در تلگرام :
https://t.me/soclibrary

🟨 بیشتر متخصصان SOC ساعت‌ها وقت صرف دیدن دوره‌های آموزشی می‌کنند... اما چند نفر مستندات رسمی Vendorها را مطالعه می‌کنند؟

واقعیت این است که بسیاری از قابلیت‌های جدید، Best Practiceها و حتی روش‌های Detection، قبل از اینکه وارد دوره‌های آموزشی، کتاب‌ها یا ویدیوهای یوتیوب شوند، ابتدا در *Documentation رسمی* منتشر می‌شوند.

اگر هدف شما تبدیل شدن به یک *SOC Analyst، Detection Engineer یا Splunk Engineer حرفه‌ای* است، مطالعه مستندات رسمی باید بخشی از برنامه یادگیری روزانه‌تان باشد.

به عنوان مثال، اگر با Splunk کار می‌کنید، مستندات زیر ارزش دنبال کردن دارند:

📘 Splunk Enterprise Security (ES)

📘 Splunk Security Content (ESCU)

📘 Splunk Lantern

📘 Splunk SOAR Documentation

📘 Splunk Release Notes

اما این موضوع فقط به Splunk محدود نمی‌شود.

اگر با سایر SIEMها کار می‌کنید، پیشنهاد می‌کنم مستندات رسمی این محصولات را نیز به‌صورت منظم دنبال کنید:

🔹 Microsoft Sentinel

🔹 Google Security Operations (Chronicle)

🔹 Elastic Security

🔹 IBM QRadar

🔹 Cortex XSIAM

چرا؟

چون مستندات رسمی فقط نحوه نصب یک محصول را توضیح نمی‌دهند؛ بلکه بهترین منبع برای یادگیری *Best Practiceها، معماری، Use Caseها، Detectionها، روش‌های پیاده‌سازی، محدودیت‌ها و قابلیت‌های جدید* هستند.

تجربه نشان داده است که بسیاری از متخصصان، ساعت‌ها زمان صرف دوره‌های آموزشی می‌کنند، اما شاید ماه‌ها از آخرین باری که مستندات رسمی Vendor مورد استفاده‌شان را مطالعه کرده‌اند گذشته باشد.

در حالی که *به‌روزترین دانش همیشه از Documentation رسمی شروع می‌شود.*

💬 *شما آخرین بار چه زمانی مستندات رسمی محصولی که هر روز با آن کار می‌کنید را مطالعه کردید؟*

اگر فقط قرار باشد یک Documentation را هر هفته دنبال کنید، انتخاب شما کدام است؟

------------------------
اگر می‌خواهید همیشه به جدیدترین Documentationها، منابع تخصصی و محتوای آموزشی دسترسی داشته باشید، از طریق وب‌سایت و کانال‌های رسمی ما همراه باشید:

🌐 وب‌سایت: https://soclib.ir

📘 کانال تخصصی SOC Library در پیام‌رسان بله:
https://ble.ir/soclib

📢 کانال تخصصی SOC Library در تلگرام:
https://t.me/soclibrary