تاکتیک‌های اساسی برای محافظت از اکوسیستم‌های‌ ایمیل

از آنجایی که امنیت‌ ایمیل یک چشم انداز همیشه در حال تغییر است، تمرکز بر مرتبط‌ترین مسائل در چشم انداز تهدید، جایی است که سازمان‌ها باید از آن شروع کنند.

بنابراین، کدام تاکتیک‌های‌ ایمیل مرتبط‌ترین و مبرم‌ترین مسائلی هستند که باید روی آن تمرکز کنیم؟ بر اساس بینش‌های Cofense، این سه نوع حمله از سال ۲۰۲۱ رایج‌ترین آن‌ها بوده‌اند:

• فیشینگ اعتبارنامه
• به خطر انداختن‌ ایمیل تجاری (BEC)
• بدافزار‌ها

به گفته تحلیلگران مرکز دفاع فیشینگ Cofense، فیشینگ اعتبارنامه، حدود ۷۰ درصد از تمام حملات را تشکیل می‌دهد که BEC با ۷ درصد پشت سر این حملات قرار می‌گیرد و بدافزار (به همراه چند مورد دیگر) بقیه موارد را تشکیل می‌دهند. وقتی به آن اعداد نگاه می‌کنید و آن‌ها را با مواردی که در طول یک حمله فیشینگ اعتبارنامه موفقیت‌آمیز کنار گذاشته می‌شوند ترکیب می‌کنید، مشخص می‌شود که توقف حملات اعتبارنامه‌ای باید در اولویت باشد. این بدان معنا نیست که توقف حملات BEC و بدافزار مهم نیست، بلکه قطعاً مهم هستند. حملات موفق، مانند حملات باج‌افزاری، اغلب برای مهاجم بسیار سودآور و برای قربانی بسیار دردناک و پرخطر هستند.

برای هر سه این حملات، چند تاکتیک اساسی وجود دارد که سازمان‌ها باید اتخاذ کرده تا اطمینان حاصل کنند که از اکوسیستم‌ ایمیل خود محافظت می‌نمایند.

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

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

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

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

تجزیه و تحلیل پس از دریافت
در نهایت، قابلیت‌های موقعیت‌یابی که می‌توانند تکامل یابند و تهدید‌ها را بطور فعال شناسایی کنند، خطر را حتی بیشتر کاهش می‌دهد. دروازه‌های‌ ایمیل امن (Secure Email Gateway) یا SEG‌ها، یکی از روش‌ها هستند، اما ما به طور مداوم می‌بینیم که تهدید‌ها از این دروازه‌ها عبور می‌کنند، بنابراین نیاز به تجزیه و تحلیل و قابلیت‌های پاسخ پس از تحویل را الزامی می‌کنند. هر SEG موجود در بازار امروز دارای نقاط ضعفی است.

به‌طور سنتی، شرکت‌ها SEG‌ها را به‌صورت سری روی هم قرار می‌دهند تا احتمال شناسایی یک تهدید را افزایش دهند؛ که یک راه حل تجزیه و تحلیل پس از تحویل، که با دانش درباره آنچه در تمام SEG‌ها وجود دارد، از نظر عملکردی مؤثرتر و همچنین مقرون به صرفه‌تر است.

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

بیشتر بخوانید

امکان دسترسی به شبکه‌های سازمانی با نقص مهم در فایروال‌های Zyxel

یک آسیب‌پذیری حیاتی (CVE-2022-30525) که چندین مدل از فایروال‌های Zyxel را تحت تأثیر قرار می‌دهد، به همراه یک ماژول Metasploit که از آن بهره‌برداری می‌کند، به صورت عمومی افشا شده است.

این آسیب‌پذیری که توسط جیک بینز، محقق Rapid 7 کشف شد و در ۱۳‌آوریل به Zyxel اطلاع داده شد، توسط این شرکت با پچ‌هایی که در ۲۸‌آوریل منتشر شد برطرف شد، اما تا کنون توسط شرکت از طریق CVE یا توصیه نامه امنیتی مرتبطی، تأیید نشده است.

جزییات CVE-2022-30525
آسیب‌پذیری CVE-2022-30525، ممکن است توسط مهاجمان احراز هویت نشده و از راه دور برای تزریق دستورات به سیستم عامل از طریق رابط HTTP مدیریتی فایروال‌های آسیب‌پذیر (در صورت قرار گرفتن در اینترنت) مورد سواستفاده قرار گیرد، که به آن‌ها اجازه می‌دهد فایل‌های خاصی را تغییر داده و کامند‌های سیستم‌عامل را اجرا کنند.

همانطور که توسط Zyxel تأیید شده است، این آسیب‌پذیری، بر مدل‌های فایروال و نسخه‌های فریمور زیر تأثیر می‌گذارد:

• USG FLEX 100(W), 200, 500, 700 – فریمور: ZLD V5.00 تا ZLD V5.21 Patch 1

• USG FLEX 50(W) / USG20(W)-VPN – فریمور: ZLD V5.10 تا ZLD V5.21 Patch 1

• ATP Series – فریمور: ZLD V5.10 تا ZLD V5.21 Patch 1

• VPN Series – فریمور: ZLD V4.60 تا ZLD V5.21 Patch 1

رفع و کاهش خطر
با وجود پچی که می‌توان آن را مهندسی معکوس کرد و ماژول Metasploit که در دسترس است، بیش از ۱۶۰۰۰ دستگاه آسیب‌پذیر قابل کشف از طریق Shodan ممکن است در روز‌ها و ماه‌های آینده مورد هدف مهاجمان قرار گیرند، که این اتفاق ممکن است به‌ویژه توسط کارگزاران دسترسی اولیه حادث شود.

به ادمین‌های دستگاه‌های آسیب دیده توصیه می‌شود در اسرع وقت فریمور خود را به نسخه V5.30 ارتقا دهند.

«در صورت امکان، بروزرسانی خودکار سیستم عامل را فعال کنید». بینز همچنین توصیه کرد دسترسی WAN به اینترفیس وب ادمین سیستم را غیرفعال کنید.

بینز از اینکه Zyxel این آسیب‌پذیری را بی‌صدا پچ کرده، ابراز تأسف کرده است، زیرا این «تنها به مهاجمان فعال کمک می‌کند و مدافعان را در مورد خطر واقعی مسائل جدید کشف‌شده در ناآگاهی کامل ر‌ها می‌نماید».

با این حال، زایکسل می‌گوید که این مسأله عمدی نبوده، بلکه به دلیل «ارتباط نادرست در طول فرآیند هماهنگی افشای اطلاعات» پیش آمده است.

بیشتر بخوانید

چهار نکته اساسی برای به حداکثر رساندن امنیت API

حجم اینترفیس‌های برنامه‌نویسی برنامه‌ها (API) بین سال‌های ۲۰۲۰ و ۲۰۲۱ افزایش یافته است. Postman رشد جهانی اکوسیستم API را تأثیرگذار خوانده و اشاره کرد که چگونه شاهد افزایش ۳۹ درصدی در تعداد مجموعه‌های ایجاد شده تا ۳۰ میلیون بوده است. حتی رشد بیشتر در تعداد درخواست‌های API ایجاد شده، با تعداد ۸۵۵ میلیون، که افزایش ۵۶ درصدی را تشکیل می‌دهد نیز مشاهده شده است.

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

با آزاد شدن این منابع، سازمان‌ها می‌توانند بر ارائه ارزش به مشتریان خود تمرکز کنند. آن‌ها همچنین می‌توانند از API‌ها برای متمایز کردن خود از رقبای خود از طریق یک یا چند تخصص استفاده کنند. API‌ها می‌توانند به آن‌ها کمک کنند تا نیاز‌های آن بخش‌های خاص را برطرف کنند و در نتیجه فرصت‌های تجاری جدید‌ امیدوار‌کننده‌ای ایجاد کنند.

چرا گاهی اوقات این یک مشکل محسوب می‌شود؟
با این حال، API‌ها می‌توانند پیچیدگی و خطرات امنیتی را ایجاد کنند. بر اساس تحقیقات انجام شده توسط Cloudentity، حدود ۹۷٪ از سازمان‌ها به دلیل نگرانی‌های امنیتی API در انتشار برنامه‌ها و سرویس‌های جدید با تأخیر مواجه شده‌اند. تقریباً نیمی از آن‌ها (۴۴٪) این نگرانی‌ها را به عنوان نگرانی‌های جدی مربوط به قرار گرفتن در معرض اطلاعات خصوصی و سایر داده‌ها بیان کرده‌اند.

گاهی اوقات، سازمان‌ها بیشتر بر روی حفظ زمان تحویل سریع برنامه‌ها تمرکز می‌کنند تا امنیت API‌های خود. این عدم تعادل به عنوان بودجه ناکافی برای تلاش‌های امنیتی API، از جمله آموزش آگاهی از امنیت برای توسعه‌دهندگان و سایر ذینفعان، ظاهر می‌شود. با اذعان به این یافته‌ها، جای تعجب نیست که فقط ۲ درصد از پاسخ‌دهندگان در نظرسنجی به توانایی سازمان خود برای ایمن‌سازی API‌های خود اطمینان داشتند.

فرصت‌هایی برای تغییر
بسیاری از سازمان‌ها به دنبال ایجاد تغییر برای امنیت API خود هستند. در نظرسنجی فوق الذکر توسط Cloudentity، حدود ۹۳ درصد از پاسخ‌دهندگان نشان دادند که قصد دارند بودجه و منابع خود را برای امنیت API افزایش دهند. بیش از نیمی (۶۴٪) نوشتند که بودجه آن‌ها می‌تواند تا ۱۵٪ در آینده افزایش یابد.

این یافته‌ها سؤال مهمی را مطرح می‌کند. سازمان‌هایی که به دنبال به حداکثر رساندن امنیت API خود هستند باید توجه خود را به کجا معطوف کنند؟ در زیر چهار نکته مهم که به این امر کمک می‌کند، ارائه شده است:

نکته شماره ۱: یک استراتژی مدیریت API را اتخاذ کنید
ابتدا، سازمان‌ها باید یک استراتژی مدیریت API را اتخاذ کنند. Help Net Security اشاره کرد که آن‌ها باید با ارائه فرآیند‌های واضح برای طراحی، پیاده‌سازی و مدیریت API که با الزامات کسب‌وکار مطابقت دارد، تا حد امکان به شکل پیشگیرانه‌ی، این استراتژی را انجام دهند. به عنوان بخشی از استراتژی خود، سازمان‌ها همچنین باید راه‌هایی را مستند کنند که از طریق آن تیم‌های امنیتی بتوانند آسیب‌پذیری‌های مربوط به API‌های خود را شناسایی، به‌ویژه ۱۰ نقطه ضعف برتر API که توسط پروژه امنیتی برنامه‌های باز وب (OWASP) شناسایی شده‌اند، اولویت‌بندی و اصلاح کنند. همه عناصر امنیتی دیگر از این پایه یک استراتژی مدیریت API سرچشمه می‌گیرند، بنابراین مهم است که آن را به درستی انجام دهید و با تکامل کسب‌وکار، آن را بازبینی و به روز کنید.

نکته شماره ۲: همه API‌های آن‌ها را پیدا کنید
با وجود یک استراتژی مدیریت API، سازمان‌ها می‌توانند تمام API‌های خود را در هر کجا که ساکن هستند کشف کنند. با این حال، آن‌ها باید در مورد نحوه برخورد با این مرحله، استراتژیک برخورد کنند. به عنوان مثال، IT همیشه در مورد همه API‌های مورد استفاده در سازمان نمی‌داند، بنابراین تکیه بر فرآیند‌های کشف دستی آن‌ها می‌تواند نقاط کور بحرانی ایجاد نماید.

سازمان Salt Security با این ارزیابی موافق است. آن‌ها در یک پست وبلاگ توضیح داده‌اند: «مستندسازی API، اگرچه به خودی خود بهترین روش است، اما ممکن است به طور مداوم انجام نشود. کشف خودکار اندپوینت‌های API، پارامتر‌ها و انواع داده‌ها برای همه سازمان‌ها ضروری است.»

با در نظر گرفتن این موضوع، سازمان‌ها باید API‌ها را در تمام محیط‌های خود نه فقط تولید، بلکه کشف کنند که شامل وابستگی‌های API و برچسب‌گذاری API‌های خود به عنوان بهترین عمل و شکل DevOps است.

نکته شماره ۳: افزایش آگاهی کارکنان از امنیت API
سازمان‌ها اگر نیروی کار آن‌ها تهدیدات موجود را درک نکنند، نمی‌توانند انتظار داشته باشند که همه از شیوه‌های امنیتی API پیروی کنند. برای رفع این مشکل، آن‌ها می‌توانند از آموزش آگاهی امنیتی برای آموزش کارکنان خود در مورد حملات مبتنی بر API و نحوه تهدید آن‌ها برای کسب‌وکار استفاده کنند. فوربز نوشت، این تلاش‌ها به برقراری امنیت در مراحل طراحی، ساخت و استقرار نرم‌افزار کمک می‌کند. همچنین مکمل ابتکارات DevSecOps است که برای ارتقای همکاری بین تیم‌های توسعه برنامه، امنیت و عملیات طراحی شده‌اند.

نکته ۴: به Zero Trust برسید
در نهایت، سازمان‌ها باید Zero Trust را به عنوان هدف خود در نظر بگیرند. یک رویکرد Zero trust می‌تواند به تیم‌های امنیتی کمک کند تا به طور مداوم سرویس، درخواست‌کننده و مشتری را تأیید کنند، بنابراین تهدیدات حملات API را به حداقل می‌رساند. تیم‌ها همچنین می‌توانند از Zero Trust برای ممیزی آن درخواست‌ها برای نشانه‌های ایجاد خطر و شاخص‌هایی که سپس می‌توانند برای محدود کردن دامنه یک حادثه بر اساس آن‌ها عمل کنند، استفاده کنند.

بیشتر بخوانید

تهدید خدمات مشتری سیسکو با اشکال بحرانی در مرکز ارتباطات سیسکو

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

یک باگ امنیتی حیاتی که بر پورتفولیوی Unified Contact Center Enterprise (UCCE) سیسکو تأثیر می‌گذارد، می‌تواند امکان افزایش اختیارات و تصاحب پلتفرم را فراهم کند.

اساساً Cisco UCCE یک پلتفرم خدمات مشتری داخلی است که قادر به پشتیبانی از ۲۴۰۰۰ ایجنت خدمات مشتری با استفاده از کانال‌هایی است که شامل صدای ورودی، صدای خروجی، پاسخ صوتی تعاملی خروجی (IVR) و کانال‌های دیجیتال می‌شود. همچنین یک لوپ ارسال بازخورد از طریق تلفن گویای پس از تماس، ‌ایمیل و نظرسنجی رهگیری وب را ارائه می‌دهد. و گزینه‌های گزارش دهی مختلف برای جمع‌آوری اطلاعات در مورد عملکرد ایجنت برای استفاده در ایجاد معیار‌ها و اطلاع‌رسانی هوش تجاری را در خود جای داده است.

بر اساس گزارش وب سایت محصولات، برخی از کاربران این محصول از جمله T-Mobile USA در میان این کاربران قرار گرفته‌اند.

باگ مورد بحث (CVE-۲۰۲۲-۲۰۶۵۸) بسیار شدید بوده و با امتیاز بحرانی 9.6 از 10 در مقیاس شدت آسیب‌پذیری CVSS، می‌تواند به مهاجمان احراز هویت شده و از راه دور اجازه دهد تا اختیارات خود را با توانایی ایجاد حساب جدید ادمین، افزایش دهند.

این به طور خاص در اینترفیس مدیریت مبتنی بر وب پورتال مدیریت مرکز تماس واحد Cisco (Unified CCMP) و Cisco Unified Contact Center Domain Manager (Unified CCDM) وجود دارد و از این اصل ناشی می‌شود که سرور به مکانیزم‌های احراز هویت که توسط کلاینت اداره می‌شود، تکیه می‌کند. این مسأله در را به روی مهاجمی باز می‌کند تا رفتار سمت کلاینت را برای دور زدن مکانیسم‌های حفاظتی دنبال کند.

مشخصاً CCMP یک ابزار مدیریتی است که به سوپروایزر مرکز تماس این امکان را می‌دهد تا عواملی را که در مناطق مختلف مرکز تماس کار می‌کنند، بین صف‌های تماس، مارک‌ها، خطوط محصول و موارد دیگر جابجا کنند، اضافه کنند و تغییر دهند. CCDM مجموعه‌ای از اجزای سرور برای مدیریت پشتیبان (back-end)، از جمله احراز هویت و سایر عملکرد‌های امنیتی، تخصیص منابع و پایگاه داده‌ای است که اطلاعات مربوط به همه منابع (مانند ایجنت‌ها و شماره‌های شماره‌گیری شده) و اقدامات انجام شده (مانند تماس‌های تلفنی و تغییر وضعیت ایجنت) را در سیستم در خود نگه می‌دارد.

سیسکو هشدار داد که با داشتن حساب‌های ادمین اضافی، مهاجمان می‌توانند به منابع تلفن و کاربر در تمام پلتفرم‌هایی که به سیسکو Unified CCMP که آسیب‌پذیر است، مرتبط هستند دسترسی پیدا کرده و آن‌ها را تغییر دهند. می‌توان این را بدون ذکر آسیبی که می‌توان با دسترسی به مجموعه داده‌های اطلاعات شخصی مشتریان، از جمله ارتباطات تلفنی و‌ ایمیلی که سیستم باید در اختیار شرکت‌ها قرار دهد، وارد آورد، به تخریب عملیاتی و هویت برندی را که مهاجم می‌تواند با تخریب کردن سیستم‌های خدمات مشتری یک شرکت بزرگ ایجاد کند را تعبیر کرد.

استفاده از آن نیز سخت نیست: سیسکو در توصیه نامه امنیتی در این هفته توضیح داد: «این آسیب‌پذیری به دلیل عدم اعتبارسنجی سمت سرور مجوز‌های یوزر است. یک مهاجم می‌تواند با ارسال یک درخواست HTTP دستکاری شده به یک سیستم آسیب‌پذیر از این آسیب‌پذیری سواستفاده کند».

با این حال، برای بهره‌برداری موفقیت‌آمیز از آسیب‌پذیری، مهاجمان به اعتبارنامه‌های معتبر «advanced user» نیاز دارند، بنابراین این اشکال برای دسترسی اولیه باید با آسیب‌پذیری دیگر مرتبط و متصل شود.

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

نسخه های 11.6.1 و نسخه های قبلی: نسخه ثابت 11.6.1 ES17 است.
نسخه 12.0.1: نسخه ثابت 12.0.1 ES5 است.
نسخه 12.5.1: نسخه ثابت 12.5.1 ES5 است.
نسخه 12.6.1: تحت تأثیر قرار نمی گیرد.

به گفته این غول شبکه، تاکنون هیچ سواستفاده عمومی شناخته شده‌ای از این آسیب‌پذیری مشاهده نشده است.

راه‌حل‌های مرکز تماس سیسکو قبلاً با اشکالات مهمی روبرو بوده است. به عنوان مثال، در سال ۲۰۲۰ یک اشکال مهم در پلتفرم «مرکز تماس in-a-box»، Unified Contact Center Express، یافت شد که امکان اجرای کد از راه دور را فراهم می‌کرد.

بیشتر بخوانید