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

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

Я представляю кілька основних гнучких концепцій розробки для декількох команд, такі як історії користувачів, оцінка складності завдань та безперервна інтеграція для контролю версій та автоматизованих побудов / тестувань.

Я знайомий з деякими базовими життєвими циклами розвитку, такими як водоспад, спіраль, RUP, рухливий тощо, але мені цікаво, чи існує таке поняття, як життєвий цикл розробки програмного забезпечення для злому / порушення безпеки. Звичайно, хакери пишуть комп'ютерний код, але який життєвий цикл цього коду? Я не думаю, що вони будуть надто перейматися технічним обслуговуванням, оскільки, як тільки порушення виявлено та виправлено, код, який використовував це порушення, марний.

Я думаю, що життєвий цикл був би таким:

1. Знайдіть розрив у безпеці
2. Скористайтеся розривом у безпеці
3. Придбати корисне навантаження
4. Використовуйте корисне навантаження

Які існують відмінності (якщо такі є) для життєвого циклу розробки програмного забезпечення, коли метою продукту є порушення безпеки?

Про який код ви говорите?

Існує багато інструментів безпеки, які використовуються в процесі злому, включаючи сканери, такі як nmap , sqlmap , Nessus та багато інших. Я б міг уявити, що вони мають такий самий тип життєвих циклів програмного забезпечення, як і будь-які інші програми.

З іншого боку, існують коди експлуатації. Коди написані, щоб скористатися дуже специфічною експлуатацією та ситуацією. Я дуже сумніваюся, що вони взагалі потребують життєвого циклу. Однак багато коди експлуатації також інтегровані з більш широкою рамкою експлуатації, як Metasploit .

Після обговорення з @AviD, я хотів би додати декілька пунктів.

Це буде дуже різним для конкретних ситуацій.

Деякі коди експлуатації можуть бути вимкнено, щоб врахувати вікно перед виправленням нульового дня. Код може бути вимкнено і з інших причин. Дивіться: ЗЛОЧИН - Як перемогти спадкоємця БЕСТА? на відмінний приклад цього. Людина написала фрагмент коду PoC, щоб швидко довести свою думку. Жодна методологія життєвого циклу програмного забезпечення не враховується для таких кодів.

Мабуть, такі зловмисні програми, як stuxnet або FLAME. Таке програмне забезпечення, як Metasploit.

Тож правильна відповідь - це залежить.

Я не розумію, чому повинен існувати конкретний різний життєвий цикл розвитку залежно від призначення продукту.

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

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

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

Я не впевнений, що ці моделі можна безпосередньо застосувати до більш орієнтованих на наукові проекти проектів, де ви намагаєтесь відповісти на запитання або дізнатися більше про систему (або про слабкість безпеки системи у вашому конкретному випадку).

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

Нещодавно хакерство сприймає сильну професіоналізацію, далеко від того, як хакери роблять це "за лулз" або щоб отримати славу, до співпраці між фахівцями з метою заробітку. Результатом цього стали повноцінні комерційні «хакерські набори», такі як комплект для експлуатації Blackhole, де конкретні слабкі програми можна легко інтегрувати, як плагіни. Я припускаю, що такі продукти розроблені майже так само, як і будь-які інші програмні продукти.

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

Life-Cyle ніколи не залежить від коду. Він швидше залежить від інших факторів, таких як:

1. Час
2. Бюджет
3. Характер замовника
4. Характер товару

У вашому сценарії методологія Agile Life Cyle була б найбільш корисною. Причина полягає в тому, що потрібно залучати свого клієнта під час розробки та перевіряти прийнятні параметри якості вашого продукту. Agile Methodology допоможе вам надзвичайно вдосконалити ваше програмне забезпечення для злому, збираючи відгуки клієнтів, а потім поступово працюючи поступово .