Управление логами — фундамент любой SIEM, в котором часто зияют прорехи

Давайте вспомним вот эту иллюстрацию двухнедельной давности:

В ней атомарным элементом считаются логи. Все логи сразу. Многие компании, да и производители SIEM, могут сказать, что уже они то выстроили достаточно зрелый, может быть даже на пятом уровне, процесс управления логами. И в принципе, не сильно задумываясь, мы можем с ними согласиться, так как о том, как работать с логами, как одним из источников информации ИБ, говорят уже много лет и даже десятилетий. Первые хостовые IDS, появившиеся в начале 80-х годов, как раз опирались в своей работе на данные из журналов регистрации. Можно предположить, что уж с логами-то за почти 40 лет у нас научились работать. Но история умеет преподносить сюрпризы. Вот так выглядит слайд из вчерашней презентации Антона Чувакина из Gartner, который рассказывал про технологию пользовательской поведенческой аналитики (UEBA):

Обратите внимания на первый пункт в списке основных проблем при внедрении и использовании UEBA — сбор данных, их доступность и качество. И это спустя 40 лет после появления первых хостовых IDS и 20 лет после появления первых SIEM. А ведь SIEM, которые в принципе должны уметь работать с источниками данных, потом отдают информацию в UEBA, а также иные системы аналитики ИБ.

• Множество источников. Это примерно как с DLP, которые вроде и борются с утечками, но когда начинаешь копать, то оказывается, что 2/3 коммуникационных каналов в вашей компании они вообще не отслеживают.
• Противоречивость данных. Например, в одном источнике у вас указан IP-адрес, но нет, допустим, имени пользователя, а в другом наоборот — имя пользователя есть, а IP-адреса нет. И как связать такие данные между собой? А вот еще простой пример. В одном логе у вас время события записано в формате DD-MMM-YYYY, а в другом — MMDDYYYY. Хорошо, если система управления логами, приводит все к единому формату, а если нет?
• Противоречивость временных меток. Ну тут все понятно и дело даже не в разных часовых поясах, в которых могли происходить события, а в отсутствии системы синхронизации, что может привести, например, к ситуации, когда в SIEM числится, что события А произошло после события Б через 66 секунд, а на самом деле оно произошло до — на 15 секунд.
• Множество разных форматов. XML, JSON, syslog, CSV (с разделениями табуляцией или запятыми), SNMP, REST, базы данных и др.
• Незащищенность логов. Кто мешает злоумышленнику удалить какие-то записи из источника информации или, что еще хуже, подменить их, создавая и поддерживая ложное чувство защищенности? А что с доступностью источников информации?
• Способы доступа к источникам информации. Часто в описании SIEM/LM написано, что они поддерживают потоковые данные из syslog (а Netflow как, кстати?) и удаленный доступ к логам через API и удаленный доступ. А что с агентами? Некоторые данные без агентов не вытащить и не проанализировать.
• Неструктурированные данные. Правда, это не совсем задача SIEM или LM, но без них сегодня сложно проводить серьезную аналитику и принимать решения и поэтому стоит задуматься об этой теме заранее.
• Отсутствие стандартов или отказ от поддержки вендорами уже существующих стандартов. RDEP, CEE, SDEE, IODEF, RID, SecDEF… Их поддерживают средства защиты или системы анализа?

• ЦБИ, которые недавно выпустили свою SIEM Neurodat,
• НТЦ Вулкан, которые активно развивают направление SIEM в своих проектах,
• Infowatch
• Код безопасности
• РТ-Информ
• R-Vision