Дмитрий Шмойлов, Kaspersky: О безопасной разработке и о том, как она строится

О важности взращивания собственных лидеров безопасности (Security Champions), проблемах выявления и устранения уязвимостей, а также плюсах и минусах открытого кода нам рассказал руководитель отдела безопасности программного обеспечения «Лаборатории Касперского» Дмитрий Шмойлов.

«Лаборатория Касперского» уделяет большое внимание безопасности своих продуктов: статус обязывает. Расскажите немного об основных направлениях работы вашего отдела. Из чего состоит процесс безопасной разработки в вашей компании?

Д. Ш.: В «Лаборатории Касперского» реализованы все основные практики, такие как обучение правилам безопасной разработки, управление требованиями по безопасности, моделирование угроз, проведение тестирований (SAST, DAST, фаззинг и так далее), композиционный анализ, управление уязвимостями в продуктах и сторонних библиотеках, ведётся программа вознаграждений (Bug Bounty). Наше подразделение продуктовой безопасности отвечает за цикл безопасной разработки (SDL) внутри «Лаборатории Касперского» и является центром компетенций по продуктовой безопасности.

В «Лаборатории Касперского» довольно давно внедрён институт ИБ-лидеров (Security Champions) как механизм горизонтального масштабирования безопасной разработки. Такая роль есть в любой команде, которая выпускает коммерческий продукт.

Если разделить цикл SDL на классические этапы, все ли они реализовываются в полной мере в вашей компании?

Д. Ш.: Да, все практики выполняются. Однако и планов по развитию и усовершенствованию также много. Давайте пройдёмся по этапам SDL и тому, как они реализованы у нас в компании, по порядку.

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

В «Лаборатории Касперского» мы активно занимаемся управлением требованиями по безопасности для наших приложений, следуя исторически сложившейся практике контроля изменений в программном обеспечении. Одной из ключевых команд в этом процессе является команда по продуктовой безопасности, которая занимается разработкой, формулированием и систематизацией требований для наших продуктов, а также проверкой результатов. Мы стремимся к тому, чтобы все вопросы безопасности были чётко учтены в официальных требованиях. Кроме того, мы обязательно проверяем выполнение этих требований, часто используя автоматизированные методы для повышения эффективности этого процесса.

На этапе дизайна Security Champions проводят работы под контролем архитекторов из команды продуктовой безопасности. На этом этапе также проводятся моделирование угроз и работа с рисками по этим моделям, приоритизация дополнительных доработок продукта с точки зрения безопасности и так далее. Здесь же определяются модули, необходимые для проведения расширенного тестирования.

На последующих этапах идёт процесс имплементации, в котором широко применяется инструментарий статического и динамического анализа. Следует отметить, что среди инструментов динамического анализа используются как сторонние решения, так и собственные разработки. Кроме того, применяются и другие методы тестирования: фаззинг, композиционный анализ (SCA) и др. На этапах имплементации особенно справедлива поговорка «много тестов не бывает». Благодаря внедрению технологии монорепозитория и увеличению числа автоматических тестирований удаётся сдвигать действия по обеспечению безопасности на более ранние стадии разработки. Это распространяется как на статический анализ кода (SAST), так и на динамический анализ (DAST), а также на анализ безопасности открытого кода (SCA).

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

Если разработка «проспала» какую-то ошибку и она выявлена на последних этапах, то цена её исправления взлетает на порядки по сравнению с первыми этапами. Вы это замечаете на своём собственном опыте?

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

На вашей практике получается ли всё это действительно подсчитать и сделать из этого историю о самоокупаемости DevSecOps, чтобы презентовать руководству и сказать «мы экономим деньги компании»?

Д. Ш.: Общий ответ — да. На ранних этапах развития «Лаборатории Касперского», когда мы только налаживали процессы безопасной разработки, руководство осознавало важность инвестиций в безопасность благодаря нашим подсчётам издержек и временных затрат. Однако сейчас для многих разработчиков безопасность стала неотъемлемой частью качества продукта. Многие процессы, такие как тестирование, разработка безопасной архитектуры и дополнительные автоматизированные тесты, стали стандартом и включены в обязательный набор работ. Эти меры, по сути, являются частью системы контроля качества (quality gate). Как уже отмечалось, исправление проблем, которые были обнаружены на поздних стадиях разработки, обходится гораздо дороже.

Всё больше команд смотрят на SDL не как на чистую безопасность, а как на элемент общего качества.

Насколько лучше стала ситуация с уязвимостями по мере внедрения практик SDL и выхода нескольких релизов? Есть ли тут какие-то наблюдения?

Д. Ш.: По вопросу о снижении уязвимостей можно сказать, что ситуация неоднозначна. После внедрения процессов разработки безопасного программного обеспечения мы начали активнее обнаруживать и устранять потенциальные проблемы сами благодаря инструментам безопасности и дополнительным тестам. Если смотреть на число обнаруженных на ранних этапах багов (как метрику), оно, наоборот, увеличилось. Кроме того, мы запустили программу Bug Bounty и начали получать от сторонних исследователей отчёты о потенциальных уязвимостях, которые в обязательном порядке обрабатывали.

Первым показателем успеха на этапе внедрения SDL было сокращение количества критических уязвимостей. Мы внесли изменения в архитектуру, тщательно просматривали потенциально опасные участки кода, увеличивали время и внимание, уделяемые их тестированию, а также внедрили фаззинг-тестирование «на потоке» для достижения успеха.

Мы закупали целые «железные» фермы, с использованием которых тесты безопасности ищут проблемы в коде. Все эти мероприятия принесли свои плоды.

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

Мы уже обсуждали, насколько важно растить ИБ-лидеров (Security Champions) в командах разработчиков. Однако зачастую не очень понятно, как их стимулировать. Каким образом вы решаете задачу по мотивации этих людей, чтобы они действительно были вовлечены в процесс и стали «рупором» вашего отдела при разработке отдельных продуктов?

Д. Ш.: Внедрение роли Security Сhampions — это основной механизм для масштабирования безопасности в десятки и сотни команд разработки. Несмотря на то что многие высказывают сомнения в эффективности этого подхода, наш опыт показывает, что именно таким образом можно привить культуру безопасности в широком масштабе внутри команд разработки. Мотивация Security Champions очень близка к мотивации разработчика / архитектора: они заинтересованы в выполнении интересных задач и возможности качественно выполнять свою работу. Security Champion — зрелый сотрудник разработки со знаниями и интересами в области безопасности. У такого рода людей есть мотивация делать свой продукт хорошо, так как именно от этого зависит его качество с точки зрения безопасности.

По большому счёту, это задача с тегом «вызов» — сделать хорошо с точки зрения безопасности.

В «Лаборатории Касперского» мы даже создали объединения Security Champions в рамках стека технологий. Мы наглядно видим, что они начинают закрывать вопросы безопасности самостоятельно (и даже более эффективно) благодаря своему глубокому знанию предметной области, а также коллаборации в рамках стека технологий.

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

Получается, что у этого человека есть квота времени и часть его ресурсов уже зарезервирована под безопасность?

Д. Ш.: Да, именно так. Для него это означает, что ему поручают дополнительные задачи, однако компенсация времени предусмотрена: он может делегировать часть своих «обычных» обязанностей другим коллегам. Хотя этот процесс не происходит мгновенно, со временем он выравнивается.

Есть ли у таких сотрудников ответственность за свою работу и должна ли она быть в принципе? Условно говоря, если они что-то упустили, можно ли с них спрашивать?

Д. Ш.: Да, конечно, однако нужно подходить к этому вопросу внимательно, учитывая различные обстоятельства каждого инцидента. В случае обнаружения проблемы безопасности (security issue) мы вовлекаем ответственного «чемпиона», вместе анализируем причины инцидента, устраняем проблему и внедряем меры для предотвращения подобных ситуаций в будущем. Также анализируем, в каких ещё местах возможны подобные проблемы.

Хотел бы ещё поспрашивать о Bug Bounty. Насколько эта программа для вас эффективна?

Д. Ш.: Когда мы только начинали работать с программой Bug Bounty, у нас были высокие ожидания относительно количества и, самое главное, качества отчётов. Они не полностью оправдались, но со временем мы осознали, что это вполне нормально. Наша программа охватывает десктоп-приложения, и порог вхождения в такую область для исследователей значительно выше. В основном на платформах Bug Bounty исследователи заинтересованы в анализе веб-приложений и инфраструктуры. В то же время число исследователей, которые занимаются десктоп-приложениями, меньше, и это одна из причин, по которым обнаруженных проблем в десктоп-приложениях у нас тоже меньше.

В целом Bug Bounty — это очень хорошая практика: она стимулирует людей делать безопасную функциональность, так как «за тобой следят тысячи глаз». Это способ повышения внутренней культуры по безопасности.

Исследователи иногда приносят ошибки, до которых мы сами не добираемся, так как очень велика вариативность сценариев работы выпускаемого ПО. Иногда они смотрят на функциональность под другим углом и показывают сценарии, которых мы могли не заметить (и, соответственно, не писать по ним тестов). Это и есть та самая изюминка, ради которой делается Bug Bounty.

Где размещена ваша программа Bug Bounty?

Д. Ш.: Мы находимся сейчас на площадке под названием Yogosha.

Хотел бы ещё уточнить кое-что об открытости разработки. «Лаборатория Касперского» многое делает для того, чтобы быть прозрачнее для своих клиентов. В какой мере эта открытость связана с безопасностью?

Д. Ш.: Вопросы безопасности — всегда про доверие, особенно для тех продуктов, которые обеспечивают защиту. Доверие клиентов — это очень важный аспект. У нас более десяти центров прозрачности по всему миру, которые расположены в Европе, Азиатско-Тихоокеанском регионе, Северной и Латинской Америке, на Ближнем Востоке и с недавних пор в Африке. Там мы рассказываем про свои технологии, о том, как они работают, показываем всё на примерах. Мы также рассказываем о работе наших внутренних сервисов, показываем результаты прохождения добровольной сертификации по безопасности, в том числе международной (результаты аудитов SOC2, ISO 27001, IEC 62443-4-1). В «Лаборатории Касперского» мы, проходя аудиты, показываем, что не только продукт защищён, но и вся экосистема работает в соответствии с ожиданиями заказчика с точки зрения безопасности. Это повышает степень доверия к нам как вендору и партнёру.

Какие инициативы в области безопасной разработки вы активно поддерживаете в настоящее время и каким образом ваша компания участвует в разработке соответствующих стандартов и документации?

Д. Ш.: Мы активно участвуем в создании новой редакции ГОСТа по безопасной разработке (ГОСТ 56939). Сейчас он проходит общественное обсуждение. Но мы этим не ограничиваемся и принимаем участие в разработке и других документов по безопасности.

Считаете ли вы, что открытый исходный код (Open Source) — это безопасно?

Д. Ш.: Немного не так. Открытый код — это, конечно, хорошо. Но не стоит питать иллюзий, что весь Open Source, который смотрели тысячи глаз, — чистый и хороший. В реальности есть много примеров того, что это не так. Наши исследования (четыре вредоносных пакета в репозитории npm, невидимые закладки в исходном коде, в популярный JavaScript-пакет UAParser.js внедрили зловреда и так далее) показывают, что в опенсорсных компонентах исходного кода встречаются в том числе и модули с откровенно злонамеренной направленностью, а также другие риски. «Лаборатория Касперского» следит за такими пакетами и предоставляет свою экспертизу в виде решения Kaspersky Open Source Software Threats Data Feed.

А как вы видите будущее развитие безопасной разработки в вашей компании?

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

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

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

Мы стараемся сделать так, чтобы встраивание безопасности в разработку всё больше сдвигалось влево (Shift Left). Раньше разработчик мог сказать, что он пишет код, а тестированием не занимается. Сейчас — вполне нормальная практика, когда разработчик пишет код и сам же на него пишет тесты. Это повышает общее качество продукта с точки зрения не только безопасности и функциональности, но и других нефункциональных вещей, таких как безопасность, производительность, стабильность. Повышение этой зрелости — тренд, к которому мы в конечном итоге придём.

В одном из эфиров AM Live обсуждался вопрос, должно ли быть у безопасников право вето на релиз продукта c уязвимостями. Правильно ли я понимаю, что в вашем случае это именно так и с багами продукт не выходит?

Д. Ш.: Да, механизм принятия решения о качестве релиза построен так, что есть несколько подразделений, которые могут наложить вето, если продукт не соответствует их критериям качества. Наше подразделение также участвует в этом процессе. При этом в «Лаборатории Касперского» выстроен баланс интересов на основе рисковой модели. Поэтому, хотя у нас есть право вето, его использование требует обдуманности и сбалансированности. В большинстве случаев все вопросы безопасности удаётся решить до релиза, и за это мы благодарны всем командам разработки внутри «Лаборатории Касперского».

Спасибо за беседу! Желаем новых успехов вам и команде!