В настоящее время сложность систем даже в относительно небольших компаниях достигла такого уровня, что поток сообщений может составлять несколько десятков в секунду. Анализировать их в ручном режиме невозможно. И тут на помощь приходят системы анализа и корреляции событий.

Долгая дорога к SIEM

В принципе системы обеспечения информационной безопасности, базировавшиеся на анализе поведения, существовали довольно давно. Еще в популярной в свое время книге самоучителе Фигурнова, по которой осваивали азы компьютерной грамотности первые поколения покорителей ПК, была описана антивирусная утилита anti4us, которая позволяла блокировать операции, характерные для вредоносного ПО. Напомню, первые издания этой книги выходили в конце 80 х годов прошлого века. Так что поведенческий, или, по другому, эвристический анализатор появился в антивирусных приложениях даже раньше, чем сигнатурный. Сейчас оба механизма используются совместно.

Примерно тогда же, возможно, чуть раньше стали использовать и средства журналирования (или логирования) событий. Однако в массовых системах этот метод начал применяться уже в 90 е годы и быстро завоевал популярность как простой и надежный способ выявления всяческого рода неисправностей и не только их. Другое дело, что эти механизмы не всегда применялись, поскольку в ряде случаев логирование могло снижать производительность, причем довольно существенно. Особенно если речь шла о серверах баз данных и ПО, которое работало поверх них. Однако уже в конце 90 х производительность серверов даже младших моделей достигла такого уровня, что активизация данной опции перестала оказывать влияние на быстродействие. Ну а у сетевого оборудования и программно--аппаратных комплексов обеспечения безопасности функция логирования была включена изначально.

Так что к рубежу прошлого и нынешнего веков задача сбора информации была в основном решена. Однако при этом возникла новая проблема: приходилось обрабатывать большие объемы данных, с чем операторы перестали справляться. Средства анализа логов, которые появились почти сразу, облегчали задачу, но не решали ее в комплексе.

Усложнились к тому времени и угрозы. Например, червь Slammer, появившийся в 2003 году, заражал несколько узлов в секунду. Его появление практически вызвало панику, поскольку размножению этого вредоноса не могли помешать никакие из существовавших в то время средств защиты от внешних атак. Однако, как отметил тогда один из специалистов: «Это не проблема систем обнаружения атак, это проблема управления данными и их представления».

Тогда же возникла смежная задача обеспечить сбор данных для расследования инцидентов, связанных с искажением корпоративной отчетности. В частности, американский закон SoX обусловил появление разного рода требований к сбору информации, касающейся работы различных систем. Однако тут приходилось обрабатывать еще большие объемы данных, так как речь шла еще и о бизнес системах, которые генерировали просто гигантские объемы событий. И чтобы в них хотя бы разобраться, не говоря уже о том, чтобы привести их к юридически значимому виду, нужны были дополнительные средства.

Оба этих процесса привели к появлению систем управления безопасностью и событиями, или Security Information and Event Management (SIEM). К середине 2003 года на рынке уже было с десяток такого рода решений, разработанных как крупными компаниями, так и стартапами. В настоящее время рынок средств SIEM активно развивается и продолжает быстрый рост. К 2015 году его объем превысит, по оценке Frost&Sullivan, миллиард долларов. Основными игроками на нём как в мире, так и в России являются HP, IBM и Symantec (см. рис. 1). По итогам прошлого года эта «большая тройка» контролировала почти 80 % российского рынка. Имеются и решения с открытым кодом, среди которых наиболее известным является OSSIM.

Как это работает

Цель таких систем состоит в том, чтобы по некоторым признакам определить первопричину того или иного инцидента. Тут можно привести аналогию с диагностикой болезни по её симптомам. Если, скажем, заложен нос, мучает кашель с обильным выделением мокроты, головная боль, но нет температуры и не болит горло, то с большой долей вероятности мы имеем дело с насморком.

К настоящему времени SIEM системы принято делить на два поколения (http://habrahabr.ru / post / 159929 / ). Самые первые (рис. 2) могли анализировать относительно небольшой набор источников для выявления подозрительных событий, из которых оператор мог вычленить явные угрозы и нарушения. Системы второго поколения (рис. 3) обладают уже вполне развитым интеллектом на основе поведенческого анализа, позволяющим обращать внимание на явные. В итоге такие системы выявляют как минимум на четверть больше потенциально опасных инцидентов, чем их предшественники.

Важно отметить, что информация о событиях собирается из разных источников. Причем приоритет этих событий с точки зрения системы, которая его зафиксировала, может быть даже и не слишком значительным. Скорее всего он и будет таким: за угрозами нынче стоят профессионалы, и они накопили немалый опыт в том, что касается обмана средств защиты. Однако все вместе эти события могут быть признаком очень серьезного инцидента, чреватого крайне неприятными последствиями. Основными источниками информации для работы современных SIEM систем являются:

  • данные контроля доступа и аутентификации — для мониторинга контроля доступа к информационным системам и использования привилегий;
  • журналы событий серверов и рабочих станций — для контроля доступа, обеспечения непрерывности, соблюдения политик информационной безопасности;
  • сетевое активное оборудование (контроль изменений и доступ, счетчики сетевого трафика);
  • средства обнаружения и предотвращения вторжений (IDS / IPS) — события о сетевых атаках, изменение конфигураций и доступ к устройствам;
  • антивирусная защита — события о работоспособности ПО, о базах данных, об изменении конфигураций и политик, о вредоносных программах;
  • сканеры уязвимостей — инвентаризация активов, сервисов, программного обеспечения, уязвимостей, поставка инвентаризационных данных и топологической структуры;
  • системы для учета рисков, критичности угрозы, приоритизации инцидента;
  • прочие системы защиты и контроля политик ИБ — DLP, мониторинга фрода, контроля устройств;
  • системы инвентаризации и управления активами — для выявления новых устройств и ПО, в том числе установленных несанкционированно;
  • системы учета трафика.

Впрочем, совсем не обязательно иметь все системы из списка. Например, наличие систем инвентаризации и управления активами для типовой российской компании будет скорее исключением, чем правилом. Тем более, что несанкционированную сетевую активность, которая исходит от самовольно установленных устройств и приложений, легко выявить и пресечь. И тому есть примеры при реализации проектов. Например, в одной из энергетических компаний был выявлен факт использования сотрудниками технологической сети для игр. Этот факт был выявлен за счет обнаружения нетипичной для легитимных приложений сетевой активности. Также было обнаружено, что ПК, управляющие технологическим оборудованием, периодически подключаются к Интернету с помощью собственных GSM-¬модемов. В другой компании, также благодаря обнаружению не вполне типичной сетевой активности, а именно входа на нетипичный порт, был выявлен факт несанкционированного использования ПО мгновенного обмена сообщениями «Mail. RU Агент», который не блокировался межсетевым экраном. Утверждается, что таким же образом можно пресечь деятельность и более опасного ПО, в том числе для таргетированных атак, для которых используются заказные вредоносы, специально разработанные против той или иной компании, и которые в принципе не выявляются тиражными антивирусными средствами. В целом же SIEM способна выявлять сетевые атаки во внутреннем и внешнем периметрах; вирусные эпидемии или отдельные заражения вредоносным ПО; попытки несанкционированного доступа к конфиденциальной информации; фрод и мошенничество; ошибки и сбои в работе информационных систем; уязвимости; ошибки конфигураций в средствах защиты и информационных системах.

А всем ли это подходит?

Как и любые другие системы обеспечения безопасности, SIEM — не панацея. Хотя бы потому, что их внедрение, что бы ни говорили вендоры и интеграторы, является уделом крупных компаний. Это довольно сложный, дорогой и длительный интеграционный проект.

При этом построенную систему обязательно надо периодически перенастраивать, поскольку ситуация с угрозами постоянно меняется: одни исчезают, зато появляются новые. То же самое относится и к требованиям регуляторов. А автоматического обновления разработчики SIEM систем (в отличие от многих других), как правило, не предусматривают.

Но настройка систем является непростой процедурой, требующей навыков профессионального программиста. Да и тогда, когда средства настройки имеют, казалось бы, несложный визуальный интерфейс, необходимо хорошо знать, как функционируют информационные системы. Иначе есть риск допустить ошибки, в результате которых корпоративная ИТ¬-инфраструктура потеряет работоспособность или упадёт производительность. Возможно и такое, что появятся новые бреши в системе безопасности, которыми вполне могут воспользоваться злоумышленники. При этом чужой опыт вряд ли будет применим. Например, по данным компании «Информзащита», переносимыми в ходе разных проектов внедрения SIEM систем оказывается не более 20 % правил корреляции. А иметь квалифицированного аналитика, способного разработать эти самые правила и поддерживать их в актуальном состоянии, могут позволить себе очень немногие компании.

И наконец, наиболее «продвинутые» механизмы работы SIEM систем дают немало ложных срабатываний. В итоге, как отметила эксперт исследовательского центра Positive Research Олеся Шелестова, очень немногие заказчики используют что то отличное от заранее предустановленных вендором правил и ограниченного набора типовых шаблонов. Впрочем, обычно этого бывает достаточно.

Три болезни SIEM

Павел Волков, директор Центра компетенций по управлению операционными рисками, «Открытые Технологии»

К наиболее серьёзным болезням SIEM можно отнести следующие.

1. Система отсеивает всё то, что ей «не нужно». Если некое поле лога, в котором раньше вы не испытывали потребности, теперь стало для вас жизненно необходимо, то в лучшем случае вам предстоит написать новый парсер для логов и «проиграть» их в системе снова, а в худшем — информация будет утрачена навсегда. Как при этом поступать с дублированием событий — вопрос особый и нетривиальный.

2. Невозможность для системы продолжать работу при изменении формата лога. А это происходит часто.

3. Ограниченность «корреляционной и поведенческой» идеологий. Они предполагают полное понимание нами всех событий и возможных их сочетаний, чего в жизни не бывает. Именно по этой причине прилично работают только очень простые и очевидные правила.

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

Для логов удобнее всего иметь систему, в которой вы сможете найти любую смысловую информацию вне зависимости от того, знал ваш парсер лога назначение конкретного поля или нет. Для такой системы нет необходимости в разработке парсеров, и начинать использовать её можно сразу. При этом она не боится изменения формата логов. Что же касается корреляций и анализа поведения, то имеет смысл говорить скорее о статистических характеристиках потока событий и использовании элементов прогнозирования для обнаружения аномалий.

Так что современное поколение SIEM — это, увы, умирающая технология, не способная справиться со слишком быстро меняющимся ИТ-ландшафтом. Данные системы сложно и бессмысленно внедрять, так как они устаревают еще до того, как начнут полноценно работать. На смену этому поколению приходит другая парадигма: решения на базе Big Data. В качестве инструментов анализа событий начинают работать методы data mining, а не банальная псевдокорреляция современных SIEM. Именно такой подход способен обеспечить и сбор всей необходимой информации, и поиск по ней в режиме, близком к реальному времени, и независимость от изменения формата логов на протяжении жизни системы, и полноценное использование инструментов статистической обработки информации и прогнозирования с учётом «сезонности». И что самое интересное, внедрять и использовать такую систему очень просто — не сложнее поисковых машин типа Google. А это умеют почти все.