Крупные компании не могут просто взять и внедрить новое ПО: сначала программный продукт должен подтвердить свою защищенность. В статье разберем, по каким причинам корпорации проводят аудит безопасности программного обеспечения, как устроены эти проверки на примере платформы для управления строительными проектами ЦУС и трех кейсов — банка, энергетической и нефтяной компаний.
Почему корпорации требуют проверки ИБ от вендоров
Защита корпоративных данных — ключевое требование при внедрении программного обеспечения в крупных компаниях. Для этого они проводят аудит безопасности программного обеспечения, который помогает выявить уязвимости и подтвердить защищенность программного продукта перед размещением в закрытом ИТ-контуре.
Изоляция продиктована внутренними регламентами компаний и требованиями законодательства. Компании обязаны соблюдать нормы по защите персональных данных (152-ФЗ), требования к объектам критической информационной инфраструктуры (187-ФЗ), а также отраслевые стандарты информационной безопасности в зависимости от специфики.
В результате любая поставка от вендоров внедряется только после тщательной проверки на соответствие стандартам ИБ. Любое новое ПО — точка входа в IT-экосистему и в нем не должно быть уязвимостей. Поэтому нужно обеспечить защиту корпоративных данных компании: условия контрактов, персональные данные сотрудников и подрядчиков, проектную и другую строительную документацию.
Последние два года тенденция к усилению информационной безопасности наблюдается в связи с увеличением числа хакерских атак. Для вендоров это означает, что они должны быть готовы к поставке ПО с прохождением комплексных проверок на защищенность.
Немного про защиту данных и ИБ
Защита корпоративных данных — это совокупность организационных, правовых и технических мер, которые обеспечивают конфиденциальность, целостность и доступность значимой для бизнеса информации при ее хранении, обработке и передаче в информационных системах и за их пределами. На практике это означает контроль прав доступа, способов обработки и каналов передачи данных, а также предотвращение ее утечки, изменения или уничтожения из-за уязвимостей программного обеспечения, действий сотрудников или внешних кибератак.
Защищенность программного продукта — это свойство программного обеспечения быть устойчивым к уязвимостям и хакерским атакам за счет архитектуры, безопасной разработки и встроенных механизмов защиты. Безопасность ПО формируют на этапе создания продукта, поддерживают во время его эксплуатации и подтверждают в ходе проверок информационной безопасности.
Аудит безопасности программного обеспечения — это проверка программного продукта и процессов его разработки на наличие уязвимостей, ошибок конфигурации и несоответствий требованиям информационной безопасности. Его проводят с привлечением экспертов и применением методов тестирования (например, SAST, DAST, SCA, пентест и других), а затем формируют отчет, который содержит уязвимости и рекомендации по их устранению.
Подпишитесь на e-mail-курс
«Цифровизация строительства — это просто», чтобы разобраться в цифре и не отставать от трендов
Как проходит аудит информационной безопасности строительного программного обеспечения
Ниже мы по шагам разберем, как выглядит типовой алгоритм прохождения проверки на примере поставки платформы для управления строительными проектами ЦУС в закрытые контуры крупных компаний.
1. Получение требований по инфобезу и их анализ. У каждой крупной компании свой перечень регламентов и инструментов, которыми будет проводиться проверка. Отличаются также настройки сканеров, глубина анализа и критерии безопасности.
На этом этапе команда ЦУС совместно со специалистами по ИБ заказчика уточняет формат поставки, перечень проверок, требования к хранению данных и способ организации взаимодействия: например, через виртуальную комнату данных. Чем точнее удается согласовать эти условия на старте, тем меньше итераций потребуется в дальнейшем цикле проверок.
2. Передача кода на проверку заказчику. Команда готовит поставку в том виде, в котором она будет устанавливаться в закрытом контуре. В нее входит только необходимый набор модулей платформы ЦУС, что повышает защищенность программного продукта и максимальную защиту корпоративных данных.
Важно, что к этому моменту команда ЦУС проверяет поставку на своей стороне аналогичными инструментами. Это позволяет заранее снять часть типовых замечаний и ускорить прохождение ИБ.
3. Получение отчета о проведенных проверках. Он включает реестр уязвимостей, которые проранжированы от низкого к критическому уровню, и рекомендации по их устранению. Отчет может содержать сотни уязвимостей, но не все из них реальны: иногда сканеры выдают ложные срабатывания.
4. Анализ отчета и ответ. Этот этап можно назвать арбитражем отчета — специалисту нужно интерпретировать результаты сканера и сделать из них выводы. Поэтому команда разработчиков и архитекторов ЦУС детально разбирает каждое замечание: смотрит контекст, анализирует архитектуру, проверяет, действительно ли проблема имеет место быть.
Результатом становится ответный отчет с указаниями, какие уязвимости должны быть устранены, а какие являются ложноположительными. Далее идет согласование отчета, а также методов устранения уязвимостей.
5. Устранение уязвимостей и повторная передача кода на проверку. После внесения изменений команда формирует новую сборку и повторно передает ее заказчику для проверки теми же инструментами и критериями. Далее цикл повторяется: проверка → отчет → анализ → проверка до тех пор, пока уровень и количество замечаний не снизятся до допустимых значений.
Проверку ИБ можно считать пройденной, когда подтверждена защищенность программного продукта и его соответствие внутренним требованиям безопасности заказчика для полной защиты корпоративных данных. Аудит безопасности программного обеспечения достаточно бюрократический и занимает время: из-за многоэтапных согласований и повторных итераций он может длиться 3−4 месяца и дольше.
Примеры требований и уязвимостей
Среди типовых проверок были требования, связанные с уязвимостями при работе с базами данных. Например, проверялась защита от SQL-инъекций — ситуации, когда злоумышленник может сформировать специальный запрос к базе данных и получить доступ к данным или изменить их.
Такие проверки направлены на предотвращение несанкционированного доступа к данным, вмешательства в работу системы, потенциальных атак на инфраструктуру.
Другая часть требований касается анализа кода. Сканеры ищут потенциально опасные конструкции и участки, где могут возникать уязвимости: например, ошибки контроля доступа, из-за которых пользователь может получить больше прав, чем ему выдал администратор платформы для управления строительными проектами ЦУС.
Три кейса проверок ИБ: банк, энергетическая и нефтяная компании
На каждом проекте использовались разные сканеры, которые проверяли программный продукт ЦУС на защищенность, отличались их настройки и сами критерии того, что считать уязвимостью. Поэтому нельзя было пройти одну проверку и передавать ту же сборку следующему заказчику.
Трек устранения замечаний на каждом проекте шел по разным сценариям.
Кейс 1. Инвестиционный контур банка
Проект шел параллельно с активной доработкой системы ЦУС под продуктовые требования, поэтому проверки ИБ встроились в общий процесс разработки.
Со стороны заказчика использовался статический анализатор кода Checkmarx с максимально строгими настройками. Большая часть замечаний касалась обработки данных при передаче их в интерфейс. Архитектурно эти риски контролировались на бэкенде, но сканер этого не зафиксировал, анализируя файлы и участки кода изолированно по формальным признакам.
Команда пересмотрела подход к этим участкам кода, и количество срабатываний удалось сократить до ~60. Эти замечания были признаны ложноположительными. Дополнительно проводились приемо-сдаточные испытания по информационной безопасности.
2 кейс. Энергетический холдинг
Самый сжатый по времени проект: заказчику потребовалось прохождение ИБ менее чем за 3 месяца. Проверялся расширенный комплекс мер по ИБ: оценивались механизмы аутентификации, проверка аутентификационных данных на стороне сервера, реакция на неудачные попытки входа, управление сессиями, ведение журнала событий. Дополнительно тестировались требования к защите каналов связи, использованию криптографических библиотек и отсутствию секретов в исходном коде.
В ходе SAST и DAST-сканирований команда последовательно устранила уязвимости критического, высокого и среднего уровня, сократив общее количество срабатываний примерно до ~20. Дополнительно проводились приемо-сдаточные испытания по информационной безопасности.
3 кейс. Нефтяная компания
После анализа требований по ИБ команда с вендором выбрали контейнерный способ передачи поставок. Для этого вендор организовал виртуальную комнату данных — промежуточный пункт между инфраструктурой заказчика и вендора, где можно безопасно загружать и выгружать данные.
Заказчик хотел внедрить два модуля ЦУС — исполнительной документации и строительного контроля. Чтобы снизить уязвимости, вендор передал только необходимый функционал, а также внедрил хранилище секретов Vault, которое позволило защитить любые чувствительные данные вроде токенов.
В результате проверки показали отсутствие уязвимостей критического и высокого уровня в коде. Компания масштабировалась на другие строительные процессы платформы для управления строительными проектами.
В процессе прохождения кейсов были выработаны подходы по безопасной разработке, в том числе основываясь на ГОСТ.
Таблица с результатами
| Компания | Тип поставки | Инструменты | Результаты | Продолжительность |
| Банк | Виртуальные машины (OS Alt Linux) | Кодовая база (SAST): Checkmarx Кодовая база (DAST): пентест от компании Digital Security | Устранены все уязвимости в пакетной базе и уязвимости critical и high в кодовой базе. | 9 месяцев: проверка ИБ проходила вместе с доработкой ПО под клиента |
| Энергетический холдинг | Контейнер (OS Ubuntu) + виртуальные машины (OS Alt Linux) | Кодовая база (SAST): Solar app Screener Кодовая база (DAST): ZAP (checkmarx) Пакетная база контейнера: Trivy + Dependency tracker (SBOM) | Устранены все уязвимости в пакетной базе и уязвимости critical, high и medium в кодовой базе. | Менее трех месяцев |
| Нефтяная компания | Контейнер (OS Ubuntu) | Кодовая база (SAST): DefectDojo Сканирование секретов в коде: GitLeaks Пакетная база контейнера: Trivy | Устранены все уязвимости в пакетной базе и уязвимости critical, high в кодовой базе. | Три месяца |
Иван Яценко, руководитель отдела проектной разработки
Гибко устранять уязвимости нам позволяет собственный фреймворк. Наш продукт платформа ЦУС — полностью самостоятельная разработка, мы не используем сторонние фреймворки. Это позволяет не ждать, когда изменения появятся в чужих обновлениях.
Когда возникают новые требования к информационной безопасности, к коду или работе с базами данных, мы можем решать их самостоятельно, не опираясь на ограничения сторонних платформ. В случае со сторонними фреймворками разработчик во многом зависит от их авторов и новых версий, рассчитывая, что вопросы безопасности уже учтены на их стороне.
С прохождением ИБ вендор усиливает защищенность программного продукта
Для вендора прохождение процедур информационной безопасности — возможность системного улучшения продукта под реальные требования крупных закрытых инфраструктур к защите корпоративных данных. Так благодаря процедурам ИБ команда платформы для управления строительными проектами ЦУС:
- Выработала подходы по безопасной разработке, в том числе основываясь на ГОСТ.
- Усовершенствовала код ПО: он стал более устойчивым к SAST и DAST проверкам, а также проверкам секретов в коде и пакетной базе контейнеров.
- Сделала продукт совместимым с программным обеспечением для хранения секретов Vault.
- Разработала методику подбора пакетов, которые необходимы для функционирования ЦУС, с минимальным наличием или полным отсутствием уязвимости.
- Повысила экспертизу относительно безопасной сборки контейнеров.
- Включила в практику предварительную проверку аналогичными инструментами в своем контуре, что позволило отдавать заказчику более безопасный код.
- Разработала и автоматизировала подход, который позволяет отдавать заказчикам только необходимый набор модулей, без лишнего кода.
Иван Яценко, руководитель отдела проектной разработки
Работа по устранению уязвимостей происходит не для конкретного заказчика на конкретном его продукте, она происходит в целом по системе. Поэтому нельзя говорить, что хорошие результаты и доказанная защищенность программного продукта — это кейс отдельного заказчика.
К моменту прохождения третьего ИБ проверка не показала большого количества замечаний. Возможно, потому, что проделана большая работа с Checkmarx при работе с банком. Поэтому каждая следующая поставка платформы ЦУС априори будет более безопасной с точки зрения проверок. Но в то же время мы не защищены от того, что базы данных с уязвимостями у сканнеров могут поменяться, новый заказчик потребует проверку другим ПО или просто изменит настройки.
Выводы
- Для корпораций ИБ — способ защиты корпоративных данных внедрения ПО в закрытый контур в соответствии с законодательством и внутренними требованиями службы информационной безопасности. Из-за увеличения кибератак компании усиливают безопасность ИТ-инфраструктуры, и вендорам необходимо доказывать защищенность ПО, чтобы поставить его заказчику.
- Аудит информационной безопасности программного обеспечения зачастую итеративен, но с каждой итерацией код и компоненты ПО становятся устойчивее к уязвимостям. В процессе проверок одинаково важны сотрудничество, умение договориться о методиках устранения замечаний и интерпретировать результаты программных продуктов.
- Опыт показал, что пройти ИБ у одного заказчика и использовать ту же сборку дальше невозможно: у каждой компании свои требования. Но именно благодаря этому каждая следующая проверка делает программный продукт защищеннее, а команду вендора — опытнее.
