Команда Solar WAF зафиксировала в первой половине 2026 года аномальный всплеск числа веб-атак, пик которого пришелся на июль. Подавляющее большинство зафиксированных событий – работа автоматизированным сканеров. Аналитики «Солара» не исключают, что в мае-июле (периоде, когда наблюдался быстрый рост количества веб-атак) российские компании подверглись спланированному массовому сканированию веб-ресурсов с помощью сканеров на базе ИИ. Несколько месяцев злоумышленники собирали информацию об уязвимостях, а в августе начали пробовать их эксплуатировать. Среди этих проб была выявлена новая тактика: злоумышленники стали маскировать трафик веб-атак под запросы легитимных ИИ-сервисов (DeepSeek, ChatGPT, Perplexity и не только). Цель такой маскировки – обмануть WAF. Как много было выявлено таких инцидентов и что за ними последует – рассказываем ниже.

Классическая модель построения центра мониторинга ИБ (Security Operations Center, SOC) обычно предполагает наличие одной централизованной системы класса Security Information and Event Management (SIEM-), в которую поступают события ИБ от всех значимых источников ИТ-инфраструктуры. На одной платформе выполняются их сбор, нормализация и корреляция, регистрация инцидентов ИБ и долговременное хранение данных. Это упрощает сопровождение решения и интеграцию с источниками, а также позволяет выстроить единые процессы работы SOC.

На практике крупные организации нередко одновременно эксплуатируют две или даже три SIEM-системы. При этом часть связанных задач можно объединять в одной платформе. Solar SIEM совмещает функции SIEM и SOAR и поддерживает цикл от обнаружения инцидента до автоматизированного реагирования. Почему компаниям все же нужны несколько платформ и когда такая архитектура оправдана – рассмотрим в этом материале.

Привет! Меня зовут Андрей Баранцев, я аналитик группы развития и сопровождения Solar SIEM в ГК «Солар». Наша команда проводит пилоты Solar SIEM у клиентов: разворачивает систему, подключает источники, проверяет ее под нагрузкой и вместе с ИБ-командами тестирует сценарии.

В первой половине 2026 года мы провели 40 пилотов Solar SIEM. За это время несколько проблем повторялись на разных проектах: инфраструктура по характеристикам подходит, а реальный поток не держит; большая часть пилота уходит на развертывание и интеграции, а сценарии остаются на конец; команда только во время тестирования выясняет, насколько самостоятельно сможет работать с контентом.

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

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

Всем привет!

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

Итак, начинаем разбираться, как ИИ меняет безопасную разработку вместе с Антоном Прокофьевым, директором центра разработки решений по контролю безопасности ПО ГК «Солар»; Дмитрием Евдокимовым, основателем и генеральным директором Luntry; Дмитрием Частухиным, основателем и техническим директором Hexway.

Где ИИ уже снимает рутинную нагрузку с AppSec? Почему сгенерированный код все равно требует проверки и зачем контролировать ИИ-приложения уже во время исполнения?

Есть такое уютное заблуждение: выключил Wi-Fi и мобильные данные – и все, ты невидимка. Спокойно можно строить теории заговора. На деле всё немного иначе. Даже в полном офлайне встроенные датчики смартфона продолжают исправно работать и копить информацию о том, чем вы занимались. Разбираемся, как смартфоны на самом деле следят за нами без сети, чего стоит опасаться по-настоящему, а что — просто повод для паранойи.

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

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

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

Рынок ГОСТ VPN и факторы роста

По оценке ГК «Солар», объем российского рынка оборудования для ГОСТ VPN вырос с 20,4 млрд рублей в 2024 году до 23,5 млрд рублей в 2025-м. По прогнозу, в 2026 году рынок достигнет 27 млрд рублей, а в 2027-м – около 31 млрд рублей. В среднем рынок растёт примерно на 15% в год.

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

ГОСТ VPN – одно из динамичных направлений сегмента сетевой и облачной безопасности. Для организаций с распределенной инфраструктурой всё более актуальной становится задача защиты каналов связи между удаленными объектами, площадками и внешними системами.

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

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

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

Представьте, что ваш зашифрованный трафик злоумышленники записывают прямо сейчас. На первый взгляд, это бессмысленно: расшифровать его классическими методами невозможно. Однако существует стратегия «собери сейчас, расшифруй потом» (Harvest Now, Decrypt Later). Суть такого подхода заключается в накоплении зашифрованных данных сегодня, чтобы взломать их завтра, когда появится достаточно мощный квантовый компьютер, называемый в литературе криптографически-значимым квантовым компьютером (Cryptographically Relevant Quantum Computer – CRQC). По нейтральным оценкам крупных международных корпораций, он может появиться через 5–10 лет. С другой стороны, некоторые криптографы считают, что у спецслужб криптографически значимые квантовые компьютеры появятся к 2029 году, а для широкого пользования – примерно к 2032. Для госсектора и крупного бизнеса, где информация требует защиты десятилетиями, это критическая угроза.

Значительная часть такого трафика передается по защищенным каналам на базе набора протоколов IPsec. Его ключевой компонент – протокол IKEv2, отвечающий за согласование ключей и алгоритмов. Изначально он не был рассчитан на использование постквантовых алгоритмов: большие размеры ключей и подписей создавали эксплуатационные сложности. Однако благодаря техническим расширениям IKEv2 теперь поддерживает гибридный режим – одновременное использование классического протокола Диффи–Хеллмана (он позволяет двум сторонам выработать общий секретный ключ по открытому каналу связи) и постквантовых алгоритмов.

Для чего нам искать эксплойты? Это помогает защититься от потенциальных атак: чем раньше найдешь и разберёшься, как он работает, тем быстрее напишешь детектирующие логики на различные средства защиты информации, например: WAF, IDS. А они уже, в свою очередь, защитят компанию от возможных атак. Как говорится, предупреждён – значит, вооружён. Особенно важно отслеживать уязвимости в open-source-продуктах, используемых в инфраструктуре (таких в России сейчас много), так как их код является открытым для анализа и поиска уязвимостей, и множество энтузиастов практической безопасности ежедневно занимаются именно этим. В этой статье мы разберем, как и где искать эксплойты и какие подводные камни могут встретиться на этом пути. Если вы только начинаете карьеру специалиста по корпоративной защите, то статья будет полезной!

За 2025 год Центр противодействия кибератакам Solar JSOC выявил 1,16 млн событий информационной безопасности у примерно 300 организаций из ключевых отраслей экономики. Второе место среди типов инцидентов занимают попытки несанкционированного доступа – на них пришлось 23% случаев: злоумышленники активно подбирают пароли и эксплуатируют уязвимости систем аутентификации. Особую опасность представляет компрометация привилегированных учетных записей. По данным ГК «Солар», в 2025 году почти треть кибератак совершается через подрядчиков, которые получают легитимный доступ к критическим системам.

Когда злоумышленник или подрядчик действует под учётной записью сотрудника с повышенными правами, обычные средства защиты периметра его не видят – формально это администратор, выполняющий штатные операции. Единственный способ разобраться, что именно происходило внутри сессии, – иметь её запись. Поэтому системы класса PAM (Privileged Access Management) записывают действия привилегированных пользователей, а регуляторы всё чаще требуют хранить такие записи.

Дальше начинается инженерная развилка. Записывать сессию можно как видео экрана, а можно – как структурированные метаданные: сырые данные протокола. Первый путь даёт привычную «картинку», но требует терабайтов хранилища и плохо ищется. Второй занимает минимум места и мгновенно ищется по командам, но требует другой архитектуры и имеет ограничения для чисто графических интерфейсов (например, сложнее восстановить визуальный контекст, если пользователь не вводил команды). В Solar SafeInspect реализован второй подход. Вместе с бизнес-архитектором ГК «Солар» Антоном Залесским разбираемся, как это устроено и почему формат хранения напрямую влияет на скорость расследования и соответствие требованиям регуляторов.

Слабые пароли, избыточные права подрядчиков, сервисные учетки без ротации − все это типичные уязвимости внутренних сетей. По данным DSEC (входит в ГК «Солар»), в 87% проектов по внутреннему тестированию в 2025 году были достигнуты поставленных целей − получен контроль над доменом, получен доступ к персональным данным, скомпрометированы средства защиты информации и получен доступ к системе резервного копирования и базам данных. Главные проблемы внутренних сетей − слабые пароли (53% проектов) и устаревшее ПО (42%). А по данным Solar 4RAYS, атаки через подрядчиков остаются устойчивым трендом и в 2026 году. PAM-система−один из ключевых инструментов, способных разорвать эту цепочку. Классическая архитектура PAM подразумевает работу через выделенный бастион-сервер или прокси-сервер (промежуточный узел, через который проходит весь трафик администратора). Пользователь понимает, что его соединения явно проксируются, а значит, технически может попытаться установить прямое соединение с целевым сервером, минуя контроль. В этом материале разбираем вместе с Дмитрием Федоровым, пресейл-аналитиком Solar SafeInspect ГК «Солар», как прозрачные режимы работы PAM-системы Solar SafeInspect на уровнях L2 и L3 решают эту проблему.

Что такое «прозрачный режим» и почему с этим термином путаница

На российском рынке PAM-систем нет единого понимания того, что стоит за словами «прозрачный режим». Как поясняет эксперт «Солара», терминологическая путаница – это не проблема, а скорее особенность рынка.

Часть вендоров называет так доступ через портал с SSO, мотивируя это тем, что пользователь не вводит пароли вручную. Другие подразумевают работу на сетевом уровне, когда PAM-система полностью скрыта от пользователя.

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

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

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

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

На протяжении множества расследований команда Solar 4RAYS сталкивалась с такими «препятствиями». Проанализировав их, мы решили описать проблемы, возникающие в том или ином ИБ-процессе, которые негативно влияют на расследование инцидента.

Почти половина айтишников — 46 процентов — целенаправленно развивают личный бренд, из них 51% делает это через социальные сети и блоги. Это данные совместного исследования «Солара» и Хабра. Чаще всего в этом контексте говорят об авторах: блог помогает им структурировать опыт и усиливает профессиональную репутацию.  

Но блоги работают и с другой стороны. Сегодня чтение профессиональных каналов — один из инструментов в актуальной для ИТ и ИБ отрасли концепции непрерывного обучения (lifelong learning). Этот подход диктует скорость изменений в отрасли, в частности, под влиянием ИИ. Регулярно меняются инструменты хакеров, появляются новые сигнатуры и цепочки Kill Chain, и те знания кибербезопасника, которые вчера были актуальны, сегодня уже устарели. 

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

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

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

Идея создать коммерческий центр мониторинга угроз зародилась в 2009 году — как предчувствие растущей сложности атак. К апрелю 2012-го она оформилась в конкретный проект. Тогда и появился JSOC как Jet Security Operations Center — проект компании «Инфосистем Джет», то есть еще до основания самого «Солара». Позже он превратился в коммерческий SOC под брендом Solar, а буква «J» в названии сохранилась как дань истории.

Сегодня Solar JSOC — крупнейший коммерческий центр мониторинга и реагирования на кибератаки в России и входит в пятерку крупнейших провайдеров управляемых сервисов кибербезопасности в Европе. Ежедневно мы обрабатываем более 200 млрд ИБ-событий, защищая свыше 1500 заказчиков из госсектора, финансовой отрасли и бизнеса всех масштабов. Работа идет круглосуточно и без выходных. В этом материале расскажем о том, как возникла идея создания JSOC и как работают его специалисты.

Забытый бэкап в открытой папке, слабый пароль без двухфакторной аутентификации, сегментация без контроля обходных маршрутов — эти три ошибки делают взлом почти неизбежным. В 2025 году DSEC (команда пентестеров с 23-летним стажем, входит в ГК «Солар») провела 390 пентестов — и в 78% случаев внешний периметр был пробит. Фишинг достигал цели всегда: хотя бы один сотрудник взаимодействовал с письмом — а в 86% случаев вводил пароль или открывал вложение.

Но главное — эти сценарии уже реализованы в реальных атаках. Эксперты центра исследования киберугроз Solar 4RAYS ГК «Солар» фиксируют те же векторы: злоумышленники годами живут в сетях, крадут данные или уничтожают инфраструктуру — все из-за таких простых ошибок. Как именно это происходит — разбираем на примерах.

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

Единственный способ узнать, не находится ли кто-то чужой в вашей сети прямо сейчас — Compromise Assessment (CA), или оценка компрометации. Для вашей инфраструктуры это то же, что для вас профилактический осмотр у стоматолога. Тот случай, когда не ждете острой боли, чтобы проверить, не завелся ли кариес. Однако CA не лечит и не ставит пломбы, но честно показывает, кто уже поселился в вашей сети и как давно. Если говорить прямо, CA собирает артефакты и ищет следы присутствия — те, что не видят, например, EDR и SIEM. А еще такая проверка покажет, побывали уже злоумышленники в вашей инфраструктуре раньше и успели ли замести следы. К тому же Compromise Assessment обычно проводится такими же методами, технологиями и людьми, которые  задействуются в полноценных расследованиях и реагировании на инциденты.

В этой статье мы разберем, в каких ситуациях Compromise Assessment необходим, чем он отличается от привычного пентеста, как правильно подготовиться к проверке и что делать с ее результатами, чтобы не допустить повторного взлома.

Всем привет, на связи Solar appScreener!
В этой статье расскажем о нашем опыте использования ИИ в нашем собственном продукте.

ИИ‑агенты уже стали неотъемлемой частью процесса разработки, это больше не мимолетный хайп, а новая реальность. По данным исследования Sonar (State of Code Developer Survey 2026, https://www.sonarsource.com/state‑of‑code‑developer‑survey‑report.pdf), 72% разработчиков, попробовавших использовать ИИ, стали использовать его ежедневно. А 42% всего написанного кода уже сгенерирован ИИ, или существенно им доработан. Какие‑то запредельные числа. Стоит признать, что мы живем в новой реальности, в которой вайбкодинг — это новый стиль программирования.

Выявить уязвимость до того, как ею воспользуются злоумышленники, разобраться в тонкостях безопасности информационных систем, освоить инструменты пентестеров под руководством опытных наставников — всё это можно попробовать на практике на стажировке в DSEC by Solar. Ждем ваши заявки до 10 мая!

Привычные средства защиты информации не способны отловить все без исключения угрозы. У каждого СЗИ есть слепые зоны: то, чего оно еще не видело или не умеет распознавать. Одно из решений данной проблемы — это использование фидов Threat Intelligence, которые в режиме 24/7 обогащают такие решения, как SIEM, NGFW, EDR, XDR и другие внешним контекстом — индикаторами компрометации, правилами детектирования и информацией о тактиках атакующих.

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

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

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