В три часа ночи сайт отвечает за привычные 180 миллисекунд. Процессор загружен на 24%, память не заканчивается, резервная копия завершилась по расписанию. По обычному мониторингу всё спокойно. Но в это же время служебная учётная запись входит с нового адреса, веб-процесс запускает оболочку, во временном каталоге появляется исполняемый файл, а через несколько секунд сервер устанавливает соединение с направлением, которого раньше не было.
Каждое событие по отдельности ещё можно объяснить. Администратор мог подключиться из другой сети. Оболочка могла понадобиться служебному скрипту. Новый адрес мог появиться после обновления подрядчика. Вопрос начинается со связки: почему эти действия произошли почти одновременно и почему именно в такой последовательности?
Для таких ситуаций мы создаём CyberSignal — собственную систему WowCash для мониторинга аномалий внутри инфраструктуры. Она собирает согласованную телеметрию с серверов, сопоставляет события с обычным поведением среды и показывает не только сигнал тревоги, но и основания для проверки. Это новое направление нашей работы на пересечении разработки, инфраструктуры, данных и искусственного интеллекта.
Работающий сервис не всегда означает спокойную инфраструктуру
Доступность отвечает на важный, но узкий вопрос: может ли пользователь сейчас открыть сайт или выполнить операцию. Метрики CPU, памяти и диска помогают понять, хватает ли системе ресурсов. Они почти ничего не говорят о том, кто запустил новый процесс, почему изменилась конфигурация, откуда вошла служебная учётная запись и с каким внешним узлом связалось приложение.
Современная атака не обязана начинаться с заметной аварии. Получив действующие учётные данные, нарушитель может пользоваться теми же SSH, PowerShell, планировщиками и административными средствами, что и команда эксплуатации. Отдельная команда выглядит легитимно. Отдельный вход тоже. Подозрительной становится последовательность действий, время, инициатор и несоответствие привычной роли сервера.
Ситуацию меняет и развитие ИИ-инструментов. Они уже помогают исследователям быстрее разбирать большие объёмы кода и находить уязвимые участки. Те же возможности сокращают время отдельных этапов разведки и автоматизации атак. Это не значит, что «ИИ теперь взламывает всё». Значит другое: окно между появлением слабого места и попыткой его использовать может становиться короче, а одной периодической проверки инфраструктуры всё чаще недостаточно.
Периметр показывает, что пришло снаружи. CyberSignal помогает увидеть, что происходит после входа — на самих узлах и между ними.
Зачем мы начали делать CyberSignal
WowCash разрабатывает высоконагруженные сервисы, системы сбора данных, ИИ-инструменты и продукты с большим количеством связей между компонентами. Чем сложнее инфраструктура, тем труднее удерживать её картину в голове. Журнал авторизации живёт в одном месте, события приложения — в другом, сетевые соединения — в третьем. Когда что-то случается, специалисту приходится вручную собирать временную линию из десятков источников.
Нам нужен был инструмент, который не превращает безопасность в бесконечную ленту несвязанных уведомлений. Так появилась идея CyberSignal: наблюдать за поведением каждого узла, хранить контекст и связывать события в понятные эпизоды. Если фоновая задача привычно запускается каждую ночь, это одно. Если похожая задача впервые появилась после необычного входа и сразу породила новое внешнее соединение, это уже другой разговор.
CyberSignal не задуман как замена всему контуру защиты. WAF фильтрует веб-запросы, EDR контролирует конечные устройства, SIEM собирает и анализирует события, резервное копирование помогает восстанавливаться. Наша система дополняет эти уровни внутренней наблюдаемостью и может работать вместе с уже установленными средствами. Конкретный набор интеграций и источников определяется инфраструктурой клиента.
Как сигнал проходит путь от сервера до предупреждения
В основе CyberSignal четыре этапа. Они важны именно в связке: собрать много журналов недостаточно, если команда всё равно не понимает, что требует внимания.
- Агент наблюдает за согласованными источниками. Он получает метрики и события на сервере в пределах выданных прав: информацию о процессах, входах, соединениях, выбранных файлах, службах и заданиях.
- Платформа нормализует телеметрию. Разные форматы приводятся к общей модели. События получают время, узел, пользователя, процесс-инициатор и другие доступные связи.
- Правила и модели ищут отклонения. Система сравнивает наблюдаемое поведение с историей узла, его ролью, заданными ограничениями и связанными событиями.
- Команда получает объяснимое предупреждение. В карточке видны приоритет, затронутый сервер, временная линия и признаки, из-за которых эпизод стоит проверить.
Основная аналитическая нагрузка находится не на клиентском сервере. Агент не ставится между посетителем и сайтом и не требует направлять через CyberSignal весь веб-трафик. Фактическая нагрузка, частота передачи и задержка обнаружения зависят от состава телеметрии, настроек и возможностей конкретного узла — это проверяется во время пилота, а не обещается одинаковым для любой инфраструктуры.
Какие данные дают системе контекст
Нельзя определить состояние инфраструктуры одним графиком. CyberSignal работает с несколькими группами сигналов, а точный состав согласуется до подключения.
- Ресурсы. Нагрузка процессора, память, диск, свободное место и сетевые объёмы помогают увидеть технические отклонения и сопоставить их с другими событиями.
- Процессы. Важны сам запуск, родительский процесс, пользователь, путь к файлу и, когда это разрешено политикой сбора, параметры запуска.
- Сеть. Новые направления соединений, необычная периодичность, изменение объёма передачи и связь соединения с процессом, если её позволяет получить система.
- Учётные записи и права. Успешные и неуспешные входы, изменения пользователей, нетипичное применение служебной учётной записи и события повышения привилегий.
- Файлы и конфигурации. Изменения выбранных каталогов, появление новых исполняемых объектов, метаданные и контрольные суммы там, где такой контроль включён.
- Службы и расписания. Новые фоновые задачи, изменения cron, systemd и других механизмов запуска могут быть штатной работой или способом закрепиться в системе — решает контекст.
- Состояние наблюдения. Последняя связь с агентом, задержка и ошибки сбора. Отсутствие данных нельзя выдавать за отсутствие проблем.
Телеметрия сама может содержать чувствительные сведения. Поэтому мы заранее определяем, какие поля нужны для анализа, где они хранятся, кто получает доступ и сколько времени сохраняется история. По умолчанию мониторингу не требуется копировать базы данных, документы клиента или всё содержимое сетевого трафика. Участие внешних ИИ-провайдеров и использование данных для обучения нельзя подразумевать: такие условия согласуются отдельно.
Аномалия — ещё не доказанная атака
Это принципиальная граница. Новый процесс может оказаться обновлением. Вход ночью — работой дежурного администратора. Резкий рост чтения файлов — резервным копированием. Хорошая система мониторинга не должна называть любой непривычный шаг взломом.
CyberSignal оценивает сочетание признаков и показывает, почему оно отличается от обычного поведения. Важность повышается, если совпали несколько условий: действие произошло впервые, его выполнил нетипичный пользователь, следом изменилась конфигурация, а затем возникло новое сетевое направление. Решение о подтверждённом инциденте принимает специалист после проверки фактов.
Такой подход помогает бороться с двумя крайностями. Первая — пропустить слабый сигнал, потому что каждый журнал по отдельности выглядит нормально. Вторая — завалить команду тревогами, на которые перестают реагировать. Во время внедрения мы отмечаем плановые обновления, резервные копии и регулярные операции, затем настраиваем правила и приоритеты по обратной связи.
Модельный эпизод: четыре события за одиннадцать секунд
Представим сервер веб-приложения. Он продолжает отвечать пользователям, скорость не изменилась. Необходимые источники телеметрии подключены. В 02:13 система видит следующую последовательность:
- 02:13:04. Процесс PHP-FPM запускает командную оболочку. Для согласованного профиля приложения это нетипично, но само по себе ещё не доказывает атаку.
- 02:13:06. Дочерний процесс обращается к исполняемому файлу во временном каталоге, который раньше на узле не наблюдался.
- 02:13:09. Для той же служебной учётной записи появляется новое задание cron.
- 02:13:15. Связанный процесс устанавливает соединение с внешним адресом, отсутствующим в истории этого сервера.
Вместо четырёх независимых писем CyberSignal формирует один эпизод. В нём указаны сервер, время, пользователь, родительские и дочерние процессы, изменённое расписание и сетевое направление. Формулировка должна быть осторожной: «возможное выполнение постороннего кода и попытка закрепления, требуется проверка». Это рабочая гипотеза, а не автоматический приговор.
Первое действие администратора в такой ситуации довольно прозаичное: открыть календарь работ и спросить коллег, не выкатывал ли кто-то обновление. Если ответ отрицательный, эпизод уже даёт отправную точку для принятого в компании регламента — сохранить данные для расследования, при необходимости изолировать узел, заменить затронутые учётные данные и посмотреть, не повторилась ли цепочка на соседних системах. Сам CyberSignal в базовом режиме никого не блокирует: одного вывода модели недостаточно, чтобы останавливать рабочий сервер.
Что видно в рабочей панели
На общей странице мы не пытаемся свести безопасность к одной зелёной лампочке. Там отдельно видны подключённые узлы, свежесть телеметрии и предупреждения, которые ещё никто не разобрал. Если серверов много, список можно сузить до проекта, группы, периода или нужного типа события.
Дальше открывается конкретный узел. Рядом оказываются графики ресурсов, входы, процессы, соединения и изменения, а временная шкала оставляет события в том порядке, в котором они происходили. Предупреждение можно взять в работу, закрыть или пометить как разрешённую активность с пояснением. Через месяц не придётся вспоминать, почему ночной запуск сочли нормальным: решение останется рядом с исходными фактами.
Есть ещё три вещи, которые нельзя смешивать: агент на связи, сервер технически исправен, подозрительных действий не найдено. Узел вполне может отвечать пользователям и одновременно требовать проверки. Переполненный диск, напротив, бывает обычной эксплуатационной проблемой без признаков атаки. А если агент замолчал, честный статус звучит так: «мы не знаем, что происходит сейчас».
Где здесь нужен искусственный интеллект
Вокруг ИИ в безопасности много лишнего шума, поэтому объясним без магии. Когда серверов несколько десятков, за сутки они производят столько нормальных событий, что просмотреть их глазами невозможно. Модели помогают искать в этом потоке связи: сравнивают сегодняшний маршрут процесса с прежними, собирают близкие по времени действия и поднимают наверх эпизоды, которые отличаются сильнее остальных.
Обычные правила при этом остаются. Если служебная запись не должна входить интерактивно, такое условие проще задать явно. Если нужно заметить редкую комбинацию из нового родительского процесса, изменения расписания и исходящего соединения, пригодится поведенческий анализ. У этих подходов разные сильные стороны, и заставлять один изображать другой незачем.
Есть неудобная деталь: вчерашнее поведение нельзя автоматически назвать безопасным. Сервер мог быть скомпрометирован до установки агента, а странный ночной запуск мог годами оставаться незамеченным. Поэтому начальный профиль сверяется с ролью узла и знаниями команды. Для критичных признаков сохраняются отдельные правила. Если данных мало, CyberSignal должен сказать именно это, а не выдавать красивый процент уверенности.
Мы считаем ИИ полезным только тогда, когда после его вывода можно открыть исходные события и задать нормальный инженерный вопрос. Фраза «модель заметила угрозу» бесполезна. Фраза «после входа этой учётной записи веб-процесс запустил новый файл, изменил cron и вышел на незнакомый адрес» уже даёт материал для проверки.
Поиск уязвимости и обнаружение атаки — разные задачи
Эти два этапа легко спутать. Сканер или исследователь изучает код и конфигурацию в поисках слабого места. Мониторинг смотрит на живую среду: не воспользовался ли кто-то доступом и что произошло после этого. Установка патча уменьшает поверхность атаки. Наблюдаемость отвечает на другой вопрос — не успел ли кто-то пройти через зазор до обновления.
Допустим, разработчики библиотеки сообщили об ошибке, а пакет для вашей системы ещё собирается. Сам номер уязвимой версии не доказывает взлом. Но если одновременно веб-процесс породил необычного потомка, появилось новое расписание и началась передача данных незнакомому получателю, у команды есть причина действовать быстрее. CyberSignal нужен для этой второй части истории.
Бывает и наоборот: сканирование ничего серьёзного не нашло, зато пароль подрядчика оказался в чужих руках. Никакой программный «замок» не ломали — вошли через дверь. Система не увидит кражу пароля как таковую, но может заметить, что этой записью впервые пользуются ночью, с другого источника и не на тех серверах, где она обычно нужна.
Именно поэтому мы не называем CyberSignal универсальным сканером уязвимостей. Он наблюдает за доступными событиями работающей инфраструктуры. Аудит кода, обновления, тестирование защищённости и контроль доступов остаются отдельной работой.
Кому пригодится внутренний мониторинг
В первую очередь — компаниям, у которых цифровой сервис уже стал частью основного бизнеса, а огромного центра мониторинга нет. Интернет-магазин не может спокойно выключить заказы на день ради расследования. SaaS отвечает за данные нескольких клиентов. Медиа и рекламная платформа живут в постоянном потоке публикаций, интеграций и подрядчиков. Там особенно важно отличить необычную активность от обычной суеты.
У каждого будет свой повод для сигнала. В одном проекте служебная учётная запись вдруг открывает интерактивную сессию. В другом после входа с нового адреса начинается переход между внутренними узлами. Где-то приложение, которое всегда читало по сотне записей, неожиданно выгружает миллионы. А иногда тревожнее всего выглядит тишина: агент перестал присылать события ровно в момент изменения конфигурации.
Панель сама по себе бизнес не защищает. Польза появляется, когда команда раньше получает повод проверить ситуацию и видит одну временную линию вместо россыпи журналов. Тогда можно ответить хотя бы на первые вопросы: где началось отклонение, какие узлы задеты, чем оно продолжилось.
Что меняется в ежедневной работе команды
Во время инцидента первый час нередко уходит на скучную археологию. Один человек ищет журнал входов, второй вспоминает, где посмотреть дерево процессов, третий выясняет, кому принадлежит внешний адрес. На одном сервере время настроено правильно, на другом отстаёт на две минуты. Часть истории к моменту разбора уже перезаписана.
Мы хотим сократить именно этот этап. Дежурный открывает предупреждение и начинает не с «где лежат логи?», а с конкретной развилки: плановая это работа или нет. Если плановая, он оставляет пояснение. Если нет, передаёт эпизод дальше вместе с объектами и последовательностью действий.
Такие комментарии пригодятся позже. Через месяц очередной ночной запуск не придётся заново объяснять всей команде. А после подтверждённого инцидента сохранённая цепочка помогает проверить соседние узлы и понять, насколько далеко дошла активность.
Для маленькой ИТ-команды это страховка от ситуации, когда всю инфраструктуру помнит один администратор. Для большой — общий язык между эксплуатацией, безопасностью и разработкой. Количество собранных событий тут вторично. Важнее, получилось ли из них сформулировать вопрос, который можно проверить.
Как проходит внедрение CyberSignal
Мы не начинаем разговор с команды установки. Сначала просим нарисовать инфраструктуру так, как её понимают люди, которые с ней работают: вот публичное приложение, здесь авторизация, сюда уходят фоновые задания, а этот старый сервер лучше пока не трогать. Уже на этом этапе часто выясняется, что одинаковые с виду узлы требуют совершенно разного наблюдения.
Для пилота выбираем небольшой, но важный участок. На нём проще проверить права агента, полноту событий и влияние на ресурсы. Одновременно договариваемся, какие сведения вообще разрешено передавать, где они будут храниться и кто увидит предупреждения. Параметры команд или журналы приложений могут содержать секреты — собирать всё «на всякий случай» нельзя.
После запуска начинается не торжественное обучение волшебной модели, а обычная настройка. Команда показывает ночные резервные копии, окна обновлений и работу подрядчиков. Мы смотрим, сохранилась ли связь между пользователем, процессом и соединением, сколько времени проходит до появления сигнала и не создаёт ли агент заметной нагрузки.
У пилота есть простой экзамен. Нужные события приходят; критичный контекст не теряется; предупреждение можно разобрать; ложные срабатывания не забивают очередь. Если один из пунктов не выполнен, сначала исправляем его. Только затем подключаем следующую группу серверов и обсуждаем интеграции с существующими процессами.
Непрерывным в CyberSignal является автоматический анализ. Это не обещание, что возле каждой установки круглосуточно сидит персональный аналитик. Каналы уведомлений, сопровождение, возможные автоматические действия и время реакции задаются условиями конкретного проекта.
Что система делает — и чего не обещает
Ни один мониторинг не видит того, что ему недоступно. Если журнал не подключён, событие не сохранилось или агент вывели из строя, в картине останется пробел. CyberSignal помогает связать собранные факты, но не гарантирует обнаружение любой атаки и не превращает сервер в неприступную крепость.
Обновления, многофакторная аутентификация, минимальные права, WAF, резервные копии и план реагирования всё равно нужны. Система не вернёт события, которые произошли до её установки. И если есть признаки уже случившегося взлома, одного наблюдения мало — требуется расследование.
Нам ближе честный статус «данных недостаточно», чем зелёный экран без оснований. Тогда команда понимает, где мониторинг действительно помогает, где остаётся слепая зона и кто принимает окончательное решение.
Новое направление WowCash
CyberSignal вырос из привычной для WowCash работы. Мы строим цифровые продукты, собираем и приводим к структуре большие объёмы данных, разрабатываем прикладные ИИ-инструменты. На этот раз источником данных стала сама инфраструктура, а результатом — понятный повод проверить её поведение.
На странице услуги мониторинга аномалий и киберугроз описаны состав пилота и результаты для команды. Подключение подстраивается под архитектуру и правила работы с данными. Заставлять компанию выбрасывать весь существующий контур ради ещё одной панели мы не собираемся.
Начнём не с установки агента, а с инфраструктуры: определим критичные серверы, доступные источники событий и ситуации, о которых ваша команда должна узнавать первой.
Если сайт работает, это действительно хорошая новость. Просто теперь мы умеем задать следующий вопрос.