Переход в digital-сегмент банков, ритейла, медицины и других жизненно важных отраслей производства и обслуживания спровоцировал многочисленные угрозы в плане безопасности. Сегодня во всем мире продолжает расти активность злоумышленников, а вопросы защиты пользовательских и корпоративных данных от кражи и намеренного повреждения все чаще становятся предметом обсуждения профессионалов.

Как бизнесу и ИТ правильно интегрировать безопасность в процесс разработки, какие инструменты для этого лучше использовать, как это все ложится на реальную практику внедрения. Делимся подходами Ростелеком, М.Видео-Эльдорадо, DD Planet, AGIMA.

Ярослав Александров, руководитель отдела разработки Solar appScreener в Ростелеком, — о том, как встроить SAST в разработку

С ростом компании и увеличением числа разработчиков проверять продукт на уязвимости «вручную» становится все сложнее. Приходится использовать SAST — средства статического тестирования защищенности приложений (Static Application Security Testing). В Solar appScreener информационная безопасность строится на базе внутреннего продукта. Продукт анализирует исходные коды. На сегодня поддерживается 26 языков программирования, исходники которых могут быть проанализированы уязвимость, и поддерживает все популярные форматы и системы управления проектами.

Как выбрать SAST?

Даже простую уязвимость невозможно отыскать при помощи примитивных алгоритмов. Сегодня на рынке представлена масса SAST-решений, как платных, так и бесплатных. Самые популярные из них — AppScan от IBM Security, Synopsys, Veracode, Application Inspector, Micro Focus, Appercut, Checkmarks.

От выбора инструмента зависит эффективность процесса разработки. Главные преимущества платных решений:

• Фокус на безопасность: специфические алгоритмы и большие базы правил.
• Поддержка множества языков программирования.
• Удобный интерфейс.
• Наличие плагинов и API.
• Наличие технической поддержки инструмента.

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

После того как SAST-решение выбрано, нужно интегрировать его в процесс разработки. Возможности интеграции могут быть следующими: встраивание инструмента в репозиторий, среды разработки, серверы CI/CD, системы отслеживания задач. Хороший инструмент способен успешно встраиваться во все перечисленные классы систем.

Примечание: открытый API SAST включает JSON API и CLI и предоставляет широкие возможности по дополнительной интеграции и автоматизации.

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

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

Следующим этапом проводят сравнение по качеству: анализируют уязвимости и ложные срабатывания применительно к собственному коду.

Нюансы и тонкости анализа кода

Чем раньше найдена уязвимость, тем дешевле она обходится разработчику и заказчику. Это значит, что продукт нужно периодически проверять на уязвимости в процессе разработки и дополнительно проводить контрольные проверки перед релизом.

Скорость и ресурсы: обычно ожидается, что инструмент будет работать быстро; запускаться на каждое изменение; показывать «на лету», кто и когда внес уязвимость. На самом деле SAST анализирует код не менее 8 часов, его сложно запускать на каждое изменение; трудно определить автора уязвимости; случаются ложные срабатывания. А значит, возникает вопрос: как настроить DevSecOps.

Здесь очень важно:

• Рассчитать время и ресурсы на анализ вашего кода.
• Определить триггеры запуска сканирования по результатам.
• Иметь в виду, что мощность нужно будет периодически пересчитывать.
• Лучше применять инкрементальный анализ, но делать это нужно с осторожностью, поскольку уязвимости могут теряться.

К примеру, можно запускать тестирование с помощью SAST, когда разработчик отправляет задачу на ревью. Можно также запускать сканирование и по окончании рабочего дня.

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

Работая над интеграцией SAST в процесс разработки, важно внедрять процессы постепенно без блокирования релиза. Последовательность процесса может быть такой:

• Выбор инструмента.
• Описание процесса (создание регламента).
• Описание технических решений.
• Проведение работ по внедрению.
• Опытная эксплуатация.

Начинать лучше с наиболее критичных систем: важно устранить новые уязвимости, провести проектирование, внедрить регламенты и технические решения.

В регламенте нужно обязательно обозначить:

• Шаги проверки кода на уязвимости.
• Ответственного за запуск сканирования.
• Роли и результаты.
• Как будет налажен процесс коммуникации.
• Service Level Agreement.
• Ответственных за контроль процесса.
• Порядок добавления новых систем к процессу.

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

Итоговые рекомендации:

• Используйте SAST на каждом этапе разработки.
• Адаптируйте интеграцию под ваш код и ваш процесс.
• Начните с устранения новых уязвимостей.
• Постепенно устраняйте старые уязвимости.
• Создавайте процесс на основе SAST.
• Внедряйте постепенно, начиная без влияния на релизы.

Владимир Садовский, руководитель группы мониторинга и реагирования на инциденты информационной безопасности «М.Видео-Эльдорадо», — о том, как построить процесс безопасного программирования

Основная идея концепции безопасного программирования сводится к тому, чтобы помогать бизнесу; ускорять процессы; минимизировать риски возникновения проблем, связанных с уязвимостями в продукте.

Классический подход к безопасности наглядно можно представить так:



Его главная проблема — связана с высокой стоимостью доработок, которые необходимы для обеспечения безопасности. Кроме того, важно обеспечить протоколы шифрования данных, шифрование протокола передачи интеграционных шин и так далее.

Что касается площадок ecommerce, то они подвергаются атакам злоумышленников чаще, чем многие другие. Цели таких атак — попытка получить определенную финансовую выгоду (обмануть программу и приобрести дорогостоящий товар бесплатно), либо завладеть персональными данными клиентов. К сожалению, пока некоторые проблемы не удается закрыть использованием классических сканеров уязвимостей. Например, если в приложении есть сканер авторизации по отпечаткам пальцев, ни один статический анализ не покажет некорректность работы такого функционала в приложении. Это увеличивает риск инцидентов, связанных с проникновением злоумышленников в аккаунты пользователей приложения. При этом, чем ближе к релизу находится приложение ритейлера, тем дороже ему обойдется исправление уязвимостей и багов.

Схема применения средств тестирования безопасности кода ecommerce-площадки может выглядеть следующим образом:



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

Далее запускается финальное тестирование, в ходе которого анализируют весь объем кода конечного продукта и “подчищают” остаточные баги.

Угрозы безопасности в ритейле

Основным драйвером для ритейла являются продажи — будь то оффлайн-магазины, интернет, маркетинг, базы данных клиентов. Все нацелено на то, чтобы максимально приблизиться к пользователю. Кроме того современный ритейл стремится продавать свои продукты, используя омниканальность; запускает различные маркетинговые акции и программы. Все это интересно не только потребителям, но и злоумышленникам. Здесь появляется дополнительная оценка, связанная с безопасностью, — потенциальный ущерб. Анализ призван выявлять баги на сайте, логические ошибки и классические проблемы безопасности, от которых впоследствии страдают реальные потребители.

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

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

Также очень важно обеспечить контроль доступа, организовать доверенную среду, настроить средства мониторинга и предотвращения утечек данных. Придется также сформировать детальные требования и политики по безопасному программированию, фиксировать все версионности Open Source и внешних библиотек.

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

Существуют различные статические и динамические анализаторы, которые позволяют выявлять проблемы и вовремя их устранять. Задача IT-подразделения — проверить, что цепочка кода работает корректно с точки зрения технических требований. Задача отдела безопасности — проверить код на уязвимости безопасности.

Поиск уязвимостей безопасности в бизнес-логике сводится к следующим аспектам:

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

Не все проблемы безопасности можно найти устранить на уровне кода и разработки. Задача отдела безопасности выстроить и наладить эффективный процесс управлением уязвимостями и инцидентами. Для этого нужно постоянно анализировать поведение пользователей, профилировать их, следить за поведением. Если оно отклоняется от привычных бизнесу паттернов, нужно рассматривать это как инцидент и немедленно реагировать.
Анализировать поведение пользователей помогает:

• Работа с Big Data и построение моделей аномального поведения и отклонения от нормы.
• Процесс мониторинга и аудита JS-скриптов. Современные сайты не работают без JS-скриптов. Зачастую они загружаются с внешних ресурсов. Поэтому важно понимать их функционал, и какую угрозу JS-скрипты несут для сайта.
• Поиск уязвимостей на основании аналитики сервисов и метрик Google и Яндекс.
• Регулярное проведение тестирования защищенности проекта в целом.
• Использование программы Bug Bounty для выявления новых уязвимостей.
• Интеграция WAF для защиты приложений и эффективного реагирования на проблемы.

Важно постоянно собирать и анализировать данные для выявления новых аномальных кейсов.

Дмитрий Никульчев, DD Planet — о том, как защитить данные пользователей web и mobile сервисов

Безопасное программирование в DD Planet построено на нескольких принципах. Первый из них — это надежность. Работоспособность продукта должна быть предсказуема, корректна и безотказна. Даже в случае, если исходные данные введены некорректно (случайно или намеренно в рамках атаки на продукт).

Второй — безопасность. Возможность защиты от внешних угроз, атак и сохранение работоспособности после их отражения и устранения.

Третий — конфиденциальность. Обеспечение безопасной и корректной работы с персональными данными. Это критически важно при разработке корпоративных и пользовательских приложений.

Например, сервис Живу.РФ, разработкой и поддержкой которого занимается DD Planet, представляет собой приватную социальную сеть для соседей и содержит множество персональных данных. Профиль пользователя подтверждается с помощью Госуслуг, а принадлежность к определенному адресу (соседство) — выпиской ЕГРН из Росреестра. Это накладывает на разработчика серьезные обязательства, связанные с защитой личной информации.

Хранение и обработка пользовательских данных

Все персональные данные мы храним в ИСПДн (Информационной системе персональных данных). Они содержатся в изолированной виртуальной сети с защищенной ИТ-инфраструктурой. В виртуальную сеть интегрированы средства обнаружения вторжений, сервер анализа защищенности и поиска уязвимостей, а также сервер резервного копирования.

Для выявления уязвимостей применяем «ручной подход» и опираемся на экспертный анализ. Данный принцип не подразумевает использование каких-либо автоматизированных средств: исследование проводит опытный специалист, а при выявлении уязвимостей он ориентируется на собственные знания. Понятно, что данный прием влечет большие временные затраты и предполагает наличие в компании специалистов высокой квалификации. Однако он считается самым эффективным с точки зрения точности и полноты охвата данных при проверке.

Severity в борьбе за идеальный продукт

В клиентской разработке важно делать релизы вовремя, при этом приложение должно быть без багов и гарантировать пользователям безопасность. Следуя этому принципу, во время тестирования продуктов мы используем принцип оценивания задач по приоритету — Severity. То есть ранжируем все задачи по устранению багов в зависимости от степени негативного влияния на продукт дефекта.

Приоритетность в устранении багов в DD Planet следующая:

1. В первую очередь мы выявляем и устраняем блокеры или ошибки, при которых у пользователя нет возможности выполнить целевое действие. Например, посетитель не может зарегистрироваться на сайте или в приложении; осуществить вход в аккаунт; получить доступ к целевым данным или к разделам приложения.
2. Далее мы отслеживаем и устраняем критические баги — проблемы безопасности, зависания системы, неправильно работающий бизнес-процесс, периодические падения приложения.
3. Затем анализируем проблемы medium-уровня — находим ошибки, которые появляются лишь в отдельных специфических ситуациях.
4. Завершающим этапом вносим минорные правки — избавляемся от мелких багов, отрабатываем замечания по интерфейсу и так далее.

Такая последовательность помогает нам быстро избавляться от багов, концентрируясь на ключевых для пользователя аспектах.

Релиз продукта происходит в несколько этапов. Сперва он публикуется на тестовом окружении для выявления багов. Затем идёт багфиксинг приоритетов c уровнем Severity 1 и 2. После этого мы делаем релиз на продакшн. В течении некоторого времени после релиза часть команды занимается устранением багов с приоритетностью 3 и 4. Через несколько дней происходит еще одно обновление в prod после устранения оставшихся проблем.

Чтобы обеспечить максимальную безопасность продукта:

• Используйте параметризованные запросы к Базе Данных.
• Избавляйтесь от конструирования запросов внутри приложения, чтобы избежать sql-инъекций.
• Подключайтесь к Базе Данных лишь под специальной заведенной учетной записью с минимально необходимым набором прав.
• Регулярно ведите журналы безопасности.

Не доверяйте пользовательскому вводу: любые данные от клиента (пользователя) должны проверяться на сервере. Это позволит предотвратить прохождение скриптов или злонамеренных шестнадцатеричных кодов. Пользовательские данные часто передаются в качестве параметров для вызова другого кода на сервере и, если их не проверить, могут серьезно нарушить безопасность системы. Вот почему так важно строго проверять все входные данные на корректность.

Андрей Рыжкин и Алексей Клинов из AGIMA — о том, как наладить контроль безопасности мобильных приложений

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

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

• Персональные данные сотрудников и клиентов.
• Данные доступа в банк-клиент.
• Данные о клиентах компании.
• Производственные чертежи.
• Проектная документация.

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

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

К сожалению, секьюрити-анализ все еще редкость для заказной разработки. Причина в уникальности проектов. Все они слишком разные, и у каждого свои потребности. Это влияет на стоимость анализа. Учитывая низкую маржинальность бизнеса, запустить процесс на поток в заказной разработке не всегда возможно. И все же, процессом лучше не пренебрегать.

Как не допустить кражу данных из приложения?

С самого начала разработки мобильного или веб-приложения имеет смысл ввести анализ кода продукта на безопасность. Аспектов здесь очень много:



Только на WAF (файрвол) в плане защиты полагаться нельзя: может не отработать правило, использоваться некорректная конфигурация или устаревшие сигнатуры. Только комплекс мер: применение vulnerability-scanner, pen-test, WAF и DDos Protection обеспечивает безопасность данных приложения.

Далее, когда приложение находится в стадии пред-прода, имеет смысл воспользоваться специализированными сканерами, анализаторами кода и провести pen-test. Это позволит отыскать уязвимости, которые не удалось выявить, анализируя код в процессе разработки.

Как организовать процесс тестирования на уязвимости?

Аудит информационной безопасности нужно проводить еще на стадии захода нового проекта в разработку. При этом важно анализировать технический долг продукта — смотреть на баги и уязвимости. После этого нужно составить роадмап по устранению уязвимостей. Иногда всё удается устранить на первом этапе. Если же проблем много, бороться с ними придется в процессе дальнейшей разработки. Сначала устранять критические, а затем — менее опасные.

Существует несколько подходов к анализу кода:

• Полная интеграция в процессе разработки CI/CD.
• Ревизия безопасности на контрольных точках.
• Ситуационная или разовая ревизия безопасности.
• Учет критериев безопасности и оценка рисков.

Идеальный вариант — интегрировать секьюрити-анализ в ежедневный ревью кода. Такой подход особенно актуален для проектов, которые один и тот же разработчик развивает длительное время.

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

Ситуационную или разовая ревизию имеет смысл запускать, если проект только пришел в разработку или если он достаточно простой.

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

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

Вместо заключения

Сегодня поиск уязвимостей в программных продуктах, мобильных и веб-приложениях становится важным направлением деятельности всех ведущих компаний-разработчиков. Одни считают надежным экспертный анализ уязвимостей и доверяют тестирование внутренним специалистам. Другие используют pen-тесты, сканеры уязвимостей и анализаторы кода. Третьи интегрируют в процесс разработки инструменты SAST. При этом до начала работ рекомендуется строить модели угроз и проводить анализ потенциальных рисков, связанных с кражей и искажением критически значимых данных.

Не стоит полагаться на только на файрволл и бесплатные средства защиты. Надежнее всего — использовать комплексный подход, регулярно и тщательно проверять код на баги и уязвимости.