Мерки за SSDLC (жизнен цикъл на сигурна разработка на софтуер)

measures ssdlc

Научете за различни мерки за сигурност, които да приложите за сигурна SDLC или SSDLC:

Тъй като технологиите се развиват бързо, свързаните със сигурността заплахи от хакване и кражба на защитени данни също се увеличиха съответно. Така че, без съмнение, че технологичният растеж поставя предизвикателства пред производителите на софтуер, за да се гарантира, че техният софтуер е силен и стабилен срещу заплахите за сигурността и уязвимостите.

Софтуерен продукт не може да бъде пуснат, дори ако функционира перфектно за предвидената функционалност, освен ако не се окаже, че е силно защитен и отговаря на определените и регламентирани стандарти за сигурност и поверителност, особено в сектори като отбраната, финансите и здравеопазването, които включват лични и финансови данни .

Човек не може да си позволи да има дефект в сигурността на продукта, когато е внедрен, бил той с висока или средна степен на сериозност. Следователно е много важно да защитим софтуера и данните от всякакъв вид атака, злонамерени заплахи, уязвимости и да гарантираме надеждността на софтуера за крайния потребител.

За разлика от традиционната ни разработка на софтуер, тестването в последната фаза след разработването на целия софтуер не е по-ефективно. С внедряването на концепцията Agile, DevOps и ShiftLeft е от съществено значение да се извърши тестване в началото, както и във всяка фаза от жизнения цикъл на приложението.

Като каза това, сигурността на софтуера не може да бъде изградена или дори тествана на последния етап и следователно трябва да бъде изградена на всяка фаза, за да се гарантира пълната сигурност на софтуера.

Какво ще научите:

• Мерки за сигурност за SSDLC
  • # 1) Фаза на изискванията
  • # 2) Фаза на планиране
  • # 3) Фаза на архитектура и дизайн
  • # 4) Фаза на развитие
  • # 5) Фаза на изпълнение
  • # 6) Тестване - фаза преди внедряване
• Таблично обобщение за SSDLC
• Заключение
  • Препоръчително четене

Мерки за сигурност за SSDLC

По-долу са изброени различните средства за мерки, свързани със сигурността, които могат да бъдат приложени през жизнения цикъл на разработката на софтуер, за да се осигури Secure SDLC или SSDLC и колкото е възможно, дефектите нямат право да се пренасят към следващата фаза.

Различните анализи и оценки на сигурността, при които трябва да се изгради защитата на фази SDLC, са.

1. Фаза на изискванията
2. Фаза на планиране
3. Фаза на архитектура и дизайн: Оценка на риска за сигурността въз основа на дизайна.
4. Фаза на развитие: Анализ на защитен код, статичен анализ на кода за сигурност.
5. Фаза на изпълнение: Динамичен анализ на код, тестване на защитата на приложението.
6. Тестване - Фаза преди внедряване: Тестване на проникване и анализ на уязвимостта.

# 1) Фаза на изискванията

• На първо място, за да се гарантира, че необходимите мерки за сигурност са вградени в софтуера, Специфични изисквания, свързани със сигурността трябва да бъдат ясно уловени по време на фазата на изискванията с достатъчно подробности и очаквани резултати.
• Докато се идентифицират типичните случаи на употреба и бизнес сценарии, има ясен набор от Случаи и сценарии на употреба, свързани със сигурността за целите на проверката трябва да бъдат идентифицирани, за да се обхванат характеристиките на защитата и да се проектират сценарии за тестване на сигурността.

По-долу са дадени няколко примерни примера, които илюстрират изричните изисквания, свързани със сигурността, които могат да бъдат уловени.

Sec-Req-01: Системата се изисква да има въведени мерки за удостоверяване на всички шлюзове и входни точки.

Sec-Req-02: Системата е необходима за реализиране на удостоверяване чрез защитен екран за вход.

Sec-Req-03: ЛИЧНИТЕ ДАННИ се криптират в покой.

# 2) Фаза на планиране

На високо ниво, но не само ограничено до тях, на етапа на планиране трябва да се обърне внимание на следните точки.

въпроси и отговори за интервю за софтуерно инженерство pdf

• Силен, Специален екип за сигурност , функциониращ извън PMO (офис за управление на проекти) на програмния екип, състоящ се от Служител по сигурността, архитекти по сигурността, тестери за сигурност да бъдат сформирани, за да извършват и управляват безпристрастно всички дейности, свързани със сигурността на програмата. За всяка от тези роли са определени ясни RnR (роли и отговорности) и RACI.
• Всякакви ескалации, неясноти свързани с проблемите със сигурността трябва да се обработват от PSO (Служител по сигурността на продуктите), така че екипът по сигурността да функционира гладко и да помага при вземането на правилните решения.
• Здрав Стратегия за тестване на сигурността уточнява как да се изпълнят изискванията, свързани със сигурността, как, кога и какво да се тества, какви инструменти трябва да се използват на всеки етап, трябва да се идентифицират.
• Задължително е включването на Контактна точка за сигурност за всички технически дискусии / прегледи, свързани с програмата, така че екипът по сигурността да е наясно с всички промени, които се случват в програмата.

# 3) Фаза на архитектура и дизайн

Обръщането на повече внимание на аспектите на сигурността в началото по време на фазата на проектиране ще помогне да се предотвратят рисковете за сигурността и да се намалят значителните усилия при промените в дизайна по-късно в SDLC.

Докато проектирате софтуера и инфраструктурата, на която ще бъде хостван софтуерът, всичко възможно Изпълнения на проекти за сигурност трябва да бъдат добре проектирани с участието на архитектите по сигурността.

Всяка неяснота и конфликти между функционалните и нефункционалните аспекти на дизайна и архитектурата трябва да бъдат отстранени чрез сесии за мозъчна атака, включващи правилните заинтересовани страни.

По време на тази фаза се прави подробна оценка на риска за сигурността на продукта, която също понякога се нарича „Статична оценка“ трябва да се извърши от екипа от експерти по сигурността.

Оценка на риска за сигурността включва преглед на програмите от гледна точка на сигурността на предварителния етап на проектиране / архитектура, за да се идентифицират свързаните със сигурността недостатъци от гледна точка на дизайна и съответно да се повиши Продукта Рискове за сигурността на екипа на проекта да се обърне към тях и да избегне навлизането в следващата фаза.

Тези оценки се извършват въз основа на указанията, стандартите и контролите за организационна / индустриална сигурност, посочени в тези документи. E.g. UXW 00320, UXW 030017

По време на оценката на риска за сигурността на продукта:

• Изискванията, характеристиките, потребителските истории и техните проектни документи се преглеждат въз основа на детайлите, артефактите, споделени от екипа на проекта, E.g. Документи за проектиране (HLDD и LLDD). Оценките включват и дискусии със съответните членове на проектния екип в случай на липса на документи или за изясняване на съмнения.
• Пропуските се идентифицират при картографиране на Изискванията за сигурност на програмата спрямо зададените стандарти и други най-добри практики. Понякога се разработват и модели на заплахи въз основа на установените пропуски.
• Тези пропуски са идентифицирани като потенциални рискове за сигурността, включително и предлагане на възможни смекчаващи мерки за изпълнение, повдигнати и управлявани.
• След като тези смекчаващи мерки бъдат приложени от екипа на проекта, те се проверяват за затваряне чрез подходящи тестови случаи, проектирани от екипа на System Test.
• Матрицата за управление на риска, която осигурява проследимост, е подготвена да проследява тези рискове. Одобрението и подписването с остатъчния риск ще бъдат предприети от Архитекта по сигурността и PSO.

Типичните модели на заплахи, които се идентифицират на фазата на проектиране, са свързани с проверка на входа, управление на одит / регистрационен файл, конфигурации и криптиране. Идентифицирането на рисковете включва атакуване на уязвимости като слаби пароли, прости груби атаки и т.н.,

Типичните прегледи включват рискове, свързани с достъпа до лични данни, достъпа до одиторски пътеки, черни списъци с бели списъци, почистване на данни и дейност по изтриване.

Примерни тестови сценарии включват:

• Уязвимост при препълване на буфера: За да се гарантира, че чрез ръчно размиване на параметрите не трябва да е възможно да се забави сървъра и да се принуди сървърът да не реагира (Отказ от услуга).
• Дезинфекция на данните: За да се гарантира, че се прави правилна дезинфекция на данни за всеки вход и изход, така че нападателят да не може да инжектира и съхранява злонамереното съдържание в системата.

# 4) Фаза на развитие

Анализ на защитен код е Оценка на статичен код метод, който се използва за оценка на Код за сигурност на различните функции на софтуера с помощта на автоматизиран инструмент за сканиране. Пример: Укрепване.

Този анализ се извършва при всяко чекиране / изграждане на код, за да сканира генерирания код за заплахи за сигурността. Тази оценка обикновено се прави на ниво User Story.

• Подсилените сканирания чрез приставки трябва да бъдат инсталирани на машините на разработчика.
• Fortify трябва да бъде интегриран с шаблона за изграждане.
• Автоматизираното сканиране ще се извършва ежедневно във всички компилации.
• Резултатът от сканирането ще бъде анализиран от екипа по сигурността за фалшиви положителни резултати.
• Дефектите, идентифицирани от тази оценка, се повдигат и управляват до затваряне, така че просмукването да бъде сведено до минимум / нулирано до следващото ниво.

Примерни тестови сценарии включват:

• За да се гарантира, че чувствителните данни не се изпращат в обикновен текст по време на предаването на данни.
• За да се осигури сигурно предаване на данни, API с външно лице трябва да бъдат разположени на HTTPS канал.

# 5) Фаза на изпълнение

Анализ на динамичен код не е нищо друго освен тестване на защитата на приложенията, което се нарича още тестване на OWASP (Open Web Application Security Project). Анализът на уязвимостта и тестването за проникване (VAPT) трябва да се извърши във фазата на внедряване / тестване.

Този анализ оценява двоичните файлове и някои конфигурации на средата и допълнително укрепва кода за изискванията за сигурност.

Като част от този анализ, Динамично поведение или функционалността на различни функции на програмите се анализира за уязвимости, свързани със сигурността. Определените случаи на употреба и бизнес сценарии също се използват за извършване на динамичен анализ на кода.

Тази дейност се извършва на Тестови компилации използване на различни инструменти за сигурност с автоматизиран и ръчен подход.

формат на тестовия случай при тестване на софтуер

• Инструментите за потребителски интерфейс HP WebInspect, Burp Suite, ZAP и SOAP обикновено се използват за проверка на уязвимости спрямо стандартни бази данни за уязвимости ( Пример: OWASP Топ 10 )
• Тази дейност, макар и основно, е автоматизирана, поради някои ограничения на инструментите може да се наложи ръчна работа за триаж на фалшиви положителни резултати.
• Това в идеалния случай се прави в отделна среда (System Testing Environment), където се разполага софтуерът, готов за тестване.
• Уязвимостите трябва да се повишат и да се приключат с предложените смекчаващи мерки.

Типичните модели на заплахи, идентифицирани по време на този анализ, са свързани с валидиране на входа, счупено удостоверяване и управление на сесии, излагане на чувствителни данни, XSS и управление на пароли.

Примерните тестови сценарии включват,

• Управление на парола: За да се гарантира, че паролите не се съхраняват в обикновен текст в конфигурационните файлове или където и да е в системата.
• Изтичане на системна информация: За да се гарантира, че системната информация не изтича в нито един момент, информацията, разкрита от printStackTrace, може да помогне на противника от план за атака.

# 6) Тестване - фаза преди внедряване

Изпитване за проникване , Тест на писалка накратко и Infra VAPT (Анализ на уязвимост и тестване на проникване) , е пълноценният холистичен тест с пълно решение и конфигурации (включително мрежа), което в идеалния случай се прави в предварителна или производствена среда.

Това се извършва главно за идентифициране на DB уязвимости и уязвимости на сървъра, заедно с всички други уязвимости. Това е последният етап от тестването на сигурността, който ще се проведе. Следователно това включва и проверка на по-рано докладвани дефекти и рискове.

• Инструменти като Nessus, Nmap, HP Web Inspect, Burp Suite, ZAP, които се предлагат на пазара, се използват за извършване на тестване на писалки.
• По време на това тестване се извършва сканиране на уеб приложения с помощта на автоматизирани инструменти и експлоатация за по-нататъшна проверка. Тестването се прави, за да се симулира действителното поведение на нападателя и следователно може да включва и няколко отрицателни теста.
• Уязвимост на инфраструктурата оценката включва сканиране, анализ и преглед на конфигурацията на сигурността на инфраструктурата (мрежи, системи и сървъри), за да се идентифицират уязвимостите и да се провери устойчивостта срещу целевите атаки.
• Това се извършва в предварителна или подобна на производството среда, където софтуерът, който е готов за внедряване, се тества и следователно симулира средата в реално време.
• Уязвимостите се идентифицират с помощта на скенери и ръчни техники за премахване на фалшиви положителни резултати. Също така, бизнес сценарии в реално време ще се изпълняват по време на ръчно тестване.
• Ще бъде изготвен окончателен доклад за целия анализ на сигурността, който се извършва за цялата програма, като се подчертава състоянието на високорисковите елементи, ако има такива.

Примерните тестови сценарии включват,

• За да се гарантира, че уязвимите HTTP методи не са активирани.
• За да се гарантира, че чувствителната информация на останалите потребители не се вижда в ясен текст в мрежата.
• За да се гарантира, че е приложена проверка за качване на файлове, за да се избегне качване на злонамерен файл.

Таблично обобщение за SSDLC

Таблицата по-долу обобщава различните аспекти на анализа на сигурността, които са обяснени по-горе.

Заключение

По този начин, с прилагането на всички тези аспекти, свързани със сигурността, интегрирани през различните фази на SDLC, помага на организацията да идентифицира дефектите в сигурността в началото на цикъла и дава възможност на организацията да приложи подходящи смекчаващи мерки, като по този начин избягва Високорискови дефекти в сигурността в системата на живо.

Проучването също така показва, че по-голямата част от дефектите в сигурността се индуцират в софтуера по време на етапа на разработка, т.е. Фаза на кодиране , при което кодирането не се е погрижило в достатъчна степен за всички аспекти на сигурността поради някакви причини.

В идеалния случай никой разработчик не би искал да напише лош код, който компрометира сигурността. По този начин, за да насочи разработчиците как да напишат защитен софтуер, предстоящият урок обхваща Най-добри практики и насоки за кодиране за разработчици, за да се гарантира по-добра сигурност на софтуера.

Надяваме се, че този урок за Secure SDLC или SSDLC е полезен !!

Препоръчително четене

• SDLC (жизнен цикъл на разработка на софтуер) Фази, методологии, процес и модели
• 10 най-добри инструмента за тестване на сигурността на мобилни приложения през 2021 г.
• 19 Мощни инструменти за тестване на проникването, използвани от професионалистите през 2021 г.
• Указания за тестване на сигурността на мобилните приложения
• Тестване на мрежовата сигурност и най-добрите инструменти за мрежова сигурност
• Тестване на сигурността (Пълно ръководство)
• Топ 4 Инструменти за тестване на сигурността с отворен код за тестване на уеб приложение
• Ръководство за тестване на сигурността на уеб приложения