Заходи щодо SSDLC (безпечний життєвий цикл розробки програмного забезпечення)

measures ssdlc

Дізнайтеся про різні заходи безпеки для впровадження безпечного SDLC або SSDLC:

Оскільки технології швидко зростають, відповідно зростають і загрози злому та викрадення захищених даних, пов’язані з безпекою. Отже, без сумніву, зростання технологій ставить перед виробниками програмного забезпечення проблеми, щоб гарантувати, що їх програмне забезпечення надійне та надійне проти загроз і вразливостей безпеки.

Програмний продукт не можна випустити, навіть якщо він ідеально функціонує за передбачуваною функціональністю, якщо не виявиться надійно захищеним і не відповідає визначеним та регламентованим стандартам безпеки та конфіденційності, особливо в таких секторах, як оборона, фінанси та охорона здоров’я, які включають особисті та фінансові дані .

Не можна дозволити собі дефект безпеки продукту під час його розгортання, будь то високої чи середньої важкості. Тому дуже важливо захистити програмне забезпечення та дані від будь-яких атак, зловмисних загроз, вразливостей та забезпечити надійність програмного забезпечення для кінцевого користувача.

На відміну від нашої традиційної розробки програмного забезпечення, тестування на останньому етапі після розробки всього програмного забезпечення не є більш ефективним. З реалізацією концепцій Agile, DevOps та ShiftLeft важливо проводити тестування на ранніх етапах, а також на кожному етапі життєвого циклу програми.

Сказавши це, безпека програмного забезпечення не може бути побудована або навіть перевірена на останньому етапі, і тому її потрібно будувати на кожній фазі, щоб забезпечити повну безпеку програмного забезпечення.

Що ви дізнаєтесь:

• Заходи безпеки для SSDLC
  • # 1) Фаза вимог
  • # 2) Фаза планування
  • # 3) Фаза архітектури та проектування
  • # 4) Фаза розробки
  • # 5) Фаза впровадження
  • # 6) Тестування - фаза перед розгортанням
• Табличний підсумок для SSDLC
• Висновок
  • Рекомендована література

Заходи безпеки для SSDLC

Нижче перераховані різні засоби, пов'язані з безпекою, які можуть бути впроваджені протягом життєвого циклу розробки програмного забезпечення для забезпечення безпечного SDLC або SSDLC, і, наскільки це можливо, дефекти не можуть переноситися на наступний етап.

Різним аналізом та оцінками безпеки, на яких захист потрібно будувати на етапах SDLC, є.

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

# 1) Фаза вимог

• Перш за все, щоб забезпечити вбудовування необхідних заходів безпеки в програмне забезпечення, Конкретні вимоги, пов'язані з безпекою потрібно чітко фіксувати на етапі вимог з достатньою кількістю деталей та очікуваних результатів.
• Визначаючи типові випадки використання та бізнес-сценарії, чіткий набір Випадки використання та сценарії використання, пов’язані з безпекою для цілей перевірки потрібно визначити, щоб охопити функції захисту та розробити сценарії тестування безпеки.

Нижче наведено кілька зразків прикладів, що ілюструють чіткі вимоги, пов'язані з безпекою, які можна охопити.

Розділ-Req-01: Система повинна мати заходи автентифікації на всіх шлюзах та точках входу.

Розділ-Req-02: Система необхідна для здійснення автентифікації через захищений екран входу.

Розділ-Req-03: ОСОБИСТІ ДАНІ повинні бути зашифровані під час відпочинку.

# 2) Фаза планування

На високому рівні, але не лише цим, на етапі планування слід подбати про наступні моменти.

моделі життєвого циклу розробки програмного забезпечення водоспад

• Сильний, Виділена команда безпеки , що функціонує поза PMO (офіс управління проектами) команди програми, що складається з Співробітник служби безпеки, архітектори безпеки, тестери безпеки бути сформованим для неупередженого здійснення та управління всією діяльністю програми, пов’язаною з безпекою. Для кожної з цих ролей визначені чіткі RnR (ролі та обов'язки) та RACI.
• Будь-який ескалації, двозначності пов'язані з проблемами безпеки повинен вирішувати PSO (Служба безпеки продуктів), щоб команда безпеки працювала безперебійно і допомагала приймати правильні рішення.
• Міцний Стратегія тестування безпеки необхідно вказати, як виконувати вимоги, пов’язані з безпекою, як, коли і що тестувати, які інструменти слід використовувати на кожному етапі.
• Обов’язковим є залучення Контактний пункт безпеки для всіх технічних обговорень / обговорень, пов’язаних із програмою, щоб команда безпеки знала про будь-які зміни, що відбуваються з програмою.

# 3) Фаза архітектури та проектування

Приділення більшої уваги аспектам безпеки на ранніх етапах на етапі проектування допоможе запобігти ризикам безпеки та зменшить значні зусилля щодо змін проекту в подальшому в SDLC.

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

Будь-яку неоднозначність та конфлікти між функціональним та нефункціональним аспектами проектування та архітектури потрібно розібрати за допомогою мозкових штурмів із залученням відповідних зацікавлених сторін.

На цьому етапі проводиться детальна оцінка ризиків безпеки продукції, яку також іноді називають 'Статична оцінка' має виконувати команда експертів з питань безпеки.

Оцінка ризику безпеки включає огляд програм з точки зору безпеки на етапі попереднього проектування / архітектури, щоб виявити недоліки, пов'язані з безпекою, з точки зору проектування і відповідно підняти Продукт Ризики безпеки до команди проекту, щоб звернутися до них та уникнути переходу до наступного етапу.

Ці оцінки проводяться на основі керівних принципів, стандартів та контролю щодо організаційної / промислової безпеки, викладених у цих документах. Наприклад UXW 00320, UXW 030017

Під час Оцінки ризику безпеки продукції:

• Вимоги, функції, історії користувачів та їх проектні документи переглядаються на основі деталей, артефактів, якими ділиться команда проекту, Наприклад Проектні документи (HLDD та LLDD). Оцінки також передбачають обговорення з відповідними членами проектної групи у разі відсутності документів або для з'ясування будь-яких сумнівів.
• Виявляються прогалини при зіставленні Вимог безпеки програми з встановленими стандартами та іншими передовими практиками. Іноді моделі загроз також розробляються на основі виявлених прогалин.
• Ці прогалини визначені як потенційні ризики безпеки, а також включають пропозиції щодо можливих пом'якшень для впровадження, підняття та управління.
• Після того, як ці пом'якшувальні прояви реалізуються командою проекту, вони перевіряються на предмет закриття за допомогою відповідних тестових кейсів, розроблених командою системного тестування.
• Матриця управління ризиками, яка забезпечує відстеження, готова відстежувати ці ризики. Схвалення та підписання із залишковим ризиком приймуть архітектор безпеки та PSO.

Типові схеми загроз, які ідентифікуються на етапі проектування, пов'язані з перевіркою вхідних даних, контролем аудиту / журналу, конфігураціями та шифруванням. Визначення ризиків включає атаки на такі вразливі місця, як слабкі паролі, прості атаки грубої сили тощо,

Типові огляди включають ризики, пов’язані з доступом до персональних даних, доступом до аудиторських доріжок, об’єктами, що вносять до чорного списку, чищенням даних та видаленням даних.

Приклади сценаріїв тесту включають:

• Уразливість переповнення буфера: Щоб гарантувати, що шляхом розмиття параметрів вручну, не повинно бути можливим уповільнення роботи сервера та змушення сервера не реагувати (відмова в обслуговуванні).
• Дезінфекція даних: Щоб забезпечити належну дезінфекцію даних для кожного введення та виводу, щоб зловмисник не міг вводити та зберігати шкідливий вміст у системі.

# 4) Фаза розробки

Безпечний аналіз коду є Оцінка статичного коду метод, який використовується для оцінки Захищений код різних функцій програмного забезпечення за допомогою автоматизованого інструменту сканування. Приклад: Укріпити.

Цей аналіз проводиться під час кожної реєстрації / побудови коду для сканування коду, сформованого на наявність загроз безпеці. Зазвичай ця оцінка проводиться на рівні історії користувача.

• Фортифіковані скани за допомогою плагінів потрібно встановлювати на машинах розробника.
• Fortify потрібно інтегрувати із шаблоном збірки.
• Автоматизоване сканування буде виконуватися на всіх збірках щодня.
• Результат сканування буде проаналізовано командою безпеки на наявність помилкових спрацьовувань.
• Виявлені в результаті цієї оцінки дефекти піднімаються та управляються до закриття, так що просочування зводиться до мінімуму / обнуляється до наступного рівня.

Приклади сценаріїв тесту включають:

• Щоб гарантувати, що конфіденційні дані не надсилаються у звичайному тексті під час передачі даних.
• Щоб забезпечити безпечну передачу даних, зовнішні API повинні бути розгорнуті на каналі HTTPS.

# 5) Фаза впровадження

Динамічний аналіз коду це не що інше, як тестування безпеки додатків, яке також називається тестуванням OWASP (Open Web Application Security Project). Аналіз вразливості та тестування на проникнення (VAPT) необхідно проводити на етапі впровадження / тестування.

Цей аналіз оцінює двійкові файли та деякі конфігурації середовища та додатково зміцнює код вимог безпеки.

Як частина цього аналізу, Динамічна поведінка або функціональність різних функцій програм аналізується на наявність уразливостей, пов’язаних із безпекою. Умовні випадки використання та бізнес-сценарії також використовуються для проведення динамічного аналізу коду.

Ця діяльність виконується на Тестові збірки використання різних інструментів безпеки з автоматизованим та ручним підходом.

• Інструменти HP WebInspect, Burp Suite, ZAP та SOAP UI зазвичай використовуються для перевірки вразливостей щодо стандартних баз даних вразливості ( Приклад: OWASP Топ 10 )
• Ця діяльність, хоча в основному автоматизована, через певні обмеження інструментів може знадобитися деяка ручна робота для зіставлення помилкових спрацьовувань.
• В ідеалі це робиться в окремому середовищі (System Testing Environment), де розгортається програмне забезпечення, готове до тестування.
• Потрібно підняти вразливі місця та довести їх до закриття за допомогою запропонованих заходів щодо пом’якшення наслідків.

Типові схеми загроз, виявлені під час цього аналізу, пов’язані з валідацією вводу, невдалою автентифікацією та управлінням сеансами, експозицією чутливих даних, управління XSS та паролями.

Приклади сценаріїв тесту включають,

• Керування паролями: Щоб паролі не зберігались у звичайному тексті у файлах конфігурації або де-небудь в системі.
• Витік системної інформації: Щоб гарантувати, що в будь-який момент системна інформація не просочиться, інформація, розкрита printStackTrace, може допомогти противнику у складі плану атаки.

# 6) Тестування - фаза перед розгортанням

Випробування на проникнення , Тест ручки коротко і Infra VAPT (аналіз вразливості та тестування на проникнення) , - повномасштабний цілісний тест з повне рішення і конфігурації (включаючи мережу), що в ідеалі робиться у попередньому або виробничому середовищі.

Це в основному проводиться для виявлення вразливостей БД та вразливостей сервера, а також інших вразливостей. Це останній етап перевірки безпеки, який буде проведено. Отже, це також включає перевірку раніше повідомлених дефектів та ризиків.

• Такі інструменти, як Nessus, Nmap, HP Web Inspect, Burp Suite, ZAP, які доступні на ринку, використовуються для тестування пера.
• Під час цього тестування здійснюється сканування веб-додатків за допомогою автоматизованих інструментів та використання для подальшої перевірки. Тестування проводиться для імітації реальної поведінки зловмисника, а отже, воно може включати також кілька негативних тестів.
• Вразливість інфраструктури оцінка включає сканування, аналіз та перевірку конфігурації безпеки інфраструктури (мереж, систем та серверів) для виявлення вразливостей та перевірки стійкості проти цільових атак.
• Це виконується в передвиробничому або виробничому середовищі, де програмне забезпечення, яке готове до розгортання, тестується і, отже, імітує середовище реального часу.
• Вразливості визначаються як за допомогою сканерів, так і вручну, щоб усунути помилкові спрацьовування. Крім того, бізнес-сценарії в реальному часі будуть виконуватися під час тестування вручну.
• Буде підготовлено остаточний звіт про весь аналіз безпеки, який проводиться для всієї програми, з висвітленням статусу елементів з високим ризиком, якщо такі є.

Приклади сценаріїв тесту включають,

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

Табличний підсумок для SSDLC

У наведеній нижче таблиці узагальнено різні аспекти аналізу безпеки, які описані вище.

Висновок

Таким чином, завдяки впровадженню всіх цих аспектів, пов'язаних із безпекою, інтегрованих на різних фазах SDLC, організація допомагає організації виявляти дефекти безпеки на початку циклу і дозволяє організації здійснювати відповідні пом'якшення, тим самим уникаючи Дефекти безпеки з високим ризиком в системі Live.

Дослідження також показує, що більшість дефектів безпеки індукуються програмним забезпеченням на етапі розробки, тобто під час Фаза кодування , де кодування недостатньо подбало про всі аспекти безпеки, з якихось причин.

що може відкрити файл JSON

В ідеалі жоден розробник не захоче писати поганий код, який порушує безпеку. Таким чином, для того, щоб допомогти розробникам, як написати безпечне програмне забезпечення, наступний підручник охоплює Найкращі практики та інструкції з кодування для розробників, щоб забезпечити кращу безпеку програмного забезпечення.

Ми сподіваємось, що цей посібник з безпечного SDLC або SSDLC був корисним !!

Рекомендована література

• Етапи, методології, процеси та моделі SDLC (життєвий цикл розробки програмного забезпечення)
• 10 найкращих засобів тестування безпеки мобільних додатків у 2021 році
• 19 Потужні засоби тестування на проникнення, використані професіоналами у 2021 році
• Вказівки щодо тестування безпеки мобільних додатків
• Тестування мережевої безпеки та найкращі інструменти мережевої безпеки
• Тестування безпеки (повний посібник)
• Найкращі 4 інструменти тестування безпеки з відкритим кодом для тестування веб-додатків
• Посібник із тестування безпеки веб-додатків