یک هشدار ساده که تبدیل به Incident شد...ساعت 02:17 بامداد، SIEM چندین رویداد *4625 (Failed Logon) را از یک سرور مالی ثبت کرد.
در نگاه اول چیز خاصی نبود؛ چند تلاش ناموفق برای ورود.
اما چند دقیقه بعد یک 4624 (Successful Logon) از همان Source IP مشاهده شد.
تحلیلگر SOC تصمیم گرفت بررسی را ادامه دهد...
در ادامه لاگها مشخص شد که بلافاصله پس از ورود موفق، یک رویداد 4672 (Special Privileges Assigned)* برای همان حساب ثبت شده است.یعنی کاربر با دسترسیهای سطح بالا وارد سیستم شده بود.
چند دقیقه بعد:
Event ID 4698یک Scheduled Task جدید ایجاد شد.سپس:
Event ID 4688فرآیند PowerShell اجرا شد.و در نهایت:
Event ID 4104Script Block Logging نشان داد که PowerShell با دستورات مشکوک برای دانلود و اجرای فایل از یک منبع خارجی اجرا شده است.در کمتر از ۱۰ دقیقه، مهاجم:
دسترسی گرفت دسترسی سطح بالا دریافت کرد Persistence ایجاد کرد اقدام به اجرای Payload نمود---
اگر بخواهیم این سناریو را به یک Correlation Rule تبدیل کنیم:4625 (Multiple Failed Logons)
4624 (Successful Logon)4672 (Privileged Logon)4698 (Scheduled Task Creation)4688 / 4104 (PowerShell Execution) Alert: Potential Initial Access + Persistence + Execution Chainنکته جالب اینجاست که هیچ Malware Detection یا EDR Alert خاصی وجود نداشت؛ تنها با کنار هم قرار دادن چند Event ID ویندوز میشد کل زنجیره حمله را مشاهده کرد.
@SOCLIB#SOC #ThreatHunting #DetectionEngineering #WindowsSecurity #Sysmon #BlueTeam #IncidentResponse #CyberSecurity #SIEM #Splunk
۳کتابخانه عملیات امنیت سایبری یک هشدار ساده که تبدیل به Incident شد... ساعت 02:17 بامداد، SIEM چندین رویداد *4625 (Failed Logon) را از یک سرور مالی ثبت کرد. در نگاه اول چیز خاصی نبود؛ چند تلاش ناموفق برای ورود. اما چند دقیقه بعد یک 4624 (Successful Logon) از همان Source IP مشاهده شد. تحلیلگر SOC تصمیم گرفت بررسی را ادامه دهد... در ادامه لاگها مشخص شد که بلافاصله پس از ورود موفق، یک رویداد 4672 (Special Privileges Assigned)* برای همان حساب ثبت شده است. یعنی کاربر با دسترسیهای سطح بالا وارد سیستم شده بود. چند دقیقه بعد: Event ID 4698 یک Scheduled Task جدید ایجاد شد. سپس: Event ID 4688 فرآیند PowerShell اجرا شد. و در نهایت: Event ID 4104 Script Block Logging نشان داد که PowerShell با دستورات مشکوک برای دانلود و اجرای فایل از یک منبع خارجی اجرا شده است. در کمتر از ۱۰ دقیقه، مهاجم: دسترسی گرفت دسترسی سطح بالا دریافت کرد Persistence ایجاد کرد اقدام به اجرای Payload نمود --- اگر بخواهیم این سناریو را به یک Correlation Rule تبدیل کنیم: 4625 (Multiple Failed Logons) 4624 (Successful Logon) 4672 (Privileged Logon) 4698 (Scheduled Task Creation) 4688 / 4104 (PowerShell Execution) Alert: Potential Initial Access + Persistence + Execution Chain نکته جالب اینجاست که هیچ Malware Detection یا EDR Alert خاصی وجود نداشت؛ تنها با کنار هم قرار دادن چند Event ID ویندوز میشد کل زنجیره حمله را مشاهده کرد. @SOCLIB #SOC #ThreatHunting #DetectionEngineering #WindowsSecurity #Sysmon #BlueTeam #IncidentResponse #CyberSecurity #SIEM #Splunk
یک هشدار ساده که تبدیل به Incident شد... ساعت 02:17 بامداد، SIEM چندین رویداد *4625 (Failed Logon) را از یک سرور مالی ثبت کرد. در نگاه اول چیز خاصی نبود؛ چند تلاش ناموفق برای ورود. اما چند دقیقه بعد یک 4624 (Successful Logon) از همان Source IP مشاهده شد. تحلیلگر SOC تصمیم گرفت بررسی را ادامه دهد... در ادامه لاگها مشخص شد که بلافاصله پس از ورود موفق، یک رویداد 4672 (Special Privileges Assigned)* برای همان حساب ثبت شده است. یعنی کاربر با دسترسیهای سطح بالا وارد سیستم شده بود. چند دقیقه بعد: Event ID 4698 یک Scheduled Task جدید ایجاد شد. سپس: Event ID 4688 فرآیند PowerShell اجرا شد. و در نهایت: Event ID 4104 Script Block Logging نشان داد که PowerShell با دستورات مشکوک برای دانلود و اجرای فایل از یک منبع خارجی اجرا شده است. در کمتر از ۱۰ دقیقه، مهاجم: دسترسی گرفت دسترسی سطح بالا دریافت کرد Persistence ایجاد کرد اقدام به اجرای Payload نمود --- اگر بخواهیم این سناریو را به یک Correlation Rule تبدیل کنیم: 4625 (Multiple Failed Logons) 4624 (Successful Logon) 4672 (Privileged Logon) 4698 (Scheduled Task Creation) 4688 / 4104 (PowerShell Execution) Alert: Potential Initial Access + Persistence + Execution Chain نکته جالب اینجاست که هیچ Malware Detection یا EDR Alert خاصی وجود نداشت؛ تنها با کنار هم قرار دادن چند Event ID ویندوز میشد کل زنجیره حمله را مشاهده کرد. @SOCLIB #SOC #ThreatHunting #DetectionEngineering #WindowsSecurity #Sysmon #BlueTeam #IncidentResponse #CyberSecurity #SIEM #Splunk همه چیز با یک ایمیل ساده شروع شد...صبح دوشنبه بود.
یکی از کارمندهای بخش مالی یک ایمیل دریافت کرد که ظاهراً از طرف واحد منابع انسانی شرکت ارسال شده بود.
موضوع ایمیل:
«نسخه جدید فیش حقوقی آماده مشاهده است»همه چیز عادی به نظر میرسید:
لوگوی شرکت وجود داشت امضای ایمیل معتبر بود حتی نام کارمند هم داخل متن نوشته شده بودکارمند روی لینک کلیک کرد.
صفحهای باز شد که دقیقاً شبیه صفحه ورود Microsoft 365 بود.
او هم بدون شک کردن، نام کاربری و رمز عبورش را وارد کرد...
و همین.
هیچ ویروسی نصب نشد.هیچ فایل مشکوکی دانلود نشد.هیچ هشدار امنیتی هم نمایش داده نشد.
اما مهاجم حالا به حساب ایمیل او دسترسی داشت.
---
چند ساعت بعد...
مهاجم وارد صندوق ایمیل شد و شروع به بررسی مکاتبات مالی شرکت کرد.
او متوجه شد که شرکت قرار است چند روز بعد مبلغ قابل توجهی به یکی از تأمینکنندگان پرداخت کند.
مهاجم صبر کرد.
روز پرداخت، از همان حساب ایمیل واقعی برای واحد مالی پیام فرستاد:
"شماره حساب تأمینکننده تغییر کرده است. لطفاً پرداخت به حساب جدید انجام شود."
از آنجایی که ایمیل از حساب واقعی ارسال شده بود، هیچکس شک نکرد.
پول انتقال داده شد.
اما نه به تأمینکننده...
بلکه به حساب مهاجم.
---
چند روز بعد، وقتی تأمینکننده اعلام کرد که هنوز پولی دریافت نکرده، تازه همه متوجه شدند چه اتفاقی افتاده است.
نکته ترسناک ماجرا؟این حادثه نه با بدافزار شروع شد،نه با هک پیچیده،نه با آسیبپذیری روز صفر.
فقط با یک کلیک روی یک لینک جعلی.
به همین دلیل هنوز هم فیشینگ یکی از موفقترین روشهای حمله در دنیا محسوب میشود.اگر یک ایمیل از شما بخواهد وارد حساب کاربری خود شوید، قبل از کلیک روی لینک، آدرس فرستنده و دامنه مقصد را دوباره بررسی کنید.
شما یا اطرافیانتان تا به حال با چنین ایمیلهایی مواجه شدهاید؟
@SOCLIB#CyberSecurity #Phishing #SecurityAwareness #SOC #BlueTeam #ThreatHunting #Infosec
۷🥳۲
تنظیم معیارهای موفقیت (Setting Success Metrics)سلام دوستان در مراحل قبلی درباره Operating Framework و ساختار عملیاتی صحبت کردیم.اما یک سؤال مهم باقی میماند:از کجا بفهمیم پیادهسازی Splunk ما واقعاً موفق بوده است؟اینجاست که Success Metrics وارد میشوند.https://soclib.ir/?p=15919
۴
خیلی از پروژههای Splunk به خاطر کمبود Data یا ضعف تکنولوژی شکست نمیخورند...بلکه چون هیچکس از ابتدا مشخص نکرده:«موفقیت این پروژه دقیقاً چه شکلی است؟»در بسیاری از سازمانها ماهها زمان صرف میشود برای:
نصب Splunk جمعآوری لاگها ساخت Dashboardها طراحی Use Caseهااما وقتی زمان ارزیابی پروژه میرسد، یک سؤال مهم مطرح میشود:
آیا واقعاً ارزش ایجاد کردهایم؟اینجاست که مفهوم Success Metrics اهمیت پیدا میکند.اگر نتوانید موفقیت را اندازهگیری کنید، بهینهسازی آن هم تقریباً غیرممکن خواهد بود.
برخی از مهمترین معیارهایی که باید در پیادهسازی Splunk زیر نظر داشته باشید:
User Adoption Search Volume Data Ingestion Trends Hardware Utilization Detection Coverage MTTD / MTTR Alert Quality & False Positive Rateیک SIEM موفق فقط لاگ جمعآوری نمیکند؛باید بتواند ارزش عملیاتی، امنیتی و حتی تجاری ایجاد کند.به همین دلیل تیمهای حرفهای علاوه بر معماری و Deployment، روی KPIها، Monitoring Dashboardها و تحلیل رفتار کاربران نیز تمرکز میکنند.
اگر میخواهید با مفهوم Success Metrics در Splunk بیشتر آشنا شوید و بدانید چگونه موفقیت یک پروژه SIEM را بهصورت عملی اندازهگیری کنید، مقاله کامل را در سایت SOCLIB مطالعه کنید: https://soclib.ir/چارچوب-موفقیت-اسپلانک-تنظیم-معیارهای/ @SOCLIB۵۲
بسیاری از تیمهای SOC روزانه دهها IOC از منابع مختلف دریافت میکنند...IPهای مخرب،دامنههای آلوده،URLهای فیشینگ،Hashهای بدافزار و دهها شاخص دیگر.
اما یک سؤال مهم وجود دارد:
آیا این IOCها واقعاً وارد فرآیند Detection و Investigation شما میشوند؟در بسیاری از سازمانها Threat Intelligence فقط در قالب فایل Excel یا گزارشهای PDF باقی میماند و هرگز به Detection عملیاتی تبدیل نمیشود.
اینجاست که Splunk Enterprise Security وارد عمل میشود.
با اتصال منابع Threat Intelligence به Splunk ES میتوان:
IOCها را بهصورت خودکار دریافت و بهروزرسانی کرد لاگهای سازمان را با شاخصهای آلودگی تطبیق داد Correlation Searchهای مبتنی بر Threat Intelligence ایجاد کرد Context بیشتری در اختیار تحلیلگران SOC قرار داد زمان شناسایی تهدیدات را کاهش دادThreat Intelligence زمانی ارزشمند است که از یک گزارش خواندنی به یک قابلیت عملیاتی در SOC تبدیل شود.
در مقاله جدید SOCLIB، فرآیند اتصال Threat Intelligence در Splunk ES به پورتال شاخصهای آلودگی و نحوه استفاده از IOCها در عملیات امنیتی را بررسی کردهایم.
مطالعه مقاله:https://soclib.ir/اتصال-threat-intelligence-در-splunk-es-به-پورتال-شاخصهای-آلود/
@SOCLIB https://t.me/soclibrary#Splunk #SplunkES #ThreatIntelligence #SOC #SIEM #ThreatHunting #DetectionEngineering #CyberSecurity #BlueTeam #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
۴
کارت بانکی شما هک نمیشود...بلکه کپی میشود!
خیلی از افراد تصور میکنند برای سرقت پول از حساب بانکی حتماً باید موبایل یا اینترنت بانکشان هک شود.
اما یکی از قدیمیترین و همچنان مؤثرترین روشهای کلاهبرداری، چیزی به نام *Skimming* است.
ماجرا از این قرار است:
مهاجم یک دستگاه کوچک روی کارتخوان یا خودپرداز نصب میکند.
وقتی کارت را وارد دستگاه میکنید، اطلاعات موجود روی نوار مغناطیسی کارت شما کپی میشود.
اگر رمز کارت هم به هر شکلی ثبت شود (مثلاً با دوربین مخفی یا صفحهکلید تقلبی)، مهاجم میتواند یک نسخه جعلی از کارت شما بسازد.
نکته جالب اینجاست:در بسیاری از موارد، قربانی تا زمانی که پیامک برداشت وجه را دریافت نکند، متوجه هیچ چیز نمیشود.
برای کاهش این خطر:
هنگام وارد کردن رمز، با دست صفحه کلید را بپوشانید. قبل از استفاده از خودپرداز یا کارتخوان، ظاهر آن را بررسی کنید. اگر قسمتی از دستگاه لق، غیرعادی یا چسبانده شده به نظر میرسد از آن استفاده نکنید. پیامک تراکنشهای بانکی را فعال نگه دارید. برای حسابهای اصلی، سقف برداشت روزانه را محدود کنید.امروزه بسیاری از سرقتهای بانکی با هک پیچیده انجام نمیشوند؛
بلکه با سوءاستفاده از چند ثانیه بیدقتی اتفاق میافتند.
امنیت فقط در فضای آنلاین نیست؛ گاهی روی همان دستگاه کارتخوانی است که هر روز از آن استفاده میکنیم. @SOCLIB#امنیت_سایبری #کارت_بانکی #اسکیمینگ #کلاهبرداری_بانکی #آگاهی_امنیتی
۴
🟨 آیا 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
یکی از مشکلاتی که بسیاری از سازمانها بعد از پیادهسازی 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
سالهاست که در حوزه امنیت اطلاعات درباره مفاهیمی مانند امنیت سایبری (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
واقعیت این است که بسیاری از قابلیتهای جدید، 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۴۱