Каковы уникальные аспекты жизненного цикла программного обеспечения атаки / инструмента на уязвимость программного обеспечения?

В моем местном университете есть небольшой студенческий компьютерный клуб, насчитывающий около 20 студентов. В клубе есть несколько небольших команд с особыми сферами деятельности, такими как разработка мобильных приложений, робототехника, разработка игр и взлом / безопасность.

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

Я знаком с некоторыми основными жизненными циклами разработки, такими как «водопад», «спираль», «RUP», «agile» и т. Д., Но мне интересно, существует ли такая вещь, как жизненный цикл разработки программного обеспечения для взлома / взлома безопасности. Конечно, хакеры пишут компьютерный код, но каков жизненный цикл этого кода? Я не думаю, что они были бы слишком обеспокоены обслуживанием, так как после того, как нарушение было найдено и исправлено, код, использовавший это нарушение, становится бесполезным.

Я полагаю, что жизненный цикл будет примерно таким:

1. Найти пробел в безопасности
2. Используйте пробел в безопасности
3. Заготовка полезной нагрузки
4. Использовать полезную нагрузку

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

О каком типе кода вы говорите?

В процессе взлома используется множество инструментов безопасности, включая сканеры, такие как nmap , sqlmap , Nessus и многие другие. Я бы предположил, что они имеют такой же жизненный цикл программного обеспечения, как и любые другие приложения.

С другой стороны, есть коды эксплойтов. Коды написаны, чтобы использовать в своих интересах очень специфический эксплойт и ситуацию. Я очень сомневаюсь, что те вообще нуждаются в жизненном цикле. Однако многие коды эксплойтов также интегрированы с более крупной средой разработки, такой как Metasploit .

После обсуждения с @AviD я хотел бы добавить несколько моментов.

Это будет сильно отличаться для конкретных ситуаций.

Некоторые коды эксплойтов могут быть выброшены, чтобы учесть окно до того, как будет исправлен нулевой день. Код может быть исключен и по другим причинам. Смотрите: ПРЕСТУПЛЕНИЕ - Как победить преемника Зверя? за отличный пример этого. Человек написал фрагмент кода PoC, чтобы быстро доказать свою точку зрения. Для таких кодов не учитывается методология жизненного цикла программного обеспечения.

Оружейные вредоносные программы, такие как stuxnet или FLAME, вероятно, делают. Пакетное программное обеспечение, как Metasploit сделать.

Так что правильный ответ ... это зависит.

Я не понимаю, почему должен быть какой-то совершенно иной жизненный цикл разработки в зависимости от назначения продукта.

Программное обеспечение, разработанное с целью нарушения безопасности, может иметь такой же долгий срок службы, как и любой другой тип программного обеспечения, и требует такого же объема обслуживания и работы.

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

Модели разработки, которые вы укажете, - это просто модели развития. Они чрезвычайно полезны, когда вы занимаетесь инженерными разработками - когда у вас есть требования, когда вам нужно создать или изменить архитектуру системы или дизайн компонентов, когда вам нужно создать или изменить продукт и связанные с ним тесты, и когда вы выпускаете заказчику.

Я не уверен, что эти модели могут быть непосредственно применены к более ориентированным на исследования проектам, где вы пытаетесь ответить на вопросы или узнать больше о системе (или слабых сторонах системы в вашем конкретном случае).

Я подозреваю, что итеративные / инкрементальные модели, такие как гибкие методы и спиральная модель, были бы наиболее полезными для формирования основы. На каждой итерации вы можете работать над тем, чтобы отвечать на вопросы или определять дополнительные параметры для работы, что может включать или не включать написание какого-либо кода. Возможно, различные методы научных исследований также могут послужить интересной основой.

В последнее время хакерство стало свидетелем сильной профессионализации: от одиноких хакеров, делающих это «ради лулза» или для получения славы, к сотрудничеству между специалистами с целью зарабатывания денег. В результате были получены полноценные коммерческие «хакерские наборы», такие как набор для эксплойтов Blackhole, где отдельные слабые места программного обеспечения можно легко интегрировать, например, плагины. Я предполагаю, что такие продукты разрабатываются практически так же, как и любые другие программные продукты.

Существует также, очевидно, развивающийся рынок для эксплойтов нулевого дня .

Life-Cyle никогда не зависит от кода. Это скорее зависит от других факторов, таких как:

1. Время
2. бюджет
3. Природа клиента
4. Природа продукта

В вашем сценарии методология Agile Life Cyle была бы наиболее полезной. Причина в том, что вам необходимо вовлечь клиента в процесс разработки и проверить приемлемые параметры качества вашего продукта. Гибкая методология поможет вам значительно улучшить ваше программное обеспечение для взлома путем сбора отзывов ваших клиентов, а затем постепенно работать на поэтапной основе.