17 Июня, 2014

Что мне не хватает в SIEM системе

Tns
В первую очередь хочется сказать об отсутствии рабочего механизма интеграции SiEM системы с промышленными IDS. Да, современные IDS/IPS прекрасно отлавливают и прекрасно предотвращают вторжение в сегмент ДМЗ или сегмент ЛВС. Но все ли они покажут успешно проведенную атаку или проникновение ? Большинство из них даже не заметит этого инцидента и не отобразит на консоли администратора безопасности цепочку событий. То что я видел на данный момент - это механизм работающий в Arcsight или Tenable на основе правил обработки событий сравнивающих известные атаки и модель поведения нарушителя в tcp/ip пространстве :-) И сравнение ведется на основе данных в базу SiEM системы но никак не на основе поступающих данных с сенсоров. Я имею в виду что должен работать механизм теггирования трафика, когда система предотвращения вторжений или межсетевой экран теггирует трафик (ставит метку) по потенциально опасному трафику и сравнивает этот кусочек трафика с тем что появляется из сегмента dmz в wan сегменте напоимер. То есть по данной метке можно отследить реально проведенную атаку до хоста пользователя. Хорошим началом в этом процессе развития IDS систем является РуБикон базирующаяся на AstraLinux с мандатной системой доступа. Моя мысль как раз заключается в том чтобы SiEM система могла понимать трафик адресованных хосту в локальной сети а всем протяжении маршрута пакетов - то есть придется использовать и сессионный уровень и уровень повыше :-) вот тогда и появится реальное количество атак отодраженных на консоли которые могут быть направленны на хост пользователя. На эту идею натолкнула старая добрая система обнаружения вторжений 1999 года под названием Shadow - уже тогда наши коллеги американцы пришли к идее теггирования трафика понятного для система сбора и обработки событий ИБ.

Второй момент который мне хотелось бы выделить - возможность работать с базой в самой SiEm системе. Что в Arcsight что в tenable SC отсуствует возможность сделать отчет по собственным выборкам в полям из СУБД. Сегодняшний уровень технической грамотности наших экспертов по ИБ настолько высок что им можно доверить формирование любых отчетов не на основе шаблонов а путем конструктора отчетов путем использования прямой выборке из базы. В обоих системах есть возможность использовать правила корреляции и создавать собственнные правила, ну так что мешает дать пользователи право создавать свои запросы и свои форсы таблиц вплоть до использования перекрестных индексов или хитроумных запросов. Конечно этот мехнизм формирования низкоуровневых запросов должен быть только в режиме select и query :-)

Третий момет - почему бы не сделать в siem системе собственную подсистему заявок и контроля выполнения заявок. Все что я видел на данный момент это система создания задания и контроля его выполнения. Но нужно расширить эту систему до возможности указания типов инфидентов самостоятельно - ведь в каждой организации своя категория рисков и модель угроз.

Четвертый момент -в Тинейбле есть система оценки рисков ИБ. Но данная система привязана к экспертной оценке рисков и полагается на мнение институтов безопасности. Нечто подобное есть и в Арксайте но опять таки там тоже все разбито по модулям - если брать скооринг то это обработка экономической составляющей а по инцидентам ИБ нет никакой оценки и математики по действующим инцидентам. То есть почему б не сделать модуль который в SiEm системе мог бы содержать в себе активы организации и напротив каждого активы можно было бы выставлять его вес в денежном эквиваленте. Далее по количеству инцидентов собранных по каждому активу подсчитывается не только вероятность реализации угроз и прочие показатели по методике но и сразу подсчитывают убытки возможные и убытки которые наступили уже при реализации угрозы. Это было бы удобно всем, в первую очередь участникам Банковской системы.

Пятый момент который хотелось бы видеть в SIEM системе - правильность архитектуры и обязательно хорошая производительность. Дело в том что любая база данных которая накапливает события становится неповоротливой. Если это SQl база данных то 5 терабайт данных для неё уже нагрузка неплохая. У меня была возможность сравнить и SQL и реляционную СУБД которая используется в том же Tenable. При одинаково объеме модуль в LCE Tenable делал выборку быстррее а все потому что там есть разделение нескольких баз по их типу: то есть база инцидентов это одна "плоская" баз, база по уязвимостям это другая база а база событий и журналирования это третья база. Причем структура построена так что в случае разрастания базы журналирования появляются новые файлы по группам событий и тем самым нет одной огромной базы выборка в которой осуществляется долго. Нет необходимости вручную архивировать СУБД пои наступлении предела размера разрешенного по лицензии - автоматом создается еще одна архивная СУБД. На вопрос а почему не используется SQL в чистом виде был давно дан ответ - по причине низкой производительности.

И шестой момент в тему масштабирования хотелось бы чтобы несколько организаций, купившие SIeM систему могли бы в расках одного холдинга иметь ролевую модель доступа ко всем объектам находящимся в нескольких SIEm системах. То есть подразделение ИБ которое обслуживает одну холдинговую компанию могло бы иметь единую консоль по всем организациям входящим в эту структуру и видеть состояния ИБ в целом. На данный момент Tenable SC позволяет это сделать но частично ограничен лицензионными лимитами на ту или иную организацию, а тот же Арксайт или Qradar предполагает закупку единой лицензии на весь холдинг. Это не совсем удобно когда каждая организация имеет свой бюджет а контроль состояния информационной безопасности осуществляется из головной организации.

Седьмой момент - трафик и производительность. На данный момент у четырех SIEm продуктов есть решения в виде сканера трафика но они не совсем производительные - поставить их на 10Gb интерфейс и зазеркалить трафик на эти сенсоры можно, как и произодить обработку 12000 плагинов имеющихся в тот же Tenable PVS. Но вопрос в тлм как связать уязвимости в трафике с уязвимостями на хостах и показать события атак в виде цепочки. Пока то что я видел - это ложные срабатывания не привязанные к событиям в трафике. Я не говорю про ids чтобы вы понимали, есть необходимость иметь сканер трафика на 10gb например, которые может работать на уровне нитей процессов а не на уровне SMP обработки и нет пока SiEm системы которая связывала бы события в локальной сети с жерналами от станций или серверов :-) как только появится рабочий сканер трафика то появится и возможность создания правил обработки трафика не на основе сигнатур а на основе поведенческой модели нарушителя. На мою просьбу например открыть возможность обработки трафика в Tenable PVS разработчики пока не дали положительного ответа. А ведь всем нам нужен рабочий инструмент анализа трафика на выскоскоростных портах и с собственным конструктором правил. Все что пока есть обработка правил на основе сигнатур или схемы инкапсуляций или коннектов :-)
или введите имя

CAPTCHA