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

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

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

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

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

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

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

Сколько нужно операционной безопасности?

 Во второй день SOC Forum выступал с докладом в секции аналитических отчетов. Выкладываю презентацию. Остановлюсь тезисно на основных вещах, которые хотелось донести.

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

2. Есть определенные различия в языке между CISO и Бизнесом, что в результате сводит общение об ИБ к пугалкам, типа: "Вот страшная-страшная угроза, но внедрив решение Х, уровень риска будет снижен до допустимых значений, нужны средства на этот Х". Подход не блещет новизной, и имеет проблемы эффективности и результативности.

3. На основании аналитики DFIR можно объективно оценить ландшафт угроз, а на базе метрик SOC - возможности соей операционной безопасности. Основной контент презентации - это те или иные цифры из аналитической отчетности, и вопросы, которые имеет смысл себе задать для оценки собственной готовности. Фактически, стоимость необходимой безопасности - это разница между возможностями атакующих (на базе фактических инцидентов, а не какого-то теоретического допущения) и способностями SOC (на базе метрик SOC, которые всегда надо считать, в случае любой операционки, иначе невозможно объективно судить о качестве сервиса)

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

4. Для тех, кто уже имеет SOC, а, следовательно, процесс управления инцидентами, статистика результатов расследования собственных инцидентов - отличный материал для понимания ландшафта угроз, а метрики SOC покажут готовы ли Синие управлять релевантными рисками ИБ.

5. Подход на базе метрик SOC, типа MTTD, MTTR представляется более точным и, самое главное, понятным менеджменту, чем, например, более академические модели оценки зрелости SOC, так как в большей степени подвержены субъективизму со стороны оценщика.

Сколько надо SOC? from Sergey Soldatov

От мониторинга к форенсике и обратно

15.11 выступал на мероприятии с более-менее техническим докладом, выкладываю презентацию.

В докладе были рассмотрены два сценария эскалации - SOC->DFIR и DFIR->SOC, на примере двух реальных инцидентов. Для инцидентов приведены техники и тактики атакующих, а также применяемые методы обнаружения.

От мониторинга к форенсике и обратно from Sergey Soldatov

Приятного просмотра!