عملکرد شناسایی، رفتار مخرب را بر اساس فعالیتی که در محیط مشاهده شده شناسایی میکند. در عملکرد شناسایی مرحله آمادهسازی، اولین مرحله و بیشک مهمترین مرحله است. آمادهسازی بینش، تدبیر، برنامهریزی، توجیه، توانایی، آموزش، اولویتبندی و هماهنگی را به همراه دارد. هر یک از این اجزا در زمینه مهندسی تشخیص تهدید، از اهمیت بسزایی برخوردار هستند. منظور از مهندسی تشخیص تهدید، شناسایی تهدیدات مرتبط و سنجش تأثیرات آن بر سیستم است که حضور تهدید را نشان میدهد و اپراتورها را آگاه میکند تا بتوانند اقدامات مطلوبی را انجام دهند.
از آنجایی که این علم رشتهای مهندسی است، متخصصان به روشی تکراری آن را اجرا میکنند:
- شناسایی منابع مهم و مورد توجه مهاجمان در سازمان
- انتخاب عامل تهدید شناخته شده که احتمالاً سازمان را هدف قرار میدهد
- مشخص کردن رفتار عامل تهدید
- شناسایی TTPهای عوامل تهدیدکننده
- تعیین تأثیر قابلاندازهگیری هر TTP بر سیستم
- اعمال قابلیت مشاهده را برای نمایش اندازهگیری
- کنترل دقت اندازهگیری
- تنظیم آستانههای هشدار
- طراحی و ساخت هشدار
- تست، ارزیابی و ادغام هشدار در محیط تولید
- بررسی دقت هشدارهای راهاندازی شده و محاسبه مقدار آن
- حفظ، بهبود یا از بین بردن هشدار، بر اساس یافتههای بازنگری شده
درحالی که به نظر میرسد انبوهی از عوامل تهدید وجود دارد، این گروهها از تاکتیکها و تکنیکهای زیادی استفاده میکنند. در نتیجه، همپوشانی قابل توجهی میان عوامل تهدید و TTPها وجود دارد.
هوش تهدید در SOC
هوش تهدید هسته اصلی شناسایی مطلوب را فراهم میکند. هوش، چهار مرحله اول فرآیند مهندسی شناسایی تهدید را تشکیل میدهد. این مراحل توسط یک تحلیلگر هوش تهدید انجام میشود که تعیین میکند چهکسی، چگونه و چرا حملات سایبری را انجام داده است. تحلیلگر هوش تهدید با زمینهسازی و دستهبندی رویدادها، گزارشها و فیدهای داده، دیدگاههایی ایجاد میکند که هدف و روش مهاجم را مشخص میکند. این دیدگاهها انتخاب عوامل تهدید و تکنیکهای آنها برای اولویتبندی شناسایی را نشان میدهد. سپس مهندس شناسایی با مهندسان سیستم، مدیران و توسعهدهندگان برای مشخصکردن و اندازهگیری اقدامات مهاجم کار میکند.
در برخی از حملات، تاثیر مهاجم به خوبی قابل درک است و به راحتی اندازهگیری میشود. مشاهده این تأثیرات با قرار دادن IDS در مقابل سرور یا EDR در Workstation کاربر، امکانپذیر است. با حملات دیگر مانند افزایش سطح دسترسی یا اجرای کد از راه دور (RCE) در یک برنامه وب سفارشی، اثرات مبهمتر میشوند. با این حال، شاید رایجترین الگوی حمله زمانی است که مهاجم از اطلاعات اعتباری مجاز استفاده میکند و از محیط به روشهای غیر پیچیدهای سوء استفاده میکند – مانند ورود به سرور دسکتاپ از راه دور با استفاده از اطلاعات اعتباری مدیریتی که در معرض خطر قرار گرفتهاند و دزدیده شدهاند.
مهندس شناسایی از طریق این مدلهای تهدید مختلف کار میکند و الزامات قابلیت دید سیستم را توسعه میدهد، که Logکردن سیستم و یا سنسورهای امنیتی اضافی را تعریف میکند که برای اندازهگیری وضعیت حضور ابزار مهاجم یا اجرای تکنیک مهاجم استفاده میشوند.
رویکرد جمعآوری الزامات قابلیت دید
رویکرد جمعآوری الزامات قابلیت دید و سپس تعریف لاگ کردن سیستم و نیازهای حسگر اضافی اغلب مخالف رویکرد بسیاری از سازمانها است. رویکرد معمول این است که SOC بر لاگهای تعریف شده توسط شرکت ارائهدهنده که با لوازم امنیتی غیر معتبر تکمیل شده است، تکیه میکند، که همه آنها به یک SIEM متمرکز متصل میشوند. سپس به مهندس SIEM یا تحلیلگر SOC گفته میشود که لاگها را نظارت و در صورت بروز مشکل آن را گزارش کنند. با این حال، این رویکرد نه مبتنی بر هوش تهدید است و نه برای پیشگیری از ضرر در اولویت قرار دارد. این رویکرد حریصانه برای لاگکردن به طور منظم منجر به افزایش هزینههای عملیاتی و سرمایهای SOC در طول زمان میشود که ارزش آن برای کسبوکار کم یا بدون افزایش است.
برای جلوگیری از این وضعیت پرهزینه و کم ارزش، باید رویکردی علمی و تعمدی برای انتخاب لاگ و سنسور اتخاذ شود. برای کارآمدترین اجرای نظارت امنیتی، در زمان ورود، لاگها باید شناخته شوند که آیا مربوط به شناسایی موارد کاربرد هستند یا مرتبط با تحقیقات فارنزیک هستند. مدیران سیستم و سایر ذینفعان نیز باید در فرآیند مهندسی امنیت شرکت داشته باشند.
توسعه شناسایی
هنگامی که الزامات قابلیت دید ایجاد شد، مهندسان شناسایی به کار خود ادامه میدهند و سیگنالهایی را که از سیستمهای نظارت شده دریافت میکنند، تأیید میکنند. به عنوان مثال، حذف نسخههای Shadow copyها ممکن است به شدت نشاندهنده باج افزار ورودی برای برخی سازمانها باشد. برخی دیگر نیز از این تکنیک برای پاک کردن فضای خالی روی هارد دیسکهای مالیاتی سرور میتوانند استفاده کنند. این زمینهسازی و اندازهگیری عملکرد سیگنال برای هر سازمانی منحصر به فرد است.
عملکرد سیگنال میزان تأثیر یک سیگنال در تعیین هدف مخرب را اندازهگیری میکند. این عمل شبیه، اما متمایز از اصطلاحات استاندارد طبقهبندی باینری مانند مثبت کاذب و منفی واقعی است. برای توضیح مثال قبل میتوان گفت، یک لاگ سیستم ممکن است بهطور دقیق حذف یک نسخه Shadow copy را شناسایی کند، اما این که آیا حذف مخرب بوده است یا خیر را تأیید نمیکند. مهندس شناسایی هم به دقت سیگنال و هم به ارزش سیگنال به SOC توجه دارد.
مهندس شناسایی ابزارهای متعددی را دسترس دارد که سیگنالها را در هشدارهای قابل اجرا تقویت و زمینهسازی کند. برخی از انواع سیگنالها ممکن است به مبنای اصلی و تنظیم آستانه هشدار نیاز داشته باشند. برای مثال، یک عامل تهدید ممکن است قصد داشته باشد با شکست عمدی Loginها به سیستم و قفل کردن پایگاه داده، کسبوکار را مختل کند. قفل یک حساب کاربری ممکن است عملی نباشد، درحالیکه قفل چند حساب، از یک منبع واحد که بسیار بالاتر از مبنای اصلی است، قابل اجرا است.
علاوه بر این، مهندس شناسایی ممکن است به دنبال ترکیب سیگنالهای مختلف در یک هشدار واحد باشد. مهندس ممکن است تعیین کند که مدیران سیستم بهطور معمول بتوانند نسخه Shadow copy را حذف کنند، اما هرگز با استفاده از PS Exec این کار را انجام نمیدهند. در نتیجه، هشدار ممکن است به دنبال وجود سرویس PS Exec و حذف نسخه Shadow باشد. این تفاوتهای اندک هشداری، مبتنی بر هوش مشاهده، گزارش و به اشتراک گذاشته شدهاند.
هر مورد شناسایی موارد کاربرد باید از طریق شناسایی Lifecycle مدیریت شود. مهاجمان تغییر میکنند، تواناییها و دستکاریهای آنها در محیطهای هدف نیز تغییر میکند. به این ترتیب، شناساییها نیز باید تغییر کنند. برای حفظ سلامت هر هشدار، متدلوژی به واسطه تست، اعتبارسنجی، ارزیابی مستمر و در نهایت تنظیم شدن ادامه مییابد.
چالش در مرکز عملیات امنیت (SOC)
هنگامی که SOC ها با حجم هشدارهای بسیار زیادی مواجه می شوند، به این معنی است که شناسایی موارد کاربرد آنها مدیریت، ارزیابی و اولویتبندی نشده است. هشدارهایی که به SOC سرازیر میشوند، نشانه رویکرد “همه چیز را Logکنید و به تحلیلگر اجازه دهید آن را مرتب کند” است، حتی زمانی که این هشدارها با مجموعه دادههای SIEM غنی میشوند و SOAR بالا میرود، آنها همچنان به تجزیهوتحلیل اضافی برای اعتبارسنجی و شروع تحقیقات نیاز دارند.
SOC کلاسیک، تحلیلگران SOC را در لایهها ی مختلف مانند Help deskها سازماندهی میکند. پایینترین لایه از اسکریپتهای گامبهگام پیروی میکند تا وظایف خاصی را به صورت «دستی خودکار» انجام دهد. به عبارت دیگر، در حالی که برخی از وظایف تکراری هستند، ممکن است ابتدایی نباشند، یا رابط ممکن است از نظر برنامهنویسی قابل دسترسی نباشد. در آن صورت، ارجاع افراد به سمت آن کارآمدتر از خودکارسازی با استفاده از یک پلت فرم SOAR مانند است.
در حین اجرای این رویههای اسکریپت شده، یک نمودار جریان، تصمیمات تحلیلگر Tier-1 را میگیرد و تحلیلگر تصمیمگیری نمیکند. اگر نمودار جریان کافی نباشد، این رخداد به یک تحلیلگر Tier-2 افزایش مییابد که ممکن است قدرت تفکر انتقادی بیشتری داشته باشد.
SOCها همچنین بهطور معمول تحلیلگران خود را بهطور اختصاصی در منابع هشدار دارند. برخی از تحلیلگران ممکن است بر روی هشدارهای ایمیل تمرکز کنند، برخی دیگر بر روی EDR و غیره تمرکز کنند. مسئله این است که یک روایت مطلوب تهدید ممکن است از چندین هشدار عبور کند. برای مثال، یک هشدار ایمیل مشکوک که یک موضوع مشکوک را برجسته میکند، مانند «بسته تحویل داده شد»، ممکن است حاوی Payloadای باشد که وقتی باز میشود، هشدار IDS را به عامل کاربر مشکوک میدهد و وقتی تداوم ثابت شد، ابزار EDR ممکن است به ایجاد سرویس مشکوک هشدار دهد. همچنین ممکن است ماینر رمزنگاری ثانویه توسط آنتی ویروس نقطه پایانی دانلود و مسدود شده باشد.
اگر این داستان حمله از روی رویکرد روایت تهدید ارزیابی شود، به وضوح حادثهای واحد است که اتفاقاً با پیشروی حمله، شناساییهای متعددی دارد. با این حال، تفکیک مسئولیت تحلیلگر بر اساس نوع سیگنال تنها بخش کوچکی از داستان را به آنها میدهد.
هنگام تجزیهوتحلیل ایمیل مشکوک “بسته تحویل داده شده”، ایمیل ممکن است به گونهای ساخته شود که پاسخی به یک رشته موجود با یک کسب و کار شخص ثالث شناخته شده باشد که باعث میشود تحلیلگر ایمیل تهدید را رد کند. کاربر مشخص شده توسط هشدار IDS ممکن است بسیار شبیه به کاربر معمولی Mozilla باشد که قبلاً در محیط استفاده شده است. از آنجایی که آنتی ویروس، ماینر کریپتو را مسدود کرده است، حتی ممکن است SOC آن را بررسی نکند.
در این مثال، در حالی که هشدار EDR ممکن است پاسخی از سوی SOC ایجاد کند، تحقیقات همچنان باید نقطه ورود این حمله را کشف کند، حتی اگر این هشدار قبلاً توسط SOC بررسی شده باشد.
آگاهی از موقعیت به طور فزایندهای دشوار میشود زیرا SOC ها روی فرآیند بررسی و انتقال دادهها از راه دور Telemetry)) اضافی نصب میشوند. همانطور که گزارشهای امنیتی و عملیاتی توسط SIEM وارد میشوند، هشدارهای بیشتری نیز فعال میشوند و نویز بیشتری تولید میشود تا تحلیلگران بتوانند از طریق آن بررسی کنند. این به نوبه خود تمرکز SOC را از شناسایی تهدیدهای واقعی منحرف میکند. بیشتر هشدارها بیخطر هستند، بنابراین تحلیلگران زمان زیادی را صرف بررسی هشدارهای غیرقابل اجرا میکنند. توانمندترین تحلیلگران SOC باید منبع را از محتوایی که دقت کمتری دارد جدا کنند. این کار خستهکننده است و تحلیلگران را خسته میکند.
در عین حال، سازمانها بطور منطقی نگران هشدارهای منفی کاذب هستند در حالیکه مهاجم در سازمان حضور دارد، اما امنیت فعلی پاسخی به آن نمیدهد. بنابراین حتی اگر یک SOC دچار سردرگمی شود، سازمان از ترس گمشدن، در اولویتبندی مجدد یا حتی خاموش کردن صدای خطا در اعلام هشدار تردید میکند. با این حال، حقیقتی ناراحتکننده در پشت داشبورد پنهان میشود: خستگی هشدار به این معنی است که خطا در اعلام هشدار، منفی کاذب را ایجاد میکند.
مرکز عملیات امنیت (SOC) بهینه شده
یک SOC مطلوب به جای تلاش برای بررسی هر سیگنالی که ممکن است نشاندهنده رفتار مخرب باشد یا نباشد، چندین هشدار مرتبط را در یک تحقیق یکپارچه ادغام میکند. در نهایت، هدف SOC تعیین این است که آیا یک سیستم یا یک حساب در معرض خطر قرار گرفته است یا خیر. برای این منظور، تحلیلگران SOC باید تمام سرنخهای زمینهای را در مورد اهداف احتمالی جمعآوری کنند.
به جای بررسی جداگانه هر هشدار، تحلیلگران باید هدف را بررسی کنند و هشدارهای مربوطه را با هم در یک تحقیق منسجم مطرح کنند. این روش، مجموعه مهارتهای تحلیلگر SOC را تغییر میدهد.
برخلاف SOC سنتی که در آن تحلیلگران به منابع گزارش و نمودارهای جریان اختصاص دارند، SOC بهینه شده از آموزش، تجربه و تفکر انتقادی تحلیلگران خود بهره میبرد. این تحلیلگر SOC مانند یک کارآگاه عمل میکند و از سرنخها، شواهد و ابزار فارنزیک برای کشف داستان پشت این رخداد استفاده میکند. این تحلیلگر با هر یک از منابع گزارش مربوطه و وسایل امنیتی آشناست و از هر ابزار موجود در زمینه تریاژ، طبقهبندی، حوزه و مهار تهدید استفاده میکند.
رسیدگی به هشدارها در مرکز عملیات امنیت
بررسیها بهطور معمول با اعلانهای خارجی یا هشدار به SOC شروع میشوند. این هشدارها ممکن است توسط ابزارهای امنیتی مانند سیستم تشخیص نفوذ شبکه یا آنتیویروس ایجاد شوند، یا ممکن است هشدارها با منطق اعمالشده بر روی گزارشها از طریق SIEM یا اعلان فعالیتهای مشکوک توسط انسان ایجاد شوند. صرف نظر از این مسئله، این هشدار نقطه شروع اولیه را به تحلیلگر میدهد.
تحلیلگران SOC نیازی به دیدن هر رویداد امنیتی ندارند، در عوض باید هشدارهایی با دقت بالا به آنها ارائه شود که مستلزم بررسی بیشتر است. بارگذاری بیش از حد تحلیلگران با رویدادهای امنیتی نامربوط میتواند توجه آنها را نسبت به رویدادهای امنیتی با اولویت بالاتر را کاهش دهدکه ممکن است نیازمند دسترسی به اطلاعات اضافی باشند و تحقیقاتی را برای تعیین تهدیدات امنیتی در مقابل تهدیداتی که باید کاهش یابند، انجام دهند. سیستمهای امنیتی نباید رویدادهای بیپایان را در صفحه نمایش پخش کنند.
هوش تهدید به تحلیلگران کمک میکند تا بر آنچه که مهم است تمرکز کنند. بااین حال، بدون مکانیسمهای مناسب برای عملیاتی کردن این اطلاعات، آنها اغلب نمیدانند با آن چه کار کنند و آن را نادیده میگیرند. خودکارسازی استفاده از هوش در یک SIEM یا تکنولوژی دفاعی خودکار که توسط SOC استفاده میشود، مزیت قابل توجهی برای تحلیلگران ایجاد میکند. اجرای صحیح اطلاعات به تکنولوژیهای SOC این امکان را میدهد تا رویدادهای مرتبط با آسیبپذیریهایی که به طور گسترده مورد سوء استفاده قرار میگیرند و تأثیر حیاتی بر سازمان دارند را بهطور خودکار اولویتبندی کنند. ردیابی این رویدادها به TTPهای رایج گروههای حمله یا دستههای شناخته شده نیز میتواند به بررسی برای تسریع تجزیهوتحلیل و انتخاب Playbook کمک کند.
نحوه پیشبرد تحلیلگر و اهداف کلی که وی دنبال میکند توسط فرآیندهای SOC و Playbookها تعریف میشود.
استفاده از تکنولوژیهای دفاعی خودکار
پیشرفتهای اخیر در تکنولوژیهای دفاعی خودکار، خطر خطای رویهای و انسانی در فرآیند تحقیق و جمعآوری شواهد را کاهش میدهد. تکنولوژیهای دفاعی خودکار از استدلال و تصمیمگیری تحلیلگران امنیتی متخصص تقلید میکنند و دادههای ابزارهای امنیتی را در سراسر زیرساخت برای غنیسازی هشدارها و تعیین اینکه آیا آنها مخرب و قابل اجرا یا بیخطر هستند، ترکیب میکنند.
تکنولوژیهای دفاعی خودکار نقش و مسئولیتهای تحلیلگران امنیتی را افزایش میدهند. با ارائه پروندههای تحقیقاتی حوزه و اولویتبندیشده به تحلیلگران امنیتی که از میان آنها میتوانند به سرعت مسیر واکنش مناسب رخداد را انتخاب کنند، تحلیلگران امنیتی میتوانند بیشتر بر شناسایی اهداف متخاصمانه در مقابل بررسی موارد خطا در اعلام هشدار تمرکز کنند.
با ارائه دادههای اولویتبندی شده و غنی شده به تحلیلگران، تکنولوژیهای دفاعی خودکار، بسیاری از مراحل اولیه تریاژ را هنگام بررسی فعالیتهای مشکوک حذف میکنند. این به تحلیلگران اجازه میدهد تا زمان خود را به جای اعتبارسنجی هشدارها، صرف تجزیهوتحلیل و پاسخگویی به فعالیتها کنند. تکنولوژیهای دفاعی خودکار هرگز جایگزین توانایی یک تحلیلگر انسانی برای درک متن دادهها نمیشوند. بااین حال، این تکنولوژی ابزاری بسیار مفید در جعبه ابزار یک تحلیلگر است. هدف تمام تیمهای SOC باشد که به تحلیلگران هشدارهایی با دقت بالا ارائه دهند که حاوی دادههای قابل اجرا باشد به طوری که تحلیلگران ماهر بتوانند مدت زمان ماندن مهاجمان را کاهش داده و از تأثیرات فاجعه آمیز جلوگیری کنند.
تکنولوژیهای دفاعی خودکار همه سیستمها و فعالیتهای مرتبط را در طول مدت حمله تحت پوشش قرار میدهند که این حادثه ممکن است چند ثانیه یا چند روز طول بکشد. این تکنولوژی بررسی حادثه، فاکتورگیری در حوزه، اهمیت منابع، مرحله حمله و اطمینان در تشدید را در اولویت قرار میدهد.
سپس رخداد اولویتبندی شده با شواهد پشتیبان به تحلیلگر ارائه میشود:
- رفتارها و Signatureهای مخرب شناسایی شده
- جدول زمانی رویداد (مجموعهای از رویدادها از ابزارهای امنیتی مختلف در طول زمان)
- سیستمها و منابع داخلی تحت تاثیر قرار گرفته
- دادههای هوش تهدید نسبت داده شده
- طراحی پیشرفت مرحله حمله با استفاده از تکنیکهای MITRE ATT&CK
داشتن درک عمیق از TTPها بر اساس هوش تهدید قابل اعتماد برای تحلیلگران SOC حیاتی است.
درک نقضهای گذشته به تحلیلگران در پیشبینی فعالیتهای آینده مهاجم در سیستمی واحد و رخدادی در سطح سازمانی، کمک میکند.
با بررسی مجدد مثال هشدار IDS با شدت بالا، تکنولوژی دفاعی خودکار موارد زیر را ارائه میدهد:
«رویداد IDS با شدت بالا از ایستگاه کاری کاربر به وب سرور داخلی. شناسایی امضای IDS شامل اجرای Empire PowerShell Payload. امضای Playload مشابهی در چندین ایستگاه کاری داخلی دیگر مشاهده میشود که هدف آنها چندین سرور حیاتی است. بررسیها به تیم پاسخ به رخداد ((CSIRT ارجاع داده شد.»