Вышел 8-й номер журнала Paged Out, который включает в себя различные материалы на тему этичного хакинга и информационной безопасности. Издание публикуется в формате: 1 страница — 1 статья. Все остальные Paged Out выпуски можно скачать с сайта проекта.
ГОСТ Р 56939-2024 на практике: что мы сделали, чтобы получить сертификат РБПО
🔎 Контекст
У Cloud.ru есть платформа, созданная специально для заказчиков, которые обязаны соблюдать особые требования к хранению данных и разработке ПО. Вся инфраструктура, которую они используют, должна быть аттестована на соответствие стандартам безопасности, а платформенные сервисы должны пройти жесткую проверку у регуляторов. Ранее платформа уже получала сертификат ФСТЭК России №4979, но при внесении определенной массы изменений в продукт, процесс требуется пройти заново, а сделать это невозможно без привлечения сторонней лаборатории и многомесячных ожиданий. Чтобы иметь возможность развивать продукт более оперативно, требовалось сертифицировать не только платформу для создания частного, гибридного или распределенного облака Cloud.ru Evolution Stack, но и все процессы вокруг нее, т.е. подтвердить соответствие ГОСТу Р 56939-2024.
🚀 Задача
Стандарт требует выстроить 25 взаимосвязанных регламентов и поддерживать более 200 артефактов в актуальном состоянии постоянно. Но этого мало: ведь стандарт есть, но конкретной методологии его реализации не существует, нужно было приземлить элементы процесса на орг.структуру нашей компании. Осложнялось всё тем, что в любой крупной ИТ-компании команды непрерывно перетасовываются, ответственные меняются, а любое кадровое изменение должно быть тут же отражено во всей документации сразу.
Аудиторы во время сертификации проверяют всё: опрашивают разработчиков, смотрят трекер задач, оценивают стек применяемых технологий, сверяют, соответствуют ли реальные процессы тому, что закреплено «на бумаге». Соответственно, ситуации, когда документация устаревает быстрее, чем обновляется, а новые исполнители не успевают вникнуть в свои обязанности, нужно было истребить полностью.
☁️ Что мы сделали
Применили существующую в компании BPM-систему как единый источник правды: описали в ней ключевые процессы РБПО, зафиксировали роли, связали их с командами через орг.структуру, разместили все артефакты, точки контроля и указали их взаимосвязи. Следующим этапом автоматизировали конвертацию и публикацию свежих документов: по расписанию из BPM-модели экспортируется HTML, который автоматически конвертируется в Markdown и публикуется во внутреннюю Wiki. Изменился владелец роли — один раз вносишь правки в BPM, все документы актуализируются и тут же становятся доступны всем и каждому. Чтобы новички не впадали в ступор от количества регламентов, поверх Wiki добавили ассистента с RAG под капотом. Можно написать в корпоративный чат любой вопрос и получить структурированную информацию о том, кто за что отвечает и как действовать в любой ситуации, причем сразу со ссылками на конкретный документ в базе знаний.
🦾 Что получили в итоге
В компании появилась полная живая и взаимосвязанная база элементов, включающая организационные единицы, роли, артефакты и инструкции по процессам. То есть на аудите мы показываем не просто набор Word'овских файлов, а живую модель с автоматически собранными артефактами. Каждый сотрудник, причастный к процессу безопасной разработки ПО, четко знает, что в какой ситуации делать и уверен в том, что данные не устарели. ИИ-ассистент сокращает время погружения в регламенты и процессы с дней до пары десятков минут, что значительно упрощает онбординг при смене роли.
Также такой подход позволил снизить затраты на устранение уязвимостей, поскольку их выявление предусмотрено на самых ранних стадиях процесса. Мы получили подтверждение качества платформы и стали первым облачным провайдером в России с сертификатом РБПО. У нас появилось больше контроля над собственным релизным циклом и теперь мы можем планировать обновления на годы вперед.
🧠 Рефлексия
Можем смело рекомендовать аналогичный пайплайн командам, которые:
сами готовятся к сертификации процессов РБПО;
хотят упростить адаптацию сотрудников на новых ролях;
хотят убрать «слепые зоны» из разработки;
ищут способ более предметно демонстрировать работу руководству или инвесторам.
РБПО по ГОСТ Р 56939—2024: вебинар №26 из 30 — Сертификация ПО согласно требованиям ФСТЭК и МО
Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Мы добрались до дополнительных (бонусных) вебинаров цикла. Рассмотрим "Сертификация ПО согласно требованиям ФСТЭК и Минобороны". На YouTube. Слайды.
В вебинаре обсуждается, что на самом деле даёт сертификат и почему он не гарантирует безопасность ПО. Какие программы обязаны проходить проверку, а какие — нет. Чем отличается сертификация от аттестации, и что происходит после получения сертификата. На эти и другие вопросы ответили в бонусном вебинаре цикла с Виталием Вареницей, ведущим специалистом ЗАО "НПО "Эшелон" по сертификации и тестированию на проникновение ПО
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Вебинар «Злоумышленник на крючке: практические кейсы применения Threat Deception Platform»
Злоумышленник не всегда начинает с громкой атаки. Часто он действует тихо: изучает инфраструктуру, ищет доступы, проверяет сетевые ресурсы и пробует подключиться к перспективным системам.
На вебинаре 25 июня (с 11:00 до 12:00, онлайн) расскажем, как технологии класса Deception помогают заметить такие действия на раннем этапе с помощью системы ловушек и приманок.
Покажем конкретные кейсы из практики проектов R‑Vision и разберём:
как технологии класса deception дополняют существующие средства защиты;
какие ловушки лучше всего срабатывают на практике;
какие атаки можно обнаружить до развития инцидента;
как работает и какие задачи решает платформа R‑Vision TDP;
как понять, что вашей компании уже нужен этот инструмент.
Отдельно обсудим, как R‑Vision TDP можно использовать в киберучениях для проверки готовности команд реагирования, а также как инструмент подтверждения выполнения регулярных требований.
Вебинар будет полезен руководителям ИБ, специалистам SOC, инженерам по мониторингу и реагированию, а также командам, которые хотят повысить качество обнаружения без сложного и ресурсоёмкого внедрения.
Регистрируйтесь, чтобы присоединиться к вебинару.
РБПО по ГОСТ Р 56939—2024: вебинар №25 из 30 — Обеспечение безопасности при выводе программного обеспечения из эксплуатации
Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.25. – "Обеспечение безопасности при выводе программного обеспечения из эксплуатации". На YouTube. Слайды. Это последний вебинар про процессы стандарта. Следующие пять будут бонусными.
Цели 25-го процесса по ГОСТ Р 56939—2024:
Недопущение реализации угроз безопасности, связанных с эксплуатацией неподдерживаемой версии ПО.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Вот скажите, вы когда-нибудь задумывались, что колеса автомобиля можно взломать? И я сейчас не говорю про "баллоник", домкрат и десяток кирпичей. Возможно для кого-то сейчас будет откровением, но современное колесо это не только металлический диск и резиновая шина, а еще и система TPMS, работающая на частотах 315/443 МГц. Давайте разберемся, что это такое и зачем это вообще нужно.
TPMS - это Tire Pressure Monitoring Systems, что в переводе "Система мониторинга давления в шинах", предназначена для предупреждения водителя о критическом падении давления шин через приборную панель. Изначально система была разработана после серии трагических аварий с участием Ford Explorer и шин Firestone в конце 90-х, когда низкое давление приводило к перегреву, разрывам покрышек и последующим переворачиваниям автомобилей на высоких скоростях.
И по сути, введение системы TPMS было реакцией правительства США, издавшее в 2000 году TREAD Act (Transportation Recall Enhancement, Accountability and Documentation), который обязал автопроизводителей оснащать автомобили вышеназванной системой для повышения безопасности, снижения расхода топлива и уменьшения износа покрышек.
Существует 2 типа работы TPMS. Первый, он же "Непрямой мониторинг" использует датчики ABS-системы для контроля скорости вращения колес: при падении давления диаметр колеса уменьшается, оно начинает вращаться быстрее остальных, система фиксирует эту разницу и выдает предупреждение.
Но нас интересует второй тип: "Прямой мониторинг". В данном случае датчики установлены в каждом шине (обычно на клапане), измеряют давление и температуру, и передают данные по радиосигналу (обычно на 315/433 МГц) на бортовой компьютер автомобиля. И вот тут вступает в игру SDR со всеми его прелестями ;)
Автор доклада (Stephen Pote) решил проэксплуатировать TPMS и собрал систему наблюдения на основе RF с использованием радио данных. В своей лаборатории он использует микроконтроллеры ESP32 и модули CC1101 для создания сети приемников, которые обнаруживают эти сигналы и отслеживают движение автомобилей. В качестве возможного применения Стивен указывает на управление воротами (разрешение проезда только известным автомобилям с оповещение пользователя по электронной почте или SMS), отслеживание транспорта и картирование маршрутов, контроль потока транспорта вокруг границы участка, а также предупреждение при обнаружении непроверенного автомобиля и отслеживание паттернов движения во времени.
Со своей стороны я вижу атаку типа социальной инженерии, что если необходимо остановить автомобиль (например, с важным лицом компании), можно подать более мощный сигнал о пробитии колеса. Ну а дальше зависит от целей и задач нарушителей, например, передать забытые в офисе документы.
Более подробно в докладе автора, а мы после просмотра можем подискутировать в комментариях на предмет ценности данного исследования.
🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
РБПО по ГОСТ Р 56939—2024: вебинар №24 из 30 — Поиск уязвимостей в программном обеспечении при эксплуатации
Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.24. – "Поиск уязвимостей в программном обеспечении при эксплуатации". На YouTube. Слайды.
Цели 24-го процесса по ГОСТ Р 56939—2024:
Организация систематического и углублённого поиска ошибок и уязвимостей в ПО при его эксплуатации в целях упреждающего реагирования: обработки ошибок кода ПО и его конфигураций (настроек) до того, как они будут выявлены сторонними лицами и повлекут инциденты информационной безопасности.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
🍔 Свободная касса для взлома
В этом году на кибербитве Standoff 17 впервые появились знакомые каждому цифровые киоски «Вкусно — и точка». Сделать там заказ можно, а вот получить его в реальности не получится — они здесь не для этого.
Прежде, чем вы спросите, ответим — так сеть ресторанов быстрого питания проверяет свою устойчивость к реальным хакерским атакам.
«Вкусно — и точка» дала красным командам доступ к цифровой копии ключевых элементов своей инфраструктуры, куда входят киоск самообслуживания, кассовое программное обеспечение, главный терминал ресторана, серверная инфраструктура, кухонные мониторы, а также интеграции с платежными сервисами и оператором фискальных данных. Она позволяет детально воспроизвести весь путь клиента — от создания заказа до его оплаты и выдачи.
Пока идет кибербитва, атакующие могут попытаться найти уязвимости и реализовать одно из девяти недопустимых событий, оказывающих влияние на бизнес-процессы оформления и обработки заказов. Сценарии атак могут быть разными, включая нарушение работы киосков самообслуживания, компрометацию административных учетных записей, создание фальшивых заказов и другие воздействия, способные повлиять на качество обслуживания гостей.
Григорий Кондаков, руководитель отдела информационной безопасности «Технологии — и точка», рассказал, что киоски, через которые посетители делают заказы — самая доступная часть инфраструктуры компании, а значит, находятся в зоне риска. Поэтому открытая для атак цифровая копия — отличная возможность проверить, смогут ли реальные злоумышленники не просто получить пару бургеров, колу и картошку фри доступ к отдельным системам или их элементам, но и повлиять на бизнес-процессы «Вкусно — и точка».
👍 В итоге все в выигрыше: компания узнает об уязвимостях раньше, чем их найдут плохие парни, а атакующие, которые сумеют воплотить недопустимый сценарий, получат за это вознаграждение.
Standoff 17 проходит в Кибердоме прямо сейчас и продлится до 19 июня.
Более 400 пакетов для Arch Linux распространяли руткит и инфостилер
Экосистема Arch Linux пострадала от масштабной атаки, которая затронула сотни пакетов в репозитории AUR
— Злоумышленники перехватили управление заброшенными проектами, сохранили их названия и историю изменений, а затем изменили PKGBUILD-файлы таким образом, чтобы при сборке пакета загружалась и запускалась малварь
❗️ В результате пользователи сами запускали вредоносную полезную нагрузку при сборке пакетов
Вредонос похищал cookie, токены и данные локального хранилища Chromium-браузеров, извлекал информацию из Slack, Discord и Microsoft Teams, воровал токены GitHub, npm, HashiCorp Vault и OpenAI, а также SSH-ключи, историю шелл-команд, VPN-профили и учетные данные Docker и Podman
Украденные данные передавались на внешний сервер, а связь с управляющей инфраструктурой злоумышленников была организована через Tor
Когда мы слышим истории про взлом высокотехнологического оборудования или АСУТП промышленного предприятия (например ядерного реактора как это произошло со 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 | 📝 Хабр | 💙 ВКонтакте
РБПО по ГОСТ Р 56939—2024: вебинар №23 из 30 — Реагирование на информацию об уязвимостях
Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.23. — «Реагирование на информацию об уязвимостях». На YouTube. Слайды.
Цели 23-го процесса по ГОСТ Р 56939—2024:
Обеспечение выявления и устранения уязвимостей при эксплуатации ПО.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939–2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая «Методика ВУ и НДВ в ПО». См. заметку «Методика выявления уязвимостей и недекларированных возможностей — 2026».
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Что было на встрече РКН с ИТ-отраслью, или «Если у вас всё работает — чего вы переживаете?»
Есть встречи, после которых хочется что-то изменить. А есть встречи, после которых хочется нервно покурить (хотя я не курю). Недавнее совещание (08.06.26) РКН с представителями ИТ-отрасли — из второй категории. Ниже краткая выжимка, что там было, чтобы вы были в курсе происходящего в кулуарах.
Встречу давно обещали и вот собрали. Без повестки, без списков, без резолюции — видимо, чтобы не выносили наружу. Не помогло: слили всё что было. Так что просьбу «не выносить в СМИ» можно класть на ту же полку, где лежит просьба не пользоваться Телеграмом. К нему ещё вернёмся.
Открывал собрание замглавы РКН — который как раз отвечает за блокировки. Его логика была проста, как лом: интернет в стране падает, но РКН почти ни при чём. Это дроны, это смежные органы, это иностранцы — все вокруг. А ТСПУ? Ну да, и оно немножко (верим?).
Дальше заговорил чиновник отвечающий за Центр мониторинга, и принёс три «гениальные» идеи. Перед чтением дальше, лучше сядьте и не пейте ничего, чтобы не подавиться от смеха, если что — я предупредил.
Подключайтесь к Центру мониторинга. Добровольно, без ответственности, как жест доброй воли. Вы только опишите всю свою инфру — а насколько подробно, мы потом сообщим. Как в анеке: вы пока разденьтесь, а доктор потом решит, нужно ли.
Построим свой репозиторий кода — на случай, если нас отрубят от внешнего. Аргумент про единую точку отказа (хакерская мечта просто) — в расчет не берется. Разраб из зала: даже США не смогли такое сделать. Другой чиновник РКН парирует: «А Китай смог». Аргумент зала о том, что китайцы всё равно сидят в опенсорсе — остался без ответа.
Сделаем госVPN с маскировкой — прятаться от западных фильтров. Зал заметил, что такой обход заблочат за полдня, как сейчас блочат всё русское. Замглавы РКН ответил, что «можно же сделать правильно». И добавил, что DPI у нас самый крутой в мире. То есть свой VPN мы спрячем гениально, а пять тысяч чужих ловим по протоколам пачками, роняя пол-Рунета ложными срабатываниями. Двойные стандарты даже не маскируются.
И тут — лучший диалог вечера:
Зал: а кто вообще решает, что блочить?
Замглавы РКН: мы боремся с порно и педофилией, а остальное — другие органы, вы же все понимаете кто.
Зал: не понимаем. Кто?
Замглавы РКН: на этот вопрос я ответить не могу.
Миллионы людей в стране на VPN'ах, гора заблоченных сервисов — а на вопрос «кто это устроил» уполномоченный орган разводит руками, как пойманный за руку гардеробщик.
Апофеоз — про Телеграм:
Зал: результат-то есть? Телеграм заблокировали?
Замглавы РКН (с гордостью): да, конечно.
Зал: коллеги, поднимите руки, кто всё ещё пользуется. — Поднимает весь зал.
Замглавы РКН: так если у вас всё работает, чего ж вы переживаете? Значит, мы не такие плохие.
Я думаю, что это не оговорка, а мировоззрение. Заблокировали так, что заработало лучше прежнего, — и записали себе в плюс. Это звучит как нелепая шутка, но это не она.
По итогам решили встречаться раз в две-три недели и обсуждать госVPN. И снова просили не болтать в прессе (ну конечно). На «зачем вы блокируете вот это» договорились не отвечать никогда — но обещали как-нибудь привести смежников из ФСБ. Горю желанием посмотреть, как они объяснят свою компетенцию.
Что в сухом остатке
Встречу собрали для галочки. Наверх уйдёт ровно это: «с отраслью встретились, проблемы обсудили, взаимопонимание нашли, всё хорошо».
Острые вопросы задать не дали — что выходит за «компетенцию», РКН не обсуждает. 149-ФЗ и закон «О связи» соблюдать никто не собирается: работают по телефонному праву, а кто звонит — секрет фирмы.
Признавать ошибки и откручивать гайки? Нелепость какая. Что настроили против себя отрасль, разрабов и даже простых людей — не понимают и не хотят. Неинтересно. За это не платят.
«ГосVPN» и «отечественный репозиторий» отрасли не нужны и технически мертворождённы — но на них упрямо настаивают: надо же хоть что-то изображать. ИБД в чистом виде.
Такие вот дела 🤷🏼
РБПО по ГОСТ Р 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 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Приглашаем на Ozon Tech CyberSec Meetup 17 июня
Привет, Хабр! Собираемся большой компанией в нашем любимом лофте, чтобы рассказать об актуальном в кибербезе: от технических вызовов до романтики CTF.
17 июня | офлайн в Москве + онлайн-трансляция
В программе 4 доклада, кофе-брейк, традиционно много качественного общения и один особенный интерактив — Cyber Match. В течение вечера вы сможете пообщаться с руководителями разных команд в формате 1х1, задать вопросы о карьере и не только.
Темы встречи:
удалённый доступ и его безопасная организация на практике;
patch management на рабочих станциях и наш опыт разработки и применения;
процесс разбора ИБ-событий и принятия решений на первой линии;
организация CTF среди сотрудников и важность соревнований для компании.
Приходите лично или подключайтесь к трансляции.
Только сначала зарегистрируйтесь по ссылке и до встречи на митапе!
Страх как продукт: почему мы до сих пор продаём ужас вместо ценности
Рынок ИБ до сих пор продаёт не защиту, а спокойный сон до следующего квартала. Страх стал валютой - от отчётов «80% компаний под угрозой» до тепловых карт, где всё красное. Ниже — ещё более сжатая выжимка: как устроена эта машина страха и чем её заменить.
Как страх стал главным продуктом:
Доказать эффект от ИБ трудно: мало данных, спорные методики, внутренняя политика сильнее формул. В результате страх стал универсальным инструментом: случился инцидент - рынок завален продуктами и отчётами «как раз от такой угрозы».
Классика жанра:
Вирус уровня WannaCry использует старые уязвимости, но продаётся как «новая эра вымогателей и уникальных защит».
Отчёты «80% компаний под угрозой» строятся на кривых опросах своей аудитории и заканчиваются «запросите демо/пилот».
FUD даёт краткосрочное внимание, но в долгую убивает доверие и либо ведёт к хаотичным покупкам «серебряных пуль», либо к апатии: всё кажется одинаково страшным.
Чеклист для CISO:
На любую страшилку ответьте:
Какой конкретный сценарий атаки описан?
Какова вероятность и ущерб именно для нашей компании?
Что изменится в нашей модели угроз, если мы это купим/внедрим?
Если хотя бы на один пункт ответа нет - это продажа эмоции, а не безопасности.
Иммунитет CEO и красные тепловые карты:
У многих CEO уже аллергия на FUD-слайды «Россия в топ‑3 по атакам» и «каждая вторая компания пострадала».В ответ безопасники приносят тепловые карты, где половина клеток ярко‑красные.
Что реально происходит:
Красный цвет мгновенно бьёт по инстинктам, один слайд перекрывает пачку таблиц.
Но карта «всё красное» без чисел - это эмоциональный шантаж ради бюджета, а не управление рисками.
Что можно поправить быстро:
У каждой «красной зоны» должны быть: сценарий, диапазон потерь и время простоя.
Вместо абстрактных рейтингов - 2–3 реально возможных для вашего бизнеса кейса с понятными цифрами.
Медиа и «исследования»: аналитика или хоррор:
ИБ‑медиа и вендорские отчёты - крупная шестерёнка машины страха.
По оценкам редакторов, 90–95% исследований делаются ради продвижения продукта: методика мутная, цифры разных отчётов по одной теме могут расходиться на порядки.
Полезно:
Читать аналитику по реально эксплуатируемым уязвимостям и zero‑day в массовых продуктах.
Разборы реальных инцидентов - их мало, но именно они меняют практику.
Вредно:
Разгонять фейки, неподтверждённые сливы и «80% под угрозой» без описания выборки.
Фильтр для отчётов
Один вопрос: «Эта цифра способна изменить наше решение?»
Если нет - перед вами маркетинг, а не аналитика.
Регулятор против хакера: чей страх сильнее:
У российского заказчика два фронта: хакеры и регулятор.
Факты:
60–70% бюджетов ИБ уходит на комплаенс (приказы, ГОСТы, 152‑ФЗ, отраслевые требования).
Остаток - на «живую» защиту: SOC, мониторинг, сегментацию, реагирование.
Почему страх регулятора побеждает:
Атака - вероятностна, может и не случиться.
Проверка - гарантирована, с датой и понятными санкциями.
Мини-действие
Разложите бюджет на «комплаенс» и «реальную защиту».
В каждый комплаенс‑проект заложите хотя бы одну меру, которая действительно снижает риск.
Как уйти от продажи страха к продаже ценности:
Нужный сдвиг: от управления страхами - к управлению рисками и бизнес‑ценностью.
На практике:
Переводите «страшно» в «сколько стоит и что конкретно делаем в ответ».
Привязывайте ИБ к бизнес‑метрикам: простои, выручка, операционные издержки, скорость изменений.
Используйте новости и инциденты как материал для обучения и улучшений, а не как повод продавить очередную «серебряную пулю».
Если вы:
Перепишете одну ключевую презентацию, убрав хоррор и добавив сценарии с деньгами.
Хоть раз в неделю спросите команду: «Мы сейчас управляем риском или реагируем на хорошо проданный страх?» - значит, вы уже выходите из режима «страх как продукт» и начинаете говорить с бизнесом на взрослом языке.
А у вас решения по ИБ сейчас чаще объясняют «по регулятору надо», «видели страшный кейс» или нормальным разговором про риски и деньги?
РБПО по ГОСТ Р 56939—2024: вебинар №21 из 30 — Безопасная поставка программного обеспечения пользователям
Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.21. – "Безопасная поставка программного обеспечения пользователям". На YouTube. Слайды.
Цели 21-го процесса по ГОСТ Р 56939—2024:
Обеспечение защиты ПО, в том числе документации ПО, от угроз, возникающих в процессе передачи ПО пользователю.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
P.S.
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Их можно смотреть на ускорении. Однако даже в этом случае с учётом дополнительных материалов и отсылок на внешние ресурсы изучение займёт около двух рабочих недель.
Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки. Так будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже познакомились.
Подробнее: НЕкурс про разработку безопасного программного обеспечения (РБПО).
В 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 с богатой экосистемой расширений — это огромная поверхность атаки. Изоляция между расширениями и ядром редактора остаётся слабым местом большинства современных инструментов разработки.
РБПО по ГОСТ Р 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 "Защита информации. Разработка безопасного программного обеспечения. Общие требования".
Помните год назад вышло беспрецедентное судебное решение Верховного Суда РФ за номером 5-КГ25-30-К2, которое призвало увеличить цифровую безопасность в Интернете и свести к минимуму мошенничество в виде оказания услуг под чужим именем? Так вот, после данного решения специалисты по ИБ вспомнили старого друга dnstwist и стали периодически проверять свой домен на наличие клонов-фишингов.Ну и что говорить, я тоже раз в неделю сдувал пыль с утилиты и проверял подозрительные "зеркала".
Однако, каждый инструмент хорош для того, для чего он был разработан, и чем больше я с работал с dnstwist тем больше я понимал, чего мне в нем не хватает для полноценного выполнения упражнения. Так как рынок не предложил достойного решения, пришлось разработать aka завайбкодить утилиту, специально заточенную для задачи от Верховного Суда.
Во-первых, текущее решении кросс-платформенное, так как реализовано на Docker. Поэтому его быстро и легко можно запустить как на Linux, так и Windows с MacOS, а также интегрировать в ваши уже существующие системы мониторинга.
Во-вторых, функционал и настройки выведены в GUI через веб-интерфейс. Это позволяет выводить графику, а именно скриншоты проверяемых доменов, избавляя от необходимости ручной перепроверки.
Также, на лету вносятся отметки о false positive, true positive или домен под продажу (тоже нужно смотреть, чтобы недоброжелатели не выкупили). Данные записываются в SQLite, которую можно легко скачать и интегрировать в свою систему.
В завершение, из глобальных фич: формируется PDF-отчет, который выводит скриншоты фишинговых и доменов на продажу, позволяя быстро и оперативно принимать решение.
Приложение доступно на GitHub под названием 5-KG25-30-K2 на русском и английском языках. Качайте, пользуйтесь и, если есть предложения, контрибьюте. Жду вашей обратной связи и комментариев по утилите.
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
Теневой ИИ: как сотрудники сливают данные через 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-источников
Организационные меры: чёткие правила использования ИИ, регистрация инструментов, обучение персонала. Главное — предоставить безопасные альтернативы вместо запретов. Запрет без замены приводит к ещё большему теневому использованию.
Проблема системная: сотрудники видят в ИИ инструмент для ускорения работы и не задумываются о последствиях. Задача ИТ — сделать защищённые решения удобнее публичных, иначе теневой ИИ будет расти.