SIEM: ответы на часто задаваемые вопросы

Вместо предисловия

Я приветствую всех, кто читает этот пост!
В последнее время мне стали часто задавать вопросы, связанные с SIEM. Окончательно добило общение с товарищем, с которым мы собрались вечером попить пивка и как-то незаметно перешли на тему, связанную с безопасностью. Он сказал, что они собираются внедрять SIEM — потому что «она помогает защитить инфраструктуру». И даже нашли людей, которые им соглашаются сделать это «за недорого и быстро». Вот тут-то я и насторожился… Как выяснилось, они думали, что внедрение 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 система:

1. Анализировать события и создавать алерты при каких-то аномалиях: сетевого трафика, неожиданных действий пользователя, неопознанных устройствах и т.д.
2. Проверить на соответствие стандартам (PCI DSS, COBIT и др). Не без подводных камней, правда.
3. Создать красивый отчет. В том числе настроенный непосредственно для ваших нужд. Например, ежедневный отчет об инцидентах, еженедельный отчет ТОР-10 нарушителей, отчет по работоспособности устройств и т.д. Отчеты настраиваются гибко, как и их получатели.
4. Мониторить события от устройств/серверов/критически важных систем, создавать соответствующие оповещения для заинтересованных лиц.
5. Собрать доказательную базу по инцидентам.
6. Помогать выбивать средства на системы ИБ из адекватных руководителей.
7. При наличии сканера уязвимостей, SIEM частично избавит вас от головной боли в плане рисков.

Кто основной потребитель SIEM?

На данный момент — банковская сфера. Потому что
а) Им нужно регулярно проводить аудиты соответствия.
б) Банки работают с чувствительной информацией, поэтому в случае возникновения инцидентов важно знать, кто-когда-откуда допустил утечку, было это злонамеренное действие или случайное и какие были сопутствующие факторы.
в) Внешними аудитороми наличие SIEM иногда ставится в +

Вторая категория потребителей — крупные предприятия (или географически распределенные предприятия), которые ежедневно генерируют тонну событий различного свойства и отследить которые просто физически невозможно, и руководители хотят «держать руку на пульсе», чтобы оперативно отреагировать на возможные инциденты.

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

Соответственно, можно примерно очертить круг тех, кому, возможно, внедрение SIEM актуально:

• Должна быть большая/географически разветвленная инфраструктура. Насколько большая? Ну, наверное, это не 100 машин :) Как минимум, 1000-1300.
• Должны быть системы ИБ — начиная от антивирусов и кончая DLP, IDS, IDM и т.д. Чем больше таких систем — тем лучше. На мой взгляд, в организации, которая собирается внедрять SIEM, DLP должна уже быть.
• Наличие устройств, которые требуют мониторинга. Многие SIEM системы «из коробки» поддерживают достаточно большое количество вендоров, в т.ч. какие-то специфические сообщения, и поэтому способны заблаговременно спрогнозировать какие-то критические ситуации. Скажем, контроллер беспроводной сети генерирует сообщение о том, что кол-во пользователей близко к критическому — на основе этого SIEM способна сгенерировать алерт, оповещение о котором будет направлено заинтересованному лицу.
• Должны быть деньги!!! И понимание того, что SIEM не окупится за полгода.

Сколько времени займет внедрение? Какие работы надо закладывать?

Приведу примерный список работ:

• Обследование инфраструктуры и принятие решения о способе внедрения. Т.е. — будем ли все события обрабатывать в одном месте или нужно распараллеливание.
• Формирование и утверждение ТЗ.
• Разработка руководства администратора и руководства пользователя.
• Установка и базовая настройка SIEM. Это означает настройку собственно сервера SIEM / интеграции железки, прописывание ее в сети, выполнение каких-то специфических настроек.
• Настройка источников событий. Настройка собственно DLP, серверов и АРМ (возможно, с установкой агентов), железок в сети на отправку событий на сборщик SIEM.
• Написание дополнительных правил реагирования. Из коробки ничего работать должным образом не будет, требуется дописывать правила для конкретной организации. Также на этом этапе вылезают первые косяки в плане криво настроенных источников / базовой настройки компонентов SIEM.
• Тестовая эксплуатация и накопление статистики. Важный этап. Кладите от месяца до четырех, в зависимости от размера организации. Приготовьтесь к тому, что на вас обрушится шквал инцидентов, 95% которых — т.н. False-Positive, т.е. ложных.
• Корректировка и дополнение правил корреляции. Выполняется параллельно с предыдущим этапом, фактически это обучение SIEM, тонкая донастройка под конкретные нужды.
• Завершение тестовой эксплуатации. Тут лучше поставить несколько дней на финальную шлифовку системы. Какие-то крупные изменения проводить тут уже нецелесообразно, иначе goto на п.5 или п.6
• Проведение приемо-сдаточных испытаний. Написание кейсов и прогонка их. Думаю, тут все понятно.

В среднем, если делать все «по уму», то минимальный срок, на который надо рассчитывать, — от полугода. Какие-то плюсы от внедрения SIEM вы почувствуете через 5-6 месяцев после работы системы в «боевом» режиме. Цена на работы будет соответствующей, к ней припишите еще стоимость лицензий, и, возможно, обучения администраторов безопасности работе с SIEM.

Что так много работ? Что так дорого? Вот XXX обещал все сделать за неделю за сто тыщ рублей!

Есть замечательная картинка, дающая ответ на такой вопрос:

SIEM относится к системам, которые не обеспечивают весь заявленный функционал «из коробки» и без предварительно сделанного тщательного обследования и дальнейшей тщательной настройки под конкретного заказчика превращаются в мусор, головную боль ИТ-отдела и ответственных за безопасность.

Останутся ли False-positive события после начала эксплуатации?

Останутся. Если вам говорят, что их не будет — плюньте в лицо тому менеджеру, что уверяет вас в этом. В этом случае либо у вас будут пропуски действительно требующих внимания инцидентов (кривая настройка), либо вам предлагают не SIEM. На итоговое количество ложно-позитивных событий повлияет количество источников, с которых SIEM гребет данные и тщательность написания правил корреляции, а также размер накопленной статистики в базе. И все равно, при подключении нового компьютера или неожиданном (но согласованном) «выверте» пользователя инцидент создастся. Тут работает принцип «лучше перебдеть, чем недобдеть». И все равно, число таких ложных событий будет мало, а точность определения инцидентов — выше, чем если бы вы анализировали вручную.
Следует также понимать, что SIEM — это часть технических мер по обеспечению ИБ организации. И она не спасет от того, что сотрудник спьяну что-то где-то разболтает в баре, или забудет в том же баре прототип вашей разработки.

SIEM способна предотвратить инциденты...

НЕТ! SIEM сама по себе не способна ничего предотвращать. Если инцидент в ней зарегистрирован, то он уже произошел. Другой разговор — что могло не быть продолжения инцидента, т.к. DLP заблокировало передачу, антивирус убил трояна, пользователь передумал сливать информацию после предупреждения и т.д.
Зато 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 это сопособны выполнять самостоятельно) и кончая тем, что крупные организации имеют свойство разрастаться, продукты ИБ обновляться и добавляться — и тогда потребуется корректировка правил.

Резюмируем

Здесь я постарался осветить общие вопросы, которые возникают у людей; к сожалению, специфика SIEM такова, что конкретные цифры для абстрактной организации привести сложно — надо знать конкретную специфику. Для предварительного уяснения ситуации можно использовать примерно такой список вопросов, на которые желательно ответить перед тем, как принимать решение о поиске интегратора, который вам все сделает (тем более, что он у вас примерно тоже спросит):

1. Что я в ожидаю в конечном итоге от внедрения SIEM? (можно перефразировать как: какие повседневные задачи планируется выполнять с помощью SIEM?)
2. Общее число пользователей?
3. Есть ли какие-то филиалы, географически удаленные, события с которых тоже надо учитывать?
4. Какие системы ИБ у нас уже есть?
5. Планируется ли анализ сетевых потоков (sFlow, netFlow...)?
6. Планируется ли снимать события с серверов, АРМ пользователей?
7. Есть ли в инфраструктуре какие-то специфические устройства, события с которых тоже нужно учитывать?
8. Как часто происходят инциденты, требующие вмешательства/расследования? (<10 инцидентов/день, 10...50 инцидентов/день, 50...100 инцидентов/день, >100 инцидентов/день)
9. Необходимость проверки на соответствие каким-либо стандартам есть? Если да, то каким?
10. Кто будет ответственным за обработку инцидентов?
11. Через какое время я ожидаю получение какого-то ощутимого результата?
12. Сколько мы готовы потратить на внедрение и закупку SIEM?
13. Кто будет поддерживать SIEM и сколько мы готовы платить за поддержку?

Пара комментариев… Если вы не можете ответить на 1й вопрос — то советую почитать литературу и погуглить — не стоит надеяться на то, что в интеграторе вам все сразу расскажут. Потому что по телефону вам расскажут маркетинговый материал. При первой встрече вы узнаете, что у интегратора, естественно, есть опыт работы в этой области. Но! Зачем вам понадобилась SIEM — инженеры будут понимать именно с ваших слов, потому что нужды конкретной организации и особенности ее функционирования вы должны знать лучше них. Поэтому, при отсутствии завершенного образа — что вы хотите получить в конечном итоге — вы получите то, что, как подумал интегратор, вам подойдет лучше всего. При наличии образа — что вы хотите увидеть в конечном итоге — неизбежно скорректируются какие-то частности, но конечный результат, как правило, вас удовлетворит. Если у вас при ответе на 2-й вопрос — число пользователей — меньше 1000, то, скорее всего, SIEM вам не нужна. Если у вас из средств ИБ стоит только антивирус и фаервол — то тем более. SIEM достаточно специфичный продукт, который нужен, на самом деле, далеко не всем.

На этом, пожалуй, закончу; если вы считаете, что какие-то общие вопросы не осветил — напишите, пожалуйста, в каментах.

Всем спасибо за внимание!