Безопасность приложений

Руслан Рахметов, Security Vision

Сегодня большинство крупных компаний так или иначе работают с различным ПО - некоторые его разрабатывают сами, многие устанавливают на корпоративные устройства, кто-то работает с облачными версиями софта. Приложения помогают автоматизировать бизнес-процессы и действия персонала, однако таят в себе сложности и угрозы: бизнес-пользователи сталкиваются с различными сбоями и ошибками в ПО, а специалисты по ИБ обеспокоены возможными уязвимостями в софте, которые эксплуатируются атакующими. Безопасные проектирование, разработка, внедрение, настройка, эксплуатация и поддержка ПО - это отдельное большое направление кибербезопасности, и сегодня мы вкратце обсудим, что такое AppSec (Application security) и как обеспечить безопасность приложений.

Итак, если обратиться к недавно опубликованном стандарту ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования», безопасное ПО - это софт, который был разработан в ходе реализации процессов и мер для предотвращения появления и устранения недостатков ПО. Недостаток ПО - это любая ошибка, допущенная при разработке (проектировании, внедрении, настройке) программы, которая может привести к невозможности выполнять требуемый функционал или быть причиной возникновения уязвимости, потенциально эксплуатируемой атакующими для реализации угроз безопасности информации. В соответствии с ГОСТ Р 56939-2024, основными целями разработки безопасного ПО являются:

• Выявление недостатков, в т.ч. уязвимостей, в разрабатываемом ПО и их оперативное устранение;

• Снижение количества недостатков, в т.ч. уязвимостей;

• Снижение ущерба от невыявленных уязвимостей в ПО.

Если дать более общее определение, то AppSec (Application Security, безопасность приложений) - это набор процессов, практик и инструментов для выявления, устранения и защиты от уязвимостей и недостатков в приложениях в рамках жизненного цикла разработки ПО (SDLC, Software Development Life Cycle). Безопасность нужно обеспечивать для приложений на различных платформах (для ОС на мобильных и стационарных устройствах - Windows, Linux, MacOS, Android, iOS и т.д.), в облачных инфраструктурах (Cloud Application Security) и для веб-приложений (Web Application Security). Среди AppSec-процессов и практик могут быть:

• Построение жизненного цикла разработки безопасного ПО (SSDLC, Secure Software Development Life Cycle);

• Внедрение подходов DevSecOps, Security-as-code, Policy-as-code;

• Работа с AppSec-инструментами (решениями классов SAST, DAST, IAST, SCA, OSA и другими);

• Проведение пентестов и программ Bug Bounty;

• Проведение программ обучения разработчиков и инженеров;

• Управление инцидентами AppSec (обработка сообщений об уязвимостях, анализ и устранение уязвимостей, повышение безопасности разработки).

Внедрение процессов, практик и инструментов AppSec даст следующие преимущества:

• Повышение безопасности: заблаговременное устранение уязвимостей и недостатков в ПО приводит к снижению вероятности реализации киберугроз, утечек данных, хищений денежных средств, нарушения бизнес-процессов;

• Снижение вероятности реализации киберинцидентов: предпочтительнее сделать ПО безопасным изначально, чем разбираться с произошедшим из-за уязвимости инцидентом;

• Повышение уровня соответствия законодательству: обеспечение соответствия законодательству по защите ПДн, КИИ, коммерческой и банковской тайны;

• Снижение влияния недостатков ПО на непрерывность бизнеса: повышение безопасности приложений минимизирует число аварий, простоев и киберинцидентов, связанных с уязвимостями в ПО;

• Автоматизация: ускорение процессов разработки, снижение рутинной нагрузки на разработчиков и тестировщиков, экономия людских ресурсов, снижение влияния человеческого фактора, стандартизация;

• Экономия: за счет оценки киберрисков и учета требований ИБ на более ранних стадиях разработки ПО (концепция «Сдвига влево», Shift Left) происходит снижение затрат на устранение ошибок, недостатков, уязвимостей, а также избежание регуляторных штрафов и необходимости расследовать киберинциденты, достигается экономия на проведении пентестов и аудитов и снижение выплат по программам Bug Bounty;

• Повышение удовлетворенности пользователей: увеличение скорости выхода новых версий, повышение качества кода, рост лояльности и уверенности пользователей в бренде, улучшение репутации вендора;

• Внедрение метрик оценки качества: за счет цифровизации процессов разработки обеспечивается возможность контроля и оптимизации.

Для построения процессов AppSec можно воспользоваться требованиями и рекомендациями следующих популярных стандартов и фреймворков:

• Стандарт ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования»;

• Стандарт ГОСТ Р 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения»;

• Серия стандартов ISO/IEC 27034 "Information technology - Security techniques - Application security";

• Серия стандартов ISO/IEC 24772 "Programming languages - Avoiding vulnerabilities in programming languages";

• Фреймворк NIST "Secure Software Development Framework (SSDF)";

• Фреймворк BSA "Framework for Secure Software";

• Фреймворк Black Duck (ранее - Synopsys) "Building Security In Maturity Model (BSIMM v15)";

• Фреймворк OWASP "Software Assurance Maturity Model (SAMM);

• Фреймворк OWASP "DevSecOps Maturity Model (DSOMM)";

• Практики безопасной разработки Microsoft Security Development Lifecycle (MS SDL);

• Проект "КиберОрда" от Positive Technologies и их методология "AppSec Table Top";

• Фреймворк "DevSecOps Assessment Framework (DAF)" от Jet Infosystems.

Например, фреймворк BSA "Framework for Secure Software" включает в себя следующие 3 направления для реализации процессов и практик Application Security:

1.1. Безопасное написание кода: моделирование угроз и анализ рисков производятся на этапе проектирования ПО; ПО разрабатывается на основе стандартов безопасной разработки; ПО защищено от известных уязвимостей, небезопасных функций и библиотек; применяются стандартные меры контроля архитектуры и проектирования ПО.

1.2. Тестирование и проверка: проводится анализ и проверка поверхности атаки на ПО; код-ревью проводится вручную или с использованием средств автоматизации; внедрен всеобъемлющий план тестирования функционала и безопасности ПО; функции безопасности ПО тестируются с применением соответствующих техник; ПО подвергается фаззинг-тестам и пентестам.

1.3. Процесс и документация: все этапы процессы безопасной разработки задокументированы; разработчики несут ответственность за безопасность ПО.

1.4. Цепочка поставок: процессы разработки связаны с процессами управления рисками цепочек поставок; присутствуют меры для контроля закупок и проверки прозрачности и безопасности сторонних программных компонентов; данные о цепочках поставок адекватно защищаются; присутствуют меры по защите от внедрения программных закладок и подделок; происхождение ПО и данные о нём передаются в стандартизованном формате; обеспечивается контроль корректности процедур развертывания ПО.

1.5. Среда разработки: среда разработки, включая информационные системы и данные, адекватно защищается от киберугроз; ПО разрабатывается с применением инструментария для безопасной разработки.

1.6. Управление идентификацией и контролем доступа: в среде разработки ПО происходит идентификация и аутентификация всех пользователей в рамках цепочки поставок и жизненного цикла ПО; в среде разработки ПО применяются политики контроля доступа к данным и процессам со стороны всех пользователей и операторов.

2.1. Поддержка управления идентификацией и аутентификацией: в ПО не содержатся недостатки, создающие предпосылки для сбоев аутентификации; ПО поддерживает строгие методы идентификации и аутентификации.

2.2. Возможность установки патчей: ПО поддерживает получение и установку обновлений и патчей безопасности.

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

2.4. Авторизация и контроль доступа: при проектировании ПО учтен принцип наименьших привилегий; в архитектуре ПО заложена поддержка авторизации и контроля доступа.

2.5. Журналирование: в ПО логируются все события и инциденты ИБ; механизмы журналирования ПО реализованы безопасным образом.

2.6. Обработка ошибок и исключений: в ПО реализован функционал обработки ошибок и исключений; в случае сбоя или неожиданного прекращения работы ПО корректно выполняются предопределенные процедуры безопасного завершения работы (fail secure).

3.1. Управление уязвимостями: вендор поддерживает актуальный план управления уязвимостями; уязвимости выявляются и устраняются быстро и комплексно с учетом их риск-ориентированной приоритизации; вендор поддерживает программу раскрытия уязвимостей.

3.2. Конфигурация: ПО поставляется с конфигурацией и руководством по изменению настроек для обеспечения безопасной установки и эксплуатации ПО.

3.3. Уведомления об уязвимостях и патчинг: вендор оперативно распространяет пачти и обновления для устранения выявленных недостатков безопасности ПО; патчи и обновления распространяются безопасным образом; патчи и обновления безопасности сопровождаются уведомлениями с описанием необходимой пользователям информации.

3.4. Окончание срока разработки и поддержки: вендор поддерживает рекомендации пользователям по жизненному циклу ПО.