Обновить

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

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

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

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

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

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

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

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

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

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

🍔 Свободная касса для взлома

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

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

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

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

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

Standoff 17 проходит в Кибердоме прямо сейчас и продлится до 19 июня.

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

Более 400 пакетов для Arch Linux распространяли руткит и инфостилер

Экосистема Arch Linux пострадала от масштабной атаки, которая затронула сотни пакетов в репозитории AUR

 — Злоумышленники перехватили управление заброшенными проектами, сохранили их названия и историю изменений, а затем изменили PKGBUILD-файлы таким образом, чтобы при сборке пакета загружалась и запускалась малварь

 ❗️ В результате пользователи сами запускали вредоносную полезную нагрузку при сборке пакетов

Вредонос похищал cookie, токены и данные локального хранилища Chromium-браузеров, извлекал информацию из Slack, Discord и Microsoft Teams, воровал токены GitHub, npm, HashiCorp Vault и OpenAI, а также SSH-ключи, историю шелл-команд, VPN-профили и учетные данные Docker и Podman

Украденные данные передавались на внешний сервер, а связь с управляющей инфраструктурой злоумышленников была организована через Tor

Этичный хакер

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

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

9 июня 2026 года Вера Менс (Vera Mens) из TEAM82 опубликовала большое исследование по атаке на источники бесперебойного питания (ИБП) от известной компании Vertiv. Коллега выявила 2 критические уязвимости в сетевых картах вендора, каждое с оценкой 9.8 баллов по шкале CVSS:
CVE-2025-46412 - обход аутентификации, позволяющей атакующему получить доступ к оборудованию через Web-интерфейс;
CVE-2025-41426 - переполнение буфера, позволяющее выполнить произвольный код на уяязвимом устройстве.

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

Не могу не обратить внимание на этический аспект команды TEAM82, которые перед публикацией статьи связались с вендором и передали все наработки. Компания Vertiv приняла отчеты, подтвердила наличие уязвимостей и выпустила патчи для уязвимых плат: Liebert RDU101 (патч v1.9.1.2_0000001) и IS-UNITY (патч v8.4.3.1_00160). К счастью, эксплойты не опубликованы, так что кто еще не успел обновиться - могут не переживать за скрипт-киди и веерные проверки на доступность.

Не устану посторять это каждый раз: не используйте интернет и беспроводные технологии на объектах АСУТП. Исключительно изолированный внутренный контур с доступом по проводам.

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

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

РБПО по ГОСТ Р 56939—2024: вебинар №23 из 30 — Реагирование на информацию об уязвимостях

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.23. — «Реагирование на информацию об уязвимостях». На YouTube. Слайды.

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

Обеспечение выявления и устранения уязвимостей при эксплуатации ПО.

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

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939–2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая «Методика ВУ и НДВ в ПО». См. заметку «Методика выявления уязвимостей и недекларированных возможностей — 2026».

НЕкурс про РБПО

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

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

Что было на встрече РКН с ИТ-отраслью, или «Если у вас всё работает — чего вы переживаете?»

Есть встречи, после которых хочется что-то изменить. А есть встречи, после которых хочется нервно покурить (хотя я не курю). Недавнее совещание (08.06.26) РКН с представителями ИТ-отрасли — из второй категории. Ниже краткая выжимка, что там было, чтобы вы были в курсе происходящего в кулуарах.

Встречу давно обещали и вот собрали. Без повестки, без списков, без резолюции — видимо, чтобы не выносили наружу. Не помогло: слили всё что было. Так что просьбу «не выносить в СМИ» можно класть на ту же полку, где лежит просьба не пользоваться Телеграмом. К нему ещё вернёмся.

Открывал собрание замглавы РКН — который как раз отвечает за блокировки. Его логика была проста, как лом: интернет в стране падает, но РКН почти ни при чём. Это дроны, это смежные органы, это иностранцы — все вокруг. А ТСПУ? Ну да, и оно немножко (верим?).

Дальше заговорил чиновник отвечающий за Центр мониторинга, и принёс три «гениальные» идеи. Перед чтением дальше, лучше сядьте и не пейте ничего, чтобы не подавиться от смеха, если что — я предупредил.

  1. Подключайтесь к Центру мониторинга. Добровольно, без ответственности, как жест доброй воли. Вы только опишите всю свою инфру — а насколько подробно, мы потом сообщим. Как в анеке: вы пока разденьтесь, а доктор потом решит, нужно ли.

  2. Построим свой репозиторий кода — на случай, если нас отрубят от внешнего. Аргумент про единую точку отказа (хакерская мечта просто) — в расчет не берется. Разраб из зала: даже США не смогли такое сделать. Другой чиновник РКН парирует: «А Китай смог». Аргумент зала о том, что китайцы всё равно сидят в опенсорсе — остался без ответа.

  3. Сделаем госVPN с маскировкой — прятаться от западных фильтров. Зал заметил, что такой обход заблочат за полдня, как сейчас блочат всё русское. Замглавы РКН ответил, что «можно же сделать правильно». И добавил, что DPI у нас самый крутой в мире. То есть свой VPN мы спрячем гениально, а пять тысяч чужих ловим по протоколам пачками, роняя пол-Рунета ложными срабатываниями. Двойные стандарты даже не маскируются.

И тут — лучший диалог вечера:

Зал: а кто вообще решает, что блочить?
Замглавы РКН: мы боремся с порно и педофилией, а остальное — другие органы, вы же все понимаете кто.
Зал: не понимаем. Кто?
Замглавы РКН: на этот вопрос я ответить не могу.

Миллионы людей в стране на VPN'ах, гора заблоченных сервисов — а на вопрос «кто это устроил» уполномоченный орган разводит руками, как пойманный за руку гардеробщик.

Апофеоз — про Телеграм:

Зал: результат-то есть? Телеграм заблокировали?
Замглавы РКН (с гордостью): да, конечно.
Зал: коллеги, поднимите руки, кто всё ещё пользуется. — Поднимает весь зал.
Замглавы РКН: так если у вас всё работает, чего ж вы переживаете? Значит, мы не такие плохие.

Я думаю, что это не оговорка, а мировоззрение. Заблокировали так, что заработало лучше прежнего, — и записали себе в плюс. Это звучит как нелепая шутка, но это не она.

По итогам решили встречаться раз в две-три недели и обсуждать госVPN. И снова просили не болтать в прессе (ну конечно). На «зачем вы блокируете вот это» договорились не отвечать никогда — но обещали как-нибудь привести смежников из ФСБ. Горю желанием посмотреть, как они объяснят свою компетенцию.

Что в сухом остатке

Встречу собрали для галочки. Наверх уйдёт ровно это: «с отраслью встретились, проблемы обсудили, взаимопонимание нашли, всё хорошо».

Острые вопросы задать не дали — что выходит за «компетенцию», РКН не обсуждает. 149-ФЗ и закон «О связи» соблюдать никто не собирается: работают по телефонному праву, а кто звонит — секрет фирмы.

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

«ГосVPN» и «отечественный репозиторий» отрасли не нужны и технически мертворождённы — но на них упрямо настаивают: надо же хоть что-то изображать. ИБД в чистом виде.

Такие вот дела 🤷🏼

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

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

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

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

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

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

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

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

P.S. Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились. 

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

Приглашаем на Ozon Tech CyberSec Meetup 17 июня

Привет, Хабр! Собираемся большой компанией в нашем любимом лофте, чтобы рассказать об актуальном в кибербезе: от технических вызовов до романтики CTF.

17 июня | офлайн в Москве + онлайн-трансляция 

В программе 4 доклада, кофе-брейк, традиционно много качественного общения и один особенный интерактив — Cyber Match. В течение вечера вы сможете пообщаться с руководителями разных команд в формате 1х1, задать вопросы о карьере и не только. 

Темы встречи: 

  • удалённый доступ и его безопасная организация на практике; 

  • patch management на рабочих станциях и наш опыт разработки и применения; 

  • процесс разбора ИБ-событий и принятия решений на первой линии; 

  • организация CTF среди сотрудников и важность соревнований для компании.

Приходите лично или подключайтесь к трансляции.

Только сначала зарегистрируйтесь по ссылке и до встречи на митапе!

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

Страх как продукт: почему мы до сих пор продаём ужас вместо ценности


Рынок ИБ до сих пор продаёт не защиту, а спокойный сон до следующего квартала. Страх стал валютой - от отчётов «80% компаний под угрозой» до тепловых карт, где всё красное. Ниже — ещё более сжатая выжимка: как устроена эта машина страха и чем её заменить.

Как страх стал главным продуктом:

Доказать эффект от ИБ трудно: мало данных, спорные методики, внутренняя политика сильнее формул. В результате страх стал универсальным инструментом: случился инцидент - рынок завален продуктами и отчётами «как раз от такой угрозы».

Классика жанра:

  • Вирус уровня WannaCry использует старые уязвимости, но продаётся как «новая эра вымогателей и уникальных защит».

  • Отчёты «80% компаний под угрозой» строятся на кривых опросах своей аудитории и заканчиваются «запросите демо/пилот».

FUD даёт краткосрочное внимание, но в долгую убивает доверие и либо ведёт к хаотичным покупкам «серебряных пуль», либо к апатии: всё кажется одинаково страшным.

Чеклист для CISO:

На любую страшилку ответьте:

  1. Какой конкретный сценарий атаки описан?

  2. Какова вероятность и ущерб именно для нашей компании?

  3. Что изменится в нашей модели угроз, если мы это купим/внедрим?

Если хотя бы на один пункт ответа нет - это продажа эмоции, а не безопасности.

Иммунитет CEO и красные тепловые карты:

У многих CEO уже аллергия на FUD-слайды «Россия в топ‑3 по атакам» и «каждая вторая компания пострадала».В ответ безопасники приносят тепловые карты, где половина клеток ярко‑красные.

Что реально происходит:

  • Красный цвет мгновенно бьёт по инстинктам, один слайд перекрывает пачку таблиц.

  • Но карта «всё красное» без чисел - это эмоциональный шантаж ради бюджета, а не управление рисками.

Что можно поправить быстро:

  • У каждой «красной зоны» должны быть: сценарий, диапазон потерь и время простоя.

  • Вместо абстрактных рейтингов - 2–3 реально возможных для вашего бизнеса кейса с понятными цифрами.

Медиа и «исследования»: аналитика или хоррор:

ИБ‑медиа и вендорские отчёты - крупная шестерёнка машины страха.
По оценкам редакторов, 90–95% исследований делаются ради продвижения продукта: методика мутная, цифры разных отчётов по одной теме могут расходиться на порядки.

Полезно:

  • Читать аналитику по реально эксплуатируемым уязвимостям и zero‑day в массовых продуктах.

  • Разборы реальных инцидентов - их мало, но именно они меняют практику.

Вредно:

  • Разгонять фейки, неподтверждённые сливы и «80% под угрозой» без описания выборки.

Фильтр для отчётов

Один вопрос: «Эта цифра способна изменить наше решение?»
Если нет - перед вами маркетинг, а не аналитика.

Регулятор против хакера: чей страх сильнее:

У российского заказчика два фронта: хакеры и регулятор.

Факты:

  • 60–70% бюджетов ИБ уходит на комплаенс (приказы, ГОСТы, 152‑ФЗ, отраслевые требования).

  • Остаток - на «живую» защиту: SOC, мониторинг, сегментацию, реагирование.

Почему страх регулятора побеждает:

  • Атака - вероятностна, может и не случиться.

  • Проверка - гарантирована, с датой и понятными санкциями.

Мини-действие

  • Разложите бюджет на «комплаенс» и «реальную защиту».

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

Как уйти от продажи страха к продаже ценности:

Нужный сдвиг: от управления страхами - к управлению рисками и бизнес‑ценностью.

На практике:

  • Переводите «страшно» в «сколько стоит и что конкретно делаем в ответ».

  • Привязывайте ИБ к бизнес‑метрикам: простои, выручка, операционные издержки, скорость изменений.

  • Используйте новости и инциденты как материал для обучения и улучшений, а не как повод продавить очередную «серебряную пулю».

Если вы:

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

  • Хоть раз в неделю спросите команду: «Мы сейчас управляем риском или реагируем на хорошо проданный страх?» - значит, вы уже выходите из режима «страх как продукт» и начинаете говорить с бизнесом на взрослом языке.

А у вас решения по ИБ сейчас чаще объясняют «по регулятору надо», «видели страшный кейс» или нормальным разговором про риски и деньги?

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

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

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

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

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

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

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

P.S.

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Их можно смотреть на ускорении. Однако даже в этом случае с учётом дополнительных материалов и отсылок на внешние ресурсы изучение займёт около двух рабочих недель.

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

Подробнее: НЕкурс про разработку безопасного программного обеспечения (РБПО).

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

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

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

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

Организация приёмки ПО с целью недопущения недостатков кода ПО перед его предоставлением пользователям.

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

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

P.S.

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Их можно смотреть на ускорении. Однако даже в этом случае с учётом дополнительных материалов и отсылок на внешние ресурсы изучение займёт около двух рабочих недель.

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

Подробнее: НЕкурс про разработку безопасного программного обеспечения (РБПО).

P.P.S. Знакомство с ГОСТ Р 56939-2024 – всё более актуальная задача

Информационное сообщение ФСТЭК России от 28 мая 2026 г. N 240/24/3693.

Разработчикам программного обеспечения средств защиты информации рекомендуется использовать положения настоящей Методики для организации внутренних процессов жизненного цикла программного обеспечения в соответствии с ГОСТ Р 56939-2024 "Защита информации. Разработка безопасного программного обеспечения. Общие требования". 

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

Помните год назад вышло беспрецедентное судебное решение Верховного Суда РФ за номером 5-КГ25-30-К2, которое призвало увеличить цифровую безопасность в Интернете и свести к минимуму мошенничество в виде оказания услуг под чужим именем? Так вот, после данного решения специалисты по ИБ вспомнили старого друга dnstwist и стали периодически проверять свой домен на наличие клонов-фишингов.Ну и что говорить, я тоже раз в неделю сдувал пыль с утилиты и проверял подозрительные "зеркала".

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

Во-первых, текущее решении кросс-платформенное, так как реализовано на Docker. Поэтому его быстро и легко можно запустить как на Linux, так и Windows с MacOS, а также интегрировать в ваши уже существующие системы мониторинга.
Во-вторых, функционал и настройки выведены в GUI через веб-интерфейс. Это позволяет выводить графику, а именно скриншоты проверяемых доменов, избавляя от необходимости ручной перепроверки.
Также, на лету вносятся отметки о false positive, true positive или домен под продажу (тоже нужно смотреть, чтобы недоброжелатели не выкупили). Данные записываются в SQLite, которую можно легко скачать и интегрировать в свою систему.
В завершение, из глобальных фич: формируется PDF-отчет, который выводит скриншоты фишинговых и доменов на продажу, позволяя быстро и оперативно принимать решение.

Приложение доступно на GitHub под названием 5-KG25-30-K2 на русском и английском языках. Качайте, пользуйтесь и, если есть предложения, контрибьюте. Жду вашей обратной связи и комментариев по утилите.

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

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

Теневой ИИ: как сотрудники сливают данные через ChatGPT и что с этим делать

Сотрудники копируют конфиденциальные данные в публичные нейросети в обход ИТ-служб. В 2025 году объём утечек вырос в 30 раз — зафиксировано 410 млн DLP-срабатываний, связанных с ChatGPT.

Явление получило название Shadow AI — использование публичных ИИ-сервисов без согласования с безопасниками. По данным Zscaler, 77% сотрудников копируют конфиденциальную информацию в промпты, 60% загружаемых PDF содержат чувствительные данные.

Что утекает

  • Исходный код и архитектурные схемы

  • Персональные данные клиентов

  • Финансовые отчёты и коммерческая тайна

  • Внутренняя переписка и служебные документы

Каналы: прямые промпты, загрузка файлов, RAG-инъекции, агентные системы. В 2023 году сотрудники Samsung передали в ChatGPT исходный код оборудования. Обнаружена уязвимость EchoLeak — письмо со специальным содержимым заставляло Microsoft 365 Copilot автоматически отправлять на внешний сервер фрагменты переписки из Outlook.

Регуляторные риски в РФ

Персональные данные граждан нельзя передавать в зарубежные сервисы без согласия (152-ФЗ). Утечка коммерческой тайны, исходного кода и финансовых отчётов нарушает требования 187-ФЗ о безопасности КИИ. Предусмотрены оборотные штрафы и уголовная ответственность по ст. 272.1 УК РФ.

Что делать

Технические меры:

  • Видимость трафика к ИИ-сервисам через корпоративный прокси

  • AI-aware DLP для анализа промптов на лету

  • Защита от prompt injection в собственных ИИ-приложениях

  • Управление агентами и контроль RAG-источников

Организационные меры: чёткие правила использования ИИ, регистрация инструментов, обучение персонала. Главное — предоставить безопасные альтернативы вместо запретов. Запрет без замены приводит к ещё большему теневому использованию.

Проблема системная: сотрудники видят в ИИ инструмент для ускорения работы и не задумываются о последствиях. Задача ИТ — сделать защищённые решения удобнее публичных, иначе теневой ИИ будет расти.

TG @CIOlogia

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

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

Ведение базы уязвимостей NVD NIST было проаудировано Министерством торговли США. NIST обвинили в отсутствии стратегических и своевременных решений по проблеме бэклога NIST NVD, с чем NIST согласился.

По итогам аудита:
1. NIST составит план по борьбе с бэклогом.
2. Будет разработано решение по приоритезации обработки уязвимостей.
3. NIST перестанет рассчитывать CVSS по умолчанию, если он уже есть или нет явного запроса на это или проблем с расчетом. Будет оценена возможность автоматизации этого процесса.
4. Расчет CVSS теперь будет доступен в виде базы.
5. Будет расширен доступ к системе CPE (Common Platform Enumeration, связка уязвимость-конкретная версия продукта) для внешних организаций.
6.Программы NIST и CISA будут скорректированы для исключения взаимного дублирования обогащения уязвимостей одним и тем же исполнителем.
7. Будет разработано новая стратегия коммуникации со стейкхолдерами.

Сам отчёт по аудиту публичный и содержит больше деталей.

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

Атака Shai-Hulud: как скомпрометировали npm-пакеты Red Hat

Инфраструктура публикации пакетов @redhat-cloud-services оказалась под контролем злоумышленников. Десятки зараженных библиотек попали в публичный реестр npm.

Как сообщает Xakep, исследователи в области информационной безопасности зафиксировали атаку на цепочку поставок Red Hat. Целью стали официальные npm-пакеты под префиксом @redhat-cloud-services — библиотеки, которые используются в корпоративных проектах на базе экосистемы Red Hat.

Механика атаки классическая для supply chain: компрометация учетных записей или инфраструктуры публикации. После получения доступа злоумышленники выпустили обновления легитимных пакетов с внедренным вредоносным кодом. Разработчики, обновляющие зависимости через npm install, получали инфицированные версии.

Особенность в используемом инструменте — черве Shai-Hulud. По данным исследователей, в атаке задействован новый вариант под названием Miasma. Shai-Hulud специализируется на горизонтальном распространении внутри npm-экосистемы: заражает один пакет, затем через цепочку зависимостей пытается компрометировать связанные библиотеки и downstream-проекты.

Для проверов: пересоберите lock-файлы, проверьте хеши установленных версий @redhat-cloud-services против официальных сигнатур. Если используете эти пакеты в production — аудит логов сетевой активности на предмет неожиданных соединений. Red Hat, вероятно, уже отозвал скомпрометированные версии, но в локальных кэшах и приватных зеркалах они могут остаться.

Случай напоминает, что доверие к корпоративным пакетам не отменяет базовых практик: dependency pinning, проверка integrity-хешей, мониторинг аномалий в поведении библиотек. Supply chain остается самым уязвимым звеном — компрометация одного аккаунта мейнтейнера дает доступ к тысячам downstream-проектов.

TG @CIOlogia

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

Awesome AI Security Tools

В ходе обсуждений автотриажа Nuclei и других средств анализа защищенности родилась идея собрать в кучу все интересное про AI Cybersecurity. Сказанно #ёПРСТ - сделано!

https://github.com/scadastrangelove/awesome-ai-security-tools

Подборка общедоступных, исследовательских и коммерческих инструментов для обеспечения безопасности ИИ и кибербезопасности с использованием ИИ: автоматическая сортировка угроз, безопасность агентов, цепочка поставок ИИ/машинного обучения, агенты для пентеста, SAST ИИ, фаззинг на основе LLM, анализ угроз, сортировка угроз SOC/SIEM, обратное проектирование, редтим LLM и многое другое.

PS. Набор ключевых слов

  • Autotriage of Security Findings

  • AI Agent & Coding-Agent Security

  • Scanners & Auditors

  • Frameworks, Rule Standards & Benchmarks

  • Runtime Protection & Enforcement

  • AI/ML Supply Chain & Model Security

  • Pentest & Red-Team Agents

  • AI-Powered SAST & Secure Code Review

  • LLM-Driven Fuzzing

  • Harness / target generation

  • Fuzzing the LLM

  • Threat Intelligence

  • Log Analysis / SIEM / SOC Triage

  • Reverse Engineering

  • LLM Red-Teaming & Guardrails

  • Scanners, Evals & Guardrails

  • Prompt-Injection Classifier Models

  • LLM Honeypots & Deception

  • CTF / Exploit / Bug-Bounty Agents & Benchmarks

  • Cloud / IaC / DFIR / OSINT / Phishing

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

Anthropic дал пол года миру на перестройку процессов кибербезопасности

Anthropic обновила свою статью по проекту Glasswing. Glasswing - это проект предварительного доступа к передовой модели Mythos недоступной в общем доступе. Указано расширение объема пилота на 150 новых организации. Обещано расширение программы на 15 стран. Ранее официальный доступ к Mythos был только у организаций в США, что вызывало негатив у других стран.

Не могу не процитировать ключевой, как мне кажется, абзац: “Mythos Preview continues a long-term trend that we’ve been warning about for some time: within 6 to 12 months, we expect that many other AI companies will have Mythos-class models, and they could release them without safeguards that prevent misuse. In that world, cyberattacks could occur much more often, and in much more unpredictable forms. It’s imperative that cyberdefenders adapt to maintain pace.”

Т.е. по оценке Anthropic в период от 6 до 12 месяцев могут появится модели аналогичные по своим возможностям Mythos, но не обязательно, что с таким же щепетильным подходом к безопасности как у Anthropic.

Нужно учитывать, что параллельно днем ранее появилась новость о подаче Антропик “конфиденциальной” заявки на IPO.

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

Сколько кибербезников нужно компании

Наткнулся на неплохую и бесплатную аналитику от Гартнер . В частности данные по штатным единица КБ как функции от ИТ по секторам экономики. И мнению по количеству КБ специалистов как доли от количества работников в компании в целом.

"Midsize enterprises (<1,000 employees): Start with one to three specialists.
Large enterprises (≥1,000 and <10,000 employees): Expand to four to 15 roles.
Extra-large enterprises (≥10,000 and <50,000 employees): Grow to 15 to 50 professionals.
Extra-extra-large enterprises (≥50,000 employees): From 50+ roles, add specialized functions as complexity grows."

Отличная стартовая статья для использования среди прочих материалов при аудите и обоснования штатных единиц Кибербезопасности.

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

В сети появилась утечка Московского портала здравоохранения

— Государственная утечка объемом 87.853.000 строк предположительно произошла в декабре 2025 года

В нее попали: 
  Персональные данные: ФИО, дата рождения, номер телефона, полис ОМС, свидетельство ОМС, СНИЛС, паспорт, дата выдачи паспорта, кем выдан паспорт, полный адрес проживания
  Информация о иностранцах: страна прибытия, аэропорт, дата прибытия
Информация о работе/учёбе: место работы/учёбы, должность/группа, фактический адрес, номер телефона огранизации, офис
  Медицинские данные: мед. организация, категория пациента, отделение прибывания, палата прибывания, наличие симптомов ОРВИ, ФИО врача, номер истории болезней, предварительный диагноз, код МКБ – 10, дата заболевания, наименование лаборатории, срочность анализа, дата взятия и отправки образца, наименование анализа, комментарий врача

 ❗️ Данный взлом является крупнейшей медицинской утечкой в РФ за все время

Этичный хакер

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

Оценка инструментов безопасности с использованием ИИ

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

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

В новом руководстве разбираем пятиэтапную модель безопасности ИИ:

▶️Обнаружение – как получать полную видимость моделей, агентов и данных

▶️ Оценка – как анализировать риски и выявлять уязвимости

▶️ Защита – как контролировать действия ИИ-систем и предотвращать атаки

▶️ Управление – как выстраивать политики, контроль и соответствие требованиям

▶️Измерение – как проверять эффективность защитных механизмов и отслеживать изменения поведения ИИ.

Материал будет полезен директорам по информационной безопасности и командам, которые занимаются внедрением и контролем ИИ-инструментов в компании.

Скачивайте на нашем сайте 🖥

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