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

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

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

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

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

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

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

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

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

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

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

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

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

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