Многие крупные компании, да и те, что поменьше, уже долгое время используют SIEM-системы в качестве одного из наиболее распространенных инструментов обеспечения информационной безопасности. Однако, часто можно слышать от людей, в том числе офицеров безопасности, что SIEM-система работает в режиме 24\7 и таким образом защищает их периметр! Это режет слух, ведь SIEM даже исходя из названия это прежде всего управление событиями ИБ, а потом все остальное. Для внесения ясности в данный вопрос возникла идея написать статью. В добавок читая не неделе Хабр я наткнулся на интересную публикацию по схожей тематике. Результаты этих трудов предстаем вам в сегодняшней публикации.
Введение в теорию
Вкратце, что такое SIEM? SIEM — это Security Information and Event Management т.е. в переводе на русский система управления событиями ИБ. Как видно из названия — она «сама по себе» не способна что-то предотвращать или защищать. Она скорее предназначена для анализа информации, поступающей от различных других систем, таких как DLP, IDS, антивирусов, различных железок (Fortinet, маршрутизаторы и т.д.) и дальнейшего выявления отклонения от норм по каким-то критериям (правилам). Как только мы выявили отклонение — генерируем инцидент. В основе работы SIEM лежит, как ни странно, почти голая математика и статистика. Каких-либо защитных функций «голая» SIEM в себе не несет.
Как работает SIEM-система
А что сейчас может считаться «современным» SIEM-продуктом? Давайте посмотрим, какие вообще бывают SIEM-системы. На данный момент существуют системы 2-х поколений. 2-е поколение в большинстве случаев называется «Next-Generation SIEM».
Давайте посмотрим, из чего состоит SIEM первого поколения:
А вот что считают Next-Generation SIEM:
Как видно, для SIEM второго поколения характерно большее число источников и они получили возможность реагировать на «нештатные» ситуации: например, если у пользователя внезапно поменялась активность (раньше просто просматривал страницы, используя HTTP, а сейчас начинает активно гонять трафик «наружу» через другие протоколы, например) — то это повод сгенерировать «событие». Помимо этого, Next-Generation SIEM способны анализировать проходящий в сети трафик без использования дополнительного «железа» или ПО (путем перевода свободной сетевой карты сервера SIEM в «неразборчивый» режим работы), отслеживать активность приложений — и это помимо оставшейся основной функции «сбор логов с источников» и «анализ событий». Также Next-Generation SIEM могут отслеживать и виртуальные инфраструктуры, что не всегда хорошо делают SIEM первого поколения.
Спорные вопросы
1. Вы говорите — SIEM сама по себе не защищает. Зачем она тогда?
SIEM нужна именно для сбора и анализа информации. Информация поступает с различных источников — таких, как DLP-системы, IDS, маршрутизаторы, межсетевые экраны, АРМ пользователей, серверов…
Согласитесь — достаточно муторно вручную просматривать логи с большого количества источников. К тому же, бывают ситуации, когда внешне безобидные события, полученные с различных источников, в совокупности несут в себе угрозу. Предположим, когда происходит отправка письма с чувствительными для компании данными человеком, имеющим на это право, но на адрес, находящийся вне его обычного круга адресов, на которые он отправляет. DLP-система этого может не отловить, но SIEM, используя накопленную статистику, на основании этого уже сгенерирует инцидент.
ОК, инцидент произошел — но сотрудник, допустивший утечку, всячески открещивается. Как доказать? SIEM способна предоставить всю необходимую доказательную базу, пригодную как для внутренних расследований, так и для суда. Собственно говоря, это одно из ее главных предназначений. В момент создания инцидента также будут оповещены все заинтересованные лица.
Дополнительный штрих — периодически вам надо проводить аудиты на соответствие каким-либо стандартам. Это SIEM тоже умеет.
Из дополнительных особенностей — SIEM после внедрения может косвенно вам помочь выбить деньги на дозакупку какого-то еще средства ИБ: например, вы в качестве обоснования прикладываете отчет, из которого видно, что большая часть полученных инцидентов закрывается запрашиваемым вами средством.
Ниже иллюстрации, в каких случаях SIEM может быть полезна.
Предположим, у вас нет SIEM. Тогда вы имеете:
А вот теперь мы поставили SIEM:
Картинки, конечно же, не претендуют на истину в последней инстанции, а просто дают примерно представление, зачем вам вообще может потребоваться SIEM.
Давайте подытожим, что может делать SIEM система:
- Анализировать события и создавать алерты при каких-то аномалиях: сетевого трафика, неожиданных действий пользователя, неопознанных устройствах и т.д.
- Проверить на соответствие стандартам (PCI DSS, COBIT и др). Не без подводных камней, правда.
- Создать красивый отчет. В том числе настроенный непосредственно для ваших нужд. Например, ежедневный отчет об инцидентах, еженедельный отчет ТОР-10 нарушителей, отчет по работоспособности устройств и т.д. Отчеты настраиваются гибко, как и их получатели.
- Мониторить события от устройств/серверов/критически важных систем, создавать соответствующие оповещения для заинтересованных лиц.
- Собрать доказательную базу по инцидентам.
- Помогать выбивать средства на системы ИБ из адекватных руководителей.
- При наличии сканера уязвимостей, SIEM частично избавит вас от головной боли в плане рисков.
2. Кто основной потребитель SIEM?
На данный момент наиболее частный заказчик это банковская сфера. Потому что
а) Им нужно регулярно проводить аудиты соответствия.
б) Банки работают с чувствительной информацией, поэтому в случае возникновения инцидентов важно знать, кто-когда-откуда допустил утечку, было это злонамеренное действие или случайное и какие были сопутствующие факторы.
в) Внешними аудитороми наличие SIEM иногда ставится в +
Вторая категория потребителей это крупные предприятия (или географически распределенные предприятия), которые ежедневно генерируют тонну событий различного свойства и отследить которые просто физически невозможно, и руководители хотят «держать руку на пульсе», чтобы оперативно отреагировать на возможные инциденты.
Третья категория так же крупные предприятия, кто уже познал всю прелесть неожиданно обнаруженного инцидента ИБ.
Соответственно, можно примерно очертить круг тех, кому, возможно, внедрение SIEM актуально:
- Должна быть большая/географически разветвленная инфраструктура. Насколько большая? Ну, наверное, это не 100 машин :) Как минимум, 1000-1300.
- Должны быть системы ИБ — начиная от антивирусов и кончая DLP, IDS, IDM и т.д. Чем больше таких систем — тем лучше. На мой взгляд, в организации, которая собирается внедрять SIEM, DLP должна уже быть.
- Наличие устройств, которые требуют мониторинга. Многие SIEM системы «из коробки» поддерживают достаточно большое количество вендоров, в т.ч. какие-то специфические сообщения, и поэтому способны заблаговременно спрогнозировать какие-то критические ситуации. Скажем, контроллер беспроводной сети генерирует сообщение о том, что кол-во пользователей близко к критическому — на основе этого SIEM способна сгенерировать алерт, оповещение о котором будет направлено заинтересованному лицу.
- Должны быть деньги!!! И понимание того, что SIEM не окупится за полгода.
3. Сколько времени займет внедрение? Какие работы надо закладывать?
Приведу примерный список работ:
- Обследование инфраструктуры и принятие решения о способе внедрения. Т.е. — будем ли все события обрабатывать в одном месте или нужно распараллеливание.
- Формирование и утверждение ТЗ.
- Разработка руководства администратора и руководства пользователя.
- Установка и базовая настройка SIEM. Это означает настройку собственно сервера SIEM / интеграции железки, прописывание ее в сети, выполнение каких-то специфических настроек.
- Настройка источников событий. Настройка собственно DLP, серверов и АРМ (возможно, с установкой агентов), железок в сети на отправку событий на сборщик SIEM.
- Написание дополнительных правил реагирования. Из коробки ничего работать должным образом не будет, требуется дописывать правила для конкретной организации. Также на этом этапе вылезают первые косяки в плане криво настроенных источников / базовой настройки компонентов SIEM.
- Тестовая эксплуатация и накопление статистики. Важный этап. Кладите от месяца до четырех, в зависимости от размера организации. Приготовьтесь к тому, что на вас обрушится шквал инцидентов, 95% которых — т.н. False-Positive, т.е. ложных.
- Корректировка и дополнение правил корреляции. Выполняется параллельно с предыдущим этапом, фактически это обучение SIEM, тонкая донастройка под конкретные нужды.
- Завершение тестовой эксплуатации. Тут лучше поставить несколько дней на финальную шлифовку системы. Какие-то крупные изменения проводить тут уже нецелесообразно, иначе goto на п.5 или п.6
- Проведение приемо-сдаточных испытаний. Написание кейсов и прогонка их. Думаю, тут все понятно.
В среднем, если делать все «по уму», то минимальный срок, на который надо рассчитывать, — от полугода. Какие-то плюсы от внедрения SIEM вы почувствуете через 5-6 месяцев после работы системы в «боевом» режиме. Цена на работы будет соответствующей, к ней припишите еще стоимость лицензий, и, возможно, обучения администраторов безопасности работе с SIEM.
4. Что так много работ? Что так дорого? Вот XXX обещал все сделать за неделю за сто тыщ рублей!
Есть замечательная картинка, дающая ответ на такой вопрос:
SIEM относится к системам, которые не обеспечивают весь заявленный функционал «из коробки» и без предварительно сделанного тщательного обследования и дальнейшей тщательной настройки под конкретного заказчика превращаются в мусор, головную боль ИТ-отдела и ответственных за безопасность.
5. Останутся ли False-positive события после начала эксплуатации?
Останутся. Если вам говорят, что их не будет — плюньте в лицо тому менеджеру, что уверяет вас в этом. В этом случае либо у вас будут пропуски действительно требующих внимания инцидентов (кривая настройка), либо вам предлагают не SIEM. На итоговое количество ложно-позитивных событий повлияет количество источников, с которых SIEM гребет данные и тщательность написания правил корреляции, а также размер накопленной статистики в базе. И все равно, при подключении нового компьютера или неожиданном (но согласованном) «выверте» пользователя инцидент создастся. Тут работает принцип «лучше перебдеть, чем недобдеть». И все равно, число таких ложных событий будет мало, а точность определения инцидентов — выше, чем если бы вы анализировали вручную.
Следует также понимать, что SIEM — это часть технических мер по обеспечению ИБ организации. И она не спасет от того, что сотрудник спьяну что-то где-то разболтает в баре, или забудет в том же баре прототип вашей разработки.
6. SIEM способна предотвратить инциденты?
НЕТ! SIEM сама по себе не способна ничего предотвращать. Если инцидент в ней зарегистрирован, то он уже произошел. Другой разговор — что могло не быть продолжения инцидента, т.к. DLP заблокировало передачу, антивирус убил трояна, пользователь передумал сливать информацию после предупреждения и т.д.
Зато SIEM обеспечит вас доказательствами, которые можно будет использовать при внутренних разборках, в суде или продемонстрировать нарушителю и сказать «Вася! не делай так! Большой брат все видит».
7. Какого вендора выбрать?
Заранее не ответишь, нормальный интегратор обычно изучает инфраструктуру клиента, его потребности, выясняет, с какой суммой денег он готов расстаться. После чего предлагает вендора, т.к. они с одной стороны и похожи, а с другой — McAfee, например, хуже масштабируется, чем IBM QRadar, и они оба могут не поддерживать какую-то специфическую программу, под которую уже есть готовый коннектор для ArcSight.
Более подробно изучить рынок SIEM помогут магические квадраты Garther
8. Какой объем жестких дисков требуется для хранения данных?
Тоже неоднозначный вопрос. Это рассчитывается в зависимости от количества источников, интенсивности генерации событий (которая завязано на количество пользователей) и прожорливости конкретного вендора. Естественно, «чем больше, тем лучше». Обычно у каждого вендора есть «железячные» варианты, и «виртуальные», железячные варианты, как правило, в плане напичканной техники ничего из себя интересного не представляют и какими-либо особыми свойствами, кроме дизайна и размеров, не обладают. Зато стоят зачастую неоправданно дорого. Но по размерам установленных в них жестких дисков можно примерно прикинуть, насколько комфортно будет чувствовать себя система на вашей конфигурации. Размеры жесткого диска, как и интенсивность потока событий, на которые рассчитаны сервера, обычно указываются в даташите.
Имейте ввиду, что решающее значение имеет скорость и надежность дисковой подсистемы, поэтому RAID тут жизненно необходим, также надо обращать внимание на производительность каждого ЖД, входящего в состав массива. SSD, хотя и быстры, на данный момент ввиду высокой стоимости хранения информации и меньшего ресурса, по сравнению с обычными HDD, наверное, использовать нежелательно.
9. Могу ли я сам написать правило корреляции?
Да, это возможно, сложностей никаких нет — создание правил в большинстве SIEM максимально визуализировано, единственно где могут быть затруднения — правила могут использовать регулярные выражения «в чистом виде». Синтаксис регулярных выражений в большинстве случаев стандартный — если человек знаком с perl, скажем, то сможет написать синтаксически грамотное регулярное выражение. Основная сложность здесь — нужно представлять логику работы в целом, т.к. добавление правил может повлечь за собой изменение в логике работы других правил по формированию инцидента.
10. А можно ли сделать поддержку для источника событий YYY?
Для начала, надо посмотреть, может ли источник (программа или железка) отправлять события как SYSLOG. Если да, то проблема решена — все SIEM ведущих вендоров с сислогом работают.
Если программа какая-то специфическая, то в большинстве случаев можно написать обработчик событий или коннектор, но это означает дополнительные трудо- и денежные затраты.
В тоже время современные SIEM «из коробки» поддерживают значительное число источников + производители их добавляют в своих обновлениях.
11. Нужна ли какая-то поддержка SIEM?
Да, нужна. Начиная от собственно обслуживания сервера (оптимизации БД и проч. служебных задач — большинство SIEM это сопособны выполнять самостоятельно) и кончая тем, что крупные организации имеют свойство разрастаться, продукты ИБ обновляться и добавляться — и тогда потребуется корректировка правил.
Резюмируем
Здесь я постарался осветить общие вопросы, которые возникают у людей; к сожалению, специфика SIEM такова, что конкретные цифры для абстрактной организации привести сложно — надо знать конкретную специфику. Для предварительного уяснения ситуации можно использовать примерно такой список вопросов, на которые желательно ответить перед тем, как принимать решение о поиске интегратора, который вам все сделает (тем более, что он у вас примерно тоже спросит):
- Что я в ожидаю в конечном итоге от внедрения SIEM? (можно перефразировать как: какие повседневные задачи планируется выполнять с помощью SIEM?)
- Общее число пользователей?
- Есть ли какие-то филиалы, географически удаленные, события с которых тоже надо учитывать?
- Какие системы ИБ у нас уже есть?
- Планируется ли анализ сетевых потоков (sFlow, netFlow...)?
- Планируется ли снимать события с серверов, АРМ пользователей?
- Есть ли в инфраструктуре какие-то специфические устройства, события с которых тоже нужно учитывать?
- Как часто происходят инциденты, требующие вмешательства/расследования? (<10 инцидентов/день, 10...50 инцидентов/день, 50...100 инцидентов/день, >100 инцидентов/день)
- Необходимость проверки на соответствие каким-либо стандартам есть? Если да, то каким?
- Кто будет ответственным за обработку инцидентов?
- Через какое время я ожидаю получение какого-то ощутимого результата?
- Сколько мы готовы потратить на внедрение и закупку SIEM?
- Кто будет поддерживать SIEM и сколько мы готовы платить за поддержку?
За материалы спасибо Дмитрий @Hamakev
P.S. дополнительные материалы по теме:
1.Обзор SIEM-систем на мировом и российском рынке, www.Anti-Malware.ru, 2014г
2. Что такое SIEM, SecurityLab, 2012г
3. Сравнение SIEM-решений для построения SOC, 2015г
4. SIEM-система, краткое описание
Комментариев нет:
Отправить комментарий
Вы можете добавить свой комментарий...
Примечание. Отправлять комментарии могут только участники этого блога.