Адриан Мастронарди (занимается созданием и управлением инженерными организациями, стоящими за выпуском ПО) выпустил книгу под названием «Полсекунды». В ней подробно рассматривается попытка создания бэкдора в xz в 2024 году. Книга распространяется бесплатно под (несвободной) некоммерческой лицензией CC, запрещающей создание производных работ.
VPN принято считать защитным инструментом. Он шифрует соединение, скрывает реальный IP и переносит доверие от интернет-провайдера к владельцу VPN-сервера. Но именно здесь появляется неприятный парадокс. Пользователь устанавливает приложение ради безопасности и добровольно отдаёт ему контроль над маршрутом почти всего сетевого трафика.
Сам по себе VPN не получает магический доступ к seed-фразам и не может просто расшифровать нормальное HTTPS-соединение. Но вредоносный VPN-клиент может оказаться обычным инфостилером в красивой упаковке. Вместе с туннелем он способен читать буфер обмена, искать расширения криптокошельков, красть cookies и сохранённые пароли, подменять адрес получателя или показывать фальшивые окна авторизации. В таком сценарии VPN нужен злоумышленнику не как технология перехвата, а как причина убедить пользователя установить вредоносную программу.
На смартфонах риск ещё интереснее. Android позволяет VPN-приложению создавать виртуальный сетевой интерфейс, через который проходят исходящие пакеты устройства. Это нормальная функция системы, но она требует огромного доверия к разработчику. Если приложение дополнительно просит доступ к специальным возможностям, уведомлениям, экрану, буферу обмена или установке неизвестных сертификатов, оно уже получает возможности, которые к обычному VPN почти не относятся. На iPhone похожим тревожным сигналом будет просьба установить профиль управления или вручную доверять корневому сертификату. Такой сертификат потенциально позволяет организовать перехват защищённого трафика на самом устройстве.
Есть и менее очевидный сценарий через DNS. VPN может назначить собственный DNS-сервер и решать, на какой IP отправить пользователя после ввода адреса сайта. Подделать HTTPS незаметно всё равно сложно, но пользователя можно направить на похожий домен, фальшивую страницу биржи или копию интерфейса кошелька. Если человек не проверяет адрес и подтверждает вход, VPN уже выполнил свою задачу. Иногда вредоносный клиент вообще не трогает трафик, а просто меняет скопированный криптоадрес перед отправкой. Пользователь видит знакомый процесс, но деньги уходят на другой кошелёк.
Поэтому опасен не VPN как протокол, а приложение и инфраструктура, которым пользователь передаёт слишком много доверия. Особенно рискованны клиенты из рекламы, Telegram-архивов, неизвестных GitHub-репозиториев и сайтов-клонов. Перед установкой стоит проверить разработчика, цифровую подпись, источник загрузки, запрашиваемые разрешения и наличие открытого кода. А устройство, с которого проводятся крупные криптооперации, лучше вообще не превращать в полигон для случайных VPN-клиентов. Защищая IP-адрес, легко случайно отдать злоумышленнику куда более ценную часть своей цифровой жизни.
Как настроить TLS в клиенте Python при HTTPS-запросах?
Бывает так, что после обновления OpenSSL часть HTTPS-вызовов к внешним сервисам падает с ошибкой ssl.SSLError. Сейчас разберемся, как настроить Python, чтобы handshake проходил успешно и соединение оставалось безопасным.
После апдейтов OpenSSL часто отключают старые протоколы и слабые шифры — старые серверы не проходят handshake. Решение на клиенте — явно создать ssl.SSLContext, задать минимальную версию TLS и, при необходимости, набор шифров, а затем передать этот контекст в HTTP-клиент (например, httpx).
import ssl
import httpx
ctx = ssl.create_default_context(purpose=ssl.Purpose.SERVER_AUTH)
ctx.minimum_version = ssl.TLSVersion.TLSv1_2
ctx.set_ciphers('ECDHE+AESGCM:!ECDSA:!aNULL:!eNULL')
with httpx.Client(verify=ctx, timeout=10.0) as client:
r = client.get('https://api.example.com')
r.raise_for_status()
print(r.status_code)
В коде мы указываем TLSv1_2 как минимальный порог. Это удобно: если сервер уже поддерживает TLS 1.3, все само заработает на самой новой версии. Но если какой-то внешний сервис еще не успел обновиться, соединение не разорвется, и все продолжит работать на стабильном 1.2. Так мы получаем универсальный код, который не сломается при работе со старыми API.
Для отладки TLS handshake применяйте openssl s_client -connect host:443 -tls1_2 чтобы увидеть, какие шифры поддерживает сервер. Временное ослабление minimum_version даст совместимость, но хуже для безопасности — лучше апгрейдить серверную часть. Сертификаты и ключи храните вне кода (секреты/volumes), не логируйте их, и при работе в контейнерах используйте безопасные механизмы передачи секретов.
Если хотите освоить инструменты Python, то в Академии Selectel у нас есть отдельная подборка статей. Там мы рассказываем, как настраивать инструменты, работать с базами данных, создавать программы с интерфейсом и использовать Python для парсинга.
Очень много CTF-соревнований проводится с использованием платформы CTFd. Как они сами скромно про себя пишут:
CTFd - The best Capture The Flag framework out there for hiring hackers, training developers, and teaching students.
Я, в одной из своих статей, писал, что полностью автоматическое решение всей CTF-площадки AI- агентом затруднено и перечислил те трудности, с которыми тогда боролся.
Оказывается, у CTFd есть API!
Так вот, работа по API решает тьму из тех проблем, с которыми я тогда столкнулся!Это прям прорыв в моих исследованиях на эту тему!
Для использования API CTFd я написал skill для OpenCode, про который и хочу вам рассказать!
CTFd-Skill — skill, позволяющий ИИ-агенту играть в любой CTF на платформе CTFd через REST API от лица обычного участника: список и чтение задач, скачивание файлов, подача флагов, подсказки, рейтинг, анонсы. Покрывает только player-действия (без админ-эндпоинтов) и работает с любым инстансом CTFd — не привязан к конкретной площадке.
Ключевые возможности:
Подача флагов с обработкой всех статусов задачи и авто-backoff без риска заблокировать себя перебором;
Персистентный журнал под каждую задачу: файлы, solve-скрипты и статусы решения задач переживают случайные перезагрузки;
Авто-обнаружение новых задач и анонсов организаторов (подсказки, уточнения) с классификацией по тегам — ничего не теряется по ходу соревнований;
Теперь промт на решение всей CTF-площадки может выглядеть так:
Используя CTFd-skill, реши все задачи площадки ctf.url.com, token - ...., формат флага ctf{...}. Все задачи, по которым тебе требуются моё мнение или моя помощь, переноси в конец. Решай все задачи, которые можешь решить автоматически.
Пробуйте, пишите обратную связь, ну поставьте мне лайк тут и звезду проекту на GitHub!
По роду своей деятельности нашей команде постоянно приходится сталкиваться с обходом физической безопасности: будь-то биометрия, СКУД или обычные “амбарные” замки. И как бы не казался большой металлический “кирпич” неприступной крепостью, вскрыть его (при этом вскрыть без повреждений) зачастую оказывается упражнением с низким уровнем сложности.
В рамках нашего очередного исследования, мы приобрели ряд навесных замков с биометрией по отпечатку пальца. И, очевидно, целью исследования мы ставили обход биометрии. В итоге, после детального разбора как аппаратной, так и программной части, мы нашли как минимум 2 негласных пути взлома.
Причиной вскрытия в первом методе, как можно наблюдать на видео, является слабая пружина запорной пластины, которая под действием перегрузки сдвигается и высвобождает наружную скобу. Как итог: прикладываем небольшую силу (например, удар) и замок открывается.
Второй путь - заложенный производителем бэкдор, который при наборе определенной комбинации на замке его просто открывает. Ужас начинается тогда, когда мы попробовали воспроизвести этот код на остальных образцах исследования: все замки имеют встроенную уязвимость (спасибо восточным партнерам за унификацию). В результате, 1-2 минуты и дверь открывается.
По понятным причинам, мы не будем публично раскрывать эксплойт, но уже уведомили об этом производителя и сделали запрос на присвоение CVE/BDU. Как говорится, ждем-с.
Кроме того, уязвимостью также может быть неправильный выбор материала замка (изучаем физику). Если запорная пластина выполнена из металла, подверженного намагничиванию, то отодвинуть ее можно с помощью простого магнита. Второе видео, скорее всего, является постановочным, но как вектор атаки его никто не отменял. К слову, этот метод был опробован первым в исследовании биометрических замков, однако инженеры предусмотрели такой вектор атаки: запорная пластина выполнена из дюралюминия и не подвержена действию магнита.
Подводя краткий итог, могу с уверенностью сказать, что выражение
Все замки от честных людей
появилось не просто так и действительно является правдой. Поэтому, выбирать инструменты или оборудование для организации защиты нужно с умом: злоумышленники думают не стандартно и не всегда идут напролом по предложенному пути.
🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
npm 12 больше не запускает скрипты установки зависимостей без разрешения
npm 12 больше не запускает скрипты установки зависимостей автоматически и требует отдельно разрешать установку из внешних источников и Git. Одновременно npm начинает ограничивать токены с обходом двухфакторной аутентификации. В посте разбираем, что это меняет для безопасности установки пакетов и что стоит проверить перед обновлением.
8 июля 2026 года GitHub выпустил npm 12 и пометил его тегом latest. Вместе с новой версией изменился базовый сценарий установки – раньше скрипт зависимости мог выполниться автоматически, теперь проект должен заранее разрешить его через allowScripts.
Ограничение распространяется на preinstall, install, postinstall и неявные сборки через node-gyp. Если такой скрипт действительно нужен, его можно добавить в список разрешенных; для разбора уже существующего проекта npm предлагает команду npm approve-scripts --allow-scripts-pending, которая показывает зависимости без явно заданного решения и помогает сохранить настройки в package.json.
Тот же принцип теперь применяется к зависимостям из Git и удаленным архивам. Без --allow-git npm откажется устанавливать Git-зависимости, а для архивов по внешним URL понадобится --allow-remote. В июньском анонсе npm 12 GitHub отдельно отмечал, что Git-зависимости создавали обходной путь для выполнения кода даже при использовании --ignore-scripts.
Одновременно npm начинает ограничивать токены с обходом двухфакторной аутентификации: в начале августа 2026 года они потеряют доступ к чувствительным операциям управления аккаунтами, пакетами и организациями, а позднее не смогут напрямую публиковать пакеты. Для автоматической публикации GitHub рекомендует переходить на доверенную публикацию через OIDC или использовать публикацию с ручным подтверждением.
Почему это важно
Новые настройки заметно сужают возможности для атак через установочные скрипты. Это хорошо видно на примере Shai-Hulud и Shai-Hulud 2.0. В первой вредоносные версии пакетов в основном запускали код через postinstall, а во второй для этого использовался preinstall. Однако важно понимать, что вредоносный пакет по-прежнему может попасть в реестр и дерево зависимостей, а нежелательный код выполнится позднее, когда его импортирует приложение или система сборки. npm 12 закрывает не весь путь заражения, а именно автоматическое выполнение кода непосредственно во время установки. Более широкий разбор атак через пакеты и другие звенья цепочки поставки есть в нашей статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».
Перед переходом на новую версию командам стоит проверить:
какие зависимости действительно используют установочные скрипты
откуда в проектах появляются Git-зависимости и удаленные архивы
есть ли в CI долгоживущие токены публикации с лишними правами
ICL Services выпустила новый эпизод подкаста «Сервисные хроники», посвященный эволюции технологии SD-WAN. Главным гостем нашего выпуска стал Максим Каминский, менеджер по развитию бизнеса «Лаборатории Касперского», давнего партнера ICL Services в области информационной безопасности.
Участники разобрали технологию SD-WAN глазами тех, кто ее разрабатывает, и тех, кто ежедневно внедряет в инфраструктуру бизнеса. Отдельный блок был посвящен кибербезопасности — в ее рамках мы вместе с «Лабораторией Касперского» регулярно реализуем совместные проекты для российских компаний. Герои обсудили, как привязать к SD-WAN полноценную защиту с помощью сервисных цепочек, межсетевых экранов и умной оркестрации.
Эксперты Arktis компании «Газинформсервис» подготовили отчёт об актуальных уязвимостях и активностях группировок
Во втором квартале Arktis зафиксировала новую волну критических уязвимостей и перераспределение сил киберпреступных группировок. Эксперты проанализировали более сотни публичных CVE, выделили топ-5 наиболее атакуемых продуктов и проследили эволюцию трендовых векторов атак — от эксплуатации атак нулевого дня до массового сканирования корпоративных периметров. Особое внимание уделено географии инцидентов: смещение фокуса злоумышленников на азиатско-тихоокеанский регион и рост шифровальщиков в госсекторе. Arktis также разобрала реальные кейсы реализации и патчинга CVE; составила антирейтинг самых частых логинов и паролей; отметила временные паттерны атак. В заключении представлен прогноз угроз на следующий квартал и практические рекомендации по приоритизации защитных мер.
Большинство пользователей думают, что все криптовалюты работают примерно одинаково. Есть кошелек, есть адрес, есть блокчейн, а различия сводятся только к скорости или комиссиям.
На самом деле Monero построен совершенно на другой философии. Если Bitcoin создавался как максимально прозрачная система, то Monero наоборот старается скрыть практически все, что можно скрыть. Из-за этого привычные вещи, которые работают в Bitcoin, здесь просто отсутствуют.
Например, в Bitcoin достаточно открыть любой blockchain explorer, вставить адрес и увидеть его баланс, историю переводов и все входящие транзакции.
В Monero так сделать нельзя.
Когда вы отправляете XMR, сеть не использует постоянный адрес получателя. Вместо этого для каждой транзакции автоматически создается одноразовый stealth address. Со стороны кажется, что средства ушли вообще на новый неизвестный кошелек, хотя на самом деле они принадлежат тому же владельцу. Если человек получит тысячу переводов, в блокчейне появится тысяча разных адресов, и понять, что все они принадлежат одному пользователю, практически невозможно.
Но это только первый уровень защиты.
Следующая особенность - Ring Signatures. Представьте, что у Bitcoin каждая транзакция показывает, какой именно выход был потрачен. В Monero этого нет. Перед отправкой кошелек автоматически подбирает несколько похожих выходов из блокчейна и объединяет их в одну группу. Проверить корректность подписи можно, но определить, какой из участников группы действительно потратил монеты, уже нельзя. Для наблюдателя все выглядят одинаково вероятными.
Даже если скрыть отправителя и получателя, остается еще одна проблема - сумма перевода. В Bitcoin она всегда видна. В Monero для этого используются Ring Confidential Transactions и Bulletproofs. Сумма полностью скрывается, но при этом сеть все равно может математически доказать, что никто не создал новые монеты из воздуха и баланс системы остался корректным.
Интересно и то, что в Monero практически отсутствует понятие грязных монет. В Bitcoin история каждой монеты сохраняется навсегда. Если когда-то она участвовала в краже или взломе, аналитические компании могут пометить ее как рискованную. В Monero происхождение конкретной монеты проследить невозможно, поэтому каждая монета остается взаимозаменяемой. Именно это свойство экономисты называют fungibility, и именно его многие считают одной из главных недостающих функций Bitcoin.
Получается интересный парадокс. В Bitcoin прозрачность считается одним из главных преимуществ сети. В Monero эту же прозрачность воспринимают как проблему, которую нужно было решить на уровне самого протокола.
Поэтому Monero нельзя назвать просто еще одной криптовалютой с функцией приватности. Это совершенно другой взгляд на устройство блокчейна, где большинство привычных инструментов анализа просто перестают работать.
Проект tlosint-vm - виртуальная машину от Tracelabs OSINT, которая проверяет тысячи открытых источников по запросу:
сервис специально создали для соревнований OSINT‑исследователей и поиска пропавших пользователей в сети;
готовый стек: Shodan CLI, Sherlock (поиск по логинам и юзернеймам), PhoneInfoga (разведка по номерам телефонов), SpiderFoot и sn0int (автоматизированные OSINT‑фреймворки), theHarvester и h8mail (email), Sublist3r (поддомены), exiftool и steghide (метаданные и стеганография);
проработана приватность — как только пользователь выходит из сервиса, то система чистит все данные и куки;
внутрь также вшили хранилище Obsidian, где можно оставлять заметки во время поиска;
без ограничений, открытый проект, легальный поиск по открытым источникам.
Старт третьей рубрики ИТ-кроссворда уже через 30 минут 🦖
В 12:00 по московскому времени открываем новую рубрику ИТ-кроссворда — «Безопасность ML и AI». В публикации вас будут ждать вопросы об использовании ML в ИБ и новых типах угроз.
👉 Отвечать на вопросы можно с 12:00 до 18:00 (МСК). Среди призов — комплекты эксклюзивного мерча Selectel и бонусы на аренду серверов.
Напоминаем, что завтра вас ждет заключительный кроссворд, однако бороться за первое место в общем зачете не обязательно, вы еще успеваете посоревноваться и выиграть призы! Победители и номинанты будут в каждой из четырех рубрик.
Как отключить Google и Apple ID и не сломать авторизацию для пользователей
Привет! Я Александр Бондаренко, руководитель проектной группы в Далее. С сегодняшнего дня кнопка «Войти через Google» на сайте может стоить от 500 до 700 тысяч рублей. Всё потому, что 7 июля вступает в силу Федеральный закон № 199-ФЗ — поправки в КоАП, по которым за авторизацию пользователей через иностранные сервисы владельцы сайтов несут административную ответственность.
В посте разберу, где искать иностранных провайдеров на сайте и как не потерять пользователей при миграции.
Коротко о законе: требование идентифицировать российских пользователей через российские сервисы действует с декабря 2023 года (149-ФЗ). В список приоритетных способов входят номер телефона РФ, «Госуслуги» (ЕСИА), единая биометрия или сервис российского гражданина или компании — например, VK ID, Яндекс ID, Сбер ID. С 7 июля у требования появилась статья в КоАП (13.55, 199-ФЗ от 26 июня) — штраф до 700 тысяч рублей для юрлиц.
Авторизация через Google и Apple ID — очевидная часть, но список шире. Sign in with Apple часто появляется просто потому, что Apple требует его для iOS-приложений. На старых проектах нередко остается Facebook Login (принадлежит Meta, признанной в России экстремистской организации). Реже встречаются GitHub, Discord и Microsoft / Azure AD — обычно в сервисах для разработчиков, игровых проектах и корпоративных SSO.
Как искать в коде
Механизмы авторизации есть не только на главной при входе, но и при регистрации, восстановлении пароля, в мобильном приложении и API для партнеров.
Для Passport.js проверьте passport-google-oauth20 и passport-apple в package.json, для OmniAuth — omniauth-google-oauth2 в Gemfile, для Firebase Auth — providers в конфиге. В мобильных сборках обратите внимание на GoogleSignIn в Podfile и play-services-auth в build.gradle.
Отдельно стоит заглянуть в консоли провайдеров — Google Cloud Console, Apple Developer, GitHub OAuth Apps. Кнопку в интерфейсе можно убрать, но пока приложение зарегистрировано в консоли и redirect-URI активен, эндпоинт технически остается рабочим.
Как перейти на российские сервисы и не потерять пользователей
Если отключить иностранного провайдера раньше, чем пользователи привяжут новый способ входа, аккаунты сохранятся, но войти в них уже не получится. Порядок действий такой:
Подключить и протестировать российский способ: SMS, VK ID, Яндекс ID, Сбер ID или «Госуслуги».
Предложить авторизованным пользователям привязать новый способ входа и заранее предупредить о дедлайне.
Тем, кто не успел, предоставить восстановление через поддержку с подтверждением личности.
После миграции отключить иностранного провайдера, удалить OAuth-приложение в консоли, очистить GOOGLE_CLIENT_SECRET из .env и хранилища секретов.
При необходимости инвалидировать активные JWT и refresh-токены, выданные через Google.
Обновить Политику обработки персональных данных.
3 вопроса, которые пока остаются открытыми
1. Что считать иностранным сервисом. Кнопку входа через Google меняем точно. А вот использование Gmail как адреса электронной почты без OAuth, по мнению большинства юристов, под действие закона не подпадает: значение имеет способ подтверждения личности, а не почтовый адрес.
2. Что делать с уже авторизованными пользователями. У нормы 2023 года не было обратной силы. Но теперь ответственность возникает за сам факт работающего иностранного способа входа, поэтому миграцию лучше провести уже сейчас.
3. Что с сайтами иностранных компаний в зоне .ru. Закон адресован владельцам сайтов без разделения по юрисдикции регистрации. Судя по формулировкам, ключевой критерий — наличие российской аудитории, а не страна регистрации компании.
Пишите в комментариях, если я не упомянул какие-то подводные камни, и подписывайтесь на мой тг-канал про цифровой комплаенс 👌
Представлен открытый сервис NtWARden (Windows Analysis and Research Toolkit), который распознает любые вредоносы и проблемное ПО, даже если эти компоненты находятся глубоко в системе Windows.
Проект NtWARden:
сканирует процессы, службы, сеть, внутренние механизмы ядра;
обнаруживает скрытые вредоносы;
убивает майнеры и трояны;
показывает реальную картину нагрузки на процессор;
помогает контролировать, что находится в системе прямо сейчас: службы, сетевые соединения, скрытые процессы;
может подключиться к другому ПК и также отслеживать его процессы.
Финальный дополнительный вебинар прошёл при участии ведущих экспертов: Дмитрия Шмойлова, Алексея Щербакова и Виталия Вареницы. Участники обсудили практику сертификации, новые национальные стандарты и методику подготовки, опыт компаний, а также подводные камни аудита и преимущества внедрения РБПО.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Представлен лёгкий браузер для парсинга данных и ИИ‑агентов — открытый Obscura на Rust работает в разы быстрее подобных проектов и занимает меньше ресурсов, чем Сhrome или Firefox:
без графического интерфейса — максимальная автоматизация;
Stealth Mode, который скрывает признаки ИИ‑агентов. Так сайты не будут распознавать устройство как бота;
использует лишь 30 МБ оперативной памяти;
сам браузер весит около 70 МБ;
грузит страницы за 85 мс;
после запуска браузер готов к работе практически сразу без дополнительных настроек.
DDoS-атака не всегда очевидна. Резкий рост нагрузки может оказаться как настоящей атакой, так и вполне легитимным всплеском трафика после рекламной кампании или важного инфоповода. В совместном материале с ITSumma разбираем, как быстро отличить одно от другого, на какие метрики смотреть в первую очередь и какие действия предпринимать в первые минуты после обнаружения проблемы.
Если вы отвечаете за стабильную работу сайта, интернет-магазина или корпоративного сервиса, эта статья поможет лучше понять логику реагирования на DDoS-инциденты и выбрать подходящую стратегию защиты.
Отдельное внимание уделяем двум основным моделям защиты — Always-On и On-Demand. Рассматриваем, чем они отличаются, в каких случаях каждая из них эффективнее, а также какие компромиссы приходится учитывать при выборе между постоянной фильтрацией трафика и подключением защиты только во время атаки.
Неделю назад КиберËж проводил CyberWeekend (где там правда викенд они нашли в начале недели, я не знаю 😂) и, в том числе, пригласили меня побеседовать про Программно-аппаратный хакинг как одно из самых сложных и интересных направлений в кибербезопасности, объединяющее знания из программирования, электроники, сетей, встроенных систем и реверс-инжиниринга.
В рамках диалога мы с Павлом осветили такие темы, как: * Почему специалистов в этой области так мало и чем они занимаются на практике. * Почему искусственный интеллект пока не способен заменить экспертов по аппаратному хакингу: работа с реальными устройствами требует опыта, интуиции и нестандартного мышления. * Как после 2022 года изменились основные направления атак и почему всё больше внимания уделяется IoT-устройствам и объектам физической инфраструктуры. * Какие навыки стоит развивать уже сегодня тем, кто интересуется IT, электроникой и информационной безопасностью.
Могу с уверенностью сказать, что доклад будет полезен начинающим специалистам, студентам технических направлений и всем, кто хочет понять, как устроена одна из самых редких и востребованных профессий в сфере кибербезопасности.
Ну и конечно же, интервью можно легко посмотреть в 📺 ВКвидео.
🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
С помощью приглашённого эксперта Екатерины Рудиной, аналитиком департамента перспективных технологий "Лаборатории Касперского", мы разобрались, в чём сходство и различие таких систем с безопасным ПО, как соотносятся создание систем с КИБ и разработка безопасного ПО, чем полезен в работе специалистов по ИБ новый ГОСТ Р 72118—2025 "Защита информации. Системы с конструктивной информационной безопасностью. Методология разработки".
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Сквозное шифрование, или как Telegram и Bitcord защищают переписку.
Хочу написать небольшой пост о сквозном шифровании, или, если использовать технический термин, E2EE (End-to-End Encryption).
Сегодня эта технология широко применяется во многих мессенджерах. Я тоже реализовал E2EE в мессенджере Bitcord . Однако далеко не все понимают, как именно работает этот механизм, поэтому попробую объяснить простыми словами.
Поскольку я являюсь разработчиком и основателем собственного мессенджера, реализовать эту схему для меня не составило особого труда. Главный секрет заключается в понимании принципов работы криптографических алгоритмов, таких как AES и RSA. Хотя современные реализации E2EE обычно используют не RSA, а алгоритмы на эллиптических кривых (например, X25519), я не стал прибегать к усложнениям.
Алгоритм AES я использовал для непосредственного шифрования текстового сообщения, которое один пользователь отправляет другому. Для шифрования применяется секретный ключ (или пароль). Основная проблема такого подхода заключается в том, что этот ключ необходимо каким-то образом передать получателю. Если злоумышленник перехватит ключ, он сможет расшифровать сообщение.
Чтобы этого не произошло, я использовал ещё один алгоритм - RSA. Для его работы требуется пара криптографических ключей: публичный и приватный. Так как RSA не предназначен для шифрования больших объёмов данных, я его использовал для безопасной передачи того самого секретного ключа, который используется алгоритмом AES.
В результате схема выглядит так.
Сначала текст сообщения шифруется алгоритмом AES с использованием случайного секретного ключа. Затем этот ключ шифруется алгоритмом RSA с использованием публичного ключа получателя. Когда получатель отправляет ответ, он выполняет ту же самую операцию, но уже с публичным ключом аппонента.
Важно понимать, что публичный ключ предназначен только для шифрования. Расшифровать данные с его помощью невозможно. Для расшифровки существует только соответствующий ему приватный ключ.
Когда получатель открывает сообщение, его устройство сначала с помощью приватного ключа RSA расшифровывает секретный ключ AES, а затем уже этим ключом расшифровывает само сообщение.
В моём приложении это работает следующим образом. Публичные ключи пользователей хранятся на сервере. Когда пользователь отправляет сообщение, приложение запрашивает у сервера публичный ключ получателя, шифрует сообщение на устройстве пользователя и отправляет на сервер уже зашифрованные данные. Сервер выступает лишь в роли посредника и пересылает этот зашифрованный пакет получателю. Сам сервер приватные ключи не хранит.
При этом приватные ключи никогда не покидают устройство пользователя. Они хранятся в защищённом хранилище смартфона, и получить к ним доступ не может ни сервер, ни разработчик приложения, ни кто-либо ещё. Поэтому расшифровать переписку может только владелец соответствующего приватного ключа.
В этом и заключается смысл сквозного шифрования: сервер передаёт сообщения, но не имеет возможности их прочитать.
Именно поэтому было довольно забавно наблюдать, как спецслужбы требовали у Павла Дурова "ключи шифрования", чтобы получить доступ к переписке пользователей Telegram. Никаких универсальных ключей у него нет и быть не может - приватные ключи находятся только на устройствах самих пользователей.
Именно поэтому требование "передать ключи" технически лишено смысла. Передавать попросту нечего.
П.С.
Я - сетевой долгожитель и начинал свой путь еще в эпоху Фидонета (FidoNet). Эта сеть была по-настоящему децентрализованной: никаких общих серверов и никакого DNS. Все строилось просто: компьютер, модем и терминальная программа для связи. Часто в роли узла (ноды) выступал сервер в банке, где знакомый сисадмин выделял адреса. При этом подключиться можно было к любому другому участнику, даже к частному лицу. Вот это и была настоящая децентрализация! Думаю, учитывая растущее давление регуляторов на современный интернет, мы скоро снова вернемся к проверенным идеям старого доброго Фидо.
Как не пропустить опасные участки кода при ревью? Можно воспользоваться инструментами статического анализа. Возьмём для примера OrcaSlicer — популярную программу, которая подготавливает 3D-модель к печати. Заглянем внутрь и посмотрим, какие сюрпризы нас ждут.
Посмотрим на одно из предупреждений статического анализатора PVS-Studio:
V1047 Lifetime of the lambda is greater than lifetime of the local variable ‘do_stop’ captured by reference. FillBedJob.cpp 250
Лямбда-выражение захватывает локальную переменную do_stop по ссылке, а затем сохраняется в params.on_packed. При этом do_stop уничтожается при выходе из метода process, так как заканчивается время жизни локального объекта. Если лямбда будет вызвана после выхода из этой функции-члена, произойдёт обращение к разрушенному объекту, и поведение в этой ситуации не определено.
Можно было бы сделать захват по значению, но в этой лямбде происходит перезапись переменной do_stop, а значит такой вариант не подходит. Поэтому можно сделать do_stop членом класса FillBedJob.
Это лишь один фрагмент, показывающий, что даже в работающем продукте могут быть ошибки. А другие опасные места в коде OrcaSlicer разобрали в новой статье.
Если вы тоже хотите минимизировать ошибки в своих проектах, сделайте статический анализ частью регулярного процесса, а поможет с этим PVS-Studio.
Узнайте, как использовать новые требования к КИИ как конкурентное преимущество
Работаете с ГИС или объектами КИИ и ищете способ выполнить регуляторные требования, не теряя в гибкости и скорости? Эксперты Cloud.ru разберут, как облачная инфраструктура закрывает вопросы защиты и при этом становится реальным инструментом развития.
На вебинаре разберем:
Актуальные изменения в требованиях к ГИС и КИИ — что важно учесть прямо сейчас.
Какие сценарии возможны с решением «Облако для КИИ» и что оно дает.
Способы применения: от защищенной инфраструктуры до ускорения цифровых сервисов.
Будет полезно инженерам инфраструктуры, руководителям ИБ-направлений, менеджерам цифровой трансформации и всем, кто планирует работать с ГИС и КИИ.
📅 Когда? 7 июля в 11:00 мск.
📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикеру в прямом эфире.
Вебинар уже через 20 минут: расскажем, как защищать данные в S3
В 12:00 мск на вебинаре разберем все: от базовых Bucket Policies и версионирования до продвинутых Conditional Write, Object Lock (WORM) и клиентского шифрования. Расскажем, как комбинировать эти инструменты для защиты от случайного удаления и кибератак. Объясним, как соответствовать регуляторным требованиям. Вебинар практический, так что вы увидите реальные примеры настройки S3 через API и CLI.
Вы узнаете
Какие уровни защиты данных в S3 существуют
Как настраивать версионирование, Conditional Write, Object Lock, шифрование с реальными командами и примерами кода
Какие границы и подводные камни существуют у каждого инструмента
Как комбинировать механизмы для защиты от ransomware, случайного удаления, взлома ключей и соответствия 152-ФЗ
Приглашаем на вебинар "Информационная безопасность корпоративных систем: практика, требования ФСТЭК и опыт Luxms BI"
Дата и время: 2 июля, четверг, в 16:00 по мск
Информационная безопасность сегодня — базовое требование, а не «опция». Основные угрозы — не "суперхаки", как в кино, а системные слабости: небезопасные сборки, слабый контроль доступа, уязвимости, и, конечно же, человеческий фактор.
На вебинаре эксперты Техконсур, ГИС, Аренадата, РОССИННО и Luxms BI обсудят современные угрозы для корпоративных систем, практику применения уровней доверия ФСТЭК и подходы к разработке и эксплуатации защищенного программного обеспечения:
как изменился ландшафт угроз для корпоративных систем в 2026 году;
для каких организаций и проектов действительно важны уровни доверия ФСТЭК;
как требования регулятора влияют на процессы разработки, сборки и поставки программного обеспечения;
какие механизмы контроля, протоколирования и администрирования необходимы современной корпоративной платформе;
как выстроить развитие продукта с учетом требований информационной безопасности.
Frontend-приложения (личные кабинеты, онлайн-банки, маркетплейсы, сайты, лендинги и т. д.) выполняются в браузере пользователя — традиционной "слепой" зоне для безопасности. В вебинаре рассмотрены актуальные угрозы, крупнейшие инциденты, построение модели угроз и то, как применение анализатора класса FAST (Frontend Application Security Testing) снижает риски и делает frontend-приложения безопасными. Объясняется, почему классические анализаторы имеют низкую достоверность для frontend-приложений, и как использовать FAST-анализатор в процессах РБПО по ГОСТ Р 56939—2024.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Эффект замыленного глаза: как бороться с выгоранием просматривая тысячу файлов в день
Привет читатели! Первая статья залетела неплохо, а значит я, Катя DLPшка, пишу все это не просто так. И пока собираюсь с мыслями для следующей статьи, поделюсь личными лайфхаками
Я уже писала, что работаю аналитиком в информационной безопасности и отвечаю за DLP-систему. В целом всё нравится. И хотя смотреть логи по восемь часов в день – это порой забавно, но чаще все-таки монотонно и муторно. Для себя я выделила три режима просмотра инцидентов, и к каждому у меня припасен свой антидот от выгорания
№1: «В офисе штиль» (или когда все пользователи вымерли)
Бывает такое: тишина, ни одного алерта, продуктивность упала ниже плинтуса. Я просмотрела все отчеты, файлы и настройки, а делать ну совсем нечего. Скука смертная. Особенно перед праздниками
Как говорила моя мама: лучший отдых – это смена деятельности. И пока пользователи пытаются расшевелиться, я переключаюсь на другие задачки. Ну и, конечно, занимаюсь своим любимым офисным развлечением – социальной инженерией в мирных целях. Люблю наблюдать за коллегами, например, кто под какой трек работает, а кто забыл заблокировать экран, уходя на обед... Если вижу беззащитный монитор, то ставлю на рабочий стол обои с огромным кабачком хехехе. Наказания могут быть веселыми.
№2: «Шквальный огонь» (глаза в кучку)
А бывает наоборот: сотрудников много, алерты прилетают в бесконечном режиме, как из пулемета. Вы, конечно, скажете: «Настрой правила получше, и будет тебе счастье». Но давайте не забывать то, что сегодня считается утечкой, завтра уже нормальный рабочий сценарий (кстати если хотите статью или пост про False Positive, то опишитесь в комментах). В такие моменты замыливаются не только глаза, но и мозг плывет 🫠 Но я не расстраиваюсь, делаю вдох-выдох и следую паре простых правил:
Меняю фокус. Не смотрю на один и тот же тип алертов часами. Отсмотрела скриншоты – переключилась на переписку, потом на файлы. Мозгу нужна встряска
Использую таймер. 40 минут работы – 5 минут отдыха с шортсами или кофе. Серьезно, метод Pomodoro спасает даже в ИБ
Включаю фон. Если не нужно вслушиваться в аудио – музычка или подкаст помогают не сойти с ума от бесконечной ленты событий
№3: «Режим детектива» (мой личный кайф)
Этот вид вырастает из второго. Среди потока находится что-то странное: файл или кусок сообщения. И тут начинается мое любимое – я превращаюсь в Шерлока. Ищу зацепки: слежу за временными рамками, смотрю, какие сайты посещались незадолго до алерта, с кем велся диалог, какие файлы открывались параллельно.Самые очевидные вещи лежат на поверхности, а ты их в упор не видишь. Можно, конечно, по тысяче раз все перепроверять, но тогда есть риск упустить уже новые события.
Мой лайфхак: взять листок бумаги и, как в старые добрые, начать выписывать всё, что нашла. Одно дело – держать улики в голове, и совсем другое – видеть их на бумаге, соединять стрелочками и кружочками. Графическое представление помогает выстроить цепочку событий и быстрее придумать, куда копать дальше.
тупо я
P.S. Для самых дотошных: свои «записки сумасшедшего» я храню в шкафчике под ключом, а когда они больше не нужны – кидаю в шредер, которй стоит прямо у моего стола. Конспирация? Нет, проф деформация)
Надеюсь, теперь вы не пойдете по каноничному путь зумера: новая работа → выгорание за три месяца → увольнение → новая работа.
P.S.S А я уж точно, слишком мне нравится нынешний коллектив, а молодая девушка-руководитель тем более. Мы с ней примерно из одного поколения, поэтому говорим на одном языке: она не давит бюрократией, а наоборот, с искренним интересом поддерживает любые мои инициативы, даже самые безумные. Это сильно меняет отношение к работе
Среди радиолюбителей и SDR-энтузиастов самой желанной "игрушкой" является продукция компании Ettus Research (работающей под брендом NI). Их оборудование USRP: Universal Software Radio Peripheral, Универсальное программно-определяемое радиоустройство - представляет собой если не эталон, то близкий к идеалу образец программно-определяемого радио.
Цена у аппарата соответствующая: за самый бюджетный и уже устаревший USRP B200 компания просит $1.420 (~106.500 руб.), а его обновленная версия USRP B206mini-i стоит $1.820 (~136.500 руб.). Вместе с тем, за продвинутые устройства USRP серии Х можно вполне купить квартиру в ближнем Подмосковье - $51.360, что составляет примерно 3.8 миллиона рублей.
Если все-таки имеется желание и, самое главное, возможность приобрести USRP, я бы предложил заказать его напрямую через друзей из-за границы, так как Российские компании-импортеры устанавливают на них маржу в 2-2.5 раза. Самый дешевый ценник, который я нашел: компания из Екатеринбурга готова поставить USRP B200mini-i за 200.000 рублей, а распространенная сеть радиокомплектующих за абсолютно тот же SDR просит 269.300 рублей...
Но если нельзя, но очень хочется, то можно
На помощь нам в очередной раз приходят поднебесные партнеры: они "разработали" и выпустили на рынок SDR-устройство TZT B200-mini-i. Как заявляет производитель:
плата разработки радиочастотного программного обеспечения USRP заменяет Ettus B200Mini/B210, индекс производительности, соответствует импортированной версии, и ее стабильность лучше
Устройство полностью совместимо со всем программным обеспечением для оригинального Ettus USRP и в компьютере определяется соответствующе. Ценник тоже не может не радовать, который на всех доступных нам маркетплейсах стартует от 38 тысяч рублей, что бюджетно по меркам оригинального.
Что касается качества приема/передачи и чистоты сигнала - ничего не могу сказать, так как сам лично руками не "щупал". Интернет и видеохостинги тоже скупы на обзоры: нашел только 1 (одно) видео, в котором автор хвалит новомодное устройство за качество сигнала, а также Wiki AliExpress, в котором обозревают фактически свой же продукт.
В общем, тут на личное усмотрение, готовы ли вы за китайскую копию отдать 40 тысяч рублей. Лично я уже намучился с аналогом HackRF, с его шумами и кривым приемом, поэтому лишний раз не хочу портить себе нервы. В данном случае я бы посоветовал немного поднакопить, и взять оригинал того же LimeSDR или BladeRF.
🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
Вебинар «Киберустойчивость на основе управления данными», практический сценарий
2 июля в 11:00 проведём вебинар о том, как выстроить управляемую и безопасную работу с данными в корпоративной дата-платформе.
Сегодня одних платформ хранения и обработки данных уже недостаточно: без прозрачности, понимания связей между данными, зон ответственности и рисков такие системы становятся одной из ключевых точек киберриска. На вебинаре разберём, как совместное использование Cardinal Platform и Arenadata Data Catalog помогает выстроить дополнительный слой контроля и повысить киберустойчивость дата-ландшафта.
Что обсудим:
✔️ почему платформы работы с данными становятся зоной повышенного риска;
✔️ какую роль играет каталог данных в обеспечении прозрачности, управляемости и безопасности;
✔️ как интеграция Cardinal Platform и Arenadata Data Catalog позволяет видеть, где находятся данные, кто за них отвечает и как они связаны;
✔️ как выстраивать процессы data governance, контроля доступа, аудита и управления чувствительной информацией;
✔️ как учитывать требования ИБ, регуляторов и внутренних политик;
✔️ как повысить киберустойчивость корпоративной дата-платформы.
Практическая часть
Покажем демонстрационный сценарий, в котором Arenadata Data Catalog используется для управления данными и рисками, а Cardinal Platform — для выстраивания контроля, аудита и дополнительного уровня защиты вокруг дата-платформы.
Для кого: руководители ИТ и ИБ, CDO и владельцы данных, архитекторы, команды data governance и специалисты по безопасной эксплуатации данных.
Спикеры: Мария Двоеносова, владелец продукта Innostage Cardinal Platform; Артем Шмарев, руководитель Центра компетенций по управлению данными, Юникон Бизнес Солюшнс; Денис Кириченко, Архитектор решений Arenadata Catalog.
В середине июня команда киберразведки экспертного центра безопасности Positive Technologies обнаружила сразу несколько ресурсов, использующих «топливную» тему для вредоносных целей.
В рамках первой кампании производится угон Telegram‑аккаунтов. От имени крупной нефтегазовой организации, предоставляющей услуги по продаже топлива физическим лицам, предлагается «забронировать» время для покупки топлива без очередей. В процессе бронирования злоумышленники просят предоставить код подтверждения, который на деле является кодом двухфакторной аутентификации от Telegram‑аккаунта. Отметим, что исходный код ресурсов изобилует комментариями, характерными для кода, сгенерированного большими языковыми моделями.
Вторая кампания заманивает «актуальными» данными о доступности топлива, предлагая скачать APK‑файл. На вредоносном сайте отображается карта со сведениями о наличии топлива на разных заправках по всей стране. Статус заправки на карте при этом определяется детерминированным алгоритмом на основании ее координат:
Под капотом приложения — инфостилер, среди функций которого сбор с устройства фотографий и текущей геопозиции с последующей отправкой в S3-хранилища, что впоследствии может использоваться для шантажа жертвы и иных целей.
Рекомендации
• Не сообщайте третьим лицам и не вводите на сторонних ресурсах никакие коды, приходящие на ваши устройства.
• Не устанавливайте незнакомые мобильные приложения, а если очень хочется — хотя бы предварительно используйте анализ через песочницу (например, в PT Sandbox 😉).
• Относитесь критически к любому ресурсу, обнаруженному в интернете, особенно если он эксплуатирует «горячую» тему.
В ходе бонусного вебинара команда PVS-Studio представила новый продукт — PVS-Studio Atlas, предназначенный для работы с результатами анализа кода: просмотра, аналитики, разметки и формирования отчётов для сертификационных лабораторий и ФСТЭК.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
PVS-Studio — статический анализатор кода для поиска критических и типовых ошибок
Также приглашаю всех познакомиться с нашим статическим анализатором PVS-Studio, который может закрыть не только 10-й процесс ГОСТ Р 56939, но и будет полезен по другим направлениям:
Обучение сотрудников (п.5.2). Формирование у программистов понимание антипаттернов и уязвимых конструкций, что улучшает их техническую экспертизу;
Моделирование угроз и разработка описания поверхности атаки (п.5.7). Дополняет процесс, выявляя потенциальные уязвимости, которые формируют поверхность атаки;
Экспертиза исходного кода (п.5.9). Позволяет усилить проверку стороннего кода, который команда включает в проект. Например, его можно использовать для выбора сторонних библиотек, оценивая качество их кода;
Поиск уязвимостей в программном обеспечении при эксплуатации (п.5.24). Можно просматривать ранее отключённые предупреждения PVS-Studio с целью дополнительного выявления дефектов в коде.
Вышел 8-й номер журнала Paged Out, который включает в себя различные материалы на тему этичного хакинга и информационной безопасности. Издание публикуется в формате: 1 страница — 1 статья. Все остальные Paged Out выпуски можно скачать с сайта проекта.
В вебинаре обсуждается, что на самом деле даёт сертификат и почему он не гарантирует безопасность ПО. Какие программы обязаны проходить проверку, а какие — нет. Чем отличается сертификация от аттестации, и что происходит после получения сертификата. На эти и другие вопросы ответили в бонусном вебинаре цикла с Виталием Вареницей, ведущим специалистом ЗАО "НПО "Эшелон" по сертификации и тестированию на проникновение ПО
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Вебинар «Злоумышленник на крючке: практические кейсы применения Threat Deception Platform»
Злоумышленник не всегда начинает с громкой атаки. Часто он действует тихо: изучает инфраструктуру, ищет доступы, проверяет сетевые ресурсы и пробует подключиться к перспективным системам.
На вебинаре25 июня (с 11:00 до 12:00, онлайн) расскажем, как технологии класса Deception помогают заметить такие действия на раннем этапе с помощью системы ловушек и приманок.
Покажем конкретные кейсы из практики проектов R‑Vision и разберём:
как технологии класса deception дополняют существующие средства защиты;
какие ловушки лучше всего срабатывают на практике;
какие атаки можно обнаружить до развития инцидента;
как работает и какие задачи решает платформа R‑Vision TDP;
как понять, что вашей компании уже нужен этот инструмент.
Отдельно обсудим, как R‑Vision TDP можно использовать в киберучениях для проверки готовности команд реагирования, а также как инструмент подтверждения выполнения регулярных требований.
Вебинар будет полезен руководителям ИБ, специалистам SOC, инженерам по мониторингу и реагированию, а также командам, которые хотят повысить качество обнаружения без сложного и ресурсоёмкого внедрения.
Открытые уроки для прокачки: Linux, backend, ИИ, безопасность и управление
Эта неделя хорошо закрывает сразу несколько рабочих зон: инфраструктуру, backend, безопасность, ИИ, аналитику и управление. Темы подобраны так, чтобы за один открытый урок можно было не просто «послушать про тренды», а разобраться в конкретной задаче: от cache и swap в Linux до проектирования аутентификации, SRE-инцидентов, NLP и системного анализа.
Все уроки бесплатные и проходят с преподавателями-практиками OTUS — можно познакомиться с экспертами, протестировать формат обучения и задать вопросы по теме.
Недопущение реализации угроз безопасности, связанных с эксплуатацией неподдерживаемой версии ПО.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Вот скажите, вы когда-нибудь задумывались, что колеса автомобиля можно взломать? И я сейчас не говорю про "баллоник", домкрат и десяток кирпичей. Возможно для кого-то сейчас будет откровением, но современное колесо это не только металлический диск и резиновая шина, а еще и система TPMS, работающая на частотах 315/443 МГц. Давайте разберемся, что это такое и зачем это вообще нужно.
TPMS - это Tire Pressure Monitoring Systems, что в переводе "Система мониторинга давления в шинах", предназначена для предупреждения водителя о критическом падении давления шин через приборную панель. Изначально система была разработана после серии трагических аварий с участием Ford Explorer и шин Firestone в конце 90-х, когда низкое давление приводило к перегреву, разрывам покрышек и последующим переворачиваниям автомобилей на высоких скоростях. И по сути, введение системы TPMS было реакцией правительства США, издавшее в 2000 году TREAD Act (Transportation Recall Enhancement, Accountability and Documentation), который обязал автопроизводителей оснащать автомобили вышеназванной системой для повышения безопасности, снижения расхода топлива и уменьшения износа покрышек.
Существует 2 типа работы TPMS. Первый, он же "Непрямой мониторинг" использует датчики ABS-системы для контроля скорости вращения колес: при падении давления диаметр колеса уменьшается, оно начинает вращаться быстрее остальных, система фиксирует эту разницу и выдает предупреждение. Но нас интересует второй тип: "Прямой мониторинг". В данном случае датчики установлены в каждом шине (обычно на клапане), измеряют давление и температуру, и передают данные по радиосигналу (обычно на 315/433 МГц) на бортовой компьютер автомобиля. И вот тут вступает в игру SDR со всеми его прелестями ;)
Автор доклада (Stephen Pote) решил проэксплуатировать TPMS и собрал систему наблюдения на основе RF с использованием радио данных. В своей лаборатории он использует микроконтроллеры ESP32 и модули CC1101 для создания сети приемников, которые обнаруживают эти сигналы и отслеживают движение автомобилей. В качестве возможного применения Стивен указывает на управление воротами (разрешение проезда только известным автомобилям с оповещение пользователя по электронной почте или SMS), отслеживание транспорта и картирование маршрутов, контроль потока транспорта вокруг границы участка, а также предупреждение при обнаружении непроверенного автомобиля и отслеживание паттернов движения во времени.
Со своей стороны я вижу атаку типа социальной инженерии, что если необходимо остановить автомобиль (например, с важным лицом компании), можно подать более мощный сигнал о пробитии колеса. Ну а дальше зависит от целей и задач нарушителей, например, передать забытые в офисе документы.
Более подробно в докладе автора, а мы после просмотра можем подискутировать в комментариях на предмет ценности данного исследования.
🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
