بررسی سناریوها و راهکارهای امنیتی کاربران با Malware Protection Plus به این سناریوهای جذاب اما ترسناک نگاه کنید:سناریو ۱: کارمند منابع انسانی روی سیستمش، به‌طور ناگهانی پنجره‌ای ظاهر می‌شود:“آپدیت فوری برای پرینتر HP در دسترس است. نصب کن.”با یک کلیک ساده، حمله آغاز می‌شود. سناریو ۲: مدیر مالی یک ایمیل دریافت کرده که نام نمایشی‌اش نام مدیرعامل است و نوشته در اسرع وقت روی این لینک کلیک کن و فلان مبلغ را آنلاین پرداخت کن! سناریو ۳: واحد فروش، کامپیوتری بدون اینترنت برای امنیت بیشتر دارد. اما از طریق یک فایل اکسل آلوده که از USB منتقل شده، بدافزار فایل‌لس فعال می‌شود. سناریو ۴: ساعت ۲:۴۵ بامداد، شرکت حمل‌ونقل بین‌المللی. یک مهندس IT به‌تنهایی در دیتاسنتر مشغول بررسی لاگ‌هاست. ناگهان با نوتیفیکیشن زیر روبه‌رو می‌شود: “۱۴ سرور در خطر رمزگذاری توسط باج‌افزار هستند. فایل‌ها ایزوله و نسخه‌ی سالم بازیابی شد.” این مهندس بی‌خبر از همه‌جا چطور مطلع شد؟ سایرین چطور گرفتار شدند؟ در ظاهر همه‌چیز طبیعی‌ست… اما: تهدیدات وحشتناکی در کمین است!چطور بر این تهدیدات غلبه کنیم؟آیا صرف داشتن آنتی‌ویروس برای جلوگیری از این وقایع کافی است؟ خب مدانت در ادامه برای هر سناریو، دقیق موارد زیر را شرح می‌دهد که تهدید چه بوده و چه کاری با چه ابزاری می‌توان انجام داد: سناریو ۱: «آپدیت جعلی پرینتر» شرح محتوا تهدید حمله‌ای فیشینگ به‌صورت آپدیت جعلی برای درایور پرینتر رفتار کاربر کارمند روی دکمه “نصب کن” کلیک می‌کند اقدامات قابل مشاهده – اجرای فایل مسدود می‌شود– سیستم ایزوله نمی‌شود چون حمله متوقف شده– نوتیفیکیشن هشدار برای مدیر IT صادر می‌شود فرایند پشت‌پرده MPP – تحلیل رفتار فایل قبل از اجرا (Pre-execution AI analysis)– تشخیص intent مخرب (Intent-based detection)– بلاک کردن فرآیند قبل از نوشتن در دیسک (On-write blocking)- ثبت signature تهدید برای آینده سناریو ۲: «ایمیل جعلی از طرف مدیرعامل» شرح محتوا تهدید حمله‌ای با ایمیل جعلی حاوی لینک فیشینگ و درخواست پرداخت رفتار کاربر کاربر روی لینک کلیک می‌کند؛ ممکن است فایل/اسکریپت دانلود شود اقدامات قابل مشاهده – اجرای فایل یا اسکریپت به‌سرعت بلاک می‌شود- فایل در قرنطینه قرار می‌گیرد- لاگ و گزارش ارسال می‌شود فرایند پشت‌پرده MPP – تشخیص URLهای مخرب با تحلیل رفتار DNS/HTTP– تحلیل فایل دانلودشده با sandbox داخلی– جلوگیری از ارتباط با سرور C2 (Command & Control)– ایجاد گزارش کامل حمله (Root-cause analysis) سناریو ۳: «بدافزار از طریق فایل Excel و USB» شرح محتوا تهدید حمله بدون اینترنت با بدافزار فایل‌لس در فایل ماکرو Excel رفتار کاربر فایل اکسل را باز می‌کند و ماکرو اجرا می‌شود اقدامات قابل مشاهده – فایل مشکوک شناسایی و قرنطینه می‌شود– اجرای PowerShell یا WMI توسط فایل بلاک می‌شود– نوتیفیکیشن برای تیم IT صادر می‌شود فرایند پشت‌پرده MPP – تحلیل ماکرو و رفتارهای مرتبط با فایل‌لس (Fileless detection)– تحلیل بلادرنگ حافظه (Memory scanning)– شناسایی و بلاک حملات Living-off-the-land– حفاظت آفلاین بدون نیاز به اینترنت سناریو ۴: «باج‌افزار شبانه در دیتاسنتر» شرح محتوا تهدید باج‌افزار فعال شده و ۱۴ سرور را هدف گرفته رفتار سیستم حمله در حال گسترش، بدون مداخله انسانی اقدامات قابل مشاهده – ایزوله شدن فوری سیستم‌های آلوده– بازیابی فایل‌ها از نسخه‌ی امن– ارسال هشدار بلادرنگ به مدیر فرایند پشت‌پرده MPP – شناسایی رفتار رمزنگاری فایل‌ها (Behavioral ransomware detection)– فعال شدن فایل‌های decoy برای فریب بدافزار- اسکن فرآیندهای حافظه و توقف رمزنگاری– بازیابی خودکار از snapshot داخلی– گزارش کامل رویداد + توصیه فنی برای پیشگیری آینده این‌ها فقط چند سناریو از دنیای تهدیدات امروز بودند… اما MPP چیست؟ Malware Protection Plus محصول شرکت ManageEngine نه‌تنها این حملات، بلکه ده‌ها سناریوی پیچیده‌تر و هدفمند را هم شناسایی و خنثی می‌کند. همه و همه قبل از آن‌که خسارتی ایجاد کنند، متوقف می‌شوند. این نرم‌افزار، چه حملاتی را خنثی می‌کند؟ 🔒 فایل‌لس و حملات بدون ردپای مشخص🛑 اجرای اسکریپت مخرب از […]

در این مقاله آموزشی و اختصاصی مدانت می‌خوانید: جریان ارزش چیست و نقش آن در زنجیره ارزش خدمات SVC تصور کنید ساعت ۹ صبح روز کاری است. یکی از کاربران کلیدی سازمان نمی‌تواند به سیستم مالی دسترسی پیدا کند. با اضطراب تماس می‌گیرد و می‌گوید: «من دسترسی ندارم، همه‌چیز قفل شده، لطفاً کمکم کنید!» در این لحظه، برای ما کارشناسان پشتیبانی فناوری اطلاعات فقط یک هدف وجود دارد: بازگرداندن سرویس در سریع‌ترین زمان ممکن با کمترین تأثیر بر عملیات کاربر. اما این فقط یک تماس ساده نیست؛ پشت‌صحنه‌ی این درخواست، یک Value Stream فعال می‌شود – مسیری مشخص و به‌هم‌پیوسته از فعالیت‌هایی که با هماهنگی تیم‌ها، فناوری، فرآیندها و بازخوردهای مداوم، به ایجاد یک نتیجه ارزشمند ختم می‌شود:بازگشت کاربر به سیستم و ادامه روان کار سازمان. در ITIL 4، ما به چنین مسیری می‌گوییم جریان ارزش (Value Stream).و این یعنی: به جای اینکه صرفاً روی اجرای یک فرآیند تمرکز کنیم، از زاویه‌ای وسیع‌تر و مشتری‌محور به کل مسیر نگاه می‌کنیم – از ثبت حادثه تا بازیابی کامل سرویس. با مدانت همراه شوید تا دقیق بیاموزید جریان ارزش چیست و چکار می‌کند؟ تعریف ساده: Value Stream به مجموعه‌ای از فعالیت‌ها و منابع گفته می‌شود که با همکاری و هماهنگی، یک ارزش مشخص برای مشتری یا ذی‌نفع ایجاد می‌کنند. تعریف رسمی ITIL4: A value stream is a series of steps an organization undertakes to create and deliver products and services to consumers.(مجموعه‌ای از مراحل برای خلق و ارائه‌ی ارزش)

چرخه‌ی حیات نرم‌افزار در ITIL4: از جرقه تا فاجعه! در این مقاله کاربردی می‌خوانید: هر نرم‌افزاری، با یک ایده شروع می‌شود. تصور کنید در سازمان ما، بخش منابع انسانی نیاز به یک سامانه‌ی ارزیابی عملکرد دارد. من بعنوان مدیر خدمات فناوری اطلاعات، این نیاز را دریافت می‌کنم. حالا، مسیر چرخه حیات آغاز می‌شود. این را حال به کسب‌وکار تعمیم دهید فرض کنید نیازی را شناسایی کرده‌اید یا مشتری از شما چیزی خواسته. چطور شروع کنیم؟ 1. ایده‌پردازی تا طراحی – Engage + Plan در مرحله‌ی نخست، نیاز کسب‌وکار را مستند می‌کنیم (فرایند Engage). سپس، در چارچوب ITIL 4 با کمک Plan، یک برنامه‌ی دقیق شامل منابع، بودجه، ریسک‌ها و نقاط عطف آماده می‌سازیم. طراحی اولیه نرم‌افزار (High-Level Design) حاصل همین مرحله است. 2. ساخت، تست و انتقال – Design & Transition + Build در این مرحله با همکاری تیم توسعه و تست، محصول ساخته می‌شود و فرایند Design and Transition وارد فاز عملیاتی می‌گردد. اینجاست که اهمیت DevOps یا Agile به کمکمان می‌آید. با استفاده از Continuous Integration/Deployment، استقرار اولیه (Pilot) انجام و در محیط محدود بررسی می‌شود. 3. اجرا و پشتیبانی – Deliver & Support نرم‌افزار وارد فاز بهره‌برداری می‌شود. کاربران از آن استفاده می‌کنند و ما، با کمک فرایند Incident Management، پشتیبانی مستمر ارائه می‌دهیم. هر مشکل به‌سرعت ثبت، اولویت‌بندی و رفع می‌شود. 4. ارزیابی ارزش – Improve چند ماه بعد، با داده‌های واقعی، ROI را محاسبه می‌کنیم. آیا زمان صرفه‌جویی شد؟ هزینه‌ها کاهش یافت؟ رضایت کاربران بالا رفت؟ اگر پاسخ مثبت است، پس به هدف رسیده‌ایم. در غیر این‌صورت، وارد چرخه‌ی Continual Improvement می‌شویم. فرایندهای کلیدی در چرخه‌ی حیات نرم‌افزار (بر اساس ITIL 4):

در چارچوب ITIL 4، جداسازی استقرار (Deployment) از انتشار (Release) بخشی از تمرین‌های پیشرفته در دو حوزه‌ی Release Management و Deployment Management محسوب می‌شود. ITIL 4 تأکید دارد که انتشار یک تغییر برای کاربران نهایی نباید الزاماً همزمان با استقرار فنی آن باشد. این رویکرد، که با استفاده از ابزارهایی مانند feature toggles، blue-green deployment یا canary releases پشتیبانی می‌شود، امکان تحویل ارزش به‌صورت امن، کنترل‌شده و با ریسک کمتر را فراهم می‌کند. در ITIL 4، تمرکز بر مدیریت ارزش کسب‌وکار است، نه صرفاً تحویل تغییر، و این جداسازی دقیقاً همین هدف را محقق می‌کند. قبل از بررسی این جداسازی بیایید یک سناریو واقعی را بررسی کنیم. نجات پروژه فروشگاه آنلاین در یک جمعه سیاه سناریو: شرکت ایکس بعنوان مالک یک پلتفرم فروشگاهی بزرگ در کشور، تصمیم می‌گیرد یک فیچر پیشنهاد هوشمند را برای افزایش فروش محصولات خود فعال کند. ویژگی‌ها کاملاً تست شده‌اند، اما ریسک اصلی زمان انتشار است: جمعه سیاه، ساعت ۹ صبح. تیم مجبور است ویژگی جدیدی را در روز جمعه سیاه ارائه دهد. یک اشتباه کوچک در این روز می‌تواند میلیون‌ها تومان خسارت وارد کند. در اینجا، جدا کردن استقرار از انتشار راه‌حلی نجات‌بخش می‌شود. این یعنی شرکت ایکس به‌جای انتشار مستقیم تصمیم می‌گیرد: نتیجه:نه‌تنها سیستم بدون مشکل کار کرد، بلکه فروش آن روز ۲۷٪ افزایش یافت. مشتریان هم تجربه بهتری داشتند جدا کردن استقرار از انتشار باعث شد تیم بتواند بدون نگرانی از بروز خطا در زمان اوج ترافیک، کنترل کامل بر ویژگی جدید داشته باشد. این رویکرد نه فقط در جمعه سیاه، بلکه در هر به‌روزرسانی مهمی ضروری است. در جدول زیر، دو تکنیک مهم در جداسازی استقرار (Deployment) از انتشار (Release) در چارچوب ITIL 4 — یعنی Feature Toggle و Canary Release — به صورت مقایسه‌ای شرح داده شده‌اند: جدول مقایسه Feature Toggle و Canary Release تکنیک‌های Feature Toggle و Canary Release سابقه‌ای چندده‌ساله در مهندسی نرم‌افزار دارند، اما با گسترش متدلوژی‌های چابک (Agile) و DevOps، نقش آن‌ها در مدیریت تغییر و انتشار بسیار پررنگ‌تر شده است. Feature Toggle نخستین بار توسط توسعه‌دهندگان در شرکت‌هایی مثل Flickr و Facebook مورد استفاده قرار گرفت تا ویژگی‌هایی را در محیط production مستقر کنند اما تنها برای گروه خاصی از کاربران یا در شرایط خاص فعال نمایند. این روش به تیم‌ها اجازه می‌دهد بدون نیاز به بازاستقرار، ویژگی‌ها را روشن یا خاموش کرده و کنترل دقیق‌تری بر زمان و نحوه انتشار داشته باشند. از سوی دیگر، Canary Release الهام‌گرفته از روش‌های ایمنی در معادن (استفاده از قناری‌ها برای شناسایی گازهای سمی) است و اولین بار در مقیاس وسیع توسط Google و Netflix به‌کار گرفته شد. این تکنیک به تیم‌ها اجازه می‌دهد تا نسخه‌ی جدیدی از نرم‌افزار را ابتدا برای درصد محدودی از کاربران منتشر کرده و در صورت عدم مشاهده مشکل، آن را به کل کاربران گسترش دهند. هر دو روش امروز بخشی جدایی‌ناپذیر از استراتژی‌های مدرن انتشار در چارچوب‌هایی مانند ITIL 4، Site Reliability Engineering (SRE) و Continuous Delivery هستند. ویژگی / تکنیک Feature Toggle (کلید ویژگی) Canary Release (انتشار قناری‌وار) تعریف مکانیسمی در کد که به شما اجازه می‌دهد یک ویژگی را بدون تغییر در کد اصلی فعال یا غیرفعال کنید. نوعی انتشار تدریجی که ابتدا تنها برای درصد کمی از کاربران فعال می‌شود. هدف اصلی جدا کردن زمان استقرار از زمان فعال‌سازی ویژگی برای کاربران. شناسایی مشکلات احتمالی در مقیاس کوچک قبل از انتشار عمومی. نحوه اجرا از طریق پارامترهای پیکربندی یا ابزارهای third-party (مثلاً LaunchDarkly، Unleash). با تقسیم ترافیک به چند گروه و هدایت آن به نسخه جدید از نرم‌افزار در محیط production. مزیت کلیدی کنترل لحظه‌ای و سریع بر فعال‌سازی ویژگی‌ها بدون نیاز به استقرار مجدد. کاهش ریسک انتشار و امکان rollback سریع در صورت بروز مشکل. مناسب برای ویژگی‌های بزرگ […]

یک ITIL مینیمال و کاربردی در جلساتی مدیریتی، پرسشی که برخی از مدیران ارشد یا مدیران فناوری اطلاعات می‌پرسند این است که کدام فرایندها را باید پیاده کنیم؟ پرسش هوشمندانه‌ای است، و اتفاقاً یکی از دغدغه‌های رایج مدیران در مسیر پیاده‌سازی ITIL همین است: “کدام فرایندها را پیاده کنیم؟ همه یا فقط چند مورد؟” اینجا مسئله پول و زمان نیست؛ بلکه مهمتر از آن آیتم‌های دیگری است که باید در پاسخ بدان پرداخت بعبارتی پاسخ این است که: ITIL4 حدود ۳۴ تمرین دارد. پیاده‌سازی کدام تمرینات بستگی شدیدی به بلوغ سازمان شما، دردها و دغدغه‌هایتان دارد. لازم نیست همه‌ی فرایندهای ITIL را اجرا کنید. باید آن‌هایی را اجرا کنید که: فرایندهایی که بیشتر سازمان‌ها با آن‌ها شروع می‌کنند: فرایند چرا انتخاب می‌شود؟ مناسب چه وضعیتی است؟ Incident Management برای کاهش زمان پاسخ‌گویی به مشکلات کاربران اگر کاربران شکایت زیادی دارند Request Fulfillment برای مدیریت درخواست‌های تکراری (مثل نصب نرم‌افزار) اگر Helpdesk غرق در درخواست‌هاست Change Enablement برای جلوگیری از تغییرات غیرمجاز و کاهش ریسک اگر تغییرات باعث اختلال می‌شوند Asset & Configuration Management برای دانستن چی داریم و کجا هست اگر دارایی‌ها گم می‌شوند یا پشتیبانی دشوار است Knowledge Management برای مستندسازی راه‌حل‌های پرتکرار اگر حل تکراری مشکلات وقت زیادی می‌گیرد راهنمای انتخاب: برای شروع حداقلی و مؤثر با چارچوب ITIL (یا همان Minimum Viable ITIL)، بهتر است فقط فرایندهایی را اجرا کنید که بیشترین ارزش را با کمترین تلاش ایجاد می‌کنند. در اینجا یک نقشه راه ساده و کاربردی برای شروع آورده‌ایم: هدف: ساخت یک ITIL مینیمال و کاربردی برای بهبود خدمات IT Minimum Viable ITIL یا به‌اختصار MVI، به معنی «حداقل چارچوب لازم از ITIL برای شروعی مؤثر» است. این رویکرد بر این اصل استوار است که شما لازم نیست کل ITIL را یکجا پیاده‌سازی کنید؛ بلکه باید با ساده‌ترین و مهم‌ترین فرایندهایی شروع کنید که بیشترین ارزش را با کمترین پیچیدگی ایجاد می‌کنند. تعریف ساده: Minimum Viable ITIL یعنی انتخاب و اجرای فقط همان بخش‌هایی از ITIL که برای شروع، بیشترین دردهای IT سازمان را درمان می‌کنند. اهداف Minimum Viable ITIL: مثال یک MVI واقعی: یک سازمان می‌تواند فقط با ۳ فرایند زیر شروع کند: و به‌تدریج فرایندهایی مانند Asset Management یا Problem Management را اضافه کند. یک نقشه‌راه حداقلی! 1. تمرکز روی سه فرایند حیاتی (Core Trio): فرایند چرا مهم است؟ ابزار پیشنهادی Incident Management پاسخ سریع به مشکلات کاربران Jira, ServiceDesk Plus Change Enablement مدیریت تغییرات بدون ریسک Jira Change Workflow Service Request Management پاسخ به درخواست‌های تکراری (مثلاً نصب نرم‌افزار) Self-service Portal 2. تعریف MVP هر فرایند (Minimum Viable Process): مثلاً برای Incident Management: 3. یک داشبورد ساده برای KPIهای اصلی: 4. ارتباط با کاربران (Communication): 5. بازخورد و بهبود تدریجی: جدول تصمیم‌گیری برای انتخاب فرایندهای ITIL مسأله یا درد سازمانی فرایند پیشنهادی ITIL هدف اجرای این فرایند کاربران از کندی یا بی‌پاسخ بودن پشتیبانی شکایت دارند Incident Management ثبت، پیگیری و حل سریع مشکلات درخواست‌های تکراری مثل نصب نرم‌افزار یا دسترسی زیاد شده‌اند Service Request Management نظم‌دهی به درخواست‌های پرتکرار تغییرات فنی باعث قطعی یا اختلال در سرویس‌ها می‌شوند Change Enablement کنترل و ارزیابی تغییرات پیش از اجرا کسی نمی‌داند چه دارایی‌هایی داریم یا کجا هستند Asset & Configuration Management ثبت و پیگیری تجهیزات IT نیروها مجبورند مشکلات را بارها از نو حل کنند Knowledge Management مستندسازی راه‌حل‌های پرتکرار گزارش‌گیری از عملکرد IT امکان‌پذیر نیست Service Level Management تعیین و پایش سطح خدمات (SLA) اولویت‌بندی درست بین کارها وجود ندارد Incident & Request Prioritization نظم‌دهی بر اساس اولویت تجاری نکته کلیدی: برای شروع، فقط 2 تا 3 مورد اول را پیاده‌سازی کنید. بقیه را به‌مرور و بر اساس نیاز اضافه کنید. برای طراحی یک سناریوی دقیق Minimum Viable ITIL (MVI) برای شما، لازم دارم […]