Добрый день, коллеги! Делимся презентациями с выступлений спикеров 👇

Защита инфраструктуры

▪️DDOS: уроки защиты
Андрей Дугин, RED Security

▪️Безопасность информационных систем в облаке: опыт и решения
Алёна Мальцева, RTCloud

▪️Трафик всё расскажет: что мы увидели в 2025
Вячеслав Новосёлов, SkyDNS

▪️Шорт-лист задач для DCAP: с чем не справятся другие СЗИ
Никита Фарзалиев, SearchInform

Процессы

▪️Как быстро навести порядок в ИБ-процессах: первые 90 дней руководителя ИБ
Данила Вайсбург, Государственная компания

▪️Регулярная оценка уровня зрелости ИБ в рамках территориально распределённой группы компаний
Александр Дворянский, ГК Элемент

▪️Системный подход и трансформация ИБ из статьи расходов в фактор ценности
Александр Осипов, ПК РАД КОП

Анализ защищённости

▪️Трендовые уязвимости 2025
Александр Леонов, Telegram-канал "Управление Уязвимостями и прочее"

▪️А уязвим ли мессенджер?
Андрей Исхаков, Банк ПСБ

▪️Цена лишнего факта: как неосознанные утечки бьют по прибыли
Александр Анашин, независимый эксперт

▪️Что устранять или как не утонуть в уязвимостях
Дмитрий Топорков, Альфа-Банк

▪️От вызовов к итогам: МегаФон SOC
Роман Соловьёв, МегаФон ПроБизнес

Безопасная разработка

▪️Проблематика внедрения ИИ в регионах
Дмитрий Служеникин, Консорциум исследования безопасности технологий ИИ

▪️Security Gate: централизованное управление безопасностью приложений
Антон Юрищев, VK Cloud

Культура кибербезопасности

▪️Культура кибербезопасности
Наталия Клименкова, Корпоративный университет Сбербанк

▪️С чего начинается киберкультура
Анастасия Иванова, Билайн

▪️Как контролировать человеческий фактор и не сойти с ума
Харитон Никишкин, Secure-T

▪️Выгорание на страже: как психологическая усталость ломает куберкультуру и что с этим делать
Ксения Трохимец, независимый эксперт в сфере управления человеческим капиталом

▪️Безопасность через доверие: культура как первая линия защиты
Антон Терешонков, RIS group

Защита данных

▪️Итоги 2025 от Киберпротект
Сергей Вахонин, КиберПротект

▪️Как обеспечить безопасность ПДн и не стать мемом в глазах клиентов
Дмитрий Беляев, Belyaev_Security

▪️Эгида Staffcop. Итоги, планы, мысли
Юрий Драченин, Контур.Эгида

▪️Материалы для создания туннелей или как обычно это бывает
Денис Гойденко, Независимый эксперт

▪️Код ИБ: итоги 2025. Защита данных 2025: от угроз — к архитектуре доверия
Александр Мизерин, Yandex Cloud

▪️Ideco NGFW Novum. Релиз нового продукта и его влияние на итоги года
Дмитрий Хомутов, Ideco

▪️Защита данных
Дмитрий Шарапов, ДОМ.РФ

Стартапы говорят

▪️Единая система управления секретами HASPBOX: пароли и секреты в безопасности
Александр Гусев, Haspbox

▪️СПР: транзакционный антифрод нового поколения
Дмитрий Камагин, TechnoScore

▪️InfEra AI.Firewall. Защита ИИ-моделей и их безопасное использование
Игорь Бирюков, InfEra Security

▪️InfEra Security. Безопасность встроенная в ДНК
Бирюков Игорь, InfEra Security

Национальный институт стандартов и технологий США (NIST) приступил к стратегическому пересмотру своей функции по анализу уязвимостей в рамках Национальной базы уязвимостей (NVD) – ключевого ресурса, на котором держится экосистема CVE. В последние годы NVD оказалась под давлением: количество новых уязвимостей, регистрируемых через систему CVE, выросло настолько (то ли еще будет по мере роста автоматизации через ИИ), что NIST не успевает вовремя дополнять записи аналитическими данными. Это вызывает вопросы о пользе и актуальности базы для всех, кто строит процессы управления уязвимостями, автоматизации и комплаенса. А ведь последний раз проблемы у NVD обсуждались менее года назад.

Для специалистов по ИБ это критично: если в базу не успевает попадать качественно проанализированная большая часть CVE, то бизнесу сложнее приоритизировать угрозы, оценивать риски и планировать устранения дыр и патчинг. Немало автоматизированных инструментов корпоративного класса сильно зависят от достоверных и полных данных NVD, чтобы корректно классифицировать и ранжировать угрозы. А тут такая засада...

NIST признает, что ресурсы и процесс обогащения данных не масштабируются под текущие объемы CVE (в последний раз про отсутствие денег на развитие говорили еще в апреле). Поэтому в ближайшее время будет внедрена формальная модель приоритизации, ориентированная на:
➡️ уязвимости из списка активно эксплуатируемых (CISA Known Exploited Vulnerabilities, KEV);
➡️ уязвимости в ПО, широко используемом федеральными агентствами США;
➡️ уязвимости в критически важных для инфраструктуры продуктах.
То есть NIST перестает пытаться "догнать все и всех" – не все CVE будут дополняться подробным контекстом, превращая NVD в чисто локальную историю для американского рынка государственных информационных систем (полная аналогия с БДУ ФСТЭК).

Аналитика и обогащение CVE, которые долгое время были прерогативой NIST, планируется передать сообществу – в частности, CVE Numbering Authorities (CNA). Для этого:
➡️ будет опубликован стратегический план с дорожной картой;
➡️ подготовлены методические рекомендации для CNA;
➡️ нанят менеджер программы для координации процесса.
NIST официально заявляет, что операционная работа по углубленному анализу давно выходит за рамки его основных задач – исследование, стандарты, R&D. Аналитическая нагрузка слишком трудоемка и дорого обходится институту. А тут 30 января грядет очередной шатдаун правительства в США.

Изменения затронут:
➡️ Поставщиков инструментов управления уязвимостями и автоматизации (SIEM, VM, EDR/XDR). Данные NVD, центральный источник метаданных и базовых оценок по CVSS/CWE/CPE, могут стать менее полными и более фрагментированными. Интересно, пойдут всякие Tenable или Qualys на поклон к другим держателям глобальных баз, например, на днях официально запущенной Люксембургским центром реагирования на компьютерные инциденты (CIRCL) базе данных Global Cybersecurity Vulnerability Enumeration (GCVE). Но доступа к той же китайской CCNVD им не видать – Китай американским вендорам заблокировал доступ на свой рынок.
➡️ Команды по уязвимостям и разработке. Российские и глобальные SOC/VOC, DevSecOps-команды, ответственность которых – быстрое обнаружение и приоритизация угроз – столкнутся с тем, что детальный контекст может поступать медленнее или через другие каналы (например, БДУ ФСТЭК или проект dbugs).
➡️ CNA и исследовательское сообщество. Им предстоит взять на себя часть функций по обогащению данных, что увеличит нагрузку и создает запрос на новые стандарты качества и согласованность.

Для бизнеса это сигнал: нельзя полагаться лишь на один источник данных – необходима мультифакторная валидация уязвимостей, кросс-чтение из нескольких репозиториев (например, dbugs или БДУ ФСТЭК) и использование внутреннего/коммерческого контекста.

#оценказащищенности #проблемыибкомпаний

Ребята из Wiz опубликовали простой, но удобный и наглядный фреймворк SITF (SDLC Infrastructure Threat Framework), разработанный для анализа и защиты от атак, нацеленных на инфраструктуру жизненного цикла разработки программного обеспечения.

Фреймворк SITF позволяет визуализировать этапы атаки на компоненты цикла разработки, идентифицировать риски, сопоставлять с ними меры защиты и позволяет анализировать цепочку атаки.

SITF включает в себя:
🟠Flow Builder — интерактивный инструмент для моделирования и визуализации атак.
🟠Explore Techniques Visually — интерактивная MITRE-подобная база знаний о техниках злоумышленников, содержащая в т.ч. описание рисков и мер защиты в разрезе компонентов SDLC.
🟠Руководство по фреймворку c примерами использования и инструкциями, а также с разбором известных атак (CircleCI, Shai-Hulud-2 и Codecov).

Как и писал в начале, инструменты очень простые в использовании и визуально удобные👍
В репозитории есть ссылки на онлайн-версии, но ссылки там битые🤷 Однако, для локального запуска достаточно скачать два html-файла и открыть их в любом веб-браузере.

#sdlc #framework #technique #risks #controls #modeling

Я тут разбирался с Moltbot (бывший Clawdbot), который мог бы за счет автоматизации существенно поднять мою продуктивность. Изучал разные мнения, в том числе и по его безопасности, которая, как это часто бывает у пет-проектов, оказалась не на высоте. Но дело даже не в этом. Я попробовал представить, как мне защитить Moltbot'а от злоупотреблений и реализации через него угроз против меня? И понял, что это, пипец, какая непростая задача. Большинство современных средств ИБ (например, NGFW или NDR или WAF) исходит из предположения, что ИИ ведет себя как человек или хотя бы как предсказуемая сессия, но ИИ-агенты так не работают.

Чтобы быть полезным, агенту нужны широкие права. Он должен сам решать, куда пойти за данными и какие источники связать между собой. Один запрос, например, "Дай рекомендации по повышению эффективности команды аналитиков SOC" может запустить целую цепочку действий:
➡️ обращение к HR-системе
➡️ загрузку данных по оргструктуре
➡️ обращение к SIEM/SOAR
➡️ запросы к базе зарплат
➡️ объединение с performance-review
➡️ синтез результата.

Решения класса IDM/PAM/JIT проектировались под мониторинг действий людей и понятные сценарии: запрос → одобрение → выполнение → отзыв доступа. У агентов же все иначе:
➡️ Один и тот же запрос сегодня – это 50 записей.
➡️ Тот же запрос завтра – это уже записей 500, включая доступ к чувствительным полям в какой-нибудь СУБД.
➡️ Послезавтра – объединение нескольких наборов данных и экспорт результата.

В таких условиях принцип наименьших привилегий перестает работать как концепция. Сделать списки контроля доступа строгим – агент "ломается" на полпути, а пользователи начинают обходить контроль. Ослабить – вы даете широкие постоянные права и увеличиваете радиус поражения в случае инцидента ИБ. И заранее предсказать путь агента невозможно – он "думает" по ходу выполнения задачи. И тут нет проблемы IAM, NGFW, СЗИ от НСД и других систем ИБ, работающих в детерминистском пространстве и ограниченном пространстве решений. Это фундаментальное отличие и, даже, противоречие автономных систем.

Классические инструменты отвечают на свои привычные вопросы:
➡️ IAM: "Этот сервис-аккаунт успешно аутентифицировался"
➡️ NGFW: "Этот запрос пришел с легитимного IP-адреса"
➡️ PAM/JIT: "Доступ был одобрен"
➡️ CASB/DLP: "Мы видим вызовы и контент".
Но они не видят цепочку исполнения. С точки зрения идентифицированных сущностей все легально, а в реальности агент:
➡️ забрал больше данных, чем требовалось
➡️ связал чувствительные наборы между собой
➡️ выдал результат пользователю, которому эти данные видеть нельзя.
В Интернете дофига кейсов, где ИИ-агенты делают больше запрошенного (я на обучении по ИБ и ИИ для топ-менеджмента тоже привожу такие кейсы), раскрывая конфиденциальную информацию случайным людям или злоумышленникам.

И традиционная ИБ не очень помогает решать эту проблему. Не потому, что она плохая, а потому, что она строилась в другой парадигме. Это примерно как NGFW, которые появились как ответ обычным МСЭ, неспособным видеть, что происходит на прикладном уровне. Так и тут. У ИИ-агентов слишком много прав (и урезать их – не вариант) и мы не видим, как они ими пользуются в рамках всей цепочки запросов и ответов (пользователь → агент → сервис(ы) → MCP-сервер/OpenRouter). На границах между компонентами теряется контекст и мы не понимаем, что происходит на самом деле.

И ИБ нужны будут новые решения. Что-то типа RASP, но для агентов, а не приложений, с добавлением понимания контекста. А я пока думаю, как решать свою задачу, так как давать избыточные права Moltbot'у у меня рука не поворачивается, а без этого он превращается просто в навороченный Shortcuts на macOS.

#ии #модельугроз