اصول متداول طراحی امن نرم‌افزار

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

صرفه‌جویی در مکانیزم

تا حد امکان طراحی و کد را ساده و کوچک نگه دارید. طراحی پیچیده‌تر منجر به حضور باگ بیشتر در کد می‌شود و اگر کد هم کم‌تر باشد حظا نیز کاهش می‌یابد.

پیش‌فرض‌های امن

واکنش پیش‌فرض به هر درخواستی، رد کردن آن باید باشد. بنابراین از درخواست کاربر رد شود سیستم امن می‌ماند.

میانجی‌گری کامل

هرگونه دسترسی به هر موجودیت محافظت شده باید اعتبارسنجی شود.

طراحی روشن و شفاف

این نوع طراحی برای خلاف «امنیت به واسطه ابهام» است و پیشنهاد می‌دهد که طرح‌ها نباید رازگونه و مخفی باشند. بهترین مثال قانون کیرشهف در رمزنگاری است: «سیستم نباید وابسته به سِرّ باشد و باید قابلیت به دست دشمن افتاد را داشته باشد بدون آن که برای سیستم را با خطر و تهدید واجه کند»[1]

تفکیک امتیازهای دسترسی

هیچ‌گونه عمل و فعالیتی یک شرط و حالت نباید اجرا شود.

حداقل دسترسی

هر باید عملیاتی با حداقل دسترسی‌ها و مجوزهای لازم اجرا شود.

حداقل مکانیزم‌های مشترک

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

مقبولیت روان‌شناختی

آیا محصول شما قابل استفاده هست؟ اگر نه استفاده نخواهد شد. همواره از خود سوال کنید: «آیا می‌توانم این سیستم را به گونه‌ای ساده‌تر جهت استفاده طراحی کنم؟». هرگز کاربران را فراموش نکنید. مقبولیت روان‌شناختی مستلزم مهارت بالا و تخصص در طراحی رابط کاربر است. نحوه بکارگیری این مورد بسیار سخت حساس است. اگر استفاده از یک سیستم بسیار امن، دشوار باشد، کاربر ممکن است امکانات امنیتی محصول را رها کند. نکته اصلی، هوشیاری امنیتی در جهت حفظ امنیت است. برای مثال اگر یک دیواره آتش و ضدویروس، سرعت سیستم را به شدت کاهش دهد و کارآیی بسیاری از نرم‌افزارها را مختل نماید، کاربر آن را غیرفعال می‌کند. در این صورت امنیت بیشتر به خطر می‌افتد.
ویژگی‌های امنیتی نرم‌افزار الزاما نرم‌افزار را از حملات مصون نمی‌دارد. هر ویژگی و قابلیت، جدای از این که امنیتی باشد یا نباشد باید به عنوان یک «ویژگی امن» ، پیاده‌سازی شود و با توجه به امنیت و کیفیت به طور صحیح مهندسی شود. صحت تمامی ورودی‌ها باید به دقت، اعتبارسنجی شوند.

تشخیص و کاهش سطح حمله

تشخیص و کاهش سطح حمله روشی برای درک اجزای تشکیل دهنده سطح حمله و چگونگی کاهش موثر خطر سوءاستفاده توسط مهاجم از نقایص بالقوه کد است.
صنعت نرم‌افزار نیاز به تغییر نگرش از رسیدن به کمال‌گرایی در کدنویسی به درک و قبول این نکته که کد همیشه دارای باگ و ضعف امنیتی است. لذا باید بر مکانیزم‌های دفاعی مضاعفی تمرکز کنید. البته نباید هرگز کمال نرم‌افزار را فراموش کنید. بنابراین باید مصرف کد را به حداقل و دسترسی به آن را نیز به حداقل کاهش داد.
سطح حمله اجتماع کد، رابط ها، سرویس‌ها، پروتکل‌های در دسترس تمام کاربران است. بخشی که در دسترس کاربران غیرمجاز است از اهمیت بیشتری برخوردار است.
ارتباط تشخیص سطح حمله و مدل تهدید
تشخیص سطح حمله بر کاهش حجم کدی که در دسترس کاربران ناشناس است، تمرکز دارد. فهم نقاط ورودی و سطوح اطمینان مورد نیاز برای دسترسی راهی برای رسیدن به این هدف. مدل‌سازی تهدید منبع تغذیه مناسبی برای فرآیند تشخیص و کاهش سطح حمله است چرا که اساس مدل‌سازی تهدید بر پایه‌ نقاط ورودی و سطوح اطمینان، استوار است.
حوزه‌های فعالیت تشخیص و کاهش سطح حمله
در شمای کلی می‌توان عناوین زیر را در نظر داشت:
کاهش حجم کد اجرایی
محدود نمودن حوزه و ناحیه‌ای که کاربر دسترسی دارد.
محدود نمودن حوزه و ناحیه‌ای که موجودیت‌ها دسترسی دارد.
کاستن مجوزهای دسترسی به کد
در تصویر 1 گام‌های لازم برای تشخیص و کاهش سطح حمله بیان شده‌اند:
ارزیابی ریسک
انجام این مرحله برای تضمین و توجیه هزینه‌ها و زمآن‌های زیادی است که صرف امن‌سازی می‌شود و باید قبل از شروع هرگونه فعالیتی مربوط به فاز طراحی، انجام گیرد. هدف از انجام ارزیابی، شفاف‌سازی میزان و حجم تلاش مورد نیاز برای امن‌سازی است. در پایان باید نکات زیر مشخص و تشریح شود:
چه بخش‌هایی از پروژه نیازمند تهیه مدل تهدید قبل نهایی شدن است؟
چه بخش‌هایی از پروژه نیازمند بازبینی امنیتی مدل است؟
چه بخش‌هایی از پروژه نیازمند تست نفوذ است (ممکن است بتوان ار شخص ثالثی برای این گام استفاده نمود).
تعیین حوزه‌های آزمون fuzz برای نیازمندی‌ها
پس از انجام ارزیابی نتیجه کار در مستنداتی به نام‌های «ارزیابی امنیتی ریسک»[2] برای مشخص نمودن سطح آسیب‌پذیری در مقابل ریسک و «رتبه‌بندی میدان تحت تاثیر ریسک»[3]
ارزیابی امنیتی ریسک
ارزیابی امنیتی ریسک برای مشخص نمودن سطح آسیب‌پذیری سیستم در مقابل حمله صورت می‌پذیرد. برای انجام هرچه بهتر این ارزیابی می‌توانید برای هر یک از قسمت‌های سیستم، پرسش‌نامه‌هایی طراحی نمایید. این پرسش‌نامه‌ها باید بتوانند همانند یک فرم اطلاعات پزشکی، مشکلات بخش‌ها را نمایان سازد تا بتوانید در گام‌های بعدی، پس از تعیین اولویت، به رفع و درمان آن بخش‌ها بپردازید.
رتبه‌بندی میدان تحت تاثیر ریسک
در این قسمت پس از مشخص شدن ریسک‌های سیستم آن‌ها را به سه حوزه اصلی تقسیم‌بندی کنید:

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

رتبه‌ دوم
اطلاعات را بین توسعه‌دهندگان و اشخاص ثالث جابجا می‌کند.

رتبه‌ سوم
برنامه در هیچ‌یک از دو رتبه نام برده شده قرار نمی‌گیرد.
تحلیل ریسک
یکی از اساس‌ترین فعالیت‌ها برای ارتقای کیفیت امنیتی محصول، مدل‌سازی تهدید است. اگر این فعالیت، درست، به موقع و کامل انجام شود می‌توان به کشف موارد امنیتی طراحی در مراحل اولیه و قبل از شروع کدنویسی، منجر شود و در ادامه باعث صرفه‌جویی چشم‌گیری در زمان و هزینه خواهد شد. جدول زیر ارزش صرفه‌جویی زمانی و هزینه‌ای را با به کارگیری مدل تهدید نمایش می‌دهد:
در واقع ایده پس‌زمینه مدل‌سازی بسیار ساده است؛ هدف، شناخت تهدیدهای امنیتی بالقوه، رتبه‌بندی و تعیین راه‌حل است[7].
برای درک بهتر مدل تهدید می‌توان به مزایای زیر اشاره نمود:
هم‌راستا با فرآیند مدیریت ریسک است، زیرا تهدیدات نرم‌افزار و معماری، ریسک‌های کاربران و محیط پیاده‌سازی نیز محسوب می‌شود.
پیش‌گیری قبل از درمان
تایید مجدد معماری و طراحی به واسطه الزام توسعه‌دهندگان برای بازبینی مجدد طراحی
ایجاد دیدگاه متفاوت برای بازبینی برای شناخت پرمخاطره‌ترین بخش‌های سیستم
راهنمایی برای انتخاب بهترین راه‌حل برای تهدید براساس نرم‌افزار و محیط
ایجاد هماهنگی با فرآیند «کاهش سطح حمله[8]»
راهنمایی برای انجام آزمون نفوذپذیری
مجموعه‌ای از مدل‌های تهدید مناسب، حاکی از یک گروه «سلامت امنیتی» است چرا که بیان‌گر عمق دقت گروه بر مسائل امنیتی و حفظ حریم‌های شخصی است.