دانلود کامل ترین جزوه تجزیه و تحلیل و طراحی سیستم

جزوه تایپ شده تجزیه و تحلیل و طراحی سیستم

دانلود فایل

علمی کاربردی شمس السادات زاهدی دکتر علی امدئیان آلن دنیس علیامد مقدسی پیام نور دانشگاه علمی کاربردی آزاد کارشناسی

: ؟ ً ؟ ؟ ؟ ؟ً ؟ ؟ : ؟ ؟ ؟ ؟ ؟ ؟ در پروژه، مورد بحث و بررسی قرار خواهیم داد، می توانند و باید توسط طرفین مورد بررسی قرار گیرند. علاوه بر این، در صورت عدم وجود فرآیندهای توسعه ایمن، می توان آنها را بهبود بخشید.

1-18 علت اهمیت مهندسی امنیت نرم افزار، چیست؟
امنیت نرم افزار چیزی فراتر از امنیت نرم افزارهای طراحی سیستم با فایروال، رمزهای عبور قوی و رمزگذاری است. همچنین توسعه نرم افزار، به گونه ای که از ابتدا امنیت بیشتری داشته باشد را نیز شامل می شود. در حال حاضر تکنیک هایی در دسترس است که به ما کمک می کند نرم افزاری را توسعه دهیم که از امنیت بالاتری نسبت به موارد دیگر برخوردار است. در این فصل، به برخی از مدل ها و تکنیک هایی که می توانند به ما در دستیابی به امنیت نرم افزاری بهتر کمک کنند، می پردازیم. سپس فعالیت های فرایند خاصی را مورد بررسی قرار می دهیم؛ از جمله فعالیت هایی مانند مهندسی الزامات، موارد سوء کاربری یا سوء مصرف، تجزیه و تحلیل ریسک امنیتی، مدل سازی تهدید، سطح حمله، کدگذاری ایمن و اندازه گیری. همچنین مدل های بهبود فرایند امنیتی را نیز بررسی خواهیم کرد. در نهایت، فهرستی از منابع را به طور خلاصه در اختیار شما قرار می دهیم تا بتوانید عمیق تر به هر یک از این موضوعات بپردازید.
تحقیقات مهندسی امنیت نرم افزار یک حیطه بسیار فعال است. در این کتاب، ما فقط یک مرور کلی از روش ها و ابزارهایی برای پشتیبانی از کار واقعی، ارائه می دهیم. کتاب های زیادی در این زمینه وجود دارد (برای مثال منابع دیگری که منحصراً به مهندسی امنیت نرم افزار اختصاص یافته اند)، که برخی از آن ها را به شما معرفی می کنیم.

تجزیه و تحلیل و طراحی سیستم

2-18 مدل های چرخه عمر امنیت
چرخه حیات توسعه امنیت مایکروسافت (SDL)، یک فرایند امنیتی نرم افزاری پیشرو در صنعت است. SDL با ابتکار گسترده مایکروسافت و یک سیاست اجباری از سال 2004 ، مایکروسافت را قادر ساخت تا امنیت و حریم خصوصی را در نرم افزار و فرهنگ خود جاسازی کند. SDL ، امنیت و حریم طراحی سیستم را در مراحل اولیه و در تمام مراحل فرآیند توسعه معرفی می کند و بدون شک، شناخته شده ترین و مورد استفاده ترین مدل چرخه عمر توسعه امنیت است. مایکروسافت مجموعه ای از اصول را تعریف کرده است که آن را Secure by Design ، Secure by Default ، Secure in Deployment و Communications (SD3+C) می نامد تا به تعیین محل تلاش جزوه تجزیه و تحلیل و طراحی سیستم امنیتی کمک کند. این اصول، به شرح زیر هستند:

جزوه تجزیه و تحلیل و طراحی سیستم دانلود رایگان خلاصه کتاب پی دی اف pdf کامل

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

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

ایمن به طور پیش فرض
حداقل امتیاز: همه اجزا با کمترین جزوه تجزیه و تحلیل و طراحی سیستم ممکن اجرا می شوند.
حفاظت شدید: اجزاء، به یک راه حل کاهش تهدید تکیه نمی کنند؛ چراکه ممکن است در صورت عدم موفقیت، کاربران را در معرض دید قرار می دهد.
تنظیمات پیش فرض محافظه کارانه: تیم توسعه از سطح حمله محصول آگاه است و آن را در پیکربندی پیش فرض به حداقل می رساند.
اجتناب از تغییرات پیش فرض خطرناک: برنامه ها هیچ گونه تغییر پیش فرضی در سیستم عامل یا تنظیمات امنیتی ایجاد نمی کنند که امنیت رایانه میزبان را کاهش دهد. در برخی موارد، مثلاً در محصولات امنیتی، قابل قبول است که یک برنامه نرم افزاری، تنظیمات امنیتی رایانه میزبان را تقویت (افزایش) دهد. شایع ترین نقض این اصل، بازی هایی هستند که یا درگاه های فایروال را بدون اطلاع کاربر باز می کنند یا به کاربران دستور می دهند بدون اطلاع کاربران از خطرات احتمالی، پورت های فایروال را باز کنند.
خاموش بودن سرویس های کم کاربرد تر به صورت پیش فرض: اگر کمتر از 80 درصد از کاربران برنامه از یک ویژگی استفاده می کنند، این ویژگی نباید به طور پیش فرض فعال شود. اندازه گیری 80 درصد استفاده در یک محصول، اغلب دشوار است؛ زیرا برنامه ها برای افراد مختلف طراحی شده اند.باید توجه کنیم که آیا یک ویژگی، فیلمنامه کاربری اصلی/اولیه را برای همه پرسونا مطرح می کند. در صورت وجود، طراحی سیستم اوقات این ویژگی به عنوان ویژگی P1 شناخته می شود.

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

ارتباطات
پاسخ امنیتی: تیم های توسعه، سریعاً به گزارش آسیب پذیری های امنیتی پاسخ می دهند و اطلاعات مربوط به به روزرسانی های امنیتی را ارسال می کنند.
مشارکت جوامع: تیم های توسعه دهنده، به صورت فعالانه با کاربران در ارتباط هستند تا به سؤالات مربوط به آسیب پذیری های امنیتی، به روزرسانی های امنیتی یا تغییرات در دیدگاه امنیتی پاسخ دهند.
تصویر 1-18
مدل فرآیند توسعه نرم افزار امن شبیه به آن چیزی است که در شکل 18.1 نشان داده شده است. مستندات SDL مایکروسافت، وظایف که معماران، طراحان، توسعه دهندگان و آزمایش کنندگان، را برای از 16 روش توصیه شده، توضیح می دهد. داده هایی که مایکروسافت پس از پیاده سازی SDL جمع آوری کرد، کاهش قابل توجهی از آسیب پذیری ها را نشان می دهد که منجر به نیاز به وصله های (پچ های) کمتر و در نتیجه صرفه جویی قابل توجهی در هزینه ها می شود. برای کسب اطلاعات بیشتر در مورد این شیوه ها، می توانید وب سایت SDL را بررسی کنید. از زمان توسعه SDL ، مقالات متعدد، کتاب، آموزش و سایر موارد، با مدل SDL همراه بوده است.
تصویر 2-18

3-18 فعالیت های چرخه عمر توسعه امن
یک رویکرد متفاوت که مستقل از مدل چرخه عمر است، نقاط تماس برای امنیت نرم افزار است، که طراحی سیستم می کند فعالیت ها (نقاط تماس) هستند که مهم هستند، نه مدل ها. فعالیت ها را می توان در هر مدل جزوه تجزیه و تحلیل و طراحی سیستم عمر گنجانید و بنابراین، آگنوستیک فرآیند تلقی می شوند. نقاط تماس، بعداً پایه و اساس BSIMM را تشکیل دادند، یک مدل بلوغ که بعداً در این فصل مورد بحث قرار می گیرد. برخی از سازمانها نقاط تماس را حداقل مجموعه فعالیت هایی می دانند که باید در توسعه نرم افزار ایمن، انجام شود. نسخه تصویری نقاط تماس، در شکل 18.2 نشان داده شده است. در این نمودار، فعالیت های امنیتی توصیه شده، در بالای فعالیت مربوط به توسعه نرم افزار یا مرحله چرخه عمر، ظاهر می شود: با در نظر داشتن SDL و نقاط تماس، برخی از فعالیت های مهم توسعه نرم افزار ایمن مرتبط با آن ها را بررسی می کنیم.

مهندسی الزامات امنیتی
اگرچه الزامات امنیتی، بخش مهمی از توسعه نرم افزار امن هستند، اما در عمل، اغلب مورد غفلت قرار می گیرد.این الزمات در صورت وجود، اغلب یک افزونه هستند که از یک لیست عمومی از ویژگی های امنیتی کپی شده اند. مهندسی الزامات مورد نیاز برای به دست آوردن مجموعه بهتری از الزامات امنیتی، به ندرت انجام می شود. عملکرد مهندسی الزامات به طور معمول، ویژگی های مورد نظر کاربر را برطرف می کند. بنابراین، به عملکرد سیستم از دیدگاه کاربر توجه می شود ، اما به آنچه سیستم نباید انجام دهد، توجه کمی اختصاص داده خواهد شد. کاربران انتظار دارند که سیستم ها ایمن باشند و این مفروضات، باید قبل از توسعه سیستم های نرم افزاری الزامات امنیتی خود را ایجاد کنند، نه بعد از آن.
اغلب، مفروضات کاربران در مورد امنیت نادیده گرفته می شود؛ زیرا تمرکز اصلی بر ویژگی های اصلی است. علاوه بر مدل های چرخه عمر امنیتی، مدل های فرایندی زیادی نیز وجود دارند که مخصوص الزامات امنیتی هستند. این موارد عبارتند از: مصنوعات اصلی الزامات امنیتی ، کاهش هزینه نرم افزار (SCR) ، SQUARE (مهندسی الزامات QUAlity Security Security) و فرایند مهندسی الزامات امنیتی (SREP). در بقیه این بخش، SQUARE را به عنوان نمونه ای از مدل های چرخه عمر امنیت، بررسی خواهیم کرد.

دانلود رایگان خلاصه کتاب تجزیه و تحلیل و طراحی سیستم PDF

1-4-18 SQUARE(مربع)
SQUARE، یک مدل فرآیند مهندسی الزامات امنیتی است، اما به خاطر داشته جزوه تجزیه و تحلیل و طراحی سیستم که اگر از قبل یک مدل فرآیند توسعه، مانند مدل ارائه شده در فصل 4، دارید، می توانید برخی از مراحل SQUARE را برای ارتقای مدل موجود خود، انتخاب کنید.البته نیازی به توسعه یک فرایند جدید برای بررسی امنیت در فعالیت های توسعه نرم افزارتان نخواهید داشت. پیشنهاد می کنیم تعاریف امنیتی را به واژه نامه خود اضافه کنید؛ انجام تجزیه و تحلیل خطرات احتمالی، از جمله شناسایی حملات احتمالی از طریق موارد سوء استفاده یا مدل سازی تهدید؛ تدوین استراتژی های کاهش؛ و طبقه بندی و اولویت بندی الزامات امنیتی داوطلب را انجام دهید. مدل فرآیند SQUARE استخراج، طبقه بندی و اولویت بندی الزامات امنیتی برای سیستم های فشرده نرم افزاری را فراهم می کند. این مدل، برایجاد مفاهیم امنیتی در مراحل اولیه چرخه عمر توسعه تمرکز می کند. این فرایند در جدول 18.1 نشان داده شده است ، و سپس توضیحات مختصری از هر مرحله ارائه شده است.

2-4-18 فرایند SQUARE
فرایند SQUARE به بهترین وجه توسط مهندسان طراحی سیستم پروژه و کارشناسان امنیتی با مدیریت اجرایی حمایتی و سهامداران اعمال می شود. بیایید نگاهی به مراحل بیندازیم.
مرحله 1: توافق بر سر تعاریف. به منظور ایجاد سردرگمی معنایی، این مرحله به عنوان پیش نیاز مهندسی الزامات امنیتی مورد نیاز است. در یک پروژه مشخص، اعضای تیم، بر اساس تجربیات قبلی خود، تمایل دارند تعاریفی را در نظر داشته باشند، اما این تعاریف اغلب با یکدیگر متفاوت هستند. منابعی مانند موسسه مهندسان برق و الکترونیک (IEEE) و دانش مهندسی نرم افزار (SWEBOK)، مجموعه ای از تعاریف را جهت انتخاب یا اصلاح ارائه می دهند.
مرحله 2: دارایی ها و اهداف امنیتی را مشخص کنید. این مرحله در سطح سازمانی پروژه اتفاق می افتد و برای پشتیبانی از توسعه نرم افزار، مورد نیاز است. به عنوان مثال، ممکن است یک سهامدار در منابع انسانی، نگران حفظ محرمانه بودن سوابق پرسنل باشد، در حالی که یک سهامدار در یک منطقه تحقیقاتی می تواند در مورد اطمینان از دسترسی، تغییر یا سرقت اطلاعات پروژه تحقیقاتی نگران باشد.
مرحله 3: تولید مصنوعات.این جزوه تجزیه و تحلیل و طراحی سیستم ه برای پشتیبانی از کلیه فعالیت های مهندسی مورد نیاز در زمینه امنیت، لازم است. اغلب اوقات، سازمان ها اسناد کلیدی مورد نیاز برای پشتیبانی از تعریف الزامات را ندارند، یا ممکن است این اسناد، به روز نباشند. یعنی ممکن است زمان زیادی صرف عقب نشینی برای تلاش جهت به دست آوردن اسناد شود، یا تیم باید قبل از ادامه کار آن ها را به روز کند.
مرحله 4: ارزیابی خطرات احتمالی. این مرحله مستلزم یک متخصص در روش های ارزیابی خطرات احتمالی، حمایت سهامداران و پشتیبانی یک مهندس الزامات امنیتی است. روش های متعددی برای ارزیابی خطرات احتمالی وجود دارد، اما صرف جزوه طراحی معماری و شهرسازی از روشی که انتخاب می کنید، نتایج ارزیابی این خطرات، می تواند در شناسایی مخاطرات امنیتی با اولویت بالا کمک کند.
مرحله 5: روش استخراج را انتخاب کنید. این مرحله زمانی اهمیت پیدا می کند که سهامداران متعددی وجود داشته باشد. در صورت وجود سهامداران با زمینه های فرهنگی متفاوت، یک تکنیک استخراج رسمی تر، مانند روش الزامات شتابدهنده، طراحی برنامه مشترک، یا مصاحبه های ساختار یافته، می تواند در غلبه بر مسائل ارتباطی مؤثر باشد. در موارد دیگر، استخراج ممکن است به ملاقات با یک سهامدار اصلی برای درک الزامات امنیتی سهامداران، انجام شود.
مرحله 6: الزامات امنیتی را کشف و استخراج کنید. این مرحله شامل فرایند استخراج واقعی با طراحی سیستم از تکنیک انتخاب شده است. اکثر تکنیک های استخراج، راهنمایی های مفصلی در مورد نحوه کشف الزامات ارائه می دهند که اساس این راهنمایی ها، مصنوعاتی است که در مراحل اولیه ایجاد شده است.
تصویر 1-18

مرحه 7: الزامات را طبقه بندی کنید. این مرحله به مهندس الزامات امنیتی اجازه می دهد تا بین الزامات اساسی، اهداف (الزامات مورد نظر) و محدودیت های معماری که ممکن است وجود داشته باشد، تمایز قائل شود. این طبقه بندی همچنین به اولویت بندی فعالیت جزوه تجزیه و تحلیل و طراحی سیستم بعدی نیز کمک می کند.
مرحله 8. الزامات را اولویت بندی کنید. این مرحله به مرحله قبل بستگی دارد و همچنین ممکن است شامل تجزیه و تحلیل هزینه و سود باشد تا مشخص شود که کدام الزامات امنیتی نسبت به هزینه آن ها، بازده بالایی دارند. البته اولویت بندی ممکن است به عواقب دیگر نقض امنیت نیز بستگی داشته باشد، مانند از دست دادن جان، شهرت و از دست دادن اعتماد مصرف کننده.
مرحله 9. بازرسی الزامات. این فعالیت بازبینی می تواند در سطوح رسمی مختلف انجام شود، که در فصل 16 مورد بحث قرار گرفته است. پس از اتمام بازرسی، تیم پروژه باید مجموعه‌ای اولیه از الزامات امنیتی اولویت بندی شده داشته باشد؛ که در صورت لزوم بتوان آن را بعداً در پروژه، مورد بازبینی قرار داد.

5-18 موارد سوءاستفاده، سوءمصرف و الگوهای حمله
موارد سوء استفاده (یا سوء مصرف) می تواند به شما طراحی سیستم کند نرم افزار خود را به روشی مشابه مهاجمان، مشاهده کنید. با تفکر در مورد رویدادهای منفی، می توانید نحوه توسعه نرم افزارهای امن را بهتر درک کنید. یک مورد سوء استفاده، می تواند به عنوان یک مورد کاربری در نظر گرفته شود که مهاجم آن را شروع می کند. یکی از اهداف موارد سوء استفاده، تصمیم گیری در مورد نحوه واکنش نرم افزار در برابر حملات احتمالی است. همچنین می توانید از موارد سوء استفاده و کاربری معمولی با هم، برای تجزیه و تحلیل تهدید و خطر استفاده کنید. پیشنهاد می کنیم موارد سوء استفاده را از طریق مشورت با سایر افراد و همفکری، ایجاد کنید. گروه بندی کارشناسان امنیتی با متخصصان موضوعی (SMEs)، به سرعت زمینه های زیادی را پوشش می دهد. در جریان همفکری، کارشناسان امنیت نرم افزار با طرح سؤالات زیادی از توسعه دهندگان، تلاش می کنند تا به شناسایی نقاط ضعف احتمالی سیستم، کمک کنند. این امر، شامل یک نگاه دقیق به همه رابط های طراحی سیستم است و رویدادهایی را در نظر می گیرد که از دید توسعه دهندگان، غیر ممکن هستند؛ اما در واقع حمله کنندگان می توانند باعث وقوع آن شوند. در اینجا چند سوال جزوه تجزیه و تحلیل و طراحی سیستم دارد که باید مورد توجه قرار گیرد: چگونه سیستم می تواند بین داده های ورودی معتبر و نامعتبر تمایز قائل شود؟ آیا می تواند تشخیص دهد که یک درخواست، از یک برنامه قانونی آمده است یا یک برنامه غیرقانونی؟ آیا یک عضو داخلی می تواند باعث خرابی سیستم شود؟ تلاش برای پاسخ به چنین سؤالاتی به توسعه دهندگان کمک می کنند تا مفروضات خود را تجزیه و تحلیل کنند و به آن ها امکان می دهد تا مشکلات را از قبل برطرف کنند. موارد سوء استفاده می توانند به شکل جدول یا نمودار باشند. شکل 18.3 نمونه ای از سوء استفاده را به تصویر کشیده است که نشان می دهد چگونه بدافزار DroidCleaner، می تواند با استفاده از یک برنامه ایمیل منبع باز به نام K-9، با موفقیت به تلفن همراه حمله کند. این موضوع، از یک گزارش بسیار بزرگتر () ‌؛