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

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

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

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

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

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

Если говорить о тенденциях, то, безусловно, внедрение безопасного жизненного цикла разработки (SSDLC) — это более современный и дальновидный подход, так как он носит комплексный характер решения проблемы и работает на опережение. При этом он помогает сократить стоимость самой разработки и стоимость реализации требований информационной безопасности.

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

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

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

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

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

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

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