Как безопасная разработка ПО оптимизирует операционную деятельность

Анастасия Харыбина, руководитель AKTIV.CONSULTING, председатель Ассоциации АБИСС, рассказала на страницах портала «Банковское обозрение», почему в последнее время все больше организаций склоняются к внедрению процессов безопасной разработки ПО (БРПО), которые не только разово подтверждают отсутствие уязвимостей в конкретный момент времени, но и минимизируют вероятность их появления на всем жизненном цикле ПО за счет периодического проведения проверок безопасности.

Как безопасная разработка ПО оптимизирует операционную деятельность

Предпосылки внедрения БРПО

Последние полгода силы ИТ/ИБ служб финансовых организаций были брошены на реструктуризацию внутренних процессов и поиск решений, которые могли бы обеспечить непрерывность операционной деятельности в условии ухода зарубежных вендоров. Многие организации столкнулись с тем, что имеющиеся на рынке решения в сегодняшнем своем виде не соответствуют их ожиданиям. И здесь перед организациями встал вопрос: внедрять то, что есть на рынке, и дорабатывать вместе с российскими вендорами, или же постепенно занять вендоронезависимую позицию и начать разработку собственных решений.При этом требования по обеспечению информационной безопасности никто не отменял. В частности, требования по безопасности прикладного ПО и автоматизированных систем, которые участвуют в финансовых операциях (Положения Банка России 683-П и 757-П). Помимо этого, если финансовая организация владеет значимым объектом критической информационной инфраструктуры (ЗО КИИ), требование по безопасности распространяется на все прикладное ПО согласно Приказу №239 ФСТЭК России.

Анализ уязвимости VS Безопасная разработка

Есть несколько способов подтвердить безопасность ПО: наличие сертификата ФСТЭК на используемое ПО, регулярное проведение анализа уязвимостей ОУД4 по ГОСТ Р 15408, внедрение процесса безопасной разработки программного обеспечения. И если изначально требования Банка России предполагали первые два варианта, то сейчас внедрение БРПО стало решением для многих организаций.По сути, большинство организаций выбирают между проведением анализа уязвимости и внедрением БРПО. Оба варианта имеют свои сильные и слабые стороны, а решение, какой путь выбрать, во многом зависит от выстроенных в организации процессах, в том числе от наличия собственной разработки. В любом случае все упирается в экономическое обоснование и корреляцию с бизнес-целями. В случае с анализом уязвимости требуются меньшие, но постоянные вложения, при этом безопасность оценивается на конкретный момент времени, и при обнаружении уязвимостей запускается дорогостоящий цикл разработки для их устранения. В случае БРПО необходимо больше ресурсов в процессе реализации проекта по внедрению, но в дальнейшем при поддержании процесса затраты минимальны.Если говорить о тенденциях, то, безусловно, внедрение безопасного жизненного цикла разработки (SSDLC) – это более современный и дальновидный подход, так как он носит комплексный характер решения проблемы и работает на опережение. При этом помогает сократить стоимость самой разработки и стоимость реализации требований информационной безопасности.

Внедрение БРПО в финансовых организациях

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

  • 1 этап – Обоснование. Определение целей и задач проекта, подготовка технико-экономического обоснования. Результатом будет принятие решение руководства о выделении ресурсов на проект.
  • 2 этап – Аудит. Обследование текущих бизнес-процессов разработки, формирование целевого состояния процесса БРПО, проведение GAP-анализа. Результатом будет перечень организационных и технических мер.
  • 3 этап – Дорожная карта. Ранжирование описанных на предыдущем этапе мер, разработка плана перехода к целевому состоянию. Результатом будет дорожная карта внедрения процесса БРПО.
  • 4 этап – Внедрение. Внедрение организационных мер (разработка ОРД и ЛНА, проведение обучения) и технических мер (SAST, DAST, Fuzzing).
  • 5 этап – Контроль. Проверка полноты и достаточности внедренных мероприятий для достижения целевого состояния БРПО. Результатом будет внедренный процесс БРПО в соответствии с требованиями регулятора и бизнес-целями организации.

Отдельное внимание необходимо уделить конфигурации целевого состояния процесса БРПО на втором этапе. И здесь опять же нужно обратиться к целям проекта, так как от них напрямую зависит, какую методологию организации БРПО выбрать. В случае комплаенс-целей можно ориентироваться, например, на Приказ ФСТЭК России №239, где описаны основные мероприятия по проверке безопасности. В общем виде все основные процессы БРПО описаны в ГОСТ Р 56939, но их необходимо дополнить процессами менеджмента БРПО по ГОСТ Р ИСО/МЭК 27034хх. Можно выделить три большие группы подпроцессов:

  1. Основные – разработка ПО (дополняется процессами моделирования угроз, статического и динамического анализа, фаззинг-тестирования и пр.), поддержка ПО в ходе жизненного цикла (дополняется процессами систематического выявления уязвимостей, оповещения об ошибках и уязвимостях конечных пользователей и пр.);
  2. Вспомогательные – менеджмент процессов БРПО, правовое регулирование;
  3. Обеспечивающие – управление инфраструктурой среды разработки, управление конфигурацией, обучение персонала.

При соблюдении проектного подхода к внедрению БРПО и корректном формировании целевого состояния с учетом имеющихся процессов и бизнес-целей, безопасная разработка не только не утяжелит операционную деятельность, но и оптимизирует ее.