Любая современная компания, независимо от отрасли, представляет собой систему взаимосвязанных процессов, которые позволяют контролировать промежуточные показатели и принимать управленческие
решения. Все подразделения компании должны быть охвачены процессной моделью, и абсолютно точно процессный подход должен применяться в подразделениях кибербезопасности.
В 2017 году в ходе трансформации Security Operation Center (SOC) Сбербанка была внедрена процессная модель в обеспечении кибербезопасности банка. Сегодня мы работаем над ее совершенствованием и
развитием. Следующий шаг ― автоматизация в первую очередь основных процессов, связанных с реагированием.
Развитие SOC в Сбербанке
SOC Сбербанка развивается, к SIEM-системе подключается всё большее количество источников данных. Мы разрабатываем сложные сценарии реализации угроз кибербезопасности (use case), по которым
создаются инциденты. Во втором квартале 2018 года SIEM Сбербанка обработала 280 млрд событий из различных источников ― в среднем 3,1 млрд в сутки. В результате корреляции событий на обработку
аналитикам поступило 9213 подозрений на инцидент, из которых 3810 представляли реальную угрозу.
Каждое подозрение на инцидент требует обработки аналитиками линий реагирования в соответствии с заранее разработанными инструкциями (playbooks). При этом необходимо выдержать ряд критичных метрик.
Например, время взятия в работу инцидента в SOC Сбербанка не может превышать пяти минут. Как обеспечить необходимую скорость реагирования при таком количестве инцидентов, возникающих в крупной и
территориально распределенной инфраструктуре Сбербанка? Это возможно только при наличии эффективной и производительной технологической платформы SOC.
SIEM-система получает события от источников, проводит их нормализацию, выявляет подозрительную активность, используя корреляционные правила. Подозрительные события поступают в ticketing-систему,
где с ними работают аналитики SOC. При этом по каждому подозрительному событию проводится проверка на корректность: аналитик первой линии проверяет, не является ли оно ложным (false positive). На
следующих линиях реагирования проводится категорирование: инциденту присваивается уровень критичности, выполняются действия по локализации, уничтожению угрозы и восстановлению нормальной работы.
Для выполнения этих действий сотрудникам каждой линии реагирования необходимо пользоваться дополнительными инструментами, входить в консоли средств защиты, получать дополнительную информацию из
других АС и инфраструктурных элементов, число которых может составлять десятки и даже сотни единиц. При этом аналитик должен иметь необходимый уровень доступа ко всем этим элементам и уметь
свободно их использовать.
У данной схемы есть и недостатки. К ним относятся длительное время решения инцидентов и риск возникновения ошибок, связанных с человеческим фактором ― ошибочными действиями аналитиков.
Автоматизация процесса поможет решить эти проблемы. Технологической платформе SOC необходим отдельный узел или компонент для управления действиями, которые требуется выполнять на средствах защиты,
автоматизированных системах и инфраструктурном оборудовании.
Автоматизация процессов кибербезопасности
В целом тема автоматизации и роботизации процессов ― одна из самых обсуждаемых в профессиональном сообществе. В Сбербанке и других организациях есть успешные кейсы применения роботизации и
автоматизации процессов в различных областях. Для автоматизации процессов кибербезопасности существует отдельный класс систем – Incident Response Platform (IRP), платформа реагирования на
инциденты.
На рынке IRP-систем представлено несколько решений, среди них есть разработки и российских компаний. Этот сегмент достаточно молодой, решения довольно сильно отличаются в части реализуемого
функционала. Помимо собственно оркестрации и функционала workload automation, интерес вызывают возможности интеграции c внешней ticketing-системой и другими элементами технологической платформы.
Это даст возможность реализовать интеграцию, позволяющую использовать уже внедренную ticketing-систему SOC. Аналитики смогут работать в едином интерфейсе управления инцидентами, при этом действия,
которые можно автоматизировать, будут выполняться через запрос из ticketing-системы в IRP, а результат их выполнения поступает обратно в ticketing-систему.
Функционал IRP
Рабочий процесс ― алгоритм, реализующий автоматизированную часть дежурной процедуры. Он имеет графическое представление в интерфейсе IRP, состоит из скриптов, переменных, хранящих результаты
выполнения скриптов, и логических условий, реализующих переходы и ветвление в рамках рабочего процесса. Рабочий процесс может содержать неограниченное количество вложенных рабочих процессов.
Коннектор ― модуль IRP, обеспечивающий подключение к конечным системам по заданным протоколам взаимодействия с указанием необходимых параметров и выполнение скриптов для внесения изменений в
конфигурации и настройки конечных систем.
Скрипт ― набор команд, выполняемых для совершения типовой операции, например блокирования учетной записи пользователя или закрытия порта.
Настройка всех подключений происходит внутри IRP через настройку соответствующих коннекторов. Скрипты и рабочие процессы настраиваются здесь же. Для аналитиков SOC IRP выступает как внешний сервис,
в который передаются входные параметры из карточки события ticketing-системы и возвращаются результаты выполнения скрипта, в том числе обогащенные данные. В итоге аналитики избавляются от
необходимости вручную собирать информацию, требуемую для принятия решения, и получают возможность быстро выполнить то или иное действие в инфраструктуре: например, блокировку пользователя,
отключение АРМ от сети прямо из интерфейса ticketing-системы. Это позволяет значительно повысить скорость решения инцидентов и, как следствие, снизить возможное влияние инцидентов кибербезопасности
на работу банка, исключить возможные ошибки сотрудников.
Подобная система должна обладать достаточным уровнем гибкости ― специалистам необходимо иметь возможность самостоятельно изменять настройки коннекторов, а также создавать новые коннекторы без
привлечения вендора. В требования к системе входит наличие конструктора рабочих процессов, позволяющего в графическом режиме строить такие процессы и связывать их с исполняемыми скриптами.
Стоит учесть, что платформа реагирования на инциденты кибербезопасности сама может стать объектом атаки. Получив несанкционированный доступ к системе, перехватив управляющий трафик между
компонентами системы, злоумышленник может нанести значительный урон ИТ-инфраструктуре. Поэтому к системе предъявляются очень серьезные требования безопасности: к хранению аутентификационной
информации, ролевой модели, защищенному соединению между компонентами, логированию действий сотрудников и журналированию команд, отправляемых скриптами.
Внедрение IRP ― это серьезный шаг в развитии SOC. Он необходим, чтобы обеспечить эффективное реагирование на инциденты кибербезопасности. SOC Сбербанка достиг уровня зрелости, предполагающего
автоматизацию процессов реагирования на инциденты кибербезопасности. Сейчас Сбербанк проводит открытый конкурс по выбору и внедрению платформы реагирования на инциденты кибербезопасности в SOC.
Сегодня на рынке присутствуют компании, в том числе и российские, способные предложить IRP-решения, отвечающие высоким требованиям безопасности Сбербанка. До конца 2018 года мы рассчитываем выбрать
и внедрить IRP-систему.
Александр БОНДАРЕНКО,
руководитель направления отдела средств защиты Сбербанка
Источник: http://www.it-world.ru/it-news/security/141760.html
