Роман Семёнов: «ИИ не заменит аналитика SOC, но поможет оперативнее реагировать на угрозы и инциденты ИБ»

Сегодня в 11:52

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

В интервью журналу RUБЕЖ Роман Семёнов, директор Департамента мониторинга и реагирования на киберугрозы блока информационной безопасности «Ростелеком», рассказал, как справиться с проблемой ложных срабатываний, какие инструменты сегодня незаменимы для SOC, как автоматизация помогает разгрузить аналитиков и какую роль искусственный интеллект может занять в мониторинге и реагировании на инциденты.

RUБЕЖ: Сколько инцидентов в месяц реально расследует ваша команда и какая доля из них оказывается критичной?

Роман Семёнов: На текущий момент дежурные смены SOC «Ростелекома» обрабатывают десятки тысяч подозрений на инцидент в месяц, но не более сотни из них квалифицируются как реальные инциденты ИБ.

Что касается критичных или сложных инцидентов, то здесь цифра «плавающая»: в какие-то периоды их может не быть совсем, а в какие-то их количество может достигать десятка. За всё время существования центра мониторинга ИБ «Ростелекома» эта цифра не превышала пары десятков полноценных расследований в месяц (в том числе с привлечением команд из других блоков).

Помимо мониторинга и обработки так называемых «классических» инцидентов ИБ, мы обеспечиваем защиту от DDoS-атак инфраструктуры «Ростелекома» и его клиентов. Так как за последние несколько лет количество таких атак кратно увеличилось, мы перестали учитывать их как отдельные инциденты и перевели в разряд операционной деятельности по обеспечению ИБ.

RUБЕЖ: Что чаще всего становится первым сигналом об атаке: аномалия в трафике, срабатывание защиты или сообщение от сотрудника?

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

Основными сигналами о подозрении на инцидент являются события от подключенных источников информации. К ним можно отнести и аномалии в трафике и сигналы о срабатывании различных систем защиты.

RUБЕЖ: Какой этап расследования «съедает» больше всего времени: сбор данных, анализ или согласование действий?

Р. Семёнов:  Самые трудоемкие этапы (по разным причинам) — это сбор и анализ данных. С согласованием действий, как правило, всё проще: мы еще не встречали работников, которые при наступлении инцидента ИБ отказывались бы делать то, что им говорят. Сложности могут возникнуть позднее — на стадии пост-анализа или на этапе выработки мер недопущения инцидента: здесь сроки согласования могут занимать какое-то время. Однако это уже будет когда-то потом, а не в момент активного «тушения пожара».

RUБЕЖ: Назовите три инструмента в вашем SOC, без которых вы не представляете работу. И один - от которого готовы отказаться.

Р. Семёнов: Я точно не готов отказаться от SIEM (системы управления информацией и событиями безопасности), SOAR (системы оркестрации, автоматизации и быстрого реагирования на инциденты ИБ) и электронной почты.

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

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

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

От чего точно готов отказаться, так это от классического настольного телефонного аппарата. Да, у нашего SOC есть несколько городских линий (в формате 8-800 и +7-499), а также короткий внутренний номер. Однако с развитием современных средств ВКС и внутренних корпоративных чатов, телефонный аппарат кажется атавизмом.

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

RUБЕЖ: Как вы отличаете реальную угрозу от ложного срабатывания, когда оба события выглядят похоже?

Р. Семёнов: Ложное срабатывание не всегда является таковым по сути. Мы выделяем так называемые «True False Positive срабатывания», когда правила и алгоритмы сработали штатно, но в это время, например, проводились какие-то технические работы, о которых нам по разным причинам ещё не успели сообщить.

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

Некоторое время назад мы пропускали все подобные случаи через процедуру case review[1], но это не приносило каких-то значимых результатов. С появлением SOAR мы сфокусировались на автоматизации: сформировали условный перечень 10 главных причин срабатываний, настроили обогащение данными из внутренних (а иногда и внешних) систем, пропустили всё через алгоритмы машинного обучения и в итоге исключили человека из цикла обработки. Нам стало гораздо легче.

[1] Процедура case review — это систематический анализ конкретного события с целью выяснения причин произошедшего и определения возможных путей улучшения ситуации в будущем.

RUБЕЖ: Что важнее для обнаружения сложной атаки: больше данных или более умные алгоритмы их обработки?

Р. Семёнов: Считаю, что здесь важен баланс. Без больших объёмов данных или достаточного количества их источников умные алгоритмы, которые кто-то должен написать и обучить, не работают. И наоборот, огромные массивы неструктурированных данных увеличивают риск ложных срабатываний. Баланс же достигается, когда количество источников и глубина телеметрии позволяют алгоритму выявлять пусть и неявные, но значимые паттерны.

RUБЕЖ: Сколько времени нужно новому аналитику, чтобы начать самостоятельно расследовать инциденты в вашей команде?

Р. Семёнов: В SOC «Ростелекома» есть несколько линий реагирования, а значит, и уровни компетенций аналитиков, которые на них работают, будут разными.

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

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

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

RUБЕЖ: Как вы принимаете решение: реагировать своими силами или привлекать внешнюю экспертизу?

Р. Семёнов: Мы не используем стороннюю экспертизу, вместо этого активно развиваем собственную. Решения принимаются на основе анализа данных Центром мониторинга ИБ «Ростелеком». Именно здесь происходит оперативное управление инцидентами, осуществляется разработка новых сценариев реагирования и проактивный поиск угроз.

В блоке ИБ «Ростелеком» есть и другие департаменты, экспертиза которых позволяет нам держать руку на пульсе.

RUБЕЖ: Какая задача в мониторинге и реагировании до сих пор не имеет хорошего решения на рынке? Ведется ли разработка таких решений, по вашим данным? 

Р. Семёнов: Здесь я бы выделил две самые болезненные проблемы, которые сегодня не решает ни один продукт: полная автоматизация реагирования и огромное количество ложных срабатываний.

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

RUБЕЖ: Что изменится в работе SOC через 2–3 года, на ваш взгляд?

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

Если смотреть на исследования различных компаний, то можно сделать вывод о том, что всё больше операций будет отдано под управление ИИ — от автоматизации при реагировании до автоматического подключения источников к мониторингу. Уже сейчас существуют продукты, которые позволяют полностью автоматизировать обнаружение и классификацию данных, их нормализацию и обогащение. Внедрение ИИ позволит более качественно и быстро обрабатывать подавляющее количество угроз и подозрений на инциденты ИБ, и оперативнее реагировать на них. Но в ближайшей перспективе рано говорить о том, что большинство операций, которые сейчас существуют в SOC, будет отдано под управление ИИ. Скорее, это будет эксплуатация в режиме copilot (умного помощника): ИИ-ассистенты будут помогать аналитикам решать различные задачи, но не заменят их полностью.

RUБЕЖ: Если бы вы начинали строить SOC сегодня, что сделали бы иначе, опираясь на текущий опыт?

Р. Семёнов: Если исходить из того, что SOC — это совокупность людей, технологий и процессов, то я бы совершенствовал именно процессы. Причем как внутренние, так и те, что обеспечивают взаимодействие с заказчиками от бизнеса.

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

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

Не случайно после каждого значимого инцидента ИБ мы внутри команды устраиваем «разбор полетов» (или так называемый lessons learned): определяем, где сработали на отлично, а что можно было бы улучшить; выявляем лишние действия в цепочке, которые больше не стоит повторять.  Все эти выводы мы регламентируем и вносим в базу знаний, которая содержит описания всех процессов.

Читайте также: Игорь Бедеров: «Границ между безопасностью физической и информационной больше не существует»