Элементы процесса разработки безопасного по Процесс обучения сотрудников

В ходе обучения сотрудники получают необходимые знания по осуществлению безопасной разработки. Знания необходимы, т.к. только обладая знаниями об уязвимостях, разработчик может принимать и проводить меры по устранению/недопущению уязвимостей в коде. Аналогичный технологический барьер наблюдается и для архитекторов и для тестировщиков – без знаний по вопросам безопасности невозможно создание безопасных приложений. И без прохождения определенных тренингов, без обучения решению практических задач связанных с безопасностью, просто не имеет смысла говорить о гарантировании создания безопасного кода. Именно поэтому процесс обучения, пожалуй, наиболее важный во всем процессе разработки безопасного ПО.

Моделирование угроз

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

Трех уровневая защита от уязвимостей в коде

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

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

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

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

• Регулярные ревизии кода командой безопасности.Но, несмотря на делегирование части ответственности команде разработчиков (для проведения ревизий), команде безопасности следует проводить регулярные проверки кода. (проводятся после добавления/модификации кода в приложениях, которые ранее прошли ревизии кода разработчиками) Регулярные ревизии кода позволяют минимизировать цену требуемых изменений для устранения уязвимостей – чем раньше будет найдена уязвимость, тем дешевле ее исправление, а также для того чтобы не допустить снижения уровня знаний по вопросам безопасности у разработчиков. Те или иные уязвимости будут найдены раньше или позже, но минимизировать затраты на устранения уязвимостей лучше минимизировав время обнаружения уязвимостей (чтобы они успели оказать минимальный возможный эффект на остальную разработку). Такая минимизация цены внесения исправлений и есть основная цель регулярных ревизий кода.

• Финальные ревизии кода командой безопасности.Необходимы для конечной проверки приложения на наличие уязвимостей. А так же для того чтобы гарантировать, что приложение готово для использования конечными пользователями.

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

Список уязвимостей, с которыми работает процесс разработки безопасного ПО (проще говоря, те которые ищутся в коде в ходе ревизий), формируется и документируется командой безопасности. Также команда безопасности обеспечивает обучение сотрудников по поиску/устранению/недопущению уязвимостям из списка уязвимостей. Список уязвимостей может быть предоставлен заказчику. Также заказчик может вносить предложения по списку уязвимостей критичных для его приложения.

Ревизии проводятся в следующем порядке:

1. Ревизии кода разработчиками. Таким образом, мы получаем на некоторый момент времени проверенный код.

2. Регулярные ревизии кода. Они необходимы для контроля кода, который был создан/модифицирован после ревизии кода разработчиками.

3. Финальные ревизии кода (как часть финальных ревизий безопасности) для конечной проверки приложения на уязвимости и получения приложений, которые с точки зрения безопасности могут использоваться конечными пользователями.