Предпосылки внедрения БРПО
Последние полгода силы ИТ/ИБ служб финансовых организаций были брошены на реструктуризацию внутренних процессов и поиск решений, которые могли бы обеспечить непрерывность операционной деятельности в условии ухода зарубежных вендоров. Многие организации столкнулись с тем, что имеющиеся на рынке решения в сегодняшнем своем виде не соответствуют их ожиданиям. И здесь перед организациями встал вопрос: внедрять то, что есть на рынке, и дорабатывать вместе с российскими вендорами, или же постепенно занять вендоронезависимую позицию и начать разработку собственных решений.При этом требования по обеспечению информационной безопасности никто не отменял. В частности, требования по безопасности прикладного ПО и автоматизированных систем, которые участвуют в финансовых операциях (Положения Банка России 683-П и 757-П). Помимо этого, если финансовая организация владеет значимым объектом критической информационной инфраструктуры (ЗО КИИ), требование по безопасности распространяется на все прикладное ПО согласно Приказу №239 ФСТЭК России.
Анализ уязвимости VS Безопасная разработка
Есть несколько способов подтвердить безопасность ПО: наличие сертификата ФСТЭК на используемое ПО, регулярное проведение анализа уязвимостей ОУД4 по ГОСТ Р 15408, внедрение процесса безопасной разработки программного обеспечения. И если изначально требования Банка России предполагали первые два варианта, то сейчас внедрение БРПО стало решением для многих организаций.По сути, большинство организаций выбирают между проведением анализа уязвимости и внедрением БРПО. Оба варианта имеют свои сильные и слабые стороны, а решение, какой путь выбрать, во многом зависит от выстроенных в организации процессах, в том числе от наличия собственной разработки. В любом случае все упирается в экономическое обоснование и корреляцию с бизнес-целями. В случае с анализом уязвимости требуются меньшие, но постоянные вложения, при этом безопасность оценивается на конкретный момент времени, и при обнаружении уязвимостей запускается дорогостоящий цикл разработки для их устранения. В случае БРПО необходимо больше ресурсов в процессе реализации проекта по внедрению, но в дальнейшем при поддержании процесса затраты минимальны.Если говорить о тенденциях, то, безусловно, внедрение безопасного жизненного цикла разработки (SSDLC) – это более современный и дальновидный подход, так как он носит комплексный характер решения проблемы и работает на опережение. При этом помогает сократить стоимость самой разработки и стоимость реализации требований информационной безопасности.
Внедрение БРПО в финансовых организациях
Внедрение нового процесса или реструктуризация имеющегося в любой организации проходит при внутреннем сопротивлении, и это нормально. В случае с БРПО препятствиями могут стать слабое обоснование для принятия решения, нехватка внутренних компетенций, завышенная оценка риска влияния на существующие процессы и так далее. Для положительного решения относительно внедрения процесса БРПО и его успешного внедрения необходимо соблюсти два основных момента: правильно сконфигурировать проект внедрения и разработать целевое состояние БРПО.Конфигурация проекта подразумевает обязательное выделение руководителя и команды проекта, куда должны войти представители всех подразделений, участвующих в новом процессе. Помимо этого, необходимо описать этапы проекта:
- 1 этап – Обоснование. Определение целей и задач проекта, подготовка технико-экономического обоснования. Результатом будет принятие решение руководства о выделении ресурсов на проект.
- 2 этап – Аудит. Обследование текущих бизнес-процессов разработки, формирование целевого состояния процесса БРПО, проведение GAP-анализа. Результатом будет перечень организационных и технических мер.
- 3 этап – Дорожная карта. Ранжирование описанных на предыдущем этапе мер, разработка плана перехода к целевому состоянию. Результатом будет дорожная карта внедрения процесса БРПО.
- 4 этап – Внедрение. Внедрение организационных мер (разработка ОРД и ЛНА, проведение обучения) и технических мер (SAST, DAST, Fuzzing).
- 5 этап – Контроль. Проверка полноты и достаточности внедренных мероприятий для достижения целевого состояния БРПО. Результатом будет внедренный процесс БРПО в соответствии с требованиями регулятора и бизнес-целями организации.
Отдельное внимание необходимо уделить конфигурации целевого состояния процесса БРПО на втором этапе. И здесь опять же нужно обратиться к целям проекта, так как от них напрямую зависит, какую методологию организации БРПО выбрать. В случае комплаенс-целей можно ориентироваться, например, на Приказ ФСТЭК России №239, где описаны основные мероприятия по проверке безопасности. В общем виде все основные процессы БРПО описаны в ГОСТ Р 56939, но их необходимо дополнить процессами менеджмента БРПО по ГОСТ Р ИСО/МЭК 27034хх. Можно выделить три большие группы подпроцессов:
- Основные – разработка ПО (дополняется процессами моделирования угроз, статического и динамического анализа, фаззинг-тестирования и пр.), поддержка ПО в ходе жизненного цикла (дополняется процессами систематического выявления уязвимостей, оповещения об ошибках и уязвимостях конечных пользователей и пр.);
- Вспомогательные – менеджмент процессов БРПО, правовое регулирование;
- Обеспечивающие – управление инфраструктурой среды разработки, управление конфигурацией, обучение персонала.
При соблюдении проектного подхода к внедрению БРПО и корректном формировании целевого состояния с учетом имеющихся процессов и бизнес-целей, безопасная разработка не только не утяжелит операционную деятельность, но и оптимизирует ее.