Siem что это такое
Siem-система – что это такое и зачем нужна?
Впервые термин SIEM в заголовках СМИ появился в 2005 году. Разработчиками технологии «Security information and event management», когда разработчики компании Gartner Марк Николетт и Амрит Вильямс представили новый продукт. Технология SIEM объединяет возможности инструментов SIM и SEM в комплексное решение для кибербезопасности. Разберемся подробнее.
Для чего нужна и как работает SIEM-система?
Все оценки были основаны на проценте атак за 2018 год. Наиболее подготовленные к кибератакам страны были выбраны по показателям Глобального индекса кибербезопасности (GCI). Актуальность законодательства оценивалась на основе существующих законов (и проектов) по 7 категориям: национальная стратегия, вооруженные силы, контент, конфиденциальность, критическая инфраструктура, торговля и преступность. По мере роста организации, обеспечение информационной безопасности требует больших ресурсов и затрат на специфическое оборудование. Киберзащита предприятия состоит из спектра работающих в тандеме приложений, предназначенных для отражения различных типов атак. К ним относится софт для обнаружения вредоносного ПО, система обнаружения сетевых вторжений (NIDS), защита от потери данных и приложения для обеспечения безопасности конечных точек. Каждое из этих приложений целиком подстраивается под свой тип угроз, но ни одно из них не обеспечивает стопроцентное покрытие цифрового щита.
Типичные функции программного инструмента SIEM включают в себя:
Программные инструменты SIEM могут сыграть важную роль в повышении эффективности и своевременности действий по реагированию на инциденты безопасности. При обнаружении нарушения, служба безопасности может использовать программное обеспечение SIEM, чтобы быстро определить, как произошла атака и какие хосты или приложения были затронуты нарушением. Инструменты SIEM могут даже реагировать на эти атаки через автоматизированные механизмы. 
Программные средства SIEM выступают в качестве управляющего и интегрирующего звена, находящегося поверх существующей системной инфраструктуры и программных средств безопасности. Средства SIEM собирают и интегрируют все генерируемые компьютером отчеты, которые регистрируются каждым отдельным приложением, службой или средством безопасности в системе, отображая полученные данные в удобочитаемом формате и облегчая обнаружение угроз. О них подробнее:
Как итог: SIEM нужна именно для сбора и анализа информации. Информация поступает с различных источников — таких, как DLP-системы, IDS, маршрутизаторы, межсетевые экраны, АРМ пользователей, серверов. К тому же, бывают ситуации, когда внешне безобидные события, полученные с различных источников, в совокупности несут в себе угрозу. Предположим, когда происходит отправка письма с чувствительными для компании данными человеком, имеющим на это право, но на адрес, находящийся вне его обычного круга адресов, на которые он отправляет. DLP система этого может не отловить, но SIEM, используя накопленную статистику, на основании этого уже сгенерирует инцидент.
Для чего нужна система SIEM и как её внедрить?
TADетали
Что такое SIEM-системы? Какие задачи решают такие решения? Каковы особенности их внедрения и эксплуатации? В этих вопросах TAdviser разбирался совместно с экспертами компании «АМТ-Груп».
Содержание
Что такое SIEM?
Системы SIEM (Security information and event management) происходят от двух классов продуктов: SIM (Security information management) — управление информационной безопасностью и SEM (Security event management) — управление событиями безопасности. Одно из первых упоминаний о SIEM было в 2005 году от аналитиков Gartner.
На практике данные продукты пересекаются по функциональному назначению, и, порой, при определённых настойках могут в значительной мере выполнять функции друг друга.
Производители SIEM иногда разделяют данный класс продуктов на SIEM первого и второго поколения (это можно рассматривать как маркетинговый приём). Как правило, под вторым поколением специалисты понимают более многофункциональный инструмент с возможностью интеграции со сторонними продуктами (системы управления политиками ИБ, c Threat Intelligence платформами, функции Network Behavioral Analysis и др.).
Использование SIEM второго поколения с функциями Threat Intelligence, в частности, предлагает сервис AMTSOC. Данная интеграция позволяет создавать корреляционные правила с критерием поиска в виде обновляемых в TI баз индикаторов. Это существенно повышает эффективность корреляции, превращая статическую корреляцию в динамическую.
Функциональные задачи SIEM
Сбор данных и нормализация: обеспечивается сбор данных (как событий ИБ, так и системных событий) от разнообразных источников: технические средства информационной безопасности (межсетевые экраны всех типов, системы предотвращения вторжений, антивирусы, системы защиты от спама, системы защиты от утечек данных, системы предварительного выполнения программ, контроля целостности и т. д.), серверы, прикладные системы и т. д.
Корреляция данных: сопоставление и поиск по атрибутам, группирование и индексирование по определенным признакам. По сути корреляция является ключевой функцией SIEM, выдающей на выходе список коррелированных событий;
Оповещение: проверка списка коррелированных событий с целью выявить инциденты ИБ и выполнить оповещение по данным инцидентам. Возможна как индикация на консоли управления SIEM, так и автоматизированное уведомление по сработанным корреляционным правилам.
Панели визуализации (dashboards): графики различных типов и форматов, таблицы, списки и другая визуализация по текущим событиям и инцидентам. Визуализация в значительной мере влияет на общее восприятие продукта и является важным элементом процесса Incident Monitoring/Tracking.
Поиск и анализ: контекстный поиск в рамках расследований инцидентов и экспертиз. Важно отметить, что поиск в сырых и нормализованных событиях может существенно отличаться.
Отчетность: создание настраиваемых отчетов с целью периодического информирования службы ИБ о текущих событиях, инцидентах, трендах. Как правило, отчеты могут выгружаться и использоваться в рамках комплексных отчетов служб ИБ.
Какие компоненты входят в состав SIEM?
Состав и реализация существенно зависят от архитектуры решения, размера внедрения, географического распределения системы, параметров производительности.
Как правило, для реализации всех базовых функций в SIEM должны присутствовать несколько основных компонентов.
Коллекторы: отвечают за сбор сырых событий. Могут поддерживать массу различных протоколов и сервисов: Syslog, Windows Event Forwarding, SDEE, SNMP Trap, клиентов баз данных (MSSQL, Oracle и т. д.) и другие специфичные сервисы от разных производителей.
Сам сбор событий может происходить как в пассивном режиме (например, syslog), так и в режиме «по запросу». Коллектор чаще всего отправляет нормализованные события в коррелятор, а сырые события отправляются в хранилище данных. В различных реализациях от разных производителей схема взаимодействия коллектора с другими компонентами может отличатся.
Хранилище данных: отвечает за хранение сырых событий. Возможны реализации с хранением нормализованных событий.
Коррелятор: обеспечивает функции обработки и корреляции нормализованных событий. Возможна реализация контекстного поиска сырых событий, находящихся в хранилище.
Консоль управления: отвечает за управление, настройку и визуализацию. При этом, в ряде случаев, функция визуализации может выполняться отдельной компонентой.
Упомянутые SIEM второго поколения могут содержать также дополнительные компоненты: сбор Flow и SPAN-трафика, BI-компоненты, TI-модуль, модули защиты от фрода, управления политиками ИБ.
Как было сказано выше, на практике архитектура внедрения определяющим образом влияет на количество компонент и их реализацию. Например, в малых реализациях почти все функции могут быть выполнены на одном аппаратном устройстве, тогда как масштабирование предполагает максимальное разделение.
Каковы основные задачи и возможности современных SIEM-решений?
На сегодняшний день сложно переоценить роль SIEM в мире ИБ. Фактически, это центральный элемент любой SOC-инфраструктуры. Можно сказать точно, что без SIEM невозможно эффективное функционирование ни одной комплексной системы ИБ.
Задача SIEM номер один – регистрация инцидентов в режиме Real-Time.
Задача SIEM номер два – предоставить удобный и функциональный инструмент для ретроспективного анализа инцидентов, расследования инцидентов.
Современный SIEM, по сути, уже должен содержать в себе Big Data технологии, обрабатывающие события ИБ как некий интенсивный поток телеметрии. От SIEM требуется как скорость, так и удобство – потому что это основной инструмент аналитики ИБ, предназначенный для расследования инцидентов, поиска следов таргетированных атак (Threat Hunting).
Тренды развития SIEM идут в сторону добавления функций Machine Learning и поведенческого анализа, что позволяет передать на откуп автоматизации все больше и больше рутинных задач Incident Monitoring, Forensic, Investigation. На практике это позволит обнаруживать не только предопределенные вручную инциденты, но и приблизиться к автоматизации процесса создания правил корреляции, что является ключевой и самой сложной задачей при настройке и поддержке SIEM (особенно на больших внедрениях).
На какие особенности внедрения SIEM нужно обращать внимание прежде всего?
Правильно настроенный и поддерживаемый SIEM – это мозг системы ИБ, но задача обучения этого мозга требует очень хорошего уровня экспертизы специалиста и хорошо поставленных процессов ИБ.
Поэтому вопрос номер один, который нужно задавать при принятии решения об использовании SIEM – насколько квалификация службы ИБ и текущая зрелость процессов ИБ позволят корректно и эффективно использовать этот инструмент. Если очевидно, что нет возможности поддерживать самостоятельно SIEM, и он будет «греть воздух», то тратить большие бюджеты на SIEM – совсем неоптимальный шаг. В этом случае стоит рассмотреть вариант аутсорсинга функции мониторинга и расследования инцидентов – например, посредством подключения услуг коммерческого SOC. Порой за цену техподдержки SIEM можно получить, в рамках коммерческого SOC как сам инструмент, так и экспертизу. При этом SLA может предполагать круглосуточный режим поддержки.
Второй вопрос – задачи масштабирования системы. Крайне важно предусмотреть такую архитектуру, которая будет способна обработать поток событий как в пиковые часы, так и в среднем. При этом необходимо распределить нагрузку на компоненты, при необходимости обеспечив балансировку данной нагрузки и выполнять рутинную обработку как можно ближе к источникам.
Третий вопрос – обеспечение надежности SIEM. Может заключатся как в дублировании компонент для отказоустойчивости, так и в дублировании по регионам для катастрофоусточивости.
Четвертый вопрос – срок хранения событий и их защита для возможности ретроспективного анализа в течение необходимого периода времени и для минимизации риска компрометации/потери данных.
Пятый вопрос – наличие необходимых коллекторов и парсеров «из коробки». Хорошо адаптированный текущий список источников в SIEM позволит в будущем избежать массу рутинных операций и доработок.
Шестой вопрос – соответствие текущим требованиям законодательства, регуляторов, отраслевых и корпоративных стандартов. Например, недавно принятый Федеральный Закон «О безопасности критической информационной инфраструктуры Российской Федерации», а также некоторые требования регулятора, могут предписывать использовать сертифицированный ФСТЭК SIEM.
Ответы на эти вопросы позволят подобрать подходящий вариант использования SIEM. В то же время, решение, сочетающее оптимальные параметры по каждому из указанных вопросов, может предложить сервис AMTSOC. Его услуга базируется на трех компонентах: функциональный SIEM с хорошим уровнем зрелости, глубокая экспертиза команды по данному решению и наличие конкурентоспособной MSSP-модели продаж.
Как выбираются источники данных для SIEM?
В идеальной ситуации чем больше источников событий – тем меньше вероятность пропустить важное событие и не идентифицировать значимый инцидент, получив так называемую ошибку второго рода (False Negative).
Но практика говорит о том, что при очень больших потоках событий возрастает вероятность ошибок первого рода (False Positive) – поскольку обработка бо́льшего количества событий приводит к усложнению задачи написания комплексных корреляционных правил и процесса фильтрации этих самых ошибок. Не говоря уже о том, что обработка дополнительных событий может серьезно увеличить стоимость решения.
Специалисты AMTSOC рекомендуют при выборе списка источников на первых этапах фокусироваться на технических средствах защиты информации, системах аутентификации и авторизации, и ИБ событиях с прикладных систем. И далее, в процессе развития и повышения зрелости службы ИБ и службы SOC, подключать все больше и больше системных событий, в т. ч. для отработки результатов процесса Threat Hunting (например, поиска в событиях прошлого следов третированных атак и создания корреляционных правил для идентификации таких атак в реальном времени).
Иногда лучшие практики рекомендуют «обрезать» объем событий посредством определения важности (severity) и конкретных модулей-источников (facility).
Подобные приёмы также используют и для сохранения производительности SIEM.
Каковы особенности эксплуатации SIEM-решений? Требуется ли поддержка?
Фактически в любой реализации SIEM необходимо тесное взаимодействие с Tier2 и Tier 3 службами техподдержки: вопросы парсинга, вопросы срабатывания корреляционных правил, нюансы визуализации и отчетности, стабильность работы компонент, поддержка кодировок, вопросы сертификации, вопросы миграции и обновлений, восстановлений после сбоев.
В итоге сложно представить эффективную работу SIEM на более-менее развитой ИТ-инфраструктуре без хорошо отлаженного взаимодействия с технической поддержкой производителя.
Например, в сервисной модели AMTSOC задачу взаимодействия с производителем SIEM берет на себя оператор данной экспертной услуги.
В чем преимущества сервисной модели SIEM? Какую ответственность несет поставщик сервиса?
Для начала нужно выделить два элемента сервисной модели:
1. Сервисная модель продажи оператором коммерческого SOC самого SIEM как инструмента: MSSP (Managed Security Service Provider);
2. Экспертиза ИБ, предоставляемая на аутсорсинг сервисными операторами коммерческого SOC.
В итоге сервисная модель как сочетание экспертизы команды коммерческого SOC и OPEX-модели инструмента SIEM имеет следующие преимущества:
Универсальных подходов нет. Практика показывает, что крупные заказчики, обладающие развитой службой ИБ и большими ресурсами, предпочитают локализовывать процессы мониторинга ИБ на своей стороне. В этом случае выбор классической схемы CAPEX является наиболее частым выбором.
Для малого и среднего бизнеса вопрос стоимости решения становится определяющим, кроме того, как говорилось выше, не всегда уровень зрелости служб ИБ позволяет эффективно использовать SIEM как центральный элемент службы ИБ.
Специалисты AMTSOC часто предлагают клиентам наглядные графики со сравнением затрат на OPEX и CAPEX модель при одинаковых параметрах SIEM. Чаще всего OPEX оказывается значительнее выгоднее как по затратам, так и по набору функций – ведь MSSP модель почти всегда предлагает клиенту не просто инструмент, а ещё и набор сервисных процессов мониторинга ИБ:
Приведённый пример не является действительным расчётом, а отображает примерное соотношение CAPEX модели с приобретением SIEM для инфраструктуры уровня малого-среднего и OPEX модели для аналогичной инфраструктуры с приобретением SIEM на баланс сервисного оператора коммерческого SOC. При этом в OPEX входит и предоставление ряда базовых услуг сервиса коммерческого SOC.
В итоге очевидно, что OPEX модель предлагает больше за меньшие деньги. Отказаться от такого подхода можно только в силу внутренних политик, предписывающих сосредоточение всех функций внутри организации или в целом консервативности ИБ. Данная демонстрация показывает причину того, что рынок услуг аутсорсинга ИБ растёт бо́льшими темпами чем рынок ИБ в целом.
SIEM: ответы на часто задаваемые вопросы
Вместо предисловия
Немного теории
Я не хочу подробно расписывать теоретические аспекты работы современных SIEM и их классификацию, т.к. тема хорошо описана. Вкратце, что такое SIEM? SIEM — это Security Information and Event Management. Как видно из названия — она «сама по себе» не способна что-то предотвращать или защищать. Данная система предназначена для анализа информации, поступающей от различных других систем, таких как DLP, IDS, антивирусов, различных железок (Fortinet, маршрутизаторы и т.д.) и дальнейшего выявления отклонения от норм по каким-то критериям. Как только мы выявили отклонение — генерируем инцидент. В основе работы SIEM лежит, как ни странно, почти голая математика и статистика. Каких-либо защитных функций «голая» SIEM в себе не несет.
По техническим аспектам работы систем такого класса рекомендую ознакомиться через статьи на www.securitylab.ru либо на Хабре в блоге Positive Technologies. Также немного информации можно найти в моем посте: habrahabr.ru/post/159929.
Собственно вопросы
Здесь я попробую дать ответы на наиболее часто задаваемые вопросы.
Вы говорите — SIEM сама по себе не защищает. Зачем она тогда?
SIEM нужна именно для сбора и анализа информации. Информация поступает с различных источников — таких, как DLP-системы, IDS, маршрутизаторы, межсетевые экраны, АРМ пользователей, серверов…
Согласитесь — достаточно муторно вручную просматривать логи с большого количества источников. К тому же, бывают ситуации, когда внешне безобидные события, полученные с различных источников, в совокупности несут в себе угрозу. Предположим, когда происходит отправка письма с чувствительными для компании данными человеком, имеющим на это право, но на адрес, находящийся вне его обычного круга адресов, на которые он отправляет. DLP система этого может не отловить, но SIEM, используя накопленную статистику, на основании этого уже сгенерирует инцидент.
ОК, инцидент произошел — но сотрудник, допустивший утечку, всячески открещивается. Как доказать? SIEM способна предоставить всю необходимую доказательную базу, пригодную как для внутренних расследований, так и для суда. Собственно говоря, это одно из ее главных предназначений. В момент создания инцидента также будут оповещены все заинтересованные лица.
И дополним штрих — периодически вам надо проводить аудиты на соответствие каким-либо стандартам. Это SIEM тоже умеет. Из дополнительных особенностей — SIEM после внедрения может косвенно вам помочь выбить деньги на дозакупку какого-то еще средства ИБ: например, вы в качестве обоснования прикладываете отчет, из которого видно, что большая часть полученных инцидентов закрывается запрашиваемым вами средством. Ниже иллюстрации, в каких случаях SIEM может быть полезна.
Предположим, у вас нет SIEM. Тогда вы имеете: 
А вот теперь мы поставили SIEM:
Картинки, конечно же, не претендуют на истину в последней инстанции, а просто дают примерно представление, зачем вам вообще может потребоваться SIEM.
Кто основной потребитель SIEM?
На данный момент — банковская сфера. Потому что
а) Им нужно регулярно проводить аудиты соответствия.
б) Банки работают с чувствительной информацией, поэтому в случае возникновения инцидентов важно знать, кто-когда-откуда допустил утечку, было это злонамеренное действие или случайное и какие были сопутствующие факторы.
в) Внешними аудитороми наличие SIEM иногда ставится в +
Вторая категория потребителей — крупные предприятия (или географически распределенные предприятия), которые ежедневно генерируют тонну событий различного свойства и отследить которые просто физически невозможно, и руководители хотят «держать руку на пульсе», чтобы оперативно отреагировать на возможные инциденты.
Третья категория — крупные предприятия, кто уже познал всю прелесть неожиданно обнаруженного инцидента ИБ.
Сколько времени займет внедрение? Какие работы надо закладывать?
В среднем, если делать все «по уму», то минимальный срок, на который надо рассчитывать, — от полугода. Какие-то плюсы от внедрения SIEM вы почувствуете через 5-6 месяцев после работы системы в «боевом» режиме. Цена на работы будет соответствующей, к ней припишите еще стоимость лицензий, и, возможно, обучения администраторов безопасности работе с SIEM.
Что так много работ? Что так дорого? Вот XXX обещал все сделать за неделю за сто тыщ рублей!
Есть замечательная картинка, дающая ответ на такой вопрос: 
SIEM относится к системам, которые не обеспечивают весь заявленный функционал «из коробки» и без предварительно сделанного тщательного обследования и дальнейшей тщательной настройки под конкретного заказчика превращаются в мусор, головную боль ИТ-отдела и ответственных за безопасность.
Останутся ли False-positive события после начала эксплуатации?
Останутся. Если вам говорят, что их не будет — плюньте в лицо тому менеджеру, что уверяет вас в этом. В этом случае либо у вас будут пропуски действительно требующих внимания инцидентов (кривая настройка), либо вам предлагают не SIEM. На итоговое количество ложно-позитивных событий повлияет количество источников, с которых SIEM гребет данные и тщательность написания правил корреляции, а также размер накопленной статистики в базе. И все равно, при подключении нового компьютера или неожиданном (но согласованном) «выверте» пользователя инцидент создастся. Тут работает принцип «лучше перебдеть, чем недобдеть». И все равно, число таких ложных событий будет мало, а точность определения инцидентов — выше, чем если бы вы анализировали вручную.
Следует также понимать, что SIEM — это часть технических мер по обеспечению ИБ организации. И она не спасет от того, что сотрудник спьяну что-то где-то разболтает в баре, или забудет в том же баре прототип вашей разработки.
SIEM способна предотвратить инциденты.
Какого вендора выбрать?
Заранее не ответишь, нормальный интегратор обычно изучает инфраструктуру клиента, его потребности, выясняет, с какой суммой денег он готов расстаться. После чего предлагает вендора, т.к. они с одной стороны и похожи, а с другой — McAfee, например, хуже масштабируется, чем IBM QRadar, и они оба могут не поддерживать какую-то специфическую программу, под которую уже есть готовый коннектор для ArcSight.
Какой объем жесткого диска требуется для хранения данных?
Тоже неоднозначный вопрос. Это рассчитывается в зависимости от количества источников, интенсивности генерации событий (которая завязано на количество пользователей) и прожорливости конкретного вендора. Естественно, «чем больше, тем лучше». Обычно у каждого вендора есть «железячные» варианты, и «виртуальные», железячные варианты, как правило, в плане напичканной техники ничего из себя интересного не представляют и какими-либо особыми свойствами, кроме дизайна и размеров, не обладают. Зато стоят зачастую неоправданно дорого. Но по размерам установленных в них жестких дисков можно примерно прикинуть, насколько комфортно будет чувствовать себя система на вашей конфигурации. Размеры жесткого диска, как и интенсивность потока событий, на которые рассчитаны сервера, обычно указываются в даташите.
Имейте ввиду, что решающее значение имеет скорость и надежность дисковой подсистемы, поэтому RAID тут жизненно необходим, также надо обращать внимание на производительность каждого ЖД, входящего в состав массива. SSD, хотя и быстры, на данный момент ввиду высокой стоимости хранения информации и меньшего ресурса, по сравнению с обычными HDD, наверное, использовать нежелательно.
UPD из комментариев Подсказали статью по этой теме. Спасибо lless.
А сложно с ней работать?
Нет, не сложно — в современных SIEM весь интерфейс интуитивно понятен, работает в подавляющем большинстве случаев, как WEB-приложение (через браузер). При необходимости можно разграничить разные разделы, к которым будет доступ, по ролям.
Могу ли я сам написать правило корреляции?
Да, это возможно, сложностей никаких нет — создание правил в большинстве SIEM максимально визуализировано, единственно где могут быть затруднения — правила могут использовать регулярные выражения «в чистом виде». Синтаксис регулярных выражений в большинстве случаев стандартный — если человек знаком с perl, скажем, то сможет написать синтаксически грамотное регулярное выражение. Основная сложность здесь — нужно представлять логику работы в целом, т.к. добавление правил может повлечь за собой изменение в логике работы других правил по формированию инцидента.
UPD из комментариев Хотелось бы добавить, что в составе SIEM иногда имеются графические утилиты для тестирования разрабатываемых регулярных выражений. В частности, у ArcSight ESM эта утилита так и называется — regex. Спасибо eafanasov за дополнение.
А можно ли сделать поддержку для источника событий YYY?
Для начала, надо посмотреть, может ли источник (программа или железка) отправлять события как SYSLOG. Если да, то проблема решена — все SIEM ведущих вендоров с сислогом работают.
Если программа какая-то специфическая, то в большинстве случаев можно написать обработчик событий или коннектор, но это означает дополнительные трудо- и денежные затраты.
В тоже время современные SIEM «из коробки» поддерживают значительное число источников + производители их добавляют в своих обновлениях.
UPD из комментариев Как верно подсказали, разные источники могут называть одно и тоже событие по-разному. Например, фаервол одного вендора скажет в логе «deny», другой «discard», третий «drop», а SIEM должна категорировать все эти события в единый формат, например «Firewall/Access/Failure», т.е. может потребоваться дополнительный обработчик. Спасибо bondbig за замечание.
Нужна ли какая-то поддержка SIEM?
Да, нужна. Начиная от собственно обслуживания сервера (оптимизации БД и проч. служебных задач — большинство SIEM это сопособны выполнять самостоятельно) и кончая тем, что крупные организации имеют свойство разрастаться, продукты ИБ обновляться и добавляться — и тогда потребуется корректировка правил.
Резюмируем
На этом, пожалуй, закончу; если вы считаете, что какие-то общие вопросы не осветил — напишите, пожалуйста, в каментах.