Расписание

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

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

Рассмотрим MITRE ATLAS на кейсах безопасности ML-систем.

Участники обсудят:

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

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

На помощь для решения задачи приходит инструментарий профилирования, подписи и применения созданных профилей для защиты ПО от подмены и иных воздействий.

На реальных примерах разберем различные ошибки бизнес-логики и как их можно было избежать.

Разберем основные виды уязвимостей приложений на базе LLM и обсудим, как им противостоять.

Безопасность в цепочках поставок (supply chain) — это важная проблема, где самое слабое звено — open source-зависимости. Для эффективного противостояния подобным уязвимостям необходимо разбираться в современных методах и тактиках злоумышленников, а также быть в курсе актуальных стандартов безопасности в этой области.

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

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

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

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

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

Рассмотрим эволюцию требований к безопасности приложений и разработки, размножение стандартов на примерах OWASP, PCI SSC и инициативах коммерческих компаний, проблематику использования стандартов, или какую проблему не снимают документы. Также обсудим, куда движется отечественная практика, и как это может накладываться на универсальную модель.

Как спроектировать сервис аутентификации и все учесть.

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

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

Актуальность защиты моделей ML при анализе трафика. Поверхности атаки. Среды исполнения моделей и их уязвимость. Способы защиты. Выбор компонентов для реализации моделей ML.

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

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

Почему безопасность мобилок, если не на первом месте, то должна быть вровень с серверной частью системы?

Как открыть YouTube в банковском приложении? Как украсть внутренние файлы из приложения без взаимодействия с пользователем? Как обойти биометрическую аутентификацию? Почему компоненты с secure в имени самые уязвимые?

Обо всем этом и о способах защиты поговорим во время доклада. Будет интересно и увлекательно!

Поговорим о том, почему динамический и статический анализ в ядре сложнее, чем в user space, а фаззинг становится проблемой уровня мироздания. Обсудим, как в «ядреной» безопасности нам помогают разработчики процессоров.

Сделаю обзор существующих форматов, схем и баз для агрегации уязвимостей. Расскажу про свой опыт участия в создании очередного формата для представления и хранения уязвимостей COSV и создания подобного архива, который стал официальным стандартом у China Computing Federation (CCF).

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

Внедрение процессов сканирования Docker-образов на уязвимости в CI/CD. Процесс позволяет сканировать контейнерные образы до их развертывания в окружении. Уязвимости будут обнаружены на ранних этапах разработки, что предотвратит их попадание в продуктовую среду, а ошибки не будут иметь фатальных последствий ни для финансов, ни для репутации компании.

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

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

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

Плагины для SAST-анализа кода на уязвимости в IntelliJ IDEA и VSCode и обработка результатов анализа. Расширения базы знаний анализатора за счет написания скриптов с помощью плагина-редактора, поддерживающего IntelliSense.

Расскажу, какие функции защиты обычно возлагают на web application firewall; можно ли реализовать защиту другими средствами; какие типовые схемы защиты мобильных и веб-приложений встречались в ходе работ в различных организациях.

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

Рассмотрим ключевую роль PolicyEngine в обеспечении безопасности Kubernetes-кластеров. Покажу, что потенциал Kyverno простирается далеко за базовые сценарии использования, открывая практически безграничные возможности, зависящие от креативности и фантазии пользователя.

Изучаем уязвимости в процессе MLOps: от рисков в данных и коде до проблем в продакшене, а также обсуждаем методы защиты для обеспечения безопасности AI-систем. Анализируем, как можно использовать white box- и black box-подходы для обнаружения и эксплуатации уязвимостей, и рассматриваем стратегии пост-эксплуатации и защиты данных.

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

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

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

Большинство организаций приходит к необходимости внедрения лучших практик по безопасности в командах разработки независимо от того, что послужило причиной — изучение лучших практик, опыт коллег или дефицит ресурсов ИБ. Это, как и большинство инициатив лучших практик, продвигается как аксиома, но действительно ли есть эффект и польза от СекЧемпов (security-чемпионов)? Или это все инфоцыганство?

Обсудим, как построить CI/CD-конвейер с нуля, почему Sec сегодня — неотъемлемая часть DevOps и какие инструменты помогут быстро перейти к DevSecOps. Разберемся, какие из решений сегодня доступны на российском рынке и попробуем понять, нужен ли вам DevSecOps по ГОСТу Р. А еще обсудим AI в DevSecOps и сравним актуальные решения для анализа кода (SAST) и проверки уязвимостей в подключаемых библиотеках (SCA).

На примере работы с платформой CodeScoring рассмотрим вопросы построения SBOM (software bill of materials), эффективной работы с графом зависимостей и уязвимостей. Рассмотрим варианты настройки политик для сокращения трудоемкости анализа open source-компонентов.

Как выстроить полноценный контроль безопасности приложений ключевыми методами анализа кода (SAST, DAST, SCA, SCS) без внедрения разрозненных инструментов.

Доклад о том, какой ценой нам удалось собрать воедино маршрутизацию nginx, Envoy, API gateways и микросервисов, получив на выходе инструмент для управления ассетами API. Обсудим, какую пользу он смог принести.

Разберем, как в СберМаркете внедрили практики безопасной разработки и заинтересовали разработчиков участвовать в этих практиках. Обратим внимание, как метрики помогают мотивировать не только AppSec-команду, но и самих разработчиков и тимлидов.

Зачем нужно искать поверхность атаки и как с помощью этого повысить защищенность приложений.

Основные риски контейнерных сред. Возможности продукта Kaspersky Container Security при работе с выделенными рисками и встраивании на всех этапах жизненного цикла разработки. Ключевая функциональность: интеграция в CI, интеграция с container registry, runtime (admission controller + eBPF control). Сравнение с open source и проблемы использования такого подхода.

Работа статического анализатора Svace и дополняющего инструмента для работы с результатами анализа Svacer. Типовой процесс анализа и разбор нескольких найденных ошибок, по которым можно судить об основных особенностях анализатора: межпроцедурный анализ с учетом отдельных путей выполнения. Описание свойств анализатора, предназначенных для его регулярного использования в CI/CD-системах (удаленный анализ, анализ с кэшем, более тонкая конфигурация). Работа с инструментом Svacer (роли, фильтры, отчеты, сравнение результатов анализа и прочее).