siem системы что это такое
Что такое SIEM?
Системы защиты постоянно развиваются и адаптируются к новым видам угроз. Количество источников информации, из которых поступают данные по текущему состоянию защищенности, растет с каждым днем.
Системы защиты постоянно развиваются и адаптируются к новым видам угроз. Количество источников информации, из которых поступают данные по текущему состоянию защищенности, растет с каждым днем. Когда инфраструктура слишком сложна, невозможно уследить за общей картиной происходящего в ней. Если своевременно не реагировать на возникающие угрозы и не предотвращать их, толку не будет даже от сотни систем обнаружения вторжений. На помощь приходят системы Security Information and Event Management (SIEM). О них мы сегодня и поговорим.
Перед системой SIEM ставятся следующие задачи.
SIEM способна выявлять:
Система SIEM универсальна за счет своей логики. Но для того чтобы возложенные на нее задачи решались — необходимы полезные источники и правила корреляции. Любое событие (например, если в определенной комнате открылась дверь) может быть подано на вход SIEM и использовано.
Источники выбираются на основании следующих факторов:
Основные источники SIEM
Решение SIEM включает в себя, как правило, несколько компонентов:
Данные о событиях собираются от источников с помощью установленных на них агентов, либо удаленно (при помощи соединения по протоколам NetBIOS, RPC, TFTP, FTP). Во втором случае неизбежно возникает нагрузка на сеть и источник событий, так как часть систем не позволяет передать только те события, которые еще не были переданы, и передает в сторону SIEM весь журнал событий, составляющий зачастую сотни мегабайт. Затирать же журнал событий на источнике при каждом сборе данных — некорректно.
События должны не только собираться в консолидированное хранилище для разбора по факту инцидента, но и обрабатываться. В противном случае вы получите решение, которое полностью не оправдывает затраты. Безусловно, инструментарий SIEM сократит время, необходимое для разбора инцидента. Но задача SIEM — своевременно обнаруживать, предотвращать угрозы и оперативно реагировать на них. Для этого необходимо составлять правила корреляции — с учетом актуальных для компании рисков. Эти правила не перманентны и должны постоянно актуализироваться экспертами. Как и в случае с правилами для систем обнаружения вторжений, если вовремя не прописать правило, позволяющее выявлять типовую угрозу, — она будет, скорее всего, реализована. Преимущества SIEM перед IDS в правилах — возможность указывать общее описание симптомов и использование накопленной статистики baseline для наблюдения за отклонениями от нормального поведения информационных систем и трафика.
Правила отдаленно напоминают правила Snort. В них описываются критерии возникновения угрозы и реакция на них. Простейший типовой пример с login failed я описывала выше. Более сложным примером на практике может быть login failed в определенной информационной системе с уточнением группы пользователя и имени удаленного объекта. В случае с фродом — параметры удаленности двух последних точек использования банковской карты за небольшой интервал времени (к примеру, клиент воспользовался оплатой бензина в Москве, а через 5 минут где то в Австралии пытаются снять 5 000 евро).
Регистрация инцидентов в собственной или внешней системе HelpDesk играет немаловажную роль. Во-первых, это документирование возникающих инцидентов. Если есть зарегистрированный инцидент, то есть и ответственный за его решение, есть сроки. Инцидент не останется неучтенным (как это бывает в случае оповещения по электронной почте). Во-вторых, это статистика по инцидентам, которая позволяет выявлять проблемы (однотипные инциденты, повторяющиеся часто и закрываемые без устранения истинных причин). На основании статистики и расчета основных показателей можно также судить об эффективности работы отдельных сотрудников, подразделения ИБ, средств защиты.
С помощью SIEM можно добиться почти абсолютной автоматизации процесса выявления угроз. При корректном внедрении такой системы подразделение ИБ переходит на абсолютно новый уровень предоставления сервиса. SIEM позволяет акцентировать внимание только на критических и действительно важных угрозах, работать не с событиями, а с инцидентами, своевременно выявлять аномалии и риски, предотвращать финансовые потери.
Важно понимать, что SEIM — это инструмент не только ИБ, но и вообще ИТ. На основе мощных корреляционных механизмов можно эффективно обеспечивать непрерывность работы IТ-сервисов, выявлять сбои в работе информационных и операционных систем, аппаратного обеспечения. Кроме того, SIEM — инструмент автоматизации. Простейший пример, актуальный для большинства компаний: конфликт IP-адресов. За счет простейшего правила RBR можно узнать об инциденте задолго до звонка пользователя. При этом устранение причины требует гораздо меньших затрат, а следовательно, уменьшаются возможные финансовые потери бизнеса.
Если анализировать реальное использование SIEM на практике, то приходится признать, что в большинстве случаев работа таких систем направлена на консолидацию журналов событий от различных источников. Фактически — используется только функционал SIM. Если и есть заданные правила корреляции, они не пополняются.
10 вопросов для осознанного выбора SIEM-системы
Прим.переводчика: в оригинальном документе 2017 года также приводится краткий обзор 24 SIEM решений и смежных технологий. Дополнительно рекомендую отчет Gartner за 2014, 2015 и 2016 года.
Security Information and Event Management является сложным и дорогим решением по сбору, нормализации, анализу и корреляции информации из лог-файлов всех ИТ-систем, однако и результаты ее работы при правильной эксплуатации являются выдающимися. Портал Solutions Review подготовил список из 5 вопросов к себе и 5 вопросов к потенциальному поставщику, собрав ответы на которые, вы сможете более осознанно сделать выбор достойной SIEM системы для внедрения в вашей организации.
5 вопросов к собственной команде перед выбором SIEM
Вопрос №1. Как мы будет осуществлять настройку и использование своей SIEM?
SIEM полноценно работает лишь в руках профессионалов и, будучи установленной в большой организации, может потребовать команду из 8 выделенных сотрудников. Такая сложная система без обслуживающего персонала похожа на необитаемую крепость — с виду неприступная, но не является помехой атакующему. SIEM не заменяет отдел Информационной Безопасности, а является инструментом, требующим высококвалифицированных специалистов, для достижения значимых результатов.
Убедитесь, что ваша организация способна использовать SIEM. Имеются ли необходимые ресурсы и персонал? Сможете ли вы нанять и обучить новых сотрудников? Если “нет”, то, возможно, лучшим решением для вас будет рассмотреть услуги от сторонних сервисных организаций (интеграторы и/или MSSP).
Вопрос №2. Что моя организация ожидает получить от внедрения SIEM?
Это кажется очевидным, но вы должны знать требования, выбирая себе SIEM или аналитическую систему безопасности. Расставьте приоритеты требований Бизнеса и Отдела Безопасности перед началом процесса тестирования и оценки систем. Какие системы будут являться источниками логов? Требуется ли сбор событий в режиме реального времени? Все ли логи нужно собирать, либо же только с критичных подсистем? Что требуется архивировать и как долго хранить? Как будут использоваться собранные данные — для расследований? поиска уязвимостей? аудита и проверки на соответствие стандартам?
Вопрос №3. Нужно ли нам полноценное решение, либо достаточно лишь системы обработки логов?
Возможности SIEM решений впечатляют, но это недешевое удовольствие для Бизнеса и, к тому же, сложное в обслуживании. Если вы заглядываетесь на самую “крутую” систему, но не задумывались еще о способе написания/получения “крутых” Use Case’ов к ней [скрипты, правила, визуализация], то вам стоит пересмотреть ваш подход.
Например, много требований соответствия стандартам безопасности могут быть легко выполнены “простой” системой log management (сбор, хранение, анализ и возможность поиска). Поэтому если основная ваша задача именно обработка логов, а не корреляция событий безопасности — не покупайте избыточное решение.
Вопрос №4. Требуется традиционный SIEM или анализ безопасности в Big Data?
Системы обработки больших массивов данных и поиска скрытых закономерностей завоевывают свое место под солнцем на рынке SIEM. Это очень эффективные системы, но еще более сложные. Поэтому они “по зубам” лишь компаниям с достаточным финансированием и зрелым и укомплектованным Отделом ИБ, в таких условиях они способны проявить все свои сильные стороны.
Будьте осторожны — если ваша компания имеет риск не осилить SIEM, то еще меньше шансов, что big data security analytics будет нормально работать. Аналитик Gartner Антон Чувакин советует “не платить за гламур Big Data, если невелик шанс оправдать инвестиции”.
Вопрос №5. Сколько денег есть возможность потратить на покупку и настройку системы?
Серьезная SIEM требует серьезных денег. Это и стоимость лицензии на сам продукт (и, возможно, услуг по интеграции и настройке), и затраты на сопутствующую ИТ-инфраструктуру (базы данных, системы хранения и т.д.), и затраты на обучение персонала. Итоговая стоимость легко может достигать сотен тысяч долларов, в зависимости от указанных параметров.
Как вариант экономии можно рассмотреть урезанные версии SIEM у именитых производителей или полноценные, но недорогие — у нишевых игроков. Вы не получите какой-то продвинутый функционал, но все же сможете решать бОльшую часть задач для SIEM, стоЯщих перед отделом информационной безопасности.
5 вопросов к возможностям выбираемой SIEM и поставщика
Вопрос №6. Как их продукт закроет требования соответствия стандартам и аудитам ИБ?
Задача соответствия требованиям различным ИБ-стандартам является одной из самых частых причин приобретения SIEM. Поэтому в большинство решений уже “из коробки” встроена поддержка аудита и отчетности по наиболее популярным стандартам, таким как HIPAA, PCI DSS и SOX. Компания значительно сэкономит во времени и ресурсах, используя такую автоматическую отчетность SIEM, но предварительно убедитесь, что нужный вам отчет будет в поставке и подходит вам. Какие еще преднастроенные отчеты есть “из коробки”? Каковы возможности по их самостоятельной подстройке?
Вопрос №7. Какова экспертиза поставщика по развертыванию и настройке? Обучению персонала?
Довольно велик риск неудачного внедрения столь сложной системы, как SIEM. В отчете 2014 года аналитик Gartner Олифер Рочфорд сообщил, что от 20% до 30% клиентов недовольны результатами внедрения. А будучи успешно развернутой, система SIEM потребует квалифицированных безопасников для ежедневной работы с ней. Спросите у поставщика, какую поддержку он способен оказать при внедрении решения и, если потребуется, при обучении ваших сотрудников.
Вопрос №8. Поддерживает ли данная SIEM работу с облаками и Big Data платформами? Т.е. будет ли решение, приобретаемое сегодня, работать с системами, купленными завтра?
Облачные (Software, Platform, Infrastructure)-As-A-Service продукты и платформы обработки Big Data уже используются в вашей организации или начнут использоваться буквально завтра. Если вы тратите серьезную сумму на покупку SIEM сегодня, то явно хотите быть уверены возможности интеграции с новыми системами завтра.
Вопрос №9. Сколько источников логов уже поддерживает SIEM? Насколько сложно подключить новый малоизвестный?
SIEM будет неполноценной, если не сможет принимать логи из важного источника событий вашей организации. Убедитесь, что большинство ваших систем будут подключены к SIEM штатными средствами, а сложность подключения специфического оборудования (или самописного приложения) будет не высока.
Основными источниками логов будут системы информационной безопасности (такие как фаервол, IPS/IDS, VPN, почтовый сервер, система антивирусной защиты и пр.), а также клиентские и серверные операционные системы.
Вы купили SIEM и уверены, что SOC у вас в кармане, не так ли?
Как-то с месяц назад меня пригласил к себе один мой старый знакомый, директор по ИБ в одной достаточно крупной компании, с целью, по его словам, «удивить меня». Отмечу, что ранее мы с ним обсуждали вызовы, с которыми столкнулись многие компании в области киберугроз и проблемы построения SOC (Security Operation Center).
Так начинается моя история о построении SOC в компании.
С присущей моменту церемониальностью, директор по ИБ сопроводил меня в опенспейс их Департамента ИТ. И там мне продемонстрировали груду коробок с дорогим «железом», а также распечатку спецификации. Она указывала на покупку лицензий одного всеми известного вендора, входящего в Quadrant for SIEM. Неподдельная радость на его лице говорила о том, что озвученные проблемы из прошлого разговора решились в одночасье. А позже он рассказал мне, что в дополнение к данному «сокровищу» были согласованы деньги на внедрение данной системы, и запланирован наем трех специалистов в штат под данную активность. При этом он сделал особый акцент на «трех специалистах», как бы давая понять, что глубоко проработал вопрос и всё просчитал. Расчет был действительно относительно здравым, но к сожалению, не проверенным эмпирически.
Мы сели и обсудили как структуру проекта построения SOC, так и предложенную им экономическую модель. Попытались оценить выделенные ставки, роли и компетенции, необходимые для выхода на необходимый уровень сервиса.
Изначально, задумка была в том, чтобы поддержку работоспособности «железа» делегировать Департаменту ИТ, отправив их инженеров на специализированные курсы вендора. Далее первую ставку задействовать под инженера-прикладника SIEM. Ожидалось, что данный товарищ сможет после обучения подключать источники событий, а ещё «желательно писать коннекторы, если потребуется» (прямая цитата). Также, в остальное время, участвовать в разборе простых инцидентов. Вторая и третья ставки планировались под экспертов для разборки инцидентов, формировании новых правил корреляции, и развития направления в целом. Также учитывался тот факт, что инцидентов может быть много, а в моменте какой-то из экспертов может заболеть или уйти в отпуск.
На вопрос: «Какой был прогноз: по количеству источников, инцидентов, сложности событий и ожидаемым срокам реакции?», был получен очень сумбурный ответ, а дальше молчание и в заключении, с грустью в голосе: «Потом что-нибудь придумаем. ».
Данный кейс можно назвать вполне типичным для тех компаний, которые по каким-то причинам осознали необходимость внедрения SOC, но не смогли комплексно оценить «масштабы бедствия».
Мы «созрели», нам нужен SOC
Одной из предпосылок внедрения SOC является достигнутая определенного уровня зрелость компании. Этот уровень позволил ранее закрыть, согласно пирамиде потребностей, базовые вещи и осознать, что теперь для целостной картины не хватает одного важного компонента. Действительно, после того как компания навела порядок в инфраструктуре (архитектура сети, сегментация, домены, процедуры обновления и прочие полезные штуки), а также внедрила необходимый и достаточный набор средств защиты информации (эшелоны защиты, endpoint и пр.), то она невольно задается вопросом: «Как мне всё моё хозяйство видеть и как оценивать то, что я увижу?».
На тот момент в компании предположительно уже существуют выстроенные процессы. Многие из них построенные в лучших традициях ITIL. Support-подразделение ИТ (в некоторых случаях и ИБ) разделено на линии поддержки, и возможно даже есть смены с режимом работы 24*7. Однако стоит отметить, что такие компании встречаются редко, и на моей памяти только 3 из 10, с численностью более 1 000 рабочих станций, могут похвастаться всем этим перечнем достижений.
Все же, если как пример, взять эти 30% счастливчиков, то перед ними стоит задача реализовать интеграционный проект, который должен выродиться в очень важный и критичный сервис. В рамках проекта, описывая жирными мазками, надо:
SOC – это используемые технологии, эксперты и выстроенные процессы.
Технологии SOC – это те инструменты, которые использует сервис для автоматизации сбора информации, корреляции и первичной аналитики. Безусловно, инструментарий определяется имеющимися возможностями и функционалом.
Эксперты SOC – участники команды, с компетенциями по направлениям:
При этом, самым главным требованием к этим процессам является то, что они должны быть бесшовно внедрены в текущие бизнес-процессы организации. Другими словами, процессы SOC не могут стоять отдельно «особняком» и должны быть, во-первых, филигранно выстроены, а, во-вторых, эффективно выполнять свою задачу – приносить ожидаемую ценность. Также отметим, что под «филигранностью» критичного сервиса понимается абсолютная четкость и согласованность в действиях сотрудников смежных подразделений, при которой не допускается простой и нарушение заданных параметров SLA даже в случае форс-мажора. Не говоря уж о популярных: «сотрудник был на обеде» или «не смогли дозвониться». Результат должен быть четким и в заданный срок. По этой причине, модель работы SOC похожа на военную службу, а принятые регламенты и инструкции — на безоговорочно исполняемый устав.
Парадоксально, но многие уверены, что главной компонентой SOC является инструментарий. В этом случае было бы уместным привести следующий пример. Представляете, вы идете, не дай бог, на операцию. Новость не из радостных, и вас в клинике начинают подбадривают словами о том, что операцию будет делать какой-то хирург, но у него потрясающий скальпель одного из самых дорогих производителей. Причем про «чудо-скальпель» вам скажут несколько раз, а может даже покажут сертификат, подтверждающий его остроту и чистоту металла. Предполагаю, что вас этот аргумент не особо успокоит и вы захотите навести справки о докторе, а также его опыте проведения похожих операций.
Безусловно, выбор SIEM-системы крайне важен и ее функционал должен четко отражать запросы покупателя. Однако всегда нужно помнить тот факт, что SIEM – это только автоматизация, для настройки которой нужны глубокие компетенции и вполне четкая логика работы.
Эксперты и процессы являются краеугольным камнем при создании SOC
Из приведенного выше перечня необходимых компетенций можно понять, что специалисты SOC это универсальные и высококвалифицированные сотрудники, которые должны находиться на стыке глубоких технических знаний, а также иметь опыт аналитика. К тому же, направление SOC достаточно молодое для РФ и СНГ, а это означает, что в данной предметной области мало экспертов. Встретить на рынке грамотных и «свободных» специалистов крайне сложно. В первую очередь такие специалисты заинтересованы работать, занимаясь новыми и интересными кейсами, которые позволяют развиваться. Нужен поток. По этой причине, они часто «оседают» в крупных сервис-провайдерах и осуществляют ротацию только между аналогичными структурами.
Стоит отметить и уровень зарплат данных специалистов. Ранее коллеги неоднократно приводили аналитику . Информация вполне актуальна и по сей день, за исключением только уровня зарплат – они стали выше, и по рынку в среднем на 15-20%. Это значит, что компания, изъявившая взять в штат экспертов должна выложить вполне серьезные деньги. Насколько эти деньги релевантны приносимой пользе, при условии, что мало какая компания (исключение – «Сервис-провайдер») может утилизировать время такого эксперта хотя бы на 70%? Даже, если такого эксперта схантили высоким окладом, вероятность того, что он подыщет себе более интересную работу – высока. К тому же, есть статистика, что участники команды такого рода проекта-сервиса за 3-7 лет полностью обновляются. Это реальность и с ней надо считаться.
Итак, компания купила замечательный инструментарий, функциональную и эффективную SIEM-систему, взяла в штат талантливого и опытного эксперта по SOC, который смог создать дружную и согласованную команду ответственных специалистов. Далее эта команда должна взять систему на сопровождение, разработать необходимые процедуры и регламенты, внедрить их и начать по ним работать. Стоит отметить, что даже после хорошего консалтинга со стороны интегратора, который помогал стоить SOC (внедрял систему, делал аудит процессов, создавал базовые правила и писал необходимые инструкции), на плечи команды SOC ложится огромный пласт работ по оптимизации созданного под реалии компании центра реагирования. Причесывание процессов и схем работы следует в режиме «case by case».
Если же консалтинга не было, и команда должна построить SOC самостоятельно, то история становится ещё более интересной и затратной. Это как студента-выпускника (пусть хоть с красным дипломом) в первые дни работы на производстве ставить на самый ответственный участок, и надеяться, что он «как-нибудь сориентируется».
Отсюда следует, что чтобы доверить построение SOC создаваемой команде, нужно быть готовым к двум сценариям:
А может лучше SOC as a Service?
Сейчас Интернет пестрит последними трендами: цифровая трансформация (digital-transformation), компании полностью уходят в «облака», непрофильные процессы выносят на аутсорсинг. Крупные компании начинают предлагать платформы, с помощью которых можно набрать необходимое количество сервисов для поддержания и развития бизнеса любого размера. Аутсорсинг по бухгалтерии, юридическим услугам, call-центрам, IT «под ключ»: это только начало глобальных изменений. Причем виды сервисов могут быть абсолютно любыми. Те, которые ещё вчера казались бы невероятными и оригинальными, как например «аутсорсинг печати», сегодня пользуются огромным спросом. Причем тренд развития сервисно-ориентированной модели мы можем увидеть по Западному рынку, который традиционно опережает РФ и СНГ. Он огромный и покрывает все отрасли.
SOC as a Service (SOCaaS) не является исключением. На рынке достаточно игроков, провайдеров сервисов информационной безопасности (Managed Security Service Provider, MSSP), которые предлагают клиентам не «изобретать колесо», а просто воспользоваться экспертизой и опытом в этой области. Эксперты именно здесь, на «потоке», набивают руку и получают огромный опыт, который позволяет им составлять четкие и эффективные процессы. Они собирают все грабли, чтобы проанализировать все возможные сценарии и предложить опции, релевантные потребностям клиентов. Клиенту не надо ничего придумывать, он просто примеряет на себя предлагаемые опции и выбирает нужные.
Что самое «вкусное» в этой истории, так это то, что:
А что в итоге?
Для моего товарища есть два варианта для успешного выхода из данной ситуации:
Однако надо признать, что даже самый лучший сервис не является универсальным средством решения всех проблем и болей клиента. И всё как обычно остается на откуп конкретной задачи, размеру кошелька и педантичности заказчика SOC.
Денис Гущин, заместитель генерального директора Infosecurity.
Исследовательская и консалтинговая компания, специализирующаяся на рынках информационных технологий Gartner определяет технологию Security Information and Event Management (SIEM) как одну из трех основополагающих технологий Security operations center (SOC) (центр мониторинга и оперативного реагирования на инциденты).
Попробую рассказать простым языком. Для технического обеспечения информационной безопасности есть два принципиально разных подхода:
Превентивный способ защиты информации, простым языком, направлен на недопущение нарушения состояния информационной безопасности активных объектов, например, блокирование запуска вредоносного файла антивирусом или запрет на входящее несанкционированное подключение межсетевым экраном. Таким образом, угрозы информационной безопасности пресекаются в зародыше — всё направлено на сохранение информации с помощью превентивных средств.
Суть детективного подхода заключается в том, чтобы собрать как можно больше информации о неком событии или действии, при условии, что мы точно не знаем, являются ли эти события или действия легитимными или нет.
Сотрудник отправляет коллеге по электронной почте зашифрованный файл, а антивирусная система не может проверить его — он не открывается без ввода пароля.
И тут возникает логические вопросы: Что делать в таком случае? Блокировать отправку? А вдруг это важное и срочное сообщение, а файл — годовой финансовый отчет, запароленный для большей надежности.
А если это на самом деле вирус, который сам себя распространяет по сети компании, избегая обнаружения таким вот образом?
Таким образом задача детектирующих средств — собрать о данном событии как можно больше информации и отправить специалисту по информационной безопасности для того, чтобы он принял решение. Возможно, потребуется телефонный звонок отправителю сообщения для получения дополнительной информации или согласование такой отправки у руководителя. Вот собственно один из множества примеров логики SIEM
КАК ЖЕ ВЫГЛЯДИТ РАБОТА СИСТЕМЫ SIEM НА ПРАКТИКЕ?
Чтобы ответить на этот вопрос, представим себе компанию среднего размера, т.е. с числом сотрудников около 1000, каждый из которых работает за ПК, а важная информация и бизнес-системы хранятся и работают на серверах. В такой компании общее число типов технических систем защиты, как превентивных, так и детектирующих, легко может перевалить за десяток. Давайте перечислим распространенные типы средств защиты информации:
1. Антивирусы, предотвращают выполнение вредоносного кода и деятельность вредоносного программного обеспечения на конечных точках (рабочих станциях и серверах), в локальном и веб-трафике, в электронной почте.
2.Средства антиэксплойт защиты, позволяют обнаруживать и предотвращать вредоносное воздействие эксплойтов, т.е. программ или набора команд, использующих уязвимости установленного прикладного или системного программного обеспечения.
3. Системы контроля и управления учетными записями, осуществляют централизованное управление учетными записями пользователей и администраторов ИТ-систем.
4. Средства предотвращения утечек данных, предназначены для защиты от несанкционированной передачи ценной информации в нарушение установленных в компании правил — например, копирование рабочей информации на флешку или отправка на личную почту.
5. Межсетевые экраны, контролируют входящий и исходящий сетевой трафик и в локальной сети, и в интернет. Цель контроля — разрешать нужный трафик легитимным приложениям и запрещать потенциально опасным.
6. Системы обнаружения и/или предотвращения сетевых вторжений, предназначены для анализа сетевого трафика и поиска в нем признаков того, что устройство пытаются атаковать через сеть с применением эксплойтов. Как следует из названия, системы обнаружения вторжений только оповещают о возможной атаке, а системы предотвращения вторжений автоматически блокируют подозрительный трафик.
7. Средства изолированного выполнения программ (Песочницы), позволяют запускать подозрительный файл в изолированной виртуальной среде, которая специально предназначена для поиска аномалий или потенциально вредоносного поведения исследуемого файла.
8.Сканеры уязвимостей, предназначены для проведения анализа уязвимостей различных ИТ-систем путем получения данных об используемых версиях ПО и сравнением данной информации с каталогами известных уязвимостей, применимых к данным версиям.
9.Системы ресурсов-приманок для злоумышленников (англ. honeypots и honeynets) представляют собой заранее созданные «муляжи» информационных систем, похожих на реальные системы компании, но не содержащих никаких ценных данных. Атакующие, попав в такую ловушку, попробуют применить свой инструментарий для проведения атаки, а в этот момент их действия будут тщательно журналироваться и затем изучаться специалистами по защите информации.
10. Средства управления портативными устройствами (англ. MDM – Mobile Device Management) представляют собой программы для контроля и защиты портативных устройств сотрудников организации. Установив такое средство на своё устройство, сотрудник может получить контролируемый и безопасный удаленный доступ к ИТ-ресурсам организации, например, подключив себе на смартфон рабочую почту.
Но, однако же, вернемся к системам SIEM. После того, как мы увидели, какими многообразными бывают системы защиты давайте подумаем, как можно получить данные со всех таких систем, обработать их и сделать пригодными для того, чтобы они помогли специалисту по Информ. Безопасности расследовать инцидент информационной безопасности.
Первая задача SIEM — получить данные от источника. Это может быть как «активный» источник, который сам умеет передавать данные в SIEM и ему достаточно указать сетевой адрес приемника, так и «пассивный», к которому SIEM-система должна обратиться сама. Получив от источника данные, SIEM-система преобразует их в единообразный, пригодный для дальнейшего использования формат — это называется нормализацией.
Далее SIEM-система выполняет таксономию, классифицирует уже нормализованные сообщения в зависимости от их содержания: какое событие говорит об успешной сетевой коммуникации, какое — о входе пользователя на ПК, а какое — о срабатывании антивируса. Таким образом, мы получаем уже не просто набор записей, а последовательность событий с определенным смыслом и временем наступления. Значит, что мы уже можем понять, в какой последовательности шли события и какая может быть связь между ними.
Далее включается основной механизм SIEM-систем: корреляция. Корреляция в SIEM — это соотнесение между собой событий, удовлетворяющих тем или иным условиям (правилам корреляции). Пример правила корреляции: если на двух и более ПК в течение 5-ти минут сработал антивирус, то это может свидетельствовать о вирусной атаке на компанию. Более сложное правило: если в течение 24 часов были зафиксированы чьи-то попытки удаленно зайти на сервер, которые в конце концов увенчались успехом, а затем с этого сервера началось копирование данных на внешний файлообменник, то это может свидетельствовать о том, что злоумышленники подобрали пароль к учетной записи, зашли внутрь сервера и крадут важные данные. По итогам срабатывания правил корреляции в SIEM-системе формируется инцидент информационной безопасности. При этом специалист по ИБ при работе с SIEM должен иметь возможность быстрого поиска по хранящимся в SIEM-системе предыдущим инцидентам и событиям на случай, если ему потребуется узнать какие-либо дополнительные технические подробности для расследования атаки.
Таким образом, основные задачи SIEM-систем таковы:
-Получение журналов с разнообразных средств защиты
-Нормализация полученных данных
-Таксономия нормализованных данных
-Корреляция классифицированных событий
-Создание инцидента, предоставление инструментов для проведения расследования
-Хранение информации о событиях и инцидентах в течение длительного времени
-Быстрый поиск по хранящимся в SIEM данным
Подводя итог, можно сказать, что системы SIEM необходимы компаниям для работы с большим потоком разнородных данных от различных источников в целях выявления потенциальных инцидентов информационной безопасности и своевременного реагирования на них. Польза от внедрения и применения SIEM-системы заключается в том, что она значительно ускоряет процесс обработки инцидентов ИБ и получения требуемой информации о событиях ИБ: аналитику не нужно подключаться к каждому средству защиты информации, он видит все данные в едином, консолидированном виде в одном удобном интерфейсе.