«Казнить нельзя помиловать, уязвимости из-за ошибок в бизнес-логике»

Змичеровская Ксения: Более 6 лет практического опыта в ИБ в таких направления как фарма, gamedev, разработка ПО, в том числе в роли системного и бизнес аналитика

Шаров Илья: Более 6 лет опыта в системной интеграции, финансовой и фин.тех отраслях. Последние три года занимался развитием, масштабированием и популяризацией практик безопасной разработки, в роли эксперта, архитектора и руководителя

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

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

«Как разработчики анализатора исходного кода с одной экспонентой боролись»

Александрия Георгий: чародей 3 круга, колдун 6 ранга, и ныне преподающий теорию и практику заклинаний в магической башне Positive Technologies, раскроет вам несколько полезных мистических заговоров, позволяющих облегчить работу магического аппарата. Но будьте осторожны, не обманитесь простотой слова "заговор", они отнюдь не просты и будут содержать в себе определенные формулы и символы, требующие их понимания и знания... ну или усидчивости их переварить.

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

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

«Архитектура сервисов: снижение трудозатрат и повышение безопасности»

Кардюков Юрий: руководитель направления Identity и Open API в компании eKassir, Product Owner системы Identity Platform. Спец в вопросах аутентификации/авторизации. Один из создателей сертификационного стенда OpenAPI (https://openbankingrussia.ru/).

Доклад о предоставлении API для пользователей и партнеров. Чем сервисы для пользователей отличаются от System-to-System взаимодействия. Как безопасно хранить чувствительную информацию, не распространять пароли на сервисы и делегировать аутентификацию на сторону API Gateway и Authorization Server (oAuth 2.0 и OpenID Connect).

Вы узнаете как:
- безопасно провести аутентификацию пользователя без сторонних библиотек и без единой строчки кода;
- чем отличается архитектура system-to-system от пользовательского API;
- предоставить доступ к сервису без открытия доступов на межсетевом экране.

«Руководство бравого докер-секурити мастера»

Задорожный Сергей: техлид, 14 лет рабоыт в банке Центр-инвест. Занимался написанием бэкендов на Java и Kotlin для энтерпрайзного энтерпрайза в финтехе.
Сейчас девопсит, техлидит, деврелит и выступает с докладами. Держит змей, пауков и прочих экзотических тварей. Любит котиков и блэк-металл.

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

Вы узнаете:
- как стать на путь DevSecOps'a и настроить Докер так, чтобы удовлетворить ибешников;
- что такое СIS Docker Benchmark, как его реализовать и какие способы усилить контейнеры ещё есть (Gvisor,Firecracker, дополнительные требования по развертыванию контейнеров от ИБ...);
- как продать Докер безопасникам.

«Supply chain security»

Шмойлов Дмитрий: Head of software security @Kaspersky. 17 лет в ИБ. последние 5 лет в Kaspersky отвечает за безопасную разработку, развитие SDLC и DevSecOps, bugbounty. Ежедневно сталкивается с рассматриваемой темой на практике.


В докладе будут рассмотрены проблемы безопасности программных компонент и процессов, которые организации, вынуждены получать от внешних поставщиков (софт, ЦОД, услуги, opensource). Риски, связанные с цепочками поставок, были всегда, но за последние несколько лет привели к ряду инцидентов в разных компаниях в мире.

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

Вы сможете:
- CISO: посмотреть на угрозы под другим углом, актуализировать ИБ концепцию, понять как донести риски до руководства;
- DevSecOps: проверить, все ли необходимые контролы реализованы/есть в вашем бэклоге;
- DevOps/Developer: узнать о рисках, которые оставались незамеченными;
- SecurityOfficer: найти «серые зоны в безопасности» внутри вашей инфраструктуры.

«Как применять подходы ZeroTrust при построении процесса безопасной разработки»

Газизова Светлана: руководитель направления аудита безопасной разработки в Swordfish Security. За последние годы собрала коллекцию как надо и как не надо делать DevSecOps; поработала с несколькими десятками компаний. Автор и тренер курсов по безопасной разработке. Из тех, кто пришел в безопасность из разработки – так что есть понимание, как коррелировать между интересами разных сторон. Автор канала по безопасной разработке с обзорами последних новостей, полезностями и мемами (без рекламы и духоты 😉) - https://news.1rj.ru/str/AppSecJourney.

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

Вы сможете найти для себя ответы на следующие вопросы:
- Насколько реально подружить две концепции и как это отразится на time to market?
- Кому нужно «не доверять» и почему?
- Как изменится цикл безопасной разработки?

«Я реверсер, я так вижу!»

Дмитрий Скляров: Head of Reverse Engineering, Positive Technologies. Ковыряет бинарщину. Ищет всё плохое, чтобы сделать его хорошим...

За те годы, что я занимаюсь Reverse Engineering, я повидал много разного кода, иногда даже в исходниках. Пообщался со многими людьми, имеющими отношение к разработке ПО, зачастую очень умными. Прочитал много статей и книг, местами даже полезных. Наблюдал появление новых техник и технологий для повышения безопасности приложений, вполне себе эффективных...

Но ошибки в коде всё не исчезают. Не то чтобы каждый бинарь содержит критические уязвимости, но шанс найти что-то "плохое" всё ещё очень велик...

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

«Язык запросов к коду... не нужен?»

Владимир Кочетков: руководитель направлений экспертизы безопасности приложений и разработки анализаторов кода, Positive Technologies. Организатор POSIdev и трека разработки PHDays.

Сергей Подкорытов: тимлид разработки анализаторов кода, Positive Technologies.

В нашем докладе мы поделимся опытом решения задачи по отчуждению экспертизы в PT Application Inspector, рассмотрим такие популярные инструменты, как Semgrep и CodeQL, и расскажем о непростом пути, пройдённом командой PT AI через несколько версий языка запросов к совершенному иному способу описания базы знаний статического анализатора.

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