С появлением первых средств защиты информации возникли первые насущные вопросы: как узнать, что возведенные баррикады работают и защищают? как быстрее реагировать на оповещения? как понять, какие угрозы удалось предотвратить? Работает ли наш файерволл, можно узнать, выполнив ICMP ping: если правила в ACL (access control list) работают, то ответов, содержащих echo request, быть не должно. Можно через консоль устройства просмотреть журнал событий, разбирая сотни или тысячи строк вручную и пытаясь увидеть отраженную или выявленную угрозу.
Время — деньги
Журналов событий, получаемых от одних только активных средств защиты, — много, не говоря уже о критических серверах, базах данных, приложениях. При помощи этих журналов можно выявить несанкционированные попытки доступа, сетевые атаки, аномалии, ведущие к нарушению непрерывности бизнеса или политик безопасности. Чтобы открыть журнал событий, нужно выполнить последовательность действий, которые требуют времени: запустить приложение, подключиться к консоли, вывести список событий и изучить его. Даже если допустить, что один сотрудник отвечает только за контроль антивирусного ПО (предположим, что имеется централизованная консоль управления), установку обновлений и IPS (предположим, что их не более 2—4), — на просмотр событий от этих источников и разбор проблем за последние сутки у него уйдет около часа. Отметим человеческий фактор: офицер может быть загружен другими делами, может болеть или быть в отпуске, отвлечься от работы или выполнить ее для проформы. Теперь посчитайте, сколько человеко-часов нужно, чтобы анализировать журналы событий на критических активах хотя бы раз в сутки? Учтите в расчетах заработную плату квалифицированного сотрудника, способного выявить угрозы в этих журналах событий, учтите время, необходимое для подключения к СЗИ в вашем филиале по медленным каналам связи. Дорого? Да, выходит круглая сумма, назвав которую руководству, вы, скорее всего, будете выставлены из кабинета.
Итак, вы установили средства защиты, настроили их, они работают, — что вам еще нужно? SIEM заменяет не один десяток человек, работает оперативно и не будет просить о повышении зарплаты.
Защита бизнеса
Главная задача ИБ — обеспечить защиту бизнеса и непрерывность бизнес-процессов. Что для этого нужно? Описываются бизнес-процессы, определяются активы, проводится их аудит (включая сканирования и пентесты), составляется модель нарушителя, изучаются риски, составляется план их минимизации. Какие меры принимаются для минимизации риска? Создаются политики, проводится обучение пользователей, устанавливаются средства защиты информации, изменяются конфигурации, устанавливаются обновления… Мы все это сделали — и оставили как есть? до следующего цикла PDCA?
Держать руку на пульсе
Принцип «поставить и забыть» в ИБ неприменим. Абcолютной защиты не существует, и самые маловероятные риски могут аукнуться остановкой бизнеса и огромными финансовыми потерями. Любое программное и аппаратное обеспечение может перестать работать или быть неверно настроено — и пропустить угрозу. Видели панель управления в современных самолетах? Все важные индикаторы собраны воедино с соблюдением эргономики и приоритета. Пилот и его помощник не могут не увидеть нарушение критически важного показателя. Так и в SIEM: в случае любого отклонения от baseline или политик (курс самолета) или нарушения работоспособности актива в результате сбоев или угроз (неполадки в оборудовании) — операторы-пилоты будут незамедлительно уведомлены.
Почему незамедлительно и что будет через час? Вирусы распространяются в считанные секунды, у злоумышленников имеются автоматизированные комплексы для анализа и эксплуатации уязвимостей. Событие о посыпавшемся RAID-массиве в системе, находящейся в промышленной эксплуатации, завтра вам будет уже не интересно, ибо часть данных (или даже все) будут утеряны. Чем оперативнее вы будете информированы, чем быстрее предпримете меры, — тем меньше финансовых потерь понесет ваш бизнес. Хорошо, если случившийся инцидент не будет иметь последствий (возвращаясь к самолетам: «Вася, прикинь! Мы вчера с Парижа в Москву на одном движке долетели!»).
Превентивной защиты не существует
Если мы устанавливаем централизованное антивирусное ПО — необходимо убедиться, что оно установлено везде, правильно сконфигурировано, работает с актуальными базами. Как? С помощью журналов событий.
Зачем? Представьте, что вы автоматизировали установку корпоративного антивирусного ПО и обновление баз. Аудит журнала событий вы осуществляете раз в два-три дня, но произошел сбой, в ОС на рабочей станции, стоящей на складе, не запускается сервис и она заражена вирусом, который распространяется по сети. Абсолютно не факт, что на всех серверах запрещен, к примеру, автозапуск, установлены все заплатки: в реальной жизни такого практически не бывает. Автоматически размещенный использующий уязвимость троян с автозапуском и распространением по сети или подделанным ярлыком на общем сетевом ресурсе приводит к коллапсу всей компании. Пока вы будете в авральном режиме анализировать случившееся — бизнес, скорее всего, будет простаивать, а начальство — нервничать и возмущаться. Финансовую оценку убытков от простоя предприятия легко произвести самостоятельно, благо это не так сложно. Кроме того, подобные сбои имеют свойство негативно влиять на премии и зарплату.
Контролируемая угроза, принятый риск
На практике встречаются случаи, когда безопасность идет вразрез с бизнесом. Случаются ситуации, когда нельзя поставить обновление, чтобы закрыть уязвимость (причин масса: сертификация, нестабильность работы, «не протестировано», конфликт с другим ПО), или, например, невозможно запретить RPC, поскольку бизнес-приложение перестанет работать. Затраты на устранение угрозы могут превышать возможные потери, поэтому риск «принимается». Однако мы можем контролировать подобные риски с помощью SIEM, реагировать на возникающие инциденты, возвращая по окончании года средства, выделенные на покрытие операционных рисков, обратно в бюджет. Естественно, что в данном случае не может быть и речи о просмотре оператором журналов межсетевого экрана без автоматического анализа и регистрации инцидентов как способа контроля рисков.
Нет причины — все виноваты
Вы наверняка сталкивались со случаями, когда для решения инцидента нет данных: отсутствует информация о точном времени и месте возникновения (не считаем звонки от пользователей), о том, что предшествовало инциденту; и мы не можем ответить на главные вопросы — почему произошел инцидент и кто в этом виноват. Нет, это нужно не для того, чтобы наказать виновных (хотя это тоже иногда необходимо). Главное, что необходимо выяснить по итогам инцидента, — что делать, чтобы инцидент не повторился. Причем одного только встроенного в OС журнала (Windows event log или syslog) может оказаться недостаточно.
Я не бог, я всего лишь системный администратор
В зрелой разветвленной инфраструктуре права администрирования делегируются достаточно широкому кругу сотрудников. Естественно, все эти сотрудники проходят проверку службы безопасности, и мы им доверяем. Но на практике зачастую сказывается людская психология: сотрудник, порушивший базу данных, RAID, принесший на личной флешке вирус, из-за которого «встал» бизнес-процесс, под страхом увольнения и штрафа, загнанный в угол — заметает следы, удаляя или подделывая журналы событий. Если не собрать вовремя эти журналы, то бизнесу будет нанесен вред в виде финансовых потерь и испорченной репутации. Собранные вовремя и консолидированные в хранилище журналы событий помогут вам принять правильное решение по итогам инцидента. Осуществить удаление данных (событий и инцидентов) из SIEM незаметно не получится: остаются записи в системном журнале, осуществляется контроль целостности. Доказательства в виде журналов событий в SIEM-системах помогут вашей организации в решении судебных вопросов.
Кто знает, что это за скрипт?..
Безусловно, можно построить управление журналами и какое-никакое управление событиями на «самописных» сценариях. Журналы собирать через syslog или открытое ПО. Можно все оформить на PowerShell, «батники», sh-сценарии, а об инцидентах сообщать на электронную почту. Как удобно и дешево!
Да, это приемлемо для малого бизнеса. Вернемся к нашему примеру с самолетом. Уберем мысленно все индикаторы с приборной панели (или сотрем их названия), а сообщения о неполадках будем направлять пилоту по СМС и на электронную почту… Как быстро пилоту надоест лазать в карман за телефоном и разбирать входящие письма?
SIEM-системы обладают функцией самодиагностики и контроля работы компонентов. Это не разбросанные тут и там «батники», целостность и работоспособность которых очень трудно проконтролировать. При использовании разрозненных сценариев практически невозможно будет защититься от подмены содержимого или просмотра административной учетной записи в незашифрованном виде. В отличие от SIEM: это комплексная система, сообщающая о непрерывности сбора событий, о сбоях в работе своих компонентов, о доступе к системным функциям и т. п.
Защищайте не только критические активы
Представим, что вы защитили критические (по вашему мнению) активы, к примеру бизнес-приложение или базу данных. Все прекрасно, денег потрачено в меру, сэкономили на отсутствии СЗИ для рабочих станций и двухфакторной авторизации для мобильных пользователей. Пользователей «зажали» групповыми политиками. Вот только не учли, что дверь с замком, стоящая посреди поля, — абсолютно неэффективна. Злоумышленники получат пользовательский и административный аккаунт с незащищенных рабочих станций или с мобильных устройств и с абсолютно легитимными запросами к вашей суперзащищенной базе данных «вытянут» все, что только можно. Деструктивные действия давно не в моде. Вы узнаете об утечке информации из новостей — и удивитесь: ведь все ваши серверы были надежно защищены! Это пример типовой атаки по модели APT. Запущенные процессы, новые библиотеки в OС, новые сервисы, открытые порты и соединения, повышение привилегий — все это можно увидеть в журналах событий на рабочих станциях, которые не являлись, по вашему мнению, критическими активами…
Защита должна быть комплексной. Доказательство тому — инциденты с Bit9 и RSA, которые почему-то не поставили разрабатываемую ими защиту на свои же рабочие станции.
Представления
Средства защиты, как правило, являются сигнатурными, то есть создаются на основе анализа уже известных угроз (вирусы, сетевые атаки, даже словарики в DLP). Новые угрозы вы можете выявить только с применением сложных алгоритмов корреляции (об RBR-корреляции — см. статью в нашем блоге — здесь не может быть и речи) на основе миллионов событий и показателей, а также анализа baseline. Человеческий не всегда способен комплексно проанализировать такой объем данных. Однако абстракция представлений в SIEM-системах способствует своевременному обнаружению угроз операторами. Система делает все предварительные расчеты и выводит показатели. Как минимум, к примеру, на основе анализа baseline система сообщает о новом DynDNS-трафике, о том, что зафиксировано по 10 безуспешных попыток входа с различных активов от имени доменного администратора. Как правило, система способна сообщить о трояне или брутфорсе (в зависимости от состава правил корреляции и возможностей конкретной системы). Применение более сложных алгоритмов корреляции позволит узнать причину инцидента (например, выявить подключение пользователем модема, в результате которого произошло заражение трояном и брутфорс). Человеку не под силу самостоятельно осуществлять такой анализ на основании миллионов текстовых событий. Возможность настройки панелей визуализации полезна как отдельным сотрудникам, так и для работы SOC (security operation center), а также подразделений ИТ и техподдержки.
Соответствие (compliance)
В ряде региональных, международных, национальных, отраслевых стандартов имеются требования к организации процесса управления журналами. Все SIEM-системы имеют шаблоны, соответствующие международным стандартам, и возможность добавления своих шаблонов для формирования отчета о соответствии по сбору и хранению событий. В случае с самодельной системой вам придется потратить значительные ресурсы, чтобы сделать подобные шаблоны в формате отчетов или интерфейса для аудитора.
Акценты
Неверное реагирование на инциденты сравнимо с некорректным поведением светофора. ИБ- и IТ-подразделения будут неспособны решать первоочередные задачи по обеспечению бизнес-процессов. SIEM обладает минимально необходимыми средствами организации процесса регистрации инцидентов (или имеет возможность интеграции со службой поддержки), способствующим контролю решения инцидентов и накопления базы знаний. В SIEM имеется возможность интеграции и приоритезации инцидентов в зависимости от их влияния на бизнес-процессы, от ценности актива и опасности угрозы. В некоторых системах возможна интеграция с системами управления рисками.
Существует ошибочное мнение, что SIEM плодит большое количество инцидентов, на которые подразделение ИБ попросту не успевает реагировать. Необходимо понимать, что SIEM — это не решение «из коробки» и, как и в случае с DLP-системами, здесь необходимо правильное внедрение, интеграция с источниками событий, индивидуальный подход к активному набору правил и алгоритмам корреляции. Гибкая система исключений и правильная настройка SIEM гарантируют вам акцент только на критически важных событиях — без флуда.
Поделитесь событиями
SIEM — это система не только для ИБ. Ошибки и сбои в операционных системах, сетевом оборудовании, ПО — информацию обо всем об этом сотрудники IТ-отдела могут почерпнуть в SIEM. IТ-отделу также хочется узнавать о возникающих инцидентах не по звонку пользователей, а заранее (тем более, что — как и инциденты ИБ — IТ-инциденты можно предотвратить).
SIEM — не слишком простое решение для процесса управления журналами, к тому же достаточно дорогостоящее для внедрения в малом и среднем бизнесе. Для его эксплуатации вам необходимо иметь как минимум одного квалифицированного сотрудника, который будет обеспечивать контроль непрерывности сбора событий, управлять правилами корреляции, корректировать и обновлять их с появлением новых угроз и в соответствии с изменениями в инфраструктуре. Установка SIEM в качестве «черного ящика» с активацией всех предустановленных правил корреляции без надлежащего контроля и управления приведет к растрате бюджета.
При успешном внедрении вы получите:
- корреляцию и оценку влияния IТ- и ИБ-событий и процессов на бизнес;
- SOC с анализом ситуации в инфраструктуре в режиме реального времени;
- автоматизацию процессов обнаружения угроз и аномалий;
- автоматизацию процессов регистрации и контроля инцидентов;
- аудит политик и стандартов соответствия, контроль и отчетность;
- задокументированное корректное реагирование на возникающие угрозы ИБ и ИТ в режиме реального времени с приоритизацией в зависимости от влияния угроз на бизнес-процессы;
- возможность расследования инцидентов и аномалий, в том числе произошедших давно;
- доказательную базу для судебных разбирательств;
- отчетность и показатели (KPI, ROI, управление событиями, управление уязвимостями).
Я привела лишь немногие примеры того, как SIEM поможет вашему бизнесу в обеспечении непрерывности, повышении оперативности, в решении проблем и инцидентов. Можно еще много писать об автоматизации, реакции (сценариях), предотвращении инцидентов и их расследовании. Об этом я постараюсь рассказать в следующих публикациях. Отдельно рассмотрим крайне важный момент, волнующий многих: как с помощью SIEM проследить влияние IТ- и ИБ-событий на бизнес.
До встречи! Жду ваших вопросов и комментариев.
Автор: Олеся Шелестова (oshelestova), исследовательский центр Positive Research.
Автор: ptsecurity
