وقتی دو سوم یک رمان جنایی را میخوانید و پرونده ظاهراً بسته شده است، غریزی میدانید که یک پیچش داستانی در راه است. امنیت ابری (Cloud Security) دقیقاً به همین شکل کار میکند. ایجاد پیرامونهای محکم و قفل کردن فایروالها حس کاذب امنیت مطلق را به وجود میآورد و این حقیقت اجتنابناپذیر را نادیده میگیرد که مهاجمان مصمم بالاخره روزی از دفاعهای شما عبور خواهند کرد. مسئله اصلی که این فصل به آن میپردازد، شکاف خطرناک میان زمان وقوع یک نفوذ (Breach) و زمان آگاه شدن تیم شما از آن است. بدون تشخیص دقیق، پاسخهای خودکار و کتابچههای بازیابی تمرینشده، یک نفوذ خاموش به درز دادههای فاجعهباری تبدیل میشود که میلیونها دلار هزینه به بار میآورد و اعتماد مشتریان را نابود میکند. زیرساخت تشخیص را مانند سیستم حفاظتی یک خانه تصور کنید: داشتن در و قفل ضروری است، اما بدون سنسورهای حرکتی و آلارمهای شکستن شیشه، یک سارق میتواند ماهها در اتاق مهمان شما زندگی کند بدون اینکه متوجه حضورش شوید. درک حوادث امنیتی مستلزم قدردانی از نحوه فاصله گرفتن آنها از مشکلات سنتی فناوری اطلاعات است. عیبیابی سنتی روی خرابیهای تصادفی سختافزار یا باگهای نرمافزاری تمرکز دارد که با پشتههای خطا و کرش سرور با صدای بلند اعلام حضور میکنند. در مقابل، حوادث امنیتی عمدی، پنهانکارانه و طراحی شدهاند تا شبیه رفتار کاربران قانونی باشند. برای شکار این بازیگران پنهان، باید بدانید چه چیزی را در کل اکوسیستم خود زیر نظر داشته باشید. این کار با دسترسی کاربران ممتاز (Privileged User Access) شروع میشود؛ جایی که اعتبارت کلیدی به سرقت رفته به مهاجمان کلید پادشاهی را میدهد. بدون ممیزی سختگیرانه، کاربران سرکش یا کلیدهای دزدیده شده نامرئی عمل میکنند. ابزارهای دفاعی، سرویسهای ابری و سیستمهای عامل دائماً حجم عظیمی از دادههای تلهمتری را تولید میکنند. اگر لاگهای مربوط به ابزارهای دفاعی (Defensive Tooling)، لاگها و متریکهای سرویس ابری (Cloud Service Logs and Metrics)، یا لاگها و متریکهای سیستم عامل (Operating System Logs and Metrics) را نادیده بگیرید، با چشم بسته رانندگی میکنید. به همین ترتیب، لاگهای میانافزار (Middleware Logs) و سرور رازها (Secrets Server) رشتههای اتصال و توکنهای API دقیقی را که مهاجمان برای نفوذ عمیقتر در معماری شما تشنه آن هستند، آشکار میکنند. در نهایت، لایه اپلیکیشن شما نیز باید مانیتور شود؛ نادیده گرفتن اپلیکیشن شما (Your Application) به معنا از دست دادن سوءاستفادههای سفارشی از منطق کسبوکار است که ابزارهای سطح زیرساخت هرگز نمیتوانند آنها را ببینند. جمعآوری دادهها بدون داشتن استراتژی برای نحوه نظارت (How to Watch) بیفایده است. دادههای خام مانند یک شلنگ آتشنشانی هستند، بنابراین شما به خط لولههای جمعآوری و نگهداری (Aggregation and Retention) برای ذخیره مرکزی لاگها، تجزیه لاگها (Parsing Logs) برای تبدیل متنهای ساختارنیافته به فیلدهای قابل جستجو، و موتورهای جستجو و همبستگی (Searching and Correlation) برای اتصال رویدادهای مختلف نیاز دارید — مانند یک ورود ناموفق در یک منطقه که بلافاصله با دانلود پایگاه داده در منطقهای دیگر دنبال میشود. این موضوع مستقیماً به سیستمهای هشداردهی و پاسخ خودکار (Alerting and Automated Response) منجر میشود که توسط مدیران اطلاعات امنیتی و رویداد (Security Information and Event Managers) پشتیبانی میشوند و ناهنجاریها را علامتگذاری کرده و مهار خودکار را قبل از اینکه مهندسان بتوانند قهوه صبحگاهی خود را بنوشند، فعال میکنند. برای جلوتر ماندن از مهاجمان پیشرفته، تیمهای امنیتی از شکار تهدید (Threat Hunting) استفاده میکنند — یعنی به جای انتظار برای به صدا درآمدن زنگ خطر، بهطور فعالانهتری لاگهای خود را برای ناهنجاریهای پنهان جستجو میکنند. وقتی تشخیص به ناچار در جلوگیری از نفوذ شکست میخورد، آمادگی بقا را تعیین میکند. آماده شدن برای یک حادثه (Preparing for an Incident) به معنای گردهم آوردن یک تیم (Team) اختصاصی، نوشتن برنامهها (Plans) واضح و انتخاب ابزارهای (Tools) مناسب قبل از وقوع فاجعه است. در طول یک رویداد فعال، پاسخ به یک حادثه (Responding to an Incident) مستلزم چارچوبهای ساختاریافته مانند زنجیرههای کشتار سایبری و MITRE ATT&CK (Cyber Kill Chains and MITRE ATT&CK) برای طبقهبندی رفتار مهاجم و حلقه OODA (The OODA Loop) برای حفظ سرعت عملیاتی تحت فشار شدید است. محققان همچنین باید پزشکی قانونی ابری (Cloud Forensics) را برای استخراج شواهد دیجیتال بدون تغییر حالتهای فرار تسلط پیدا کنند، در حالی که بهطور فعال مسدود کردن دسترسی غیرمجاز (Blocking Unauthorized Access) و متوقف کردن خارج کردن دادهها و فرمان و کنترل (Stopping Data Exfiltration and Command and Control) را انجام میدهند. هنگامی که مهاجم بیرون رانده شد، فاز بازیابی (Recovery) آغاز میشود که شامل استقرار مجدد سیستمهای فناوری اطلاعات (Redeplying IT Systems)، ارسال دقیق اعلانها (Notifications) به ذینفعان و مشتریان، و انجام بررسیهای پس از حادثه یا همان درسهای آموختهشده (Lessons Learned) برای اطمینان از عدم تکرار بردار نفوذ است. برای اطمینان از عملکرد واقعی این سیستمها، مهندسان باید متریکهای نمونه (Example Metrics) را تجزیهوتحلیل کنند، ابزارهای نمونه برای تشخیص، پاسخ و بازیابی (Example Tools for Detection, Response, and Recovery) را آزمایش کنند، و تشخیص و پاسخ در یک اپلیکیشن نمونه (Detection and Response in a Sample Application) را پیادهسازی کنند. این امر نیازمند نظارت بر سیستمهای حفاظتی (Monitoring the Protective Systems)، نظارت بر اپلیکیشن (Monitoring the Application)، نظارت بر مدیران سیستم (Monitoring the Administrators) و درک عمیق زیرساخت ممیزی (Understanding the Auditing Infrastructure) است. بدون این نظارت همهجانبه، تورهای نجات شما به سرعت به نقاط کور تبدیل میشوند. پیمایش تنش بین کنترلهای امنیتی سختگیرانه و سرعت توسعهدهندگان یک تعادل دائمی است. هشدار بیش از حد باعث خستگی از هشدار میشود و مهندسان را وادار میکند هشدارهای حیاتی را نادیده بگیرند، در حالی که هشدار کم سازمان را در برابر نفوذهای خاموش آسیبپذیر میسازد. دستیابی به این تعادل مستلزم این است که تلهمتری امنیتی به عنوان یک ویژگی درجه یک محصول در نظر گرفته شود نه یک فکر بعدی. [ ] پیکربندی تجمیع متمرکز لاگها و تعریف سیاستهای سختگیرانه نگهداری دادهها. [ ] پیادهسازی احراز هویت چندمرحلهای و ممیزی دقیق برای تمام حسابهای کاربری ممتاز. [ ] تجزیه و نرمالسازی لاگهای سیستمعامل، ابر و میانافزار به فرمتهای قابل جستجو. [ ] ساخت قوانین همبستگی و هشدارها برای رفتارهای ناهنجار پرخطر. [ ] ایجاد یک برنامه مکتوب پاسخ به حادثه و برگزاری تمرینات رومیزی. [ ] تسلط بر تکنیکهای پزشکی قانونی ابری برای بررسی نفوذها بدون از بین بردن شواهد. [ ] استقرار اسکریپتهای مهار خودکار برای مسدود کردن فوری دسترسی غیرمجاز و خروج دادهها. [ ] برگزاری جلسات بررسی بدون سرزنش و درسهای آموختهشده پس از هر رویداد امنیتی.
