Вторая линия, виртуальная

Ротация - важнейший инструмент борьбы с выгоранием, чем неизбежно страдает любой SOC. Многие психологические исследования, да и мой личный опыт, подтверждают, что мы отдыхаем от смены вида деятельности ( а безделье, напротив, зачастую утомляет), поэтому нам нужно обеспечить смену деятельности.

Из общения с различными менеджерами SOC, да и процессе собеседований с потенциальными коллегами на операционные линии, сложилась уверенность, что в большинстве SOC есть первая линия аналитиков, действующая практически полностью по алгоритму (~плейбуку) и более-менее проявить инициативу можно только на "второй" линии. При этом мне никто не объяснил, почему, если работа первой линии столь детально алгоритмизирована, ее нельзя полностью автоматизировать, да хоть даже с использованием машобуча. Да, есть определенные различия в квалификации аналитиков, в опыте, но это все равно не повод полностью обламывать крылья, превращая аналитиков SOC в биологические автоматы. Чтобы люди умели принимать решения,  им надо давать возможность принимать решения!

Постоянно раздумывая о проблематике, намеченной выше, мы в конечном счете пришли к выводу, что у нас не будет нескольких операционных линий с жестким назначением аналитиков. Я уже рассказывал (и раньше в этом посте есть ссылка на запись доклада), что "первой линией" в нашем случае является Автоаналитик, являющийся частью конвейера обработки телеметрии, а на команду SOC уже попадает меньше фолсы. Вместо нескольких у нас есть одна операционная линия, среди которой по расписанию выделяется группа, выполняющая функции второй линии. Поскольку состав группы по расписанию меняется каждую неделю, внутри мы ее называем "Виртуальная вторая линия" (Virtual Second Line, VSL). 

На VSL выпадают все более-менее творческие задачи за рамками расследования алертов, причем назначение конкретных членов VSL на функциональные участки также приводится в расписании, мы это тоже постоянно ротируем. Для понимания приведу примеры некоторых функциональных участков для VSL .

• Операционка. Эта группа занимается расследованием алертов, как и дежурные, но на нее дежурные могут выполнить эскалацию. При получении такой эскалации данная группа VSL (конкретный аналитик, на кого передали кейс) переключается на работу по эскалации и доводит ее до конца. По завершении работы на эскалации, снова "превращается" в операционного аналитика, расследующего поступающие алерты. Такой режим работы используется при высокой нагрузке команды SOC в целом (большой объем работы, много алертов и/или инцидентов). В более спокойное время, под операционку не выделяется группа из состава VSL, а на эскалации переключаются из других направлений (например, аналитик занимался ретро-хантингом, но, получив эскалацию. переключился на нее, а по окончании - продолжил проверять свои гипотезы)
• Перепроверка. Известно, что мы перепроверяем за Автоаналитиком, но мы перепроверяем и за аналитиками. Приоритезация перепроверки (за кем следует посмотреть побольше) управляется метриками SOC (в частности, на основе конверсии). Типы ошибок аналитиков я привел в докладе на слайде 32, ошибки регулярно обсуждаются, и тенденция к их уменьшению доказывает полезность этого мероприятия.
• Периодический ретро-хантинг. Не все гипотезы реализованы в виде алертов, ввиду своей склонности к ложным срабатываниям. Но это не отменяет необходимость их проверки вручную. Для ретро-хантинга есть несколько критериев. которые позволяют его применять с большей результативностью.
• Фильтрация, адаптация детектирующей логики. Давно писали о разных типах ложных срабатываний, с т.з. этой статьи "контекстные" ложные срабатывания в ответственности операционной группы и на их расследование требуются ресурсы.

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