- Регистрация
- 27 Апр 2025
- Сообщения
- 51
- Реакции
- 0
- Баллы
- 6
Как МТС повысила уровень кибербезопасности без раздувания IT-бюджета
Повышение уровня кибербезопасности — это не всегда новые системы защиты и горы СЗИ. Зачастую достаточно пересмотреть процессы и приоритеты. Разберём, как с этим справились в МТС.
---
Вызовы старой модели доверенной сети
Экономическая цель любой IT-инфраструктуры — минимизировать издержки: меньше ручной работы, меньше сбоев и вызовов в авральном режиме. В результате внутри сети возникает клише “все свои”: VPN работает, фаервол включён — и “проходите, Вася”. Проблема в том, что злоумышленники давно уже внутри — используют устаревшие SMB, принтеры или старые VPN-шлюзы для проникновения.
Пример: в 2013 году злоумышленники проникли в сеть Target через поставщика климат-контроля. В 2024 году через уязвимый VPN они эксплуатировали CVE-2023-46805 и CVE-2024-21887, реализуя веб-шеллы GLASSTOKEN и BUSHWALK. Всё прошло тихо — алерты молчали 48–72 часа.
Вывод: классическая доверенная сеть — это дырявая дверь без охраны.
---
Zero Trust как главный путь вперёд
Zero Trust — звучит жёстко, но это реальная необходимость. Принципы, которые мы применили:
1. Проверять явно
Каждый доступ — это отдельный гость на входе: аутентификация, авторизация, проверка цели визита. Даже админ проходит 2FA и анализ поведения, прежде чем получить доступ.
2. Минимум прав
— Just-In-Time: доступ на определённое время
— Just-Enough-Access: только нужные ресурсы
— Адаптивные политики: права ужесточаются при риске
3. Предполагаем компромисc
Даже если злоумышленник внутри, его доступ жёстко ограничен. Перехват зашифрованных данных внутри сегментации, мониторинг аномалий и Canary-метки: всё это необходимо.
4. Контекстная аутентификация
Анализ “цифрового почерка”: ритм набора текста, давление клавиш, геолокация, поведенческие метрики — всё чтобы понять, что перед вами реальный пользователь.
---
Как это реализовали в МТС
Кластерный подход ИБ-архитектуры
ИБ-архитекторы больше не занимаются всем подряд. Введены кластеры по бизнес-продуктам:
— Внутренние сервисы
— IoT-продукты
— Медиасервисы (KION, МТС-музыка)
— Телеком-решения
Команды продуктов взаимодействуют только с безопасниками своего кластера — знания углубляются, а ответственность питкает именно на нужных специалистов.
Задача 1: пилот и коммуникация
Создан пилотный кластер — там отрабатывали процесс взаимодействия между безопасниками и продуктовыми командами. Состоялись митапы, обсуждения, доказывали ценность перемен. Это помогло переходу от роли “контролёров” к “Security Business Partners”.
Задача 2: автоматизация заявок
Упразднён конвейерный подход в заявках. Все обращения поступают в Service Desk, затем автоматически передаются на конкретного архитектора кластера. Так выросла ответственность и контекстный уровень обработки.
Задача 3: лидеры или Centers of Competency
На уровне компании созданы центры компетенций (ЦК) в DevOps, SRE и ИБ. В ИБ-кластерах назначены лидеры-главные архитекторы. Это позволило унифицировать практики по всей экосистеме МТС.
---
Лайфхаки на основе опыта МТС
1. Не ломайте всё сразу
Начинайте преобразования только если есть чёткое понимание проблемы и готовность к сопротивлению сотрудников и топ-менеджмента.
2. Избегайте конвейера в заявках
Назначайте ответственных в зависимости от продукта/кластера — так усиливается специализация и глубина экспертизы.
3. Используйте метрики
Даже при отсутствии явных проблем метрики (OWASP SAMM, BSIMM) позволяют раннее выявить системные сбои.
4. Гибкие SLA и разумные сроки
Пентест может занимать месяц, но ревью кода перед выкатыванием рекомендуется завершать за пару дней. Это позволяет органично вписаться в цикл разработки.
---
Итоговый результат
— Упрощение инфраструктуры — без взрыва бюджетов
— Чёткие роли и зоны ответственности
— Контекстное взаимодействие, а не реактивные проверки
— Дальнейшая масштабируемость на всю экосистему
— Повторяемые и контролируемые процессы безопасности.
Повышение уровня кибербезопасности — это не всегда новые системы защиты и горы СЗИ. Зачастую достаточно пересмотреть процессы и приоритеты. Разберём, как с этим справились в МТС.
---
Вызовы старой модели доверенной сети
Экономическая цель любой IT-инфраструктуры — минимизировать издержки: меньше ручной работы, меньше сбоев и вызовов в авральном режиме. В результате внутри сети возникает клише “все свои”: VPN работает, фаервол включён — и “проходите, Вася”. Проблема в том, что злоумышленники давно уже внутри — используют устаревшие SMB, принтеры или старые VPN-шлюзы для проникновения.
Пример: в 2013 году злоумышленники проникли в сеть Target через поставщика климат-контроля. В 2024 году через уязвимый VPN они эксплуатировали CVE-2023-46805 и CVE-2024-21887, реализуя веб-шеллы GLASSTOKEN и BUSHWALK. Всё прошло тихо — алерты молчали 48–72 часа.
Вывод: классическая доверенная сеть — это дырявая дверь без охраны.
---
Zero Trust как главный путь вперёд
Zero Trust — звучит жёстко, но это реальная необходимость. Принципы, которые мы применили:
1. Проверять явно
Каждый доступ — это отдельный гость на входе: аутентификация, авторизация, проверка цели визита. Даже админ проходит 2FA и анализ поведения, прежде чем получить доступ.
2. Минимум прав
— Just-In-Time: доступ на определённое время
— Just-Enough-Access: только нужные ресурсы
— Адаптивные политики: права ужесточаются при риске
3. Предполагаем компромисc
Даже если злоумышленник внутри, его доступ жёстко ограничен. Перехват зашифрованных данных внутри сегментации, мониторинг аномалий и Canary-метки: всё это необходимо.
4. Контекстная аутентификация
Анализ “цифрового почерка”: ритм набора текста, давление клавиш, геолокация, поведенческие метрики — всё чтобы понять, что перед вами реальный пользователь.
---
Как это реализовали в МТС
Кластерный подход ИБ-архитектуры
ИБ-архитекторы больше не занимаются всем подряд. Введены кластеры по бизнес-продуктам:
— Внутренние сервисы
— IoT-продукты
— Медиасервисы (KION, МТС-музыка)
— Телеком-решения
Команды продуктов взаимодействуют только с безопасниками своего кластера — знания углубляются, а ответственность питкает именно на нужных специалистов.
Задача 1: пилот и коммуникация
Создан пилотный кластер — там отрабатывали процесс взаимодействия между безопасниками и продуктовыми командами. Состоялись митапы, обсуждения, доказывали ценность перемен. Это помогло переходу от роли “контролёров” к “Security Business Partners”.
Задача 2: автоматизация заявок
Упразднён конвейерный подход в заявках. Все обращения поступают в Service Desk, затем автоматически передаются на конкретного архитектора кластера. Так выросла ответственность и контекстный уровень обработки.
Задача 3: лидеры или Centers of Competency
На уровне компании созданы центры компетенций (ЦК) в DevOps, SRE и ИБ. В ИБ-кластерах назначены лидеры-главные архитекторы. Это позволило унифицировать практики по всей экосистеме МТС.
---
Лайфхаки на основе опыта МТС
1. Не ломайте всё сразу
Начинайте преобразования только если есть чёткое понимание проблемы и готовность к сопротивлению сотрудников и топ-менеджмента.
2. Избегайте конвейера в заявках
Назначайте ответственных в зависимости от продукта/кластера — так усиливается специализация и глубина экспертизы.
3. Используйте метрики
Даже при отсутствии явных проблем метрики (OWASP SAMM, BSIMM) позволяют раннее выявить системные сбои.
4. Гибкие SLA и разумные сроки
Пентест может занимать месяц, но ревью кода перед выкатыванием рекомендуется завершать за пару дней. Это позволяет органично вписаться в цикл разработки.
---
Итоговый результат
— Упрощение инфраструктуры — без взрыва бюджетов
— Чёткие роли и зоны ответственности
— Контекстное взаимодействие, а не реактивные проверки
— Дальнейшая масштабируемость на всю экосистему
— Повторяемые и контролируемые процессы безопасности.