Как защитить приложение на стадии его разработки

Просмотров: 1816
Автор:
Бубнов Михаил

Бубнов Михаил

Директор по развитию продуктов — Attack Killer

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

С другой стороны, происходит существенное сокращение инвестиций в разработку софта: по данным «Руссофта», за год (2017/2016) внешние инвестиции в вендоров ПО в России сократились в 4 раза. Как часто бывает, все это, в первую очередь, отражается на безопасности. Меньше времени и ресурсов — меньше возможностей проводить детальные тесты на наличие уязвимостей. Такая же картина наблюдается и во внутренней разработке компаний, только здесь все осложняется специфическими угрозами и наличием множества несистемных требований к безопасности.

Не лучше дела обстоят и с устранением уже обнаруженных уязвимостей. Согласно октябрьскому отчету CA Veracode, около 70% брешей в программном коде приложений остаются незакрытыми в течение месяца — а более половины не «патчатся» и за три месяца. Происходит это по тем же причинам: у разработчиков есть ресурсы только на самые критичные уязвимости, и не хватает даже на «дыры» со средним приоритетом. 

Что попадает под удар?

Первый объект атак на приложения, разработанные для сторонних заказчиков — финансовые, персональные, медицинские и другие данные пользователей. За последние годы накопилось много примеров успешных атак, которые приводят к компрометации миллионов записей: так было в 2014 году с Yahoo (3 млрд. пользовательских аккаунтов), в 2015 — со страховой компанией Anthem (79 млн. записей, включая адреса и номера социального страхования), в 2016 аналогичная ситуация произошла с  Uber («утекли» персданные 57 млн. клиентов и 600 тыс. водителей), в 2017 — с бюро кредитных историй Equifax. В 2018 году печально «прославился» Московский метрополитен: уязвимость сервиса бесплатного Wi-Fi более года позволяла получать телефонные номера всех его пользователей – скомпрометированными оказались 12 миллионов номеров и «цифровых портретов» пассажиров.

Все эти примеры — лишь то, что всплывает в СМИ. Тысячи атак на небольшие компании и приложения не доходят до читателей, оставаясь головной болью разработчиков и их клиентов, в том числе бизнес-пользователей. Атаки грозят простоями для бизнеса, потерей репутации и даже прямыми финансовыми убытками — ведь их целью часто становятся счета и данные банковских карт.
У внутренней разработки свои, специфические угрозы. Здесь под ударом оказывается, в первую очередь, корпоративная информация компании, в том числе коммерческая тайна. Специфика в том, что приложения «пишутся» для себя. Служба информационной безопасности не участвует в этом процессе, а разбирается с последствиями постфактум.

Но для любого разработчика, внутреннего или внешнего, бреши в коде — это еще и потери во времени. Несколько лет назад мы посчитали, сколько времени для исправления какого-либо бага или ошибки в программном обеспечении может быть потрачено на разных стадиях его разработки и внедрения. В этом расчете мы учитывали время на поиск бреши, анализ его критичности, выпуск «патча», тестирование, все согласования и доставку пользователям. И разница между тем, чтобы найти ошибку на стадии разработки или после внедрения ее заказчику, отличается на 2 порядка – то есть в более, чем в 100 раз. 

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

Как встроить защиту в разработку?

Логика работы автоматизированных средств защиты проста: если нет времени проверять приложение или обновление перед выпуском, значит, нужно встроить поиск ошибок прямо в жизненный цикл разработки (он же SDLC — Software development lifecycle). Для этого существуют сканеры, которые находят в коде уязвимости любой природы: вызванные обычными ошибками, плохим знанием языка программирования или преднамеренным желанием оставить «закладку» и впоследствии использовать ее. 

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

Основной плюс автоматизированных сканеров – скорость их работы. Они, в отличие от человека, «помнят» абсолютно все заданные алгоритмы и хранят знания о проблемах, ошибках и уязвимостях. Второе преимущество – возрастающая экономия. В моей личной практике был пример: с одним из заказчиков мы подсчитали экономию от внедрения автоматизированной системы проверки кода. Получилось, что в год можно сэкономить до 4 млн. рублей просто на времени сотрудников: 2 млн. строк исходного текста машина обсчитает за 1 час, а человеку на это понадобится минимум 2 недели. 
Сканер работает по заданному алгоритму, и если он ищет определенного рода конструкцию в исходных файлах, то находит ее со стопроцентной вероятностью. Если параметры заданы нечетко (такое тоже бывает), то она находит все подозрительные фрагменты и сообщает, что результат требует перепроверки. 

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

Но и со сканерами все непросто: разные виды построены по разным принципам, у каждого из которых плюсы и минусы.

Какие бывают сканеры?

Сейчас их три вида: статические, динамические и интерактивные.

Статический сканер (англ. SAST – Static Application Security Testing) – инструмент, который формирует гипотезы о наличии в коде ошибок. Он не оперирует данными о последствиях каждой конкретной ошибки, поэтому и не может проверить гипотезу. Иными словами, SAST не сможет определить реальную угрозу, если подобной ошибки нет в базе знаний. Из-за этого статические сканеры могут давать значительное количество как ложно-положительных, так и ложно-отрицательных результатов: проще говоря, как «подсвечивать» качественные фрагменты кода, так и пропускать уязвимости. 

Динамический сканер (англ. DAST – Dynamic Application Security Testing) работает по принципу так называемого «черного ящика»: тестирует запущенные приложения, проверяя реакцию системы на разные вводные. В результате DAST находит совершенно конкретные, эксплуатируемые уязвимости с понятными последствиями — и, если бы не проверка сканером и последующее исправление, их впоследствии обязательно обнаружили бы злоумышленники. 

Здорово? Да, но есть один минус: чтобы «отработать» все варианты входящих запросов, приходится проводить множество тестов — а это серьезно нагружает систему и требует довольно много времени.

Поэтому появился третий вид сканеров — интерактивный, IAST. Такие сканеры совмещают в себе и быстродействие SAST, и точность DAST. Иными словами, внутри интерактивного сканера реализован алгоритм (или «агент», как его часто называют), который собирает и анализирует данные от запущенного приложения. То есть в результате статического анализа формируется набор данных и шаблонов, а потом динамическим анализом выполняется тестирование по этим наборам. В сложных ситуациях решение принимает человек.

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

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

Комментарии (0)

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.