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

10

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

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

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

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

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

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

Давид Качиньский
источник
4
кто говорит, что есть какие-то формальности во взломе вообще
трещотка урод
1
Черт, уже четыре хороших ответа. Будет трудно выбрать только один.
Давид Качиньский,
@DavidKaczynski, вы также можете задать вопрос об информационной безопасности , чтобы узнать мнение тех, кто действительно разрабатывает различные типы программного обеспечения. И есть большие различия, в зависимости от требований безопасности ...
AviD
@AviD спасибо, я думаю, что я получил здесь несколько превосходных ответов в отношении того факта, что жизненные циклы разработки для инвазивного программного обеспечения по своей сути не отличаются. Я хотел бы узнать больше о целях или возможностях инвазивного программного обеспечения, если безопасность нарушена, например, заражение компьютера вирусом, создание бэкдора или имитация пользователя для получения данных.
Давид Качиньский,
1
@DavidKaczynski, но моя точка зрения заключается в том, что он по своей сути отличается - или, скорее, разработка одного типа отличается от другого типа. Посмотрите, например, ответ Терри в качестве примера, и сравните их далее с вирусами, и снова с нулевыми днями, и снова со Stuxnet, и ... Некоторые будут должным образом спроектированы, некоторые выброшены за одну ночь, зависит от различного контекста и требований ,
AviD

Ответы:

7

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

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

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


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

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

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

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

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

Ayrx
источник
У нас еще не было официальной встречи для обсуждения целей или возможных путей нарушения безопасности, поэтому я не могу сказать, какой тип кода мы будем разрабатывать (или если бы мы использовали существующее программное обеспечение / технологию для достижения наших целей). Мне по-прежнему интересно узнать, какие существуют формальные методы, позволяющие воспользоваться преимуществами скомпрометированной системы, такие как создание бэкдоров, имитация пользователей, заражение компьютера вирусом и т. Д. Я полагаю, что этот тип вопроса больше подходит для ИТ-безопасности
Дэвид Качиньский
3

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

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

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

Одед
источник
3

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

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

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

Томас Оуэнс
источник
1

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

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

Майкл Боргвардт
источник
1

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

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

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

Maxood
источник
Это кажется немного субъективным. Вы предлагаете, чтобы другие методы жизненного цикла НЕ вовлекали клиента во время разработки или проверяли приемлемые параметры качества? Конечно, это не уникально для Agile.
Джей Стивенс