Soc что это такое в безопасности
SOC for beginners. Задачи SOC: контроль защищенности
Продолжаем цикл наших статей о центрах мониторинга кибератак для начинающих. В прошлой статье мы говорили о Security Monitoring, инструментах SIEM и Use Case.
Термин Security Operations Center у многих ассоциируется исключительно с мониторингом инцидентов. Многим сервис-провайдерам это, в принципе, на руку, поэтому мало кто говорит о том, что мониторинг имеет ряд серьезных ограничения в плане защиты от кибератак.
В этой статье мы на примерах продемонстрируем слабые места мониторинга инцидентов ИБ, расскажем, что с этим делать, и в конце, как обычно, дадим несколько практических рекомендаций на тему того, как провести аудит защищенности инфраструктуры своими силами.
«Уязвимость» Security Monitoring
В чем и сильная, и слабая сторона Security Monitoring? В том, что в первую очередь он оперирует событиями безопасности. Это либо события и срабатывания правил средств защиты информации, либо логи и журнальные файлы: операционной системы, базы данных, прикладного ПО.
При этом есть большое количество ситуаций, при которых либо в логах активность явным образом не фиксируется, либо поток событий или возможности систем не позволяют эффективно организовать процесс мониторинга.
Давайте рассмотрим на примерах.
1. Эксплуатация уязвимостей систем
Рассмотрим достаточно типовую ситуацию: есть существенно защищенный периметр, отдельно выделенный сегмент DMZ и достаточно слабо сегментированная офисная сеть компьютеров. И вот, в этой сети у нас появляется «новый » хост. Принадлежит ли эта машина инсайдеру, или это ноутбук рядового сотрудника, зараженный при помощи социальной инженерии, не столь важно. Злоумышленник начинает точечно заниматься эксплуатацией уязвимости RCE на операционных системах серверов и рабочих станций, доступных ему в рамках сегмента.
Каким образом можно зафиксировать такую проблему? Отсутствие сегментации сети оставляет нас без надежд на детект от сетевых средств защиты, будь то IPS или другие системы. В логах самой операционной системы эксплуатация RCE уязвимости не несет никакого специального кода, и поэтому нет никакой возможности отличить её от обычной попытки аутентификации в ОС. Так или иначе, в логах будет запуск системного процесса svchost.exe от системного пользователя.
Единственной нашей надеждой остаются IDS-модули средств защиты хоста, но, как показывает наша практика, наличие работающего и регулярно обновляемого IDS на всех хостах инфраструктуры – большая редкость.
Вот как выглядит процесс эксплуатации «наболевшей» уязвимости EternalBlue SMB Remote Windows Kernel Pool Corruption (устраняемой обновлением безопасности MS17-010). Обратите внимание, что отсутствие любого из приведенных в примере трех источников не даст нам полной картины и возможности понять, была атака или нет.
В итоге можно надеяться на чудо, а можно начать строить процесс управления уязвимостями и попытаться локализовать проблему еще до ее проявления.
По этой проблеме есть достаточно большое количество специализированных материалов, поэтому заострять внимание на ней не будем. Обозначим лишь несколько тезисов.
«Выиграть гонку» с уязвимостями и построить инфраструктуру с актуальными обновлениями безопасности – задача, практически не реализуемая в крупном корпоративном клиенте. Количество уязвимостей из года в год растет, причем большинство из них среднего и высокого уровня критичности (согласно системе оценки CVSS v2).
Распределение количества уязвимостей по годам в разрезе их критичности (ссылка на источник).
При рассмотрении и составлении карты устранения уязвимостей необходимо не только придерживаться принципа Парето (т.е. выбирать только самую критичную часть для устранения), но и очень тщательно работать с компенсирующими мерами – с достижимостью уязвимости за счет настроек средств защиты, анализом возможных векторов реализации и т.д.
Но это не единственная задача, оставшаяся за скоупом возможностей мониторинга.
2. Профилирование прямого доступа в Интернет
Периодически в глазах службы безопасности SIEM превращается в могучий инструмент, который в состоянии оперировать любыми событиями или потоками данных. В таком случае может возникнуть, например, следующая задача: в рамках компании есть некоторое согласованное количество маршрутов разрешенного прямого доступа в Интернет в обход прокси-серверов. И в целях контроля работы сетевых специалистов перед SIEM ставится задача: контролировать все несогласованные ранее открытия прямых доступов путем анализа сессий из корпоративной сети.
Казалось бы, задача простая и логичная. Но есть несколько ограничений:
В итоге данный вопрос в первую очередь касается управления конфигурациями и контроля изменений. И, несмотря на теоретическую возможность решения этой задачи с помощью мониторинга, многократно эффективнее оперировать специализированными средствами и уже в SIEM мониторить работоспособность процесса.
Совокупно же эти примеры приводят нас к более глобальной задаче: SOC должен детально понимать инфраструктуру компании, ее уязвимости и процессы в «широком смысле» и принимать решение о том, как наиболее эффективно мониторить данную инфраструктуру и как максимально быстро узнавать о том, что в ней что-то изменилось – то есть в каждый момент времени объективно оценивать фактическую защищенность инфраструктуры от атаки.
Контроль защищенности – задачи и технологии
На наш взгляд, в тематику контроля защищенности попадают следующие задачи:
Для каждой из обозначенных задач есть свой инструментарий:
Мониторинг и контроль защищенности => Мониторинг + контроль защищенности
Одним из важных преимуществ параллельного запуска процессов мониторинга и контроля защищенности в SOC является возможность «переопылять» один процесс информацией из другого, тем самым повышая общую безопасность. Разберем на примере, как это работает.
Мониторинг как инструмент выявления новых хостов и активов
Если в компании не построен процесс инвентаризации активов или ИТ не делится его результатами, появление новой системы с критичным функционалом или критичными данными может пройти мимо информационной безопасности. Но ситуация существенно меняется, когда существует процесс мониторинга.
В 99% случаев вновь появившийся хост в обязательном порядке «проявит» себя:
Пример: события аутентификации в ОС Windows с фильтрами по известным именам хостов. Как правило, в компании есть критерии именования хостов, за которые можно зацепиться.
И, уже владея информацией о том, что появились новые сущности в сети компании, вполне можно разобраться в их задачах, легитимности или учесть их в общей модели угроз.
И наоборот, если невозможно закрыть какую-то процессную или технологическую уязвимость навсегда, в качестве компенсирующей меры можно разработать дополнительные сигнатуры и сценарии, контролирующие эксплуатацию данной уязвимости.
В качестве примера можно привести процесс наладки и обслуживания технологического оборудования на заводе (или, например, ГРЭС – другими словами, практически на любом производстве). Для работы с таким оборудованием, как правило, привлекаются инженеры от производителя, и зачастую это иностранные специалисты, для которых нужно каким-то образом организовать удаленный доступ до площадки. Довольно часто из-за ограничений существующей архитектуры сети и технологических сегментов удаленный доступ открывается напрямую из Интернета (по RDP, SSH) до терминальных серверов, с которых уже осуществляется наладка оборудования посредством специализированного ПО. И по-другому организовать этот доступ просто нет возможности. Да, можно открывать доступ по заявке и в строго определенное технологическое окно, ограничить адреса, с которых будут разрешены подключения к терминальному серверу, но все же остается риск перехвата RDP/SSH сессии, эксплуатации уязвимостей ОС из сети Интернет, проникновения в технологическую сеть через АРМ инженера-наладчика, заражения бэкдором данного терминального сервера и т.п.
Так как «закрыть» данную процессную уязвимость нет возможности, в качестве компенсирующей меры можно предложить усиленный мониторинг данных терминальных серверов и активности на них, а именно:
Контроль защищенности – с чего начать
Мы предлагаем начать подход к задачам контроля защищенности со следующих действий:
SOC for beginners. Задачи SOC: мониторинг
Мы продолжаем рассказывать о буднях Security Operations Center – о реагировании на массовые кибератаки, любопытных кейсах у заказчиков и правилах корреляции событий, позволяющих нам детектировать атаки на заказчиков и пр.
Сегодня мы хотим открыть новый цикл статей, задача которого – продемонстрировать, с какими задачами и трудностями сталкиваются все начинающие (и не очень) SOCостроители, и главное – поделиться нашим опытом по их решению.
В этих статьях мы будем касаться разных вопросов и технического, и методического характера, и максимально отделять коммерческое и маркетинговое позиционирование от реальных задач. В наших планах завершить первый цикл статей как раз к SOC-Форуму, чтобы площадка стала одним из мест для обсуждения данных вопросов.
Начнем с самой популярной задачи, без которого сложно представить SOC, – мониторинга инцидентов.
Security monitoring – реальная задача или новая маркетинговая реальность?
Любой опытный безопасник за свою карьеру пережил немало трендов на новые красивые аббревиатуры. Очередные NG-технологии, искусственные интеллектуальные системы, «золотые» и «серебряные» пули защиты от хакеров и таргетированных атак и т.д. Сейчас одним из таких популярных направлений стал мониторинг инцидентов информационной безопасности. При этом эксперты иногда высказываются, что безопасность не требует мониторинга, а требует только активного блокирования. Однако мы считаем иначе – по двум причинам.
Причина первая: динамика развития компаний
«Мир изменился, я чувствую это в воздухе, я чувствую это в воде».
Галадриэль, CSO Лотлориэна
Существуют два глобальных изменения, которые все агрессивнее входят в жизнь каждой компании, обладающих хоть какой-то ИТ-инфраструктурой:
Причина вторая: интеллектуальность атак и средств защиты
«Погоди, Гретель, вот скоро луна взойдет, и станут видны хлебные крошки».
Гензель, 1 level Security Analyst
Попытка взлома, отбитая или заблокированная средством защиты, сегодня уже не является поводом для успокоения, поскольку инструментарий злоумышленников, а следовательно, и сами атаки, непрерывно эволюционируют.
Приведем два простых примера.
1. В компании используется NGFW. Такие системы могут детектировать не только внешние атаки, но и потенциально вредоносную активность внутри сети (например, активность бота). И вот в один прекрасный день NGFW заблокировал попытку одного из хостов подключиться к центру управления бот-сетями вредоносного семейства / отправки информации на сервера, подконтрольные злоумышленникам.
Можно ли утверждать, что на этом инцидент исчерпан? На первый взгляд, да. Наша защита успешно заблокировала подключение, бот не связался с центром управления, и в итоге вредоносная активность в сети не началась. Но давайте копнем глубже: 90% процентов сотрудников компании уже давно пользуются ноутбуками. И если сотрудник решит поработать из дома или из кафе, бот успешно достучится до центра управления, ведь там, за пределами сети предприятия, нет ни NGFW, ни бдительного безопасника. К чему это приведет? На первом этапе – к компрометации всех данных этого ноутбука. На втором – к обновлению протоколов или адресов центра управления бота, что не позволит NGFW успешно блокировать атаку.
2. Уже достаточно давно антивирусные агенты научились выявлять и блокировать хакерские утилиты, например, печально известный mimikatz. И вот мы настроили соответствующую политику в нашей компании и зафиксировали блокировку. На одном из хостов ИТ-администраторов был запущен и заблокирован mimikatz.
Этот пример аналогичен предыдущему – с одной стороны, компрометации учетных записей не произошло, инцидент исчерпан. Но, даже если оставить в стороне ненормальность самой ситуации и желание в ней разобраться (сам ли ИТ-администратор запускал утилиту и для чего), ничто не помешает злоумышленнику еще раз попытаться получить доступ. Он попытается «прибить» процесс антивируса, использует версию, которая антивирусом не определяется, например, при применении powershell-аналогов. В конце концов, просто найдет хост без антивируса и получит интересующую его информацию там.
В итоге, проигнорировав анализ и разбор заблокированной атаки, мы оставляем действия злоумышленников без контроля. И вместо того, чтобы купировать их попытки захватить нашу инфраструктуру, мы оставляем их с развязанными руками, позволяя придумать новый способ атаки и вернуться к ней с ранее захваченных позиций.
Два этих примера доказывают, что оперативный мониторинг и тщательный анализ событий ИБ может не только помочь в выявлении и разборе инцидентов, но и усложнить жизнь злоумышленников.
Говорим мониторинг – подразумеваем SIEM?
Некоторое время назад между темой SOC и мониторинга ставился знак равенства, а дальше он же возникал между понятиями «мониторинг» и «SIEM». И, хотя вокруг этой темы сломано много копий, хочется вернуться к этому вопросу, чтобы он не смущал нас в дальнейшем.
В мировой практике и даже на территории России известны подходы к решению задач мониторинга и построения SOC вообще без применения SIEM. Один из крупнейших и самых успешных SOC прошлого десятилетия был целиком построен на оперативной регулярной работе сотрудников: на высокорегулярной основе дежурная смена анализировала журналы антивируса, прокси, IPS и других средств защиты – где руками, где базовыми скриптами, где умными отчетами. Этот подход позволял закрывать 80% задач baseline мониторинга (к примерам базовых задач и начального подхода я подойду детальнее в следующем разделе).
Так зачем же на самом деле нужна платформа SIEM/Log Management в плоскости задач мониторинга? Попробуем разобрать на примерах.
Use case 1. Собрать все инциденты «в одну кучу».
На первый взгляд эта задача может показаться бесполезной, но, на самом деле, трудно переоценить потребность заказчиков в ее решении. Особенно когда их цель –не обработка каждого детекта со средства защиты, а поиск определенных закономерностей. Например, выявление повторяющихся событий/инцидентов (когда проблема методически не устранена), фиксация странных активностей с одного хоста/на один хост (первые робкие шаги к модному слову kill chain), анализ частотности срабатываний.
Безусловно, для решения столь утилитарной задачи SIEM, по-честному, не нужен. Вполне приемлемым вариантом здесь может стать service desk с учетом заявок и правильная работа с отчетами из него (анализ закономерностей глазами).
Но, тем не менее, когда компания запускает у себя SIEM, ее, как правило мотивирует именно желание собрать все инциденты в едином окне, поэтому включаем этот use case в наш список.
Use case 2. Склеить однотипные инциденты.
Когда речь идет о развивающейся и длительной активности злоумышленника, при неправильной настройке сценария можно столкнуться с явлением под названием «incident storm». Например:
И в этом потоке событий очень легко пропустить инцидент, отличный от указанных активностей. Поэтому правильный SIEM всегда позволит склеить эти активности по ключевым полям, чтобы разбирать их как один общий инцидент.
Use Case 3. Обогатить расследование информацией из дополнительных систем.
После выявления инцидента аналитику обычно предстоит очень большой объем работы по поиску его причин и последствий. Рассмотрим следующий пример: одним из базовых правил мониторинга и контроля во многих международных стандартах является запрет на использование системных неперсонифированных учетных записей в инфраструктуре. И вот перед нами встала задача контролировать вход под учетной записью root на операционной системе Unix. Нужен ли для решения такой задачи SIEM? Безусловно, нет; любой администратор, владеющий основами написания скриптов, с легкостью создаст двухстрочный скрипт, который позволит выявлять такую активность.
Но теперь давайте посмотрим, что нам, как оператору SOC, нужно дальше сделать с этим событием.
Чем отличаются эти два события? Какое из подключений легитимно, а какое нет? Сейчас у нас есть только ip-адрес, с которого выполнялось подключение. Это, безусловно, не позволяет нам локализовать пользователя. Вот как действовали бы мы:
После этого необходимо оценить воздействие на систему, оказанное после входа под системной записью root. При правильно настроенном аудите нам, в принципе, будет достаточно журналов сервера, но есть одно «но»: сам злоумышленник с этими правами мог с легкостью их модифицировать. Что приводит нас к задаче хранения журналов в независимом источнике (одной из задач, которые часто ставят под SIEM). В итоге, анализ этих журналов позволяет оценить проблему и ее критичность.
Безусловно, большую часть этой работы можно выполнить и без SIEM, но тогда на нее уйдет гораздо больше времени, а аналитик столкнется с серьезными ограничениями. Поэтому хотя SIEM и не строго необходим, при проведении расследований он имеет серьезные преимущества.
Use Case 4. Простая и сложная корреляция.
На эту тему написаны уже сотни статей и презентаций, поэтому надолго останавливаться на данном примере не хочется. Скажу еще раз главное: сегодня, чтобы эффективно выявлять и отражать атаки, нужно уметь выявлять корреляции между событиями ИБ. Будет ли это создание и удаление учетной записи в Active Directory в течение подозрительно короткого интервала или выявление продолжительных vpn-сессий (длиннее 8 часов) на межсетевом экране – не важно. Так или иначе, базовыми скриптами или инструментами самого средства защиты эта задача не решается из-за огромного объема проходящих через него событий безопасности. Для решения таких задач и предназначены платформы SIEM.
Итого: подход к задачам мониторинга на первом этапе не обязательно требует SIEM-платформы, но она существенно упрощает жизнь SOC и его операторов. В долгосрочной перспективе, по мере углубления в задачи по выявлению инцидентов, наличие SIEM перестает быть рекомендацией и становится обязательным условием.
Мониторинг – с чего начать?
Отвечая на вопрос в заглавии этого раздела, большинство заказчиков впадает в одно из двух заблуждений.
Единственной задачей SOC и вообще информационной безопасности является борьба с APT или таргетированными атаками. Наша практика показывает, что до выстраивания базовых процессов мониторинга, наведения порядка в инфраструктуре и «причесывания» процессов реагирования ставить столь амбициозную задачу перед собой не стоит.
О мониторинге можно думать только после того, как вся инфраструктура будет накрыта плотным колпаком из средств защиты и самых современных систем ИБ. По нашим наблюдениям, хороший первый результат по повышению уровня ИБ можно получить, обладая минимальным набором средств защиты. Это подтверждает и статистика, которую мы собираем на регулярной основе: например, в первом полугодии 2017 около 67% событий у заказчиков были зафиксированы при помощи основных сервисов ИТ-инфраструктуры и средств обеспечения базовой безопасности – межсетевых экранов и сетевого оборудования, VPN-шлюзов, контроллеров доменов, почтовых серверов, антивирусов, прокси-серверов и систем обнаружения вторжений.
Итак, процесс мониторинга событий и инцидентов можно начать с достаточно базовых вещей:
Руслан Рахметов, Security Vision
Оглавление
Друзья, в предыдущей статье (https://www.securityvision.ru/blog/informatsionnaya-bezopasnost-chto-eto/) мы обсудили основные понятия информационной безопасности и дали определение некоторым терминам. Разумеется, сфера защиты информации не ограничивается описанными определениями, и по мере появления новых статей мы будем всё больше погружаться в данную область и объяснять специфические термины.
Сейчас же давайте представим, как выглядит практическая работа тех, кто профессионально занимается информационной безопасностью, т.е. специалистов по защите информации. Мы часто слышим, что многие значимые расследования хакерских атак ведутся в Ситуационных центрах информационной безопасности, или Центрах SOC (от англ. Security Operations Center). Что такое SOC? Кто там работает и что делает? Какие обязанности выполняют сотрудники SOC, с какими системами и средствами они работают? Правда ли, что без знаний языков программирования не удастся достичь высот в работе в составе команды SOC-Центра, а навыки администрирования информационных систем нужны специалисту по защите информации как воздух? Поговорим об этом ниже.
Пока же нам следует уяснить, из каких специалистов должен состоять Центр SOC? Какие компетенции важны для успешной и плодотворной работы в Ситуационных центрах информационной безопасности? Для начала мы подробнее расскажем, какие именно задачи решаются в SOC-Центрах, поговорим о классификации SOC и о моделях работы и предоставления сервисных услуг заказчикам Ситуационных центров информационной безопасности.
На практике подключение и использование услуг SOC-Центра выглядит следующим образом:
1. Заказчик услуг SOC-Центра, который видит необходимость в аутсорсинге оперативного реагирования на свои инциденты ИБ, обращается к менеджерам SOC с запросом о подключении к сервисам SOC.
2. Менеджеры Центра SOC согласовывают детали подключения информационных и защитных систем заказчика к инфраструктуре SOC-Центра для того, чтобы оперативно обрабатывать поступающие данные без выезда на площадку Заказчика.
4. На площадке Заказчика информационные системы и имеющиеся средства технической защиты настраиваются на пересылку всей значимой с точки зрения ИБ информации во внешний SOC.
5. Во внешнем SOC-Центре входящие данные непрерывно обрабатываются сотрудниками SOC (дежурной сменой), которая состоит, как правило, из следующих специалистов:
Специалист по настройке правил в системах SIEM, SOAR, IRP получает от Заказчика вводные данные о работе информационных систем и затем составляет правила выявления инцидентов и реагирования на них в используемых в SOC-Центре системах. Это могут быть правила корреляции в системах SIEM, которые отвечают за обработку входящих сообщений от систем безопасности заказчика и за выстраивание этих разнородных событий в логически целостную «историю» для поиска возможной атаки. Также настраиваются правила автоматического реагирования, локализации, восстановления информационных систем при помощи SOAR и IRP решений. В случае, если для защиты Заказчиков используются сигнатурные методы обнаружения угроз, например, антивирусы или системы обнаружения/предотвращения компьютерных вторжений, то данный специалист создает для них сигнатуры, т.е. описывает правила, по которым угроза должна быть обнаружена.
Как сегодня строится центр оперативного управления информационной безопасностью (SOC-центр)
В крупных компаниях есть люди, которые занимаются только тем, что контролируют состояние ИБ и ждут, когда начнутся проблемы. Речь идёт не про охранников перед мониторами, а про выделенных людей (как минимум одного в смене) в отделе информационной безопасности.
Большую часть времени оператор SOC-центра работает с SIEMами. SIEM-системы собирают данные с различных источников по всей сети и совместно с другими решениями сопоставляют события и оценивают угрозу — как индивидуально для каждого пользователя и сервиса, так и в целом для групп пользователей и узлов сети. Как только кто-то начинает себя вести слишком подозрительно, оператору SOC-центра поступает уведомление. Если уровень подозрительности зашкаливает, сначала изолируется подозрительный процесс или рабочее место, а уже потом приходит уведомление. Дальше начинается расследование инцидента.
Очень упрощая, за каждое подозрительное действие пользователь получает штрафные очки. Если действие характерно для него или его коллег — очков мало. Если действие нетипичное — очков много.
Для UBA-систем (User Behaviour Analytics) последовательность действий также имеет значение. По отдельности резкий скачок объёма трафика, подключение к новому IP или копирование данных с файлового сервера случается время от времени. А вот если сначала юзер открыл письмо, потом у него было обращение к только что зарегистрированному домену, а затем он начал шариться по соседним машинам и отправлять странный зашифрованный трафик в Интернет — это уже подозрение в атаке.
Как работают с инфобезопасностью обычно?
Обычно на среднем уровне развития отдела ИБ у типовой компании есть набор систем защиты — файрволы (часто NGFW), потоковые антивирусы, системы защиты от DDoS, DLP-система с агентами на рабочих станциях и так далее. Но всё это редко увязывается в единую информационную сеть, которая сопоставляет события и находит неочевидные корреляции.
«Ещё неопытные» отличаются от «уже опытных» выстроенными процессами работы с постоянно меняющейся инфраструктурой компании. То есть система динамическая, а вся инфраструктура рассматривается как живой организм, растущий и непрерывно развивающийся. Исходя из этой парадигмы и задаются все правила работы, процедуры и регламенты взаимодействия в рамках существующей экосистемы.
Если такого подхода нет, то даже при том, что данные как-то собираются, а инциденты как-то фиксируются, мы часто видим, что ответственные не знают, как реагировать на те или иные ситуации. Знаю, вы сейчас готовы мне не поверить. Но вот недавно был яркий пример. Госкомпания при замене оборудования не успела вовремя накатить правильные конфиги и поймала вирус-шифровальщик. Звонят и спрашивают: «Что делать-то прямо сейчас?» ИТ хочет блокировать полностью, зачистить сегмент сети, переустановив все ОС, ИБ говорит, что там критичные данные и непонятно, до чего дотянулась вирусня, — и не даёт разрешения ничего трогать. Время уходит.
Мы посоветовали изолировать сегмент на межсетевом экране, сделать полный снепшот всех рабочих станций сегмента и передать его нам на форензику. Пока проводится анализ, для зашифрованных станций переустановить ОС с нуля, для остальных — проверить на руткит, запустив антивирус с LiveCD. Затем вернуть станции в сеть, но продолжать пристально мониторить трафик на прокси и NGFW на предмет распространения заразы и провести аудит безопасности для ключевых систем.
В итоге заказчик пересмотрел риски ИБ и переделал всю защиту на нормальную, с централизованным контролем настроек рабочих станций, серверов и сетевого оборудования, централизованной системой контроля запускаемых приложений, контролем целостности ключевых систем и более жёсткими настройками на средствах защиты информации.
Чем построение SOC-центра отличается от внедрения SIEM-системы?
Ну, в первую очередь тем, что SIEM-системы реактивны по своей природе. У них есть ключевое преимущество — они связывают и объединяют кучу систем разных вендоров. То есть не надо менять и переделывать всю инфраструктуру с нуля — берёте свои имеющиеся компоненты защиты и ставите поверх них SIEM-систему. Проблема в том, что SIEM-система начинает работать только тогда, когда злоумышленник уже проник в инфраструктуру. Поэтому для эффективного SOC-центра классические SIEM-системы необходимо дополнять системами класса UBA и данными Threat Intelligence, которые позволяют обнаружить злоумышленника ещё на ранних стадиях атаки, в идеале — на этапе подготовки ко взлому.
Через несколько недель обучения UBA-системы, что есть инцидент, а что — обычная повторяющаяся рутина, остаётся порядка десятка основных тревог в день. Допустим, восемь из них требуют быстрого анализа, но заканчиваются банально — это баги, сбои железа, нетипичная, но разрешённая активность пользователей. Ещё одна — ситуация, когда скрипт-кидди пытается прорваться через защиту. И последняя — реальная утечка данных или целенаправленная атака. Такие случаи требуют более детального расследования, в том числе ретроспективного анализа большого объёма данных на глубину порядка нескольких месяцев. Тут SOC-центрам хорошо помогают системы анализа данных, построенные на базе технологий класса Big Data.
Рисунок 1. Типовой сценарий APT-атаки
SIEM и UBA смотрят, кто и что делал, что изменил и как, чтобы понять, скомпрометирован или нет узел или сотрудник.
Во-вторых, нужны люди, которые занимаются обнаружением и расследованием инцидентов ИБ. Т. е. их задача — не поддержка инфраструктуры, а активное участие в оперативном реагировании на инциденты ИБ. За день на крупную розничную сеть вполне возможна сотня потенциальных инцидентов ИБ. Большая часть — это автоматические атаки на веб-ресурсы или неучтённые взаимодействия с внешними системами, но часть из них вполне реальные внешние APT-атаки и внутренний фрод.
В-третьих, должны быть проработаны регламенты и процедуры взаимодействия различных подразделений в момент атаки, так называемые Play Book, в соответствии с которыми проводится локализация и расследование инцидента ИБ. Во многих ситуациях у SOC-сотрудников должны быть высокие полномочия. Например, они должны иметь право мгновенно приостановить работу продакшена, если идёт массовая утечка данных. В банке рубануть питание в такой ситуации — предел смелости. Но если заранее всё продумать и зафиксировать план действий в регламенте, можно будет выбрать меньшее зло в каждой конкретной ситуации. Всё это делается для того, чтобы как можно раньше обнаружить инцидент и минимизировать потенциальный ущерб.
Практика
У нас реализован свой SOC-центр, к которому мы подключили как свою инфраструктуру, так и ряд наших заказчиков. В его основе — SIEM-система, которую мы дополнили нашей собственной разработкой на основе Big Data с машинным обучением для обнаружения аномалий и APT-атак. На первой линии у нас выделенная группа Helpdesk — «универсальные солдаты», которые и базовый траблшутинг проведут, и простые инциденты смогут закрыть. Вторая линия — это аналитики, специалисты ИБ, которых привлекаем к расследованию сложных инцидентов и глубокой форензике. А ещё есть команда пентестеров, которая время от времени проверяет периметр сети на прочность. Все команды общаются друг с другом через HPSM для удобства и поддержки единой базы знаний.
Одна из важнейших фишек систем поведенческого анализа, которые развёртываются в рамках SOC-центров, — это обучение и калибровка. То есть те самые оценки действий пользователей и узлов по шкале потенциальной опасности, формируемые в реальном времени. Если рабочая станция пользователя скомпрометирована, то его поведение в системе будет довольно сильно отличаться от коллег.
Это важно локализовывать на основе типового поведения. Например, если человек работает сетевиком в крупной компании и запускает кучу странных тулз, SIEM увидит, что рядом у него работает ещё пятеро таких же людей — значит, всё норм. А вот если бухгалтер начнёт делать нечто похожее на выкрутасы инженера — тревога будет сразу.
Рисунок 2. Модели машинного обучения для обнаружения аномальной активности в сети
Ещё пара фишек
Очень хорошая штука — объединение разрозненных инцидентов в единый киллчейн. Есть ряд стадий, через которые проходит хакер в ходе взлома инфраструктуры, начиная от подготовки к сканированию и заканчивая кражей данных и уничтожением логов. Признаки такой активности можно отслеживать в течение месяцев и заносить в «карточку» пользователя, что даёт возможность операторам быстро выявить «нулевого пациента».
Рисунок 4. Пример киллчейна
Эволюция системы защиты
В итоге всё выглядит примерно так:
А это пример набора систем защиты, которые связаны между собой в рамках SOC и обмениваются данными через SIEM:
Кстати, если вы начинающий специалист и давно хотите поработать в сфере информационной безопасности, у нас есть кое-что для вас. Мы ищем младшего менеджера по продвижению решений ИБ. Нужно будет разбираться и в актуальных решениях, и в вендорах и их продуктах. Общаться с заказчиками, составлять коммерческие предложения и так далее. В общем, скучно не будет. За подробностями пишите мне на почту.