Запускаем свой SOC или подключаем внешний?

Запускаем свой SOC или подключаем внешний?
Пока завсегдатаи ИБ-форумов рассуждают о новейших технологиях в Security Operations Center, по умолчанию считая центр мониторинга и реагирования на киберугрозы необходимой частью современной инфраструктуры, в реальном мире многие продолжают работать без него. И это касается не только небольших компаний, но и крупных организаций, потому что чем больше экосистема ИТ-решений, тем сложнее пристроить к ней даже базовый уровень мониторинга и реагирования на события ИБ.

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


Внутренний или внешний SOC?


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

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

В итоге типовой проект построения SOC на стороне заказчика растягивается на 2-3 года.

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

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

При этом использование внешней экспертизы для обнаружения угроз ИБ тоже связано с целым рядом опасений. Во-первых, заказчики часто предполагают, что внешний SOC сразу после подключения завалит их своими готовыми процессами. А поскольку отдел ИБ обычно и так весьма загружен, перспектива настраивать передачу данных из десятка-другого систем выглядит не очень радужно.

Во-вторых, возникает проблема «знакомства» подрядчика с инфраструктурой заказчика. На первый взгляд все это выглядит как тот же самый аудит, который необходимо проводить перед проектом. И на этом этапе у многих возникает вопрос: «А какая тогда разница, строить свое или подключать сервис?». При этом разница, конечно, есть – дальнейшие этапы подключения к внешнему SOC проходят намного быстрее.

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

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

Бизнес-интервью


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

• Как устроена инфраструктура в целом, ее объем, распределенность
• Особенности сетевой топологии: в каких сегментах сети находятся продуктивные системы, где ЦОД, где DMZ, где размещаются администраторы, а где обыкновенные пользователи
• Ключевые политики компании по управлению доступом, проводимым изменениям, и естественно обеспечению информационной безопасности
• Какие информационные системы являются наиболее критичными для деятельности компании (кроме тех, которые очевидны из нашего опыта работы с конкретной отраслью), где они располагаются
• Используется ли в инфраструктуре удаленный доступ (администраторами, пользователями, подрядчиками) и как он организован и т.д.

Подготовка базовых сценариев


После беседы становится понятно, какие системы могут выступать источниками данных, какие из них нужно мониторить в первую очередь. Также появляется возможность построить начальный прогноз и некоторый RoadMap развития сервиса SOC.

Подключение основных компонентов


В каждой компании есть набор базовых инфраструктурных систем. Например, практически все используют Active Directory, один из антивирусов, системы межсетевого экранирования, системы контроля доступа в Интернет (прокси), системы централизованной инвентаризации (SCCM) и так далее. При поступлении потока данных из этих систем мы начинаем видеть некоторый набор событий. И, хотя на этом этапе в зоне нашей видимости далеко не полный перечень элементов инфраструктуры, собранные данные помогают дополнить информацию, полученную в ходе бизнес-интервью — подтвердить или выявить отличия. Например, на интервью нам говорят, что для удаленного доступа используется только протокол RDP и программа Remote Administrator, а на практике может выясниться, что администраторы и пользователи применяют в работе целый спектр систем.

Профилирование мониторинга


Подключение новых систем позволяет получать все больше данных и начать применять общие правила (которые уже сформулированы как best practice). Но главное, что на этом этапе мы уже можем накапливать статистику. Становится понятно, как выявление инцидентов работает в продуктиве (но данные об инцидентах заказчику пока не отправляются).

Такое профилирование может продолжаться 1–2 месяца. Мы изучаем, кто и к каким ресурсам обращается. Определяемся, какой трафик считать легитимным, а какой — нет. Также для профилирования могут применяться данные из интервью. Но реальность, как правило, отклоняется от принятых практик. Например, нередко выясняется, что тот или иной администратор заходит в критически важные базы данных прямо со своей рабочей станции, причем с root-правами, вместо того, чтобы использовать для этого персональную учетную запись и промежуточный терминальный сервер. И что, несмотря на запрет использовать в компании Remote Access Tools, служба Help Desk по согласованной позже служебке все-таки применяет Team Viewer для работы с удаленными точками продаж или выездными сотрудниками. В такой ситуации нужно действовать аккуратно, чтобы фактически запустить процесс выявления инцидентов как можно скорее, но не заваливать службу ИБ заказчика сотнями уведомлений по тем событиям, которые формально не соответствуют политике ИБ, но по сути являются утвержденной и рабочей практикой жизни компании.

Адаптация к реальности и запуск


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

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

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

Бонусы для заказчиков


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

Например, одной из довольно распространенных рекомендаций оказывается такая банальность, как «Поставить галочку в антивирусе “не только обнаруживать, но и удалять”». У многих эта опция не включена, и сообщения о тех же самых вирусах копируются и множатся день ото дня. Начало работы с внешним SOC подсвечивает проблемные зоны систем защиты и позволяет понять, где нужно просто обновить конфигурации.

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

Но главный плюс заключается в том, что мониторинг инцидентов ИБ можно подключить за 1–2 месяца. Конечно, срок может меняться и увеличиваться в зависимости от особенностей работы заказчика: от большой нагрузки в области операционной деятельности, отпусков персонала, привлечения подрядчиков и так далее.

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

После подключения сервиса SIEM-система постепенно обрастает данными и статистикой, происходит масштабирование решения и подключение новых источников. Главный секрет — не пытаться сделать все сразу, а подойти к развитию системы как к воспитанию щенка. Сначала это “Сидеть”, “Лежать”, а уже потом сложные трюки.

Построить SOC самостоятельно


Несколько практических советов для тех, кто хочет строить свой собственный SOC:

● Начните выстраивать защиту вокруг наиболее критических элементов инфраструктуры.

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

● Четко сформулируйте свои цели. Очень часто в ходе интервью мы не можем получить ответ на вопрос, что клиент хочет видеть на выходе, и что он понимает под аббревиатурой SOC на практике.

● Не пытайтесь охватить сразу необъятное. Подробное ТЗ – это хорошо и правильно, но если из-за сложности проекта сдвинутся сроки и раздуется бюджет, никто не выиграет.

● Если нет понимания, как именно стоит выстроить процессы, начните с сервиса внешнего мониторинга. Это никак не противоречит созданию своего SOC, но помогает выстроить процессы и перенять опыт у практиков в сфере ИБ.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите , пожалуйста.

Как сделать опрос?)

  • 50,0%Просто1
  • 0,0%Сложно0
  • 50,0%У меня лапки!)1

А какой SOC выбрали бы вы?

  • 50,0%1) Свой1
  • 0,0%2) Внешний0
  • 0,0%3) Комбинацию0
  • 50,0%4) Хотел бы я знать…1
Alt text

Большой брат следит за вами, но мы знаем, как остановить его

Подпишитесь на наш канал!