CISO может хорошо понимать угрозы и технологии, но всё равно сталкиваться с нехваткой ресурсов и поддержки бизнеса. Узнаем, почему руководителю ИБ важно уметь говорить с компанией на одном языке и как превратить безопасность из набора требований в понятную бизнес‑ценность.
В экосистемах со сложившейся моделью пакетных индексов вроде Python, Java или JavaScript состав проекта обычно начинают анализировать с манифеста, где разработчик перечисляет прямые зависимости проекта и их допустимые версии. Менеджер пакетов читает эти требования, выбирает совместимые версии и подтягивает зависимости, которые нужны самим пакетам. Конкретный результат выбора сохраняется в lock-файле, где фиксируется уже не диапазон, а точные версии прямых и транзитивных зависимостей. В результате получается список всех пакетов, необходимых для работы с проектом.
В проектах на C и C++ такой общей записи, как правило, нет. Одну библиотеку могут устанавливать через менеджер системных пакетов, другую собирать из исходников в отдельном пайплайне, третью копировать прямо в каталог с исходным кодом проекта. Все они могут оказаться в рабочем приложении, хотя ни один источник не обязан перечислять их все в одном месте.
На крупной кодовой базе это быстро становится проблемой. Например, в нашем разборе автоматизации SBOM для LibreOffice в проекте была сотня с лишним C/C++ библиотек, собственная сборочная система и ресурсы вроде шрифтов и словарей, которые тоже попадают в поставку. За каждым компонентом такого SBOM стоит отдельное расследование от файла и команды сборки к имени проекта, версии и источнику. На каждом переходе теряется своя часть данных.
В CodeScoring мы анализируем состав программных продуктов и на практике часто сталкиваемся с ограничениями разных экосистем. Разбор проектов на C/C++ требует особого внимания. В этой статье мы разобрали особенности этой экосистемы, которые осложняют построение SBOM, и постарались рассказать, что позволяют выяснить разные методы анализа.
Flowise — визуальный конструктор для LLM-приложений: перетаскиваете на холст модель, векторное хранилище, инструменты и память, соединяете их линиями и получаете чат-бота, RAG-поиск по документам или агента. У проекта 55 тысяч звёзд на GitHub, 25 тысяч форков и почти 7 миллионов скачиваний Docker-образа. Его разворачивают у себя компании, которым нельзя отправлять данные в облачные конструкторы.
29 июля 2026 года команда объявила о закрытии: «разработчики всё чаще доверяют сложные задачи агентам для программирования, а жёсткие low-code-процессы упираются в потолок». 13 августа репозиторий заархивировали, 31 августа поддержка закончилась. В объявлении прямо сказано: код под Apache 2.0 ваш, форкайте.
Установки при этом никуда не делись, а бюллетени об уязвимостях продолжили выходить. Десятого сентября GitHub опубликовал ещё шесть advisory для Flowise — все с пометкой «исправленной версии нет». Я решил сделать то, что предложили авторы, и продолжить проект под именем Keelflow (GitHub, Apache-2.0). Киль (keel) держит судно на курсе — примерно этого и хочется от проекта, у которого кончилась команда.
Оказалось, что форкнуть Flowise «как есть» нельзя. Об этом, о том, что пришлось переписать, и о том, что нашлось в коде по дороге, — эта статья.
В вашем телефоне исполняется код восьми авторов, и ваш — самый бесправный. Мы написали свою ОС на Rust, загрузили её на планшет и полгода выясняли, кто ещё живёт в чипе и чьи правила там действуют. Как это устроено на самом деле, почему это касается ноутбуков, iPhone и «умных» лампочек — и что с этим делать.
Собрал платный API для проверки кода на протоколе x402 — агент получает HTTP 402, платит в USDC, получает подписанный сертификат. Довёл до продакшена и наткнулся на четыре бага, каждый из которых выглядел как рабочий код. Заодно проверил, есть ли вообще спрос — и вот что показали цифры.
Весной 2014 года директор по технической инфраструктуре Columbia Sportswear уволился и ушёл к ИТ-подрядчику. А в каталоге компании остался сотрудник Джефф Мэннинг, которого никогда не существовало. Под этой учётной записью бывший директор заходил в сеть ещё больше двух лет — по данным иска компании, больше 700 раз — и читал корпоративную почту, прежде всего тех, кто отвечал за закупку ИТ-оборудования. Обнаружили его случайно, при обновлении почтовой системы.
Это типовая «закладка», и при классическом подходе к аудиту, построенном на журналах событий, её появление может остаться незаметным для службы безопасности. В этой статье я расскажу, почему нельзя доверять журналам аудита и на что обратить внимание при защите служб каталогов.
Невидимые изменения в службах каталогов
История первая — про тех, кто знает инфраструктуру изнутри. Майкл Липер почти четырнадцать лет проработал в Columbia Sportswear и дорос до директора по технической инфраструктуре. Перед уходом он завёл в каталоге учётную запись jmanning для несуществующего сотрудника Джеффа Мэннинга с доступом по VPN и к виртуальным рабочим столам, а заодно расширил права сервисной учётной записи svcmon, которой давно никто не пользовался. Собственная учётная запись ему после этого была не нужна. Дальше — больше двух лет чтения почты ИТ-специалистов, отвечавших за закупки: подрядчику, где Липер стал техническим директором, очень помогало знать, что бывший работодатель собирается покупать. «Джеффа Мэннинга» нашли летом 2016 года, случайно, при обновлении почтовой системы. В декабре 2017-го Липер получил три года пробации и 400 часов общественных работ — без тюрьмы
Безопасность процессов изменения информационного потока данных от человека к машинному пока остается вне широкого обсуждения, но бизнесу важно понимать, когда процессы, которые могут привести к аварии, уже запущены на атомной электростанции (из-за свойств атомной энергии), не будет иметь значение насколько исправны щитки и распределение проводки в вашем офисе.
Программисты выстраивают гардрейлы и правила «можно/нельзя» для агента, выходящего во внешний мир. Но любое такое правило опирается на признак «чему доверять/чему нет». Инъекция промптов не зря стоит первой в OWASP Top-10 for LLM: агент не отличает данные от команды, потому что не отличает, кто и зачем написал текст.
Бизнес может максимально защитить свой периметр и код, но модели учатся на цифровых информационных потоков в сети, а агенты уже сейчас читают синтезированный текст. Это и есть системная (информационная) неустойчивость самого принципа работы ИИ и тот, кто увидит это первым, получит преимущество, ровно как в любой структурной неустойчивости.
Модели не могут не обучаться (собственного опыта у них нет, им нужны данные), а данные им сейчас поставляют миллионы обычных пользователей, публикуя сгенерированные тексты под своими именами. И сам ИИ помогает обходить свои собственные защиты «очеловечивая» машинные тексты. Доля неразличимых синтетических данных растет и через несколько поколений обновлений модели будут обучаться на собственных данных, превращая информацию в бессмыслицу и исследования показывают траекторию этой деградации.
Этот коллапс поначалу не будет громким, но окажется стремительным, глобальным и дорогим - как взрыв ипотечного пузыря. Код будет работать штатно, тесты проходить, но качество решений поплывёт, потому что нарушения будут не в ПО, а в глобальной коммуникации. Избежать этого можно при одном условии - синтетические данные должны добавляться к человеческим, а не вытеснять их, но сейчас пока происходит обратное. И очень важно разобраться именно сейчас, к чему нам нужно готовиться.
Боков Фёдор, Security Vision
«Хочу видеть всю картину, но не готов дать вам ключи от всех дверей» — так звучит одно из самых частых и противоречивых пожеланий заказчика, который купил продукт по управлению активами, но не хочет предоставлять какие‑либо данные для подключения к целевым хостам, сетевым устройствам и другим ИТ‑активам. Чем в таком случае вендор может помочь? Управлением активов в режиме Blackbox.
В большой компании картина почти всегда одинаковая. Систем много, а ответа на вопрос, что у нас есть и где это лежит, нет. SIEM пишет события. Мониторинг опрашивает узлы и строит графики, и в нем же кто-то пытается вести инвентаризацию, потому что хосты уже заведены. ITSM знает заявки и согласованные сервисы. Рядом лежат локальные базы, выросшие исторически, и файл Excel на чьем-то диске. Его все считают временным, пока он на полгода не становится единственным источником правды.
ИБ в этой картине оказывается в странной позиции. Защищать формально надо все. Но что именно входит в это «все», целиком не назовет никто. Когда случается инцидент или проверка, вместо расследования начинается аудит инфраструктуры с нуля. Кто владелец, какой контур, какой адрес, отвечает ли узел, почему туннель настроен на оборудовании, но отсутствует в учете. Атакующие или просто беспорядок в процессах заставляют службу безопасности заниматься инвентаризацией всего подряд. Это дорого, поздно и почти всегда неполно.
Защищать то, чего не понимаешь, можно только наугад. И чем больше параллельных версий состава инфраструктуры, тем проще нарушителю, внешнему или внутреннему, найти брешь, которой нет ни в одной системе целиком.
Можно закрыть все уязвимости и быть взломанным через стандартный пароль. Разбираем, что такое комплаенс в ИБ, почему в России он стал жестче и дороже, как построить собственный стандарт на основе требований регулятора и почему контроль конфигураций - часть управления уязвимостями.
Многие пользователи в России подключают Telegram через прокси, чтобы сохранять доступ к информации. Но что, если сам прокси окажется враждебным?
Мы обнаружили, что такой сервер мог без предупреждения получить доменные данные Windows, раскрыть личность пользователя и многократно извлекать фрагменты памяти Telegram Desktop. В лаборатории в этих фрагментах оказывались тестовые пароли, API-ключи и другие секреты из повторно используемых буферов.
В корпоративной Windows-среде атака могла пойти дальше: перехватить NTLM-аутентификацию и через AD CS привести к удалённому выполнению кода с правами SYSTEM. В статье — исходный код, PoC и полная цепочка атаки.
Хочу поделиться разбором инцидента, который заставил меня вместо привычного GUI окунуться в файловую систему OPNsense. Я расскажу, как с виду легитимный, но подозрительный процесс привёл к обнаружению бэкдора в системном файле, почему расследование зашло в тупик и какие выводы мы из него вынесли. Всё по существу.
TL;DR: В OPNsense обнаружен процесс php‑cgi, пожирающий 100% CPU. Оказался бэкдором, вшитым в системный файл system.inc через cron. Источник внедрения не установлен — помешал общий root‑пароль и отсутствие внешнего логирования. Выводы — в конце.
Недавно я писал материал о реагировании на инциденты информационной безопасности в Linux в двух частях (одна, вторая). Я попытался написать что-то поинтереснее, чем просто набор команд, чтобы этот материал можно было использовать как методологию – раз, и основу для собственных плейбуков – два.
Теперь применим тот же подход к Windows. В конце концов, большинство корпоративных рабочих станций работают на Windows, у всех есть виндовые домены, и машин под Windows Server тоже везде хватает.
Материалов о Windows Incident Response немало. Но многим работам не хватает целостного представления о предмете. Они выглядят как наборы команд для терминала; если вывод есть - плохо, если нет - хорошо. Эта проблема характерна и для статей по Linux IR, но выражена там не так сильно – думаю, по причине того, что ОС Windows щедра на следы — заметно щедрее Linux.
Собственно, нужна методология. Реагирование – это не бездумный копипаст десятков команд и не поиск одного ультимативного артефакта, который ответит на все наши вопросы. Это корреляция множества следов, которые лежат в разных местах и каждый из которых отвечает лишь на часть вопросов.
Под катом — пытаемся подходить к вопросу системно через разбор заражённого хоста аналитиком IR от первой команды до готового таймлайна и списка IOC. Если вы читаете это не из любопытства, а потому что подозреваете компрометацию прямо сейчас, а антивирус молчит, вы можете опираться на статью для ручного поиска вредоносного ПО.
Привет, Хабр!
Меня зовут Антон Станкевичус, я старший специалист по тестированию безопасности программного обеспечения в компании «Гарда».
Моделирование угроз (Threat modeling) — уже давно не задача из серии «если дойдут руки», а важное требование по безопасности для российских разработчиков ПО. Мы тоже подходим к такой работе максимально тщательно.
Недавно я выбирал инструмент для автоматизации Threat modeling. Было важно, чтобы он соответствовал ГОСТу по защите информации. Требовалось предоставить руководству обзор рынка и доступных решений, чтобы согласовать оптимальный вариант.
Забегая вперед, Threat modeling редко выполняется единственным инструментом. Одни решения помогают формализовать архитектуру, другие — автоматически находить уязвимости, третьи удобно встраиваются в конвейер CI/CD. Для наглядности я решил не только сравнить между собой рассматриваемое ПО и подходы, но и оценить, насколько каждое из них соответствует требованиям регулятора, а также разложить их по функциональным группам.
Итак, поехали!
В 2026 году среди вредоносных Android-приложений появился новый претендент на лидерство – RedWing. Это вредоносное ПО начали распространять через Telegram по модели MaaS (Malware-as-a-service, вредоносная программа как услуга).
Специалисты департаментов Fraud Protection) и киберразведки Threat Intelligence компании F6 исследовали несколько обнаруженных образцов RedWing, изучили функционал и возможности ВПО. Как выяснили эксперты, злоумышленники распространяют несколько вариантов этого вредоносного приложения, которые, вероятно, предназначены для выполнения разных целей киберпреступников. Первый вариант – троян удаленного доступа (Remote Access Trojan, RAT), нацеленный прежде всего на удаленное управление скомпрометированным устройством. Второй вариант – стилер, основная задача которого – сбор информации с устройства.
Исследование версии RedWing как стилера готовится к публикации и выйдет отдельно. А в первой части блога мы расскажем о результатах исследования ВПО RedWing в исполнении RAT.
Во время исследования контроллеров Realtek я столкнулся с таким любопытным способом защиты прошивки от реверс-инжиниринга, как XOM (eXecution Only Memory). Эта технология разработана ARM уже около 10 лет назад. Опираясь на свой опыт, назвать ее очень популярной не могу. Однако, в Realtek решили использовать XOM в ряде своих контроллеров, которые попали к нам на исследование.
Если коротко, XOM – это аппаратно-программная технология, формирующая execute-only область памяти. Суть XOM состоит в аппаратной фильтрации транзакций на шине AXI (AHB). Если транзакция в защищаемую область запрашивает исполнение инструкции - доступ разрешен, если чтение/запись данных – доступ запрещен. Таким образом, прочитать или перезаписать прошивку в XOM просто так не получится.
Данная статья описывает подход к восстановлению спрятанной в XOM прошивки, основанный на анализе изменений состояния памяти и регистров процессора, возникающих вследствие выполнения инструкций процессора.
Привет! Меня зовут Андрей Баранцев, я аналитик группы развития и сопровождения Solar SIEM в ГК «Солар». Наша команда проводит пилоты Solar SIEM у клиентов: разворачивает систему, подключает источники, проверяет ее под нагрузкой и вместе с ИБ-командами тестирует сценарии.
В первой половине 2026 года мы провели 40 пилотов Solar SIEM. За это время несколько проблем повторялись на разных проектах: инфраструктура по характеристикам подходит, а реальный поток не держит; большая часть пилота уходит на развертывание и интеграции, а сценарии остаются на конец; команда только во время тестирования выясняет, насколько самостоятельно сможет работать с контентом.
SIEM-система собирает события от серверов, рабочих станций, корпоративных приложений и средств защиты, нормализует их и связывает между собой. Аналитик получает общую картину и может восстановить последовательность действий при разборе подозрительной активности.
В этой статье разберем четыре проблемы, с которыми клиенты и команды внедрения сталкиваются во время пилотных проектов. Где чаще всего спотыкаются инженеры и что проверить заранее, чтобы не создавать себе проблемы уже по ходу пилота. Поехали!
Сотрудник уволился, а клиенту и коллеге остались его ссылки на файлы с Яндекс Диска. Что будет с этими ссылками при блокировке и удалении аккаунта, справка Яндекс 360 не говорит. Я проверил на двух тестовых учётных записях: исход ссылки решило то, чей это был Диск - свой или чужая папка. Каждую старую ссылку можно перепроверить одним GET-запросом к API Диска без токена.
Код в моих проектах пишут агенты, Codex и Grok, и они же пишут к нему тесты. За последние месяцы набралась коллекция зелёных тестов, которые ничего не проверяли: тест на подделку подписи, проходящий без сравнения HMAC, лимиты, которые вызывали только их собственные тесты, отчёты «all pass» с заглушённым кодом возврата. Разбираю, где это ловится и как у меня устроена приёмка.
Как‑то я захотел кошелёк Monero с нормальным веб‑интерфейсом, но без компромиссов по ключам: чтобы он работал на моей машине, ходил в мой узел и не притворялся кастодиальным сервисом. Писать криптографию самому — плохая идея, поэтому вся работа с ключами осталась за официальным monero-wallet-rpc, а на мне была «всего лишь» оболочка: бэкенд, интерфейс и куча инфраструктурной логики, которая внезапно оказалась самой интересной частью задачи.
