О чем статья
Рассказываем о внутренней кухне AppSec в Positive Technologies. Какие навыки важны для AppSec-специалиста, а какие можно назвать опциональными? Почему классические практики DevSecOps в нашем случае не всегда применимы? Как «поженить» задачи ИБ, разработки и интересы бизнеса? На эти и другие вопросы отвечают наши AppSec-эксперты.
Для начала расскажите, за какие направления вы отвечаете и чем занимаетесь на работе.
Владимир Кочетков: Я возглавляю направление AppSec и отвечаю за то, чтобы процессы, люди и технологии работали правильно. Код пишу редко, в основном в качестве хобби, зато активно участвую в разработке архитектуры наших продуктов. Например, сейчас занимаюсь компонентной проработкой нашего нового проекта — фаззера прикладного уровня.
Георгий Александрия: Я занимаюсь статическим анализом приложений в разрезе кибербезопасности и разрабатываю ядро JSA для PT Application Inspector (PT AI).
Дмитрий Рассадин: Я работаю в группе экспертизы и исследования безопасности приложений. Изучаем и пробуем новые концепты и advanced-подходы в AppSec. Все это завязано на исходном коде, поэтому сам код, к сожалению или к счастью, все еще пишу. А вообще, мы с Валерием большую часть времени думаем, что бы еще проанализировать…
Валерий Пушкарь: Пишу и анализирую код, изучаю актуальные исследования, плотно взаимодействую со смежными командами, например с отделом развития бизнеса. В части исследований работаю с Димой. Формально не прикреплен ни к одной группе, но душой и сердцем я в JSA :).
Владимир Кочетков: Немного дополню с точки зрения руководителя. Георгий отвечает за разработку ядер PT AI и занимается технологиями анализа приложений в целом. У Валеры душа, может, и лежит к JSA, но, вообще, он техлид всей AppSec-экспертизы. Отвечает за новые исследования и знания, которые заносятся в наши продукты. В свою очередь, Дима — техлид исследовательской группы. Ребята создают ядра AppSec-продуктов и отвечают за их технологическое развитие. Например, недавно они реализовали новый модуль SCA для выявления уязвимых зависимостей.
Какие навыки необходимы для работы в AppSec?
Владимир Кочетков: Отвечу первый, чтобы у ребят была возможность сказать «согласны» :) В первую очередь важна стрессоустойчивость, пусть это и не хард-скилл. Иногда технология, которая, на первый взгляд, кажется идеальной, оказывается неработоспособной из-за мелких, но критичных деталей. Это, мягко говоря, может огорчить. Исследовательская работа строится так, что из десяти решений девять чаще всего летят в корзину. Я, конечно, утрирую, но значительная часть деятельности ресерчеров — отсеивание несостоявшихся или нерентабельных технологий, на изучение которых тратится довольно много времени. Поэтому моральная устойчивость действительно важна.
Теперь к хард-скиллам. Начну с того, что я веду курс по AppSec для разработчиков Positive Technologies и считаю, что им не обязательно владеть предметной областью AppSec, если они с ней не связаны. Чтобы писать безопасный код, не нужно быть хакером или глубоко разбираться в ИБ — достаточно следовать конкретным практикам. Погружаться в предметную область необходимо тем, кто хочет стать разработчиком непосредственно в AppSec. Например, изучать компиляторные технологии, средства анализа кода и т. д. Проще говоря, для разработчиков владение глубокими знаниями в AppSec — опциональный скилл. А вот AppSec-эксперты, которые отвечают за защиту созданных девелоперами продуктов, должны разбираться в разработке. К примеру, в их задачи входит прототипирование новых технологий, а для этого нужно уметь писать код. Исключения бывают, но редко, поэтому почти все наши ключевые AppSec-эксперты — выходцы из разработки, погрузившиеся в область безопасности приложений.
Георгий Александрия: В AppSec важен такой софт-скилл, как недоверчивость: все нужно ставить под сомнение. Даже если перед вами правда за семью печатями, может выясниться, что где-то скрывается восьмая — фальшивая.
Валерий Пушкарь: Согласен: верь всему и не верь ничему. Еще добавлю в копилку софт-скиллов любознательность: что будет, если я суну два пальца в розетку? Без этого в нашей сфере никуда :)
Дмитрий Рассадин: AppSec-специалисты должны уметь и не бояться читать код на разных языках. При этом даже обзорные знания разных технологических стеков для них зачастую важнее, чем для разработчиков. Почему? Разработчиков в компании обычно куда больше, чем AppSec-специалистов. Например, в «Яндексе», по слухам, на десять тысяч человек одно время приходилась всего пара десятков AppSec-инженеров, и они достойно справлялись. Также важно умение ставить себя на место потенциального злоумышленника, который к тому же внезапно получил доступ ко всему коду (как и вы сами). Что он мог бы сделать, имея полное представление об обработке внешних событий и трансформации входящих данных?
Георгий Александрия: Соглашусь, чтение кода на разных языках — востребованный навык. Например, он нужен для изучения и анализа используемых в компании библиотек и фреймворков на наличие слабостей, закладок, уязвимостей и всего прочего.
Наш продуктовый тезис звучит так: многих специалистов в значительной степени можно заменить технологиями. В том объеме, в котором сейчас ощущается потребность на рынке, люди на самом деле не нужны — по крайней мере в области разработки защищенного кода.
Как в вашей команде выстроены рабочие процессы?
Владимир Кочетков: Помните мультфильм про обезьянку и ее детей? Так вот, обезьянка — это я, а маленькие обезьянки — они :)
Георгий Александрия: К нам поступают задачи из разных источников: клиенты, руководство, смежные продукты, экспертиза, также есть внутренние запросы команды. Мы анализируем их, расставляем приоритеты и планируем объем работ. Далее декомпозируем и распределяем задачи: часть уходит в разработку, часть — в экспертизу, часть — в смежные отделы. В рамках разработки могут поступать разного рода уточнения по задачам. В зависимости от степени уточнений либо адаптируем их, либо пересматриваем задачи и объем работ в целом.
Владимир Кочетков: Помню, мой предыдущий руководитель однажды поставил задачу: «Сделай анализатор JavaScript так, чтобы мне понравилось». И все — никаких больше требований! Но самое интересное: в итоге ему понравилось, значит, это возможно :)
Конечно, изначально любая задача растет из продуктовых требований, запросов клиентов и т. д., но в целом у нас достаточно свободы. Ожидается, что исполнитель сам предложит варианты и поможет выбрать подходящий. Приведу пример: сейчас мы пытаемся научить уже упомянутый модуль JSA работать с произвольными моделями угроз. Благодаря этому пользователи смогут корректировать модели с учетом специфики конкретного проекта. Это важно как для клиентов компании, так и для проектов наших коллег, например PT NAD. Кроме того, эта функциональность нужна для создания единой AppSec-платформы, которая будет покрывать весь жизненный цикл приложения. Недавно мы обсуждали, как решить эту задачу: специально встретились в Питере, чтобы все согласовать, и провели пару часов с маркерами за доской. На той же встрече обсуждалось использование в продукте языка DSL (нужен для описания правил поиска уязвимостей в коде). Тема не новая, но сейчас без нее сложно конкурировать на рынке. Я играл роль пользователя без навыков программирования, но с экспертизой в AppSec. Ребята предлагали варианты решения задачи, мы выбрали лучший и сейчас реализуем.
Дмитрий Рассадин: В текущем виде наша команда достаточно много времени обсуждает свежие технологии, актуальные уязвимости и новые способы их эксплуатации. Порой тема для нового исследования приходит из какой-нибудь статьи или выступления на хакерской конференции. Также мы поддерживаем регулярные контакты с группой разработки, благо работаем бок о бок уже много лет и всегда готовы помочь друг другу.
Две практики, которые в каком-то смысле «делают нашу команду», если использовать кальку с английского:
- Так называемые технички (чуть подзаглохли, но обязательно возродим). По сути, это двухчасовые созвоны всей командой, во время которых мы брейнштормим на заданную тему. Их любят все, потому что это не только интересно, но и продуктивно: на выходе мы получаем решения конкретных технических задач.
- Пятничные митапы с докладами на самые разные темы. Дима, например, рассказывал, как правильно использовать в работе Joern — сторонний анализатор кода, а другой наш коллега объяснял всем основы биоинформатики.
Какие инструменты вы используете в работе?
Георгий Александрия: Попробую выделить следующие категории:
- Инструменты для анализа скомпилированных и исполняемых файлов. Сюда входят декомпиляторы и дизассемблеры, которые позволяют читать и анализировать работу программ на уровне бинарного кода.
- Инструменты для анализа, фильтрации и обработки трафика сети. Это и файрволлы, и снифферы, и утилиты для отправки. Например, wireshark, curl или аналоги.
- Инструменты для разработки и тестирования приложений. Сюда относятся различные общеизвестные интегрированные среды разработки и контейнеризаторы приложений.
- Инструменты для коммуникации и управления задачами.
- Инструменты для анализа активностей системы и запущенных в ней процессов с целью выявления аномальных поведений.
- Инструменты виртуализации и использования протоколов передачи данных.
Дмитрий Рассадин: А еще мы пользуемся LLM :) В основном используем Python, Go, C# и Rust, а при завершении работы над РОС особое внимание уделяем профилировщикам: нам важно оценить, оптимально ли работает предлагаемая технология и нет ли там заложенных проблем by design (наш design :) ), которые аукнутся в будущем.
Отмечу, что на этапе прототипирования мы часто пользуемся решениями Open Source для быстрой проверки гипотез. Но в дальнейшем стараемся заменять неэффективные открытые инструменты на самописные. Сейчас, например, пишем собственные компоненты для работы с базой уязвимых фидов. Они не только работают корректнее и быстрее, чем Open Source аналоги, но и гораздо проще масштабируются под наши новые нужды.
Владимир Кочетков: Приведу еще один пример. В начале 2024 г. перед нами встала задача обрабатывать трендовые CVE и интегрировать их в наши AppSec-продукты, как это делается в NAD, VM или SIEM. В итоге мы написали собственный инструмент. Он не только реализует нужный нам процесс обработки CVE, но и позволяет формировать фид для нашего SCA-продукта именно в том виде, в котором становится возможной интеграция средств SAST и SCA.
Георгий Александрия: Бывают и обратные примеры, когда разрабатываем собственные прототипы, а после заменяем их готовыми решениями. Например, у нас была своя система верификации и выводимости логических условий, но позже мы отказались от нее в пользу Open Source решения.
Владимир Кочетков: Перевожу: они нагло выкинули код, большую часть которого написали мы с коллегой, и перешли на Open Source. Это было грустно, хотя, если убрать мой код из продукта, это, как правило, идет ему в плюс, а не в минус :)
Валерий Пушкарь: Хорошо, что ты сам это озвучил :)
Продолжая тему Open Source: насколько в AppSec принято контрибьютить? Вы делитесь экспертизой с сообществом?
Владимир Кочетков: Экспертиза — главная ценность большинства наших продуктов, особенно PT BlackBox и PT AI. Если будем открыто ей делиться в полном объеме, то потеряем конкурентное преимущество.
Что касается участия в Open Source, строгой политики нет: каждый решает сам. Были случаи, когда мы успешно дорабатывали открытые решения, но после того, как GitHub начал блокировать нам аккаунты из-за санкций, желание активно контрибьютить лично у меня пропало.
Дмитрий Рассадин: Иногда мы дорабатывали Open Source инструменты, потом уставали их поддерживать и начинали разрабатывать свои. Вместо улучшения чужого продукта мы создаем свой — более стабильный и функциональный. Потенциально это тоже контрибьют. В целом вопросы о размещении наших разработок в открытом доступе всегда обсуждаются на уровне руководства. А вообще, за последний год наши Pull Request появились в нескольких популярных средствах работы с кодом, которыми пользуются значительное число участников международного ИБ-коммьюнити.
Георгий Александрия: В целом — да. Однако если политика Open Source проекта и наше видение не совпадают (что выражается в отказе от принятия правок), мы стараемся избегать лишних претензий: если позволяет лицензирование, дублируем проекты и развиваем их самостоятельно, иначе — ищем аналоги.
Как «поженить» задачи ИБ, разработки и интересы бизнеса?
Владимир Кочетков: Самый простой способ навести мосты с бизнесом — сходить в бар, но в нашем случае по ряду причин популярностью пользуются кальянные. Однажды в Питере ребята так спорили, что исписали всю салфетку формулами и схемами по теории графов :)
Георгий Александрия: Давайте не будем вспоминать в деталях…
Владимир Кочетков: А если серьезно, все конфликты решаются по классической схеме: садимся, обсуждаем проблему, находим компромисс. Например, одна крупная российская компания попросила нас раскрыть все фолз-позитивы в PT AI, чтобы их стажеры могли во всем этом поковыряться. По сути, они хотели «видеть всю плоскость атаки», но мы убедили их в том, что разгребать десятки тысяч фолзов — неподъемный труд.
«Интуиция и мастерство!»
На каких этапах разработки вы обычно подключаетесь к проектам?
Георгий Александрия: Зависит от продукта и конкретной ситуации. Иногда на старте, чтобы продумать архитектуру: сценарии воздействия, взаимодействия, разбиение на подмодули и подкомпоненты. Потом распределяем задачи и начинаем разработку. Бывает и наоборот: архитектура уже придумана, роли распределены, а мы подключаемся непосредственно к разработке. Это равновероятные истории, выходит примерно 50 на 50.
Валерий Пушкарь: Бывают и «организационные» проекты. Как-то у нас появилась молодая команда, которая должна была разработать легковесный анализатор для проверки одной гипотезы. Мы не планировали его продавать, это была, скорее, экспериментальная работа. Позже проект было решено временно использовать для поддержки языка смарт-контрактов Solidity, но, поскольку команда была новая, им потребовалась помощь. Моя задача состояла в том, чтобы быстро наладить межпроцессное взаимодействие между ядром и контрольной частью системы. Пришлось включиться, оперативно решить проблему и сопроводить анализатор в продакшн.
Владимир Кочетков: Как это выглядело с моей стороны. Смотрю на код и вижу: здесь писал джун, здесь уже миддл, и вдруг… узнаю стиль Валеры. Думаю: стоп, а что здесь делает Валера? :)
Валерий Пушкарь: У меня прям слеза навернулась! Как говорится, великие художники не копируют, а воруют...
Какие общепринятые практики безопасной разработки вы используете, а какие нет?
Владимир Кочетков: В целом мы приветствуем все практики, которые соответствуют здравому смыслу. Лучше приведу пример того, что категорически отрицаю: «hack yourself first». В чем идея: каждую пятницу разработчик вместо написания кода должен пробовать взломать собственное приложение. Звучит, конечно, интересно, но это порочная практика. В чем смысл имитировать действия хакера с навыками атаки, как у среднестатистического разработчика (то есть примерно никакими)? Более того, чтобы человек нашел хотя бы пару уязвимостей, его нужно сначала этому научить — выдернуть из рабочего процесса и заставить заниматься чужими задачами. Я категорически против: разработчик должен писать безопасный код, а не примерять на себя роль хакера.
Георгий Александрия: Мы используем общепринятые практики DevOps в части разработки и исследований. Тем не менее в рамки стандартного DevSecOps мы не совсем вписываемся, поэтому типовые практики редко подходят, за исключением непрерывного использования инструментов SAST и DAST. В основном мы опираемся на экспертизу и ручное ревью. А вообще, есть знаменитая фраза знаменитого профессора Фортрана: «Нормально делай — нормально будет» :)
Валерий Пушкарь: Интуиция и мастерство!
Дмитрий Рассадин: Однако мы все же используем типовые инструменты. Например, сканируем наши разработки с помощью плагинов IDE, в том числе PT AI. Но большая часть вопросов, связанных с безопасностью кода, решается на этапе ревью. Также следим за непопаданием критичных файлов в наши репозитории и отучаемся отправлять приватные данные даже через корпоративный мессенджер: недавно коллеги как раз развернули сервис, позволяющий безопасно обмениваться подобной информацией.
Владимир Кочетков: Не могу не добавить, что ревью с Георгием — это отдельное удовольствие :) Однажды мы обменялись 120 комментариями, в которых спорили даже не о безопасности, а о корректном использовании механизмов языка…
И последний вопрос: вы часто сталкиваетесь с серьезными проблемами безопасности?
Владимир Кочетков: Я начинал в команде анализа защищенности веб-приложений и могу сказать, что, с хакерской точки зрения, наши ребята умеют писать безопасный код. Причем это получается естественно, а не потому, что они все поголовно хакеры и по пятницам взламывают свои продукты:) Так что критичные проблемы возникают крайне редко. Конечно, бывают ошибки и даже архитектурные просчеты, но они не приводят к уязвимостям вроде RCE или обхода прав. Максимум, что случалось, — это DOS-условия и использование уязвимых компонентов.
Георгий Александрия: При анализе кода различных сторонних приложений как средствами автоматического анализа, так и ручного часто выявляются проблемы безопасности разных уровней — от захардкоженных паролей до серьезных RCE. Возвращаясь к упомянутому DOS, был интересный кейс, когда нам пришлось целенаправленно добавить в архитектуру продукта коллизию хешей, которая может привести к HashDOS. Придется, конечно, очень сильно повозиться, однако в теории это возможно. Мы даже думали оставить пасхалку: если нашел, напиши нам — и ты в команде.
Владимир Кочетков: «И ты в команде!» Да, все так и было, но потом этот код попал под оптимизацию…
