هیچ نرم افزاری بدون باگ وجود ندارد، درست است؟ در حالی که این یک احساس رایج است، ما مفروضاتی را می‌سازیم که بر این فرض تکیه می‌کنند که نرم‌افزار هیچ اشکالی در زندگی دیجیتالی روزانه ما ندارد. ما به ارائه‌دهندگان هویت (IDP) اعتماد داریم تا احراز هویت را به درستی انجام دهند، سیستم‌های عامل کاملاً با مشخصات آنها مطابقت داشته باشند و تراکنش‌های مالی همیشه مطابق با هدف انجام شوند. حتی واضح تر، ما به نرم افزار با ایمنی فیزیکی خود اعتماد داریم رفتن در هواپیما، رانندگی با خودرویی که به طور فعال پایبندی ما به خطوط ترافیکی یا فاصله ما از خودروی جلویی یا انجام برخی جراحی های خاص را اصلاح می کند. چه چیزی این امکان را فراهم می کند؟ یا به عبارت دیگر چرا هواپیماها به دلیل نرم افزار بد از آسمان سقوط نمی کنند؟
تضمین کیفیت نرم افزار از ابزارهای علمی و مهندسی وام گرفته شده است. یکی از راه‌های تضمین و بهبود کیفیت نرم‌افزار، عمومی کردن آن و دادن انگیزه به افراد زیادی برای تلاش برای شکستن آن است.
دیگری استفاده از الگوهای طراحی یا چارچوب های معماری خوب است که ریشه در مهندسی دارند. برای مثال، در حالی که نمی‌توان هر پروژه نرم‌افزاری را تحت همان سطح بررسی هسته لینوکس قرار داد، که برای چندین دهه تحت بررسی بوده است، پروژه‌های نرم‌افزاری می‌توانند کد منبع را باز کنند تا بررسی دقیق شوند یا کدی را برای ممیزی ارسال کنند به این امید که برخی از موارد را به دست آورند. تضمین های امنیتی
و البته، تست وجود دارد. خواه استاتیک، پویا، یا بلادرنگ، که توسط توسعه‌دهنده یا یک تیم اختصاصی انجام می‌شود، آزمایش بخش عمده‌ای از توسعه نرم‌افزار است. با نرم افزارهای حیاتی، آزمایش معمولاً یک پروژه کاملاً مجزا است که توسط یک تیم جداگانه با تخصص خاص انجام می شود.
تست خوب است، اما ادعای جامع بودن ندارد. هیچ تضمینی وجود ندارد که ما همه اشکالات را پیدا کنیم زیرا نمی دانیم کدام اشکالات را نمی دانیم. آیا ما قبلاً 99٪ از اشکالات هسته لینوکس را در آنجا پیدا کرده ایم؟ 50 درصد؟ 10 درصد؟
ادعای "مطلق"
حوزه تحقیق روش‌های رسمی به دنبال راه‌هایی است تا به شما اطمینان دهد که در یک نرم‌افزار خاص، مانند کارگزار سهام یا مرجع گواهی، هیچ اشکالی وجود ندارد. ایده اصلی این است که نرم افزار را به ریاضی ترجمه کنید، جایی که همه چیز به خوبی تعریف شده باشد، و سپس یک مدرک واقعی ایجاد کنید که نرم افزار بدون اشکال کار می کند. به این ترتیب، می توانید مطمئن شوید که نرم افزار شما بدون اشکال است، همانطور که می توانید مطمئن باشید که هر عدد می تواند به ضرب اعداد اول تجزیه شود. (توجه داشته باشید که من تعریفی از اشکال ندارم. همانطور که بعداً خواهیم دید، این یک مشکل خواهد بود.)
تکنیک‌های روش رسمی مدت‌هاست که برای نرم‌افزارهای حیاتی مورد استفاده قرار می‌گرفتند، اما آنها بسیار محاسباتی و سخت‌گیر بودند و بنابراین فقط برای قطعات کوچک نرم‌افزار، مانند بخش محدودی از میان‌افزار تراشه یا یک پروتکل احراز هویت، اعمال می‌شدند. در سال های اخیر، اثبات کننده های قضیه پیشرفته مانند Z3 و خروس استفاده از این فناوری را در زمینه بزرگتری ممکن ساخته است. اکنون به طور رسمی تأیید شده است زبانهای برنامه نویسی, سیستم های عاملو کامپایلرها که 100% ضمانت کار بر اساس مشخصات خود را دارند. استفاده از این فناوری ها همچنان به تخصص پیشرفته و توان محاسباتی زیادی نیاز دارد که آنها را برای اکثر سازمان ها بسیار گران می کند.
ارائه‌دهندگان بزرگ ابر در حال انجام راستی‌آزمایی رسمی پشته‌های اساسی خود هستند تا به سطوح بالایی از تضمین امنیت برسند. آمازون و مایکروسافت گروه‌های تحقیقاتی اختصاصی دارند که با تیم‌های مهندسی کار می‌کنند تا روش‌های تأیید رسمی را در زیرساخت‌های حیاتی مانند ذخیره‌سازی یا شبکه‌سازی بگنجانند. مثالها عبارتند از AWS S3 و EBS و بلاک چین لاجوردی. اما واقعیت جالب این است که در چند سال گذشته، ارائه دهندگان ابری بوده اند تلاش برای کالایی کردن تأیید رسمی برای فروش به مشتریان خود.
به طور قاطع پیکربندی نادرست را حل می کنید؟
سال گذشته، AWS دو ویژگی را منتشر کرد که از تأیید رسمی برای رسیدگی به مشکلاتی استفاده می کند که مدت هاست مشتریان خود را آزار می دهد، یعنی شبکه و پیکربندی نادرست مدیریت هویت و دسترسی (IAM).س دسترسی به شبکه و پیکربندی های IAM حتی برای یک حساب کاربری پیچیده است و این پیچیدگی در یک سازمان بزرگ با تصمیم گیری و حاکمیت توزیع شده به شدت افزایش می یابد. AWS با دادن کنترل‌های ساده به مشتریان خود - مانند «سطل‌های S3 نباید در معرض اینترنت قرار گیرند» یا «ترافیک اینترنت به نمونه‌های EC2 باید از طریق فایروال عبور کند» - و تضمین اعمال آنها در هر سناریوی پیکربندی ممکن، آن را برطرف می‌کند.
AWS اولین کسی نیست که به مشکل پیکربندی نادرست پرداخته است، حتی برای مسائل خاص AWS مانند سطل های S3 را باز کنید. فروشندگان مدیریت وضعیت امنیت ابری (CSPM) مدتی است که به این موضوع پرداخته‌اند و پیکربندی کانال پورت مجازی (VPC) و نقش‌های IAM را تجزیه و تحلیل می‌کنند و مواردی را شناسایی می‌کنند که در آن امتیازات خیلی ضعیف هستند، از ویژگی‌های امنیتی به درستی استفاده نمی‌شود، و داده‌ها می‌توانند در معرض دید قرار گیرند. به اینترنت خوب چه خبر؟
خوب، اینجاست که تضمین مطلق وارد می شود راه حل CSPM با ایجاد یک لیست شناخته شده-بد یا شناخته شده-خوب از پیکربندی های نادرست کار می کند، گاهی اوقات زمینه را از محیط شما اضافه می کند و بر اساس آن نتایج تولید می کند. تحلیلگرهای شبکه و IAM با بررسی هر درخواست بالقوه IAM یا شبکه کار می‌کنند و تضمین می‌کنند که طبق مشخصات شما منجر به دسترسی ناخواسته نمی‌شوند (مانند «عدم دسترسی به اینترنت»). تفاوت در تضمین های مربوط به منفی های کاذب است.
در حالی که AWS ادعا می‌کند که هیچ راهی وجود ندارد که چیزی را از دست داده باشد، فروشندگان CSPM می‌گویند که همیشه در جستجوی پیکربندی‌های نادرست جدید برای فهرست‌نویسی و شناسایی هستند، که تأییدی است که قبلاً این پیکربندی‌های اشتباه را شناسایی نکرده‌اند.
برخی از اشکالات تأیید رسمی
تأیید رسمی برای یافتن مسائل کاملاً تعریف شده مانند مسائل امنیتی حافظه عالی است. با این حال، هنگام تلاش برای یافتن باگ‌های منطقی، همه چیز دشوار می‌شود، زیرا آنها نیاز به مشخص کردن آنچه که کد واقعاً قرار است انجام دهد، دقیقاً همان کاری است که خود کد انجام می‌دهد، دشوار می‌شود.
برای یک چیز، تأیید رسمی مستلزم تعیین اهداف کاملاً تعریف شده است. در حالی که برخی از اهداف، مانند جلوگیری از دسترسی به اینترنت، به اندازه کافی ساده به نظر می رسند، اما در واقعیت چنین نیستند. مستندات تحلیلگر AWS IAM دارد یک بخش کامل تعریف «عمومی» به معنای، و پر از هشدارها است. تضمین هایی که ارائه می دهد فقط به اندازه ادعاهای ریاضی که کدگذاری کرده است خوب است.
همچنین بحث پوشش وجود دارد. آنالایزرهای AWS تنها چند سرویس اصلی AWS را پوشش می دهند. اگر ترافیک را از طریق یک کانال اتصال خروجی به شبکه خود هدایت کنید، تحلیلگر نمی داند. اگر سرویسی به دو نقش IAM دسترسی داشته باشد و بتواند آنها را برای خواندن از یک سطل عمومی محرمانه و نوشتن در یک سطل عمومی ترکیب کند، تحلیلگر نمی‌داند. با این وجود، در برخی از زیرمجموعه‌های کاملاً تعریف‌شده مشکل پیکربندی نادرست، تأیید رسمی تضمین‌های قوی‌تری نسبت به قبل ارائه می‌دهد.
با بازگشت به سوال مزیت نسبی مطرح شده در بالا، تفاوت این است که IAM و تحلیلگر شبکه ادعا می کنند که لیست مشکلات شناسایی شده آن جامع است، در حالی که CSPM ادعا می کند که لیست آن هر پیکربندی نادرست شناخته شده امروزی را پوشش می دهد. این سوال کلیدی است: آیا باید اهمیت دهید؟
آیا باید به تضمین های مطلق اهمیت دهیم؟
سناریوی زیر را در نظر بگیرید. شما صاحب یک CSPM هستید و به شبکه AWS و تحلیلگر IAM نگاه می کنید. با مقایسه نتایج این دو، متوجه می شوید که آنها دقیقاً همان مشکلات را شناسایی کرده اند. پس از مدتی تلاش، تمام مشکلات موجود در آن لیست را برطرف می کنید. تنها با تکیه بر CSPM خود، احساس می کنید اکنون در مکان خوبی هستید و می توانید منابع امنیتی را به جای دیگری اختصاص دهید. با افزودن آنالایزرهای AWS به ترکیب، اکنون - با ضمانت AWS - می‌دانید که در مکان خوبی هستید. آیا این نتایج یکسان است؟
حتی اگر اخطار راستی‌آزمایی رسمی را نادیده بگیریم و فرض کنیم که 100% مسائل را برطرف می‌کند، اندازه‌گیری مزایا نسبت به سرویس‌های مبتنی بر شناسایی مانند CSPM تمرینی برای هر سازمانی با ریسک امنیتی خاص خود خواهد بود. برخی این تضمین های مطلق را پیشگامانه می یابند، در حالی که برخی دیگر احتمالاً به کنترل های موجود پایبند هستند.
این سوالات منحصر به CSPM نیستند. همین مقایسه‌ها را می‌توان برای ابزارهای تست امنیت برنامه‌های کاربردی وب SAST/DAST/IAST و نرم‌افزارهای رسمی تأیید شده، به عنوان مثال، انجام داد.
صرف نظر از انتخاب‌های سازمانی فردی، یکی از عوارض جانبی هیجان‌انگیز این فناوری جدید، راهی مستقل برای شروع اندازه‌گیری نرخ‌های منفی کاذب راه‌حل‌های امنیتی است، که فروشندگان را به سمت بهتر شدن سوق می‌دهد و شواهد واضحی را برای آنها ارائه می‌کند که در آن جا باید بهبود یابند. این به خودی خود کمک بزرگی به صنعت امنیت سایبری است.
