Как обеспечить безопасность разработки, сохранив время и нервы

Источник: habr.com

Переход в 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 (файрвол) в плане защиты полагаться нельзя: может не отработать правило, использоваться некорректная конфигурация или устаревшие сигнатуры. Только комплекс мер: применение статического анализа исходного кода в процессе разработки, инструментальный анализ в боевой среде, pen-test, WAF и защита от DDoS — поможет обеспечить высокий уровень безопасности приложения.
Инструментальные сканеры и pen-test, позволят обнаружить уязвимости, которые не удалось выявить, анализируя код в процессе разработки.

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

В AGIMA реализовано несколько подходов к анализу кода на безопасность:

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

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

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

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

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

Результатом секьюрити-анализа внедренного на ранних стадиях разработки, становится:

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

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

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

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