МТС SOC перешел на SIEM-систему Kaspersky и обрел единый личный кабинет

МТС SOC перешел на SIEM-систему Kaspersky и обрел единый личный кабинет

МТС SOC перешел на SIEM-систему Kaspersky и обрел единый личный кабинет

Компания МТС RED вывела сервисы своего SOC на новый уровень развития. Завершена интеграция Kaspersky Unified Monitoring and Analysis Platform (KUMA), у пользователей появился единый личный кабинет, позволяющий видеть всю аналитику и управлять средствами защиты.

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

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

Частота срабатывания различных правил корреляции и распределение инцидентов по типам позволяют получить представление об актуальных для организации угрозах, выявить слабые места инфраструктуры и оптимизировать настройки систем защиты. В личном кабинете также постоянно отображаются уровень соблюдения центром мониторинга SLA и используемый заказчиком объем показателя EPS (Events Per Second, число событий в секунду), влияющий на стоимость сервисов.

Интерфейс личного кабинета доступен как пользователю, так и дежурной смене МТС SOC. Благодаря этому сотрудник ИБ-службы может в реальном времени видеть, как аналитики центра мониторинга обрабатывают инцидент, и давать свои комментарии во встроенном чате. Заказчику также предоставлена возможность кастомизировать список событий, отфильтровав их по необходимым параметрам: времени, статусу, типу инцидента и проч.

«Заказчикам важно, чтобы сервисы кибербезопасности не были "черным ящиком", — комментирует руководитель МТС SOC Андрей Дугин. — Это и обеспечивает личный кабинет — полную прозрачность работы SOC и возможность оценивать его эффективность на реальных данных. Поскольку мы используем собственные технологии IRP, мы можем быстро откликаться на запросы рынка и гибко управлять планами разработки дальнейших функций личного кабинета».

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

Выбор российской KUMA в качестве SIEM-решения обусловлен ее высокой производительностью и легкостью масштабирования. Коробочное решение поддерживает широкий перечень коннекторов к типовым источникам событий и обладает гибким API, то есть может быть интегрировано как с продуктами самой «Лаборатории Касперского», так и со сторонними разработками.

Критическую уязвимость в ядре Linux x86 не замечали с 2020 года

В ядре Linux обнаружили уязвимость, которая тихо жила в системе несколько лет — и притом в одном из самых чувствительных мест. Речь идёт о механизме обработки page fault на архитектуре x86, то есть о коде, который срабатывает каждый раз, когда процессор фиксирует некорректный доступ к памяти.

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

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

На уязвимость обратил внимание инженер Intel Седрик Син (Cedric Xing), внимательно изучавший код обработки исключений. Как выяснилось, логика в функции do_page_fault() опиралась на устаревшее и, по сути, ошибочное допущение.

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

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

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

Особенно показательной оказалась ветка __bad_area_nosemaphore(), где предпринимается попытка «восстановить правильное состояние», но на деле это происходило не всегда и не одинаково. В результате возникала асимметрия: в зависимости от пути выполнения система могла оказаться в неожиданном состоянии.

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

Патчи уже вошли в ветку Linux 6.19, а также планируются к бэкпорту в поддерживаемые стабильные версии. Фактически оно устраняет дефект, появившийся ещё во времена Linux 5.8.

RSS: Новости на портале Anti-Malware.ru