Обновить

Информационная безопасность

Сначала показывать
Порог рейтинга

Приходите на вебинар — покажем, как выстроить резервное копирование, которому можно доверять

Бэкап есть почти у всех. Но одно дело — хранить копии, другое — быть уверенным, что при сбое инфраструктура поднимется в нужные сроки и без потерь. Как перейти от «копии существуют» к «восстановление работает»?

Разберем это на совместном вебинаре с экспертами Cloud.ru и оператором ИТ-решений ОБИТ. Будет полезно ИТ-директорам, директорам по ИБ, системным архитекторам, инженерам и администраторам — всем, кто отвечает за сохранность данных в облаке.

Что расскажем и покажем:

  • какие практики резервного копирования актуальны сейчас и в чем их различия;

  • почему классическая стратегия 3-2-1 на практике может не выполнять свою функцию;

  • почему сторонний бэкап становится стандартом, а не опцией;

  • как опыт интегратора влияет на результат — и что меняется, когда интегратор и вендор работают в связке;

  • реальные кейсы: что именно это дает бизнесу.

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

📅 Когда? 26 мая в 11:00 мск.

📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам в прямом эфире.

Теги:
Рейтинг0
Комментарии0

Эхо из прошлого: ошибки архитектуры могут "выстрелить" спустя годы (благодаря WebArchive)

Представьте: 8 лет назад была небезопасная архитектура с IDOR. Т.е. можно было получить доступ к документу просто зная его ссылку. А ссылки чудным образом попали в WebArchive (он же - Wayback Machine). Спустя время архитектуру поменяли и проблема ушла. Но, WebArchive всё помнит: ссылки уже успели сохраниться. И кто-то, спустя многие годы, публикует статью с указанием ссылок на WebArchive, где указаны персональные данные и платёжки клиентов. Внимание, вопрос: успокоит ли общественность реакция в стиле: "да это давно было, сервиса уж нет"?

Вот один из сохранённых по ссылке документа: он сохранился в Wayback Machine в 2018 и до сих пор доступен.

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

Теги:
Всего голосов 1: ↑1 и ↓0+2
Комментарии0

Пару месяцев назад мне довелось поучаствовать в “контрольной закупке” одного из ювелирных магазинов. Обстоятельства были предельно ясные: в комментариях группы магазина в мессенджере Телеграмм стали писать боты и предлагать помощь с выбором украшения. При этом переписку старались перевести в личные сообщения, где уже и началось НЛП. Моя задача была определить, кто этим занимается и есть ли причастность сотрудников компании к данной схеме.

Ну что же, примеряем на себе образ “потенциального потерпевшего” и вступаем в переписку с ботом. Сначала меня игнорируют и недели 2-3 не выходят на связь, а потом долгожданное сообщение в … 4 часа утра! В каком часовом поясе живут лица по ту сторону экрана, я могу только догадываться.
Что было дальше, лучше почитать в прикрепленных скриншотах: как говорится, комментировать - только портить.

С учетом ограничений платформы на загрузку только 1 картинки, всю переписку можно прочитать у меня в группе Телеграм или Макс.

Однако при прочтении прошу обратить внимание на следующие аспе:

  1. переписка велась с моего основного аккаунта, а “Виктория” даже не предприняла попытку установить, кто с ней общается и чем занимается;

  2. адрес доставки и адрес склада совпадают, но у “Виктории” опять ничего не триггернуло;

  3. описание банка, направленное “Викторией”, было сгенерировано ИИ не в ее пользу, так как “она” сама пишет: банк контролируется через иностранные компании и просьба не путать по написанию с другими банками. Но для “Виктории” главное, что офис находится в Москве :)

Естественно, что вся переписка велась при непосредственном контроле со стороны службы СБ заказчика. В качестве дополнительного “прогрева” были даже мысли “нарисовать” платежку с оплатой, но мысли о 327-й УК РФ не давали покоя, поэтому решили не рисковать. Ну и конечно, после окончания взаимодействия были уведомлены СБ Российских банков, где присутствовали счета указанных в переписке дропов.

В общем, как пели кот Базилио и лиса Алиса из кинофильма “Буратино”:

На дурака не нужен нож,
Ему с три короба наврёшь -
И делай с ним, что хошь!

Будьте аккуратны, берегите себя и своих близких.

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии0

Дела становятся еще детектнее, а запуск новой версии PT NAD 13.0 — еще ближе ☄️

Уже 4 июня, ровно в 14:00, команда системы поведенческого анализа сетевого трафика от Positive Technologies — PT NAD — прольет свет на каждый темный уголок вашей инфраструктуры в новом сезоне «Очень детектных дел» (отсылка не случайна).

В этот день вы сможете вместе с нами узнать, как поменяют правила игры:

  • автоматизированное реагирование;

  • облачное детектирование;

  • архивное хранение метаданных.

Чтобы точно все это успеть, вот чек-лист ваших действий прямо сейчас:

1) Отменить все свои планы на 4 июня в 14:00

2) Зарегистрироваться на онлайн-запуск по ссылке

3) С нетерпением ждать встречи вместе с нами.

Увидимся уже скоро! Такие дела.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Сегодня n8n и Dify стали популярными инструментами для создания ИИ‑агентов, автоматизации процессов и интеграции с LLM. Однако при внедрении в крупном бизнесе компании сталкиваются с рядом вопросов: ИБ, отсутствие SLA, юридические ограничения, интеграция с корпоративной средой.

На вебинаре покажем, как использовать возможности n8n и Dify в Enterprise‑контуре с помощью платформы ROBIN — безопасно, легально и с полноценной технической поддержкой.

Обсудим:

  • какие риски возникают при самостоятельном внедрении Open Source решений;

  • как обеспечить соответствие требованиям ИБ и импортозамещения;

  • как связать ИИ‑агентов с корпоративными системами и RPA;

  • как использовать готовые коннекторы и автоматизировать процессы даже в системах без API;

  • реальные кейсы: выставление счетов в 1С через Telegram‑бота (связка n8n + ROBIN) и интеллектуальный подбор оборудования с оформлением заказа в ERP (связка Dify + ROBIN).

Также расскажем о подходе ROBIN к поддержке и сопровождению внешних ИИ‑агентов в корпоративной среде.

20 мая, 11:00онлайн, бесплатно, требуется регистрация.

Теги:
Рейтинг0
Комментарии0

Согласно проекту Zero Day ClockLive, с 2018 года значительно сократилось время от выявления уязвимостей в ПО до начала их активной эксплуатации в продуктивных системах (дельта между публичным раскрытием CVE и первым подтверждённым случаем эксплуатации в реальных условиях).

Теги:
Рейтинг0
Комментарии0

РБПО по ГОСТ Р 56939—2024: вебинар №14 из 30 – Управление доступом и контроль целостности кода при разработке программного обеспечения

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.14. – "Управление доступом и контроль целостности кода при разработке программного обеспечения". На YouTube. Слайды.

Примечание. Во время демонстрации работы GitFlic с PVS-Studio часть срабатываний не попала в SARIF-отчёт, потому что при запуске утилиты plog-converter не был указан флаг -a. Без него утилита включает в отчёт только срабатывания диагностических правил общего назначения уровней 1 и 2. Чтобы сохранить все срабатывания из исходного отчёта, нужно передать флагу -a значение ALL. Подробнее о флагах утилиты plog-converter можно прочитать в нашей документации.

Цели 14-го процесса по ГОСТ Р 56939—2024:

Обеспечение управления доступом к исходному коду и его целостности.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Теги:
Всего голосов 3: ↑2 и ↓1+1
Комментарии0

Dirty Frag (CVE-2026-43284, CVE-2026-43500): Логи, артефакты и правило корреляции

Dirty Frag — это случай, расширяющий класс ошибок, к которому относятся Dirty Pipe и Copy Fail. Поскольку это детерминированная логическая ошибка, не зависящая от временного окна, она не требует состояния гонки, ядро не аварийно завершает работу в случае неудачного эксплойта, а вероятность успеха очень высока

Подробнее можно ознакомиться тут и тут

Пример логов:

<14>2026-05-13T07:46:45.247707+03:00 test_serv auditdrecord: type=MAC_IPSEC_EVENT msg=audit(1778647605.244:144825): op=SAD-delete auid=4294967295 ses=4294967295 src=127.0.0.1 dst=127.0.0.1 spi=3735928356(0xdeadbe24) res=1 AUID="unset"
<14>2026-05-13T07:46:41.600544+03:00 test_serv auditdrecord: type=MAC_IPSEC_EVENT msg=audit(1778647601.596:144762): op=SA-icv-failure src=127.0.0.1 dst=127.0.0.1 spi=3735928360(0xdeadbe28) seqno=200


Итак, с точки зрения защиты нам нужно выявить основные паттерны эксплуатации данного LPE:

1. События IPsec/XFRM в auditd:
Ключевой auditd-артефакт для Dirty Frag - событие c type=MAC_IPSEC_EVENT

Это событие появляется при операциях с IPsec Security Association Database, то есть при создании, удалении или ошибках обработки Security Association. Наиболее интересные значения op:
SAD-add - добавление Security Association;
SAD-delete - удаление Security Association;
SA-icv-failure - ошибка проверки целостности IPsec-пакета.

2. Подозрительный SPI
В публичном PoC для Dirty Frag используется характерный диапазон SPI:
0xdeadbe10, 0xdeadbe11, 0xdeadbe12 ... 0xdeadbeXX

3. Loopback-трафик src=127.0.0.1, dst=127.0.0.1
Это связано с тем, что эксплуатация происходит локально: атакующему не нужен внешний сетевой трафик, он прогоняет специально подготовленные ESP/UDP-пакеты через loopback.

4. Пачка однотипных событий за короткий промежуток времени
Dirty Frag - не одиночное событие. В публичном PoC создаётся серия XFRM SA, по одной на каждый 4-байтный фрагмент записи в page cache. Поэтому вместо одного события обычно будет наблюдаться серия:
SAD-add
SAD-delete
SA-icv-failure
в течение короткого промежутка времени.

Правило корреляции для KUMA:
Время жизни контейнера: 300 сек
Порог срабатывания: 10+ событий

DeviceProduct = 'auditd' AND DeviceEventClassID = 'MAC_IPSEC_EVENT' AND (FlexString2 = ['SAD-add', 'SA-icv-failure', 'SAD-delete'] OR Extra.spi contains '0xdeadbe') AND SourceAddress = '127.0.0.1' AND DestinationAddress = '127.0.0.1'
Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Среди специалистов по информационной безопасности ходит довольно смешной и жизненный мем:

Я инфобезник, поэтому:
• у меня нет социальных сетей
• у меня нет умных устройств
• я не сохраняю пароли в браузере
• я не использую автозаполнение
• все замки исключительно механические
• я заклеиваю веб-камеры на всех используемых устройствах
• не подключаюсь к публичным Wi-Fi
• не кликаю на ссылки • …

Этот список можно продолжать бесконечно, но в каждой шутке, как известно, есть только доля шутки. И ведь действительно, если посмотреть со стороны на свою цифровую жизнь, то можно увидеть, что:
• у меня дома нет умных колонок (только трофейная Маруся, выжившая после проведенных тестирований)
• никаких умных дверных ручек (спасибо, уже пентестили)
• я не знаю свои пароли (потому что они все разные, длиной в 30-40 символов, сгенерированные случайным образом, содержащие все 4 составляющие и хранящиеся специальным образом)
• по возможности использую 2FA (нет, я не параноик, просто соблюдаю минимальную цифровую гигиену)
• не подключаюсь к сторонним Wi-Fi (у меня безлимитный мобильный интернет, поэтому даже и смысла нет в лишних телодвижениях)
• по ссылкам хожу только через режим инкогнито (да и в принципе, почти все вирусы только на Windows, так что тут не страшно)
• а “набитая рука” на фишингах помогает определить зловредное письмо по первым словам заголовка (да, пранки с РикРоллами научили нас не кликать по подозрительным ссылкам лучше, чем повышение осведомленности со стороны ИБ ;)

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

А какие привычки цифровой гигиены используете вы и почему? Делитесь своими советами - давайте проведем внеплановое повышение осведомленности aka awareness!

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

п.с. прошу прощения, если видео было просмотрено на максимальной громкости, не в наушниках и рядом с колонкой Алисы ;)

Теги:
Всего голосов 5: ↑0 и ↓5-5
Комментарии5

В России меньше трети компаний страхуют киберриски

Экспертно-аналитический центр ГК InfoWatch выпустил исследование в «Ущерб от утечек информации и страхование». В нем говорится, что риски киберинцидентов застрахованы менее чем у трети российских компаний (28%), при связанные с подобными происшествиями риски страхуют лишь 15,7% компаний.

Кроме того:

  • штрафы за утечки данных и возможные убытки от выплат вымогателям в России законодательно страховать запрещено;

  • умышленные действия сотрудников не входят в большинство полисов киберстрахования;

  • проблема рынка киберстрахования — сложности с оценкой ущерба от утечек, единой методики не существует.

Подробности на сайте InfoWatch.

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

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

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

Что случилось с cPanel. cPanel — это панель управления хостингом, которую используют сотни тысяч веб-серверов по всему миру. Уязвимость в ней позволяла получить доступ к серверу без логина и пароля. Никакого брутфорса, никакой социальной инженерии — просто прямой вход через дыру в аутентификации.

Детали уязвимости в исходном материале не раскрываются — ни CVE-номера, ни версии, ни механизма. Это важная оговорка: оценить реальный масштаб риска без этих данных сложно. Но факт массовых компрометаций зафиксирован.

Почему шесть лет — это тревожнее самого взлома. Долгое присутствие в тени говорит об одном: группа умела не шуметь. Это не сканирование Shodan и немедленная эксплуатация — это терпеливая работа с избирательными целями. Когда такая группа всё же «засвечивается», обычно это означает либо смену тактики, либо намеренный переход к масштабированию.

Для владельцев хостинг-инфраструктуры и тех, кто держит сайты на shared-хостинге с cPanel, вопрос сейчас не «взломают ли», а «не взломали ли уже». Следы присутствия профессиональной группы могут быть нечитаемы стандартными средствами мониторинга.

  • Проверить версию cPanel и наличие последних обновлений безопасности

  • Поднять логи аутентификации за последние недели — аномальные входы без учётных данных

  • Проверить целостность файлов на сервере (особенно конфиги и веб-шеллы)

  • Если хостинг управляемый — запросить у провайдера подтверждение патча

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

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

TG @CIOlogia

Теги:
Всего голосов 3: ↑2 и ↓1+1
Комментарии0

Microsoft майским Patch Tuesday закрыла 120 уязвимостей — 17 критических, 14 из которых позволяют удалённо выполнить код. Нулевых дней нет, но расслабляться рано.

По данным Anti-Malware от 13 мая 2026 года, в майском пакете обновлений Microsoft исправила 120 уязвимостей. Структура по типам: 61 — повышение привилегий, 31 — удалённое выполнение кода, 14 — раскрытие информации, 13 — подмена, 8 — отказ в обслуживании, 6 — обход защиты.

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

Три CVE которые стоит закрыть первыми. CVE-2026-35421 — уязвимость в Windows GDI. Эксплуатируется через вредоносный EMF-файл, открытый в Microsoft Paint. Да, в Paint. Звучит несерьёзно, пока не вспоминаешь, сколько пользователей открывают вложения именно там.

CVE-2026-40365 — SharePoint Server. Аутентифицированный злоумышленник может удалённо выполнить код на сервере через сетевую атаку. Для корпоративной среды это прямой путь к данным и внутренним сервисам.

CVE-2026-41096 — Windows DNS Client. Контролируемый атакующим DNS-сервер отправляет специально сформированный ответ, вызывает повреждение памяти и добивается RCE. Вектор атаки — сетевой уровень, без какого-либо взаимодействия с пользователем.

Office и предпросмотр как вектор атаки. Отдельного внимания заслуживает пакет патчей для Microsoft Office, Word и Excel. Несколько закрытых уязвимостей позволяют выполнить код при открытии специально подготовленного файла. Часть атак срабатывает через панель предварительного просмотра — то есть файл даже не нужно открывать полностью.

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

  • SharePoint Server — обновить приоритетно, особенно если он смотрит наружу или используется как интранет-портал

  • Windows DNS Client — проверить, применились ли патчи на всех рабочих станциях и серверах в домене

  • Office / Word / Excel — развернуть через WSUS или Intune без ожидания следующего окна обслуживания

  • GDI / Paint — звучит как мелочь, но EMF-файлы гуляют в корпоративной почте чаще, чем кажется

120 уязвимостей за один цикл — это уже не исключение, а норма для Microsoft. Апрельский пакет был сопоставимым. Темп не снижается, и это означает одно: окно между выходом патча и его эксплуатацией в реальных атаках продолжает сжиматься. Кто не успел за 30 дней — играет в другую игру.

TG @CIOlogia

Теги:
Всего голосов 1: ↑1 и ↓0+2
Комментарии0

РБПО по ГОСТ Р 56939—2024: вебинар №13 из 30 – Обеспечение безопасности сборочной среды программного обеспечения

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.13. – "Обеспечение безопасности сборочной среды программного обеспечения". На YouTube. Слайды.

Цели 13-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

P.S. В вебинаре рассказывается, в том числе, про GitFlic. Отмечу, что PVS-Studio совместим с платформой GitFlic. Благодаря этому разработчики могут получать результаты сканирования PVS-Studio напрямую в интерфейсе GitFlic, что упрощает процесс разработки и тестирования.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Ближайшие события

SAST: с чем сталкиваются команды и как это решать

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

▶️ Основные проблемы, которые беспокоят разработчиков:

  • долгие сканирования на крупных кодовых базах;

  • большое количество ложных срабатываний (False Positive);

  • недостаточное покрытие технического стека правилами (False Negative).

▶️ Как решать:

  • выбирайте инструменты, которые отвечают требованиям вашей компании и отрасли;

  • разработайте набор правил под конкретный проект;

  • редактируйте встроенные правила в продукте;

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

▶️ Что лучше выбрать: коммерческий или некоммерческий SAST- сканер?

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

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

Обычно, чтобы определиться с выбором SAST-инструмента, команды проводят пилот: сравнивают решения по функциональности и качеству детекта. Максимальный эффект от решения достигается тогда, когда выстроен процесс тестирования с настройкой правил, метриками и понятными критериями эффективности.

Теги:
Рейтинг0
Комментарии0

10 мая 2026 года OpenAI объявила Daybreak — связку GPT-5.5 и Codex, которая ищет уязвимости в репозитории, валидирует их в sandbox и предлагает патч в один клик.

GPT-5.5, вышедший 23 апреля 2026-го, стал первой моделью OpenAI, перешагнувшей порог «High» по кибервозможностям согласно собственному Preparedness Framework компании. Поверх него — Codex как агентный harness, который работает напрямую с кодовой базой. Вместе они и составляют Daybreak.

Три уровня доступа и один жёсткий порог. Базовый тир — GPT-5.5 для общих сценариев, без особых ограничений. Средний — Trusted Access for Cyber (TAC): secure code review, triage уязвимостей, анализ малвари, detection engineering, валидация патчей. К моменту анонса в TAC уже числились тысячи верифицированных одиночных защитников и сотни команд.

Верхний тир — GPT-5.5-Cyber, представленный 7 мая 2026-го. Это «cyber-permissive» вариант флагмана: не умнее, но менее склонен отказывать на запросы про крафт пейлоадов, воспроизведение эксплойтов в лабораторных условиях и реверс бинарей. Выдаётся точечно. С 1 июня 2026 года потребуется phishing-resistant аутентификация — OpenAI явно не хочет, чтобы этот SKU воспринимался как обычная подписка.

Что это даёт в реальном pipeline. Если стек уже завязан на Codex или ChatGPT Enterprise, Daybreak встраивает непрерывный security-loop прямо в CI/CD: модель строит threat-модель из репозитория, валидирует уязвимости в sandbox, генерирует патч через Codex. Для open-source мейнтейнеров OpenAI обещает pro bono сканирование — по аналогии с Aardvark в private beta осенью 2025-го, которая дала 10 CVE по итогам responsible disclosure.

Контекст запуска не случаен: IBM X-Force в 2026 году зафиксировал рост атак на публичные приложения на 44% год к году, CrowdStrike — рост активности AI-усиленных противников на 89%. Anthropic продвигает Claude Mythos с фокусом на безопасность, но без публичного доступа; Google — CodeMender; стартап XBOW занимает свою нишу. Daybreak при этом позиционируется как первый массово развёрнутый агент для defense-команд от ведущего AI-вендора.

Интереснее всего здесь не сама модель, а архитектурное решение: OpenAI разделила «умеет» и «разрешено» на уровне продуктовых тиров с верификацией личности. Это прецедент — раньше ограничения были только техническими (system prompt, фильтры). Теперь доступ к определённым возможностям привязан к идентификации пользователя. Насколько это удержит модель от злоупотреблений — покажет практика.

TG @CIOlogia

Теги:
Рейтинг0
Комментарии0

Представлен бесплатный сервис Filescan, который работает прямо в браузере и проверяет любой сайт или файл на вирусы:

  • работает со всеми типами файлов, включая картинки, видео, apk и exe;

  • запускает приложения в песочнице и смотрит на его поведение;

  • ищет в сигнатуры вредоносных объектов и подозрительный код;

  • при этом работает быстро — разбор задачи занимает несколько секунд;

Теги:
Всего голосов 3: ↑3 и ↓0+5
Комментарии0

Представлен сервис «taken.» который позволяет оценить, какую информацию о вас знают сайты в интернете. Спойлер: они знают буквально всё — от вашего местоположения до точных настроек системы, заряда батареи и даже установленных шрифтов.

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии5

Сбалансированные Claude Code Safety Hooks с минимум false positive благодаря AST-парсингу Bash

Наконец-то сделал хуки моей мечты - достаточно безопасные и практически без false-positive. Хуки вымученные, эволюционировали на граблях можно сказать.

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

Соответственно, когда хуков нет совсем или их мало, безопасность хромает - агент может уронить базу, сделать rm rf и тд, а если хуков слишком много , то... вы привыкаете клацать Enter на Allow, уже даже не читая о чем вообще сыр-бор. Поэтому, нужен тонкий баланс и хуками важно закрывать только действительно деструктивные, необратимые или критические действия.

Ну, и сразу второй нюанс - для блоков я предпочитаю использовать ask хуки вместо блокирующих, т. к. агенты нынче слишком умные и получив блокирующий хук, наверняка найдет способ обойти ограничение (особенно если прилетел какой-нибудь prompt-injection), тк хуки обычно весьма примитивны.

Короче-говоря, с учетом всех этих нюансов я написал свои opiniated-хуки, которые сам использую, они максимально сбалансированны по allow/ask с практически нулевым false positive - благодаря парсингу AST, а не regex'ам, которые обычно в хуках. Частично в основе лежит claude-code-safety-net весьма сильно переработанный и дополненный.

Внутри:
1. rmrm/unlink/shred вне cwd, по /etc, $HOME; через sudo, xargs, find -delete, pipe-to-shell.
2. infrakubectl, docker, terraform, helm, gcp.
3. dbDROP/TRUNCATE/DELETE через psql/mysql; redis-cli FLUSHALL/SHUTDOWN, supabase.
4. paas — Railway, Fly, Heroku, Vercel, Netlify с destructive-глаголами (PocketOS-класс).
5. gitreset --hard, clean -fd, checkout . / restore ., branch -D, stash drop/clear, push -f, push --delete.

Ссылка на репо: https://github.com/CodeAlive-AI/ai-driven-development/tree/main/hooks/balanced-safety-hooks

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

Кстати, для простого и корректного управления своими хуками у меня есть отдельный скилл hooks-management, который теперь поддерживает Claude Code, Codex и OpenCode.

Если вам нравится такой контент, то не премините заглянуть в мой Telegram канал, в котором я регулярно делюсь всякими полезностями про AI-Driven Development: https://t.me/+A-CrVovS0lczMDVi

Теги:
Всего голосов 3: ↑2 и ↓1+1
Комментарии0

Чтение книг расширяет наш кругозор, заставляя мозги работать и восполняя пробелы в “белых зонах”. Сегодня в рубрике “что почитать” мы поговорим про книгу Алексея Усанова “Реверс-инжинириг встраиваемых систем”.

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

Структурно книга состоит из 6 глав, охватывающие различные направления программно-аппаратного хакинга: первичный анализ, получение прошивки, статистический и динамический анализы, механизмы защиты страиваемых систем и, в качестве дополнения, обустройство рабочего места исследователя.

Если говорить про автора, то Алексей более 15 лет занимается исследованиями встраиваемых систем и системной разработкой, является руководителем направления исследований безопасности аппаратных решений в компании Positive Technologies, а также аботал преподавателем на кафедре Информационная безопасность МГТУ им. Баумана.

Книгу я дочитываю, поэтому могу смело ее рекомендовать. Приобрести экземпляр можно напрямую у Издательства ДМК за 1749 рублей, но советую поторопиться, так как тираж у книги всего 200 экземпляров.

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Теги:
Всего голосов 4: ↑4 и ↓0+4
Комментарии3

РБПО по ГОСТ Р 56939—2024: вебинар №12 из 30 – Использование безопасной системы сборки программного обеспечения

Команда ООО "ПВС" совместно с Виталием Пиковым из учебного центра "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.12. – "Использование безопасной системы сборки программного обеспечения". На YouTube. Слайды.

Цели 12-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации, подготовленная Андреем Карповым, доступна по ссылке: ГОСТ56939.РФ.

P.S. Мы регулярно проводим вебинары на различные темы, не обязательно связанные с РБПО. У нас появился подкаст «Разбаговка»! Приглашаем слушать и принять участие в качестве гостя.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0