Пилотирование SOC: подводные камни

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

Слишком сложный сценарий для пилота

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

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

Иногда заказчики выделяют демо-зоны — часть своей инфраструктуры, на которой можно вносить тестовые изменения во время пилота. Но нужного сценария в демо-зоне может не быть — например, по правилам безопасности клиент не готов передавать определенные логи. 

Логи — сообщения о событиях в системе, важных для информационной безопасности: смене пароля, скачивании файла, загрузке файла на сайт, входе в систему.

В этом случае мы генерируем событие в самой SIEM и показываем, как SOC на него реагирует.

Неготовность пилотировать сразу нескольких провайдеров

В рамках тендеров крупные заказчики обычно пилотируют двух-трех сервис-провайдеров. И иногда они сами не знают, как работать одновременно с несколькими участниками.

У каждого участника может быть свой SIEM, форматы данных между ними могут быть несовместимы. Мы помогаем сделать унифицированную транспортную систему для сбора логов. Настроить все так, чтобы форматы данных были для всех участников универсальны и чтобы логи на пути к SIEM не обрезались и не менялись. 

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

Задержки по времени из-за взаимодействия с ИТ- и ИБ-командами

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

Мы на этапе подготовки пилота говорим заказчику, что необходимо спланировать все ресурсы. Мы прописываем все коммуникации, разделяем источники событий по ответственным группам. И всегда прописываем, кто является основным контактом; с кем можно связаться, если основной контакт недоступен; на кого можно эскалировать, если у заказчика многоуровневая структура. 

Инфраструктура заказчика оказывается не готова к внедрению SOC

На тестовом периоде во время пилота выявляются разные недочеты.
 

Нелегитимные пользователи
У заказчика отображается большое число пользователей, потому что он забыл удалить из системы часть бывших сотрудников. С точки зрения ИБ это может представлять угрозу. Все это потом нужно будет переделывать.

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

Обрезанные логи
Может происходить сбор обрезанных логов — они идут по протоколу UDP, который ограничивает их размер. В таком случае выявлять инциденты тоже невозможно.

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

Отсутствие группы реагирования

Заказчик может внедрить SOC, но не подготовить группу реагирования, которая будет устранять инциденты. Из-за этого работа SOC теряет смысл.

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

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