Предположите, что Ваше программное обеспечение подвергнется нападению

Количество времени и усилие, что атакующий потратит атаку Вашей программы, зависят от нескольких факторов, включая:

• Значение данных Ваши дескрипторы программы. Это хранит тысячи номеров кредитных карт или набор рецепта пользователя?

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

• Определенные клиенты, купившие Вашу программу. Ваше приложение текстового редактора использует Автоматическим Восстановлением Джо или Big Megacorp, Inc.?

• Как широко будет распределена Ваша программа. Действительно ли это - приложение, использующееся единственной, маленькой рабочей группой, или это встроено в операционную систему, собирающуюся быть выпущенной во всем мире?

На основе тех тех же факторов необходимо решить, какой уровень риска приемлем. Потеря данных, которые будут стоить Вашей компании 1 000$ для исправления, не выравнивает по ширине усилие по разработке за 10 000$ закрыть все потенциальные ошибки безопасности. С другой стороны, ущерб репутации Вашей компании мог бы стоить намного более в конечном счете, чем это будет стоить, чтобы разработать и разработать безопасный код.

Оцените риск

Вот некоторые факторы для рассмотрения при оценке риска:

• Какова худшая вещь, которая может произойти, если Ваше программное обеспечение успешно подвергается нападению?

  Это позволит хищение идентификационных данных пользователя, позволит атакующему получать контроль над компьютером пользователя, или просто позволять хакеру получить необычно высокий счет в пинболе?

• Как трудно это должно предпринять успешную атаку?

  Если использование уязвимости потребовало бы установки Троянского коня на компьютере пользователя, который может использовать в своих интересах состояние состязания, происходящее только, как только в 50 раз программе запускает, Вы могли бы решить, что уровень риска приемлем. Если использование может помещаться в сценарий и использоваться деточками сценария (атакующие, выполняющие предзаписанные сценарии атаки), или автоматизированы для распространения сетями роботов (сети захваченных компьютеров), уровень риска намного выше.

• Насколько большой цель - он?

  Вы продавали сто копий своего приложения, или оно установлено по умолчанию на сотнях тысяч компьютеров?

  Действительно ли это уязвимо по умолчанию, или только после того, как пользователь выберет необычный набор опций?

• Сколько пользователей было бы затронуто?

  Атака на машину конечного пользователя обычно влияет на одного или двух человек, но атака «отказ в обслуживании» на сервере могла бы влиять на тысячи пользователей, если даже один сервер подвергается нападению. Точно так же червь, распространенный общей почтовой программой, мог бы заразить тысячи компьютеров.

• Насколько доступный цель?

  Выполнение программы требуют локального доступа, или программа принимает запросы через сеть? Аутентификация требуется для установления соединения, или кто-либо может отправить запросы к программе?

Создайте модель угрозы

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

• Типы данных Ваше приложение будут работать с

• Ситуации, в которых Ваше приложение должно иметь дело с недоверяемыми данными

• Типы данных транспортируют Ваше использование приложения

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

• Стратегии смягчения каждого из тех типов использования

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

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

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

• Вывод Program (или пользователю или к другому программному модулю). Атакующий мог бы быть в состоянии получить доступ к частной информации, хранившей в системе, или считать и изменить информацию, передаваемую между модулями (атака «человек посередине»).

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

• Среда программы. Среда выполнения программы включает свои открытые дескрипторы файлов, переменные окружения, порты Маха, предпочтительные файлы, и т.д.

Рассмотрите типы угроз

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

Используйте общие методы смягчения

Средние значения смягчения угроз в программном обеспечении являются многими и варьировались, но несколько базовых методов распространены:

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

• Используйте в своих интересах игру в песочнице — установление определенных разработчиками пределов для того, что Ваше приложение может сделать — для минимизации ущерба, который может нанести приложение, если это поставилось под угрозу.

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

• Выполните fuzzing — отправляющий неправильных данных в Ваше приложение или демона, чтобы видеть, повреждается ли это — и исправьте любые ошибки, которые Вы находите в процессе.

• Используйте в своих интересах функциональность безопасности, встроенную в операционную систему вместо того, чтобы заново изобрести колесо.

Знайте компромиссы

При решении, как смягчить угрозу, имейте в виду, что часто существуют компромиссы между безопасностью и удобством. Безопасность программного обеспечения должна установить равновесие между безопасностью и удобством пользования. Рассмотрите два экстремальных примера проектирования программного обеспечения:

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

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

• Другая программа всегда работает с полномочиями пользователя root и выполняет любую работу, которую Вы любите, никогда не требуя авторизации.

  Такая программа проста в использовании, и на физически безопасном компьютере, не подключенном к сети, это могло бы даже быть умеренно безопасно. Однако под наиболее нормальными условиями, это была бы огромная угроза безопасности.

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