Хочу продолжить тему выбора средств защиты, начатую в прошлом посте, и поговорить адресно про популярные нынче SIEM-ы. Нужен вам на самом деле SIEM или нет я обсуждать не буду, допустим, вы решили что нужен. Как выбрать ? Как сравнить имеющиеся решения ? Нужна видимо какая-то система критериев.
В этом посте я хочу представить свою прикидку 10 ключевых критериев, на которые стоит обратить внимание при выборе SIEM. Сразу оговорюсь, что конечно это не исчерпывающий список и в рамках подбора решения для вашей организации его необходимо расширить. Выбрать только 10 непросто, есть еще немало других, которые не попали в итоговый список, просто потому что я искусственно ограничил список таким количеством. Я конечно же не претендую на истину в последней инстанции. Хотите как-то изменить мою 10-ку, прошу писать в комментариях.
1. Наличие успешных внедрений (в идеале в вашей отрасли). Думаю тут все очевидно, если продукт не работает / не используется ни у кого из вашей отрасли или может быть даже в целом в стране, то это повод задуматься хотите ли вы быть пионером. Причем в рамках этого критерия стоит проверить не просто наличие логотипа на сайте, а реально пообщаться с соответствующим клиентом. К сожалению приходится сталкиваться с ситуациями когда вендор громко заявляет о наличии его решения у того или иного заказчика, а на поверку оказывается что либо там пилот на очень ограниченной области, либо решение куплено и лежит на полке. Ни тот ни другой вариант за успешное внедрение принять нельзя.
2. Наличие техподдержки / технической документации / обучения на русском языке. Тут вроде тоже все очевидно, продукт сложный, потребует однозначно докрутки, тонкой настройки, а значит нужно сразу смотреть есть ли исчерпывающая документация на решение, какой уровень техподдержки обещает производитель, есть ли учебные курсы для обучения специалистов работе с этой системой. Все это конечно же должно быть на русском языке, к сожалению уровень владения иностранными языками в нашей отрасли по-прежнему не высок.
3. Необходимость установки агентов для сбора данных. Установка дополнительных агентов очень часто становится проблемой, поэтому стоит сразу оценить что умеет собирать система агентами, что без агентов, какие требования у агентов к железу, насколько ваша инфраструктура готова к развертыванию еще одного агентского решения.
4. Наличие готовых коннекторов для используемых у вас программных систем, данные из которых планируется собирать в SIEM. Тут речь идет и о средствах защиты, и о прикладных системах, и об операционных системах. В идеале все уже должно быть, если чего-то нет, то см. п.5. И самое важное это не количество коннекторов в принципе, а какой объем того что есть в вашей инфраструктуре они покрывают. Наличие коннекторов к 500 решений классно выглядит в брошюре, но если при этом в этом списке только 2 из скажем 10 источников, с которых вы хотите брать данные, то это беда.
5. Легкость интеграции / разработки новых коннекторов. Коннекторы однозначно потребуются, не сразу так потом. Поэтому лучше сразу понять уровень сложности этой задачи. Можно ли это сделать самому или обязательно потребуется привлекать вендора / интегратора. Насколько легко и интуитивно это можно сделать или необходимо будет освоить серьезные программерские навыки.
6. Производительность. С одной стороны чем выше возможности системы по объему собираемой информации тем лучше, но тут в первую очередь нужно смотреть на имеющиеся потребности. Зачем платить за высокую мощность и жертвовать (возможно) другими аспектами, если вы, например, хотите мониторить всего лишь 10-ку самых критичных серверов ? Но, с другой стороны, надо понимать, что "аппетит растет во время еды" и нагрузка на систему однозначно будет расти.
7. Удобство / легкость настройки и работы с системой. Субъективный критерий, но легко проверяется на пилоте. Если интерфейс кривой-косой, не интуитивный, непонятный, то работать с системой будет сложно. В этом смысле самый правильный путь это в рамках пилота дать поработать с системой тем, кто в боевом режиме будет с ней работать, и потом попросить их оценить удобство работы с системой по одному или нескольким субъективным критериям: эргономика, понятность, удобство (провести мини-анкетирование или просто коллективное обсуждение).
8. Наличие API для интеграции с другими внешними системами. Данные из SIEM-а с высокой вероятностью могут понадобиться где-то еще. Если у системы нет нормального API, в идеале построенного на REST или подобной архитектуре, то такая интеграция в последствии может стать либо очень финансово затратной, либо попросту невозможной.
9. Гибкость настройки правил корреляции. Одна из ключевых задач SIEM-а это корреляция. Ради этого многие и берут это решение. Но без правил корреляция не работает, а значит эти правила надо будет писать. Готовые правила конечно есть у большинства разработчиков, но они как правило добавлены только для того чтобы можно было показать в качестве демо-примера, в реальной жизни они вам скорее всего не понадобятся, нужно будет писать свои. И вот тут как раз и возникнет вопрос того насколько это все легко и просто, в общем, все очень похоже на п.5.
10. Механизмы уведомления. SIEM это ведь в первую очередь система мониторинга, а значит она должна уметь оперативно оповещать команду реагирования на инциденты. Тут аналогично вопрос не в количестве доступных методов уведомления, а в покрытии тех методов, которые вы используете или хотите использовать при реагировании на инциденты (например, кому-то нужно SMS-оповещение, кому-то - нет), а также возможность гибкой настройки условий использования тех или иных методов уведомления.
Facebook
Комментариев нет:
Отправить комментарий