Обновить

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

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

РБПО по ГОСТ Р 56939—2024: вебинар №26 из 30 — Сертификация ПО согласно требованиям ФСТЭК и МО

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Мы добрались до дополнительных (бонусных) вебинаров цикла. Рассмотрим "Сертификация ПО согласно требованиям ФСТЭК и Минобороны". На YouTube. Слайды.

В вебинаре обсуждается, что на самом деле даёт сертификат и почему он не гарантирует безопасность ПО. Какие программы обязаны проходить проверку, а какие — нет. Чем отличается сертификация от аттестации, и что происходит после получения сертификата. На эти и другие вопросы ответили в бонусном вебинаре цикла с Виталием Вареницей, ведущим специалистом ЗАО "НПО "Эшелон" по сертификации и тестированию на проникновение ПО

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

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

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

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

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

Теги:
+4
Комментарии0

Вебинар «Злоумышленник на крючке: практические кейсы применения Threat Deception Platform»

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

На вебинаре 25 июня (с 11:00 до 12:00, онлайн) расскажем, как технологии класса Deception помогают заметить такие действия на раннем этапе с помощью системы ловушек и приманок.

Покажем конкретные кейсы из практики проектов R‑Vision и разберём:

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

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

  • какие атаки можно обнаружить до развития инцидента;

  • как работает и какие задачи решает платформа R‑Vision TDP;

  • как понять, что вашей компании уже нужен этот инструмент.

Отдельно обсудим, как R‑Vision TDP можно использовать в киберучениях для проверки готовности команд реагирования, а также как инструмент подтверждения выполнения регулярных требований.

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

Регистрируйтесь, чтобы присоединиться к вебинару.

Теги:
+3
Комментарии0

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

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

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

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

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

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

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

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

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

Теги:
+3
Комментарии0

Вот скажите, вы когда-нибудь задумывались, что колеса автомобиля можно взломать? И я сейчас не говорю про "баллоник", домкрат и десяток кирпичей. Возможно для кого-то сейчас будет откровением, но современное колесо это не только металлический диск и резиновая шина, а еще и система 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 | 📝 Хабр | 💙 ВКонтакте

Теги:
+3
Комментарии5

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

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

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

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

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

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

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

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

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

Теги:
+3
Комментарии0

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

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

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

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

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

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

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

Теги:
+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

Когда мы слышим истории про взлом высокотехнологического оборудования или АСУТП промышленного предприятия (например ядерного реактора как это произошло со 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
Комментарии0

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

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

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

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

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

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

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

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

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

Теги:
+3
Комментарии0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги:
+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 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились. 

Теги:
+5
Комментарии0

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

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

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

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

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

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

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

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

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

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

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

Теги:
+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, мониторинг, сегментацию, реагирование.

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

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

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

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

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

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

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

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

На практике:

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

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

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

Если вы:

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

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

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

Теги:
+1
Комментарии0

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

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

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

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

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

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

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

P.S.

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

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

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

Теги:
+3
Комментарии0

В VS Code обнаружена 0-day уязвимость для кражи токенов GitHub

Исследователь безопасности Аммар Аскар опубликовал детали критической уязвимости в Visual Studio Code, позволяющей перехватывать токены GitHub OAuth. PoC-эксплоит уже в открытом доступе.

Уязвимость затрагивает механизм авторизации через GitHub в VS Code. При подключении аккаунта редактор получает OAuth-токен с правами на репозитории пользователя. Проблема в том, что токен можно перехватить через специально подготовленное расширение или внешний процесс.

Как сообщает xakep.ru, Аммар Аскар продемонстрировал работающий эксплоит. Атака строится на том, что VS Code хранит токены в памяти процесса без должной изоляции. Злоумышленник может получить доступ к токену через API расширений или прямое чтение памяти, если у него есть локальный доступ к машине.

Проблема особенно актуальна для CI/CD-окружений и удалённой разработки, где VS Code часто используется на shared-инфраструктуре. Украденный токен даёт полный доступ к приватным репозиториям, возможность коммитить код и менять настройки проектов.

Microsoft пока не выпустила патч. Временное решение — отозвать токены через настройки GitHub и переключиться на SSH-ключи для работы с репозиториями. Для команд с жёсткими требованиями к безопасности имеет смысл временно ограничить использование OAuth в VS Code через корпоративные политики.

Уязвимость подтверждает давний тезис: IDE с богатой экосистемой расширений — это огромная поверхность атаки. Изоляция между расширениями и ядром редактора остаётся слабым местом большинства современных инструментов разработки.

TG @CIOlogia

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

РБПО по ГОСТ Р 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